[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On Wed, Aug 18, 2021 at 10:04:07AM +0100, Andre Przywara wrote: > On Tue, 17 Aug 2021 09:38:10 +0200 > Maxime Ripard wrote: > > Hi Maxime, > > > On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: > > > On Mon, 26 Jul 2021 16:41:37 +0200 > > > Maxime Ripard wrote: > > > > > > > Hi, > > > > > > > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > > > > > Add the obvious compatible name to the existing RTC binding. > > > > > The actual RTC part of the device uses a different day/month/year > > > > > storage scheme, so it's not compatible with the previous devices. > > > > > Also the clock part is quite different, as there is no external 32K > > > > > LOSC > > > > > oscillator input. > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > > > > > > --- > > > > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 > > > > > ++ > > > > > 1 file changed, 14 insertions(+) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > > index beeb90e55727..d8a6500e5840 100644 > > > > > --- > > > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > > +++ > > > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > > @@ -26,6 +26,7 @@ properties: > > > > >- const: allwinner,sun50i-a64-rtc > > > > >- const: allwinner,sun8i-h3-rtc > > > > >- const: allwinner,sun50i-h6-rtc > > > > > + - const: allwinner,sun50i-h616-rtc > > > > > > > > > >reg: > > > > > maxItems: 1 > > > > > @@ -104,6 +105,19 @@ allOf: > > > > >minItems: 3 > > > > >maxItems: 3 > > > > > > > > > > + - if: > > > > > + properties: > > > > > +compatible: > > > > > + contains: > > > > > +const: allwinner,sun50i-h616-rtc > > > > > + > > > > > +then: > > > > > + properties: > > > > > +clock-output-names: > > > > > + minItems: 3 > > > > > + maxItems: 3 > > > > > > > > You don't need both of them when they are equal > > > > > > > > > +clocks: false > > > > > + > > > > > > > > It's not entirely clear to me what those clocks are about though. If we > > > > look at the clock output in the user manual, it looks like there's only > > > > two clocks that are actually being output: the 32k "fanout" clock and > > > > the losc. What are the 3 you're talking about?] > > > > > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce > > > clock (/32), and the multiplexed PAD. > > > > But the input and debounce clock is only for the RTC itself right? So it > > should be local to the driver and doesn't need to be made available to > > the other drivers > > I understood "debounce" as being the clock used for the pinctrl > debouncer. What would it debounce otherwise? Do you think that this > "debounce circuit" is something internal to the RTC and is totally > irrelevant for us? I don't think that's it. The Debounce circuit is after the 32 divider, so we have a clock rate of 1kHz (Figure 3-35, page 275) The PIO Interrupt debouncing can use either a 32kHz or 24MHz clock, so the rates don't match, and given the naming would rather be clocked from CLK32K_LOSC. The DCXO_CTRL_REG (Section 3.13.6.13) hints at something different though, it says: " CLK16M_RC_EN 1: Enable 0: Disable The related register configuration is necessary to ensure the reset debounce circuit has a stable clock source. The first time SoC starts up, by default, the reset debounce circuit of SoC uses 32K divided by RC16M. In power-off, software reads the related bit to ensure whether EXT32K is working normally, if it is normal, first switch the clock source of debounce circuit to EXT32K, then close RC16M. Without EXT32K scenario or external RTC scenario, software confirms firstly whether EXT32K is working normally before switching, or software does not close RC16M. " I'm not sure why it would be useful for though > But in general I looked at how many *different* clocks this diagram > describes, and I count: one unaltered ("SYSTEM"), one "div by > 32" (RTC/debounce), and one multiplexed. My aim was to avoid > DT binding changes when we later discover we do need one of them for > something (as happened in the past). So three seemed to be the safe > choice here, to avoid surprises. In the worst case we just will never > reference one of them. My concern is the pretty much the opposite: if we ever need to remove it for whatever reason, if it's in the DT, we can't. While we can totally add it if we need it. > > Either way, what this list is must be documented. > > You mean to overwrite the "description" stanza for clock-output-names? Yes > And can this be done in the per-SoC parts in the later part of the > binding, keeping the existing description? Sure Maxime -- You
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On 8/18/21 4:04 AM, Andre Przywara wrote: > On Tue, 17 Aug 2021 09:38:10 +0200 > Maxime Ripard wrote: > > Hi Maxime, > >> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: >>> On Mon, 26 Jul 2021 16:41:37 +0200 >>> Maxime Ripard wrote: >>> Hi, On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > Add the obvious compatible name to the existing RTC binding. > The actual RTC part of the device uses a different day/month/year > storage scheme, so it's not compatible with the previous devices. > Also the clock part is quite different, as there is no external 32K LOSC > oscillator input. > > Signed-off-by: Andre Przywara > > --- > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > index beeb90e55727..d8a6500e5840 100644 > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > @@ -26,6 +26,7 @@ properties: >- const: allwinner,sun50i-a64-rtc >- const: allwinner,sun8i-h3-rtc >- const: allwinner,sun50i-h6-rtc > + - const: allwinner,sun50i-h616-rtc > >reg: > maxItems: 1 > @@ -104,6 +105,19 @@ allOf: >minItems: 3 >maxItems: 3 > > + - if: > + properties: > +compatible: > + contains: > +const: allwinner,sun50i-h616-rtc > + > +then: > + properties: > +clock-output-names: > + minItems: 3 > + maxItems: 3 You don't need both of them when they are equal > +clocks: false > + It's not entirely clear to me what those clocks are about though. If we look at the clock output in the user manual, it looks like there's only two clocks that are actually being output: the 32k "fanout" clock and the losc. What are the 3 you're talking about?] >>> >>> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce >>> clock (/32), and the multiplexed PAD. >> >> But the input and debounce clock is only for the RTC itself right? So it >> should be local to the driver and doesn't need to be made available to >> the other drivers > > I understood "debounce" as being the clock used for the pinctrl > debouncer. What would it debounce otherwise? Do you think that this > "debounce circuit" is something internal to the RTC and is totally > irrelevant for us? I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz. > But in general I looked at how many *different* clocks this diagram > describes, and I count: one unaltered ("SYSTEM"), one "div by > 32" (RTC/debounce), and one multiplexed. My aim was to avoid > DT binding changes when we later discover we do need one of them for > something (as happened in the past). So three seemed to be the safe > choice here, to avoid surprises. In the worst case we just will never > reference one of them. Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC). >> Either way, what this list is must be documented. > > You mean to overwrite the "description" stanza for clock-output-names? > And can this be done in the per-SoC parts in the later part of the > binding, keeping the existing description? > > Cheers, > Andre > >> Also, it looks like the 32k fanout clock needs at least the hosc or pll-periph in input, so we probably don't want to ask for no parent clock? Do you suggest we fix this for the existing bindings? >>> Well, we never seem to reference the HOSC this way, this was always >>> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we >>> don't support this yet. So I went with 0 input clocks *for now*: the >>> driver can then ignore all clocks, so any clock referenced in the DT >>> later won't cause any harm. This will all be addressed by Samuel's RTC >>> clock patch, which will also touch the H6, IIRC. And it looks like we >>> will need to touch the binding anyway then, but can then just *extend* >>> this. >> >> You mentioned that series several times already and never provided an >> explanation for what it was supposed to be doing except fixing >> everything. What's the general plan for that series? This is my fault for not sending anything yet. Since the initial version of the driver had the RTC providing HOSC, it depended on converting the existing A100, H6, and H616 CCU drivers to use .fw_name for parents, since those drivers hardcode two different global names for HOSC. And I had no opportunit to do that yet.
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
Salut Alex, On Tue, Aug 17, 2021 at 10:13:11AM +0200, Alexandre Belloni wrote: > On 17/08/2021 09:38:10+0200, Maxime Ripard wrote: > > > > It's not entirely clear to me what those clocks are about though. If we > > > > look at the clock output in the user manual, it looks like there's only > > > > two clocks that are actually being output: the 32k "fanout" clock and > > > > the losc. What are the 3 you're talking about?] > > > > > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce > > > clock (/32), and the multiplexed PAD. > > > > But the input and debounce clock is only for the RTC itself right? So it > > should be local to the driver and doesn't need to be made available to > > the other drivers > > > > Shouldn't they be exposed to be able to use assigned-clock? I'm not sure we would even need that? If it's an internal clock to the RTC, then we probably won't ever need to change it from the device tree? Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210819075630.upliivqux4dsohzd%40gilmour. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On Tue, 17 Aug 2021 09:38:10 +0200 Maxime Ripard wrote: Hi Maxime, > On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: > > On Mon, 26 Jul 2021 16:41:37 +0200 > > Maxime Ripard wrote: > > > > > Hi, > > > > > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > > > > Add the obvious compatible name to the existing RTC binding. > > > > The actual RTC part of the device uses a different day/month/year > > > > storage scheme, so it's not compatible with the previous devices. > > > > Also the clock part is quite different, as there is no external 32K LOSC > > > > oscillator input. > > > > > > > > Signed-off-by: Andre Przywara > > > > > > > > --- > > > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > > > > 1 file changed, 14 insertions(+) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > index beeb90e55727..d8a6500e5840 100644 > > > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > > @@ -26,6 +26,7 @@ properties: > > > >- const: allwinner,sun50i-a64-rtc > > > >- const: allwinner,sun8i-h3-rtc > > > >- const: allwinner,sun50i-h6-rtc > > > > + - const: allwinner,sun50i-h616-rtc > > > > > > > >reg: > > > > maxItems: 1 > > > > @@ -104,6 +105,19 @@ allOf: > > > >minItems: 3 > > > >maxItems: 3 > > > > > > > > + - if: > > > > + properties: > > > > +compatible: > > > > + contains: > > > > +const: allwinner,sun50i-h616-rtc > > > > + > > > > +then: > > > > + properties: > > > > +clock-output-names: > > > > + minItems: 3 > > > > + maxItems: 3 > > > > > > You don't need both of them when they are equal > > > > > > > +clocks: false > > > > + > > > > > > It's not entirely clear to me what those clocks are about though. If we > > > look at the clock output in the user manual, it looks like there's only > > > two clocks that are actually being output: the 32k "fanout" clock and > > > the losc. What are the 3 you're talking about?] > > > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce > > clock (/32), and the multiplexed PAD. > > But the input and debounce clock is only for the RTC itself right? So it > should be local to the driver and doesn't need to be made available to > the other drivers I understood "debounce" as being the clock used for the pinctrl debouncer. What would it debounce otherwise? Do you think that this "debounce circuit" is something internal to the RTC and is totally irrelevant for us? But in general I looked at how many *different* clocks this diagram describes, and I count: one unaltered ("SYSTEM"), one "div by 32" (RTC/debounce), and one multiplexed. My aim was to avoid DT binding changes when we later discover we do need one of them for something (as happened in the past). So three seemed to be the safe choice here, to avoid surprises. In the worst case we just will never reference one of them. > Either way, what this list is must be documented. You mean to overwrite the "description" stanza for clock-output-names? And can this be done in the per-SoC parts in the later part of the binding, keeping the existing description? Cheers, Andre > > > > Also, it looks like the 32k fanout clock needs at least the hosc or > > > pll-periph in input, so we probably don't want to ask for no parent > > > clock? > > > > Well, we never seem to reference the HOSC this way, this was always > > somewhat explicit. And yes, there is PLL-PERIPH as an input, but we > > don't support this yet. So I went with 0 input clocks *for now*: the > > driver can then ignore all clocks, so any clock referenced in the DT > > later won't cause any harm. This will all be addressed by Samuel's RTC > > clock patch, which will also touch the H6, IIRC. And it looks like we > > will need to touch the binding anyway then, but can then just *extend* > > this. > > You mentioned that series several times already and never provided an > explanation for what it was supposed to be doing except fixing > everything. What's the general plan for that series? > > Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210818100407.7cf7cfb7%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On 17/08/2021 09:38:10+0200, Maxime Ripard wrote: > > > It's not entirely clear to me what those clocks are about though. If we > > > look at the clock output in the user manual, it looks like there's only > > > two clocks that are actually being output: the 32k "fanout" clock and > > > the losc. What are the 3 you're talking about?] > > > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce > > clock (/32), and the multiplexed PAD. > > But the input and debounce clock is only for the RTC itself right? So it > should be local to the driver and doesn't need to be made available to > the other drivers > Shouldn't they be exposed to be able to use assigned-clock? -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/YRtvl2FWKqAw4b3l%40piout.net.
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
Hi, On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote: > On Mon, 26 Jul 2021 16:41:37 +0200 > Maxime Ripard wrote: > > > Hi, > > > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > > > Add the obvious compatible name to the existing RTC binding. > > > The actual RTC part of the device uses a different day/month/year > > > storage scheme, so it's not compatible with the previous devices. > > > Also the clock part is quite different, as there is no external 32K LOSC > > > oscillator input. > > > > > > Signed-off-by: Andre Przywara > > > > > > --- > > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > > > 1 file changed, 14 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > index beeb90e55727..d8a6500e5840 100644 > > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > > @@ -26,6 +26,7 @@ properties: > > >- const: allwinner,sun50i-a64-rtc > > >- const: allwinner,sun8i-h3-rtc > > >- const: allwinner,sun50i-h6-rtc > > > + - const: allwinner,sun50i-h616-rtc > > > > > >reg: > > > maxItems: 1 > > > @@ -104,6 +105,19 @@ allOf: > > >minItems: 3 > > >maxItems: 3 > > > > > > + - if: > > > + properties: > > > +compatible: > > > + contains: > > > +const: allwinner,sun50i-h616-rtc > > > + > > > +then: > > > + properties: > > > +clock-output-names: > > > + minItems: 3 > > > + maxItems: 3 > > > > You don't need both of them when they are equal > > > > > +clocks: false > > > + > > > > It's not entirely clear to me what those clocks are about though. If we > > look at the clock output in the user manual, it looks like there's only > > two clocks that are actually being output: the 32k "fanout" clock and > > the losc. What are the 3 you're talking about?] > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce > clock (/32), and the multiplexed PAD. But the input and debounce clock is only for the RTC itself right? So it should be local to the driver and doesn't need to be made available to the other drivers Either way, what this list is must be documented. > > Also, it looks like the 32k fanout clock needs at least the hosc or > > pll-periph in input, so we probably don't want to ask for no parent > > clock? > > Well, we never seem to reference the HOSC this way, this was always > somewhat explicit. And yes, there is PLL-PERIPH as an input, but we > don't support this yet. So I went with 0 input clocks *for now*: the > driver can then ignore all clocks, so any clock referenced in the DT > later won't cause any harm. This will all be addressed by Samuel's RTC > clock patch, which will also touch the H6, IIRC. And it looks like we > will need to touch the binding anyway then, but can then just *extend* > this. You mentioned that series several times already and never provided an explanation for what it was supposed to be doing except fixing everything. What's the general plan for that series? Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210817073810.7stuzrppyjf4spab%40gilmour. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On Mon, 26 Jul 2021 16:41:37 +0200 Maxime Ripard wrote: > Hi, > > On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > > Add the obvious compatible name to the existing RTC binding. > > The actual RTC part of the device uses a different day/month/year > > storage scheme, so it's not compatible with the previous devices. > > Also the clock part is quite different, as there is no external 32K LOSC > > oscillator input. > > > > Signed-off-by: Andre Przywara > > > > --- > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > > 1 file changed, 14 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > index beeb90e55727..d8a6500e5840 100644 > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > @@ -26,6 +26,7 @@ properties: > >- const: allwinner,sun50i-a64-rtc > >- const: allwinner,sun8i-h3-rtc > >- const: allwinner,sun50i-h6-rtc > > + - const: allwinner,sun50i-h616-rtc > > > >reg: > > maxItems: 1 > > @@ -104,6 +105,19 @@ allOf: > >minItems: 3 > >maxItems: 3 > > > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: allwinner,sun50i-h616-rtc > > + > > +then: > > + properties: > > +clock-output-names: > > + minItems: 3 > > + maxItems: 3 > > You don't need both of them when they are equal > > > +clocks: false > > + > > It's not entirely clear to me what those clocks are about though. If we > look at the clock output in the user manual, it looks like there's only > two clocks that are actually being output: the 32k "fanout" clock and > the losc. What are the 3 you're talking about?] I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce clock (/32), and the multiplexed PAD. > Also, it looks like the 32k fanout clock needs at least the hosc or > pll-periph in input, so we probably don't want to ask for no parent > clock? Well, we never seem to reference the HOSC this way, this was always somewhat explicit. And yes, there is PLL-PERIPH as an input, but we don't support this yet. So I went with 0 input clocks *for now*: the driver can then ignore all clocks, so any clock referenced in the DT later won't cause any harm. This will all be addressed by Samuel's RTC clock patch, which will also touch the H6, IIRC. And it looks like we will need to touch the binding anyway then, but can then just *extend* this. The point is that everything works(TM) as of now: The consumers (pinctrl) get their LOSC clock, and can go ahead. This is in the interest to get us moving now, and refine the actual implementation later. In this case this will only change the accuracy of the LOSC frequency (HOSC/x, PLL/y, calibrated RC), but won't change the semantics. Cheers, Andre -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210802013938.29fa18ed%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
Hi, On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote: > Add the obvious compatible name to the existing RTC binding. > The actual RTC part of the device uses a different day/month/year > storage scheme, so it's not compatible with the previous devices. > Also the clock part is quite different, as there is no external 32K LOSC > oscillator input. > > Signed-off-by: Andre Przywara > > --- > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > index beeb90e55727..d8a6500e5840 100644 > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > @@ -26,6 +26,7 @@ properties: >- const: allwinner,sun50i-a64-rtc >- const: allwinner,sun8i-h3-rtc >- const: allwinner,sun50i-h6-rtc > + - const: allwinner,sun50i-h616-rtc > >reg: > maxItems: 1 > @@ -104,6 +105,19 @@ allOf: >minItems: 3 >maxItems: 3 > > + - if: > + properties: > +compatible: > + contains: > +const: allwinner,sun50i-h616-rtc > + > +then: > + properties: > +clock-output-names: > + minItems: 3 > + maxItems: 3 You don't need both of them when they are equal > +clocks: false > + It's not entirely clear to me what those clocks are about though. If we look at the clock output in the user manual, it looks like there's only two clocks that are actually being output: the 32k "fanout" clock and the losc. What are the 3 you're talking about? Also, it looks like the 32k fanout clock needs at least the hosc or pll-periph in input, so we probably don't want to ask for no parent clock? Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210726144137.6dauuxdssu7yszox%40gilmour. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string
On Fri, 23 Jul 2021 16:38:29 +0100, Andre Przywara wrote: > Add the obvious compatible name to the existing RTC binding. > The actual RTC part of the device uses a different day/month/year > storage scheme, so it's not compatible with the previous devices. > Also the clock part is quite different, as there is no external 32K LOSC > oscillator input. > > Signed-off-by: Andre Przywara > --- > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 14 ++ > 1 file changed, 14 insertions(+) > Reviewed-by: Rob Herring -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210723223416.GA2724623%40robh.at.kernel.org.