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

[Jagan Teki]

On Wed, Jan 3, 2018 at 3:26 PM, Vignesh R <vigneshr at 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 at 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.