From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752177AbbEDT5c (ORCPT ); Mon, 4 May 2015 15:57:32 -0400 Received: from mail-bn1on0085.outbound.protection.outlook.com ([157.56.110.85]:31354 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751252AbbEDT5a (ORCPT ); Mon, 4 May 2015 15:57:30 -0400 Authentication-Results: spf=fail (sender IP is 66.35.236.236) 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: <5547CDEF.5050003@opensource.altera.com> Date: Mon, 4 May 2015 14:52:15 -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> In-Reply-To: <55477CEC.1050600@opensource.altera.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.129.157.38] X-ClientProxiedBy: BY1PR0501CA0020.namprd05.prod.outlook.com (25.162.139.30) To BN3PR03MB1367.namprd03.prod.outlook.com (25.163.34.153) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1367;UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB145; 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:BN3PR03MB1367;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1367;BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BL2PR03MB145;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB145; X-Forefront-PRVS: 05669A7924 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(377454003)(377424004)(51704005)(24454002)(479174004)(5001960100002)(4001350100001)(93886004)(2950100001)(19580395003)(76176999)(64126003)(122386002)(40100003)(46102003)(87266999)(50466002)(54356999)(50986999)(110136002)(65816999)(23676002)(47776003)(15975445007)(66066001)(5001920100001)(33656002)(80316001)(59896002)(77156002)(83506001)(92566002)(62966003)(87976001)(86362001)(19580405001)(42186005);DIR:OUT;SFP:1101;SCL:1;SRVR:BN3PR03MB1367;H:[137.57.160.210];FPR:;SPF:None;MLV:sfv;LANG:en; X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1367 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1AFFO11FD038.protection.gbl X-Forefront-Antispam-Report: CIP:66.35.236.236;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(339900001)(377454003)(377424004)(51704005)(199003)(479174004)(189002)(24454002)(64126003)(59896002)(106466001)(16796002)(90366008)(46102003)(33656002)(105606002)(2950100001)(92566002)(122386002)(23676002)(40100003)(50986999)(86362001)(65816999)(76176999)(50466002)(6806004)(19580405001)(15975445007)(66066001)(65956001)(80316001)(83506001)(19580395003)(47776003)(77156002)(62966003)(110136002)(87266999)(87936001)(93886004)(4001350100001)(65806001)(54356999)(5001960100002)(85426001)(5001920100001)(7099028);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2PR03MB145;H:sj-itexedge04.altera.priv.altera.com;FPR:;SPF:Fail;MLV:ovrnspm;A:0;MX:1;PTR:InfoDomainNonexistent;LANG:en; X-Forefront-PRVS: 05669A7924 X-OriginatorOrg: opensource.altera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2015 19:57:28.0484 (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.236];Helo=[sj-itexedge04.altera.priv.altera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB145 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Dinh