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

[H. Nikolaus Schaller]

Hi Ezequiel,

> Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
>
> Hello,
>
> First of all, I'd like to thank everyone for the great work
> on ingenic-drm. The driver is in very good shape
> and a pleasure to work with.
>
> Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5",
> from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1,
> and then run weston over HDMI (how often
> weston runs on mips, uh? :)

Wow!

> The edid of my monitor is properly read
> and modetest reports all modes.
>
> I've only tested the primary plane, for some reason
> the overlay is not working as expected, but it must
> be probably some minor thing.
>
> As for the bus format, I have just added a skip
> for CONNECTOR_HDMIA types in the encoder
> atomic check. And then MEDIA_BUS_FMT_RGB888_1X24
> is hardcoded if there are no bus formats negotiated

Cool!

> Paul et al, if you guys can rebase your work on v5.9-rc1
> and Cc I will be happy to review and test the patches.

I have tried our latest letux-5.9-rc1 tree (with Pauls fixes)
on my setup but screen remains black and the kernel was stuck
after showing "login:" and reported

[ 490.680469] rcu: INFO: rcu_preempt self-detected stall on CPU

Maybe, can you share your rebased tree to clearly identify the
subtle differences? Maybe I have broken something by the rebase.

> Cheers & thanks again,
> Eze

Thanks and best regards,
Nikolaus


>
>
>
>
> On Tue, 7 Jul 2020 at 04:27, Paul Boddie <pa...@boddie.org.uk> wrote:
>>
>> On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote:
>>>
>>> On 06/07/2020 01:57, Paul Boddie wrote:
>>>>
>>>> It also seems to be appropriate to set the input_bus_format on the
>>>> platform- specific HDMI driver; otherwise, I doubt that appropriate bus
>>>> encodings will be chosen in the Synopsys driver.
>>>
>>> It does but when not provided, it doesn't use it.
>>>
>>> It's handled in drm_atomic_bridge_chain_select_bus_fmts() :
>>> if (conn->display_info.num_bus_formats &&
>>> conn->display_info.bus_formats)
>>> out_bus_fmts[0] = conn->display_info.bus_formats[0];
>>> else
>>> out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
>>
>> OK. I thought I'd seen this somewhere, but I had started to think that
>> input_bus_format would remain initialised (presumably to zero) and this would
>> then cause the Synopsys driver to not change the bus format to the actual
>> default.
>>
>> [...]
>>
>>>> Testing against 5.8-rc3 with the above changes seems to have moved the
>>>> needle slightly. Although I still get "Input not supported" from my
>>>> monitor, running modetest now gives a different error:
>>>>
>>>> modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
>>>>
>>>> ...now yields this:
>>>>
>>>> setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
>>>> failed to set gamma: Invalid argument
>>>
>>> This is because you don't provide the gamma setup ioctl, it's not a fatal
>>> error at all. It should be warning since it's optional.
>>>
>>> Did you check all modes ?
>>
>> I have checked a few more. Currently, testing them is awkward because it
>> involves switching my monitor to DVI input, getting "Input Not Supported",
>> unplugging the cable, and then the hotplug event has most likely caused a bad
>> pointer dereference in ingenic_drm_crtc_atomic_flush and thus a kernel panic.
>>
>> So, I'll try and fix this panic, which appears to be due to the DRM driver
>> accessing a null framebuffer pointer (presumably having been invalidated
>> elsewhere upon unplugging), and see if I can't get some more information about
>> the state of the peripherals.
>>
>> Paul
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Ezequiel Garcia]

Sure.

Please give this a try and let me know if it works for you.

I've cleaned and squashed your changes, hopefully
I've kept the correct authorship for all of them.

https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1

This should be enough to get an fbcon, launch weston, etc.
However, there are few things that still don't look right.
Seems planes X,Y offset is not working, and also enabling
a second plane results in both planes going black for good.

This needs some more investigation, but seems at least a good start.

Thanks again for all the good work,
Ezequiel

[H. Nikolaus Schaller]

Hi Ezequiel,

> Am 20.08.2020 um 00:26 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
>
> On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller <h...@goldelico.com> wrote:
>>
>> Maybe, can you share your rebased tree to clearly identify the
>> subtle differences? Maybe I have broken something by the rebase.
>>
>
> Sure.
>
> Please give this a try and let me know if it works for you.
>
> I've cleaned and squashed your changes, hopefully
> I've kept the correct authorship for all of them.
>
> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1
>
> This should be enough to get an fbcon, launch weston, etc.
> However, there are few things that still don't look right.
> Seems planes X,Y offset is not working, and also enabling
> a second plane results in both planes going black for good.

