Re: [PATCH v3 2/2] ARM: dts: tegra20: Add video decoder node

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, Oct 12, 2017 at 03:06:17PM +0300, Dmitry Osipenko wrote:
> Hello Vladimir,
> 
> On 12.10.2017 10:43, Vladimir Zapolskiy wrote:
> > Hello Dmitry,
> > 
> > On 10/11/2017 11:08 PM, Dmitry Osipenko wrote:
> >> Add a device node for the video decoder engine found on Tegra20.
> >>
> >> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
> >> ---
> >>  arch/arm/boot/dts/tegra20.dtsi | 17 +++++++++++++++++
> >>  1 file changed, 17 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> >> index 7c85f97f72ea..1b5d54b6c0cb 100644
> >> --- a/arch/arm/boot/dts/tegra20.dtsi
> >> +++ b/arch/arm/boot/dts/tegra20.dtsi
> >> @@ -249,6 +249,23 @@
> >>  		*/
> >>  	};
> >>  
> >> +	vde@6001a000 {
> >> +		compatible = "nvidia,tegra20-vde";
> >> +		reg = <0x6001a000 0x3D00    /* VDE registers */
> >> +		       0x40000400 0x3FC00>; /* IRAM region */
> > 
> > this notation of a used region in IRAM is non-standard and potentially it
> > may lead to conflicts for IRAM resource between users.
> > 
> > My proposal is to add a valid device tree node to describe an IRAM region
> > firstly, then reserve a subregion in it by using a new "iram" property.
> > 
> 
> The defined in DT IRAM region used by VDE isn't exactly correct, actually it
> should be much smaller. I don't know exactly what parts of IRAM VDE uses, for
> now it is just safer to assign the rest of the IRAM region to VDE.
> 
> I'm not sure whether it really worthy to use a dynamic allocator for a single
> static allocation, but maybe it would come handy later.. Stephen / Jon /
> Thierry, what do you think?

This sounds like a good idea. I agree that this currently doesn't seem
to be warranted, but consider what would happen if at some point we have
more devices requiring access to the IRAM. Spreading individual reg
properties all across the DT will make it very difficult to ensure they
don't overlap.

Presumably the mmio-sram driver will check that pool don't overlap. Or
even if it doesn't it will make it a lot easier to verify because it's
all in the same DT node and then consumers only reference it.

I like Vladimir's proposal. I also suspect that Rob may want us to stick
to a standardized way referencing such external memory.

Thierry

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux