Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support

[Rafael J. Wysocki]

On Tuesday, November 06, 2012 01:53:01 PM Bjorn Helgaas wrote:
> On Tue, Nov 6, 2012 at 6:16 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> > On Monday, November 05, 2012 09:54:37 AM Bjorn Helgaas wrote:
> >> On Sat, Nov 3, 2012 at 2:39 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> >> > On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
> >> >> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> >> >> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> >> >> > ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
> >> >> > configure the SPI slave devices behind the SPI controller. This patch adds
> >> >> > support for this to the SPI core.
> >> >> >
> >> >> > In addition we bind ACPI nodes to SPI devices. This makes it possible for
> >> >> > the slave drivers to get the ACPI handle for further configuration.
> >> >> >
> >> >> > Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> >> >> > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >> >> > ---
> >> >> >  drivers/spi/spi.c |  231 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >>
> >> >> > +static acpi_status acpi_spi_add_resources(struct acpi_resource *res, void *data)
> >> >> > +{
> >> >> > +       struct acpi_spi_device_info *info = data;
> >> >> > +       struct acpi_resource_spi_serialbus *sb;
> >> >> > +       struct spi_device *spi = info->spi;
> >> >> > +
> >> >> > +       switch (res->type) {
> >> >> > +       case ACPI_RESOURCE_TYPE_SERIAL_BUS:
> >> >> > +               sb = &res->data.spi_serial_bus;
> >> >> > +               if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_SPI) {
> >> >> > +                       spi->chip_select = sb->device_selection;
> >> >> > +                       spi->max_speed_hz = sb->connection_speed;
> >> >> > +
> >> >> > +                       /* Mode (clock phase/polarity/etc. */
> >> >> > +                       if (sb->clock_phase == ACPI_SPI_SECOND_PHASE)
> >> >> > +                               spi->mode |= SPI_CPHA;
> >> >> > +                       if (sb->clock_polarity == ACPI_SPI_START_HIGH)
> >> >> > +                               spi->mode |= SPI_CPOL;
> >> >> > +                       if (sb->device_polarity == ACPI_SPI_ACTIVE_HIGH)
> >> >> > +                               spi->mode |= SPI_CS_HIGH;
> >> >> > +
> >> >> > +                       /*
> >> >> > +                        * The info is valid once we have found the
> >> >> > +                        * SPISerialBus resource.
> >> >> > +                        */
> >> >> > +                       info->valid = true;
> >> >> > +               }
> >> >> > +               break;
> >> >> > +
> >> >> > +       case ACPI_RESOURCE_TYPE_IRQ:
> >> >> > +               info->gsi = res->data.irq.interrupts[0];
> >> >> > +               info->triggering = res->data.irq.triggering;
> >> >> > +               info->polarity = res->data.irq.polarity;
> >> >> > +               break;
> >> >> > +
> >> >> > +       case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> >> >> > +               info->gsi = res->data.extended_irq.interrupts[0];
> >> >> > +               info->triggering = res->data.extended_irq.triggering;
> >> >> > +               info->polarity = res->data.extended_irq.polarity;
> >> >>
> >> >> A driver doesn't seem like the right place for _CRS parsing code.
> >> >
> >> > This is not a driver, however. :-)
> >>
> >> OK.  Can you describe what this is?  I assume the picture involves an
> >> SPI master device and one or more SPI slave devices, and the ACPI
> >> namespace tells us something about them, and somehow this code is
> >> related to those devices because it's looking at _CRS for them.
> >
> > This is part of the SPI core that looks for SPI devices below a controller.
> >
> >> A _CRS method is associated with a Device in the namespace.  What is
> >> that device in this case?
> >
> > An SPI device below a controller.
> >
> >> What is its PNP ID?
> >
> > I can't answer that from the top of my head, sorry.
> >
> >> What driver claims devices with that ID?
> >
> > The driver that declares support for it in its acpi_match_table[] array.
> 
> OK, I guess my problem is in understanding the difference between (1)
> a platform device where we use the acpi_match_table[] to locate
> devices with matching ACPI IDs, and (2) a device where we use
> pnp_register_driver() or acpi_bus_register_driver() to locate devices
> with matching ACPI IDs.
> 
> They seem similar to me.  For example, take a PNP0A03 PCI host bridge.
>  This seems like a platform device since there's no native hardware
> method to enumerate it.  The ACPI namespace gives us a way to find it.
>  We use acpi_bus_register_driver() to bind a driver to it.  The driver
> has the struct acpi_device * and can access any ACPI state it needs.
> The driver supplies .add() and .remove() methods, so in principle the
> driver doesn't need to know anything about hotplug (assuming the ACPI
> core handles hotplug correctly, which it doesn't yet).

Well, I hope this is the last time I need to explain that. :-)

Please see this message for detailed discussion:

http://marc.info/?l=linux-kernel&m=135180467616074&w=4

> How is the SPI controller different than this?  Is there some logical
> difference that requires a different framework?  Or are you proposing
> that we get rid of acpi_bus_register_driver() and migrate everything
> to this new framework?

Yes, I do, but let's just do it gradually.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/