Re: [PATCH] iio: dac: ad5593r: Dynamically set AD5593R channel modes

[Andy Shevchenko <andy.shevchenko@gmail.com>]

On Thu, Sep 3, 2020 at 10:37 AM AceLan Kao <acelan.kao@canonical.com> wrote:
>
> Hi Andy,
>
> I spent some time studying/reading what you wrote, but I still don't
> understand how to leverage meta-acpi.

meta-acpi is a Yocto layer to support provided ACPI tables for the
build. My point here is to have it as a collection of ASL examples.
It's what you asked for below in this email.
Also we can collect your ASL example under board (presumably new) folder.

> From what I understand from the following discussion in the thread,
> ADS5593 could be used,
> so we can keep using it and don't have to introduce PRP0001 in the table, right?

Precisely!

> Here is the ADS5593 asl code, but I have no idea how to re-use it
> after it's been modified,
> the only way I know is to override the ACPI tables via initrd[1].

There is also Config FS approach (like overlays) to do it at runtime.
That what we are using in Yocto build for Intel Edison.

> Could you share some examples in real cases that I can follow?

Yes, like I mentioned StackOverflow search results (maybe G will give better).
But let's see what you have in your ASL code first.

On the first glance I didn't see any issues with it, but on second
look here is one. Look into this [5] example.
If you noticed it uses the same path in Scope and in the reference in
I2cSerialBus() while in your ASL they are different.

Do you have issues with loading it (as is and after above addressed)?

[5]: https://github.com/westeri/meta-acpi/blob/master/recipes-bsp/acpi-tables/samples/edison/ft6236.asli

> Thanks.
>
> 1. Documentation/admin-guide/acpi/initrd_table_override.rst
>
> Andy Shevchenko <andy.shevchenko@gmail.com> 於 2020年8月31日 週一 下午8:48寫道：
> >
> > On Mon, Aug 31, 2020 at 3:45 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Mon, Aug 31, 2020 at 2:28 PM AceLan Kao <acelan.kao@canonical.com> wrote:
> > > > This patch is mainly for Advantech's UNO-420[1] which is a x86-based platform.
> > > > This platform is more like a development platform for customers to
> > > > customize their products,
> > > > so, specify the channel modes in ACPI table is not generic enough,
> > > > that's why William submit this patch.
> > > >
> > > > Are there other ways to specify or pass values to the module without
> > > > using module parameters?
> > > > It's good if we can leverage sysfs, but I don't know if there is one
> > > > for this scenario.
> > >
> > > Can we provide DT bindings for that and use then in ACPI? ACPI has a
> > > possibility to reuse DT properties and compatible strings [1]. As far
> > > as I can see the driver uses fwnode API, so it supports ACPI case
> > > already [2]. So, what prevents you to utilize 'adi,mode' property?
> > >
> > > Also, we accept examples of ASL excerpt in meta-acpi project [3]. It
> > > has already plenty of examples [4] how to use PRP0001 for DIY /
> > > development boards.
> > >
> > > So, take all together I think this patch is simple redundant.
> >
> > One more useful link is SO answers on the topic:
> > https://stackoverflow.com/search?tab=newest&q=prp0001
> >
> > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > > [2]: https://elixir.bootlin.com/linux/v5.9-rc3/source/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> > > [3]: https://github.com/westeri/meta-acpi
> > > [4]: https://github.com/westeri/meta-acpi/tree/master/recipes-bsp/acpi-tables/samples
> > >
> > > P.S. Jonathan, it seems this driver has artificial ACPI HID. We
> > > probably have to remove it. However, ADS is indeed reserved for Analog
> > > Devices in PNP registry. Can we have AD's official answer on this?
> > > Cc'ing additional AD people.
> > >
> > > > 1. https://www.advantech.com/products/9a0cc561-8fc2-4e22-969c-9df90a3952b5/uno-420/mod_2d6a546b-39e3-4bc4-bbf4-ac89e6b7667c



-- 
With Best Regards,
Andy Shevchenko