All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Beer <daniel.beer@igorinstitute.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, Andy Liu <andy-liu@ti.com>,
	Derek Simkowiak <derek.simkowiak@igorinstitute.com>,
	Rob Herring <robh+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH 2/2] ASoC: dt-bindings: add bindings for TI TAS5805M.
Date: Wed, 12 Jan 2022 07:47:00 +1300	[thread overview]
Message-ID: <20220111184700.GA10070@nyquist.nev> (raw)
In-Reply-To: <Yd29tk6ZJgDFDvVI@sirena.org.uk>

On Tue, Jan 11, 2022 at 05:26:14PM +0000, Mark Brown wrote:
> On Tue, Jan 11, 2022 at 01:00:09PM +1300, Daniel Beer wrote:
> 
> > +  ti,dsp-config: |
> > +    description: |
> > +      A byte sequence giving DSP configuration. Each pair of bytes, in
> > +      sequence, gives a register address and a value to write. If you
> > +      are taking this data from TI's PPC3 tool, this should contain only
> > +      the register writes following the 5ms delay.
> 
> This doesn't look appropriate for DT, it looks more like it should be
> loaded as firmware since systems might want to support multiple
> configurations at runtime based on use casea.  It would also be good to
> have code to validate that any supplied coefficeints/firmware don't
> overwrite registers managed by the driver, just in case.

Hi Mark,

That was my initial thought, but the problem is that different instances
may have different configurations.

We don't really have a way of validating the configuration here, since
it's typically generated by TI's PPC3 tool.

If you think it's still inappropriate to supply the configuration in the
device-tree, do you have any suggestions?

Cheers,
Daniel

-- 
Daniel Beer
Firmware Engineer at Igor Institute
daniel.beer@igorinstitute.com or +64-27-420-8101
Offices in Seattle, San Francisco, and Vancouver BC or (206) 494-3312

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Beer <daniel.beer@igorinstitute.com>
To: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Andy Liu <andy-liu@ti.com>, Rob Herring <robh+dt@kernel.org>,
	Derek Simkowiak <derek.simkowiak@igorinstitute.com>
Subject: Re: [PATCH 2/2] ASoC: dt-bindings: add bindings for TI TAS5805M.
Date: Wed, 12 Jan 2022 07:47:00 +1300	[thread overview]
Message-ID: <20220111184700.GA10070@nyquist.nev> (raw)
In-Reply-To: <Yd29tk6ZJgDFDvVI@sirena.org.uk>

On Tue, Jan 11, 2022 at 05:26:14PM +0000, Mark Brown wrote:
> On Tue, Jan 11, 2022 at 01:00:09PM +1300, Daniel Beer wrote:
> 
> > +  ti,dsp-config: |
> > +    description: |
> > +      A byte sequence giving DSP configuration. Each pair of bytes, in
> > +      sequence, gives a register address and a value to write. If you
> > +      are taking this data from TI's PPC3 tool, this should contain only
> > +      the register writes following the 5ms delay.
> 
> This doesn't look appropriate for DT, it looks more like it should be
> loaded as firmware since systems might want to support multiple
> configurations at runtime based on use casea.  It would also be good to
> have code to validate that any supplied coefficeints/firmware don't
> overwrite registers managed by the driver, just in case.

Hi Mark,

That was my initial thought, but the problem is that different instances
may have different configurations.

We don't really have a way of validating the configuration here, since
it's typically generated by TI's PPC3 tool.

If you think it's still inappropriate to supply the configuration in the
device-tree, do you have any suggestions?

Cheers,
Daniel

-- 
Daniel Beer
Firmware Engineer at Igor Institute
daniel.beer@igorinstitute.com or +64-27-420-8101
Offices in Seattle, San Francisco, and Vancouver BC or (206) 494-3312

  reply	other threads:[~2022-01-11 18:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  0:00 [PATCH 2/2] ASoC: dt-bindings: add bindings for TI TAS5805M Daniel Beer
2022-01-11  0:00 ` Daniel Beer
2022-01-11 15:14 ` Rob Herring
2022-01-11 15:14   ` Rob Herring
2022-01-11 17:26 ` Mark Brown
2022-01-11 17:26   ` Mark Brown
2022-01-11 18:47   ` Daniel Beer [this message]
2022-01-11 18:47     ` Daniel Beer
2022-01-14 12:11     ` Mark Brown
2022-01-14 12:11       ` 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=20220111184700.GA10070@nyquist.nev \
    --to=daniel.beer@igorinstitute.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andy-liu@ti.com \
    --cc=broonie@kernel.org \
    --cc=derek.simkowiak@igorinstitute.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.