[PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.

[Scott Wood]

On Tue, Oct 20, 2009 at 12:01:19PM +0200, Richard Cochran wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:scottwood at freescale.com]
> >
> > What problems have you been having with upstream kernels on mpc8313erdb,
> > other than this IRQ issue?  It should work, though the BSP may have extra
> > features that haven't been pushed upstream.
> 
> I have been working from kernel 2.6.30 (although the very latest
> kernel is just the same WRT these problems, AFAICT). I had to patch in
> order to sovle the following three problems:
> 
> 1. The flash layout in the DTS does not match the default partitioning
>    from Freescale. In the current dts, the NAND partitioning is wrong,
>    and there is no partitioning for the NOR flash given.

OK, I wasn't aware of that -- that kind of thing is an artifact of the BSP
development process being fairly separate from upstream development.  The
"open source team" works on upstream Linux and upstream U-Boot.  We don't
run the BSP u-boot (since we're developing the newer u-boot), and it's easy
to miss when things like this diverge.

In this case, I'd be surprised if the NAND partitioning that is upstream
came from anywhere but an early BSP's Linux tree.  There's not much we (the
upstream-focused developers) can do if different BSPs have different layouts
(other than not specify a layout at all)...  What is the layout you see in
your BSP?

> 2. The eTSEC interrupt issue that started this thread.

Well, yes. :-)

> 3. The PTP IO signals are not configured in a vanilla linux. For this,
>    you need parts of a Freescale patch. [1] Their PTP implementation
>    gianfar driver is horrible, but still, the IO configuration in
>    these two files in the patch is necessary to get any external
>    signals from the PTP clock:
> 
>    arch/powerpc/platforms/83xx/mpc8313_rdb.c
>    arch/powerpc/platforms/83xx/mpc83xx.h

Yes, this is one of those features that is currently BSP-only (partly due to
it needing work, as you note above).  That's different than the board simply
not being supported upstream, but if you need it, you need it.  I'll raise
the issue in my team, but I suggest also letting Freescale support (or other
official feedback channels) know what you'd like to see in terms of
improvements in that code and getting it upstream.

-Scott