On Mon, May 18, 2015 at 04:33:49PM +0100, Jon Hunter wrote: > Background: > ========== > On tegra124 and tegra132 devices the pads used by the Display Port Auxiliary > (DPAUX) channel are multiplexed such that they can also be used by one of the > internal i2c controllers. Note that this is different from i2c-over-AUX > supported by the DPAUX controller. The register that configures these pads is > part of the DPAUX controllers register set and so requires the clock for the > DPAUX controller to be enabled to access the register as well as keeping the > SOR (serial output resource) power domain enabled. > > Currently, there is no pinctrl device for these pads and so cannot be easily > mapped to function as an i2c interface. Furthermore, when using the pads for > the DPAUX channel, the DPAUX driver (drivers/gpu/drm/tegra/dpaux.c) directly > writes the to appropriate register to setup the pads. > > There are some products based upon the tegra132 that use these pads for an > internal i2c controller and hence we want to support this configuration in the > kernel. Good timing, I was going to (reluctantly) add this to my long TODO list. I generally like the proposal. > Proposal: > ======== > Add a DPAUX MFD device that consists of a DPAUX controller, for the Display > Port Auxiliary related functionality and a DPAUX pad controller, for handling > the pinctrl for the DPAUX pads. Both the DPAUX controller and DPAUX pad > controller need to access the DPAUX register set and therefore, by making the > MFD compatible with "simple-mfd" and "syscon", a regmap for the DPAUX registers > will be created to synchronise register accesses made by the drivers. Can we not do without an MFD here? Not only would it break DT ABI, but it's also way more complicated than it needs to be in my opinion, we're only sharing a single register (or perhaps even two) after all. Keeping everything in a single DT node would also make the binding less awkward because the power domain doesn't apply to the pad controller part of DPAUX. Can't the dpaux driver simply register the pinmux controller itself? Thierry
Attachment:
pgpKPqJBcBfwI.pgp
Description: PGP signature
