[PATCH qemu 11/38] aspeed/smc: get the number of flash modules from hw strapping

Andrew Jeffery andrew at aj.id.au
Wed Nov 23 12:22:23 AEDT 2016


On Tue, 2016-11-22 at 08:21 +0100, Cédric Le Goater wrote:
> > > So we should set or unset these SCU regs when the SoC is created
> > > and 
> > > derive the wdt2 enablement from them. I suppose that the helper
> > > routine 
> > > to check for the conditions would be under SCU. 
> > > 
> > > or do we start a simple pinctrl model and slowly add the
> > > enablement
> > > of the pins we need ? 
> > > 
> > 
> > From the discussion on IRC last night between Cédric, Joel and
> > myself
> > we decided to start on a pinmux backend to help manage these
> > issues.
> 
> Do you have a rough idea of an API that the SoC could use ? 
> 
> 	enum AspeedAST2500Function {
> 		FWSPICS0,
> 		FWSPICS1,
> 		FWSPICS2,
> 	};
> 
> 	enum AspeedAST2400Function {
> 		ROMCS1,
> 		ROMCS2,
> 		ROMCS3,
> 		ROMCS4,
> 	};
> 
> 	bool aspeed_pin_is_enabled(AspeedPinmux *p, int func);

Largely this looks good.

But bikeshedding a bit, but I think the function name should focus on
functions, not pins. The function maps to some pin in the physical
case, but for qemu's purposes we don't care about that just yet. Even
if we do care in the future we can internally map functions to pins
behind a pinmux abstraction. As such I think we can get away with a
small tweak:

bool aspeed_pinmux_is_enabled(AspeedPinmux *p, int func);

Did you have any thought about how we hoist ourselves from a
AspeedPinmux to say an AspeedAST2500Pinmux with this interface? As it
stands (without specifying parts of AspeedPinmux) we don't have the
context to correctly interpret the func arg. Already with these few
functions we have to test different bits depending on the SoC at hand,
and the 2500 has the extra requirements of talking to the GFX and LPC
controllers in other cases.

I expect having a tag field internal to p is enough. I'll have a think
about it.

Andrew

> 
> Thanks,
> 
> C. 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161123/f84abac9/attachment.sig>


More information about the openbmc mailing list