On Fri, Jan 25, 2019 at 2:57 AM Jernej Škrabec <jernej.skrabec@xxxxxxxx> 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@xxxxxxxxxxx>
> 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@xxxxxxxx>
> 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
