RE: [PATCH v2 0/6] spi: Add Renesas SPIBSC controller

[Chris Brandt <Chris.Brandt@xxxxxxxxxxx>]

Hello

On Mon, Dec 16, 2019, Sergei Shtylyov wrote:
> > As a side note, there is another HW block in Renesas that does the same
> > thing as the SPI-BSC that they use in the MCU devices. That one they
> 
>    MCU?
Yup.
  But...it has no significance to this discussion though :)


> > When I first saw the series on the mailing list, my plan was to just wait
> > and then add RZ/A1 and RZ/A2 support. But....it looks like it all died.
> 
>    No. :-) It was worked on during all these months... I just finally decided
> to stop, take a deep breath, and post what patches I had accumulated, without
> the whole driver suite working first... I'm sorry it took so long....

So at the moment, there is nothing yet for me to 'try' on the RZ/A series, correct?


> > My understanding is that HyperFlash uses standard CFI commands, so all
> 
>    The CFI command set driver needed some changes too (e.g. using the status
> register to determine if a command is done).

So the existing MTD-SPI layer knows how to talk to SPI devices.
And, you've fixed up the existing CFI layer to talk to HyperFlash devices.
But, you do not want these MTD layer to talk directly to a Renesas HW driver?
You want to put another software layer in between?


I'm guessing that from this statement....

> >>> library that you are proposing have a very different API than just
> >>> 'send bytes' and 'receive bytes'?
> >>
> >>    There's "prepare" and "transfer" APIs and also "direct map read" API.
> 
>   The 1st one prepares the values to be written in either SPI mode or direct
> read mode registers. Then you can call "transfer" or "direct mao read" which
> would write out the register values into either set...

...that you want more control of the data stream being passed to the RPC-IF driver.
Correct??

It all keeps sounding complicated, unless I'm just not understanding the code
you are trying to implement.


Chris