On Tue, Nov 27, 2012 at 04:37:32PM +0100, Laurent Pinchart wrote:
> One possibly crazy idea I had was to replace backlight devices as we know
> them
> with LED devices (a LED driver IC shouldn't be supported by different APIs
> depending on whether the LEDs it drives are used as a backlight or
Hi Tomi,
On Tuesday 27 November 2012 17:19:05 Tomi Valkeinen wrote:
> On 2012-11-27 17:08, Laurent Pinchart wrote:
> > On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
> >> On 2012-11-21 13:40, Thierry Reding wrote:
> > [snip]
> >
> >>> One thing that's not very clear is how the backl
On 2012-11-27 17:08, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
>> On 2012-11-21 13:40, Thierry Reding wrote:
>
> [snip]
>
>>> One thing that's not very clear is how the backlight subsystem should be
>>> wired up with the display framework
Hi Thierry,
On Wednesday 21 November 2012 14:00:39 Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-21 13:40, Thierry Reding wrote:
> > > On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> > (sorry for bouncing back and forth wit
Hi Tomi,
On Wednesday 21 November 2012 14:04:17 Tomi Valkeinen wrote:
> On 2012-11-21 13:40, Thierry Reding wrote:
[snip]
> > One thing that's not very clear is how the backlight subsystem should be
> > wired up with the display framework. I have a patch on top of the Tegra
> > DRM driver which
Hi Thierry,
Sorry for the late reply.
On Wednesday 21 November 2012 12:40:18 Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-21 06:23, Alex Courbot wrote:
> > > On Wednesday 21 November 2012 05:54:29 Grant Likely wrote:
> > >>> With the adven
On Thu, 22 Nov 2012 22:40:21 +0100, 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 s
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 Thu, Nov 22, 2012 at 09:57:22AM +0100, Linus Walleij wrote:
> Is it correct to assume that this library will be useful also for ALSA
> SoC type of devices?
ASoC has facilities for autogenerating the bulk of the sequences which
with modern devices is all that you really need.
signature.asc
De
On Thu, Nov 22, 2012 at 5:57 PM, Linus Walleij wrote:
> I have the same (limited by experience) opinion. Working sort of
> near som audio drivers I have understood that power sequencing
> is a big issue not only for things like this backlight example, but
> even more so in the area of audio to avo
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 something like that. However
because of the resource issues this had to b
On Thu, Nov 22, 2012 at 12:12 AM, Thierry Reding
wrote:
> On Thu, Nov 22, 2012 at 12:02:47AM +0900, Alexandre Courbot wrote:
>> Mmmm so maybe I am misinterpreting things, but it looks like we
>> have just buried the power sequences here, haven't we?
>
> I don't think so. In fact I was just startin
On Wed, Nov 21, 2012 at 2:31 AM, Mark Brown
wrote:
> As I said in my earlier reviews I think this is a useful thing to have
> as a utility library for drivers independantly of the DT bindings, it
> would allow drivers to become more data driven. Perhaps we can rework
> the series so that the DT
On Thu, Nov 22, 2012 at 11:06 AM, Mark Brown
wrote:
> On Thu, Nov 22, 2012 at 11:01:34AM +0900, Alexandre Courbot wrote:
>
>> The thing I don't understand here is why would anyone want power
>> sequences without the DT representation. Guys, that's the whole point! :)
>
>> If we are to implement th
On Thu, Nov 22, 2012 at 11:01:34AM +0900, Alexandre Courbot wrote:
> The thing I don't understand here is why would anyone want power
> sequences without the DT representation. Guys, that's the whole point! :)
> If we are to implement things into drivers, then callback functions
> are going to se
On Wed, Nov 21, 2012 at 3:12 PM, Thierry Reding
wrote:
> On Thu, Nov 22, 2012 at 12:02:47AM +0900, Alexandre Courbot wrote:
>> Mmmm so maybe I am misinterpreting things, but it looks like we
>> have just buried the power sequences here, haven't we?
>
> I don't think so. In fact I was just starting
On Wed, 21 Nov 2012 13:23:06 +0900, Alex Courbot wrote:
> 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'
On Wed, Nov 21, 2012 at 10:00 AM, Alex Courbot wrote:
> 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 s
On Wed, 21 Nov 2012 10:31:34 +0900, Mark Brown
wrote:
> On Tue, Nov 20, 2012 at 09:54:29PM +, Grant Likely wrote:
> > On Sat, 17 Nov 2012 19:55:45 +0900, Alexandre Courbot
> > wrote:
>
> > > With the advent of the device tree and of ARM kernels that are not
> > > board-tied, we cannot rely
On Thu, Nov 22, 2012 at 12:02:47AM +0900, Alexandre Courbot wrote:
> Mmmm so maybe I am misinterpreting things, but it looks like we
> have just buried the power sequences here, haven't we?
I don't think so. In fact I was just starting to think that maybe for
Tegra we could have a generic panel dr
Mmmm so maybe I am misinterpreting things, but it looks like we
have just buried the power sequences here, haven't we?
Alex.
On Wed, Nov 21, 2012 at 10:32 PM, Tomi Valkeinen wrote:
> On 2012-11-21 15:00, Thierry Reding wrote:
>> On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
>>>
On 2012-11-21 15:00, Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
>> On 2012-11-21 13:40, Thierry Reding wrote:
>>> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
>>
>> (sorry for bouncing back and forth with my private and my @ti addresse
On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
> On 2012-11-21 13:40, Thierry Reding wrote:
> > On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
>
> (sorry for bouncing back and forth with my private and my @ti addresses.
> I can't find an option in thunderbird to o
On 2012-11-21 13:40, Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
(sorry for bouncing back and forth with my private and my @ti addresses.
I can't find an option in thunderbird to only use one sender address,
and I always forget to change it when respondi
On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
> On 2012-11-21 06:23, Alex Courbot wrote:
> > 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 t
On 2012-11-21 06:23, Alex Courbot wrote:
> 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
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 2012-11-21 10:32, Alex Courbot wrote:
>> Ok. I'll need to dig up the conversation
>
> IIRC it was somewhere around here:
>
> https://lkml.org/lkml/2012/9/7/662
>
> See the parent messages too.
Thanks.
>> Did you consider any examples
>> of how some driver could handle the error cases?
>
>
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
> >
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 define the gpio resource inside the step. For power and pwm the
>> resource is defined before the
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 Tue, Nov 20, 2012 at 09:54:29PM +, Grant Likely wrote:
> On Sat, 17 Nov 2012 19:55:45 +0900, Alexandre Courbot
> 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 tr
On Sat, 17 Nov 2012 19:55:45 +0900, Alexandre Courbot
wrote:
> Some device drivers (e.g. panel or backlights) need to follow precise
> sequences for powering on and off, involving GPIOs, regulators, PWMs
> and other power-related resources, with a defined powering order and
> delays to respect be
Hi,
On 2012-11-17 12:55, Alexandre Courbot wrote:
A few questions after looking at the documentation:
> +Example
> +---
> +Here are example sequences declared within a backlight device that use all
> the
> +supported resources types:
> +
> + backlight {
> + compatible = "pwm
On Mon, Nov 19, 2012 at 11:29:05AM +0900, Alex Courbot wrote:
> 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
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 Sat, Nov 17, 2012 at 07:55:45PM +0900, Alexandre Courbot wrote:
> Some device drivers (e.g. panel or backlights) need to follow precise
> sequences for powering on and off, involving GPIOs, regulators, PWMs
> and other power-related resources, with a defined powering order and
> delays to respec
38 matches
Mail list logo
