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

H. Nikolaus Schaller hns at goldelico.com
Wed May 29 10:56:41 CEST 2019


> Am 29.05.2019 um 09:05 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> 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...

Next finding using linus/v5.2-rc2 and omap2plus_defconfig on the OMAP5 EVM:

[    5.212678] reg-fixed-voltage modem_power_reg: No GPIO consumer (null) found
[    5.212998] pca953x 3-0022: GPIO lookup for consumer reset
[    5.223364] at24 0-0050: 256 byte 24c02 EEPROM, writable, 1 bytes/write
[    5.225311] pca953x 3-0022: using device tree for GPIO lookup
[    5.237702] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect at 48000000/segment at 0/target-module at 7a000/i2c at 0/tca6424 at 22[0]'
[    5.238956] omap_hsmmc 480ad000.mmc: GPIO lookup for consumer wp
[    5.252040] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/interconnect at 48000000/segment at 0/target-module at 7a000/i2c at 0/tca6424 at 22[0]'
[    5.252047] pca953x 3-0022: using lookup tables for GPIO lookup
[    5.258074] omap_hsmmc 480ad000.mmc: using device tree for GPIO lookup
[    5.272308] pca953x 3-0022: No GPIO consumer reset found
[    5.278259] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp/interconnect at 48000000/segment at 0/target-module at ad000/mmc at 0[0]'
[    5.284961] pca953x 3-0022: failed writing register
[    5.290141] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/ocp/interconnect at 48000000/segment at 0/target-module at ad000/mmc at 0[0]'

So there is also failure:

[    5.284961] pca953x 3-0022: failed writing register

We are coming closer... Something in the regmap or i2c or pca953x address
calculation is going wrong.

BR,
Nikolaus



More information about the Letux-kernel mailing list