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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 15-05-14 11:28 AM, Florian Fainelli wrote:
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.

Hi Florian,
Yes, we can flag that - but we have no understanding of how the block operates in this mode. It would be great if your team could add the necessary full duplex support in a patch enhancement to the driver?

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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux