Jon Smirl wrote:
> I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
> real kernel aliasing/insmod system. Half of why we are having trouble
> is because asoc isn't using this mechanism. I've posted patches fixing
> i2c to use the same mechanism. I don't have the asoc ones ready
On 11/26/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> David Gibson wrote:
>
> > 1) We have a "universal" device-tree-based fabric driver which
> > parses all the above-described interconnection information in the
> > device tree and handles any situation. Cool, but probably a lot of
> > work
David Gibson wrote:
> 1) We have a "universal" device-tree-based fabric driver which
> parses all the above-described interconnection information in the
> device tree and handles any situation. Cool, but probably a lot of
> work and fiddly to get right.
Definitely a lot of work. I suggest
On Mon, Nov 19, 2007 at 04:58:44PM +, Matt Sealey wrote:
> Segher Boessenkool wrote:
> >> And I forgot the rant you guys usually get - for god's sake, why isn't
> >> anyone using the "model" property?
> >
> > Probably because it isn't useful all that often.
> >
> >> [EMAIL PROTECTED] {
> >>
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> David Gibson wrote:
> > On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> >
> > Gah! For the benefit of others on this list who may be misled.
> >
> > *Neither* of you correctly understands the device tree, what I've see
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > You might be stuck with using either a platform_device or an
> > > of_platform_device as a stepping stone to creating the
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
> > Matt, the various properties you list do not mean what you think they
> > mean.
> >
> > name - should be named according to the generic names convention.
> > It's pretty much arbitrary, meant for human readability of the device
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Now how do I pick which fabric driver to initialize?
>
> I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
> that works.
I believe that is your only choice on v1. V1 is not set up to
correctly ha
Jon Smirl wrote:
> Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > You might be stuck with using either a platform_device or an
> > of_platform_device as a stepping stone to creating the device on the
> > ALSA fabric driver.
>
> I also concluded that I need
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > > On 11/19/0
On 11/19/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> > I never said drivers should depend on it but why do you want to name
> > an i2s bus as "i2s" or the i2c bus as "i2c"?
>
> Because that's what they are?
>
> > There are far, far more
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote:
> I never said drivers should depend on it but why do you want to name
> an i2s bus as "i2s" or the i2c bus as "i2c"?
Because that's what they are?
> There are far, far more descriptive names that can be used. i2s is
> basically audio,
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > > Jon Smirl wr
Segher Boessenkool wrote:
>> And I forgot the rant you guys usually get - for god's sake, why isn't
>> anyone using the "model" property?
>
> Probably because it isn't useful all that often.
>
>> [EMAIL PROTECTED] {
>> \\ this is our magic audio fabric
>> device_type = "digispeaker,flinge
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm no
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm no
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > Jon Smirl wrote:
> > > >
> > > > > In the ALSA SOC model the i2s, codec
Grant Likely wrote:
> You probably mean "don't use the of_platform bus to load the fabric
> driver".
Yes, that is what I meant.
> He still needs to use the data in the device tree to decide
> what fabric drivers to use.
I'm not sure about that. The fabric driver is tied to the platform itsel
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > Jon Smirl wrote:
> > >
> > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > A fabric driver tells s
David Gibson wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
>
> The device tree des
On 11/19/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board.
On 11/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board. Wh
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >> The codec-fabric node was just being used to trigger the loading of
> >> the platform specific driver.
> >
> > Just remember one thing.
> >
> > 1) the term "fabric" when coined for audio drivers is a n
On 11/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right
So, like, the other day Timur Tabi mumbled:
>
> If I weren't on vacation this week, I'd email you my code. It's almost done
> and it demonstrates what I'm thinking.
Are the margins of this paper too small for your proof?
jdl
___
Linuxppc-dev mailing
Jon Smirl wrote:
> In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> A fabric driver tells specifically how a generic codec is wired into
> the board. What I haven't been able figure out is how to load the
> right fabric driver.
Do not use the device tree to load the fabric
Matt Sealey wrote:
> Jon Smirl wrote:
>> The codec-fabric node was just being used to trigger the loading of
>> the platform specific driver.
>
> Just remember one thing.
>
> 1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
> specific term. It isn't relevant for anything but
> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> dr
> And I forgot the rant you guys usually get - for god's sake, why isn't
> anyone using the "model" property?
Probably because it isn't useful all that often.
> [EMAIL PROTECTED] {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
This is wrong in so many way
On 11/18/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> > Matt Sealey wrote:
> > > Jon Smirl wrote:
> > >
> > > If you require the codec to be subservient to some "fabric" then I
> > > suggest you make a "sound" node with a compatible en
On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >
> > If you require the codec to be subservient to some "fabric" then I
> > suggest you make a "sound" node with a compatible entry which is
> > defined as something specific to your board (dig
On 11/18/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> I'd suggest something like this:
>
> [EMAIL PROTECTED] {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
>
> \\ it's actually just an i2s pcm codec
> compatible = "mpc5200-psc-i2s";
>
>
Matt Sealey wrote:
> Jon Smirl wrote:
>
> If you require the codec to be subservient to some "fabric" then I
> suggest you make a "sound" node with a compatible entry which is
> defined as something specific to your board (digispeaker,audio) and
> let your driver pick that up and then switch on the
Jon Smirl wrote:
>
> The codec-fabric node was just being used to trigger the loading of
> the platform specific driver.
Just remember one thing.
1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
specific term. It isn't relevant for anything but ALSA SoC drivers.
2) this dev
On 11/18/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > David Gibson
> > made a proposal that a fabric node wrap the codec node. That doesn't
> > work very well with the i2c bus where the bus code is walking down the
> > nodes and triggering the instantiation of the i2c drivers.
>
> Yeah, do
> [EMAIL PROTECTED] { // PSC2
> compatible = "mpc5200b-psc-ac97","mpc5200-psc-ac97";
> cell-index = <1>;
> reg = <2200 100>;
> interrupts = <2 2 0>;
> interrupt-pa
I've been trying to write ALSA SOC code supporting audio codecs and
device trees.
This looks ok for the main device tree entires. Codecs are hung off
from their controlling bus. It may still need a little tweaking.
[EMAIL PROTECTED] { // PSC2
co
39 matches
Mail list logo
