On Saturday, November 10, 2012 10:14:47 AM Bjorn Helgaas wrote:
> On Sat, Nov 10, 2012 at 4:10 AM, Rafael J. Wysocki wrote:
> > On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote:
> >> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely
> >> wrote:
> >> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn
On Sat, Nov 10, 2012 at 4:10 AM, Rafael J. Wysocki wrote:
> On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote:
>> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely
>> wrote:
>> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote:
>> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely
>> >
On Sat, Nov 10, 2012 at 11:10 AM, Rafael J. Wysocki wrote:
> On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote:
>> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely
>> wrote:
>> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote:
>> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely
>>
On Friday, November 09, 2012 09:53:26 AM Bjorn Helgaas wrote:
> On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely
> wrote:
> > On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote:
> >> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely
> >> wrote:
> >>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrot
On Fri, Nov 9, 2012 at 9:43 AM, Grant Likely wrote:
> On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote:
>> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely
>> wrote:
>>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrote:
[+cc Greg, Peter, Tony since they acked the original patch [1]]
>>>
On Fri, Nov 09, 2012 at 04:43:27PM +, Grant Likely wrote:
> In the short term, yes but only because we don't have any other
> alternative. What I'd really rather have is a safe way to attach datum
> (ie. acpi_device or device_node) to a struct device and get it back
> later in a type safe way.
On Fri, Nov 9, 2012 at 4:35 PM, Bjorn Helgaas wrote:
> On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely
> wrote:
>> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrote:
>>> [+cc Greg, Peter, Tony since they acked the original patch [1]]
>>>
>>> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg
>>> w
On Fri, Nov 9, 2012 at 8:45 AM, Grant Likely wrote:
> On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrote:
>> [+cc Greg, Peter, Tony since they acked the original patch [1]]
>>
>> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg
>> wrote:
>>> On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaa
On Fri, Nov 9, 2012 at 3:11 PM, Bjorn Helgaas wrote:
> [+cc Greg, Peter, Tony since they acked the original patch [1]]
>
> On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg
> wrote:
>> On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote:
>>> Struct device_driver is a generic structure, so
[+cc Greg, Peter, Tony since they acked the original patch [1]]
On Thu, Nov 8, 2012 at 1:04 PM, Mika Westerberg
wrote:
> On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote:
>> Struct device_driver is a generic structure, so it seems strange to
>> have to include non-generic things like
On Thu, Nov 08, 2012 at 06:48:05PM +, Grant Likely wrote:
> On Sat, Nov 3, 2012 at 7:46 AM, Mika Westerberg
> 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 t
On Thu, Nov 8, 2012 at 9:06 PM, Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 06:05:23 PM Grant Likely wrote:
>> On Wed, Nov 7, 2012 at 9:58 AM, Mika Westerberg
>> wrote:
>> > On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote:
>> >> >
>> >> > OK, but then we need to pa
On Thursday, November 08, 2012 06:05:23 PM Grant Likely wrote:
> On Wed, Nov 7, 2012 at 9:58 AM, Mika Westerberg
> wrote:
> > On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote:
> >> >
> >> > OK, but then we need to pass the information obtained from _CRS
> >> > (presumably after so
On Thursday, November 08, 2012 10:20:42 PM Mika Westerberg wrote:
> On Thu, Nov 08, 2012 at 01:46:24AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 07, 2012 03:05:48 PM Mika Westerberg wrote:
> > > On Wed, Nov 07, 2012 at 12:14:31PM +0100, Rafael J. Wysocki wrote:
> > > > > So is the
On Thu, Nov 08, 2012 at 01:46:24AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 07, 2012 03:05:48 PM Mika Westerberg wrote:
> > On Wed, Nov 07, 2012 at 12:14:31PM +0100, Rafael J. Wysocki wrote:
> > > > So is the idea now that the ACPI core parses the resources and passes
> > > > them
On Thu, Nov 08, 2012 at 12:32:25PM -0700, Bjorn Helgaas wrote:
> Struct device_driver is a generic structure, so it seems strange to
> have to include non-generic things like of_device_id and now
> acpi_match_table there.
Yes, but in a sense the DT and ACPI are "generic". So that they are used to
On Wed, Nov 7, 2012 at 2:56 AM, Mika Westerberg
wrote:
> On Tue, Nov 06, 2012 at 11:18:11PM +0100, Rafael J. Wysocki wrote:
>> > 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
On Sat, Nov 3, 2012 at 7:46 AM, Mika Westerberg
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
On Wed, Nov 7, 2012 at 9:58 AM, Mika Westerberg
wrote:
> On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote:
>> >
>> > OK, but then we need to pass the information obtained from _CRS
>> > (presumably after some adjustments through _SRS) to drivers, or rather to
>> > things like the
On Wednesday, November 07, 2012 03:05:48 PM Mika Westerberg wrote:
> On Wed, Nov 07, 2012 at 12:14:31PM +0100, Rafael J. Wysocki wrote:
> > > So is the idea now that the ACPI core parses the resources and passes them
> > > forward via struct acpi_device? I'm just wondering how to proceed with
> > >
On Wed, Nov 07, 2012 at 12:14:31PM +0100, Rafael J. Wysocki wrote:
> > So is the idea now that the ACPI core parses the resources and passes them
> > forward via struct acpi_device? I'm just wondering how to proceed with
> > these I2C and SPI enumeration patches.
>
> Well, we definitely don't want
On Wednesday, November 07, 2012 11:58:42 AM Mika Westerberg wrote:
> On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote:
> > >
> > > OK, but then we need to pass the information obtained from _CRS
> > > (presumably after some adjustments through _SRS) to drivers, or rather to
> > >
On Tue, Nov 06, 2012 at 11:36:08PM +0100, Rafael J. Wysocki wrote:
> >
> > OK, but then we need to pass the information obtained from _CRS
> > (presumably after some adjustments through _SRS) to drivers, or rather to
> > things like the SPI core, I2C core etc. so that they can create device
> > ob
On Tue, Nov 06, 2012 at 11:18:11PM +0100, Rafael J. Wysocki wrote:
> > 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
On Tuesday, November 06, 2012 11:28:37 PM Rafael J. Wysocki wrote:
> On Tuesday, November 06, 2012 01:35:56 PM Bjorn Helgaas wrote:
> > On Tue, Nov 6, 2012 at 6:43 AM, Rafael J. Wysocki wrote:
> > > On Monday, November 05, 2012 09:54:42 AM Bjorn Helgaas wrote:
> > >> On Mon, Nov 5, 2012 at 3:31 AM
On Tuesday, November 06, 2012 01:35:56 PM Bjorn Helgaas wrote:
> On Tue, Nov 6, 2012 at 6:43 AM, Rafael J. Wysocki wrote:
> > On Monday, November 05, 2012 09:54:42 AM Bjorn Helgaas wrote:
> >> On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki wrote:
> >> > On Saturday, November 03, 2012 09:59:28
On Tuesday, November 06, 2012 01:53:01 PM Bjorn Helgaas wrote:
> On Tue, Nov 6, 2012 at 6:16 AM, Rafael J. Wysocki 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 wrote:
> >> > On Saturday, November 03, 2012 01:42:02
On Tue, Nov 6, 2012 at 6:16 AM, Rafael J. Wysocki 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 wrote:
>> > On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
>> >> On Sat, Nov 3, 2012 at 1:46 AM, Mika West
On Tue, Nov 6, 2012 at 6:43 AM, Rafael J. Wysocki wrote:
> On Monday, November 05, 2012 09:54:42 AM Bjorn Helgaas wrote:
>> On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki wrote:
>> > On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
>> >> On Saturday, November 03, 2012 10:13:
On Monday, November 05, 2012 09:54:42 AM Bjorn Helgaas wrote:
> On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki wrote:
> > On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
> >> On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
> >> > On Sat, Nov 03, 2012 at 01:
On Monday, November 05, 2012 09:54:37 AM Bjorn Helgaas wrote:
> On Sat, Nov 3, 2012 at 2:39 PM, Rafael J. Wysocki wrote:
> > On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
> >> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> >> wrote:
> >> > ACPI 5 introduced SPISerialBus resou
On Mon, Nov 05, 2012 at 02:02:19PM +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
> > I've got practical systems where there are multiple buses physically
> > connected, though in practice almost always only one is actually used at
> > runtime when it's
On Mon, Nov 5, 2012 at 3:03 PM, Jean Delvare wrote:
(...)
>> If the addresses are consecutive like ours it makes sense
>> to just instantiate one device and have the driver know that it will
>> also be able to access address +1, +2 ... +n. So is it possible
>> to group the consecutive related addr
On Mon, Nov 05, 2012 at 10:43:17AM -0700, Bjorn Helgaas wrote:
> > It should already be unique in case of ACPI. We use ACPI _HID and _UID to
> > achieve that.
>
> Using only _HID and _UID to guarantee uniqueness means you're relying
> on a property of the BIOS, so you're vulnerable to BIOS bugs.
>
On Mon, 5 Nov 2012 19:12:48 +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
> > I2C core fears that you're mixing up everything ;) I2C adapter devices
> > are struct i2c_adapter aka i2c-0, i2c-1 etc. i2c_client is for slave
> > devices. There's nothing
On Mon, Nov 5, 2012 at 10:12 AM, Mika Westerberg
wrote:
> On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
>> On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
>> > On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
>> > >
>> > > In the ACPI namespace we have d
On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
> On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
> > On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
> > >
> > > In the ACPI namespace we have device nodes and serial interfaces below
> > > them.
> > > In
On Sat, Nov 3, 2012 at 2:39 PM, Rafael J. Wysocki wrote:
> On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
>> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
>> wrote:
>> > ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
>> > configure the SPI slave devices
On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki wrote:
> On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
>> On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
>> > On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
>> > > On Sat, Nov 3, 2012 at 1:46
On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
> >
> > In the ACPI namespace we have device nodes and serial interfaces below them.
> > In the above case we see that a single device node supports two different
> > inte
On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
>
> In the ACPI namespace we have device nodes and serial interfaces below them.
> In the above case we see that a single device node supports two different
> interfaces and in that case we probably should create two different
> st
On Monday, November 05, 2012 03:03:26 PM Jean Delvare wrote:
> Hi Linus,
>
> On Mon, 5 Nov 2012 14:20:52 +0100, Linus Walleij wrote:
> > On Mon, Nov 5, 2012 at 2:15 PM, Mika Westerberg
> > wrote:
> > > On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
> > >> On Monday, November 0
Hi Linus,
On Mon, 5 Nov 2012 14:20:52 +0100, Linus Walleij wrote:
> On Mon, Nov 5, 2012 at 2:15 PM, Mika Westerberg
> wrote:
> > On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
> >> On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
> >> > On Mon, 5 Nov 2012 14:02:19
On Mon, Nov 05, 2012 at 02:20:52PM +0100, Linus Walleij wrote:
> >
> > It looks like some PMICs for example have two I2C control interfaces, like
> > TI's TWL6030 if I'm not mistaken. If both are put behind the same I2C
> > controller with different address, you have the situation like above.
>
>
On Mon, Nov 5, 2012 at 2:15 PM, Mika Westerberg
wrote:
> On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
>> On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
>> > On Mon, 5 Nov 2012 14:02:19 +0200, Mika Westerberg wrote:
>> > > On Mon, Nov 05, 2012 at 11:56:39AM +0100
On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
> > On Mon, 5 Nov 2012 14:02:19 +0200, Mika Westerberg wrote:
> > > On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
> > > > I've got practical systems where
On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
> On Mon, 5 Nov 2012 14:02:19 +0200, Mika Westerberg wrote:
> > On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
> > > I've got practical systems where there are multiple buses physically
> > > connected, though in practice alm
On Mon, 5 Nov 2012 14:02:19 +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
> > I've got practical systems where there are multiple buses physically
> > connected, though in practice almost always only one is actually used at
> > runtime when it's I2C and
On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
> On Mon, Nov 05, 2012 at 12:56:02PM +0200, Mika Westerberg wrote:
>
> > > struct acpi_device {
> > > ...
> > > union acpi_resource_serial_bus *serial;
> > > ...
> > > };
>
> > It is also possible to have several serial bus connect
On Mon, Nov 05, 2012 at 01:03:22PM +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 11:54:55AM +0100, Mark Brown wrote:
> > On Sat, Nov 03, 2012 at 09:46:32AM +0200, Mika Westerberg wrote:
> > > + strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
> > > + if (info.gsi >=
On Mon, Nov 05, 2012 at 11:54:55AM +0100, Mark Brown wrote:
> On Sat, Nov 03, 2012 at 09:46:32AM +0200, Mika Westerberg wrote:
>
> > + strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
> > + if (info.gsi >= 0)
> > + spi->irq = acpi_register_gsi(&adev->dev, info.gs
On Mon, Nov 05, 2012 at 12:56:02PM +0200, Mika Westerberg wrote:
> > struct acpi_device {
> > ...
> > union acpi_resource_serial_bus *serial;
> > ...
> > };
> It is also possible to have several serial bus connectors on a single
> device (although we've seen only one connector per dev
On Sat, Nov 03, 2012 at 09:46:32AM +0200, Mika Westerberg wrote:
> + 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,
On Sat, Nov 03, 2012 at 10:13:10PM +0200, Mika Westerberg wrote:
> On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
> > > + case ACPI_RESOURCE_TYPE_IRQ:
> > > + info->gsi = res->data.irq.interrupts[0];
> > > + info->triggering = res->data.irq.trigger
On Mon, Nov 05, 2012 at 11:31:19AM +0100, Rafael J. Wysocki wrote:
> The general idea is to move the _CRS parsing routine from acpi_platform.c
> to scan.c and make it attach resource objects to struct acpi_device.
>
> I'm thinking about adding a list head to struct acpi_device pointing to a
> list
On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
> On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
> > On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
> > > On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> > > wrote:
> > > > ACPI 5 introduced SP
On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
> On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
> > On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> > wrote:
> > > ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
> > > configure the SPI sl
On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> 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
On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
> On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
> 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
On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
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
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 fo
61 matches
Mail list logo