Re: [Openvortex-dev] I/O space & other stuff

[Jeff Muizelaar]

On Sun, 13 Apr 2003, Shamus wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I was wondering why in the vortex2.h file that the hwread/hwwrite
> macros divide the target address by 4. In snooping around HwIO.cpp I
> noticed that the binary driver does *not* do
> this--it seems to write directly to the address (plus the ioremap'ed
> address, 'natch). What's the reason for the divide-by-4?

pointer arithmetic. In the HwIO.cpp we are adding to an integer in
vortex2.h we are adding to a pointer. It all of course ends up the same in
the compiled code though.

> Also in my snooping through the compiled C++ code I've been able to
> make some headway into figuring out a lot of the objects' member
> variables. I believe I can make a bit more headway into fleshing out
> the member functions as well (I've been looking at the entire hardware
> initialization sequence that's kicked off by CAsp4Core's Initialize()
> function and made some good progress)--any requests?

send patches or documentation.
Manuel can probably make better suggestions than I. Generally the bigger
the better. If you want you could try SetAdbCtrl__9CAsp4FIFOiiiiii (there
are probably more valuable ones but this is all that comes to mind at the
moment). I tried this one but have so far been unsuccessful. If you want I
can send a control flow graph.

> I was also thinking about adding devfs support as well, but it seems
> that the kernel sound drivers already do this when you use
> register_sound_dsp and register_sound_mixer... Perhaps it would be
> possible to add in a few more device nodes (using devfs) so that it
> wouldn't be necessary to muck around with aliasing devices using
> modules.conf. Of course, there would probably have to be some #ifdefs
> to support kernels without devfs--but to me having a sound module that
> can take care of itself is very desirable because it's (for lack of a
> better term) user friendly and the Right Thing To Do(tm). Thoughts?

The OSS driver is no longer being developed. Just the same putting this
type of thing into a driver is a mistake. If it belongs anywhere it would
be in sound core. Otherwise it would simply be a bandaid and cause
inconsistency with regards to the other oss drivers.

-Jeff