DRM/KMS experimental drivers for HiKey 970

DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Hi,

I've been working to get upstream support for the DRM driver on HiKey 970.

While the patches are not ready yet for upstream merge, I'm placing
what I've sone so far on this repository:

	https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1

The drivers there are a port from the Linaro's HiKey official Kernel:

	https://github.com/96boards-hikey/linux

The patches there preserve the old history. The porting patches
are applied after the original patches imported from that tree.

Besides the DRM driver, this repository contains:

- a PMIC/regulator driver; 
- an iommu driver (still requiring some changes at DT properties);
- A DMA driver;
- a small ugly hack reverting some PM changes at the WiFi driver,
  causing a regression on this board for HiKey 970.

My current plans are to start upstreaming those needed drivers.

The KMS/DRM driver there still need some changes. I guess it is
not ready for being upstreamed yet. Also, it depends on the
other drivers to work.

In particular, its support for DPMS is broken: if the monitor is
suspended, it won't return back to the right frequency settings.

Feel free to test it and send me patches fixing things there :-)

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Daniel Vetter]

On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Hi,
>
> I've been working to get upstream support for the DRM driver on HiKey 970.
>
> While the patches are not ready yet for upstream merge, I'm placing
> what I've sone so far on this repository:
>
>         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
>
> The drivers there are a port from the Linaro's HiKey official Kernel:
>
>         https://github.com/96boards-hikey/linux
>
> The patches there preserve the old history. The porting patches
> are applied after the original patches imported from that tree.
>
> Besides the DRM driver, this repository contains:
>
> - a PMIC/regulator driver;
> - an iommu driver (still requiring some changes at DT properties);
> - A DMA driver;
> - a small ugly hack reverting some PM changes at the WiFi driver,
>   causing a regression on this board for HiKey 970.
>
> My current plans are to start upstreaming those needed drivers.
>
> The KMS/DRM driver there still need some changes. I guess it is
> not ready for being upstreamed yet. Also, it depends on the
> other drivers to work.
>
> In particular, its support for DPMS is broken: if the monitor is
> suspended, it won't return back to the right frequency settings.

Hm this is somewhat surprising, at least with atomic, since DPMS as a
separate thing doesn't exist anymore - it's the same path as any other
modeset. With the suspend/resume helpers even the same as after
resume. But of course in reality there's always potential for some
differences between boot-up state and what your atomic_disable leaves
behind to creep in.

Just figured I drop this in quickly, always great to have more hw
drivers showing up!

Cheers, Daniel

> Feel free to test it and send me patches fixing things there :-)
>
> Thanks,
> Mauro
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Em Wed, 5 Aug 2020 11:34:54 +0200
Daniel Vetter <daniel@ffwll.ch> escreveu:

> On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > Hi,
> >
> > I've been working to get upstream support for the DRM driver on HiKey 970.
> >
> > While the patches are not ready yet for upstream merge, I'm placing
> > what I've sone so far on this repository:
> >
> >         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
> >
> > The drivers there are a port from the Linaro's HiKey official Kernel:
> >
> >         https://github.com/96boards-hikey/linux
> >
> > The patches there preserve the old history. The porting patches
> > are applied after the original patches imported from that tree.
> >
> > Besides the DRM driver, this repository contains:
> >
> > - a PMIC/regulator driver;
> > - an iommu driver (still requiring some changes at DT properties);
> > - A DMA driver;
> > - a small ugly hack reverting some PM changes at the WiFi driver,
> >   causing a regression on this board for HiKey 970.
> >
> > My current plans are to start upstreaming those needed drivers.
> >
> > The KMS/DRM driver there still need some changes. I guess it is
> > not ready for being upstreamed yet. Also, it depends on the
> > other drivers to work.
> >
> > In particular, its support for DPMS is broken: if the monitor is
> > suspended, it won't return back to the right frequency settings.  
> 
> Hm this is somewhat surprising, at least with atomic, since DPMS as a
> separate thing doesn't exist anymore - it's the same path as any other
> modeset. With the suspend/resume helpers even the same as after
> resume. But of course in reality there's always potential for some
> differences between boot-up state and what your atomic_disable leaves
> behind to creep in.

Yeah, I didn't notice anything that would explain a problem there,
but I didn't have much time so far to try to identify what is
the real issue there.

Btw, this problem is also present on the official Hikey Linaro's tree. 
There, it had an ugly hack at the modeset logic on adv7535 downstream
driver.

Ah, I forgot to mention, but this driver has a problem when talking
with EDID. So, I'm passing this parameter via grub:

	drm_kms_helper.edid_firmware=edid/1920x1080.bin

