From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: Allocation of frame buffer at a specific memory range or address
Date: Sat, 16 Apr 2016 11:37:20 +0530 [thread overview]
Message-ID: <5711D698.4030606@synopsys.com> (raw)
In-Reply-To: <1460735338.3248.21.camel@synopsys.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
To: Alexey Brodkin
<Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "daniel-/w4YWyX8dFk@public.gmane.org"
<daniel-/w4YWyX8dFk@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"airlied-cv59FeDIM0c@public.gmane.org"
<airlied-cv59FeDIM0c@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: Allocation of frame buffer at a specific memory range or address
Date: Sat, 16 Apr 2016 11:37:20 +0530 [thread overview]
Message-ID: <5711D698.4030606@synopsys.com> (raw)
In-Reply-To: <1460735338.3248.21.camel-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Cc: "daniel@ffwll.ch" <daniel@ffwll.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"airlied@linux.ie" <airlied@linux.ie>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Rob Herring <robh@kernel.org>
Subject: Re: Allocation of frame buffer at a specific memory range or address
Date: Sat, 16 Apr 2016 11:37:20 +0530 [thread overview]
Message-ID: <5711D698.4030606@synopsys.com> (raw)
In-Reply-To: <1460735338.3248.21.camel@synopsys.com>
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
next prev parent reply other threads:[~2016-04-16 6:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 15:48 Allocation of frame buffer at a specific memory range or address Alexey Brodkin
2016-04-15 15:48 ` Alexey Brodkin
2016-04-15 16:42 ` Daniel Vetter
2016-04-15 16:42 ` Daniel Vetter
2016-04-15 16:42 ` Daniel Vetter
2016-04-16 6:07 ` Vineet Gupta [this message]
2016-04-16 6:07 ` Vineet Gupta
2016-04-16 6:07 ` Vineet Gupta
2016-04-16 21:48 ` Rob Clark
2016-04-16 21:48 ` Rob Clark
2016-04-16 21:48 ` Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5711D698.4030606@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.