Re: [PATCH 1/3] spi: Add addr_width field to struct spi_message

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

Hi Zhiqiang,

On Tue, May 12, 2015 at 10:06 AM, Hou Zhiqiang <B48286@xxxxxxxxxxxxx> wrote:
>> From: geert.uytterhoeven@xxxxxxxxx [mailto:geert.uytterhoeven@xxxxxxxxx]
>> On Behalf Of Geert Uytterhoeven
>> Sent: 2015年5月11日 15:43
>> To: Hou Zhiqiang-B48286
>> Cc: linux-spi; Mark Brown; Hu Mingkai-B21284
>> Subject: Re: [PATCH 1/3] spi: Add addr_width field to struct spi_message
>>
>> On Sun, May 10, 2015 at 4:47 PM, Zhiqiang Hou <B48286@xxxxxxxxxxxxx>
>> wrote:
>> > From: Hou Zhiqiang <B48286@xxxxxxxxxxxxx>
>> >
>> > Make SPI controller can get address width of the SPI device.
>>
>> What does "address wdith" mean? From your other patches, I infer it's
>> either
>> 24 or 32 bit addressing as used by nor-jedec ("m25p80").
>> Why does the generic spi_message needs to have nor-jedec-specific fields?
>
> Yes, the address width is the address width of spi flash.
> The reason to add this nor-jedec-specific field to spi_message is the eSPI controller
> of Freescale limits the MAX transaction length(TRANLEN) to 0x10000 each transaction, so if the
> data size transferred exceed the TRANLEN, the eSPI controller can only transfer data for
> the first TRANLEN, and need to issue new write/read commands to complete the remainders.
> So, eSPI controller need getting the address width of spi flash, and then calculate the
> new address to initialize the new write/read commands.

Shouldn't this be handled by the m25p80 driver instead?

I see spi_master has a max_dma_len field.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html