From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH] video: simplefb: add mode parsing function Date: Thu, 23 May 2013 13:21:27 -0600 Message-ID: <519E6C37.2010706@wwwdotorg.org> References: <1369296231-26597-1-git-send-email-acourbot@nvidia.com> <519E438A.9030408@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Geert Uytterhoeven Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Linux Fbdev development list , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Alexandre Courbot , Andrew Morton List-Id: devicetree@vger.kernel.org On 05/23/2013 10:57 AM, Geert Uytterhoeven wrote: > On Thu, May 23, 2013 at 6:27 PM, Stephen Warren wrote: >>> + >>> + cpt += field->length; >>> + } >>> + >>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8; >> >> Should this error-check that isn't > 32? > > So pixels can't be larger than 32 bits? > IIRC, some SGI and Sun graphics cards had e.g. 80 bit pixels (incl. Z buffer). That's a good point. Out of curiosity, how does the FB core treat these format definitions? Are they expected to fit into a 16-/32-/64-/128- bit power-of-two bit-size, or are they treated as a string of bytes that get serialized into memory LSB first (or perhaps MSB first on BE systems?) The difference would be that from a CPU perspective only, if you pack the RGB components into a u32, then write that to RAM as a u32, then the in-memory byte-by-byte order is different on different endian systems, whereas if the FB core treats it as a series of bytes only, then presumably the in-memory byte-by-byte order is identical irrespective of host CPU endianness.