<div dir="ltr">Hi Joel, thanks for commenting!<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 23, 2016 at 6:59 PM, Joel Stanley <span dir="ltr"><<a href="mailto:joel@jms.id.au" target="_blank">joel@jms.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hell Kun,<br>
<span class="m_-5664281760833887805m_-1177382596902210427gmail-"><br>
On Sat, Oct 22, 2016 at 11:15 AM, Kun Yi <<a href="mailto:kunyi@google.com" target="_blank">kunyi@google.com</a>> wrote:<br>
> Hello,<br>
><br>
> I'm looking for feedback on a simple Aspeed SPI1 mode control driver that does two things mainly:<br>
> 1. Expose a sysfs interface for userland control of SPI1 interface.<br>
> 2. Optionally override the SPI1 mode at probe if "start_mode" is configured in<br>
>    device tree.<br>
<br>
</span>Why do you plan to override the mode at boot time? Is this for firmware updates?<br></blockquote><div><br></div><div>More important here is the ability to change the SPI mode at *run time*. One use case is for platforms without eSPI/LPC support. When host CPU is booting and BIOS needs to read SPI chip, the most straightforward way for BMC to allow host access to the SPI chip is to toggle to SPI pass-through mode. Thus the core purpose of the driver is for enabling SPI pass-through mode on demand.<br></div><div><br></div><div>Overriding the SPI mode at boot time is only to make sure the host SPI chip can be recognized correctly by the SMC driver. Because currently pinctrl treats HW strap as read-only, mis-configured HW strap pins will cause SMC driver to fail reading SPI flash ID and not register it in MTD subsystem, and there is no easy way to probe again later. Though enabling pinctrl to set HW strap register might be a better approach as Andrew mentioned.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We plan to move away from having the NOR flash accessible from both<br>
the host and the BMC for all platforms. There's no good way to<br>
indicate ownership, and the Linux mtd subsystem does not have a good<br>
way of relinquishing nor reestablishing control. For instance, there's<br>
no way to "unmount" the MTD device, and there's no way to force a<br>
re-scan of partitions if you modify the layout.<br></blockquote><div><br></div><div>I saw some discussions related on IRC but wasn't clear about the details. Could you elaborate a little? Do you plan to only allow BMC daemons to access both host/BMC NOR flashes?</div><div><br></div><div>I got the impression that mtd will stick around for now. Do we have a time frame for deprecating that?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think there are some issues with your approach that break<br>
pinctrl/pinmux that Andrew will highlight.<br></blockquote><div><br></div><div>Sure I will reply to those in Andrew's email.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
<br>
Joel<br>
<span class="m_-5664281760833887805m_-1177382596902210427gmail-"><br>
><br>
> Aspeed 24XX/25XX support three interface modes for their SPI1 interface,<br>
> which can be configured via HW strap register. In the typical case of connecting<br>
> a host flash chip SPI1 interface:<br>
> - SPI master mode makes BMC the master to the host SPI flash<br>
> - SPI pass-through mode make whichever external SPI interface connected to SYSSPI<br>
>   be the master<br>
> - There are also "disable" and "debug" modes. Aspeed 25XX specified the debug<br>
>   mode is reserved though.<br>
><br>
> In particular, SPI pass-through mode would enable an external SPI master to<br>
> directly program host SPI chip and possibly serve as an alternative way to LPC<br>
> for host CPU accessing SPI flash. I think by providing a sysfs handle, userspace<br>
> applications can have a flexible way to mux host SPI flash ownership between<br>
> BMC/external on the fly.<br>
><br>
> Overriding the SPI mode at probe time can be useful to make sure 2500-smc flash<br>
> controller always identifies the flash chip and create /dev/mtd files correctly.<br>
><br>
> I wrote the driver as a standalone misc driver for the ease of initial implementation.<br>
> There are other options such as merging the functionality into the SMC driver<br>
> itself, possibly enabled by optional device tree arguments/nodes, but I just want to<br>
> send the patches out first to gather comments on perceived usefulness of<br>
> the feature and how you think the driver should be constructed.<br>
><br>
> Feedback greatly appreciated!<br>
><br>
> Regards,<br>
> Kun<br>
><br>
</span>> ______________________________<wbr>_________________<br>
> openbmc mailing list<br>
> <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>
> <a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/listi<wbr>nfo/openbmc</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-5664281760833887805m_-1177382596902210427gmail_signature"><div dir="ltr">Regards,<div>Kun</div></div></div>
</div></div></div>