On Thu, Aug 05, 2010 at 09:21:15AM -0700, Tabi Timur-B04825 wrote:
the FIFO depth, the drivers need to know that information. The only way to pass that info to the drivers is via the device tree.
Clearly this is not entirely true, people manage to write non-DT kernels after all. In a strongly device tree oriented model it does need to be via the device tree, but even there there's options for how the data gets there - for example, we can supply it by looking at the CPU type and fixing up the DTS prior to the driver seeing it, or any one of a number of other methods. I'd probably not have queried this so much if I'd noticed some sort of handling for such a method.
It's not so much this particular property I'm worried about as the general style for things like this so CCing in Grant.
Mark Brown wrote:
I'd have strongly expected that the device tree was able to incoporate all the properties that are standard to the CPU by reference somehow (with that data being distributed separately to the per system device tree).
Separately? Why? Look at the device trees we have today. They are full of nodes with all sorts of device-specific properties that describe minor differences among the devices across various SOCs.
Separately because people make and distribute systems with a parts on them well before software is finalised in mainline. Requiring that both the DTS and the kernel match up and get updated for new feature support means that you've got two different things (potentially maintained by different groups in the end user environment) to distribute and get updated on systems separately. Failure to update one may result in problems on another, either with features not getting enabled or with newer kernel versions not wanting to run on systems with older device trees.
It also seems like busy work for users to have to add things like this to their device trees. I think what I'd expect to see in a strongly device tree model is something like the tree for a board saying it's using a given SoC and then a standard device tree for the SoC which is shared between all the different users of that SoC getting merged in early in boot (probably from the kernel). That way if we gain support for a new feature on the SoC or discover something that needs to be flagged up for workaround then every board using the SoC will pick it up. This seems particularly useful for things like crypto engines that are physically internal to the SoC and so don't normally require per-board hookup. In ASoC terms you do need board specific hookup so that's a bit less of an issue but it looses us some of the benefit of having standard chip drivers by pushing some of the chip generic knowledge into a per-machine location.
The fact that the PowerPC systems are currently doing this isn't something I'd rely on with other architectures, the vendor and customer bases may be very different.