Yes, it works!!!

There are some unexpected things related to CONFIG settings on my setup
(maybe missing modules) but for the first time I can see the boot log on the panel.

>
> This needs some more investigation, but seems at least a good start.

Yes it is!

I can now git diff the code and the CONFIG.

So it seems we have indeed a breakthrough.

Thanks to all who did contribute (even behind the scenes in the DRM subsystem),
Nikolaus

[Paul Boddie]

On Thursday, 20 August 2020 10:19:45 CEST H. Nikolaus Schaller wrote:
>
> Yes, it works!!!

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).

I used my usual recipe for kernel compilation:

ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make ci20_defconfig
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make menuconfig
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 uImage
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 modules
ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 dtbs
sudo sh -c 'INSTALL_MOD_PATH=nn ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
make modules_install'
sudo sh -c 'INSTALL_PATH=nn/boot ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
make dtbs_install'
sudo cp arch/mips/boot/uImage nn/boot/

This was with a snapshot archive made from the following changeset:

b911b4883bfe4f7fa753ac2ff42b25fa6b3055e2

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.)

> There are some unexpected things related to CONFIG settings on my setup
> (maybe missing modules) but for the first time I can see the boot log on the
> panel.
> > This needs some more investigation, but seems at least a good start.
>
> Yes it is!
>
> I can now git diff the code and the CONFIG.
>
> So it seems we have indeed a breakthrough.
>
> Thanks to all who did contribute (even behind the scenes in the DRM
> subsystem), Nikolaus

Before trying this new branch, I did try and tidy up the branch I had been
working on. I didn't notice all the changes and the new ingenic-drm-drv.c
file, having assumed that not much would have changed in the DRM driver.

Nevertheless, my attempts at integrating the different branches can be found
in the paulb-jz4780-ci20-hdmi-5.9-rc1 branch, mentioned earlier.

It would be nice to reconcile the JZ4780 support with the evolving upstream
support, accommodating the extended descriptors and the extra register usage.

Paul

P.S. I noticed a few problems with the 5.9-rc1 branches such as powering down
not actually removing the power and, in my own branch, networking not working
reliably (or maybe even at all), with the tedious progress indicator never
terminating in the boot sequence. So, once again, it is another case of half a
step forwards and about three steps back.

[Ezequiel Garcia]

On Thu, 20 Aug 2020 at 19:49, Paul Boddie <pa...@boddie.org.uk> wrote:
>
> On Thursday, 20 August 2020 10:19:45 CEST H. Nikolaus Schaller wrote:
> >
> > Yes, it works!!!
>
> 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.

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.

> I used my usual recipe for kernel compilation:
>
> ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make ci20_defconfig
> ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make menuconfig
> ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 uImage
> ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 modules
> ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 dtbs
> sudo sh -c 'INSTALL_MOD_PATH=nn ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
> make modules_install'
> sudo sh -c 'INSTALL_PATH=nn/boot ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \
> make dtbs_install'
> sudo cp arch/mips/boot/uImage nn/boot/
>
> This was with a snapshot archive made from the following changeset:
>
> b911b4883bfe4f7fa753ac2ff42b25fa6b3055e2
>
> 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

> > There are some unexpected things related to CONFIG settings on my setup
> > (maybe missing modules) but for the first time I can see the boot log on the
> > panel.
> > > This needs some more investigation, but seems at least a good start.
> >
> > Yes it is!
> >
> > I can now git diff the code and the CONFIG.
> >
> > So it seems we have indeed a breakthrough.
> >
> > Thanks to all who did contribute (even behind the scenes in the DRM
> > subsystem), Nikolaus
>
> Before trying this new branch, I did try and tidy up the branch I had been
> working on. I didn't notice all the changes and the new ingenic-drm-drv.c
> file, having assumed that not much would have changed in the DRM driver.
>
> Nevertheless, my attempts at integrating the different branches can be found
> in the paulb-jz4780-ci20-hdmi-5.9-rc1 branch, mentioned earlier.
>
> 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.

> Paul
>
> P.S. I noticed a few problems with the 5.9-rc1 branches such as powering down
> not actually removing the power and, in my own branch, networking not working
> reliably (or maybe even at all), with the tedious progress indicator never
> terminating in the boot sequence. So, once again, it is another case of half a
> step forwards and about three steps back.
>

Life (and kernel) is like this: sometimes you need to take three steps
back to make a jump forward :-)

[Paul Boddie]

On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> On Thu, 20 Aug 2020 at 19:49, Paul Boddie <pa...@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.

