[Letux-kernel] GTA04 display and 5.10-rc5

[H. Nikolaus Schaller]

Hi,

> Am 30.11.2020 um 14:23 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi Tomi and Andreas,
> 
>> Am 30.11.2020 um 13:29 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
>> 
>> On 30/11/2020 12:35, H. Nikolaus Schaller wrote:
>> 
>>> So this makes it clear that it is the new omapdrm-mipi-dsi series which I
>>> have started to integrate into letux-5.10-rc5.
>>> 
>>> This series seems to break drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
>>> while the Letux3704 uses one of the drivers/gpu/drm/panel/panel-simple.c
>>> definitions. This explains why there is another difference between your
>>> devices.
>>> 
>>> So something in Tomis series seems to break DPI with the specific driver.
>>> The same may happen for VENC so we have to look at it as well.
>> 
>> I tested my DSI series with omap4 panda (DVI output via DPI), and it works both with modules and
>> built-in. So at least it's not totally broken.
> 
> A first assessment:
> prepare and enable are called properly and write spi commands to the panel.
> 
> It seems some upstream patch between 5.10-rc3 and 5.10-rc6 which breaks the
> GTA04/OMAP3 display. Maybe also something in gpio-spi or gpio so that the
> panel stays in reset state.
> 
> I will now bisect.

Good news: it is NOT the DSI series or anything in omapdrm.
Bad news: once again people did break existing gpio-spi...

766c6b63aa044e84b045803b40b14754d69a2a1d is the first bad commit
commit 766c6b63aa044e84b045803b40b14754d69a2a1d
Author: Sven Van Asbroeck <thesven73 at gmail.com>
Date:   Fri Nov 6 10:07:06 2020 -0500

    spi: fix client driver breakages when using GPIO descriptors
    
    Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
    introduced the optional use of GPIO descriptors for chip selects.
    
    A side-effect of this change: when a SPI bus uses GPIO descriptors,
    all its client devices have SPI_CS_HIGH set in spi->mode. This flag is
    required for the SPI bus to operate correctly.
    
    This unfortunately breaks many client drivers, which use the following
    pattern to configure their underlying SPI bus:
    
    static int client_device_probe(struct spi_device *spi)
    {
            ...
            spi->mode = SPI_MODE_0;
            spi->bits_per_word = 8;
            err = spi_setup(spi);
            ..
    }
    
    In short, many client drivers overwrite the SPI_CS_HIGH bit in
    spi->mode, and break the underlying SPI bus driver.
    
    This is especially true for Freescale/NXP imx ecspi, where large
    numbers of spi client drivers now no longer work.
    
    Proposed fix:
    -------------
    When using gpio descriptors, depend on gpiolib to handle CS polarity.
    Existing quirks in gpiolib ensure that this is handled correctly.
    
    Existing gpiolib behaviour will force the polarity of any chip-select
    gpiod to active-high (if 'spi-active-high' devicetree prop present) or
    active-low (if 'spi-active-high' absent). Irrespective of whether
    the gpio is marked GPIO_ACTIVE_[HIGH|LOW] in the devicetree.
    
    Loose ends:
    -----------
    If this fix is applied:
    - is commit 138c9c32f090
      ("spi: spidev: Fix CS polarity if GPIO descriptors are used")
      still necessary / correct ?
    
    Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
    Signed-off-by: Sven Van Asbroeck <thesven73 at gmail.com>
    Acked-by: Linus Walleij <linus.walleij at linaro.org>
    Link: https://lore.kernel.org/r/20201106150706.29089-1-TheSven73@gmail.com
    Signed-off-by: Mark Brown <broonie at kernel.org>

 drivers/spi/spi.c | 23 ++++++-----------------
 1 file changed, 6 insertions(+), 17 deletions(-)


BR,
Nikolaus