linux-kernel - RE: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MN2PR02MB6029D633F47B3B0DDF77D841C1E40@MN2PR02MB6029.namprd02.prod.outlook.com>
Date:   Thu, 20 Jun 2019 08:19:38 +0000
From:   Manish Narani <MNARANI@...inx.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     Michal Simek <michals@...inx.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Rajan Vaja <RAJANV@...inx.com>, Jolly Shah <JOLLYS@...inx.com>,
        Nava kishore Manne <navam@...inx.com>,
        Olof Johansson <olof@...om.net>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP Platform
 Tap Delays Setup

Hi Uffe,


> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@...aro.org>
> Sent: Wednesday, June 19, 2019 8:11 PM
> To: Manish Narani <MNARANI@...inx.com>
> Cc: Michal Simek <michals@...inx.com>; Rob Herring <robh+dt@...nel.org>;
> Mark Rutland <mark.rutland@....com>; Adrian Hunter
> <adrian.hunter@...el.com>; Rajan Vaja <RAJANV@...inx.com>; Jolly Shah
> <JOLLYS@...inx.com>; Nava kishore Manne <navam@...inx.com>; Olof
> Johansson <olof@...om.net>; linux-mmc@...r.kernel.org; DTML
> <devicetree@...r.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>; Linux ARM <linux-arm-kernel@...ts.infradead.org>
> Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP
> Platform Tap Delays Setup
> 
> On Tue, 18 Jun 2019 at 06:59, Manish Narani <MNARANI@...inx.com> wrote:
> >
> > Hi Uffe,
> >
> > Thanks for the review. Please find my comments below.
> >
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@...aro.org>
> > > Sent: Monday, June 17, 2019 8:29 PM
> > > To: Michal Simek <michals@...inx.com>
> > > Cc: Manish Narani <MNARANI@...inx.com>; Rob Herring
> > > <robh+dt@...nel.org>; Mark Rutland <mark.rutland@....com>; Adrian
> > > Hunter <adrian.hunter@...el.com>; Rajan Vaja <RAJANV@...inx.com>; Jolly
> > > Shah <JOLLYS@...inx.com>; Nava kishore Manne <navam@...inx.com>;
> Olof
> > > Johansson <olof@...om.net>; linux-mmc@...r.kernel.org; DTML
> > > <devicetree@...r.kernel.org>; Linux Kernel Mailing List <linux-
> > > kernel@...r.kernel.org>; Linux ARM <linux-arm-
> kernel@...ts.infradead.org>
> > > Subject: Re: [PATCH 3/3] mmc: sdhci-of-arasan: Add support for ZynqMP
> > > Platform Tap Delays Setup
> > >
> > > [...]
> > >
> > > > >>
> > > > >>
> > > > >>> In regards to the mmc data part, I suggest to drop the
> > > > >>> ->set_tap_delay() callback, but rather use a boolean flag to indicate
> > > > >>> whether clock phases needs to be changed for the variant. Potentially
> > > > >>> that could even be skipped and instead call clk_set_phase()
> > > > >>> unconditionally, as the clock core deals fine with clock providers
> > > > >>> that doesn't support the ->set_phase() callback.
> >
> > In the current implementation, I am taking care of both the input and
> > output clock delays with the single clock (which is output clock) registration
> > and differentiating these tap delays based on their values
> > (<256 then input delay and  >= 256 then output delay), because that is
> > zynqmp specific. If we want to make this generic, we may need to
> > register 'another' clock which will be there as an input (sampling) clock
> > and then we can make this 'clk_set_phase()' be called unconditionally
> > each for both the clocks and let the platforms handle their clock part.
> > What's your take on this?
> 
> Not sure exactly what you are suggesting, but my gut feeling says it
> sounds good.
> 
> How is tap delays managed for both the input clock and the output
> clock? Is some managed by the clock provider (which is probably
> firmware in your case) and some managed by the MMC controller?

Yes, for the existing "xlnx,zynqmp-8.9a" controller, the tap delays will be managed by the firmware, however in the upcoming "xlnx,versal-8.9a" variant the tap delays will be managed by the MMC controller itself.
I will include the Versal one in the next series of patches.

Thanks,
Manish