On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better
Hi Jacek,
On Mon, Sep 7, 2015 at 3:03 PM, Jacek Anaszewski
wrote:
> On 09/01/2015 07:00 PM, Geert Uytterhoeven wrote:
>> I'm wondering if there already exists a driver for a gpio that's connected
>> to both an LED and an input switch.
>>
>> I'd expect such a hardware configuration to be fairly co
Hi Sascha,
Any comments about this version? Maybe you missed it since you answered
me on the RFC version. Of course I'll do the changes you requested for
the next version (remove gpio_request_*() stuff and add macros for gpio
muxing case).
Thanks
Ludovic
On Tue, Aug 11, 2015 at 10:28:00AM +0200
Hi Geert,
On 09/01/2015 07:00 PM, Geert Uytterhoeven wrote:
Hi,
I'm wondering if there already exists a driver for a gpio that's connected
to both an LED and an input switch.
I'd expect such a hardware configuration to be fairly common, as gpios can be
a limited resource.
Most of the time the
On 09/06/2015 12:15 AM, Linus Walleij wrote:
> Adding linux-gpio and some people that have been patching
> this driver to TO-line.
>
> Grygorii et al, does this look correct? Anyone who can test and
> send a patch for mainline?
>
> Yours,
> Linus Walleij
>
> On Mon, Aug 31, 2015 at 4:26 PM, Janu
When looking up a gpiochip through its firmware node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
When looking up a pin controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
Hello,
I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playin
When looking up a pin controller through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: T
+Cc: Austin, Philipp
On 08/26/2015 10:53 AM, Linus Walleij wrote:
On Tue, Aug 18, 2015 at 1:10 PM, Grygorii Strashko
wrote:
This patch series contains set of trivial fixes and improvements, and also
patches which fixes wrong APIs usage in atomic context as for -RT as for
non-RT kernel. The fi
On Wed, Aug 19, 2015 at 12:18:29PM +0200, Markus Pargmann wrote:
> This series adds a gpio-initval property to the devicetree. It provides a way
> to initialize GPIOs to a defined value.
This is actually a good thing to have. I know at least one SoC contains
a paragraph in its hardware spec:
Gen
On Wed, Aug 19, 2015 at 12:18:31PM +0200, Markus Pargmann wrote:
> From: Markus Pargmann
>
> The gpio name is now stored in the gpio descriptor, so we can simply use
What is now? Does this introduce a dependency; maybe better reference a
commit here?
> that instead of an argument to the functio
On Wed, Aug 19, 2015 at 12:18:30PM +0200, Markus Pargmann wrote:
> From: Markus Pargmann
>
> There is no reason to find out chip and hwnum to use to request a gpio
> and get another gpio descriptor. We already have the descriptor we want
> to use so we can directly use it.
>
> Signed-off-by: Mar
13 matches
Mail list logo
