[PATCH v1 28/43] i2c: designware_i2c: Support ACPI table generation
Simon Glass
sjg at chromium.org
Wed Jul 8 05:33:00 CEST 2020
Hi Wolfgang,
On Thu, 25 Jun 2020 at 06:46, Wolfgang Wallner
<wolfgang.wallner at br-automation.com> wrote:
>
> Hi Simon,
>
> -----"Simon Glass" <sjg at chromium.org> schrieb: -----
> > Betreff: [PATCH v1 28/43] i2c: designware_i2c: Support ACPI table generation
> >
> > Update the PCI driver to generate ACPI information so that Linux has the
> > full information about each I2C bus.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> >
> > ---
> >
> > Changes in v1:
> > - Capitalise ACPI_OPS_PTR
> >
> > drivers/i2c/designware_i2c.c | 25 ++++++++
> > drivers/i2c/designware_i2c.h | 15 +++++
> > drivers/i2c/designware_i2c_pci.c | 104 ++++++++++++++++++++++++++++++-
> > 3 files changed, 143 insertions(+), 1 deletion(-)
> >
[.]
> > +/*
> > + * Write ACPI object to describe speed configuration.
> > + *
> > + * ACPI Object: Name ("xxxx", Package () { scl_lcnt, scl_hcnt, sda_hold }
> > + *
> > + * SSCN: I2C_SPEED_STANDARD
> > + * FMCN: I2C_SPEED_FAST
> > + * FPCN: I2C_SPEED_FAST_PLUS
> > + * HSCN: I2C_SPEED_HIGH
> > + */
> > +static void dw_i2c_acpi_write_speed_config(struct acpi_ctx *ctx,
> > + struct dw_i2c_speed_config *config)
> > +{
> > + switch (config->speed_mode) {
> > + case IC_SPEED_MODE_HIGH:
> > + acpigen_write_name(ctx, "HSCN");
> > + break;
> > + case IC_SPEED_MODE_FAST_PLUS:
> > + acpigen_write_name(ctx, "FPCN");
> > + break;
> > + case IC_SPEED_MODE_FAST:
> > + acpigen_write_name(ctx, "FMCN");
> > + break;
> > + case IC_SPEED_MODE_STANDARD:
> > + default:
> > + acpigen_write_name(ctx, "SSCN");
> > + }
> > +
> > + /* Package () { scl_lcnt, scl_hcnt, sda_hold } */
> > + acpigen_write_package(ctx, 3);
> > + acpigen_write_word(ctx, config->scl_hcnt);
> > + acpigen_write_word(ctx, config->scl_lcnt);
> > + acpigen_write_dword(ctx, config->sda_hold);
> > + acpigen_pop_len(ctx);
> > +}
>
> This function is rather generic, and probably the same for any I2C controller.
> Is the intention to implement it for Designware as a first step and move it to
> a generic place if the need arises, or should it stay here?
So far I have only not seen Intel SoCs use anything other than
designware I2C. If that happens then the encoding may well be the same
and we could end up with some common code. But I am not sure at
present. The kernel I2C driver that reads this is designware ony, from
what I can tell.
Regards,
Simon
More information about the U-Boot
mailing list