On 28/02/13 10:27, Laxman Dewangan wrote: > 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. > Since I originally wrote the driver it is now possible to get your parents regmap without knowledge of the parent.
All that is then needed is a method to pass an offset (possibly re-use IO_RESOURCE). The final but of information that would be needed is some method to pass down product_id/design_rev and for a lot of the IP blocks they could be made independent of the actual parent. This is theoretical at the moment because I would not do this work unless it became neccessary. But this was in my head when I was originally designing the driver. The RTC is a good point, the same RTC IP block is used in most tps6591X and tps800XX devices. My dream would be to make them all one driver! Graeme -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
