| Message ID | 20230818042119.25722-1-ashok.reddy.soma@amd.com |
|---|---|
| Headers | show |
| Series | spi-nor: Add parallel and stacked memories support | expand |
On 8/18/23 06:21, Ashok Reddy Soma wrote: > This series adds support for Xilinx qspi parallel and stacked memeories. > > In parallel mode, the current implementation assumes that a maximum of > two flashes are connected. The QSPI controller splits the data evenly > between both the flashes so, both the flashes that are connected in > parallel mode should be identical. > During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in > nor->flags. > > In stacked mode the current implementation assumes that a maximum of two > flashes are connected and both the flashes are of same make but can > differ in sizes. So, except the sizes all other flash parameters of both > the flashes are identical > > Spi-nor will pass on the appropriate flash select flag to low level > driver, and it will select pass all the data to that particular flash. > > Write operation in parallel mode are performed in page size * 2 chunks as > each write operation results in writing both the flashes. For doubling > the address space each operation is performed at addr/2 flash offset, > where addr is the address specified by the user. > > Similarly for read and erase operations it will read from both flashes, > so size and offset are divided by 2 and send to flash. > > > > Ashok Reddy Soma (7): > dm: core: support reading a single indexed u64 value > mtd: spi-nor: Add parallel and stacked memories support > mtd: spi-nor: Add parallel memories support for read_sr and read_fsr > mtd: spi-nor: Add parallel and stacked memories support in read_bar > and write_bar > spi: spi-uclass: Read chipselect and restrict capabilities > spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver > spi: zynq_qspi: Add parallel memories support in QSPI driver > > drivers/core/of_access.c | 22 ++ > drivers/core/ofnode.c | 30 +++ > drivers/mtd/spi/spi-nor-core.c | 385 ++++++++++++++++++++++++++++----- > drivers/spi/spi-uclass.c | 21 +- > drivers/spi/xilinx_spi.c | 4 +- > drivers/spi/zynq_qspi.c | 145 +++++++++++-- > drivers/spi/zynq_spi.c | 6 +- > drivers/spi/zynqmp_gqspi.c | 146 +++++++++++-- > include/dm/of_access.h | 19 ++ > include/dm/ofnode.h | 12 + > include/linux/mtd/spi-nor.h | 13 ++ > include/spi.h | 29 ++- > 12 files changed, 737 insertions(+), 95 deletions(-) > I put this to CI and I see a lot of issue that's why v2 is definitely required but would be good if someone can review it from high level point of view. Thanks, Michal
On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma <ashok.reddy.soma@amd.com> wrote: > > This series adds support for Xilinx qspi parallel and stacked memeories. > > In parallel mode, the current implementation assumes that a maximum of > two flashes are connected. The QSPI controller splits the data evenly > between both the flashes so, both the flashes that are connected in > parallel mode should be identical. > During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in > nor->flags. > > In stacked mode the current implementation assumes that a maximum of two > flashes are connected and both the flashes are of same make but can > differ in sizes. So, except the sizes all other flash parameters of both > the flashes are identical > > Spi-nor will pass on the appropriate flash select flag to low level > driver, and it will select pass all the data to that particular flash. > > Write operation in parallel mode are performed in page size * 2 chunks as > each write operation results in writing both the flashes. For doubling > the address space each operation is performed at addr/2 flash offset, > where addr is the address specified by the user. > > Similarly for read and erase operations it will read from both flashes, > so size and offset are divided by 2 and send to flash. > > > > Ashok Reddy Soma (7): > dm: core: support reading a single indexed u64 value > mtd: spi-nor: Add parallel and stacked memories support > mtd: spi-nor: Add parallel memories support for read_sr and read_fsr > mtd: spi-nor: Add parallel and stacked memories support in read_bar > and write_bar > spi: spi-uclass: Read chipselect and restrict capabilities > spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver > spi: zynq_qspi: Add parallel memories support in QSPI driver This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree and let Linux approve the parallel and stacked otherwise it is very difficult to maintain. Thanks, Jagan,
On 12/6/23 13:24, Jagan Teki wrote: > On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma > <ashok.reddy.soma@amd.com> wrote: >> >> This series adds support for Xilinx qspi parallel and stacked memeories. >> >> In parallel mode, the current implementation assumes that a maximum of >> two flashes are connected. The QSPI controller splits the data evenly >> between both the flashes so, both the flashes that are connected in >> parallel mode should be identical. >> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in >> nor->flags. >> >> In stacked mode the current implementation assumes that a maximum of two >> flashes are connected and both the flashes are of same make but can >> differ in sizes. So, except the sizes all other flash parameters of both >> the flashes are identical >> >> Spi-nor will pass on the appropriate flash select flag to low level >> driver, and it will select pass all the data to that particular flash. >> >> Write operation in parallel mode are performed in page size * 2 chunks as >> each write operation results in writing both the flashes. For doubling >> the address space each operation is performed at addr/2 flash offset, >> where addr is the address specified by the user. >> >> Similarly for read and erase operations it will read from both flashes, >> so size and offset are divided by 2 and send to flash. >> >> >> >> Ashok Reddy Soma (7): >> dm: core: support reading a single indexed u64 value >> mtd: spi-nor: Add parallel and stacked memories support >> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr >> mtd: spi-nor: Add parallel and stacked memories support in read_bar >> and write_bar >> spi: spi-uclass: Read chipselect and restrict capabilities >> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver >> spi: zynq_qspi: Add parallel memories support in QSPI driver > > This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree > and let Linux approve the parallel and stacked otherwise it is very > difficult to maintain. Linux thread is here and it is pretty close to be merged. https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ DT binding is already approved but have no clue how big effort is to synchronize it. When was it synchronized last time? Thanks, Michal
On Wed, Dec 6, 2023 at 6:11 PM Michal Simek <michal.simek@amd.com> wrote: > > > > On 12/6/23 13:24, Jagan Teki wrote: > > On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma > > <ashok.reddy.soma@amd.com> wrote: > >> > >> This series adds support for Xilinx qspi parallel and stacked memeories. > >> > >> In parallel mode, the current implementation assumes that a maximum of > >> two flashes are connected. The QSPI controller splits the data evenly > >> between both the flashes so, both the flashes that are connected in > >> parallel mode should be identical. > >> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in > >> nor->flags. > >> > >> In stacked mode the current implementation assumes that a maximum of two > >> flashes are connected and both the flashes are of same make but can > >> differ in sizes. So, except the sizes all other flash parameters of both > >> the flashes are identical > >> > >> Spi-nor will pass on the appropriate flash select flag to low level > >> driver, and it will select pass all the data to that particular flash. > >> > >> Write operation in parallel mode are performed in page size * 2 chunks as > >> each write operation results in writing both the flashes. For doubling > >> the address space each operation is performed at addr/2 flash offset, > >> where addr is the address specified by the user. > >> > >> Similarly for read and erase operations it will read from both flashes, > >> so size and offset are divided by 2 and send to flash. > >> > >> > >> > >> Ashok Reddy Soma (7): > >> dm: core: support reading a single indexed u64 value > >> mtd: spi-nor: Add parallel and stacked memories support > >> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr > >> mtd: spi-nor: Add parallel and stacked memories support in read_bar > >> and write_bar > >> spi: spi-uclass: Read chipselect and restrict capabilities > >> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver > >> spi: zynq_qspi: Add parallel memories support in QSPI driver > > > > This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree > > and let Linux approve the parallel and stacked otherwise it is very > > difficult to maintain. > > Linux thread is here and it is pretty close to be merged. > https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ > > DT binding is already approved but have no clue how big effort is to synchronize > it. When was it synchronized last time? It wasn't. U-Boot spinor has its own and makes changes accordingly. It would be better to sync the Linux. This is what I'm referring to here. Jagan.
On 12/6/23 14:28, Jagan Teki wrote: > On Wed, Dec 6, 2023 at 6:11 PM Michal Simek <michal.simek@amd.com> wrote: >> >> >> >> On 12/6/23 13:24, Jagan Teki wrote: >>> On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma >>> <ashok.reddy.soma@amd.com> wrote: >>>> >>>> This series adds support for Xilinx qspi parallel and stacked memeories. >>>> >>>> In parallel mode, the current implementation assumes that a maximum of >>>> two flashes are connected. The QSPI controller splits the data evenly >>>> between both the flashes so, both the flashes that are connected in >>>> parallel mode should be identical. >>>> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in >>>> nor->flags. >>>> >>>> In stacked mode the current implementation assumes that a maximum of two >>>> flashes are connected and both the flashes are of same make but can >>>> differ in sizes. So, except the sizes all other flash parameters of both >>>> the flashes are identical >>>> >>>> Spi-nor will pass on the appropriate flash select flag to low level >>>> driver, and it will select pass all the data to that particular flash. >>>> >>>> Write operation in parallel mode are performed in page size * 2 chunks as >>>> each write operation results in writing both the flashes. For doubling >>>> the address space each operation is performed at addr/2 flash offset, >>>> where addr is the address specified by the user. >>>> >>>> Similarly for read and erase operations it will read from both flashes, >>>> so size and offset are divided by 2 and send to flash. >>>> >>>> >>>> >>>> Ashok Reddy Soma (7): >>>> dm: core: support reading a single indexed u64 value >>>> mtd: spi-nor: Add parallel and stacked memories support >>>> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr >>>> mtd: spi-nor: Add parallel and stacked memories support in read_bar >>>> and write_bar >>>> spi: spi-uclass: Read chipselect and restrict capabilities >>>> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver >>>> spi: zynq_qspi: Add parallel memories support in QSPI driver >>> >>> This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree >>> and let Linux approve the parallel and stacked otherwise it is very >>> difficult to maintain. >> >> Linux thread is here and it is pretty close to be merged. >> https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ >> >> DT binding is already approved but have no clue how big effort is to synchronize >> it. When was it synchronized last time? > > It wasn't. U-Boot spinor has its own and makes changes accordingly. It > would be better to sync the Linux. This is what I'm referring to here. Wasn't this the style which barebox guys wanted to do long time ago in U-Boot and the reason why barebox was born? I don't think that this can happen over night and also I don't think make sense to pretty much close spi framework for new changes till this happen. Tom: What do you think? Thanks, Michal
On Wed, Dec 6, 2023 at 7:12 PM Michal Simek <michal.simek@amd.com> wrote: > > > > On 12/6/23 14:28, Jagan Teki wrote: > > On Wed, Dec 6, 2023 at 6:11 PM Michal Simek <michal.simek@amd.com> wrote: > >> > >> > >> > >> On 12/6/23 13:24, Jagan Teki wrote: > >>> On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma > >>> <ashok.reddy.soma@amd.com> wrote: > >>>> > >>>> This series adds support for Xilinx qspi parallel and stacked memeories. > >>>> > >>>> In parallel mode, the current implementation assumes that a maximum of > >>>> two flashes are connected. The QSPI controller splits the data evenly > >>>> between both the flashes so, both the flashes that are connected in > >>>> parallel mode should be identical. > >>>> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in > >>>> nor->flags. > >>>> > >>>> In stacked mode the current implementation assumes that a maximum of two > >>>> flashes are connected and both the flashes are of same make but can > >>>> differ in sizes. So, except the sizes all other flash parameters of both > >>>> the flashes are identical > >>>> > >>>> Spi-nor will pass on the appropriate flash select flag to low level > >>>> driver, and it will select pass all the data to that particular flash. > >>>> > >>>> Write operation in parallel mode are performed in page size * 2 chunks as > >>>> each write operation results in writing both the flashes. For doubling > >>>> the address space each operation is performed at addr/2 flash offset, > >>>> where addr is the address specified by the user. > >>>> > >>>> Similarly for read and erase operations it will read from both flashes, > >>>> so size and offset are divided by 2 and send to flash. > >>>> > >>>> > >>>> > >>>> Ashok Reddy Soma (7): > >>>> dm: core: support reading a single indexed u64 value > >>>> mtd: spi-nor: Add parallel and stacked memories support > >>>> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr > >>>> mtd: spi-nor: Add parallel and stacked memories support in read_bar > >>>> and write_bar > >>>> spi: spi-uclass: Read chipselect and restrict capabilities > >>>> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver > >>>> spi: zynq_qspi: Add parallel memories support in QSPI driver > >>> > >>> This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree > >>> and let Linux approve the parallel and stacked otherwise it is very > >>> difficult to maintain. > >> > >> Linux thread is here and it is pretty close to be merged. > >> https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ > >> > >> DT binding is already approved but have no clue how big effort is to synchronize > >> it. When was it synchronized last time? > > > > It wasn't. U-Boot spinor has its own and makes changes accordingly. It > > would be better to sync the Linux. This is what I'm referring to here. > > Wasn't this the style which barebox guys wanted to do long time ago in U-Boot > and the reason why barebox was born? > I don't think that this can happen over night and also I don't think make sense > to pretty much close spi framework for new changes till this happen. Don't understand barebox theory here. I'm talking about code maintenance in u-boot spinor becoming meaningful if the core area gets synced with Linux. Jagan.
On Wed, Dec 06, 2023 at 06:58:14PM +0530, Jagan Teki wrote: > On Wed, Dec 6, 2023 at 6:11 PM Michal Simek <michal.simek@amd.com> wrote: > > > > > > > > On 12/6/23 13:24, Jagan Teki wrote: > > > On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma > > > <ashok.reddy.soma@amd.com> wrote: > > >> > > >> This series adds support for Xilinx qspi parallel and stacked memeories. > > >> > > >> In parallel mode, the current implementation assumes that a maximum of > > >> two flashes are connected. The QSPI controller splits the data evenly > > >> between both the flashes so, both the flashes that are connected in > > >> parallel mode should be identical. > > >> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in > > >> nor->flags. > > >> > > >> In stacked mode the current implementation assumes that a maximum of two > > >> flashes are connected and both the flashes are of same make but can > > >> differ in sizes. So, except the sizes all other flash parameters of both > > >> the flashes are identical > > >> > > >> Spi-nor will pass on the appropriate flash select flag to low level > > >> driver, and it will select pass all the data to that particular flash. > > >> > > >> Write operation in parallel mode are performed in page size * 2 chunks as > > >> each write operation results in writing both the flashes. For doubling > > >> the address space each operation is performed at addr/2 flash offset, > > >> where addr is the address specified by the user. > > >> > > >> Similarly for read and erase operations it will read from both flashes, > > >> so size and offset are divided by 2 and send to flash. > > >> > > >> > > >> > > >> Ashok Reddy Soma (7): > > >> dm: core: support reading a single indexed u64 value > > >> mtd: spi-nor: Add parallel and stacked memories support > > >> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr > > >> mtd: spi-nor: Add parallel and stacked memories support in read_bar > > >> and write_bar > > >> spi: spi-uclass: Read chipselect and restrict capabilities > > >> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver > > >> spi: zynq_qspi: Add parallel memories support in QSPI driver > > > > > > This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree > > > and let Linux approve the parallel and stacked otherwise it is very > > > difficult to maintain. > > > > Linux thread is here and it is pretty close to be merged. > > https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ > > > > DT binding is already approved but have no clue how big effort is to synchronize > > it. When was it synchronized last time? > > It wasn't. U-Boot spinor has its own and makes changes accordingly. It > would be better to sync the Linux. This is what I'm referring to here. Is anyone actively working on that? Under the assumption that no one is, I really don't want to block all progress in this subsystem until a new person steps up to start reworking everything.
On 12/12/23 13:34, Tom Rini wrote: > On Wed, Dec 06, 2023 at 06:58:14PM +0530, Jagan Teki wrote: >> On Wed, Dec 6, 2023 at 6:11 PM Michal Simek <michal.simek@amd.com> wrote: >>> >>> >>> >>> On 12/6/23 13:24, Jagan Teki wrote: >>>> On Fri, Aug 18, 2023 at 9:51 AM Ashok Reddy Soma >>>> <ashok.reddy.soma@amd.com> wrote: >>>>> >>>>> This series adds support for Xilinx qspi parallel and stacked memeories. >>>>> >>>>> In parallel mode, the current implementation assumes that a maximum of >>>>> two flashes are connected. The QSPI controller splits the data evenly >>>>> between both the flashes so, both the flashes that are connected in >>>>> parallel mode should be identical. >>>>> During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in >>>>> nor->flags. >>>>> >>>>> In stacked mode the current implementation assumes that a maximum of two >>>>> flashes are connected and both the flashes are of same make but can >>>>> differ in sizes. So, except the sizes all other flash parameters of both >>>>> the flashes are identical >>>>> >>>>> Spi-nor will pass on the appropriate flash select flag to low level >>>>> driver, and it will select pass all the data to that particular flash. >>>>> >>>>> Write operation in parallel mode are performed in page size * 2 chunks as >>>>> each write operation results in writing both the flashes. For doubling >>>>> the address space each operation is performed at addr/2 flash offset, >>>>> where addr is the address specified by the user. >>>>> >>>>> Similarly for read and erase operations it will read from both flashes, >>>>> so size and offset are divided by 2 and send to flash. >>>>> >>>>> >>>>> >>>>> Ashok Reddy Soma (7): >>>>> dm: core: support reading a single indexed u64 value >>>>> mtd: spi-nor: Add parallel and stacked memories support >>>>> mtd: spi-nor: Add parallel memories support for read_sr and read_fsr >>>>> mtd: spi-nor: Add parallel and stacked memories support in read_bar >>>>> and write_bar >>>>> spi: spi-uclass: Read chipselect and restrict capabilities >>>>> spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver >>>>> spi: zynq_qspi: Add parallel memories support in QSPI driver >>>> >>>> This set is a bit hard to go. We need to Sync the Linux SPI-NOR tree >>>> and let Linux approve the parallel and stacked otherwise it is very >>>> difficult to maintain. >>> >>> Linux thread is here and it is pretty close to be merged. >>> https://lore.kernel.org/all/20231125092137.2948-1-amit.kumar-mahapatra@amd.com/ >>> >>> DT binding is already approved but have no clue how big effort is to synchronize >>> it. When was it synchronized last time? >> >> It wasn't. U-Boot spinor has its own and makes changes accordingly. It >> would be better to sync the Linux. This is what I'm referring to here. > > Is anyone actively working on that? Under the assumption that no one is, > I really don't want to block all progress in this subsystem until a new > person steps up to start reworking everything. > Glad to hear it. Actually I have already reported to Venkatesh that there is still issue for sandbox reported by CI in v5. And v5 version is available here. https://lore.kernel.org/all/20231201031839.239567-1-venkatesh.abbarapu@amd.com/ Thanks, Michal
This series adds support for Xilinx qspi parallel and stacked memeories. In parallel mode, the current implementation assumes that a maximum of two flashes are connected. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in nor->flags. In stacked mode the current implementation assumes that a maximum of two flashes are connected and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical Spi-nor will pass on the appropriate flash select flag to low level driver, and it will select pass all the data to that particular flash. Write operation in parallel mode are performed in page size * 2 chunks as each write operation results in writing both the flashes. For doubling the address space each operation is performed at addr/2 flash offset, where addr is the address specified by the user. Similarly for read and erase operations it will read from both flashes, so size and offset are divided by 2 and send to flash. Ashok Reddy Soma (7): dm: core: support reading a single indexed u64 value mtd: spi-nor: Add parallel and stacked memories support mtd: spi-nor: Add parallel memories support for read_sr and read_fsr mtd: spi-nor: Add parallel and stacked memories support in read_bar and write_bar spi: spi-uclass: Read chipselect and restrict capabilities spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver spi: zynq_qspi: Add parallel memories support in QSPI driver drivers/core/of_access.c | 22 ++ drivers/core/ofnode.c | 30 +++ drivers/mtd/spi/spi-nor-core.c | 385 ++++++++++++++++++++++++++++----- drivers/spi/spi-uclass.c | 21 +- drivers/spi/xilinx_spi.c | 4 +- drivers/spi/zynq_qspi.c | 145 +++++++++++-- drivers/spi/zynq_spi.c | 6 +- drivers/spi/zynqmp_gqspi.c | 146 +++++++++++-- include/dm/of_access.h | 19 ++ include/dm/ofnode.h | 12 + include/linux/mtd/spi-nor.h | 13 ++ include/spi.h | 29 ++- 12 files changed, 737 insertions(+), 95 deletions(-)