On Thu, May 16, 2024 at 06:15:18PM +0100, Conor Dooley wrote:
> On Wed, May 15, 2024 at 02:28:51PM -0400, Frank Li wrote:
> > On Wed, May 15, 2024 at 05:04:48PM +0100, Conor Dooley wrote:
> > > On Wed, May 15, 2024 at 10:47:57AM +0800, Shengjiu Wang wrote:
> > > > On Wed, May 15, 2024 at 5:09 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
> > > > >
> > > > > Quoting Conor Dooley (2024-05-14 11:06:14)
> > > > > > On Tue, May 14, 2024 at 05:33:27PM +0800, Shengjiu Wang wrote:
> > > > > > > diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
> > > > > > > index 0a6dc1a6e122..a403ace4d11f 100644
> > > > > > > --- a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
> > > > > > > +++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
> > > > > > > @@ -15,7 +15,10 @@ description: |
> > > > > > >
> > > > > > > properties:
> > > > > > > compatible:
> > > > > > > - const: fsl,imx8mp-audio-blk-ctrl
> > > > > > > + items:
> > > > > > > + - const: fsl,imx8mp-audio-blk-ctrl
> > > > > > > + - const: syscon
> > > > > > > + - const: simple-mfd
> > > > > > >
> > > > > > > reg:
> > > > > > > maxItems: 1
> > > > > > > @@ -44,6 +47,11 @@ properties:
> > > > > > > ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mp-clock.h
> > > > > > > for the full list of i.MX8MP IMX8MP_CLK_AUDIOMIX_ clock IDs.
> > > > > > >
> > > > > > > + reset-controller:
> > > > > > > + type: object
> > > > > > > + $ref: /schemas/reset/fsl,imx8mp-audiomix-reset.yaml#
> > > > > > > + description: The child reset devices of AudioMIX Block Control.
> > > > > >
> > > > > > Why not just set #reset-cells = <1> in the existing node? IIRC it was
> > > > > > already suggested to you to do that and use auxdev to set up the reset
> > > > > > driver.
> > > > >
> > > > > Yes, do that.
> > > >
> > > > Can I know why sub nodes can't be used? the relationship of parent and
> > > > child devices looks better with sub nodes.
> > >
> > > That's pretty subjective. I don't think it looks better to have a clock
> > > node that is also a syscon with a reset child node as it is rather
> > > inconsistent.
> >
> > I think it is multi function device syscon node. it should be like
> >
> > mfd
> > {
> > clock
> > {
> > ...
> > }
> >
> > reset
> > {
> > ...
> > }
> > }
> >
> > clock and reset are difference device node with totally difference's
> > compatible string.
>
> Which is I suspect is gonna require a change to your clock driver,
> because the range in the existing clock nodes:
> audio_blk_ctrl: clock-controller@30e20000 {
> compatible = "fsl,imx8mp-audio-blk-ctrl";
> reg = <0x30e20000 0x10000>;
> };
> would then have to move to the mfd parent node, and your clock child
> would have a reg property that overlaps the reset region. You'd need to
> then define a new binding that splits the range in two - obviously
> doable, but significantly more work and more disruptive than using an
> auxdev.
I am new for auxdev.
according to doc: https://docs.kernel.org/driver-api/auxiliary_bus.html
"key requirement for utilizing the auxiliary bus is that there is no
dependency on a physical bus, device, register accesses or regmap support.
These individual devices split from the core cannot live on the platform
bus as they are not physical devices that are controlled by DT/ACPI."
^^^^ ^^^
Look like it is easy to register auxdev "reset" devices. But I have a
problem. How to use it by DT phandle? "reset" devices is service provider.
Some client will use it.
Generally, reset node will used by other devices nodes. like
ABC: reset {
compatible="simple-reset";
...
}
other node will use "reset = <&ABC 0>". If use auxdev, how to get &ABC
in dts file.
>
> > > > A further question is can I use the reset-ti-syscon? which is a generic reset
> > > > device for SoCs. with it I don't even need to write a new reset device driver.
> > > > it is more simple.
> > >
> > > That is for a TI SoC. You're working on an imx. I don't think that you
> > > should be using that...
> >
> > I think this statement violate the linux basic reuse prinicple. If the
> > code logic are the same why need duplicate it just because it is difference
> > company. Of coures, if it is generic enough, it'd better to add a more
> > generic compatible string.
>
> That's true, but I suspect it only works because only through (ab)use
> of the ti,reset-bits property not because you're actually compatible
> with TI's reset hardware.
Reset's implement is very simple. Most design is similar in difference
SOC. Just toggle a register bit. If regiser layout is the same, it should
be compatible. this ti driver is suitable for most case. I think call it
as simple-reset-syscon are more reasonable.
>
> Cheers,
> Conor.
