-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconnecting an output signal to a different pin does not clear previous connections #2928
Comments
We don't do this, because we'd have to loop through all GPIOs to find which ones use the signal we want to connect. We could store the last assigned pin in memory, but what if the user might want to connect a signal to multiple pins at once? |
The GPIO signal semantics haven't been well defined and should probably be sorted out before stabilizing the any drivers that use the GPIO matrix or io mux. I think the optimal behaviour would be for the driver to store whatever peripheral input/output the user provides, and deconfigure them on drop. In practice this might be annoying to implement. Looping through all the GPIO won't achieve this because it will also undo any connections setup outside the driver, which is undesirable. |
We can logically OR all the pin masks that a driver uses and track the pins that way, but that would mean wasting at least a |
Heh, good idea, better than to waste a u8 for each signal that I had in mind. Can be part of the driver State. |
Wait nevermind we still have to know which pin is which signal, we don't want to accidentally reassign MISO as CS0 |
That, we can figure out from the GPIO registers 😄 So we store a bitmap of all the output pins the driver owns then use the registers to figure which signal they're mapped to. Though I can't tell why we need this information to deconfigure them |
An example where this matters is SPI hardware chip select. Due to how the IO_MUX works, connecting a new output to the peripheral's (e.g.) CS0 output doesn't clear the old selection, e.g. trying to connect a single SPI chip select signal to multiple pins one by one, then asserting that chip select ends up selecting multiple SPI devices.
The text was updated successfully, but these errors were encountered: