Re: [linuxdc-dev] VMU driver (Better maple)

[Fredrik H. <hu...@hu...>]

Paul Mundt <pm...@mv...> writes:

> > In particular, the mtd subsystem seems to use driver api
> > which writes one byte at a time, which is something
> > I would really really like to avoid in a VMU driver.
> > 
> No, this is not the MTD subsystem. MTD supports many different types of
> devices.. the mapping driver is really nothing more than something that deals
> with underlying access to the device. ie, it generally needs to manage things
> like varying offsets and such for read/write requests..
> 
> The one byte at a time thing isn't true either, I only implemented an 8-bit
> read/write to demonstrate how to deal with things.. the whole driver was a
> proof of concept that was pending a real maple implementation, and is still in
> need of a bit of rework. Though full 8/16/32bit requests are fully supported..

I don't want 8/16/32 bit requests.
A pure block device would only have to service a whole block at a
time, which would be much easier.

> > In my oppinion it would seem better to use a block device
> > driver, but this may have other traps of course.
> 
> MTD fully supports block devices. Devices are generally registered through
> mtdchar, which gives character device access to registered devices.. but you
> can just as easily build in mtdblock support, load that, and have all your
> registered devices accessible as block devices.

But can you write a low-level mtd driver which doesn't have to
be able to read one byte at a time?

> > One particular issue with a VMU driver is that it needs
> > to convey some meta-information (size, block size, root
> > block location etc.) to the reader/filesystem. One way
> > to support this would be to use an ioctl, but I'm not sure
> > that would be the best way because then loopbacks would
> > be impossible once a VMU filesystem is written.....
> > 
> Size is static for all VMU's, since even the banked ones are only toggleable
> via a hardware switch. As far as block size (as far as the fs is concerned),
> this can all be mapped over top of the VMU flash.. all access to the device is
> forced through maple blocks anyways, so it really doesn't matter what you want
> to deal with your fs block size as.. it all gets wrapped in the end..

Actually, different size VMUs are supported, but as far as I know, all
existing ones are the same size.  The fact that everything is forced
to maple blocks is the very reason I think a simple block device driver
would be the easiest.

> > An alternative solution (which is not pretty, but it works)
> > would be to map the meta-information into block 0 and then
> > map block 0 of the VMU into block 1 of the block device
> > (etc. etc.).
> > 
> Why would you want to store any of this information in a block on the device?
> Your superblock already does all of this for you. Though for things like the
> VMU file system, where the superblock resides at the _end_ of the flash ..
> things get a little wierder.

The superblock in the VMU can in fact be stored anywhere on the vmu.
There is a special maple call which says where the superblock is. That
is why meta information is needed. 

> > And, before I forget: If I do make a vmu driver, what major/minor
> > numbers should I use? In theory you can connect 24 vmus to a
> > dreamcast, so I'll need at least 24 separate devices. (Alternatively,
> > I could create *one* device node which maps all the vmus into one
> > address space, but I would only do that as a last resort...)
> > 
> MTD already deals with this. Don't side step it. And if you're lucky .. I'll
> even find the free time to fix my driver to work with your maple code, and
> then you won't need to worry about this at all. (This is also why I told you a
> good while ago that a driver was already in place and was merely in need of a
> bit of fixing up.. reinventing the wheel is a completely useless activity
> here).

Again, I might misunderstand how your driver is supposed to work, but
it seems to me that your driver will only be able to write 50-60 bytes per
second to the vmu. If that is the case, a new wheel might be a good idea.
(Since it (a) writes one byte at a time and (b) a vmu needs a small timeout
 after each write)

> Regards,
> 
> -- 
> Paul Mundt <pm...@mv...>
> MontaVista Software, Inc.

        /Fredrik Hubinette