From patchwork Mon Nov 12 13:57:34 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomi Valkeinen X-Patchwork-Id: 1728291 Return-Path: X-Original-To: patchwork-linux-fbdev@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 74DD5DFE80 for ; Mon, 12 Nov 2012 13:57:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752040Ab2KLN5k (ORCPT ); Mon, 12 Nov 2012 08:57:40 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:42508 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628Ab2KLN5k (ORCPT ); Mon, 12 Nov 2012 08:57:40 -0500 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id qACDvbFC027060; Mon, 12 Nov 2012 07:57:37 -0600 Received: from DLEE74.ent.ti.com (dlee74.ent.ti.com [157.170.170.8]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id qACDvbDO027944; Mon, 12 Nov 2012 07:57:37 -0600 Received: from dlelxv22.itg.ti.com (172.17.1.197) by DLEE74.ent.ti.com (157.170.170.8) with Microsoft SMTP Server id 14.1.323.3; Mon, 12 Nov 2012 07:57:36 -0600 Received: from [172.24.68.17] (h68-17.vpn.ti.com [172.24.68.17]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id qACDvZqn011530; Mon, 12 Nov 2012 07:57:35 -0600 Message-ID: <50A1004E.8000203@ti.com> Date: Mon, 12 Nov 2012 15:57:34 +0200 From: Tomi Valkeinen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Grazvydas Ignotas CC: , , , , Subject: Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram References: <1352715906-16946-1-git-send-email-tomi.valkeinen@ti.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org On 2012-11-12 15:39, Grazvydas Ignotas wrote: > Hi, > > On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen wrote: >> This series changes omapfb to use standard dma_alloc funcs instead of omap >> specific vram allocator. This let's us remove the omap vram allocator, making >> omapfb platform independent. >> >> However, note that using standard dma funcs causes the following downsides: >> >> ... >> >> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I >> changed the ioctl to return 64M for all the values, which, I hope, the >> applications will interpret as "there's enough vram". > > Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? > >> 4) "vram" kernel parameter to define how much ram to reserve for video use no >> longer works. The user needs to enable CMA and use "cma" parameter. > > That's a significant change, you should update Documentation/ . I've added the following documentation change: diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index a564cee..4484e02 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD Misc notes ---------- -OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. +OMAP FB allocates the framebuffer memory using the standard dma allocator. You +can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma +allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase +the global memory area for CMA. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. @@ -301,11 +304,6 @@ framebuffer parameters. Kernel boot arguments --------------------- -vram=[,] - - Amount of total VRAM to preallocate and optionally a physical start - memory address. For example, "10M". omapfb allocates memory for - framebuffers from VRAM. -