From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey.Brodkin@synopsys.com (Alexey Brodkin) Date: Thu, 28 Apr 2016 13:46:22 +0000 Subject: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer In-Reply-To: <572190F3.3020709@synopsys.com> References: <1461767701-12208-1-git-send-email-abrodkin@synopsys.com> <1461767701-12208-3-git-send-email-abrodkin@synopsys.com> <572190F3.3020709@synopsys.com> List-ID: Message-ID: <1461851171.3673.30.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Subject: Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer Date: Thu, 28 Apr 2016 13:46:22 +0000 Message-ID: <1461851171.3673.30.camel@synopsys.com> References: <1461767701-12208-1-git-send-email-abrodkin@synopsys.com> <1461767701-12208-3-git-send-email-abrodkin@synopsys.com> <572190F3.3020709@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <572190F3.3020709-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> Content-Language: en-US Content-ID: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Vineet Gupta Cc: "dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org Hi Vineet, On Thu, 2016-04-28 at 09:56 +-0530, Vineet Gupta wrote: +AFs-snip+AF0- +AD4- +AD4- +AD4- +AD4- diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- index 420dcfd..ae6162d 100644 +AD4- +AD4- --- a/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- +-+-+- b/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- +AEAAQA- -95,6 +-95,24 +AEAAQA- +AD4- +AD4- +AKA- +ACM-size-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +AKA- ranges +AD0- +ADw-0x00000000 0x80000000 0x40000000+AD4AOw- +AD4- +AD4- +AKA- device+AF8-type +AD0- +ACI-memory+ACIAOw- +AD4- +AD4- - reg +AD0- +ADw-0x80000000 0x20000000+AD4AOw- /+ACo- 512MiB +ACo-/ +AD4- +AD4- +- reg +AD0- +ADw-0x80000000 0x1f000000+AD4AOw- /+ACo- 512 - 16 MiB +ACo-/ +AD4- 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 +AH4-4Mb. Now if we add support of triple-buffering we'll need +AH4-12Mb so I booked a little bit more - 16Mb. But now I recalled that we also support+AKA-r8g8b8 mode and in this case 3 bytes are used for color encoding, which effectively gives +AH4-6Mb for 1 FullHD frame. And for tripple-buffering we'll need +AD4- 18Mb, so probably we'll need to go for 24 or even 32 Mb. +AFs-snip+AF0- +AD4- +AD4- +- +AD4- +AD4- +- reserved-memory +AHs- +AD4- +AD4- +- +ACM-address-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +- +ACM-size-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +- ranges+ADs- +AD4- +AD4- +- /+ACo- +AD4- +AD4- +- +AKAAKg- Move frame buffer out of IOC aperture (0x8z-0xAz). +AD4- +AD4- +- +AKAAKg-/ +AD4- +AD4- +- frame+AF8-buffer: frame+AF8-buffer+AEA-bf000000 +AHs- +AD4- +AD4- +- compatible +AD0- +ACI-shared-dma-pool+ACIAOw- +AD4- +AD4- +- reg +AD0- +ADw-0xbf000000 0x1000000+AD4AOw- +AD4- Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel +AD4- currently only uses 512M. Once we increase that, this will need fixing too. Better +AD4- to make this as far possible. Makes sense. Will move it to the very end of 1Gb. +AD4- Note that the IOC start alignment needs to follow +AD4- max(4k, size). What will be maximum size of frame buffer - 16M always +ACE- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbcD1Nqa (ORCPT ); Thu, 28 Apr 2016 09:46:30 -0400 Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:36508 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752363AbcD1Nq3 convert rfc822-to-8bit (ORCPT ); Thu, 28 Apr 2016 09:46:29 -0400 From: Alexey Brodkin To: Vineet Gupta CC: "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer Thread-Topic: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer Thread-Index: AQHRoJINTxhBRt4+OUilnhwOEeS1I5+eqZeAgACcY4A= Date: Thu, 28 Apr 2016 13:46:22 +0000 Message-ID: <1461851171.3673.30.camel@synopsys.com> References: <1461767701-12208-1-git-send-email-abrodkin@synopsys.com> <1461767701-12208-3-git-send-email-abrodkin@synopsys.com> <572190F3.3020709@synopsys.com> In-Reply-To: <572190F3.3020709@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.131] Content-Type: text/plain; charset="utf-7" Content-ID: Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vineet, On Thu, 2016-04-28 at 09:56 +-0530, Vineet Gupta wrote: +AFs-snip+AF0- +AD4- +AD4- +AD4- +AD4- diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- index 420dcfd..ae6162d 100644 +AD4- +AD4- --- a/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- +-+-+- b/arch/arc/boot/dts/axc001.dtsi +AD4- +AD4- +AEAAQA- -95,6 +-95,24 +AEAAQA- +AD4- +AD4- +AKA- +ACM-size-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +AKA- ranges +AD0- +ADw-0x00000000 0x80000000 0x40000000+AD4AOw- +AD4- +AD4- +AKA- device+AF8-type +AD0- +ACI-memory+ACIAOw- +AD4- +AD4- - reg +AD0- +ADw-0x80000000 0x20000000+AD4AOw- /+ACo- 512MiB +ACo-/ +AD4- +AD4- +- reg +AD0- +ADw-0x80000000 0x1f000000+AD4AOw- /+ACo- 512 - 16 MiB +ACo-/ +AD4- 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 +AH4-4Mb. Now if we add support of triple-buffering we'll need +AH4-12Mb so I booked a little bit more - 16Mb. But now I recalled that we also support+AKA-r8g8b8 mode and in this case 3 bytes are used for color encoding, which effectively gives +AH4-6Mb for 1 FullHD frame. And for tripple-buffering we'll need +AD4- 18Mb, so probably we'll need to go for 24 or even 32 Mb. +AFs-snip+AF0- +AD4- +AD4- +- +AD4- +AD4- +- reserved-memory +AHs- +AD4- +AD4- +- +ACM-address-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +- +ACM-size-cells +AD0- +ADw-1+AD4AOw- +AD4- +AD4- +- ranges+ADs- +AD4- +AD4- +- /+ACo- +AD4- +AD4- +- +AKAAKg- Move frame buffer out of IOC aperture (0x8z-0xAz). +AD4- +AD4- +- +AKAAKg-/ +AD4- +AD4- +- frame+AF8-buffer: frame+AF8-buffer+AEA-bf000000 +AHs- +AD4- +AD4- +- compatible +AD0- +ACI-shared-dma-pool+ACIAOw- +AD4- +AD4- +- reg +AD0- +ADw-0xbf000000 0x1000000+AD4AOw- +AD4- Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel +AD4- currently only uses 512M. Once we increase that, this will need fixing too. Better +AD4- to make this as far possible. Makes sense. Will move it to the very end of 1Gb. +AD4- Note that the IOC start alignment needs to follow +AD4- max(4k, size). What will be maximum size of frame buffer - 16M always +ACE- What do you mean by that? -Alexey