[PATCH v2 1/2] fsl: Add binding for RCPM

Scott Wood scottwood at freescale.com
Wed Sep 16 12:37:56 AEST 2015


On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 10:32 AM
> > To: Wang Dongsheng-B40534 <Dongsheng.Wang at freescale.com>
> > Cc: devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> > robh+dt at kernel.org; linux-arm-kernel at lists.infradead.org; Wang Huan-
> > B18965 <alison.wang at freescale.com>; Jin Zhengxiong-R64188
> > <Jason.Jin at freescale.com>; Zhao Chenhui-B35336
> > <chenhui.zhao at freescale.com>; Tang Yuantian-B29983
> > <Yuantian.Tang at freescale.com>
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > 
> > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > Hi Scott,
> > > 
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> > > > robh+dt at kernel.org; linux-arm-kernel at lists.infradead.org; Wang Huan-
> > > > B18965; Jin
> > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > 
> > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > Hi Scott,
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> > > > > > robh+dt at kernel.org; linux-arm-kernel at lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965; Jin
> > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > 
> > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > +-------------------------------------------
> > > > > > > +Required rcpm-wakeup property should be added to a device
> > > > > > > +node if the
> > > > > > > device
> > > > > > > +can be used as a wakeup source.
> > > > > > > +
> > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > > > + The
> > > > > > > first
> > > > > > > cell
> > > > > > > +     is a pointer to the rcpm node, the second cell is the
> > > > > > > + bit mask
> > > > > > > that
> > > > > > > +     should be set in IPPDEXPCR0, and the last cell is for
> > > > > > > IPPDEXPCR1.
> > > > > > > +     Note: If the platform has no IPPDEXPCR1 register, put a
> > > > > > > + zero
> > > > > > > here.
> > > > > > 
> > > > > > What if a future platform has more than two of these registers?
> > > > > 
> > > > > Those registers are only used for wakeup device, we have a lot of
> > > > > available bit for feature. For example, In LS1021a platform only
> > > > > 7bits has used in the registers, and 57bits is reserved.
> > > > 
> > > > Still, it'd be better to for the rcpm node to advertise the number
> > > > of cells it expects.
> > > 
> > > For the foreseeable future it should be enough to use, even if not
> > > enough to use in the future at that time we can update the binding.
> > 
> > That's the whole point.  Device tree is stable ABI.  Updating it later to 
> > not be
> > fixed to two cells would be a lot harder than getting it right from the
> > beginning.  Putting the number of cells in the phandle target is a 
> > standard
> > device tree idiom.
> > 
> I agree with you. But what's the point a SOC has more than 64 wakeup source?

I don't know.  Hardware people do strange things sometimes.  They might not 
want to reuse bits they once used for something on some other chip, or they 
might have some encoding scheme in mind that results in the bits not being 
packed as tightly as possible, or there may be some big array of similar 
devices...

What's the point of skipping this part of the phandle-plus-arguments idiom?

-Scott



More information about the Linuxppc-dev mailing list