From: Mark Brown <broonie@kernel.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com,
robh@kernel.org, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563
Date: Tue, 9 Jun 2020 18:58:52 +0100 [thread overview]
Message-ID: <20200609175852.GQ4583@sirena.org.uk> (raw)
In-Reply-To: <bb7cff87-f814-1b37-c9eb-e68919e3c077@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
On Tue, Jun 09, 2020 at 12:35:50PM -0500, Dan Murphy wrote:
> On 6/9/20 12:31 PM, Mark Brown wrote:
> > Why not just use a standard name for the firmware? If the firmwares
> > vary per-board then building it using the machine compatible (or DMI
> > info) could handle that, with a fallback to a standard name for a
> > default setup.
> The number of firmwares can vary per IC on the board itself. So you may
> have X number of firmware files all with different names all targets for
> different TAS2563 ICs.
> Also TI will not be providing the individual binaries to the customer.
> There is a customer tool that the user uses to create the binaries.
> So the output names are arbitrary.
> I was going to mention this in the cover letter but did not think mentioning
> the user tool had any value
That's all fairly standard for this sort of device. You could still
cope with this by including the I2C address in the default name
requested - do something like tas2562/myboard-addr.fw or whatever. The
concern here is that someone shouldn't have to replace their DT if they
decide they want to start using the DSP, and someone making a distro
shouldn't be stuck dealing with what happens if multiple vendors decide
to just reuse the same name (eg, just calling everything tas2562
regardless of plastics).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-06-09 17:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 17:28 [RFC PATCH 0/2] TAS2563 DSP Firmware Loader Dan Murphy
2020-06-09 17:28 ` [RFC PATCH 1/2] dt-bindings: tas2562: Add firmware support for tas2563 Dan Murphy
2020-06-09 17:31 ` Mark Brown
2020-06-09 17:35 ` Dan Murphy
2020-06-09 17:58 ` Mark Brown [this message]
2020-06-09 18:06 ` Dan Murphy
2020-06-09 18:47 ` Mark Brown
2020-06-09 19:20 ` Dan Murphy
2020-06-10 10:29 ` Mark Brown
2020-06-10 14:12 ` Dan Murphy
2020-06-10 14:28 ` Mark Brown
2020-06-17 22:04 ` Rob Herring
2020-06-18 10:57 ` Mark Brown
2020-06-09 17:28 ` [RFC PATCH 2/2] ASoc: tas2563: DSP Firmware loading support Dan Murphy
2020-06-09 17:50 ` Mark Brown
2020-06-12 17:30 ` Dan Murphy
2020-06-12 17:46 ` Mark Brown
2020-06-09 17:52 ` [RFC PATCH 0/2] TAS2563 DSP Firmware Loader Mark Brown
2020-06-09 18:07 ` Dan Murphy
2020-06-09 18:16 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200609175852.GQ4583@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=robh@kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®