mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-kernel@vger.kernel.org, lenb@kernel.org,
	rafael.j.wysocki@intel.com, broonie@opensource.wolfsonmicro.com,
	grant.likely@secretlab.ca, linus.walleij@linaro.org,
	khali@linux-fr.org, ben-linux@fluff.org, w.sang@pengutronix.de,
	mathias.nyman@linux.intel.com, linux-acpi@vger.kernel.org
Subject: Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support
Date: Sat, 03 Nov 2012 21:39:25 +0100	[thread overview]
Message-ID: <1792336.CIafglX82A@vostro.rjw.lan> (raw)
In-Reply-To: <CAErSpo5q64uEse3aYYZkuQrD+9AJ9HFP_VVB1TabYfO-_BvY3g@mail.gmail.com>

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@linux.intel.com> 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@linux.intel.com>
> > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  drivers/spi/spi.c |  231 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 230 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > index 84c2861..de22a6e 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -35,6 +35,7 @@
> >  #include <linux/sched.h>
> >  #include <linux/delay.h>
> >  #include <linux/kthread.h>
> > +#include <linux/acpi.h>
> >
> >  static void spidev_release(struct device *dev)
> >  {
> > @@ -93,6 +94,10 @@ static int spi_match_device(struct device *dev, struct device_driver *drv)
> >         if (of_driver_match_device(dev, drv))
> >                 return 1;
> >
> > +       /* Then try ACPI */
> > +       if (acpi_driver_match_device(dev, drv))
> > +               return 1;
> > +
> >         if (sdrv->id_table)
> >                 return !!spi_match_id(sdrv->id_table, spi);
> >
> > @@ -888,6 +893,227 @@ static void of_register_spi_devices(struct spi_master *master)
> >  static void of_register_spi_devices(struct spi_master *master) { }
> >  #endif
> >
> > +#ifdef CONFIG_ACPI
> > +struct acpi_spi {
> > +       acpi_status (*callback)(struct acpi_device *, void *);
> > +       void *data;
> > +};
> > +
> > +static acpi_status acpi_spi_enumerate_device(acpi_handle handle, u32 level,
> > +                                            void *data, void **return_value)
> > +{
> > +       struct acpi_spi *acpi_spi = data;
> > +       struct acpi_device *adev;
> > +
> > +       if (acpi_bus_get_device(handle, &adev))
> > +               return AE_OK;
> > +       if (acpi_bus_get_status(adev) || !adev->status.present)
> > +               return AE_OK;
> > +
> > +       return acpi_spi->callback(adev, acpi_spi->data);
> > +}
> > +
> > +static acpi_status acpi_spi_enumerate(acpi_handle handle,
> > +       acpi_status (*callback)(struct acpi_device *, void *), void *data)
> > +{
> > +       struct acpi_spi acpi_spi;
> > +
> > +       acpi_spi.callback = callback;
> > +       acpi_spi.data = data;
> > +
> > +       return acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> > +                                  acpi_spi_enumerate_device, NULL,
> > +                                  &acpi_spi, NULL);
> > +}
> > +
> > +struct acpi_spi_device_info {
> > +       struct spi_device *spi;
> > +       int triggering;
> > +       int polarity;
> > +       int gsi;
> > +       bool valid;
> > +};
> > +
> > +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. :-)

> I think the intent of _CRS is to describe resources that need to be
> coordinated across all devices, e.g., MMIO space, I/O port space, and
> IRQs.  Since these resources require system-wide coordination, even
> when we don't have drivers for some devices, the ACPI core should be
> able to parse _CRS without needing any device-specific knowledge.

Hmm.

So you would like the ACPI core to parse _CRS centrally for each device
node and create an SPI device object and run spi_add_device() to register
it whenever it finds ACPI_RESOURCE_TYPE_SERIAL_BUS/ACPI_RESOURCE_SERIAL_TYPE_SPI?
And analogously for I2C?

That might work too.

> I know the Linux ACPI core doesn't parse _CRS today, but it should.
> The only reason we get away with the core ignoring _CRS is because the
> BIOS sets up most ACPI devices and we never change them.  If we change
> any resource assignments, we have to know where all the other devices
> are so we can avoid conflicts.

Well, point taken.

