linuxdc-dev — Developer discussion list

[linuxdc-dev]Maple connect

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

What are the circumstances under which the 'connect' function for a maple 
client device will be called?

I am building an experimental driver - as a module - for the microphone and 
while clearly the init and exit functions are being called and the maple core 
correctly reports the loading of a microphone driver, connect doesn't seem to 
get called.

Is this correct behaviour?


Adrian

[linuxdc-dev]Patch for sound driver

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

This patch fixes problems with closing down low smaple rate/mono sounds

--- aica.c	Sun Jan 27 11:17:17 2002
+++ linux-sh-dc/drivers/sound/aica/main.c	Tue Jan 29 21:36:53 2002
@@ -319,8 +319,8 @@
 {
 	aica_dev_t *devc = (aica_dev_t *) (file->private_data);
 	int playpoint, i;
-	if (chanh->freq < 11000) {
-		interruptible_sleep_on_timeout(&(devc->open_wait), HZ);
+	if (chanh->freq < 23000) {
+		interruptible_sleep_on_timeout(&(devc->open_wait), HZ/5);
 	}
 	if (devc->last_write_length > 0) {
 		spu_write_wait();
@@ -341,7 +341,7 @@

 		for (i = 0; i < (HZ * 2); i++) {

-			if (chanh->freq < 11000)
+			if (chanh->freq < 23000)
 				interruptible_sleep_on_timeout(&
 							       (devc->
 								open_wait),

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[Ernie <st...@ma...>]

On Monday, January 28, 2002, at 05:48 PM, M. R. Brown wrote:
> Is there anyone on the list who has a bunch of 2nd class DC 
> peripherals?  I
> may want to send you a test program to grab useful info from them.  2nd
> class also includes 3rd-party controllers, and of course, the steering
> wheel :P.

Ah yes, the steering wheel.  For moving through your emails ... Maybe if 
one has a gas pedal, we can hook it into kernel networking, and use it 
as a kind of bandwidth control ...

Ok ok, i'll stop now, i promise :)

-e

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Mon, Jan 28, 2002:

> On Monday 28 Jan 2002 10:48 pm, M. R. Brown wrote:
> > * John Wiggins <lin...@ho...> on Mon, Jan 28, 2002:
> > > I take it that it would be too much trouble to look at the maple bus =
in
> > > the same light as one would for USB...
> >
> > We do ... although you have to question the intelligence of adding all
> > those Maple drivers in the kernel tree itself.  True that USB does, but=
 is
> > that necessarily the right thing to do?  USB does include mass storage,
> > audio, networking, etc. but it's a heck of a lot more organized (and
> > standardized) than Maple ever could be.  Besides, those USB drivers hook
> > into other Linux subsystems.  I can't imagine what subsystem the maracas
> > would hook into.
> >
>=20
> Well, I doubt we'll ever really have maracas drivers, but why should thes=
e be=20
> treated any differently (in terms of running as kernel code) than, say, a=
=20
> mouse, which is an utterly useless article when it comes to a Dreamcast?
>=20

Because there is provision for mice in more than one spot in the kernel.
The mouse hooks into the input subsystem via mousedev, so it's presence is
more than justified in the kernel itself.  There is no such maracasdev or
any other input mechanism that one could subscribe to that would justify a
hacked up kernel interface to the maracas.

I wasn't saying that we don't include Maple device support because it is or
isn't useful, but the argument is whether or not they are useful as kernel
drivers or userspace drivers.  IMO, if the device deviates from the
standard Maple input list and introduces a proprietary protocol that can't
be utilized sanely anywhere else in the kernel besides Maple, then support
for it belongs in userspace.  I don't know enough yet about the maracas,
dance pad, fishing rod, etc. to make that determination, but my best guess
is that they don't look like controllers to Maple.

I think in those extreme cases that a more generic Maple driver and
userspace access library would work, similar to how evdev works as a
catch-all in the input subsystem.  I do not think that we should spend time
making those devices "emulate" real Maple input devices for the sake of
coolness.  The lightgun is as hacked as I am willing to go, only because it
*must* be a hack, there is no other sane way to support it.

We've already talked about borrowing from or integrating USB and Maple, and
that is more than enough challenge by itself.

M. R.

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

On Monday 28 Jan 2002 10:48 pm, M. R. Brown wrote:
> * John Wiggins <lin...@ho...> on Mon, Jan 28, 2002:
> > I take it that it would be too much trouble to look at the maple bus in
> > the same light as one would for USB...
>
> We do ... although you have to question the intelligence of adding all
> those Maple drivers in the kernel tree itself.  True that USB does, but is
> that necessarily the right thing to do?  USB does include mass storage,
> audio, networking, etc. but it's a heck of a lot more organized (and
> standardized) than Maple ever could be.  Besides, those USB drivers hook
> into other Linux subsystems.  I can't imagine what subsystem the maracas
> would hook into.
>

Well, I doubt we'll ever really have maracas drivers, but why should these be 
treated any differently (in terms of running as kernel code) than, say, a 
mouse, which is an utterly useless article when it comes to a Dreamcast?

>
> M. R.

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[M. R. B. <mr...@0x...>]

* John Wiggins <lin...@ho...> on Mon, Jan 28, 2002:

> I take it that it would be too much trouble to look at the maple bus in t=
he=20
> same light as one would for USB...
>=20

We do ... although you have to question the intelligence of adding all
those Maple drivers in the kernel tree itself.  True that USB does, but is
that necessarily the right thing to do?  USB does include mass storage,
audio, networking, etc. but it's a heck of a lot more organized (and
standardized) than Maple ever could be.  Besides, those USB drivers hook
into other Linux subsystems.  I can't imagine what subsystem the maracas
would hook into.

But if "controller" type devices map out to controller buttons, then it's
not that big of a deal.  Does the fishing rod return analog input like the
controller, or some weird protocol that only fishing rods know how to do?
If it is a controller, then it can live with the rest of the Maple
controller code and be treated as such - apps that use it wouldn't need to
know the difference.

Is there anyone on the list who has a bunch of 2nd class DC peripherals?  I
may want to send you a test program to grab useful info from them.  2nd
class also includes 3rd-party controllers, and of course, the steering
wheel :P.

M. R.

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[John W. <lin...@ho...>]

I take it that it would be too much trouble to look at the maple bus in the 
same light as one would for USB...


>From: Ernie <st...@ma...>
>To: lin...@li...
>Subject: Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera
>Date: Mon, 28 Jan 2002 17:14:33 -0500
>
>I don't know about everyone else, but I can't wait to check my email
>from my DC with a fishing rod ... oh, and maybe we could use the
>lightgun to delete emails?  Man, that'd rock ... ;)
>
>-e
>
>On Monday, January 28, 2002, at 03:15 PM, M. R. Brown wrote:
>
>>* Paul Mundt <pm...@mv...> on Mon, Jan 28, 2002:
>>
>>>Doesn't belong in maple much at all.. This looks a lot like something
>>>that's
>>>begging to be implemented through v4l (Video4Linux). See
>>>drivers/media/video..
>>>
>>
>>Ah yeah.
>>
>>>Too bad we can't automagically taint the kernel if a bastard maple
>>>device is
>>>plugged in.. would serve the user right for hooking one of those
>>>abominations
>>>up anyways..
>>>
>>
>>C'mon!!  Don't you want to check your e-mail from your DC with a goddamn
>>fishing rod?!?  Don't you want to dance-dance your way through your
>>list of
>>running processes???  Shake, shake, shake, senora, your way across the
>>Web?
>>
>>Let's use our ball^H^H^H^Hheads people! :P.
>>
>>M. R.
>>
>
>
>_______________________________________________
>Linuxdc-dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxdc-dev




--
John Wiggins
Loxly Norwych (DAoC)
Xortan Brax (EQ)
Gunther Dragon (UDIC)
lin...@ho...
jwi...@sp...
wig...@ya...


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

On Monday 28 Jan 2002 10:14 pm, Ernie wrote:
> I don't know about everyone else, but I can't wait to check my email
> from my DC with a fishing rod ... oh, and maybe we could use the
> lightgun to delete emails?  Man, that'd rock ... ;)
>

Well said that man :->

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[Ernie <st...@ma...>]

I don't know about everyone else, but I can't wait to check my email 
from my DC with a fishing rod ... oh, and maybe we could use the 
lightgun to delete emails?  Man, that'd rock ... ;)

-e

On Monday, January 28, 2002, at 03:15 PM, M. R. Brown wrote:

> * Paul Mundt <pm...@mv...> on Mon, Jan 28, 2002:
>
>> Doesn't belong in maple much at all.. This looks a lot like something 
>> that's
>> begging to be implemented through v4l (Video4Linux). See 
>> drivers/media/video..
>>
>
> Ah yeah.
>
>> Too bad we can't automagically taint the kernel if a bastard maple 
>> device is
>> plugged in.. would serve the user right for hooking one of those 
>> abominations
>> up anyways..
>>
>
> C'mon!!  Don't you want to check your e-mail from your DC with a goddamn
> fishing rod?!?  Don't you want to dance-dance your way through your 
> list of
> running processes???  Shake, shake, shake, senora, your way across the 
> Web?
>
> Let's use our ball^H^H^H^Hheads people! :P.
>
> M. R.
>

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[M. R. B. <mr...@0x...>]

* Paul Mundt <pm...@mv...> on Mon, Jan 28, 2002:

> Doesn't belong in maple much at all.. This looks a lot like something tha=
t's
> begging to be implemented through v4l (Video4Linux). See drivers/media/vi=
deo..
>=20

Ah yeah.

> Too bad we can't automagically taint the kernel if a bastard maple device=
 is
> plugged in.. would serve the user right for hooking one of those abominat=
ions
> up anyways..
>=20

C'mon!!  Don't you want to check your e-mail from your DC with a goddamn
fishing rod?!?  Don't you want to dance-dance your way through your list of
running processes???  Shake, shake, shake, senora, your way across the Web?

Let's use our ball^H^H^H^Hheads people! :P.

M. R.

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[Paul M. <pm...@mv...>]

On Mon, Jan 28, 2002 at 01:54:26PM -0600, M. R. Brown wrote:
> > I did find a document this time though. And it appears to be 'webcam' c=
apable=20
> > as well as still photos capabale.
>=20
> Sounds pretty cool, I *guess* this could fit in a maple input kernel
> driver, but I'm not so sure how.
>=20
Doesn't belong in maple much at all.. This looks a lot like something that's
begging to be implemented through v4l (Video4Linux). See drivers/media/vide=
o..

> > Now, who's gonna write a fishing rod driver?
>=20
> The bastard maple devices (fishing rod, maracas, dancepad, etc.) will pro=
bably
> exist as userspace drivers to a generic maple driver interface.  Unless
> someone can provide justification of why they would need to be in the
> kernel?
>=20
Too bad we can't automagically taint the kernel if a bastard maple device is
plugged in.. would serve the user right for hooking one of those abominatio=
ns
up anyways..

Regards,

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

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Mon, Jan 28, 2002:

>=20
> I did find a document this time though. And it appears to be 'webcam' cap=
able=20
> as well as still photos capabale.
>=20

Sounds pretty cool, I *guess* this could fit in a maple input kernel
driver, but I'm not so sure how.

> There is even mention of a 'TV game'. Can anyone think of how such a game=
=20
> might work? I need justification before buying this thing as I already ha=
ve a=20
> digital camera.
>=20

Hey man, it's a testament to Sega's legacy of providing the coolest add-on
devices to their consoles.  What other reason do you need?

> Now, who's gonna write a fishing rod driver?
>=20

The bastard maple devices (fishing rod, maracas, dancepad, etc.) will proba=
bly
exist as userspace drivers to a generic maple driver interface.  Unless
someone can provide justification of why they would need to be in the
kernel?

M. R.

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

On Sunday 27 Jan 2002 6:20 pm, M. R. Brown wrote:

>
> I believe the Linux 2.4 Input subsystem has support for microphones.  Scour
> the web for docs (unfortunately there aren't a lot in the kernel tree) and
> start reading linux/include/linux/input.h.
>
> If it can be done as a Input microphone, I think that would be the
> easiest/coolest.
>

Happy to write (or attempt to write more accurately) whatever driver is most 
helpful/useful, but I assume that the most useful driver will be one that 
sits on top of OSS so that a read call to /dev/dsp reads in whatever is 
coming down the microphone (obviously this does not preclude other 
funcunality).

I have looked at that file, but it doesn't meant much to me (yet) - the 
device is on it's way but not due here for another week or so, so I have 
plenty of time to read up.


Adrian

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

On Sunday 27 Jan 2002 6:20 pm, M. R. Brown wrote:
>
> It's Google time :P.
>

Believe it or not, I had actually looked before and found only documents in 
Japanese at which, on a scale of 0 to 10 I score -1.

I did find a document this time though. And it appears to be 'webcam' capable 
as well as still photos capabale.

There is even mention of a 'TV game'. Can anyone think of how such a game 
might work? I need justification before buying this thing as I already have a 
digital camera.

Now, who's gonna write a fishing rod driver?

Adrian

Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Sun, Jan 27, 2002:

> I have now bought one of these (via ebay). I want to use it to provide so=
und=20
> read capabilities - though I know this will be a maple device.
>=20
> Any thoughts or comments?
>=20

I believe the Linux 2.4 Input subsystem has support for microphones.  Scour
the web for docs (unfortunately there aren't a lot in the kernel tree) and
start reading linux/include/linux/input.h.

If it can be done as a Input microphone, I think that would be the
easiest/coolest.

> The other device I have thought of buying is the Dreameye camera. It is=
=20
> almost as expensive as a BBA (:->) - but what does it do? Does it take st=
ills=20
> only or is it webcam capable?
>=20

It's Google time :P.

I've been thinking about getting a karaoke device - to determine how the
expansion port passthrough mechanism works.  It may also be some sort of
input device (as well as output), who knows?

M. R.

[linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

I have now bought one of these (via ebay). I want to use it to provide sound 
read capabilities - though I know this will be a maple device.

Any thoughts or comments?

The other device I have thought of buying is the Dreameye camera. It is 
almost as expensive as a BBA (:->) - but what does it do? Does it take stills 
only or is it webcam capable?


Adrian

[linuxdc-dev]Patch for sound driver (again)

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

Ooops, left out the big block of comments at the start.

Corrected patch below. Will commit this morning.

--- main.c	Sat Jan 26 11:38:03 2002
+++ aica.c	Sun Jan 27 10:58:03 2002
@@ -1,22 +1,23 @@
-/////////////////////////////////////////////////////////
-// OSS compliant sound driver for Dreamcast Linux      //
-// New coding is                                       //
-// Copyright (C) Adrian McMenamin 2001, 2002           //
-// ad...@mc...                            //
-//                                                     //
-// Substantially based on Dan Potter's Kallistios code //
-// Copyright Dan Potter and others, 2000, 2001         //
-//                                                     //
-//                                                     //
-// Licencsed under FSF's General Public Licence v2     //
-// http://www.gnu.org                                  //
-// Absolutely no warranty is offered                   //
-/////////////////////////////////////////////////////////
-//
-//
-// This drives the SH4 end of the sound driver
-/////////////////////////////////////////////////////////
-/////////////////////////////////////////////////////////
+/*=======================================================
+== OSS compliant sound driver for Dreamcast Linux      ==
+== New coding is                                       ==
+== Copyright (C) Adrian McMenamin 2001, 2002           ==
+== ad...@mc...                            ==
+==                                                     ==
+== Substantially based on Dan Potter's Kallistios code ==
+== Copyright Dan Potter and others, 2000, 2001         ==
+==                                                     ==
+==                                                     ==
+== Licencsed under FSF's General Public Licence v2     ==
+== http://www.gnu.org                                  ==
+== Absolutely no warranty is offered                   ==
+=========================================================
+==
+==
+== This drives the SH4 end of the sound driver
+=========================================================
+=======================================================*/
+
 #include <linux/init.h>
 #include <linux/config.h>
 #include <linux/module.h>
@@ -32,7 +33,7 @@
 #include <asm/semaphore.h>
 #include <asm/dc_sysasic.h>
 #include "../sound_config.h"
-#include "arm7.h"		//static array of ARM 7 code
+#include "arm7.h"
 
 /* Command values */
 #define AICA_CMD_KICK 0x80000000
@@ -177,17 +178,17 @@
 
 }
 
+
+/* Stop the ARM7 processor and clear registers
+   for all channels */
 void spu_disable()
 {
 	int i;
-
-	/* Stop the ARM processor */
 	spu_write_wait();
 	uint32_t regval = readl(0xa0702c00);
 	regval |= 1;
 	spu_write_wait();
 	writel(regval, 0xa0702c00);
-	//close down all channels
 	for (i = 0; i < 64; i++) {
 		spu_write_wait();
 		regval = readl(0xa0700000 + (i * 0x80));
@@ -200,26 +201,19 @@
 }
 
 
+/* Halt the sound processor,
+   clear the memory,
+   load some default ARM7 code,
+   and then restart ARM7
+*/
 int spu_init()
 {
-	/* Stop the ARM */
-	spu_disable();
 
-	/* Clear out sound RAM */
+	spu_disable();
 	spu_memset(0, 0, 0x200000 / 4);
-
-	/* Load a default "program" into the SPU that just executes
-	   an infinite loop */
 	*(uint32_t *) 0xa0800000 = 0xea000002;
-
-	/* Start the SPU again */
 	spu_enable();
-
-	// Wait a little
 	schedule();
-
-
-
 	return 0;
 }
 
@@ -251,52 +245,48 @@
 typedef struct aica_dev {
 
 	struct aica_dev *next_dev;
-	int channel;		//which one are we using here?  
-	int audio_minor;	//device number
-	int mixer_minor;	//device number
-	wait_queue_head_t open_wait;	//wait queue
-	int last_write_length;	//length of data last written to device
-	int sformat;		//format of data being written
+	int channel;		/* which one are we using here? */
+	int audio_minor;	/* device number */
+	int mixer_minor;	/* device number */
+	wait_queue_head_t open_wait;	/* wait queue */
+	int last_write_length;	/* length of data last written to device */
+	int sformat;		/* format of data being written */
 
 } aica_dev_t;
 
-//static linked list of all open devices
+/* List of all open devices */
 static aica_dev_t *aica_dev_list;
 
 
+/* open the device file, locking AICA registers as we go */
+
 static int aica_audio_open(struct inode *inode, struct file *file)
 {
 	aica_dev_t *devc;
 	dev_t minor = MINOR(inode->i_rdev);
 	MOD_INC_USE_COUNT;
 
-	/* open the channel
-	 * locking the memory as appropriate
-	 */
+
 	devc = aica_dev_list;
-	
+
 	if (down_interruptible(&dsp_mutex))
 		return -ERESTARTSYS;
 
-	//Lock channels 1 & 2
 	request_mem_region(0xa0700000, 0x100, "AICA Channels");
 
-	//sample type - based on which device has been opened
 	chanh = kmalloc(sizeof(aica_channel), GFP_KERNEL);
 	if (chanh == NULL)
 		return -ENOMEM;
 	chanh->flags = 0;
 
 	if ((minor & 0xF) == SND_DEV_DSP) {
-		chanh->sfmt = SM_8BIT;	//AICA format
-		devc->sformat = AFMT_U8;	//OSS default format for this device
+		chanh->sfmt = SM_8BIT;
+		devc->sformat = AFMT_U8;
 	} else if ((minor & 0xF) == SND_DEV_DSP16) {
 		chanh->sfmt = SM_16BIT;
 		devc->sformat = AFMT_S16_LE;
 	} else {
-		//total failure!
 		DEBGM("Attempting to open an unsupported device file\n");
-		//unlock channel
 		release_mem_region(0xa0700000, 0x100);
 		up(&dsp_mutex);
 		MOD_DEC_USE_COUNT;
@@ -306,7 +296,6 @@
 	devc->last_write_length = 0;
 	file->private_data = devc;
 
-	//Start AICA
 	spu_disable();
 	spu_memset(0, 0, 0x31000);
 	spu_memload(0, bin_arm7, sizeof(bin_arm7));
@@ -317,12 +306,15 @@
 	chanh->vol = left_volume;
 	chanh->pan = 0x80;
 	chanh->pos = 0;
-	chanh->freq = 8000;	//8k is defined as the OSS default
+	chanh->freq = 8000;
 	total_count = 0;
 	currentpoint = 0;
 	return 0;
 }
 
+
+/* Release device, waiting for queued audio to play out */
+
 static int aica_audio_release(struct inode *inode, struct file *file)
 {
 	aica_dev_t *devc = (aica_dev_t *) (file->private_data);
@@ -335,8 +327,6 @@
 		playpoint = readl(0xa0810004 + 4);
 		if ((playpoint * samplelength) > currentpoint) {
 			for (i = 0; i < (HZ * 2); i++) {
-				//wait comes back to start of buffer
-
 				interruptible_sleep_on_timeout(&
 							       (devc->
 								open_wait),
@@ -362,7 +352,6 @@
 				break;
 		}
 	}
-	//reached the end of the road
 
 	spu_disable();
 	if (BUFFER)
@@ -386,13 +375,13 @@
 	return 0;
 }
 
+
+/* Perform stereo seperation for 16- and 8-bit samples */
 static int aica_audio_process_stereo(int *count_out, int *count)
 {
-
-	//second channel has largely the same attributes as first
 	int z, y, x, w;
 	*count_out = *count / 2;
-	y = *count_out;		//only need to read this once
+	y = *count_out;
 	BUFFER2 = kmalloc(y, GFP_KERNEL);
 	if (BUFFER2 == NULL)
 		return -1;
@@ -424,10 +413,12 @@
 	return 0;
 }
 
-
+/* Block if buffer full until playing has freed
+   up necessary space. Sleep while waiting for
+   low smaple rates, but lock processor for
+   demaning samples */
 inline static int aica_audio_tidy_buffers(aica_dev_t * devc)
 {
-	//about to overwrite a playing buffer?
 	int playpoint;
 	do {
 		if (chanh->freq < 23000)
@@ -438,10 +429,8 @@
 	} while (((playpoint * samplelength) > currentpoint)
 		 && ((playpoint * samplelength) <
 		     (currentpoint + total_count)));
-	//writing past end of the buffer?
 	if ((currentpoint + total_count) > 0x8000) {
 		currentpoint = 0;
-		//check again
 		do {
 			if (chanh->freq < 23000)
 				interruptible_sleep_on_timeout(&
@@ -467,13 +456,11 @@
 	BUFFER = kmalloc(count, GFP_KERNEL);
 	copy_from_user(BUFFER, buffer, count);
 	int count_out = count;
-	//check for any format changes needed
 	samplelength = 1;
 	if (chanh->sfmt == SM_16BIT)
 		samplelength = 2;
 	else if (devc->sformat == AFMT_U8)
 		convert_u8tos8(BUFFER, count);
-	//process stereo if required
 	if (stereo) {
 		if (aica_audio_process_stereo(&count_out, &count) != 0)
 			return -1;
@@ -515,9 +502,11 @@
 	int newdata, left, right, s, m;
 	audio_buf_info info;
 	switch (cmd) {
+
 	case SNDCTL_DSP_GETCAPS:
 		put_user(DSP_CAP_TRIGGER | DSP_CAP_REALTIME, (int *) arg);
 		return 0;
+
 	case SNDCTL_DSP_SETFMT:
 		get_user(newdata, (int *) arg);
 		switch (newdata) {
@@ -540,16 +529,18 @@
 		default:
 			devc->sformat = AFMT_U8;
 			chanh->sfmt = SM_8BIT;
-			//have set a default format
-			//but should return an error
+			/* have set a default format
+			   but should return an error */
 			return -ENOTTY;
 		}
 		put_user(devc->sformat, (int *) arg);
 		return 0;
+
 	case SNDCTL_DSP_GETFMTS:
 		newdata = AFMT_S8 | AFMT_S16_LE | AFMT_IMA_ADPCM;
 		put_user(newdata, (int *) arg);
 		return 0;
+
 	case SNDCTL_DSP_SPEED:
 		get_user(newdata, (int *) arg);
 		if (newdata < 10000) {
@@ -570,16 +561,18 @@
 			chanh->freq = 44100;
 		put_user(chanh->freq, (int *) arg);
 		return 0;
+
 	case SNDCTL_DSP_RESET:
 		chn_halt();
-		//clear memory
 		spu_memset(0x21000, 0, 0x8000);
 		spu_memset(0x11000, 0, 0x8000);
 		currentpoint = 0;
 		return 0;
+
 	case SNDCTL_DSP_GETBLKSIZE:
 		put_user(buffer_size, (int *) arg);
 		return 0;
+
 	case SNDCTL_DSP_SETFRAGMENT:
 		get_user(newdata, (int *) arg);
 		s = newdata & 0xffff;
@@ -592,8 +585,9 @@
 		arg = (m << 16) | s;
 		put_user(0x010f, (int *) arg);
 		return 0;
+
+		/* bytes left to play */
 	case SNDCTL_DSP_GETODELAY:
-		//bytes left to play
 		spu_write_wait();
 		s = readl(0xa0810004 + 4);
 		if ((s * samplelength) > currentpoint) {
@@ -603,8 +597,10 @@
 			newdata = currentpoint - (s * samplelength);
 		put_user(newdata, (int *) arg);
 		return 0;
+
+		/* How many fragments till writing blocks? */
 	case SNDCTL_DSP_GETOSPACE:
-		//how many framents till writing blocks?
+
 		spu_write_wait();
 		s = readl(0xa0810004 + 4);
 		if ((s * samplelength) > currentpoint) {
@@ -615,15 +611,14 @@
 			info.fragments =
 			    ((0x8000 - currentpoint) +
 			     (s * samplelength)) / buffer_size;
-
-		info.fragstotal = 0x8000 / buffer_size;	//total fragments possible
+		info.fragstotal = 0x8000 / buffer_size;
 		info.fragsize = buffer_size;
 		info.bytes = info.fragments * buffer_size;
 		copy_to_user((audio_buf_info *) arg, &info, sizeof(info));
 		return 0;
+
 	case SNDCTL_DSP_SYNC:
 	case SNDCTL_DSP_POST:
-		//flushes sound buffer
 		spu_write_wait();
 		s = readl(0xa0810004 + 4);
 		if ((s * samplelength) > currentpoint) {
@@ -631,20 +626,18 @@
 			    currentpoint + 0x8000 - (s * samplelength);
 		} else
 			newdata = currentpoint - (s * samplelength);
-		//work out delay
 		newdata = newdata / samplelength;
-		//in milliseconds
+		/* delay in milliseconds */
 		newdata = (newdata * 1000) / chanh->freq;
-		//sleep that time then kill sound
 		newdata = (newdata * HZ) / 1000;
 		interruptible_sleep_on_timeout(&(devc->open_wait),
 					       newdata);
 		chn_halt();
-		//clear memory
 		spu_memset(0x21000, 0, 0x8000);
 		spu_memset(0x11000, 0, 0x8000);
 		currentpoint = 0;
 		return 0;
+
 	case SNDCTL_DSP_STEREO:
 		get_user(newdata, (int *) arg);
 		if (newdata == 1) {
@@ -662,20 +655,20 @@
 			newdata = 1;
 		put_user(newdata, (int *) arg);
 		return 0;
-		//Supported Mixer ioctls
+
+		/* Supported Mixer ioctls */
 	case SOUND_MIXER_READ_DEVMASK:
 		newdata = SOUND_MASK_PCM | SOUND_MASK_VOLUME;
 		put_user(newdata, (int *) arg);
 		return 0;
+
 	case SOUND_MIXER_WRITE_VOLUME:
 	case SOUND_MIXER_WRITE_PCM:
 		get_user(newdata, (int *) arg);
-		//Stereo channel volume 
 		left = newdata & 0xff;
 		right = (newdata & 0xff00) >> 8;
 		left_volume = left;
 		right_volume = right;
-		//rescale and set
 		chanh->vol = (left * 255) / 100;
 		newdata = ((right * 255) / 100) << 8;
 		newdata = newdata | 0xff;
@@ -701,7 +694,9 @@
 
 };
 
-//Mixer code
+
+/* Mixer code
+   very basic currently */
 
 static int aica_mixer_open(struct inode *inode, struct file *file)
 {
@@ -723,19 +718,19 @@
 		return -1;
 	int newdata, left, right;
 	switch (cmd) {
+
 	case SOUND_MIXER_READ_DEVMASK:
 		newdata = SOUND_MASK_PCM | SOUND_MASK_VOLUME;
 		put_user(newdata, (int *) arg);
 		return 0;
+
 	case SOUND_MIXER_WRITE_VOLUME:
 	case SOUND_MIXER_WRITE_PCM:
 		get_user(newdata, (int *) arg);
-		//Stereo channel volume 
 		left = newdata & 0xff;
 		right = (newdata & 0xff00) >> 8;
 		left_volume = left;
 		right_volume = right;
-		//rescale and set
 		chanh->vol = (left * 255) / 100;
 		newdata = ((right * 255) / 100) << 8;
 		newdata = newdata | 0xff;
@@ -757,11 +752,18 @@
 	ioctl:aica_mixer_ioctl,
 };
 
+
+
+/* Create holder for device, 
+   together with wait queue
+   and then register device
+   with underlying OSS code
+*/
+
 static int __init attach_aica(void)
 {
 	printk
 	    ("AICA audio device driver for Dreamcast Linux - ver 0.1-pre14\n");
-	//initialise data holder for device  
 	aica_dev_t *devc = NULL;
 	sema_init(&dsp_mutex, 1);
 	int err = -ENOMEM;
@@ -770,17 +772,13 @@
 	if (devc == NULL)
 		goto fail0;
 
-	//initialise wait queue
 	init_waitqueue_head(&devc->open_wait);
-	//register device drivers
-	//register sound_dsp with OSS
 	devc->audio_minor = register_sound_dsp(&aica_audio_fops, -1);
 	if (devc->audio_minor < 0) {
 		DEBGM("attach_aica: register_sound_dsp error %d\n", err);
 		err = devc->audio_minor;
 		goto faildsp;
 	}
-	//register mixer with OSS
 	devc->mixer_minor = register_sound_mixer(&aica_mixer_fops, -1);
 	if (devc->mixer_minor < 0) {
 		DEBGM("attach_aica: register_sound_mixer error %d\n", err);
@@ -815,8 +813,6 @@
 
 static int __exit unload_aica(void)
 {
-	//walk through the list
-	//deallocating the lot
 	aica_dev_t *devc;
 	aica_dev_t *devcp;
 	devcp = aica_dev_list;
@@ -835,6 +831,12 @@
 	return 0;
 }
 
+
+
+/* Lock iomem and initialise
+   ARM7 processor
+*/
+
 static int __init init_aica(void)
 {
 
@@ -842,23 +844,19 @@
 	BUFFER2 = NULL;
 	BUFFERL = NULL;
 	BUFFERR = NULL;
-	/* take ownership of register that controls ARM */
 	if (request_mem_region(0xa0702c00, 4, "AICA ARM control") == NULL) {
 		DEBGM
 		    ("Could not take ownership of SPU control register\n");
 		return -ENODEV;
 	}
 
-/*  take ownership of sound memory */
 	if (request_mem_region(0xa0800000, 0x200000, "AICA Sound RAM") ==
 	    NULL) {
 		DEBGM("Could not take ownership of sound RAM\n");
 		return -ENOMEM;
 	}
-	//Basic spu set up
 	spu_init();
 
-	//now create the devfs files etc
 	if (attach_aica()) {
 		DEBGM("Failed to initialise AICA sound driver\n");
 		return -EINVAL;
@@ -869,19 +867,14 @@
 
 static void __exit exit_aica(void)
 {
-//set low bit of register to 1
 
 	DEBGM("AICA sound driver being unloaded...\n");
-
 	if (unload_aica())
 		DEBGM("Error in unloading AICA\n");
 
-	spu_init();		//revert to neutral state
-
+	spu_init();
 
-/*    //release the SPU control register   */
 	release_mem_region(0xa0702c00, 4);
-	//release the sound memory 
 	release_mem_region(0xa0800000, 0x200000);
 
 }

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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 10:39:16PM -0800, Fredrik Hubinette wrote:
> 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.
>=20
As far as speed. 32bit requests are just fine as well. You have no performa=
nce
gains going the block-aligned route. Though you're free to profile this and
prove me wrong if you wish.

> > MTD fully supports block devices. Devices are generally registered thro=
ugh
> > mtdchar, which gives character device access to registered devices.. bu=
t you
> > can just as easily build in mtdblock support, load that, and have all y=
our
> > registered devices accessible as block devices.
>=20
> But can you write a low-level mtd driver which doesn't have to
> be able to read one byte at a time?
>=20
You don't _have_ to do byte access at all. You're free to do 16bit and 32bit
requests all day long. Again, the 8bit read/write routine in the driver was
simply there as an example of how to wrap things. I can add 16/32bit support
if it'll really make you happy.

> > Size is static for all VMU's, since even the banked ones are only toggl=
eable
> > via a hardware switch. As far as block size (as far as the fs is concer=
ned),
> > this can all be mapped over top of the VMU flash.. all access to the de=
vice is
> > forced through maple blocks anyways, so it really doesn't matter what y=
ou want
> > to deal with your fs block size as.. it all gets wrapped in the end..
>=20
> 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.
>=20
Well, that's fine and all. Things like block size and number of blocks are
completely configurable through my driver, so that's a non-issue.

> > Why would you want to store any of this information in a block on the d=
evice?
> > Your superblock already does all of this for you. Though for things lik=
e the
> > VMU file system, where the superblock resides at the _end_ of the flash=
 ..
> > things get a little wierder.
>=20
> 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.=20
>=20
And the point of this is .. ? All stock unmodified VMU's are going to have =
the
fs consistent and will have the superblock in the same location. Whether you
wish to move this around at a later point in time or not is really pretty
irrelevant. Realistically, the majority of people who want to read/write the
VMU's are going to be those who want to modify existing saved game data.. so
repositioning the superblock is pretty much useless. And for most "sane"
filesystems, the superblock will reside at the beginning of the volume .. so
repositioning this stuff is still useless.

> > 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 tol=
d you a
> > good while ago that a driver was already in place and was merely in nee=
d of a
> > bit of fixing up.. reinventing the wheel is a completely useless activi=
ty
> > here).
>=20
> 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 timeo=
ut
>  after each write)
>=20
Again, you seem to misunderstand things like 16 and 32bit writes being
supported. Since this has been stated about a dozen times by now, I'll pres=
ume
you've caught on to the fact that you can indeed do non-byte access to the
device and that you can indeed push more than 50-60 bytes per second to the
VMU. As far as the timeout is concerned.. that's a pretty useless point, and
can easily be pushed into the existing MTD driver.

If you think you need a new wheel to accomplish this, then go right ahead..
you're entitled to spend as much time heading down the wrong path as you li=
ke.
Though it would be nice if you were doing something that would benefit
everyone (ie, VMU fs) instead of trying to reinvent those things that don't
need reinventing.

Regards,

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

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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 10:49:27PM -0800, Fredrik Hubinette wrote:
> > As far as sizes are concerned.. take a look at include/linux/mtd/map.h =
..
> >=20
> >         __u8 (*read8)(struct map_info *, unsigned long);
> >         __u16 (*read16)(struct map_info *, unsigned long);
> > 	__u32 (*read32)(struct map_info *, unsigned long);
> >=20
> > [snip]
> >=20
> >         void (*write8)(struct map_info *, __u8, unsigned long);
> >         void (*write16)(struct map_info *, __u16, unsigned long);
> >         void (*write32)(struct map_info *, __u32, unsigned long);
> >=20
> > So no .. in no way are you limited to 8-bit only access..
>=20
> None of these functions provide access to a whole block of data though,
> which is what would make most sense for a maple VMU device.
>=20
No, requests are dealt with in a manner that's MTD-sane. You aren't going to
be dealing with block-aligned requests in much of anything else either, so
there's really not much point in deviating from this.

In addition to this, maple isn't that fast, and 128k flash isn't that big. =
You
aren't going to run into much as far as an I/O bottleneck by breaking things
out into 8/16/32bit requests.

> Well, I'm planning on writing a user-space utility for reading/writing
> vmus first. That way I can make sure I have all the details right before
> I implement an actual filesystem. I need access to the actual device first
> though.
>=20
Okay. Well, you can try doing it through the block layer directly if you
really want.. but I think you're going to run into a lot more drawbacks this
way instead of going through MTD. Though since I likely won't be hacking on
the MTD driver in the next couple of days, you might wish to persue the blo=
ck
driver idea if you want something quick and dirty to get you to the point
where you can start hacking on the VMU fs.

Regards,

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

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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 10:42:39PM -0800, Fredrik Hubinette wrote:
> > Right. Maple is stupid. If we could have raw access to the device and j=
ust
> > map the whole region directly, it wouldn't be a problem.. the problem i=
s that
> > the only kind of access to the device that we have is in full blocks. I=
f we
> > don't want to read in a whole block, we still need to do the math to fi=
nd out
> > where the end of our read sits, read that block, and then deal with mas=
king
> > off only that which we're interested in, and handing it all back.. it's=
 not a
> > very fun system, but the driver is documented and does outline all of t=
his..
> > so it shouldn't be of much surprise to anyone.
> >=20
> I do not see block access as a problem. IDE, SCSI, floppy and most
> other storage devices deals in blocks only. I don't see why VMUs
> should be any different.
>=20
Block access is fine if you have some form of useless subsystem dealing with
it.. as is the case with IDE and SCSI. Things like flash on the other hand
where you generally need to have raw access to the device through useful me=
ans
like proper addresses, become somewhat of an oddity to deal with through bl=
ock
access.. especially through a subsystem that isn't too particularly friendly
with it (ie, MTD). Though doing a workaround for this (as is the case with =
my
driver) isn't that big of a deal .. and is definately the optimal solution =
for
this problem that I can think of anyways..

Regards,

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

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

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

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

> On Sat, Jan 26, 2002 at 05:15:40PM -0800, Fredrik Hubinette wrote:
> > Well, I might be reading the whole thing wrong, but as I understand
> > the code, it provides both char and block devices for each mtd device.
> > However, the mtd map handler has a byte-based interface which seems
> > like a lot of extra work to implement. This may however be incorrect.
> > I will do some more reading, but maybe someone more knowledge can save
> > me some trouble by pointing me in the right direction?
> > 
> See my previous mail regarding character/block device access..
> 
> As far as sizes are concerned.. take a look at include/linux/mtd/map.h ..
> 
>         __u8 (*read8)(struct map_info *, unsigned long);
>         __u16 (*read16)(struct map_info *, unsigned long);
> 	__u32 (*read32)(struct map_info *, unsigned long);
> 
> [snip]
> 
>         void (*write8)(struct map_info *, __u8, unsigned long);
>         void (*write16)(struct map_info *, __u16, unsigned long);
>         void (*write32)(struct map_info *, __u32, unsigned long);
> 
> So no .. in no way are you limited to 8-bit only access..

None of these functions provide access to a whole block of data though,
which is what would make most sense for a maple VMU device.

> > If this is indeed a misunderstanding on my behalf, then I will definitely
> > use the MTD subsystem since that is probably where vmus *should* be
> > integrated.
> > 
> Grab the latest MTD CVS if you really feel like it ..
> http://linux-mtd.infradead.org .. and start reading source..

I will.

> > I have looked at it. I may not understand it properly, but it seems
> > very incomplete and based on reading/writing one byte at a time, which
> > would be extremely slow. It was part of the reason I thought the mtdmap
> > API was byte-based.
> > 
> Again.. most proof of concepts aren't meant to be used for production
> environments.. I could've sworn we had this same kind of discussion regarding
> the stuff I was doing with maple..

I understand proof-of-concept. I'm just not sure I agree with the concept.

> The stuff is incomplete, but it doesn't take much to fix it.. really the
> majority of work that needs to be done (especially if you want to deal with
> your VMU the way it is) would be to look at writing a linux VMU fs
> implementation. This should be feasible as a hack of fat .. but the superblock
> won't reside at the beginning of the flash.. so that'll need some adjustment.
> 
> Regards,

Well, I'm planning on writing a user-space utility for reading/writing
vmus first. That way I can make sure I have all the details right before
I implement an actual filesystem. I need access to the actual device first
though.

        /Hubbe

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

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

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

> On Sat, Jan 26, 2002 at 07:22:13PM -0600, M. R. Brown wrote:
> > > Well, I might be reading the whole thing wrong, but as I understand
> > > the code, it provides both char and block devices for each mtd device.
> > > However, the mtd map handler has a byte-based interface which seems
> > > like a lot of extra work to implement. This may however be incorrect.
> > > I will do some more reading, but maybe someone more knowledge can save
> > > me some trouble by pointing me in the right direction?
> > 
> > I remember now.  Paul's idea was to read/write from the VMU in blocks, but
> > provide the byte-interface for the currently held block.  If you need byte
> > 512, you'd have to read in that block in order to get to it.  Sound sane?
> > 
> Right. Maple is stupid. If we could have raw access to the device and just
> map the whole region directly, it wouldn't be a problem.. the problem is that
> the only kind of access to the device that we have is in full blocks. If we
> don't want to read in a whole block, we still need to do the math to find out
> where the end of our read sits, read that block, and then deal with masking
> off only that which we're interested in, and handing it all back.. it's not a
> very fun system, but the driver is documented and does outline all of this..
> so it shouldn't be of much surprise to anyone.
> 
> Fucking useless maple.
> 
> Regards,
> 

I do not see block access as a problem. IDE, SCSI, floppy and most
other storage devices deals in blocks only. I don't see why VMUs
should be any different.

        /Fredrik Hubinette

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

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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 07:22:13PM -0600, M. R. Brown wrote:
> > Well, I might be reading the whole thing wrong, but as I understand
> > the code, it provides both char and block devices for each mtd device.
> > However, the mtd map handler has a byte-based interface which seems
> > like a lot of extra work to implement. This may however be incorrect.
> > I will do some more reading, but maybe someone more knowledge can save
> > me some trouble by pointing me in the right direction?
>=20
> I remember now.  Paul's idea was to read/write from the VMU in blocks, but
> provide the byte-interface for the currently held block.  If you need byte
> 512, you'd have to read in that block in order to get to it.  Sound sane?
>=20
Right. Maple is stupid. If we could have raw access to the device and just
map the whole region directly, it wouldn't be a problem.. the problem is th=
at
the only kind of access to the device that we have is in full blocks. If we
don't want to read in a whole block, we still need to do the math to find o=
ut
where the end of our read sits, read that block, and then deal with masking
off only that which we're interested in, and handing it all back.. it's not=
 a
very fun system, but the driver is documented and does outline all of this..
so it shouldn't be of much surprise to anyone.

Fucking useless maple.

Regards,

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

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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 05:15:40PM -0800, Fredrik Hubinette wrote:
> Well, I might be reading the whole thing wrong, but as I understand
> the code, it provides both char and block devices for each mtd device.
> However, the mtd map handler has a byte-based interface which seems
> like a lot of extra work to implement. This may however be incorrect.
> I will do some more reading, but maybe someone more knowledge can save
> me some trouble by pointing me in the right direction?
>=20
See my previous mail regarding character/block device access..

As far as sizes are concerned.. take a look at include/linux/mtd/map.h ..

        __u8 (*read8)(struct map_info *, unsigned long);
        __u16 (*read16)(struct map_info *, unsigned long);
	__u32 (*read32)(struct map_info *, unsigned long);

[snip]

        void (*write8)(struct map_info *, __u8, unsigned long);
        void (*write16)(struct map_info *, __u16, unsigned long);
        void (*write32)(struct map_info *, __u32, unsigned long);

So no .. in no way are you limited to 8-bit only access..

> If this is indeed a misunderstanding on my behalf, then I will definitely
> use the MTD subsystem since that is probably where vmus *should* be
> integrated.
>=20
Grab the latest MTD CVS if you really feel like it ..
http://linux-mtd.infradead.org .. and start reading source..

> I have looked at it. I may not understand it properly, but it seems
> very incomplete and based on reading/writing one byte at a time, which
> would be extremely slow. It was part of the reason I thought the mtdmap
> API was byte-based.
>=20
Again.. most proof of concepts aren't meant to be used for production
environments.. I could've sworn we had this same kind of discussion regardi=
ng
the stuff I was doing with maple..

The stuff is incomplete, but it doesn't take much to fix it.. really the
majority of work that needs to be done (especially if you want to deal with
your VMU the way it is) would be to look at writing a linux VMU fs
implementation. This should be feasible as a hack of fat .. but the superbl=
ock
won't reside at the beginning of the flash.. so that'll need some adjustmen=
t.

Regards,

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