Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 06:16:33PM +0100, Mark Brown wrote: > On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: > > > I'm okay with that. How about fsl/mpc5200-of-machine.c for now? > > (only the mpc5200 i2s driver uses it at the moment). It can always be > > renamed if other folks want to use it for other chips. > > That seems reasonable so long as you're happy with it, though it does > seem to be going to the other extreme in terms of broadness :) Okay, I've changed my mind. :-) I'll back off a bit from this extreme and call it: sound/soc/fsl/soc-of-simple.c Does that sound okay? If non-freescale chips decide to use it then it can be moved out of the freescale director. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Fri, Jul 18, 2008 at 01:17:20AM -0600, Grant Likely wrote: > Okay, I've changed my mind. :-) I'll back off a bit from this extreme and > call it: > sound/soc/fsl/soc-of-simple.c > Does that sound okay? If non-freescale chips decide to use it then it > can be moved out of the freescale director. Fine by me - you could add an of directory but I don't mind either way so long as the people actually using the code are happy. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Grant Likely wrote: Okay, I've changed my mind. :-) I'll back off a bit from this extreme and call it: sound/soc/fsl/soc-of-simple.c That works for me. And please don't forget to CC: me on any discussion involving sound/soc/fsl. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
> Simple utility layer for creating ASoC machine instances based on data
> in the OpenFirmware device tree. OF aware platform drivers and codec
> drivers register themselves with this framework and the framework
> automatically instantiates a machine driver.
Ideally someone from the PowerPC community would sign off on this -
given the nature and volume of discussion people obviously have very
strong opinions about how machine drivers should be done so I'd really
like to see some community buy in for something like this. From an ASoC
point of view if this works it's fine.
> This is most likely temporary glue code to work around limitations in
> the ASoC v1 framework. I expect ASoC v2 won't need this.
It will need some way of providing a machine driver, generic (like this
one) or otherwise.
> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> +{
> + struct platform_device *pdev;
> + int rc;
> +
> + /* Only register the device if both the codec and platform have
> + * been registered */
> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> + return;
> +
> + pr_info("platform<-->codec match achieved; registering machine\n");
So what this does is add an extremely simple machine driver which
matches up the first DAI on a single codec and platform with no facility
for setting up any configurable clocking or anything? This is fine in
so far as it goes but it's going to work for very few systems as it is -
most codecs will need some additional configuration. This could be
added later, though.
Given this it might be worth renaming it to something less generic and
perhaps pushing it down into an of directory below the main ASoC
directory to parallel existing machine drivers. I'm happy with the code
from an ASoC point of view.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/14/08, Mark Brown <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>
> > Simple utility layer for creating ASoC machine instances based on data
> > in the OpenFirmware device tree. OF aware platform drivers and codec
> > drivers register themselves with this framework and the framework
> > automatically instantiates a machine driver.
>
>
> Ideally someone from the PowerPC community would sign off on this -
> given the nature and volume of discussion people obviously have very
> strong opinions about how machine drivers should be done so I'd really
> like to see some community buy in for something like this. From an ASoC
> point of view if this works it's fine.
Grant is one of the core PowerPC developers. There's no big
disagreement on the driver model, there just isn't a clean solution
for building a PowerPC ASoC driver under ASoC v1. The ASoC v1 driver
model is simply not compatible with the PowerPC device tree model.
That's why all of this glue code is needed.
Hopefully we can get the driver model sorted out in v2. If the ASoC
driver model is fixed all of this glue code disappears.
The PowerPC side isn't without fault too. PowerPC still doesn't have a
good way to load the fabric/machine driver.
Which are we going to call it, fabric or machine? I had been working
on the Apple code in sound/aoa. It is called fabric in that code. The
equivalent driver is called machine in ASoC v1.
>
>
> > This is most likely temporary glue code to work around limitations in
> > the ASoC v1 framework. I expect ASoC v2 won't need this.
>
>
> It will need some way of providing a machine driver, generic (like this
> one) or otherwise.
>
>
> > +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> > +{
> > + struct platform_device *pdev;
> > + int rc;
> > +
> > + /* Only register the device if both the codec and platform have
> > + * been registered */
> > + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> > + return;
> > +
> > + pr_info("platform<-->codec match achieved; registering machine\n");
>
>
> So what this does is add an extremely simple machine driver which
> matches up the first DAI on a single codec and platform with no facility
> for setting up any configurable clocking or anything? This is fine in
> so far as it goes but it's going to work for very few systems as it is -
> most codecs will need some additional configuration. This could be
> added later, though.
>
> Given this it might be worth renaming it to something less generic and
> perhaps pushing it down into an of directory below the main ASoC
> directory to parallel existing machine drivers. I'm happy with the code
> from an ASoC point of view.
>
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:13:14AM -0400, Jon Smirl wrote: > On 7/14/08, Mark Brown <[EMAIL PROTECTED]> wrote: > > Ideally someone from the PowerPC community would sign off on this - > > given the nature and volume of discussion people obviously have very > Grant is one of the core PowerPC developers. There's no big OK, fair enough... > Hopefully we can get the driver model sorted out in v2. If the ASoC > driver model is fixed all of this glue code disappears. > The PowerPC side isn't without fault too. PowerPC still doesn't have a > good way to load the fabric/machine driver. I'm finding it difficult to square these two statements - from an ASoC point of view the main thing this patch is doing is adding a machine driver and that's not something that's going to go away. With version 2 you will get the wait for all components to come on-line logic that's implemented here from the ASoC core but that doesn't remove the need for a machine driver to tell the core what to wait for and arrange any machine specific things like clocking. It's this debate about machine drivers that makes me nervous here. Like I say, from an ASoC point of view it's not an issue and the current approach is fine. > Which are we going to call it, fabric or machine? I had been working > on the Apple code in sound/aoa. It is called fabric in that code. The > equivalent driver is called machine in ASoC v1. ASoC has always called it a machine driver. > > > This is most likely temporary glue code to work around limitations in > > > the ASoC v1 framework. I expect ASoC v2 won't need this. > > > > > > It will need some way of providing a machine driver, generic (like this > > one) or otherwise. [BTW, it'd be helpful if you could delete unreferenced quotes when you reply - it makes things much easier to read, especially when reviewing lengthy patches. Unfortunately the GMail UI encourages doing this :(] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Jon Smirl wrote: > Which are we going to call it, fabric or machine? Fabric. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: >> The PowerPC side isn't without fault too. PowerPC still doesn't have a >> good way to load the fabric/machine driver. > > I'm finding it difficult to square these two statements - from an ASoC > point of view the main thing this patch is doing is adding a machine > driver and that's not something that's going to go away. Jon's concern is that there is no straightforward way to build a kernel with multiple fabric drivers and have the right one chosen via the device tree. This is just a limitation of the device tree model, and no one has come up with a good solution yet. The problem still exists in ASoC V2. However, it's not anything that ASoC itself needs to be concerned with. It's purely a PowerPC problem. >> Which are we going to call it, fabric or machine? I had been working >> on the Apple code in sound/aoa. It is called fabric in that code. The >> equivalent driver is called machine in ASoC v1. > > ASoC has always called it a machine driver. Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, it should be called a fabric driver because we already have machine drivers. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:14 AM, Timur Tabi <[EMAIL PROTECTED]> wrote: > Mark Brown wrote: > >>> The PowerPC side isn't without fault too. PowerPC still doesn't have a >>> good way to load the fabric/machine driver. >> >> I'm finding it difficult to square these two statements - from an ASoC >> point of view the main thing this patch is doing is adding a machine >> driver and that's not something that's going to go away. > > Jon's concern is that there is no straightforward way to build a kernel with > multiple fabric drivers and have the right one chosen via the device tree. > This > is just a limitation of the device tree model, and no one has come up with a > good solution yet. > > The problem still exists in ASoC V2. However, it's not anything that ASoC > itself needs to be concerned with. It's purely a PowerPC problem. It's purely an *OF Device Tree* problem. PowerPC isn't the only platform using the device tree. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote: > Mark Brown wrote: > > I'm finding it difficult to square these two statements - from an ASoC > > point of view the main thing this patch is doing is adding a machine > > driver and that's not something that's going to go away. > Jon's concern is that there is no straightforward way to build a kernel with > multiple fabric drivers and have the right one chosen via the device tree. > This > is just a limitation of the device tree model, and no one has come up with a > good solution yet. Indeed - I understand what the problem you guys have is, I just want to make sure that there is a reasonable consensus among the PowerPC people that this approach is OK to go in and won't create ructions. The lack of resolution on this issue makes me nervous about any proposed solution where I haven't seen any explicit indication that the community is OK with it. Incidentally, nobody ever really commented on my suggestion to do something DMI-like - you've already got the board type information present in the device trees (in the model and compatible information in the root nodes), all that's needed is an API to allow matching on it. > The problem still exists in ASoC V2. However, it's not anything that ASoC > itself needs to be concerned with. It's purely a PowerPC problem. Right, I just want to be clear that you guys all understand what this code does and that there won't be too many complaints after the fact. > > ASoC has always called it a machine driver. > Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, > it > should be called a fabric driver because we already have machine drivers. I don't mind - you can call it what you like inside PowerPC-specific code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 7:49 AM, Mark Brown
<[EMAIL PROTECTED]> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
>> +{
>> + struct platform_device *pdev;
>> + int rc;
>> +
>> + /* Only register the device if both the codec and platform have
>> + * been registered */
>> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
>> + return;
>> +
>> + pr_info("platform<-->codec match achieved; registering machine\n");
>
> So what this does is add an extremely simple machine driver which
> matches up the first DAI on a single codec and platform with no facility
> for setting up any configurable clocking or anything? This is fine in
> so far as it goes but it's going to work for very few systems as it is -
> most codecs will need some additional configuration. This could be
> added later, though.
Yes, that is pretty much exactly what it is. When I wrote this my
goal was just to get something working that had some semblance of
cleanliness. Since it is now looking like something that could get
merged, I'll clean up the documentation describing exactly what it is
and what the limitations are. I fully expect that if others find it
useful then they will need to extend it to extract additional
configuration information out of the device tree.
That being said, I expect this code to be completely rewritten when
ASoC v2 hits mainline. Most of the code is devoted to matching
platforms with codecs. The mechanism will be completely different
when the ASoC layer handles making sure all devices are present before
setting up the machine driver. I expect that some machines can be
handled with some form of generic of-asoc driver, while more complex
ones will need custom code.
> Given this it might be worth renaming it to something less generic and
> perhaps pushing it down into an of directory below the main ASoC
> directory to parallel existing machine drivers. I'm happy with the code
> from an ASoC point of view.
I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
(only the mpc5200 i2s driver uses it at the moment). It can always be
renamed if other folks want to use it for other chips.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: > I'm okay with that. How about fsl/mpc5200-of-machine.c for now? > (only the mpc5200 i2s driver uses it at the moment). It can always be > renamed if other folks want to use it for other chips. That seems reasonable so long as you're happy with it, though it does seem to be going to the other extreme in terms of broadness :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote: >> Mark Brown wrote: > >> > I'm finding it difficult to square these two statements - from an ASoC >> > point of view the main thing this patch is doing is adding a machine >> > driver and that's not something that's going to go away. > >> Jon's concern is that there is no straightforward way to build a kernel with >> multiple fabric drivers and have the right one chosen via the device tree. >> This >> is just a limitation of the device tree model, and no one has come up with a >> good solution yet. > > Indeed - I understand what the problem you guys have is, I just want to > make sure that there is a reasonable consensus among the PowerPC people > that this approach is OK to go in and won't create ructions. The lack > of resolution on this issue makes me nervous about any proposed solution > where I haven't seen any explicit indication that the community is OK > with it. > > Incidentally, nobody ever really commented on my suggestion to do > something DMI-like I'm feeling stupid; what does "DMI" stand for? > - you've already got the board type information > present in the device trees (in the model and compatible information in > the root nodes), all that's needed is an API to allow matching on it. Yes, we have APIs for matching against device trees. Personally, I'm leaning towards having the powerpc platform code (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a platform device for the machine driver and let as many machine drivers as needed be written. Hopefully we'll be able to do at least one generic machine driver that will be usable by most PowerPC boards, but I don't think it is a requirement or even realistic to shoehorn all powerpc sound circuits into a single driver. >> The problem still exists in ASoC V2. However, it's not anything that ASoC >> itself needs to be concerned with. It's purely a PowerPC problem. > > Right, I just want to be clear that you guys all understand what this > code does and that there won't be too many complaints after the fact. Shouldn't be. I'm certainly not pushing this as the end-all be-all powerpc sound machine driver. >> > ASoC has always called it a machine driver. > >> Wait, I thought it's supposed to be called a fabric driver now? On PowerPC, >> it >> should be called a fabric driver because we already have machine drivers. > > I don't mind - you can call it what you like inside PowerPC-specific > code. Oh help! Don't tell us that! Otherwise we'll always be talking across purposes. When ambiguous, let's just be sure to always refer to them as "ASoC machine drivers". :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:16 AM, Mark Brown <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: > >> I'm okay with that. How about fsl/mpc5200-of-machine.c for now? >> (only the mpc5200 i2s driver uses it at the moment). It can always be >> renamed if other folks want to use it for other chips. > > That seems reasonable so long as you're happy with it, though it does > seem to be going to the other extreme in terms of broadness :) heh; I don't care. This stuff is all going to be in flux anyway, so change is inevitable whatever is chosen now. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 11:21:12AM -0600, Grant Likely wrote: > On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown > > Incidentally, nobody ever really commented on my suggestion to do > > something DMI-like > I'm feeling stupid; what does "DMI" stand for? Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this. Note that it's *not* binding a driver, it just provides the hooks to enable the modules to be automatically loaded and to let drivers query information in DMI. > Yes, we have APIs for matching against device trees. Personally, I'm > leaning towards having the powerpc platform code > (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a > platform device for the machine driver and let as many machine drivers > as needed be written. Hopefully we'll be able to do at least one That would be what I'd expected initially - it is, after all, what other platforms are doing here. > generic machine driver that will be usable by most PowerPC boards, but > I don't think it is a requirement or even realistic to shoehorn all > powerpc sound circuits into a single driver. Yes, that'd be completely unrealistic. > > I don't mind - you can call it what you like inside PowerPC-specific > > code. > Oh help! Don't tell us that! Otherwise we'll always be talking > across purposes. When ambiguous, let's just be sure to always refer > to them as "ASoC machine drivers". :-) Feh, from now on I shall me naming all new concepts with pwgen :) . ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: > Desktop Management Interface, a standard BIOS interface for getting > system data on x86 class hardware. Of particular interest here is the > fact that it contains various ID strings for things like motherboard and > chassis - on Linux drivers can be automatically loaded based on these > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > that does this. The only problem with this is that the OF probing code in the kernel binds drivers to device tree nodes. So when a driver claims a node, no other driver will be probed with it. So we can't have generic nodes that classify the motherboard and just let everyone get probed on it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 01:40:24PM -0500, Timur Tabi wrote: > Mark Brown wrote: > > Desktop Management Interface, a standard BIOS interface for getting > > system data on x86 class hardware. Of particular interest here is the > > fact that it contains various ID strings for things like motherboard and > > chassis - on Linux drivers can be automatically loaded based on these > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > that does this. > The only problem with this is that the OF probing code in the kernel binds > drivers to device tree nodes. So when a driver claims a node, no other driver > will be probed with it. > So we can't have generic nodes that classify the motherboard and just let > everyone get probed on it. My suggestion is that you change this for the root node. It's already got the information required in there, it's just there's no way to use it to load modules at the minute. You could presumably read the information out of the device tree using existing APIs to check you're running on the right board once code is loaded? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Mark Brown wrote: >> The only problem with this is that the OF probing code in the kernel binds >> drivers to device tree nodes. So when a driver claims a node, no other >> driver >> will be probed with it. > >> So we can't have generic nodes that classify the motherboard and just let >> everyone get probed on it. > > My suggestion is that you change this for the root node. That's an interesting idea. > It's already > got the information required in there, it's just there's no way to use > it to load modules at the minute. Correct. > You could presumably read the > information out of the device tree using existing APIs to check you're > running on the right board once code is loaded? Yes. The driver <-> node binding is only for probing. Any driver can scan the entire tree at any time. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 01:40:24PM -0500, Timur Tabi wrote: > Mark Brown wrote: > > > Desktop Management Interface, a standard BIOS interface for getting > > system data on x86 class hardware. Of particular interest here is the > > fact that it contains various ID strings for things like motherboard and > > chassis - on Linux drivers can be automatically loaded based on these > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > that does this. > > The only problem with this is that the OF probing code in the kernel binds > drivers to device tree nodes. So when a driver claims a node, no other driver > will be probed with it. Yes, but that is only for the of_platform bus which is just one way to setup device drivers from the device tree. Setting it up from the platform code is just as valid an option. Or, each ASoC machine driver could read the device tree itself in the module_init hook to decide whether or not to instantiate itself. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> wrote: > Mark Brown wrote: > > > Desktop Management Interface, a standard BIOS interface for getting > > system data on x86 class hardware. Of particular interest here is the > > fact that it contains various ID strings for things like motherboard and > > chassis - on Linux drivers can be automatically loaded based on these > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > that does this. > > > The only problem with this is that the OF probing code in the kernel binds > drivers to device tree nodes. So when a driver claims a node, no other > driver > will be probed with it. > > So we can't have generic nodes that classify the motherboard and just let > everyone get probed on it. Allowing multiple binds at the root causes the problem of something like compatible="lite5200b,mpc5200-simple". Both platforms would bind and that's not what you want. I'm not a fan of each platform creating a platform device in arch/powerpc/platforms/*. That implies that each platform would cause another source file to be added each containing pretty much identical code. It also makes the mpc5200-simple platform pointless. Of course this scheme works and I'm doing it right now, but it's clearly not an optimal solution. Another scheme would be to add kernel code to always create virtual OF devices like "lite5200b-fabric" that are derived off from the machine name that achieved a bind. A third scheme would be to convert the powerpc machine drivers themselves to device drivers and move them out of arch/powerpc/platforms/* into drivers/whatever. Then add the ASoC fabric code to them. I don't know if you can load device drivers early enough to load a powerpc machine driver from initrd. A fourth scheme is to do it at compile time. But that means no universal firmware images that support multiple hardware revisions. We have this one today too. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote: > On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> wrote: > > Mark Brown wrote: > > > chassis - on Linux drivers can be automatically loaded based on these > > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > > that does this. > Allowing multiple binds at the root causes the problem of something > like compatible="lite5200b,mpc5200-simple". Both platforms would bind > and that's not what you want. Binding isn't the issue here - it's loading the driver in the first place. Once the drivers are loaded they can (hopefully) figure out if they are running on appropriate hardware. > Another scheme would be to add kernel code to always create virtual OF > devices like "lite5200b-fabric" that are derived off from the machine > name that achieved a bind. This is what I'm suggesting, modulo the fact that I'm suggesting *not* creating virtual devices but rather providing a mechanism for drivers to load without binding to anything. It strikes me that you're going to run into similar situations with other hardware at some point - either for undocumented extras that you happen to know exist on the system (like much of the DMI usage on x86) or for other things where you've got on-board hardware structured like sound hardware tends to be. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/15/08, Mark Brown <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote: > > On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> wrote: > > > Mark Brown wrote: > > > > > > chassis - on Linux drivers can be automatically loaded based on these > > > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > > > that does this. > > > > Allowing multiple binds at the root causes the problem of something > > like compatible="lite5200b,mpc5200-simple". Both platforms would bind > > and that's not what you want. > > Binding isn't the issue here - it's loading the driver in the first > place. Once the drivers are loaded they can (hopefully) figure out if > they are running on appropriate hardware. In this case we would end up with two core PowerPC machine drivers bound, not ALSA ones. We have machine drivers in the PowerPC core, that's one reason why it is confusing to call the ALSA drivers machine drivers too. If we allow multiple bindings both lite5200b and mpc5200-simple would bind. The compatible list is a priority list from most specific to most general. First you check for the specific driver lite5200b, if it's not found then load the generic one mpc5200-simple. > > Another scheme would be to add kernel code to always create virtual OF > > devices like "lite5200b-fabric" that are derived off from the machine > > name that achieved a bind. > > > This is what I'm suggesting, modulo the fact that I'm suggesting *not* > creating virtual devices but rather providing a mechanism for drivers to > load without binding to anything. It strikes me that you're going to If you have drivers for four different hardware releases compiled into your kernel, the only kernel mechanism I know of to trigger only one of these to initialize is to create a device and then let the probe mechanism sort it out. This is even more true when the drivers are on initrd and need to be dynamically loaded. The module load code will search through the alias lists in the module .ko files. It has been pointed out that a lite5200b-fabric device isn't really a virtual devices. It's a device that represents the traces on the PCB wiring the generic chip drivers together. > run into similar situations with other hardware at some point - either > for undocumented extras that you happen to know exist on the system > (like much of the DMI usage on x86) or for other things where you've got > on-board hardware structured like sound hardware tends to be. This makes sense, it is possible that other areas we aren't familiar with will need fabric drivers too. The problem is easily exposed in audio hardware since we use external clock and amp chips. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote: > On 7/15/08, Mark Brown <[EMAIL PROTECTED]> wrote: > > Binding isn't the issue here - it's loading the driver in the first > > place. Once the drivers are loaded they can (hopefully) figure out if > > they are running on appropriate hardware. > In this case we would end up with two core PowerPC machine drivers > bound, not ALSA ones. We have machine drivers in the PowerPC core, > that's one reason why it is confusing to call the ALSA drivers machine > drivers too. Again, I'm not talking about binding anything. > > This is what I'm suggesting, modulo the fact that I'm suggesting *not* > > creating virtual devices but rather providing a mechanism for drivers to > > load without binding to anything. It strikes me that you're going to > If you have drivers for four different hardware releases compiled into > your kernel, the only kernel mechanism I know of to trigger only one > of these to initialize is to create a device and then let the probe > mechanism sort it out. This is even more true when the drivers are on > initrd and need to be dynamically loaded. The module load code will > search through the alias lists in the module .ko files. This can be handled in the module initialisation (rather than driver probe) - providing something can arrange for the driver to get loaded then the drivers can check the system they're running on when that happens and fail if it's inappropriate. The ARM ASoC drivers and x86 DMI based stuff do things this way, for example (ARM doesn't have the automatic module load stuff implemented, though). The infrastructure for automatically loading modules is usable separately from device registration, though normally the two do go hand in hand. > It has been pointed out that a lite5200b-fabric device isn't really a > virtual devices. It's a device that represents the traces on the PCB > wiring the generic chip drivers together. This was brought up very early on when you guys first started working on it. :/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
