On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
From: Anton Vorontsov <hidden> Date: 2008-02-18 17:37:58
On Mon, Feb 18, 2008 at 12:30:11PM -0500, Valdis.Kletnieks@vt.edu wrote:
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild?
LE Fujitsu mb86277 (MINT) on the BE MPC8360E.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Clemens Koller <hidden> Date: 2008-02-18 23:35:35
Valdis.Kletnieks@vt.edu schrieb:
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Regards,
Clemens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-02-19 00:37:00
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
Valdis.Kletnieks@vt.edu schrieb:
quoted
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Most "sane" gfx chips nowadays provide configurable surfaces that allow
to perform the swap when writing/reading from regions of the
framebuffer, with the ability to set a different swapper setting (based
on bit depth) per region.
Then there is also the risk that your PCI<->Localbus has been wired
improperly :-)
Ben.
From: Clemens Koller <hidden> Date: 2008-02-19 11:28:19
Benjamin Herrenschmidt schrieb:
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
quoted
Valdis.Kletnieks@vt.edu schrieb:
quoted
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Most "sane" gfx chips nowadays provide configurable surfaces that allow
to perform the swap when writing/reading from regions of the
framebuffer, with the ability to set a different swapper setting (based
on bit depth) per region.
Most! But not the SM50x. I still hope I would be wrong here. :-(
Then there is also the risk that your PCI<->Localbus has been wired
improperly :-)
That's not an issue in my case. The SM50x can be connected to
either an PCI or some Local/CPU-whateverbus IF.
I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
If the sm501 is attached to the MPC85xx' PCI like any other video card,
the PCI config-space is can be accessed as usual, whereas the framebuffer
memory area is byte-swapped compared to other common video cards.
So, to get back on topic:
I would welcome endianess swapping in SW. Some architectures (PowerPC)
should also be able to do swapped-endian mmapping. I just haven't
had time for a closer look but it looks also interesting way to do it
that way.
Regards,
Clemens
From: Andrew Morton <akpm@linux-foundation.org> Date: 2008-02-19 12:07:26
On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller [off-list ref] wrote:
Benjamin Herrenschmidt schrieb:
quoted
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
quoted
Valdis.Kletnieks@vt.edu schrieb:
quoted
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Most "sane" gfx chips nowadays provide configurable surfaces that allow
to perform the swap when writing/reading from regions of the
framebuffer, with the ability to set a different swapper setting (based
on bit depth) per region.
Most! But not the SM50x. I still hope I would be wrong here. :-(
quoted
Then there is also the risk that your PCI<->Localbus has been wired
improperly :-)
That's not an issue in my case. The SM50x can be connected to
either an PCI or some Local/CPU-whateverbus IF.
I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
If the sm501 is attached to the MPC85xx' PCI like any other video card,
the PCI config-space is can be accessed as usual, whereas the framebuffer
memory area is byte-swapped compared to other common video cards.
So, to get back on topic:
I would welcome endianess swapping in SW. Some architectures (PowerPC)
should also be able to do swapped-endian mmapping. I just haven't
had time for a closer look but it looks also interesting way to do it
that way.
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
From: Clemens Koller <hidden> Date: 2008-02-19 12:22:21
Andrew Morton schrieb:
On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller [off-list ref] wrote:
quoted
Benjamin Herrenschmidt schrieb:
quoted
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
quoted
Valdis.Kletnieks@vt.edu schrieb:
quoted
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
quoted
I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
Both resolve endianess at driver level. Actually, both handle it by setting special
bits so the graphics chip itself reorder bytes to transform foreign endianess.
I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus.
The chip also has a register to swap endianess, but that seems to only affect some
LocalBus modes.
The current fb and X drivers are working, but when it comes to font
aliasing and hw-acceleration, the problems start to rise again...
Most "sane" gfx chips nowadays provide configurable surfaces that allow
to perform the swap when writing/reading from regions of the
framebuffer, with the ability to set a different swapper setting (based
on bit depth) per region.
Most! But not the SM50x. I still hope I would be wrong here. :-(
quoted
Then there is also the risk that your PCI<->Localbus has been wired
improperly :-)
That's not an issue in my case. The SM50x can be connected to
either an PCI or some Local/CPU-whateverbus IF.
I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
If the sm501 is attached to the MPC85xx' PCI like any other video card,
the PCI config-space is can be accessed as usual, whereas the framebuffer
memory area is byte-swapped compared to other common video cards.
So, to get back on topic:
I would welcome endianess swapping in SW. Some architectures (PowerPC)
should also be able to do swapped-endian mmapping. I just haven't
had time for a closer look but it looks also interesting way to do it
that way.
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Propably my bad, being subscribed to several CCed lists...
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
Since it seem that there are some odd chips out in the wild, I guess
Valdis (also readded to CC:) has no more objections to give it a try. :-)
Regards,
Clemens
From: Paul Mackerras <hidden> Date: 2008-02-20 00:57:45
Andrew Morton writes:
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping. That
would mean that all framebuffers would have to have the same
endianness, but that would suffice for embedded systems such as
Anton's and would end up a lot simpler IMHO.
Paul.
From: Anton Vorontsov <hidden> Date: 2008-02-20 12:18:33
On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
Andrew Morton writes:
quoted
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping.
This is of course viable alternative. And I was considering this, but
later I abandoned the idea: that way we'll end up doing math in the
native endianness and then converting it to the foreign. This feels
ugly in contrast when we can do the right math in the first place, per
framebuffer.
That
would mean that all framebuffers would have to have the same
endianness,
Yup, another downside of changing the code to fix some narrow
problem. Plus, this means things will break if/when we'll attach
PCI video card into the MPC8360E-RDK.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
From: Clemens Koller <hidden> Date: 2008-02-20 15:44:41
Paul Mackerras schrieb:
Andrew Morton writes:
quoted
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping. That
would mean that all framebuffers would have to have the same
endianness, but that would suffice for embedded systems such as
Anton's and would end up a lot simpler IMHO.
Yes. At least the affected PowerPC platforms can do byte-swapping on
the fly, so this should be sufficient and without performance
penalty, AFAICS.
Regards,
Clemens
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-02-20 20:40:00
On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
quoted
Andrew Morton writes:
quoted
Bizarrely, the original author of the patch (Anton) has fallen off the cc.
Could whoever did that please thwap himself?
Anyway, my head is now officially spinning. Did anyone actually have a
reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping.
This is of course viable alternative. And I was considering this, but
later I abandoned the idea: that way we'll end up doing math in the
native endianness and then converting it to the foreign. This feels
ugly in contrast when we can do the right math in the first place, per
framebuffer.
Also, the type of swap to do in fb_readl/writel would have to depend
on the bit depth which is kind of ugly.
quoted
That
would mean that all framebuffers would have to have the same
endianness,
Yup, another downside of changing the code to fix some narrow
problem. Plus, this means things will break if/when we'll attach
PCI video card into the MPC8360E-RDK.
From: Paul Mackerras <hidden> Date: 2008-02-21 04:59:59
Anton Vorontsov writes:
quoted
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping.
This is of course viable alternative. And I was considering this, but
later I abandoned the idea: that way we'll end up doing math in the
native endianness and then converting it to the foreign. This feels
ugly in contrast when we can do the right math in the first place, per
framebuffer.
OK. I guess I'm convinced then. However, your patch description
needs to be a lot better. It should describe things like why you
want to make the change and why the change you are proposing is a good
idea and is better than other alternatives. If you'd done that
originally we might not have needed to have all this discussion. :)
Paul.