6by9 wrote:The firmware driver hardcodes register 0xB to 0x2f, and 0xD to 0x00.
Shouldn't register 0xB be 0xFC because there are discrete pullups on IO0 and IO1 that you'd conflict with otherwise (R7 & R8)? It's the upper bits which are floating and hence want pulling to some known level.
I just looked at the firmware source code and copied what I found there!
I'd agree for IO0 that there appears to be a conflict. For IO1 there isn't as it is defined as an output, and as per the text in the datasheet "If the pin is defined as output in register 03h, the corresponding bit has no effect".
The settings were probably written for the Pi3 (IO4 and IO7 used as inputs, pulling disabled. All others outputs) and not considered in detail for CM3.
6by9 wrote:There is a request to allow reconfiguration of the FXL6408 GPIOs (mainly for controlling the power LED on the Pi3), so if I'm bored enough when looking into that I may look at adding pull up/down control at that point. It requires extending quite a few APIs though.
That'd be brilliant if it's possible. My inspection of lines 1335 & 1336 of https://raw.githubusercontent.com/raspb ... t-blob.dts
which include termination = "no_pulling"
made me think all the hooks were in place. ie. I'm not wanting to adaptively fiddle with the settings via a mailbox property, just one shot setting from the dt-blob.[/quote]
Gordon just made the comment of "didn't I implement that bit?".
He has implemented the parser and handling of the the initial state, but the API between the generic GPIO handler and the GPIO expander driver is missing any notion of pulling (or reconfiguration after open). If it was going through the standard GPIO driver instead of the expander one, then it would all be there.
Not a huge job to fix, but also a little way off the top of the priority list, and I currently couldn't suggest a timescale on it.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.