From patchwork Sun May 22 16:41:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Suchanek X-Patchwork-Id: 9130981 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2F6BD60761 for ; Sun, 22 May 2016 16:42:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8CEB281B7 for ; Sun, 22 May 2016 16:42:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CBFD2281C1; Sun, 22 May 2016 16:42:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2FAE7281B7 for ; Sun, 22 May 2016 16:42:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752389AbcEVQmA (ORCPT ); Sun, 22 May 2016 12:42:00 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:36104 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752272AbcEVQmA (ORCPT ); Sun, 22 May 2016 12:42:00 -0400 Received: by mail-wm0-f52.google.com with SMTP id n129so45124185wmn.1; Sun, 22 May 2016 09:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8zk8tliv/fj+Gshw2QNRXiL7Rf8hxjrvItEhbPkf7tI=; b=HQH2BQBCELHYPPDKoiJoB2idbWiqgDXaAs1gwBMCW1izbEu826jEiMSOR/+mny88U0 pBh4D42vFT3xLpNB4J0KuhyavX3/BIpY+8GWK7fHrPyPfFcsme2pmBVsmRL3D9MJ+nRF prrptLDqJNTqBE0AldYlChPLQPbebVNAtVc51nSY2sl8a0UM5tzyKVKvdbUTYLMGBv1+ 5qfLJdS0cGMhH0vv4ka+reecaNOEIjqQeLyJoYRi/9f10xXecANMzksHYMorLDnRWQMZ 5SdXxEABHePCze7LMuM5EK0hE7CgiHXbzjdfCR7iDxis1Ld3pUjCdw/vU/ocVCmhUsaS TIug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8zk8tliv/fj+Gshw2QNRXiL7Rf8hxjrvItEhbPkf7tI=; b=Jg7f86qvsLMKL9NKerYWxeh7n9VBJ31SmYDwdWsIbiwB8CFv7fUgKzo694CJ2rsdAE GQOVPb3Y4LSTioAIWoXK3rQdqW1DJpCgn3C2tewGyirgxo+6KAc7HBZ6V5C+eOZ0iezs gu24J9VhXRTqGkBKA3J+jYEQgYZ74dMVaQ2Y2Aq9H3V6oKrcsQZ8ecDODug1BXCEFvNe VhezVKNIT+Yb3vyMZog6oSNW7Lj2i9SnlzdXFJRSWi2wHbiVrWXi5gHkl/7uKnxj99sT cq4lLL9jUorsQGbq7MExvEq6+4V7Mm6xZVWnWcbraIh28vPiK4a477+Dxgnh5v9t1nnM 0Row== X-Gm-Message-State: AOPr4FWRYspjSe1hfEnzrQU4pDgy1VvOHni7QHPD/bhrpbdb7x+i6gVjjBpR9s7bTjkitsI7joslpUnRBFGMsA== X-Received: by 10.194.55.10 with SMTP id n10mr12285139wjp.28.1463935318211; Sun, 22 May 2016 09:41:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.98 with HTTP; Sun, 22 May 2016 09:41:18 -0700 (PDT) In-Reply-To: References: From: Michal Suchanek Date: Sun, 22 May 2016 18:41:18 +0200 Message-ID: Subject: Re: sunxi spi clock problem To: Chen-Yu Tsai Cc: =?UTF-8?Q?Emilio_L=C3=B3pez?= , Michael Turquette , Stephen Boyd , Maxime Ripard , linux-clk , "linux-arm-kernel@lists.infradead.org" , Linux Kernel Mailing List , linux-sunxi Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, The debugfs output shows that spi2 is reparented under pll5 and the pll5 frequency remains unchanged. The request to get a 2GHz clock for spi is fulfilled on best-effort basis by giving the 864MHz pll5 clock which should theoretically result in 432MHz SPI clock. On 22 May 2016 at 16:58, Chen-Yu Tsai wrote: > Hi, > > On Sun, May 22, 2016 at 10:18 PM, Michal Suchanek wrote: >> Hello, >> >> I tried running a spidev test program on linux 4.6 and I uncovered a >> problem with the sunxi clk framework. >> >> Basically the system would lock up after running the test program. >> >> Digging deeper I found that it locks up with commit >> [47284e3e0f3c427c93f8583549b6c938e8a18015] spi: sun4i: allow transfers >> to set transmission speed >> >> This exposes a problem with the test program. I try to set the SPI >> sped to 1MHz but at other place the speed is multiplied by 1000 to >> save typing zeros so the actual requested speed is 1GHz. This commit >> probably allows that request to propagate leading to the observed >> system lockup. >> >> Given the parents OSC24M, pll6 and pll5 one of pll6 and pll5 is >> probably set up at 2GHz (or both in turn because due to some rounding >> neither goes fully up to 2GHz resulting in 864000000 SPI clock). Then >> the system locks up. > > IIRC the mod clock does not propagate rate changes up the tree. > But some output from the debugfs would be helpful. See below. > >> >> I can limit the speed in the SPI driver which is rated at 100MHz in >> SoC manual (giving 200MHz pll) but the clk driver should probably >> limit the clock setting to sane speeds itself. >> >> I am not familiar with the sunxi-clk code and it has unfortunately no >> debug prints which would show what is programmed to what speed. > > You can use /sys/kernel/debug/clk/clk_summary, provided you have > debugfs built in and mounted. root@a10s:~/spidisp# ./spitest -d -s 1000000 /dev/spidev2.0 Debug mode. /dev/spidev2.0: spi mode 0x0, 8 bits per word, 1000000000 Hz max Sending 00 clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------------------------- osc32k 0 0 32768 0 0 osc24M 6 6 24000000 0 0 ir0 0 0 24000000 0 0 spi2 0 0 24000000 0 0 spi1 0 0 24000000 0 0 spi0 0 0 24000000 0 0 ... spi_master spi2: spi2.0: timeout transferring 1 bytes@1000000000Hz for 100(100)ms spidev spi2.0: SPI transfer failed: -110 spi_master spi2: failed to transfer one message from queue ... pll5 1 1 864000000 0 0 pll5_other 0 0 864000000 0 0 pll5_ddr 1 1 432000000 0 0 ... xfer: Connection timed out buffer size: 1, result -110 buffer size: 1, result -110, Connection timed out Sending clock enable_cnt prepare_cnt rate accuracy phase ---------------------------------------------------------------------------------------- osc32k 0 0 32768 0 0 osc24M 6 6 24000000 0 0 ir0 0 0 24000000 0 0 spi1 0 0 24000000 0 0 spi0 0 0 24000000 0 0 ss 0 0 24000000 0 0 ... pll5 1 1 864000000 0 0 pll5_other 0 0 864000000 0 0 spi2 0 0 864000000 0 0 pll5_ddr 1 1 432000000 0 0 ... maximum buffer size: 0 Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... pll5 1 1 864000000 0 0 pll5_other 0 0 864000000 0 0 spi2 0 0 864000000 0 0 pll5_ddr 1 1 432000000 0 0 pll4 0 0 384000000 0 0 pll2-prediv 0 The system locks up here before finishing the output from debugfs and actually starting the transfer printed above. Thanks Michal --- The diff between the two full outputs shows only spi2 changed: 0 0 spi1 0 0 24000000 0 0 spi0 0 0 24000000 0 0 ss 0 0 24000000 0 0 @@ -69,6 +68,7 @@ pll6_sata 0 0 100000000 0 0 pll5 1 1 864000000 0 0 pll5_other 0 0 864000000 0 0 + spi2 0 0 864000000 0 0 pll5_ddr 1 1 432000000 0 0 pll4 0 0 384000000 0 0 pll2-prediv 0 0 1500000 0 0 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- clk1.txt 2016-05-22 18:38:24.890906037 +0200 +++ clk2.txt 2016-05-22 18:38:15.891003130 +0200 @@ -3,7 +3,6 @@ osc32k 0 0 32768 0 0 osc24M 6 6 24000000 0 0 ir0 0 0 24000000 0 0 - spi2 0 0 24000000