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 ple
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 ar
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 ar
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 "uns
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 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 de
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 gpiod_looku
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 need
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, 2
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 majo
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 rfkill_gpio_platfor
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 warn
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 basic
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 Shevchenko
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 clkdev
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 p
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 loo
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
int
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/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 for
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 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 th
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, at
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] gp
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
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 ha
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/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 su
> +#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
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
Alex
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! I
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 th
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, bu
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 means
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
firmware@0203F
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 pref
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 +
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 shou
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 but
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 CONFIG_GPI
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 valid
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 not
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 01:20 PM, Stephen Warren wrote:
On 03/05/2013 07:18 PM, Alex Courbot wrote:
On 03/06/2013 08:51 AM, Andrew Chew wrote:
The backlight enable regulator is specified in the device tree node for
backlight.
diff --git a/include/linux/pwm_backlight.h
struct
On 03/06/2013 11:41 AM, Andrew Chew wrote:
struct pwm_bl_data {
struct pwm_device *pwm;
struct device *dev;
+ struct regulator*en_supply;
+ boolen_supply_enabled;
Couldn't you use regulator_is_enabled() and get rid of en
On 03/06/2013 08:51 AM, Andrew Chew wrote:
The backlight enable regulator is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
Applied all recommendations from Thierry Reding and Alex Courbot, including
making pwm_bl take an optional regulator instead of a GPIO
On 03/05/2013 01:43 PM, Andrew Chew wrote:
The backlight enable GPIO is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
I decided to go ahead with disabling/enabling the backlight via GPIO as
needed. Note that I named the new functions pwm_backlight_enable() and
On 03/05/2013 01:59 PM, Alex Courbot wrote:
Btw, you also want to check if the enable-gpio property exists first
because otherwise probe() will fails if no GPIO is specified).
That's actually not true - I overlooked the fact that probe() checks for
the GPIO validity before requesting i
On 03/05/2013 01:48 PM, Andrew Chew wrote:
I sent out a new patch that enables/disables the backlight enable gpio.
On 03/05/2013 01:00 PM, Andrew Chew wrote:
I did come to the same conclusion regarding the platform data breakage.
I'm expecting that the use of platform data will go away, at lea
On 03/05/2013 01:00 PM, Andrew Chew wrote:
I did come to the same conclusion regarding the platform data breakage.
I'm expecting that the use of platform data will go away, at least on ARM,
since we are all aggressively moving what used to be in platform data into
the device tree. Do other platf
On 03/05/2013 07:46 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Mon, Mar 04, 2013 at 01:49:49PM -0800, Andrew Chew wrote:
The backlight enable GPIO is specified in the device tree node for
backlight.
Signed-off-by: Andrew Chew
---
.../bindings/video/backlight/pwm-backlight.t
On 02/15/2013 08:05 PM, Bjørn Mork wrote:
Maybe something like the completely untested:
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3148b10..38e19ba 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -512,6 +512,9 @@ static int rpm_
On 02/15/2013 08:05 PM, Bjørn Mork wrote:
Alex Courbot writes:
Unfortunately it does not, and fails the same way. On the other hand,
I do not see the issue when doing the following:
diff --git a/drivers/usb/serial/usb_wwan.c b/drivers/usb/serial/usb_wwan.c
index e4fad5e..1490029 100644
--- a
, 14 Feb 2013 18:34:48 +0100
Subject: [PATCH] USB: usb_wwan: clear port busy state on error
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Reported-by: Alex Courbot
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/usb_wwan.c |4 +++-
1 file changed
Hi everyone,
I have this pretty weird issue on Android 3.1 kernel and would really
appreciate some insight that would allow me to figure it out. Could not
find any reference to a similar problem so I am seeking your advice.
The board features a USB GSM modem using the usb_wwan module. Once in
On 02/09/2013 07:34 PM, Grant Likely wrote:
The debugfs files really need to hold the gpiolib spinlock before
accessing the list. Otherwise chip addition/removal will cause an oops.
Cc: Alexandre Courbot
Cc: Linus Walleij
Signed-off-by: Grant Likely
Tested-by: Alexandre Courbot
Just wonde
Hi Grant,
On 02/10/2013 01:34 AM, Grant Likely wrote:
> Alex, this is broken when the sysfs interface isn't enabled. Can you
> send a fixup patch?
>
> g.
>
> On Sat, Feb 9, 2013 at 3:41 PM, kbuild test robot
> wrote:
>> tree: git://git.secretlab.ca/git/linux-2.6.git gpio/next
>> head: 8a307b
On 02/06/2013 02:21 AM, Linus Walleij wrote:
This looks like it is preserving this userspace-sensitive semantic
so that dynamically added chips will still get the same assigned
numbers.
It does (it should, at least), the assigned ranges should be strictly
identical to the previous version. Whi
On 01/30/2013 04:48 PM, Thierry Reding wrote:
I already said this in another thread. I think we should only be using
the CDF .get_modes() for static modes that cannot be obtained from EDID.
Thinking about it, I'm not quite sure why EDID would be needed for this
kind of panel anyway. Ventana proba
On 01/30/2013 04:40 PM, Thierry Reding wrote:
Thanks *a lot* for taking care of this Alexandre! From a quick look at
the patches they seem generally fine. I'll go over them in a bit more
detail though.
Glad you like it better than my previous attempts at controlling Tegra's
panels and backligh
On 01/30/2013 04:24 PM, Thierry Reding wrote:
Could you pick up a somewhat meaningful name? You know, there are too
many variables with name "drm/connector/output/encoder"... :)
Well, it's supposed to be abstract. From the CDF point of view it
could be anything besides a panel. I know this make
On 01/30/2013 04:20 PM, Mark Zhang wrote:
+ /* OFF and STANDBY are equivalent to us */
+ if (state == DISPLAY_ENTITY_STATE_STANDBY)
+ state = DISPLAY_ENTITY_STATE_OFF;
Do we need this? The "switch" below handles the same thing already.
Indeed, I have rewritten this p
On 01/30/2013 03:50 PM, Mark Zhang wrote:
@@ -147,6 +148,9 @@ struct tegra_output {
struct drm_encoder encoder;
struct drm_connector connector;
+ struct display_entity this;
+ struct display_entity *output;
Could you pick up a somewhat meaningful name? You know, the
On Wednesday 23 January 2013 17:45:39 Alex Courbot wrote:
> > I'm confused. Why would you want to call into pwm_bl directly? If we're
> > going to split this up into separate platform devices, why not look up a
> > given backlight device and use the backlight API on
On Wednesday 23 January 2013 18:15:30 Leela Krishna Amudala wrote:
> > + pwm_backlight_set_subdriver_data(dev, data);
>
> Here you are passing ventana_bl_data pointer as input and in the
> pwm_backlight_get_subdriver_data() function you are assigning the
> received driver data to backlight_d
> I'm confused. Why would you want to call into pwm_bl directly? If we're
> going to split this up into separate platform devices, why not look up a
> given backlight device and use the backlight API on that? The pieces of
> the puzzle are all there: you can use of_find_backlight_by_node() to
> obt
On Tuesday 22 January 2013 01:46:33 Stephen Warren wrote:
> > arch/arm/boot/dts/tegra20-ventana.dts | 18 +++-
> > arch/arm/configs/tegra_defconfig | 1 +
> > drivers/video/backlight/Kconfig| 7 ++
> > drivers/video/backlight/pwm_bl.c | 3 +
> > drivers/video/backlight/
On Monday 21 January 2013 15:35:58 Mark Zhang wrote:
> > + backlight {
> > + compatible = "pwm-backlight-ventana";
> > + brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176
> > 192
208
> > 224 240 255>; + default-brightness-level = <12>;
> > +
> > +
Hi Thierry,
On Monday 21 January 2013 15:49:28 Thierry Reding wrote:
> Eventually this should all be covered by the CDF, but since that's not
> ready yet we want something ad-hoc to get the hardware supported. As
> such I would like to see this go into some sort of minimalistic, Tegra-
> specific
Hi Steven,
On 01/18/2013 01:50 AM, Steven King wrote:
Well, my concern is the small, single chip platforms with limited ram and
speeds measured in MHz. My goal was that these platforms that had very basic
gpio needs, no offboard gpio, just toggling a few pins for spi or whatever,
could do that
On 01/10/2013 07:08 PM, Arnd Bergmann wrote:
I've tried to find platforms that don't yet use GPIOLIB and fortunately
there are very few left:
I found two that provide the generic gpio interfaces when gpiolib
is disabled, but use gpiolib otherwise for the same hardware,
arch/m68k/include/asm/mcfg
On Wednesday 09 January 2013 18:46:12 Arnd Bergmann wrote:
> > The question is, do we want to totally get rid of the integer
> > namespace? That would be the ultimate step, but would require another
> > way to identify GPIOs (controller_device:offset might be such a way),
> > and also to reorganize
Hi Guenter,
On Friday 07 December 2012 10:49:47 Guenter Roeck wrote:
> My own idea for a solution was to keep integer based handles, but replace
> gpio_desc[] with a hash table. But ultimately I don't really care how
> it is done.
>
> Do you have a solution for gpiochip_find_base() in mind, and h
On Thursday 06 December 2012 22:42:59 Grant Likely wrote:
> how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
Sure, matching existing interfaces is better. "git grep hwnum" does not seem
to reveal much related to irqdomain though?
> I've only lightly scanned this patch, but I
On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> I don't have any problem with a gpio_get function, but I do agree that
> making it return an opaque handle is how it should be written with a new
> set of accessors. The handle should probably be simply the pointer to
> the &gpio_desc[number
On Friday 23 November 2012 05:40:21 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 01:39:41PM +, Grant Likely wrote:
> [...]
>
> > I do think that each sequence should be contained within a single
> > property, but I'm open to other suggestions.
>
> IIRC a very early prototype did implement
On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote:
> If the power-off sequence disables a regulator that was supposed to be
> enabled by the power-on sequence (but wasn't enabled because of an
> error), the regulator_disable is still called when the driver runs the
> power-off sequence, i
On Wednesday 21 November 2012 16:13:47 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On 2012-11-21 03:56, Alex Courbot wrote:
> > Hi Tomi,
> >
> > On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> >> I guess there's a reason, bu
Hi Grant,
On Wednesday 21 November 2012 05:54:29 Grant Likely wrote:
> > With the advent of the device tree and of ARM kernels that are not
> > board-tied, we cannot rely on these board-specific hooks anymore but
>
> This isn't strictly true. It is still perfectly fine to have board
> specific co
Hi Tomi,
On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 500>;" wo
On Saturday 17 November 2012 19:38:50 Anton Vorontsov wrote:
> > +++ b/drivers/power/power_seq/Kconfig
> > @@ -0,0 +1,2 @@
> > +config POWER_SEQ
> > + tristate
>
> This really needs a proper Kconfig description and a help text, shortly
> describing the purpose of the subsystem.
Does it? The cur
On 11/16/2012 04:26 PM, Anton Vorontsov wrote:
+#include "power_seq_delay.c"
+#include "power_seq_regulator.c"
+#include "power_seq_pwm.c"
+#include "power_seq_gpio.c"
This is odd, although I remember you already explained why you have to
include the .c files, instead of linking them separately
Hi Srinivas,
On Friday 16 November 2012 15:58:29 Srinivas KANDAGATLA wrote:
> Hi Alex,
> I am looking forward for this feature to be mainlined,
*cough* Ack *cough* :)
> but I have
> comment on the way the types are tied up to power seq infrastructure.
> I know your use case are limited to using
On Friday 16 November 2012 05:07:53 Thierry Reding wrote:
> This second version of this patch series splits the patches up into more
> logical chunks as requested by Stephen. Instead of renaming the matching
> parameters in the clock driver, this version renames the AUXDATA entries
> to match what
On Friday 16 November 2012 11:36:36 Alex Courbot wrote:
> On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
> > This third version of the patch series cleans up some minor issues that
> > were found in the previous versions, such as deferred probe not working
> > pro
On Friday 16 November 2012 05:28:21 Thierry Reding wrote:
> This third version of the patch series cleans up some minor issues that
> were found in the previous versions, such as deferred probe not working
> properly and the display remaining enabled after the driver is removed.
>
> I've also put
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot wrote:
> > How about, in a first time (and because I'd also like to get the power
> > seqs
> > moving on), a typedef from int to gpio_handle_t and a first
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> I would prefer to create, e.g. in
> something like:
>
> struct gpio;
>
> struct gpio *gpio_get(struct device *dev, const char *name);
>
> int gpio_get_value(struct gpio *g);
>
> Nothing more! I.e. struct gpio is an opaque cookie, not
On Tuesday 06 November 2012 01:35:11 Stephen Warren wrote:
> On 11/04/2012 11:04 AM, Linus Walleij wrote:
> > On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot
wrote:
> >> Would anyone be opposed to having a gpio_get() function that works
> >> similarly to e.g.
Hi Linus, thanks for the reply!
On Monday 05 November 2012 02:04:33 Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote:
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
>
On Wednesday 31 October 2012 23:25:41 Stephen Warren wrote:
> On 10/31/2012 03:04 AM, Alex Courbot wrote:
> > Hi,
> >
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
>
> One major stumbli
Hi,
Would anyone be opposed to having a gpio_get() function that works similarly
to e.g. regulator_get() and clk_get()?
I can see some good reasons to have this:
- Less platform data to pass to drivers,
- Consistency between different subsystems. Regulator, clock, PWM, ... all use
this scheme.
On Friday 19 October 2012 17:20:36 Tony Prisk wrote:
> On Fri, 2012-10-19 at 18:06 +0900, Alexandre Courbot wrote:
> > +static void pwm_backlight_on(struct backlight_device *bl)
> > +{
> > + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> > + int ret;
> > +
> > + if (pb->enabled)
1 - 100 of 147 matches
Mail list logo
