> Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. Oops. >> - we currently don't support 'shipping the topology and firmware >> bundled up in a single image to avoid them getting out of sync'. No >> idea how that might work. > > Seems like it'd be trivial to arrange in the kernel, or with userspace > firmware loading the loader could do the unpacking. I think we can bundle the firmware inside of the kernel image itself, but we've never tried so it doesn't work by default. I don't know what userspace loading means, we rely on request_firmware and don't assume any specific support from userspace. >> - if the machine driver is specified in DeviceTree, then the topology >> used is *required* to be aligned with the machine driver. The rules >> are that a topology may not make references to a BE dailink exposed in >> the machine driver, but conversely if the topology makes a reference >> to a BE dailink that is not exposed in the machine driver the topology >> parsing will fail. It's one of the current weaknesses of >> topology-based solutions, we have non-configurable hardware-related >> things that are described in topology but should really be described >> in platform firmware, be it ACPI or DT, and provided to the topology. > > That seems like an orthogonal issue here? The requirement for a > firmware that's joined up with the hardware (and system description) > that it's being used with exists regardless of how we rename things. It's not completely orthogonal. The topology currently defines e.g. the I2S interface index, Mclk, bclk, fsync, etc, and my point is that these bits of information are completely related to the hardware and should probably come from platform firmware/ACPI. The topology framework currently provides too much freedom to developers, it's fine to add new pipelines, PCM devices and new processing, but when it comes to the hardware interfaces the topology is completely constrained. I've been arguing for a while now that the dailink descriptions and configurations should be treated as an input to the topology, not something that the topology can configure. I don't know how many issues we had to deal with because the topology settings were not supported by the hardware, or mismatches between topology and machine drivers (missing dailinks, bad dailink index, etc).
