* [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask
@ 2019-01-16 17:10 John Stultz
0 siblings, 0 replies; 5+ messages in thread
From: John Stultz @ 2019-01-16 17:10 UTC (permalink / raw)
To: lkml
Cc: John Stultz, Vinod Koul, Rob Herring, Mark Rutland, Tanglei Han,
Zhuangluan Su, Ryan Grachek, Manivannan Sadhasivam, dmaengine,
devicetree
Some dma channels can be reserved for secure mode or other
hardware on the SoC, so provide a binding for a bitmask
listing the available channels for the kernel to use.
This follows the pre-existing bcm,dma-channel-mask binding.
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Tanglei Han <hantanglei@huawei.com>
Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
Cc: Ryan Grachek <ryan@edited.us>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
v3: Renamed to hisi-dma-avail-chan
v4: Reworked to generic dma-channel-mask
---
Documentation/devicetree/bindings/dma/dma.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
index 6312fb0..eeb4e4d 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -16,6 +16,9 @@ Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA request signals supported by the
controller.
+- dma-channel-mask: Bitmask of available DMA channels in ascending order
+ that are not reserved by firmware and are available to
+ the kernel. i.e. first channel corresponds to LSB.
Example:
@@ -29,6 +32,7 @@ Example:
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
+ dma-channel-mask = <0xfffe>
};
* DMA router
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask
@ 2019-01-17 17:08 Manivannan Sadhasivam
0 siblings, 0 replies; 5+ messages in thread
From: Manivannan Sadhasivam @ 2019-01-17 17:08 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Vinod Koul, Rob Herring, Mark Rutland, Tanglei Han,
Zhuangluan Su, Ryan Grachek, dmaengine, devicetree
On Wed, Jan 16, 2019 at 09:10:23AM -0800, John Stultz wrote:
> Some dma channels can be reserved for secure mode or other
> hardware on the SoC, so provide a binding for a bitmask
> listing the available channels for the kernel to use.
>
> This follows the pre-existing bcm,dma-channel-mask binding.
>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Tanglei Han <hantanglei@huawei.com>
> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> Cc: Ryan Grachek <ryan@edited.us>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: dmaengine@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v3: Renamed to hisi-dma-avail-chan
> v4: Reworked to generic dma-channel-mask
> ---
> Documentation/devicetree/bindings/dma/dma.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
> index 6312fb0..eeb4e4d 100644
> --- a/Documentation/devicetree/bindings/dma/dma.txt
> +++ b/Documentation/devicetree/bindings/dma/dma.txt
> @@ -16,6 +16,9 @@ Optional properties:
> - dma-channels: Number of DMA channels supported by the controller.
> - dma-requests: Number of DMA request signals supported by the
> controller.
> +- dma-channel-mask: Bitmask of available DMA channels in ascending order
> + that are not reserved by firmware and are available to
> + the kernel. i.e. first channel corresponds to LSB.
A general assumption is, "dma-channel-mask" refers to the bit fields of
the channels which needs to be masked. But here, it refers to the channels
which are available. Doesn't it contradict?
Thanks,
Mani
>
> Example:
>
> @@ -29,6 +32,7 @@ Example:
> #dma-cells = <1>;
> dma-channels = <32>;
> dma-requests = <127>;
> + dma-channel-mask = <0xfffe>
> };
>
> * DMA router
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask
@ 2019-01-17 17:43 John Stultz
0 siblings, 0 replies; 5+ messages in thread
From: John Stultz @ 2019-01-17 17:43 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: lkml, Vinod Koul, Rob Herring, Mark Rutland, Tanglei Han,
Zhuangluan Su, Ryan Grachek,
open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
On Thu, Jan 17, 2019 at 9:08 AM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Wed, Jan 16, 2019 at 09:10:23AM -0800, John Stultz wrote:
> > Some dma channels can be reserved for secure mode or other
> > hardware on the SoC, so provide a binding for a bitmask
> > listing the available channels for the kernel to use.
> >
> > This follows the pre-existing bcm,dma-channel-mask binding.
> >
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Tanglei Han <hantanglei@huawei.com>
> > Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> > Cc: Ryan Grachek <ryan@edited.us>
> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: John Stultz <john.stultz@linaro.org>
> > ---
> > v3: Renamed to hisi-dma-avail-chan
> > v4: Reworked to generic dma-channel-mask
> > ---
> > Documentation/devicetree/bindings/dma/dma.txt | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
> > index 6312fb0..eeb4e4d 100644
> > --- a/Documentation/devicetree/bindings/dma/dma.txt
> > +++ b/Documentation/devicetree/bindings/dma/dma.txt
> > @@ -16,6 +16,9 @@ Optional properties:
> > - dma-channels: Number of DMA channels supported by the controller.
> > - dma-requests: Number of DMA request signals supported by the
> > controller.
> > +- dma-channel-mask: Bitmask of available DMA channels in ascending order
> > + that are not reserved by firmware and are available to
> > + the kernel. i.e. first channel corresponds to LSB.
>
> A general assumption is, "dma-channel-mask" refers to the bit fields of
> the channels which needs to be masked. But here, it refers to the channels
> which are available. Doesn't it contradict?
Hrm. So while I can sort of understand the common usage of "mask" as
to "hide", thus the desire to have a bitfield mean "the channels we
hide" or "don't use", but in my experience bitmasking is more commonly
used to keep only a portion of the the bits, so from that perspective
its more intuitive that a mask be the channels we keep to use. So I'm
not sure if your suggestion makes it more clear.
But I'm not very particular here, so I'll defer to others on this.
thanks
-john
^ permalink raw reply [flat|nested] 5+ messages in thread
* [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask
@ 2019-01-20 11:06 Vinod Koul
0 siblings, 0 replies; 5+ messages in thread
From: Vinod Koul @ 2019-01-20 11:06 UTC (permalink / raw)
To: John Stultz
Cc: Manivannan Sadhasivam, lkml, Rob Herring, Mark Rutland,
Tanglei Han, Zhuangluan Su, Ryan Grachek,
open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
On 17-01-19, 09:43, John Stultz wrote:
> On Thu, Jan 17, 2019 at 9:08 AM Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> wrote:
> >
> > On Wed, Jan 16, 2019 at 09:10:23AM -0800, John Stultz wrote:
> > > Some dma channels can be reserved for secure mode or other
> > > hardware on the SoC, so provide a binding for a bitmask
> > > listing the available channels for the kernel to use.
> > >
> > > This follows the pre-existing bcm,dma-channel-mask binding.
> > >
> > > Cc: Vinod Koul <vkoul@kernel.org>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Tanglei Han <hantanglei@huawei.com>
> > > Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> > > Cc: Ryan Grachek <ryan@edited.us>
> > > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Cc: dmaengine@vger.kernel.org
> > > Cc: devicetree@vger.kernel.org
> > > Signed-off-by: John Stultz <john.stultz@linaro.org>
> > > ---
> > > v3: Renamed to hisi-dma-avail-chan
> > > v4: Reworked to generic dma-channel-mask
> > > ---
> > > Documentation/devicetree/bindings/dma/dma.txt | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
> > > index 6312fb0..eeb4e4d 100644
> > > --- a/Documentation/devicetree/bindings/dma/dma.txt
> > > +++ b/Documentation/devicetree/bindings/dma/dma.txt
> > > @@ -16,6 +16,9 @@ Optional properties:
> > > - dma-channels: Number of DMA channels supported by the controller.
> > > - dma-requests: Number of DMA request signals supported by the
> > > controller.
> > > +- dma-channel-mask: Bitmask of available DMA channels in ascending order
> > > + that are not reserved by firmware and are available to
> > > + the kernel. i.e. first channel corresponds to LSB.
> >
> > A general assumption is, "dma-channel-mask" refers to the bit fields of
> > the channels which needs to be masked. But here, it refers to the channels
> > which are available. Doesn't it contradict?
>
> Hrm. So while I can sort of understand the common usage of "mask" as
> to "hide", thus the desire to have a bitfield mean "the channels we
> hide" or "don't use", but in my experience bitmasking is more commonly
> used to keep only a portion of the the bits, so from that perspective
> its more intuitive that a mask be the channels we keep to use. So I'm
> not sure if your suggestion makes it more clear.
>
> But I'm not very particular here, so I'll defer to others on this.
Given the context and documentation which explicitly says it is bitmask
of available channels, i think we are fine :)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask
@ 2019-01-22 1:13 Rob Herring
0 siblings, 0 replies; 5+ messages in thread
From: Rob Herring @ 2019-01-22 1:13 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Vinod Koul, Mark Rutland, Tanglei Han, Zhuangluan Su,
Ryan Grachek, Manivannan Sadhasivam, dmaengine, devicetree
On Wed, 16 Jan 2019 09:10:23 -0800, John Stultz wrote:
> Some dma channels can be reserved for secure mode or other
> hardware on the SoC, so provide a binding for a bitmask
> listing the available channels for the kernel to use.
>
> This follows the pre-existing bcm,dma-channel-mask binding.
>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Tanglei Han <hantanglei@huawei.com>
> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com>
> Cc: Ryan Grachek <ryan@edited.us>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: dmaengine@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v3: Renamed to hisi-dma-avail-chan
> v4: Reworked to generic dma-channel-mask
> ---
> Documentation/devicetree/bindings/dma/dma.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-22 1:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-22 1:13 [2/8,v4] Documentation: bindings: dma: Add binding for dma-channel-mask Rob Herring
-- strict thread matches above, loose matches on Subject: below --
2019-01-20 11:06 Vinod Koul
2019-01-17 17:43 John Stultz
2019-01-17 17:08 Manivannan Sadhasivam
2019-01-16 17:10 John Stultz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).