On Wed, Jun 17, 2020 at 04:04:59PM -0600, Rob Herring wrote:
> Given bus numbering may not be constant, that seems like not the best
> way to match up devices. I'd assume that userspace needs some way to
> identify which instance is which already, so maybe there's other data
> you can use alrea
On Wed, Jun 10, 2020 at 09:12:15AM -0500, Dan Murphy wrote:
> Mark
>
> On 6/10/20 5:29 AM, Mark Brown wrote:
> > On Tue, Jun 09, 2020 at 02:20:29PM -0500, Dan Murphy wrote:
> > > On 6/9/20 1:47 PM, Mark Brown wrote:
> > > > That's really not very idiomatic for how Linux does stuff and seems to
> >
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-
Mark
On 6/10/20 5:29 AM, Mark Brown wrote:
On Tue, Jun 09, 2020 at 02:20:29PM -0500, Dan Murphy wrote:
On 6/9/20 1:47 PM, Mark Brown wrote:
That's really not very idiomatic for how Linux does stuff and seems to
pretty much guarantee issues with hotplugging controls and ordering -
you'd need sp
On Tue, Jun 09, 2020 at 02:20:29PM -0500, Dan Murphy wrote:
> On 6/9/20 1:47 PM, Mark Brown wrote:
> > That's really not very idiomatic for how Linux does stuff and seems to
> > pretty much guarantee issues with hotplugging controls and ordering -
> > you'd need special userspace to start up even
Mark
On 6/9/20 1:47 PM, Mark Brown wrote:
On Tue, Jun 09, 2020 at 01:06:50PM -0500, Dan Murphy wrote:
I could make a default as you suggested to include i2c address and bus in
the name. But the TAS2563 does not need the firmware to operate and the
2562 does not have a DSP.
That's fine, the d
On Tue, Jun 09, 2020 at 01:06:50PM -0500, Dan Murphy wrote:
> I could make a default as you suggested to include i2c address and bus in
> the name. But the TAS2563 does not need the firmware to operate and the
> 2562 does not have a DSP.
That's fine, the driver can just use the compatible string
Mark
On 6/9/20 12:58 PM, Mark Brown wrote:
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 han
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 st
Mark
On 6/9/20 12:31 PM, Mark Brown wrote:
On Tue, Jun 09, 2020 at 12:28:40PM -0500, Dan Murphy wrote:
Add a property called firmware-name that will be the name of the
firmware that will reside in the file system or built into the kernel.
Why not just use a standard name for the firmware? If
On Tue, Jun 09, 2020 at 12:28:40PM -0500, Dan Murphy wrote:
> Add a property called firmware-name that will be the name of the
> firmware that will reside in the file system or built into the kernel.
Why not just use a standard name for the firmware? If the firmwares
vary per-board then building
Add a property called firmware-name that will be the name of the
firmware that will reside in the file system or built into the kernel.
Signed-off-by: Dan Murphy
---
Documentation/devicetree/bindings/sound/tas2562.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicet
12 matches
Mail list logo
