[alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Grant Likely
grant.likely at secretlab.ca
Tue Jul 15 03:21:12 EST 2008
On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown
<broonie at opensource.wolfsonmicro.com> 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.
More information about the Linuxppc-dev
mailing list