mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: masonccyang@mxic.com.tw
Cc: bbrezillon@kernel.org, broonie@kernel.org,
	devicetree@vger.kernel.org,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Simon Horman <horms@verge.net.au>,
	juliensu@mxic.com.tw, lee.jones@linaro.org,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-spi@vger.kernel.org, marek.vasut@gmail.com,
	mark.rutland@arm.com, robh+dt@kernel.org, zhengxunli@mxic.com.tw
Subject: Re: [PATCH v9 2/3] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
Date: Thu, 4 Apr 2019 21:56:19 +0300	[thread overview]
Message-ID: <7467d695-8922-16b2-03d4-fb4bbdda125a@cogentembedded.com> (raw)
In-Reply-To: <OFAEA16021.C7F7B095-ON482583D1.0031A13D-482583D1.00335085@mxic.com.tw>

Hello!

On 04/03/2019 12:20 PM, masonccyang@mxic.com.tw wrote:

>> >> > +static void rpc_spi_mem_set_prep_op_cfg(struct spi_device *spi,
>> >> > +               const struct spi_mem_op *op,
>> >> > +               u64 *offs, size_t *len)
>> >> > +{
>> >> > +   struct rpc_spi *rpc = spi_controller_get_devdata(spi->controller);
>> >> > +
>> >> > +   rpc->cmd = RPC_SMCMR_CMD(op->cmd.opcode);
>> >> > +   rpc->smenr = RPC_SMENR_CDE |
>> >> > +           RPC_SMENR_CDB(ilog2(op->cmd.buswidth));
>> >> > +   rpc->totalxferlen = 1;
>> >> > +   rpc->xfer_dir = SPI_MEM_NO_DATA;
>> >> > +   rpc->xferlen = 0;
>> >> > +   rpc->addr = 0;
>> >> > +
>> >> > +   if (op->addr.nbytes) {
>> >> > +      rpc->smenr |= RPC_SMENR_ADB(ilog2(op->addr.buswidth));
>> >> > +      if (op->addr.nbytes == 4)
>> >> > +         rpc->smenr |= RPC_SMENR_ADE(0xf);
>> >> > +      else
>> >> > +         rpc->smenr |= RPC_SMENR_ADE(0x7);
>> >> > +
>> >> > +      if (offs && len)
>> >> > +         rpc->addr = *offs;
>> >> > +      else
>> >> > +         rpc->addr = op->addr.val;
>> >> > +      rpc->totalxferlen += op->addr.nbytes;
>> >> > +   }
>> >> > +
>> >> > +   if (op->dummy.nbytes) {
>> >> > +      rpc->smenr |= RPC_SMENR_DME;
>> >> > +      rpc->dummy = RPC_SMDMCR_DMCYC(op->dummy.nbytes);
>> >>
>> >>    So you haven't fixed this bug? I repeat, the driver doesn't work right
>> >> w/o this fixed!
>> >
>> > Do you mean
>> >
>> > rpc->dummy = RPC_SMDMCR_DMCYC(op->dummy.nbytes) * 8;   ?
>>
>>    Yes. Or some other code that amounts to it.

   Oops, I wasn't attentive enough, I was proposing:

	rpc->dummy = RPC_SMDMCR_DMCYC(op->dummy.nbytes * 8);

> why not setting "op->dummy.nbytes = 7" from spi-nor.c protocol layer ?

   We want 8 dummy clocks, not 8 dummy bytes. And if you'd looked into
spi_nor_read_sfdp(), you'd have seen that it requests 8 dummy clocks already.

> driver may check device ID or something else to setup op->dummy.nbytes.

   The RDSFDP command is not chip specific.

> I think it is not a good idea to *8 in spi host driver.

>> > What is your flash part number?
>>
>>    Spansion/Cypress S25FS512S. The datasheet says there must be 8 dummy cycles
>> for the RSFDP command...
>>
>> > The problem you found is in 1 bit or 4 bits width ?
>>
>>    1-bit, I think.
>>
>> >>
>> >> [...]
>> >> > +static ssize_t rpc_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
>> >> > +                   u64 offs, size_t len, void *buf)
>> >> > +{
>> >> > +   struct rpc_spi *rpc =
>> >> > +         spi_controller_get_devdata(desc->mem->spi->controller);
>> >> > +   int ret;
>> >> > +
>> >> > +   if (offs + desc->info.offset + len > U32_MAX)
>> >> > +      return -EINVAL;
>> >> > +
>> >> > +   if (len > 0x4000000)
>> >> > +      len = 0x4000000;
>> >>
>> >>    Ugh...
>> >
>> > by mtd->size ?
>>
>>   That'd be better, yes.
>>
> 
> Oops, it seems hard to get mtd->size info. from spi_mem_dirmap,

   It's in desc->info.length, no?

> I would like to keep 0x4000000.

   I'm seeing Boris in the CC's... Boris, is it legitimate to limit
a single dirmap read by the memory "window" size? Or should we try to 
serve any valid transfer length?

>> >> > +
>> >> > +   ret = rpc_spi_set_freq(rpc, desc->mem->spi->max_speed_hz);
>> >> > +   if (ret)
>> >> > +      return ret;
>> >> > +
>> >> > +   rpc_spi_mem_set_prep_op_cfg(desc->mem->spi,
>> >> > +                &desc->info.op_tmpl, &offs, &len);
>> >> > +
>> >> > +   regmap_update_bits(rpc->regmap, RPC_CMNCR, RPC_CMNCR_MD, 0);
>> >> > +   regmap_write(rpc->regmap, RPC_DRCR, RPC_DRCR_RBURST(32) |
>> >> > +           RPC_DRCR_RBE);
>> >> > +
>> >> > +   regmap_write(rpc->regmap, RPC_DRCMR, rpc->cmd);
>> >> > +   regmap_write(rpc->regmap, RPC_DREAR, RPC_DREAR_EAC(1));
>> >>
>> >>    So you're not even trying to support flashes larger than the
>> read dirmap?
>> >> Now I don't think it's acceptable (and I have rewritten this code
>> internally).
>> >
>> > what about the size comes form mtd->size ?
>>
>>    I'm not talking about size here; we should use the full address.
>> I'm attaching
>> my patch...
> 
> okay,got it!
> what about just
> -      regmap_write(rpc->mfd->regmap, RPC_DREAR, RPC_DREAR_EAC(1));
> +      regmap_write(rpc->mfd->regmap, RPC_DREAR,
> +                   RPC_DREAR_EAV(offs >> 25) | RPC_DREAR_EAC(1));
> 
> because only > 64MByte size make RPC_DREAR_EAV() work.

   Boris, what's your opinion on this?
   Note that for the write dirmap we have just 256-byte buffer (reusing
the read cache). Is it legitimate to limit the served length to 256 bytes?

> thanks & best regards,
> Mason

MBR, Sergei

  parent reply	other threads:[~2019-04-04 18:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29  8:20 [PATCH v9 0/3] mfd: Add Renesas R-Car Gen3 RPC-IF MFD driver Mason Yang
2019-03-29  8:20 ` [PATCH v9 1/3] mfd: Add Renesas R-Car Gen3 RPC-IF MFD controller driver Mason Yang
2019-03-29 10:43   ` Marek Vasut
2019-03-29 15:12   ` Sergei Shtylyov
2019-03-29  8:20 ` [PATCH v9 2/3] spi: Add Renesas R-Car Gen3 RPC-IF SPI " Mason Yang
2019-03-29 10:44   ` Marek Vasut
2019-03-29 15:52   ` Sergei Shtylyov
     [not found]     ` <OF7F1B534F.B934A9FE-ON482583D0.001DC618-482583D0.001FE84B@mxic.com.tw>
2019-04-02 20:10       ` Sergei Shtylyov
     [not found]         ` <OFAEA16021.C7F7B095-ON482583D1.0031A13D-482583D1.00335085@mxic.com.tw>
2019-04-04 18:56           ` Sergei Shtylyov [this message]
2019-04-04 19:12             ` Boris Brezillon
2019-04-06 19:59               ` Sergei Shtylyov
2019-04-09 11:20           ` Sergei Shtylyov
2019-04-10 19:47             ` Sergei Shtylyov
2019-04-09 20:07   ` Sergei Shtylyov
     [not found]     ` <OFC7F0028A.CFF6BD04-ON482583D8.00084FA1-482583D8.0008985F@mxic.com.tw>
2019-04-10  6:27       ` Marek Vasut
     [not found]         ` <OF75EDBF48.5C308F1B-ON482583D8.0027A537-482583D8.002C0A64@mxic.com.tw>
2019-04-10  8:03           ` Marek Vasut
2019-04-10  8:11           ` Boris Brezillon
2019-04-10 17:53           ` Sergei Shtylyov
2019-04-13 16:38   ` Sergei Shtylyov
2019-04-13 16:39     ` Sergei Shtylyov
     [not found]       ` <OF82CE76E9.E6395EF7-ON482583DD.000E37D7-482583DD.000E5077@mxic.com.tw>
2019-04-17 18:44         ` Sergei Shtylyov
     [not found]           ` <OF4ABCC306.B053BA23-ON482583E0.000F480C-482583E0.000FAD4A@mxic.com.tw>
2019-04-18 19:43             ` Sergei Shtylyov
     [not found]               ` <OF58AAFF49.C4593DEB-ON482583E1.001D551E-482583E1.001F089D@LocalDomain>
     [not found]                 ` <OFE74649D4.F69BB5EF-ON482583E1.0033F73F-482583E1.00344ED2@mxic.com.tw>
2019-04-22 16:44                   ` Sergei Shtylyov
     [not found]               ` <OF58AAFF49.C4593DEB-ON482583E1.001D551E-482583E1.001F089D@mxic.com.tw>
2019-04-23  7:29                 ` Geert Uytterhoeven
2019-05-14 19:06                 ` Sergei Shtylyov
2019-05-14 19:13                   ` Sergei Shtylyov
2019-03-29  8:20 ` [PATCH v9 3/3] dt-bindings: mfd: Document Renesas R-Car Gen3 RPC-IF controller bindings Mason Yang
2019-03-29 10:45   ` Marek Vasut
2019-03-29 10:49   ` Sergei Shtylyov

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=7467d695-8922-16b2-03d4-fb4bbdda125a@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=bbrezillon@kernel.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=horms@verge.net.au \
    --cc=juliensu@mxic.com.tw \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=masonccyang@mxic.com.tw \
    --cc=robh+dt@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®