[U-Boot] [PATCH 2/6] mx6q: Add support for ECSPI through mxc_spi driver

[Eric Nelson <eric.nelson@boundarydevices.com>]

On 01/18/2012 01:39 AM, Stefano Babic wrote:
> On 18/01/2012 02:44, Eric Nelson wrote:
>> I'll defer to Stefano on this one, since I did this in response
>> to his request:
>
> Yes, I admit I am guilty about this !
>
> The layout of the CSPI registers is not exactly the same for all SOCs.
> For example, the MXC_CSPICTRL_TC has a different position, as well as
> the BITCOUNT (because the MX31 can send less bits in one shot) and
> MXC_CSPICTRL_CHIPSELECT.
>
> So they are similar, but not exactly the same.
>
> Then we have the MX5 registers. Even if we check the CSPI (not eCSPI)
> controller, the layout of the registers is different compared to the MX3
> SOCs.
>
>> The struct cspi_regs is already present in mx31, mx35, and mx51 headers,
>> so I'm not breaking new ground here, only in the bitfield declarations.
>
> Right, I see the same. The cspi_regs structure is already defined into
> the imx_regs.h, only the bit layout was moved. And as the bit layout is
> SOC dependent, I think the right place for it is inside the imx-regs.h
> registers.
>
>> My interpretation of Stefano's intent is to clean up the driver at the
>> expense of extra defines in the arch-specific headers.
>
> Yes, you're right - of course, I am open also to other solutions if they
> are proofed to be better ;-).
>

I think this is about as good as things get with the current code base.
I would argue that the driver would be better if it explicitly supported
ECSPI and CSPI at the same time since the mx5x CPUs support it.

Implememting that would likely require a de-structuring (removing the
use of structs to represent the register set). IOW, a re-write.

That's probably not worth the effort unless someone's built hardware
that needs it (I'm not aware of any).

On our boards that use more than one channel of SPI (for PMIC and SF), we're 
using ECSPI on both. I think the same was true on the MX51 EVK.