On Fri, Apr 12, 2013 at 12:35:05AM +0200, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
> wrote:
>
> > Grant and Linus W,
> >
> > Do you have any comments on this patch? Could it still be merged for 3.10?
>
> No and yes.
>
> Applied and pushed for linux-next now.
On Fri, Apr 12, 2013 at 12:35:05AM +0200, Linus Walleij wrote:
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Grant and Linus W,
Do you have any comments on this patch? Could it still be merged for 3.10?
No and yes.
Applied and pushed for
On Friday, April 12, 2013 12:33:55 AM Linus Walleij wrote:
> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> wrote:
>
> > Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> > a helper function analogous to Device Tree version that allows drivers to
> > specify which
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
wrote:
> Grant and Linus W,
>
> Do you have any comments on this patch? Could it still be merged for 3.10?
No and yes.
Applied and pushed for linux-next now.
Sorry for taking so long, I was confused by the discussion.
I had to use some fuzzing
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
wrote:
> Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> a helper function analogous to Device Tree version that allows drivers to
> specify which GPIO resource they are interested (using an index to the GPIO
>
On Wed, Apr 03, 2013 at 01:04:26PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg wrote:
> > Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> > a helper function analogous to Device Tree version that allows drivers to
> >
On Wed, Apr 03, 2013 at 01:04:26PM +0200, Rafael J. Wysocki wrote:
On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify which GPIO resource they are interested (using
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Grant and Linus W,
Do you have any comments on this patch? Could it still be merged for 3.10?
No and yes.
Applied and pushed for linux-next now.
Sorry for taking so long, I was confused by the
On Friday, April 12, 2013 12:33:55 AM Linus Walleij wrote:
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows
On Thu, Apr 04, 2013 at 12:01:23PM +0200, Benjamin Tissoires wrote:
> > One option is to provide acpi_get_gpio_all() that returns all GPIOs and
> > their corresponding types. That should allow clients like i2c-hid to find
> > the right GPIO (I'm hoping that there will be only one GpioInt
On Thu, Apr 4, 2013 at 11:57 AM, Mika Westerberg
wrote:
> On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
>> On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
>> wrote:
>> > On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
>> >> Hi Mika,
>> >>
>> >> On Wed,
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
> On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
> wrote:
> > On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
> >> Hi Mika,
> >>
> >> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> >> wrote:
> >> >
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
wrote:
> On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
>> Hi Mika,
>>
>> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
>> wrote:
>> > Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
>> > a
On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
> Hi Mika,
>
> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> wrote:
> > Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> > a helper function analogous to Device Tree version that allows drivers
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
wrote:
> Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> a helper function analogous to Device Tree version that allows drivers to
> specify which GPIO resource they are interested (using an index to the GPIO
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify which GPIO resource they are interested
On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Instead of open-coding ACPI GPIO
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
On Thu, Apr 4, 2013 at 11:57 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Thu, Apr 04, 2013 at 11:19:53AM +0200,
On Thu, Apr 04, 2013 at 12:01:23PM +0200, Benjamin Tissoires wrote:
One option is to provide acpi_get_gpio_all() that returns all GPIOs and
their corresponding types. That should allow clients like i2c-hid to find
the right GPIO (I'm hoping that there will be only one GpioInt associated
On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg wrote:
> Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> a helper function analogous to Device Tree version that allows drivers to
> specify which GPIO resource they are interested (using an index to the GPIO
>
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify which GPIO resource they are interested (using an index to the GPIO
resources). The function then finds out the correct resource, translates
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify which GPIO resource they are interested (using an index to the GPIO
resources). The function then finds out the correct resource, translates
On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg wrote:
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
a helper function analogous to Device Tree version that allows drivers to
specify which GPIO resource they are interested (using an index to the GPIO
26 matches
Mail list logo
