Hi Simon,
On Mon, Jul 13, 2020 at 3:37 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Tue, 7 Jul 2020 at 21:25, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 6 Jul 2020 at 18:22, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Jul 7, 2020 at 3:22 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Thu, 2 Jul 2020 at 22:33, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Jul 3, 2020 at 11:50 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Thu, 2 Jul 2020 at 18:54, Bin Meng bmeng.cn@gmail.com wrote: > > Hi Simon, > > On Fri, Jul 3, 2020 at 8:46 AM Simon Glass sjg@chromium.org wrote: > > > > Hi Bin, > > > > On Mon, 29 Jun 2020 at 20:49, Bin Meng bmeng.cn@gmail.com wrote: > > > > > > Hi Simon, > > > > > > On Mon, Jun 15, 2020 at 11:57 AM Simon Glass sjg@chromium.org wrote: > > > > > > > > The Intel Non-High-Definition-Audio Link Table (NHLT) table describes the > > > > audio codecs and connections in a system. Various devices can contribute > > > > information to produce the table. > > > > > > > > Add core support for this, based on a structure which is built up through > > > > calls to the driver. > > > > > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > > --- > > > > > > > > drivers/core/acpi.c | 15 +++++++++++++++ > > > > include/dm/acpi.h | 26 ++++++++++++++++++++++++++ > > > > 2 files changed, 41 insertions(+) > > > > > > > > diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c > > > > index ea304a3067..a5053fec6f 100644 > > > > --- a/drivers/core/acpi.c > > > > +++ b/drivers/core/acpi.c > > > > @@ -31,6 +31,7 @@ enum method_t { > > > > METHOD_WRITE_TABLES, > > > > METHOD_FILL_SSDT, > > > > METHOD_INJECT_DSDT, > > > > + METHOD_SETUP_NHLT, > > > > > > Do we really need to promote this to be an ACPI core method? Can we > > > reuse the SSDT/DSDT one? > > > > I don't think so. Those two are for a particular purpose. In fact NHLT > > is generated while doing SSDT I think. The idea is that drivers that > > want to contribute to NHLT can do so. But we cannot use the SSDT > > mechanism since each driver contributes only a part of the info, and > > we need something else to bring it all together. > > Will there be only one device that sets up the NHLT info?
WIth coral it is two devices. I'm not sure of the maximum, but I suppose it depends on the audio codecs present.
Could we make this method to be provided by the codec device, instead of a generic ACPI core method?
The codec device does implement this. See the drivers where they actually implement the NHLT method.
This is definitely an ACPI-specific thing, so I think we need core support for iterating through drivers that want to provide this info.
My concern is that this is not generic enough to promote this to ACPI core.
I wanted to have something like this:
Create a codec uclass driver, and in the code uclass driver, create an op that is used to set up the NHLT infor if ACPI_GEN is on.
We already have UCLASS_SOUND so could add it to sound_ops. But that seems weird to me since this is not an operation to play a sound. We do this with GIPOs and IRQs but in that case the operation returns some data. Here we are asking the driver to add some data to a table. I'm just not sure it makes sense.
What do you think?
Let me know what you think about this as I'd like to finish this series.
I haven't looked into the details of NHLT but I trust your consideration so let's leave this as it is.
Regards, Bin