From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D6C7C83004 for ; Tue, 28 Apr 2020 09:05:36 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E3FD9206E2 for ; Tue, 28 Apr 2020 09:05:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kGCgKDpc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3FD9206E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BRrmQIokemQBGx1hObyKY2pynfFPaP5wQYOvRaTknBU=; b=kGCgKDpcBM/V2h 0UWRl6Bqyd2utL1oxakyBcUaGrYh0zjLJljbvIgew3/9xvIoFVU+j7CxWHWTJ/3J8jJwncvwSXdz1 P6BHsWE1bqkrOAo9dHmxC9z+gGAUBO4+xHrMhwGu9lzbAk4+noeoQDzhdi/sTvZGyckPo1bvxHiIP PmTXh9pXaswp4q7TEgMTj78SdVSijzpkMV01qapupKe1QbkSMwp0IXNy+A6D1JurnlBYIdVApzunG j1bHdLhmtDE3omS2IUpokq1tI/kv9Mbv4iYE5ZAkPBdHpQZ4KcWZaR3/bWzz/GznmHC0sOa1WkXVa +VFwp7eeRqVl0D5g+CkA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTMBJ-0003eX-0X; Tue, 28 Apr 2020 09:05:33 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTMBF-0003d2-Uk for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2020 09:05:31 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2F4BF30E; Tue, 28 Apr 2020 02:05:27 -0700 (PDT) Received: from [10.57.41.45] (unknown [10.57.41.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6399E3F305; Tue, 28 Apr 2020 02:05:25 -0700 (PDT) Subject: Re: [PATCH 2/2] arm: dts: stm32f769-disco: Enable MIPI DSI display support To: Adrian Pop , Alexandre Torgue , Lee Jones References: <20200424182139.32190-1-pop.adrian61@gmail.com> <3efb57a1-283b-f2f0-66a4-97e88c6c02d6@st.com> From: Vladimir Murzin Message-ID: <81d9b932-ef2d-6d5c-9a58-2edb88e7e593@arm.com> Date: Tue, 28 Apr 2020 10:05:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200428_020530_074396_CFDB3DDC X-CRM114-Status: GOOD ( 20.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Maxime Coquelin , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Adrian, On 4/27/20 9:05 PM, Adrian Pop wrote: > Added lee.jones@linaro.org. > > First, thank you all for taking a look at my changes! > > Hello Alex, > > On Mon, Apr 27, 2020 at 11:28 AM Alexandre Torgue > wrote: >> >> Hi Adrian >> >> On 4/24/20 8:21 PM, Adrian Pop wrote: >>> STM32f769-disco features a 4" MIPI DSI display: add support for it. >>> >>> Signed-off-by: Adrian Pop >>> --- >> >> Commit title should be ARM: dts: stm32: ... > > Will fix in next version if that's ok. > >> >> Can you explain a bit more in your commit message why do you use a >> reserved memory pool for DMA and where this pool is located. (I assume >> it's linked to a story of DMA and cache memory attribute on cortexM7...) > > Need to look more into this, but if I remove it, /dev/fb0 is not > available anymore and I get a warning stating: > ... > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] Initialized stm 1.0.0 20170330 for 40016800.display-controller on minor 0 > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 13 at arch/arm/mm/dma-mapping-nommu.c:50 0xc000b8ed > CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 5.6.0-next-20200412 #23 > Hardware name: STM32 (Device Tree Support) > Workqueue: events 0xc014fa35 > Function entered at [] from [] > ... > > When I looked in arch/arm/mm/dma-mapping-nommu.c:50, there is a comment stating: > > /* > * dma_alloc_from_global_coherent() may fail because: > * > * - no consistent DMA region has been defined, so we can't > * continue. > * - there is no space left in consistent DMA region, so we > * only can fallback to generic allocator if we are > * advertised that consistency is not required. > */ > > This is the reason I added the reserved-memory. > > About the location, does it need to be hardcoded? On my board > (STM32F769I-Disco, tftp boot) in boot log I get: > ... > Reserved memory: created DMA memory pool at 0xc0ef1000, size 1 MiB > OF: reserved mem: initialized node linux,dma, compatible id shared-dma-pool > ... > I'd recommend to place it at specific address, otherwise it will play badly with CONFIG_MPU=y. MPU covers only single contiguous memblock (due to limitations in number of available MPU regions), so placing DMA pool anywhere may result in split of such contiguous memblock, as effect you may see that some memory is not used. Usually, folks place DMA pool at the end of RAM. >> >> Did you try this configuration with XIP boot ? > > I did not try with XIP. Currently loading zImage from tftp to memory. > Will try with XIP as well, and get back with feedback. > Bear in mind that with CONFIG_MPU=y XIP start address need to be aligned to 1M. Cheers Vladimir _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel