sh: maple: fix empty port handling

Handle timeout response from empty ports of the maple bus to prevent a stuck maple_sentq and a blocked maple bus.

When only some ports are used, e.g. if only keyboard is connected and the other ports are empty, the device tends to timeout and return 0xff for the empty port. This needs to be handled, just like the MAPLE_RESPONSE_NONE response, to detect empty ports and to have usable peripherals, if not all of the ports are utilized. Previously, an empty port resulted in a never cleared maple_sentq which totally blocked the maple bus to be used.

Signed-off-by Florian Fuchs <[email protected]>

---
Note: This patch was tested on real Sega Dreamcast hardware and resulted in a usable keyboard, even when only 1 or 2 ports where populated. The hot-plugging of the keyboard does also work fine.

The description of the timeout response can be obtained on the bottom of of the page: https://mc.pp.se/dc/maplebus.html: "If no response is received before the timeout, a word with all bits set (FFFFFFFF) is written at the Result address."

 drivers/sh/maple/maple.c | 1 +
 include/linux/maple.h    | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

drivers/sh/maple/maple.c +1 -0

index 6dc0549f7900..3d6c716cfc98 100644
@@ -649,6 +649,7 @@ static void maple_dma_handler(struct work_struct *work)
 			list_del_init(&mq->list);
 			switch (code) {
 			case MAPLE_RESPONSE_NONE:
+			case MAPLE_RESPONSE_TIMEOUT:
 				maple_response_none(mdev);
 				break;
 

include/linux/maple.h +2 -1

index 3be4e567473c..4ae3cc6678a8 100644
@@ -27,7 +27,8 @@ enum maple_code {
 	MAPLE_COMMAND_BWRITE,
 	MAPLE_COMMAND_BSYNC,
 	MAPLE_COMMAND_SETCOND,
-	MAPLE_COMMAND_MICCONTROL
+	MAPLE_COMMAND_MICCONTROL,
+	MAPLE_RESPONSE_TIMEOUT = 255
 };
 
 enum maple_file_errors {

base-commit: 24172e0d79900908cf5ebf366600616d29c9b417

Hi Florian.

Quoted 54 lines · Florian Fuchs

Handle timeout response from empty ports of the maple bus to prevent a stuck maple_sentq and a blocked maple bus.

When only some ports are used, e.g. if only keyboard is connected and the other ports are empty, the device tends to timeout and return 0xff for the empty port. This needs to be handled, just like the MAPLE_RESPONSE_NONE response, to detect empty ports and to have usable peripherals, if not all of the ports are utilized. Previously, an empty port resulted in a never cleared maple_sentq which totally blocked the maple bus to be used.

Signed-off-by Florian Fuchs <[email protected]>

---
Note: This patch was tested on real Sega Dreamcast hardware and resulted in a usable keyboard, even when only 1 or 2 ports where populated. The hot-plugging of the keyboard does also work fine.

The description of the timeout response can be obtained on the bottom of of the page: https://mc.pp.se/dc/maplebus.html: "If no response is received before the timeout, a word with all bits set (FFFFFFFF) is written at the Result address."

 drivers/sh/maple/maple.c | 1 +
 include/linux/maple.h    | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

drivers/sh/maple/maple.c +1 -0

index 6dc0549f7900..3d6c716cfc98 100644
@@ -649,6 +649,7 @@ static void maple_dma_handler(struct work_struct 
 *work)
 			list_del_init(&mq->list);
 			switch (code) {
 			case MAPLE_RESPONSE_NONE:
+			case MAPLE_RESPONSE_TIMEOUT:
 				maple_response_none(mdev);
 				break;

include/linux/maple.h +2 -1

index 3be4e567473c..4ae3cc6678a8 100644
@@ -27,7 +27,8 @@ enum maple_code {
 	MAPLE_COMMAND_BWRITE,
 	MAPLE_COMMAND_BSYNC,
 	MAPLE_COMMAND_SETCOND,
-	MAPLE_COMMAND_MICCONTROL
+	MAPLE_COMMAND_MICCONTROL,
+	MAPLE_RESPONSE_TIMEOUT = 255
 };
 
 enum maple_file_errors {

Quoted 1 line

base-commit: 24172e0d79900908cf5ebf366600616d29c9b417

Thanks for your patch! I'll try to get it reviewed in the weekend.

In the meantime, I'll like to add Artur Rojek who did some work for Linux on the Dreamcast as well if I remember correctly. Maybe he could test your patch as I currently don't have my Dreamcast set up for testing.

Adrian

thanks for the patch! Can this be tested with just regular controllers?

Hi Artur,
thank you so much for fixing the DC boot on linux again! Adrian, thank you for looking at it!

Quoted 1 line · Artur Rojek

thanks for the patch! Can this be tested with just regular controllers?

Yes, indeed you can test it with the controller, when you compile with joystick support, like:

CONFIG_MAPLE=y
CONFIG_INPUT=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_MAPLE=y

You should not put a VMU in though, as thats currently broken (I have a patch ready).

Then you can directly read from the evdev and listen for the button presses:

	bash-5.3# cat /dev/input/event2 | xxd

You need to press a button for 20-30 times, as it seems to buffer the events and outputs it in batches.

Then, you should see the following outputs for the buttons:

Button A:

	00000000: 7800 0000 94c3 0d00 0100 3001 0000 0000  x.........0.....
Button B:
	000001e0: 7800 0000 94c3 0d00 0100 3101 0100 0000  x.........1....
Button X:
	000003b0: 7800 0000 94c3 0d00 0100 3301 0100 0000  x.........3.....
Button Y:
	00000900: 7800 0000 94c3 0d00 0100 3401 0100 0000  x.........4.....

The Joystick should be detected like this:
/ # dmesg|grep maple
maple: bus core now registered
maple (null): detected Dreamcast Controller: function 0x1: at (2, 0) maple (null): no driver found
input: Dreamcast Controller as /devices/maple/2:00.1/input/input2

Another indicator is the dmesg log for empty ports:
maple (null): no devices to port 3

These messages were previously not there, as the empty ports were never detected.

btw, I have also a cdi file, that boots for me, although I heard there were issues on the NTSC-U devices, if helpful:
https://github.com/foxdrodd/dreamcast-linux/releases/download/6.17.7/linux6177-joystick.cdi

Thank you for your efforts,
Florian

Quoted 46 lines · Florian Fuchs

Hi Artur,
thank you so much for fixing the DC boot on linux again! Adrian, thank you for looking at it!

Quoted 2 lines · Artur Rojek

thanks for the patch! Can this be tested with just regular controllers?

Yes, indeed you can test it with the controller, when you compile with joystick support, like:

CONFIG_MAPLE=y
CONFIG_INPUT=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_MAPLE=y

You should not put a VMU in though, as thats currently broken (I have a patch ready).

Then you can directly read from the evdev and listen for the button presses:

	bash-5.3# cat /dev/input/event2 | xxd

You need to press a button for 20-30 times, as it seems to buffer the events and outputs it in batches.

Then, you should see the following outputs for the buttons:

Button A:

	00000000: 7800 0000 94c3 0d00 0100 3001 0000 0000  x.........0.....
Button B:
	000001e0: 7800 0000 94c3 0d00 0100 3101 0100 0000  x.........1....
Button X:
	000003b0: 7800 0000 94c3 0d00 0100 3301 0100 0000  x.........3.....
Button Y:
	00000900: 7800 0000 94c3 0d00 0100 3401 0100 0000  x.........4.....

The Joystick should be detected like this:
/ # dmesg|grep maple
maple: bus core now registered
maple (null): detected Dreamcast Controller: function 0x1: at (2, 0) maple (null): no driver found
input: Dreamcast Controller as /devices/maple/2:00.1/input/input2

Quoted 5 lines

Another indicator is the dmesg log for empty ports:
maple (null): no devices to port 3

These messages were previously not there, as the empty ports were never detected.

Hey Florian,

Before applying this patch, no input on a maple port is being registered until all 4 maple ports are populated (in my case by four controllers). Once all 4 are plugged in, I can register input on either of them by cat-ing their respective char devs.

After applying the patch, I confirm that input can be read immediately for the present devices, even if the other ports are unpopulated.

However, this patch also breaks hotplug on maple ports - I can no longer plug in additional controllers at runtime and have them show up.

I think we need to hold off on this patch until the hotplug issue is addressed.

Quoted 66 lines · Artur Rojek

Quoted 46 lines · Florian Fuchs

Hi Artur,
thank you so much for fixing the DC boot on linux again! Adrian, thank you for looking at it!

Quoted 2 lines · Artur Rojek

thanks for the patch! Can this be tested with just regular controllers?

Yes, indeed you can test it with the controller, when you compile with joystick support, like:

CONFIG_MAPLE=y
CONFIG_INPUT=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_MAPLE=y

You should not put a VMU in though, as thats currently broken (I have a patch ready).

Then you can directly read from the evdev and listen for the button presses:

	bash-5.3# cat /dev/input/event2 | xxd

You need to press a button for 20-30 times, as it seems to buffer the events and outputs it in batches.

Then, you should see the following outputs for the buttons:

Button A:

	00000000: 7800 0000 94c3 0d00 0100 3001 0000 0000  x.........0.....
Button B:
	000001e0: 7800 0000 94c3 0d00 0100 3101 0100 0000  x.........1....
Button X:
	000003b0: 7800 0000 94c3 0d00 0100 3301 0100 0000  x.........3.....
Button Y:
	00000900: 7800 0000 94c3 0d00 0100 3401 0100 0000  x.........4.....

The Joystick should be detected like this:
/ # dmesg|grep maple
maple: bus core now registered
maple (null): detected Dreamcast Controller: function 0x1: at (2, 0) maple (null): no driver found
input: Dreamcast Controller as /devices/maple/2:00.1/input/input2

Quoted 5 lines

Another indicator is the dmesg log for empty ports:
maple (null): no devices to port 3

These messages were previously not there, as the empty ports were never detected.

Hey Florian,

Before applying this patch, no input on a maple port is being registered until all 4 maple ports are populated (in my case by four controllers). Once all 4 are plugged in, I can register input on either of them by cat-ing their respective char devs.

After applying the patch, I confirm that input can be read immediately for the present devices, even if the other ports are unpopulated.

However, this patch also breaks hotplug on maple ports - I can no longer plug in additional controllers at runtime and have them show up.

Quoted 3 lines

I think we need to hold off on this patch until the hotplug issue is addressed.

Thank you for taking the time to test it! And sorry for the obvious issue, I think my testing was wrong as I just removed and plugged in an already registered device, and missed it with a new one.

Regards,
Florian

Quoted 46 lines · Florian Fuchs

Hi Artur,
thank you so much for fixing the DC boot on linux again! Adrian, thank you for looking at it!

Quoted 2 lines · Artur Rojek

thanks for the patch! Can this be tested with just regular controllers?

Yes, indeed you can test it with the controller, when you compile with joystick support, like:

CONFIG_MAPLE=y
CONFIG_INPUT=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_MAPLE=y

You should not put a VMU in though, as thats currently broken (I have a patch ready).

Then you can directly read from the evdev and listen for the button presses:

	bash-5.3# cat /dev/input/event2 | xxd

You need to press a button for 20-30 times, as it seems to buffer the events and outputs it in batches.

Then, you should see the following outputs for the buttons:

Button A:

	00000000: 7800 0000 94c3 0d00 0100 3001 0000 0000  x.........0.....
Button B:
	000001e0: 7800 0000 94c3 0d00 0100 3101 0100 0000  x.........1....
Button X:
	000003b0: 7800 0000 94c3 0d00 0100 3301 0100 0000  x.........3.....
Button Y:
	00000900: 7800 0000 94c3 0d00 0100 3401 0100 0000  x.........4.....

The Joystick should be detected like this:
/ # dmesg|grep maple
maple: bus core now registered
maple (null): detected Dreamcast Controller: function 0x1: at (2, 0) maple (null): no driver found
input: Dreamcast Controller as /devices/maple/2:00.1/input/input2

Quoted 5 lines

Another indicator is the dmesg log for empty ports:
maple (null): no devices to port 3

These messages were previously not there, as the empty ports were never detected.

Hey Florian,

Before applying this patch, no input on a maple port is being registered until all 4 maple ports are populated (in my case by four controllers). Once all 4 are plugged in, I can register input on either of them by cat-ing their respective char devs.

After applying the patch, I confirm that input can be read immediately for the present devices, even if the other ports are unpopulated.

However, this patch also breaks hotplug on maple ports - I can no longer plug in additional controllers at runtime and have them show up.

I think we need to hold off on this patch until the hotplug issue is addressed.

Quoted 1 line

Quoted 3 lines

btw, I have also a cdi file, that boots for me, although I heard there were issues on the NTSC-U devices, if helpful:
https://github.com/foxdrodd/dreamcast-linux/releases/download/6.17.7/linux6177-joystick.cdi

Thanks for the cdi. I have no means to burn CDs anymore, so instead I quickly built a small buildroot based rootfs, and booted it as initramfs over serial line :-)