Hi Stephen,
On Sat, 13 Feb 2021 at 09:11, Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
> > +examples:
> > + - |
> > + clkgen_mux_mspi0: clkgen_mux_mspi0 {
> > + compatible = "mstar,msc313-clkgen-mux";
> > + regmap = <&clkgen>;
> > + offset = <0xcc>;
> > + #clock-cells = <1>;
> > + mstar,gate = <0>;
> > + mstar,mux-shift = <2>;
> > + mstar,mux-width = <2>;
>
> It looks like a node-per clk sort of binding which has been rejected
> multiple times in the past. If the clks are spread across various
> devices then it sounds like the mediatek design where they have many
> syscon nodes that also register clks inside those register spaces. In
> this case, I would expect the clkgen node to be registering clks. Given
> that there isn't a reg property and there's these mstar specific
> properties like shift/width it looks really wrong. Please don't do this.
Ok. I will rethink this. One of the problems I face here is that there
isn't any documentation for what the clkgen looks like.
I have a list of offsets and bit positions for these muxes but very little else.
Looking at the mediatek clock drivers it seems like they have a driver
that consumes some register areas and then creates all of the muxes
etc within those areas within the driver instead. If that's an
acceptable solution I will go for that.
There would probably be 2 compatible strings right now (one for the pm
area and one for the normal area) and that would take a phandle to the
syscon that holds the registers. Then there would be a big table of
the offsets, masks etc in the driver.
Thanks,
Daniel