With the EDID info from the monitor I'm using at the tests.

Perhaps the DPMS is somehow related to it.

In any case, the modeset part of this driver needs to be revisited,
before merging it drivers/drm.

Btw, both issues are also present at the official Hikey driver,
which makes a little harder to fix, as I was unable to get any
documentation about this chipset so far - except for the public
ones at 96boards.org.

> 
> Just figured I drop this in quickly, always great to have more hw
> drivers showing up!

Yeah, it has been great for me to work on this DRM driver.

Btw, although I didn't test, this driver is meant to support
also Hikey 960.

I intend to test it there when I have some spare time.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Daniel Vetter]

On Wed, Aug 5, 2020 at 12:13 PM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Em Wed, 5 Aug 2020 11:34:54 +0200
> Daniel Vetter <daniel@ffwll.ch> escreveu:
>
> > On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
> > <mchehab+huawei@kernel.org> wrote:
> > >
> > > Hi,
> > >
> > > I've been working to get upstream support for the DRM driver on HiKey 970.
> > >
> > > While the patches are not ready yet for upstream merge, I'm placing
> > > what I've sone so far on this repository:
> > >
> > >         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
> > >
> > > The drivers there are a port from the Linaro's HiKey official Kernel:
> > >
> > >         https://github.com/96boards-hikey/linux
> > >
> > > The patches there preserve the old history. The porting patches
> > > are applied after the original patches imported from that tree.
> > >
> > > Besides the DRM driver, this repository contains:
> > >
> > > - a PMIC/regulator driver;
> > > - an iommu driver (still requiring some changes at DT properties);
> > > - A DMA driver;
> > > - a small ugly hack reverting some PM changes at the WiFi driver,
> > >   causing a regression on this board for HiKey 970.
> > >
> > > My current plans are to start upstreaming those needed drivers.
> > >
> > > The KMS/DRM driver there still need some changes. I guess it is
> > > not ready for being upstreamed yet. Also, it depends on the
> > > other drivers to work.
> > >
> > > In particular, its support for DPMS is broken: if the monitor is
> > > suspended, it won't return back to the right frequency settings.
> >
> > Hm this is somewhat surprising, at least with atomic, since DPMS as a
> > separate thing doesn't exist anymore - it's the same path as any other
> > modeset. With the suspend/resume helpers even the same as after
> > resume. But of course in reality there's always potential for some
> > differences between boot-up state and what your atomic_disable leaves
> > behind to creep in.
>
> Yeah, I didn't notice anything that would explain a problem there,
> but I didn't have much time so far to try to identify what is
> the real issue there.
>
> Btw, this problem is also present on the official Hikey Linaro's tree.
> There, it had an ugly hack at the modeset logic on adv7535 downstream
> driver.
>
> Ah, I forgot to mention, but this driver has a problem when talking
> with EDID. So, I'm passing this parameter via grub:
>
>         drm_kms_helper.edid_firmware=edid/1920x1080.bin
>
> With the EDID info from the monitor I'm using at the tests.

Hm probing and atomic check/commit should be largely decoupled, at
least for dumb outputs. For DP and hdmi 2, where we have sideband
traffic to do link training and all that it's different. So fake edid
(or just force-setting a mode you like, even on a disconnected output)
should all work.

> Perhaps the DPMS is somehow related to it.
>
> In any case, the modeset part of this driver needs to be revisited,
> before merging it drivers/drm.
>
> Btw, both issues are also present at the official Hikey driver,
> which makes a little harder to fix, as I was unable to get any
> documentation about this chipset so far - except for the public
> ones at 96boards.org.

Uh yeah that makes it tough :-/

> >
> > Just figured I drop this in quickly, always great to have more hw
> > drivers showing up!
>
> Yeah, it has been great for me to work on this DRM driver.
>
> Btw, although I didn't test, this driver is meant to support
> also Hikey 960.
>
> I intend to test it there when I have some spare time.

Adding John Stulz, I think he's been working on upstreaming part of
that too, but not sure.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[John Stultz]

On Wed, Aug 5, 2020 at 1:51 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
> I've been working to get upstream support for the DRM driver on HiKey 970.
>
> While the patches are not ready yet for upstream merge, I'm placing
> what I've sone so far on this repository:
>
>         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
>
> The drivers there are a port from the Linaro's HiKey official Kernel:
>
>         https://github.com/96boards-hikey/linux
>
> The patches there preserve the old history. The porting patches
> are applied after the original patches imported from that tree.
>
> Besides the DRM driver, this repository contains:
>
> - a PMIC/regulator driver;
> - an iommu driver (still requiring some changes at DT properties);
> - A DMA driver;
> - a small ugly hack reverting some PM changes at the WiFi driver,
>   causing a regression on this board for HiKey 970.
>
> My current plans are to start upstreaming those needed drivers.
>
> The KMS/DRM driver there still need some changes. I guess it is
> not ready for being upstreamed yet. Also, it depends on the
> other drivers to work.

