On Aug 18, Andrew Lunn wrote: > On Sun, Aug 18, 2024 at 02:48:05PM +0200, Benjamin Larsson wrote: > > On 17/08/2024 23:39, Andrew Lunn wrote: > > > How messy are the GPIO and PWM registers? Are there N blocks of > > > independent GPIO registers? and M blocks of independent PWM registers? > > > By that, does one block of GPIO registers contain all you need for one > > > GPIO controller? One block of PWM registers give you all you need for > > > one PWM controller? Or are the registers for one GPIO controller > > > scattered all over the place? > > > > > > Could you point at a public datasheet? > > > > > > Andrew > > > > > Hi, per my understanding there is no public datasheet/register reference > > manual. > > > > But here is the division of regions of the registers in the gpio block and > > how it is currently divided between the drivers (according to my current > > understanding). > > > > 1FBF0200, gpio/pinctrl > > 1FBF0204, gpio/pinctrl > > 1FBF0208, gpio/pinctrl > > 1FBF020C, gpio/pinctrl > > 1FBF0210, gpio/pinctrl > > 1FBF0214, gpio/pinctrl > > A typical SoC has multiple instances of a GPIO controller. Each GPIO > controller typically has 4 or 5 registers: In, Out, Direction, > Interrupt Enable, Interrupt Status. If these 4 or 5 registers are > contiguous, you could have one DT node per controller, rather than one > node for all GPIO controllers. it is the same for en7581 pinctrl too. I think we can squash most of the gpio/irq registers into "bigger" io-regions (just keeping a couple of holes for pwm and leds). It is just a matter of moving the logic from the dts to the driver. I am currently working on it. I will post v2 soon. > > If the hardware designer has really messed up and fully interleaved > GPIO and PWM, it might be better to have an MFD. The MFD node has a > single reg covering the entire range. The MFD would then map the whole > range, and provide accessors to the child devices. Hard code the > knowledge of what registers are where. Given how badly the hardware is > designed, it is unlikely it will get reused in the future, so there is > no point putting lots of stuff into DT. Hard code it. I am not sure it is possible/feasible to implement a MFD device here since the mapped region is huge and sparse. Regards, Lorenzo > > Andrew
Attachment:
signature.asc
Description: PGP signature
