[U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5

[Stefano Babic <sbabic@denx.de>]

David Jander wrote:
> Absolutely right. I just posted it as reference for your patch eventually, not 
> because I thought it was good that way.

Yes, I know. I want only to point out what we have to reach ;-)

>>> Seems to work, but never mind...
>> Ok, I will resend my patch, I hope you can give a chance a test it on
>> your target.
> 
> Will do.
> Btw, do you have any idea why spi_xchg_single() hangs while transmitting the 
> second word without claiming the bus again?

Can you see where does it hang ? Which device is connected to your SPI
bus ? Does it work with the pmic (I think so, see later...).

> 
> Also, I don't know if you already fixed mxc_spi.c, to use the correct byte-
> ordering when sending u8 buffers.

Well, it seems we are working at the same issues, and probably it is
better if we try some coordination ;-)

I have already fix the byte ordering, but I am fixing now the misaligned
access (this is the reason I have not sent the changes for gpios in the
mxc_spi.c: I am reworking this driver...). In the mainline driver, only
32-bit aligned buffers are allowed, and this is a strong limitation. I
cannot use some other components in u-boot, such as SPI flash, because
the code allocates u8 buffers that can be disaligned. And with other
devices (sensors, eeprom, ...) does not work, because most of them
require to transfer only one or two bytes as command.

Now that I think...is it maybe your case now ? The FIFO can be accessed
only as word, other accesses are not allowed according to the manual.

However, I am currently working on several issues for MX51. It should be
nice to know which are your plans to save both some time ;-)

> I have a fix, but it is not yet ready.
> I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the (broken) 
> pmic driver,

As I said, I changed the pmic driver, too. I do not agree we must have
"special" functions, only because something is broken. The pmic works
because it is connected to the FSL SPI controller, and the endianess is
consistent. However, it is common for a SPI driver to allocate a "char"
buffer, and the first byte in the buffer is the first byte sent to the
SPI bus. This is not the case with mxc_spi.c

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================