Hey Mauro,
  I'm really excited to see this effort being picked up! Thanks for
taking this on!

The patch set you have looks like it maybe started with a 4.9 tree
(I'm guessing the hikey960 4.9 tree which maybe was adapted as a
starting point for the hikey970?). Its nice to have the full history
but given the long lifetime, it may complicate reviewing a bit.

A while back, after 4.9, some folks at HiSilicon reworked the display
driver so that it could re-use and share logic with the already
upstream kirin drm driver, in the hopes of upstreaming it. This helped
avoid the smmu dependency, and some of the odd bits about how it was
tied to the ion heap driver (looks like you've already pulled that out
in your tree).  Unfortunately the upstreaming effort fell apart, but
I've been forward porting along the results of that work along. But I
haven't had the cycles to clean the code up (it has *lots* of
checkpatch issues for a start) to submit it.

You can find my current mainline tracking tree here:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP

And the drm display bits are here:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP&id=f5e888b02b683a9a6636174c6d2b74f697e87513

If you want to pick up these patches, refactor and submit them, I'd of
course have *zero* complaints :)
But even if you don't, hopefully this tree might be helpful for
comparison sake as you shake out issues with the current tree.

Do keep me in the loop, as I'd love to test and validate whatever
patches you do end up planning to submit.

thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Em Thu, 6 Aug 2020 12:24:40 -0700
John Stultz <john.stultz@linaro.org> escreveu:

> On Wed, Aug 5, 2020 at 1:51 AM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> > I've been working to get upstream support for the DRM driver on HiKey 970.
> >
> > While the patches are not ready yet for upstream merge, I'm placing
> > what I've sone so far on this repository:
> >
> >         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
> >
> > The drivers there are a port from the Linaro's HiKey official Kernel:
> >
> >         https://github.com/96boards-hikey/linux
> >
> > The patches there preserve the old history. The porting patches
> > are applied after the original patches imported from that tree.
> >
> > Besides the DRM driver, this repository contains:
> >
> > - a PMIC/regulator driver;
> > - an iommu driver (still requiring some changes at DT properties);
> > - A DMA driver;
> > - a small ugly hack reverting some PM changes at the WiFi driver,
> >   causing a regression on this board for HiKey 970.
> >
> > My current plans are to start upstreaming those needed drivers.
> >
> > The KMS/DRM driver there still need some changes. I guess it is
> > not ready for being upstreamed yet. Also, it depends on the
> > other drivers to work.  
> 
> Hey Mauro,
>   I'm really excited to see this effort being picked up! Thanks for
> taking this on!
> 
> The patch set you have looks like it maybe started with a 4.9 tree
> (I'm guessing the hikey960 4.9 tree which maybe was adapted as a
> starting point for the hikey970?). 

Yes. It came from the official Hikey tree from Linaro.

> Its nice to have the full history
> but given the long lifetime, it may complicate reviewing a bit.

I know. What can be done is to send a diff at patch 00/xx with
the entire history for each driver folded, in order to easy
for reviewers. Still, applying upstream with the full history
sounds valuable, specially if some patch needs to be reverted.

It also helps preserving the original authorship for each change.

> A while back, after 4.9, some folks at HiSilicon reworked the display
> driver so that it could re-use and share logic with the already
> upstream kirin drm driver, in the hopes of upstreaming it. This helped
> avoid the smmu dependency, and some of the odd bits about how it was
> tied to the ion heap driver

Sounds nice! I ended doing something similar to it on my patchset
(but taking a different approach), with regards of supporting
both 960 and 970 by the same driver, by converting all ifdefs
into runtime code.

Did this work cover the Hikey 970 or just 960?

The current driver has some issues - even at the original tree:

1. EDAC doesn't work with the upstream adv7535 driver
   (on 4.9, EDAC sometimes works with a forked version of adv7535,
   with several hacks on it);

2. Sometimes LDI underflows occur - usually when switching resolution;

3. DPMS causes the monitor to not work after suspend;

4. There are problems at the panel switch HDMI code. I ended solving
   it by removing the panel settings from DT.

Does any of the above issues got solved at the version on your tree?

-

