From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.gna.ch (darkcity.gna.ch [195.226.6.51]) by ozlabs.org (Postfix) with ESMTP id EE17CB6F11 for ; Mon, 4 Oct 2010 21:30:53 +1100 (EST) Subject: Re: Introduce support for little endian PowerPC From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Benjamin Herrenschmidt In-Reply-To: <1285966204.2463.137.camel@pasglop> References: <1285916771-18033-1-git-send-email-imunsie@au1.ibm.com> <2C5357FA-F87F-457E-B5C1-0DCC5A842DE7@kernel.crashing.org> <1285935283.2463.78.camel@pasglop> <1285950041.15020.272.camel@thor.local> <1285966204.2463.137.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 Oct 2010 12:30:42 +0200 Message-ID: <1286188242.15020.349.camel@thor.local> Mime-Version: 1.0 Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Ian Munsie List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote:=20 > On Fri, 2010-10-01 at 18:20 +0200, Michel D=C3=A4nzer wrote: > > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:=20 > > >=20 > > > Now, the main reasons in practice are anything touching graphics. > > >=20 > > > There's quite a few IP cores out there for SoCs that don't have HW > > > swappers, and -tons- of more or less ugly code that can't deal with n= on > > > native pixel ordering (hell, even Xorg isn't good at it, we really on= ly > > > support cards that have HW swappers today). > >=20 > > That's not true. Even the radeon driver doesn't really need the HW > > swappers anymore with KMS. >=20 > And last I looked X still pukes if you give it a pixmap in non native > byte order but that might have been fixed. I'm not sure what exactly you mean by that, but I'm not aware of any such issues offhand. > > > There's an even bigger pile of application code that deals with graph= ics > > > without any regard for endianness and is essentially unfixable. > >=20 > > Out of curiosity, what kind of APIs are those apps using? X11 and OpenG= L > > have well-defined semantics wrt endianness, allowing the drivers to > > handle any necessary byte swapping internally, and IME the vast majorit= y > > of apps handle this correctly. >=20 > So why is it so hard to get any video card working on ppc ? :-) I didn't say anything about that, just that IME it should be mostly possible to deal with endianness within the driver stack. Note that I'm not arguing against these changes, just pointing out some apparent inaccuracies in the reasoning for them. --=20 Earthling Michel D=C3=A4nzer | http://www.vmware.c= om Libre software enthusiast | Debian, X and DRI developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754623Ab0JDKaw (ORCPT ); Mon, 4 Oct 2010 06:30:52 -0400 Received: from darkcity.gna.ch ([195.226.6.51]:50283 "EHLO mail.gna.ch" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752840Ab0JDKav convert rfc822-to-8bit (ORCPT ); Mon, 4 Oct 2010 06:30:51 -0400 X-Quarantine-ID: <3Yzzvgh3nGCw> X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 09 hex): Face: ...MWASAkVVViQjzP\n jycPrvgA\n\t\n R1goSzOnkp14Y[...] Subject: Re: Introduce support for little endian PowerPC From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Benjamin Herrenschmidt Cc: Josh Boyer , linuxppc-dev@lists.ozlabs.org, paulus@samba.org, linux-kernel@vger.kernel.org, Ian Munsie In-Reply-To: <1285966204.2463.137.camel@pasglop> References: <1285916771-18033-1-git-send-email-imunsie@au1.ibm.com> <2C5357FA-F87F-457E-B5C1-0DCC5A842DE7@kernel.crashing.org> <1285935283.2463.78.camel@pasglop> <1285950041.15020.272.camel@thor.local> <1285966204.2463.137.camel@pasglop> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRFDg4OHh4eLCwsOzs7S0tLWlpaa2treXl5hISEjY2NmJiYqKiotLS0xsbG1dXV/Pz81CO0SQAAArtJREFUOMtd1M9P01AcAHCI/4AtGq/QDfDHRfraEX8eaNeJFw1rO/DCYet7mxc1ZG0x3sStHQkmZpqtHDwAi+tMiFEzbZdwNWEJR48cjPG4g5HhELUbrHvjpYe2n7zvt++977cD/7rjsCry8uNG93Gge9OKUyAAgLB1AlpTZICmAzR15QTEiQAPAKADYLMPfhNnEJR4HvD0tT5YI2KGUcyqihQN7mDwZ3hMN4q2N4ol+gEGTSLWhorrjYXrGPwc0jTDOoKP4xi8G0W6adl2Gz6zGDwag5p5PMON7vZgJuSB976+3U6y2QdeKNet1+uum9/qwVQHvEjtKesY0EIb7CNYe+7DIRXCID/vQ4tksVAY7JFBD7yvqrWTL93xoUmOQsPIddbnuk8v+bBPsigB2KRlFxS4nL/owwEpKBSg2MU3UcDf+nATyyHEQwrHzJZFNpXeuOHDC0qW4sMhEHESFGOUrvgQpWUYFVNQdjQxca8abnSB55CmehdcLSxa1ifoQ4JBpmGYWbhsly3X0fxQ7xmkW3Y5CztLcXI+fAu2oWho3nbV6s5rH35xSC/aBR2tOpVa/Utv25tcTDPL6aT21kG17WrvaFtMBJmFhJCsVF4uu9VG76DWBaRnEiNs7pU659pYlfwtQSRy9GCYlwR7C6/dPQgBw3MsTPNWA4d9SeMDDC9JYdnqq/amdF+diGnVhXFztQ/2lJSWjulOxjRX+uC7EkOqhLRk2ejrqHVBEqCqJLO5cmEXgx8TrBiWVQh1u2DhzQlPsyIveU2YLGorGBxODoR5notlpcUieoLB1/NEmGc4AalGJpLe8WF/8txMWASAkVVViQjzP jycPrvgA R1goSzOnkp14YCYHsp7QJHAS5QcXDqG1jBxdSITVgBNkBTFloj88Q/gMkFcuItYiQPUCBGc2xh5drsD/wGZrgsgDOE4ZAAAAABJRU5ErkJggg== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Mon, 04 Oct 2010 12:30:42 +0200 Message-ID: <1286188242.15020.349.camel@thor.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote: > > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: > > > > > > Now, the main reasons in practice are anything touching graphics. > > > > > > There's quite a few IP cores out there for SoCs that don't have HW > > > swappers, and -tons- of more or less ugly code that can't deal with non > > > native pixel ordering (hell, even Xorg isn't good at it, we really only > > > support cards that have HW swappers today). > > > > That's not true. Even the radeon driver doesn't really need the HW > > swappers anymore with KMS. > > And last I looked X still pukes if you give it a pixmap in non native > byte order but that might have been fixed. I'm not sure what exactly you mean by that, but I'm not aware of any such issues offhand. > > > There's an even bigger pile of application code that deals with graphics > > > without any regard for endianness and is essentially unfixable. > > > > Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL > > have well-defined semantics wrt endianness, allowing the drivers to > > handle any necessary byte swapping internally, and IME the vast majority > > of apps handle this correctly. > > So why is it so hard to get any video card working on ppc ? :-) I didn't say anything about that, just that IME it should be mostly possible to deal with endianness within the driver stack. Note that I'm not arguing against these changes, just pointing out some apparent inaccuracies in the reasoning for them. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer