Allocation of frame buffer at a specific memory range or address

Allocation of frame buffer at a specific memory range or address

[Alexey Brodkin]

Hello,

I'm wondering if there's a way to force kernel to allocate backing
memory for frame buffer in a special location?

A little bit of background below.
I continue to work on DRM driver for ARC PGU, latest
is v5 and available here -?https://lkml.org/lkml/2016/3/28/170

In current state everything more or less works but I'd like to
implement one improvement - I'd like to have an ability to specify
where in memory will be allocated frame-buffer's backing storage area.
I.e. buffer which will be read by PGU hardware.

Currently we use whatever DRM susbsystem put in "gem->paddr".
That's a snippet of the code which tells PGU hardware
which memory location to scan for data:
--------------------->8--------------------
	arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);

	/* Telling PGU hardware where is data to read */
	arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
--------------------->8--------------------

But we may use a special memory area which works better
for that case, i.e. for example could be accessed faster by both
CPU and PGU hardware (like on-chip SRAM as opposed to external DDR).

And now the question is how to force DRM subsystem or just that driver
to use whatever predefined (say via device tree) location in memory
for data buffer allocation.

All thoughts on this are more than welcome.

-Alexey

Allocation of frame buffer at a specific memory range or address

[Alexey Brodkin]

Hello,

I'm wondering if there's a way to force kernel to allocate backing
memory for frame buffer in a special location?

A little bit of background below.
I continue to work on DRM driver for ARC PGU, latest
is v5 and available here - https://lkml.org/lkml/2016/3/28/170

In current state everything more or less works but I'd like to
implement one improvement - I'd like to have an ability to specify
where in memory will be allocated frame-buffer's backing storage area.
I.e. buffer which will be read by PGU hardware.

Currently we use whatever DRM susbsystem put in "gem->paddr".
That's a snippet of the code which tells PGU hardware
which memory location to scan for data:
--------------------->8--------------------
	arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);

	/* Telling PGU hardware where is data to read */
	arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
--------------------->8--------------------

But we may use a special memory area which works better
for that case, i.e. for example could be accessed faster by both
CPU and PGU hardware (like on-chip SRAM as opposed to external DDR).

And now the question is how to force DRM subsystem or just that driver
to use whatever predefined (say via device tree) location in memory
for data buffer allocation.

All thoughts on this are more than welcome.

-Alexey

Allocation of frame buffer at a specific memory range or address

[Daniel Vetter]

On Fri, Apr 15, 2016 at 5:48 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hello,
>
> I'm wondering if there's a way to force kernel to allocate backing
> memory for frame buffer in a special location?
>
> A little bit of background below.
> I continue to work on DRM driver for ARC PGU, latest
> is v5 and available here - https://lkml.org/lkml/2016/3/28/170
>
> In current state everything more or less works but I'd like to
> implement one improvement - I'd like to have an ability to specify
> where in memory will be allocated frame-buffer's backing storage area.
> I.e. buffer which will be read by PGU hardware.
>
> Currently we use whatever DRM susbsystem put in "gem->paddr".
> That's a snippet of the code which tells PGU hardware
> which memory location to scan for data:
> --------------------->8--------------------
>         arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
>         gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
>
>         /* Telling PGU hardware where is data to read */
>         arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
> --------------------->8--------------------
>
> But we may use a special memory area which works better
> for that case, i.e. for example could be accessed faster by both
> CPU and PGU hardware (like on-chip SRAM as opposed to external DDR).
>
> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.
>
> All thoughts on this are more than welcome.

Instead of using cma, you need to create your own gem buffer objects
and allocate the memory for those from wherever you want to. Or you
can do a mix of cma gem allocations and other objects (e.g. omapdrm
does that). Using cma (which simply uses dma_alloc_coherent
underneath) is just a convenient way, and generally the right choice
on SoC display drivers. There's no need to use that at all, KMS is
fully agnostic to how/what your underlying buffer objects even are.
You could have allocations in some sepcial secure memory that only the
gpu could even read/write, as another example.

Maybe we need to make this part in the overview docs better?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: Allocation of frame buffer at a specific memory range or address

[Daniel Vetter]

