From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754871AbbCBTKF (ORCPT ); Mon, 2 Mar 2015 14:10:05 -0500 Received: from mail-gw3-out.broadcom.com ([216.31.210.64]:48716 "EHLO mail-gw3-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbbCBTJ7 (ORCPT ); Mon, 2 Mar 2015 14:09:59 -0500 X-IronPort-AV: E=Sophos;i="5.09,676,1418112000"; d="scan'208";a="58219163" Message-ID: <54F4B57F.3030306@broadcom.com> Date: Mon, 2 Mar 2015 11:09:51 -0800 From: Arun Ramamurthy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Russell King - ARM Linux , Pawel Moll CC: Rob Herring , Mark Rutland , Ian Campbell , Kumar Gala , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , Dmitry Torokhov , Anatol Pomazau , Jonathan Richardson , Scott Branden , Ray Jui , "bcm-kernel-feedback-list@broadcom.com" Subject: Re: [PATCH] video: ARM CLCD: Added support for FBIOPAN_DISPLAY and virtual y resolution References: <1424898082-1522-1-git-send-email-arun.ramamurthy@broadcom.com> <1424898082-1522-2-git-send-email-arun.ramamurthy@broadcom.com> <1425312509.3092.7.camel@arm.com> <20150302161122.GP8656@n2100.arm.linux.org.uk> In-Reply-To: <20150302161122.GP8656@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15-03-02 08:11 AM, Russell King - ARM Linux wrote: > On Mon, Mar 02, 2015 at 04:08:29PM +0000, Pawel Moll wrote: >> I'm not sure about this... The word "virtual" never works well with >> device tree nodes defined as "hardware description". >> >> I understand what you're doing, but adding this property to the display >> controller's node doesn't sound right. How does this describe hardware? >> If anywhere, it's more like a job for the panel node? > I see what you are saying Pawel, I can follow Russell's recommendation of adding a RAM size node called max-memory-available or something similar > A better description (and implementation) would be to describe the size > of the RAM available for video purposes. The driver can then use the > requested virtual X resolution to limit (and/or compute) the virtual Y > resolution to allow Y panning/wrapping of the display. > In this scenario, where would I specify the virtual X resolution? I am assuming it would be in the panel-timing node as Pawel suggested? > This would match some hardware where the video RAM is indeed a separate > physical set of RAM (such as the IM-PD/1). >