a different resource depending on the device that is passed.
But there is no similar get_gpio() function for GPIOs which number is directly
specified in the resource, and I don't know if such a function would make
sense otherwise. Opinions on the subject are welcome.
Alexandre Courbot (3
interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../devicetree/bindings/power/power_seq.txt| 121 +++
Documentation/power/power_seq.txt | 253
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../bindings/video/backlight/pwm-backlight.txt | 72 -
drivers/video/backlight/Kconfig
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index bec8bb2
Hi Grant, Stephen,
On Tue, Apr 16, 2013 at 2:45 AM, Grant Likely grant.lik...@secretlab.ca wrote:
Grant, if this is ok with you, how shall we have this integrated into your
branch? Half of this has been tested in my -next branch, and the present
patches
make the next half, should I resend
Hi Chen,
Cool, thanks! Can you send a formatted patch to include in the series,
or do you prefer me to squash it in the relevant patch and add your
signoff for this file?
Alex.
2013/4/6 Chen Baozi baoz...@gmail.com:
On Fri, Mar 29, 2013 at 06:11:15AM -0700, Alexandre Courbot wrote:
Another
file changed, 4 insertions(+), 4 deletions(-)
Acked-by: Alexandre Courbot acour...@nvidia.com
Integrated into my series, thanks. With this I guess I can send the
whole series again to Grant for him to integrate in his branch. It's
time if we want it to make it for 3.10.
Alex.
diff --git
not update the Chinese documentation in a satisfying
manner due to my absence of Chinese skills. Hope that will be forgiven.
Alexandre Courbot (3):
Convert selectors of GENERIC_GPIO to GPIOLIB
Remove GENERIC_GPIO config option
Rename CONFIG_GPIOLIB to CONFIG_GPIO
Documentation/gpio.txt
GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on
GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/unicore32/Kconfig | 2 +-
drivers/extcon/Kconfig | 2
GENERIC_GPIO has been made equivalent to GPIOLIB in architecture code
and all driver code has been switch to depend on GPIOLIB. It is thus
safe to have GENERIC_GPIO removed.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/gpio.txt | 10 +-
arch/alpha/Kconfig
On Thu, Mar 14, 2013 at 3:01 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Wed, Mar 13, 2013 at 8:53 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, Mar 13, 2013 at 1:12 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot
On Thu, Mar 14, 2013 at 11:14 PM, Linus Walleij
linus.wall...@linaro.org wrote:
For submitting the pull request to Torvalds in the end you will need
to create a signed tag. Do you have a signed GPG key? Else it's
about time to create a key and start collecting signatures... then you
can also
and
platform code.
If you have any good reason to not see these changes applied, please let me
know shortly - acks are welcome too.
Thanks,
Alex.
Alexandre Courbot (3):
mips: pnx833x: remove requirement for GENERIC_GPIO
m68k: coldfire: use gpiolib
blackfin: force use of gpiolib
arch/blackfin
pnx833x does not seem to use the generic gpio API.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
arch/mips/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips
Set the GENERIC_GPIO option to false by default and force the use of
gpiolib instead of making it optional, to prepare for the removal of
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Linus Walleij linus.wall...@linaro.org
Force use of gpiolib for Coldfire, as a step towards the deprecation of
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
arch/m68k/Kconfig.cpu | 3 +--
1 file changed, 1 insertion(+), 2
On Thu, Mar 21, 2013 at 9:09 AM, Grant Likely grant.lik...@secretlab.ca wrote:
- My branch is based on the latest stable, similarly to what I have
seen elsewhere. One of the patches triggers a merge conflict on
today's linux-next due to a whitespace change. Is there something I
can do to fix
Remove the selection of GENERIC_GPIO for S3C24XX and S5PC100 in
preparation of the removal of this option.
ARCH_REQUIRE_GPIOLIB (which also selects GENERIC_GPIO) is already
selected whenever these machines are chosen anyway, so this
patch should not have any side-effect.
Signed-off-by: Alexandre
The GPIO driver uses gpiolib, thus it should be compiled when
CONFIG_GPIOLIB is defined and not only CONFIG_GENERIC_GPIO
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/plat-orion/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b7b7228..ae70ab1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1199,7 +1199,6 @@ config CPU_LOONGSON2F
The GPIO driver uses gpiolib, thus it should be compiled when
CONFIG_GPIOLIB is defined and not only CONFIG_GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/loongson/common/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips
PUV3_GPIO depends on ARCH_PUV3 which requires GPIOLIB and thus already
selects GENERIC_GPIO
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/unicore32/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index dc50b15..a889117
GENERIC_GPIO was explicitly selected along with ARCH_REQUIRE_GPIOLIB,
which itself selects GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/powerpc/platforms/40x/Kconfig | 1 -
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/85xx/Kconfig | 1 -
arch
Require gpiolib instead of just GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ae70ab1..5cfa818 100644
--- a/arch/mips/Kconfig
+++ b/arch
pnx833x does not seem to use the generic gpio API.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5cfa818..c1c6549 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
This will help removing the GENERIC_GPIO option.
GPIO access is done through gpiolib, which selects GENERIC_GPIO anyway.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/avr32/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/avr32/Kconfig b/arch
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/blackfin/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 600494c..b947e26 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -56,7 +56,7
This is one step towards the removal of the GENERIC_GPIO option.
OpenRISC mandates the use of GPIOLIB, which enables GENERIC_GPIO anyway,
so this patch should be a no-op.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/openrisc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1
GPIO implementation for unicore32 uses gpiolib, which sets GENERIC_GPIO
when selected.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/unicore32/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index a889117
The Xtensa GPIO driver uses gpiolib and cannot compile with only
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/xtensa/configs/iss_defconfig | 1 -
arch/xtensa/configs/s6105_defconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/xtensa/configs
-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/sh/boards/mach-sdk7786/Makefile | 2 +-
arch/sh/boards/mach-x3proto/Makefile | 2 +-
arch/sh/kernel/cpu/sh2a/Makefile | 2 +-
arch/sh/kernel/cpu/sh3/Makefile | 2 +-
arch/sh/kernel/cpu/sh4a/Makefile | 2 +-
5 files changed, 5
The GPIO driver for txx9 requires gpiolib, so this is more accurate and
let us get rid of one mention of GENERIC_GPIO which is due to disappear.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/txx9/generic/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Force use of gpiolib for Coldfire, as a step towards the deprecation of
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/m68k/Kconfig.cpu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index b1cfff8
with it and that nothing gets broken, as the effect of
changing configuration options are sometimes difficult to predict.
Alexandre Courbot (17):
arm: remove unneeded select GENERIC_GPIO
arm: remove redundant GENERIC_GPIO selection
arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB
mips: remove redundant
GENERIC_GPIO was selected next to ARCH_REQUIRE_GPIOLIB, which itself
selects GENERIC_GPIO.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/mips/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 32eb3d6..b7b7228 100644
On Tue, Mar 12, 2013 at 8:18 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 12 March 2013, Alexandre Courbot wrote:
@@ -24,7 +24,7 @@ config UNICORE32
Please see web page at http://www.pkunity.com/.
config GENERIC_GPIO
- def_bool y
+ def_bool n
def_bool n
On Tue, Mar 12, 2013 at 8:23 PM, Arnd Bergmann a...@arndb.de wrote:
Nice series,
Acked-by: Arnd Bergmann a...@arndb.de
Thanks!
For most platforms, this change should be a no-op. However I would like to
make
sure that everyone is ok with it and that nothing gets broken, as the effect
of
On Sat, Feb 9, 2013 at 6:37 PM, Grant Likely grant.lik...@secretlab.ca wrote:
However, this code is incorrect (it was incorrect before you touched it,
so not your fault). Moving it to a list makes it a lot worse though
because it introduces the possibility of dereferencing an invalid
pointer.
On Sat, Feb 9, 2013 at 10:11 PM, Grant Likely grant.lik...@secretlab.ca wrote:
I've been thinking about the adding of a new API to supplant the old,
and I'm wondering if we're going about this the wrong way around; at
least for the public api. We've moved to a model where device drivers
are
On Sat, Feb 9, 2013 at 10:24 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot acour...@nvidia.com
wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace
On Sat, Feb 9, 2013 at 6:58 PM, Grant Likely grant.lik...@secretlab.ca wrote:
I'm actually going to NAK this one. This is a hot path. Having a O(1)
lookup from gpio number to gpio desc is important. I know you want to be
rid of the gpio_desc table entirely, but in this case I think it is
From: Alexandre Courbot acour...@nvidia.com
Fix all compilation errors and warnings triggered by my latest series of
patch on Grant's linux-next branch. Please meld this patch into the culprit
one to avoid ending with a commit that breaks compilation in the git history.
Signed-off-by: Alexandre
On Mon, Feb 11, 2013 at 8:31 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot acour...@nvidia.com wrote:
Just wondering: if we manage to change this spinlock into a mutex in the
future, wouldn't it be better to acquire it only once in
From: Alexandre Courbot acour...@nvidia.com
This comment applies to gpio_to_chip(), not gpiod_to_chip().
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio
From: Alexandre Courbot acour...@nvidia.com
Their value being obtained by gpio_chip_hwgpio(), this better reflects
their use.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 70 +-
1 file changed, 35 insertions
Delivered-To: gnu...@gmail.com
Received: by 10.64.96.232 with SMTP id dv8csp15271ieb;
Sun, 10 Feb 2013 05:48:07 -0800 (PST)
X-Received: by 10.68.0.39 with SMTP id 7mr11102539pbb.124.1360504086445;
Sun, 10 Feb 2013 05:48:06 -0800 (PST)
Return-Path: acour...@nvidia.com
Received: from
they were intended to become a new revision, but I leave that decision to
Grant's discretion.
This patchset has been thoroughly tested on Tegra 2/Ventana with a GPIO
backlight driver and the sysfs interface.
Alexandre Courbot (4):
gpiolib: check descriptors validity before use
gpiolib: use const
From: Alexandre Courbot acour...@nvidia.com
Some functions dereferenced their GPIO descriptor argument without
checking its validity first, potentially leading to an oops when given
an invalid argument.
This patch also makes gpio_get_value() more resilient when given an
invalid GPIO, returning 0
From: Alexandre Courbot acour...@nvidia.com
Constify descriptor parameter of gpiod_* functions for those that
should obviously not modify it. This includes value or direction get,
cansleep, and IRQ number query.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c
Add missing braces in an if..else condition.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e27877a..e14eb88 100644
--- a/drivers/gpio
On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot acour...@nvidia.com wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares
videomode patches and the CDF v2.
Alexandre Courbot (4):
video: panel: add CLAA101WA01A panel support
tegra: ventana: add display and backlight DT nodes
drm: tegra: use the Common Display Framework
tegra: enable CDF and claa101 panel
.../bindings/gpu/nvidia,tegra20-host1x.txt
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index adc4754
Make the tegra-drm driver use the Common Display Framework, letting it
control the panel state according to the DPMS status.
A nvidia,panel property is added to the output node of the Tegra DC
that references the panel connected to a given output.
Signed-off-by: Alexandre Courbot acour
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/configs/tegra_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index a7827fd..6da0de2 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm
Add support for the Chunghwa CLAA101WA01A display panel.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../video/display/chunghwa,claa101wa01a.txt| 8 +
drivers/video/display/Kconfig | 8 +
drivers/video/display/Makefile | 1
According to include/linux/backlight.h, the fb_blank field is to be
removed and blank status should preferably be set by setting the
BL_CORE_FBBLANK bit of the state field. This patch ensures this
condition is also taken into account when updating the backlight state.
Signed-off-by: Alexandre
On Thu, Jan 31, 2013 at 5:27 AM, Stephen Warren swar...@wwwdotorg.org wrote:
So this looks like a reasonable binding to me. The one issue is that
it's very generic, and if we go this route, we'll probably end up with
tens or hundreds of identical or extremely similar simple bindings, and
On Thu, Jan 31, 2013 at 12:51 PM, Mark Zhang nvmarkzh...@gmail.com wrote:
DDC access is a property of the display controller, not the panel
itself. The panel might be hooked up to a display controller's DDC/I2C
channel as the target, but it isn't the host/controller of the DDC/I2C
channel. As
On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang nvmarkzh...@gmail.com wrote:
Display controller don't know whether the panel has EDID EEPROM but the
panel driver knows. So why we need to make display controller queries
EDID blindly? Since panel driver knows about all video modes/panel
size stuffs,
to
use it. And without any user in the kernel, there should be no reason to keep
this function.
If Dmitri could give his Acked-by or Tested-by and one of the GPIO maintainers
merge this series, I could go ahead with the deeper changes to gpiolib.
Thanks,
Alexandre Courbot (2):
arm: pxa: tosa: do
GPIO address space reservation during early platform initialization is
not needed anymore for Tosa. Remove the calls to gpiochip_reserve()
which is due to be removed.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/mach-pxa/tosa.c | 6 --
1 file changed, 6 deletions
gpiochip_reserve() has no user and stands in the way of the removal of
the static gpio_desc[] array. Remove this function as well as the now
unneeded RESERVED flag of struct gpio_desc.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 58
had the expected value. Being a
rather deep change, it should certainly undergo some more testing.
Alexandre Courbot (9):
gpiolib: link all gpio_chips using a list
gpiolib: use gpio_chips list in gpiolib_sysfs_init
gpiolib: use gpio_chips list in gpiochip_find
gpiolib: use gpio_chips list
Re-implement gpiochip_find_base using the list of chips instead of the
global gpio_desc[] array. This makes it both simpler and more efficient,
and is needed to remove the global descriptors array.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 37
Allocate the GPIO descriptor's memory dynamically when GPIO chips are
added instead of using the static gpio_desc[] array. gpio_desc[] is now
totally unused and therefore removed.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 16
1 file
not
affect such use cases.
The descriptor-based GPIO API, due to be introduced soon, will make this
lookup unnecessary.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio
Add a pointer to the gpio_chip structure that references the array of
GPIO descriptors belonging to the chip, and update gpiolib code to use
this pointer instead of the global gpio_desc[] array. This is another
step towards the removal of the gpio_desc[] global array.
Signed-off-by: Alexandre
had the expected value. Being a
rather deep change, it should certainly undergo some more testing.
Alexandre Courbot (9):
gpiolib: link all gpio_chips using a list
gpiolib: use gpio_chips list in gpiolib_sysfs_init
gpiolib: use gpio_chips list in gpiochip_find
gpiolib: use gpio_chips list
to eventually get rid of the global gpio_desc[] array.
The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 51
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
introduction of the descriptor-based GPIO API.
Signed-off-by: Alexandre Courbot acour
This makes the code both simpler and faster compared to parsing the GPIO
number space.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 37 ++---
1 file changed, 10 insertions(+), 27 deletions(-)
diff --git a/drivers/gpio
Using the GPIO chips list is much faster than parsing the entire GPIO
number space.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio
Use the small list of GPIO chips instead of parsing the whole GPIO
number space.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index
On Wed, Feb 27, 2013 at 2:53 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, 22 Feb 2013 11:19:44 +0900, Alexandre Courbot gnu...@gmail.com
wrote:
Grant, will you be able to include these for 3.9? They fix code that
you merged recently, so I'd be glad if they could be squashed
On Wed, Feb 27, 2013 at 4:52 PM, Grant Likely grant.lik...@secretlab.ca wrote:
While you're working on that, I'd like you to keep the following in
mind. I'm getting concerned with the level of overhead that the gpio
access routines are incuring. They're doing a lot of checks right now
when
On Sun, Jan 20, 2013 at 12:38 PM, Mark Zhang ma...@nvidia.com wrote:
So this is a non power sequence version of backlight panel enabling,
isn't it? I remember we talked about this several days ago and you
mentioned kernel guys want an ad-hoc version(power sequence logics
inside driver, not in
welcome - in any case,
I hope to make this converge into something mergeable quickly.
Note that these patches are the last missing block to get a functional
panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
on Ventana is usable out-of-the-box. Yay.
Alexandre Courbot (3):
pwm
a subdriver mechanism to the pwm-backlight
driver that allows such hooks to be defined in optionally-compiled
sub-drivers. Every subdriver has its own device tree properties, which
sets the correct hooks to the pwm-backlight driver.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers
Add the host1x device and DDC i2c bus to enable internal panel on
Ventana.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch
Add a PWM-backlight subdriver for Tegra boards, with support for
Ventana.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 18 +++-
arch/arm/configs/tegra_defconfig | 1 +
drivers/video/backlight/Kconfig| 7 ++
drivers/video
On Thu, Feb 14, 2013 at 7:49 AM, Ryan Mallon rmal...@gmail.com wrote:
Is it really useful to use the same pr_debug for the error case? Why not do:
desc = gpio_to_desc(gpio);
if (!desc) {
pr_debug(%s - Invalid gpio %d\n, __func__, gpio);
return
On Thu, Feb 14, 2013 at 7:54 AM, Ryan Mallon rmal...@gmail.com wrote:
Nitpicky - Is it accurate to call these hardware numbers? Don't some of
the platforms remap the gpio numbers? These numbers may not match
against the platform's datasheet for example.
I'm following a suggestion by Grant and
to avoid meaningless error messages and ugly ternary operators
- use pr_warn instead of pr_debug to signal invalid GPIOs
- do descriptors validity check before acquiring any lock
Alexandre Courbot (4):
gpiolib: check descriptors validity before use
gpiolib: use const parameters when possible
gpiolib
-by: Alexandre Courbot acour...@nvidia.com
Cc: Ryan Mallon rmal...@gmail.com
---
drivers/gpio/gpiolib.c | 112 -
1 file changed, 65 insertions(+), 47 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index fff9786..1a8a7a8 100644
Constify descriptor parameter of gpiod_* functions for those that
should obviously not modify it. This includes value or direction get,
cansleep, and IRQ number query.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 29 -
1 file
Their value being obtained by gpio_chip_hwgpio(), this better reflects
their use.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 70 +-
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpio
This comment applies to gpio_to_chip(), not gpiod_to_chip().
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a33bfc2..c2534d6 100644
Grant, will you be able to include these for 3.9? They fix code that
you merged recently, so I'd be glad if they could be squashed into the
patch mentioned in the description.
Thanks,
Alex.
On Fri, Feb 15, 2013 at 2:46 PM, Alexandre Courbot acour...@nvidia.com wrote:
This short series
if no platform
data is present, making it possible to remove the explicit DT parsing function
* Lots of fixes in the documentation which should be clearer now (thanks
Stephen!)
Alexandre Courbot (4):
Runtime Interpreted Power Sequences
pwm_backlight: use power sequences
tegra: dt: add label
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../bindings/video/backlight/pwm-backlight.txt | 65 +++-
drivers/video/backlight/Kconfig
interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../devicetree/bindings/power_seq/power_seq.txt| 122 ++
Documentation/power/power_seq.txt | 215
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index 3e5952f
This is necessary to reference the PWM in board device trees.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 405d167
:
- Move to driver to base/
- Use sub-nodes to describe steps in the DT as suggested by Simon Glass
- Write some documentation
- Make the DT support optional
Alexandre Courbot (3):
runtime interpreted power sequences
pwm_backlight: use power sequences
tegra: add pwm backlight device tree
interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/power/power_seq.txt | 120 +++
drivers/base/Kconfig | 4 +
drivers/base/Makefile
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/boot/dts/tegra20-ventana.dts | 53 +++
arch/arm/boot/dts/tegra20.dtsi| 2 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm
Make use of the power sequences specified in the device tree or platform
data, if any.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../bindings/video/backlight/pwm-backlight.txt | 55 +-
drivers/video/backlight/Kconfig| 1 +
drivers/video/backlight
resources types.
Alexandre Courbot (4):
Runtime Interpreted Power Sequences
pwm_backlight: use power sequences
tegra: dt: add label to tegra20's PWM
tegra: ventana: add pwm backlight DT nodes
.../devicetree/bindings/power_seq/power_seq.txt| 117 ++
.../bindings/video/backlight/pwm
interpreter that can execute such power sequences
encoded either as platform data or within the device tree.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
.../devicetree/bindings/power_seq/power_seq.txt| 117 ++
Documentation/power/power_seq.txt | 225
1 - 100 of 3008 matches
Mail list logo
