[Libre-soc-bugs] [Bug 762] Peripheral Pin Muxing Development
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Jan 20 22:53:03 GMT 2022
https://bugs.libre-soc.org/show_bug.cgi?id=762
--- Comment #8 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
(In reply to Luke Kenneth Casson Leighton from comment #7)
> (In reply to Andrey Miroshnikov from comment #6)
>
> > This wouldn't quite work as the gpio layout has an additional "i" signal, so
> > I'll probably have to keep this one separate. Will need some more thinking
> > on that.
>
> yyeah, although the format of the data as far as its memory-mapping
> is concerned the csrbus layout looks perfect.
At the moment csrbus only connects the first byte of the data word. Is this how
you expect it to be? Should I extend csrbus to store the full word (several
gpio configs)?
>
> however you will need *another* layout which is the actual
> wires-as-connected-directly-to-the-IOPad-Cell. that one would
> not have bank_sel, but would be more like:
>
> padlayout = (("oe", 1),
> ("i", 1),
> ("o", 1),
> ("puen", 1),
> ("pden", 1),
> )
What about ie? IOPad assume the GPIO is input if oe is low?
> will we want the exact same types as in jtag.tap.IOTypes? i don't
> know. maybe. will we want puen/pden to be optional? probably,
What do you mean by having the same types as IOTypes?
Here's what I saw in debug/jtag.py:
iotypes = {'-': IOType.In,
'+': IOType.Out,
'>': IOType.TriOut,
'*': IOType.InTriOut,
}
scanlens = {IOType.In: 1,
IOType.Out: 1,
IOType.TriOut: 2,
IOType.InTriOut: 3,
}
Do you mean the layout definition needs to have the '-'/'+'/etc. strings for
each signal? Like ("oe", 1, '+')
> but not right away, i suggest just keeping it straightforward and
> simple, add options later
Sure, I'll focus on what you mentioned already, plenty to do as is hahaha
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list