[1/3] media: dt: bindings: sunxi-ir: Add A64 compatible
diff mbox series

Message ID 20190111173015.12119-2-jernej.skrabec@siol.net
State New
Headers show
Series
  • Add support for IR on Allwinner A64
Related show

Commit Message

Jernej Škrabec Jan. 11, 2019, 5:30 p.m. UTC
A64 IR is compatible with A13, so add A64 compatible with A13 as a
fallback.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Chen-Yu Tsai Jan. 12, 2019, 1:56 a.m. UTC | #1
On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
>
> A64 IR is compatible with A13, so add A64 compatible with A13 as a
> fallback.

We ask people to add the SoC-specific compatible as a contigency,
in case things turn out to be not so "compatible".

To be consistent with all the other SoCs and other peripherals,
unless you already spotted a "compatible" difference in the
hardware, i.e. the hardware isn't completely the same, this
patch isn't needed. On the other hand, if you did, please mention
the differences in the commit log.

ChenYu

> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
>  Documentation/devicetree/bindings/media/sunxi-ir.txt | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> index 278098987edb..ecac6964b69b 100644
> --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> @@ -1,7 +1,10 @@
>  Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
>
>  Required properties:
> -- compatible       : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
> +- compatible       : value must be one of:
> +  * "allwinner,sun4i-a10-ir"
> +  * "allwinner,sun5i-a13-ir"
> +  * "allwinner,sun50i-a64-ir", "allwinner,sun5i-a13-ir"
>  - clocks           : list of clock specifiers, corresponding to
>                       entries in clock-names property;
>  - clock-names      : should contain "apb" and "ir" entries;
> --
> 2.20.1
>
Jernej Škrabec Jan. 12, 2019, 8:08 a.m. UTC | #2
Dne sobota, 12. januar 2019 ob 02:56:11 CET je Chen-Yu Tsai napisal(a):
> On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> 
wrote:
> > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > fallback.
> 
> We ask people to add the SoC-specific compatible as a contigency,
> in case things turn out to be not so "compatible".
> 
> To be consistent with all the other SoCs and other peripherals,
> unless you already spotted a "compatible" difference in the
> hardware, i.e. the hardware isn't completely the same, this
> patch isn't needed. On the other hand, if you did, please mention
> the differences in the commit log.

When comparing registers descriptions between A13 and A64, I noticed few minor 
differences:

A13: RXINT: 11:6 RAL
A64: RXINT: 13:8 RAL

A13: IR_RXSTA: 12:6 RAC
A64: IR_RXSTA: 14:8 RAC, 7 STAT (missing on A13)

What is strange that  RAL and RAC field have offset defined as 8 in driver. I'm 
not sure if that is a typo in A13 manual or driver issue. I assume the former, 
otherwise it wouldn't work. I couldn't found original BSP driver source to 
confirm, though.

STAT bit is really not that important. It just tells if IR unit is busy or 
not.

The biggest difference is in 0x34 register. A64 has one more clock option 
(without postdivider), although register values are backward compatible. A64 
also has Active threshold setting (duration of CIR going from idle to active 
state).

If we dismiss RAC and RAL differences as manual error and don't care for new 
clock option and active threshold, then having new compatible maybe really 
doesn't make sense.

Best regards,
Jernej

> 
> ChenYu
> 
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> > 
> >  Documentation/devicetree/bindings/media/sunxi-ir.txt | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> > b/Documentation/devicetree/bindings/media/sunxi-ir.txt index
> > 278098987edb..ecac6964b69b 100644
> > --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> > +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> > @@ -1,7 +1,10 @@
> > 
> >  Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
> > 
> >  Required properties:
> > -- compatible       : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
> > +- compatible       : value must be one of:
> > +  * "allwinner,sun4i-a10-ir"
> > +  * "allwinner,sun5i-a13-ir"
> > +  * "allwinner,sun50i-a64-ir", "allwinner,sun5i-a13-ir"
> > 
> >  - clocks           : list of clock specifiers, corresponding to
> >  
> >                       entries in clock-names property;
> >  
> >  - clock-names      : should contain "apb" and "ir" entries;
> > 
> > --
> > 2.20.1
Maxime Ripard Jan. 21, 2019, 9:50 a.m. UTC | #3
Hi,

