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 05/24/2013 01:27 AM, Stephen Warren wrote:
Stephen, please note that the "r5g6b5" mode initially supported
by the driver becomes "b5g6r5" with the new function. This is because
the least significant bits are defined first in the string - this
makes parsing much easier, notably for modes which
On 02/20/2013 08:00 AM, Stephen Warren wrote:
On 02/18/2013 04:30 AM, Wei Ni wrote:
Add support to handle irq. When the temperature touch the limit value, the
driver can handle the interrupt.
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
+static void lm90_irq_work(struct work_st
On 02/18/2013 08:30 PM, Wei Ni wrote:
Using macros for the indexes and nrs of temp8 and temp11.
This make the code much clearer.
Signed-off-by: Wei Ni
Acked-by: Alexandre Courbot
Great patch. This makes the code much more readable. I also compiled
lm90.o before and after this patch, and di
On 02/18/2013 08:30 PM, Wei Ni wrote:
Register the remote sensor to the thermal framework.
It can support to show the temperature and read/write threshold.
Signed-off-by: Wei Ni
---
arch/arm/boot/dts/tegra30-cardhu.dtsi |1 +
drivers/hwmon/lm90.c | 182 +
On 02/18/2013 08:30 PM, Wei Ni wrote:
diff --git a/Documentation/devicetree/bindings/thermal/tegra3-thermal.txt
b/Documentation/devicetree/bindings/thermal/tegra3-thermal.txt
new file mode 100644
This should go with the previous patch (which introduces the driver)
instead of this one. Binding
On 02/18/2013 08:30 PM, Wei Ni wrote:
Enable thermal sensor lm90 in the dts file.
Acked-by: Alexandre Courbot
Btw, shouldn't this patch come last, after all the changes you did to
lm90? If you keep the current order, you will need to ensure that the
device performs as expected on Cardhu for
On Thu, Feb 14, 2013 at 2:01 AM, Linus Walleij wrote:
On Thu, Feb 14, 2013 at 1:41 AM, Stephen Warren wrote:
On 02/13/2013 05:34 PM, Doug Anderson wrote:
A little torn here. It adds a bunch of complexity to the code to
handle this case and there are no known or anticipated users. I only
w
On 02/11/2013 03:25 PM, Tony Prisk wrote:
I was just wondering if the following would be an acceptable way to turn
off an lcd backlight when the pwm-backlight driver is set to level 0.
The LCD backlight is 'powered' by the gpio.
leds {
compatible = "gpio-leds";
backlight {
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 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 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)
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
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 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
> > >
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 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 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: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 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 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 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 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 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 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/
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
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
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 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 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
48 matches
Mail list logo
