dslinux/linux-2.6.x/drivers/mmc scsd_c.c scsd_s.S

[Malcolm]

On 8/28/06, Amadeus <amadeus at iksw-muees.de> wrote:

> Yes, but this would mean to duplicate about 50% of the driver code.
> Each time a new card is added. Why?

The MMC layer is supposed to handle all high level things so the
drivers are only doing device specific things.

> I want to set up a common build for all RAM-capable cards now, and for
> this goal, code sharing makes sense to me.

I doubt it matters as much as you think.

> > Don't write an M3SD driver in assembler.
>
> IMHO, this is the best way to go for the lowlevel interface.

No, assembly is less maintainable, as less people can read it.

> Writing these drivers in assembler gives you some benefits not possible
> in C.
>
> - Speed. Movement of data is faster if you code the central loops in
> assembler. Because in the RAM-based builds, all userland lives on
> CF/SD, speed is an important factor for DSlinux here. If you loose time
> for GBA ROM/IO switching, it is importend to limit these time losses as
> most as possible. In the development of the new driver, speed issues
> were clearly visible to me.

The kernel has a fast memcpy implementation.

> - Control. In assembler, you can control the usage of the stack and
> stack-based local variables. In C, you can not. As in the RAM-based
> builds, the stack will(!) be in GBA ROM space, it is mandatory to block
> stack accesses if GBA ROM space is switched to IO.
>
> Sorry if you don't like what I do. For me, using the most suited
> language for each task is natural behaviour, if you must go to the
> limit. I am aware that some programmers have strong objections for
> choosing languages, or avoiding gotos, or else. I feel uncomfortable
> with this.

The kernel avoids assembly as much as possible.

> So what can we do to improve the situation?
>
> First of all the stack situation: I think it will be good if the kernel
> stack is in main memory for all builds, because of speed. Do you know
> how to achieve this? This will open the door to C-based "switching"
> drivers, and the only cause for writing assembler will be speed, so
> assembler parts may be much smaller.

Ideally the stack would be in DTCM, but as there is a stack per
process, this is not possible.

I don't know how to force the stack to be in RAM with the current
memory regions.

> I have got new and extended code for the M3SD, in the libfatdragon lib
> (from DSORGANIZE), and I think it is better now to write a driver.

I don't know about this lib.

Chishm's lib is being developed in cvs:
http://devkitpro.cvs.sourceforge.net/devkitpro/libfat/
He has much improved M3SD code over the original from the M3 manufacturers.

-- 
Malcolm Parsons