The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c
Hi,
On 10/23/2018 12:39 PM, Yogesh Narayan Gaur wrote:
> Hi,
>
> Did we have have any comments or remarks about this patch-series, if not
> please apply.
Now that the octal mode is close to an end, it would make sense to wait for it,
so that you can add the octal flag for this memory when
On 11/08/2018 02:54 PM, Boris Brezillon wrote:
> On Thu, 8 Nov 2018 11:07:11 +
> wrote:
>
>> The map selector is limited to a maximum of 8 bits, allowing
>> for a maximum of 256 possible map configurations. The total
>> number of map configurations should be addressable by the
>> total
Use GFP_DMA to ensure that the memory we allocate for transfers in
nor->read() can be DMAed.
spi_nor_read_sfdp() calls spi_nor_read_raw(), which calls nor-read().
The latter might be implemented by the m25p80 driver which is on top
of the spi-mem layer. spi-mem requires DMA-able in/out buffers,
The map selector is limited to a maximum of 8 bits, allowing
for a maximum of 256 possible map configurations. The total
number of map configurations should be addressable by the
total number of bits described by the detection commands.
For example: if there are five to eight possible sector map
JESD216C states that just the Basic Flash Parameter Table is mandatory.
Already defined (or future) additional parameter headers and tables are
optional.
Don't drop already collected sfdp data in case an optional table
parser fails. In case of failing, each optional parser is responsible
to roll
Iterate over smpt array using its starting address and length
instead of the blindly iterations that used data found in the array.
This prevents possible memory accesses outside of the smpt array
boundaries in case software, or manufacturers, misrepresent smpt
array fields.
Suggested-by: Boris
Bunch of fixes that we found while debugging the roll back to
SPINOR_OP_READ_1_1_4_4B in case smpt parser fails.
Boris, Yogesh,
Now I'm looking for a fix in case the smpt detection commands
define variable address length and dummy bytes. Will follow.
Tudor Ambarus (7):
mtd: spi-nor: don't
The entire smpt array is initialized with data read from sfdp,
there is no need to init it with zeroes before.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c
spi_nor_read_raw() calls nor->read() which might be implemented
by the m25p80 driver. m25p80 uses the spi-mem layer which requires
DMA-able in/out buffers. Pass kmalloc'ed dma buffer to spi_nor_read_raw().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 14 ++
1
Don't overwrite the errno from spi_nor_read_raw().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index bd1866d714f2..79ca1102faed
On 11/08/2018 04:15 PM, Boris Brezillon wrote:
> On Thu, 8 Nov 2018 13:58:45 +
> wrote:
>
>> On 11/08/2018 02:54 PM, Boris Brezillon wrote:
>>> On Thu, 8 Nov 2018 11:07:11 +
>>> wrote:
>>>
The map selector is limited to a maximum of 8 bits, allowing
for a maximum of 256
On 11/08/2018 04:54 PM, Boris Brezillon wrote:
> On Thu, 8 Nov 2018 14:48:11 +
> wrote:
>
>> +
>
> Maybe I missed something but it sounds like this change is just
> optimizing the SPMT parsing a bit, and to be honest, I'm not sure this
> is really needed. Most of
There are uniform, non-uniform and flexible erase flash configurations.
The non-uniform erase types, are the erase types that can _not_ erase
the entire flash by their own.
As the code was, in case flashes had flexible erase capabilities
(support both uniform and non-uniform erase types in the
Hi, Liu, Boris, Cyrille,
On 11/14/2018 03:51 PM, Boris Brezillon wrote:
> On Wed, 14 Nov 2018 20:56:05 +0800
> Liu Xiang wrote:
>
>> In is25lp256, the DWORD1 of JEDEC Basic Flash Parameter Header
>> is 0xfff920e5. So the DWORD1[18:17] Address Bytes bits are 0b00,
Liu, can you point us to a
JESD216C states that just the Basic Flash Parameter Table is mandatory.
Already defined (or future) additional parameter headers and tables are
optional.
Don't drop already collected sfdp data in case an optional table
parser fails. In case of failing, each optional parser is responsible
to roll
Iterate over smpt array using its starting address and length
instead of the blind iterations that used data found in the array.
This prevents possible memory accesses outside of the smpt array
boundaries in case software, or manufacturers, misrepresent smpt
array fields.
Fixes: b038e8e3be72
spi_nor_read_raw() calls nor->read() which might be implemented
by the m25p80 driver. m25p80 uses the spi-mem layer which requires
DMA-able in/out buffers. Pass kmalloc'ed dma buffer to spi_nor_read_raw().
Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
Signed-off-by:
The entire smpt array is initialized with data read from sfdp,
there is no need to init it with zeroes before.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c
Don't overwrite the errno from spi_nor_read_raw().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 98e433e8e4c2..04a1c5b825e6
Bunch of fixes that we found while debugging the roll back to
SPINOR_OP_READ_1_1_4_4B in case smpt parser fails.
Boris, Yogesh,
Now I'm looking for a fix in case the smpt detection commands
define variable address length and dummy bytes. Will follow.
v2:
- drop patches 3 and 6
- update fixes
gcc 7 with -Wimplicit-fallthrough raises:
drivers/mtd/spi-nor/spi-nor.c: In function ‘set_4byte’:
drivers/mtd/spi-nor/spi-nor.c:289:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
need_wren = true;
~~^~
drivers/mtd/spi-nor/spi-nor.c:290:2: note: here
On 11/16/2018 01:17 PM, Tudor Ambarus - M18064 wrote:
[cut]
> @@ -2729,9 +2751,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
>* uniform_erase_type bitmask. The bitmask will be used later on when
>* selecting the uniform erase.
>*/
> -
There are uniform, non-uniform and flexible erase flash configurations.
The non-uniform erase types, are the erase types that can _not_ erase
the entire flash by their own.
As the code was, in case flashes had flexible erase capabilities
(support both uniform and non-uniform erase types in the
From: Tudor Ambarus
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to
From: "tudor.amba...@microchip.com"
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency
From: "tudor.amba...@microchip.com"
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency
On 11/14/2018 02:55 PM, Liu Xiang wrote:
> The is25lp256 supports 4-byte opcodes and quad output.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Liu Xiang
Reviewed-by: Tudor Ambarus
> ---
> drivers/mtd/spi-nor/spi-nor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
From: Cyrille Pitchen
Add support for SFDP (JESD216B) 4-byte Address Instruction Table. This
table is optional but when available, we parse it to get the 4-byte
address op codes supported by the memory.
Using these op codes is stateless as opposed to entering the 4-byte
address mode or setting
Hi, Alexander,
On 11/23/2018 01:33 PM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> So erasesize is back to the value before non-uniform support patches,
> partitions are not made read only any more, but actual write or
> erase still fails.
How does the erase fail?
What map configuration is
Hi, Alexander,
On 11/23/2018 11:42 AM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> Hello Tudor,
>
> On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
>> From: Tudor Ambarus
>>
>> Bug reported for the out-of-tree S25FS128S flash memory.
>>
>> BFPT table advertises all the erase types
From: Tudor Ambarus
Bug reported for the out-of-tree S25FS128S flash memory.
BFPT table advertises all the erase types supported by all the
possible map configurations. Update the erase_type array to indicate
which erase types are applicable to the current map configuration.
Backward
Hi, Alexander,
Can you please test this patch to see if it fixes your problem?
Thanks,
ta
On 11/22/2018 02:36 PM, Tudor Ambarus - M18064 wrote:
> From: Tudor Ambarus
>
> Bug reported for the out-of-tree S25FS128S flash memory.
>
> BFPT table advertises all the erase types supported by all
On 11/22/2018 06:14 PM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> Hello Tudor,
>
> On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
>> From: Tudor Ambarus
>>
>> Bug reported for the out-of-tree S25FS128S flash memory.
>>
>> BFPT table advertises all the erase types supported by all
From: Cyrille Pitchen
Add support for SFDP (JESD216B) 4-byte Address Instruction Table. This
table is optional but when available, we parse it to get the 4-byte
address op codes supported by the memory.
Using these op codes is stateless as opposed to entering the 4-byte
address mode or setting
On 11/20/2018 05:35 PM, kbuild test robot wrote:
> Hi Cyrille,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on mtd/spi-nor/next]
> [also build test ERROR on v4.20-rc3 next-20181120]
> [if your patch is applied to the wrong git tree, please drop us a note
From: Tudor Ambarus
BFPT advertises all the erase types supported by all the possible
map configurations. Mask out the erase types that are not supported
by the current map configuration.
Backward compatibility test done on sst26vf064b.
Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map
On 11/28/2018 09:57 AM, Boris Brezillon wrote:
> On Tue, 20 Nov 2018 11:55:21 +
> wrote:
>
>> +
>> +/*
>> + * We set nor->addr_width here to skip spi_nor_set_4byte_opcodes()
>> + * later because this latest function implements a legacy quirk for
>> + * the erase size of
On 1/20/21 5:02 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 15:52, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 4:05 PM, Michael Walle wrote:
diff --git a/drivers/mtd/spi-nor/sst.c
On 1/20/21 6:47 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 17:25, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 5:49 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open
On 1/20/21 5:49 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-01-20 16:39, schrieb tudor.amba...@microchip.com:
>> On 1/20/21 5:02 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open
On 1/20/21 7:00 AM, Pan Bian wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The allocated master is not released. Goto error handling label rather
> than directly return.
>
> Fixes: 04242ca4e891 ("spi: atmel: Use SPI core DMA mapping
Hi, Sieng,
On 12/8/20 3:57 AM, Sieng Piaw Liew wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Enable 4-bit Block Protect support for MX256405D and its variants using
> the same ID.
>
> Tested on Innacom W3400V6 router with MX25L6406E
Hi, Saravana,
On 12/18/20 5:17 AM, Saravana Kannan wrote:
> Cyclic dependencies in some firmware was one of the last remaining
> reasons fw_devlink=on couldn't be set by default. Now that cyclic
> dependencies don't block probing, set fw_devlink=on by default.
>
> Setting fw_devlink=on by
On 1/20/21 4:05 PM, Michael Walle wrote:
>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> index 00e48da0744a..d6e1396abb96 100644
>> --- a/drivers/mtd/spi-nor/sst.c
>> +++ b/drivers/mtd/spi-nor/sst.c
>> @@ -8,6 +8,39 @@
>>
>> #include "core.h"
>>
>> +static int
On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
>
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> Even if sst26vf shares the SPINOR_OP_GBULK opcode with
>> Macronix (ex. MX25U12835F) and
On 1/20/21 2:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
Hi, Pratyush,
Thanks for reviewing this.
>
> On 20/01/21 12:54PM, Tudor Ambarus wrote:
>> The Global Block Unlock command has different names
Hi, Andreas,
On 12/21/20 12:43 AM, Andreas Rammhold wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This adds support for the xt25f128b as found on the rockpi4b SBC.
>
> Signed-off-by: Andreas Rammhold
> ---
>
> This continues the
On 10/5/20 6:31 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Since this flash doesn't have a Profile 1.0 table, the Octal DTR
> capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
> fast read
On 10/1/20 9:34 AM, Pratyush Yadav wrote:
> So using an address width of 4 here is not necessarily the right thing
> to do. This change would break SMPT parsing for all flashes that use
> 3-byte addressing by default because SMPT parsing can involve register
> reads/writes. One such device is the
On 10/6/20 2:03 PM, Tudor Ambarus - M18064 wrote:
> On 10/1/20 9:34 AM, Pratyush Yadav wrote:
>> So using an address width of 4 here is not necessarily the right thing
>> to do. This change would break SMPT parsing for all flashes that use
>> 3-byte addressing by default because SMPT parsing can
On 10/5/20 12:32 AM, Bert Vermeulen wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> If a flash chip has more than 16MB capacity but its BFPT reports
> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3.
>
> The check
On 10/5/20 11:48 AM, Alexander A Sverdlin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> From: Alexander Sverdlin
>
> spi_nor_parse_sfdp() modifies the passed structure so that it points to
> itself (params.erase_map.regions to
On 10/1/20 11:20 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Allow flashes to specify a hook to enable octal DTR mode. Use this hook
> whenever possible to get optimal transfer speeds.
>
> Signed-off-by: Pratyush
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> They are thin wrappers around nor->controller_ops->{read,write}_reg().
> In a future commit DTR support will be added. These ops can not be
> supported by the {read,write}_reg() hooks and these helpers will make it
> easier to reject those calls.
2/15
Hi,
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Allow flashes to specify a hook to enable octal DTR mode. Use this hook
> whenever possible to get optimal transfer speeds.
>
> Signed-off-by:
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> ENOTSUPP is not a SUSV4 error code. Using EOPNOTSUPP is preferred
> in its stead.
>
> Signed-off-by: Pratyush Yadav
Reviewed-by: Tudor Ambarus
> ---
>
On 9/29/20 3:51 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 29/09/20 11:26AM, tudor.amba...@microchip.com wrote:
>> Hi,
>>
>> On 9/16/20 3:44 PM, Pratyush Yadav wrote:
>>> EXTERNAL EMAIL: Do not click links or
Hi, Pratyush,
I'm replying to v10 so that we continue the discussion, but this applies to v13
as well.
On 7/21/20 2:29 PM, Pratyush Yadav wrote:
>>> @@ -2368,12 +2517,16 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor,
>>> u32 *hwcaps)
>>> struct spi_nor_flash_parameter *params =
On 9/29/20 7:29 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 29/09/20 03:42PM, tudor.amba...@microchip.com wrote:
>> Hi, Pratyush,
>>
>> I'm replying to v10 so that we continue the discussion, but this applies to
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Some devices in DTR mode expect an extra command byte called the
> extension. The extension can either be same as the opcode, bitwise
> inverse of the
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This table is indication that the flash is xSPI compliant and hence
> supports octal DTR mode. Extract information like the fast read opcode,
> dummy
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The xSPI Profile 1.0 table specifies how many dummy cycles and address
> bytes are needed for the Read Status Register command in octal DTR mode.
> Use
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Some controllers, like the cadence qspi controller, have trouble reading
> only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in
did you
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Allow flashes to specify a hook to enable octal DTR mode. Use this hook
> whenever possible to get optimal transfer speeds.
We need to restrict the access
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> A Soft Reset sequence will return the flash to Power-on-Reset (POR)
> state. It consists of two commands: Soft Reset Enable and Soft Reset.
> Find out if
On 9/29/20 4:08 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 16/09/20 06:14PM, Pratyush Yadav wrote:
>> Perform a Soft Reset on shutdown on flashes that support it so that the
>> flash can be reset to its initial
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On resume, the init procedure will be run that will re-enable it.
>
> Signed-off-by: Pratyush Yadav
> ---
> drivers/mtd/spi-nor/core.c | 18
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Flashes might want to add a custom setup hook to configure the flash in
> the proper mode for operation. But after that, they would still want to
> run the
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
> support for using it in octal DTR mode.
>
> The flash by default boots in a hybrid
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Since this flash doesn't have a Profile 1.0 table, the Octal DTR
> capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
> fast read
On 9/16/20 3:44 PM, Pratyush Yadav wrote:
> Hi,
Hello,
>
> This series adds support for Octal DTR flashes in the SPI NOR framework,
> and then adds hooks for the Cypress Semper and Micron Xcella flashes to
> allow running them in Octal DTR mode. This series assumes that the flash
> is handed to
Hi, Michael,
PLease accept my apologies for the long delay.
I do agree with Vignesh's comments. Few others below.
On 3/27/20 5:59 PM, Michael Walle wrote:
[cut]
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index cc68ea84318e..fd1c36d70a13 100644
> ---
On 10/1/20 1:38 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
Hi, Michael,
>
>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>> index cc68ea84318e..fd1c36d70a13 100644
>>> ---
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> ENOTSUPP is not a SUSV4 error code. Using EOPNOTSUPP is preferred
> in its stead.
>
> Reviewed-by: Tudor Ambarus
The R-b tag should be after your S-o-b.
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> They are thin wrappers around
> nor->controller_ops->{read_reg,write_reg,erase}(). In a future commit
> DTR support will be added. These ops can not be
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This table is indication that the flash is xSPI compliant and hence
> supports octal DTR mode. Extract information like the fast read opcode,
> dummy
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The xSPI Profile 1.0 table specifies how many dummy cycles and address
> bytes are needed for the Read Status Register command in octal DTR mode.
> Use
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Some controllers, like the cadence qspi controller, have trouble reading
> only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in
> DTR
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Allow flashes to specify a hook to enable octal DTR mode. Use this hook
> whenever possible to get optimal transfer speeds.
>
> Signed-off-by: Pratyush
On 10/1/20 10:50 AM, Miquel Raynal wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
> It seems that your mailer/server introduced that line automatically,
> can you do something to avoid it?
>
I don't know any plugin that removes tags
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Double Transfer Rate (DTR) is SPI protocol in which data is transferred
> on each clock edge as opposed to on each clock cycle. Make
> framework-level
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> From: Tudor Ambarus
>
> Parse just the 22nd dword and look for the 'DTR Octal Mode Enable
> Volatile bit'.
>
> SPI_NOR_IO_MODE_EN_VOLATILE should be set
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> A Soft Reset sequence will return the flash to Power-on-Reset (POR)
> state. It consists of two commands: Soft Reset Enable and Soft Reset.
> Find out if
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Perform a Soft Reset on shutdown on flashes that support it so that the
> flash can be reset to its initial state and any configurations made by
> spi-nor
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On resume, the init procedure will be run that will re-enable it.
>
> Signed-off-by: Pratyush Yadav
Reviewed-by: Tudor Ambarus
> ---
>
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
> support for using it in octal DTR mode.
>
> The flash by default boots in a hybrid
On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Since this flash doesn't have a Profile 1.0 table, the Octal DTR
> capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
> fast read
On 10/1/20 11:37 AM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 01/10/20 07:46AM, tudor.amba...@microchip.com wrote:
>> On 9/30/20 9:57 PM, Pratyush Yadav wrote:
>>> @@ -2387,12 +2496,16 @@
On 10/1/20 11:40 AM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 01/10/20 08:35AM, tudor.amba...@microchip.com wrote:
>> On 9/30/20 9:57 PM, Pratyush Yadav wrote:
>>> EXTERNAL EMAIL: Do not click links or open
On 10/1/20 10:38 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
Hi, Michael,
>
> Am 2020-10-01 09:07, schrieb tudor.amba...@microchip.com:
> diff --git a/drivers/mtd/spi-nor/core.c
On 10/1/20 3:28 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all Atmel parts
On 10/1/20 3:28 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all Atmel parts
On 10/1/20 9:34 AM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi,
>
> On 01/10/20 01:56AM, Bert Vermeulen wrote:
>> Flash chips that announce BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 capability
>> get an addr_width of 3.
On 10/1/20 5:12 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-10-01 16:06, schrieb tudor.amba...@microchip.com:
>> On 10/1/20 3:28 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open
On 10/1/20 5:37 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2020-10-01 16:25, schrieb tudor.amba...@microchip.com:
>> On 10/1/20 5:12 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open
On 9/14/20 3:00 PM, Vignesh Raghavendra wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 9/11/20 8:17 PM, Marco Felsch wrote:
>> The sst write support for devices using the special SST_WRITE routine
>> is broken since commit commit
Hi, Mason, YC Lin,
On 5/29/20 10:36 AM, Mason Yang wrote:
> Get maximum operation speed of device in octal mode from
> BFPT 20th DWORD.
>
I would like to understand how would we use the max speed value
at the SPI NOR level. The maximum operation speed is typically used
to determine the number
1 - 100 of 688 matches
Mail list logo
