[U-Boot] [PATCH] spi: cadence_qspi: Enable quad mode for read and programming

[Jagan Teki]

On 26 August 2015 at 21:27, Tom Rini <trini at konsulko.com> wrote:
> On Wed, Aug 26, 2015 at 07:17:28PM +0530, Jagan Teki wrote:
>> On 26 August 2015 at 13:00, Chin Liang See <clsee at altera.com> wrote:
>> > On Wed, 2015-08-26 at 08:57 +0200, marex at denx.de wrote:
>> >> On Wednesday, August 26, 2015 at 02:09:55 AM, Chin Liang See wrote:
>> >> > Enable the quad output fast read and quad input fast program
>> >> > support. Quad mode is supported by Cadence QSPI controller.
>> >> >
>> >> > Signed-off-by: Chin Liang See <clsee at altera.com>
>> >> > Cc: Dinh Nguyen <dinguyen at opensource.altera.com>
>> >> > Cc: Stefan Roese <sr at denx.de>
>> >> > Cc: Vikas Manocha <vikas.manocha at st.com>
>> >> > Cc: Jagannadh Teki <jteki at openedev.com>
>> >> > Cc: Pavel Machek <pavel at denx.de>
>> >> > Cc: Marek Vasut <marex at denx.de>
>> >> > ---
>> >> >  drivers/spi/cadence_qspi.c     |   11 +++++++++++
>> >> >  drivers/spi/cadence_qspi_apb.c |   16 ++++++++++++----
>> >> >  2 files changed, 23 insertions(+), 4 deletions(-)
>> >> >
>> >> > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> >> > index 34a0f46..c6b69c4 100644
>> >> > --- a/drivers/spi/cadence_qspi.c
>> >> > +++ b/drivers/spi/cadence_qspi.c
>> >> > @@ -318,6 +318,16 @@ static int cadence_spi_ofdata_to_platdata(struct
>> >> > udevice *bus) return 0;
>> >> >  }
>> >> >
>> >> > +static int cadence_spi_child_pre_probe(struct udevice *dev)
>> >> > +{
>> >> > +   struct spi_slave *slave = dev_get_parentdata(dev);
>> >> > +
>> >> > +   /* Cadence QSPI controller can support quad read and program */
>> >> > +   slave->op_mode_rx = SPI_OPM_RX_QOF;
>> >> > +   slave->op_mode_tx = SPI_OPM_TX_QPP;
>> >> > +   return 0;
>> >> > +}
>> >> > +
>> >> >  static const struct dm_spi_ops cadence_spi_ops = {
>> >> >     .xfer           = cadence_spi_xfer,
>> >> >     .set_speed      = cadence_spi_set_speed,
>> >> > @@ -341,5 +351,6 @@ U_BOOT_DRIVER(cadence_spi) = {
>> >> >     .ofdata_to_platdata = cadence_spi_ofdata_to_platdata,
>> >> >     .platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
>> >> >     .priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
>> >> > +   .child_pre_probe = cadence_spi_child_pre_probe,
>> >> >     .probe = cadence_spi_probe,
>> >> >  };
>> >>
>> >> Simon, can you please check if this DM bit is correct ?
>> >>
>> >> > diff --git a/drivers/spi/cadence_qspi_apb.c
>> >> > b/drivers/spi/cadence_qspi_apb.c index d053407..deffb6b 100644
>> >> > --- a/drivers/spi/cadence_qspi_apb.c
>> >> > +++ b/drivers/spi/cadence_qspi_apb.c
>> >> > @@ -29,6 +29,9 @@
>> >> >  #include <asm/io.h>
>> >> >  #include <asm/errno.h>
>> >> >  #include "cadence_qspi.h"
>> >> > +#include <spi.h>
>> >> > +#include <spi_flash.h>
>> >> > +#include "../mtd/spi/sf_internal.h"
>> >>
>> >> Why do you need this include ?
>> >>
>> >
>> > Actually I am comparing the opcode to determine whether its a quad
>> > command. If yes, we need to setup the controller accordingly.
>>
>> Sorry, this I wouldn't recommend as of now please assign quad directly
>> instead setting up controller based on the flash stuff, Yes things
>> need to change it on u-boot like spi-nor framework and currently we
>> are working on it[1] will defiantly back with proper solution.
>>
>> [1] http://git.denx.de/?p=u-boot/u-boot-spi.git;a=shortlog;h=refs/heads/spi-nor
>
> What's not clear to me here is, are you implementing a similar framework
> to what the linux kernel has but with the same name, or slowly
> introducing the framework from the linux kernel?  Thanks.

I can't say it's a direct Linux copy at least from the initial
support, but with same compatibility means same style of approach and
will slowly add missing futures.

Things which are differ from Linux, from base support
- Code logic of spi_flash operations erase/read/write
- As these flash ops are bound with BAR, dual_flash which are not
there yet in Linux
- Handling of spi-nor in Linux from high level with MTD, but here with spi_flash
- No in-build MTD stuff

And these differ points, may implement same as Linux in future based
on our u-boot design and need, but will take significant amount of
time.

Apart from adding spi-nor, there is a quite significant tuning
required on whole spi_flash handling code like, handling cmd_sf with
the help of some spi_flash could be include/spi_flash.h or any common
code in drivers/mtd/spi instead of direct calls to spi-uclass [1] this
is to isolate flash handling directly to spi.
And this will also an enhancement for spi-nand addition in future,
where spi_flash will handling spi-nand.c at low level.

[1] http://snag.gy/Pc8GG.jpg

thanks!
-- 
Jagan | openedev.