[U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

[Jagan Teki]

On Mon, Sep 3, 2018 at 12:46 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> On 09/02/2018 08:41 PM, Jagan Teki wrote:
>> On Sun, Sep 2, 2018 at 11:56 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>>> On 09/02/2018 08:00 PM, Jagan Teki wrote:
>>>> On Sun, Aug 26, 2018 at 4:07 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>>>>> On 08/26/2018 08:45 AM, Jagan Teki wrote:
>>>>>> On Sat, Aug 25, 2018 at 11:04 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>>>>>>> Add DM support to the SH QSPI driver while retaining non-DM support.
>>>>>>> The later is required as this driver is used in SPL which has a size
>>>>>>> limitation of 16 kiB.
>>>>>>>
>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas at gmail.com>
>>>>>>> Cc: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>>>>>>> ---
>>>>>>>  drivers/spi/sh_qspi.c | 215 +++++++++++++++++++++++++++++++++++---------------
>>>>>>>  1 file changed, 150 insertions(+), 65 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
>>>>>>> index e9123e2c39..64dfd748d6 100644
>>>>>>> --- a/drivers/spi/sh_qspi.c
>>>>>>> +++ b/drivers/spi/sh_qspi.c
>>>>>>> @@ -67,15 +67,12 @@ struct sh_qspi_regs {
>>>>>>>  };
>>>>>>>
>>>>>>>  struct sh_qspi_slave {
>>>>>>> +#ifndef CONFIG_DM_SPI
>>>>>>
>>>>>> We are trying to drop non-dm code as much as possible (with
>>>>>> MIGRATION.txt policy), how about adding PLTADATA or spi read glue code
>>>>>> or any other?
>>>>>
>>>>> The SPL on that board (silk) has 16 kiB limit, right now I am at 15500 B
>>>>> with gcc 7.x already, adding any more overhead will make it overflow. So
>>>>> while I'd like to have it all fancy DM and stuff, it's not possible.
>>>>
>>>> How about having simple glue code for SPL, since it anyway used for
>>>> read in real?
>>>
>>> I'd prefer to use the same driver for both SPL and U-Boot instead of
>>> hacking stuff up. Not sure what exactly you mean by "glue" though.
>>
>> Something that bypass spi stack and read the flash with local code,
>> this usually suited for low SRAM size like silk example
>> spl_spi_sunxi.c
>
> But I am not _that_ cripplingly low, so I'd prefer to stick to a
> standard solution instead of some hack.

OK, is this a fix or shall I take it for next?