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
On Wed, Feb 25, 2015 at 7:25 PM, David Cohen
david.a.co...@linux.intel.com 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
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
On Wed, Feb 25, 2015 at 10:34:45AM +0900, Alexandre Courbot wrote:
On Wed, Feb 25, 2015 at 5:34 AM, David Cohen
david.a.co...@linux.intel.com 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
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
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
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 Wed, Feb 25, 2015 at 5:34 AM, David Cohen
david.a.co...@linux.intel.com 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
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,
On Tue, Feb 10, 2015 at 06:44:34PM +0900, Alexandre Courbot wrote:
On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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 r...@rjwysocki.net
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
heikki.kroge...@linux.intel.com wrote:
Hi guys,
On Thu, Jan 22, 2015 at 05:14:22PM +0100, Rafael J.
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
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 Tuesday, February 10, 2015 06:32:46 PM Alexandre Courbot wrote:
On Fri, Jan 23, 2015 at 8:21 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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
On Fri, Jan 23, 2015 at 8:21 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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
On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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 r...@rjwysocki.net
wrote:
On Friday, January 30, 2015 03:48:30 PM Linus Walleij 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 checksum of the binary or something.
> >>
> >> And then you'd
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
On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki r...@rjwysocki.net 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
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 r...@rjwysocki.net 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
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
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 Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote:
On Thu, Jan 22, 2015 at 5:12 PM, Rafael J. Wysocki r...@rjwysocki.net 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
On Thu, Jan 22, 2015 at 5:12 PM, Rafael J. Wysocki r...@rjwysocki.net 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
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 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.
Can
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
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
> >
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
problem
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, January
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
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
> >
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
On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki r...@rjwysocki.net 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
On Thursday, January 22, 2015 11:57:55 AM Alexandre Courbot wrote:
On Wed, Jan 21, 2015 at 6:25 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot gnu...@gmail.com
wrote:
I am
On Thursday, January 22, 2015 09:17:38 AM Linus Walleij wrote:
On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki r...@rjwysocki.net
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
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 Wed, Jan 21, 2015 at 6:25 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot gnu...@gmail.com wrote:
I am not really fond of this idea since it adds complexity to the
(already
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
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 6:59 AM, Alexandre Courbot gnu...@gmail.com 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
On Tuesday, January 20, 2015 01:16:06 PM Linus Walleij wrote:
On Mon, Jan 19, 2015 at 6:59 AM, Alexandre Courbot gnu...@gmail.com 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
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 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).
Also
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 Wed, Jan 14, 2015 at 9:58 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
This makes it possible to assign GPIOs at runtime. The
motivation for it is because of need to forward GPIOs from
one device
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
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
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 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
heikki.kroge...@linux.intel.com wrote:
This makes it
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 be
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
heikki.kroge...@linux.intel.com wrote:
This makes it possible to assign GPIOs at runtime. The
motivation for it is because of need
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
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
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
>
On 1/14/15 4:58 AM, Linus Walleij wrote:
On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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
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
heikki.kroge...@linux.intel.com wrote:
This makes it possible to assign GPIOs at runtime. The
motivation for it is because of need to forward GPIOs from
one
On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus
heikki.kroge...@linux.intel.com 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
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
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
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
64 matches
Mail list logo
