Hi Benjamin, After confirm with our h/w designer, ast2400 did not support big-endian as you said. We support it in our previous product(PCI revision < 0x20) for frame buffer access. So, the possible solution is made in sw level for big-endian support. May we know the impact if we did not support it in h/w design? We will consider to support it in next generation. The default MMIO is enabled since the products PCI revision >= 0x20. The possible solution is check the value of 0x3c3 through MMIO. If the value is 0xFF, then you must enable it through PCI IO.
Regards,
Y.C. Chen
-----Original Message----- From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] Sent: Saturday, June 07, 2014 3:16 PM To: Dave Airlie Cc: dri-devel@lists.freedesktop.org; YC Chen Subject: Re: ast2400 woes
On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:
IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO use the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42, can it be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
On my AST2400 at least, even when MMIO is disabled, 0x3c3 still responds so it works but is that valid for all chips ? Or do I need to favor the PIO path if PIO is available in that case for older chipsets ?
Note: I have it working now with a couple of patches that i'll send when I've cleaned them up, though I still need answers to the earlier questions so we can make sure we don't break earlier chipset support on x86.
However, YC, the Endian control bits in extended CRTC register A2 seem to have no effect at all. With a big endian kernel I get the wrong endian on graphics regardless of the setting of that register !
Is endian swapping supported on the AST2400 ?
Also what is the exact effect of that register ? Does it affect access from PCI to the framebuffer or does it affect the way the CRTC consumes pixels from the framebuffer ? Is is supposed to have an effect on register accesses ?
Cheers, Ben.