drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

Ezequiel Garcia ezequiel at vanguardiasur.com.ar
Mon Aug 24 13:46:03 UTC 2020


On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <paul at crapouillou.net> wrote:
>
>
>
> Le sam. 22 août 2020 à 0:11, Paul Boddie <paul at boddie.org.uk> a
> écrit :
> > On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> >>  On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul at boddie.org.uk>
> >> wrote:
> >>  >
> >>  > It still doesn't work for me. I still get "Input not supported"
> >> from my
> >>  > monitor. It is a DVI monitor connected via a HDMI adapter, but
> >> EDID
> >>  > probing
> >>  > works and, as I noted previously, the HDMI/LCDC can be made to
> >> work (and
> >>  > obviously did work in the 3.18 kernel).
> >>
> >>  This means the dw_hdmi encoder driver is still not good enough
> >>  to support your adapter. I haven't yet compared v3.18 vendor
> >>  with our version, but I'm afraid that the dw_hdmi stack has
> >>  probably changed quite a bit, so a comparison will be difficult.
> >
> > I would have to look at this again to check, but although I may have
> > referred
> > to the 3.18 HDMI driver (drivers/gpu/drm/jz4780/dwc_hdmi.c), I'm
> > fairly sure I
> > used the more recent driver
> > (drivers/gpu/drm/bridge/synopsys/dw_hdmi.c) as my
> > primary reference when making the hardware work with the L4 Runtime
> > Environment. But the actual functionality with regard to setting
> > registers in
> > the HDMI peripheral is mostly identical between both forms of the
> > driver.
> >
> > (This makes sense because few people are likely to have access to the
> > proprietary documentation. In fact, few people are likely to have
> > even tried
> > to deduce what is doing on. One of the register value tables suggests
> > that one
> > of the values would really need to be different, if you consider the
> > patterns
> > involved, which means that either the documentation mentions this
> > special case
> > or that a mistake has been made that has not yet been exposed through
> > real
> > world use.)
> >
> >>  The natural debug path for me would be to checkout v3.18,
> >>  connect your DVI monitor and make a dump of all the
> >>  dw_hdmi registers, then make the same dump for our
> >>  mainline kernel -- making sure we are comparing the same
> >>  mode.
> >
> > It is possible that something does not get initialised in the same
> > way, and
> > Nikolaus and I have been working with register dumps, although I
> > haven't been
> > generating them myself within Linux. So it is possible that I am
> > missing some
> > misconfiguration in the driver that causes an incompatibility with my
> > monitor.
> >
> > It should be noted that the initialisation is simpler with the DVI
> > mode,
> > thankfully. The "AVI infoframe" stuff (going from memory) is
> > completely
> > skipped, as are a range of other things, which made my
> > reimplementation effort
> > somewhat quicker. I also didn't bother with the audio functionality,
> > but then
> > I don't think DVI has any audio channels, either.
> >
> > One reason for implementing drivers for L4Re was to determine what is
> > actually
> > needed to initialise the hardware correctly, doing so in an
> > environment that
> > has been quicker to test than Linux has been (given some very old
> > development
> > hardware I have been using until recently). Another reason is that I
> > actually
> > want to get the CI20 hardware working with L4Re, which it was
> > originally
> > supposed to do, but in fact that effort was never actually finished.
> >
> >>  > I downloaded it from here:
> >>  >
> >>  >
> >> https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1
> >>  >
> >>  > (I was going to clone the repository late last night, but it was
> >> taking a
> >>  > long time and I also didn't want to clone everything yet again.)
> >>
> >>  If you want to avoid cloning the same things over and over
> >>  you can use git-clone --reference. And if you want to checkout
> >>  just a single branch, git now has --single-branch.
> >>
> >>  For instance, (assuming a torvalds/ local repo):
> >>
> >>  git clone -b letux/jz4780-hdmi-v4 --single-branch
> >>  git://git.goldelico.com/letux-kernel.git --reference torvalds/ letux
> >
> > Thanks for the tip! I guess I will spare everyone my thoughts about
> > git's
> > never-ending usability deficit.
> >
> > [...]
> >
> >>  > It would be nice to reconcile the JZ4780 support with the evolving
> >>  > upstream support, accommodating the extended descriptors and the
> >> extra
> >>  > register usage.
> >>  I think that's already done in the patches I've cleaned up.
> >>  The only thing left to check is plane offset and overlay enablement.
> >
> > There are some things that are done in different places, like various
> > registers being set in particular "atomic" methods and not during
> > probing.
> > Also, the upstream driver has specific plane descriptors whereas my
> > own
> > modifications introduced dual descriptors in a slightly different
> > way. Plus,
> > the upstream driver doesn't support extended descriptors, as far as I
> > am
> > aware.
> >
> > So, unless Paul Cercueil is fine with what you have done, I don't
> > think we are
> > close to integrating anything. Then again, I am not really a Linux
> > kernel
> > developer, so perhaps I won't comment in depth about what the
> > requirements
> > might be.
>
> If you send clean patches, there's no reason for me not to merge them.
>

I'd really like to see HDMI support on my CI20 being merged. Thank to
recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work,
the patches are IMO quite clean.

Nikolaus, Paul: Do you have plans to submit these? If not, I'll be
happy to get them out the door for review.

Cheers,
Ezequiel


More information about the dri-devel mailing list