SM501 Frame Buffer driver on PPC

SM501 Frame Buffer driver on PPC

[Absolut Hunter]

All,

I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
board. Using the Denx Kernel 2.4.25 I see that most of this is already
included in the kernel.

However a few questions:

The TQM5200 Board uses this driver, but I am gathering this is a PCI based
video setup?; Our board uses a local bus memory interface. I.e. we have
setup the SM501 to be in the SH-3/4 Slave mode. 

We have dedicated 32Megs of Video memory to be local only to the SM501, and
mapped it to 0xF8000000 on /CS6, placing the registers at 0xFBE00000

Anyway, I have the UPMA machine setup to communicate with the SM501 and have
verified basic communication with registers, etc.. When using Linux the
kernel Oops's when register_framebuffer is called. I have setup the
voyager.h file to use the correct addresses.

Has anyone used the SM501 driver with this type of NON-Unified memory
architecture? I am guessing this can be confusing to the driver since the
frame buffer registers inside the SM501 need to be using offset ZERO instead
of the 0xF8000000 like the MPC8280 sees.

Thanks,

-Russell McGuire

Re: SM501 Frame Buffer driver on PPC

[Dan Malek]

On Nov 2, 2005, at 8:40 PM, Absolut Hunter wrote:

> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture?

What do you mean, non-unified?

>  I am guessing this can be confusing to the driver since the
> frame buffer registers inside the SM501 need to be using offset ZERO 
> instead
> of the 0xF8000000 like the MPC8280 sees.

The SM501 PCI driver assumes the addresses are from the PCI
base address, not from zero.   Properly using the local bus address
in a similar way should work just fine.

Thanks.

	-- Dan

Re: SM501 Frame Buffer driver on PPC

[Clemens Koller]

Hello, Russell,

> I am attempting to bring up a SM501 frame buffer driver on our PPC MPC8280
> board. Using the Denx Kernel 2.4.25 I see that most of this is already
> included in the kernel.

I am using the SM501 on PCI on Kernel 2.6 and updated several things in the
driver - not really the same contstruction area as you are working on.
But if you need some code, please let me know (off-list). I posted some things
in the past in this list and on fb-devel, too - just have a look.

The endianess on PCI on ppc is still an issue (I haven't investigated this
problem further during the last month).

I hope that I'll find some time to setup a webpage to publish that
stuff, soon...

Best regards,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

Re: SM501 Frame Buffer driver on PPC

[Mark Chambers]

> The endianess on PCI on ppc is still an issue (I haven't investigated this
> problem further during the last month).
> 

There really shouldn't be an endian issue on SM501 since registers are
32 bit.  What we do have is the 5200 that does byte swapping on PCI
for no good reason (IMHO)

--Mark Chambers

RE: SM501 Frame Buffer driver on PPC

[Martin Krause]

Hi Russell,

Absolut Hunter wrote on Thursday, November 03, 2005 2:40 AM:=20
> The TQM5200 Board uses this driver, but I am gathering this is a PCI
> based=20
> video setup?; Our board uses a local bus memory interface. I.e. we
> have=20
> setup the SM501 to be in the SH-3/4 Slave mode.

On the TQM5200 the SM501 is connected over the local bus, not over
PCI. The SH-4 Interface is used.

> We have dedicated 32Megs of Video memory to be local only to the
> SM501, and mapped it to 0xF8000000 on /CS6, placing the registers at
> 0xFBE00000=20
>=20
> Anyway, I have the UPMA machine setup to communicate with the SM501
> and have verified basic communication with registers, etc.. When
> using Linux the=20
> kernel Oops's when register_framebuffer is called. I have setup the
> voyager.h file to use the correct addresses.

Yes,

#define FB_PHYSICAL_ADDR	0xF8000000
#define REG_PHYSICAL_ADDR	0xFBE00000=20

should do the job (if the addresses are correct).

