[Letux-kernel] Pyra display driver once again broken in v5.2-rc1

[H. Nikolaus Schaller]

> Am 29.05.2019 um 07:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 29.05.2019 um 07:16 schrieb Andreas Kemnade <andreas at kemnade.info>:
>> 
>> On Wed, 29 May 2019 06:39:22 +0200
>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> 
>>>> Am 28.05.2019 um 23:40 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>> 
>>>> On Mon, 27 May 2019 21:25:41 +0200
>>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>> 
>>>>>> Am 27.05.2019 um 14:46 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>>>> 
>>>>>> Hi,
>>>>>> unfortunately every year or so some upstream change breaks
>>>>>> our (still out-of tree) DSI panel driver for the Pyra(Phone).
>>>>>> This time it happened with v5.2-rc1.
>>>>>> 
>>>>>> v5.2-rc1 also broke the GTA04 display and the L3704/L7004 displays,
>>>>>> but those are DPI panels and the reasons were two separate
>>>>>> issues which have nothing to do with the Pyra DSI panel.
>>>>>> 
>>>>>> There have been some API changes for DSI panel drivers and
>>>>>> I have done a
>>>>>> 
>>>>>> 	git diff v5.2-rc1 v5.1 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
>>>>>> 
>>>>>> to identify them and tried to apply similar patches to our
>>>>>> panel. But still the driver is successfully probed, but shows
>>>>>> not activity. No calls to enable() or connect(). Backlight stays
>>>>>> black. And as a result there is also no /dev/fb0, text console
>>>>>> or X11.
>>>>>> 
>>>>>> Unfortunately, it has not improved after upgrading to v5.2-rc2.
>>>>>> 
>>>>>> So once again it appears that I have to git bisect upstream
>>>>>> patches to find out what is going on...    
>>>>> 
>>>>> After spending more hours... it does not seem to be in our patches
>>>>> and the panel driver is likely almost correct now.
>>>>> 
>>>>> I believe this because I also found not working:
>>>>> * dwc3 (usb3/otg port)
>>>>> * bq24297 battery charger driver (my Pyra fortunately runs well enough with U-Boot initialization)
>>>>> * tca6424 (gpio expander - we use the pcal9524 variant)
>>>>> 
>>>>> The tca6424 driver seems to be broken (not loaded).
>>>>> 
>>>> [    6.581432] ts3a227e 4-003b: Cannot request irq 0 (-22)
>>>> [    6.597252] ts3a227e: probe of 4-003b failed with error -22
>>>> 
>>>> so somehow it insists of having an irq and we are not providing one in
>>>> the dtb, at least not in pyra-mainboard-v5.1.dtsi  
>>> 
>>> The reference is set in pyra-mainboard-v5.2.dtsi
>>> 
>> ... which is as far as I understand not used on a 5.1 board.
>> 
>>> 		interrupt-parent = <&gpio99>;
>>> 		interrupts = <14 IRQ_TYPE_EDGE_RISING>;
>>> 
>>> But: this is another symptom of the tca6424 (gpio99) not being available.
>>> It is not only a gpio expander but also an interrupt expander.
>> 
>> so it an independant problem.
>>> 
>>> So we should focus on finding out why the tca6424 / pcal6524 does
>>> not probe.
>> 
>> yes, I disabled the hdmi stuff completely. Result: Display works.
> 
> Ok, fine! So we at least have an idea that the broken display is this
> time just a symptom and not a bug...
> 
> Strangely I do not see a printk() added to pca953x_probe()...

Well, it turned out that my dmesg buffer was too small to find it after
booting and login.

Here is something related:

[    7.457864] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
[    7.463749] bus: 'platform': really_probe: bound device 4807a000.i2c to driver omap_i2c
[    7.472247] bus: 'platform': driver_probe_device: matched device 4807c000.i2c with driver omap_i2c
[    7.481649] really_probe: driver omap_i2c
[    7.485860] bus: 'platform': really_probe: probing driver omap_i2c with device 4807c000.i2c
[    7.495402] bus: 'i2c': driver_probe_device: matched device 4-0022 with driver pca953x
[    7.503697] really_probe: driver pca953x
[    7.507827] bus: 'i2c': really_probe: probing driver pca953x with device 4-0022
[    7.515531] pca953x_probe: tca6424
[    7.519129] vdds_1v8_main: supplied by smps7
[    7.524125] pca953x 4-0022: failed writing register
[    7.529444] pca953x: probe of 4-0022 failed with error -22
[    7.535545] omap_i2c 4807c000.i2c: bus 4 rev0.12 at 400 kHz
[    7.541420] bus: 'platform': really_probe: bound device 4807c000.i2c to driver omap_i2c
[    7.549934] bus: 'platform': driver_probe_device: matched device 40132000.target-module with driver ti-sysc

So this maybe has a different reason. Maybe, the tca6424 is kept in RESET state?

No. It is responding:

root at letux:~# i2cdetect -r -y 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- 3b -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root at letux:~# i2cdump -y 4 0x22
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 48 02 XX 00 00 00 XX 00 00 00 XX 00 48 0f XX    .H?X...X...X.H?X
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX ^C
root at letux:~# 

Well, this are not the real register values since the tca6424 uses
a "pointer register" that must be written before reading.

It is like an adventure game to find out what is going wrong...

BR,
Nikolaus