Message-ID: <e4351834-5c7d-b751-b3c7-97dce5207783@gmail.com>
Date:   Wed, 30 Jan 2019 08:15:25 +0100
From:   Marek Vasut <marek.vasut@...il.com>
To:     masonccyang@...c.com.tw
Cc:     bbrezillon@...nel.org, broonie@...nel.org,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Simon Horman <horms@...ge.net.au>, juliensu@...c.com.tw,
        linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-spi@...r.kernel.org, sergei.shtylyov@...entembedded.com,
        zhengxunli@...c.com.tw
Subject: Re: [PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller
 driver

On 1/30/19 3:22 AM, masonccyang@...c.com.tw wrote:
> Hi Marek,

Hi,

>> "Marek Vasut" <marek.vasut@...il.com>
>> 2019/01/29 下午 12:45
>>
>> To
>>
>> masonccyang@...c.com.tw,
>>
>> cc
>>
>> bbrezillon@...nel.org, broonie@...nel.org, "Geert Uytterhoeven"
>> <geert+renesas@...der.be>, "Simon Horman" <horms@...ge.net.au>,
>> juliensu@...c.com.tw, linux-kernel@...r.kernel.org, linux-renesas-
>> soc@...r.kernel.org, linux-spi@...r.kernel.org,
>> sergei.shtylyov@...entembedded.com, zhengxunli@...c.com.tw
>>
>> Subject
>>
>> Re: [PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller
> driver
>>
>> On 1/29/19 3:26 AM, masonccyang@...c.com.tw wrote:
>> > Hi Marek,
>>
>> Hi,
>>
>> >> >> "Marek Vasut" <marek.vasut@...il.com>
>> >> >> >> >> > +module_platform_driver(rpc_spi_driver);
>> >> >> >> >>
>> >> >> >> >> RPC is not a SPI controller, it's a SPI and HF controller.
>> >> >> >> >>
>> >> >> >> >> Also, how difficult will it be to add the HF support ?
>> >> >> >> >
>> >> >> >> > One of my customers needs RPC SPI driver for our company's
>> >> >> >> > Octal-Flash,MX25UW51245G.
>> >> >> >> > We don't have HF product and hope you could understanding.
>> >> >> >>
>> >> >> >> I am worried that when we need to add RPC HF support (which is
>> > what all
>> >> >> >> boards but the D3 Draak use), we will have to rewrite the entire
>> > driver
>> >> >> >> and/or convert it to MFD and that would be a tremendous
>> >> > undertaking. I'd
>> >> >> >> prefer to have the driver ready for the HF addition before it's
>> >> > accepted
>> >> >> >> upstream.
>> >> >> >>
>> >> >> >
>> >> >> > I think maybe your concerned would be happened only if HF driver
>> >> > goes with
>> >> >> > spi-mem layer.
>> >> >> >
>> >> >> > A comment for HF from Daniel Fishman. FYR.
>> >> >> >
>> >> >> > https://www.quora.com/What-is-a-hyper-flash-memory-and-how-is-it-
>> >> >> different-from-normal-flash-memory
>> >> >>
>> >> >> I have a decent idea what HF and SPI NOR are, since I wrote the RPC
>> >> >> driver for both HF and SPI mode for U-Boot (as I mentioned earlier).
>> >> >>
>> >> >> The HF in Linux would use the CFI NOR part of MTD framework. My
> concern
>> >> >> is that when we need to add HF support into this driver, this driver
>> >> >> will have to be basically rewritten, since the architecture
> won't allow
>> >> >> for that. I'd like to avoid that, since the majority of Gen3 boards,
>> >> >> expect for the D3 Draak, use RPC in HF mode.
>> >> >
>> >> > FYI~
>> >> >
>> >> > MX25UW51245g(64MByte Octa)                      S26KL512S(64MByte HF)
>> >> >    8 IO                                                  8 IO
>> >> > 200MHz DDR@...v                                   166MHz DDR@...v
>> >> >
>> >> > support Read-while-write                       Not support
>> >> > good for OTA,etc
>> >> > powerful application
>> >>
>> >> What does that mean ?
>> >
>> > I have no idea why would you say "since the majority of Gen3 boards use
>> > RPC in HF mode" ?
>>
>> Well, the H3/M3W/M3N S-X(S) and the H3/M3 ULCB and E3 Ebisu all boot
>> from HF. Only the D3 Draak uses QSPI NOR.
> 
> It's understandable because mx25uw51245g is a new product and it has been
> adopted by Renesas’ Automotive Instrument Cluster RH850/D1M1A MCU.

The aforementioned boards are not going away however. There's too many
users to ignore those.

> We also have patched R-Car's BL for booting from Octa-Flash as bellow log:
> 
> NOTICE:  BL2: R-Car D3 Initial Program Loader(CA53) Rev.0.5.1
> NOTICE:  BL2: PRR is R-Car D3 Ver1.0
> NOTICE:  BL2: Boot device is MXIC_OctaFlash
> NOTICE:  BL2: LCM state is CM
> NOTICE:  BL2: DDR3L-1866(rev.0.02)
> NOTICE:  BL2: QoS is default setting(rev.0.07)
> NOTICE:  BL2: v1.3(release):
> NOTICE:  BL2: Built : 09:56:31, Sep 26 2018
> NOTICE:  BL2: Normal boot
> NOTICE:  BL2: dst=0xe63111f0 src=0x8180000 len=512(0x200)
> NOTICE:  BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800)
> NOTICE:  BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000)
> NOTICE:  BL2: dst=0x50000000 src=0x8640000 len=1048576(0x100000)

This looks like a very old ATF version. Anyway, please submit those
patches upstream, they should be generic.

>> > So far as I know that HF is provided by Cypress only and
>> > any mass production product use the component which is provided by only
>> > one provider
>> > will be a big risk.
>> >
>> > Compare to HF, there are more provider of SPI/Octa could support the
>> > mass production product
>> > as their second provider.
>> >
>> > In addition, from the technical points of view, mx25uw51245g is more
>> > powerful than HF and
>> > good for complicate user application, i.e., OTA and so on.
>>
>> Did you consider protocol overhead too ? I don't think you can compare
>> them just by raw numbers of pins and bus frequency.
>>
>> Note that over-the-air update (if that's what you mean by OTA) is
>> completely separate from the underlying storage device.
> 
> It's key feature of mx25uw51245g supports Read-while-Write capability
> that allows read access from one memory bank while writing to another
> memory bank.

Note that this sales pitch is rather off-topic.

>> > I think customer have more choice for their flash memory component.
>> Note that none of this is really relevant to my concerns above regarding
>> HF support. This driver should be implemented as MFD driver and the SPI
>> part should use the MFD core part , just like the future HF part.
>>
> 
> Even though they are both internal NOR memory chip, is it a trend of Kernel
> for the different HW controller and protocol ?

I'm not sure I understand the question, but the HF behaves like a CFI
NOR, that's why it should be operated via the CFI part of the MTD
framework. The SPI NOR behaves, well, like a SPI NOR and so should be
operated via the SPI NOR part of the MTD framework.

However, a lot of the code operating the RPC is common for the HF and
SPI NOR modes, which is why that part should be a MFD driver or some
common core driver.

> What about others,i.e., raw-NAND and spi-NAND ?

I don't think the RPC supports those, does it ?

> oh, a little bit leaving the topic !
> anyway, nice to talk to you about this R-Car Gen3 RPC driver.
[...]

-- 
Best regards,
Marek Vasut

Powered by blists - more mailing lists