I'm a bit late to the party, sorry for that.

On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> >
> > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > fallback.
> 
> We ask people to add the SoC-specific compatible as a contigency,
> in case things turn out to be not so "compatible".
> 
> To be consistent with all the other SoCs and other peripherals,
> unless you already spotted a "compatible" difference in the
> hardware, i.e. the hardware isn't completely the same, this
> patch isn't needed. On the other hand, if you did, please mention
> the differences in the commit log.

Even if we don't spot things, since we have the stable DT now, if we
ever had that compatible in the DT from day 1, it's much easier to
deal with.

I'd really like to have that pattern for all the IPs even if we didn't
spot any issue, since we can't really say that the datasheet are
complete, and one can always make a mistake and overlook something.

I'm fine with this version, and can apply it as is if we all agree.

Maxime
Chen-Yu Tsai Jan. 21, 2019, 9:57 a.m. UTC | #4
On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> I'm a bit late to the party, sorry for that.
>
> On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > >
> > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > fallback.
> >
> > We ask people to add the SoC-specific compatible as a contigency,
> > in case things turn out to be not so "compatible".
> >
> > To be consistent with all the other SoCs and other peripherals,
> > unless you already spotted a "compatible" difference in the
> > hardware, i.e. the hardware isn't completely the same, this
> > patch isn't needed. On the other hand, if you did, please mention
> > the differences in the commit log.
>
> Even if we don't spot things, since we have the stable DT now, if we
> ever had that compatible in the DT from day 1, it's much easier to
> deal with.
>
> I'd really like to have that pattern for all the IPs even if we didn't
> spot any issue, since we can't really say that the datasheet are
> complete, and one can always make a mistake and overlook something.
>
> I'm fine with this version, and can apply it as is if we all agree.

I'm OK with having the fallback compatible. I'm just pointing out
that there are and will be a whole bunch of them, and we don't need
to document all of them unless we are actually doing something to
support them.

On the other hand, the compatible string situation for IR needs a
bit of cleaning up at the moment. Right now we have sun4i-a10 and
sun5i-a13. As Jernej pointed out, the A13's register definition is
different from A64 (or any other SoCs later than sun6i). So we need
someone with an A10s/A13 device that has IR to test it and see if
the driver or the manual is wrong, and we'd likely add a compatible
for the A20.

Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
was lost in A31, and also all of sun8i / sun50i. So we're going to
need to add an A31 compatible that all later platforms would need
to switch to.


Regards
ChenYu
Jernej Škrabec Jan. 21, 2019, 5:33 p.m. UTC | #5
Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> 
wrote:
> > Hi,
> > 
> > I'm a bit late to the party, sorry for that.
> > 
> > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> 
wrote:
> > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > fallback.
> > > 
> > > We ask people to add the SoC-specific compatible as a contigency,
> > > in case things turn out to be not so "compatible".
> > > 
> > > To be consistent with all the other SoCs and other peripherals,
> > > unless you already spotted a "compatible" difference in the
> > > hardware, i.e. the hardware isn't completely the same, this
> > > patch isn't needed. On the other hand, if you did, please mention
> > > the differences in the commit log.
> > 
> > Even if we don't spot things, since we have the stable DT now, if we
> > ever had that compatible in the DT from day 1, it's much easier to
> > deal with.
> > 
> > I'd really like to have that pattern for all the IPs even if we didn't
> > spot any issue, since we can't really say that the datasheet are
> > complete, and one can always make a mistake and overlook something.
> > 
> > I'm fine with this version, and can apply it as is if we all agree.
> 
> I'm OK with having the fallback compatible. I'm just pointing out
> that there are and will be a whole bunch of them, and we don't need
> to document all of them unless we are actually doing something to
> support them.

If you don't document them, checkpatch will complain. But if you can live with 
this warning, that's fine by me.

> 
> On the other hand, the compatible string situation for IR needs a
> bit of cleaning up at the moment. Right now we have sun4i-a10 and
> sun5i-a13. As Jernej pointed out, the A13's register definition is
> different from A64 (or any other SoCs later than sun6i). So we need
> someone with an A10s/A13 device that has IR to test it and see if
> the driver or the manual is wrong, and we'd likely add a compatible
> for the A20.
> 
> Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> was lost in A31, and also all of sun8i / sun50i. So we're going to
> need to add an A31 compatible that all later platforms would need
> to switch to.
> 

