* [PATCH RESEND v4 2/2] elantech: Call psmouse_reset when elantech probe fails
From: Ulrik De Bie @ 2014-08-20 18:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Hans de Goede, David Herrmann, ulrik.debie-os
In-Reply-To: <1408558692-11736-1-git-send-email-ulrik.debie-os@e2big.org>
elantech_init() calls elantech_set_absolute_mode which sets the driver in
an absolute mode. When after this the elantech_init fails, it is best
to turn the ps/2 mouse emulation mode back on by calling psmouse_reset()
so that it can work as a regular mouse.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
---
drivers/input/mouse/elantech.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 5dd620a..771291c 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1620,6 +1620,7 @@ int elantech_init(struct psmouse *psmouse)
sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
&elantech_attr_group);
init_fail:
+ psmouse_reset(psmouse);
kfree(etd);
return error;
}
--
2.1.0.rc1
^ permalink raw reply related
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Dmitry Torokhov @ 2014-08-20 14:49 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <s5hfvgrwe59.wl-tiwai@suse.de>
On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote:
> At Wed, 20 Aug 2014 09:05:58 +0200,
> Takashi Iwai wrote:
> > Well, it worked on my test machine a year ago or so. Maybe I had a
> > good luck.
>
> FYI, now I tested again an analog joystick on SB Live put on a Dell
> IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as
> is.
>
> So it's not that broken.
That's probably because in your system TSCs are stable when switching CPU
frequency. Earlier systems had bunch of issues there IIRC.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Dmitry Torokhov @ 2014-08-20 14:48 UTC (permalink / raw)
To: Andreas Mohr
Cc: Takashi Iwai, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <20140820142719.GA15319@rhlx01.hs-esslingen.de>
On Wed, Aug 20, 2014 at 04:27:19PM +0200, Andreas Mohr wrote:
> > > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > > > choice for longer times) would be affected by Cpufreq...
> > > > And there are no details on how exactly cpufreq is a problem or how this
> > > > timing issue could be fixed...
> > >
> > > If you take a look at gameport_measure_speed() in gameport.c you will see that
> > > it counts cycles for timing, which obviously does not work that well when CPU
> > > frequency changes.
> > >
> > > The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> > > stepped up to fix that.
>
> He probably meant one issue filed about this problem here:
> "Direct use of tsc: Analog joystick doesn't work properly with CPU
> frequency scaling activated"
> https://bugzilla.kernel.org/show_bug.cgi?id=12297
> right?
Right. There is also about a3d joystick not workign and I think a few others.
>
> > Hm, can't we just use the standard ktime for measuring the time diff?
> > And, I guess only few programs care the speed parameter.
>
> For clocksource matters, I've got an initial patch for Azt3328 which
> adds its 1MHz timer as a clocksource, which probably means that on this
> hardware the gameport would be accurate for both digital and non-digital
> modes (not that that would help much for machines without this soundcard
> which also don't sport a high-res timer...).
>
> Since I've got some more patches waiting for some gameport compatible
> soundcard devices, I should be able to take this opportunity to retest
> gameport support, too...
> And since there's in fact my VIA system which has my second azt3328 in
> its single-slot PCI and which in fact probably is a cpufreq system,
> I might be able to work on fixing the cpufreq timer issue (but if
> Vojtech managed to golden his offer to work on a fix to this issue, I
> would be far from unhappy :).
>
>
>
> BTW, I think I spotted a bug in the gameport removal commit (one driver
> did an if (!joystick) ... where the subsequent line was removed as well
> even though logically it quite likely shouldn't).
>
>
> From my POV it would be much more favourable to do this relatively simple(??)
> timer fix rather than removing an entire subsystem since it's partially(?)
> broken.
Fair enough. If you send me patches that fixes issues then I do not see any
problem with it staying in. Vojtech also promised to dig out his old hardware.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Andreas Mohr @ 2014-08-20 14:27 UTC (permalink / raw)
To: Takashi Iwai
Cc: Dmitry Torokhov, Andreas Mohr, linux-input, linux-kernel,
Vojtech Pavlik, Jiri Kosina
In-Reply-To: <s5hwqa3hetu.wl-tiwai@suse.de>
Hi,
Sorry for having introduced a cut in discussion threading (broken
formatting which caused In-Reply-To header loss).
Will add several slightly disconnected items in single mail
due to restricted environment.
On Wed, Aug 20, 2014 at 08:09:49AM +0200, Takashi Iwai wrote:
> At Tue, 19 Aug 2014 22:18:15 -0700,
> Dmitry Torokhov wrote:
> >
> > Hi Andreas,
> >
> > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
> > > drivers (where the ones I'm owning hardware of are intended to be in
> > > active maintenance)
> >
> > Are you actively testing gameport interfaces with real joysticks/gamepads on
> > these cards? And what software is still in use that runs on these old boxes
> > (with mainline kernel)?
>
> MPlayer and some programs have the joystick interface (even often
> activated as default), IIRC. I don't use it. But I tested it
> sometime ago.
BTW, I have a slightly extended vested interest in that topic since I
did initial joystick driver support on Wine, too...
(Read: there is the possibility of using many Windows apps with their
joystick support, too - not to mention the various arcade emulators
which probably have that as well).
> > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > > choice for longer times) would be affected by Cpufreq...
> > > And there are no details on how exactly cpufreq is a problem or how this
> > > timing issue could be fixed...
> >
> > If you take a look at gameport_measure_speed() in gameport.c you will see that
> > it counts cycles for timing, which obviously does not work that well when CPU
> > frequency changes.
> >
> > The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> > stepped up to fix that.
He probably meant one issue filed about this problem here:
"Direct use of tsc: Analog joystick doesn't work properly with CPU
frequency scaling activated"
https://bugzilla.kernel.org/show_bug.cgi?id=12297
right?
> Hm, can't we just use the standard ktime for measuring the time diff?
> And, I guess only few programs care the speed parameter.
For clocksource matters, I've got an initial patch for Azt3328 which
adds its 1MHz timer as a clocksource, which probably means that on this
hardware the gameport would be accurate for both digital and non-digital
modes (not that that would help much for machines without this soundcard
which also don't sport a high-res timer...).
Since I've got some more patches waiting for some gameport compatible
soundcard devices, I should be able to take this opportunity to retest
gameport support, too...
And since there's in fact my VIA system which has my second azt3328 in
its single-slot PCI and which in fact probably is a cpufreq system,
I might be able to work on fixing the cpufreq timer issue (but if
Vojtech managed to golden his offer to work on a fix to this issue, I
would be far from unhappy :).
BTW, I think I spotted a bug in the gameport removal commit (one driver
did an if (!joystick) ... where the subsequent line was removed as well
even though logically it quite likely shouldn't).
>From my POV it would be much more favourable to do this relatively simple(??)
timer fix rather than removing an entire subsystem since it's partially(?)
broken.
Andreas Mohr
^ permalink raw reply
* Re: USB reset xhci_hcd for ELAN touchscreen
From: Jiri Kosina @ 2014-08-20 13:20 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, linux-usb, Mathias Nyman, linux-input
In-Reply-To: <20140714182526.GA12963@localhost>
On Mon, 14 Jul 2014, Johan Hovold wrote:
> From 8101c0dfd42a232f1d2872de4f412d8d61d5646f Mon Sep 17 00:00:00 2001
> From: Johan Hovold <johan@kernel.org>
> Date: Mon, 14 Jul 2014 18:43:31 +0200
> Subject: [PATCH] HID: usbhid: add HID_QUIRK_IN
>
> Add quirk to submit the interrupt-in urb already at start() rather than
> at open().
>
> This is needed for devices that disconnects from the bus unless the
> interrupt endpoint has been polled at least once or when not responding
> to input events.
It's not really super-nice, but if no other way around it has been found
to be possible in USB core, I am willing to take this.
> ---
> drivers/hid/usbhid/hid-core.c | 26 +++++++++++++++++++++++---
> include/linux/hid.h | 1 +
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 7b88f4c..4b5d986 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
> struct usbhid_device *usbhid = hid->driver_data;
>
> spin_lock_irqsave(&usbhid->lock, flags);
> - if (hid->open > 0 &&
> + if ((hid->open > 0 || hid->quirks & HID_QUIRK_IN) &&
> !test_bit(HID_DISCONNECTED, &usbhid->iofl) &&
> !test_bit(HID_SUSPENDED, &usbhid->iofl) &&
> !test_and_set_bit(HID_IN_RUNNING, &usbhid->iofl)) {
> @@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
> case 0: /* success */
> usbhid_mark_busy(usbhid);
> usbhid->retry_delay = 0;
> + if ((hid->quirks & HID_QUIRK_IN) && !hid->open)
> + break;
> hid_input_report(urb->context, HID_INPUT_REPORT,
> urb->transfer_buffer,
> urb->actual_length, 1);
> @@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
> if (!--hid->open) {
> spin_unlock_irq(&usbhid->lock);
> hid_cancel_delayed_stuff(usbhid);
> - usb_kill_urb(usbhid->urbin);
> - usbhid->intf->needs_remote_wakeup = 0;
> + if (!(hid->quirks & HID_QUIRK_IN)) {
> + usb_kill_urb(usbhid->urbin);
> + usbhid->intf->needs_remote_wakeup = 0;
> + }
> } else {
> spin_unlock_irq(&usbhid->lock);
> }
> @@ -1133,6 +1137,20 @@ static int usbhid_start(struct hid_device *hid)
>
> set_bit(HID_STARTED, &usbhid->iofl);
>
> + hid->quirks |= HID_QUIRK_IN; /* FIXME */
This of course needs to be set on per-device basis :)
> + if (hid->quirks & HID_QUIRK_IN) {
> + ret = usb_autopm_get_interface(usbhid->intf);
> + if (ret)
> + goto fail;
> + usbhid->intf->needs_remote_wakeup = 1;
> + ret = hid_start_in(hid);
> + if (ret) {
> + dev_err(&hid->dev,
> + "failed to start in urb: %d\n", ret);
> + }
> + usb_autopm_put_interface(usbhid->intf);
> + }
> +
> /* Some keyboards don't work until their LEDs have been set.
> * Since BIOSes do set the LEDs, it must be safe for any device
> * that supports the keyboard boot protocol.
> @@ -1165,6 +1183,8 @@ static void usbhid_stop(struct hid_device *hid)
> if (WARN_ON(!usbhid))
> return;
>
> + usbhid->intf->needs_remote_wakeup = 0;
> +
> clear_bit(HID_STARTED, &usbhid->iofl);
> spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */
> set_bit(HID_DISCONNECTED, &usbhid->iofl);
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 77632cf..13f81ae 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -286,6 +286,7 @@ struct hid_item {
> #define HID_QUIRK_HIDINPUT_FORCE 0x00000080
> #define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
> #define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x00000200
> +#define HID_QUIRK_IN 0x00000400
0x00000400 has been removed before dynamic quirks started to be possible,
so there is no potential clash, that's fine.
I'd just propose some more descriptive name for the quirk ... how about
something like HID_QUIRK_EARLY_INTERRUPT?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Geert Uytterhoeven @ 2014-08-20 12:53 UTC (permalink / raw)
To: One Thousand Gnomes
Cc: Takashi Iwai, Dmitry Torokhov, Andreas Mohr,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Vojtech Pavlik, Jiri Kosina
In-Reply-To: <20140820132902.7eed767f@alan.etchedpixels.co.uk>
On Wed, Aug 20, 2014 at 2:29 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
>> It's the gameport core code that is currently broken under some
>> situation, right? If so, marking it as broken is the first step, and
>> we don't need to touch else. We may fix it later, or we may not. If
>> the thing isn't improved, then we can drop the whole stuff.
>
> It's only broken on x86 with frequency changing. x86 is not the only
> platform with ISA or PCI bus or gameports.
>
> It really ought to go via staging, and the other arch maintainers be
> asked. The m68k and mips world does include a department of relics and
> retro-computing 8)
It seems there are no m68k-specific drivers with gameport support...
Good, let's kill all joystick ports that are newer than ports with 2600-style
connectors ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: One Thousand Gnomes @ 2014-08-20 12:29 UTC (permalink / raw)
To: Takashi Iwai
Cc: Dmitry Torokhov, Andreas Mohr, linux-input, linux-kernel,
Vojtech Pavlik, Jiri Kosina
In-Reply-To: <s5htx57hc89.wl-tiwai@suse.de>
> It's the gameport core code that is currently broken under some
> situation, right? If so, marking it as broken is the first step, and
> we don't need to touch else. We may fix it later, or we may not. If
> the thing isn't improved, then we can drop the whole stuff.
It's only broken on x86 with frequency changing. x86 is not the only
platform with ISA or PCI bus or gameports.
It really ought to go via staging, and the other arch maintainers be
asked. The m68k and mips world does include a department of relics and
retro-computing 8)
I suspect nobody cares however.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: One Thousand Gnomes @ 2014-08-20 12:20 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Dmitry Torokhov, Andreas Mohr, linux-input, linux-kernel,
Jiri Kosina, Takashi Iwai
In-Reply-To: <20140820063951.GA6791@suse.cz>
> It wouldn't be hard to fix: That code was developed when the timing
> infrastructure in the kernel was non-existent, making use of it today
> would make things a lot easier.
You can also use pm_qos on most machines to stop PM messing it up. Ugly
but works.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Takashi Iwai @ 2014-08-20 12:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <s5htx57hc89.wl-tiwai@suse.de>
At Wed, 20 Aug 2014 09:05:58 +0200,
Takashi Iwai wrote:
> Well, it worked on my test machine a year ago or so. Maybe I had a
> good luck.
FYI, now I tested again an analog joystick on SB Live put on a Dell
IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as
is.
So it's not that broken.
Takashi
^ permalink raw reply
* [RESEND PATCH 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc, Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez@collabora.co.uk>
From: Andrew Bresticker <abrestic@chromium.org>
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
it is working on the in-progress command.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/mfd/cros_ec.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c53804a..634c434 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -23,6 +23,10 @@
#include <linux/mfd/core.h>
#include <linux/mfd/cros_ec.h>
#include <linux/mfd/cros_ec_commands.h>
+#include <linux/delay.h>
+
+#define EC_COMMAND_RETRIES 50
+#define EC_RETRY_DELAY_MS 10
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
@@ -65,10 +69,39 @@ EXPORT_SYMBOL(cros_ec_check_result);
int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
- int ret;
+ int ret, i;
mutex_lock(&ec_dev->lock);
ret = ec_dev->cmd_xfer(ec_dev, msg);
+ if (ret == -EAGAIN && msg->result == EC_RES_IN_PROGRESS) {
+ /*
+ * Query the EC's status until it's no longer busy or
+ * we encounter an error.
+ */
+ for (i = 0; i < EC_COMMAND_RETRIES; i++) {
+ struct cros_ec_command status_msg;
+ struct ec_response_get_comms_status status;
+
+ msleep(EC_RETRY_DELAY_MS);
+
+ status_msg.version = 0;
+ status_msg.command = EC_CMD_GET_COMMS_STATUS;
+ status_msg.outdata = NULL;
+ status_msg.outsize = 0;
+ status_msg.indata = (uint8_t *)&status;
+ status_msg.insize = sizeof(status);
+
+ ret = ec_dev->cmd_xfer(ec_dev, &status_msg);
+ if (ret < 0)
+ break;
+
+ msg->result = status_msg.result;
+ if (status_msg.result != EC_RES_SUCCESS)
+ break;
+ if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
+ break;
+ }
+ }
mutex_unlock(&ec_dev->lock);
return ret;
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc, Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez@collabora.co.uk>
From: Andrew Bresticker <abrestic@chromium.org>
Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI and LPC drivers.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/mfd/cros_ec.c | 10 +++++++++-
drivers/mfd/cros_ec_spi.c | 11 -----------
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index a9faebd..c53804a 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -65,7 +65,13 @@ EXPORT_SYMBOL(cros_ec_check_result);
int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
- return ec_dev->cmd_xfer(ec_dev, msg);
+ int ret;
+
+ mutex_lock(&ec_dev->lock);
+ ret = ec_dev->cmd_xfer(ec_dev, msg);
+ mutex_unlock(&ec_dev->lock);
+
+ return ret;
}
EXPORT_SYMBOL(cros_ec_cmd_xfer);
@@ -98,6 +104,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
+ mutex_init(&ec_dev->lock);
+
err = mfd_add_devices(dev, 0, cros_devs,
ARRAY_SIZE(cros_devs),
NULL, ec_dev->irq, NULL);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index b396705..bf6e08e 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -79,13 +79,11 @@
* if no record
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
- * @lock: mutex to ensure only one user of cros_ec_cmd_xfer_spi at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
- struct mutex lock;
};
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -232,13 +230,6 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
int sum;
int ret = 0, final_ret;
- /*
- * We have the shared ec_dev buffer plus we do lots of separate spi_sync
- * calls, so we need to make sure only one person is using this at a
- * time.
- */
- mutex_lock(&ec_spi->lock);
-
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
@@ -327,7 +318,6 @@ exit:
if (ec_msg->command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
- mutex_unlock(&ec_spi->lock);
return ret;
}
@@ -359,7 +349,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi->spi = spi;
- mutex_init(&ec_spi->lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 1/7] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc, Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez@collabora.co.uk>
From: Doug Anderson <dianders@chromium.org>
If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
unresponsive for quite a while. Add a delay to the end of the command
to prevent random failures of future commands.
NOTES:
* This could be optimized a bit by simply delaying the next command
sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
complexity doesn't seem worth it.
* This is a bit of an "ugly hack" since the SPI driver is effectively
snooping on the communication and making a lot of assumptions. It
would be nice to architect in some better solution long term.
* This same logic probably needs to be applied to the i2c driver.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/mfd/cros_ec_spi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 588c700..b396705 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -65,6 +65,12 @@
*/
#define EC_SPI_RECOVERY_TIME_NS (200 * 1000)
+/*
+ * The EC is unresponsive for a time after a reboot command. Add a
+ * simple delay to make sure that the bus stays locked.
+ */
+#define EC_REBOOT_DELAY_MS 50
+
/**
* struct cros_ec_spi - information about a SPI-connected EC
*
@@ -318,6 +324,9 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
ret = len;
exit:
+ if (ec_msg->command == EC_CMD_REBOOT_EC)
+ msleep(EC_REBOOT_DELAY_MS);
+
mutex_unlock(&ec_spi->lock);
return ret;
}
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 7/7] Input: cros_ec_keyb: Optimize ghosting algorithm.
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
From: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Previous algorithm was a bit conservative and complicating with
respect to identifying key ghosting. This CL uses the bitops hamming
weight function (hweight8) to count the number of matching rows for
colM & colN. If that number is > 1 ghosting is present.
Additionally it removes NULL keys and our one virtual keypress
KEY_BATTERY from consideration as these inputs are never physical
keypresses.
Signed-off-by: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Reviewed-by: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Reviewed-by: Luigi Semenzato <semenzato-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Tested-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8oXa1LcwEujcA@public.gmane.orgk>
---
drivers/input/keyboard/cros_ec_keyb.c | 92 +++++++++++++++++++----------------
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
index 93111d1..5d773d2 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -22,6 +22,7 @@
*/
#include <linux/module.h>
+#include <linux/bitops.h>
#include <linux/i2c.h>
#include <linux/input.h>
#include <linux/interrupt.h>
@@ -38,6 +39,7 @@
* @row_shift: log2 or number of rows, rounded up
* @keymap_data: Matrix keymap data used to convert to keyscan values
* @ghost_filter: true to enable the matrix key-ghosting filter
+ * @valid_keys: bitmap of existing keys for each matrix column
* @old_kb_state: bitmap of keys pressed last scan
* @dev: Device pointer
* @idev: Input device
@@ -49,6 +51,7 @@ struct cros_ec_keyb {
int row_shift;
const struct matrix_keymap_data *keymap_data;
bool ghost_filter;
+ uint8_t *valid_keys;
uint8_t *old_kb_state;
struct device *dev;
@@ -57,39 +60,15 @@ struct cros_ec_keyb {
};
-static bool cros_ec_keyb_row_has_ghosting(struct cros_ec_keyb *ckdev,
- uint8_t *buf, int row)
-{
- int pressed_in_row = 0;
- int row_has_teeth = 0;
- int col, mask;
-
- mask = 1 << row;
- for (col = 0; col < ckdev->cols; col++) {
- if (buf[col] & mask) {
- pressed_in_row++;
- row_has_teeth |= buf[col] & ~mask;
- if (pressed_in_row > 1 && row_has_teeth) {
- /* ghosting */
- dev_dbg(ckdev->dev,
- "ghost found at: r%d c%d, pressed %d, teeth 0x%x\n",
- row, col, pressed_in_row,
- row_has_teeth);
- return true;
- }
- }
- }
-
- return false;
-}
-
/*
* Returns true when there is at least one combination of pressed keys that
* results in ghosting.
*/
static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t *buf)
{
- int row;
+ int col1, col2, buf1, buf2;
+ struct device *dev = ckdev->dev;
+ uint8_t *valid_keys = ckdev->valid_keys;
/*
* Ghosting happens if for any pressed key X there are other keys
@@ -103,27 +82,23 @@ static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t *buf)
*
* In this case only X, Y, and Z are pressed, but g appears to be
* pressed too (see Wikipedia).
- *
- * We can detect ghosting in a single pass (*) over the keyboard state
- * by maintaining two arrays. pressed_in_row counts how many pressed
- * keys we have found in a row. row_has_teeth is true if any of the
- * pressed keys for this row has other pressed keys in its column. If
- * at any point of the scan we find that a row has multiple pressed
- * keys, and at least one of them is at the intersection with a column
- * with multiple pressed keys, we're sure there is ghosting.
- * Conversely, if there is ghosting, we will detect such situation for
- * at least one key during the pass.
- *
- * (*) This looks linear in the number of keys, but it's not. We can
- * cheat because the number of rows is small.
*/
- for (row = 0; row < ckdev->rows; row++)
- if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
- return true;
+ for (col1 = 0; col1 < ckdev->cols; col1++) {
+ buf1 = buf[col1] & valid_keys[col1];
+ for (col2 = col1 + 1; col2 < ckdev->cols; col2++) {
+ buf2 = buf[col2] & valid_keys[col2];
+ if (hweight8(buf1 & buf2) > 1) {
+ dev_dbg(dev, "ghost found at: B[%02d]:0x%02x & B[%02d]:0x%02x",
+ col1, buf1, col2, buf2);
+ return true;
+ }
+ }
+ }
return false;
}
+
/*
* Compares the new keyboard state to the old one and produces key
* press/release events accordingly. The keyboard state is 13 bytes (one byte
@@ -222,6 +197,30 @@ static void cros_ec_keyb_close(struct input_dev *dev)
free_irq(ec->irq, ckdev);
}
+/*
+ * Walks keycodes flipping bit in buffer COLUMNS deep where bit is ROW. Used by
+ * ghosting logic to ignore NULL or virtual keys.
+ */
+static void cros_ec_keyb_compute_valid_keys(struct cros_ec_keyb *ckdev)
+{
+ int row, col;
+ int row_shift = ckdev->row_shift;
+ unsigned short *keymap = ckdev->idev->keycode;
+ unsigned short code;
+
+ BUG_ON(ckdev->idev->keycodesize != sizeof(*keymap));
+
+ for (col = 0; col < ckdev->cols; col++) {
+ for (row = 0; row < ckdev->rows; row++) {
+ code = keymap[MATRIX_SCAN_CODE(row, col, row_shift)];
+ if (code && (code != KEY_BATTERY))
+ ckdev->valid_keys[col] |= 1 << row;
+ }
+ dev_dbg(ckdev->dev, "valid_keys[%02d] = 0x%02x\n",
+ col, ckdev->valid_keys[col]);
+ }
+}
+
static int cros_ec_keyb_probe(struct platform_device *pdev)
{
struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
@@ -242,6 +241,11 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
&ckdev->cols);
if (err)
return err;
+
+ ckdev->valid_keys = devm_kzalloc(&pdev->dev, ckdev->cols, GFP_KERNEL);
+ if (!ckdev->valid_keys)
+ return -ENOMEM;
+
ckdev->old_kb_state = devm_kzalloc(&pdev->dev, ckdev->cols, GFP_KERNEL);
if (!ckdev->old_kb_state)
return -ENOMEM;
@@ -285,6 +289,8 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
input_set_capability(idev, EV_MSC, MSC_SCAN);
input_set_drvdata(idev, ckdev);
ckdev->idev = idev;
+ cros_ec_keyb_compute_valid_keys(ckdev);
+
err = input_register_device(ckdev->idev);
if (err) {
dev_err(dev, "cannot register input device\n");
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
From: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
If the EC device tree node has sub-nodes, try to instantiate them as
MFD sub-devices. We can configure the EC features provided by the board.
Signed-off-by: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
---
drivers/mfd/cros_ec.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 634c434..96c926c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -21,6 +21,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/mfd/core.h>
+#include <linux/of_platform.h>
#include <linux/mfd/cros_ec.h>
#include <linux/mfd/cros_ec_commands.h>
#include <linux/delay.h>
@@ -109,22 +110,16 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
EXPORT_SYMBOL(cros_ec_cmd_xfer);
static const struct mfd_cell cros_devs[] = {
- {
- .name = "cros-ec-keyb",
- .id = 1,
- .of_compatible = "google,cros-ec-keyb",
- },
- {
- .name = "cros-ec-i2c-tunnel",
- .id = 2,
- .of_compatible = "google,cros-ec-i2c-tunnel",
- },
};
int cros_ec_register(struct cros_ec_device *ec_dev)
{
struct device *dev = ec_dev->dev;
int err = 0;
+#ifdef CONFIG_OF
+ struct device_node *node;
+ int id = ARRAY_SIZE(cros_devs);
+#endif
if (ec_dev->din_size) {
ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
@@ -146,6 +141,31 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
dev_err(dev, "failed to add mfd devices\n");
return err;
}
+#ifdef CONFIG_OF
+ /*
+ * Add sub-devices declared in the device tree. NOTE they should NOT be
+ * declared in cros_devs
+ */
+ for_each_child_of_node(dev->of_node, node) {
+ char name[128];
+ struct mfd_cell cell = {
+ .id = 0,
+ .name = name,
+ };
+
+ if (of_modalias_node(node, name, sizeof(name)) < 0) {
+ dev_err(dev, "modalias failure on %s\n",
+ node->full_name);
+ continue;
+ }
+ dev_dbg(dev, "adding MFD sub-device %s\n", node->name);
+ cell.of_compatible = of_get_property(node, "compatible", NULL);
+ err = mfd_add_devices(dev, ++id, &cell, 1, NULL, ec_dev->irq,
+ NULL);
+ if (err)
+ dev_err(dev, "fail to add %s\n", node->full_name);
+ }
+#endif
dev_info(dev, "Chrome EC device registered\n");
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 3/7] mfd: cros_ec: stop calling ->cmd_xfer() directly
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
From: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Instead of having users of the ChromeOS EC call the interface-specific
cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
to use instead. This will allow us to put all the locking and retry
logic in one place instead of duplicating it across the different
drivers.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Reviewed-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 7 +++++++
include/linux/mfd/cros_ec.h | 24 ++++++++++++++++++------
4 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index a4411da..8ca5cbb 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -229,7 +229,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
msg.indata = response;
msg.insize = response_len;
- result = bus->ec->cmd_xfer(bus->ec, &msg);
+ result = cros_ec_cmd_xfer(bus->ec, &msg);
if (result < 0)
goto exit;
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
index 791781a..93111d1 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -182,7 +182,7 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
.insize = ckdev->cols,
};
- return ckdev->ec->cmd_xfer(ckdev->ec, &msg);
+ return cros_ec_cmd_xfer(ckdev->ec, &msg);
}
static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4873f9c..a9faebd 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -62,6 +62,13 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_check_result);
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ return ec_dev->cmd_xfer(ec_dev, msg);
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
static const struct mfd_cell cros_devs[] = {
{
.name = "cros-ec-keyb",
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index fcbe9d1..0e166b9 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -62,10 +62,6 @@ struct cros_ec_command {
* @dev: Device pointer
* @was_wake_device: true if this device was set to wake the system from
* sleep at the last suspend
- * @cmd_xfer: send command to EC and get response
- * Returns the number of bytes received if the communication succeeded, but
- * that doesn't mean the EC was happy with the command. The caller
- * should check msg.result for the EC's result code.
*
* @priv: Private data
* @irq: Interrupt to use
@@ -82,6 +78,10 @@ struct cros_ec_command {
* @dout_size: size of dout buffer to allocate (zero to use static dout)
* @parent: pointer to parent device (e.g. i2c or spi device)
* @wake_enabled: true if this device can wake the system from sleep
+ * @cmd_xfer: send command to EC and get response
+ * Returns the number of bytes received if the communication succeeded, but
+ * that doesn't mean the EC was happy with the command. The caller
+ * should check msg.result for the EC's result code.
* @lock: one transaction at a time
*/
struct cros_ec_device {
@@ -92,8 +92,6 @@ struct cros_ec_device {
struct device *dev;
bool was_wake_device;
struct class *cros_class;
- int (*cmd_xfer)(struct cros_ec_device *ec,
- struct cros_ec_command *msg);
/* These are used to implement the platform-specific interface */
void *priv;
@@ -104,6 +102,8 @@ struct cros_ec_device {
int dout_size;
struct device *parent;
bool wake_enabled;
+ int (*cmd_xfer)(struct cros_ec_device *ec,
+ struct cros_ec_command *msg);
struct mutex lock;
};
@@ -153,6 +153,18 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg);
/**
+ * cros_ec_cmd_xfer - Send a command to the ChromeOS EC
+ *
+ * Call this to send a command to the ChromeOS EC. This should be used
+ * instead of calling the EC's cmd_xfer() callback directly.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ */
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg);
+
+/**
* cros_ec_remove - Remove a ChromeOS EC
*
* Call this to deregister a ChromeOS EC, then clean up any private data.
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 2/7] i2c: i2c-cros-ec-tunnel: Set retries to 3
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas
In-Reply-To: <1408536812-7836-1-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
From: Derek Basehore <dbasehore-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Since the i2c bus can get wedged on the EC sometimes, set the number of retries
to 3. Since we un-wedge the bus immediately after the wedge happens, this is the
correct fix since only one transfer will fail.
Signed-off-by: Derek Basehore <dbasehore-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Reviewed-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 05e033c..a4411da 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -16,6 +16,8 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
+#define I2C_MAX_RETRIES 3
+
/**
* struct ec_i2c_device - Driver data for I2C tunnel
*
@@ -290,6 +292,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
bus->adap.algo_data = bus;
bus->adap.dev.parent = &pdev->dev;
bus->adap.dev.of_node = np;
+ bus->adap.retries = I2C_MAX_RETRIES;
err = i2c_add_adapter(&bus->adap);
if (err) {
--
2.0.1
^ permalink raw reply related
* [RESEND PATCH 0/7] Second batch of cleanups for cros_ec
From: Javier Martinez Canillas @ 2014-08-20 12:13 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Javier Martinez Canillas
Hello Lee,
This is a resend of a patch series originally sent [0] almost a
month ago (July, 28). The series add a batch of cleanups patches
for the mfd cros_ec driver and its subdevices drivers. The first
batch of cleanups was posted by Doug Anderson [1] and have already
been merged. The patches were taken from the ChromeOS 3.8 kernel
and after this series, no cleanups patches for cros_ec are left.
The remaining commits add support not yet available in mainline.
There is almost no functionality added on this series but the
idea is to reduce the delta between the mainline drivers and
the ones in the downstream Chrome OS 3.8 kernel so the missing
functionality can be added on top once these cleanups patches
are merged. The missing functionlity currently in mainline is:
- Chrome OS Embedded Controller userspace device interface
- Chrome OS Embedded Controller Low Pin Count (LPC) inteface
- Access to vboot context stored on a block device
- Access to vboot context stored on EC's nvram
The patches in this series are authored by different people
(all on cc) and consist of the following:
Andrew Bresticker (3):
mfd: cros_ec: stop calling ->cmd_xfer() directly
mfd: cros_ec: move locking into cros_ec_cmd_xfer
mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
Derek Basehore (1):
i2c: i2c-cros-ec-tunnel: Set retries to 3
Doug Anderson (1):
mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC
Todd Broch (2):
mfd: cros_ec: Instantiate sub-devices from device tree
Input: cros_ec_keyb: Optimize ghosting algorithm.
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 5 +-
drivers/input/keyboard/cros_ec_keyb.c | 89 +++++++++++++++++----------------
drivers/mfd/cros_ec.c | 88 ++++++++++++++++++++++++++++----
drivers/mfd/cros_ec_spi.c | 20 ++++----
include/linux/mfd/cros_ec.h | 24 ++++++---
5 files changed, 154 insertions(+), 72 deletions(-)
There were no changes on this resend, just picked Acked-by and
Tested-by tags and also added my own Signed-off-by tag to all
the patches as suggested by Andreas Färber even when I just
picked them from downstream and rebased on top of linux-next.
The patches should be merged together which means that they
should go through your mfd tree once the relevant acks are
obtained.
Best regards,
Javier
[0]: https://www.mail-archive.com/linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg11385.html
[1]: https://lkml.org/lkml/2014/6/16/681
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Clemens Ladisch @ 2014-08-20 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: linux-kernel, Vojtech Pavlik, Jiri Kosina, Takashi Iwai
In-Reply-To: <1408466497-25640-1-git-send-email-dmitry.torokhov@gmail.com>
Dmitry Torokhov wrote:
> Gameport support hasn't been working well ever since cpufreq became
> mainstream
Back in the gameport-mainstream days, we did not have a usable high-
resolution timer API. But why can't we use something like
getrawmonotonic() now? (Yes, I'm volunteering ...)
> and it becomes increasingly hard to find hardware and software that
> would run on such old hardware.
I have two such sound cards, and a joystick.
Regards,
Clemens
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Takashi Iwai @ 2014-08-20 7:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <20140820063130.GA11226@core.coreip.homeip.net>
At Tue, 19 Aug 2014 23:31:30 -0700,
Dmitry Torokhov wrote:
>
> On Wed, Aug 20, 2014 at 08:09:49AM +0200, Takashi Iwai wrote:
> > At Tue, 19 Aug 2014 22:18:15 -0700,
> > Dmitry Torokhov wrote:
> > >
> > > Hi Andreas,
> > >
> > > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
> > >
> > > > Hi,
> > > >
> > > > > Gameport support hasn't been working well ever since cpufreq became
> > > > > mainstream and it becomes increasingly hard to find hardware and
> > > > > software
> > > > > that would run on such old hardware.
> > > >
> > > > Given that I'm puzzled why one would want to deprecate a whole subsystem
> > > > which appears to be supported by a whole 14 different PCI sound card
> > > > drivers (where the ones I'm owning hardware of are intended to be in
> > > > active maintenance)
> > >
> > > Are you actively testing gameport interfaces with real joysticks/gamepads on
> > > these cards? And what software is still in use that runs on these old boxes
> > > (with mainline kernel)?
> >
> > MPlayer and some programs have the joystick interface (even often
> > activated as default), IIRC. I don't use it. But I tested it
> > sometime ago.
>
> But we are not dropping joystick support, you can still use USB, BT, etc
> joysticks. It is only gameport joysticks that I think are pretty much extinct
> by now.
They are dying, I agree. But is it really extinct? It's hard to
judge.
> > > > and only 3 ISA-based ones, I'm missing several
> > > > details and justifications of that decision here (perhaps there was a
> > > > prior discussion/activity that I'm missing?).
> > >
> > > There was a post to linux-input a few days ago when I ased if anyone woudl cry
> > > over gameport going away.
> >
> > Well, asking the usage in the devel ML isn't enough, I'm afraid.
> > ML is only for a small group of developers, where no user cares unless
> > they hit a problem.
>
> That is true, but what is better venue? Even disabling in Kconfig won't help
> much as distros will re-enable it and users do not compile their own kernels.
I meant to statically disable Kconfig, or just "depends on BROKEN".
Only user who edits Kconfig and build the kernel can enable it again.
> > > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > > > choice for longer times) would be affected by Cpufreq...
> > > > And there are no details on how exactly cpufreq is a problem or how this
> > > > timing issue could be fixed...
> > >
> > > If you take a look at gameport_measure_speed() in gameport.c you will see that
> > > it counts cycles for timing, which obviously does not work that well when CPU
> > > frequency changes.
> > >
> > > The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> > > stepped up to fix that.
> >
> > Hm, can't we just use the standard ktime for measuring the time diff?
>
> We could use high-res timers, if they are available. Are they available on such
> old hardware and are they sufficiently fast to provide needed timings? I
> definitely do not have any hardware to est with.
The boards aren't necessarily bound with the old hardware. PCI boards
run fine on the modern machines if they still have a PCI slot (how
lucky). And, the highres timer itself isn't so new...
> > And, I guess only few programs care the speed parameter.
>
> It is not programs that care about speed parameter, it is joystick kernel
> drivers that need it to time access.
OK.
> > > > The obvious workaround for such an ensuing dearth of hardware support
> > > > could be USB 15-pin gameport adapters - but are they even supported on
> > > > Linux? Haven't seen info on this...
> > > > And even if supported, these adapters (at least the non-perfect ones, as
> > > > can be seen from reviews on a well-known online shop site) are said to
> > > > be hit-or-miss.
> > > >
> > > > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
> > > > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
> > > >
> > >
> > > They have better chance of being supported ;) I had a couple a few years back
> > > and they did work for me.
> > >
> > > > If we keep removing functionality like this, then why stop short of
> > > > removing x86 32bit as a whole? By having Linux support nicely restricted
> > > > to hardware made within the last 5 years, we would surely be doing the
> > > > planned-obsolescence Micro$oft "ecosystem" (what was ecological about
> > > > this again?) a huge favour...
> > >
> > > I really do not care about Microsoft and favors, I just go by the fact that
> > > this hardware is becoming naturally extinct. And not only hardware, but also
> > > software that uses it. Do you still play a lot of games with joysticks on such
> > > hardware?
> >
> > IMO, the number of users is less relevant for such an action. Even if
> > there're only a few users, users do exist.
> >
> > But, if the code maintenance becomes a too big burden, it's time to
> > think of code removal. Is this the case? Really difficult to keep
> > the code?
>
> We can keep it, but it is pretty much broken, so why?
Well, it worked on my test machine a year ago or so. Maybe I had a
good luck.
It's the gameport core code that is currently broken under some
situation, right? If so, marking it as broken is the first step, and
we don't need to touch else. We may fix it later, or we may not. If
the thing isn't improved, then we can drop the whole stuff.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Vojtech Pavlik @ 2014-08-20 6:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Jiri Kosina,
Takashi Iwai
In-Reply-To: <20140820051815.GA1109@core.coreip.homeip.net>
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote:
> Are you actively testing gameport interfaces with real joysticks/gamepads on
> these cards? And what software is still in use that runs on these old boxes
> (with mainline kernel)?
I still do have a huge box of gameport hardware in my office, it's just
that I haven't opened it for a number of years. However, if this thread
spurred enough interest in gameport devices, I would be willing to open
it and do the needed fixes.
If not, I think dropping makes sense. I still would shed a tear for all
those weird devices in the box, and possibly design an ATMega-based
USB<->Gameport adapter that actually works and supports even the digital
joysticks.
> > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > choice for longer times) would be affected by Cpufreq...
> > And there are no details on how exactly cpufreq is a problem or how this
> > timing issue could be fixed...
>
> If you take a look at gameport_measure_speed() in gameport.c you will see that
> it counts cycles for timing, which obviously does not work that well when CPU
> frequency changes.
>
> The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> stepped up to fix that.
It wouldn't be hard to fix: That code was developed when the timing
infrastructure in the kernel was non-existent, making use of it today
would make things a lot easier.
> > The obvious workaround for such an ensuing dearth of hardware support
> > could be USB 15-pin gameport adapters - but are they even supported on
> > Linux? Haven't seen info on this...
> > And even if supported, these adapters (at least the non-perfect ones, as
> > can be seen from reviews on a well-known online shop site) are said to
> > be hit-or-miss.
> >
> > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
> > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
> >
>
> They have better chance of being supported ;) I had a couple a few years back
> and they did work for me.
They do work for analog joysticks if you don't want any extended
functionality. I have a couple in said box.
--
Vojtech Pavlik
Director SuSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Dmitry Torokhov @ 2014-08-20 6:31 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <s5hwqa3hetu.wl-tiwai@suse.de>
On Wed, Aug 20, 2014 at 08:09:49AM +0200, Takashi Iwai wrote:
> At Tue, 19 Aug 2014 22:18:15 -0700,
> Dmitry Torokhov wrote:
> >
> > Hi Andreas,
> >
> > On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
> >
> > > Hi,
> > >
> > > > Gameport support hasn't been working well ever since cpufreq became
> > > > mainstream and it becomes increasingly hard to find hardware and
> > > > software
> > > > that would run on such old hardware.
> > >
> > > Given that I'm puzzled why one would want to deprecate a whole subsystem
> > > which appears to be supported by a whole 14 different PCI sound card
> > > drivers (where the ones I'm owning hardware of are intended to be in
> > > active maintenance)
> >
> > Are you actively testing gameport interfaces with real joysticks/gamepads on
> > these cards? And what software is still in use that runs on these old boxes
> > (with mainline kernel)?
>
> MPlayer and some programs have the joystick interface (even often
> activated as default), IIRC. I don't use it. But I tested it
> sometime ago.
But we are not dropping joystick support, you can still use USB, BT, etc
joysticks. It is only gameport joysticks that I think are pretty much extinct
by now.
>
> > > and only 3 ISA-based ones, I'm missing several
> > > details and justifications of that decision here (perhaps there was a
> > > prior discussion/activity that I'm missing?).
> >
> > There was a post to linux-input a few days ago when I ased if anyone woudl cry
> > over gameport going away.
>
> Well, asking the usage in the devel ML isn't enough, I'm afraid.
> ML is only for a small group of developers, where no user cares unless
> they hit a problem.
That is true, but what is better venue? Even disabling in Kconfig won't help
much as distros will re-enable it and users do not compile their own kernels.
>
> > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > > choice for longer times) would be affected by Cpufreq...
> > > And there are no details on how exactly cpufreq is a problem or how this
> > > timing issue could be fixed...
> >
> > If you take a look at gameport_measure_speed() in gameport.c you will see that
> > it counts cycles for timing, which obviously does not work that well when CPU
> > frequency changes.
> >
> > The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> > stepped up to fix that.
>
> Hm, can't we just use the standard ktime for measuring the time diff?
We could use high-res timers, if they are available. Are they available on such
old hardware and are they sufficiently fast to provide needed timings? I
definitely do not have any hardware to est with.
> And, I guess only few programs care the speed parameter.
It is not programs that care about speed parameter, it is joystick kernel
drivers that need it to time access.
>
>
> > > The obvious workaround for such an ensuing dearth of hardware support
> > > could be USB 15-pin gameport adapters - but are they even supported on
> > > Linux? Haven't seen info on this...
> > > And even if supported, these adapters (at least the non-perfect ones, as
> > > can be seen from reviews on a well-known online shop site) are said to
> > > be hit-or-miss.
> > >
> > > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
> > > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
> > >
> >
> > They have better chance of being supported ;) I had a couple a few years back
> > and they did work for me.
> >
> > > If we keep removing functionality like this, then why stop short of
> > > removing x86 32bit as a whole? By having Linux support nicely restricted
> > > to hardware made within the last 5 years, we would surely be doing the
> > > planned-obsolescence Micro$oft "ecosystem" (what was ecological about
> > > this again?) a huge favour...
> >
> > I really do not care about Microsoft and favors, I just go by the fact that
> > this hardware is becoming naturally extinct. And not only hardware, but also
> > software that uses it. Do you still play a lot of games with joysticks on such
> > hardware?
>
> IMO, the number of users is less relevant for such an action. Even if
> there're only a few users, users do exist.
>
> But, if the code maintenance becomes a too big burden, it's time to
> think of code removal. Is this the case? Really difficult to keep
> the code?
We can keep it, but it is pretty much broken, so why?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Takashi Iwai @ 2014-08-20 6:09 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <20140820051815.GA1109@core.coreip.homeip.net>
At Tue, 19 Aug 2014 22:18:15 -0700,
Dmitry Torokhov wrote:
>
> Hi Andreas,
>
> On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
>
> > Hi,
> >
> > > Gameport support hasn't been working well ever since cpufreq became
> > > mainstream and it becomes increasingly hard to find hardware and
> > > software
> > > that would run on such old hardware.
> >
> > Given that I'm puzzled why one would want to deprecate a whole subsystem
> > which appears to be supported by a whole 14 different PCI sound card
> > drivers (where the ones I'm owning hardware of are intended to be in
> > active maintenance)
>
> Are you actively testing gameport interfaces with real joysticks/gamepads on
> these cards? And what software is still in use that runs on these old boxes
> (with mainline kernel)?
MPlayer and some programs have the joystick interface (even often
activated as default), IIRC. I don't use it. But I tested it
sometime ago.
> > and only 3 ISA-based ones, I'm missing several
> > details and justifications of that decision here (perhaps there was a
> > prior discussion/activity that I'm missing?).
>
> There was a post to linux-input a few days ago when I ased if anyone woudl cry
> over gameport going away.
Well, asking the usage in the devel ML isn't enough, I'm afraid.
ML is only for a small group of developers, where no user cares unless
they hit a problem.
> > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > choice for longer times) would be affected by Cpufreq...
> > And there are no details on how exactly cpufreq is a problem or how this
> > timing issue could be fixed...
>
> If you take a look at gameport_measure_speed() in gameport.c you will see that
> it counts cycles for timing, which obviously does not work that well when CPU
> frequency changes.
>
> The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> stepped up to fix that.
Hm, can't we just use the standard ktime for measuring the time diff?
And, I guess only few programs care the speed parameter.
> > The obvious workaround for such an ensuing dearth of hardware support
> > could be USB 15-pin gameport adapters - but are they even supported on
> > Linux? Haven't seen info on this...
> > And even if supported, these adapters (at least the non-perfect ones, as
> > can be seen from reviews on a well-known online shop site) are said to
> > be hit-or-miss.
> >
> > http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
> > http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
> >
>
> They have better chance of being supported ;) I had a couple a few years back
> and they did work for me.
>
> > If we keep removing functionality like this, then why stop short of
> > removing x86 32bit as a whole? By having Linux support nicely restricted
> > to hardware made within the last 5 years, we would surely be doing the
> > planned-obsolescence Micro$oft "ecosystem" (what was ecological about
> > this again?) a huge favour...
>
> I really do not care about Microsoft and favors, I just go by the fact that
> this hardware is becoming naturally extinct. And not only hardware, but also
> software that uses it. Do you still play a lot of games with joysticks on such
> hardware?
IMO, the number of users is less relevant for such an action. Even if
there're only a few users, users do exist.
But, if the code maintenance becomes a too big burden, it's time to
think of code removal. Is this the case? Really difficult to keep
the code?
Last but not least, the usual steps for such a big deprecation is to
disable the build in Kconfig at first, watch out for a couple of
release cycles, then drop the actual codes. Dropping the whole stuff
from the beginning is too risky, especially if there is no
alternative.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Andreas Mohr @ 2014-08-20 5:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina, Takashi Iwai
In-Reply-To: <20140820051815.GA1109@core.coreip.homeip.net>
On Tue, Aug 19, 2014 at 10:18:15PM -0700, Dmitry Torokhov wrote:
> Hi Andreas,
>
> On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
>
> > Hi,
> >
> > > Gameport support hasn't been working well ever since cpufreq became
> > > mainstream and it becomes increasingly hard to find hardware and
> > > software
> > > that would run on such old hardware.
> >
> > Given that I'm puzzled why one would want to deprecate a whole subsystem
> > which appears to be supported by a whole 14 different PCI sound card
> > drivers (where the ones I'm owning hardware of are intended to be in
> > active maintenance)
>
> Are you actively testing gameport interfaces with real joysticks/gamepads on
> these cards? And what software is still in use that runs on these old boxes
> (with mainline kernel)?
Well, I did test some games with real joysticks
e.g. in order to implement working Digital Enhanced Game Port support
(where BTW the couple cards/driver combos which support that
should also be completely unaffected by cpufreq
since its delay accounting is digital).
> > and only 3 ISA-based ones, I'm missing several
> > details and justifications of that decision here (perhaps there was a
> > prior discussion/activity that I'm missing?).
>
> There was a post to linux-input a few days ago when I ased if anyone woudl cry
> over gameport going away.
Missed that one (not subscribed), sorry.
> > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > choice for longer times) would be affected by Cpufreq...
> > And there are no details on how exactly cpufreq is a problem or how this
> > timing issue could be fixed...
>
> If you take a look at gameport_measure_speed() in gameport.c you will see that
> it counts cycles for timing, which obviously does not work that well when CPU
> frequency changes.
Yup, but at least not for the candidates above.
> The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> stepped up to fix that.
Ouch.
I'm afraid I don't have any cpufreq-supporting hardware (hint, hint)
which would enable me to work on it, though.
> > The obvious workaround for such an ensuing dearth of hardware support
> > could be USB 15-pin gameport adapters - but are they even supported on
> > Linux? Haven't seen info on this...
> > And even if supported, these adapters (at least the non-perfect ones, as
> > can be seen from reviews on a well-known online shop site) are said to
> > be hit-or-miss.
> They have better chance of being supported ;) I had a couple a few years back
> and they did work for me.
Good to know. I took a note to buy a good adapter as well.
> > If we keep removing functionality like this, then why stop short of
> > removing x86 32bit as a whole? By having Linux support nicely restricted
> > to hardware made within the last 5 years, we would surely be doing the
> > planned-obsolescence Micro$oft "ecosystem" (what was ecological about
> > this again?) a huge favour...
>
> I really do not care about Microsoft and favors, I just go by the fact that
> this hardware is becoming naturally extinct. And not only hardware, but also
> software that uses it. Do you still play a lot of games with joysticks on such
> hardware?
Not me (I'm a developer). But other people probably would be inclined to
do so, as long as sufficient support remains in place,
on an architecture which is still in very wide use.
And this case here (as opposed to e.g. the NI5010 ISA BNC network
card where it was arguably very likely that it was totally unused)
seems like a self-fulfilling prophecy...
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Dmitry Torokhov @ 2014-08-20 5:18 UTC (permalink / raw)
To: Andreas Mohr
Cc: linux-input, linux-kernel, Vojtech Pavlik, Jiri Kosina,
Takashi Iwai
In-Reply-To: <20140820024638.GA25240@rhlx01.hs-esslingen.de>
Hi Andreas,
On Wed, Aug 20, 2014 at 04:46:38AM +0200, Andreas Mohr wrote:
> Hi,
>
> > Gameport support hasn't been working well ever since cpufreq became
> > mainstream and it becomes increasingly hard to find hardware and
> > software
> > that would run on such old hardware.
>
> Given that I'm puzzled why one would want to deprecate a whole subsystem
> which appears to be supported by a whole 14 different PCI sound card
> drivers (where the ones I'm owning hardware of are intended to be in
> active maintenance)
Are you actively testing gameport interfaces with real joysticks/gamepads on
these cards? And what software is still in use that runs on these old boxes
(with mainline kernel)?
> and only 3 ISA-based ones, I'm missing several
> details and justifications of that decision here (perhaps there was a
> prior discussion/activity that I'm missing?).
There was a post to linux-input a few days ago when I ased if anyone woudl cry
over gameport going away.
>
> Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> choice for longer times) would be affected by Cpufreq...
> And there are no details on how exactly cpufreq is a problem or how this
> timing issue could be fixed...
If you take a look at gameport_measure_speed() in gameport.c you will see that
it counts cycles for timing, which obviously does not work that well when CPU
frequency changes.
The bugs have been opened in bugzilla/reported on lists ages ago but nobody
stepped up to fix that.
> The obvious workaround for such an ensuing dearth of hardware support
> could be USB 15-pin gameport adapters - but are they even supported on
> Linux? Haven't seen info on this...
> And even if supported, these adapters (at least the non-perfect ones, as
> can be seen from reviews on a well-known online shop site) are said to
> be hit-or-miss.
>
> http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
> http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
>
They have better chance of being supported ;) I had a couple a few years back
and they did work for me.
> If we keep removing functionality like this, then why stop short of
> removing x86 32bit as a whole? By having Linux support nicely restricted
> to hardware made within the last 5 years, we would surely be doing the
> planned-obsolescence Micro$oft "ecosystem" (what was ecological about
> this again?) a huge favour...
I really do not care about Microsoft and favors, I just go by the fact that
this hardware is becoming naturally extinct. And not only hardware, but also
software that uses it. Do you still play a lot of games with joysticks on such
hardware?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Andreas Mohr @ 2014-08-20 2:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, Vojtech Pavlik, Jiri Kosina,
Takashi Iwai
Reply-To:
In-Reply-To: <1408466497-25640-1-git-send-email-dmitry.torokhov@gmail.com>
X-Priority: none
Hi,
> Gameport support hasn't been working well ever since cpufreq became
> mainstream and it becomes increasingly hard to find hardware and
> software
> that would run on such old hardware.
Given that I'm puzzled why one would want to deprecate a whole subsystem
which appears to be supported by a whole 14 different PCI sound card
drivers (where the ones I'm owning hardware of are intended to be in
active maintenance) and only 3 ISA-based ones, I'm missing several
details and justifications of that decision here (perhaps there was a
prior discussion/activity that I'm missing?).
Also, I'm left wondering why e.g. my Athlon XP system (a very popular
choice for longer times) would be affected by Cpufreq...
And there are no details on how exactly cpufreq is a problem or how this
timing issue could be fixed...
The obvious workaround for such an ensuing dearth of hardware support
could be USB 15-pin gameport adapters - but are they even supported on
Linux? Haven't seen info on this...
And even if supported, these adapters (at least the non-perfect ones, as
can be seen from reviews on a well-known online shop site) are said to
be hit-or-miss.
http://www.flightsim.com/vbfs/showthread.php?238938-joystick-GamePort-to-USB-adapter-question
http://reviews.thesource.ca/9026/2600164/nexxtech-usb-gameport-adapter-reviews/reviews.htm
If we keep removing functionality like this, then why stop short of
removing x86 32bit as a whole? By having Linux support nicely restricted
to hardware made within the last 5 years, we would surely be doing the
planned-obsolescence Micro$oft "ecosystem" (what was ecological about
this again?) a huge favour...
We already have an IMHO dangerous state in support of somewhat less mainstream
hardware, so do we want to keep furthering that?
Could we have more details/discussion prior to activities to remove
whole subsystems?
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox