Re: [PATCH 2/2] spi: bcm-mspi: Add support for Broadcom MSPI driver.

[Florian Fainelli <f.fainelli@xxxxxxxxx>]

On 14/05/15 11:19, Scott Branden wrote:
> Hi Mark,
> 
> On 15-05-14 03:31 AM, Mark Brown wrote:
>> On Wed, May 13, 2015 at 05:19:06PM -0700, Scott Branden wrote:
>>
>>> The purpose of this mspi interface is to connect to NOR flash.  There
>>> are
>>> other SPI interfaces on the devices used to connect to other SPI
>>> devies.  We
>>> don't have any need to support full duplex slaves on this port (NOR
>>> have any
>>> hardware wired this way - pun realized after typing this).
>>
>> Chip vendors often say this sort of thing and then get surprised by what
>> their users choose to do, and even if it only ever gets used with flash
>> all it would take is some new flash command which can use full duplex
>> for something.  Please write the code so it at least tries to handle
>> full duplex operation, if you can't test it fully that's not the end of
>> the world.  It doesn't look like it should be particularly difficult.
>>
> Yes, there is always room for improvements in code.  In this case - it
> really is not worth our time to add code we can't test.  We try to
> deliver code that we can test and actually works.  Yes, if anyone needs
> to use the mspi for full duplex operation code can be added in the
> future - it is software.  This block has gone through many generations
> of our SoCs and has only been used for this purpose - the bootROM boots
> from this SPI only.  It is dedicated for this purpose.
> 
> Also, there are other SPI blocks on the SoC that are used for connect
> other SPI devices.  These SPI blocks are properly designed for
> full-duplex operation.  This mspi block is designed for connecting to
> NOR flash.

This is an implementation detail and architectural choice that is
specific to the Cygnus SoCs where a single MSPI is present, right?

This same MSPI block is instantiated multiple times in BCM7xxx chips to
interface to general purpose SPI slaves, ranging from Ethernet switches
to bluetooth chips etc... those will definitively want full-duplex to be
working.

I would greatly appreciate if some thought to supporting full duplex
transfers was given in this driver drop. If you cannot test that, then
maybe just flag the driver has been half-duplex only for now...

Thank you.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html