Re: [PATCH] asoc/multi-component: fsl: add support for variable SSI FIFO depth

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.