> > P.S. I noticed a few problems with the 5.9-rc1 branches such as powering
> > down not actually removing the power and, in my own branch, networking
> > not working reliably (or maybe even at all), with the tedious progress
> > indicator never terminating in the boot sequence. So, once again, it is
> > another case of half a step forwards and about three steps back.
>
> Life (and kernel) is like this: sometimes you need to take three steps
> back to make a jump forward :-)

Well, I wish I could be so optimistic. Objectively, the whole Linux kernel
development process is just so poor when we consider that we started out in
2014 or earlier with software that actually worked with the hardware, but
since it wasn't written quite to everybody's tastes and in line with the
fashions of the day, the whole exercise of reworking it was thrown straight
back at the developers. And since the developers were only being paid for as
long as their employers were interested, which turned out not to last
particularly long, we all ended up with yet another piece of equipment which
risks becoming obsolete unnecessarily.

Of course I would probably benefit from upstreamed support for the CI20,
although I was actually fairly happy using the 3.18 kernel with a relatively
recent Debian version, and we might not yet be at the point where new Debian
releases don't work with such an old kernel. But for the most part I don't
really care personally about fixing up Linux support for such hardware because
my own interests lie elsewhere. I suppose the most I get out of it is looking
at how the hardware works and being in a stronger position to reimplement the
driver support for L4Re. Indeed, I got the RTC support working in L4Re in
order to troubleshoot the Linux drivers, although they still seem to be
pathologically unable to handle the "lost clock" condition that is hardly
unlikely on the CI20.

Yet at the same time, I always manage to feel guilty asking for cooperation to
get improvements made to Linux, spending quite a bit of my own personal time
working with the underdocumented frameworks involved, building, deploying,
testing, and so on. And this is just my own way of offering help to others who
might not be in quite the same position, technically, to improve a situation
that might be far more important to them. Whatever little satisfaction I might
get from helping out tends to get completely overwhelmed by the amount of
effort, frustration and time involved.

Anyway, sorry for the rant. I'm sure other people find their own activities of
this nature to be sufficiently fulfilling and enjoyable. Life does present us
all with setbacks, but I generally don't appreciate getting served up with
more of them just so that some people in the Valley or wherever can "have fun"
or whatever the mantra is these days.

Paul

[Paul Cercueil]

Le sam. 22 août 2020 à 0:11, Paul Boddie <pa...@boddie.org.uk> a
écrit :

If you send clean patches, there's no reason for me not to merge them.

>> > P.S. I noticed a few problems with the 5.9-rc1 branches such as
>> powering
>> > down not actually removing the power and, in my own branch,
>> networking
>> > not working reliably (or maybe even at all), with the tedious
>> progress
>> > indicator never terminating in the boot sequence. So, once again,
>> it is
>> > another case of half a step forwards and about three steps back.
>>
>> Life (and kernel) is like this: sometimes you need to take three
>> steps
>> back to make a jump forward :-)

That's pretty much expected for a -rc1 release. Wait until -rc3 or -rc4
to have something more or less stable.

Cheers,
-Paul

[Ezequiel Garcia]

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

[H. Nikolaus Schaller]

Hi Ezequiel,

> Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
>
> On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <pa...@crapouillou.net> wrote:
>>
>>
>>
>> Le sam. 22 août 2020 à 0:11, Paul Boddie <pa...@boddie.org.uk> a
>> écrit :
>>

>> 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.

I have done some testing and it appears that it only works if DRM is
compiled into the kernel. At least in my setup. If DRM and/or HDMI are made
modules there is no video or code doesn't compile completely.

We have to analyse that further.

And it seems to differ significantly from what Paul has developed recently
to make it work. It seems to be quite lucky that we have a working setup now :)

> Nikolaus, Paul: Do you have plans to submit these?

Yes, as soon as we are sure that it works (and when it doesn't).

But thanks to your work it is now much easier to improve things, since we
are no longer looking for a break-through but just have to avoid regressions.

> If not, I'll be happy to get them out the door for review.

Let it mature a little first and have it tested on more setups and rebased
to mainline v5.9-rc2 :)

BR and thanks,
Nikolaus

[Ezequiel Garcia]

On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <h...@goldelico.com> wrote:
>
> Hi Ezequiel,
>
> > Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
> >
> > On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <pa...@crapouillou.net> wrote:
> >>
> >>
> >>
> >> Le sam. 22 août 2020 à 0:11, Paul Boddie <pa...@boddie.org.uk> a
> >> écrit :
> >>
> >> 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.
>
> I have done some testing and it appears that it only works if DRM is
> compiled into the kernel. At least in my setup. If DRM and/or HDMI are made
> modules there is no video or code doesn't compile completely.
>
> We have to analyse that further.
>

