Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





In the case of this driver could you look at registering the link from
the device for the clocks?  Have it say "I supply SCK on device X" as it
registers.  That should be fairly straightforward I think, we do that
for one of the regulators.

When you wrote 'in the case of this driver', were you referring to the clock provider, saying 'I support SCK on device i2c-104C5122:00' ?

If you have a pointer on the regulator example, I'd appreciate it, I am really way beyond my comfort zone.

The main thing I want to avoid is having to have the CODEC drivers know
platform specific strings that they're supposed to look up, or general
approaches where that ends up being a thing that looks idiomatic.  That
was something board files did for a while, it didn't work very well and
we did something better with clkdev instead.  I'm a lot less worried
about this for cases where it's two devices that are part of the SoC
talking to each other, that's relatively well controled and doesn't
affect non-x86 platforms.  When it starts touching the CODECs it's a lot
more worrying.

I see the nuance, thanks for the clarification.

Maybe an alternate suggestion if you want to avoid hard-coded strings in the kernel: what if we added optional properties for the clock lookup name in both the codec and clock driver, and set the name in a _DSD blob. That would move the platform-specific names to platform firmware, and avoid the links described above that are probably ACPI-only.

In this case we can add whatever we want, the DSDT table contains absolutely nothing for audio so we can add things as needed, and in case another usage of this codec happens in a future device they'd have to define their own clock name and store it in platform firmware.

I think by now there's ample evidence that it's worth investing in
better firmware descriptions :(

Indeed, and tools to check they are correct! Most of the stuff we defined for SoundWire ends-up wrong or undefined, still an uphill battle...



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux