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 ha
+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 wind
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 best
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 kern
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
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
> > G
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,
> > > >
> > > > T
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 -0600
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 05:42:07PM
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
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
> > > > > > > > binar
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, 2
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 modul
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 = "fo
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 appr
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
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 t
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 11
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:
>> >
>> > d
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
> > b/drivers
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
> --- a/drivers/p
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, 201
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 se
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 se
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'r
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
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+
> Signed-off-by:
36 matches
Mail list logo