On Fri, Apr 15, 2016 at 5:48 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hello,
>
> I'm wondering if there's a way to force kernel to allocate backing
> memory for frame buffer in a special location?
>
> A little bit of background below.
> I continue to work on DRM driver for ARC PGU, latest
> is v5 and available here - https://lkml.org/lkml/2016/3/28/170
>
> In current state everything more or less works but I'd like to
> implement one improvement - I'd like to have an ability to specify
> where in memory will be allocated frame-buffer's backing storage area.
> I.e. buffer which will be read by PGU hardware.
>
> Currently we use whatever DRM susbsystem put in "gem->paddr".
> That's a snippet of the code which tells PGU hardware
> which memory location to scan for data:
> --------------------->8--------------------
>         arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
>         gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
>
>         /* Telling PGU hardware where is data to read */
>         arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
> --------------------->8--------------------
>
> But we may use a special memory area which works better
> for that case, i.e. for example could be accessed faster by both
> CPU and PGU hardware (like on-chip SRAM as opposed to external DDR).
>
> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.
>
> All thoughts on this are more than welcome.

Instead of using cma, you need to create your own gem buffer objects
and allocate the memory for those from wherever you want to. Or you
can do a mix of cma gem allocations and other objects (e.g. omapdrm
does that). Using cma (which simply uses dma_alloc_coherent
underneath) is just a convenient way, and generally the right choice
on SoC display drivers. There's no need to use that at all, KMS is
fully agnostic to how/what your underlying buffer objects even are.
You could have allocations in some sepcial secure memory that only the
gpu could even read/write, as another example.

Maybe we need to make this part in the overview docs better?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Allocation of frame buffer at a specific memory range or address

[Daniel Vetter]

On Fri, Apr 15, 2016 at 5:48 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hello,
>
> I'm wondering if there's a way to force kernel to allocate backing
> memory for frame buffer in a special location?
>
> A little bit of background below.
> I continue to work on DRM driver for ARC PGU, latest
> is v5 and available here - https://lkml.org/lkml/2016/3/28/170
>
> In current state everything more or less works but I'd like to
> implement one improvement - I'd like to have an ability to specify
> where in memory will be allocated frame-buffer's backing storage area.
> I.e. buffer which will be read by PGU hardware.
>
> Currently we use whatever DRM susbsystem put in "gem->paddr".
> That's a snippet of the code which tells PGU hardware
> which memory location to scan for data:
> --------------------->8--------------------
>         arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
>         gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
>
>         /* Telling PGU hardware where is data to read */
>         arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
> --------------------->8--------------------
>
> But we may use a special memory area which works better
> for that case, i.e. for example could be accessed faster by both
> CPU and PGU hardware (like on-chip SRAM as opposed to external DDR).
>
> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.
>
> All thoughts on this are more than welcome.

Instead of using cma, you need to create your own gem buffer objects
and allocate the memory for those from wherever you want to. Or you
can do a mix of cma gem allocations and other objects (e.g. omapdrm
does that). Using cma (which simply uses dma_alloc_coherent
underneath) is just a convenient way, and generally the right choice
on SoC display drivers. There's no need to use that at all, KMS is
fully agnostic to how/what your underlying buffer objects even are.
You could have allocations in some sepcial secure memory that only the
gpu could even read/write, as another example.

Maybe we need to make this part in the overview docs better?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Allocation of frame buffer at a specific memory range or address

[Vineet Gupta]

On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:

> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.

It seems this is pretty easy to do with DT reserved-memory binding.

You need to partition memory into @memory and @reserved-memory.
Later can be subdivided into more granular regions and your driver can refer to
one of the regions.

Something like below (untested)

+	memory {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0xA0000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		/* This memory bypasses IOC port */
+		fb_reserved at A0000000 {
+			reg = <0x0 0xA0000000 0x0 0xAF000000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			/* no-map;   */
+		};
+	};
+
+
+	fb0: video at 12300000 {
+		memory-region = <&fb_reserved>;
+		/* ... */
+	};

This might also need a DT helper in ARC mm init code.

+	early_init_fdt_scan_reserved_mem();

HTH,
-Vineet

Re: Allocation of frame buffer at a specific memory range or address

[Vineet Gupta]

On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:

> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.

It seems this is pretty easy to do with DT reserved-memory binding.

You need to partition memory into @memory and @reserved-memory.
Later can be subdivided into more granular regions and your driver can refer to
one of the regions.

Something like below (untested)

+	memory {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0xA0000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		/* This memory bypasses IOC port */
+		fb_reserved@A0000000 {
+			reg = <0x0 0xA0000000 0x0 0xAF000000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			/* no-map;   */
+		};
+	};
+
+
+	fb0: video@12300000 {
+		memory-region = <&fb_reserved>;
+		/* ... */
+	};

This might also need a DT helper in ARC mm init code.

+	early_init_fdt_scan_reserved_mem();

HTH,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Allocation of frame buffer at a specific memory range or address

[Vineet Gupta]

On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:

> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.

It seems this is pretty easy to do with DT reserved-memory binding.

