-
Couldn't load subscription status.
- Fork 8.1k
drivers: display: hub12: add horizontal chaining support #98445
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
base: main
Are you sure you want to change the base?
drivers: display: hub12: add horizontal chaining support #98445
Conversation
heronet
commented
Oct 28, 2025
- Add support for chaining multiple 32x16 panels horizontally by setting width to multiples of 32 (64, 96, 128, etc).
- Fix a minor race condition issue.
drivers/display/display_hub12.c
Outdated
| } | ||
|
|
||
| k_sem_take(&data->lock, K_FOREVER); | ||
| k_mutex_lock(&data->lock, K_FOREVER); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mutex seemed like a better fit since we're protecting shared data access. Also helps if multiple threads end up calling display_write at different priorities
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that the submitter of this document is you. I'm curious why your first choice wasn't a mutex, and now you're back to modify it again (just asking).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly a matter of preference actually. The initial implementation with a semaphore worked fine, and this patch primarily adds display chaining. While updating, I realized that a semaphore isn’t strictly necessary here, and using a mutex could also help with priority inversion. So I replaced the semaphore with a mutex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Expect for priority inversion mitigation, a semaphore is lighter than & recommended over a mutex in Zephyr. A mutex makes the function unusable from an ISR.
Also calling display_write from multiple threads would be a bad practice in my opinion.
https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-8-thread-synchronization/topic/mutexes/
https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-8-thread-synchronization/topic/semaphores/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it’s a trade-off. Do you think it would be better if I reverted to semaphores? I’m fine with that.
Edit: I went for semaphore as it is more performant and recommended than mutex.
- Add support for chaining multiple 32x16 panels horizontally by setting width to multiples of 32 (64, 96, 128, etc). Signed-off-by: Siratul Islam <email@sirat.me>
- Add support for chaining multiple 32x16 panels horizontally by setting width to multiples of 32 (64, 96, 128, etc). - Also fixed a race condition issue. Signed-off-by: Siratul Islam <email@sirat.me>
69c4ee3 to
6fec537
Compare
|


