[Pkg-raspi-maintainers] Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

[Bjørn Mork]

Cyril Brulebois <cyril at debamax.com> writes:

> Cyril Brulebois <cyril at debamax.com> (2022-04-29):
>> > I'll try and pinpoint when it broke using the various intermediary
>> > versions:
>> > 
>> >  - 5.17~rc3-1~exp1
>> 
>> The first attempt was sufficient: it breaks as early as that version.
>
> Using the same base image as before, and only updating the kernel: I've
> tested upstream builds, starting from the .config found in the Debian
> 5.16.18-1 package, using oldconfig and accepting everything by default:
>
>  - v5.16 is confirmed a first good;
>  - v5.17-rc1 is confirmed a first bad;
>  - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61

But that's a merge commit. Not likely the real cuplrit, unless there's a
merge bug.

I looked briefly at what was merged there, and I believe this commit
stands out as suspicious:

bjorn at miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Mon Nov 22 23:21:56 2021 +0100

    mmc: bcm2835: stop setting chan_config->slave_id
    
    The field is not interpreted by the DMA engine driver, as all the data
    is passed from devicetree instead. Remove the assignment so the field
    can eventually be deleted.
    
    Reviewed-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
    Signed-off-by: Arnd Bergmann <arnd at arndb.de>
    Acked-by: Ulf Hansson <ulf.hansson at linaro.org>
    Acked-by: Mark Brown <broonie at kernel.org>
    Link: https://lore.kernel.org/r/20211122222203.4103644-5-arnd@kernel.org
    Signed-off-by: Vinod Koul <vkoul at kernel.org>

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 8c2361e66277..463b707d9e99 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1293,14 +1293,12 @@ static int bcm2835_add_host(struct bcm2835_host *host)
 
                host->dma_cfg_tx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
                host->dma_cfg_tx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-               host->dma_cfg_tx.slave_id = 13;         /* DREQ channel */
                host->dma_cfg_tx.direction = DMA_MEM_TO_DEV;
                host->dma_cfg_tx.src_addr = 0;
                host->dma_cfg_tx.dst_addr = host->phys_addr + SDDATA;
 
                host->dma_cfg_rx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
                host->dma_cfg_rx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-               host->dma_cfg_rx.slave_id = 13;         /* DREQ channel */
                host->dma_cfg_rx.direction = DMA_DEV_TO_MEM;
                host->dma_cfg_rx.src_addr = host->phys_addr + SDDATA;
                host->dma_cfg_rx.dst_addr = 0;


But I'm basing that only on it being related to the bcm28/27xx SoCs and
a bit unexpected in the sound merge...  I cannot explain why this mmc
host driver change should affect your display.  Could be completely
wrong.  But migt be worth testing?



Bjørn