On Thu, Oct 23, 2014 at 2:25 PM, Arnd Bergmann wrote:
> On Thursday 23 October 2014 15:02:46 Alexandre Courbot wrote:
>> On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann wrote:
>> > On Tuesday 21 October 2014 14:14:02 Alexandre Courbot wrote:
>
>> > Drivers that use
>> > existing bindings with the
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
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 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
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 Fri, Oct 24, 2014 at 6:51 AM, Rafael J. Wysocki wrote:
> 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
On Fri, Oct 24, 2014 at 6:51 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
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
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 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
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 23 October 2014 15:02:46 Alexandre Courbot wrote:
> On Tue, Oct 21, 2014 at 4:54 PM, Arnd Bergmann 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 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);
> >
On Wed, Oct 22, 2014 at 11:07 PM, Rafael J. Wysocki 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 2014
On Tue, Oct 21, 2014 at 4:54 PM, 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
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 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
>
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 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
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
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
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
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
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 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 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
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 Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann wrote:
> On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
>> On Sat, Oct 18, 2014 at 6:47 PM, 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.
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,
40 matches
Mail list logo
