On Thu, Oct 23, 2014 at 2:25 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 23 October 2014 15:02:46 Alexandre Courbot wrote:
On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
Drivers that use
existing
On Sat, Oct 25, 2014 at 12:00:33AM +0200, Rafael J. Wysocki wrote:
I folded your fixes into my patch and I'm going to send the result, with a
changelog, in a reply to this message.
Thanks!
If everyone is happy with it, I'll add it to the device properties patch
series as it depends on those.
On Thu, Oct 23, 2014 at 11:51:59PM +0200, Rafael J. Wysocki wrote:
OK, let's try to take that a bit farther. :-)
With the (untested) patch below applied (which is a replacement for the one
sent previously), the driver can use static tables like these:
static struct acpi_gpio_params
On Friday, October 24, 2014 10:34:36 AM Mika Westerberg wrote:
On Thu, Oct 23, 2014 at 11:51:59PM +0200, Rafael J. Wysocki wrote:
OK, let's try to take that a bit farther. :-)
With the (untested) patch below applied (which is a replacement for the one
sent previously), the driver can use
On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
We have enforced naming things for the dmaengine binding, which has
just led to everyone calling things rx and tx. My fear is that
if we start to enforce giving
On Wed, Oct 22, 2014 at 11:07 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, October 22, 2014 11:28:40 AM Arnd Bergmann wrote:
On Wednesday 22 October 2014 11:51:40 Mika Westerberg wrote:
On Wed, Oct 22, 2014 at 10:33:32AM +0200, Arnd Bergmann wrote:
On Wednesday 22 October
On Thursday 23 October 2014 15:10:55 Alexandre Courbot wrote:
Then, the driver needs to do something like:
if (!device_property_present(dev,
known_property_that_should_be_present)
ACPI_COMPANION(dev))
acpi_probe_gpios(dev);
and in the
On Thursday 23 October 2014 15:02:46 Alexandre Courbot wrote:
On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
Drivers that use
existing bindings with the foo-gpio form (or worse, foo-somethingelse
can use
On Thu, Oct 23, 2014 at 01:21:06AM +0200, Rafael J. Wysocki wrote:
OK, would the below make sense, then (completely untested, on top of the v6
of the device properties patchset)?
Yes it does :-)
With the the below fix it works nicely with the modified rfkill-gpio.c
driver.
+static bool
On Thursday, October 23, 2014 03:56:55 PM Mika Westerberg wrote:
On Thu, Oct 23, 2014 at 01:21:06AM +0200, Rafael J. Wysocki wrote:
OK, would the below make sense, then (completely untested, on top of the v6
of the device properties patchset)?
Yes it does :-)
With the the below fix it
On Tue, Oct 21, 2014 at 09:54:45AM +0200, Arnd Bergmann wrote:
On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
We have enforced naming things for the dmaengine binding, which has
just led to everyone calling things rx and tx. My fear is that
if we start to enforce giving
On Wednesday 22 October 2014 11:10:44 Mika Westerberg wrote:
It expects that GPIOs returned from _CRS are in specific order. Since we
can't change these existing ACPI tables, we must support them somehow.
This patch series handles it so that:
1) If we can't find given property (e.g
On Wed, Oct 22, 2014 at 10:33:32AM +0200, Arnd Bergmann wrote:
On Wednesday 22 October 2014 11:10:44 Mika Westerberg wrote:
It expects that GPIOs returned from _CRS are in specific order. Since we
can't change these existing ACPI tables, we must support them somehow.
This patch series
On Wednesday 22 October 2014 11:51:40 Mika Westerberg wrote:
On Wed, Oct 22, 2014 at 10:33:32AM +0200, Arnd Bergmann wrote:
On Wednesday 22 October 2014 11:10:44 Mika Westerberg wrote:
It expects that GPIOs returned from _CRS are in specific order. Since we
can't change these existing
On Wednesday, October 22, 2014 11:28:40 AM Arnd Bergmann wrote:
On Wednesday 22 October 2014 11:51:40 Mika Westerberg wrote:
On Wed, Oct 22, 2014 at 10:33:32AM +0200, Arnd Bergmann wrote:
On Wednesday 22 October 2014 11:10:44 Mika Westerberg wrote:
It expects that GPIOs returned
On Wed, Oct 22, 2014 at 04:07:08PM +0200, Rafael J. Wysocki wrote:
Moreover, we need to clarify what situation we're really talking about.
For one, drivers using the unified interface only will always use names for
GPIOs, because they have to assume that either a DT or ACPI w/ _DSD is
On Wednesday, October 22, 2014 05:56:51 PM Mika Westerberg wrote:
On Wed, Oct 22, 2014 at 04:07:08PM +0200, Rafael J. Wysocki wrote:
Moreover, we need to clarify what situation we're really talking about.
For one, drivers using the unified interface only will always use names for
GPIOs,
On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
We have enforced naming things for the dmaengine binding, which has
just led to everyone calling things rx and tx. My fear is that
if we start to enforce giving a name, we'd end up with lots of
drivers that use a gpio-gpios
On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki
r...@rjwysocki.net wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
Some drivers need to deal with
On Monday 20 October 2014 01:58:57 Rafael J. Wysocki wrote:
Actually, since the two last patches in the series, which currently are
the only users of these new functions, both pass gpios as the property
name and 0 as the index, I can simplify the functions so that (a)
fwnode_get_gpiod()
On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki
r...@rjwysocki.net wrote:
From: Mika Westerberg
On Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
On October 17, 2014 2:16:00 PM CEST,
On Saturday, October 18, 2014 11:47:41 AM Arnd Bergmann wrote:
On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki
r...@rjwysocki.net wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
Some drivers need to deal with
On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki r...@rjwysocki.net
wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a
From: Mika Westerberg mika.westerb...@linux.intel.com
Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a separate firmware node in device tree. Typically these
child nodes do not have
On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki r...@rjwysocki.net
wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
Some drivers need to deal with only firmware representation of its
GPIOs. An example would be a GPIO button array driver where each button
is described as a
26 matches
Mail list logo
