On Wed, Aug 5, 2020 at 12:13 PM Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > > Em Wed, 5 Aug 2020 11:34:54 +0200 > Daniel Vetter <daniel@xxxxxxxx> escreveu: > > > On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab > > <mchehab+huawei@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
