Skip to content
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

Open
bugadani opened this issue Jan 10, 2025 · 6 comments
Assignees
Labels
1.0-blocker bug Something isn't working peripheral:gpio GPIO peripheral

Comments

@bugadani
Copy link
Contributor

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.

@bugadani bugadani added bug Something isn't working peripheral:gpio GPIO peripheral status:needs-attention This should be prioritized labels Jan 10, 2025
@bugadani
Copy link
Contributor Author

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?

@Dominaezzz
Copy link
Collaborator

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.

@MabezDev
Copy link
Member

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 u32 but more than likely a u64 on most chips for each driver. Maybe that's not so bad?

@MabezDev MabezDev added 1.0-blocker and removed status:needs-attention This should be prioritized labels Jan 10, 2025
@bugadani
Copy link
Contributor Author

bugadani commented Jan 10, 2025

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 u32 but more than likely a u64 on most chips for each driver. Maybe that's not so bad?

Heh, good idea, better than to waste a u8 for each signal that I had in mind. Can be part of the driver State.

@bugadani
Copy link
Contributor Author

Wait nevermind we still have to know which pin is which signal, we don't want to accidentally reassign MISO as CS0

@Dominaezzz
Copy link
Collaborator

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

@JurajSadel JurajSadel self-assigned this Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.0-blocker bug Something isn't working peripheral:gpio GPIO peripheral
Projects
Status: Todo
Development

No branches or pull requests

4 participants