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.
Than
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
> resourc
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
> > spec
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 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, A
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:
> >> > Inste
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 helper
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 t
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
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
> r
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
13 matches
Mail list logo
