linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>, <pavel@ucw.cz>
Cc: <linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v14 13/19] leds: lp55xx: Add multicolor framework support to lp55xx
Date: Fri, 25 Oct 2019 13:18:46 -0500	[thread overview]
Message-ID: <74868064-6a40-172e-ce28-94722e1f1aaf@ti.com> (raw)
In-Reply-To: <bfcae4c2-aa4d-8460-528f-6029d7a87b4d@gmail.com>

Jacek

On 10/25/19 1:13 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 10/25/19 7:57 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 10/22/19 12:41 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 10/22/19 6:37 PM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> On 10/18/19 4:56 PM, Jacek Anaszewski wrote:
>>>>> On 10/18/19 11:48 PM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>> +        ret = lp5xx_parse_channel_child(child, cfg, i);
>>>>>> I went into details of this parsing and finally came up with
>>>>>> the code which is a bit greater in size, but IMHO cleaner.
>>>>>> Note changes in variable naming. It is not even compile-tested.
>>>>>>
>>>>>> static int lp55xx_parse_common_child(struct device_node *np,
>>>>>>                                        struct lp55xx_led_config *cfg,
>>>>>>                                        int led_number, int *chan_nr)
>>>>>> {
>>>>>>            int ret;
>>>>>>
>>>>>>            of_property_read_string(np, "chan-name",
>>>>>>                                    &cfg[led_number].name);
>>>>>>            of_property_read_u8(np, "led-cur",
>>>>>>                                &cfg[led_number].led_current);
>>>>>>            of_property_read_u8(np, "max-cur",
>>>>>>                                &cfg[led_number].max_current);
>>>>>>
>>>>>>            ret = of_property_read_u32(np, "reg", chan_nr);
>>>>>>            if (ret)
>>>>>>                    return ret;
>>>>>>
>>>>>>            if (chan_nr < 0 || chan_nr > cfg->max_chan_nr) /* side note:
>>>>>> new
>>>>>> max_chan_nr property needed in cfg */
>>>>>>                    return -EINVAL;
>>>>>>
>>>>>>            return 0;
>>>>>> }
>>>>>>
>>>>>> static int lp55xx_parse_mutli_led_child(struct device_node *np,
>>>>>>                                            struct lp55xx_led_config
>>>>>> *cfg,
>>>>>>                                            int child_number,
>>>>>>                                            int color_number)
>>>>>> {
>>>>>>            int chan_nr, color_id;
>>>>>>
>>>>>>            ret = lp55xx_parse_common_child(child, cfg, child_number,
>>>>>> color_number,
>>>>>>                                            &chan_nr);
>>>>>>            if (ret)
>>>>>>                    return ret;
>>>>>>
>>>>>>            ret = of_property_read_u32(child, "color", &color_id);
>>>>>>            if (ret)
>>>>>>                   return ret;
>>>>>>
>>>>>>            cfg[child_number].color_components[color_number].color_id =
>>>>>> color_id;
>>>>>>           
>>>>>> cfg[child_number].color_components[color_number].output_num =
>>>>>> chan_nr;
>>>>>>            set_bit(color_id, &cfg[child_number].available_colors);
>>>>>>
>>>>>>            return 0;
>>>>>> }
>>>>>>
>>>>>> staitc int lp55xx_parse_mutli_led(struct device_node *np,
>>>>>>                                      struct lp55xx_led_config *cfg,
>>>>>>                                      int child_number)
>>>>>> {
>>>>>>            struct device_node *child;
>>>>>>            int num_colors = 0, i = 0;
>>>>> s/, i = 0//
>>>>>
>>>>>>            for_each_child_of_node(np, child) {
>>>>>>                    ret = lp55xx_parse_mutli_led_child(child, cfg,
>>>>>> num_colors,
>>>>>>                                                       child_number, i))
>>>>> Replace above call with below:
>>>>>
>>>>> ret = lp55xx_parse_mutli_led_child(child, cfg, child_number,
>>>>> num_colors);
>>>>>
>>>> I applied your DT parser patch from the v13 series.  Which eliminates
>>>> this comment correct?
>>> Yes, it contains this fix.
>>>
>> OK I added your patch and it broke a lot of the DT parsing for the LP55xx.
>>
>> I would prefer to stick with the original code without having to
>> re-write this again.
> Let me test that with Qemu first.
>
max_channel is never set so not sure where that is supposed to come from 
since each child device has different number of channels.  And if the 
user has to populate that information from the DT then it does not make 
sense as the user would already be aware of the number of channels.  
This information would have to come from the child device some how and 
the children do not have access to the structure to set it.

In checking the chan_nr to the max_channels you are comparing a pointer 
to an integer.  Easy fix but did not solve the registration issues.

cfg->num_colors is not set anywhere so the registration always goes to 
base led_registration.  Unless we key off a different value to determine 
to register to multicolor class or not.  Or we default this to the 
multi_class registration to figure out how to register based on 
available_colors.

That is what I am seeing so far in my debugging and I still don't have 
it working.

Dan


  reply	other threads:[~2019-10-25 18:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 12:25 [PATCH v14 00/19] MultiColor Framework v14 Dan Murphy
2019-10-18 12:25 ` [PATCH v14 01/19] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-10-18 12:25 ` [PATCH v14 02/19] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-10-18 12:25 ` [PATCH v14 03/19] " Dan Murphy
2019-10-18 12:25 ` [PATCH v14 04/19] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-10-18 21:44   ` Jacek Anaszewski
2019-10-23 12:23     ` Dan Murphy
2019-10-18 12:25 ` [PATCH v14 05/19] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-10-18 12:25 ` [PATCH v14 06/19] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-10-18 12:25 ` [PATCH v14 07/19] dt: bindings: lp55xx: Be consistent in the document with LED acronym Dan Murphy
2019-10-18 12:25 ` [PATCH v14 08/19] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2019-10-18 12:25 ` [PATCH v14 09/19] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2019-10-18 12:25 ` [PATCH v14 10/19] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2019-10-18 12:25 ` [PATCH v14 11/19] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2019-10-18 12:25 ` [PATCH v14 12/19] leds: lp55xx: Convert LED class registration to devm_* Dan Murphy
2019-10-18 18:02   ` Jacek Anaszewski
2019-10-18 18:02   ` Jacek Anaszewski
2019-10-18 20:27     ` Dan Murphy
2019-10-18 12:25 ` [PATCH v14 13/19] leds: lp55xx: Add multicolor framework support to lp55xx Dan Murphy
2019-10-18 21:48   ` Jacek Anaszewski
2019-10-18 21:56     ` Jacek Anaszewski
2019-10-22 16:37       ` Dan Murphy
2019-10-22 17:41         ` Jacek Anaszewski
2019-10-25 17:57           ` Dan Murphy
2019-10-25 18:13             ` Jacek Anaszewski
2019-10-25 18:18               ` Dan Murphy [this message]
2019-10-25 18:56                 ` Jacek Anaszewski
2019-10-25 20:07                   ` Dan Murphy
2019-10-23 12:22     ` Dan Murphy
2019-10-24 21:02       ` Jacek Anaszewski
2019-10-18 22:02   ` Jacek Anaszewski
2019-10-23 12:25     ` Dan Murphy
2019-10-18 12:25 ` [PATCH v14 14/19] leds: lp5523: Update the lp5523 code to add multicolor brightness function Dan Murphy
2019-10-18 12:25 ` [PATCH v14 15/19] leds: lp5521: Add multicolor framework multicolor brightness support Dan Murphy
2019-10-18 12:25 ` [PATCH v14 16/19] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2019-10-18 12:25 ` [PATCH v14 17/19] leds: lp5523: Fix checkpatch issues in the code Dan Murphy
2019-10-18 12:25 ` [PATCH v14 18/19] dt: bindings: Update lp55xx binding to recommended LED naming Dan Murphy
2019-10-18 12:25 ` [PATCH v14 19/19] leds: lp55xx-common: Remove extern from lp55xx-common header Dan Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74868064-6a40-172e-ce28-94722e1f1aaf@ti.com \
    --to=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).