On 02/11/2020 19:04, Sam Ravnborg wrote:
Hi Neil.
> --- > .../bindings/display/intel,keembay-display.yaml | 75 ++++++++++++++++++++++ > 1 file changed, 75 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/intel,keembay-display.yaml > > diff --git a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > new file mode 100644 > index 0000000..8a8effe > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml > @@ -0,0 +1,75 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Devicetree bindings for Intel Keem Bay display controller > + > +maintainers: > + - Anitha Chrisanthus anitha.chrisanthus@intel.com > + - Edmond J Dea edmund.j.dea@intel.com > + > +properties: > + compatible: > + const: intel,keembay-display > + > + reg: > + items: > + - description: LCD registers range > + - description: Msscam registers range > +
Indeed the split is much better, but as you replied on http://lore.kernel.org/r/BY5PR11MB41827DE07436DD0454E24E6E8C0A0@BY5PR11MB418... the msscam seems to be shared with the camera subsystem block, if this is the case it should be handled.
If it's a shared register block, it could be defined as a "syscon" used by both subsystems.
I think I got it now.
msscam is used to enable clocks both for the display driver and the mipi-dsi part.
If just clocks, then the msscam should be a clock provider possibly. If not, then the below looks right.
I am feeling a little clueless here - sorry.
Can you help with any example that does this?
Everything I looked up in bindings/clock/ had a "#clock-cells" which is not relevant for msscam - or so I think at least.
Looking at the code make it clear it's not relevant to implement it as clock controller.
The syscon is enough.
Neil
Sam