From: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> To: "Sean Nyekjær" <sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v2 3/4] iio: ad5755: added full support for devicetree Date: Tue, 9 Feb 2016 21:30:44 +0100 [thread overview] Message-ID: <56BA4C74.9030503@metafoo.de> (raw) In-Reply-To: <56B9A1B2.6030007-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> On 02/09/2016 09:22 AM, Sean Nyekjær wrote: > > On 2016-02-03 15:31, Sean Nyekjaer wrote: >> Devicetree can provide platform data >> >> Signed-off-by: Sean Nyekjaer <sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> > Lars do you have time to look at this before i'm fixing the comments from > Jonathan and Rob :-) The obvious thing is to use '-' instead of '_' since that is the DT convention. Other than that this non-trivial. This is the first binding for such a device and it is always hard to come up with a good ABI without knowing what other similar devices might need to be supported by the same bindings. And it is also not always clear what is hardware description and what is driver policy. The external resistor configuration should be clear, that's a description of the hardware whether the resistor exists or not. For the others it's not so clear. E.g. the DC-to-DC converter configuration, this is most certainly not a description of the hardware. But we could get away with it by saying this is a system level design decision and is made by the system designer based on the operating parameters of the hardware and hence is policy that belongs in the DT. It might make sense to follow what the regulator bindings do here, even though the regulator is not exposed externally. The configuration of the output pin (voltage level, current level, etc) is certainly influenced by the restrictions of the hardware itself. You don't want to allow a configuration that can damage the hardware. But on the other hand it is still a valid usecase for some applications to switch between two setups at runtime, which is something you said you need to be able to do. Here we might want to use something similar to pinctrl where the devicetree can offer a selection of valid configurations and the driver can switch between those configurations. - Lars [...] >> +static struct ad5755_platform_data *ad5755_parse_dt(struct device *dev) >> +{ >> + struct device_node *np = dev->of_node; >> + struct device_node *pp; >> + struct ad5755_platform_data *pdata; >> + unsigned int tmp; >> + unsigned int tmparray[3]; >> + int devnr; >> + >> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); >> + if (!pdata) >> + return NULL; >> + >> + pdata->ext_dc_dc_compenstation_resistor = >> + of_property_read_bool(np, >> "adi,ext_dc_dc_compenstation_resistor"); >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_phase", &tmp)) >> + pdata->dc_dc_phase = tmp; >> + else >> + pdata->dc_dc_phase = AD5755_DC_DC_PHASE_ALL_SAME_EDGE; >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_freq", &tmp)) >> + pdata->dc_dc_freq = tmp; >> + else >> + pdata->dc_dc_freq = AD5755_DC_DC_FREQ_410kHZ; >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_maxv", &tmp)) >> + pdata->dc_dc_maxv = tmp; >> + else >> + pdata->dc_dc_maxv = AD5755_DC_DC_MAXV_23V; >> + >> + devnr = 0; >> + for_each_child_of_node(np, pp) { >> + if (devnr > AD5755_NUM_CHANNELS) { >> + dev_err(dev, "There is to many channels defined in DT\n"); >> + goto error_out; >> + } >> + >> + if (!of_property_read_u32(pp, "adi,mode", &tmp)) >> + pdata->dac[devnr].mode = tmp; >> + else >> + pdata->dac[devnr].mode = AD5755_MODE_CURRENT_4mA_20mA; >> + >> + pdata->dac[devnr].ext_current_sense_resistor = >> + of_property_read_bool(pp, "adi,ext_current_sense_resistor"); >> + >> + pdata->dac[devnr].enable_voltage_overrange = >> + of_property_read_bool(pp, "adi,enable_voltage_overrange"); >> + if (!of_property_read_u32_array(pp, "adi,slew", tmparray, 3)) { >> + pdata->dac[devnr].slew.enable = tmparray[0]; >> + pdata->dac[devnr].slew.rate = tmparray[1]; >> + pdata->dac[devnr].slew.step_size = tmparray[2]; >> + } else { >> + pdata->dac[devnr].slew.enable = false; >> + pdata->dac[devnr].slew.rate = AD5755_SLEW_RATE_64k; >> + pdata->dac[devnr].slew.step_size = AD5755_SLEW_STEP_SIZE_1; >> + } >> + >> + devnr++; >> + } >> + >> + return pdata; [...]
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de> To: "Sean Nyekjær" <sean.nyekjaer@prevas.dk>, linux-iio@vger.kernel.org Cc: devicetree@vger.kernel.org Subject: Re: [PATCH v2 3/4] iio: ad5755: added full support for devicetree Date: Tue, 9 Feb 2016 21:30:44 +0100 [thread overview] Message-ID: <56BA4C74.9030503@metafoo.de> (raw) In-Reply-To: <56B9A1B2.6030007@prevas.dk> On 02/09/2016 09:22 AM, Sean Nyekjær wrote: > > On 2016-02-03 15:31, Sean Nyekjaer wrote: >> Devicetree can provide platform data >> >> Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> > Lars do you have time to look at this before i'm fixing the comments from > Jonathan and Rob :-) The obvious thing is to use '-' instead of '_' since that is the DT convention. Other than that this non-trivial. This is the first binding for such a device and it is always hard to come up with a good ABI without knowing what other similar devices might need to be supported by the same bindings. And it is also not always clear what is hardware description and what is driver policy. The external resistor configuration should be clear, that's a description of the hardware whether the resistor exists or not. For the others it's not so clear. E.g. the DC-to-DC converter configuration, this is most certainly not a description of the hardware. But we could get away with it by saying this is a system level design decision and is made by the system designer based on the operating parameters of the hardware and hence is policy that belongs in the DT. It might make sense to follow what the regulator bindings do here, even though the regulator is not exposed externally. The configuration of the output pin (voltage level, current level, etc) is certainly influenced by the restrictions of the hardware itself. You don't want to allow a configuration that can damage the hardware. But on the other hand it is still a valid usecase for some applications to switch between two setups at runtime, which is something you said you need to be able to do. Here we might want to use something similar to pinctrl where the devicetree can offer a selection of valid configurations and the driver can switch between those configurations. - Lars [...] >> +static struct ad5755_platform_data *ad5755_parse_dt(struct device *dev) >> +{ >> + struct device_node *np = dev->of_node; >> + struct device_node *pp; >> + struct ad5755_platform_data *pdata; >> + unsigned int tmp; >> + unsigned int tmparray[3]; >> + int devnr; >> + >> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); >> + if (!pdata) >> + return NULL; >> + >> + pdata->ext_dc_dc_compenstation_resistor = >> + of_property_read_bool(np, >> "adi,ext_dc_dc_compenstation_resistor"); >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_phase", &tmp)) >> + pdata->dc_dc_phase = tmp; >> + else >> + pdata->dc_dc_phase = AD5755_DC_DC_PHASE_ALL_SAME_EDGE; >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_freq", &tmp)) >> + pdata->dc_dc_freq = tmp; >> + else >> + pdata->dc_dc_freq = AD5755_DC_DC_FREQ_410kHZ; >> + >> + if (!of_property_read_u32(np, "adi,dc_dc_maxv", &tmp)) >> + pdata->dc_dc_maxv = tmp; >> + else >> + pdata->dc_dc_maxv = AD5755_DC_DC_MAXV_23V; >> + >> + devnr = 0; >> + for_each_child_of_node(np, pp) { >> + if (devnr > AD5755_NUM_CHANNELS) { >> + dev_err(dev, "There is to many channels defined in DT\n"); >> + goto error_out; >> + } >> + >> + if (!of_property_read_u32(pp, "adi,mode", &tmp)) >> + pdata->dac[devnr].mode = tmp; >> + else >> + pdata->dac[devnr].mode = AD5755_MODE_CURRENT_4mA_20mA; >> + >> + pdata->dac[devnr].ext_current_sense_resistor = >> + of_property_read_bool(pp, "adi,ext_current_sense_resistor"); >> + >> + pdata->dac[devnr].enable_voltage_overrange = >> + of_property_read_bool(pp, "adi,enable_voltage_overrange"); >> + if (!of_property_read_u32_array(pp, "adi,slew", tmparray, 3)) { >> + pdata->dac[devnr].slew.enable = tmparray[0]; >> + pdata->dac[devnr].slew.rate = tmparray[1]; >> + pdata->dac[devnr].slew.step_size = tmparray[2]; >> + } else { >> + pdata->dac[devnr].slew.enable = false; >> + pdata->dac[devnr].slew.rate = AD5755_SLEW_RATE_64k; >> + pdata->dac[devnr].slew.step_size = AD5755_SLEW_STEP_SIZE_1; >> + } >> + >> + devnr++; >> + } >> + >> + return pdata; [...]
next prev parent reply other threads:[~2016-02-09 20:30 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-03 14:31 [PATCH v2 1/4] iio: ad5755: add support for dt bindings Sean Nyekjaer 2016-02-03 14:31 ` Sean Nyekjaer [not found] ` <1454509864-32285-1-git-send-email-sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 2016-02-03 14:31 ` [PATCH v2 2/4] iio: ad5755: Add DT binding documentation Sean Nyekjaer 2016-02-03 14:31 ` Sean Nyekjaer [not found] ` <1454509864-32285-2-git-send-email-sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 2016-02-03 14:31 ` [PATCH v2 3/4] iio: ad5755: added full support for devicetree Sean Nyekjaer 2016-02-03 14:31 ` Sean Nyekjaer [not found] ` <1454509864-32285-3-git-send-email-sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 2016-02-03 14:31 ` [PATCH v2 4/4] iio: ad5755: Add full DT binding documentation Sean Nyekjaer 2016-02-03 14:31 ` Sean Nyekjaer [not found] ` <1454509864-32285-4-git-send-email-sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 2016-02-06 18:30 ` Jonathan Cameron 2016-02-06 18:30 ` Jonathan Cameron [not found] ` <56B63BAC.2040001-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2016-02-08 17:37 ` Rob Herring 2016-02-08 17:37 ` Rob Herring 2016-02-09 8:22 ` [PATCH v2 3/4] iio: ad5755: added full support for devicetree Sean Nyekjær 2016-02-09 8:22 ` Sean Nyekjær [not found] ` <56B9A1B2.6030007-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org> 2016-02-09 20:30 ` Lars-Peter Clausen [this message] 2016-02-09 20:30 ` Lars-Peter Clausen [not found] ` <56BA4C74.9030503-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> 2016-02-16 13:46 ` Sean Nyekjær 2016-02-16 13:46 ` Sean Nyekjær 2016-02-06 18:36 ` [PATCH v2 2/4] iio: ad5755: Add DT binding documentation Jonathan Cameron 2016-02-06 18:36 ` Jonathan Cameron
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=56BA4C74.9030503@metafoo.de \ --to=lars-qo5elluwu/uelga04laivw@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=sean.nyekjaer-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.