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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux