* Query: spi-nor: dummy buswidth calculation
@ 2018-09-04 9:28 ` Yogesh Narayan Gaur
0 siblings, 0 replies; 6+ messages in thread
From: Yogesh Narayan Gaur @ 2018-09-04 9:28 UTC (permalink / raw)
To: boris.brezillon, linux-mtd, linux-spi
Hi Boris,
I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
In func m25p80_read(), dummy.buswidth is being assigned as
+ op.dummy.buswidth = op.addr.buswidth;
Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
- op.dummy.buswidth = op.addr.buswidth;
+ op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
[1] https://patchwork.kernel.org/patch/10334345/
--
Regards
Yogesh Gaur
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Query: spi-nor: dummy buswidth calculation
@ 2018-09-04 9:28 ` Yogesh Narayan Gaur
0 siblings, 0 replies; 6+ messages in thread
From: Yogesh Narayan Gaur @ 2018-09-04 9:28 UTC (permalink / raw)
To: boris.brezillon, linux-mtd, linux-spi
Hi Boris,
I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
In func m25p80_read(), dummy.buswidth is being assigned as
+ op.dummy.buswidth = op.addr.buswidth;
Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
- op.dummy.buswidth = op.addr.buswidth;
+ op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
[1] https://patchwork.kernel.org/patch/10334345/
--
Regards
Yogesh Gaur
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query: spi-nor: dummy buswidth calculation
2018-09-04 9:28 ` Yogesh Narayan Gaur
@ 2018-09-04 12:30 ` Boris Brezillon
-1 siblings, 0 replies; 6+ messages in thread
From: Boris Brezillon @ 2018-09-04 12:30 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: juliensu, zhengxunli, linux-mtd, masonccyang, linux-spi
+Macronix team
On Tue, 4 Sep 2018 09:28:11 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Boris,
>
> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
>
> In func m25p80_read(), dummy.buswidth is being assigned as
> + op.dummy.buswidth = op.addr.buswidth;
>
> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
>
> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
Interesting. Macronix is also working on octo-mode support. I think we
should sync instead of duplicating the work.
>
> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
> - op.dummy.buswidth = op.addr.buswidth;
> + op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
Regarding this particular aspect, I just followed what was done before
the conversion to spi_mem_exec_op(). Maybe it was not correct though.
Regards,
Boris
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query: spi-nor: dummy buswidth calculation
@ 2018-09-04 12:30 ` Boris Brezillon
0 siblings, 0 replies; 6+ messages in thread
From: Boris Brezillon @ 2018-09-04 12:30 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: linux-mtd, linux-spi, juliensu, zhengxunli, masonccyang
+Macronix team
On Tue, 4 Sep 2018 09:28:11 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Boris,
>
> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
>
> In func m25p80_read(), dummy.buswidth is being assigned as
> + op.dummy.buswidth = op.addr.buswidth;
>
> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
>
> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
Interesting. Macronix is also working on octo-mode support. I think we
should sync instead of duplicating the work.
>
> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
> - op.dummy.buswidth = op.addr.buswidth;
> + op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
Regarding this particular aspect, I just followed what was done before
the conversion to spi_mem_exec_op(). Maybe it was not correct though.
Regards,
Boris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query: spi-nor: dummy buswidth calculation
2018-09-04 12:30 ` Boris Brezillon
@ 2018-09-04 13:10 ` Cyrille Pitchen
-1 siblings, 0 replies; 6+ messages in thread
From: Cyrille Pitchen @ 2018-09-04 13:10 UTC (permalink / raw)
To: Boris Brezillon, Yogesh Narayan Gaur
Cc: juliensu, linux-spi, masonccyang, linux-mtd, zhengxunli
Hi all,
Le 04/09/2018 à 14:30, Boris Brezillon a écrit :
> +Macronix team
>
> On Tue, 4 Sep 2018 09:28:11 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
>
>> Hi Boris,
>>
>> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
>>
>> In func m25p80_read(), dummy.buswidth is being assigned as
>> + op.dummy.buswidth = op.addr.buswidth;
>>
>> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
>> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
>>
>> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
>> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
>
> Interesting. Macronix is also working on octo-mode support. I think we
> should sync instead of duplicating the work.
>
>>
>> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
>> - op.dummy.buswidth = op.addr.buswidth;
>> + op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
>
> Regarding this particular aspect, I just followed what was done before
> the conversion to spi_mem_exec_op(). Maybe it was not correct though.
>
Actually this is correct and changing that for the above proposal would
clearly break support of all existing memories in SPI 1-1-2 or SPI 1-1-4.
SPI x-y-z means:
- x I/O line(s) for the instruction op code cycles
- y I/O line(s) for the address/mode/dummy cycles
- z I/O line(s) for the data cycles
Till now, this is how all Dual or Quad SPI NOR flash memories work.
Besides, according to the recent JEDEC JESD126 rev C specification,
introducing support to Octo SPI protocols:
6.4.20 JEDEC Basic Flash Parameter Table: 17th DWORD
Bits Description
23:21 (1-1-8) Fast Read Number of Mode Clocks
This filed will be 000b if Mode Bits are not supported.
NOTE This field should be counted in clocks not number of bits
received by the serial flash. The master drivers the bus during
"mode bits" cycles, the master tri-states the bus during
"dummy" cycles.
Example: If 4 mode bits are needed with a single input address
phase command, this field would be 100b.
20:16 (1-1-8) Fast Read Number of Wait states (dummy clocks) needed
before valid output
This field will be 00000b if wait states/dummy clocks are not supported.
(The number of dummy clocks should be > 0 to avoid contention on bi-
directional pins.)
Example: If 8 bits are needed with a single input address phase command,
this field would be 01000b.
So it looks like SPI 1-1-8 follows the same logic as SPI 1-1-2 and SPI 1-1-4.
Then either there is an error about the actual number of dummy clock cycles to
use or Micron folks have decided to design things their own way.
I've tried to download the datasheet for MT35XU512ABA1G12 but its under NDA.
Best regards,
Cyrille
> Regards,
>
> Boris
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query: spi-nor: dummy buswidth calculation
@ 2018-09-04 13:10 ` Cyrille Pitchen
0 siblings, 0 replies; 6+ messages in thread
From: Cyrille Pitchen @ 2018-09-04 13:10 UTC (permalink / raw)
To: Boris Brezillon, Yogesh Narayan Gaur
Cc: juliensu, zhengxunli, linux-mtd, masonccyang, linux-spi
Hi all,
Le 04/09/2018 à 14:30, Boris Brezillon a écrit :
> +Macronix team
>
> On Tue, 4 Sep 2018 09:28:11 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
>
>> Hi Boris,
>>
>> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
>>
>> In func m25p80_read(), dummy.buswidth is being assigned as
>> + op.dummy.buswidth = op.addr.buswidth;
>>
>> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
>> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
>>
>> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
>> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.
>
> Interesting. Macronix is also working on octo-mode support. I think we
> should sync instead of duplicating the work.
>
>>
>> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
>> - op.dummy.buswidth = op.addr.buswidth;
>> + op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
>
> Regarding this particular aspect, I just followed what was done before
> the conversion to spi_mem_exec_op(). Maybe it was not correct though.
>
Actually this is correct and changing that for the above proposal would
clearly break support of all existing memories in SPI 1-1-2 or SPI 1-1-4.
SPI x-y-z means:
- x I/O line(s) for the instruction op code cycles
- y I/O line(s) for the address/mode/dummy cycles
- z I/O line(s) for the data cycles
Till now, this is how all Dual or Quad SPI NOR flash memories work.
Besides, according to the recent JEDEC JESD126 rev C specification,
introducing support to Octo SPI protocols:
6.4.20 JEDEC Basic Flash Parameter Table: 17th DWORD
Bits Description
23:21 (1-1-8) Fast Read Number of Mode Clocks
This filed will be 000b if Mode Bits are not supported.
NOTE This field should be counted in clocks not number of bits
received by the serial flash. The master drivers the bus during
"mode bits" cycles, the master tri-states the bus during
"dummy" cycles.
Example: If 4 mode bits are needed with a single input address
phase command, this field would be 100b.
20:16 (1-1-8) Fast Read Number of Wait states (dummy clocks) needed
before valid output
This field will be 00000b if wait states/dummy clocks are not supported.
(The number of dummy clocks should be > 0 to avoid contention on bi-
directional pins.)
Example: If 8 bits are needed with a single input address phase command,
this field would be 01000b.
So it looks like SPI 1-1-8 follows the same logic as SPI 1-1-2 and SPI 1-1-4.
Then either there is an error about the actual number of dummy clock cycles to
use or Micron folks have decided to design things their own way.
I've tried to download the datasheet for MT35XU512ABA1G12 but its under NDA.
Best regards,
Cyrille
> Regards,
>
> Boris
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-04 13:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-04 9:28 Query: spi-nor: dummy buswidth calculation Yogesh Narayan Gaur
2018-09-04 9:28 ` Yogesh Narayan Gaur
2018-09-04 12:30 ` Boris Brezillon
2018-09-04 12:30 ` Boris Brezillon
2018-09-04 13:10 ` Cyrille Pitchen
2018-09-04 13:10 ` Cyrille Pitchen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.