You need to partition memory into @memory and @reserved-memory.
Later can be subdivided into more granular regions and your driver can refer to
one of the regions.

Something like below (untested)

+	memory {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0xA0000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		/* This memory bypasses IOC port */
+		fb_reserved@A0000000 {
+			reg = <0x0 0xA0000000 0x0 0xAF000000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			/* no-map;   */
+		};
+	};
+
+
+	fb0: video@12300000 {
+		memory-region = <&fb_reserved>;
+		/* ... */
+	};

This might also need a DT helper in ARC mm init code.

+	early_init_fdt_scan_reserved_mem();

HTH,
-Vineet

Allocation of frame buffer at a specific memory range or address

[Rob Clark]

On Sat, Apr 16, 2016 at 2:07 AM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
>
>> And now the question is how to force DRM subsystem or just that driver
>> to use whatever predefined (say via device tree) location in memory
>> for data buffer allocation.
>
> It seems this is pretty easy to do with DT reserved-memory binding.
>
> You need to partition memory into @memory and @reserved-memory.
> Later can be subdivided into more granular regions and your driver can refer to
> one of the regions.

jfyi, it might be useful to look at msm_init_vram() which has support
to wrap vram carveout as gem buffer, for exact same purpose..

BR,
-R


> Something like below (untested)
>
> +       memory {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0xA0000000>;
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +       };
> +
> +       reserved-memory {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +               /* This memory bypasses IOC port */
> +               fb_reserved at A0000000 {
> +                       reg = <0x0 0xA0000000 0x0 0xAF000000>;
> +                       #address-cells = <2>;
> +                       #size-cells = <2>;
> +                       /* no-map;   */
> +               };
> +       };
> +
> +
> +       fb0: video at 12300000 {
> +               memory-region = <&fb_reserved>;
> +               /* ... */
> +       };
>
> This might also need a DT helper in ARC mm init code.
>
> +       early_init_fdt_scan_reserved_mem();
>
> HTH,
> -Vineet

Re: Allocation of frame buffer at a specific memory range or address

[Rob Clark]

On Sat, Apr 16, 2016 at 2:07 AM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
>
>> And now the question is how to force DRM subsystem or just that driver
>> to use whatever predefined (say via device tree) location in memory
>> for data buffer allocation.
>
> It seems this is pretty easy to do with DT reserved-memory binding.
>
> You need to partition memory into @memory and @reserved-memory.
> Later can be subdivided into more granular regions and your driver can refer to
> one of the regions.

jfyi, it might be useful to look at msm_init_vram() which has support
to wrap vram carveout as gem buffer, for exact same purpose..

BR,
-R


> Something like below (untested)
>
> +       memory {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0xA0000000>;
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +       };
> +
> +       reserved-memory {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +               /* This memory bypasses IOC port */
> +               fb_reserved@A0000000 {
> +                       reg = <0x0 0xA0000000 0x0 0xAF000000>;
> +                       #address-cells = <2>;
> +                       #size-cells = <2>;
> +                       /* no-map;   */
> +               };
> +       };
> +
> +
> +       fb0: video@12300000 {
> +               memory-region = <&fb_reserved>;
> +               /* ... */
> +       };
>
> This might also need a DT helper in ARC mm init code.
>
> +       early_init_fdt_scan_reserved_mem();
>
> HTH,
> -Vineet
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Allocation of frame buffer at a specific memory range or address

[Rob Clark]

On Sat, Apr 16, 2016 at 2:07 AM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
>
>> And now the question is how to force DRM subsystem or just that driver
>> to use whatever predefined (say via device tree) location in memory
>> for data buffer allocation.
>
> It seems this is pretty easy to do with DT reserved-memory binding.
>
> You need to partition memory into @memory and @reserved-memory.
> Later can be subdivided into more granular regions and your driver can refer to
> one of the regions.

jfyi, it might be useful to look at msm_init_vram() which has support
to wrap vram carveout as gem buffer, for exact same purpose..

BR,
-R


> Something like below (untested)
>
> +       memory {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0xA0000000>;
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +       };
> +
> +       reserved-memory {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +               /* This memory bypasses IOC port */
> +               fb_reserved@A0000000 {
> +                       reg = <0x0 0xA0000000 0x0 0xAF000000>;
> +                       #address-cells = <2>;
> +                       #size-cells = <2>;
> +                       /* no-map;   */
> +               };
> +       };
> +
> +
> +       fb0: video@12300000 {
> +               memory-region = <&fb_reserved>;
> +               /* ... */
> +       };
>
> This might also need a DT helper in ARC mm init code.
>
> +       early_init_fdt_scan_reserved_mem();
>
> HTH,
> -Vineet