> > +               break;
> > +       }
> > +
> > +       return AE_OK;
> > +}
> > +
> > +static acpi_status acpi_spi_add_device(struct acpi_device *adev, void *data)
> > +{
> > +       struct acpi_spi_device_info info;
> > +       struct spi_master *master = data;
> > +       struct spi_device *spi;
> > +       acpi_status status;
> > +
> > +       spi = spi_alloc_device(master);
> > +       if (!spi) {
> > +               dev_err(&master->dev, "failed to allocate SPI device\n");
> > +               return AE_ERROR;
> > +       }
> > +
> > +       memset(&info, 0, sizeof(info));
> > +       info.spi = spi;
> > +       info.gsi = -1;
> > +
> > +       status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
> > +                                    acpi_spi_add_resources, &info);
> > +       if (ACPI_FAILURE(status) || !info.valid)
> > +               goto fail_put_dev;
> > +
> > +       strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
> > +       if (info.gsi >= 0)
> > +               spi->irq = acpi_register_gsi(&adev->dev, info.gsi,
> > +                                            info.triggering, info.polarity);
> > +       request_module(spi->modalias);
> > +       if (spi_add_device(spi)) {
> > +               dev_err(&master->dev, "failed to add SPI device from ACPI\n");
> > +               goto fail_unregister_gsi;
> > +       }
> > +
> > +       return AE_OK;
> > +
> > + fail_unregister_gsi:
> > +       if (info.gsi >= 0)
> > +               acpi_unregister_gsi(info.gsi);
> > + fail_put_dev:
> > +       spi_dev_put(spi);
> > +
> > +       return AE_OK;
> > +}
> > +
> > +static void acpi_register_spi_devices(struct spi_master *master)
> > +{
> > +       acpi_status status;
> > +       acpi_handle handle;
> > +
> > +       handle = master->dev.acpi_handle;
> > +       if (!handle)
> > +               return;
> > +
> > +       status = acpi_spi_enumerate(handle, acpi_spi_add_device, master);
> 
> How does this work with hot-plug?  acpi_spi_enumerate() walks a
> portion of the namespace.  How do we deal with changes to that part of
> the namespace?  For example, what happens if this part of the
> namespace gets pruned because an enclosing device is removed?  Is
> there a way to discover new SPI devices if they get added?

Yes, there should be a way to do that eventually.  No, we don't have any
removable SPI devices described by ACPI yet, as far as I know.  So even if
we added code for that now, we wouldn't be able to test it anyway with any
real hardware until such devices become available.  I have no idea when that's
going to happen, though.

> > +       if (ACPI_FAILURE(status))
> > +               dev_warn(&master->dev, "failed to enumerate SPI slaves\n");
> > +}
> > +
> > +struct acpi_spi_find {
> > +       acpi_handle handle;
> > +       u16 chip_select;
> > +       bool found;
> > +};
> > +
> > +static acpi_status acpi_spi_find_child_address(struct acpi_resource *res,
> > +                                              void *data)
> > +{
> > +       struct acpi_resource_spi_serialbus *sb;
> > +       struct acpi_spi_find *spi_find = data;
> > +
> > +       if (res->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
> > +               return AE_OK;
> > +
> > +       sb = &res->data.spi_serial_bus;
> > +       if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_SPI)
> > +               return AE_OK;
> > +
> > +       if (sb->device_selection == spi_find->chip_select) {
> > +               spi_find->found = true;
> > +               return AE_CTRL_TERMINATE;
> > +       }
> > +
> > +       return AE_OK;
> > +}
> > +
> > +static acpi_status acpi_spi_find_child(struct acpi_device *adev, void *data)
> > +{
> > +       struct acpi_spi_find *spi_find = data;
> > +       acpi_status status;
> > +
> > +       status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
> > +                                    acpi_spi_find_child_address, spi_find);
> > +       if (ACPI_FAILURE(status) || !spi_find->found)
> > +               return status;
> > +
> > +       spi_find->handle = adev->handle;
> > +       return AE_CTRL_TERMINATE;
> > +}
> > +
> > +static int acpi_spi_find_device(struct device *dev, acpi_handle *handle)
> > +{
> > +       struct spi_device *spi = to_spi_device(dev);
> > +       struct spi_master *master = spi->master;
> > +       struct acpi_spi_find spi_find;
> > +       acpi_handle parent;
> > +       acpi_status status;
> > +
> > +       parent = master->dev.acpi_handle;
> > +       if (!parent)
> > +               return -ENODEV;
> > +
> > +       memset(&spi_find, 0, sizeof(spi_find));
> > +       spi_find.chip_select = spi->chip_select;
> > +
> > +       status = acpi_spi_enumerate(parent, acpi_spi_find_child, &spi_find);
> > +       if (ACPI_FAILURE(status) || !spi_find.handle)
> > +               return -ENODEV;
> > +
> > +       *handle = spi_find.handle;
> > +       return 0;
> > +}
> > +
> > +static struct acpi_bus_type acpi_spi_bus = {
> > +       .bus = &spi_bus_type,
> > +       .find_device = acpi_spi_find_device,
> > +};
> > +
> > +static void acpi_spi_bus_register(void)
> > +{
> > +       register_acpi_bus_type(&acpi_spi_bus);
> > +}
> > +#else
> > +static inline void acpi_register_spi_devices(struct spi_master *master) {}
> > +static inline void acpi_spi_bus_register(void) {}
> > +#endif /* CONFIG_ACPI */
> > +
> >  static void spi_master_release(struct device *dev)
> >  {
> >         struct spi_master *master;
> > @@ -1023,8 +1249,9 @@ int spi_register_master(struct spi_master *master)
> >                 spi_match_master_to_boardinfo(master, &bi->board_info);
> >         mutex_unlock(&board_lock);
> >
> > -       /* Register devices from the device tree */
> > +       /* Register devices from the device tree and ACPI */
> >         of_register_spi_devices(master);
> > +       acpi_register_spi_devices(master);
> >  done:
> >         return status;
> >  }
> > @@ -1550,6 +1777,8 @@ static int __init spi_init(void)
> >         status = class_register(&spi_master_class);
> >         if (status < 0)
> >                 goto err2;
> > +
> > +       acpi_spi_bus_register();
> >         return 0;
> >
> >  err2:
> > --

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  parent reply	other threads:[~2012-11-03 20:35 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-03  7:46 [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Mika Westerberg
2012-11-03  7:46 ` [PATCH 1/3] gpio / ACPI: add ACPI support Mika Westerberg
2012-11-05 11:53   ` Linus Walleij
2012-11-05 12:14     ` Mathias Nyman
2012-11-05 12:46       ` Rafael J. Wysocki
2012-11-05 13:11         ` Linus Walleij
2012-11-05 13:19           ` Rafael J. Wysocki
2012-11-05 13:28             ` Linus Walleij
2012-11-05 13:50               ` Rafael J. Wysocki
2012-11-05 14:40                 ` Linus Walleij
2012-11-06  9:39                   ` Mika Westerberg
2012-11-06 10:15                     ` Linus Walleij
2012-11-07  8:54                       ` Mika Westerberg
2012-11-08 15:55   ` Grant Likely
2012-11-08 19:38     ` Mika Westerberg
2012-11-09 14:11       ` Mathias Nyman
2012-11-09 14:18         ` Grant Likely
2012-11-09 15:05           ` Mathias Nyman
2012-11-09 15:46             ` Grant Likely
2012-11-11  9:50               ` Mika Westerberg
2012-11-03  7:46 ` [PATCH 2/3] spi / ACPI: add ACPI enumeration support Mika Westerberg
2012-11-03 19:42   ` Bjorn Helgaas
2012-11-03 20:13     ` Mika Westerberg
2012-11-03 20:59       ` Rafael J. Wysocki
2012-11-05 10:31         ` Rafael J. Wysocki
2012-11-05 10:56           ` Mika Westerberg
2012-11-05 10:56             ` Mark Brown
2012-11-05 12:02               ` Mika Westerberg
2012-11-05 12:23                 ` Jean Delvare
2012-11-05 12:59                   ` Rafael J. Wysocki
2012-11-05 13:15                     ` Mika Westerberg
2012-11-05 13:20                       ` Linus Walleij
2012-11-05 13:43                         ` Mika Westerberg
2012-11-05 14:03                         ` Jean Delvare
2012-11-05 14:19                           ` Rafael J. Wysocki
2012-11-05 14:53                             ` Mika Westerberg
2012-11-05 15:19                               ` Jean Delvare
2012-11-05 17:12                                 ` Mika Westerberg
2012-11-05 17:43                                   ` Bjorn Helgaas
2012-11-05 18:08                                     ` Mika Westerberg
2012-11-05 17:49                                   ` Jean Delvare
2012-11-05 20:42                           ` Linus Walleij
2012-11-06  8:11                 ` Mark Brown
2012-11-05 16:54           ` Bjorn Helgaas
2012-11-06 13:43             ` Rafael J. Wysocki
2012-11-06 20:35               ` Bjorn Helgaas
2012-11-06 22:28                 ` Rafael J. Wysocki
2012-11-06 22:36                   ` Rafael J. Wysocki
2012-11-07  9:58                     ` Mika Westerberg
2012-11-07 11:14                       ` Rafael J. Wysocki
2012-11-07 13:05                         ` Mika Westerberg
2012-11-08  0:46                           ` Rafael J. Wysocki
2012-11-08 20:20                             ` Mika Westerberg
2012-11-08 20:54                               ` Rafael J. Wysocki
2012-11-08 18:05                       ` Grant Likely
2012-11-08 21:06                         ` Rafael J. Wysocki
2012-11-08 21:34                           ` Grant Likely
2012-11-05 10:54       ` Mark Brown
2012-11-03 20:39     ` Rafael J. Wysocki [this message]
2012-11-05 16:54       ` Bjorn Helgaas
2012-11-06 13:16         ` Rafael J. Wysocki
2012-11-06 20:53           ` Bjorn Helgaas
2012-11-06 22:18             ` Rafael J. Wysocki
2012-11-07  9:56               ` Mika Westerberg
2012-11-08 19:32                 ` Bjorn Helgaas
2012-11-08 20:04                   ` Mika Westerberg
2012-11-09 15:11                     ` Bjorn Helgaas
2012-11-09 15:45                       ` Grant Likely
2012-11-09 16:35                         ` Bjorn Helgaas
2012-11-09 16:43                           ` Grant Likely
2012-11-09 16:48                             ` Mark Brown
2012-11-09 16:53                             ` Bjorn Helgaas
2012-11-10 11:10                               ` Rafael J. Wysocki
2012-11-10 11:16                                 ` Grant Likely
2012-11-10 17:14                                 ` Bjorn Helgaas
2012-11-10 19:40                                   ` Rafael J. Wysocki
2012-11-05 10:54   ` Mark Brown
2012-11-05 11:03     ` Mika Westerberg
2012-11-05 11:13       ` Mark Brown
2012-11-08 18:48   ` Grant Likely
2012-11-09  3:50     ` Mika Westerberg
2012-11-03  7:46 ` [PATCH 3/3] i2c " Mika Westerberg
2012-11-03 21:52   ` Jean Delvare
2012-11-04  7:23     ` Mika Westerberg
2012-11-04  8:50       ` Jean Delvare
2012-11-04 10:50         ` Mika Westerberg
2012-11-08 18:58   ` Grant Likely
2012-11-09  3:51     ` Mika Westerberg
2012-11-04 18:29 ` [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Linus Walleij
2012-11-05  9:23   ` Mika Westerberg
2012-11-12 11:51 ` [PATCH 0/3] Centralized parsing of ACPI device resources (was: Re: [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C) Rafael J. Wysocki
2012-11-12 12:00   ` [PATCH 1/3] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-12 13:27     ` Mika Westerberg
2012-11-12 20:25       ` [Update][PATCH " Rafael J. Wysocki
2012-11-12 12:01   ` [PATCH 2/3] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-12 12:02   ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Rafael J. Wysocki
2012-11-12 14:46     ` Mika Westerberg
2012-11-12 21:03       ` Rafael J. Wysocki
2012-11-13  7:12         ` Mika Westerberg
2012-11-13 12:06           ` [Replacement][PATCH 3/3] Rafael J. Wysocki
2012-11-13 14:16             ` Mika Westerberg
2012-11-13 15:15               ` Rafael J. Wysocki
2012-11-13 15:18                 ` Mika Westerberg
2012-11-13 15:28                   ` Rafael J. Wysocki
2012-11-13 15:37                     ` Mika Westerberg
2012-11-13 16:34           ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Moore, Robert
2012-11-13 20:44             ` Rafael J. Wysocki
2012-11-13 22:06               ` Moore, Robert
2012-11-13 22:56                 ` Rafael J. Wysocki
2012-11-14  2:23                   ` Moore, Robert
2012-11-14  9:18                     ` Rafael J. Wysocki
2012-11-14  9:32                       ` Rafael J. Wysocki
2012-11-14 14:20                         ` Moore, Robert
2012-11-13 20:51   ` [PATCH 0/3 rev 2] Centralized parsing of ACPI device resources Rafael J. Wysocki
2012-11-13 20:55     ` [PATCH 1/3 rev 2] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-13 20:55     ` [PATCH 2/3 rev 2] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-13 20:56     ` [PATCH 3/3 rev 2] ACPI: Centralized processing of ACPI device resources Rafael J. Wysocki
2012-11-14  9:52     ` [PATCH 0/3 rev 2] Centralized parsing " Mika Westerberg
2012-11-14 10:08       ` Rafael J. Wysocki

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=1792336.CIafglX82A@vostro.rjw.lan \
    --to=rjw@sisk.pl \
    --cc=ben-linux@fluff.org \
    --cc=bhelgaas@google.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=grant.likely@secretlab.ca \
    --cc=khali@linux-fr.org \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=w.sang@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®