On Friday, November 14, 2014 11:53:40 AM Mika Westerberg wrote:
> +Rafael
>
> On Fri, Nov 14, 2014 at 10:39:07AM +0100, Linus Walleij wrote:
> > On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
> > wrote:
> > > On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
> >
> > >> It looks we
+Rafael
On Fri, Nov 14, 2014 at 10:39:07AM +0100, Linus Walleij wrote:
> On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
> wrote:
> > On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
>
> >> It looks we have an implicit dependency to GPIO driver in Bay Trail, and
> >> having this
On Tue, Nov 4, 2014 at 10:51 PM, David Cohen
wrote:
> On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
>> to a list of devices we depend on, we can defer this particular driver
>> going further in probe until all the dependencies listed in _DEP are
>> resolved.
>
> That's the
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
wrote:
> On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
>> It looks we have an implicit dependency to GPIO driver in Bay Trail, and
>> having this window until load the module is not acceptable to fulfill
>> this implicit dependency.
On Mon, Nov 3, 2014 at 7:42 PM, Mika Westerberg
wrote:
> On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
>> that's an issue that needs solving, but forcing every x86 kernel to ship
>> with this driver, is not a proper solution.
>
> I would rather have the driver build in to the
On Mon, Nov 3, 2014 at 7:42 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
that's an issue that needs solving, but forcing every x86 kernel to ship
with this driver, is not a proper solution.
I would rather have the
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
It looks we have an implicit dependency to GPIO driver in Bay Trail, and
having this window until load the module is not acceptable to fulfill
On Tue, Nov 4, 2014 at 10:51 PM, David Cohen
david.a.co...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
to a list of devices we depend on, we can defer this particular driver
going further in probe until all the dependencies listed in _DEP are
+Rafael
On Fri, Nov 14, 2014 at 10:39:07AM +0100, Linus Walleij wrote:
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
It looks we have an implicit dependency to GPIO driver in Bay Trail,
On Friday, November 14, 2014 11:53:40 AM Mika Westerberg wrote:
+Rafael
On Fri, Nov 14, 2014 at 10:39:07AM +0100, Linus Walleij wrote:
On Tue, Nov 4, 2014 at 7:57 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
On Tue, Nov 04, 2014 at 01:51:53PM -0800, David Cohen wrote:
> On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
> > On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
> > > > It is not implicit at all.
> > > >
> > > > The user of the GPIO in ACPI DSDT table says
On Tue, Nov 04, 2014 at 01:51:53PM -0800, David Cohen wrote:
On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
It is not implicit at all.
The user of the GPIO in ACPI DSDT table says something like:
On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
> On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
> > > It is not implicit at all.
> > >
> > > The user of the GPIO in ACPI DSDT table says something like:
> > >
> > > Name (_DEP, Package () { \_SB.GPO2 })
> > >
> >
On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
> > It is not implicit at all.
> >
> > The user of the GPIO in ACPI DSDT table says something like:
> >
> > Name (_DEP, Package () { \_SB.GPO2 })
> >
> > or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
> >
On Tue, Nov 04, 2014 at 08:57:02PM +0200, Mika Westerberg wrote:
> On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
> > On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
> > > On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> > > > Hi Mika,
> > > >
> > > >
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
> On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> > > Hi Mika,
> > >
> > > Thanks for your feedbacks :)
> > >
> > > On Mon, Nov 03, 2014 at 08:42:47PM
On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
> On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> > Hi Mika,
> >
> > Thanks for your feedbacks :)
> >
> > On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > > On Mon, Nov 03, 2014 at 09:50:11AM
Hi,
On Tue, Nov 04, 2014 at 09:51:35AM +0200, Mika Westerberg wrote:
> > > > > > > > > > I think adding the module exit + allowing this driver to be
> > > > > > > > > > a module
> > > > > > > > > > would be a good approach. Then we don't need to force
> > > > > > > > > > generic x86 kernel
> >
On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> Hi Mika,
>
> Thanks for your feedbacks :)
>
> On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Nov 03, 2014 at
On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
Hi Mika,
Thanks for your feedbacks :)
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
Hi,
On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika
Hi,
On Tue, Nov 04, 2014 at 09:51:35AM +0200, Mika Westerberg wrote:
I think adding the module exit + allowing this driver to be
a module
would be a good approach. Then we don't need to force
generic x86 kernel
binaries to always have this
On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
Hi Mika,
Thanks for your feedbacks :)
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
Hi Mika,
Thanks for your feedbacks :)
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika
On Tue, Nov 04, 2014 at 08:57:02PM +0200, Mika Westerberg wrote:
On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
Hi Mika,
Thanks for your
On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
It is not implicit at all.
The user of the GPIO in ACPI DSDT table says something like:
Name (_DEP, Package () { \_SB.GPO2 })
or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
GPIO banks.
On Tue, Nov 04, 2014 at 09:34:24PM +0200, Mika Westerberg wrote:
On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
It is not implicit at all.
The user of the GPIO in ACPI DSDT table says something like:
Name (_DEP, Package () { \_SB.GPO2 })
or similar. That is
On Mon, Nov 03, 2014 at 02:40:38PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > > > > > > > > I think adding the module exit + allowing this driver to be a
> > > > > > > > > module
> > > > > > > > > would be a good approach. Then we
Hi Mika,
Thanks for your feedbacks :)
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
> > > On Mon, Nov 03, 2014 at 05:27:43PM +0200,
Hi,
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > > > > > > > I think adding the module exit + allowing this driver to be a
> > > > > > > > module
> > > > > > > > would be a good approach. Then we don't need to force generic
> > > > > > > > x86 kernel
> > > > > > > >
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> > > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > > > On Mon, Nov 03,
Hi,
On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
> On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > > > On Fri, Oct 31,
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > > > I think adding the
Hi,
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > > > I think adding the
On Fri, Oct 31, 2014 at 2:20 PM, Felipe Balbi wrote:
> [Me]
>> But another way to get rid of the dilemma is to set
>> .suppress_bind_attrs = true on the .driver field of the
>> device driver. The one can't unbind it through sysfs anymore.
>>
>> .driver = {
>> .name =
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > > I think adding the module exit + allowing this driver to be a module
> > > > would be a good
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > I think adding the module exit + allowing this driver to be a module
> > > would be a good approach. Then we don't need to force generic x86 kernel
> > > binaries
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > I think adding the module exit + allowing this driver to be a module
> > would be a good approach. Then we don't need to force generic x86 kernel
> > binaries to always have this driver. Unless Mathias or Mika knows a
> > constraint
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
I think adding the module exit + allowing this driver to be a module
would be a good approach. Then we don't need to force generic x86 kernel
binaries to always have this driver. Unless Mathias or Mika knows a
constraint to force
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
I think adding the module exit + allowing this driver to be a module
would be a good approach. Then we don't need to force generic x86 kernel
binaries to always
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
I think adding the module exit + allowing this driver to be a module
would be a good approach. Then
On Fri, Oct 31, 2014 at 2:20 PM, Felipe Balbi ba...@ti.com wrote:
[Me]
But another way to get rid of the dilemma is to set
.suppress_bind_attrs = true on the .driver field of the
device driver. The one can't unbind it through sysfs anymore.
.driver = {
.name =
Hi,
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
I think adding the module
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
I think adding the module exit +
Hi,
On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
On Fri, Oct 31, 2014 at
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
Hi,
On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
On Mon, Nov 03, 2014 at
Hi,
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
I think adding the module exit + allowing this driver to be a
module
would be a good approach. Then we don't need to force generic
x86 kernel
binaries to always have this driver. Unless
Hi Mika,
Thanks for your feedbacks :)
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
Hi,
On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika
On Mon, Nov 03, 2014 at 02:40:38PM -0600, Felipe Balbi wrote:
Hi,
On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
I think adding the module exit + allowing this driver to be a
module
would be a good approach. Then we don't need to force generic
On Fri, Oct 31, 2014 at 09:23:39AM -0700, David Cohen wrote:
> On Fri, Oct 31, 2014 at 08:20:05AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
> > > On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi wrote:
> > > > On Tue, Oct 28, 2014 at
On Fri, Oct 31, 2014 at 08:20:05AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
> > On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi wrote:
> > > On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
> > >> On Mon, Oct 13, 2014 at 9:36
Hi,
On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
> On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi wrote:
> > On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
> >> On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi wrote:
> >> > On Mon, Oct 13, 2014 at 02:26:32PM -0500,
On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi wrote:
> On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
>> On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi wrote:
>> > On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
>>
>> > I also noticed that this is missing:
>> >
>> >
On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
I also noticed that this is
Hi,
On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Oct 13, 2014 at
On Fri, Oct 31, 2014 at 08:20:05AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
On Mon, Oct 13, 2014 at 9:36
On Fri, Oct 31, 2014 at 09:23:39AM -0700, David Cohen wrote:
On Fri, Oct 31, 2014 at 08:20:05AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Oct 31, 2014 at 09:12:16AM +0100, Linus Walleij wrote:
On Tue, Oct 28, 2014 at 3:42 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Oct 28, 2014 at
On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
> On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi wrote:
> > On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
>
> > I also noticed that this is missing:
> >
> > diff --git a/drivers/pinctrl/pinctrl-baytrail.c
> >
On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi wrote:
> On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
> I also noticed that this is missing:
>
> diff --git a/drivers/pinctrl/pinctrl-baytrail.c
> b/drivers/pinctrl/pinctrl-baytrail.c
> index e12e5b0..7db5ab9 100644
> ---
On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
I also noticed that this is missing:
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index e12e5b0..7db5ab9 100644
---
On Tue, Oct 28, 2014 at 11:15:20AM +0100, Linus Walleij wrote:
On Mon, Oct 13, 2014 at 9:36 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
I also noticed that this is missing:
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
On Mon, Oct 13, 2014 at 02:36:18PM -0500, Felipe Balbi wrote:
> On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
> > > On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
> > > > On Mon, Oct 13,
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
> > On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
> > > On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
> > > > Even if a gpio pin is
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
> > On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
> > > On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
> > > > Even if a gpio pin is
Hi,
On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
> On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
> > On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
> > > Even if a gpio pin is set to output, we still need to set INPUT_EN bit
> >
> > here you say
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
> On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
> > Even if a gpio pin is set to output, we still need to set INPUT_EN bit
>
> here you say you're setting that bit.
>
> > to be able to read its value. Without this
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
> Even if a gpio pin is set to output, we still need to set INPUT_EN bit
here you say you're setting that bit.
> to be able to read its value. Without this change, we'll always read low
> level state.
>
> Cc: # v3.14+
>
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
to be able to read its value. Without this change, we'll always read low
level state.
Cc: # v3.14+
Signed-off-by: David Cohen
---
Hi,
I'm resending same v1 patch but now copying linux stable and linux gpio.
This patch is
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
to be able to read its value. Without this change, we'll always read low
level state.
Cc: sta...@vger.kernel.org # v3.14+
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
Hi,
I'm resending same v1 patch but now
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
here you say you're setting that bit.
to be able to read its value. Without this change, we'll always read low
level state.
Cc: sta...@vger.kernel.org #
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
here you say you're setting that bit.
to be able to read its value. Without this change, we'll
Hi,
On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
here you say you're setting
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
Hi,
On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
Even if a gpio pin is set to
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
Hi,
On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at 11:23:59AM -0700, David Cohen wrote:
Even if a gpio pin is set to
On Mon, Oct 13, 2014 at 02:36:18PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at 02:26:32PM -0500, Felipe Balbi wrote:
Hi,
On Mon, Oct 13, 2014 at 12:24:04PM -0700, David Cohen wrote:
On Mon, Oct 13, 2014 at 02:14:05PM -0500, Felipe Balbi wrote:
On Mon, Oct 13, 2014 at
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
to be able to read its value. Without this change, we'll always read low
level state.
Signed-off-by: David Cohen
---
drivers/pinctrl/pinctrl-baytrail.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Even if a gpio pin is set to output, we still need to set INPUT_EN bit
to be able to read its value. Without this change, we'll always read low
level state.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
drivers/pinctrl/pinctrl-baytrail.c | 2 +-
1 file changed, 1 insertion(+), 1
76 matches
Mail list logo
