From: <Eugen.Hristev@microchip.com> To: <jic23@kernel.org>, <alexandre.belloni@bootlin.com> Cc: <robh+dt@kernel.org>, <Nicolas.Ferre@microchip.com>, <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-rtc@vger.kernel.org>, <a.zummo@towertech.it>, <Ludovic.Desroches@microchip.com> Subject: Re: [PATCH 04/10] rtc: at91rm9200: use of_platform_populate as return value Date: Thu, 9 Jan 2020 11:19:45 +0000 [thread overview] Message-ID: <7e67d601-e17e-f82c-edeb-824fc3dd89db@microchip.com> (raw) In-Reply-To: <20191223111636.4698123b@archlinux> On 23.12.2019 13:16, Jonathan Cameron wrote: > On Thu, 19 Dec 2019 11:23:21 +0100 > Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > >> On 19/12/2019 09:15:02+0000, Eugen.Hristev@microchip.com wrote: >>> >>> >>> On 18.12.2019 18:58, Alexandre Belloni wrote: >>>> On 18/12/2019 16:52:21+0000, Eugen.Hristev@microchip.com wrote: >>>>> >>>>> >>>>> On 18.12.2019 18:43, Alexandre Belloni wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On 18/12/2019 16:24:00+0000, Eugen.Hristev@microchip.com wrote: >>>>>>> From: Eugen Hristev <eugen.hristev@microchip.com> >>>>>>> >>>>>>> This allows the RTC node to have child nodes in DT. >>>>>>> This allows subnodes to be probed. >>>>>>> >>>>>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> >>>>>>> --- >>>>>>> drivers/rtc/rtc-at91rm9200.c | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c >>>>>>> index 3b833e0..f1b5b3d 100644 >>>>>>> --- a/drivers/rtc/rtc-at91rm9200.c >>>>>>> +++ b/drivers/rtc/rtc-at91rm9200.c >>>>>>> @@ -421,7 +421,7 @@ static int __init at91_rtc_probe(struct platform_device *pdev) >>>>>>> at91_rtc_write_ier(AT91_RTC_SECEV); >>>>>>> >>>>>>> dev_info(&pdev->dev, "AT91 Real Time Clock driver.\n"); >>>>>>> - return 0; >>>>>>> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); >>>>>>> >>>>>> >>>>>> You can avoid the DT binding change and DT parsing by using >>>>>> platform_add_device here. I don't think there is any point describing >>>>>> the trigger as a child node (a watchdog functionality wouldn't be >>>>>> described for example). Hi Alexandre, I started to work on this, I am trying to add and probe the rtc_adc_trigger with platform_device_add. However, some issues arise: this means that the rtc_adc_trigger will not be OF-compatible, so, how can I identify the driver to probe ? Second, by adding a new platform device from the RTC driver, would mean that I would have to supply it's probe/remove functions, which I cannot have here. Those are in the rtc_adc_trigger iio driver. In fact, the question is, which is the mechanism you suggested, to be able to probe the rtc_adc_trigger, from inside the rtc driver, without using a child node in DT, as you requested ? The rtc_adc_trigger needs a MEM resource, and a parent, and it must reside inside the IIO subsystem. Thanks, Eugen >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> It's needed because the ADC needs a link to the trigger device. This is >>>>> a hardware link inside the SoC, so I thought the best way is to describe >>>>> this hardware is in the Device Tree. >>>>> Otherwise the ADC node is unaware of the RTC triggering possibility. >>>>> If we just assign the RTC trigger device to the ADC through the sysfs, >>>>> the ADC cannot distinguish between the RTC trigger and other various >>>>> triggers which can be attached. >>>>> >>>> >>>> I'm not sure this links is required but I will let Jonathan review. Even >>>> if it is needed, you can still use the rtc node to describe that link. >>> >>> Actually, the RTC node could potentially have two different ADC >>> triggers. There is another OUT1 field that can do a second trigger for >>> the ADC only for the last channel. Future development might add this >>> trigger, so, with that in mind, I think it's best to link the exact >>> trigger and not the RTC node. >> >> Nothing prevents you from using an index with the phandle (and I would >> add a type in that case then). Having subnodes in the DT is not really a >> good idea. The IP is the RTC, it just happens to have some outputs. >> See what has been done for the PMC. >> >> > > If it can be done either way, let's avoid adding to the rtc dt binding. > > Jonathan > >
WARNING: multiple messages have this Message-ID (diff)
From: <Eugen.Hristev@microchip.com> To: <jic23@kernel.org>, <alexandre.belloni@bootlin.com> Cc: linux-rtc@vger.kernel.org, devicetree@vger.kernel.org, a.zummo@towertech.it, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Ludovic.Desroches@microchip.com, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 04/10] rtc: at91rm9200: use of_platform_populate as return value Date: Thu, 9 Jan 2020 11:19:45 +0000 [thread overview] Message-ID: <7e67d601-e17e-f82c-edeb-824fc3dd89db@microchip.com> (raw) In-Reply-To: <20191223111636.4698123b@archlinux> On 23.12.2019 13:16, Jonathan Cameron wrote: > On Thu, 19 Dec 2019 11:23:21 +0100 > Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > >> On 19/12/2019 09:15:02+0000, Eugen.Hristev@microchip.com wrote: >>> >>> >>> On 18.12.2019 18:58, Alexandre Belloni wrote: >>>> On 18/12/2019 16:52:21+0000, Eugen.Hristev@microchip.com wrote: >>>>> >>>>> >>>>> On 18.12.2019 18:43, Alexandre Belloni wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On 18/12/2019 16:24:00+0000, Eugen.Hristev@microchip.com wrote: >>>>>>> From: Eugen Hristev <eugen.hristev@microchip.com> >>>>>>> >>>>>>> This allows the RTC node to have child nodes in DT. >>>>>>> This allows subnodes to be probed. >>>>>>> >>>>>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> >>>>>>> --- >>>>>>> drivers/rtc/rtc-at91rm9200.c | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c >>>>>>> index 3b833e0..f1b5b3d 100644 >>>>>>> --- a/drivers/rtc/rtc-at91rm9200.c >>>>>>> +++ b/drivers/rtc/rtc-at91rm9200.c >>>>>>> @@ -421,7 +421,7 @@ static int __init at91_rtc_probe(struct platform_device *pdev) >>>>>>> at91_rtc_write_ier(AT91_RTC_SECEV); >>>>>>> >>>>>>> dev_info(&pdev->dev, "AT91 Real Time Clock driver.\n"); >>>>>>> - return 0; >>>>>>> + return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); >>>>>>> >>>>>> >>>>>> You can avoid the DT binding change and DT parsing by using >>>>>> platform_add_device here. I don't think there is any point describing >>>>>> the trigger as a child node (a watchdog functionality wouldn't be >>>>>> described for example). Hi Alexandre, I started to work on this, I am trying to add and probe the rtc_adc_trigger with platform_device_add. However, some issues arise: this means that the rtc_adc_trigger will not be OF-compatible, so, how can I identify the driver to probe ? Second, by adding a new platform device from the RTC driver, would mean that I would have to supply it's probe/remove functions, which I cannot have here. Those are in the rtc_adc_trigger iio driver. In fact, the question is, which is the mechanism you suggested, to be able to probe the rtc_adc_trigger, from inside the rtc driver, without using a child node in DT, as you requested ? The rtc_adc_trigger needs a MEM resource, and a parent, and it must reside inside the IIO subsystem. Thanks, Eugen >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> It's needed because the ADC needs a link to the trigger device. This is >>>>> a hardware link inside the SoC, so I thought the best way is to describe >>>>> this hardware is in the Device Tree. >>>>> Otherwise the ADC node is unaware of the RTC triggering possibility. >>>>> If we just assign the RTC trigger device to the ADC through the sysfs, >>>>> the ADC cannot distinguish between the RTC trigger and other various >>>>> triggers which can be attached. >>>>> >>>> >>>> I'm not sure this links is required but I will let Jonathan review. Even >>>> if it is needed, you can still use the rtc node to describe that link. >>> >>> Actually, the RTC node could potentially have two different ADC >>> triggers. There is another OUT1 field that can do a second trigger for >>> the ADC only for the last channel. Future development might add this >>> trigger, so, with that in mind, I think it's best to link the exact >>> trigger and not the RTC node. >> >> Nothing prevents you from using an index with the phandle (and I would >> add a type in that case then). Having subnodes in the DT is not really a >> good idea. The IP is the RTC, it just happens to have some outputs. >> See what has been done for the PMC. >> >> > > If it can be done either way, let's avoid adding to the rtc dt binding. > > Jonathan > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-09 11:19 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-18 16:23 [PATCH 00/10] Enhancements to at91-sama5d2_adc and rtc trigger Eugen.Hristev 2019-12-18 16:23 ` Eugen.Hristev 2019-12-18 16:23 ` [PATCH 02/10] dt-bindings: iio: adc: at91-sama5d2: add rtc-trigger optional property Eugen.Hristev 2019-12-18 16:23 ` Eugen.Hristev 2019-12-23 11:58 ` Jonathan Cameron 2019-12-23 11:58 ` Jonathan Cameron 2019-12-18 16:23 ` [PATCH 01/10] iio: adc: at91-sama5d2_adc: update for other trigger usage Eugen.Hristev 2019-12-18 16:23 ` Eugen.Hristev 2019-12-23 11:56 ` Jonathan Cameron 2019-12-23 11:56 ` Jonathan Cameron 2019-12-18 16:23 ` [PATCH 03/10] dt-bindings: iio: trigger: at91-rtc-trigger: add bindings Eugen.Hristev 2019-12-18 16:23 ` Eugen.Hristev 2019-12-23 12:01 ` Jonathan Cameron 2019-12-23 12:01 ` Jonathan Cameron 2019-12-18 16:24 ` [PATCH 04/10] rtc: at91rm9200: use of_platform_populate as return value Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-18 16:43 ` Alexandre Belloni 2019-12-18 16:43 ` Alexandre Belloni 2019-12-18 16:52 ` Eugen.Hristev 2019-12-18 16:52 ` Eugen.Hristev 2019-12-18 16:58 ` Alexandre Belloni 2019-12-18 16:58 ` Alexandre Belloni 2019-12-19 9:15 ` Eugen.Hristev 2019-12-19 9:15 ` Eugen.Hristev 2019-12-19 10:23 ` Alexandre Belloni 2019-12-19 10:23 ` Alexandre Belloni 2019-12-23 11:16 ` Jonathan Cameron 2019-12-23 11:16 ` Jonathan Cameron 2020-01-09 11:19 ` Eugen.Hristev [this message] 2020-01-09 11:19 ` Eugen.Hristev 2020-01-09 11:52 ` Alexandre Belloni 2020-01-09 11:52 ` Alexandre Belloni 2019-12-18 16:24 ` [PATCH 06/10] iio: adc: at91-sama5d2_adc: handle unfinished conversions Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-23 12:20 ` Jonathan Cameron 2019-12-23 12:20 ` Jonathan Cameron 2019-12-18 16:24 ` [PATCH 05/10] iio: trigger: at91-rtc-trigger: introduce at91 rtc adc trigger driver Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-23 12:17 ` Jonathan Cameron 2019-12-23 12:17 ` Jonathan Cameron 2019-12-18 16:24 ` [PATCH 08/10] iio: adc: at91-sama5d2_adc: implement RTC triggering Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-23 12:28 ` Jonathan Cameron 2019-12-23 12:28 ` Jonathan Cameron 2019-12-18 16:24 ` [PATCH 07/10] iio: adc: at91-sama5d2_adc: fix differential channels in triggered mode Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-23 12:23 ` Jonathan Cameron 2019-12-23 12:23 ` Jonathan Cameron 2019-12-18 16:24 ` [PATCH 10/10] ARM: dts: at91: sama5d2_xplained: enable rtc_adc_trigger Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev 2019-12-18 16:24 ` [PATCH 09/10] ARM: dts: at91: sama5d2: add rtc_adc_trigger node Eugen.Hristev 2019-12-18 16:24 ` Eugen.Hristev
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=7e67d601-e17e-f82c-edeb-824fc3dd89db@microchip.com \ --to=eugen.hristev@microchip.com \ --cc=Ludovic.Desroches@microchip.com \ --cc=Nicolas.Ferre@microchip.com \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=devicetree@vger.kernel.org \ --cc=jic23@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-iio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rtc@vger.kernel.org \ --cc=robh+dt@kernel.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.