linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Naga Sureshkumar Relli <nagasure@xilinx.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>,
	naga suresh kumar <nagasureshkumarrelli@gmail.com>
Cc: "cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
	"Marek Vašut" <marek.vasut@gmail.com>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Brian Norris" <computersforpeace@gmail.com>,
	"boris.brezillon@free-electrons.com"
	<boris.brezillon@free-electrons.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: RE: [RFC PATCH 0/5] RFC for Zynq QSPI
Date: Tue, 18 Sep 2018 08:58:14 +0000	[thread overview]
Message-ID: <MWHPR02MB2623014F6F8E7B8F78952834AF1D0@MWHPR02MB2623.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20180918091712.2f97db80@bbrezillon>

Hi Boris,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Tuesday, September 18, 2018 12:47 PM
> To: naga suresh kumar <nagasureshkumarrelli@gmail.com>
> Cc: Naga Sureshkumar Relli <nagasure@xilinx.com>; cyrille.pitchen@wedev4u.fr; Marek
> Vašut <marek.vasut@gmail.com>; David Woodhouse <dwmw2@infradead.org>; Brian
> Norris <computersforpeace@gmail.com>; boris.brezillon@free-electrons.com; linux-
> mtd@lists.infradead.org
> Subject: Re: [RFC PATCH 0/5] RFC for Zynq QSPI
> 
> Hi Naga,
> 
> On Tue, 18 Sep 2018 11:26:05 +0530
> naga suresh kumar <nagasureshkumarrelli@gmail.com> wrote:
> 
> > Hi,
> >
> > Please see my reply inline by prefacing my name, currently i am facing
> > issues with my outlook. the reply looks not good but please don't mind.
> 
> I do mind. Please find a way to fix that, 'cause I'm pretty sure others will soon complain about
> that too.
Its working now.
> 
> 
> > > > As i said, it needs tweaking the mtd->size and spi read/write addresses.
> > >
> > > Can you elaborate a bit on why you think this is needed? Did you
> > > look at [1]? Maybe it will prevent us from exposing the flash size
> > > at the spi-mem level.
> > > [naga]: some example snippet below
> > >
> > > spi_nor_read () {
> > >
> > >    if (nor->isparallel == 1)
> > >
> > >    {
> > >
> > >       offset /= 2; //byte stripping will happen here
> > >
> > >        nor->spi->master->flags |= SPI_DATA_STRIPE;
> > >
> > >        //By setting this flag even bits of data word located in
> > > lower memory and odd are in upper memory
> > >
> > >    }
> > >
> > >    if (nor->isstacked == 1) {
> > >
> > >      stack_shift = 1;
> > >
> > >      if (offset >= (mtd->size / 2)) {
> > >
> > >      offset = offset - (mtd->size / 2);
> > >
> > >      nor->spi->master->flags |= SPI_MASTER_U_PAGE;
> > >
> > >      //We can access Upper memory or lower memory, by setting this
> > > flag in controller.
> > >
> > >   } else {
> > >
> > >         nor->spi->master->flags &= ~SPI_MASTER_U_PAGE;
> > >
> > >   }
> > >
> > >  }
> > >
> > > same for spi_nor_write() also.
> 
> Let's put the stacked and parallel support on the side for now and focus on single die/chip
> support. Will find a clean way to handle that afterwards.
Ok
> 
> > >
> > > Also in both dual parallel and stacked mode mtd->size should be sum
> > > of both flash device sizes
> 
> Yes, but this information should stay at the spi-nor/mtd level.
> 
> > >
> > > also status register read will change, it needs status from both devices.
> > > like that some changes
> > >
> > > will be needed in core.
> 
> Which is why this needs to be handled in spi-nor.c. The spi-nor core needs to know about the
> parallel/stack setup and handle it differently (read both status bytes, read both IDs, ...).
Ok
> 
> > > > Can somebody share your thoughts on this(Adding Zynq QSPI Dual
> > > > parallel
> > > and
> > > > stacked)?
> > >
> > > I always have a hard time with this naming. I guess stacked is when
> > > you have 2 chips sharing the same I/O bus, and parallel is when you
> > > have 2 chips with one taking all of the I/O and the other taking the
> > > other half. Is that correct?
> > > [naga]: Yes, you are correct, i have attached the diagrams for these mode.
> > >
> > > In parallel mode, with the help of controller STRIPE feature, even
> > > bits of
> > >
> > > data words are located in lower memory and odd bits are located in
> > > upper memory.
> > >
> > > Data management will be taken care by controller in both modes
> 
> Ok. I need to think about it a bit more. In the meantime, I recommend that you submit a
> version of the driver that does not support parallel and stacked modes.
Ok sure.

Thanks,
Naga Sureshkumar Relli.
> 
> Regards,
> 
> Boris

  reply	other threads:[~2018-09-18  8:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-23 12:21 [RFC PATCH 0/5] RFC for Zynq QSPI Naga Sureshkumar Relli
2018-03-23 12:21 ` [RFC PATCH 1/5] spi: Add support for Zynq qspi controller Naga Sureshkumar Relli
2018-03-23 12:21 ` [RFC PATCH 2/5] mtd: spi-nor: Add support for Zynq QSPI controller Naga Sureshkumar Relli
2018-03-23 12:22 ` [RFC PATCH 3/5] mtd: spi-nor: Add Dual Parallel and Stacked support for Zynq QSPI Naga Sureshkumar Relli
2018-03-23 12:22 ` [RFC PATCH 4/5] spi: Add PM Support for Zynq QSPI controller Naga Sureshkumar Relli
2018-03-23 12:22 ` [RFC PATCH 5/5] devicetree: Add devicetree bindings documentation for Naga Sureshkumar Relli
2018-03-23 14:47   ` Miquel Raynal
2018-03-23 12:52 ` [RFC PATCH 0/5] RFC for Zynq QSPI Marek Vasut
2018-03-23 13:39   ` Naga Sureshkumar Relli
2018-04-16  7:25 ` Naga Sureshkumar Relli
     [not found]   ` <CALgLF9K=rZxVx_QXvV_LH3OhidTcguZ=K=p=Lf9AfFbk4H+8Zw@mail.gmail.com>
2018-09-17 15:05     ` Boris Brezillon
2018-09-17 15:07       ` Boris Brezillon
     [not found]       ` <CALgLF9JVweEcEm6L33HaHp4HtXhmsZL7J5FDe8+O11i0Q1nukg@mail.gmail.com>
2018-09-18  7:17         ` Boris Brezillon
2018-09-18  8:58           ` Naga Sureshkumar Relli [this message]
2019-06-26  9:53           ` naga suresh kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR02MB2623014F6F8E7B8F78952834AF1D0@MWHPR02MB2623.namprd02.prod.outlook.com \
    --to=nagasure@xilinx.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=nagasureshkumarrelli@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).