Re: [PATCH v2 2/2] dt-bindings: dsp: fsl: Add DSP optional clocks documentation

From: Rob Herring <robh@kernel.org>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: "Daniel Baluta" <daniel.baluta@oss.nxp.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Devicetree List" <devicetree@vger.kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	Linux-ALSA <alsa-devel@alsa-project.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Suman Anna" <s-anna@ti.com>,
	"Daniel Baluta" <daniel.baluta@nxp.com>,
	"Shengjiu Wang" <shengjiu.wang@nxp.com>
Subject: Re: [PATCH v2 2/2] dt-bindings: dsp: fsl: Add DSP optional clocks documentation
Date: Thu, 9 Sep 2021 12:15:45 -0500	[thread overview]
Message-ID: <CAL_JsqJd2AvBxRjHj=VZV2DH26tSNSX=5eEpc-HoFrc=dLxEFQ@mail.gmail.com> (raw)
In-Reply-To: <CAEnQRZBmruc8GNfJTm99=0K7PyGrEiB1CxY3c2RSZhLFLR-nhQ@mail.gmail.com>

On Thu, Sep 9, 2021 at 6:21 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> > > The H/W block is controlled by the DSP firmware. So, we don't want
> > > to use the Linux kernel driver (thus the H/W block device tree node).
> >
> > 'status' is how you disable a device to not be used by the OS.
> >
> > The information about that device's resources are already in DT, we
> > don't need to duplicate that here. If you want a list of devices
> > assigned to the DSP here, that would be okay.
>
> Thanks! This is a very good idea. I was thinking at a totally different thing.
>
> So having something like this:
>
> dsp {
>
>
> hw-block-list = <&sai1>, <&sai2>;
>
> }

Yes.

> And then inside the DSP driver we can get access to sai1 clocks. Do
> you know of any standard property name?

There isn't. So it needs a vendor prefix.

There's been some discussions around 'system devicetree' where all
processors (like the DSP) view of the system get represented. Device
assignment is one of the issues to solve with that, but it's not
anywhere close to having something to help here.

Rob