H6 has IR TX peripheral too, but it's different IP block...

Do you want me to switch all A31 and newer to different compatible in this 
series? I can do this, but I haven't any A13 device to test if this is really 
needed. Or you can argue that this is needed anyway due to missing TX 
capability.

BR,
Jernej
Chen-Yu Tsai Jan. 21, 2019, 5:39 p.m. UTC | #6
On Tue, Jan 22, 2019 at 1:33 AM Jernej Škrabec <jernej.skrabec@siol.net> wrote:
>
> Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com>
> wrote:
> > > Hi,
> > >
> > > I'm a bit late to the party, sorry for that.
> > >
> > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
> > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > fallback.
> > > >
> > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > in case things turn out to be not so "compatible".
> > > >
> > > > To be consistent with all the other SoCs and other peripherals,
> > > > unless you already spotted a "compatible" difference in the
> > > > hardware, i.e. the hardware isn't completely the same, this
> > > > patch isn't needed. On the other hand, if you did, please mention
> > > > the differences in the commit log.
> > >
> > > Even if we don't spot things, since we have the stable DT now, if we
> > > ever had that compatible in the DT from day 1, it's much easier to
> > > deal with.
> > >
> > > I'd really like to have that pattern for all the IPs even if we didn't
> > > spot any issue, since we can't really say that the datasheet are
> > > complete, and one can always make a mistake and overlook something.
> > >
> > > I'm fine with this version, and can apply it as is if we all agree.
> >
> > I'm OK with having the fallback compatible. I'm just pointing out
> > that there are and will be a whole bunch of them, and we don't need
> > to document all of them unless we are actually doing something to
> > support them.
>
> If you don't document them, checkpatch will complain. But if you can live with
> this warning, that's fine by me.
>
> >
> > On the other hand, the compatible string situation for IR needs a
> > bit of cleaning up at the moment. Right now we have sun4i-a10 and
> > sun5i-a13. As Jernej pointed out, the A13's register definition is
> > different from A64 (or any other SoCs later than sun6i). So we need
> > someone with an A10s/A13 device that has IR to test it and see if
> > the driver or the manual is wrong, and we'd likely add a compatible
> > for the A20.
> >
> > Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> > was lost in A31, and also all of sun8i / sun50i. So we're going to
> > need to add an A31 compatible that all later platforms would need
> > to switch to.
> >
>
> H6 has IR TX peripheral too, but it's different IP block...
>
> Do you want me to switch all A31 and newer to different compatible in this
> series? I can do this, but I haven't any A13 device to test if this is really
> needed. Or you can argue that this is needed anyway due to missing TX
> capability.

The lack of TX capability does necessitate switching to an A31 compatible.
So yes, please switch. Lets leave the A10s/A13 alone for now, unless
someone complains. I think this was done from inception, so if it was
broken, someone should've complained a long time ago. I just want to
be sure where the error is, and put in a comment explaining it. However
I don't have the hardware either.

ChenYu
Jernej Škrabec Jan. 21, 2019, 5:59 p.m. UTC | #7
Dne ponedeljek, 21. januar 2019 ob 18:39:26 CET je Chen-Yu Tsai napisal(a):
> On Tue, Jan 22, 2019 at 1:33 AM Jernej Škrabec <jernej.skrabec@siol.net> 
wrote:
> > Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai 
napisal(a):
> > > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard
> > > <maxime.ripard@bootlin.com>
> > 
> > wrote:
> > > > Hi,
> > > > 
> > > > I'm a bit late to the party, sorry for that.
> > > > 
> > > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec
> > > > > <jernej.skrabec@siol.net>
> > 
> > wrote:
> > > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > > fallback.
> > > > > 
> > > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > > in case things turn out to be not so "compatible".
> > > > > 
> > > > > To be consistent with all the other SoCs and other peripherals,
> > > > > unless you already spotted a "compatible" difference in the
> > > > > hardware, i.e. the hardware isn't completely the same, this
> > > > > patch isn't needed. On the other hand, if you did, please mention
> > > > > the differences in the commit log.
> > > > 
> > > > Even if we don't spot things, since we have the stable DT now, if we
> > > > ever had that compatible in the DT from day 1, it's much easier to
> > > > deal with.
> > > > 
> > > > I'd really like to have that pattern for all the IPs even if we didn't
> > > > spot any issue, since we can't really say that the datasheet are
> > > > complete, and one can always make a mistake and overlook something.
> > > > 
> > > > I'm fine with this version, and can apply it as is if we all agree.
> > > 
> > > I'm OK with having the fallback compatible. I'm just pointing out
> > > that there are and will be a whole bunch of them, and we don't need
> > > to document all of them unless we are actually doing something to
> > > support them.
> > 
> > If you don't document them, checkpatch will complain. But if you can live
> > with this warning, that's fine by me.
> > 
> > > On the other hand, the compatible string situation for IR needs a
> > > bit of cleaning up at the moment. Right now we have sun4i-a10 and
> > > sun5i-a13. As Jernej pointed out, the A13's register definition is
> > > different from A64 (or any other SoCs later than sun6i). So we need
> > > someone with an A10s/A13 device that has IR to test it and see if
> > > the driver or the manual is wrong, and we'd likely add a compatible
> > > for the A20.
> > > 
> > > Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> > > was lost in A31, and also all of sun8i / sun50i. So we're going to
> > > need to add an A31 compatible that all later platforms would need
> > > to switch to.
> > 
> > H6 has IR TX peripheral too, but it's different IP block...
> > 
> > Do you want me to switch all A31 and newer to different compatible in this
> > series? I can do this, but I haven't any A13 device to test if this is
> > really needed. Or you can argue that this is needed anyway due to missing
> > TX capability.
> 
> The lack of TX capability does necessitate switching to an A31 compatible.
> So yes, please switch. Lets leave the A10s/A13 alone for now, unless
> someone complains. I think this was done from inception, so if it was
> broken, someone should've complained a long time ago. I just want to
> be sure where the error is, and put in a comment explaining it. However
> I don't have the hardware either.

How do you want me to split patches? I propose following:
1. one patch to add all compatibles to DT binding documentation
2. one patch to add A31 compatible to driver
3. one patch for all 32 bit SoCs DT changes
4. one patch to add A64 compatible
5. one patch to enable OrangePi Win IR node

I don't think it's sensible to have multiple patches (one per SoC) for step 1 
and 3.

Best regards,
Jernej
Rob Herring Jan. 22, 2019, 12:19 a.m. UTC | #8
On Mon, Jan 21, 2019 at 05:57:57PM +0800, Chen-Yu Tsai wrote:
> On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Hi,
> >
> > I'm a bit late to the party, sorry for that.
> >
> > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > >
> > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > fallback.
> > >
> > > We ask people to add the SoC-specific compatible as a contigency,
> > > in case things turn out to be not so "compatible".
> > >
> > > To be consistent with all the other SoCs and other peripherals,
> > > unless you already spotted a "compatible" difference in the
> > > hardware, i.e. the hardware isn't completely the same, this
> > > patch isn't needed. On the other hand, if you did, please mention
> > > the differences in the commit log.
> >
> > Even if we don't spot things, since we have the stable DT now, if we
> > ever had that compatible in the DT from day 1, it's much easier to
> > deal with.
> >
> > I'd really like to have that pattern for all the IPs even if we didn't
> > spot any issue, since we can't really say that the datasheet are
> > complete, and one can always make a mistake and overlook something.
> >
> > I'm fine with this version, and can apply it as is if we all agree.
> 
> I'm OK with having the fallback compatible. I'm just pointing out
> that there are and will be a whole bunch of them, and we don't need
> to document all of them unless we are actually doing something to
> support them.

Yes, you do. Otherwise, how will we validate what is and isn't a valid 
set of compatible strings? It's not required yet, but bindings are 
moving to json-schema.

Rob
Chen-Yu Tsai Jan. 22, 2019, 2:16 a.m. UTC | #9
On Tue, Jan 22, 2019 at 8:19 AM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jan 21, 2019 at 05:57:57PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm a bit late to the party, sorry for that.
> > >
> > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > > >
> > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > fallback.
> > > >
> > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > in case things turn out to be not so "compatible".
> > > >
> > > > To be consistent with all the other SoCs and other peripherals,
> > > > unless you already spotted a "compatible" difference in the
> > > > hardware, i.e. the hardware isn't completely the same, this
> > > > patch isn't needed. On the other hand, if you did, please mention
> > > > the differences in the commit log.
> > >
> > > Even if we don't spot things, since we have the stable DT now, if we
> > > ever had that compatible in the DT from day 1, it's much easier to
> > > deal with.
> > >
> > > I'd really like to have that pattern for all the IPs even if we didn't
> > > spot any issue, since we can't really say that the datasheet are
> > > complete, and one can always make a mistake and overlook something.
> > >
> > > I'm fine with this version, and can apply it as is if we all agree.
> >
> > I'm OK with having the fallback compatible. I'm just pointing out
> > that there are and will be a whole bunch of them, and we don't need
> > to document all of them unless we are actually doing something to
> > support them.
>
> Yes, you do. Otherwise, how will we validate what is and isn't a valid
> set of compatible strings? It's not required yet, but bindings are
> moving to json-schema.

Ideally, if we knew which IP blocks in each SoC were compatible with
each other, we wouldn't need "per-SoC" compatible strings for each
block. However in reality this doesn't happen, due to a combination
of lack of time, lack of / uncertainty of documentation, and lack of
hardware for testing by the contributors.

The per-SoC compatible we ask people to add are a contigency plan,
for when things don't actually work, and we need some way to support
that specific piece of hardware on old DTs. At which point we will
add that SoC-specific compatible as a new compatible string to the
bindings. But not before.

ChenYu
Rob Herring Jan. 22, 2019, 1:37 p.m. UTC | #10
On Mon, Jan 21, 2019 at 8:16 PM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Tue, Jan 22, 2019 at 8:19 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Jan 21, 2019 at 05:57:57PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm a bit late to the party, sorry for that.
> > > >
> > > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > > > >
> > > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > > fallback.
> > > > >
> > > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > > in case things turn out to be not so "compatible".
> > > > >
> > > > > To be consistent with all the other SoCs and other peripherals,
> > > > > unless you already spotted a "compatible" difference in the
> > > > > hardware, i.e. the hardware isn't completely the same, this
> > > > > patch isn't needed. On the other hand, if you did, please mention
> > > > > the differences in the commit log.
> > > >
> > > > Even if we don't spot things, since we have the stable DT now, if we
> > > > ever had that compatible in the DT from day 1, it's much easier to
> > > > deal with.
> > > >
> > > > I'd really like to have that pattern for all the IPs even if we didn't
> > > > spot any issue, since we can't really say that the datasheet are
> > > > complete, and one can always make a mistake and overlook something.
> > > >
> > > > I'm fine with this version, and can apply it as is if we all agree.
> > >
> > > I'm OK with having the fallback compatible. I'm just pointing out
> > > that there are and will be a whole bunch of them, and we don't need
> > > to document all of them unless we are actually doing something to
> > > support them.
> >
> > Yes, you do. Otherwise, how will we validate what is and isn't a valid
> > set of compatible strings? It's not required yet, but bindings are
> > moving to json-schema.
>
> Ideally, if we knew which IP blocks in each SoC were compatible with
> each other, we wouldn't need "per-SoC" compatible strings for each
> block. However in reality this doesn't happen, due to a combination
> of lack of time, lack of / uncertainty of documentation, and lack of
> hardware for testing by the contributors.
>
> The per-SoC compatible we ask people to add are a contigency plan,
> for when things don't actually work, and we need some way to support
> that specific piece of hardware on old DTs.

You are right up to here.

> At which point we will
> add that SoC-specific compatible as a new compatible string to the
> bindings. But not before.

No, the point SoC-specific compatibles is they are already present in
the DT and you only have to update the OS to fix issues. The SoC
specific compatible has to be documented when first used in dts files,
not when the OS uses them. That is the rule.

