All of lore.kernel.org
 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: 127+ 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 16:34             ` Moore, Robert
2012-11-13 20:44             ` Rafael J. Wysocki
2012-11-13 20:44               ` Rafael J. Wysocki
2012-11-13 22:06               ` Moore, Robert
2012-11-13 22:06                 ` Moore, Robert
2012-11-13 22:56                 ` Rafael J. Wysocki
2012-11-13 22:56                   ` Rafael J. Wysocki
2012-11-14  2:23                   ` Moore, Robert
2012-11-14  2:23                     ` Moore, Robert
2012-11-14  9:18                     ` Rafael J. Wysocki
2012-11-14  9:18                       ` Rafael J. Wysocki
2012-11-14  9:32                       ` Rafael J. Wysocki
2012-11-14  9:32                         ` Rafael J. Wysocki
2012-11-14 14:20                         ` Moore, Robert
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.