Re: [PATCH 1/4] documentation: add palmas dts definition

[Laxman Dewangan]

On Thursday 28 February 2013 03:28 PM, Graeme Gregory wrote:
> On 28/02/13 08:52, Laxman Dewangan wrote:
> > On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
> > > On 02/17/2013 10:11 PM, J Keerthy wrote:
> > > +- interrupt-parent : The parent interrupt controller.
> > > +
> > > +Optional node:
> > > +- Child nodes contain in the palmas. The palmas family is made of
> > > several
> > > +  variants that support a different number of features.
> > > +  The child nodes will thus depend of the capability of the variant.
> > > Are there DT bindings for those child nodes anywhere?
> > >
> > > Representing each internal component as a separate DT node feels a
> > > little like designing the DT bindings to model the Linux-internal MFD
> > > structure. DT bindings should be driven by the HW design and
> > > OS-agnostic.
> > >
> > >   From a DT perspective, is there any need at all to create a separate DT
> > > node for each component? This would only be needed or useful if the
> > > child IP blocks (and hence DT bindings for those blocks) could be
> > > re-used in other top-level devices that aren't represented by this
> > > top-level ti,palmas DT binding. Are the HW IP blocks here re-used
> > > anywhere, or will they be?
> >
> > I dont think that child IP block can be used outside of the palma
> > although other mfd device may have same IP.
> >
> > The child driver very much used the palma's API for register access
> > and they can not be separated untill driver is write completely
> > independent of palmas API. Currently, child driver include the palma
> > header, uses palma mfd stcruture and plama's api for accessing registers.
> I wonder why break good software principles of keeping data and code
> localised? Just because there is no current case where a block is
> re-used does not mean it shall not be so in the future. The original
> information I got from TI when designing this was blocks may be re-used
> in future products.
>
> This structure also makes it much neater when dealing with palmas
> varients with different IP blocks which already exist.
>
> I also do not see an issue with working like the internal MFD structure,
> I think it is a good design.


I did not get how the register access will be happen from IP driver.
suppose we have RTC driver which is common IP for device 1 and device2. 
Device1 and device2 are registered as separate MFD driver which has 
different set of chip structure and initialisation.

When I write the RTC register then how do  I call register access? 
Currently RTC driver is saying device1_reg_read() or device2_reg_read() 
etc on which register address passed along with dev or chip structure.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/