From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from host.buserror.net (host.buserror.net [209.198.135.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3vxqVm0zCmzDq5W for ; Tue, 4 Apr 2017 10:25:03 +1000 (AEST) Message-ID: <1491265487.2944.71.camel@buserror.net> From: Scott Wood To: Robin Murphy , Michael Ellerman , roy.pledge@nxp.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org Cc: Mark Rutland , madalin.bucur@nxp.com Date: Mon, 03 Apr 2017 19:24:47 -0500 In-Reply-To: References: <1490822037-6752-1-git-send-email-roy.pledge@nxp.com> <1490822037-6752-3-git-send-email-roy.pledge@nxp.com> <871ste5dmw.fsf@concordia.ellerman.id.au> <1491031518.2944.62.camel@buserror.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Subject: Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 2017-04-03 at 15:52 +0100, Robin Murphy wrote: > On 01/04/17 08:25, Scott Wood wrote: > > > > On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote: > > > > > > On 31/03/17 04:27, Michael Ellerman wrote: > > > > > > > > > > > > Robin Murphy writes: > > > > > > > > > > > > > > > > > > > Hi Roy, > > > > > > > > > > On 29/03/17 22:13, Roy Pledge wrote: > > > > > > > > > > > > > > > > > > Use the shared-memory-pool mechanism for frame queue descriptor > > > > > > and > > > > > > packed frame descriptor record area allocations. > > > > > Thanks for persevering with this - in my opinion it's now looking > > > > > like > > > > > it was worth the effort :) > > > > > > > > > > AFAICS the ioremap_wc() that this leads to does appear to give back > > > > > something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't > > > > > horrendously misnamed), and "no-map" should rule out any cacheable > > > > > linear map alias existing, so it would seem that this approach > > > > > should > > > > > avert Scott's concerns about attribute mismatches. > > > > How does 'no-map' translate into something being excluded from the > > > > linear mapping? > > > Reserved regions marked with "no-map" get memblock_remove()d by > > > early_init_dt_alloc_reserved_memory_arch(). As I understand things, the > > > linear map should only cover memblock areas, and it would be explicitly > > > violating the semantics of "no-map" to still cover such a region. > > Discontiguous memory isn't supported on these PPC chips.  Everything up to > > memblock_end_of_DRAM() gets mapped -- and if that were to change, the > > fragmentation would waste TLB1 entries. > Ah, so the "PPC-specific angles I'm not aware of" category is indeed > non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be > related, then. > > That said, though, AFAICS only certain x86 and s390 configurations ever > call memblock_set_bottom_up(true), so we should be able to assume that > the reserved region allocations always fall through to > __memblock_find_range_top_down(). Thus if your DRAM is contiguous, then > "no-map"-ing the reserved regions will simply end up pushing > memblock_end_of_DRAM() down in a manner that would appear to still avoid > overlaps. Can you guarantee it will be at the end?  What if there were other early memblock allocations (e.g. other reserved-memory regions without no-map) that came first? > I can only see that going wrong if the end of DRAM wasn't at > least 32MB aligned to begin with - is that ever likely to happen in > practice? Probably not, unless the user asks for an unusual memory size via mem= or similar. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: oss@buserror.net (Scott Wood) Date: Mon, 03 Apr 2017 19:24:47 -0500 Subject: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations In-Reply-To: References: <1490822037-6752-1-git-send-email-roy.pledge@nxp.com> <1490822037-6752-3-git-send-email-roy.pledge@nxp.com> <871ste5dmw.fsf@concordia.ellerman.id.au> <1491031518.2944.62.camel@buserror.net> Message-ID: <1491265487.2944.71.camel@buserror.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2017-04-03 at 15:52 +0100, Robin Murphy wrote: > On 01/04/17 08:25, Scott Wood wrote: > > > > On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote: > > > > > > On 31/03/17 04:27, Michael Ellerman wrote: > > > > > > > > > > > > Robin Murphy writes: > > > > > > > > > > > > > > > > > > > Hi Roy, > > > > > > > > > > On 29/03/17 22:13, Roy Pledge wrote: > > > > > > > > > > > > > > > > > > Use the shared-memory-pool mechanism for frame queue descriptor > > > > > > and > > > > > > packed frame descriptor record area allocations. > > > > > Thanks for persevering with this - in my opinion it's now looking > > > > > like > > > > > it was worth the effort :) > > > > > > > > > > AFAICS the ioremap_wc() that this leads to does appear to give back > > > > > something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't > > > > > horrendously misnamed), and "no-map" should rule out any cacheable > > > > > linear map alias existing, so it would seem that this approach > > > > > should > > > > > avert Scott's concerns about attribute mismatches. > > > > How does 'no-map' translate into something being excluded from the > > > > linear mapping? > > > Reserved regions marked with "no-map" get memblock_remove()d by > > > early_init_dt_alloc_reserved_memory_arch(). As I understand things, the > > > linear map should only cover memblock areas, and it would be explicitly > > > violating the semantics of "no-map" to still cover such a region. > > Discontiguous memory isn't supported on these PPC chips.??Everything up to > > memblock_end_of_DRAM() gets mapped -- and if that were to change, the > > fragmentation would waste TLB1 entries. > Ah, so the "PPC-specific angles I'm not aware of" category is indeed > non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be > related, then. > > That said, though, AFAICS only certain x86 and s390 configurations ever > call memblock_set_bottom_up(true), so we should be able to assume that > the reserved region allocations always fall through to > __memblock_find_range_top_down(). Thus if your DRAM is contiguous, then > "no-map"-ing the reserved regions will simply end up pushing > memblock_end_of_DRAM() down in a manner that would appear to still avoid > overlaps. Can you guarantee it will be at the end? ?What if there were other early memblock allocations (e.g. other reserved-memory regions without no-map) that came first? > I can only see that going wrong if the end of DRAM wasn't at > least 32MB aligned to begin with - is that ever likely to happen in > practice? Probably not, unless the user asks for an unusual memory size via mem= or similar. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations Date: Mon, 03 Apr 2017 19:24:47 -0500 Message-ID: <1491265487.2944.71.camel@buserror.net> References: <1490822037-6752-1-git-send-email-roy.pledge@nxp.com> <1490822037-6752-3-git-send-email-roy.pledge@nxp.com> <871ste5dmw.fsf@concordia.ellerman.id.au> <1491031518.2944.62.camel@buserror.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Robin Murphy , Michael Ellerman , roy.pledge-3arQi8VN3Tc@public.gmane.org, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: Mark Rutland , madalin.bucur-3arQi8VN3Tc@public.gmane.org List-Id: devicetree@vger.kernel.org On Mon, 2017-04-03 at 15:52 +0100, Robin Murphy wrote: > On 01/04/17 08:25, Scott Wood wrote: > > > > On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote: > > > > > > On 31/03/17 04:27, Michael Ellerman wrote: > > > > > > > > > > > > Robin Murphy writes: > > > > > > > > > > > > > > > > > > > Hi Roy, > > > > > > > > > > On 29/03/17 22:13, Roy Pledge wrote: > > > > > > > > > > > > > > > > > > Use the shared-memory-pool mechanism for frame queue descriptor > > > > > > and > > > > > > packed frame descriptor record area allocations. > > > > > Thanks for persevering with this - in my opinion it's now looking > > > > > like > > > > > it was worth the effort :) > > > > > > > > > > AFAICS the ioremap_wc() that this leads to does appear to give back > > > > > something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't > > > > > horrendously misnamed), and "no-map" should rule out any cacheable > > > > > linear map alias existing, so it would seem that this approach > > > > > should > > > > > avert Scott's concerns about attribute mismatches. > > > > How does 'no-map' translate into something being excluded from the > > > > linear mapping? > > > Reserved regions marked with "no-map" get memblock_remove()d by > > > early_init_dt_alloc_reserved_memory_arch(). As I understand things, the > > > linear map should only cover memblock areas, and it would be explicitly > > > violating the semantics of "no-map" to still cover such a region. > > Discontiguous memory isn't supported on these PPC chips.  Everything up to > > memblock_end_of_DRAM() gets mapped -- and if that were to change, the > > fragmentation would waste TLB1 entries. > Ah, so the "PPC-specific angles I'm not aware of" category is indeed > non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be > related, then. > > That said, though, AFAICS only certain x86 and s390 configurations ever > call memblock_set_bottom_up(true), so we should be able to assume that > the reserved region allocations always fall through to > __memblock_find_range_top_down(). Thus if your DRAM is contiguous, then > "no-map"-ing the reserved regions will simply end up pushing > memblock_end_of_DRAM() down in a manner that would appear to still avoid > overlaps. Can you guarantee it will be at the end?  What if there were other early memblock allocations (e.g. other reserved-memory regions without no-map) that came first? > I can only see that going wrong if the end of DRAM wasn't at > least 32MB aligned to begin with - is that ever likely to happen in > practice? Probably not, unless the user asks for an unusual memory size via mem= or similar. -Scott -- 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