Rob
Jernej Škrabec Jan. 24, 2019, 6:56 p.m. UTC | #11
Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> 
wrote:
> > Hi,
> > 
> > I'm a bit late to the party, sorry for that.
> > 
> > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> 
wrote:
> > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > fallback.
> > > 
> > > We ask people to add the SoC-specific compatible as a contigency,
> > > in case things turn out to be not so "compatible".
> > > 
> > > To be consistent with all the other SoCs and other peripherals,
> > > unless you already spotted a "compatible" difference in the
> > > hardware, i.e. the hardware isn't completely the same, this
> > > patch isn't needed. On the other hand, if you did, please mention
> > > the differences in the commit log.
> > 
> > Even if we don't spot things, since we have the stable DT now, if we
> > ever had that compatible in the DT from day 1, it's much easier to
> > deal with.
> > 
> > I'd really like to have that pattern for all the IPs even if we didn't
> > spot any issue, since we can't really say that the datasheet are
> > complete, and one can always make a mistake and overlook something.
> > 
> > I'm fine with this version, and can apply it as is if we all agree.
> 
> I'm OK with having the fallback compatible. I'm just pointing out
> that there are and will be a whole bunch of them, and we don't need
> to document all of them unless we are actually doing something to
> support them.
> 
> On the other hand, the compatible string situation for IR needs a
> bit of cleaning up at the moment. Right now we have sun4i-a10 and
> sun5i-a13. As Jernej pointed out, the A13's register definition is
> different from A64 (or any other SoCs later than sun6i). So we need
> someone with an A10s/A13 device that has IR to test it and see if
> the driver or the manual is wrong, and we'd likely add a compatible
> for the A20.
> 
> Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> was lost in A31, and also all of sun8i / sun50i. So we're going to
> need to add an A31 compatible that all later platforms would need
> to switch to.

Actually, A13 also doesn't have IR TX capability. So I still think it's best 
having A13 compatible as a fallback and not A31. Unless A31 was released 
before A13?

Best regards,
Jernej
Chen-Yu Tsai Jan. 25, 2019, 2:29 a.m. UTC | #12
On Tue, Jan 22, 2019 at 9:38 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jan 21, 2019 at 8:16 PM Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > On Tue, Jan 22, 2019 at 8:19 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Mon, Jan 21, 2019 at 05:57:57PM +0800, Chen-Yu Tsai wrote:
> > > > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm a bit late to the party, sorry for that.
> > > > >
> > > > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > > > > >
> > > > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > > > fallback.
> > > > > >
> > > > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > > > in case things turn out to be not so "compatible".
> > > > > >
> > > > > > To be consistent with all the other SoCs and other peripherals,
> > > > > > unless you already spotted a "compatible" difference in the
> > > > > > hardware, i.e. the hardware isn't completely the same, this
> > > > > > patch isn't needed. On the other hand, if you did, please mention
> > > > > > the differences in the commit log.
> > > > >
> > > > > Even if we don't spot things, since we have the stable DT now, if we
> > > > > ever had that compatible in the DT from day 1, it's much easier to
> > > > > deal with.
> > > > >
> > > > > I'd really like to have that pattern for all the IPs even if we didn't
> > > > > spot any issue, since we can't really say that the datasheet are
> > > > > complete, and one can always make a mistake and overlook something.
> > > > >
> > > > > I'm fine with this version, and can apply it as is if we all agree.
> > > >
> > > > I'm OK with having the fallback compatible. I'm just pointing out
> > > > that there are and will be a whole bunch of them, and we don't need
> > > > to document all of them unless we are actually doing something to
> > > > support them.
> > >
> > > Yes, you do. Otherwise, how will we validate what is and isn't a valid
> > > set of compatible strings? It's not required yet, but bindings are
> > > moving to json-schema.
> >
> > Ideally, if we knew which IP blocks in each SoC were compatible with
> > each other, we wouldn't need "per-SoC" compatible strings for each
> > block. However in reality this doesn't happen, due to a combination
> > of lack of time, lack of / uncertainty of documentation, and lack of
> > hardware for testing by the contributors.
> >
> > The per-SoC compatible we ask people to add are a contigency plan,
> > for when things don't actually work, and we need some way to support
> > that specific piece of hardware on old DTs.
>
> You are right up to here.
>
> > At which point we will
> > add that SoC-specific compatible as a new compatible string to the
> > bindings. But not before.
>
> No, the point SoC-specific compatibles is they are already present in
> the DT and you only have to update the OS to fix issues. The SoC
> specific compatible has to be documented when first used in dts files,
> not when the OS uses them. That is the rule.

