[RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200610/c1c0919f/attachment.sig>