From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757330AbbEET16 (ORCPT ); Tue, 5 May 2015 15:27:58 -0400 Received: from mail-bl2on0071.outbound.protection.outlook.com ([65.55.169.71]:16070 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751114AbbEET1z (ORCPT ); Tue, 5 May 2015 15:27:55 -0400 Authentication-Results: spf=fail (sender IP is 66.35.236.227) smtp.mailfrom=opensource.altera.com; lixom.net; dkim=none (message not signed) header.d=none; Authentication-Results: lixom.net; dkim=none (message not signed) header.d=none; Message-ID: <5549187E.7050802@opensource.altera.com> Date: Tue, 5 May 2015 14:22:38 -0500 From: Dinh Nguyen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Krzysztof Kozlowski CC: , Dinh Nguyen , , , , olof Johansson Subject: Re: [PATCH] dmaengine: pl300: enable the clock to PL330 dma References: <1430713734-12175-1-git-send-email-dinguyen@opensource.altera.com> <55477413.2020908@opensource.altera.com> <55477CEC.1050600@opensource.altera.com> <5547CDEF.5050003@opensource.altera.com> <5548DA1B.2080604@opensource.altera.com> In-Reply-To: <5548DA1B.2080604@opensource.altera.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.129.157.38] X-ClientProxiedBy: BN1PR08CA0024.namprd08.prod.outlook.com (10.242.217.152) To CY1PR03MB1374.namprd03.prod.outlook.com (25.163.16.28) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1374;UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:;UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:CY1PR03MB1374;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1374;BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BY1PR0301MB0837;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; X-Forefront-PRVS: 0567A15835 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(24454002)(479174004)(377454003)(377424004)(51704005)(62966003)(86362001)(50466002)(92566002)(40100003)(122386002)(575784001)(2950100001)(77156002)(42186005)(15975445007)(47776003)(23676002)(93886004)(110136002)(5001920100001)(5001960100002)(65806001)(66066001)(83506001)(87976001)(4001350100001)(19580395003)(99136001)(50986999)(76176999)(33656002)(54356999)(46102003)(19580405001)(80316001)(4580500001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR03MB1374;H:[137.57.160.210];FPR:;SPF:None;MLV:sfv;LANG:en; X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1374 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BY2FFO11FD022.protection.gbl X-Forefront-Antispam-Report: CIP:66.35.236.227;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(339900001)(377454003)(377424004)(51704005)(199003)(24454002)(189002)(479174004)(77156002)(2950100001)(62966003)(23676002)(93886004)(50466002)(86362001)(76176999)(87266999)(64126003)(40100003)(4001350100001)(105606002)(19580405001)(54356999)(50986999)(65816999)(90366008)(65806001)(47776003)(15975445007)(106466001)(59896002)(16796002)(92566002)(65956001)(66066001)(85426001)(19580395003)(46102003)(33656002)(83506001)(575784001)(99136001)(87936001)(110136002)(80316001)(6806004)(5001960100002)(122386002)(7099028)(4580500001);DIR:OUT;SFP:1101;SCL:1;SRVR:BY1PR0301MB0837;H:sj-itexedge03.altera.priv.altera.com;FPR:;SPF:Fail;MLV:ovrnspm;A:0;MX:1;PTR:InfoDomainNonexistent;LANG:en; X-Forefront-PRVS: 0567A15835 X-OriginatorOrg: opensource.altera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2015 19:27:51.3595 (UTC) X-MS-Exchange-CrossTenant-Id: fbd72e03-d4a5-4110-adce-614d51f2077a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fbd72e03-d4a5-4110-adce-614d51f2077a;Ip=[66.35.236.227];Helo=[sj-itexedge03.altera.priv.altera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0837 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/2015 09:56 AM, Dinh Nguyen wrote: > On 05/04/2015 10:55 PM, Krzysztof Kozlowski wrote: >> 2015-05-05 4:52 GMT+09:00 Dinh Nguyen : >>> On 05/04/2015 09:06 AM, Dinh Nguyen wrote: >>>> +CC Olof >>>> >>>> On 5/4/15 8:50 AM, Krzysztof Kozlowski wrote: >>>>> 2015-05-04 22:28 GMT+09:00 Dinh Nguyen : >>>>>> Hi Krzystof, >>>>>> >>>>>> On 5/4/15 12:30 AM, Krzysztof Kozlowski wrote: >>>>>>> 2015-05-04 13:28 GMT+09:00 : >>>>>>>> From: Dinh Nguyen >>>>>>>> >>>>>>>> Turn on the clock to the PL330 DMA if there is a clock node provided. >>>>>>> >>>>>>> Why? There is no explanation in the patch for this important question - why? >>>>>>> >>>>>>> Amba bus already does this and provide a wrapper function. >>>>>>> Additionally that would mess up with runtime PM and clock >>>>>>> enable/disable. >>>>>> >>>>>> I don't see the clock for the DMA getting turned on at all, which is why >>>>>> after the kernel has booted, the filesystem tries to open up a serial >>>>>> port using DMA and the system hangs. The failure is seen here: >>>>>> >>>>>> http://arm-soc.lixom.net/bootlogs/next/next-20150504/socfpga-arm-multi_v7_defconfig.html >>>>> >>>>> Thanks! >>>>> >>>>> The amba bus and pl330 should enable the clock and then disable it >>>>> after probing: >>>>> static int amba_probe(struct device *dev) >>>>> { >>>>> ... >>>>> ret = amba_get_enable_pclk(pcdev); >>>>> ... >>>>> >>>>> I wonder why do you think it is not enabled at all? >>>> >>>> I've checked it down to the register level that the gate for this clock >>>> does not get set. >>>> >>>>> >>>>>> >>>>>> This only happens with the multi_v7_defconfig, because the PL330 DMA is >>>>>> getting built into the kernel, while the socfpga_defconfig does not >>>>>> enable the PL330. >>>>> >>>>> It makes sense. If pl330 driver is not enabled then necessary clocks >>>>> are turned on by bootloader. Probing pl330 effectively disables the >>>>> clock (if DMA is not used). >>>>> >>>>>> The DTS for the socfpga platform looks like this: >>>>>> >>>>>> pdma: pdma@ffe01000 { >>>>>> compatible = "arm,pl330", "arm,primecell"; >>>>>> reg = <0xffe01000 0x1000>; >>>>>> interrupts = <0 104 4>, >>>>>> <0 105 4>, >>>>>> ... >>>>>> #dma-cells = <1>; >>>>>> #dma-channels = <8>; >>>>>> #dma-requests = <32>; >>>>>> clocks = <&l4_main_clk>; >>>>>> clock-names = "apb_pclk"; >>>>>> }; >>>>>> >>>>>> Perhaps I have the wrong designation for clock-names and the amba bus is >>>>>> not able to pick up the correct clock? >>>>> >>>>> I have two ideas: >>>>> 1. Is this really the clock for the DMA? If DMA is not used then >>>>> disabling it should be OK. >>>> >>>> Yes, this is the clock for the DMA. Yeah, leaving this clock off is >>>> fine, until the DMA gets used. Up until v4.0, SoCFPGA was not using the >>>> DMA at all, but in v4.0, there was a patch to assign the UARTs to it's >>>> DMA channel. >>>> >>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/socfpga.dtsi?id=78c03c7af89721bd8a4428408a8cc7b53972e4b8 >>>> >>>>> 2. Disabling the clock may effectively disable its parent or >>>>> grandparent if there are not more users. Maybe some other driver needs >>>>> these parents to be enabled? This was the issue for at least one >>>>> similar error (on Exynos boards). >>>>> >>>> >>>> I'll check up on these issues. When I was debugging this issue, the >>>> l4_main_clk is only used by the DMA, so it was not getting turned on by >>>> an other drivers. >>>> >>> >>> Ah, it looks like perhaps there's a problem with the serial driver and >>> suspend/resume? If disable CONFIG_PM, then the DMA seems to be working >>> fine with the debug uart. It appears the DMA is getting suspended and >>> doesn't get resumed. >>> >> >> You mean runtime PM suspend and resume or system sleep? During boot >> only the first one should happen. > > It's runtime PM suspend/resume. > >> >> Could you test the DMA with dmatest? Disable the DMA in UART and >> compile with CONFIG_DMATEST. Syntax for testing is here: >> Documentation/dmaengine/dmatest.txt >> > > # echo Y > /sys/module/dmatest/parameters/run > [ 93.143775] dmatest: Started 1 threads using dma0chan0 > [ 93.149227] pm_generic_runtime_resume > [ 93.153334] dmatest: Started 1 threads using dma0chan1 > [ 93.159380] dmatest: Started 1 threads using dma0chan2 > [ 93.165041] dmatest: Started 1 threads using dma0chan3 > [ 93.170280] dmatest: Started 1 threads using dma0chan4 > [ 93.175996] dmatest: Started 1 threads using dma0chan5 > [ 93.181642] dmatest: Started 1 threads using dma0chan6 > [ 93.188754] dmatest: dma0chan1-copy0: summary 10 tests, 0 failures > 282 iops 2008 KB/s (0) > [ 93.197091] dmatest: Started 1 threads using dma0chan7 > [ 93.199353] dmatest: dma0chan3-copy0: summary 10 tests, 0 failures > 297 iops 2260 KB/s (0) > [ 93.205407] dmatest: dma0chan0-copy0: summary 10 tests, 0 failures > 177 iops 1364 KB/s (0) > [ 93.215599] dmatest: dma0chan2-copy0: summary 10 tests, 0 failures > 196 iops 1450 KB/s (0) > [ 93.219994] dmatest: dma0chan4-copy0: summary 10 tests, 0 failures > 225 iops 1554 KB/s (0) > [ 93.224322] dmatest: dma0chan5-copy0: summary 10 tests, 0 failures > 231 iops 1948 KB/s (0) > [ 93.230065] dmatest: dma0chan6-copy0: summary 10 tests, 0 failures > 231 iops 1759 KB/s (0) > [ 93.231251] dmatest: dma0chan7-copy0: summary 10 tests, 0 failures > 298 iops 2331 KB/s (0) > [ 93.243523] pm_generic_runtime_suspend > root@socfpga_cyclone5:~# > If I run dmatest the 2nd time it fails. It does not look like amba_pm_runtime_resume() is getting called to turn on the clocks on the subsequent tries. Dinh