We also want to be able to differentiate between per-SoC compatibles
vs actual backwards-compatible tuples, such as

    - "allwinner,sun8i-r40-rtc", "allwinner,sun8i-h3-rtc"

found in Documentation/devicetree/bindings/rtc/sun6i-rtc.txt .

In the future, if someone has the time to do an in-depth comparison
and testing, they should be able to deprecated and/or remove the per-SoC
compatible strings that we added for contingency from the bindings.

As such, I'd like implementors to not target the SoC-specific compatibles,
unless imcompatiblities are discovered, at which point the bindings would
also be updated, removing the fallback compatible.

The SoC-specific compatible strings are really a workaround for the lack
of resources of the community supporting this platform, while being able
to support DT stability. I want to make it clear in some way visible to
all that this is an exception, not the norm. And I'd also like to leave
the door open to later cleanup.

What would be an acceptable way to do this? Add extra notes accompanying
the per-SoC compatibles?

Regards
ChenYu
Chen-Yu Tsai Jan. 25, 2019, 2:49 a.m. UTC | #13
On Fri, Jan 25, 2019 at 2:57 AM Jernej Škrabec <jernej.skrabec@siol.net> wrote:
>
> Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com>
> wrote:
> > > Hi,
> > >
> > > I'm a bit late to the party, sorry for that.
> > >
> > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
> > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > fallback.
> > > >
> > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > in case things turn out to be not so "compatible".
> > > >
> > > > To be consistent with all the other SoCs and other peripherals,
> > > > unless you already spotted a "compatible" difference in the
> > > > hardware, i.e. the hardware isn't completely the same, this
> > > > patch isn't needed. On the other hand, if you did, please mention
> > > > the differences in the commit log.
> > >
> > > Even if we don't spot things, since we have the stable DT now, if we
> > > ever had that compatible in the DT from day 1, it's much easier to
> > > deal with.
> > >
> > > I'd really like to have that pattern for all the IPs even if we didn't
> > > spot any issue, since we can't really say that the datasheet are
> > > complete, and one can always make a mistake and overlook something.
> > >
> > > I'm fine with this version, and can apply it as is if we all agree.
> >
> > I'm OK with having the fallback compatible. I'm just pointing out
> > that there are and will be a whole bunch of them, and we don't need
> > to document all of them unless we are actually doing something to
> > support them.
> >
> > On the other hand, the compatible string situation for IR needs a
> > bit of cleaning up at the moment. Right now we have sun4i-a10 and
> > sun5i-a13. As Jernej pointed out, the A13's register definition is
> > different from A64 (or any other SoCs later than sun6i). So we need
> > someone with an A10s/A13 device that has IR to test it and see if
> > the driver or the manual is wrong, and we'd likely add a compatible
> > for the A20.
> >
> > Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> > was lost in A31, and also all of sun8i / sun50i. So we're going to
> > need to add an A31 compatible that all later platforms would need
> > to switch to.
>
> Actually, A13 also doesn't have IR TX capability. So I still think it's best
> having A13 compatible as a fallback and not A31. Unless A31 was released
> before A13?

No, but the A31 IR receiver has some additional bits in the FIFO control
and status registers, as well as the config register (which controls
sampling parameters). Looks like the A31 has an improved version. That
would make it backward compatible, if not for the fact that the FIFO
level bits are at a different offset, which might have been moved to
make way for the extra bits. That would make them incompatible. But
this should really be tested.

So the fallback compatible should be the A31's, not the A13's.

The A64's looks like the same hardware as the A31, with two extra bits:

  - CGPO: register 0x00, bit offset 8. Controls output level of
          "non-existing" TX pin

  - DRQ_EN: register 0x2c, bit offset 5. Controls DRQ usage for DMA.
            Not really useful as there isn't a DMA request line for
            the hardware.

Both bits are also togglable on the A31, but since actual hardware
don't support these two features, I think we can ignore them.

So it looks like for the A64 has the same IP block as the A31, in
which case we won't need the per-SoC compatible as we've done the
work to compare them.

Maxime, what do you think? And do you guys have any A10s/A13 hardware
to test the FIFO level bits?


