[U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support

Jagan Teki
2018-01-03T10:07:10Z

On Wed, Jan 3, 2018 at 3:26 PM, Vignesh R <vigneshr@ti.com> wrote:
>
>
> On Wednesday 03 January 2018 03:02 PM, Jagan Teki wrote:
>> On Wed, Jan 3, 2018 at 2:19 PM, Vignesh R <vigneshr@ti.com> wrote:
>>>
>>>
>>> On Thursday 28 December 2017 11:42 AM, Jagan Teki wrote:
>>> [...]
>>>> +static const struct mtd_ops spi_nor_mtd_ops = {
>>>> + .read = spi_nor_mread,
>>>> + .erase = spi_nor_merase,
>>>> +};
>>>> +
>>>
>>> Wondering why spi_nor_mwrite is not hooked up here?
>>
>> yes, because of sst we need to assign the write hook during scan, see spi-nor.c
>>
>>>
>>>> +U_BOOT_DRIVER(spinor_mtd) = {
>>>> + .name = "spinor_mtd",
>>>> + .id = UCLASS_MTD,
>>>> + .ops = &spi_nor_mtd_ops,
>>>> + .probe = spi_nor_mtd_probe,
>>>> +};
>>>> +
>>>> +U_BOOT_DRIVER(spinor) = {
>>>> + .name = "spinor",
>>>> + .id = UCLASS_SPI_NOR,
>>>> +};
>>>> +
>>>> +UCLASS_DRIVER(spinor) = {
>>>> + .id = UCLASS_SPI_NOR,
>>>> + .name = "spinor",
>>>> + .flags = DM_UC_FLAG_SEQ_ALIAS,
>>>> + .per_device_auto_alloc_size = sizeof(struct spi_nor_uclass_priv),
>>>> +};
>>>
>>> [...]
>>>
>>>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>>>> new file mode 100644
>>>> index 0000000..e1688e2
>>>> --- /dev/null
>>>> +++ b/include/linux/mtd/spi-nor.h
>>>> @@ -0,0 +1,217 @@
>>> [...]
>>>> +struct spi_nor {
>>>> + struct udevice *dev;
>>>> + const char *name;
>>>> + u8 init_done;
>>>> + u32 page_size;
>>>> + u8 addr_width;
>>>> + u8 erase_opcode;
>>>> + u8 read_opcode;
>>>> + u8 read_dummy;
>>>> + u8 program_opcode;
>>>> + u32 max_write_size;
>>>> + u32 flags;
>>>> + u8 mode;
>>>
>>>> + u8 read_mode;
>>>
>>> Where is this field used? Shouldn't this field carry single/dual/quad
>>> mode information?
>>
>> I think it came up from previous versions, no real use as of now will
>> check and update in next version
>
> This field is very much needed to inform SPI NOR controllers where to
> use 1-1-2 or 1-1-4 or 1-1-1 mode for reading data from flash. It should
> be the SPI NOR framework providing this info and not expecting driver to
> assume this or infer from DT.

yes remember, we have common mode(for both read and write) ie
initialized and used in spi-nor instead have read_mode.