On Wed, Jun 10, 2020 at 09:12:15AM -0500, Dan Murphy wrote: > On 6/10/20 5:29 AM, Mark Brown wrote: > > I'm not *completely* opposed to having the ability to suggest a name in > > firmware, the big problem is making use of the DSP completely dependent > > on having a DT property or doing some non-standard dance in userspace. > Well from what I see we have 4 options. These are not mutually exclusive approaches. > 1. We can have a DT node like RFC'd (Need Rob's comments here) This is compatible with any hardcoding option. > 2. We can have a defconfig flag that hard codes the name (This will > probably be met with some resistance if not some really bad reactions and I > don't prefer to do it this way) This is even worse than the ALSA control suggestion. > 3. We can hard code the name of the firmware in the c file. > 4. Dynamically derive a file name based on the I2C bus-address-device so it > would be expected to be "2_4c_tas2563.bin". Just need to figure out how to > get the bus number. > Again only option 1 allows us to have different firmware binaries per IC > instance and also denotes the use of the DSP. The DSP is not programmed No, this is not the case at all - a per-device generated file allows this just as well. > So special audio handling is very explicit in the user space. More then > likely most standard distributions will not even use the DSP for this device > it is more of a specialized use case for each product. People do things like make AOSP derived distributions for phones.
Attachment:
signature.asc
Description: PGP signature
