Dan,OKÂ I got it limping along now by passing in the chip->cfg to the populate data along with rearranging the child probe.
On 10/25/19 8:18 PM, Dan Murphy wrote:
JacekThis was my silent assumption that the child will initialize that.
On 10/25/19 1:13 PM, Jacek Anaszewski wrote:
Dan,max_channel is never set so not sure where that is supposed to come from
On 10/25/19 7:57 PM, Dan Murphy wrote:
JacekLet me test that with Qemu first.
On 10/22/19 12:41 PM, Jacek Anaszewski wrote:
Dan,OK I added your patch and it broke a lot of the DT parsing for the
On 10/22/19 6:37 PM, Dan Murphy wrote:
JacekYes, it contains this fix.
On 10/18/19 4:56 PM, Jacek Anaszewski wrote:
On 10/18/19 11:48 PM, Jacek Anaszewski wrote:I applied your DT parser patch from the v13 series. Which eliminates
Dan,+ÂÂÂÂÂÂÂ ret = lp5xx_parse_channel_child(child, cfg, i);
I went into details of this parsing and finally came up withs/, i = 0//
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;
ÂÂÂÂÂÂÂÂÂÂ for_each_child_of_node(np, child) {Replace above call with below:
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ret = lp55xx_parse_mutli_led_child(child, cfg,
num_colors,
child_number, i))
ret = lp55xx_parse_mutli_led_child(child, cfg, child_number,
num_colors);
this comment correct?
LP55xx.
I would prefer to stick with the original code without having to
re-write this again.
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.
And I was not thoroughly seeking the most proper place for this
property, just chose first I could think . You are free to
change its location so that it was accessible for the child.
In checking the chan_nr to the max_channels you are comparing a pointerYou need to add below at the end of lp55xx_parse_mutli_led():
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.
cfg[child_number].num_colors = num_colors;
and below in led_parse_logical_led() at the end of the
"if (ret)" branch.
cfg[child_number].num_colors = 1;
Yes I know you only compile tested this.That is what I am seeing so far in my debugging and I still don't haveI didn't pretend it was flawless, just wanted to show general idea
it working.
how I would see that.