Re: sh: intc - add support for SH7706, SH7707, SH7708, SH7709

[Paul M. <pau...@re...>]

On Tue, Jul 24, 2007 at 11:49:19PM +0900, Magnus Damm wrote:
> +#ifdef CONFIG_CPU_SUBTYPE_SH7706
> +#define SH7706
> +#endif
> +#ifdef CONFIG_CPU_SUBTYPE_SH7707
> +#define SH7707
> +#endif
> +#ifdef CONFIG_CPU_SUBTYPE_SH7708
> +#define SH7708
> +#endif
> +#ifdef CONFIG_CPU_SUBTYPE_SH7709
> +#define SH7709
> +#endif
> +
This sort of violent preprocessor abuse really makes one want to weep for
humanity. ifdefs are supposed to be ugly, so people think twice about
employing them. Shortening the names to mask this fact is not a path you
want to go down.

> +#if defined(SH7706) || defined(SH7707) || defined(SH7709)
> +	INTC_VECT(IRQ4, 0x680), INTC_VECT(IRQ5, 0x6a0),
> +	INTC_VECT(DMAC_DEI0, 0x800), INTC_VECT(DMAC_DEI1, 0x820),
> +	INTC_VECT(DMAC_DEI2, 0x840), INTC_VECT(DMAC_DEI3, 0x860),
> +	INTC_VECT(ADC_ADI, 0x980),
> +	INTC_VECT(SCIF2_ERI, 0x900), INTC_VECT(SCIF2_RXI, 0x920),
> +	INTC_VECT(SCIF2_BRI, 0x940), INTC_VECT(SCIF2_TXI, 0x960),
> +#endif
> +#if defined(SH7707) || defined(SH7709)
> +	INTC_VECT(PINT07, 0x700), INTC_VECT(PINT815, 0x720),
> +	INTC_VECT(SCIF0_ERI, 0x880), INTC_VECT(SCIF0_RXI, 0x8a0),
> +	INTC_VECT(SCIF0_BRI, 0x8c0), INTC_VECT(SCIF0_TXI, 0x8e0),
> +#endif
> +};
> +
Since these vectors seem to be an inclusive superset, this is perhaps
doable. I do worry about sharing this stuff within a common setup file,
however. The PFC states are going to have less in common than the
interrupt vectors, and while this may seem to be the lesser evil compared
to splitting it all out per subtype, in the long term we may simply not
have a choice in the matter.

Randomly sprinkling around interrupt vector setup based on subtype is a
big part of what we wanted to get away from with the make_ipr_irq()
atrocity and its ilk. Normally this would be grounds for rejection right
off the top, however, as most of these parts are bound to start showing
up in museums soon, it's likely a reasonable assumption that nothing
earthshaking is going to happen in the setup code for these in the
forseeable future, so perhaps keeping them unified like this will be the
easiest to maintain.

I'd like to hear from Kristoffer and Yoshii-san on whether this is a
useful direction, as they're the ones ultimately using these parts of
antiquity. If they're in favour of this approach, I'll queue it up for
-rc2.