With regards to (2), the driver sets several clocks to adjust to the
pixel rate:

	[    6.391078] [drm] Got built-in EDID base block and 0 extensions from "edid/1920x1080.bin" for connector "HDMI-A-1"
	[    6.402931] [drm] Valid mode: 1920x1080@60, clock 148500 (adjusted to 144000)
	[    6.417986] [drm] Valid mode: 1920x1080@60, clock 148500 (adjusted to 144000)
	[    6.418046] [drm] enabling DPE regulator
	[    6.418053] [drm] -.
	[    6.418261] [drm] dss_pri_clk:[300000000]->[300000000].
	[    6.418417] [drm] dss_mmbuf_clk:[238000000]->[237142858].
	[    6.418445] [drm] Requested clock 148500 kHz, setting to 144000 kHz
	[    6.418451] [drm] PLL7 set to (0x4903405, 0x6800000)
	[    6.418615] [drm] dss_pxl0_clk:[144000000]->[144000000].

However, PXL0 clock is always set to 144 MHz, no matter the pixel clock.

At the 4.9 version, there is a commented out code trying to set it
on a higher frequency:

	#if 1
		ret = clk_set_rate(ctx->dss_pxl0_clk, 144000000UL);
	#else
		/*comfirm ldi1 switch ppll7*/
		if (pixel_clock_ori <= 255000000)
			ret = clk_set_rate(ctx->dss_pxl0_clk, DEFAULT_MIDIA_PPLL7_CLOCK_FREQ/7);
		else if (pixel_clock_ori <= 415000000)
			ret = clk_set_rate(ctx->dss_pxl0_clk, DEFAULT_MIDIA_PPLL7_CLOCK_FREQ/5);
		else if (pixel_clock_ori <= 594000000)
			ret = clk_set_rate(ctx->dss_pxl0_clk, DEFAULT_MIDIA_PPLL7_CLOCK_FREQ/3);
		else {
			DRM_ERROR("Clock don't support!!\n");
			return -EINVAL;
		}
	#endif

Which seems to be focusing on supporting 1080p and 4K modes, but I was
unable to make the commented out part of the code to work.

> (looks like you've already pulled that out in your tree). 

Yes, I was able to drop ION by removing the old framebuffer API
part of the driver, using FB emulation. 

> Unfortunately the upstreaming effort fell apart, but
> I've been forward porting along the results of that work along. But I
> haven't had the cycles to clean the code up (it has *lots* of
> checkpatch issues for a start) to submit it.

Yes, I can figure out. The 4.9 patchset also had lots of those.
I guess I fixed most of them on this version.

> You can find my current mainline tracking tree here:
> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP
> 
> And the drm display bits are here:
> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey960-mainline-WIP&id=f5e888b02b683a9a6636174c6d2b74f697e87513

Are they covering both Hikey 960 and 970?

If I knew that before, I would have started from your tree. Before
jumping into it, I tried to seek other trees with Hikey 970. The
only one I found was a 4.19 Kernel tree from Mani - which didn't
carry the DRM driver.

So, I had to start from the 4.9 tree, getting rid of lots of
Android and Chrome-OS specific patches. There were around 2K
patches on the top of vanilla 4.9.78. I had to mine them, picking
just the ones needed for DRM to work.

-

Btw, were you able to make USB work on Hikey 970? I noticed that
you recently ported rt1711h and added bindings for Hikey 960.

I did myself a quick port from the ones at 4.9 Kernel but didn't spend 
much time on them[1]. The Hikey 970 also uses the Richtek 1711 driver
but donwstream has a different USB phy driver, and the 4.9 version
do some changes at the DWG3 for it to work. There's also an USB hub
driver, which also seems to be need.

With my port, despite the drivers being probed fine, lsusb doesn't
show anything, even after fixing the SPMI driver for it to properly
control the needed power lines. I didn't spend much time debugging
it.

[1] my goal here is just to find a way to send evdev events to
XWayland. Unfortunately, things like "x2x" won't work on Wayland.

> If you want to pick up these patches, refactor and submit them, I'd of
> course have *zero* complaints :)
> But even if you don't, hopefully this tree might be helpful for
> comparison sake as you shake out issues with the current tree.

Thanks for pointing to it!

On a quick look, I'm not seeing there the other drivers that
seem to be required by Hikey 970 GPU drivers:

	- drivers/dma/hisi_dma_64.c;
	- drivers/clk/hisilicon/clk-kirin970-stub.c;
	  (this one seems to be needed by Mali/Panfrost only);
	- Hikey 6421v600 SPMI PMIC drivers;
	- drivers/iommu/hisi_smmu_lpae.c.

