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 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
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/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
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 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 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: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: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 Thursday 13 September 2012 05:33:56 Anton Vorontsov wrote:
> On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote:
>
> > On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> >
> > > New revision of the power sequences, taking as usual the feedback that
> > > was
> > > kindly provided a
On Thursday 13 September 2012 06:07:13 Stephen Warren wrote:
> On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regulators, PWMs
> > with a precise powering order and
On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
>
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regu
On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
>
> > New revision of the power sequences, taking as usual the feedback that
> > was
> > kindly provided about the last version.
> >
> > I
On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 15:08 +0900, Alex Courbot wrote:
>
> > On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:
> >
> > > > Old Signed by an unknown
On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote:
> > I understand the logic behind handling powering sequences in the device
> > driver, but as we discussed for some classes of devices this might just
>
On Thursday 13 September 2012 14:54:09 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
>
> > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> >
> >
> >
> > > Howev
On Thursday 13 September 2012 15:03:27 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
>
> > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> >
> > > On Thu, 2012-09-13 a
On Thursday 13 September 2012 15:19:30 Mark Brown wrote:
> On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote:
> > On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> > > It would be sensible to make sure that the framework is done in such a
> > >
hu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
> > > > > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> > > > > > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> > > > > > > However, I fear these board specif
On 09/14/2012 12:24 AM, Stephen Warren wrote:
On 09/13/2012 01:29 AM, Mark Brown wrote:
On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote:
On Thursday 13 September 2012 15:19:30 Mark Brown wrote:
On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
It would be sensible to make
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 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 Fri 27 Jul 2012 02:10:54 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Jul 26, 2012 at 02:11:58PM -0700, Linus Torvalds wrote:
On Thu, Jul 26, 2012 at 12:16 AM, Thierry Reding
wrote:
The new PWM subsystem aims at collecting all implementations of the
legacy PWM API
On 07/28/2012 03:19 AM, Greg Kroah-Hartman wrote:
On Fri, Jul 27, 2012 at 09:05:48PM +0900, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and del
Hi Simon,
On 07/30/2012 08:00 PM, Simon Glass wrote:
For the delay, I think milliseconds is reasonable. I suppose there is
no reasonable need for microseconds?
I don't see any need for microseconds myself - anybody sees use for
finer-grained delays?
Btw, I noticed I was using mdelay instead
On 07/30/2012 08:33 PM, Thierry Reding wrote:
+You will need an instance of power_seq_resources to keep track of the resources
+that are already allocated. On success, the function returns a devm allocated
+resolved sequence that is ready to be passed to power_seq_run(). In case of
+failure, and
On 07/31/2012 06:13 PM, Thierry Reding wrote:
I don't see any need for microseconds myself - anybody sees use for
finer-grained delays?
Btw, I noticed I was using mdelay instead of msleep - caught and fixed that.
You might want to take a look at Documentation/timers/timers-howto.txt.
msleep()
On 07/31/2012 07:26 AM, Stephen Warren wrote:
On 07/30/2012 09:44 AM, Rob Herring wrote:
On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise
On 07/31/2012 07:45 AM, Stephen Warren wrote:
+- Delay to wait before performing the action,
+- Delay to wait after performing the action.
I don't see a need to have a delay both before and after an action;
except at the start of the sequence, step n's post-delay is at the same
point in the seq
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 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
Hi Heiko,
On Thursday 06 September 2012 22:14:53 Heiko Stübner wrote:
> Hi Alexander,
>
> Am Freitag, 31. August 2012, 13:34:03 schrieb Alexandre Courbot:
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regulator
Hi Stephen,
Skipping the typos and rephrasing issues (which will all be addressed,
thanks!), these issues caught my attention more particularly:
On Thursday 06 September 2012 01:19:45 Stephen Warren wrote:
> > +"regulator" type required properties:
> > + - id: name of the regulator to use. Regu
On Thursday 06 September 2012 01:25:27 Stephen Warren wrote:
> On 08/31/2012 05:34 AM, Alexandre Courbot wrote:
> > Make use of the power sequences specified in the device tree or platform
> > data to control how the backlight is powered on and off.
> >
> > +++ b/Documentation/devicetree/bindings/
On Friday 07 September 2012 16:29:03 Mark Brown wrote:
> On Fri, Sep 07, 2012 at 05:28:17PM +0900, Alex Courbot wrote:
> > We could make power sequences an option of its own and add #ifdefs to
> > drivers that use it to lift this ambiguity, but I like the transparency
> > o
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)
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
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 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.
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 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 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 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: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
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 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
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 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 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 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
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/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
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 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 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 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 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 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: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: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/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/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 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 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
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/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/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
---
Renamed en_supply to enable_supply to match the corresponding device tree
property.
Removed unnecessary check for pb->enable_supply valid
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 07/31/2012 09:22 PM, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the
On 07/31/2012 09:55 PM, Mitch Bradley wrote:
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen
On 07/31/2012 07:19 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
On 07/30/2012 08:33 PM, Thierry Reding wrote:
+You will need an instance of power_seq_resources to keep track of the resources
+that are already allocated
On Wed 01 Aug 2012 05:04:53 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Aug 01, 2012 at 04:37:09PM +0900, Alexandre Courbot wrote:
Add resource managed variants of pwm_get() and pwm_put() for
convenience. Code is largely inspired by the equivalent devm functions
of the
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources directly in each step; something more like:
gpio@1 {
action = "enable-gpio";
gpio = <&gpio 1 0>;
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
Oh I see. That's a little confusing. Why not just reference the relevant
resources direct
On Thu 02 Aug 2012 05:45:41 PM JST, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
Old Signed by an unknown key
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
The problem is, how do we turn these phandles into the resource of
interest. The type of the resource can be
On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
I missed some of the earlier bits of the thread here but why can't we do
device based lookups?
That is because the phandles
On 08/07/2012 01:16 AM, Stephen Warren wrote:
On 08/05/2012 08:27 PM, Alex Courbot wrote:
On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
I missed some of the earlier bits of the
On Tuesday 21 August 2012 17:54:20 Tomi Valkeinen wrote:
> > However this also means we'll essentially just be moving the board code.
>
>
> What do you mean "just"? Wasn't the point of the whole "arm board file
> mess" to get rid of the code from the board files? If the code in the
> board file i
On 08/16/2012 04:42 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 16, 2012 at 03:08:55PM +0900, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a pr
On 08/16/2012 06:52 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, Aug 16, 2012 at 06:19:08PM +0900, Alex Courbot wrote:
On 08/16/2012 04:42 PM, Thierry Reding wrote:
Old Signed by an unknown key
On Thu, Aug 16, 2012 at 03:08:55PM +0900, Alexandre Courbot wrote
On 08/17/2012 03:38 AM, Stephen Warren wrote:
On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between
On 08/17/2012 06:47 AM, Rafael J. Wysocki wrote:
On Thursday, August 16, 2012, Alexandre Courbot wrote:
Overdue revision of this new feature, some changes required additional thought
and rework.
The most important change is in the way power sequences are expressed in the
device tree. In order t
Hi Tomi,
On Tuesday 21 August 2012 15:44:29 Tomi Valkeinen wrote:
> > +Problem
> > +---
> > +One very common board-dependent code is the out-of-driver code that is
> > used to +turn a device on or off. For instance, SoC boards very commonly
> > use a GPIO +(abstracted to a regulator or not) to
On Tuesday 21 August 2012 16:33:30 Thierry Reding wrote:
> I suppose power sequences aren't needed if you have a specific driver
> for every panel out there. However that also means that you'd have to
> write drivers for literally every panel that requires support. In the
> end this will just resul
Hi Simon,
On Thu 12 Jul 2012 06:37:33 PM JST, Simon Glass wrote:
I would like to do something similar in U-Boot for Tegra, although
perhaps not right away. For now I will go with something considerably
simpler! But if this is merged into the kernel we will move to it in
U-Boot.
Cool, I'd love
On 07/12/2012 11:27 PM, Simon Glass wrote
I agree the type strings are a problem in the current form - if we could get
constants in the device tree, that would be much better. Your way of
representing the sequences is interesting though, if we can solve the type
issue (and also evaluate its cost
On 07/12/2012 07:54 PM, R, Durgadoss wrote:
We are working on a notification API from any generic sensor driver to
the thermal framework.
Please have a look at the 'notify_thermal_framework' API in the patch here:
http://www.spinics.net/lists/linux-acpi/msg36049.html
At first sight these patche
On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote:
As of now, we are getting the definitions done through the platform layer
data. Considerations for device tree .. yes.. but I do not have any sample
implementation..
Maybe we can help with that then, since we are going to need it.
On the
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
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
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>;
> > +
> > +
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/
> 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 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
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
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
1 - 100 of 147 matches
Mail list logo
