On 05/08/2014 12:57 AM, Stephen Warren wrote:
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
Console rotation is needed for devices like Tegra Note 7 and NVIDIA
SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you
On 05/08/2014 12:57 AM, Stephen Warren wrote:
On 05/06/2014 09:18 PM, Alexandre Courbot wrote:
Console rotation is needed for devices like Tegra Note 7 and NVIDIA
SHIELD to get the boot console in the expected orientation.
I've squashed this into Tegra's for-3.16/defconfig branch.
Can you
On 12/11/2013 12:28 AM, Andy Shevchenko wrote:
On Tue, 2013-12-10 at 23:37 +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function they
On 12/11/2013 12:28 AM, Andy Shevchenko wrote:
On Tue, 2013-12-10 at 23:37 +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function they
On 12/09/2013 09:40 PM, Mika Westerberg wrote:
On Fri, Dec 06, 2013 at 11:06:56AM +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function
On 12/09/2013 07:28 PM, Andy Shevchenko wrote:
On Fri, 2013-12-06 at 11:06 +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function they
On 12/09/2013 06:32 PM, Andy Shevchenko wrote:
Remove old and currently wrong address of the FSF from license parts of the
code.
The address is not wrong, it is just that you don't want to see it
become wrong should it change in the future.
--
To unsubscribe from this list: send the line
On 12/09/2013 06:32 PM, Andy Shevchenko wrote:
Remove old and currently wrong address of the FSF from license parts of the
code.
The address is not wrong, it is just that you don't want to see it
become wrong should it change in the future.
--
To unsubscribe from this list: send the line
On 12/09/2013 07:28 PM, Andy Shevchenko wrote:
On Fri, 2013-12-06 at 11:06 +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function they
On 12/09/2013 09:40 PM, Mika Westerberg wrote:
On Fri, Dec 06, 2013 at 11:06:56AM +0900, Alexandre Courbot wrote:
Some devices drivers make use of optional GPIO parameters. For such
drivers, it is important to discriminate between the case where no
GPIO mapping has been defined for the function
On 12/03/2013 09:49 PM, Heikki Krogerus wrote:
This makes it possible to request the gpio descriptors in
rfkill_gpio driver regardless of the platform.
Signed-off-by: Heikki Krogerus
---
arch/arm/mach-tegra/board-paz00.c | 11 +++
1 file changed, 11 insertions(+)
Changes since v3:
On 12/03/2013 09:49 PM, Heikki Krogerus wrote:
This makes it possible to request the gpio descriptors in
rfkill_gpio driver regardless of the platform.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-tegra/board-paz00.c | 11 +++
1 file changed, 11
On 11/29/2013 12:54 AM, Andy Shevchenko wrote:
On Thu, Nov 28, 2013 at 10:46 AM, Alexandre Courbot wrote:
Change the format of the platform GPIO lookup tables to make them less
confusing and improve lookup efficiency.
The previous format was a single linked-list that required to compare
the
On 11/29/2013 08:57 PM, Heikki Krogerus wrote:
Hi,
On Thu, Nov 28, 2013 at 05:46:28PM +0900, Alexandre Courbot wrote:
@@ -88,16 +89,20 @@ Note that GPIO_LOOKUP() is just a shortcut to
GPIO_LOOKUP_IDX() where idx = 0.
A lookup table can then be defined as follows:
- struct
On 11/29/2013 08:57 PM, Heikki Krogerus wrote:
Hi,
On Thu, Nov 28, 2013 at 05:46:28PM +0900, Alexandre Courbot wrote:
@@ -88,16 +89,20 @@ Note that GPIO_LOOKUP() is just a shortcut to
GPIO_LOOKUP_IDX() where idx = 0.
A lookup table can then be defined as follows:
- struct
On 11/29/2013 12:54 AM, Andy Shevchenko wrote:
On Thu, Nov 28, 2013 at 10:46 AM, Alexandre Courbot acour...@nvidia.com wrote:
Change the format of the platform GPIO lookup tables to make them less
confusing and improve lookup efficiency.
The previous format was a single linked-list that
On 11/29/2013 06:29 PM, Linus Walleij wrote:
On Sat, Nov 23, 2013 at 11:34 AM, Alexandre Courbot wrote:
For platforms that use device tree or ACPI as the standard way to look
GPIOs up, allow the platform-defined GPIO mappings to be used as a
fallback. This may be useful for platforms that
On 11/29/2013 06:29 PM, Linus Walleij wrote:
On Sat, Nov 23, 2013 at 11:34 AM, Alexandre Courbot acour...@nvidia.com wrote:
For platforms that use device tree or ACPI as the standard way to look
GPIOs up, allow the platform-defined GPIO mappings to be used as a
fallback. This may be useful for
On 11/29/2013 04:47 AM, Dave Martin wrote:
On Thu, Nov 28, 2013 at 04:58:33PM +, Stephen Warren wrote:
On 11/27/2013 11:02 PM, Alexandre Courbot wrote:
On Wed, Nov 27, 2013 at 1:47 AM, Dave Martin wrote:
On Tue, Nov 26, 2013 at 10:35:58AM +0900, Alexandre Courbot wrote:
On Tue, Nov 26,
On 11/29/2013 04:47 AM, Dave Martin wrote:
On Thu, Nov 28, 2013 at 04:58:33PM +, Stephen Warren wrote:
On 11/27/2013 11:02 PM, Alexandre Courbot wrote:
On Wed, Nov 27, 2013 at 1:47 AM, Dave Martin dave.mar...@arm.com wrote:
On Tue, Nov 26, 2013 at 10:35:58AM +0900, Alexandre Courbot
On 11/26/2013 07:05 PM, Mika Westerberg wrote:
From: Heikki Krogerus
Convert to the safer gpiod_* family of API functions.
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 11/27/2013 05:33 AM, Stephen Warren wrote:
On 11/26/2013 03:05 AM, Mika Westerberg wrote:
From: Heikki Krogerus
This makes it possible to request the gpio descriptors in
rfkill_gpio driver regardless of the platform.
V2 of the series did the following:
static struct
On 11/27/2013 05:33 AM, Stephen Warren wrote:
On 11/26/2013 03:05 AM, Mika Westerberg wrote:
From: Heikki Krogerus heikki.kroge...@linux.intel.com
This makes it possible to request the gpio descriptors in
rfkill_gpio driver regardless of the platform.
V2 of the series did the following:
On 11/26/2013 07:05 PM, Mika Westerberg wrote:
From: Heikki Krogerus heikki.kroge...@linux.intel.com
Convert to the safer gpiod_* family of API functions.
Reviewed-by: Alexandre Courbot acour...@nvidia.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On 11/25/2013 06:28 PM, Mika Westerberg wrote:
On Mon, Nov 25, 2013 at 06:07:10PM +0900, Alexandre Courbot wrote:
On Mon, Nov 25, 2013 at 5:58 PM, Mika Westerberg
wrote:
On Sat, Nov 23, 2013 at 02:54:29PM +0900, Alexandre Courbot wrote:
Add missing declarations and include files to avoid
On 11/25/2013 06:02 PM, Heikki Krogerus wrote:
On Mon, Nov 25, 2013 at 05:47:38PM +0900, Alex Courbot wrote:
On 11/25/2013 05:41 PM, Heikki Krogerus wrote:
Adding the lookup table in first patch and then changing the driver in
the second creates a point to the history where this driver stops
On 11/25/2013 05:54 PM, Mika Westerberg wrote:
On Sat, Nov 23, 2013 at 06:21:03PM +0900, Alexandre Courbot wrote:
On Fri, Nov 22, 2013 at 9:14 PM, Mika Westerberg
wrote:
Now that all users of acpi_gpio.h have been moved to user either the GPIO
s/user/use
OK.
descriptor interface or to
On 11/25/2013 05:41 PM, Heikki Krogerus wrote:
On Sat, Nov 23, 2013 at 05:59:30PM +0900, Alexandre Courbot wrote:
Wouldn't it be possible (and simpler) to move patch 2 of your series
to first position, and then to merge patch 1 and 3 together in second
position? It seems to me that you are
On 11/25/2013 05:41 PM, Heikki Krogerus wrote:
On Sat, Nov 23, 2013 at 05:59:30PM +0900, Alexandre Courbot wrote:
Wouldn't it be possible (and simpler) to move patch 2 of your series
to first position, and then to merge patch 1 and 3 together in second
position? It seems to me that you are
On 11/25/2013 05:54 PM, Mika Westerberg wrote:
On Sat, Nov 23, 2013 at 06:21:03PM +0900, Alexandre Courbot wrote:
On Fri, Nov 22, 2013 at 9:14 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
Now that all users of acpi_gpio.h have been moved to user either the GPIO
s/user/use
OK.
On 11/25/2013 06:02 PM, Heikki Krogerus wrote:
On Mon, Nov 25, 2013 at 05:47:38PM +0900, Alex Courbot wrote:
On 11/25/2013 05:41 PM, Heikki Krogerus wrote:
Adding the lookup table in first patch and then changing the driver in
the second creates a point to the history where this driver stops
On 11/25/2013 06:28 PM, Mika Westerberg wrote:
On Mon, Nov 25, 2013 at 06:07:10PM +0900, Alexandre Courbot wrote:
On Mon, Nov 25, 2013 at 5:58 PM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
On Sat, Nov 23, 2013 at 02:54:29PM +0900, Alexandre Courbot wrote:
Add missing declarations
On 11/19/2013 06:24 PM, Linus Walleij wrote:
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
wrote:
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
Signed-off-by: Andy
On 11/19/2013 06:24 PM, Linus Walleij wrote:
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from
On 11/19/2013 08:48 AM, Stephen Warren wrote:
On 11/18/2013 04:43 AM, Thierry Reding wrote:
On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
FUSE clock is enabled by most bootloaders, but we cannot expect
it to be on in all contexts (e.g. kexec).
This patch adds a FUSE
On 11/18/2013 08:43 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
FUSE clock is enabled by most bootloaders, but we cannot expect it to be
on in all contexts (e.g. kexec).
This patch adds a FUSE clkdev to all Tegra
On 11/18/2013 08:58 PM, Catalin Marinas wrote:
On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support
On 11/18/2013 06:34 PM, Linus Walleij wrote:
On Sat, Nov 16, 2013 at 1:34 PM, Alexandre Courbot wrote:
The first version received zero feedback, hopefully this one will get more
attention. :) Not much changes, just some more proofreading and the fixes
and improvements that came from it. It
On 11/18/2013 06:34 PM, Linus Walleij wrote:
On Sat, Nov 16, 2013 at 1:34 PM, Alexandre Courbot acour...@nvidia.com wrote:
The first version received zero feedback, hopefully this one will get more
attention. :) Not much changes, just some more proofreading and the fixes
and improvements that
On 11/18/2013 08:58 PM, Catalin Marinas wrote:
On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot acour...@nvidia.com wrote:
The ARM tree includes a firmware_ops interface that is designed
On 11/18/2013 08:43 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
FUSE clock is enabled by most bootloaders, but we cannot expect it to be
on in all contexts (e.g. kexec).
This patch adds a FUSE clkdev to all Tegra
On 11/19/2013 08:48 AM, Stephen Warren wrote:
On 11/18/2013 04:43 AM, Thierry Reding wrote:
On Mon, Nov 18, 2013 at 07:40:47PM +0900, Alexandre Courbot wrote:
FUSE clock is enabled by most bootloaders, but we cannot expect
it to be on in all contexts (e.g. kexec).
This patch adds a FUSE
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support for simple, TrustZone-based firmwares but could
also cover other use-cases. It has been suggested that this
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot acour...@nvidia.com wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support for simple, TrustZone-based firmwares but could
also cover other use-cases. It has been
On 11/14/2013 02:57 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot wrote:
On 11/13/2013 05:38 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren
wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Just a set of small fixes to address
On 11/14/2013 02:57 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot acour...@nvidia.com wrote:
On 11/13/2013 05:38 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote
On 11/13/2013 05:38 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Just a set of small fixes to address the concerns expressed on v9 with the
non-prefixed version DT properties. I hope there won't be a need
On 11/13/2013 05:23 AM, Stephen Warren wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Register the firmware operations for Trusted Foundations if the device
tree indicates it is active on the device.
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
void
On 11/13/2013 05:23 AM, Stephen Warren wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Register the firmware operations for Trusted Foundations if the device
tree indicates it is active on the device.
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
void
On 11/13/2013 05:38 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Just a set of small fixes to address the concerns expressed on v9 with the
non-prefixed version DT properties. I hope
On 10/31/2013 01:59 PM, NeilBrown wrote:
* PGP Signed by an unknown key
On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown wrote:
On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:
Yes, the device is soldered down and has a reset line that needs to be pulsed
low at about the same time
On 10/31/2013 01:59 PM, NeilBrown wrote:
* PGP Signed by an unknown key
On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown broo...@kernel.org wrote:
On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:
Yes, the device is soldered down and has a reset line that needs to be pulsed
low at
On 10/29/2013 05:12 PM, Kumar Gala wrote:
On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:
On Mon, Oct 28, 2013 at 11:31:36PM +, Tomasz Figa wrote:
On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
On Oct 28, 2013,
On 10/29/2013 10:25 PM, Linus Walleij wrote:
On Tue, Oct 29, 2013 at 10:10 AM, Stephen Rothwell
wrote:
I have applied the following patch for today (it should go into the gpio
tree if it is considered correct):
From: Stephen Rothwell
Date: Tue, 29 Oct 2013 20:05:12 +1100
Subject: [PATCH]
On 10/29/2013 10:25 PM, Linus Walleij wrote:
On Tue, Oct 29, 2013 at 10:10 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
I have applied the following patch for today (it should go into the gpio
tree if it is considered correct):
From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 29
On 10/29/2013 05:12 PM, Kumar Gala wrote:
On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:
On Mon, Oct 28, 2013 at 11:31:36PM +, Tomasz Figa wrote:
On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
On Oct 28, 2013,
On 10/25/2013 04:33 PM, NeilBrown wrote:
* PGP Signed by an unknown key
On Fri, 25 Oct 2013 15:23:45 +0900 Alex Courbot wrote:
Hi Neil,
On 10/25/2013 09:22 AM, NeilBrown wrote:
I'm wondering if there was any news on the Runtime Interpreted Power
Sequences?
The most recent news I can
On 10/25/2013 04:33 PM, NeilBrown wrote:
* PGP Signed by an unknown key
On Fri, 25 Oct 2013 15:23:45 +0900 Alex Courbot acour...@nvidia.com wrote:
Hi Neil,
On 10/25/2013 09:22 AM, NeilBrown wrote:
I'm wondering if there was any news on the Runtime Interpreted Power
Sequences?
The most
Hi Neil,
On 10/25/2013 09:22 AM, NeilBrown wrote:
I'm wondering if there was any news on the Runtime Interpreted Power
Sequences?
The most recent news I can find is
https://lkml.org/lkml/2013/4/27/73
where you say they might be ready for 3.11. Clearly that didn't work
(predictions being
Hi Neil,
On 10/25/2013 09:22 AM, NeilBrown wrote:
I'm wondering if there was any news on the Runtime Interpreted Power
Sequences?
The most recent news I can find is
https://lkml.org/lkml/2013/4/27/73
where you say they might be ready for 3.11. Clearly that didn't work
(predictions being
On 10/16/2013 04:37 AM, Linus Walleij wrote:
On Sat, Oct 12, 2013 at 12:31 AM, Alex Courbot wrote:
+#else
+static struct device_node *of_find_gpio(struct device *dev, const char *id
+ unsigned int idx, unsigned long flags)
+{
+ return ERR_PTR(-ENODEV
On 10/16/2013 04:37 AM, Linus Walleij wrote:
On Sat, Oct 12, 2013 at 12:31 AM, Alex Courbot acour...@nvidia.com wrote:
+#else
+static struct device_node *of_find_gpio(struct device *dev, const char *id
+ unsigned int idx, unsigned long flags)
+{
+ return
On 10/15/2013 04:07 AM, Russell King - ARM Linux wrote:
On Fri, Oct 11, 2013 at 02:45:34PM -0700, Alexandre Courbot wrote:
Trusted Foundations is a TrustZone-based secure monitor for ARM that
can be invoked using the same SMC-based API on all supported
platforms. This patch adds initial basic
On 10/15/2013 04:07 AM, Russell King - ARM Linux wrote:
On Fri, Oct 11, 2013 at 02:45:34PM -0700, Alexandre Courbot wrote:
Trusted Foundations is a TrustZone-based secure monitor for ARM that
can be invoked using the same SMC-based API on all supported
platforms. This patch adds initial basic
> +#else
> +static struct device_node *of_find_gpio(struct device *dev, const char *id
> + unsigned int idx, unsigned long flags)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +#endif
... and of course I forgot to fix the main compilation error. Linus,
would
+#else
+static struct device_node *of_find_gpio(struct device *dev, const char *id
+ unsigned int idx, unsigned long flags)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
... and of course I forgot to fix the main compilation error. Linus,
would you mind
On 10/04/2013 09:37 AM, Alexandre Courbot wrote:
Hopefully final version of this patchset. If I'm not mistaken the last thing
that prevents Stephen from merging it is Russel's Ack. Russel, could you check
it?
Oops.
s/Russel/Russell/g, with apologies for the continuous misspelling. m(__)m
On 10/04/2013 09:37 AM, Alexandre Courbot wrote:
Hopefully final version of this patchset. If I'm not mistaken the last thing
that prevents Stephen from merging it is Russel's Ack. Russel, could you check
it?
Oops.
s/Russel/Russell/g, with apologies for the continuous misspelling. m(__)m
On 09/04/2013 03:42 AM, Stephen Warren wrote:
On 08/29/2013 03:57 AM, Alexandre Courbot wrote:
New version revised according to comments received for v3. Hopefully
it will be good enough to be merged.
Aside from the small issue in patch 1/5, the series,
Reviewed-by: Stephen Warren
Thanks!
On 09/04/2013 03:42 AM, Stephen Warren wrote:
On 08/29/2013 03:57 AM, Alexandre Courbot wrote:
New version revised according to comments received for v3. Hopefully
it will be good enough to be merged.
Aside from the small issue in patch 1/5, the series,
Reviewed-by: Stephen Warren
On 07/23/2013 12:32 PM, Stephen Warren wrote:
On 07/22/2013 07:15 PM, Alex Courbot wrote:
...
Although the patch seems ok to me in its current form, there are two
points for which I still have small doubts:
1) Whether size_t and pointers will have the same size on all platforms.
ptrsize_t
On 07/23/2013 03:08 AM, Jon Medhurst (Tixy) wrote:
On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
When decompressing into memory, the output buffer length is set to some
arbitrarily high value (0x7fff) to indicate the output is,
virtually, unlimited in size.
The problem with
On 07/23/2013 03:08 AM, Jon Medhurst (Tixy) wrote:
On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
When decompressing into memory, the output buffer length is set to some
arbitrarily high value (0x7fff) to indicate the output is,
virtually, unlimited in size.
The problem with
On 07/23/2013 12:32 PM, Stephen Warren wrote:
On 07/22/2013 07:15 PM, Alex Courbot wrote:
...
Although the patch seems ok to me in its current form, there are two
points for which I still have small doubts:
1) Whether size_t and pointers will have the same size on all platforms.
ptrsize_t
On 06/07/2013 04:22 PM, Alexander van Heukelum wrote:
static struct simplefb_format simplefb_formats[] = {
{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
Hi,
31? I assume in practice this doesn't influence anything,
On 06/07/2013 01:32 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
We're talking about adding a bunch of code instead of one line in a
table. Sorry, I NACK your NACK. If we get more entries we'll add the
parser, but not just for this.
as there is no NACK so far I do take as a NACK
... which
On 06/07/2013 01:32 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
We're talking about adding a bunch of code instead of one line in a
table. Sorry, I NACK your NACK. If we get more entries we'll add the
parser, but not just for this.
as there is no NACK so far I do take as a NACK
... which
On 06/07/2013 04:22 PM, Alexander van Heukelum wrote:
static struct simplefb_format simplefb_formats[] = {
{ r5g6b5, 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ { a8b8g8r8, 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
Hi,
31? I assume in practice this doesn't influence anything, but I
Hi Tomasz,
On 06/06/2013 07:17 PM, Tomasz Figa wrote:
+Global properties
+---
+
+The following properties can be specified into the "chosen" root
+node:
+
+ nvidia,secure-os: enable SecureOS.
Hmm, on Exynos we had something like
On 06/06/2013 06:35 PM, Russell King - ARM Linux wrote:
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we
On 06/06/2013 05:24 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 10:12 AM, Alex Courbot wrote:
On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 9:20 AM, Alexandre Courbot wrote:
Signed-off-by: Alexandre Courbot
---
Documentation
On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 9:20 AM, Alexandre Courbot wrote:
Signed-off-by: Alexandre Courbot
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
drivers/video/simplefb.c | 1 +
On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 9:20 AM, Alexandre Courbot acour...@nvidia.com wrote:
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
drivers/video/simplefb.c
On 06/06/2013 05:24 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 10:12 AM, Alex Courbot acour...@nvidia.com wrote:
On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On Jun 6, 2013, at 9:20 AM, Alexandre Courbot acour...@nvidia.com wrote:
Signed-off
On 06/06/2013 06:35 PM, Russell King - ARM Linux wrote:
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we
Hi Tomasz,
On 06/06/2013 07:17 PM, Tomasz Figa wrote:
+Global properties
+---
+
+The following properties can be specified into the chosen root
+node:
+
+ nvidia,secure-os: enable SecureOS.
Hmm, on Exynos we had something like
Hi Grant,
Here is the pull request for the GENERIC_GPIO removal. It is almost
certain that a few fixups will be necessary - while I don't have precise
patches, the following steps should ensure the state of the code is clean:
* "git grep CONFIG_GENERIC_GPIO" should return 0 hits. Matches
Hi Grant,
Here is the pull request for the GENERIC_GPIO removal. It is almost
certain that a few fixups will be necessary - while I don't have precise
patches, the following steps should ensure the state of the code is clean:
* git grep CONFIG_GENERIC_GPIO should return 0 hits. Matches
On 03/29/2013 06:11 AM, Alexandre Courbot wrote:
If I can get a few acks on these (or at least the first two ones) I'd like to
include them into my next branch as soon as possible so points of breakage can
be fixed. There are indeed a few new users of GENERIC_GPIO (CC Romain, I sent a
warning
On 03/29/2013 06:11 AM, Alexandre Courbot wrote:
If I can get a few acks on these (or at least the first two ones) I'd like to
include them into my next branch as soon as possible so points of breakage can
be fixed. There are indeed a few new users of GENERIC_GPIO (CC Romain, I sent a
warning
On 03/12/2013 07:35 PM, Paul Mundt wrote:
On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote:
SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
through CONFIG_GPIOLIB, yet some compilation units depended on
CONFIG_GENERIC_GPIO. Make them depend on
On 03/12/2013 07:35 PM, Paul Mundt wrote:
On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote:
SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
through CONFIG_GPIOLIB, yet some compilation units depended on
CONFIG_GENERIC_GPIO. Make them depend on
On 03/08/2013 06:16 AM, Andrew Chew wrote:
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Renamed en_supply to enable_supply to match the corresponding device tree
property.
Removed unnecessary check for pb->enable_supply
On 03/08/2013 06:07 AM, Andrew Chew wrote:
From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
Sent: Thursday, March 07, 2013 3:27 AM
To: Alex Courbot
Cc: Andrew Chew; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1 v4] pwm_bl: Add support for backlight enable
regulator
* PGP
On 03/07/2013 04:11 PM, Thierry Reding wrote:
+ boolen_supply_enabled;
This boolean can be dropped. As discussed in a previous thread, the
pwm-backlight driver shouldn't need to know about any other uses of the
regulator.
Sorry for being obstinate - but I'm still
On 03/08/2013 06:07 AM, Andrew Chew wrote:
From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
Sent: Thursday, March 07, 2013 3:27 AM
To: Alex Courbot
Cc: Andrew Chew; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1 v4] pwm_bl: Add support for backlight enable
regulator
* PGP
On 03/08/2013 06:16 AM, Andrew Chew wrote:
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
Renamed en_supply to enable_supply to match the corresponding device tree
property.
Removed unnecessary check for
On 03/07/2013 04:11 PM, Thierry Reding wrote:
+ boolen_supply_enabled;
This boolean can be dropped. As discussed in a previous thread, the
pwm-backlight driver shouldn't need to know about any other uses of the
regulator.
Sorry for being obstinate - but I'm still
On 03/06/2013 04:00 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Mar 06, 2013 at 01:53:27PM +0900, Alex Courbot wrote:
On 03/06/2013 11:41 AM, Andrew Chew wrote:
struct pwm_bl_data {
struct pwm_device *pwm;
struct device *dev
On 03/06/2013 04:00 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Mar 06, 2013 at 01:53:27PM +0900, Alex Courbot wrote:
On 03/06/2013 11:41 AM, Andrew Chew wrote:
struct pwm_bl_data {
struct pwm_device *pwm;
struct device *dev
1 - 100 of 294 matches
Mail list logo