Ah! That's true.

The fix is just re-organizing the code a bit. Just pushed a possible
fix for that (following the IPU handling by Paul Cercueil),
please feel free to test this:

https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2

FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
(which means dm9000 works). I'm testing with weston and modetest.

Note that enabling DRM_INGENIC_IPU will make the driver
fail to load, as the IPU is not optional (and not present on ci20.dts).
A minor thing to fix.

Cheers,
Ezequiel

[Paul Cercueil]

Le lun. 24 août 2020 à 14:38, Ezequiel Garcia
<ezeq...@vanguardiasur.com.ar> a écrit :

Actually that's a bug, the IPU should be optional. I'll come up with a
fix.

>> And it seems to differ significantly from what Paul has developed
>> recently
>> to make it work. It seems to be quite lucky that we have a working
>> setup now :)
>>
>> > Nikolaus, Paul: Do you have plans to submit these?
>>
>> Yes, as soon as we are sure that it works (and when it doesn't).
>>
>> But thanks to your work it is now much easier to improve things,
>> since we
>> are no longer looking for a break-through but just have to avoid
>> regressions.
>>
>> > If not, I'll be happy to get them out the door for review.
>>
>> Let it mature a little first and have it tested on more setups and
>> rebased
>> to mainline v5.9-rc2 :)
>>

DRM drivers follow their own schedule, you should rebase to
drm-misc-next instead.

Cheers,
-Paul

[H. Nikolaus Schaller]

Hi Ezequiel,

> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
>
> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller <h...@goldelico.com> wrote:
>>
>> Hi Ezequiel,
>

> The fix is just re-organizing the code a bit. Just pushed a possible
> fix for that (following the IPU handling by Paul Cercueil),
> please feel free to test this:
>
> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2

Works well (after doing a minor fix to the CI20 defconfig)!

>
> FWIW, my test setup uses mainline vanilla U-Boot v2020.07.
> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS
> (which means dm9000 works). I'm testing with weston and modetest.
>
> Note that enabling DRM_INGENIC_IPU will make the driver
> fail to load, as the IPU is not optional (and not present on ci20.dts).
> A minor thing to fix.
>
> Cheers,
> Ezequiel
>
>> And it seems to differ significantly from what Paul has developed recently
>> to make it work. It seems to be quite lucky that we have a working setup now :)
>>
>>> Nikolaus, Paul: Do you have plans to submit these?
>>
>> Yes, as soon as we are sure that it works (and when it doesn't).
>>
>> But thanks to your work it is now much easier to improve things, since we
>> are no longer looking for a break-through but just have to avoid regressions.
>>
>>> If not, I'll be happy to get them out the door for review.
>>
>> Let it mature a little first and have it tested on more setups and rebased
>> to mainline v5.9-rc2 :)

> Am 24.08.2020 um 23:11 schrieb Paul Cercueil <pa...@crapouillou.net>:
>
> DRM drivers follow their own schedule, you should rebase to drm-misc-next instead.
>

With the comment from Paul, I think it is best if you push them for review.

My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
included only for making my Ethernet interface work for testing):

https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5

Please take it, do the required squashes and rebasing and post them for discussion to the
appropriate lists.

BR and thanks for this great break through,
Nikolaus

[H. Nikolaus Schaller]

Hi Ezequiel,

I hope you are well. Do you plan to do the squash and rebase and posts?

BR and thanks,
Nikolaus

[Ezequiel Garcia]

Hi Nikolaus,

I wanted to use the component API for the the dw hdmi glue driver
but somehow it wasn't probing and I haven't had time to debug it. Using the
component API consistently would allow to do some cleanups IMHO.

Thanks,
Ezequiel

[H. Nikolaus Schaller]

Hi Ezequiel,

> Am 10.09.2020 um 14:14 schrieb Ezequiel Garcia <ezeq...@vanguardiasur.com.ar>:
>>> With the comment from Paul, I think it is best if you push them for review.
>>>
>>> My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have
>>> included only for making my Ethernet interface work for testing):
>>>
>>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5
>>>
>>> Please take it, do the required squashes and rebasing and post them for discussion to the
>>> appropriate lists.
>>
>> I hope you are well. Do you plan to do the squash and rebase and posts?
>>
>
> Hi Nikolaus,
>
> I wanted to use the component API for the the dw hdmi glue driver
> but somehow it wasn't probing and I haven't had time to debug it. Using the
> component API consistently would allow to do some cleanups IMHO.

Yes, that would be a good move as long as it is not a dead-end-street :)

If you have something to test please let us know.

BR,
Nikolaus