On 04/27/2015 07:17 PM, Vasant Hegde wrote:
> On 04/27/2015 04:45 PM, Jacek Anaszewski wrote:
>> On 04/27/2015 11:53 AM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
I was not aware that some other entity than the driver could be
interested
On 04/28/2015 08:59 AM, Stewart Smith wrote:
Jacek Anaszewski writes:
Is the DT node we are discussing used by some other drivers than the
LED class driver? Or is it required in this form by other components of
your platform?
OS kernels are the chief consumers, Linux being the overwhelmingly
Jacek Anaszewski writes:
> Is the DT node we are discussing used by some other drivers than the
> LED class driver? Or is it required in this form by other components of
> your platform?
OS kernels are the chief consumers, Linux being the overwhelmingly major
one here.
But this is what firmware
On 04/27/2015 04:45 PM, Jacek Anaszewski wrote:
> On 04/27/2015 11:53 AM, Benjamin Herrenschmidt wrote:
>> On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
>>> I was not aware that some other entity than the driver could be
>>> interested in the information provided by DT node. I will no
On 04/27/2015 11:53 AM, Benjamin Herrenschmidt wrote:
On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
I was not aware that some other entity than the driver could be
interested in the information provided by DT node. I will no longer
object, provided that we will get an ack from DT ma
Hi Vasant,
On 04/24/2015 12:15 PM, Jacek Anaszewski wrote:
[...]
For attention and fault LEDs only brightness attribute would matter.
Sure.
DT bindings would look as follows:
opal-leds {
compatible = "ibm,opal-leds";
U78C9.001.RST0027-P1-C1:fault {
};
On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
> I was not aware that some other entity than the driver could be
> interested in the information provided by DT node. I will no longer
> object, provided that we will get an ack from DT maintainer.
My understanding is that we no longer ne
Hi Benjamin,
Thanks for your explanation.
On 04/27/2015 12:07 AM, Benjamin Herrenschmidt wrote:
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote:
How the firmware is related to kernel? These bindings are for kernel,
not for the firmware.
There should be no relation. DT bindings sho
On Fri, 2015-04-24 at 12:15 +0200, Jacek Anaszewski wrote:
> No matter what format of device tree OPAL produces, I assume that
> it must compile it from some sources.
Nope. Well... .C code maybe qualifies as "sources" :-)
> dtb file is a compiled form of human readable dts file containing
> Flatt
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote:
> How the firmware is related to kernel? These bindings are for kernel,
> not for the firmware.
There should be no relation. DT bindings should be kernel agnostic and
represent the HW layout, not be designed based on what a given kernel
d
On Fri, 24 Apr 2015 14:18:30 +1000
Stewart Smith wrote:
> Jacek Anaszewski writes:
> >> These device tree comes from out firmware ... which is immutable .
> >
> > How the firmware is related to kernel? These bindings are for
> > kernel, not for the firmware.
> >
> > DT bindings are compiled to *
On Fri, 24 Apr 2015 11:00:41 +0530
Hi Vasant,
Vasant Hegde wrote:
> On 04/23/2015 07:43 PM, Jacek Anaszewski wrote:
> > On Thu, 23 Apr 2015 10:55:40 +0530
> > Vasant Hegde wrote:
> >
>
> Hi Jacek,
>
> .../...
>
> >>
> >> These device tree comes from out firmware ... which is immutable .
> >
On 04/23/2015 07:43 PM, Jacek Anaszewski wrote:
> On Thu, 23 Apr 2015 10:55:40 +0530
> Vasant Hegde wrote:
>
Hi Jacek,
.../...
>>
>> These device tree comes from out firmware ... which is immutable .
>
> How the firmware is related to kernel? These bindings are for kernel,
> not for the firmw
Jacek Anaszewski writes:
>> These device tree comes from out firmware ... which is immutable .
>
> How the firmware is related to kernel? These bindings are for kernel,
> not for the firmware.
>
> DT bindings are compiled to *.dtb file which is concatenated with
> zImage. During system boot device
On Thu, 23 Apr 2015 10:55:40 +0530
Vasant Hegde wrote:
> On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
> > Hi Vasant,
> >
>
> Hi Jacek,
>
>
> .../...
>
> >>
> >>>
> >>> From what I can see from the driver code the LEDs are set with:
> >>>
> >>> opal_leds_set_ind(token, loc_code, led_mask,
On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
> Hi Vasant,
>
Hi Jacek,
.../...
>>
>>>
>>> From what I can see from the driver code the LEDs are set with:
>>>
>>> opal_leds_set_ind(token, loc_code, led_mask, led_value,
>>> &max_led_type);
>>>
>>> and their state can be read with:
>>>
>>> opa
Hi Vasant,
On 20.04.2015 17:53, Vasant Hegde wrote:
> On 04/20/2015 08:50 PM, Jacek Anaszewski wrote:
>> On 04/20/2015 02:34 PM, Vasant Hegde wrote:
>>> On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
Hi Vasant,
I'd like to clarify some details regarding your explanation.
Vasant Hegde writes:
> On 04/16/2015 12:20 AM, Stewart Smith wrote:
>> Jacek Anaszewski writes:
+static struct platform_driver powernv_led_driver = {
+ .probe = powernv_led_probe,
+ .remove = powernv_led_remove,
+ .driver = {
+ .name = "powernv-led-driver",
>
On 04/20/2015 08:50 PM, Jacek Anaszewski wrote:
> On 04/20/2015 02:34 PM, Vasant Hegde wrote:
>> On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
>>> Hi Vasant,
>>>
>>> I'd like to clarify some details regarding your explanation.
>>>
>>> On 04/15/2015 12:15 PM, Vasant Hegde wrote:
>>> [...]
>>
>
On 04/20/2015 02:34 PM, Vasant Hegde wrote:
On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
[...]
In Power Systems LEDs are overloaded (meaning same LED is used for identify an
On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
> I'd like to clarify some details regarding your explanation.
>
> On 04/15/2015 12:15 PM, Vasant Hegde wrote:
> [...]
In Power Systems LEDs are overloaded (meaning same LED is used for
identify and
fault dependin
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
[...]
In Power Systems LEDs are overloaded (meaning same LED is used for identify and
fault depending on their state --- blinking = identify and solid = fault).
Hence here appe
Resending, as there were some problems with delivering this message.
Original Message
Subject: Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
Date: Thu, 16 Apr 2015 13:34:17 +0200
From: Jacek Anaszewski
To: Vasant Hegde
CC: linuxppc-dev@lists.ozlabs.org
On 04/16/2015 12:26 PM, Vasant Hegde wrote:
On 04/16/2015 02:21 PM, Jacek Anaszewski wrote:
Hi Vasant,
On 04/16/2015 08:52 AM, Vasant Hegde wrote:
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
Hi V
On 04/16/2015 02:21 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
> On 04/16/2015 08:52 AM, Vasant Hegde wrote:
>> On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
>>> On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>>
>> Hi Jacek,
>>
>
Hi Vasant,
On 04/16/2015 08:52 AM, Vasant Hegde wrote:
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
.../...
I mean, we have to retain the state of LED across system rebo
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
> On 04/15/2015 12:15 PM, Vasant Hegde wrote:
>> On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
>>> Hi Vasant,
Hi Jacek,
.../...
>
I mean, we have to retain the state of LED across system reboot.
>>>
>>> Static variables are reinitia
On 04/16/2015 12:20 AM, Stewart Smith wrote:
> Jacek Anaszewski writes:
>>> +static struct platform_driver powernv_led_driver = {
>>> + .probe = powernv_led_probe,
>>> + .remove = powernv_led_remove,
>>> + .driver = {
>>> + .name = "powernv-led-driver",
>>> + .owner = TH
Jacek Anaszewski writes:
>> +static struct platform_driver powernv_led_driver = {
>> +.probe = powernv_led_probe,
>> +.remove = powernv_led_remove,
>> +.driver = {
>> +.name = "powernv-led-driver",
>> +.owner = THIS_MODULE,
>> +.of_match_table = pow
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
> On 04/15/2015 08:26 AM, Vasant Hegde wrote:
>> On 04/14/2015 08:50 PM, Jacek Anaszewski wrote:
>>> Hi Vasant,
>>
>> Hi Jacek,
>>
This patch implements LED driver for PowerNV platform using the existing
generic LED clas
On 04/14/2015 08:50 PM, Jacek Anaszewski wrote:
> Hi Vasant,
Hi Jacek,
>>
>> This patch implements LED driver for PowerNV platform using the existing
>> generic LED class framework. It registers classdev structures for all
>> individual LEDs detected on the system through LED specific device tree
Hi Vasant,
On 03/20/2015 12:04 PM, Vasant Hegde wrote:
From: Anshuman Khandual
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework. It registers classdev structures for all
individual LEDs detected on the system through LED specific device tree
On 03/25/2015 10:51 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2015-03-20 at 16:34 +0530, Vasant Hegde wrote:
>> From: Anshuman Khandual
>>
>> This patch implements LED driver for PowerNV platform using the existing
>> generic LED class framework. It registers classdev structures for all
>> indiv
On Fri, 2015-03-20 at 16:34 +0530, Vasant Hegde wrote:
> From: Anshuman Khandual
>
> This patch implements LED driver for PowerNV platform using the existing
> generic LED class framework. It registers classdev structures for all
> individual LEDs detected on the system through LED specific devic
From: Anshuman Khandual
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework. It registers classdev structures for all
individual LEDs detected on the system through LED specific device tree
nodes. Device tree nodes specify what all kind of LEDs pre
35 matches
Mail list logo
