Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbcKUCl3 convert rfc822-to-8bit (ORCPT ); Sun, 20 Nov 2016 21:41:29 -0500 Received: from mga01.intel.com ([192.55.52.88]:34133 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbcKUCl2 (ORCPT ); Sun, 20 Nov 2016 21:41:28 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,524,1473145200"; d="scan'208";a="1088209186" Message-ID: <1479696084.2822.4.camel@intel.com> Subject: Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver From: "Ong, Hean Loong" To: Rob Herring , One Thousand Gnomes Cc: Tomi Valkeinen , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" Date: Mon, 21 Nov 2016 10:41:24 +0800 In-Reply-To: References: <1479287278-5192-1-git-send-email-hean.loong.ong@intel.com> <20161118140903.q33zx7bk5nergq45@rob-hp-laptop> <20161118141547.465c431e@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1115 Lines: 31 On Fri, 2016-11-18 at 12:56 -0600, Rob Herring wrote: > On Fri, Nov 18, 2016 at 8:15 AM, One Thousand Gnomes > wrote: > > > > > > > > AIUI, we're not taking new FB drivers. This should be a DRM > > > driver > > > instead. > > Yes - clone one of the dumb DRM drivers, or if you've got any > > little bits > > of acceleration (even rolling the display) then it's possibly worth > > accelerating for text mode. > > > > > > > > > > > > > +- max-width: The width of the framebuffer in pixels. > > > > +- max-height: The height of the framebuffer in pixels. > > > > +- bits-per-color: only "8" is currently supported > > > These are not h/w properties. > > How are the max ones not hardware properties ? > Because the way they are used is setting the mode, not some check of > the max when the mode is set. If this is synthesized for only one > size, then that would be different, but we have bindings for modes. > > Rob Currently the idea is to just synthesize the display to just 1920 x 1080. Therefore we came to a conclusion that it should be part of the HW properties. HeanLoong