[U-Boot] [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Thu, Nov 23, 2017 at 1:00 PM, Siva Durga Prasad Paladugu
<sivadur at xilinx.com> wrote:
> Hi Jagan,
>
>> -----Original Message-----
>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>> Sent: Wednesday, November 01, 2017 2:54 PM
>> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>> Cc: u-boot at lists.denx.de; Liam Beguin <liambeguin at gmail.com>
>> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
>> ZynqMP qspi driver
>>
>> On Tue, Oct 31, 2017 at 6:33 PM, Siva Durga Prasad Paladugu
>> <sivadur at xilinx.com> wrote:
>> > Hi Jagan,
>> >
>> >> -----Original Message-----
>> >> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>> >> Sent: Tuesday, October 31, 2017 3:01 PM
>> >> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>> >> Cc: u-boot at lists.denx.de; Liam Beguin <liambeguin at gmail.com>
>> >> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
>> >> ZynqMP qspi driver
>> >>
>> >> On Tue, Oct 31, 2017 at 2:50 PM, Siva Durga Prasad Paladugu
>> >> <sivadur at xilinx.com> wrote:
>> >> > Hi Jagan,
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>> >> >> Sent: Tuesday, October 31, 2017 2:40 PM
>> >> >> To: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>> >> >> Cc: u-boot at lists.denx.de; Liam Beguin <liambeguin at gmail.com>;
>> Siva
>> >> >> Durga Prasad Paladugu <sivadur at xilinx.com>
>> >> >> Subject: Re: [UBOOT PATCH 1/2] spi: zynqmp_qspi: Add support for
>> >> >> ZynqMP qspi driver
>> >> >>
>> >> >> On Tue, Oct 24, 2017 at 3:33 PM, Siva Durga Prasad Paladugu
>> >> >> <siva.durga.paladugu at xilinx.com> wrote:
>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>> >> >> > is responsible for communicating with qspi flash devices.
>> >> >>
>> >> >> Legacy question, what is your approach for dual memory setup? Did
>> >> >> you write another flash driver?
>> >> > No
>> >> >
>> >> >>
>> >> >> I see this driver use dual flash slave 'option' which doesn't live
>> >> >> on spi side anymore. better to have a discussion on approach and
>> >> >> will
>> >> review further.
>> >> >
>> >> > I can see that spi_flash.c(driver/mtd/spi/spi_flash.c) has the
>> >> > option for
>> >> dual flash under CONFIG_SF_DUAL_FLASH.
>> >> > I thought of using the same. Isn't it takes care of dual flash case?
>> >> > Please let me know if you any further thoughts on how it has to be
>> >> handled.
>> >>
>> >> Dual flash case should take for generic spi drivers, if you strictly
>> >> want your controller to handle flash device rather !flashes then we
>> >> need to write the driver at flash side. ie why I asked as first question.
>> >
>> > Does this mean that drivers that are present in drivers/spi/ should
>> > work for both flashes and !flashes. And the drivers that only targets
>> > flash devices should be in different place and doesn’t use Dual flash
>> functionality under CONFIG_SF_DUAL_FLASH? Or it can still use this.
>>
>> Sorry, you understand it reverse or may be I'm not clear.
>>
>> drivers at drivers/spi can handle only generic slaves which includes spi-flash
>> and some spi-flash(spi-nor) controllers which only deals with spi-flash
>> slaves which can be part of drivers/mtd/spi. Since your driver is categorized
>> as spi-nor controller(in above notes from you) it's better to write driver at
>> drivers/mtd/spi side.
>
> No, the controller is meant to handle other slaves as well along with spi-nor.
> Also for now, we are targeting single spi flash. So, keeping the driver here
> should just be fine. Please let me know if you need any further info.

remember if driver sits here, then we can't extent your controller
specific functions.

And rebase your patches and set it again.