From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 20 May 2013 15:25:46 +0000 Subject: Re: [PATCH V2] video: implement a simple framebuffer driver Message-Id: <519A407A.4040006@wwwdotorg.org> List-Id: References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On 05/18/2013 04:29 AM, Alexandre Courbot wrote: > On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren wrote: >> +struct simplefb_format { >> + const char *name; >> + u32 bits_per_pixel; >> + struct fb_bitfield red; >> + struct fb_bitfield green; >> + struct fb_bitfield blue; >> + struct fb_bitfield transp; >> +}; >> + >> +struct simplefb_format simplefb_formats[] = { >> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} }, >> +}; > > I have been adding a few extra formats to this list, and I wonder if > this could not simply be turned into a function that would directly > convert the name string into the corresponding right format. The > mapping between name and format seems to be a 1:1 and this would > probably avoid errors in the future. I'm especially thinking about > color order here - I started adding a mode that reads > > { "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} }, > > while it should probably be called "a8b8g8r8" as the order of colors > is not the same as your r5g6b5. > > I can submit a patch if there is no issue with that idea. I chose r5g6b5 rather than rgb565 specifically to make that format trivially name machine-parsable. So, I'm not opposed to converting that table to code. I'm not 100% sure if it's worth it or necessary by the time we get to just 2 formats in the array, but I don't see any big disadvantage, so why not. The DT binding documentation might want enhancing with a more general description of how formats should be represented if this is implemented. From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Mon, 20 May 2013 09:25:46 -0600 Subject: [PATCH V2] video: implement a simple framebuffer driver In-Reply-To: References: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <519A407A.4040006@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/18/2013 04:29 AM, Alexandre Courbot wrote: > On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren wrote: >> +struct simplefb_format { >> + const char *name; >> + u32 bits_per_pixel; >> + struct fb_bitfield red; >> + struct fb_bitfield green; >> + struct fb_bitfield blue; >> + struct fb_bitfield transp; >> +}; >> + >> +struct simplefb_format simplefb_formats[] = { >> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} }, >> +}; > > I have been adding a few extra formats to this list, and I wonder if > this could not simply be turned into a function that would directly > convert the name string into the corresponding right format. The > mapping between name and format seems to be a 1:1 and this would > probably avoid errors in the future. I'm especially thinking about > color order here - I started adding a mode that reads > > { "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} }, > > while it should probably be called "a8b8g8r8" as the order of colors > is not the same as your r5g6b5. > > I can submit a patch if there is no issue with that idea. I chose r5g6b5 rather than rgb565 specifically to make that format trivially name machine-parsable. So, I'm not opposed to converting that table to code. I'm not 100% sure if it's worth it or necessary by the time we get to just 2 formats in the array, but I don't see any big disadvantage, so why not. The DT binding documentation might want enhancing with a more general description of how formats should be represented if this is implemented. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH V2] video: implement a simple framebuffer driver Date: Mon, 20 May 2013 09:25:46 -0600 Message-ID: <519A407A.4040006@wwwdotorg.org> References: <1365043183-28905-1-git-send-email-swarren@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: Alexandre Courbot Cc: "linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , Rob Clark , linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Andrew Morton , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On 05/18/2013 04:29 AM, Alexandre Courbot wrote: > On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren wrote: >> +struct simplefb_format { >> + const char *name; >> + u32 bits_per_pixel; >> + struct fb_bitfield red; >> + struct fb_bitfield green; >> + struct fb_bitfield blue; >> + struct fb_bitfield transp; >> +}; >> + >> +struct simplefb_format simplefb_formats[] = { >> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} }, >> +}; > > I have been adding a few extra formats to this list, and I wonder if > this could not simply be turned into a function that would directly > convert the name string into the corresponding right format. The > mapping between name and format seems to be a 1:1 and this would > probably avoid errors in the future. I'm especially thinking about > color order here - I started adding a mode that reads > > { "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} }, > > while it should probably be called "a8b8g8r8" as the order of colors > is not the same as your r5g6b5. > > I can submit a patch if there is no issue with that idea. I chose r5g6b5 rather than rgb565 specifically to make that format trivially name machine-parsable. So, I'm not opposed to converting that table to code. I'm not 100% sure if it's worth it or necessary by the time we get to just 2 formats in the array, but I don't see any big disadvantage, so why not. The DT binding documentation might want enhancing with a more general description of how formats should be represented if this is implemented.