This is a patch to add support for the GPIO functionality of the Nuvoton NCT5104D.
Tested on my PC Engines APU1C4 @ rev 297048.
Details
Details
- Reviewers
loos adrian - Commits
- rS297443: Add support for the Nuvoton NCT5104D.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Hi!
Only thing missing are the bus barrier operations (which are noops on intel hardware, but still.)
Other than that, great!
Comment Actions
Thank you for the feedback!
I was able to look at this today and added memory barriers and fixed a couple of silly mistakes.
Let me know if there's anything else I can do to get this committed.
Comment Actions
ok! one more little thing before I'll commit it.
You've got some locking in there, which is great. I'd like to see lock assertions in the places where you go and fiddle with the hardware.
So, read pin, write pin, pin is inverted, etc.
That way you can be absolutely sure that you've got the right lock held when you access the hardware.
Other than that, this works for you and it looks great, so let's get it in there. :-)
| sys/dev/nctgpio/nctgpio.c | ||
|---|---|---|
| 24 ↗ | (On Diff #14448) | Need a blank line and a $FreeBSD$ tag so it gets expanded. :p |
| 53 ↗ | (On Diff #14448) | Normally I'd put the hardware definitions in a xxxreg.h file, but for something this small it's likely not worthwhile. We can always break it out later! |
| 94 ↗ | (On Diff #14448) | And normally the struct and defines below would go into xxxxvar.h - but again, it's such a simple driver that it's not really worthwhile and not a commit blocker. :) |
| 104 ↗ | (On Diff #14448) | Add a GPIO_LOCK_ASSERT( ) and GPIO_UNLOCK_ASSERT(). (see general comments.) |
Comment Actions
Added locked/unlocked assertions and init/destroy macros. Added $FreeBSD$ tag.
There are only 4 functions that do direct IO with the device, so I added assertions there to ensure the lock is held. It did require initializing/destroying the mutex in a second location in the code, but still seems better than the alternative of trying to add the assertion to every path of execution leading to the 4 functions.
Tested and working: https://www.youtube.com/watch?v=a1vpRa7-pQY