Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

On Sunday 02 Dec 2001 7:05 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Dec 02, 2001:
> > Now, is it right to just copy a lump of memory over from user space in
> > this way?
>
> Well even if it was ok (I don't know) semantically, you can't do it
> realistically for the AICA.  Remember the discussion on dcdev?  You can
> only copy so much data to AICA RAM at once - if you don't wait for the FIFO
> to be clear then you'll crash the AICA.
>

That may be the problem - as the memory allocation now apears to work (at 
least a read of the memory returns that it contains the same data that was 
written).


> > I haven't specifically allocated a buffer inside the sound RAM area -
> > just claimed it for the kernel when initiating the module and assumed
> > that it's there - the function doesn't fail in the sense that the -EFAULT
> > error is never reported, but does that mean it has actually worked?
> >
> > Should I be allocating a buffer first and copying the data from user
> > space into that?
>
> Damn, I need time :P.  Check out the latest KOS which (apparently) has AICA
> DMA working.  You want to use DMA.  You have to use DMA.  It's DMA or die
> ... ok maybe that's too much.  But that's the only way you'll effectively
> get anything to AICA RAM without choking on the FIFO.
>

I'd have to write my own DMA routines (I think) as the kernel supported ones 
crash the SH4 kernel or rather cause input to freeze up - far too big a job 
for me.


> I still have to sit down and write the register test to see if it's
> feasible to play with the AICA regs directly from the SH4.  Or you could
>
> :P.
> :
> > Perhaps I am just clutching at straws.
>
> What you need is a AICA test program.  It doesn't even have to be kernel
> related, and you can provide your own inX() outX() routines that treat the
> AICA registers as latches and checks *every* value you get back from the
> AICA.  I still believe you can play with AICA registers from the SH4, take
> a look at this:
>
> From arch/sh/kernel/rtc-aica.c:
>
> /* The AICA RTC is represented by a 32-bit seconds counter stored in 2
>  * 16-bit registers.*/
> #define AICA_RTC_SECS_H         0xa0710000
> #define AICA_RTC_SECS_L         0xa0710004
>
> /**
>  * aica_rtc_gettimeofday - Get the time from the AICA RTC
>  * @tv: pointer to resulting timeval
>  *
>  * Grabs the current RTC seconds counter and adjusts it to the Unix
>  * Epoch.
>  */
> void aica_rtc_gettimeofday(struct timeval *tv) {
> 	unsigned long val1, val2;
>
> 	do {
> 		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 	} while (val1 != val2);
>
> 	tv->tv_sec = val1 - TWENTY_YEARS;
>
> 	/* Can't get microseconds with just a seconds counter. */
> 	tv->tv_usec = 0;
> }
>
>
> Now, you see how I'm grabbing those registers?

Yes, okay  but I am not exactly sure what the point you are making is. Simple 
test routines I've put in the SH4 code today show that the registers report 
that their contents after writing agree with the value that is meant to be 
written to them.

  In your test program (or
> your kernel driver), write a generic routine that does just that.  You may
> end up with valid values after all.
>
> The aica_rtc_settimeofday() is basically the same, except at the top of the
> while loop, there are ctrl_outl() statements that write the register value.
> You could even throw the FIFO check in there just to be on the safe side.
>
I need to know more about the FIFO I thin - is it in the CPU manual?


> Let's prove those dcdev'rs wrong :P.  Let me know what you come up with,
> and I'll try to work on something later.
>
> Hope this helps,
>
> M. R.