[RFC 0/2] spi: aspeed: SPI1 mode control driver enabling sysfs control

[Kun Yi]

Hi Andrew,

One question I have though: I think pinmux/pinctrl driver is supposed to be
a boot time static pin configure module and parses DT and configures
accordingly. Is it possible to use pinmux to dynamically modify the pin
states? This is essentially the problem I'm trying to deal with.

Thanks,
Kun

On Sun, Oct 23, 2016 at 8:05 PM, Andrew Jeffery <andrew at aj.id.au> wrote:

> Hi Kun,
>
> On Fri, 2016-10-21 at 17:45 -0700, Kun Yi wrote:
> > Hello,
> >
> > I'm looking for feedback on a simple Aspeed SPI1 mode control driver
> that does two things mainly:
> > 1. Expose a sysfs interface for userland control of SPI1 interface.
> > 2. Optionally override the SPI1 mode at probe if "start_mode" is
> configured in
> >    device tree.
> >
> > Aspeed 24XX/25XX support three interface modes for their SPI1 interface,
> > which can be configured via HW strap register. In the typical case of
> connecting
> > a host flash chip SPI1 interface:
> > - SPI master mode makes BMC the master to the host SPI flash
> > - SPI pass-through mode make whichever external SPI interface connected
> to SYSSPI
> >   be the master
> > - There are also "disable" and "debug" modes. Aspeed 25XX specified the
> debug
> >   mode is reserved though.
> >
> > In particular, SPI pass-through mode would enable an external SPI master
> to
> > directly program host SPI chip and possibly serve as an alternative way
> to LPC
> > for host CPU accessing SPI flash. I think by providing a sysfs handle,
> userspace
> > applications can have a flexible way to mux host SPI flash ownership
> between
> > BMC/external on the fly.
> >
> > Overriding the SPI mode at probe time can be useful to make sure
> 2500-smc flash
> > controller always identifies the flash chip and create /dev/mtd files
> correctly.
> >
> > I wrote the driver as a standalone misc driver for the ease of initial
> implementation.
> > There are other options such as merging the functionality into the SMC
> driver
> > itself, possibly enabled by optional device tree arguments/nodes, but I
> just want to
> > send the patches out first to gather comments on perceived usefulness of
> > the feature and how you think the driver should be constructed.
>
> At least one issue I have with the implementation is that the strap
> register is currently "owned" by the pinctrl driver, but the patch as
> it stands has no interaction with this subsystem. Arguably the pinctrl
> driver is where this should be implemented, as it encapsulates pinmux
> whose aim is to manage the functionality made available on the SoC's
> pins.
>
> Currently the pinctrl driver treats the strapping register as read-
> only. That should probably change in light of what you're trying to do
> here, though only to the extent of allowing the SPI mode switch.
>
> Cheers,
>
> Andrew




-- 
Regards,
Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161024/f3a692b6/attachment-0001.html>