At least the SPMI drivers are specific for Hikey 970, as Hikey960
uses a normal mfd PMIC driver. Yet, maybe the other drivers were
replaced by some alternative ones upstream (although I was not
able to find them on Kernel v5.7 - which is the version that I
used to start this port).

The clk-kirin970-stub also seems to be specific for 970, as it
seems to be implementing something different than the kirin960
one.

> 
> Do keep me in the loop, as I'd love to test and validate whatever
> patches you do end up planning to submit.


Surely. It is great to have some help reviewing those patches.

My current plan is to start submitting the non-DRM drivers
soon. I guess the SPMI drivers are ready for upstream submission.
I'll probably start sending patches from this one.

The DMA also seems to be fine.

The iommu driver still require some adjustments, in order to
use a more standard DT description. 

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Sam Ravnborg]

Hi Mauro.

> 
> I know. What can be done is to send a diff at patch 00/xx with
> the entire history for each driver folded, in order to easy
> for reviewers.
Personnaly this would be preferred as I assume the history is a lot of
forth and back rather than incremental logical changes.

No promises of any useful reviews though...

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Em Fri, 7 Aug 2020 10:59:43 +0200
Sam Ravnborg <sam@ravnborg.org> escreveu:

> Hi Mauro.
> 
> > 
> > I know. What can be done is to send a diff at patch 00/xx with
> > the entire history for each driver folded, in order to easy
> > for reviewers.  
> Personnaly this would be preferred as I assume the history is a lot of
> forth and back rather than incremental logical changes.

Actually, it is not that bad. The changes at the code are incremental. 
I suspect that the initial patch is actually a folded changeset for
the Linaro's 4.9 Kernel tree. The changes afterwards happened inside
the Linaro tree, more or less following the usual one patch per
logical change approach.

On the top of that, there are the changes I did myself, in order to port
it from 4.9. Having those at the history helps a lot, in the case
I made any mistake on such ports.

> No promises of any useful reviews though...

A review on the folded change should be enough. In case of doubts
about something, the detailed changeset could be useful, specially
to help identifying eventual mistakes I could have done during the 
port.

Anyway, my plan is to first get the non-DRM changesets reviewed, as
I may need to modify some things depending on the feedback from
the other subsystems.

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Hi Daniel,

Em Wed, 5 Aug 2020 13:04:18 +0200
Daniel Vetter <daniel@ffwll.ch> escreveu:


> > > > I've been working to get upstream support for the DRM driver on HiKey 970.
> > > >
> > > > While the patches are not ready yet for upstream merge, I'm placing
> > > > what I've sone so far on this repository:
> > > >
> > > >         https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1

I already started the process of submitting the pending drivers which
are required for the DRM driver to work (regulators and IOMMU).

I'm now planning what to do with the DRM KMS driver. This driver is
somewhat similar to the Kirin 6220 driver, but the display engine
uses a different set of registers which are chipset specific. My
port should work with either Kirin 960 or 970, although, so far,
I tested only the Kirin 970 part.

Besides its size, the driver is pretty much a standard KMS driver
that uses emulation framebuffer.

Yet, as I said before, it currently has some bugs that are hard to
debug and fix, as the downstream version also has them.

John has a different port, which works only for Kirin 960, adding
some functionality on the existing Kirin 6220 driver. Based on the
history on his WIP tree, it sounds to me that the same bugs I'm
facing are also present on his port. 

The known bugs are:

- EDID reads via adv7135 don't work properly. Adding a delay on
  some part of adv7135 code may help, but that sounds to me more
  like a hack than a final solution;

- There are some underflows on a something called LDI. This is the
  worse bug, as, once it happens, the hardware stops changing the
  displayed image. At John's tree for Kirin 960, there were several
  attempts (and several reverts), trying to address it. Based on a comment
  at the downstream version, at least for Kirin 970 I suspect that this could
  be due to a too low clock frequency, but increasing it alone breaks the 
  driver. I suspect that other clock frequencies would need to be adjusted,
  but I don't know how to adjust the other clocks for it to work with a
  higher frequency;

- There's currently a hack at the valid modesetting logic; only
  modes that are known to work return MODE_OK. 	 

I'm planning to test my port on Kirin 960 soon, and ensure that the
DRM driver will work for both chipsets.

In the future, I'm planning to try merging support for all 3 Kirin
variants at the same driver, probably using part of John's approach
for Kirin 960.

In any case, considering the existing bugs, plus the eventual future
work in order to support multiple Kirin variants at the same driver,
I would prefer merging this driver first at staging. 

Would that be acceptable?

Thanks,
Mauro
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel