On Tue, Apr 14, 2020 at 03:13:01PM -0500, Pierre-Louis Bossart wrote: > On 4/14/20 2:50 PM, Mark Brown wrote: > > It's not just DT platforms that I'm worried about here, it's also ACPI > > systems - all it takes is for a system to have a second device and a > > name collision could happen, especially with such generic names. We > > tried to avoid doing this for board files for the same reason. > I am on the paranoid side but here I don't see much potential for conflicts: > a) this only works for the Up2 board with a HAT connector > b) this only work with the Hifiberry DAC+ PRO board. > This codec is not used in any traditional client devices. That's what you're doing right now but someone else can use the same devices, or adopt the same approaches on something like a Chromebook. > > My understanding is that ACPI just doesn't have clock bindings (or audio > > bindings or...) so you're basically using board files here and board > > files can definitely do more than we're seeing here. > I don't understand your definition of board file, sorry. We've never had > one, the only thing that's board-specific is the machine driver. Architectures that don't have firmware bindings use straight C code to register and set things up. Machine drivers are essentially board files, they're just audio specific bits of board file that use audio APIs and so are in the sound directory. > > You should be able to register links between devices using the clock > > API, or add that functionality if it's not there but AFAIK clkdev still > > works. > The machine driver has no information whatsoever on who provides the clock. > I just don't see how I might link stuff without at least some amount of > information? The machine driver must have this information, it knows exactly what hardware it runs on. The whole point of a machine driver is that it's board specific. > All I needed was to toggle 2 gpios to select 44.1 or 48kHz...Looks like it's > going to take two more years, oh well. I think you're giving up way too easily here. The kernel has really good support for systems that don't have any firmware description at all, this shouldn't be complex or breaking new ground.
Attachment:
signature.asc
Description: PGP signature
