[PATCH v10 1/6] dt-bindings: display: Add support for Intel KeemBay Display

[Rob Herring]

On Mon, Nov 2, 2020 at 12:04 PM Sam Ravnborg <sam at ravnborg.org> 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 at intel.com>
> > >>>>> +  - Edmond J Dea <edmund.j.dea at 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@BY5PR11MB4182.namprd11.prod.outlook.com
> > >>> 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?

I'm pretty sure there's some DSI PHYs where they are also a clock provider.

> Everything I looked up in bindings/clock/ had a "#clock-cells" which is
> not relevant for msscam - or so I think at least.

That is precisely what needs to be added to msscam and then there
would be another 'clocks' entry here.

But it really depends if the register accesses here map to the
controls the clock API provides.

Rob