[U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

Jagan Teki jagannadh.teki at gmail.com
Wed May 9 10:48:15 UTC 2018


On Wed, May 9, 2018 at 4:08 PM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> <sivadur at xilinx.com> wrote:
>> Hi Jagan,
>>
>>> -----Original Message-----
>>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>>> Sent: Wednesday, May 09, 2018 1:22 PM
>>> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>> Cc: Jagan Teki <jagan at amarulasolutions.com>; U-Boot-Denx <u-
>>> boot at lists.denx.de>; michal.simek at xilinx.com
>>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> ZynqMP qspi driver
>>>
>>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>>> <sivadur at xilinx.com> wrote:
>>> >
>>> > Hi,
>>> >
>>> >> -----Original Message-----
>>> >> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>>> >> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>> >> Cc: Jagan Teki <jagan at amarulasolutions.com>; U-Boot-Denx <u-
>>> >> boot at lists.denx.de>; michal.simek at xilinx.com
>>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>>> >> for ZynqMP qspi driver
>>> >>
>>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>>> >> <sivadur at xilinx.com> wrote:
>>> >> > Hi Jagan,
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: Jagan Teki [mailto:jagan at amarulasolutions.com]
>>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>>> >> >> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>> >> >> Cc: U-Boot-Denx <u-boot at lists.denx.de>; michal.simek at xilinx.com
>>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> >> ZynqMP
>>> >> >> qspi driver
>>> >> >>
>>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>>> >> >> <siva.durga.paladugu at xilinx.com> wrote:
>>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>>> >> >> > is responsible for communicating with qspi flash devices.
>>> >> >> >
>>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>>> >> >> > <siva.durga.paladugu at xilinx.com>
>>> >> >> > ---
>>> >> >> > Changes for v3:
>>> >> >> > - Renamed all macros, functions, files and configs as per
>>> >> >> > comment
>>> >> >> > - Used wait_for_bit wherever required
>>> >> >> > - Removed unnecessary header inclusion
>>> >> >> >
>>> >> >> > Changes for v2:
>>> >> >> > - Rebased on top of latest master
>>> >> >> > - Moved macro definitions to .h file as per comment
>>> >> >> > - Fixed magic values with macros as per comment
>>> >> >> > ---
>>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>>> ++++++
>>> >> >> >  drivers/spi/Kconfig                             |   7 +
>>> >> >> >  drivers/spi/Makefile                            |   1 +
>>> >> >> >  drivers/spi/zynqmp_gqspi.c                      | 670
>>> >> >> ++++++++++++++++++++++++
>>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
>>> >> >> > arch/arm/include/asm/arch-
>>> >> >> zynqmp/zynqmp_gqspi.h
>>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
>>> >> >> >
>>> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >>
>>> >> >> already asked you to move this header code in driver .c file
>>> >> >
>>> >> > You might have missed my reply to your earlier comment on this.
>>> >> > These were moved to .h based on comment from Lukasz in v1.
>>> >> > I don’t have any issue in having them anywhere. Let me know your
>>> choice.
>>> >>
>>> >> I'm trying to align Linux code, better to move like that and make
>>> >> sure to use similar macros.
>>> >>
>>> >> >
>>> >
>>> > [snip]
>>> >
>>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>>> >> *priv) {
>>> >> >> > +       u8 command = 1;
>>> >> >> > +       u32 gen_fifo_cmd;
>>> >> >> > +       u32 bytecount = 0;
>>> >> >> > +
>>> >> >> > +       while (priv->len) {
>>> >> >> > +               gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>>> >> >> > +               gen_fifo_cmd |= GQSPI_GFIFO_TX;
>>> >> >> > +
>>> >> >> > +               if (command) {
>>> >> >> > +                       command = 0;
>>> >> >> > +                       last_cmd = *(u8 *)priv->tx_buf;
>>> >> >> > +               }
>>> >> >>
>>> >> >> don't understand this code can you explain? command assigned 1 it
>>> >> >> will not updated anywhere?
>>> >> >
>>> >> > I want to store last command sent. As the first byte in loop only
>>> >> > contains command, it ensures it fills only for one time and next
>>> >> > time it
>>> >> may contain data to be sent along with command.
>>> >> > Command initialized to 1 while declaring it above(u8 command = 1).
>>> >>
>>> >> Ok the first TX buf has command and reused in tx and rx fifo, how
>>> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
>>> >
>>> > This holds the command that was sent last to the device before we use in
>>> tx/rx fill, hence used this name.
>>>
>>> ie. what I wonder, usually the spi transfer start with cmd + data in that case
>>> it would be the first command, did gqspi work reverse way?
>>
>> It's also same as others :-), the last_cmd holds the recent command that was sent to the device.
>> Its just name. To avoid confusion, I can use other names like "cmd_sent or cmd_recent". Hope this is ok for you or suggest which
>> one would be appropriate.
>
> Let's park the naming aside.
>
>    u8 command = 0;
>
>    while (priv->len) {
>                gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>                gen_fifo_cmd |= GQSPI_GFIFO_TX;
>
>                if (command) {
>                        command = 0;
>                        last_cmd = *(u8 *)priv->tx_buf;
>                }
>     ......
>              priv->len--;
>   }
>
> Why the last_cmd assignment is in loop? say priv->len has non-zero the
> command is 1 last_cmd assigned and command reassigned to 0 there is no
> way execute the if for next while isn't it?

The main issue with this driver, which I told/commented several times
about using flash specific stuff.

+
+#define QUAD_OUT_READ_CMD              0x6B
+#define QUAD_PAGE_PROGRAM_CMD          0x32
+#define DUAL_OUTPUT_FASTRD_CMD         0x3B
+

Jagan.


More information about the U-Boot mailing list