> Has anyone used the SM501 driver with this type of NON-Unified memory
> architecture? I am guessing this can be confusing to the driver since
> the=20
> frame buffer registers inside the SM501 need to be using offset ZERO
> instead=20
> of the 0xF8000000 like the MPC8280 sees.

I'm not sure, what you mean with NON-Unified memory. Note that the
TQM5200 uses the memory integrated in the SM501 as framebuffer. So
the SM501 is configured to use internal memory. If you want to use=20
external memory, you have to change the SM501 initialisation. Take
a look at the DRAM Control register of the SM501. Pin GPIO12 is
used during reset to enable or disable "Embedded Memory Control".

Please note, that the framebuffer driver does all register accesses
32-bit wide. Make sure your hardware supports this.

Maybe you have to change endianness (little/big).

Regards,
Martin

RE: SM501 Frame Buffer driver on PPC

[Martin Krause]

Mark Chambers wrote on Thursday, November 03, 2005 3:06 PM:=20
> > The endianess on PCI on ppc is still an issue (I haven't
> > investigated this problem further during the last month).
> >=20
>=20
> There really shouldn't be an endian issue on SM501 since registers are
> 32 bit.  What we do have is the 5200 that does byte swapping on PCI
> for no good reason (IMHO)

We experienced a byte swapping issue on the SM501, too, although it
is connected via the local plus bus with the MPC5200 and not via PCI
bus.

In 16 bpp mode bytes appear to be swapped in a very ugly way.
Unfortunately we have no explanation for this, nor a real
workaround.

-- Martin Krause

Re: SM501 Frame Buffer driver on PPC

[Jarno Manninen]

On Thursday 03 November 2005 16:16, Martin Krause wrote:
> Mark Chambers wrote on Thursday, November 03, 2005 3:06 PM:
> > > The endianess on PCI on ppc is still an issue (I haven't
> > > investigated this problem further during the last month).
> >
> > There really shouldn't be an endian issue on SM501 since registers are
> > 32 bit.  What we do have is the 5200 that does byte swapping on PCI
> > for no good reason (IMHO)

Actually the 5200 does _not_ change the order of bytes written on the PCI bus, 
but just the bytelanes. Why? Consider this. We have two mapped entities and 
some data in system memory.

	struct something {
		char 1;
		char 2;
		char 3;
		char 4;
	};

	/* Mapped memory from PCI bus */
	struct something *device_memory;
	uint32_t *device_register;

	/* And local data */
	struct something system_memory = { 0x11, 0x22, 0x33, 0x44 };
	uint32_t value = 0x11223344;

And we transfer data from system memory to PCI device.

	memcpy(device_memory, &system_memory, sizeof(struct something));
	*device_register = value;

These both would create 32-bit access to the PCI device( I suppose :), but if 
we just blindly swap or don't swap written bytes the result is mess:

					Swapping
Item		With 						Without
struct	{ 0x44, 0x33, 0x22, 0x11 }	{ 0x11, 0x22, 0x33, 0x44 }
integer	0x44331100				0x11223344
Result	Integer OK				Struct OK
		Struct messed				Integer messed

So the actual problem is that there is no feasible way to determine if a 
access of given width needs to be swapped on the "bus-level". So basically it 
is left to user to decide when the swapping is needed. But of course this can 
be taken care on the device level with clever planning.

I hope I didn't get it all too wrong. :)

> We experienced a byte swapping issue on the SM501, too, although it
> is connected via the local plus bus with the MPC5200 and not via PCI
> bus.
>
> In 16 bpp mode bytes appear to be swapped in a very ugly way.
> Unfortunately we have no explanation for this, nor a real
> workaround.

Yes, the byteswap implementation on SMI-chips is quite braindead. They have
	
Input	1234
Swap1	4321
Swap2	3412

When what we really need is:

Swap	2143

IMHO the easiest way is to use 24-bit mode that can be usually handled only by 
changing the byte-offsets.

- Jarno