On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote:

Jon Smirl wrote:

quoted

Does this need to be bus-frequency? It's always called MCLK in all of
the literature.

I'm trying to make this node as generic as possible.  The fabric driver 
is the one that will parse this node and pass the data to the codec 
driver, so I can't use any codec-specific terms.

The API from the fabric driver for passing clock information includes a 
clock ID, a direction, and a frequency.  I can do something like this:

clock1 = <0, bb8000>

Would that be better?

To cover everything you'd need to be able to specify all the clocking
parameters, especially a PLL configuration, and also specify more than
one of each item.  Even then you'd still have problems like...

quoted

In my case the MCLK comes from a chip on the i2c bus that is
programmable How would that be encoded?.

I'm going under the assumption that MCLK does not change once the board 
is up and running.  In your case, you'd need to do something quite 
different, because you're not reading the clock info from the device 
tree and passing it to the codec at initialization once.  If you want to 
define an extension to the 'codec' child node that handles that, I'll 
add it to the documentation.

According to the documentation in your patch the bus frequency should
already be optional (though I don't immediately see that in the code,
but then I'm entirely unfamiliar with OpenFirmware device trees).
Boards that reconfigure the clocking at run time can then provide
code to set the clocking up at the appropriate times, which is probably
what they want anyway.