All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"juliensu@mxic.com.tw" <juliensu@mxic.com.tw>,
	"zhengxunli@mxic.com.tw" <zhengxunli@mxic.com.tw>,
	"masonccyang@mxic.com.tw" <masonccyang@mxic.com.tw>
Subject: Re: Query: spi-nor: dummy buswidth calculation
Date: Tue, 4 Sep 2018 14:30:28 +0200	[thread overview]
Message-ID: <20180904143028.4629fe10@bbrezillon> (raw)
In-Reply-To: <VI1PR04MB1038E10EBE458DD72A1070C499030@VI1PR04MB1038.eurprd04.prod.outlook.com>

+Macronix team

On Tue, 4 Sep 2018 09:28:11 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:

> Hi Boris,
> 
> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
> 
> In func m25p80_read(), dummy.buswidth is being assigned as
> +       op.dummy.buswidth = op.addr.buswidth;
> 
> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
> 
> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.

Interesting. Macronix is also working on octo-mode support. I think we
should sync instead of duplicating the work.

> 
> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
> -       op.dummy.buswidth = op.addr.buswidth;
> +       op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);

Regarding this particular aspect, I just followed what was done before
the conversion to spi_mem_exec_op(). Maybe it was not correct though.

Regards,

Boris

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
Cc: "juliensu@mxic.com.tw" <juliensu@mxic.com.tw>,
	"zhengxunli@mxic.com.tw" <zhengxunli@mxic.com.tw>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"masonccyang@mxic.com.tw" <masonccyang@mxic.com.tw>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>
Subject: Re: Query: spi-nor: dummy buswidth calculation
Date: Tue, 4 Sep 2018 14:30:28 +0200	[thread overview]
Message-ID: <20180904143028.4629fe10@bbrezillon> (raw)
In-Reply-To: <VI1PR04MB1038E10EBE458DD72A1070C499030@VI1PR04MB1038.eurprd04.prod.outlook.com>

+Macronix team

On Tue, 4 Sep 2018 09:28:11 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:

> Hi Boris,
> 
> I have query regarding dummy bus width calculation for the read commands, added in the patch series [1]
> 
> In func m25p80_read(), dummy.buswidth is being assigned as
> +       op.dummy.buswidth = op.addr.buswidth;
> 
> Above, buswidth for dummy commands are being assigned and are marked equal to the buswidth of the address command.
> This is true for case when we are doing operation in 1-4-4 or 1-2-2 protocol where data as well as address are running on same data lines and having same buswidth.
> 
> I am adding support of octal commands in framework and for this needs to add support for 1-1-8 protocol for Micron flash MT35XU512ABA1G12.
> For octal command, 7Ch, flash is sending data and the dummy on the 8 data lines and address on 1 data line.

Interesting. Macronix is also working on octo-mode support. I think we
should sync instead of duplicating the work.

> 
> If I do below code change, then I am getting correct data else there is data corruption only in the first byte read.
> -       op.dummy.buswidth = op.addr.buswidth;
> +       op.dummy.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);

Regarding this particular aspect, I just followed what was done before
the conversion to spi_mem_exec_op(). Maybe it was not correct though.

Regards,

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2018-09-04 12:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04  9:28 Query: spi-nor: dummy buswidth calculation Yogesh Narayan Gaur
2018-09-04  9:28 ` Yogesh Narayan Gaur
2018-09-04 12:30 ` Boris Brezillon [this message]
2018-09-04 12:30   ` Boris Brezillon
2018-09-04 13:10   ` Cyrille Pitchen
2018-09-04 13:10     ` Cyrille Pitchen

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=20180904143028.4629fe10@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=masonccyang@mxic.com.tw \
    --cc=yogeshnarayan.gaur@nxp.com \
    --cc=zhengxunli@mxic.com.tw \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.