ok, I've tracked it down. The sound driver initialization is somehow blowing
away the mcp init. Naturally, I need both. :)
In sa1100_switches.c, the below code initializes interrupts for the general
I/O on the UCD.
BCR_set(BCR_CODEC_RST);
Ser4MCCR0 = MCCR0_MCE | MCCR0_SmpCnt;
codec_write(CODEC_REG_IO_DIRECTION, 0);
codec_write(CODEC_REG_RISE_INT_ENABLE, 0xff);
codec_write(CODEC_REG_FALL_INT_ENABLE, 0xff);
(attached for completeness)
static inline void codec_write(ushort addr, ushort data)
{
ulong flags;
save_flags_cli(flags);
while (!(Ser4MCSR & MCSR_CWC));
Ser4MCDR2 = ((addr & 0xf) << FShft(MCDR2_ADD)) | MCDR2_Wr | (data &
0xffff);
restore_flags(flags);
}
-----------------------
Then, the below code initializes the sound. Commenting this block out
allows for switches to work, but not surprisingly, sound then doesn't.
sa1100-uda1341.c
/* Setup the uarts */
GAFR |= (GPIO_SSP_TXD | GPIO_SSP_RXD | GPIO_SSP_SCLK |
GPIO_SSP_SFRM | GPIO_SSP_CLK);
GPDR |= (GPIO_SSP_TXD | GPIO_SSP_SCLK | GPIO_SSP_SFRM);
GPDR &= ~(GPIO_SSP_RXD | GPIO_SSP_CLK);
PPAR |= PPAR_SPR;
Ser4SSCR0 = SSCR0_SSE + SSCR0_DataSize(16) + SSCR0_TI;
Ser4SSCR1 = SSCR1_SClkIactL + SSCR1_SClk1P + SSCR1_ExtClk;
------------------------------
According to the documentation, these two blocks of code should be
compatible(Primarily 11-156, 11-17[2-3] in SA-1110 Developer's Manual).
Setting the SPR bit on PPAR before initializing the SSP should allow both to
coexist. (where the SSP uses GPIO instead of the MCP RXD4/TXD4, etc). This
doesn't appear to be the case. Can anyone here spot discrepancies?
thanks again,
Teman
----- Original Message -----
From: "John Dorsey" <[EMAIL PROTECTED]>
To: "Teman Clark-Lindh" <[EMAIL PROTECTED]>
Cc: "Linux Arm Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 8:57 PM
Subject: Re: Assabet /dev/switches
>
> On Wednesday, April 11, 2001, at 09:06 PM, Teman Clark-Lindh wrote:
>
> > However, nothing happens. The handler registration takes place
> > successfully
> > (no conflicts with touchscreen, etc), but it is never called.
>
> (My recollection is a bit hazy on this, and I haven't looked at the code
> lately. Hopefully, someone will step in to debunk any myths that I'm
> about to tell.)
>
> When that driver was written, there were promises of a Grand Unified
> UCB1200 driver framework which would allow cooperative sharing of that
> chip's single interrupt source. As such, absolutely no effort was made
> to permit any sort of peaceful coexistance between the sa1100_switches
> driver and, say, the touchscreen code. Since you mention that the
> UCB1300 switch handler is successfully registered, I might guess that
> some other driver is clobbering the interrupt source at the chip.
>
> I've been doing my best not to touch the kernel recently, but if the
> UCB1200 code has evolved beyond the old "all-or-nothing" model, I'll be
> happy to revisit this driver. Otherwise, I'm afraid the answer to your
> question is, "disable anything else having to do with the UCB1200 in
> your kernel configuration."
>
> -jd, who took care to ensure that this brain damage didn't make it into
> Spot
>
> _______________________________________________
> http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
> Please visit the above address for information on this list.
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
