Received: by 10.223.176.5 with SMTP id f5csp997977wra; Tue, 6 Feb 2018 10:46:38 -0800 (PST) X-Google-Smtp-Source: AH8x225jYkHkZj9csHjsmU+UTNadgnkvl7cIIdCdjt6ALGZJVNzuIBXvJc/doJwian9ZkRuvYe7m X-Received: by 2002:a17:902:b595:: with SMTP id a21-v6mr3262451pls.253.1517942798078; Tue, 06 Feb 2018 10:46:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517942798; cv=none; d=google.com; s=arc-20160816; b=qFtBQK5Jg8sNvXjv2XEc28sJ6+sMrQfBzUK7+6J896e5bgMUOQe0A59nozHaLrNYm7 zNgW5uL6yc7UUtYhtWTltaFjTFBFJIKUdc+ndCOhbaQY7LCZ8JM4sLszMpXiuChRgzUP XK4CH3VoXTB4pGW10tt9DSX31Ed6gYBe4JItVLKcywm6yr028YWIfx3b08j5bHcshtDz 7Q1q11cO78K92OhNfOz5kjt3pDgu7NHWFdEq35nciSrefgl4GQRBQBjPMl+zhdN6vGW8 W2uMoVhj9aeZZbNR1Vy+gxr0pMES2PZQvBPvUcKcjF15NqmWFIF+iFFDFgVr58IjWh9A ibbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=TtizOkK1knWmTVBzj4fL6webZ+dzhEGQCgnOfuRgs2Y=; b=lESNscKkE7pfSh6J3rduwZp3EQcCKcnH54LEhRNOr9O6Gr6siNXSacCqdtLYdMm8lB sqxJ4g1IEhexLB+1Tz5XwF+bCHZyn/vYKrHu7yQN9mJDsMhvcqD91sy7uyIdB5wtHSGR t8gw2Kk7bmr/C/FjHt5hw0GSnCCf8oNd3G43VxxqwltyId5Qj6hB4DAWZMZaOo5p9pzx l3WV5gVnIaPuU+/kGoJedQl4pKAwiVtvm4EQenQWSd68A1HjVjHUfegqHdUqKLRqTK4x BfckUn+LBUBWAxnKxfzcSfrd2/E3SmD8pkFT2Nj6ECcURZaXFNlLqw93OnhuE1zsrJY/ K33Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=bUnQUHpk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11-v6si8796461pls.112.2018.02.06.10.46.24; Tue, 06 Feb 2018 10:46:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=bUnQUHpk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753200AbeBFSpt (ORCPT + 99 others); Tue, 6 Feb 2018 13:45:49 -0500 Received: from mail-ot0-f193.google.com ([74.125.82.193]:45361 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752852AbeBFSpo (ORCPT ); Tue, 6 Feb 2018 13:45:44 -0500 Received: by mail-ot0-f193.google.com with SMTP id 73so2691067oti.12 for ; Tue, 06 Feb 2018 10:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TtizOkK1knWmTVBzj4fL6webZ+dzhEGQCgnOfuRgs2Y=; b=bUnQUHpkQtpMFpRdDIrAbJnjHKTaCWF/qe8o3lSNywvQ0+AWx8lhScGd27hTwAr2YO s24Horo+FaQ9XHWzNRz6KQLJXX4DrJ7Ymv37zgmm0WFN0dTn23KHvn/voM4ElU82EUFP 8ETc9i7Rx/vvB3XWdr8oSJrKpdoUHkvgPlv9d88VCdig2TxJ/vynIDmj9qUfU696WX14 nTjhjIPCfasVvsTgKBNCr/+GsKff7tFXUrGfiFCc8p3eJBnSsMFefQ9afqNOIc5Jdann Jp2RMiVR+QCFCOGT8AuhVO/ZJmW+qRr+K9CXvEBUyTqRmf9dm90XPjNSixeUoVq+Qt1M qGUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TtizOkK1knWmTVBzj4fL6webZ+dzhEGQCgnOfuRgs2Y=; b=mvVk1ajJeSWT0+zajBWzJKIAVz6COaM18WYsMz3hR8f/IlR0TqXaz6jFrGWJw0Xvf/ o9fwLWQTA9543wYlsMRYNSE34A1VjGpbNkMYutllfXoGLVjm/laFofKEJcyQ1ksSSGA6 0EIYreblfBDD1q3yzZubPMNuKWd23LkY5mZHvRawVauKPm8+wSw+675DOiEmorFi7bIl nd300NRs2WjnC0Rb5cys72Eoxq+J8usZDme/r+jW4cUM2wlI/xkX8yRSvcR4Bp5jenAB f5sVCNbqrgyp+9ngsrNILmHyE7SWYwEsOzJO1Wftw0so67aPABFoTtriMz/sq5TUgLbg r4sg== X-Gm-Message-State: APf1xPCm6XrHb8f/fPrVu6XdkjJR7Awvm/gHrdWOA6yhM0VIoEPuQLoA HA6QyklIjDhE2KsesLlseu0AC0/96I9PJo53DZDNLg== X-Received: by 10.157.30.132 with SMTP id n4mr2403830otn.280.1517942743327; Tue, 06 Feb 2018 10:45:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.42.71 with HTTP; Tue, 6 Feb 2018 10:45:42 -0800 (PST) In-Reply-To: <4aa2ab13-7890-6904-86b3-e2dbcb6d6daa@lechnology.com> References: <20180205155222.22189-1-brgl@bgdev.pl> <3f171f6a-bcea-65ec-d56d-f6ae24660f34@ti.com> <54dbdb98-e0e4-c8c9-fec4-2f050745d9be@ti.com> <794024f3-f87a-58ed-2722-a4a2d09df3ce@lechnology.com> <4aa2ab13-7890-6904-86b3-e2dbcb6d6daa@lechnology.com> From: Bartosz Golaszewski Date: Tue, 6 Feb 2018 19:45:42 +0100 Message-ID: Subject: Re: [PATCH] ARM: dts: da850-evm: add clock properties to the nand node To: David Lechner Cc: Sekhar Nori , Bartosz Golaszewski , Kevin Hilman , Rob Herring , Mark Rutland , Russell King , arm-soc , linux-devicetree , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-02-06 19:25 GMT+01:00 David Lechner : > On 02/06/2018 12:16 PM, David Lechner wrote: >> >> On 02/06/2018 07:51 AM, Sekhar Nori wrote: >>> >>> On Tuesday 06 February 2018 06:38 PM, Bartosz Golaszewski wrote: >>>> >>>> 2018-02-06 12:07 GMT+01:00 Sekhar Nori : >>>>> >>>>> On Monday 05 February 2018 09:22 PM, Bartosz Golaszewski wrote: >>>>>> >>>>>> From: Bartosz Golaszewski >>>>>> >>>>>> Make nand work with the common clock framework by specifying which >>>>>> clock should be used and what name to look up. >>>>>> >>>>>> Signed-off-by: Bartosz Golaszewski >>>>>> --- >>>>>> arch/arm/boot/dts/da850-evm.dts | 3 +++ >>>>>> 1 file changed, 3 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts >>>>>> b/arch/arm/boot/dts/da850-evm.dts >>>>>> index a86a8a1816f2..2602ad8e99ee 100644 >>>>>> --- a/arch/arm/boot/dts/da850-evm.dts >>>>>> +++ b/arch/arm/boot/dts/da850-evm.dts >>>>>> @@ -296,6 +296,9 @@ >>>>>> reg = <0 0x02000000 0x02000000 >>>>>> 1 0x00000000 0x00008000>; >>>>>> >>>>>> + clocks = <&psc0 3>; >>>>>> + clock-names = "aemif"; >>>>> >>>>> >>>>> Looks like this is being added only to satisfy the devm_clk_get() call >>>>> in nand_davinci_probe() which I think is superfluous since we also >>>>> enable the same clock in aemif_probe(). >>>>> >>>>> Perhaps the better solution is to drip the clk code in >>>>> drivers/mtd/nand/davinci_nand.c and shift legacy code to start using >>>>> drivers/memory/aemif.c as well? This way we can also drop >>>>> arch/arm/mach-davinci/aemif.c >>>>> >>>>> Thanks, >>>>> Sekhar >>>> >>>> >>>> Yes, this sounds good, but I think we should leave it for later as an >>>> additional improvement, once everything else is in place. I think >>>> these patches should be applied together with David's series in order >>>> to not break the support on davinci boards and the aemif work would go >>>> in later as a follow-up. How about that? >>> >>> >>> No, I dont think we should add temporary hacks to DT to work around >>> driver issues (I do think its a hack since the clock belongs to aemif >>> module not NAND flash). >>> >>> An easier driver hack might be to not treat devm_clk_get() failure in >>> davinci_nand.c as catastrophic. It will safely fail in DT case and we >>> should get the clock in legacy boot case. >>> >>> I think we are looking at a driver update dependency anyway. >> >> >> It looks like keystone.dtsi is using the clock-ranges property in the >> aemif node to pass the clock to child nodes. Could we not do the same >> in da850.dtsi? > > > Bartosz, please try this instead of your patch. > > FYI, this is just following the existing memory-controllers/ti-aemif.txt > device tree bindings, so not a "hack". > > --- > diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi > index 3a1f2ce..ff9d807 100644 > --- a/arch/arm/boot/dts/da850.dtsi > +++ b/arch/arm/boot/dts/da850.dtsi > @@ -796,6 +796,8 @@ > ranges = <0 0 0x60000000 0x08000000 > 1 0 0x68000000 0x00008000>; > clocks = <&psc0 3>; > + clock-names = "aemif"; > + clock-ranges; > status = "disabled"; > }; > memctrl: memory-controller@b0000000 { > --- Yes, this works. Sekhar: can we include it in David's series, while still keeping the plan to move legacy boards to using the aemif driver? Best regards, Bartosz