vc4: 7" LCD touchscreen not supported about linux HOT 34 CLOSED

+1

from linux.

Some registers are locked down by the firmware, like the ones used for OTP access

from linux.

+1

from linux.

+1

from linux.

+1

from linux.

Progress on this: drm-vc4-dsi-boot configures most of the of the vc4 hardware for the panel, and console and X work.

It doesn't successfully initialize if the panel wasn't enabled at boot (tested using ignore_lcd=1 in config.txt) and doesn't control the Toshiba chip on the panel (so DPMS results in the panel flipping out due to pixels no longer showing up when they should).

from linux.

+1

from linux.

Any guesstimates on this hitting upstream? I tried merging with rpi-4.6.y to test, but I probably failed as the result doesn't boot. It gets to a black screen with some random flashing characters every few seconds.

from linux.

@zarr since the code isn't done, just merging upstream wouldn't work.

from linux.

Any progress on this?

from linux.

Hi @anholt,
I have an official DSI display connected to my pi3 using the latest rasbian (with HDMI not connected)
Is it still the case that there's no way to use your VC4 driver here?
When I boot with this configuration, I get a blank screen.

Is there anything that I should add to my config.txt (besides what rasbi-config adds when I enable your driver via that)?

Would it help if I provided any logs or diagnostic output for you?

from linux.

@greyltc This bug is that the DSI display is not supported yet, so there's no way to get it to work.

from linux.

+1

from linux.

New rpi-4.4.y-dsi branch is up porting the upstream-targeted DSI work to downstream. bcm2709_defconfig-only, and requires this in config.txt:

ignore_lcd=1
(Otherwise we lose our i2c0 pin setup frequently, and our transaction interrupts get stolen)

It may also need:

mask_gpu_interrupt1=0x1000
(more transaction interrupt theft prevention)

This branch does not work! The panel at best gets turned on but scans out white instead of pixel data. The transactions are timing out, and after doing them, even the i2c reads from the atmel start going from mostly-not-timing-out to always failing.

We should probably be using i2c-gpio on the pins to avoid clashing with the i2c0 that the firmware also uses. Even still, the write (not read!) transactions were working on my upstream branch, and are failing here, so something went wrong in the backport. Also the tc358762 reads from i2c at boot are bad looking, and I don't know how to do tc358762 writes over i2c.

I'm hoping @ghollingworth could take a look at this at some point while I'm on vacation and fill in how to do tc358762 writes over i2c.

from linux.

Any progress on this? @ghollingworth ? @anholt ?

from linux.

I just sent a pull request for cut down DSI support (no power management, requires firmware initialization). Working on touchscreen input now.

from linux.

Thank you for your work on this!

from linux.

Eric, do you have a rough idea where this could be implemented? I understand you've got plenty of other stuff on your plate and it's not a high priority.

from linux.

The stub implementation is now merged downstream, so the LCD should now minimally work with the open driver. Keeping this open to track development and merge for upstream.

from linux.

Hi Eric,

That's fantastic news! I've upgraded the kernel and the display indeed lit up. Unfortunately I didn't have much luck with Xorg server. According to the log, it all starts fine, but nothing on the screen. Switching back to VT works fine.

Xorg Log:
http://dpaste.com/1FSCMZ2

from linux.

I also tried kwin_wayland --drm to see if I can get plasma5 DRM backend running via EGL, but it stopped with:

FATAL ERROR: Creating connecting to XServer failed: 5

dmesg gave me this:

[ 535.818190] disable

from linux.

Creating connection*

from linux.

can this be down to:

[Thu Aug 11 16:58:24 2016] [drm] Initialized drm 1.1.0 20060810
[Thu Aug 11 16:58:24 2016] random: nonblocking pool is initialized
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[Thu Aug 11 16:58:24 2016] usbcore: registered new interface driver brcmfmac
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[Thu Aug 11 16:58:24 2016] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[Thu Aug 11 16:58:24 2016] [drm] No driver support for vblank timestamp query.
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: No connectors reported connected with modes
[Thu Aug 11 16:58:24 2016] [drm] Cannot find any crtc or sizes - going 1024x768
[Thu Aug 11 16:58:24 2016] Console: switching to colour frame buffer device 128x48
[Thu Aug 11 16:58:24 2016] vc4-drm soc:gpu: fb0: frame buffer device

from linux.

@sandersr It would be great to open your own bug report so that we don't interleave too many conversations (and I'll close this bug whenever I do the upstream support, anyway). Also, please attach full logs, not snippets or pastebin links.

The panel gets probed late due to being a module. That dmesg snippet makes sense for the panel not having been probed at that point. Then later the panel got probed, and it looks like that was done by the time X started. Does xrandr say DSI is on (asterisk next to the mode) and connected when it's displaying black? Is the HDMI showing the desktop correctly? When you switch to another VT and DSI comes on, does switching back to X go back to black?

from linux.

@anholt you're absolutely right, I should have opened a new bug. I'm sorry, I'll get it all sorted.

from linux.

I've updated the upstream-targeting branch again recently. Still not working: it just displays a white screen, like the backlight is on but no particular pixel data has latched. Some open questions:

• Is our i2c-gpio working properly?

I'm not getting errors from the transactions, and the backlight does flash, but running through fading the backlight in and out might be useful for increasing confidence in the I2C side of things.

• Can we tell what is failing?

We did some debug with a scope at the Pi offices, and the conclusion there was that we had HSYNC/VSYNC going into the bridge but not coming out. I don't have a scope myself to test more as I make changes, and I never got confident enough in the scope at the office that I understood what we were seeing.

• Is it possible to hook up different panels?

Could we run the FPC out to a breadboard and wire up somebody else's panel, maybe something with an existing panel driver in the kernel? It would be great to be able to bisect the bug space between the panel driver (driving the fine atmel chip) and the DSI driver itself.

• With recent bugfixes in the branch, could we get things working with firmware starting up the panel and then disabling/enabling it from there?

I used to have a mode in this driver where we inherited from the firmware and got things scanning out, but encoder disable/enable would fail. Trying to go from the downstream tree's use_firmware_setup mode incrementally toward reprogramming everything on disable/enable might be informative.

from linux.

The drm-vc4-dsi branch now has a working driver stack against 4.9-rc1. I'm hoping to merge this for 4.11. The transactions over the DSI bus hadn't been working, and it took writing some nasty firmware workaround code to figure it out. I'd love to be using DSI transactions instead of I2C, but I'm about out of debug energy for DSI at this point.

from linux.

I have an oscilloscope that can decode I2C, a pi3, the official display and I can compile and deploy the kernel. Is there anything I can do to help?

from linux.

At this point what's left to debug is why the ULPS latching fails (the warning thrown at boot on that branch) and why the DSI transactions fail (see #if 0 code in panel-raspberrypi-touchscreen.c). I2C seems to be stable.

from linux.

@anholt Did your drm-vc4-dsi branch make it into 4.11?

from linux.

The DSI driver is in, but the panel driver is blocked.

from linux.

What, if any of this stuff is in https://github.com/raspberrypi/linux rpi-4.9.y ?
Should I be able to use vc4 with my official touchscreen display if I use that kernel now?

from linux.

It's all present in rpi-4.9.y and should work.

from linux.

Everything is upstreamed now (other than DT, which is unclear if it can be upstreamed), so I'm calling this one done. Some patches still need to flow downstream.

from linux.