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

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut