Adafruit DPI display blank after 1.20150923-1 upgrade

[oniongarlic]

The latest official kernel update release broke my Adafruit DPI display (https://www.adafruit.com/products/2454), it stays white.
Going back with rpi-update to revision 6ade0bac40feeaaaf8ef20eb6b90843e99fbf9a7 makes it work again.
I'm using the dt blob and config available on https://learn.adafruit.com/adafruit-dpi-display-kippah-ttl-tft/installation

[6by9]

Just to check:
2e142eec8f45ec6013dcce267f3b6a0e07c5c5d6 - fails
6ade0bac40feeaaaf8ef20eb6b90843e99fbf9a7 - works
There was a change to the dt-blob.bin required back in June - Adafruit did update their blob, but the robertely tree they based it on hasn't taken the pull request as yet.

I'd expect it to be a firmware change rather than the kernel.
Ping @popcornmix - nothing obvious in the commit history. I guess it'll be something messing with GPIOs 0&1 for HAT related things, and that overriding the dt-blob. I have a Kippah and display if you want to borrow, or get me to test anything. (Gert's VGA666 doesn't need GPIOs 0&1, so that will probably still be working). Something firing up an I2C transaction on GPIOs 0&1 would do it, as the I2C driver doesn't put back the previous state, just returns them to being inputs on semaphore_release.

[6by9]

Confirmed (I got bored) - it's something in commit 2e142eec that is screwing with GPIOs 0&1.

6ade0bac
pi@raspberrypi ~ $ sudo raspi-gpio get
BANK0 (GPIO 0 to 27):
  GPIO 00: level=0 fsel=6 alt=2 func=PCLK
  GPIO 01: level=0 fsel=6 alt=2 func=DE
  GPIO 02: level=0 fsel=6 alt=2 func=LCD_VSYNC
  GPIO 03: level=0 fsel=6 alt=2 func=LCD_HSYNC
  GPIO 04: level=0 fsel=6 alt=2 func=DPI_D0
  GPIO 05: level=0 fsel=6 alt=2 func=DPI_D1
...

2e142eec
pi@raspberrypi ~ $ sudo raspi-gpio get
BANK0 (GPIO 0 to 27):
  GPIO 00: level=1 fsel=0 alt=  func=INPUT <<<<<< :-(
  GPIO 01: level=1 fsel=0 alt=  func=INPUT <<<<<< :-(
  GPIO 02: level=0 fsel=6 alt=2 func=LCD_VSYNC
  GPIO 03: level=0 fsel=6 alt=2 func=LCD_HSYNC
  GPIO 04: level=0 fsel=6 alt=2 func=DPI_D0
  GPIO 05: level=0 fsel=6 alt=2 func=DPI_D1
...

You can restore it once the Pi has booted by using

sudo raspi-gpio set 0 a2
sudo raspi-gpio set 1 a2

but that's a bodge rather than a fix.

I do see a firmware source repo commit bf3605ae that appears to be fiddling with I2C muxing.

Having decompiled the Adafruit blob, I think it is the change on ID_SDA and ID_SCL not being reflected in that blob. (The original values of 0&1 being incorrect, but ignored as the firmware actually used CAMERA_0_SDA_PIN and CAMERA_0_SCL_PIN). That's a bit of a pain as now everyone has to recompile their blobs if they reconfigure GPIOs 0&1 :-(
@popcornmix I can't think of an easy way to make that backwards compatible whilst correcting the code. Any ideas?

[6by9]

Actually I do have a thought, although it's not a full fix.
Phil did an overlay for the VGA666 which sets up the GPIOs correctly, but that misses out GPIO 0&1 as they aren't needed for VGA.
Create a new overlay for DPI, and the kernel would set the muxing correctly even though the firmware HAT code has changed it. The downside is that the kernel only sets that up when it boots so you lose the rainbow splash screen and a bit of the early kernel boot output. With the overlay you don't actually need the custom blob at all.

[popcornmix]

I think the problem is a bug in the dt-bin.dtb file which specified ID_SDA and ID_SCL as pins 0 and 1, which interferes with the DPI display.
There used to be a bug in the firmware where we incorrectly used CAMERA_0_SDA_PIN and CAMERA_0_SCL_PIN rather than the correct symbols for ID_SDA and ID_SCL. Most platforms use the same pins for these, but it isn't guaranteed (e.g. on a compute module).

Can you test this blob file which removes the incorrect ID_SDA/ID_SCL definitions:
https://dl.dropboxusercontent.com/u/3669512/temp/dt-blob.dtb

[popcornmix]

@6by9 has produced this (untested) overlay file:
https://dl.dropboxusercontent.com/u/3669512/temp/dpi-display-overlay.dtb

If you remove the curent dt-blob.bin file, add the new overlay file, and add to config.txt:
dtoverlay=dpi-display
that may also work, and is a preferred solution for the future (as it shouldn't break when we update the firmware dt-blob).

[6by9]

Just to emphasise, you do need all the other lines in config.txt that the Adafruit tutorial tells you to add. The dtoverlay line is in addition, not replacing.
(Thanks popcornmix for posting that on Dropbox)

[oniongarlic]

Thanks for looking into it. I'll test as soon as I'm with my Pi again.

[6by9]

I'm slightly confused now.
My overlay recovers the display when combined with the now incorrect blob from Adafruit, so is setting the pinmuxing correctly. However it doesn't seem to be sufficient to do the job without the blob. I guess it must be drive strength or terminations that differ from default (though I can't see any immediate diffs).
No time today, but will try to look tonight by slimming down the blob until I get the base set that works.

[errolt]

The blob, from https://github.com/robertely/dpi666/blob/master/setup/dt-blob-dpi.dts, seems OK. The display data starts on the DPI bus, but shortly after startup the clock and de pins are assigned back to I2C. Switching this back via an overlay seems like a workaround. Why does the HAT code ignore the devicetree? Is there no way to disable the HAT I2C bus via the config.txt?

[6by9]

The blob on github is identical to Adafruit's blob. Both have incorrectly defined ID_SDA and ID_SCL as being 0 & 1, not 28 & 29.

This "device tree" is configuring the firmware side, not the kernel. There aren't the same restrictions within the firmware on peripheral access control.

On the Compute Module, I2C0 is dynamically muxed between GPIOs 0&1 or 28&29 for when running two cameras (they both have the same I2C address). After each use, the GPIO is reset back to input. That is why you will generally see 28&29 assigned as input even with the camera running.

The HAT code is running only on boot, but after it has accessed the incorrectly defined GPIOs 0&1, it puts them back to inputs. Correcting ID_SDA and ID_SCL to 28 & 29 is the correct fix - without that HATs won't work (but they're unlikely to anyway as all the GPIOs are nicked for DPI). I will sort out an updated dt-blob for robertely and Adafruit when I get 2 minutes, but there may be many other copies floating around - this is not a controlled release process.

There was discussion about putting back the muxing after I2C use, but that was mainly because people were trying to allow both ARM and VC access to I2C0 at the same time, and the ARM kept losing out because the pins were remuxed back to inputs. I still don't see there being a real argument for it here.

The discussion over a kernel dt-overlay for dpi is really as it makes it an easier way to configure for a DPI screen - dt-blob.bin really is a low level thing that general users shouldn't need to fiddle with.

@popcornmix I see config.txt option force_eeprom_read. Am I right in thinking setting this to 0 will stop HAT probing and work around this issue? Possibly easier to get people to make a config.txt change than a blob change. (I'll still sort out an overlay anyway)

[errolt]

Ahh, this section?
pin_define@ID_SDA {
type = "internal";
number = <0>;
};
pin_define@ID_SCL {
type = "internal";
number = <1>;
};
should change to
pin_define@ID_SDA {
type = "internal";
number = <28>;
};
pin_define@ID_SCL {
type = "internal";
number = <29>;
};
Is that correct? Sorry, new to devicetrees and such.

Edit: It works. Thank you! :)

[errolt]

Hmm, updating the blob "works". Pi starts up with DPI on pin 0 and 1, then HAT code takes over, but when it is done it switches back to DPI?

[popcornmix]

@6by9 ID_SDA and ID_SCL should be 0 & 1 on most platforms, so that is not the issue.
Moving them to pins 28 & 29 is just having the same effect as disabling them which we know works.

@pelwell has said he'd have a look at why the dtoverlay is not doing what we want.

[6by9]

Ah, got confused over which GPIOs it was meant to be on. (How have HATs worked in the past when it was using the camera SDA/SCL defines? Perhaps they haven't and that was why the firmware changed! Doesn't really matter, just puzzled).

There is no way to use a HAT as well as a DPI display, so removing the HAT probing is one option. Have I read it right that "force_eeprom_read=0" will do that?
They've already got to mess around in config.txt to put in the config, so adding that is minimal headache.

Ta to Phil - I just ran out of time when I was looking at it the other day. Shout if he wants display hardware - I have it with me and can drop it over to you.

[pelwell]

So it turns out that, while not perfect, the original hat_probe code was correct. Its use of the camera pins was to prevent I2C0 from being mapped to multiple pin groups simultaneously, and the ID pins were hackily hard-coded to 0 and 1. The effect of the previous change was to leave the camera pins alone, which would cause problems if they were using I2C0, and to save the state of the ID pins twice, setting them to inputs in-between. Since the original values were restored in the same (not reversed) sequence, this has the effect of leaving 0 and 1 as inputs.

I've given @popcornmix a patch.

[6by9]

Ouch! Nice bit of detective work - glad I hadn't dug into it too much.
I believe there is no need to explicitly set 0&1 to I2C0 mode - obtain_i2c_semaphore will do that for you, but it will always set them back to inputs afterwards.

[pelwell]

The latest firmware release includes the patch. Please update and retest.

[oniongarlic]

Display works again, thanks !

[gdudek]

Since upgrading to kernel 4.1.19 my analog audio is coming out high pitched (about 1.2 times the correct frequency) when I use the blobs here.

[gdudek]

The overlay from robertely/dpi666 works well for me, with the awful proviso that my audio sounds speeded up afterwards (by a factor of about 1.2). Any ideas or help? I have tried to rebuild the dts file with trial-and-error changes to the clock stuff, but it's black magic to me.

[gdudek]

Complied my own dts using
vco@PLLD { freq = <2400000000>; };
in the clock section and my audio problems (high pitched sound) are resolved.