Handling device shared SFR on dt platform

Hello,

I'm working on adding the device tree support for two devices that share some IO registers. Exactly, there is one shared SFR that contains a common bit to enable two PHY devices, and another two bits, each to separately reset each PHY.

Currently this shared register is statically memory mapped and it is handled by a platform specific callback, that both drivers use to control their corresponding (sub)devices in synchronised manner.

The two devices are a MIPI-CSI2 receiver and a MIPI-DSI transmitter, and the common register is there to control the camera and the display port PHY. The hardware design is a bit unfortunate, but there is not much I could do about it.

Generally, this is handled by having a third node for the shared register block and both device nodes holding a phandle to it.

No, there isn't any common infrastructure for implementing this, but it isn't very much code.

Hello Grant,

Quoted 6 lines · Grant Likely

Generally, this is handled by having a third node for the shared register block and both device nodes holding a phandle to it.

No, there isn't any common infrastructure for implementing this, but it isn't very much code.

Thank you, that sounds good. I'm just wondering how to handle the shared resource access synchronisation. There is an IORESOURCE_MUXED resource type flag which could be used to prevent drivers from stomping on each others feet when accessing the shared register, if I understand the software muxed resource semantics correctly. That is, using something like request_muxed_(mem_)region()/release_mem_region() for the shared register protection.

What concerns me, is an overhead from region request/ioremap(?)/release, just to access a single 32-bit register. I'm going to see if those accesses could be moved to only device driver's probe() and remove() callbacks and what might be the resulting power consumption increase from that, if any.

Quoted 4 lines

What concerns me, is an overhead from region request/ioremap(?)/release, just to access a single 32-bit register. I'm going to see if those accesses could be moved to only device driver's probe() and remove() callbacks and what might be the resulting power consumption increase from that, if any.

Personally, I'd just create a shared function used by both drivers to access the register and protect it with a spinlock. That way the region only needs to be mapped once, and the overhead is as low as possible.

Quoted 9 lines · Grant Likely

Quoted 4 lines

What concerns me, is an overhead from region request/ioremap(?)/release, just to access a single 32-bit register. I'm going to see if those accesses could be moved to only device driver's probe() and remove() callbacks and what might be the resulting power consumption increase from that, if any.

Personally, I'd just create a shared function used by both drivers to access the register and protect it with a spinlock. That way the region only needs to be mapped once, and the overhead is as low as possible.

Hmm, that's what I originally started with. I've just removed function callback from the platform data struct in favour of having the drivers using directly the function exported by plat-s5p. Then I started devising something alternative, in hope to get rid of the drivers compilation dependency on PLAT_S5P. There seems little point in that though, since the chance to have those IP blocks available on other archs or ARM sub-archs, than Samsung S5P/Exynos, are extremely low.