Regards
ChenYu
Maxime Ripard Jan. 25, 2019, 3:51 p.m. UTC | #14
On Fri, Jan 25, 2019 at 10:49:58AM +0800, Chen-Yu Tsai wrote:
> On Fri, Jan 25, 2019 at 2:57 AM Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> >
> > Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> > > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard <maxime.ripard@bootlin.com>
> > wrote:
> > > > Hi,
> > > >
> > > > I'm a bit late to the party, sorry for that.
> > > >
> > > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec <jernej.skrabec@siol.net>
> > wrote:
> > > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > > > fallback.
> > > > >
> > > > > We ask people to add the SoC-specific compatible as a contigency,
> > > > > in case things turn out to be not so "compatible".
> > > > >
> > > > > To be consistent with all the other SoCs and other peripherals,
> > > > > unless you already spotted a "compatible" difference in the
> > > > > hardware, i.e. the hardware isn't completely the same, this
> > > > > patch isn't needed. On the other hand, if you did, please mention
> > > > > the differences in the commit log.
> > > >
> > > > Even if we don't spot things, since we have the stable DT now, if we
> > > > ever had that compatible in the DT from day 1, it's much easier to
> > > > deal with.
> > > >
> > > > I'd really like to have that pattern for all the IPs even if we didn't
> > > > spot any issue, since we can't really say that the datasheet are
> > > > complete, and one can always make a mistake and overlook something.
> > > >
> > > > I'm fine with this version, and can apply it as is if we all agree.
> > >
> > > I'm OK with having the fallback compatible. I'm just pointing out
> > > that there are and will be a whole bunch of them, and we don't need
> > > to document all of them unless we are actually doing something to
> > > support them.
> > >
> > > On the other hand, the compatible string situation for IR needs a
> > > bit of cleaning up at the moment. Right now we have sun4i-a10 and
> > > sun5i-a13. As Jernej pointed out, the A13's register definition is
> > > different from A64 (or any other SoCs later than sun6i). So we need
> > > someone with an A10s/A13 device that has IR to test it and see if
> > > the driver or the manual is wrong, and we'd likely add a compatible
> > > for the A20.
> > >
> > > Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> > > was lost in A31, and also all of sun8i / sun50i. So we're going to
> > > need to add an A31 compatible that all later platforms would need
> > > to switch to.
> >
> > Actually, A13 also doesn't have IR TX capability. So I still think it's best
> > having A13 compatible as a fallback and not A31. Unless A31 was released
> > before A13?
> 
> No, but the A31 IR receiver has some additional bits in the FIFO control
> and status registers, as well as the config register (which controls
> sampling parameters). Looks like the A31 has an improved version. That
> would make it backward compatible, if not for the fact that the FIFO
> level bits are at a different offset, which might have been moved to
> make way for the extra bits. That would make them incompatible. But
> this should really be tested.
> 
> So the fallback compatible should be the A31's, not the A13's.
> 
> The A64's looks like the same hardware as the A31, with two extra bits:
> 
>   - CGPO: register 0x00, bit offset 8. Controls output level of
>           "non-existing" TX pin
> 
>   - DRQ_EN: register 0x2c, bit offset 5. Controls DRQ usage for DMA.
>             Not really useful as there isn't a DMA request line for
>             the hardware.
> 
> Both bits are also togglable on the A31, but since actual hardware
> don't support these two features, I think we can ignore them.
>
> So it looks like for the A64 has the same IP block as the A31, in
> which case we won't need the per-SoC compatible as we've done the
> work to compare them.
>
> Maxime, what do you think?

Even though no hardware support those two features, I'd really prefer
to have an A64 compatible in addition to the A31's in the DT to be
future proof and being able to deal nicely with backward
compatibility. But of course, the driver can only use the A31 for now.

> And do you guys have any A10s/A13 hardware to test the FIFO level
> bits?

I don't think I have one with an IR receiver

Maxime

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 278098987edb..ecac6964b69b 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,7 +1,10 @@ 
 Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
 
 Required properties:
-- compatible	    : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
+- compatible	    : value must be one of:
+  * "allwinner,sun4i-a10-ir"
+  * "allwinner,sun5i-a13-ir"
+  * "allwinner,sun50i-a64-ir", "allwinner,sun5i-a13-ir"
 - clocks	    : list of clock specifiers, corresponding to
 		      entries in clock-names property;
 - clock-names	    : should contain "apb" and "ir" entries;