Re: [PATCH] Add SH7720 CPU support

[Paul M. <le...@li...>]

On Mon, Jul 23, 2007 at 09:15:01AM +0200, Markus Brunner wrote:
> this patch adds support for the SH7720 SH3-DSP CPU to 2.6.22.
> How are the chances to get it accepted?
> 
Ho hum, you just missed the merge window. If it's tidied up enough, we
might be able to do this for -rc2, as the changes are pretty isolated and
it's not a lot of code.

> DMA is untested. Suggestions how to test it are welcome.
> 
The DMA API is in a bit of flux at the moment, we've got to revamp it for
the driver model and also for dmaengine integration. Once that's out of
the way, you'll be able to use the async_tx API for testing.

> UBC is untested. Booting is fine with, or without the "Wakeup UBC on
> startup" option.  Not surprising, because the bootloader didn't disable
> it. Suggestions how to test it are welcome.  Is anybody really using
> it? It looks a little unmaintained.  We removed the UBC_TYPE_SH7729
> define in asm-sh/ubc.h, because it is unused, but looks rather
> important because of all the ifdef CPU_SUBTYPEs.
> 
Yes, the UBC stuff is completely bitrotted. There are also endless
disagreements between ST and Renesas silicon about register sizes and so
on, and it's also completely broken for SMP. utrace is how I was planning
on solving this particular problem, but there hasn't been a lot of
progress there. I'm hopeful Roland will get the remaining issues sorted
out for 2.6.24 or so so we can actually fix up the UBC for once.

> A small bug was fixed after line 367 rtc-sh.c. The comment already
> claimed to stop the RTC, but actually it was not done. This is not
> necessary for all CPUs, but at least for 7720 and 7705.
> 
Looks like an issue with the block version. I suppose we should version
it explicitly and keep the CPU selections in the Kconfig, rather than
having the driver turn in to ifdef hell.

> Added asm-sh/port.h and asm-sh/cpu-sh3/port.h because the registers of
> the PFC are defined all over the place and port.h seemed to be the
> right place.
> 
This is another area where work still needs to be done. I believe Manuel
was planning on looking at this, as he had a use case for it with his MMC
drivers.

> The SH7720 has PINT interrupts, but support wasn't added. The reason is
> that the existing driver is not flexible enough.
> 
Magnus and Kristoffer are looking at this, the INTC driver was added last
week in order to help with these sorts of things.

> We tried to implement early printk but failed miserably. The
> scif_sercon_init function was never called.  Any hints?
> 
scif_sercon_init() currently depends on SH-4, and will only be called if
you boot with earlyprintk=serial, and have CONFIG_EARLY_SCIF_CONSOLE set.

Most platforms do not want any reinit of the ports for debug, we
generally just want to reuse the bootloader configuration and give the
kernel an idea of where an initialized port is in order to do the early
printk.

> kgdb is working, but I have problems using ttySC1, however ttySC1 is
> working fine for other things.
> 
kgdb is being replaced with the unified stub, which is currently in -mm.
You may want to look at that and see if it works for you. I've identified
a few problems with it that I've hacked some patches up for, but I've not
had the time to finish those up and get them to Andrew yet. I'll try and
do that if you're interested in this.

> Ethernet NFS performance is pretty bad (about 500 kB/s). I have not
> done any research on this yet.
> 
This is pretty normal when the sense selection on the IRQ is wrong. It's
especially common for edge-triggered smc91x chips when the IPR/INTC2 code
does level sensing. The INTC stuff from Magnus provides the proper hooks
for getting all of this tidied up and hooked up for your CPU, I'd suggest
looking at that first.

In general I don't have a problem with this patch, but I think you're
going to want to do some rework for the INTC IRQs. Magnus can help you
with this, as he's currently trying to debug it on SH-3 already, and you
seem to have the hardware to help test and debug. I suspect that that
alone will address a lot of the problems you've been seeing.

I can throw this in to a branch for testing if you want to do the
conversion incrementally, or you can resubmit against current git if you
want to do the INTC rework first. The obvious bugfix bits I'll merge
directly, thanks.