vc4: 7" LCD touchscreen not supported

Question

vc4: 7" LCD touchscreen not supported

Closed this issue 7 years ago · 34 comments

The DSI1 connector isn't enabled yet. drm-vc4-dsi-boot is the WIP for it, but currently writes to the device don't appear to take effect.

destans commented 9 years ago

+1

nnexai commented 9 years ago

+1

LittleKita commented 9 years ago

+1

Cardhu commented 9 years ago

+1

AndreeeCZ commented 9 years ago

+1

sirdel commented 8 years ago

+1

Answer 1 · 2016-03-09T14:56:26.000Z

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

Answer 2 · 2016-04-01T01:04:17.000Z

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

Answer 3 · 2016-04-03T21:06:11.000Z

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.

Answer 4 · 2016-04-04T17:35:03.000Z

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

Answer 5 · 2016-04-19T00:01:41.000Z

Any progress on this?

Answer 6 · 2016-05-16T10:11:27.000Z

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?

Answer 7 · 2016-05-17T18:20:12.000Z

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

Answer 8 · 2016-06-14T19:52:04.000Z

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.

Answer 9 · 2016-07-07T14:25:09.000Z

Any progress on this? @ghollingworth ? @anholt ?

Answer 10 · 2016-07-07T19:21:35.000Z

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

Answer 11 · 2016-08-01T10:09:28.000Z

Thank you for your work on this!

Answer 12 · 2016-08-05T13:32:31.000Z

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.

Answer 13 · 2016-08-10T17:07:12.000Z

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.

Answer 14 · 2016-08-11T14:45:40.000Z

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

Answer 15 · 2016-08-11T14:48:35.000Z

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

Answer 16 · 2016-08-11T14:49:01.000Z

Creating connection*

Answer 17 · 2016-08-11T16:10:14.000Z

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

Answer 18 · 2016-08-11T19:18:09.000Z

@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?

Answer 19 · 2016-08-12T08:09:55.000Z

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

Answer 20 · 2016-12-06T18:41:59.000Z

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.

Answer 21 · 2016-12-14T00:09:36.000Z

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.

Answer 22 · 2016-12-14T10:21:01.000Z

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?

Answer 23 · 2016-12-14T19:44:09.000Z

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.

Answer 24 · 2017-03-15T10:10:25.000Z

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

Answer 25 · 2017-03-15T22:03:56.000Z

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

Answer 26 · 2017-03-16T14:32:51.000Z

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?

Answer 27 · 2017-03-16T16:07:54.000Z

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

Answer 28 · 2017-11-09T18:34:29.000Z

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.