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

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Chris Brandt <Chris.Brandt@renesas.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>
Cc: "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	Mason Yang <masonccyang@mxic.com.tw>
Subject: Re: [PATCH v2 0/6] spi: Add Renesas SPIBSC controller
Date: Tue, 17 Dec 2019 22:30:02 +0300	[thread overview]
Message-ID: <bb630141-021c-5618-f266-b98b29956fa8@cogentembedded.com> (raw)
In-Reply-To: <TY1PR01MB1562B9EB96818DCA507079808A510@TY1PR01MB1562.jpnprd01.prod.outlook.com>

Hello!

On 12/17/2019 01:21 AM, Chris Brandt 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 :)

   But what does the acronym mean?

>>> 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?

   Why, I can send you a working version of the SPI driver, and even HF one if you're
interested.

>>> 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.

   SPI-NOR does it with a help of drivers/spi/spi-mem.c... As for the HyperFlash,
it needs a HyperBus driver (that I have a working patch for)...

> And, you've fixed up the existing CFI layer to talk to HyperFlash evices.

   Mostly Boris B. did it... :-)

> But, you do not want these MTD layer to talk directly to a Renesas HW driver?

   Yes, because the SPI-NOR and HyperBus have different driver APIs.

> You want to put another software layer in between?

   Yes.

> 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.

   Well, it reflects the fact that the "SPI mode" and "direct read" register sets
are largely identical. The "preparation" stage sets up the register values, the 
other stages use that data to set up the real register sets and then do the
needed transfers...

> Chris

MBR, Sergei