On Wed, Feb 25, 2015 at 7:25 PM, David Cohen
wrote:
> In my case [1] I need 2 "virtual devices" (and more in future) to be
> part of an USB OTG port control. I call it virtual because they are too
> simple components connected to no bus and controlled by GPIOs:
> - a fixed regulator controlled by
On Wed, Feb 25, 2015 at 10:34:45AM +0900, Alexandre Courbot wrote:
> On Wed, Feb 25, 2015 at 5:34 AM, David Cohen
> wrote:
> > Hi,
> >
> >> If we decide to go ahead with the solution proposed by this patch for
> >> practical reasons (which are good reasons indeed), I still have one
> >> problem wi
On Wed, Feb 25, 2015 at 5:34 AM, David Cohen
wrote:
> Hi,
>
>> If we decide to go ahead with the solution proposed by this patch for
>> practical reasons (which are good reasons indeed), I still have one
>> problem with its current form.
>>
>> As the discussion highlighted, this is an ACPI problem
Hi,
> If we decide to go ahead with the solution proposed by this patch for
> practical reasons (which are good reasons indeed), I still have one
> problem with its current form.
>
> As the discussion highlighted, this is an ACPI problem, so I'd very
> much like it to be confined to the ACPI GPIO
On Tue, Feb 10, 2015 at 04:10:04PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, February 10, 2015 06:32:46 PM Alexandre Courbot wrote:
> > On Fri, Jan 23, 2015 at 8:21 PM, Heikki Krogerus
> > wrote:
> > > Hi guys,
> > >
> > > On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J. Wysocki wrote:
> >
On Tue, Feb 10, 2015 at 06:44:34PM +0900, Alexandre Courbot wrote:
> On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus
> wrote:
> > On Wed, Feb 04, 2015 at 10:51:27AM +0100, Linus Walleij wrote:
> >> On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki
> >> wrote:
> >> > On Friday, January 30, 2015
On Tuesday, February 10, 2015 06:32:46 PM Alexandre Courbot wrote:
> On Fri, Jan 23, 2015 at 8:21 PM, Heikki Krogerus
> wrote:
> > Hi guys,
> >
> > On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J. Wysocki wrote:
> >> On Thursday, January 22, 2015 11:57:55 AM Alexandre Courbot wrote:
> >> > If w
On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus
wrote:
> On Wed, Feb 04, 2015 at 10:51:27AM +0100, Linus Walleij wrote:
>> On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki
>> wrote:
>> > On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
>>
>> >> So you could detect one by making a
On Fri, Jan 23, 2015 at 8:21 PM, Heikki Krogerus
wrote:
> Hi guys,
>
> On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J. Wysocki wrote:
>> On Thursday, January 22, 2015 11:57:55 AM Alexandre Courbot wrote:
>> > If we decide to go ahead with the solution proposed by this patch for
>> > practical
On Wed, Feb 04, 2015 at 10:51:27AM +0100, Linus Walleij wrote:
> On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki wrote:
> > On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
>
> >> So you could detect one by making a checksum of the binary or something.
> >>
> >> And then you'd know
On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki wrote:
> On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
>> So you could detect one by making a checksum of the binary or something.
>>
>> And then you'd know that the table with this checksum needs patching?
>
> At a single table le
On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
> On Thu, Jan 22, 2015 at 5:12 PM, Rafael J. Wysocki wrote:
> > On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:
>
> >> If the kernel anyway has to supply some kind of workaround for
> >> the issue, it is more a question o
On Thu, Jan 22, 2015 at 5:12 PM, Rafael J. Wysocki wrote:
> On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:
>> If the kernel anyway has to supply some kind of workaround for
>> the issue, it is more a question of where to place it. Whether it does
>> so by patching the ACPI tables
On Fri, Jan 23, 2015 at 04:14:13PM +0100, Rafael J. Wysocki wrote:
> > That actually makes me think that we could then drop the lookup tables
> > completely and use device properties instead with the help of "generic
> > property" (attached):
>
> Which reminds me that I've lost track of this one.
On Friday, January 23, 2015 01:21:22 PM Heikki Krogerus wrote:
>
> --Nq2Wo0NMKNjxTN9z
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
>
> Hi guys,
>
> On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J. Wysocki wrote:
> > On Thursday
Hi guys,
On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J. Wysocki wrote:
> On Thursday, January 22, 2015 11:57:55 AM Alexandre Courbot wrote:
> > If we decide to go ahead with the solution proposed by this patch for
> > practical reasons (which are good reasons indeed), I still have one
> > pro
On Thursday, January 22, 2015 11:57:55 AM Alexandre Courbot wrote:
> On Wed, Jan 21, 2015 at 6:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
> >> On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot
> >> wrote:
> >>
> >> > I am not really fond of
On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:
> On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki
> wrote:
>
> > Yes, it can (in principle). In fact, we have a plan to refine it, but it is
> > going to take some time. Once we've done that, we'll see how painful it is
> > to
On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki wrote:
> Yes, it can (in principle). In fact, we have a plan to refine it, but it is
> going to take some time. Once we've done that, we'll see how painful it is to
> "patch" ACPI tables this way in practice.
>
> Also there is an ecosystem pro
On Wed, Jan 21, 2015 at 6:25 AM, Rafael J. Wysocki wrote:
> On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
>> On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot wrote:
>>
>> > I am not really fond of this idea since it adds complexity to the
>> > (already too complex) GPIO lookup,
On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
> On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot wrote:
>
> > I am not really fond of this idea since it adds complexity to the
> > (already too complex) GPIO lookup, and only solves to a local level
> > (GPIO) what is a more globa
On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot wrote:
> I am not really fond of this idea since it adds complexity to the
> (already too complex) GPIO lookup, and only solves to a local level
> (GPIO) what is a more global problem (bad ACPI tables that can affect
> any subsystem).
(...)
> it
On Mon, Jan 19, 2015 at 02:59:54PM +0900, Alexandre Courbot wrote:
> I am not really fond of this idea since it adds complexity to the
> (already too complex) GPIO lookup, and only solves to a local level
> (GPIO) what is a more global problem (bad ACPI tables that can affect
> any subsystem).
>
>
On Wed, Jan 14, 2015 at 9:58 PM, Linus Walleij wrote:
> On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> wrote:
>
>> This makes it possible to assign GPIOs at runtime. The
>> motivation for it is because of need to forward GPIOs from
>> one device to an other. That feature may be useful for
>>
On Thu, Jan 15, 2015 at 10:28:03AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 14, 2015 08:32:12 AM Darren Hart wrote:
> >
> > On 1/14/15 4:58 AM, Linus Walleij wrote:
> > > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> > > wrote:
> > >
> > >> This makes it possible to assign GP
On Wednesday, January 14, 2015 08:32:12 AM Darren Hart wrote:
>
> On 1/14/15 4:58 AM, Linus Walleij wrote:
> > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> > wrote:
> >
> >> This makes it possible to assign GPIOs at runtime. The
> >> motivation for it is because of need to forward GPIOs fr
On Thursday, January 08, 2015 10:25:10 AM Heikki Krogerus wrote:
> On Thu, Dec 18, 2014 at 10:23:18AM +0200, Heikki Krogerus wrote:
> > This makes it possible to assign GPIOs at runtime. The
> > motivation for it is because of need to forward GPIOs from
> > one device to an other. That feature may
On 1/14/15 4:58 AM, Linus Walleij wrote:
> On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> wrote:
>
>> This makes it possible to assign GPIOs at runtime. The
>> motivation for it is because of need to forward GPIOs from
>> one device to an other. That feature may be useful for
>> example wit
Ugh, Samuel actually Cc'd this time...
On 1/14/15 4:58 AM, Linus Walleij wrote:
> On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
> wrote:
>
>> This makes it possible to assign GPIOs at runtime. The
>> motivation for it is because of need to forward GPIOs from
>> one device to an other. That fe
On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
wrote:
> This makes it possible to assign GPIOs at runtime. The
> motivation for it is because of need to forward GPIOs from
> one device to an other. That feature may be useful for
> example with some mfd devices, but initially it is needed
> beca
On Thu, Dec 18, 2014 at 10:23:18AM +0200, Heikki Krogerus wrote:
> This makes it possible to assign GPIOs at runtime. The
> motivation for it is because of need to forward GPIOs from
> one device to an other. That feature may be useful for
> example with some mfd devices, but initially it is needed
This makes it possible to assign GPIOs at runtime. The
motivation for it is because of need to forward GPIOs from
one device to an other. That feature may be useful for
example with some mfd devices, but initially it is needed
because on some Intel Braswell based ACPI platforms the GPIO
resources c
32 matches
Mail list logo
