From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
Date: Thu, 28 Apr 2016 13:46:22 +0000 [thread overview]
Message-ID: <1461851171.3673.30.camel@synopsys.com> (raw)
In-Reply-To: <572190F3.3020709@synopsys.com>
Hi Vineet,
On Thu, 2016-04-28@09:56 +0530, Vineet Gupta wrote:
[snip]
> >
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> > ? #size-cells = <1>;
> > ? ranges = <0x00000000 0x80000000 0x40000000>;
> > ? device_type = "memory";
> > - reg = <0x80000000 0x20000000>; /* 512MiB */
> > + reg = <0x80000000 0x1f000000>; /* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.
Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).
So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.
But now I recalled that we also support?r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.
[snip]
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + /*
> > + ?* Move frame buffer out of IOC aperture (0x8z-0xAz).
> > + ?*/
> > + frame_buffer: frame_buffer at bf000000 {
> > + compatible = "shared-dma-pool";
> > + reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.
Makes sense. Will move it to the very end of 1Gb.
> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !
What do you mean by that?
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
To: Vineet Gupta <Vineet.Gupta1-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Cc: "dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
Date: Thu, 28 Apr 2016 13:46:22 +0000 [thread overview]
Message-ID: <1461851171.3673.30.camel@synopsys.com> (raw)
In-Reply-To: <572190F3.3020709-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Vineet,
On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:
[snip]
> >
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> > #size-cells = <1>;
> > ranges = <0x00000000 0x80000000 0x40000000>;
> > device_type = "memory";
> > - reg = <0x80000000 0x20000000>; /* 512MiB */
> > + reg = <0x80000000 0x1f000000>; /* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.
Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).
So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.
But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.
[snip]
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + /*
> > + * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > + */
> > + frame_buffer: frame_buffer@bf000000 {
> > + compatible = "shared-dma-pool";
> > + reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.
Makes sense. Will move it to the very end of 1Gb.
> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !
What do you mean by that?
-Alexey--
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: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
Date: Thu, 28 Apr 2016 13:46:22 +0000 [thread overview]
Message-ID: <1461851171.3673.30.camel@synopsys.com> (raw)
In-Reply-To: <572190F3.3020709@synopsys.com>
Hi Vineet,
On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:
[snip]
> >
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> > #size-cells = <1>;
> > ranges = <0x00000000 0x80000000 0x40000000>;
> > device_type = "memory";
> > - reg = <0x80000000 0x20000000>; /* 512MiB */
> > + reg = <0x80000000 0x1f000000>; /* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.
Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).
So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.
But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.
[snip]
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + /*
> > + * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > + */
> > + frame_buffer: frame_buffer@bf000000 {
> > + compatible = "shared-dma-pool";
> > + reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.
Makes sense. Will move it to the very end of 1Gb.
> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !
What do you mean by that?
-Alexey
next prev parent reply other threads:[~2016-04-28 13:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 14:34 [PATCH 0/2] drm/arcpgu: Get use of dedicated memory area for frame buffer Alexey Brodkin
2016-04-27 14:34 ` Alexey Brodkin
2016-04-27 14:35 ` [PATCH 1/2] drm/arcpgu: use " Alexey Brodkin
2016-04-27 14:35 ` Alexey Brodkin
2016-04-27 14:35 ` Alexey Brodkin
2016-04-27 14:35 ` [PATCH 2/2] ARC: [axs10x] Specify reserved memory " Alexey Brodkin
2016-04-27 14:35 ` Alexey Brodkin
2016-04-27 14:35 ` Alexey Brodkin
2016-04-28 4:26 ` Vineet Gupta
2016-04-28 4:26 ` Vineet Gupta
2016-04-28 4:26 ` Vineet Gupta
2016-04-28 13:46 ` Alexey Brodkin [this message]
2016-04-28 13:46 ` Alexey Brodkin
2016-04-28 13:46 ` Alexey Brodkin
2016-04-28 13:56 ` Vineet Gupta
2016-04-28 13:56 ` Vineet Gupta
2016-04-28 13:56 ` Vineet Gupta
2016-04-28 14:38 ` Alexey Brodkin
2016-04-28 14:38 ` Alexey Brodkin
2016-04-28 14:38 ` Alexey Brodkin
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=1461851171.3673.30.camel@synopsys.com \
--to=alexey.brodkin@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.