Estoy atascado durante los últimos 3 días en un punto.
Estoy trabajando en el controlador de dispositivo eink con el chipset msm8960 qualcomm.
Scenario:En el archivo: kernel/arch/arm/mach-msm/devices-8960.c
No puedo verificar las use of spidm_channels" and "spidm_crci"entradas correspondientes. (msm8960 pro) (copiado de algún código de referencia) ¿Cómo verificar si los valores correspondientes start and endson correctos? Tengo una hoja de datos para msm pero no puedo encontrar ninguna referencia.
He agregado el siguiente código para crear un nuevo recurso gsbi en el archivo como:
static struct resource resources_qup_spi_gsbi9[] = {
{
.name = "spi_base",
.start = MSM_GSBI9_QUP_PHYS,
.end = MSM_GSBI9_QUP_PHYS + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = "gsbi_base",
.start = MSM_GSBI9_PHYS,
.end = MSM_GSBI9_PHYS + 4 - 1,
.flags = IORESOURCE_MEM,
},
{
.name = "spi_irq_in",
.start = GSBI9_QUP_IRQ,
.end = GSBI9_QUP_IRQ,
.flags = IORESOURCE_IRQ,
},
{
.name = "spidm_channels",
.start = 3,
.end = 4,
.flags = IORESOURCE_DMA,
},
{
.name = "spidm_crci",
.start = 12,
.end = 13,
.flags = IORESOURCE_DMA,
},
};
La razón de tener esta duda es que nuestra operación DMA está fallando con el error: from logs:
<6>[ 0.764932] wait_for_ready: I/F Ready.^M
<7>[ 0.765176] s1d13522_ spi9.0: setup mode 0, 16 bits/w, 51200000 Hz max --> 0^M
<3>[ 1.756630] spi_qsd spi_qsd.9: msm_spi_process_transfer: SPI transaction timeout^M
y luego si intentamos realizar otra operación DMA da el siguiente error:
<3>[ 6.773355] s1d13522if_cmd: wait_for_ready: I/F busy bit stuck^M
<7>[ 6.775400] s1d13522_ spi9.0: setup mode 0, 16 bits/w, 51200000 Hz max --> 0^M
<4>[ 6.775583] ------------[ cut here ]------------^M
<4>[ 6.775614] WARNING: at /home/anshul_10605816/hip_mirror_2330_code/kernel /lib/list_debug.c:32 __list_add+0x58/0x78()^M
<4>[ 6.775644] list_add corruption. prev->next should be next (c0d5124c), but was 00100100. (prev=edf643b8).^M
<4>[ 6.775675] Modules linked in:^M
<4>[ 6.775766] [<c00149b8>] (unwind_backtrace+0x0/0x11c) from [<c007c818>] (warn_slowpath_common+0x4c/0x64)^M
<4>[ 6.775827] [<c007c818>] (warn_slowpath_common+0x4c/0x64) from [<c007c8b0>] (warn_slowpath_fmt+0x2c/0x3c)^M
<4>[ 6.775888] [<c007c8b0>] (warn_slowpath_fmt+0x2c/0x3c) from [<c02a9538>] (__list_add+0x58/0x78)^M
<4>[ 6.775919] [<c02a9538>] (__list_add+0x58/0x78) from [<c001e3d4>] (start_ready_cmd+0x84/0x13c)^M
<4>[ 6.775980] [<c001e3d4>] (start_ready_cmd+0x84/0x13c) from [<c001e704>] (msm_dmov_enqueue_cmd_ext_work+0x148/0x284)^M
<4>[ 6.776041] [<c001e704>] (msm_dmov_enqueue_cmd_ext_work+0x148/0x284) from [<c0094e0c>] (process_one_work+0x27c/0x484)^M
<4>[ 6.776072] [<c0094e0c>] (process_one_work+0x27c/0x484) from [<c0095224>] (worker_thread+0x210/0x3b0)^M
<4>[ 6.776133] [<c0095224>] (worker_thread+0x210/0x3b0) from [<c00990c0>] (kthread+0x80/0x8c)^M
<4>[ 6.776194] [<c00990c0>] (kthread+0x80/0x8c) from [<c000f108>] (kernel_thread_exit+0x0/0x8)^M
<4>[ 6.776224] ---[ end trace da227214a82491b8 ]---^M
<3>[ 11.766732] spi_qsd spi_qsd.9: msm_spi_process_transfer: SPI transaction timeout^M
Cualquier ayuda sería muy apreciada.
Si necesita más información sobre el código, hágamelo saber.
La configuración de recursos depende de su plataforma, no solo del controlador.
Una idea podría ser validar su bus SPI antes de usarlo directamente con el conjunto de chips de destino. Sugiero usar la interfaz Spidev y un código de espacio de usuario para enviar algo en el bus y observar el resultado en un analizador lógico o un osciloscopio. Usualmente hago eso para validar nuevos tableros.
La corrupción de list_add es sospechosa, pero es difícil decir más en ese punto.