[PATCH] mtd/ifc: Add support for IFC controller version 2.0

Scott Wood oss at buserror.net
Tue Feb 16 19:36:37 AEDT 2016


On Tue, 2016-02-16 at 07:19 +0000, Raghav Dogra wrote:
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss at buserror.net]
> > Sent: Tuesday, February 16, 2016 6:12 AM
> > To: Raghav Dogra <raghav.dogra at nxp.com>; Brian Norris
> > <computersforpeace at gmail.com>; Li Yang <leoli at freescale.com>
> > Cc: Raghav Dogra <raghav at freescale.com>; linux-mtd at lists.infradead.org;
> > linuxppc-dev <linuxppc-dev at lists.ozlabs.org>; Prabhakar Kushwaha
> > <prabhakar.kushwaha at nxp.com>; Jaiprakash Singh
> > <b44839 at freescale.com>
> > Subject: Re: [PATCH] mtd/ifc: Add support for IFC controller version 2.0
> > 
> > On Mon, 2016-02-15 at 06:18 +0000, Raghav Dogra wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Brian Norris [mailto:computersforpeace at gmail.com]
> > > > Sent: Saturday, February 13, 2016 1:14 AM
> > > > To: Li Yang <leoli at freescale.com>
> > > > Cc: Raghav Dogra <raghav at freescale.com>;
> > > > linux-mtd at lists.infradead.org; linuxppc-dev
> > > > <linuxppc-dev at lists.ozlabs.org>; oss at buserror.net; Prabhakar
> > > > Kushwaha <prabhakar.kushwaha at nxp.com>; Jaiprakash Singh
> > > > <b44839 at freescale.com>
> > > > Subject: Re: [PATCH] mtd/ifc: Add support for IFC controller version
> > > > 2.0
> > > > 
> > > > On Thu, Feb 04, 2016 at 05:07:16PM -0600, Li Yang wrote:
> > > > > On Wed, Feb 3, 2016 at 12:36 AM, Raghav Dogra
> > > > > <raghav at freescale.com>
> > > > wrote:
> > > > > > The new IFC controller version 2.0 has a different memory map
> > > > > > page.
> > > > > > Upto IFC 1.4 PAGE size is 4 KB and from IFC2.0 PAGE size is 64KB.
> > > > > > This patch segregates the IFC global and runtime registers to
> > > > > > appropriate PAGE sizes.
> > > > > 
> > > > > If the global registers and the runtime registers are so
> > > > > independent that they have to be on different page boundaries, it
> > > > > would make more sense for them to be defined as separate reg
> > > > > regions in the device tree at the very beginning.  Then we would
> > > > > only need to change the device tree now and it would be future proof
> > for any page size.
> > > > 
> > > > To be clear: Scott, you were NACK'ing the DT binding change request,
> > > > right? I though we had an Ack on the previous revision (that Raghav
> > > > failed to carry).
> > > > 
> > > > > > 
> > > > > > Signed-off-by: Jaiprakash Singh <b44839 at freescale.com>
> > > > > > Signed-off-by: Raghav Dogra <raghav at freescale.com>
> > > > > 
> > > > > The patch cannot apply on latest 4.5-rc cleanly either.
> > > > > Otherwise,
> > > > 
> > > > Yeah... neither this patch nor its (allegedly) dependent patch [1]
> > > > apply cleanly.
> > > > 
> > > > If you expect me to take this patch via MTD, please rebase to
> > > > l2-mtd.git as stated here:
> > > > 
> > > > http://linux-mtd.infradead.org/source.html
> > > > 
> > > I expect Scott to pick this patch, and apply via linuxppc-dev. I will
> > > send the patch on based on
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > Branch "master"
> > 
> > Why are you expecting that, for a patch that touches an MTD driver and
> > doesn't touch arch/powerpc, and for which I've already given an ack for it
> > to
> > go via the MTD tree?
> 
> I was expecting that because this patch is dependent on the
> "drivers/memory: Add deep sleep support for IFC" patch 
> https://patchwork.ozlabs.org/patch/582762/ for which an ACK is still
> pending.
> So, till you ACK that patch, Brian won't be able to pick that patch, I
> guess.
> So, I thought you can pick both the patches when an ACK is given to the deep
> sleep patch.

I recommend respinning this patch without that dependency, as this patch is
ready now (except for the rebase) and that patch is not, and then base the
deep sleep patch on top of this one.  I also expect that the final version of
that patch will touch the NAND driver as well (see my reply to it).

-Scott



More information about the Linuxppc-dev mailing list