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
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 do
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
On 02/18/2013 08:30 PM, Wei Ni wrote:
Enable thermal sensor lm90 in the dts file.
Acked-by: Alexandre Courbot acour...@nvidia.com
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
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.
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 w...@nvidia.com
---
arch/arm/boot/dts/tegra30-cardhu.dtsi |1 +
drivers/hwmon/lm90.c | 182
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 w...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
Great patch. This makes the code much more readable. I also compiled
lm90.o
On Thu, Feb 14, 2013 at 2:01 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Feb 14, 2013 at 1:41 AM, Stephen Warren swar...@wwwdotorg.org 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
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,
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: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, but the above looks a bit inconsistent. For
gpio you
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,
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; work in
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 code
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 current state
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 type
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. But I
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 the
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
properly and the display
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
I would prefer to create, e.g. in linux/gpio/consumer.h
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
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot acour...@nvidia.com 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 implementation
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 acour...@nvidia.com
wrote:
Would anyone be opposed to having a gpio_get() function that works
similarly to e.g. regulator_get() and clk_get
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 acour...@nvidia.com wrote:
Would anyone be opposed to having a gpio_get() function that works
similarly to e.g. regulator_get() and clk_get()?
I
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
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 stumbling block is that with device tree, each
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
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, regulators,
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 think now is
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 key
On Wed, 2012-09-12 at 18:57 +0900
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
not
scale. I don't know
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:
However, I fear these board specific things may be quite a bit
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 at 15:36 +0900, Alex Courbot wrote
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
way that drivers can use
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 specific things may be quite a bit
anything,
so it may well be pwm, gpios and regulators are not enough
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 about the last
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, regulators,
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. Regulator
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.
+++
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
of the current way. It also
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 is device
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 control
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 result
48 matches
Mail list logo
