RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:40 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 09:05:23 + > Yogesh Narayan Gaur wrote: > > > Hi, > > > > > -Original Message- > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > > Sent: Tuesday, October 23, 2018 2:31 PM > > > To: Yogesh Narayan Gaur > > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > > ; rich...@nod.at; Mark Brown > > > ; linux-kernel@vger.kernel.org; > > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; > > > Cyrille Pitchen ; > > > computersforpe...@gmail.com; dw...@infradead.org; > > > linux-arm-ker...@lists.infradead.org > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform > > > SFDP SPI NOR flash memories > > > > > > On Tue, 23 Oct 2018 10:48:27 +0200 > > > Boris Brezillon wrote: > > > > > > > On Tue, 23 Oct 2018 08:18:35 + Yogesh Narayan Gaur > > > > wrote: > > > > > > > > > > > > > > I have added the prints in m25p80_read() and in flexspi > > > > > controller prepare_lut > > > and read_rxfifo() func. > > > > > In these have added prints for data variable of struct op and > > > > > data which > > > being read by the controller from the flash. > > > > > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0008] > > > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, > > > bwidth:1] > > > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > > nbytes:1] > > > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] > > > > > aadr[val:4, > > > nbytes:3, bwidth:1] > > > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > > 1:24003008 2:0 3:0] > > > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > > err: > > > > > > > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0004] > > > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, > > > bwidth:1] > > > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > > nbytes:1] > > > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] > > > > > aadr[val:2, > > > nbytes:3, bwidth:1] > > > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > > 1:24003008 2:0 3:0] > > > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > > err: > > > > > > > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0002] > > > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, > > > bwidth:1] > > > > > [2.247383] m25p80_read, dummy[nbyte
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:40 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 09:05:23 + > Yogesh Narayan Gaur wrote: > > > Hi, > > > > > -Original Message- > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > > Sent: Tuesday, October 23, 2018 2:31 PM > > > To: Yogesh Narayan Gaur > > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > > ; rich...@nod.at; Mark Brown > > > ; linux-kernel@vger.kernel.org; > > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; > > > Cyrille Pitchen ; > > > computersforpe...@gmail.com; dw...@infradead.org; > > > linux-arm-ker...@lists.infradead.org > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform > > > SFDP SPI NOR flash memories > > > > > > On Tue, 23 Oct 2018 10:48:27 +0200 > > > Boris Brezillon wrote: > > > > > > > On Tue, 23 Oct 2018 08:18:35 + Yogesh Narayan Gaur > > > > wrote: > > > > > > > > > > > > > > I have added the prints in m25p80_read() and in flexspi > > > > > controller prepare_lut > > > and read_rxfifo() func. > > > > > In these have added prints for data variable of struct op and > > > > > data which > > > being read by the controller from the flash. > > > > > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0008] > > > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, > > > bwidth:1] > > > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > > nbytes:1] > > > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] > > > > > aadr[val:4, > > > nbytes:3, bwidth:1] > > > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > > 1:24003008 2:0 3:0] > > > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > > err: > > > > > > > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0004] > > > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, > > > bwidth:1] > > > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > > nbytes:1] > > > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] > > > > > aadr[val:2, > > > nbytes:3, bwidth:1] > > > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > > 1:24003008 2:0 3:0] > > > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > > err: > > > > > > > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > > read_opcode:0065, data_mask:0002] > > > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > > dummy:0008, len:0001 > > > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, > > > bwidth:1] > > > > > [2.247383] m25p80_read, dummy[nbyte
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 09:05:23 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 2:31 PM > > To: Yogesh Narayan Gaur > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > ; rich...@nod.at; Mark Brown > > ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Tue, 23 Oct 2018 10:48:27 +0200 > > Boris Brezillon wrote: > > > > > On Tue, 23 Oct 2018 08:18:35 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > > prepare_lut > > and read_rxfifo() func. > > > > In these have added prints for data variable of struct op and data > > > > which > > being read by the controller from the flash. > > > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > > > > nbytes:3, > > bwidth:1] > > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > > > > > nbytes:3, bwidth:1] > > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, > > > > nbytes:3, > > bwidth:1] > > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > > > > > nbytes:3, bwidth:1] > > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > > > > nbytes:3, > > bwidth:1] > > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > > > > > nbytes:3, bwidth:1] > > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > > > [2.305
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 09:05:23 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 2:31 PM > > To: Yogesh Narayan Gaur > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > ; rich...@nod.at; Mark Brown > > ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Tue, 23 Oct 2018 10:48:27 +0200 > > Boris Brezillon wrote: > > > > > On Tue, 23 Oct 2018 08:18:35 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > > prepare_lut > > and read_rxfifo() func. > > > > In these have added prints for data variable of struct op and data > > > > which > > being read by the controller from the flash. > > > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > > > > nbytes:3, > > bwidth:1] > > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > > > > > nbytes:3, bwidth:1] > > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, > > > > nbytes:3, > > bwidth:1] > > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > > > > > nbytes:3, bwidth:1] > > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, > > > > nbytes:3, > > bwidth:1] > > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > > > > > nbytes:3, bwidth:1] > > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > > > [2.305
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 08:59:22 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 2:18 PM > > To: Yogesh Narayan Gaur > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > ; rich...@nod.at; Mark Brown > > ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Tue, 23 Oct 2018 08:18:35 + > > Yogesh Narayan Gaur wrote: > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > prepare_lut > > and read_rxfifo() func. > > > In these have added prints for data variable of struct op and data which > > > being > > read by the controller from the flash. > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > > > > bwidth:1] > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > > > > > bwidth:1] > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > nbytes:3, bwidth:1] > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > > > > bwidth:1] > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > > [2.305444] spi_nor_parse_smpt:3065 > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > > > > and check the RL (Read Latency) and AL (Address Length) values. > > > > > > Please let me know how to rea
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 08:59:22 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Tuesday, October 23, 2018 2:18 PM > > To: Yogesh Narayan Gaur > > Cc: cristian.bir...@microchip.com; Tudor Ambarus > > ; rich...@nod.at; Mark Brown > > ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Tue, 23 Oct 2018 08:18:35 + > > Yogesh Narayan Gaur wrote: > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > prepare_lut > > and read_rxfifo() func. > > > In these have added prints for data variable of struct op and data which > > > being > > read by the controller from the flash. > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > > > > bwidth:1] > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > > > > > bwidth:1] > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > nbytes:3, bwidth:1] > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > > > > bwidth:1] > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > > [2.305444] spi_nor_parse_smpt:3065 > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > > > > and check the RL (Read Latency) and AL (Address Length) values. > > > > > > Please let me know how to rea
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:31 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 10:48:27 +0200 > Boris Brezillon wrote: > > > On Tue, 23 Oct 2018 08:18:35 + > > Yogesh Narayan Gaur wrote: > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > prepare_lut > and read_rxfifo() func. > > > In these have added prints for data variable of struct op and data which > being read by the controller from the flash. > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > err: > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > err: > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > err: > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > > > [2.305444] spi_nor_parse_smpt:3065 > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > and > > > > check the RL (Read Latency) and AL (Address Length) values. > > > > > > Please let me know how to read CR2NV register. > > > > Actually, RDAR is already what you use to read the map_id, and we need > > to use it to read the register that contains the number of dummy > > cycles and the number of address bytes to use for RDAR operations. > > Looks like we have a chicken and egg situation here :-). > > > > Let's try something els
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:31 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 10:48:27 +0200 > Boris Brezillon wrote: > > > On Tue, 23 Oct 2018 08:18:35 + > > Yogesh Narayan Gaur wrote: > > > > > > > > I have added the prints in m25p80_read() and in flexspi controller > > > prepare_lut > and read_rxfifo() func. > > > In these have added prints for data variable of struct op and data which > being read by the controller from the flash. > > > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > err: > > > > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > err: > > > > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > err: > > > > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > > > [2.305444] spi_nor_parse_smpt:3065 > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > and > > > > check the RL (Read Latency) and AL (Address Length) values. > > > > > > Please let me know how to read CR2NV register. > > > > Actually, RDAR is already what you use to read the map_id, and we need > > to use it to read the register that contains the number of dummy > > cycles and the number of address bytes to use for RDAR operations. > > Looks like we have a chicken and egg situation here :-). > > > > Let's try something els
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 10:48:27 +0200 Boris Brezillon wrote: > On Tue, 23 Oct 2018 08:18:35 + > Yogesh Narayan Gaur wrote: > > > > > I have added the prints in m25p80_read() and in flexspi controller > > prepare_lut and read_rxfifo() func. > > In these have added prints for data variable of struct op and data which > > being read by the controller from the flash. > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > bwidth:1] > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > > bwidth:1] > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > nbytes:3, bwidth:1] > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > bwidth:1] > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > [2.305444] spi_nor_parse_smpt:3065 > > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) and > > > check the RL (Read Latency) and AL (Address Length) values. > > > > Please let me know how to read CR2NV register. > > Actually, RDAR is already what you use to read the map_id, and we need > to use it to read the register that contains the number of dummy cycles > and the number of address bytes to use for RDAR operations. Looks like > we have a chicken and egg situation here :-). > > Let's try something else: > > 1/ create an u8 array of 16 entries named data_bytes > > for each loop iteration (the first for loop): > 2/ set ->addr_width to 3 and ->read_dummy to 0 > 3/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) > 4/ dump the data_bytes buf > 5/ set ->addr_width to 4 > 6/ call spi_nor_read_raw(nor, addr,
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 10:48:27 +0200 Boris Brezillon wrote: > On Tue, 23 Oct 2018 08:18:35 + > Yogesh Narayan Gaur wrote: > > > > > I have added the prints in m25p80_read() and in flexspi controller > > prepare_lut and read_rxfifo() func. > > In these have added prints for data variable of struct op and data which > > being read by the controller from the flash. > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0008] > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > bwidth:1] > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.151004] smpt_read[1] addr[0004], data_byte[] > > err: > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0004] > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > > bwidth:1] > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > > nbytes:3, bwidth:1] > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > > err: > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > > read_opcode:0065, data_mask:0002] > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > > dummy:0008, len:0001 > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > > bwidth:1] > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > > nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > > nbytes:3, bwidth:1] > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > > 1:24003008 2:0 3:0] > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > > > [2.283634] smpt_read[5] addr[0004], data_byte[] > > err: > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > > > [2.296496] End [addr_width:0003, read_dumy:0008, > > read_opcode:0065] ReturnVal: > > [2.305444] spi_nor_parse_smpt:3065 > > > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) and > > > check the RL (Read Latency) and AL (Address Length) values. > > > > Please let me know how to read CR2NV register. > > Actually, RDAR is already what you use to read the map_id, and we need > to use it to read the register that contains the number of dummy cycles > and the number of address bytes to use for RDAR operations. Looks like > we have a chicken and egg situation here :-). > > Let's try something else: > > 1/ create an u8 array of 16 entries named data_bytes > > for each loop iteration (the first for loop): > 2/ set ->addr_width to 3 and ->read_dummy to 0 > 3/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) > 4/ dump the data_bytes buf > 5/ set ->addr_width to 4 > 6/ call spi_nor_read_raw(nor, addr,
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:18 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 08:18:35 + > Yogesh Narayan Gaur wrote: > > > > > I have added the prints in m25p80_read() and in flexspi controller > > prepare_lut > and read_rxfifo() func. > > In these have added prints for data variable of struct op and data which > > being > read by the controller from the flash. > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.151004] smpt_read[1] addr[0004], data_byte[] > err: > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > err: > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.283634] smpt_read[5] addr[0004], data_byte[] > err: > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > > [2.305444] spi_nor_parse_smpt:3065 > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > > > and check the RL (Read Latency) and AL (Address Length) values. > > > > Please let me know how to read CR2NV register. > > Actually, RDAR is already what you use to read the map_id, and we need to use > it to read the register that contains the number of dummy cycles and the > number > of address bytes to use for RDAR operations. Looks like we have a chicken and > egg situation here :-). > > Let's try something else: > > 1/ create an u8 array of 16 entries named data_bytes > > for each loop iteration (the first for loop): > 2/ set ->addr_width to 3 and ->read_dummy to 0 3/ call spi_nor_read_raw(nor, > addr, ARRAY_SIZE(data_bytes), data_bytes) 4/ dump the data_bytes buf 5/ set - > >addr_width to 4 6/ call spi_nor_read_raw(nor, a
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 2:18 PM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 08:18:35 + > Yogesh Narayan Gaur wrote: > > > > > I have added the prints in m25p80_read() and in flexspi controller > > prepare_lut > and read_rxfifo() func. > > In these have added prints for data variable of struct op and data which > > being > read by the controller from the flash. > > > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.151004] smpt_read[1] addr[0004], data_byte[] > err: > > > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] > err: > > > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, > nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.283634] smpt_read[5] addr[0004], data_byte[] > err: > > > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > > [2.305444] spi_nor_parse_smpt:3065 > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) > > > and check the RL (Read Latency) and AL (Address Length) values. > > > > Please let me know how to read CR2NV register. > > Actually, RDAR is already what you use to read the map_id, and we need to use > it to read the register that contains the number of dummy cycles and the > number > of address bytes to use for RDAR operations. Looks like we have a chicken and > egg situation here :-). > > Let's try something else: > > 1/ create an u8 array of 16 entries named data_bytes > > for each loop iteration (the first for loop): > 2/ set ->addr_width to 3 and ->read_dummy to 0 3/ call spi_nor_read_raw(nor, > addr, ARRAY_SIZE(data_bytes), data_bytes) 4/ dump the data_bytes buf 5/ set - > >addr_width to 4 6/ call spi_nor_read_raw(nor, a
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 08:18:35 + Yogesh Narayan Gaur wrote: > > I have added the prints in m25p80_read() and in flexspi controller > prepare_lut and read_rxfifo() func. > In these have added prints for data variable of struct op and data which > being read by the controller from the flash. > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.151004] smpt_read[1] addr[0004], data_byte[] err: > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] err: > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.283634] smpt_read[5] addr[0004], data_byte[] err: > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > [2.305444] spi_nor_parse_smpt:3065 > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) and > > check the RL (Read Latency) and AL (Address Length) values. > > Please let me know how to read CR2NV register. Actually, RDAR is already what you use to read the map_id, and we need to use it to read the register that contains the number of dummy cycles and the number of address bytes to use for RDAR operations. Looks like we have a chicken and egg situation here :-). Let's try something else: 1/ create an u8 array of 16 entries named data_bytes for each loop iteration (the first for loop): 2/ set ->addr_width to 3 and ->read_dummy to 0 3/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) 4/ dump the data_bytes buf 5/ set ->addr_width to 4 6/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) 7/ dump the data_bytes buf If the SPI driver is working correctly, we should be able to figure out the right value for ->addr_width and ->read_dummy. Thanks, Boris
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 08:18:35 + Yogesh Narayan Gaur wrote: > > I have added the prints in m25p80_read() and in flexspi controller > prepare_lut and read_rxfifo() func. > In these have added prints for data variable of struct op and data which > being read by the controller from the flash. > > [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0008] > [2.099113] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.151004] smpt_read[1] addr[0004], data_byte[] err: > > > > [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0004] > [2.165429] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, > bwidth:1] > [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, > nbytes:3, bwidth:1] > [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] > > [2.217319] smpt_read[3] addr[0002], data_byte[0002] err: > > > > [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, > read_opcode:0065, data_mask:0002] > [2.231744] m25p80_read, nor[op:0065 addr_width:0003, > dummy:0008, len:0001 > [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, > bwidth:1] > [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] > > [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, > nbytes:3, bwidth:1] > [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] > > [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 > 1:24003008 2:0 3:0] > [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] > > [2.283634] smpt_read[5] addr[0004], data_byte[] err: > > > > [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 > > [2.296496] End [addr_width:0003, read_dumy:0008, > read_opcode:0065] ReturnVal: > [2.305444] spi_nor_parse_smpt:3065 > > [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22) > > > > > > > Next thing you can do is read the CR2NV reg (using the RDAR command) and > > check the RL (Read Latency) and AL (Address Length) values. > > Please let me know how to read CR2NV register. Actually, RDAR is already what you use to read the map_id, and we need to use it to read the register that contains the number of dummy cycles and the number of address bytes to use for RDAR operations. Looks like we have a chicken and egg situation here :-). Let's try something else: 1/ create an u8 array of 16 entries named data_bytes for each loop iteration (the first for loop): 2/ set ->addr_width to 3 and ->read_dummy to 0 3/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) 4/ dump the data_bytes buf 5/ set ->addr_width to 4 6/ call spi_nor_read_raw(nor, addr, ARRAY_SIZE(data_bytes), data_bytes) 7/ dump the data_bytes buf If the SPI driver is working correctly, we should be able to figure out the right value for ->addr_width and ->read_dummy. Thanks, Boris
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
HI, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 11:10 AM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 04:47:33 + > Yogesh Narayan Gaur wrote: > > > Hi, > > > > > -Original Message- [] > > Ok, so now the opcode and address are matching the values in the spec. > Can you check what's sent to the SPI controller side (in your > ->exec_op() implementation), just to make sure the m25p80 propagates > the information correctly? When you do that, make sure you also print the > buswidth of each element (op->cmd.buswidth, op->addr.buswidth, > op->dummy.buswidth and op->data.buswidth). > > Can you also print the read_data_mask value here. I have added the prints in m25p80_read() and in flexspi controller prepare_lut and read_rxfifo() func. In these have added prints for data variable of struct op and data which being read by the controller from the flash. [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0008] [2.099113] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] [2.151004] smpt_read[1] addr[0004], data_byte[] err: [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0004] [2.165429] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, bwidth:1] [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, bwidth:1] [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] [2.217319] smpt_read[3] addr[0002], data_byte[0002] err: [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0002] [2.231744] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] [2.283634] smpt_read[5] addr[0004], data_byte[] err: [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 [2.296496] End [addr_width:0003, read_dumy:0008, read_opcode:0065] ReturnVal: [2.305444] spi_nor_parse_smpt:3065 [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22)
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
HI, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, October 23, 2018 11:10 AM > To: Yogesh Narayan Gaur > Cc: cristian.bir...@microchip.com; Tudor Ambarus > ; rich...@nod.at; Mark Brown > ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Tue, 23 Oct 2018 04:47:33 + > Yogesh Narayan Gaur wrote: > > > Hi, > > > > > -Original Message- [] > > Ok, so now the opcode and address are matching the values in the spec. > Can you check what's sent to the SPI controller side (in your > ->exec_op() implementation), just to make sure the m25p80 propagates > the information correctly? When you do that, make sure you also print the > buswidth of each element (op->cmd.buswidth, op->addr.buswidth, > op->dummy.buswidth and op->data.buswidth). > > Can you also print the read_data_mask value here. I have added the prints in m25p80_read() and in flexspi controller prepare_lut and read_rxfifo() func. In these have added prints for data variable of struct op and data which being read by the controller from the flash. [2.091467] smpt[0]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0008] [2.099113] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.107367] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.114753] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.121706] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.129786] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.136132] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.144223] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] [2.151004] smpt_read[1] addr[0004], data_byte[] err: [2.157782] smpt[2]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0004] [2.165429] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.173683] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, bwidth:1] [2.181068] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.188021] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:2, nbytes:3, bwidth:1] [2.196101] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.202447] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.210539] nxp_fspi_read_rxfifo, ReadData op.buf[0x02] [2.217319] smpt_read[3] addr[0002], data_byte[0002] err: [2.224098] smpt[4]=[addr_width:0003, read_dumy:0008, read_opcode:0065, data_mask:0002] [2.231744] m25p80_read, nor[op:0065 addr_width:0003, dummy:0008, len:0001 [2.239998] m25p80_read, cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.247383] m25p80_read, dummy[nbytes:1 bwidth:1] data[bwidth:1, nbytes:1] [2.254336] nxp_fspi_prepare_lut cmd[opcode:65 bwidth:1] aadr[val:4, nbytes:3, bwidth:1] [2.262416] dummy[nbytes:1 bwidth:1] data[dir:0 bwidth:1, nbytes:1] [2.268762] nxp-fspi 20c.flexspi: CMD[65] lutval[0:8180465 1:24003008 2:0 3:0] [2.276854] nxp_fspi_read_rxfifo, ReadData op.buf[0x00] [2.283634] smpt_read[5] addr[0004], data_byte[] err: [2.290412] spi_nor_get_map_in_use:2915 map_id=0 smpt_len:16 i=:6 [2.296496] End [addr_width:0003, read_dumy:0008, read_opcode:0065] ReturnVal: [2.305444] spi_nor_parse_smpt:3065 [2.308924] m25p80 spi0.0: failed to parse SMPT (err = -22)
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 04:47:33 +
Yogesh Narayan Gaur wrote:
> Hi,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 5:22 PM
> > To: Yogesh Narayan Gaur
> > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > ; rich...@nod.at; Mark Brown
> > ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille
> > Pitchen
> > ; computersforpe...@gmail.com;
> > dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 11:46:55 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Monday, October 22, 2018 5:13 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > > > ; rich...@nod.at; Mark Brown
> > > > ; linux-kernel@vger.kernel.org;
> > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > Cyrille Pitchen ;
> > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Mon, 22 Oct 2018 11:03:09 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > > > To: Yogesh Narayan Gaur ;
> > > > > > cristian.bir...@microchip.com
> > > > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > > > Cyrille Pitchen ;
> > > > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > > > linux-arm-ker...@lists.infradead.org
> > > > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to
> > > > > > non-uniform SFDP SPI NOR flash memories
> > > > > >
> > > > > > On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > > > wrote:
> > > > > > >
> > > Patch used
> > >
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> > > spi_nor *nor, const u32 settings)
> >
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> >
> > See, you should have i += 2 here, not i++.
>
> Ok
> >
> > > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > > + if (!nor->addr_width)
> > > + nor->addr_width = 3;
> > > +
> > > + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor,
> > > + smpt[i]);
> > > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> > > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > > + nor->read_opcod
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 23 Oct 2018 04:47:33 +
Yogesh Narayan Gaur wrote:
> Hi,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 5:22 PM
> > To: Yogesh Narayan Gaur
> > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > ; rich...@nod.at; Mark Brown
> > ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille
> > Pitchen
> > ; computersforpe...@gmail.com;
> > dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 11:46:55 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Monday, October 22, 2018 5:13 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > > > ; rich...@nod.at; Mark Brown
> > > > ; linux-kernel@vger.kernel.org;
> > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > Cyrille Pitchen ;
> > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Mon, 22 Oct 2018 11:03:09 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > > > To: Yogesh Narayan Gaur ;
> > > > > > cristian.bir...@microchip.com
> > > > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > > > Cyrille Pitchen ;
> > > > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > > > linux-arm-ker...@lists.infradead.org
> > > > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to
> > > > > > non-uniform SFDP SPI NOR flash memories
> > > > > >
> > > > > > On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > > > wrote:
> > > > > > >
> > > Patch used
> > >
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> > > spi_nor *nor, const u32 settings)
> >
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> >
> > See, you should have i += 2 here, not i++.
>
> Ok
> >
> > > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > > + if (!nor->addr_width)
> > > + nor->addr_width = 3;
> > > +
> > > + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor,
> > > + smpt[i]);
> > > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> > > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > > + nor->read_opcod
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 5:22 PM
> To: Yogesh Narayan Gaur
> Cc: cristian.bir...@microchip.com; Tudor Ambarus
> ; rich...@nod.at; Mark Brown
> ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen
> ; computersforpe...@gmail.com;
> dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 11:46:55 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 5:13 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > > ; rich...@nod.at; Mark Brown
> > > ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > Cyrille Pitchen ;
> > > computersforpe...@gmail.com; dw...@infradead.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 11:03:09 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > > > Hi,
> > > >
> > > > > -Original Message-
> > > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > > To: Yogesh Narayan Gaur ;
> > > > > cristian.bir...@microchip.com
> > > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > > Cyrille Pitchen ;
> > > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > > linux-arm-ker...@lists.infradead.org
> > > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to
> > > > > non-uniform SFDP SPI NOR flash memories
> > > > >
> > > > > On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > Patch used
> >
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> > spi_nor *nor, const u32 settings)
>
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
>
> See, you should have i += 2 here, not i++.
Ok
>
> > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > + if (!nor->addr_width)
> > + nor->addr_width = 3;
> > +
> > + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor,
> > + smpt[i]);
> > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > addr = smpt[i + 1];
> >
> > err = spi_nor_read_raw(nor, addr, 1, _byte);
>
> And add a trace here to print data_byte and addr.
>
Logs:
[1.625840] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631536] Start [addr_width:, read_dumy:,
read_opcode:]
[1.639013] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.644317] spi_nor_get_ma
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 5:22 PM
> To: Yogesh Narayan Gaur
> Cc: cristian.bir...@microchip.com; Tudor Ambarus
> ; rich...@nod.at; Mark Brown
> ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen
> ; computersforpe...@gmail.com;
> dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 11:46:55 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 5:13 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > > ; rich...@nod.at; Mark Brown
> > > ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > Cyrille Pitchen ;
> > > computersforpe...@gmail.com; dw...@infradead.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 11:03:09 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > > > Hi,
> > > >
> > > > > -Original Message-
> > > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > > To: Yogesh Narayan Gaur ;
> > > > > cristian.bir...@microchip.com
> > > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > > Cyrille Pitchen ;
> > > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > > linux-arm-ker...@lists.infradead.org
> > > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to
> > > > > non-uniform SFDP SPI NOR flash memories
> > > > >
> > > > > On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > Patch used
> >
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> > spi_nor *nor, const u32 settings)
>
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
>
> See, you should have i += 2 here, not i++.
Ok
>
> > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > + if (!nor->addr_width)
> > + nor->addr_width = 3;
> > +
> > + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor,
> > + smpt[i]);
> > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > addr = smpt[i + 1];
> >
> > err = spi_nor_read_raw(nor, addr, 1, _byte);
>
> And add a trace here to print data_byte and addr.
>
Logs:
[1.625840] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631536] Start [addr_width:, read_dumy:,
read_opcode:]
[1.639013] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.644317] spi_nor_get_ma
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:46:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 5:13 PM
> > To: Yogesh Narayan Gaur
> > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > ; rich...@nod.at; Mark Brown
> > ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille
> > Pitchen
> > ; computersforpe...@gmail.com;
> > dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 11:03:09 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > To: Yogesh Narayan Gaur ;
> > > > cristian.bir...@microchip.com
> > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > Cyrille Pitchen ;
> > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Mon, 22 Oct 2018 12:46:27 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > wrote:
> > > > >
> Patch used
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
See, you should have i += 2 here, not i++.
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> + if (!nor->addr_width)
> + nor->addr_width = 3;
> +
> + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
And add a trace here to print data_byte and addr.
Thanks,
Boris
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:46:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 5:13 PM
> > To: Yogesh Narayan Gaur
> > Cc: cristian.bir...@microchip.com; Tudor Ambarus
> > ; rich...@nod.at; Mark Brown
> > ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille
> > Pitchen
> > ; computersforpe...@gmail.com;
> > dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 11:03:09 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Monday, October 22, 2018 4:23 PM
> > > > To: Yogesh Narayan Gaur ;
> > > > cristian.bir...@microchip.com
> > > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > Cyrille Pitchen ;
> > > > computersforpe...@gmail.com; dw...@infradead.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Mon, 22 Oct 2018 12:46:27 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > > wrote:
> > > > >
> Patch used
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
See, you should have i += 2 here, not i++.
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> - nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> + if (!nor->addr_width)
> + nor->addr_width = 3;
> +
> + nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
And add a trace here to print data_byte and addr.
Thanks,
Boris
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 5:13 PM
> To: Yogesh Narayan Gaur
> Cc: cristian.bir...@microchip.com; Tudor Ambarus
> ; rich...@nod.at; Mark Brown
> ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen
> ; computersforpe...@gmail.com;
> dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 11:03:09 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 4:23 PM
> > > To: Yogesh Narayan Gaur ;
> > > cristian.bir...@microchip.com
> > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > Cyrille Pitchen ;
> > > computersforpe...@gmail.com; dw...@infradead.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 12:46:27 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > wrote:
> > > >
Patch used
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ pr_info("Start [addr_width:%08x, read_dumy:%08x, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
+
+ for (i = 0; iaddr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
- nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
+ if (!nor->addr_width)
+ nor->addr_width = 3;
+
+ nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor, smpt[i]);
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
+ pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
+
addr = smpt[i + 1];
err = spi_nor_read_raw(nor, addr, 1, _byte);
@@ -2894,18 +2907,37 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Configuration that is currently in use.
*/
map_id = map_id << 1 | !!(data_byte & read_data_mask);
- i = i + 2;
+ map_id_is_valid = true;
}
- /* Find the matching configuration map */
- while (SMPT_MAP_ID(smpt[i]) != map_id) {
- if (smpt[i] & SMPT_DESC_END)
- goto out;
+ if (map_id_is_valid)
+ pr_info("%s:%i map_id=%d smpt_len:%d i=:%d\n", __func__,
__LINE__, map_id, smpt_len, i);
+ else
+ pr_info("%s:%i NO map_id\n", __func__, __LINE__);
+
+ for (nmaps = 0; i< smpt_len; nmaps++) {
+ if(!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ i += 2;
+ continue;
+ }
+
+ if(!map_id_is_valid) {
+ if (nmaps) {
+ ret = NULL;
+ break;
+ }
+
+ ret = smpt+i;
+ } else if (map_id == SMPT_MAP_ID(smpt[i])) {
+ ret = smpt+i;
+ break;
+ }
+
/* increment the table index to the next map */
i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
}
- ret = smpt + i;
+ pr_info("End [addr_width:%08x, read_dumy:%08x, read_opcode:%08x]\n"
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 5:13 PM
> To: Yogesh Narayan Gaur
> Cc: cristian.bir...@microchip.com; Tudor Ambarus
> ; rich...@nod.at; Mark Brown
> ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen
> ; computersforpe...@gmail.com;
> dw...@infradead.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 11:03:09 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 4:23 PM
> > > To: Yogesh Narayan Gaur ;
> > > cristian.bir...@microchip.com
> > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > Cyrille Pitchen ;
> > > computersforpe...@gmail.com; dw...@infradead.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 12:46:27 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur
> > > > wrote:
> > > >
Patch used
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2863,26 +2863,39 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ pr_info("Start [addr_width:%08x, read_dumy:%08x, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
+
+ for (i = 0; iaddr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
- nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
+ if (!nor->addr_width)
+ nor->addr_width = 3;
+
+ nor->read_dummy = 8; //spi_nor_smpt_read_dummy(nor, smpt[i]);
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
+ pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%08x,
read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
+
addr = smpt[i + 1];
err = spi_nor_read_raw(nor, addr, 1, _byte);
@@ -2894,18 +2907,37 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Configuration that is currently in use.
*/
map_id = map_id << 1 | !!(data_byte & read_data_mask);
- i = i + 2;
+ map_id_is_valid = true;
}
- /* Find the matching configuration map */
- while (SMPT_MAP_ID(smpt[i]) != map_id) {
- if (smpt[i] & SMPT_DESC_END)
- goto out;
+ if (map_id_is_valid)
+ pr_info("%s:%i map_id=%d smpt_len:%d i=:%d\n", __func__,
__LINE__, map_id, smpt_len, i);
+ else
+ pr_info("%s:%i NO map_id\n", __func__, __LINE__);
+
+ for (nmaps = 0; i< smpt_len; nmaps++) {
+ if(!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ i += 2;
+ continue;
+ }
+
+ if(!map_id_is_valid) {
+ if (nmaps) {
+ ret = NULL;
+ break;
+ }
+
+ ret = smpt+i;
+ } else if (map_id == SMPT_MAP_ID(smpt[i])) {
+ ret = smpt+i;
+ break;
+ }
+
/* increment the table index to the next map */
i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
}
- ret = smpt + i;
+ pr_info("End [addr_width:%08x, read_dumy:%08x, read_opcode:%08x]\n"
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:03:09 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Monday, October 22, 2018 4:23 PM > > To: Yogesh Narayan Gaur ; > > cristian.bir...@microchip.com > > Cc: Tudor Ambarus ; rich...@nod.at; Mark > > Brown ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Mon, 22 Oct 2018 12:46:27 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 22 Oct 2018 10:39:48 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > > > Can you add > > > > > > if (!nor->addr_width) > > > nor->addr_width = 3; > > > > > > After the > > > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > > > line. > > > > And you should also try to force ->read_dummy to 8, because according to the > > spec, the default read_latency is 8 for this chip. With that in place, you > > should > > get an map_id of 1, 3 or 5. > > > > Below is the log output. > I have forced the read_dummy as 8 and addr_width is programmed as 3. > > [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.630875] Start [addr_width:, read_dumy:, > read_opcode:] > [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 11:03:09 + Yogesh Narayan Gaur wrote: > Hi, > > > -Original Message- > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > > Sent: Monday, October 22, 2018 4:23 PM > > To: Yogesh Narayan Gaur ; > > cristian.bir...@microchip.com > > Cc: Tudor Ambarus ; rich...@nod.at; Mark > > Brown ; linux-kernel@vger.kernel.org; > > nicolas.fe...@microchip.com; marek.va...@gmail.com; > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille > > Pitchen > > ; computersforpe...@gmail.com; > > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP > > SPI > > NOR flash memories > > > > On Mon, 22 Oct 2018 12:46:27 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 22 Oct 2018 10:39:48 + > > > Yogesh Narayan Gaur wrote: > > > > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > > > Can you add > > > > > > if (!nor->addr_width) > > > nor->addr_width = 3; > > > > > > After the > > > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > > > line. > > > > And you should also try to force ->read_dummy to 8, because according to the > > spec, the default read_latency is 8 for this chip. With that in place, you > > should > > get an map_id of 1, 3 or 5. > > > > Below is the log output. > I have forced the read_dummy as 8 and addr_width is programmed as 3. > > [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.630875] Start [addr_width:, read_dumy:, > read_opcode:] > [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Monday, October 22, 2018 4:23 PM > To: Yogesh Narayan Gaur ; > cristian.bir...@microchip.com > Cc: Tudor Ambarus ; rich...@nod.at; Mark > Brown ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Mon, 22 Oct 2018 12:46:27 +0200 > Boris Brezillon wrote: > > > On Mon, 22 Oct 2018 10:39:48 + > > Yogesh Narayan Gaur wrote: > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > Can you add > > > > if (!nor->addr_width) > > nor->addr_width = 3; > > > > After the > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > line. > > And you should also try to force ->read_dummy to 8, because according to the > spec, the default read_latency is 8 for this chip. With that in place, you > should > get an map_id of 1, 3 or 5. > Below is the log output. I have forced the read_dummy as 8 and addr_width is programmed as 3. [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 [1.630875] Start [addr_width:, read_dumy:, read_opcode:] [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 [1.680782] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 [1.686084] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 [1.691391] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe [1.696782] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 [1.702171] spi_nor_get_map_in_use:2882 smpt[12]=00
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Monday, October 22, 2018 4:23 PM > To: Yogesh Narayan Gaur ; > cristian.bir...@microchip.com > Cc: Tudor Ambarus ; rich...@nod.at; Mark > Brown ; linux-kernel@vger.kernel.org; > nicolas.fe...@microchip.com; marek.va...@gmail.com; > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; Cyrille Pitchen > ; computersforpe...@gmail.com; > dw...@infradead.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI > NOR flash memories > > On Mon, 22 Oct 2018 12:46:27 +0200 > Boris Brezillon wrote: > > > On Mon, 22 Oct 2018 10:39:48 + > > Yogesh Narayan Gaur wrote: > > > > > > > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] > > > > You still don't print read_dummy correctly: %0x8 -> %08x. > > > > Can you add > > > > if (!nor->addr_width) > > nor->addr_width = 3; > > > > After the > > > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > > > line. > > And you should also try to force ->read_dummy to 8, because according to the > spec, the default read_latency is 8 for this chip. With that in place, you > should > get an map_id of 1, 3 or 5. > Below is the log output. I have forced the read_dummy as 8 and addr_width is programmed as 3. [1.625176] m25p80 spi0.0: found s25fl512s, expected m25p80 [1.630875] Start [addr_width:, read_dumy:, read_opcode:] [1.638352] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc [1.643658] spi_nor_get_map_in_use:2882 smpt[1]=0004 [1.648963] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc [1.654266] spi_nor_get_map_in_use:2882 smpt[3]=0002 [1.659569] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd [1.664872] spi_nor_get_map_in_use:2882 smpt[5]=0004 [1.670175] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe [1.675477] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 [1.680782] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 [1.686084] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 [1.691391] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe [1.696782] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 [1.702171] spi_nor_get_map_in_use:2882 smpt[12]=00
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon wrote: > On Mon, 22 Oct 2018 10:39:48 + > Yogesh Narayan Gaur wrote: > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > You still don't print read_dummy correctly: %0x8 -> %08x. > > Can you add > > if (!nor->addr_width) > nor->addr_width = 3; > > After the > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > line. And you should also try to force ->read_dummy to 8, because according to the spec, the default read_latency is 8 for this chip. With that in place, you should get an map_id of 1, 3 or 5. > > > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > > > [1.752018] End [addr_width:, read_dumy:08, > > read_opcode:0065] > > > > Also, one more thing when we are returning from the function, we are > > over-writing the values of addr_widthm read_dummy and read_opcode. > > Is this correct? > > Yes, that's correct. > > > > > out: > > nor->addr_width = addr_width; > > nor->read_dummy = read_dummy; > > nor->read_opcode = read_opcode; > > return ret; > > } > > > >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 12:46:27 +0200 Boris Brezillon wrote: > On Mon, 22 Oct 2018 10:39:48 + > Yogesh Narayan Gaur wrote: > > > > > [1.632190] Start [addr_width:, read_dumy:08, > > read_opcode:] > > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > > read_opcode:] > > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > > read_opcode:0065] > > You still don't print read_dummy correctly: %0x8 -> %08x. > > Can you add > > if (!nor->addr_width) > nor->addr_width = 3; > > After the > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); > > line. And you should also try to force ->read_dummy to 8, because according to the spec, the default read_latency is 8 for this chip. With that in place, you should get an map_id of 1, 3 or 5. > > > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > > > [1.752018] End [addr_width:, read_dumy:08, > > read_opcode:0065] > > > > Also, one more thing when we are returning from the function, we are > > over-writing the values of addr_widthm read_dummy and read_opcode. > > Is this correct? > > Yes, that's correct. > > > > > out: > > nor->addr_width = addr_width; > > nor->read_dummy = read_dummy; > > nor->read_opcode = read_opcode; > > return ret; > > } > > > >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur wrote: > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] You still don't print read_dummy correctly: %0x8 -> %08x. Can you add if (!nor->addr_width) nor->addr_width = 3; After the nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); line. > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > [1.752018] End [addr_width:, read_dumy:08, read_opcode:0065] > > > Also, one more thing when we are returning from the function, we are > over-writing the values of addr_widthm read_dummy and read_opcode. > Is this correct? Yes, that's correct. > > out: > nor->addr_width = addr_width; > nor->read_dummy = read_dummy; > nor->read_opcode = read_opcode; > return ret; > } >
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:39:48 + Yogesh Narayan Gaur wrote: > > [1.632190] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.686874] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.692176] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.697566] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.702954] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.708343] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.713732] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.719120] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.724509] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] > [1.731650] smpt[1]=[addr_width:, read_dumy:08, > read_opcode:] > [1.738791] smpt[2]=[addr_width:, read_dumy:08, > read_opcode:0065] You still don't print read_dummy correctly: %0x8 -> %08x. Can you add if (!nor->addr_width) nor->addr_width = 3; After the nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]); line. > [1.745932] spi_nor_get_map_in_use:2911 map_id=0 smpt_len:16 i=:3 > > [1.752018] End [addr_width:, read_dumy:08, read_opcode:0065] > > > Also, one more thing when we are returning from the function, we are > over-writing the values of addr_widthm read_dummy and read_opcode. > Is this correct? Yes, that's correct. > > out: > nor->addr_width = addr_width; > nor->read_dummy = read_dummy; > nor->read_opcode = read_opcode; > return ret; > } >
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 3:57 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 10:03:55 +
> Yogesh Narayan Gaur wrote:
>
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> > * @nor: pointer to a 'struct spi_nor'
> > * @smpt: pointer to the sector map parameter table
> > */
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
>
> ^ i += 2) {
>
> > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > addr = smpt[i + 1];
> >
> > err = spi_nor_read_raw(nor, addr, 1, _byte); @@
> > -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> > * Configuration that is currently in use.
> > */
> > map_id = map_id << 1 | !!(data_byte & read_data_mask);
> > + map_id_is_valid = true;
> > i = i + 2;
>
> Drop the above line (i = i + 2).
>
[1.632190] Start [addr_width:, read_dumy:08, read_opcode:]
[1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004
[1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
[1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002
[1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
[1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004
[1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
[1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
[1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 3:57 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 10:03:55 +
> Yogesh Narayan Gaur wrote:
>
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> > * @nor: pointer to a 'struct spi_nor'
> > * @smpt: pointer to the sector map parameter table
> > */
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
>
> ^ i += 2) {
>
> > + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> > nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> > + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > addr = smpt[i + 1];
> >
> > err = spi_nor_read_raw(nor, addr, 1, _byte); @@
> > -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> > * Configuration that is currently in use.
> > */
> > map_id = map_id << 1 | !!(data_byte & read_data_mask);
> > + map_id_is_valid = true;
> > i = i + 2;
>
> Drop the above line (i = i + 2).
>
[1.632190] Start [addr_width:, read_dumy:08, read_opcode:]
[1.639148] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.644451] spi_nor_get_map_in_use:2882 smpt[1]=0004
[1.649755] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
[1.655057] spi_nor_get_map_in_use:2882 smpt[3]=0002
[1.660360] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
[1.665662] spi_nor_get_map_in_use:2882 smpt[5]=0004
[1.670965] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
[1.676267] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
[1.681571] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
^ i += 2) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
Drop the above line (i = i + 2).
> }
>
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; i< smpt_len; nmaps++) {
> + if((smpt[i] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+i;
> + } else if (map_id == SMPT_MAP_ID(smpt[i])) {
> + ret = smpt+i;
> + break;
> + }
> +
> /* increment the table index to the next map */
> i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> }
>
> - ret = smpt + i;
> + pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
> nor->addr_width, nor->read_dummy, nor->read_opcode);
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
^ i += 2) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
Drop the above line (i = i + 2).
> }
>
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; i< smpt_len; nmaps++) {
> + if((smpt[i] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+i;
> + } else if (map_id == SMPT_MAP_ID(smpt[i])) {
> + ret = smpt+i;
> + break;
> + }
> +
> /* increment the table index to the next map */
> i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> }
>
> - ret = smpt + i;
> + pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
> nor->addr_width, nor->read_dummy, nor->read_opcode);
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:17:58 + Yogesh Narayan Gaur wrote: > It works, Not really. > [1.628162] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.633854] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.640811] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.646117] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.651421] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.656724] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.662028] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.667331] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.672635] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.677937] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.683240] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.688542] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.693845] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.699234] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.704625] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.710014] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.715403] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.720791] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.726180] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] There's still a problem here: you should see this trace 3 times since we have 3 command descriptors. And of course, the addr_width and read_dummy are wrong. > [1.733320] spi_nor_get_map_in_use:2912 map_id=0 smpt_len:16 i=:3 > > [1.739406] End [addr_width:, read_dumy:08, read_opcode:0065] > > [1.746204] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:17:58 + Yogesh Narayan Gaur wrote: > It works, Not really. > [1.628162] m25p80 spi0.0: found s25fl512s, expected m25p80 > > [1.633854] Start [addr_width:, read_dumy:08, > read_opcode:] > [1.640811] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc > > [1.646117] spi_nor_get_map_in_use:2882 smpt[1]=0004 > > [1.651421] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc > > [1.656724] spi_nor_get_map_in_use:2882 smpt[3]=0002 > > [1.662028] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd > > [1.667331] spi_nor_get_map_in_use:2882 smpt[5]=0004 > > [1.672635] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe > > [1.677937] spi_nor_get_map_in_use:2882 smpt[7]=7ff1 > > [1.683240] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4 > > [1.688542] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4 > > [1.693845] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe > > [1.699234] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4 > > [1.704625] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4 > > [1.710014] spi_nor_get_map_in_use:2882 smpt[13]=7ff1 > > [1.715403] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff > > [1.720791] spi_nor_get_map_in_use:2882 smpt[15]=03f4 > > [1.726180] smpt[0]=[addr_width:, read_dumy:08, > read_opcode:0065] There's still a problem here: you should see this trace 3 times since we have 3 command descriptors. And of course, the addr_width and read_dummy are wrong. > [1.733320] spi_nor_get_map_in_use:2912 map_id=0 smpt_len:16 i=:3 > > [1.739406] End [addr_width:, read_dumy:08, read_opcode:0065] > > [1.746204] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
Okay, so addr_width is wrong here (I guess read_dummy is wrong too).
That's probably because we fall in the SMPT_CMD_ADDRESS_LEN_USE_CURRENT
case and nor->addr_width has not yet been initialize when we reach this
function.
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
[...]
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
^ %08x
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
Okay, so addr_width is wrong here (I guess read_dummy is wrong too).
That's probably because we fall in the SMPT_CMD_ADDRESS_LEN_USE_CURRENT
case and nor->addr_width has not yet been initialize when we reach this
function.
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
[...]
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
^ %08x
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 3:41 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 10:03:55 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 2:46 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > cristian.bir...@microchip.com; Cyrille Pitchen
> > > ; computersforpe...@gmail.com;
> > > dw...@infradead.org; linux-arm- ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 06:04:13 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > >
> > With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> > smpt_len;
> nmaps++) {".
> >
> > [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.630377] Start [addr_width:, read_dumy:08,
> read_opcode:]
> > [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> > [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> > [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> > [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> > [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> > [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> > [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> > [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> > [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> > [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> > [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> > [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> > [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> > [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> > [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> > [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> > [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> > [1.729861] spi_nor_get_map_in_use:2912 map_id=1
> >
> >
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> > * @nor: pointer to a 'struct spi_nor'
> > * @smpt: pointer to the sector map parameter table
> > */
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
> > +
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 3:41 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 10:03:55 +
> Yogesh Narayan Gaur wrote:
>
> > Hi,
> >
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, October 22, 2018 2:46 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: Tudor Ambarus ; rich...@nod.at;
> > > Mark Brown ; linux-kernel@vger.kernel.org;
> > > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > cristian.bir...@microchip.com; Cyrille Pitchen
> > > ; computersforpe...@gmail.com;
> > > dw...@infradead.org; linux-arm- ker...@lists.infradead.org
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Mon, 22 Oct 2018 06:04:13 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > >
> > With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> > smpt_len;
> nmaps++) {".
> >
> > [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.630377] Start [addr_width:, read_dumy:08,
> read_opcode:]
> > [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> > [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> > [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> > [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> > [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> > [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> > [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> > [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> > [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> > [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> > [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> > [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> > [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> > [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> > [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> > [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> > [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> > [1.729861] spi_nor_get_map_in_use:2912 map_id=1
> >
> >
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> > * @nor: pointer to a 'struct spi_nor'
> > * @smpt: pointer to the sector map parameter table
> > */
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> > + read_opcode:%08x]\n", nor->addr_width, nor->read_dummy,
> > + nor->read_opcode);
> > +
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
> > +
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 2:46 PM
> > To: Yogesh Narayan Gaur
> > Cc: Tudor Ambarus ; rich...@nod.at; Mark
> > Brown ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > cristian.bir...@microchip.com; Cyrille Pitchen ;
> > computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> > ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> >
> With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> smpt_len; nmaps++) {".
>
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
>
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 10:03:55 +
Yogesh Narayan Gaur wrote:
> Hi,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 2:46 PM
> > To: Yogesh Narayan Gaur
> > Cc: Tudor Ambarus ; rich...@nod.at; Mark
> > Brown ; linux-kernel@vger.kernel.org;
> > nicolas.fe...@microchip.com; marek.va...@gmail.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > cristian.bir...@microchip.com; Cyrille Pitchen ;
> > computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> > ker...@lists.infradead.org
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> >
> With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
> smpt_len; nmaps++) {".
>
> [1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
> [1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
> [1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
> [1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
> [1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
> [1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
> [1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
> [1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
> [1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
> [1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
> [1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
> [1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
> [1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
> [1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
> [1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
> [1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
> [1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
> [1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
> [1.722720] smpt[0]=[addr_width:, read_dumy:08,
> read_opcode:0065]
> [1.729861] spi_nor_get_map_in_use:2912 map_id=1
>
>
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct
> spi_nor *nor, const u32 settings)
> * @nor: pointer to a 'struct spi_nor'
> * @smpt: pointer to the sector map parameter table
> */
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + pr_info("Start [addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if ((smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
> nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
> + pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
> read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
> +
> addr = smpt[i + 1];
>
> err = spi_nor_read_raw(nor, addr, 1, _byte);
> @@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
>
>
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 2:46 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 06:04:13 +
> Yogesh Narayan Gaur wrote:
>
>
With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
smpt_len; nmaps++) {".
[1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
[1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
[1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
[1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
[1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
[1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
[1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
[1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
[1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
[1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
[1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
[1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
[1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
[1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
[1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
[1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
[1.722720] smpt[0]=[addr_width:, read_dumy:08, read_opcode:0065]
[1.729861] spi_nor_get_map_in_use:2912 map_id=1
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ pr_info("Start [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
+
+ for (i = 0; iaddr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
+ pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
+
addr = smpt[i + 1];
err = spi_nor_read_raw(nor, addr, 1, _byte);
@@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Configuration that is currently in use.
*/
map_id = map_id << 1 | !!(data_byte & read_data_mask);
+ map_id_is_valid = true;
i = i + 2;
}
- /* Find the matching configuration map */
- while (SMPT_MAP_ID(smpt[i]) != map_id) {
- if (smpt[i] & SMPT_DESC_END)
- goto out;
+ if (map_id_is_valid)
+ pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
+ else
+ pr_info("%s:%i NO map_id\n", __func__, __LINE__);
+
+ for (nmaps = 0; i< smpt_len; nmaps++) {
+ if((smpt[i] & SMPT_DESC_TYPE_MAP))
+ continue;
+
+ if(!map_id_is_valid) {
+ if (nmaps) {
+ ret = NULL;
+ break;
+ }
+
+ ret = smpt+i;
+ } else if (map_id == SMPT_MAP_ID(smpt[i])) {
+ ret = smpt+i;
+ break;
+ }
+
/* increment the table index to the next map */
i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
}
- ret = smpt + i;
+ pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
/* fall through */
out:
nor->addr_width = addr_width;
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 2:46 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; rich...@nod.at; Mark
> Brown ; linux-kernel@vger.kernel.org;
> nicolas.fe...@microchip.com; marek.va...@gmail.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> cristian.bir...@microchip.com; Cyrille Pitchen ;
> computersforpe...@gmail.com; dw...@infradead.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 06:04:13 +
> Yogesh Narayan Gaur wrote:
>
>
With below patch, it gets stuck in for loop of "+ for (nmaps = 0; i<
smpt_len; nmaps++) {".
[1.624684] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.630377] Start [addr_width:, read_dumy:08, read_opcode:]
[1.637335] spi_nor_get_map_in_use:2882 smpt[0]=08ff65fc
[1.642641] spi_nor_get_map_in_use:2882 smpt[1]=0004
[1.647945] spi_nor_get_map_in_use:2882 smpt[2]=04ff65fc
[1.653248] spi_nor_get_map_in_use:2882 smpt[3]=0002
[1.658551] spi_nor_get_map_in_use:2882 smpt[4]=02ff65fd
[1.663855] spi_nor_get_map_in_use:2882 smpt[5]=0004
[1.669158] spi_nor_get_map_in_use:2882 smpt[6]=ff0201fe
[1.674461] spi_nor_get_map_in_use:2882 smpt[7]=7ff1
[1.679766] spi_nor_get_map_in_use:2882 smpt[8]=00037ff4
[1.685070] spi_nor_get_map_in_use:2882 smpt[9]=03fbfff4
[1.690375] spi_nor_get_map_in_use:2882 smpt[10]=ff0203fe
[1.695768] spi_nor_get_map_in_use:2882 smpt[11]=03fbfff4
[1.701158] spi_nor_get_map_in_use:2882 smpt[12]=00037ff4
[1.706550] spi_nor_get_map_in_use:2882 smpt[13]=7ff1
[1.711940] spi_nor_get_map_in_use:2882 smpt[14]=ff0005ff
[1.717330] spi_nor_get_map_in_use:2882 smpt[15]=03f4
[1.722720] smpt[0]=[addr_width:, read_dumy:08, read_opcode:0065]
[1.729861] spi_nor_get_map_in_use:2912 map_id=1
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2863,26 +2863,36 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ pr_info("Start [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
+
+ for (i = 0; iaddr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
+ pr_info("smpt[%d]=[addr_width:%08x, read_dumy:%0x8,
read_opcode:%08x]\n", i, nor->addr_width, nor->read_dummy, nor->read_opcode);
+
addr = smpt[i + 1];
err = spi_nor_read_raw(nor, addr, 1, _byte);
@@ -2894,18 +2904,36 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Configuration that is currently in use.
*/
map_id = map_id << 1 | !!(data_byte & read_data_mask);
+ map_id_is_valid = true;
i = i + 2;
}
- /* Find the matching configuration map */
- while (SMPT_MAP_ID(smpt[i]) != map_id) {
- if (smpt[i] & SMPT_DESC_END)
- goto out;
+ if (map_id_is_valid)
+ pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
+ else
+ pr_info("%s:%i NO map_id\n", __func__, __LINE__);
+
+ for (nmaps = 0; i< smpt_len; nmaps++) {
+ if((smpt[i] & SMPT_DESC_TYPE_MAP))
+ continue;
+
+ if(!map_id_is_valid) {
+ if (nmaps) {
+ ret = NULL;
+ break;
+ }
+
+ ret = smpt+i;
+ } else if (map_id == SMPT_MAP_ID(smpt[i])) {
+ ret = smpt+i;
+ break;
+ }
+
/* increment the table index to the next map */
i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
}
- ret = smpt + i;
+ pr_info("End [addr_width:%08x, read_dumy:%0x8, read_opcode:%08x]\n",
nor->addr_width, nor->read_dummy, nor->read_opcode);
/* fall through */
out:
nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
Why did you change this for loop?
> + if(!(smpt[nmaps] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
With your change in the for () block, this test is no longer valid...
Please keep the original patch and patch the if () condition as
suggested.
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+nmaps;
> + } else if (map_id == SMPT_MAP_ID(smpt[nmaps])) {
> + ret = smpt+nmaps;
> + break;
> + }
> +
> /* increment the table index to the next map */
> - i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> + nmaps += SMPT_MAP_REGION_COUNT(smpt[nmaps]) + 1;
> }
>
> - ret = smpt + i;
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> - /* Find the matching configuration map */
> - while (SMPT_MAP_ID(smpt[i]) != map_id) {
> - if (smpt[i] & SMPT_DESC_END)
> - goto out;
> + if (map_id_is_valid)
> + pr_info("%s:%i map_id=%d\n", __func__, __LINE__, map_id);
> + else
> + pr_info("%s:%i NO map_id\n", __func__, __LINE__);
> +
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
Why did you change this for loop?
> + if(!(smpt[nmaps] & SMPT_DESC_TYPE_MAP))
> + continue;
> +
> + if(!map_id_is_valid) {
> + if (nmaps) {
With your change in the for () block, this test is no longer valid...
Please keep the original patch and patch the if () condition as
suggested.
> + ret = NULL;
> + break;
> + }
> +
> + ret = smpt+nmaps;
> + } else if (map_id == SMPT_MAP_ID(smpt[nmaps])) {
> + ret = smpt+nmaps;
> + break;
> + }
> +
> /* increment the table index to the next map */
> - i += SMPT_MAP_REGION_COUNT(smpt[i]) + 1;
> + nmaps += SMPT_MAP_REGION_COUNT(smpt[nmaps]) + 1;
> }
>
> - ret = smpt + i;
> /* fall through */
> out:
> nor->addr_width = addr_width;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 08:32:21 +
Yogesh Narayan Gaur wrote:
> HI,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 1:32 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
> >
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> > > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > u32 *smpt)
> > > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > +u32 *smpt, u32 smpt_len)
> > > {
> > > const u32 *ret = NULL;
> > > - u32 i, addr;
> > > + u32 i, addr, nmaps;
> > > int err;
> > > u8 addr_width, read_opcode, read_dummy;
> > > u8 read_data_mask, data_byte, map_id;
> > > + bool map_id_is_valid = false;
> > >
> > > addr_width = nor->addr_width;
> > > read_dummy = nor->read_dummy;
> > > read_opcode = nor->read_opcode;
> > >
> > > + for (i = 0; i > > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > > + i, smpt[i]);
> > > +
> > > map_id = 0;
> > > - i = 0;
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> > > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > > smpt[i]);
> >
> > Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
> >
> It didn't showing any print messages here, did above line " if
> (!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
> ((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Yes.
>
> Below is the log, with the suggested change of modifying as
> > + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> > + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
>
> [1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
>
> [1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
>
> [1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
>
> [1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
>
> [1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
>
> [1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
>
> [1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
>
> [1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
>
> [1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
>
> [1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
>
> [1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
>
> [1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 08:32:21 +
Yogesh Narayan Gaur wrote:
> HI,
>
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, October 22, 2018 1:32 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
> >
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Mon, 22 Oct 2018 06:04:13 +
> > Yogesh Narayan Gaur wrote:
> >
> > > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > u32 *smpt)
> > > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > > +u32 *smpt, u32 smpt_len)
> > > {
> > > const u32 *ret = NULL;
> > > - u32 i, addr;
> > > + u32 i, addr, nmaps;
> > > int err;
> > > u8 addr_width, read_opcode, read_dummy;
> > > u8 read_data_mask, data_byte, map_id;
> > > + bool map_id_is_valid = false;
> > >
> > > addr_width = nor->addr_width;
> > > read_dummy = nor->read_dummy;
> > > read_opcode = nor->read_opcode;
> > >
> > > + for (i = 0; i > > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > > + i, smpt[i]);
> > > +
> > > map_id = 0;
> > > - i = 0;
> > > /* Determine if there are any optional Detection Command
> > > Descriptors */
> > > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > > + for (i = 0; i< smpt_len; i++) {
> > > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > > + break;
> > > +
> > > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > > smpt[i]);
> >
> > Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
> >
> It didn't showing any print messages here, did above line " if
> (!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
> ((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Yes.
>
> Below is the log, with the suggested change of modifying as
> > + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> > + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
>
> [1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
>
> [1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
>
> [1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
>
> [1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
>
> [1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
>
> [1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
>
> [1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
>
> [1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
>
> [1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
>
> [1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
>
> [1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
>
> [1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
>
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
HI,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 1:32 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
>
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 06:04:13 +
> Yogesh Narayan Gaur wrote:
>
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
> > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > smpt[i]);
>
> Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
>
It didn't showing any print messages here, did above line " if
(!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Below is the log, with the suggested change of modifying as
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
[1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
[1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
[1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
[1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
[1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
[1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
[1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
[1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
[1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
[1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
[1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
[1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
[1.695495] spi_nor_get_map_in_use:2880 smpt[12]=00037ff4
[1.700886] spi_nor_get_map_in_use:2880 smpt[13]=7ff1
[1.706275] spi_nor_get_map_in_use:2880 smpt[14]=ff0005ff
[1.711664] spi_nor_get_map_in_use:2880 smpt[15]=03f4
[1.717053] spi_no
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
HI,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, October 22, 2018 1:32 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com; Mark Brown
>
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Mon, 22 Oct 2018 06:04:13 +
> Yogesh Narayan Gaur wrote:
>
> > -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > u32 *smpt)
> > +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const
> > +u32 *smpt, u32 smpt_len)
> > {
> > const u32 *ret = NULL;
> > - u32 i, addr;
> > + u32 i, addr, nmaps;
> > int err;
> > u8 addr_width, read_opcode, read_dummy;
> > u8 read_data_mask, data_byte, map_id;
> > + bool map_id_is_valid = false;
> >
> > addr_width = nor->addr_width;
> > read_dummy = nor->read_dummy;
> > read_opcode = nor->read_opcode;
> >
> > + for (i = 0; i > + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__,
> > + i, smpt[i]);
> > +
> > map_id = 0;
> > - i = 0;
> > /* Determine if there are any optional Detection Command
> > Descriptors */
> > - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> > + for (i = 0; i< smpt_len; i++) {
> > + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> > + break;
> > +
> > read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> > nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> > nor->read_dummy = spi_nor_smpt_read_dummy(nor,
> > smpt[i]);
>
> Could you also print the ->addr_width, ->read_dummy and ->read_opcode here?
>
It didn't showing any print messages here, did above line " if
(!(smpt[i] & SMPT_DESC_TYPE_MAP))" also needs to be changes to "if
((smpt[i] & SMPT_DESC_TYPE_MAP))"?
Below is the log, with the suggested change of modifying as
> + for (nmaps = 0; nmaps< smpt_len; nmaps++) {
> + if((smpt[nmaps] & SMPT_DESC_TYPE_MAP))
[1.625992] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631681] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
[1.636988] spi_nor_get_map_in_use:2880 smpt[1]=0004
[1.642292] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
[1.647596] spi_nor_get_map_in_use:2880 smpt[3]=0002
[1.652898] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
[1.658200] spi_nor_get_map_in_use:2880 smpt[5]=0004
[1.663503] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
[1.668806] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
[1.674108] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
[1.679412] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
[1.684715] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
[1.690105] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
[1.695495] spi_nor_get_map_in_use:2880 smpt[12]=00037ff4
[1.700886] spi_nor_get_map_in_use:2880 smpt[13]=7ff1
[1.706275] spi_nor_get_map_in_use:2880 smpt[14]=ff0005ff
[1.711664] spi_nor_get_map_in_use:2880 smpt[15]=03f4
[1.717053] spi_no
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
Please amend this as well. Thanks!
---
drivers/mtd/spi-nor/spi-nor.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3a9b69e9ba6d..3019708696cd 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2887,10 +2887,15 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
{
const u32 *ret = NULL;
+ u8 *dma_safe;
u32 i, addr;
int err;
u8 addr_width, read_opcode, read_dummy;
- u8 read_data_mask, data_byte, map_id;
+ u8 read_data_mask, map_id;
+
+ dma_safe = kmalloc(sizeof(*dma_safe), GFP_KERNEL | GFP_DMA);
+ if (!dma_safe)
+ return ERR_PTR(-ENOMEM);
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
@@ -2906,7 +2911,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
addr = smpt[i + 1];
- err = spi_nor_read_raw(nor, addr, 1, _byte);
+ err = spi_nor_read_raw(nor, addr, 1, dma_safe);
if (err)
goto out;
@@ -2914,7 +2919,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Build an index value that is used to select the Sector Map
* Configuration that is currently in use.
*/
- map_id = map_id << 1 | !!(data_byte & read_data_mask);
+ map_id = map_id << 1 | !!(*dma_safe & read_data_mask);
i = i + 2;
}
@@ -2929,6 +2934,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
ret = smpt + i;
/* fall through */
out:
+ kfree(dma_safe);
nor->addr_width = addr_width;
nor->read_dummy = read_dummy;
nor->read_opcode = read_opcode;
--
2.9.4
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi,
Please amend this as well. Thanks!
---
drivers/mtd/spi-nor/spi-nor.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3a9b69e9ba6d..3019708696cd 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2887,10 +2887,15 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
{
const u32 *ret = NULL;
+ u8 *dma_safe;
u32 i, addr;
int err;
u8 addr_width, read_opcode, read_dummy;
- u8 read_data_mask, data_byte, map_id;
+ u8 read_data_mask, map_id;
+
+ dma_safe = kmalloc(sizeof(*dma_safe), GFP_KERNEL | GFP_DMA);
+ if (!dma_safe)
+ return ERR_PTR(-ENOMEM);
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
@@ -2906,7 +2911,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
addr = smpt[i + 1];
- err = spi_nor_read_raw(nor, addr, 1, _byte);
+ err = spi_nor_read_raw(nor, addr, 1, dma_safe);
if (err)
goto out;
@@ -2914,7 +2919,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
* Build an index value that is used to select the Sector Map
* Configuration that is currently in use.
*/
- map_id = map_id << 1 | !!(data_byte & read_data_mask);
+ map_id = map_id << 1 | !!(*dma_safe & read_data_mask);
i = i + 2;
}
@@ -2929,6 +2934,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor
*nor, const u32 *smpt)
ret = smpt + i;
/* fall through */
out:
+ kfree(dma_safe);
nor->addr_width = addr_width;
nor->read_dummy = read_dummy;
nor->read_opcode = read_opcode;
--
2.9.4
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
Could you also print the ->addr_width, ->read_dummy and ->read_opcode
here?
> @@ -2894,18 +2900,35 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> -static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt)
> +static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32
> *smpt, u32 smpt_len)
> {
> const u32 *ret = NULL;
> - u32 i, addr;
> + u32 i, addr, nmaps;
> int err;
> u8 addr_width, read_opcode, read_dummy;
> u8 read_data_mask, data_byte, map_id;
> + bool map_id_is_valid = false;
>
> addr_width = nor->addr_width;
> read_dummy = nor->read_dummy;
> read_opcode = nor->read_opcode;
>
> + for (i = 0; i + pr_info("%s:%i smpt[%d]=%08x\n", __func__, __LINE__, i,
> smpt[i]);
> +
> map_id = 0;
> - i = 0;
> /* Determine if there are any optional Detection Command Descriptors
> */
> - while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
> + for (i = 0; i< smpt_len; i++) {
> + if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
> + break;
> +
> read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
> nor->addr_width = spi_nor_smpt_addr_width(nor, smpt[i]);
> nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
Could you also print the ->addr_width, ->read_dummy and ->read_opcode
here?
> @@ -2894,18 +2900,35 @@ static const u32 *spi_nor_get_map_in_use(struct
> spi_nor *nor, const u32 *smpt)
> * Configuration that is currently in use.
> */
> map_id = map_id << 1 | !!(data_byte & read_data_mask);
> + map_id_is_valid = true;
> i = i + 2;
> }
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> Hi Boris, Tudor,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 3:23 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 07:46:30 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Boris,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > > ; marek.va...@gmail.com;
> > > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > > > > > > >
> > > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > > For my connected flash part, jedec ID read points to
> > > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > > exact connected flash part. When I check the data sheet of
> > > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > > * 1024, 256, }
> > > > > > >
> > > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > > protocol read are wrong and on further debugging found that
> > > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > > >
> > > > > > > If I revert this patch, reads are working fine.
> > > > > >
> > > > > > Can you try with the following patch?
> > > > > >
> > > > >
> > > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > > mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > > > >
> > > >
> > > > Can you try with this patch applied?
> > > >
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> >
> > Okay, let's try this one to see why the SMPT parsing fails.
> >
>
> Please find the below info for the SMPT table read from the flash
> [1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
> [1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
> [1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
> [1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
> [1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
> [1.657606] spi_nor_get
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Mon, 22 Oct 2018 06:04:13 +
Yogesh Narayan Gaur wrote:
> Hi Boris, Tudor,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 3:23 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 07:46:30 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Boris,
> > >
> > > > -Original Message-
> > > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > > To: Yogesh Narayan Gaur
> > > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > > ; marek.va...@gmail.com;
> > > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > > SFDP SPI NOR flash memories
> > > >
> > > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > > wrote:
> > > > >
> > > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > > wrote:
> > > > > >
> > > > > > > >
> > > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > > For my connected flash part, jedec ID read points to
> > > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > > exact connected flash part. When I check the data sheet of
> > > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > > * 1024, 256, }
> > > > > > >
> > > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > > protocol read are wrong and on further debugging found that
> > > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > > >
> > > > > > > If I revert this patch, reads are working fine.
> > > > > >
> > > > > > Can you try with the following patch?
> > > > > >
> > > > >
> > > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > > mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > > > >
> > > >
> > > > Can you try with this patch applied?
> > > >
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> >
> > Okay, let's try this one to see why the SMPT parsing fails.
> >
>
> Please find the below info for the SMPT table read from the flash
> [1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
> [1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
> [1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
> [1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
> [1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
> [1.657606] spi_nor_get
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris, Tudor,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Wednesday, October 17, 2018 3:23 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Wed, 17 Oct 2018 07:46:30 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Boris,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > ; marek.va...@gmail.com;
> > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > wrote:
> > > > >
> > > > > > >
> > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > For my connected flash part, jedec ID read points to
> > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > exact connected flash part. When I check the data sheet of
> > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > * 1024, 256, }
> > > > > >
> > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > protocol read are wrong and on further debugging found that
> > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > >
> > > > > > If I revert this patch, reads are working fine.
> > > > >
> > > > > Can you try with the following patch?
> > > > >
> > > >
> > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > mode but 1-1-4 vs 1-4-4 modes.
> > Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> > read
> opcode is being sent for 1-1-4 mode.
> > > >
> > >
> > > Can you try with this patch applied?
> > >
> > With suggested patch, read for protocol 1-4-4 working correctly.
> >
> > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> >
>
> Okay, let's try this one to see why the SMPT parsing fails.
>
Please find the below info for the SMPT table read from the flash
[1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
[1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
[1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
[1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
[1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
[1.657606] spi_nor_get_map_in_use:2880 smpt[5]=0004
[1.662911] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
[1.668215] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
[1.673520] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
[1.678825] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
[1.684128] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
[1.689519] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
[1.694911] spi_nor_get_map_in_use:2880 smpt[12]=00037ff4
[1.700303] spi_nor_get_map_in_use:2880 smpt[13]=7f
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris, Tudor,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Wednesday, October 17, 2018 3:23 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Wed, 17 Oct 2018 07:46:30 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Boris,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Wednesday, October 17, 2018 1:00 PM
> > > To: Yogesh Narayan Gaur
> > > Cc: Cyrille Pitchen ; Tudor Ambarus
> > > ; marek.va...@gmail.com;
> > > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > > SFDP SPI NOR flash memories
> > >
> > > On Wed, 17 Oct 2018 09:10:45 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon
> > > > wrote:
> > > >
> > > > > On Wed, 17 Oct 2018 02:07:43 + Yogesh Narayan Gaur
> > > > > wrote:
> > > > >
> > > > > > >
> > > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > > For my connected flash part, jedec ID read points to
> > > > > > s25fl512s. I have asked my board team to confirm the name of
> > > > > > exact connected flash part. When I check the data sheet of
> > > > > > s25fs512s, it also points to the same Jedec ID information. {
> > > > > > "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > > > > * 1024, 256, }
> > > > > >
> > > > > > But as stated earlier, if I skip reading SFDP or read using
> > > > > > 1-1-1 protocol then read are always correct. For 1-4-4
> > > > > > protocol read are wrong and on further debugging found that
> > > > > > Read code of 0x6C is being send as opcode instead of 0xEC.
> > > > > >
> > > > > > If I revert this patch, reads are working fine.
> > > > >
> > > > > Can you try with the following patch?
> > > > >
> > > >
> > > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > > mode but 1-1-4 vs 1-4-4 modes.
> > Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> > read
> opcode is being sent for 1-1-4 mode.
> > > >
> > >
> > > Can you try with this patch applied?
> > >
> > With suggested patch, read for protocol 1-4-4 working correctly.
> >
> > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> >
>
> Okay, let's try this one to see why the SMPT parsing fails.
>
Please find the below info for the SMPT table read from the flash
[1.631085] spi_nor_get_map_in_use:2880 smpt[0]=08ff65fc
[1.636393] spi_nor_get_map_in_use:2880 smpt[1]=0004
[1.641696] spi_nor_get_map_in_use:2880 smpt[2]=04ff65fc
[1.646998] spi_nor_get_map_in_use:2880 smpt[3]=0002
[1.652302] spi_nor_get_map_in_use:2880 smpt[4]=02ff65fd
[1.657606] spi_nor_get_map_in_use:2880 smpt[5]=0004
[1.662911] spi_nor_get_map_in_use:2880 smpt[6]=ff0201fe
[1.668215] spi_nor_get_map_in_use:2880 smpt[7]=7ff1
[1.673520] spi_nor_get_map_in_use:2880 smpt[8]=00037ff4
[1.678825] spi_nor_get_map_in_use:2880 smpt[9]=03fbfff4
[1.684128] spi_nor_get_map_in_use:2880 smpt[10]=ff0203fe
[1.689519] spi_nor_get_map_in_use:2880 smpt[11]=03fbfff4
[1.694911] spi_nor_get_map_in_use:2880 smpt[12]=00037ff4
[1.700303] spi_nor_get_map_in_use:2880 smpt[13]=7f
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 07:46:30 +
Yogesh Narayan Gaur wrote:
> Hi Boris,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 1:00 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 09:10:45 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 09:07:24 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 02:07:43 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > >
> > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > > have asked my board team to confirm the name of exact connected
> > > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > > points to the same Jedec ID information. { "s25fl512s",
> > > > > INFO(0x010220, 0x4d00, 256
> > > > > * 1024, 256, }
> > > > >
> > > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > > wrong and on further debugging found that Read code of 0x6C is
> > > > > being send as opcode instead of 0xEC.
> > > > >
> > > > > If I revert this patch, reads are working fine.
> > > >
> > > > Can you try with the following patch?
> > > >
> > >
> > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
> > >
> >
> > Can you try with this patch applied?
> >
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
Okay, let's try this one to see why the SMPT parsing fails.
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..564882c87641 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2855,23 +2855,31 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* spi_nor_get_map_in_use() - get the configuration map in use
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
+ * @smpt_len: number of entries in the smpt array
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
+u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ for (i = 0; i < smpt_len; i++)
+ pr_info("%s:%i smpt[%d] = %08x\n", __func__, __LINE__, i,
smpt[i]);
+
map_id = 0;
- i = 0;
/* Determine if there are any optional Detection Command Descriptors */
- while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ for (i = 0; i < smpt_len; i++) {
+ if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
+ break;
+
read_da
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 07:46:30 +
Yogesh Narayan Gaur wrote:
> Hi Boris,
>
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, October 17, 2018 1:00 PM
> > To: Yogesh Narayan Gaur
> > Cc: Cyrille Pitchen ; Tudor Ambarus
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > On Wed, 17 Oct 2018 09:10:45 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 09:07:24 +0200
> > > Boris Brezillon wrote:
> > >
> > > > On Wed, 17 Oct 2018 02:07:43 +
> > > > Yogesh Narayan Gaur wrote:
> > > >
> > > > > >
> > > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > > have asked my board team to confirm the name of exact connected
> > > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > > points to the same Jedec ID information. { "s25fl512s",
> > > > > INFO(0x010220, 0x4d00, 256
> > > > > * 1024, 256, }
> > > > >
> > > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > > wrong and on further debugging found that Read code of 0x6C is
> > > > > being send as opcode instead of 0xEC.
> > > > >
> > > > > If I revert this patch, reads are working fine.
> > > >
> > > > Can you try with the following patch?
> > > >
> > >
> > > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > > mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
> > >
> >
> > Can you try with this patch applied?
> >
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
Okay, let's try this one to see why the SMPT parsing fails.
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..564882c87641 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2855,23 +2855,31 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor
*nor, const u32 settings)
* spi_nor_get_map_in_use() - get the configuration map in use
* @nor: pointer to a 'struct spi_nor'
* @smpt: pointer to the sector map parameter table
+ * @smpt_len: number of entries in the smpt array
*/
-static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt)
+static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
+u32 smpt_len)
{
const u32 *ret = NULL;
- u32 i, addr;
+ u32 i, addr, nmaps;
int err;
u8 addr_width, read_opcode, read_dummy;
u8 read_data_mask, data_byte, map_id;
+ bool map_id_is_valid = false;
addr_width = nor->addr_width;
read_dummy = nor->read_dummy;
read_opcode = nor->read_opcode;
+ for (i = 0; i < smpt_len; i++)
+ pr_info("%s:%i smpt[%d] = %08x\n", __func__, __LINE__, i,
smpt[i]);
+
map_id = 0;
- i = 0;
/* Determine if there are any optional Detection Command Descriptors */
- while (!(smpt[i] & SMPT_DESC_TYPE_MAP)) {
+ for (i = 0; i < smpt_len; i++) {
+ if (!(smpt[i] & SMPT_DESC_TYPE_MAP))
+ break;
+
read_da
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Yogesh, Tudor,
Le 17/10/2018 à 04:07, Yogesh Narayan Gaur a écrit :
> Hi Tudor,
>
>> -Original Message-
>> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
>> Sent: Tuesday, October 16, 2018 10:04 PM
>> To: Tudor Ambarus ; Yogesh Narayan Gaur
>> ; marek.va...@gmail.com;
>> dw...@infradead.org; computersforpe...@gmail.com;
>> boris.brezil...@bootlin.com; rich...@nod.at
>> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>> NOR flash memories
>>
>> Hi Tudor,
>>
>> Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
>>> Hi, Yogesh,
>>>
>>> On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
>>>> Hi Tudor,
>>>>
>>>> This patch is breaking the 1-4-4 Read protocol for the spansion flash
>> "s25fl512s".
>>>>
>>>> Without this patch read request command for Quad mode, 4-byte enable, is
>> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
>>>> But after applying this patch, read request command for Quad mode is
>> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>>>>
>>>> This flash also supports non-uniform erase.
>>>> Can you please check and provide some suggestion?
>>>
>>> I don't have this memory to test it, but I'll try to help.
>>>
>>> Does s25fl512s support non-uniform erase? I'm looking in datasheet[1]
>>> at JEDEC BFPT table, dwords 8 and 9, page 132/146 and it looks like it
>>> supports just 256KB uniform erase.
>>>
>>
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I have asked
> my board team to confirm the name of exact connected flash part.
> When I check the data sheet of s25fs512s, it also points to the same Jedec ID
> information.
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
>
At least the 6th byte of the JEDEC ID, the Cypress Family ID, is different
between S25FL512S (0x80) and S25FS512S (0x81).
Hence the INFO6() macro can be used to create separated entries in
the spi_nor_ids[] array.
Warning: the exact value of the 4th byte of the JEDEC ID for S25FL512S
memory parts is not provided by the Cypress datasheet I read. It's only
written that "The value is OPN dependent".
Maybe you can do the magic by placing a new INFO6() entry for the S25FL512S,
just before the legacy INFO() entry for S25FL512S. Indeed entries are tested
in the order they appear inside the spi_nor_ids[] array from spi_nor_read_id(),
so the INFO6() entry would be tested 1st, trying to match 6 bytes, then the
INFO() entry only trying to match 3 bytes.
Maybe it won't solve your issue but since this is not the 1st time that
someone needs to make the difference between those 2 memory parts...
Best regards,
Cyrille
> But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol
> then read are always correct.
> For 1-4-4 protocol read are wrong and on further debugging found that Read
> code of 0x6C is being send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
>
> --
> Regards
> Yogesh Gaur
>
>> s25fS512s supports both uniform and non uniform erase options but s25fL512s
>> is
>> always uniform. L is an old memory part, S is newer.
>>
>> Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't
>> tell
>> you whether or not the memory part can be non uniform.
>> If the memory can be non uniform then the sector erase map table is
>> mandatory,
>> hence when the table is missing you know that your memory part is always
>> uniform.
>>
>> Best regards,
>>
>> Cyrille
>>
>>> Thanks,
>>> ta
>>>
>>> [1]
>>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>
>> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
>> araya
>>>
>> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
>> b4c6f
>>>
>> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
>> OGlFbg
>>> XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
>>>
>>>>
>>>> --
>>>> Regards
>>>> Yogesh Gaur
>>>>
>>>>> -Original Message-
>>>>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Yogesh, Tudor,
Le 17/10/2018 à 04:07, Yogesh Narayan Gaur a écrit :
> Hi Tudor,
>
>> -Original Message-
>> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
>> Sent: Tuesday, October 16, 2018 10:04 PM
>> To: Tudor Ambarus ; Yogesh Narayan Gaur
>> ; marek.va...@gmail.com;
>> dw...@infradead.org; computersforpe...@gmail.com;
>> boris.brezil...@bootlin.com; rich...@nod.at
>> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>> NOR flash memories
>>
>> Hi Tudor,
>>
>> Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
>>> Hi, Yogesh,
>>>
>>> On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
>>>> Hi Tudor,
>>>>
>>>> This patch is breaking the 1-4-4 Read protocol for the spansion flash
>> "s25fl512s".
>>>>
>>>> Without this patch read request command for Quad mode, 4-byte enable, is
>> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
>>>> But after applying this patch, read request command for Quad mode is
>> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>>>>
>>>> This flash also supports non-uniform erase.
>>>> Can you please check and provide some suggestion?
>>>
>>> I don't have this memory to test it, but I'll try to help.
>>>
>>> Does s25fl512s support non-uniform erase? I'm looking in datasheet[1]
>>> at JEDEC BFPT table, dwords 8 and 9, page 132/146 and it looks like it
>>> supports just 256KB uniform erase.
>>>
>>
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I have asked
> my board team to confirm the name of exact connected flash part.
> When I check the data sheet of s25fs512s, it also points to the same Jedec ID
> information.
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
>
At least the 6th byte of the JEDEC ID, the Cypress Family ID, is different
between S25FL512S (0x80) and S25FS512S (0x81).
Hence the INFO6() macro can be used to create separated entries in
the spi_nor_ids[] array.
Warning: the exact value of the 4th byte of the JEDEC ID for S25FL512S
memory parts is not provided by the Cypress datasheet I read. It's only
written that "The value is OPN dependent".
Maybe you can do the magic by placing a new INFO6() entry for the S25FL512S,
just before the legacy INFO() entry for S25FL512S. Indeed entries are tested
in the order they appear inside the spi_nor_ids[] array from spi_nor_read_id(),
so the INFO6() entry would be tested 1st, trying to match 6 bytes, then the
INFO() entry only trying to match 3 bytes.
Maybe it won't solve your issue but since this is not the 1st time that
someone needs to make the difference between those 2 memory parts...
Best regards,
Cyrille
> But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol
> then read are always correct.
> For 1-4-4 protocol read are wrong and on further debugging found that Read
> code of 0x6C is being send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
>
> --
> Regards
> Yogesh Gaur
>
>> s25fS512s supports both uniform and non uniform erase options but s25fL512s
>> is
>> always uniform. L is an old memory part, S is newer.
>>
>> Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't
>> tell
>> you whether or not the memory part can be non uniform.
>> If the memory can be non uniform then the sector erase map table is
>> mandatory,
>> hence when the table is missing you know that your memory part is always
>> uniform.
>>
>> Best regards,
>>
>> Cyrille
>>
>>> Thanks,
>>> ta
>>>
>>> [1]
>>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>
>> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
>> araya
>>>
>> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
>> b4c6f
>>>
>> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
>> OGlFbg
>>> XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
>>>
>>>>
>>>> --
>>>> Regards
>>>> Yogesh Gaur
>>>>
>>>>> -Original Message-
>>>>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 08:20:19 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> > -Original Message-
> > From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> > Sent: Wednesday, October 17, 2018 1:31 PM
> > To: Yogesh Narayan Gaur ; Boris Brezillon
> >
> > Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > Hi, Yogesh,
> >
> > On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > > Hi Boris,
> > >
> > >> -Original Message-
> > >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > >> Sent: Wednesday, October 17, 2018 1:00 PM
> > >> To: Yogesh Narayan Gaur
> > >> Cc: Cyrille Pitchen ; Tudor Ambarus
> > >> ; marek.va...@gmail.com;
> > >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > >> SFDP SPI NOR flash memories
> > >>
> > >> On Wed, 17 Oct 2018 09:10:45 +0200
> > >> Boris Brezillon wrote:
> > >>
> > >>> On Wed, 17 Oct 2018 09:07:24 +0200
> > >>> Boris Brezillon wrote:
> > >>>
> > >>>> On Wed, 17 Oct 2018 02:07:43 +
> > >>>> Yogesh Narayan Gaur wrote:
> > >>>>
> > >>>>>>
> > >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> > >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> > >>>>> have asked my board team to confirm the name of exact connected
> > >>>>> flash part. When I check the data sheet of s25fs512s, it also
> > >>>>> points to the same Jedec ID information. { "s25fl512s",
> > >>>>> INFO(0x010220, 0x4d00, 256
> > >>>>> * 1024, 256, }
> > >>>>>
> > >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> > >>>>> wrong and on further debugging found that Read code of 0x6C is
> > >>>>> being send as opcode instead of 0xEC.
> > >>>>>
> > >>>>> If I revert this patch, reads are working fine.
> > >>>>
> > >>>> Can you try with the following patch?
> > >>>>
> > >>>
> > >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > >>> mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > >>>
> > >>
> > >> Can you try with this patch applied?
> > >>
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> > > Without this patch, param_headers are getting freed and restoring
> > > previous
> > erase map i.e. opcode related to 1-1-4 protocol.
> > >
> >
> > Can you add some prints in spi_nor_parse_smpt() to isolate what's failing?
> > We
> > should understand whether it's something wrong in spi_nor_parse_smpt() or
> > the
> > s25fs512s smpt table does not respect the standard.
> >
>
> It's returning failure from below point in func spi_nor_get_map_in_use()
>
> /* Find the matching configuration map */
> while (SMPT_MAP_ID(smpt[i]) != map_id) {
> if (smpt[i] & SMPT_DESC_END) {
> printk("%d %s \n", __LINE__, __func__);
> goto out;
> }
Can you dump the smpt array just before calling
spi_nor_get_map_in_use()?
> --
> Regards
> Yogesh Gaur.
>
> > Thanks,
> > ta
> >
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 08:20:19 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> > -Original Message-
> > From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> > Sent: Wednesday, October 17, 2018 1:31 PM
> > To: Yogesh Narayan Gaur ; Boris Brezillon
> >
> > Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> > ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP
> > SPI
> > NOR flash memories
> >
> > Hi, Yogesh,
> >
> > On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > > Hi Boris,
> > >
> > >> -Original Message-
> > >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > >> Sent: Wednesday, October 17, 2018 1:00 PM
> > >> To: Yogesh Narayan Gaur
> > >> Cc: Cyrille Pitchen ; Tudor Ambarus
> > >> ; marek.va...@gmail.com;
> > >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> > >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > >> SFDP SPI NOR flash memories
> > >>
> > >> On Wed, 17 Oct 2018 09:10:45 +0200
> > >> Boris Brezillon wrote:
> > >>
> > >>> On Wed, 17 Oct 2018 09:07:24 +0200
> > >>> Boris Brezillon wrote:
> > >>>
> > >>>> On Wed, 17 Oct 2018 02:07:43 +
> > >>>> Yogesh Narayan Gaur wrote:
> > >>>>
> > >>>>>>
> > >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> > >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> > >>>>> have asked my board team to confirm the name of exact connected
> > >>>>> flash part. When I check the data sheet of s25fs512s, it also
> > >>>>> points to the same Jedec ID information. { "s25fl512s",
> > >>>>> INFO(0x010220, 0x4d00, 256
> > >>>>> * 1024, 256, }
> > >>>>>
> > >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> > >>>>> wrong and on further debugging found that Read code of 0x6C is
> > >>>>> being send as opcode instead of 0xEC.
> > >>>>>
> > >>>>> If I revert this patch, reads are working fine.
> > >>>>
> > >>>> Can you try with the following patch?
> > >>>>
> > >>>
> > >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > >>> mode but 1-1-4 vs 1-4-4 modes.
> > > Yes, that's only I have stated in my first mail that instead of 1-4-4
> > > mode read
> > opcode is being sent for 1-1-4 mode.
> > >>>
> > >>
> > >> Can you try with this patch applied?
> > >>
> > > With suggested patch, read for protocol 1-4-4 working correctly.
> > >
> > > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> > >
> > > Without this patch, param_headers are getting freed and restoring
> > > previous
> > erase map i.e. opcode related to 1-1-4 protocol.
> > >
> >
> > Can you add some prints in spi_nor_parse_smpt() to isolate what's failing?
> > We
> > should understand whether it's something wrong in spi_nor_parse_smpt() or
> > the
> > s25fs512s smpt table does not respect the standard.
> >
>
> It's returning failure from below point in func spi_nor_get_map_in_use()
>
> /* Find the matching configuration map */
> while (SMPT_MAP_ID(smpt[i]) != map_id) {
> if (smpt[i] & SMPT_DESC_END) {
> printk("%d %s \n", __LINE__, __func__);
> goto out;
> }
Can you dump the smpt array just before calling
spi_nor_get_map_in_use()?
> --
> Regards
> Yogesh Gaur.
>
> > Thanks,
> > ta
> >
>
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> Sent: Wednesday, October 17, 2018 1:31 PM
> To: Yogesh Narayan Gaur ; Boris Brezillon
>
> Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi, Yogesh,
>
> On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > Hi Boris,
> >
> >> -Original Message-
> >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> >> Sent: Wednesday, October 17, 2018 1:00 PM
> >> To: Yogesh Narayan Gaur
> >> Cc: Cyrille Pitchen ; Tudor Ambarus
> >> ; marek.va...@gmail.com;
> >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> >> SFDP SPI NOR flash memories
> >>
> >> On Wed, 17 Oct 2018 09:10:45 +0200
> >> Boris Brezillon wrote:
> >>
> >>> On Wed, 17 Oct 2018 09:07:24 +0200
> >>> Boris Brezillon wrote:
> >>>
> >>>> On Wed, 17 Oct 2018 02:07:43 +
> >>>> Yogesh Narayan Gaur wrote:
> >>>>
> >>>>>>
> >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> >>>>> have asked my board team to confirm the name of exact connected
> >>>>> flash part. When I check the data sheet of s25fs512s, it also
> >>>>> points to the same Jedec ID information. { "s25fl512s",
> >>>>> INFO(0x010220, 0x4d00, 256
> >>>>> * 1024, 256, }
> >>>>>
> >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> >>>>> wrong and on further debugging found that Read code of 0x6C is
> >>>>> being send as opcode instead of 0xEC.
> >>>>>
> >>>>> If I revert this patch, reads are working fine.
> >>>>
> >>>> Can you try with the following patch?
> >>>>
> >>>
> >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> >>> mode but 1-1-4 vs 1-4-4 modes.
> > Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> > read
> opcode is being sent for 1-1-4 mode.
> >>>
> >>
> >> Can you try with this patch applied?
> >>
> > With suggested patch, read for protocol 1-4-4 working correctly.
> >
> > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> >
> > Without this patch, param_headers are getting freed and restoring previous
> erase map i.e. opcode related to 1-1-4 protocol.
> >
>
> Can you add some prints in spi_nor_parse_smpt() to isolate what's failing? We
> should understand whether it's something wrong in spi_nor_parse_smpt() or the
> s25fs512s smpt table does not respect the standard.
>
It's returning failure from below point in func spi_nor_get_map_in_use()
/* Find the matching configuration map */
while (SMPT_MAP_ID(smpt[i]) != map_id) {
if (smpt[i] & SMPT_DESC_END) {
printk("%d %s \n", __LINE__, __func__);
goto out;
}
--
Regards
Yogesh Gaur.
> Thanks,
> ta
>
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Tudor Ambarus [mailto:tudor.amba...@microchip.com]
> Sent: Wednesday, October 17, 2018 1:31 PM
> To: Yogesh Narayan Gaur ; Boris Brezillon
>
> Cc: Cyrille Pitchen ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi, Yogesh,
>
> On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> > Hi Boris,
> >
> >> -Original Message-
> >> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> >> Sent: Wednesday, October 17, 2018 1:00 PM
> >> To: Yogesh Narayan Gaur
> >> Cc: Cyrille Pitchen ; Tudor Ambarus
> >> ; marek.va...@gmail.com;
> >> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> >> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> >> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> >> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> >> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> >> SFDP SPI NOR flash memories
> >>
> >> On Wed, 17 Oct 2018 09:10:45 +0200
> >> Boris Brezillon wrote:
> >>
> >>> On Wed, 17 Oct 2018 09:07:24 +0200
> >>> Boris Brezillon wrote:
> >>>
> >>>> On Wed, 17 Oct 2018 02:07:43 +
> >>>> Yogesh Narayan Gaur wrote:
> >>>>
> >>>>>>
> >>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
> >>>>> For my connected flash part, jedec ID read points to s25fl512s. I
> >>>>> have asked my board team to confirm the name of exact connected
> >>>>> flash part. When I check the data sheet of s25fs512s, it also
> >>>>> points to the same Jedec ID information. { "s25fl512s",
> >>>>> INFO(0x010220, 0x4d00, 256
> >>>>> * 1024, 256, }
> >>>>>
> >>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> >>>>> protocol then read are always correct. For 1-4-4 protocol read are
> >>>>> wrong and on further debugging found that Read code of 0x6C is
> >>>>> being send as opcode instead of 0xEC.
> >>>>>
> >>>>> If I revert this patch, reads are working fine.
> >>>>
> >>>> Can you try with the following patch?
> >>>>
> >>>
> >>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
> >>> mode but 1-1-4 vs 1-4-4 modes.
> > Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> > read
> opcode is being sent for 1-1-4 mode.
> >>>
> >>
> >> Can you try with this patch applied?
> >>
> > With suggested patch, read for protocol 1-4-4 working correctly.
> >
> > [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
> > [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
> > [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
> > [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
> > [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
> >
> > Without this patch, param_headers are getting freed and restoring previous
> erase map i.e. opcode related to 1-1-4 protocol.
> >
>
> Can you add some prints in spi_nor_parse_smpt() to isolate what's failing? We
> should understand whether it's something wrong in spi_nor_parse_smpt() or the
> s25fs512s smpt table does not respect the standard.
>
It's returning failure from below point in func spi_nor_get_map_in_use()
/* Find the matching configuration map */
while (SMPT_MAP_ID(smpt[i]) != map_id) {
if (smpt[i] & SMPT_DESC_END) {
printk("%d %s \n", __LINE__, __func__);
goto out;
}
--
Regards
Yogesh Gaur.
> Thanks,
> ta
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Yogesh,
On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> Hi Boris,
>
>> -Original Message-
>> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
>> Sent: Wednesday, October 17, 2018 1:00 PM
>> To: Yogesh Narayan Gaur
>> Cc: Cyrille Pitchen ; Tudor Ambarus
>> ; marek.va...@gmail.com;
>> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
>> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>> NOR flash memories
>>
>> On Wed, 17 Oct 2018 09:10:45 +0200
>> Boris Brezillon wrote:
>>
>>> On Wed, 17 Oct 2018 09:07:24 +0200
>>> Boris Brezillon wrote:
>>>
>>>> On Wed, 17 Oct 2018 02:07:43 +
>>>> Yogesh Narayan Gaur wrote:
>>>>
>>>>>>
>>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
>>>>> For my connected flash part, jedec ID read points to s25fl512s. I
>>>>> have asked my board team to confirm the name of exact connected
>>>>> flash part. When I check the data sheet of s25fs512s, it also
>>>>> points to the same Jedec ID information. { "s25fl512s",
>>>>> INFO(0x010220, 0x4d00, 256
>>>>> * 1024, 256, }
>>>>>
>>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
>>>>> protocol then read are always correct. For 1-4-4 protocol read are
>>>>> wrong and on further debugging found that Read code of 0x6C is
>>>>> being send as opcode instead of 0xEC.
>>>>>
>>>>> If I revert this patch, reads are working fine.
>>>>
>>>> Can you try with the following patch?
>>>>
>>>
>>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
>>> mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
>>>
>>
>> Can you try with this patch applied?
>>
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
> Without this patch, param_headers are getting freed and restoring previous
> erase map i.e. opcode related to 1-1-4 protocol.
>
Can you add some prints in spi_nor_parse_smpt() to isolate what's failing? We
should understand whether it's something wrong in spi_nor_parse_smpt() or the
s25fs512s smpt table does not respect the standard.
Thanks,
ta
>
>> --->8---
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index
>> 9407ca5f9443..cf33d834698c 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
>> switch (SFDP_PARAM_HEADER_ID(param_header)) {
>> case SFDP_SECTOR_MAP_ID:
>> err = spi_nor_parse_smpt(nor, param_header);
>> + if (err) {
>> + dev_warn(dev,
>> +"failed to parse SMPT (err = %d)\n",
>> +err);
>> + /*
>> +* SMPT parsing is optional, let's not drop
>> +* all information we extracted so far just
>> +* because it failed.
>> +*/
>> + err = 0;
>> + }
>> break;
>>
>> default:
>
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Yogesh,
On 10/17/2018 10:46 AM, Yogesh Narayan Gaur wrote:
> Hi Boris,
>
>> -Original Message-
>> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
>> Sent: Wednesday, October 17, 2018 1:00 PM
>> To: Yogesh Narayan Gaur
>> Cc: Cyrille Pitchen ; Tudor Ambarus
>> ; marek.va...@gmail.com;
>> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
>> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>> NOR flash memories
>>
>> On Wed, 17 Oct 2018 09:10:45 +0200
>> Boris Brezillon wrote:
>>
>>> On Wed, 17 Oct 2018 09:07:24 +0200
>>> Boris Brezillon wrote:
>>>
>>>> On Wed, 17 Oct 2018 02:07:43 +
>>>> Yogesh Narayan Gaur wrote:
>>>>
>>>>>>
>>>>> Actually there is no entry of s25fs512s in current spi-nor.c file.
>>>>> For my connected flash part, jedec ID read points to s25fl512s. I
>>>>> have asked my board team to confirm the name of exact connected
>>>>> flash part. When I check the data sheet of s25fs512s, it also
>>>>> points to the same Jedec ID information. { "s25fl512s",
>>>>> INFO(0x010220, 0x4d00, 256
>>>>> * 1024, 256, }
>>>>>
>>>>> But as stated earlier, if I skip reading SFDP or read using 1-1-1
>>>>> protocol then read are always correct. For 1-4-4 protocol read are
>>>>> wrong and on further debugging found that Read code of 0x6C is
>>>>> being send as opcode instead of 0xEC.
>>>>>
>>>>> If I revert this patch, reads are working fine.
>>>>
>>>> Can you try with the following patch?
>>>>
>>>
>>> Hm, nevermind. The problem is actually not related to 4B vs non-4B
>>> mode but 1-1-4 vs 1-4-4 modes.
> Yes, that's only I have stated in my first mail that instead of 1-4-4 mode
> read opcode is being sent for 1-1-4 mode.
>>>
>>
>> Can you try with this patch applied?
>>
> With suggested patch, read for protocol 1-4-4 working correctly.
>
> [1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
>
> [1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
>
> [1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
>
> [1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
>
> [1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
>
> Without this patch, param_headers are getting freed and restoring previous
> erase map i.e. opcode related to 1-1-4 protocol.
>
Can you add some prints in spi_nor_parse_smpt() to isolate what's failing? We
should understand whether it's something wrong in spi_nor_parse_smpt() or the
s25fs512s smpt table does not respect the standard.
Thanks,
ta
>
>> --->8---
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index
>> 9407ca5f9443..cf33d834698c 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
>> switch (SFDP_PARAM_HEADER_ID(param_header)) {
>> case SFDP_SECTOR_MAP_ID:
>> err = spi_nor_parse_smpt(nor, param_header);
>> + if (err) {
>> + dev_warn(dev,
>> +"failed to parse SMPT (err = %d)\n",
>> +err);
>> + /*
>> +* SMPT parsing is optional, let's not drop
>> +* all information we extracted so far just
>> +* because it failed.
>> +*/
>> + err = 0;
>> + }
>> break;
>>
>> default:
>
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Wednesday, October 17, 2018 1:00 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Wed, 17 Oct 2018 09:10:45 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 09:07:24 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 02:07:43 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > > > >
> > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > have asked my board team to confirm the name of exact connected
> > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > points to the same Jedec ID information. { "s25fl512s",
> > > > INFO(0x010220, 0x4d00, 256
> > > > * 1024, 256, }
> > > >
> > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > wrong and on further debugging found that Read code of 0x6C is
> > > > being send as opcode instead of 0xEC.
> > > >
> > > > If I revert this patch, reads are working fine.
> > >
> > > Can you try with the following patch?
> > >
> >
> > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > mode but 1-1-4 vs 1-4-4 modes.
Yes, that's only I have stated in my first mail that instead of 1-4-4 mode read
opcode is being sent for 1-1-4 mode.
> >
>
> Can you try with this patch applied?
>
With suggested patch, read for protocol 1-4-4 working correctly.
[1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
[1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
[1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
[1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Without this patch, param_headers are getting freed and restoring previous
erase map i.e. opcode related to 1-1-4 protocol.
--
Regards
Yogesh Gaur
> --->8---
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> 9407ca5f9443..cf33d834698c 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> switch (SFDP_PARAM_HEADER_ID(param_header)) {
> case SFDP_SECTOR_MAP_ID:
> err = spi_nor_parse_smpt(nor, param_header);
> + if (err) {
> + dev_warn(dev,
> +"failed to parse SMPT (err = %d)\n",
> +err);
> + /*
> +* SMPT parsing is optional, let's not drop
> +* all information we extracted so far just
> +* because it failed.
> +*/
> + err = 0;
> + }
> break;
>
> default:
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Wednesday, October 17, 2018 1:00 PM
> To: Yogesh Narayan Gaur
> Cc: Cyrille Pitchen ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Wed, 17 Oct 2018 09:10:45 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 09:07:24 +0200
> > Boris Brezillon wrote:
> >
> > > On Wed, 17 Oct 2018 02:07:43 +
> > > Yogesh Narayan Gaur wrote:
> > >
> > > > >
> > > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > > have asked my board team to confirm the name of exact connected
> > > > flash part. When I check the data sheet of s25fs512s, it also
> > > > points to the same Jedec ID information. { "s25fl512s",
> > > > INFO(0x010220, 0x4d00, 256
> > > > * 1024, 256, }
> > > >
> > > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > > protocol then read are always correct. For 1-4-4 protocol read are
> > > > wrong and on further debugging found that Read code of 0x6C is
> > > > being send as opcode instead of 0xEC.
> > > >
> > > > If I revert this patch, reads are working fine.
> > >
> > > Can you try with the following patch?
> > >
> >
> > Hm, nevermind. The problem is actually not related to 4B vs non-4B
> > mode but 1-1-4 vs 1-4-4 modes.
Yes, that's only I have stated in my first mail that instead of 1-4-4 mode read
opcode is being sent for 1-1-4 mode.
> >
>
> Can you try with this patch applied?
>
With suggested patch, read for protocol 1-4-4 working correctly.
[1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80
[1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22)
[1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8)
[1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc)
[1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes)
Without this patch, param_headers are getting freed and restoring previous
erase map i.e. opcode related to 1-1-4 protocol.
--
Regards
Yogesh Gaur
> --->8---
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> 9407ca5f9443..cf33d834698c 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
> switch (SFDP_PARAM_HEADER_ID(param_header)) {
> case SFDP_SECTOR_MAP_ID:
> err = spi_nor_parse_smpt(nor, param_header);
> + if (err) {
> + dev_warn(dev,
> +"failed to parse SMPT (err = %d)\n",
> +err);
> + /*
> +* SMPT parsing is optional, let's not drop
> +* all information we extracted so far just
> +* because it failed.
> +*/
> + err = 0;
> + }
> break;
>
> default:
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you try with this patch applied?
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..cf33d834698c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
switch (SFDP_PARAM_HEADER_ID(param_header)) {
case SFDP_SECTOR_MAP_ID:
err = spi_nor_parse_smpt(nor, param_header);
+ if (err) {
+ dev_warn(dev,
+"failed to parse SMPT (err = %d)\n",
+err);
+ /*
+* SMPT parsing is optional, let's not drop
+* all information we extracted so far just
+* because it failed.
+*/
+ err = 0;
+ }
break;
default:
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you try with this patch applied?
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..cf33d834698c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
switch (SFDP_PARAM_HEADER_ID(param_header)) {
case SFDP_SECTOR_MAP_ID:
err = spi_nor_parse_smpt(nor, param_header);
+ if (err) {
+ dev_warn(dev,
+"failed to parse SMPT (err = %d)\n",
+err);
+ /*
+* SMPT parsing is optional, let's not drop
+* all information we extracted so far just
+* because it failed.
+*/
+ err = 0;
+ }
break;
default:
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you add traces in this loop [1] to see which features are flagged
as supported and which ones are not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2259
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:10:45 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 09:07:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 17 Oct 2018 02:07:43 +
> > Yogesh Narayan Gaur wrote:
> >
> > > >
> > > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > > For my connected flash part, jedec ID read points to s25fl512s. I
> > > have asked my board team to confirm the name of exact connected flash
> > > part. When I check the data sheet of s25fs512s, it also points to the
> > > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > > * 1024, 256, }
> > >
> > > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > > protocol then read are always correct. For 1-4-4 protocol read are
> > > wrong and on further debugging found that Read code of 0x6C is being
> > > send as opcode instead of 0xEC.
> > >
> > > If I revert this patch, reads are working fine.
> >
> > Can you try with the following patch?
> >
>
> Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
> but 1-1-4 vs 1-4-4 modes.
>
Can you add traces in this loop [1] to see which features are flagged
as supported and which ones are not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2259
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:07:24 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 02:07:43 +
> Yogesh Narayan Gaur wrote:
>
> > >
> > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > For my connected flash part, jedec ID read points to s25fl512s. I
> > have asked my board team to confirm the name of exact connected flash
> > part. When I check the data sheet of s25fs512s, it also points to the
> > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > * 1024, 256, }
> >
> > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > protocol then read are always correct. For 1-4-4 protocol read are
> > wrong and on further debugging found that Read code of 0x6C is being
> > send as opcode instead of 0xEC.
> >
> > If I revert this patch, reads are working fine.
>
> Can you try with the following patch?
>
Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
but 1-1-4 vs 1-4-4 modes.
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 09:07:24 +0200
Boris Brezillon wrote:
> On Wed, 17 Oct 2018 02:07:43 +
> Yogesh Narayan Gaur wrote:
>
> > >
> > Actually there is no entry of s25fs512s in current spi-nor.c file.
> > For my connected flash part, jedec ID read points to s25fl512s. I
> > have asked my board team to confirm the name of exact connected flash
> > part. When I check the data sheet of s25fs512s, it also points to the
> > same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> > * 1024, 256, }
> >
> > But as stated earlier, if I skip reading SFDP or read using 1-1-1
> > protocol then read are always correct. For 1-4-4 protocol read are
> > wrong and on further debugging found that Read code of 0x6C is being
> > send as opcode instead of 0xEC.
> >
> > If I revert this patch, reads are working fine.
>
> Can you try with the following patch?
>
Hm, nevermind. The problem is actually not related to 4B vs non-4B mode
but 1-1-4 vs 1-4-4 modes.
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 02:07:43 +
Yogesh Narayan Gaur wrote:
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I
> have asked my board team to confirm the name of exact connected flash
> part. When I check the data sheet of s25fs512s, it also points to the
> same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> protocol then read are always correct. For 1-4-4 protocol read are
> wrong and on further debugging found that Read code of 0x6C is being
> send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
Can you try with the following patch?
Also, can you add a trace to check whether you're reaching this point
[1] or not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2227
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..49278c1491a6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2643,6 +2643,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
+ nor->flags |= SNOR_F_4B_OPCODES;
nor->addr_width = 4;
break;
@@ -3552,7 +3554,7 @@ static int spi_nor_init(struct spi_nor *nor)
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
+ !(nor->flags & SNOR_F_4B_OPCODES)) {
/*
* If the RESET# pin isn't hooked up properly, or the system
* otherwise doesn't perform a reset command in the boot
@@ -3586,7 +3588,7 @@ void spi_nor_restore(struct spi_nor *nor)
/* restore the addressing mode */
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES) &&
+ !(nor->flags & SNOR_F_4B_OPCODES) &&
(nor->flags & SNOR_F_BROKEN_RESET))
set_4byte(nor, nor->info, 0);
}
@@ -3724,6 +3726,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_NOR_NO_FR)
params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ if (info->flags & SPI_NOR_4B_OPCODES)
+ nor->flags |= SNOR_F_4B_OPCODES;
+
/*
* Configure the SPI memory:
* - select op codes for (Fast) Read, Page Program and Sector Erase.
@@ -3742,13 +3747,16 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
} else if (mtd->size > 0x100) {
/* enable 4-byte addressing if the device exceeds 16MiB */
nor->addr_width = 4;
- if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
- info->flags & SPI_NOR_4B_OPCODES)
- spi_nor_set_4byte_opcodes(nor, info);
+ if (JEDEC_MFR(info) == SNOR_MFR_SPANSION)
+ nor->flags |= SNOR_F_4B_OPCODES;
} else {
nor->addr_width = 3;
}
+ if (info->addr_width == 4 &&
+ nor->flags & SNOR_F_4B_OPCODES)
+ spi_nor_set_4byte_opcodes(nor, info);
+
if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
dev_err(dev, "address width is too large: %u\n",
nor->addr_width);
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7f0c7303575e..4ffb165f4f85 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -236,6 +236,7 @@ enum spi_nor_option_flags {
SNOR_F_READY_XSR_RDY= BIT(4),
SNOR_F_USE_CLSR = BIT(5),
SNOR_F_BROKEN_RESET = BIT(6),
+ SNOR_F_4B_OPCODES = BIT(7)
};
/**
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Wed, 17 Oct 2018 02:07:43 +
Yogesh Narayan Gaur wrote:
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I
> have asked my board team to confirm the name of exact connected flash
> part. When I check the data sheet of s25fs512s, it also points to the
> same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256
> * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1
> protocol then read are always correct. For 1-4-4 protocol read are
> wrong and on further debugging found that Read code of 0x6C is being
> send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
Can you try with the following patch?
Also, can you add a trace to check whether you're reaching this point
[1] or not.
[1]https://elixir.bootlin.com/linux/v4.19-rc8/source/drivers/mtd/spi-nor/spi-nor.c#L2227
--->8---
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 9407ca5f9443..49278c1491a6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2643,6 +2643,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
+ nor->flags |= SNOR_F_4B_OPCODES;
nor->addr_width = 4;
break;
@@ -3552,7 +3554,7 @@ static int spi_nor_init(struct spi_nor *nor)
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
+ !(nor->flags & SNOR_F_4B_OPCODES)) {
/*
* If the RESET# pin isn't hooked up properly, or the system
* otherwise doesn't perform a reset command in the boot
@@ -3586,7 +3588,7 @@ void spi_nor_restore(struct spi_nor *nor)
/* restore the addressing mode */
if ((nor->addr_width == 4) &&
(JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
- !(nor->info->flags & SPI_NOR_4B_OPCODES) &&
+ !(nor->flags & SNOR_F_4B_OPCODES) &&
(nor->flags & SNOR_F_BROKEN_RESET))
set_4byte(nor, nor->info, 0);
}
@@ -3724,6 +3726,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_NOR_NO_FR)
params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ if (info->flags & SPI_NOR_4B_OPCODES)
+ nor->flags |= SNOR_F_4B_OPCODES;
+
/*
* Configure the SPI memory:
* - select op codes for (Fast) Read, Page Program and Sector Erase.
@@ -3742,13 +3747,16 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
} else if (mtd->size > 0x100) {
/* enable 4-byte addressing if the device exceeds 16MiB */
nor->addr_width = 4;
- if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
- info->flags & SPI_NOR_4B_OPCODES)
- spi_nor_set_4byte_opcodes(nor, info);
+ if (JEDEC_MFR(info) == SNOR_MFR_SPANSION)
+ nor->flags |= SNOR_F_4B_OPCODES;
} else {
nor->addr_width = 3;
}
+ if (info->addr_width == 4 &&
+ nor->flags & SNOR_F_4B_OPCODES)
+ spi_nor_set_4byte_opcodes(nor, info);
+
if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
dev_err(dev, "address width is too large: %u\n",
nor->addr_width);
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7f0c7303575e..4ffb165f4f85 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -236,6 +236,7 @@ enum spi_nor_option_flags {
SNOR_F_READY_XSR_RDY= BIT(4),
SNOR_F_USE_CLSR = BIT(5),
SNOR_F_BROKEN_RESET = BIT(6),
+ SNOR_F_4B_OPCODES = BIT(7)
};
/**
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Yogesh Narayan Gaur
> Sent: Wednesday, October 17, 2018 7:38 AM
> To: 'Cyrille Pitchen' ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@bootlin.com; rich...@nod.at
> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi Tudor,
>
> > -Original Message-
> > From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> > Sent: Tuesday, October 16, 2018 10:04 PM
> > To: Tudor Ambarus ; Yogesh Narayan Gaur
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com;
> > boris.brezil...@bootlin.com; rich...@nod.at
> > Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > SFDP SPI NOR flash memories
> >
> > Hi Tudor,
> >
> > Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> > > Hi, Yogesh,
> > >
> > > On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> > >> Hi Tudor,
> > >>
> > >> This patch is breaking the 1-4-4 Read protocol for the spansion
> > >> flash
> > "s25fl512s".
> > >>
> > >> Without this patch read request command for Quad mode, 4-byte
> > >> enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > >> But after applying this patch, read request command for Quad mode
> > >> is
> > coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> > >>
> > >> This flash also supports non-uniform erase.
> > >> Can you please check and provide some suggestion?
> > >
> > > I don't have this memory to test it, but I'll try to help.
> > >
> > > Does s25fl512s support non-uniform erase? I'm looking in
> > > datasheet[1] at JEDEC BFPT table, dwords 8 and 9, page 132/146 and
> > > it looks like it supports just 256KB uniform erase.
> > >
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I have asked
> my
> board team to confirm the name of exact connected flash part.
Cypress connected flash part on my target is S25FS512SAGBHV210.
--
Regards
Yogesh Gaur
> When I check the data sheet of s25fs512s, it also points to the same Jedec ID
> information.
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol
> then read
> are always correct.
> For 1-4-4 protocol read are wrong and on further debugging found that Read
> code of 0x6C is being send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
>
> --
> Regards
> Yogesh Gaur
>
> > s25fS512s supports both uniform and non uniform erase options but
> > s25fL512s is always uniform. L is an old memory part, S is newer.
> >
> > Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone
> > can't tell you whether or not the memory part can be non uniform.
> > If the memory can be non uniform then the sector erase map table is
> > mandatory, hence when the table is missing you know that your memory
> > part is always uniform.
> >
> > Best regards,
> >
> > Cyrille
> >
> > > Thanks,
> > > ta
> > >
> > > [1]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> > >
> >
> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
> > araya
> > >
> >
> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
> > b4c6f
> > >
> >
> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
> > OGlFbg
> > > XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
> > >
> > >>
> > >> --
> > >> Regards
> > >> Yogesh Gaur
> > >>
> > >>> -Original Message-
> > >>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
> > >>> Behalf Of Tudor Ambarus
> > >>> Sent: Tuesday, September 11, 2018 9:10 PM
> > >>> To
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Yogesh Narayan Gaur
> Sent: Wednesday, October 17, 2018 7:38 AM
> To: 'Cyrille Pitchen' ; Tudor Ambarus
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@bootlin.com; rich...@nod.at
> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi Tudor,
>
> > -Original Message-
> > From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> > Sent: Tuesday, October 16, 2018 10:04 PM
> > To: Tudor Ambarus ; Yogesh Narayan Gaur
> > ; marek.va...@gmail.com;
> > dw...@infradead.org; computersforpe...@gmail.com;
> > boris.brezil...@bootlin.com; rich...@nod.at
> > Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> > cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> > linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> > Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> > SFDP SPI NOR flash memories
> >
> > Hi Tudor,
> >
> > Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> > > Hi, Yogesh,
> > >
> > > On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> > >> Hi Tudor,
> > >>
> > >> This patch is breaking the 1-4-4 Read protocol for the spansion
> > >> flash
> > "s25fl512s".
> > >>
> > >> Without this patch read request command for Quad mode, 4-byte
> > >> enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > >> But after applying this patch, read request command for Quad mode
> > >> is
> > coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> > >>
> > >> This flash also supports non-uniform erase.
> > >> Can you please check and provide some suggestion?
> > >
> > > I don't have this memory to test it, but I'll try to help.
> > >
> > > Does s25fl512s support non-uniform erase? I'm looking in
> > > datasheet[1] at JEDEC BFPT table, dwords 8 and 9, page 132/146 and
> > > it looks like it supports just 256KB uniform erase.
> > >
> >
> Actually there is no entry of s25fs512s in current spi-nor.c file.
> For my connected flash part, jedec ID read points to s25fl512s. I have asked
> my
> board team to confirm the name of exact connected flash part.
Cypress connected flash part on my target is S25FS512SAGBHV210.
--
Regards
Yogesh Gaur
> When I check the data sheet of s25fs512s, it also points to the same Jedec ID
> information.
> { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
>
> But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol
> then read
> are always correct.
> For 1-4-4 protocol read are wrong and on further debugging found that Read
> code of 0x6C is being send as opcode instead of 0xEC.
>
> If I revert this patch, reads are working fine.
>
> --
> Regards
> Yogesh Gaur
>
> > s25fS512s supports both uniform and non uniform erase options but
> > s25fL512s is always uniform. L is an old memory part, S is newer.
> >
> > Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone
> > can't tell you whether or not the memory part can be non uniform.
> > If the memory can be non uniform then the sector erase map table is
> > mandatory, hence when the table is missing you know that your memory
> > part is always uniform.
> >
> > Best regards,
> >
> > Cyrille
> >
> > > Thanks,
> > > ta
> > >
> > > [1]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> > >
> >
> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
> > araya
> > >
> >
> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
> > b4c6f
> > >
> >
> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
> > OGlFbg
> > > XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
> > >
> > >>
> > >> --
> > >> Regards
> > >> Yogesh Gaur
> > >>
> > >>> -Original Message-
> > >>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
> > >>> Behalf Of Tudor Ambarus
> > >>> Sent: Tuesday, September 11, 2018 9:10 PM
> > >>> To
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> Sent: Tuesday, October 16, 2018 10:04 PM
> To: Tudor Ambarus ; Yogesh Narayan Gaur
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@bootlin.com; rich...@nod.at
> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi Tudor,
>
> Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> > Hi, Yogesh,
> >
> > On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> >> Hi Tudor,
> >>
> >> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
> >>
> >> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> >> But after applying this patch, read request command for Quad mode is
> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >>
> >> This flash also supports non-uniform erase.
> >> Can you please check and provide some suggestion?
> >
> > I don't have this memory to test it, but I'll try to help.
> >
> > Does s25fl512s support non-uniform erase? I'm looking in datasheet[1]
> > at JEDEC BFPT table, dwords 8 and 9, page 132/146 and it looks like it
> > supports just 256KB uniform erase.
> >
>
Actually there is no entry of s25fs512s in current spi-nor.c file.
For my connected flash part, jedec ID read points to s25fl512s. I have asked my
board team to confirm the name of exact connected flash part.
When I check the data sheet of s25fs512s, it also points to the same Jedec ID
information.
{ "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol then
read are always correct.
For 1-4-4 protocol read are wrong and on further debugging found that Read code
of 0x6C is being send as opcode instead of 0xEC.
If I revert this patch, reads are working fine.
--
Regards
Yogesh Gaur
> s25fS512s supports both uniform and non uniform erase options but s25fL512s is
> always uniform. L is an old memory part, S is newer.
>
> Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't
> tell
> you whether or not the memory part can be non uniform.
> If the memory can be non uniform then the sector erase map table is mandatory,
> hence when the table is missing you know that your memory part is always
> uniform.
>
> Best regards,
>
> Cyrille
>
> > Thanks,
> > ta
> >
> > [1]
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >
> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
> araya
> >
> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
> b4c6f
> >
> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
> OGlFbg
> > XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
> >
> >>
> >> --
> >> Regards
> >> Yogesh Gaur
> >>
> >>> -Original Message-
> >>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
> >>> Behalf Of Tudor Ambarus
> >>> Sent: Tuesday, September 11, 2018 9:10 PM
> >>> To: marek.va...@gmail.com; dw...@infradead.org;
> >>> computersforpe...@gmail.com; boris.brezil...@bootlin.com;
> >>> rich...@nod.at
> >>> Cc: Tudor Ambarus ; linux-
> >>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
> >>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> >>> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> >>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> >>> SFDP SPI NOR flash memories
> >>>
> >>> Based on Cyrille Pitchen's patch
> >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> >>> kml.or
> >>>
> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
> >>>
> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
> >>>
> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
> >>>
> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
> >>>
> >>> This patch is a transitional patch in introducing the support of
> >>> SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
> -Original Message-
> From: Cyrille Pitchen [mailto:cyrille.pitc...@wedev4u.fr]
> Sent: Tuesday, October 16, 2018 10:04 PM
> To: Tudor Ambarus ; Yogesh Narayan Gaur
> ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@bootlin.com; rich...@nod.at
> Cc: linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> Hi Tudor,
>
> Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> > Hi, Yogesh,
> >
> > On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> >> Hi Tudor,
> >>
> >> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
> >>
> >> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> >> But after applying this patch, read request command for Quad mode is
> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >>
> >> This flash also supports non-uniform erase.
> >> Can you please check and provide some suggestion?
> >
> > I don't have this memory to test it, but I'll try to help.
> >
> > Does s25fl512s support non-uniform erase? I'm looking in datasheet[1]
> > at JEDEC BFPT table, dwords 8 and 9, page 132/146 and it looks like it
> > supports just 256KB uniform erase.
> >
>
Actually there is no entry of s25fs512s in current spi-nor.c file.
For my connected flash part, jedec ID read points to s25fl512s. I have asked my
board team to confirm the name of exact connected flash part.
When I check the data sheet of s25fs512s, it also points to the same Jedec ID
information.
{ "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, }
But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol then
read are always correct.
For 1-4-4 protocol read are wrong and on further debugging found that Read code
of 0x6C is being send as opcode instead of 0xEC.
If I revert this patch, reads are working fine.
--
Regards
Yogesh Gaur
> s25fS512s supports both uniform and non uniform erase options but s25fL512s is
> always uniform. L is an old memory part, S is newer.
>
> Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't
> tell
> you whether or not the memory part can be non uniform.
> If the memory can be non uniform then the sector erase map table is mandatory,
> hence when the table is missing you know that your memory part is always
> uniform.
>
> Best regards,
>
> Cyrille
>
> > Thanks,
> > ta
> >
> > [1]
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >
> cypress.com%2Ffile%2F177971%2Fdownloaddata=02%7C01%7Cyogeshn
> araya
> >
> n.gaur%40nxp.com%7C76e7e1555f4a4cda378008d63385480b%7C686ea1d3bc2
> b4c6f
> >
> a92cd99c5c301635%7C0%7C0%7C636753044876199155sdata=cioC98EH
> OGlFbg
> > XPhoIIJ72K3JrNUnzA1pYhSB9jDwg%3Dreserved=0
> >
> >>
> >> --
> >> Regards
> >> Yogesh Gaur
> >>
> >>> -Original Message-
> >>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On
> >>> Behalf Of Tudor Ambarus
> >>> Sent: Tuesday, September 11, 2018 9:10 PM
> >>> To: marek.va...@gmail.com; dw...@infradead.org;
> >>> computersforpe...@gmail.com; boris.brezil...@bootlin.com;
> >>> rich...@nod.at
> >>> Cc: Tudor Ambarus ; linux-
> >>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
> >>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org;
> >>> linux-arm- ker...@lists.infradead.org; cristian.bir...@microchip.com
> >>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform
> >>> SFDP SPI NOR flash memories
> >>>
> >>> Based on Cyrille Pitchen's patch
> >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> >>> kml.or
> >>>
> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
> >>>
> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
> >>>
> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
> >>>
> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
> >>>
> >>> This patch is a transitional patch in introducing the support of
> >>> SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Tuesday, October 16, 2018 5:48 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Tue, 16 Oct 2018 14:04:11 +0200
> Boris Brezillon wrote:
>
> > On Tue, 16 Oct 2018 09:51:47 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Tudor,
> > >
> > > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
> > >
> > > Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > > But after applying this patch, read request command for Quad mode is
> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> > >
> > > This flash also supports non-uniform erase.
> > > Can you please check and provide some suggestion?
> >
> > Are you sure the regression comes from this patch? I suspect your bug
> > comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error
> > for flash size larger than 16MB").
>
> I guess you're testing with an fsl-qspi controller, right? Can you try with
> this
> patch?
I am testing nxp-flexspi controller and doing just read of small size 0x200.
Also 1-1-1 protocol i.e. spi-rx/tx-bus-width as 1 is working fine for this
flash.
Without this patch read from 1-4-4 protocol is working correctly.
--
Regards
Yogesh Gaur
>
> --->8---
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 1ff3430f82c8..c47fe70c9f98 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q) static
> int
> fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd) {
> switch (cmd) {
> - case SPINOR_OP_READ_1_1_4:
> - case SPINOR_OP_READ_1_1_4_4B:
> - return SEQID_READ;
> case SPINOR_OP_WREN:
> return SEQID_WREN;
> case SPINOR_OP_WRDI:
> @@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> return SEQID_SE;
> case SPINOR_OP_CHIP_ERASE:
> return SEQID_CHIP_ERASE;
> - case SPINOR_OP_PP:
> - return SEQID_PP;
> case SPINOR_OP_RDID:
> return SEQID_RDID;
> case SPINOR_OP_WRSR:
> @@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> case SPINOR_OP_BRWR:
> return SEQID_BRWR;
> default:
> - if (cmd == q->nor[0].erase_opcode)
> + if (cmd == q->nor[0].read_opcode)
> + return SEQID_READ;
> + else if (cmd == q->nor[0].program_opcode)
> + return SEQID_PP;
> + else if (cmd == q->nor[0].erase_opcode)
> return SEQID_SE;
> dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
> break;
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Tuesday, October 16, 2018 5:48 PM
> To: Yogesh Narayan Gaur
> Cc: Tudor Ambarus ; marek.va...@gmail.com;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> linux-kernel@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
> NOR flash memories
>
> On Tue, 16 Oct 2018 14:04:11 +0200
> Boris Brezillon wrote:
>
> > On Tue, 16 Oct 2018 09:51:47 +
> > Yogesh Narayan Gaur wrote:
> >
> > > Hi Tudor,
> > >
> > > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
> > >
> > > Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > > But after applying this patch, read request command for Quad mode is
> coming as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> > >
> > > This flash also supports non-uniform erase.
> > > Can you please check and provide some suggestion?
> >
> > Are you sure the regression comes from this patch? I suspect your bug
> > comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error
> > for flash size larger than 16MB").
>
> I guess you're testing with an fsl-qspi controller, right? Can you try with
> this
> patch?
I am testing nxp-flexspi controller and doing just read of small size 0x200.
Also 1-1-1 protocol i.e. spi-rx/tx-bus-width as 1 is working fine for this
flash.
Without this patch read from 1-4-4 protocol is working correctly.
--
Regards
Yogesh Gaur
>
> --->8---
>
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 1ff3430f82c8..c47fe70c9f98 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q) static
> int
> fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd) {
> switch (cmd) {
> - case SPINOR_OP_READ_1_1_4:
> - case SPINOR_OP_READ_1_1_4_4B:
> - return SEQID_READ;
> case SPINOR_OP_WREN:
> return SEQID_WREN;
> case SPINOR_OP_WRDI:
> @@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> return SEQID_SE;
> case SPINOR_OP_CHIP_ERASE:
> return SEQID_CHIP_ERASE;
> - case SPINOR_OP_PP:
> - return SEQID_PP;
> case SPINOR_OP_RDID:
> return SEQID_RDID;
> case SPINOR_OP_WRSR:
> @@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
> case SPINOR_OP_BRWR:
> return SEQID_BRWR;
> default:
> - if (cmd == q->nor[0].erase_opcode)
> + if (cmd == q->nor[0].read_opcode)
> + return SEQID_READ;
> + else if (cmd == q->nor[0].program_opcode)
> + return SEQID_PP;
> + else if (cmd == q->nor[0].erase_opcode)
> return SEQID_SE;
> dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
> break;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> Hi, Yogesh,
>
> On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
>> Hi Tudor,
>>
>> This patch is breaking the 1-4-4 Read protocol for the spansion flash
>> "s25fl512s".
>>
>> Without this patch read request command for Quad mode, 4-byte enable, is
>> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
>> But after applying this patch, read request command for Quad mode is coming
>> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>>
>> This flash also supports non-uniform erase.
>> Can you please check and provide some suggestion?
>
> I don't have this memory to test it, but I'll try to help.
>
> Does s25fl512s support non-uniform erase? I'm looking in datasheet[1] at JEDEC
> BFPT table, dwords 8 and 9, page 132/146 and it looks like it supports just
> 256KB uniform erase.
>
s25fS512s supports both uniform and non uniform erase options but s25fL512s is
always uniform. L is an old memory part, S is newer.
Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't tell
you whether or not the memory part can be non uniform.
If the memory can be non uniform then the sector erase map table is mandatory,
hence when the table is missing you know that your memory part is always
uniform.
Best regards,
Cyrille
> Thanks,
> ta
>
> [1] http://www.cypress.com/file/177971/download
>
>>
>> --
>> Regards
>> Yogesh Gaur
>>
>>> -Original Message-
>>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
>>> Tudor Ambarus
>>> Sent: Tuesday, September 11, 2018 9:10 PM
>>> To: marek.va...@gmail.com; dw...@infradead.org;
>>> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
>>> Cc: Tudor Ambarus ; linux-
>>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
>>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>>> NOR
>>> flash memories
>>>
>>> Based on Cyrille Pitchen's patch
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
>>> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
>>> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
>>> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
>>> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>>>
>>> This patch is a transitional patch in introducing the support of SFDP SPI
>>> memories with non-uniform erase sizes like Spansion s25fs512s.
>>> Non-uniform erase maps will be used later when initialized based on the SFDP
>>> data.
>>>
>>> Introduce the memory erase map which splits the memory array into one or
>>> many erase regions. Each erase region supports up to 4 erase types, as
>>> defined
>>> by the JEDEC JESD216B (SFDP) specification.
>>>
>>> To be backward compatible, the erase map of uniform SPI NOR flash memories
>>> is initialized so it contains only one erase region and this erase region
>>> supports
>>> only one erase command. Hence a single size is used to erase any
>>> sector/block
>>> of the memory.
>>>
>>> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
>>> flash
>>> memories is quite expensive, when possible, the erase map is tuned to come
>>> back to the uniform case.
>>>
>>> The 'erase with the best command, move forward and repeat' approach was
>>> suggested by Cristian Birsan in a brainstorm session, so:
>>>
>>> Suggested-by: Cristian Birsan
>>> Signed-off-by: Tudor Ambarus
>>> ---
>>> drivers/mtd/spi-nor/spi-nor.c | 594
>>> +++---
>>> include/linux/mtd/spi-nor.h | 107
>>> 2 files changed, 659 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index
>>> dc8757e..4687345 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -18,6 +18,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
>>> *nor,
>>> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
>>> nor->program_opcode = spi_nor_convert_3to4_program(nor-
program_opcode);
>>> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
>>> +
>>> + if (!spi_nor_has_uniform_erase(nor)) {
>>> + struct spi_nor_erase_map *map = >erase_map;
>>> + struct spi_nor_erase_type *erase;
>>> + int i;
>>> +
>>> + for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
>>> + erase = >erase_type[i];
>>> + erase->opcode =
>>> + spi_nor_convert_3to4_erase(erase->opcode);
>>> + }
>>> + }
>>> }
>>>
>>> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
>>> int spi_nor_erase_sector(struct spi_nor
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
Le 16/10/2018 à 17:14, Tudor Ambarus a écrit :
> Hi, Yogesh,
>
> On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
>> Hi Tudor,
>>
>> This patch is breaking the 1-4-4 Read protocol for the spansion flash
>> "s25fl512s".
>>
>> Without this patch read request command for Quad mode, 4-byte enable, is
>> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
>> But after applying this patch, read request command for Quad mode is coming
>> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>>
>> This flash also supports non-uniform erase.
>> Can you please check and provide some suggestion?
>
> I don't have this memory to test it, but I'll try to help.
>
> Does s25fl512s support non-uniform erase? I'm looking in datasheet[1] at JEDEC
> BFPT table, dwords 8 and 9, page 132/146 and it looks like it supports just
> 256KB uniform erase.
>
s25fS512s supports both uniform and non uniform erase options but s25fL512s is
always uniform. L is an old memory part, S is newer.
Also, the 8th and 9th WORDs of the Basic Flash Parameter Table alone can't tell
you whether or not the memory part can be non uniform.
If the memory can be non uniform then the sector erase map table is mandatory,
hence when the table is missing you know that your memory part is always
uniform.
Best regards,
Cyrille
> Thanks,
> ta
>
> [1] http://www.cypress.com/file/177971/download
>
>>
>> --
>> Regards
>> Yogesh Gaur
>>
>>> -Original Message-
>>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
>>> Tudor Ambarus
>>> Sent: Tuesday, September 11, 2018 9:10 PM
>>> To: marek.va...@gmail.com; dw...@infradead.org;
>>> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
>>> Cc: Tudor Ambarus ; linux-
>>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
>>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI
>>> NOR
>>> flash memories
>>>
>>> Based on Cyrille Pitchen's patch
>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
>>> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
>>> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
>>> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
>>> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>>>
>>> This patch is a transitional patch in introducing the support of SFDP SPI
>>> memories with non-uniform erase sizes like Spansion s25fs512s.
>>> Non-uniform erase maps will be used later when initialized based on the SFDP
>>> data.
>>>
>>> Introduce the memory erase map which splits the memory array into one or
>>> many erase regions. Each erase region supports up to 4 erase types, as
>>> defined
>>> by the JEDEC JESD216B (SFDP) specification.
>>>
>>> To be backward compatible, the erase map of uniform SPI NOR flash memories
>>> is initialized so it contains only one erase region and this erase region
>>> supports
>>> only one erase command. Hence a single size is used to erase any
>>> sector/block
>>> of the memory.
>>>
>>> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
>>> flash
>>> memories is quite expensive, when possible, the erase map is tuned to come
>>> back to the uniform case.
>>>
>>> The 'erase with the best command, move forward and repeat' approach was
>>> suggested by Cristian Birsan in a brainstorm session, so:
>>>
>>> Suggested-by: Cristian Birsan
>>> Signed-off-by: Tudor Ambarus
>>> ---
>>> drivers/mtd/spi-nor/spi-nor.c | 594
>>> +++---
>>> include/linux/mtd/spi-nor.h | 107
>>> 2 files changed, 659 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index
>>> dc8757e..4687345 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -18,6 +18,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
>>> *nor,
>>> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
>>> nor->program_opcode = spi_nor_convert_3to4_program(nor-
program_opcode);
>>> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
>>> +
>>> + if (!spi_nor_has_uniform_erase(nor)) {
>>> + struct spi_nor_erase_map *map = >erase_map;
>>> + struct spi_nor_erase_type *erase;
>>> + int i;
>>> +
>>> + for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
>>> + erase = >erase_type[i];
>>> + erase->opcode =
>>> + spi_nor_convert_3to4_erase(erase->opcode);
>>> + }
>>> + }
>>> }
>>>
>>> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
>>> int spi_nor_erase_sector(struct spi_nor
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Yogesh,
On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
I don't have this memory to test it, but I'll try to help.
Does s25fl512s support non-uniform erase? I'm looking in datasheet[1] at JEDEC
BFPT table, dwords 8 and 9, page 132/146 and it looks like it supports just
256KB uniform erase.
Thanks,
ta
[1] http://www.cypress.com/file/177971/download
>
> --
> Regards
> Yogesh Gaur
>
>> -Original Message-
>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
>> Tudor Ambarus
>> Sent: Tuesday, September 11, 2018 9:10 PM
>> To: marek.va...@gmail.com; dw...@infradead.org;
>> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
>> Cc: Tudor Ambarus ; linux-
>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR
>> flash memories
>>
>> Based on Cyrille Pitchen's patch
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
>> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
>> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
>> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
>> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>>
>> This patch is a transitional patch in introducing the support of SFDP SPI
>> memories with non-uniform erase sizes like Spansion s25fs512s.
>> Non-uniform erase maps will be used later when initialized based on the SFDP
>> data.
>>
>> Introduce the memory erase map which splits the memory array into one or
>> many erase regions. Each erase region supports up to 4 erase types, as
>> defined
>> by the JEDEC JESD216B (SFDP) specification.
>>
>> To be backward compatible, the erase map of uniform SPI NOR flash memories
>> is initialized so it contains only one erase region and this erase region
>> supports
>> only one erase command. Hence a single size is used to erase any sector/block
>> of the memory.
>>
>> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
>> flash
>> memories is quite expensive, when possible, the erase map is tuned to come
>> back to the uniform case.
>>
>> The 'erase with the best command, move forward and repeat' approach was
>> suggested by Cristian Birsan in a brainstorm session, so:
>>
>> Suggested-by: Cristian Birsan
>> Signed-off-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 594
>> +++---
>> include/linux/mtd/spi-nor.h | 107
>> 2 files changed, 659 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index
>> dc8757e..4687345 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -18,6 +18,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
>> *nor,
>> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
>> nor->program_opcode = spi_nor_convert_3to4_program(nor-
>>> program_opcode);
>> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
>> +
>> +if (!spi_nor_has_uniform_erase(nor)) {
>> +struct spi_nor_erase_map *map = >erase_map;
>> +struct spi_nor_erase_type *erase;
>> +int i;
>> +
>> +for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
>> +erase = >erase_type[i];
>> +erase->opcode =
>> +spi_nor_convert_3to4_erase(erase->opcode);
>> +}
>> +}
>> }
>>
>> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
>> int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) }
>>
>> /*
>> + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend
>> + * @erase: pointer to a structure that describes a SPI NOR erase type
>> + * @dividend: dividend value
>> + * @remainder: pointer to u32 remainder (will be updated)
>> + *
>> + * Returns two values: remainder and the new dividend */ static u64
>> +spi_nor_div_by_erase_size(const struct spi_nor_erase_type *erase,
>> + u64 dividend, u32 *remainder)
>> +{
>> +/* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
>> +*remainder = (u32)dividend & erase->size_mask;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Yogesh,
On 10/16/2018 12:51 PM, Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
I don't have this memory to test it, but I'll try to help.
Does s25fl512s support non-uniform erase? I'm looking in datasheet[1] at JEDEC
BFPT table, dwords 8 and 9, page 132/146 and it looks like it supports just
256KB uniform erase.
Thanks,
ta
[1] http://www.cypress.com/file/177971/download
>
> --
> Regards
> Yogesh Gaur
>
>> -Original Message-
>> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
>> Tudor Ambarus
>> Sent: Tuesday, September 11, 2018 9:10 PM
>> To: marek.va...@gmail.com; dw...@infradead.org;
>> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
>> Cc: Tudor Ambarus ; linux-
>> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
>> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
>> ker...@lists.infradead.org; cristian.bir...@microchip.com
>> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR
>> flash memories
>>
>> Based on Cyrille Pitchen's patch
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
>> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
>> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
>> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
>> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>>
>> This patch is a transitional patch in introducing the support of SFDP SPI
>> memories with non-uniform erase sizes like Spansion s25fs512s.
>> Non-uniform erase maps will be used later when initialized based on the SFDP
>> data.
>>
>> Introduce the memory erase map which splits the memory array into one or
>> many erase regions. Each erase region supports up to 4 erase types, as
>> defined
>> by the JEDEC JESD216B (SFDP) specification.
>>
>> To be backward compatible, the erase map of uniform SPI NOR flash memories
>> is initialized so it contains only one erase region and this erase region
>> supports
>> only one erase command. Hence a single size is used to erase any sector/block
>> of the memory.
>>
>> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
>> flash
>> memories is quite expensive, when possible, the erase map is tuned to come
>> back to the uniform case.
>>
>> The 'erase with the best command, move forward and repeat' approach was
>> suggested by Cristian Birsan in a brainstorm session, so:
>>
>> Suggested-by: Cristian Birsan
>> Signed-off-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 594
>> +++---
>> include/linux/mtd/spi-nor.h | 107
>> 2 files changed, 659 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index
>> dc8757e..4687345 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -18,6 +18,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
>> *nor,
>> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
>> nor->program_opcode = spi_nor_convert_3to4_program(nor-
>>> program_opcode);
>> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
>> +
>> +if (!spi_nor_has_uniform_erase(nor)) {
>> +struct spi_nor_erase_map *map = >erase_map;
>> +struct spi_nor_erase_type *erase;
>> +int i;
>> +
>> +for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
>> +erase = >erase_type[i];
>> +erase->opcode =
>> +spi_nor_convert_3to4_erase(erase->opcode);
>> +}
>> +}
>> }
>>
>> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
>> int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) }
>>
>> /*
>> + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend
>> + * @erase: pointer to a structure that describes a SPI NOR erase type
>> + * @dividend: dividend value
>> + * @remainder: pointer to u32 remainder (will be updated)
>> + *
>> + * Returns two values: remainder and the new dividend */ static u64
>> +spi_nor_div_by_erase_size(const struct spi_nor_erase_type *erase,
>> + u64 dividend, u32 *remainder)
>> +{
>> +/* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
>> +*remainder = (u32)dividend & erase->size_mask;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 14:04:11 +0200
Boris Brezillon wrote:
> On Tue, 16 Oct 2018 09:51:47 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Tudor,
> >
> > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> > "s25fl512s".
> >
> > Without this patch read request command for Quad mode, 4-byte enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > But after applying this patch, read request command for Quad mode is coming
> > as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >
> > This flash also supports non-uniform erase.
> > Can you please check and provide some suggestion?
>
> Are you sure the regression comes from this patch? I suspect your bug
> comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
> flash size larger than 16MB").
I guess you're testing with an fsl-qspi controller, right? Can you try
with this patch?
--->8---
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 1ff3430f82c8..c47fe70c9f98 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
- case SPINOR_OP_READ_1_1_4:
- case SPINOR_OP_READ_1_1_4_4B:
- return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
case SPINOR_OP_WRDI:
@@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
return SEQID_SE;
case SPINOR_OP_CHIP_ERASE:
return SEQID_CHIP_ERASE;
- case SPINOR_OP_PP:
- return SEQID_PP;
case SPINOR_OP_RDID:
return SEQID_RDID;
case SPINOR_OP_WRSR:
@@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
case SPINOR_OP_BRWR:
return SEQID_BRWR;
default:
- if (cmd == q->nor[0].erase_opcode)
+ if (cmd == q->nor[0].read_opcode)
+ return SEQID_READ;
+ else if (cmd == q->nor[0].program_opcode)
+ return SEQID_PP;
+ else if (cmd == q->nor[0].erase_opcode)
return SEQID_SE;
dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
break;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 14:04:11 +0200
Boris Brezillon wrote:
> On Tue, 16 Oct 2018 09:51:47 +
> Yogesh Narayan Gaur wrote:
>
> > Hi Tudor,
> >
> > This patch is breaking the 1-4-4 Read protocol for the spansion flash
> > "s25fl512s".
> >
> > Without this patch read request command for Quad mode, 4-byte enable, is
> > coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> > But after applying this patch, read request command for Quad mode is coming
> > as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
> >
> > This flash also supports non-uniform erase.
> > Can you please check and provide some suggestion?
>
> Are you sure the regression comes from this patch? I suspect your bug
> comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
> flash size larger than 16MB").
I guess you're testing with an fsl-qspi controller, right? Can you try
with this patch?
--->8---
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 1ff3430f82c8..c47fe70c9f98 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -477,9 +477,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
- case SPINOR_OP_READ_1_1_4:
- case SPINOR_OP_READ_1_1_4_4B:
- return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
case SPINOR_OP_WRDI:
@@ -490,8 +487,6 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
return SEQID_SE;
case SPINOR_OP_CHIP_ERASE:
return SEQID_CHIP_ERASE;
- case SPINOR_OP_PP:
- return SEQID_PP;
case SPINOR_OP_RDID:
return SEQID_RDID;
case SPINOR_OP_WRSR:
@@ -503,7 +498,11 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
case SPINOR_OP_BRWR:
return SEQID_BRWR;
default:
- if (cmd == q->nor[0].erase_opcode)
+ if (cmd == q->nor[0].read_opcode)
+ return SEQID_READ;
+ else if (cmd == q->nor[0].program_opcode)
+ return SEQID_PP;
+ else if (cmd == q->nor[0].erase_opcode)
return SEQID_SE;
dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
break;
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 09:51:47 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
Are you sure the regression comes from this patch? I suspect your bug
comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
flash size larger than 16MB").
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On Tue, 16 Oct 2018 09:51:47 +
Yogesh Narayan Gaur wrote:
> Hi Tudor,
>
> This patch is breaking the 1-4-4 Read protocol for the spansion flash
> "s25fl512s".
>
> Without this patch read request command for Quad mode, 4-byte enable, is
> coming as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
> But after applying this patch, read request command for Quad mode is coming
> as 0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
>
> This flash also supports non-uniform erase.
> Can you please check and provide some suggestion?
Are you sure the regression comes from this patch? I suspect your bug
comes from 41fe242979e4 ("mtd: spi-nor: fsl-quadspi: fix read error for
flash size larger than 16MB").
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
This patch is breaking the 1-4-4 Read protocol for the spansion flash
"s25fl512s".
Without this patch read request command for Quad mode, 4-byte enable, is coming
as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
But after applying this patch, read request command for Quad mode is coming as
0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
This flash also supports non-uniform erase.
Can you please check and provide some suggestion?
--
Regards
Yogesh Gaur
> -Original Message-
> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
> Tudor Ambarus
> Sent: Tuesday, September 11, 2018 9:10 PM
> To: marek.va...@gmail.com; dw...@infradead.org;
> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
> Cc: Tudor Ambarus ; linux-
> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR
> flash memories
>
> Based on Cyrille Pitchen's patch
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>
> This patch is a transitional patch in introducing the support of SFDP SPI
> memories with non-uniform erase sizes like Spansion s25fs512s.
> Non-uniform erase maps will be used later when initialized based on the SFDP
> data.
>
> Introduce the memory erase map which splits the memory array into one or
> many erase regions. Each erase region supports up to 4 erase types, as defined
> by the JEDEC JESD216B (SFDP) specification.
>
> To be backward compatible, the erase map of uniform SPI NOR flash memories
> is initialized so it contains only one erase region and this erase region
> supports
> only one erase command. Hence a single size is used to erase any sector/block
> of the memory.
>
> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
> flash
> memories is quite expensive, when possible, the erase map is tuned to come
> back to the uniform case.
>
> The 'erase with the best command, move forward and repeat' approach was
> suggested by Cristian Birsan in a brainstorm session, so:
>
> Suggested-by: Cristian Birsan
> Signed-off-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/spi-nor.c | 594
> +++---
> include/linux/mtd/spi-nor.h | 107
> 2 files changed, 659 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> dc8757e..4687345 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
> *nor,
> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
> nor->program_opcode = spi_nor_convert_3to4_program(nor-
> >program_opcode);
> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
> +
> + if (!spi_nor_has_uniform_erase(nor)) {
> + struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_erase_type *erase;
> + int i;
> +
> + for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
> + erase = >erase_type[i];
> + erase->opcode =
> + spi_nor_convert_3to4_erase(erase->opcode);
> + }
> + }
> }
>
> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
> int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) }
>
> /*
> + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend
> + * @erase: pointer to a structure that describes a SPI NOR erase type
> + * @dividend:dividend value
> + * @remainder: pointer to u32 remainder (will be updated)
> + *
> + * Returns two values: remainder and the new dividend */ static u64
> +spi_nor_div_by_erase_size(const struct spi_nor_erase_type *erase,
> + u64 dividend, u32 *remainder)
> +{
> + /* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
> + *remainder = (u32)dividend & erase->size_mask;
> + return dividend >> erase->size_shift;
> +}
> +
> +/*
> + * spi_nor_find_best_erase_type() - find the best erase type for the
> +given
> + * offset in the serial flash memory and the number of bytes to erase.
> +The
> + * region in which the address fits is expected to be provided.
> + * @map: the erase map of the SPI NOR
> + * @region: pointer to a structure that describes a SPI NOR erase region
> + * @addr:offset in the serial flash memory
> + *
RE: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi Tudor,
This patch is breaking the 1-4-4 Read protocol for the spansion flash
"s25fl512s".
Without this patch read request command for Quad mode, 4-byte enable, is coming
as 0xEC i.e. SPINOR_OP_READ_1_4_4_4B.
But after applying this patch, read request command for Quad mode is coming as
0x6C i.e. SPINOR_OP_READ_1_1_4_4B.
This flash also supports non-uniform erase.
Can you please check and provide some suggestion?
--
Regards
Yogesh Gaur
> -Original Message-
> From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
> Tudor Ambarus
> Sent: Tuesday, September 11, 2018 9:10 PM
> To: marek.va...@gmail.com; dw...@infradead.org;
> computersforpe...@gmail.com; boris.brezil...@bootlin.com; rich...@nod.at
> Cc: Tudor Ambarus ; linux-
> ker...@vger.kernel.org; nicolas.fe...@microchip.com;
> cyrille.pitc...@microchip.com; linux-...@lists.infradead.org; linux-arm-
> ker...@lists.infradead.org; cristian.bir...@microchip.com
> Subject: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR
> flash memories
>
> Based on Cyrille Pitchen's patch
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.or
> g%2Flkml%2F2017%2F3%2F22%2F935data=02%7C01%7Cyogeshnarayan.
> gaur%40nxp.com%7C3c782e52b7fd4a8b9af008d617fd5154%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636722774108718782sdata=szyc%
> 2FTumG6eYAmBd0oW3IL7v1yLh9E1SAZqL%2BCWczOA%3Dreserved=0.
>
> This patch is a transitional patch in introducing the support of SFDP SPI
> memories with non-uniform erase sizes like Spansion s25fs512s.
> Non-uniform erase maps will be used later when initialized based on the SFDP
> data.
>
> Introduce the memory erase map which splits the memory array into one or
> many erase regions. Each erase region supports up to 4 erase types, as defined
> by the JEDEC JESD216B (SFDP) specification.
>
> To be backward compatible, the erase map of uniform SPI NOR flash memories
> is initialized so it contains only one erase region and this erase region
> supports
> only one erase command. Hence a single size is used to erase any sector/block
> of the memory.
>
> Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
> flash
> memories is quite expensive, when possible, the erase map is tuned to come
> back to the uniform case.
>
> The 'erase with the best command, move forward and repeat' approach was
> suggested by Cristian Birsan in a brainstorm session, so:
>
> Suggested-by: Cristian Birsan
> Signed-off-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/spi-nor.c | 594
> +++---
> include/linux/mtd/spi-nor.h | 107
> 2 files changed, 659 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index
> dc8757e..4687345 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -261,6 +262,18 @@ static void spi_nor_set_4byte_opcodes(struct spi_nor
> *nor,
> nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
> nor->program_opcode = spi_nor_convert_3to4_program(nor-
> >program_opcode);
> nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
> +
> + if (!spi_nor_has_uniform_erase(nor)) {
> + struct spi_nor_erase_map *map = >erase_map;
> + struct spi_nor_erase_type *erase;
> + int i;
> +
> + for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++) {
> + erase = >erase_type[i];
> + erase->opcode =
> + spi_nor_convert_3to4_erase(erase->opcode);
> + }
> + }
> }
>
> /* Enable/disable 4-byte addressing mode. */ @@ -499,6 +512,275 @@ static
> int spi_nor_erase_sector(struct spi_nor *nor, u32 addr) }
>
> /*
> + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend
> + * @erase: pointer to a structure that describes a SPI NOR erase type
> + * @dividend:dividend value
> + * @remainder: pointer to u32 remainder (will be updated)
> + *
> + * Returns two values: remainder and the new dividend */ static u64
> +spi_nor_div_by_erase_size(const struct spi_nor_erase_type *erase,
> + u64 dividend, u32 *remainder)
> +{
> + /* JEDEC JESD216B Standard imposes erase sizes to be power of 2. */
> + *remainder = (u32)dividend & erase->size_mask;
> + return dividend >> erase->size_shift;
> +}
> +
> +/*
> + * spi_nor_find_best_erase_type() - find the best erase type for the
> +given
> + * offset in the serial flash memory and the number of bytes to erase.
> +The
> + * region in which the address fits is expected to be provided.
> + * @map: the erase map of the SPI NOR
> + * @region: pointer to a structure that describes a SPI NOR erase region
> + * @addr:offset in the serial flash memory
> + *
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Boris, On 09/11/2018 06:40 PM, Tudor Ambarus wrote: > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c [cut] > /* I missed to use the opening comment mark for kernel-doc comments: "/**". This observation applies to all newly introduced function descriptions, in this patch and in the next as well. > + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend > + * @erase: pointer to a structure that describes a SPI NOR erase type > + * @dividend:dividend value > + * @remainder: pointer to u32 remainder (will be updated) > + * > + * Returns two values: remainder and the new dividend I should have used "Return: describe the return value" in order to be aligned with the example from kernel-doc. This also applies to most of the function descriptions. [cut] > +/* > + *spi_nor_init_uniform_erase_map() - Initialize uniform erase map add a space after that "*" I will gladly submit a new version if there are no other comments. Please let me know. Cheers, ta
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
Hi, Boris, On 09/11/2018 06:40 PM, Tudor Ambarus wrote: > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c [cut] > /* I missed to use the opening comment mark for kernel-doc comments: "/**". This observation applies to all newly introduced function descriptions, in this patch and in the next as well. > + * spi_nor_div_by_erase_size() - calculate remainder and update new dividend > + * @erase: pointer to a structure that describes a SPI NOR erase type > + * @dividend:dividend value > + * @remainder: pointer to u32 remainder (will be updated) > + * > + * Returns two values: remainder and the new dividend I should have used "Return: describe the return value" in order to be aligned with the example from kernel-doc. This also applies to most of the function descriptions. [cut] > +/* > + *spi_nor_init_uniform_erase_map() - Initialize uniform erase map add a space after that "*" I will gladly submit a new version if there are no other comments. Please let me know. Cheers, ta
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On 09/11/2018 05:40 PM, Tudor Ambarus wrote: > Based on Cyrille Pitchen's patch https://lkml.org/lkml/2017/3/22/935. > > This patch is a transitional patch in introducing the support of > SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512s. > Non-uniform erase maps will be used later when initialized based on the > SFDP data. > > Introduce the memory erase map which splits the memory array into one > or many erase regions. Each erase region supports up to 4 erase types, > as defined by the JEDEC JESD216B (SFDP) specification. > > To be backward compatible, the erase map of uniform SPI NOR flash memories > is initialized so it contains only one erase region and this erase region > supports only one erase command. Hence a single size is used to erase any > sector/block of the memory. > > Besides, since the algorithm used to erase sectors on non-uniform SPI NOR > flash memories is quite expensive, when possible, the erase map is tuned > to come back to the uniform case. > > The 'erase with the best command, move forward and repeat' approach was > suggested by Cristian Birsan in a brainstorm session, so: > > Suggested-by: Cristian Birsan > Signed-off-by: Tudor Ambarus Reviewed-by: Marek Vasut -- Best regards, Marek Vasut
Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
On 09/11/2018 05:40 PM, Tudor Ambarus wrote: > Based on Cyrille Pitchen's patch https://lkml.org/lkml/2017/3/22/935. > > This patch is a transitional patch in introducing the support of > SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512s. > Non-uniform erase maps will be used later when initialized based on the > SFDP data. > > Introduce the memory erase map which splits the memory array into one > or many erase regions. Each erase region supports up to 4 erase types, > as defined by the JEDEC JESD216B (SFDP) specification. > > To be backward compatible, the erase map of uniform SPI NOR flash memories > is initialized so it contains only one erase region and this erase region > supports only one erase command. Hence a single size is used to erase any > sector/block of the memory. > > Besides, since the algorithm used to erase sectors on non-uniform SPI NOR > flash memories is quite expensive, when possible, the erase map is tuned > to come back to the uniform case. > > The 'erase with the best command, move forward and repeat' approach was > suggested by Cristian Birsan in a brainstorm session, so: > > Suggested-by: Cristian Birsan > Signed-off-by: Tudor Ambarus Reviewed-by: Marek Vasut -- Best regards, Marek Vasut
