Message-ID: <20190125155108.op45cqrlssz6rw3t@flea>
Date:   Fri, 25 Jan 2019 16:51:08 +0100
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Jernej Škrabec <jernej.skrabec@...l.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [PATCH 1/3] media: dt: bindings: sunxi-ir: Add A64 compatible

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@...l.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@...tlin.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@...l.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

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists