Re: [PATCH v2 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC
On 26/01/15 23:01, Jonathan Cameron wrote: On 25/01/15 18:47, Marek Vasut wrote: On Sunday, January 25, 2015 at 05:28:18 PM, Kristina Martšenko wrote: These patches fix some issues with using the touchscreen and reading other ADC channels at the same time. Entire series Reviewed-by: Marek Vasut ma...@denx.de Thanks again! All 4 applied to the fixes-togreg branch of iio.git and cc'd to stable. Thanks, Jonathan! I'm not entirely sure if these are critical enough to go in stable, but alright. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC
These patches fix some issues with using the touchscreen and reading other ADC channels at the same time. The main issue is that the virtual channels the touchscreen uses can overlap with the channels that the iio buffer is configured to read, causing the touchscreen to read those channels instead, and report wrong values. Patch #1 fixes that by separating the channels they use. Patches #2 and #3 stop buffered mode and sysfs reads from disabling the touchscreen. Patch #4 keeps the buffer from reporting wrong values when the touchscreen is in use. Note that I've only tested these patches on i.MX28. I checked the i.MX23 reference manual, and there don't seem to be any differences in the parts I changed, but it would still be nice if someone could test on i.MX23 as well. Changes in v2: - renamed TS_VCHn macros to TOUCHSCREEN_VCHANNELn - removed indentation changes from patch #2 Kristina Martšenko (4): iio: mxs-lradc: separate touchscreen and buffer virtual channels iio: mxs-lradc: make ADC reads not disable touchscreen interrupts iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions iio: mxs-lradc: only update the buffer when its conversions have finished drivers/staging/iio/adc/mxs-lradc.c | 200 ++-- 1 file changed, 98 insertions(+), 102 deletions(-) -- 2.2.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 4/4] iio: mxs-lradc: only update the buffer when its conversions have finished
Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Reviewed-by: Marek Vasut ma...@denx.de
---
drivers/staging/iio/adc/mxs-lradc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index d2e0c275bf4d..ebcbd12d48b9 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -1152,10 +1152,12 @@ static irqreturn_t mxs_lradc_handle_irq(int irq, void
*data)
LRADC_CTRL1_LRADC_IRQ(TOUCHSCREEN_VCHANNEL2));
}
- if (iio_buffer_enabled(iio))
- iio_trigger_poll(iio-trig);
- else if (reg LRADC_CTRL1_LRADC_IRQ(0))
+ if (iio_buffer_enabled(iio)) {
+ if (reg lradc-buffer_vchans)
+ iio_trigger_poll(iio-trig);
+ } else if (reg LRADC_CTRL1_LRADC_IRQ(0)) {
complete(lradc-completion);
+ }
mxs_lradc_reg_clear(lradc, reg clr_irq, LRADC_CTRL1);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels
The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.
As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.
So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.
This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.
[1] 06ddd353f5c8 (iio: mxs: Implement support for touchscreen)
[2] dee05308f602 (Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection)
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
Note that this patch alone isn't very useful, as another bug causes buffered
capture to disable the touchscreen entirely (on i.MX28). Patch #2 in this
series fixes the other issue.
drivers/staging/iio/adc/mxs-lradc.c | 166
1 file changed, 75 insertions(+), 91 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index f053535385bf..4e574b76ead0 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -214,11 +214,14 @@ struct mxs_lradc {
unsigned long is_divided;
/*
-* Touchscreen LRADC channels receives a private slot in the CTRL4
-* register, the slot #7. Therefore only 7 slots instead of 8 in the
-* CTRL4 register can be mapped to LRADC channels when using the
-* touchscreen.
-*
+* When the touchscreen is enabled, we give it two private virtual
+* channels: #6 and #7. This means that only 6 virtual channels (instead
+* of 8) will be available for buffered capture.
+*/
+#define TOUCHSCREEN_VCHANNEL1 7
+#define TOUCHSCREEN_VCHANNEL2 6
+
+ /*
* Furthermore, certain LRADC channels are shared between touchscreen
* and/or touch-buttons and generic LRADC block. Therefore when using
* either of these, these channels are not available for the regular
@@ -342,6 +345,9 @@ struct mxs_lradc {
#defineLRADC_CTRL4 0x140
#defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf ((n) * 4))
#defineLRADC_CTRL4_LRADCSELECT_OFFSET(n) ((n) * 4)
+#defineLRADC_CTRL4_LRADCSELECT(n, x) \
+ (((x) LRADC_CTRL4_LRADCSELECT_OFFSET(n)) \
+ LRADC_CTRL4_LRADCSELECT_MASK(n))
#define LRADC_RESOLUTION 12
#define LRADC_SINGLE_SAMPLE_MASK ((1 LRADC_RESOLUTION) - 1)
@@ -416,6 +422,14 @@ static bool mxs_lradc_check_touch_event(struct mxs_lradc
*lradc)
LRADC_STATUS_TOUCH_DETECT_RAW);
}
+static void mxs_lradc_map_channel(struct mxs_lradc *lradc, unsigned vch,
+ unsigned ch)
+{
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL4_LRADCSELECT_MASK(vch),
+ LRADC_CTRL4);
+ mxs_lradc_reg_set(lradc, LRADC_CTRL4_LRADCSELECT(vch, ch), LRADC_CTRL4);
+}
+
static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
{
/*
@@ -443,12 +457,8 @@ static void mxs_lradc_setup_ts_channel(struct mxs_lradc
*lradc, unsigned ch)
LRADC_DELAY_DELAY(lradc-over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch), LRADC_CTRL1);
- /* wake us again, when the complete conversion is done */
- mxs_lradc_reg_set(lradc, LRADC_CTRL1_LRADC_IRQ_EN(ch), LRADC_CTRL1);
/*
* after changing the touchscreen plates setting
* the signals need some initial time to settle. Start the
@@ -502,12 +512,8 @@ static void mxs_lradc_setup_ts_pressure(struct mxs_lradc
*lradc, unsigned ch1,
LRADC_DELAY_DELAY(lradc-over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc
[PATCH v2 3/4] iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
Reading a channel through sysfs, or starting a buffered capture, can
occasionally turn off the touchscreen.
This is because the read_raw() and buffer preenable()/postdisable()
callbacks unschedule current conversions on all channels. If a delay
channel happens to schedule a touchscreen conversion at the same time,
the conversion gets cancelled and the touchscreen sequence stops.
This is probably related to this note from the reference manual:
If a delay group schedules channels to be sampled and a manual
write to the schedule field in CTRL0 occurs while the block is
discarding samples, the LRADC will switch to the new schedule
and will not sample the channels that were previously scheduled.
The time window for this to happen is very small and lasts only
while the LRADC is discarding samples.
So make the callbacks only unschedule conversions for the channels they
use. This means channel 0 for read_raw() and channels 0-5 for the buffer
(if the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
This is tested and fixes the issue on i.MX28, but hasn't been tested on
i.MX23.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Reviewed-by: Marek Vasut ma...@denx.de
---
drivers/staging/iio/adc/mxs-lradc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 653af03bc69d..d2e0c275bf4d 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -824,7 +824,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
if (lradc-soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, 0x1, LRADC_CTRL0);
/* Enable / disable the divider per requirement */
if (test_bit(chan, lradc-is_divided))
@@ -1272,7 +1272,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
mxs_lradc_reg_clear(lradc,
lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc-buffer_vchans, LRADC_CTRL0);
for_each_set_bit(chan, iio-active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
ctrl4_set |= chan LRADC_CTRL4_LRADCSELECT_OFFSET(ofs);
@@ -1305,7 +1305,7 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, LRADC_DELAY_TRIGGER_LRADCS_MASK |
LRADC_DELAY_KICK, LRADC_DELAY(0));
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc-buffer_vchans, LRADC_CTRL0);
if (lradc-soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc,
lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/4] iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.
So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
Note that only i.MX28 is affected by this issue, i.MX23 should be fine.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Reviewed-by: Marek Vasut ma...@denx.de
---
drivers/staging/iio/adc/mxs-lradc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 4e574b76ead0..653af03bc69d 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -220,6 +220,9 @@ struct mxs_lradc {
*/
#define TOUCHSCREEN_VCHANNEL1 7
#define TOUCHSCREEN_VCHANNEL2 6
+#define BUFFER_VCHANS_LIMITED 0x3f
+#define BUFFER_VCHANS_ALL 0xff
+ u8 buffer_vchans;
/*
* Furthermore, certain LRADC channels are shared between touchscreen
@@ -819,7 +822,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
* used if doing raw sampling.
*/
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
@@ -1266,8 +1269,9 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
}
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
for_each_set_bit(chan, iio-active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
@@ -1303,8 +1307,9 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
kfree(lradc-buffer);
mutex_unlock(lradc-lock);
@@ -1542,6 +1547,11 @@ static int mxs_lradc_probe(struct platform_device *pdev)
touch_ret = mxs_lradc_probe_touchscreen(lradc, node);
+ if (touch_ret == 0)
+ lradc-buffer_vchans = BUFFER_VCHANS_LIMITED;
+ else
+ lradc-buffer_vchans = BUFFER_VCHANS_ALL;
+
/* Grab all IRQ sources */
for (i = 0; i of_cfg-irq_count; i++) {
lradc-irq[i] = platform_get_irq(pdev, i);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels
On 18/01/15 02:19, Marek Vasut wrote:
On Saturday, January 17, 2015 at 01:22:08 AM, Kristina Martšenko wrote:
Hi!
Hi!
Good stuff, thank you! Just minor nitpicks below.
[...]
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c index e0e91836eec1..fc65cd311be9
100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -214,11 +214,14 @@ struct mxs_lradc {
unsigned long is_divided;
/*
- * Touchscreen LRADC channels receives a private slot in the CTRL4
- * register, the slot #7. Therefore only 7 slots instead of 8 in the
- * CTRL4 register can be mapped to LRADC channels when using the
- * touchscreen.
- *
+ * When the touchscreen is enabled, we give it two private virtual
+ * channels: #6 and #7. This means that only 6 virtual channels (instead
+ * of 8) will be available for buffered capture.
+ */
+#define TS_VCH1 7
+#define TS_VCH2 6
Please use a bit more explicit name for the macro, it's really not clear what
the macro represents from it's name. Something like TOUCHSCREEN_VCHANNEL1
might
work better for example. What do you think ?
Sure, I tried to keep it short and similar to the TS_CH_YP (etc) macros,
but clearer is better, so I'll change it to TOUCHSCREEN_VCHANNEL1 in v2.
+
+/*
* Furthermore, certain LRADC channels are shared between touchscreen
* and/or touch-buttons and generic LRADC block. Therefore when using
* either of these, these channels are not available for the regular
[...]
I also have a general question/idea here, it's explicitly not something I'd
like
to force upon you to implement. I see we have some kind of a hardware, which
can
sample up-to N inputs in parallel . Each input is muxed between M possible
sources . Is such a thing common in the ADC/DAC world ? Would it be worth to
implement generic helper to handle this kind of a N:M mapping ? What do you
all
think please ?
Hmm, I don't know how other drivers do this, or if there's anything in
common. The IIO people will probably have a better idea, so I'll wait
for them to respond.
Kristina
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
On 18/01/15 02:21, Marek Vasut wrote:
On Saturday, January 17, 2015 at 01:22:09 AM, Kristina Martšenko wrote:
Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.
So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
Note that only i.MX28 is affected by this issue, i.MX23 should be fine.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
drivers/staging/iio/adc/mxs-lradc.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c index fc65cd311be9..0cf276ff0dc5
100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -218,8 +218,11 @@ struct mxs_lradc {
* channels: #6 and #7. This means that only 6 virtual channels (instead
* of 8) will be available for buffered capture.
*/
-#define TS_VCH1 7
-#define TS_VCH2 6
+#define TS_VCH1 7
+#define TS_VCH2 6
Please fix the indent in 1/4 , so you don't have to change it again this
patch.
Right, of course, I'll do that in v2.
Reviewed-by: Marek Vasut ma...@denx.de
Thanks for taking time to review all the patches!
Kristina
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
On 19/01/15 09:57, Marek Vasut wrote: On Monday, January 19, 2015 at 08:20:31 AM, Juergen Borleis wrote: On Saturday 17 January 2015 01:22:10 Kristina Martšenko wrote: Reading a channel through sysfs, or starting a buffered capture, can occasionally turn off the touchscreen. [...] I have my old ChumbyOne around (i.MX23). How to test this buffered capture while using the touchscreen part of the ADC (I have never used the IIO before). That's great, thanks for offering to test this. Last time I checked there was drivers/staging/iio/Documentation/generic_buffer.c , but you can also wait for a more precise advice from Kristina . Hope it helps at least a bit ;-) Yeah, I used generic_buffer.c for testing. You can enable some channels like this: echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage7_en echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage10_en echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage12_en echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage13_en echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage14_en echo 1 /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage15_en And then start the capture and read 10 samples with generic_buffer: ./generic_buffer -n 8005.lradc -c 10 And using the touchscreen at the same time should work now. Let me know if it doesn't :) Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC
On 18/01/15 13:21, Stefan Wahren wrote: Hi Kristina, Hi Stefan! Kristina Martšenko kristina.martse...@gmail.com hat am 17. Januar 2015 um 01:22 geschrieben: These patches fix some issues with using the touchscreen and reading other ADC channels at the same time. The main issue is that the virtual channels the touchscreen uses can overlap with the channels that the iio buffer is configured to read, causing the touchscreen to read those channels instead, and report wrong values. Patch #1 fixes that by separating the channels they use. Patches #2 and #3 stop buffered mode and sysfs reads from disabling the touchscreen. Patch #4 keeps the buffer from reporting wrong values when the touchscreen is in use. Note that I've only tested these patches on i.MX28. I checked the i.MX23 reference manual [1], and there don't seem to be any differences in the parts I changed, but it would still be nice if someone could test on i.MX23 as well. i have a iMX233-Olinuxino-MAXI, but no touchscreen. If it does make sense to you, could you please send me testing instructions and i'll give it a try? Thanks a lot for offering! Unfortunately in this case all testing involves using the touchscreen while reading other ADC channels, so without a touchscreen there isn't much to test, sorry :( Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC
Hi, These patches fix some issues with using the touchscreen and reading other ADC channels at the same time. The main issue is that the virtual channels the touchscreen uses can overlap with the channels that the iio buffer is configured to read, causing the touchscreen to read those channels instead, and report wrong values. Patch #1 fixes that by separating the channels they use. Patches #2 and #3 stop buffered mode and sysfs reads from disabling the touchscreen. Patch #4 keeps the buffer from reporting wrong values when the touchscreen is in use. Note that I've only tested these patches on i.MX28. I checked the i.MX23 reference manual [1], and there don't seem to be any differences in the parts I changed, but it would still be nice if someone could test on i.MX23 as well. The patches were tested on next-20150113 and rebased onto iio/togreg. Thanks, Kristina [1] i.MX23: http://cache.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf i.MX28: http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf Kristina Martšenko (4): iio: mxs-lradc: separate touchscreen and buffer virtual channels iio: mxs-lradc: make ADC reads not disable touchscreen interrupts iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions iio: mxs-lradc: only update the buffer when its conversions have finished drivers/staging/iio/adc/mxs-lradc.c | 192 +--- 1 file changed, 91 insertions(+), 101 deletions(-) -- 2.2.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
Reading a channel through sysfs, or starting a buffered capture, can
occasionally turn off the touchscreen.
This is because the read_raw() and buffer preenable()/postdisable()
callbacks unschedule current conversions on all channels. If a delay
channel happens to schedule a touchscreen conversion at the same time,
the conversion gets cancelled and the touchscreen sequence stops.
This is probably related to this note from the reference manual:
If a delay group schedules channels to be sampled and a manual
write to the schedule field in CTRL0 occurs while the block is
discarding samples, the LRADC will switch to the new schedule
and will not sample the channels that were previously scheduled.
The time window for this to happen is very small and lasts only
while the LRADC is discarding samples.
So make the callbacks only unschedule conversions for the channels they
use. This means channel 0 for read_raw() and channels 0-5 for the buffer
(if the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
This is tested and fixes the issue on i.MX28, but hasn't been tested on
i.MX23.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
drivers/staging/iio/adc/mxs-lradc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 0cf276ff0dc5..5b5cb205b9ed 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -825,7 +825,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
if (lradc-soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, 0x1, LRADC_CTRL0);
/* Enable / disable the divider per requirement */
if (test_bit(chan, lradc-is_divided))
@@ -1273,7 +1273,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
mxs_lradc_reg_clear(lradc,
lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc-buffer_vchans, LRADC_CTRL0);
for_each_set_bit(chan, iio-active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
ctrl4_set |= chan LRADC_CTRL4_LRADCSELECT_OFFSET(ofs);
@@ -1306,7 +1306,7 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, LRADC_DELAY_TRIGGER_LRADCS_MASK |
LRADC_DELAY_KICK, LRADC_DELAY(0));
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc-buffer_vchans, LRADC_CTRL0);
if (lradc-soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc,
lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.
So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
Note that only i.MX28 is affected by this issue, i.MX23 should be fine.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
drivers/staging/iio/adc/mxs-lradc.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index fc65cd311be9..0cf276ff0dc5 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -218,8 +218,11 @@ struct mxs_lradc {
* channels: #6 and #7. This means that only 6 virtual channels (instead
* of 8) will be available for buffered capture.
*/
-#define TS_VCH17
-#define TS_VCH26
+#define TS_VCH17
+#define TS_VCH26
+#define BUFFER_VCHANS_LIMITED 0x3f
+#define BUFFER_VCHANS_ALL 0xff
+ u8 buffer_vchans;
/*
* Furthermore, certain LRADC channels are shared between touchscreen
@@ -820,7 +823,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
* used if doing raw sampling.
*/
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
@@ -1267,8 +1270,9 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
}
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
for_each_set_bit(chan, iio-active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
@@ -1304,8 +1308,9 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
if (lradc-soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc-buffer_vchans LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
kfree(lradc-buffer);
mutex_unlock(lradc-lock);
@@ -1561,6 +1566,11 @@ static int mxs_lradc_probe(struct platform_device *pdev)
touch_ret = mxs_lradc_probe_touchscreen(lradc, node);
+ if (touch_ret == 0)
+ lradc-buffer_vchans = BUFFER_VCHANS_LIMITED;
+ else
+ lradc-buffer_vchans = BUFFER_VCHANS_ALL;
+
/* Grab all IRQ sources */
for (i = 0; i of_cfg-irq_count; i++) {
lradc-irq[i] = platform_get_irq(pdev, i);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] iio: mxs-lradc: only update the buffer when its conversions have finished
Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
drivers/staging/iio/adc/mxs-lradc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 5b5cb205b9ed..d60ca849175e 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -1153,10 +1153,12 @@ static irqreturn_t mxs_lradc_handle_irq(int irq, void
*data)
LRADC_CTRL1_LRADC_IRQ(TS_VCH2));
}
- if (iio_buffer_enabled(iio))
- iio_trigger_poll(iio-trig);
- else if (reg LRADC_CTRL1_LRADC_IRQ(0))
+ if (iio_buffer_enabled(iio)) {
+ if (reg lradc-buffer_vchans)
+ iio_trigger_poll(iio-trig);
+ } else if (reg LRADC_CTRL1_LRADC_IRQ(0)) {
complete(lradc-completion);
+ }
mxs_lradc_reg_clear(lradc, reg clr_irq, LRADC_CTRL1);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels
The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.
As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.
So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.
This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.
[1] 06ddd353f5c8 (iio: mxs: Implement support for touchscreen)
[2] dee05308f602 (Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection)
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
Note that this patch alone isn't very useful, as another bug causes buffered
capture to disable the touchscreen entirely (on i.MX28). Patch #2 in this
series fixes the other issue.
drivers/staging/iio/adc/mxs-lradc.c | 158
1 file changed, 68 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index e0e91836eec1..fc65cd311be9 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -214,11 +214,14 @@ struct mxs_lradc {
unsigned long is_divided;
/*
-* Touchscreen LRADC channels receives a private slot in the CTRL4
-* register, the slot #7. Therefore only 7 slots instead of 8 in the
-* CTRL4 register can be mapped to LRADC channels when using the
-* touchscreen.
-*
+* When the touchscreen is enabled, we give it two private virtual
+* channels: #6 and #7. This means that only 6 virtual channels (instead
+* of 8) will be available for buffered capture.
+*/
+#define TS_VCH17
+#define TS_VCH26
+
+ /*
* Furthermore, certain LRADC channels are shared between touchscreen
* and/or touch-buttons and generic LRADC block. Therefore when using
* either of these, these channels are not available for the regular
@@ -342,6 +345,9 @@ struct mxs_lradc {
#defineLRADC_CTRL4 0x140
#defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf ((n) * 4))
#defineLRADC_CTRL4_LRADCSELECT_OFFSET(n) ((n) * 4)
+#defineLRADC_CTRL4_LRADCSELECT(n, x) \
+ (((x) LRADC_CTRL4_LRADCSELECT_OFFSET(n)) \
+ LRADC_CTRL4_LRADCSELECT_MASK(n))
#define LRADC_RESOLUTION 12
#define LRADC_SINGLE_SAMPLE_MASK ((1 LRADC_RESOLUTION) - 1)
@@ -416,6 +422,14 @@ static bool mxs_lradc_check_touch_event(struct mxs_lradc
*lradc)
LRADC_STATUS_TOUCH_DETECT_RAW);
}
+static void mxs_lradc_map_channel(struct mxs_lradc *lradc, unsigned vch,
+ unsigned ch)
+{
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL4_LRADCSELECT_MASK(vch),
+ LRADC_CTRL4);
+ mxs_lradc_reg_set(lradc, LRADC_CTRL4_LRADCSELECT(vch, ch), LRADC_CTRL4);
+}
+
static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
{
/*
@@ -450,12 +464,8 @@ static void mxs_lradc_setup_ts_channel(struct mxs_lradc
*lradc, unsigned ch)
LRADC_DELAY_DELAY(lradc-over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch), LRADC_CTRL1);
- /* wake us again, when the complete conversion is done */
- mxs_lradc_reg_set(lradc, LRADC_CTRL1_LRADC_IRQ_EN(ch), LRADC_CTRL1);
/*
* after changing the touchscreen plates setting
* the signals need some initial time to settle. Start the
@@ -509,12 +519,8 @@ static void mxs_lradc_setup_ts_pressure(struct mxs_lradc
*lradc, unsigned ch1,
LRADC_DELAY_DELAY(lradc-over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch2
Re: Anybody working on sep?
On 23/06/14 23:32, Kristina Martšenko wrote: Hi Mark, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving sep out of staging in over a year. Are there any plans to clean it up and move it out soon? No response from Mark here. Alan, Jayant, either of you know what the status of the sep staging driver is? Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: phison: remove driver
The driver hasn't been cleaned up and it doesn't look like anyone is
working on it anymore (including the original author). So remove the
driver from the kernel. If someone wants to work on cleaning it up and
moving it out of staging, this commit can be reverted.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Cc: Evan Ko evan...@phison.com
---
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile| 1 -
drivers/staging/phison/Kconfig | 5 ---
drivers/staging/phison/Makefile | 1 -
drivers/staging/phison/phison.c | 94 -
5 files changed, 103 deletions(-)
delete mode 100644 drivers/staging/phison/Kconfig
delete mode 100644 drivers/staging/phison/Makefile
delete mode 100644 drivers/staging/phison/phison.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5b14f0d..be3f91c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -54,8 +54,6 @@ source drivers/staging/rtl8821ae/Kconfig
source drivers/staging/rts5208/Kconfig
-source drivers/staging/phison/Kconfig
-
source drivers/staging/line6/Kconfig
source drivers/staging/octeon/Kconfig
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d4536df..a4408a8 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_R8192EE) += rtl8192ee/
obj-$(CONFIG_R8723AU) += rtl8723au/
obj-$(CONFIG_R8821AE) += rtl8821ae/
obj-$(CONFIG_RTS5208) += rts5208/
-obj-$(CONFIG_IDE_PHISON) += phison/
obj-$(CONFIG_LINE6_USB)+= line6/
obj-$(CONFIG_NETLOGIC_XLR_NET) += netlogic/
obj-$(CONFIG_OCTEON_ETHERNET) += octeon/
diff --git a/drivers/staging/phison/Kconfig b/drivers/staging/phison/Kconfig
deleted file mode 100644
index 1b56119..000
--- a/drivers/staging/phison/Kconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-config IDE_PHISON
- tristate PCIE ATA PS5000 IDE support
- depends on PCI ATA ATA_SFF ATA_BMDMA
- ---help---
- This is an experimental driver for PS5000 IDE driver.
diff --git a/drivers/staging/phison/Makefile b/drivers/staging/phison/Makefile
deleted file mode 100644
index 7642a21..000
--- a/drivers/staging/phison/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_IDE_PHISON) += phison.o
diff --git a/drivers/staging/phison/phison.c b/drivers/staging/phison/phison.c
deleted file mode 100644
index 3826561..000
--- a/drivers/staging/phison/phison.c
+++ /dev/null
@@ -1,94 +0,0 @@
-/*
- * Copyright (C) 2006 Red Hat evan...@phison.com
- *
- * May be copied or modified under the terms of the GNU General Public License
- *
- * [Modify History]
- * #0001, Evan, 2008.10.22, V0.00, New release.
- * #0002, Evan, 2008.11.01, V0.90, Test Work In Ubuntu Linux 8.04.
- * #0003, Evan, 2008.01.08, V0.91, Change Name PCIE-SSD to E-BOX.
- */
-
-#include linux/kernel.h
-#include linux/module.h
-#include linux/pci.h
-#include linux/blkdev.h
-#include linux/delay.h
-#include linux/device.h
-#include scsi/scsi_host.h
-#include linux/libata.h
-#include linux/ata.h
-
-#define PHISON_DEBUG
-
-#define DRV_NAME phison_e-box /* #0003 */
-#define DRV_VERSION0.91 /* #0003 */
-
-#define PCI_VENDOR_ID_PHISON 0x1987
-#define PCI_DEVICE_ID_PS5000 0x5000
-
-static int phison_pre_reset(struct ata_link *link, unsigned long deadline)
-{
- int ret;
- struct ata_port *ap = link-ap;
-
- ap-cbl = ATA_CBL_NONE;
- ret = ata_std_prereset(link, deadline);
- dev_dbg(ap-dev, phison_pre_reset(), ret = %x\n, ret);
- return ret;
-}
-
-static struct scsi_host_template phison_sht = {
- ATA_BMDMA_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations phison_ops = {
- .inherits = ata_bmdma_port_ops,
- .prereset = phison_pre_reset,
-};
-
-static int phison_init_one(struct pci_dev *pdev, const struct pci_device_id
*id)
-{
- int ret;
- struct ata_port_info info = {
- .flags = ATA_FLAG_NO_ATAPI,
-
- .pio_mask = 0x1f,
- .mwdma_mask = 0x07,
- .udma_mask = ATA_UDMA5,
-
- .port_ops = phison_ops,
- };
- const struct ata_port_info *ppi[] = { info, NULL };
-
- ret = ata_pci_bmdma_init_one(pdev, ppi, phison_sht, NULL, 0);
-
- dev_dbg(pdev-dev, phison_init_one(), ret = %x\n, ret);
-
- return ret;
-}
-
-static const struct pci_device_id phison_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_PHISON, PCI_DEVICE_ID_PS5000),
- PCI_CLASS_STORAGE_IDE 8, 0x00, 0 },
- { 0, },
-};
-MODULE_DEVICE_TABLE(pci, phison_pci_tbl);
-
-static struct pci_driver phison_pci_driver = {
- .name = DRV_NAME,
- .id_table = phison_pci_tbl,
- .probe = phison_init_one,
- .remove = ata_pci_remove_one,
-#ifdef CONFIG_PM /* haven't tested
[PATCH 2/2] ARM: OMAP2+: remove DSP platform device
It was added to support DSP Bridge. Since DSP Bridge was removed, and
nothing else is using the platform device, remove it too.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
Cc: Omar Ramirez Luna omar.rami...@copitl.com
Cc: Suman Anna s-a...@ti.com
Cc: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/Makefile | 4 -
arch/arm/mach-omap2/common.c | 2 -
arch/arm/mach-omap2/dsp.c | 134 -
include/linux/platform_data/dsp-omap.h | 34 -
4 files changed, 174 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dsp.c
delete mode 100644 include/linux/platform_data/dsp-omap.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8ca99e9..fa78000 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -232,10 +232,6 @@ obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
-ifneq ($(CONFIG_TIDSPBRIDGE),)
-obj-y += dsp.o
-endif
-
# OMAP2420 MSDI controller integration support (MMC)
obj-$(CONFIG_SOC_OMAP2420) += msdi.o
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9e..484cdad 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -14,7 +14,6 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/platform_data/dsp-omap.h
#include common.h
#include omap-secure.h
@@ -30,7 +29,6 @@ int __weak omap_secure_ram_reserve_memblock(void)
void __init omap_reserve(void)
{
- omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
deleted file mode 100644
index f7492df..000
--- a/arch/arm/mach-omap2/dsp.c
+++ /dev/null
@@ -1,134 +0,0 @@
-/*
- * TI's OMAP DSP platform device registration
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- * Copyright (C) 2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/*
- * XXX The function pointers to the PRM/CM functions are incorrect and
- * should be removed. No device driver should be changing PRM/CM bits
- * directly; that's a layering violation -- those bits are the responsibility
- * of the OMAP PM core code.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-
-#include asm/memblock.h
-
-#include control.h
-#include cm2xxx_3xxx.h
-#include prm2xxx_3xxx.h
-#ifdef CONFIG_TIDSPBRIDGE_DVFS
-#include omap-pm.h
-#endif
-#include soc.h
-
-#include linux/platform_data/dsp-omap.h
-
-static struct platform_device *omap_dsp_pdev;
-
-static struct omap_dsp_platform_data omap_dsp_pdata __initdata = {
-#ifdef CONFIG_TIDSPBRIDGE_DVFS
- .dsp_set_min_opp = omap_pm_dsp_set_min_opp,
- .dsp_get_opp = omap_pm_dsp_get_opp,
- .cpu_set_freq = omap_pm_cpu_set_freq,
- .cpu_get_freq = omap_pm_cpu_get_freq,
-#endif
- .dsp_prm_read = omap2_prm_read_mod_reg,
- .dsp_prm_write = omap2_prm_write_mod_reg,
- .dsp_prm_rmw_bits = omap2_prm_rmw_mod_reg_bits,
- .dsp_cm_read = omap2_cm_read_mod_reg,
- .dsp_cm_write = omap2_cm_write_mod_reg,
- .dsp_cm_rmw_bits = omap2_cm_rmw_mod_reg_bits,
-
- .set_bootaddr = omap_ctrl_write_dsp_boot_addr,
- .set_bootmode = omap_ctrl_write_dsp_boot_mode,
-};
-
-static phys_addr_t omap_dsp_phys_mempool_base;
-
-void __init omap_dsp_reserve_sdram_memblock(void)
-{
- phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- phys_addr_t paddr;
-
- if (!cpu_is_omap34xx())
- return;
-
- if (!size)
- return;
-
- paddr = arm_memblock_steal(size, SZ_1M);
- if (!paddr) {
- pr_err(%s: failed to reserve %llx bytes\n,
- __func__, (unsigned long long)size);
- return;
- }
-
- omap_dsp_phys_mempool_base = paddr;
-}
-
-static phys_addr_t omap_dsp_get_mempool_base(void)
-{
- return omap_dsp_phys_mempool_base;
-}
-
-static int __init omap_dsp_init(void)
-{
- struct platform_device *pdev;
- int err = -ENOMEM;
- struct omap_dsp_platform_data *pdata = omap_dsp_pdata;
-
- if (!cpu_is_omap34xx())
- return 0;
-
- pdata-phys_mempool_base = omap_dsp_get_mempool_base();
-
- if (pdata-phys_mempool_base) {
- pdata-phys_mempool_size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- pr_info(%s: %llx bytes @ %llx\n, __func__,
- (unsigned long long)pdata-phys_mempool_size,
- (unsigned long long)pdata
Re: Anybody working on ced1401?
On 14/07/14 11:28, Luca Ellero wrote: On 13/07/2014 18:46, Greg KH wrote: On Fri, Jun 27, 2014 at 05:11:45PM +0200, Luca Ellero wrote: Hi Greg, On 27/06/2014 16:55, Greg KH wrote: On Fri, Jun 27, 2014 at 03:04:43PM +0200, Luca Ellero wrote: Il 26/06/2014 21:23, Greg KH ha scritto: On Thu, Jun 26, 2014 at 09:36:17AM +0200, Alois Schloegl wrote: On 2014-06-18 13:33, Kristina Martšenko wrote: Hi Alois, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving ced1401 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina Hi Kristina, thanks for the notice. Please, give me some time for checking here how we want to go forward with this. What do you mean by this? You all have had a lot of time, with no real progress at all? How about we delete the driver and if you decide to continue to work on it, we can revert that deletion and go from there? thanks, greg k-h Hi, I have a hundred patches for this driver ready to send. Why have you not sent them previously? What is preventing you to send them? Because it's only for a few weeks that I've been working on them. They basically convert all camelCase and Hungarian notation names to Linux convention and fix some checkpatch errors (no logic is modified). Do you have this hardware to test the code with? Do you want to work on getting this driver merged out of the staging tree? I used to have one CED1401, but unfortunately I don't have it any more. Anyway if Alois (or someone else) can test the patches it would be great. I can do a bit more work to get this driver out of staging. As you don't have the hardware anymore, does it make much sense to keep working on the driver? I'd recommend just deleting it, if someone shows up with the hardware later, we can always revert it. Hi Greg, I agree. Without hardware, it's very hard to go ahead. I sent the patches in the hope that someone can test them. But if no one is interested, I have no objection in removing the driver. regards Luca Thanks, Luca. Since no one with the hardware seems interested right now, I'm going to go ahead and remove the driver. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Status of RMI4 drivers?
On 06/07/14 21:12, Dmitry Torokhov wrote: On Sat, Jul 5, 2014 at 8:39 PM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Jul 05, 2014 at 04:37:37PM +0100, Alan Cox wrote: On Fri, 2014-07-04 at 21:48 +0300, Kristina Martšenko wrote: Hi, I'm going over some older drivers in the staging tree and wanted to ask about cptm1217 and ste_rmi4. They've been in staging for three and a half years now, waiting for the upstream Synaptics RMI4 drivers. From what I understand, the RMI4 development is happening in the synaptics-rmi4 branch of Dmitry's git tree. Does anyone have any idea when the RMI4 code might be ready and get merged properly? How is that going? I'd be quite happy to move cptm1217 out of staging, however its now been there so many years waiting the rumoured RMI4 driver that I don't have hardware to do any testing on it, so it would need to be a straight move. Kristina found a driver here: https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=synaptics-rmi4 Dmitry, what's the status of ever getting that code merged into the tree? I was supposed to uprev the driver to the latest kernel and start merging it, unfortunately last month and a half was quite a mess. Hopefully now I should have more time since I can do bunch of this work during normal hours. Good to know, thanks. So what happens to the staging drivers once you merge the driver? Will their devices be supported by the new driver or will someone have to merge their functionality into the new driver (and test it)? Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on tidspbridge?
On 29/06/14 19:42, Greg KH wrote: On Fri, Jun 20, 2014 at 07:05:17PM +0300, Kristina Martšenko wrote: On 20/06/14 18:43, Kristina Martšenko wrote: Hi Omar, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving tidspbridge out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina Omar's email address in tidspbridge's TODO file seems to be outdated. Resending to more recent addresses which hopefully won't bounce. Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Status of RMI4 drivers?
Hi, I'm going over some older drivers in the staging tree and wanted to ask about cptm1217 and ste_rmi4. They've been in staging for three and a half years now, waiting for the upstream Synaptics RMI4 drivers. From what I understand, the RMI4 development is happening in the synaptics-rmi4 branch of Dmitry's git tree. Does anyone have any idea when the RMI4 code might be ready and get merged properly? How is that going? Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Q] Removed cxt1e1 module in staging branch
On 02/07/14 12:41, DaeSeok Youn wrote: Hi, all. I saw your change which removes cxt1e1 in staging tree. Actually, I have been cleaning up coding style and fixing minor issues without real cxt1e1 hardware. And I am not cleaning up all of files in cxt1e1 but some files already done and have plans for other files. may be.. I cannot fix major issues because I don't have a real device but minor issues can be fixed and coding style also. If you want to fix majors' which can be with real device, stay removed. But if it can be reverted for fixing minor issues including coding style, please revert. I cannot focus all of my time on making patches, but I can make patches steadily for that module. Hi DaeSeok, Thanks for the patches, but there needs to be progress made towards moving the driver out of staging. There's not much point in fixing coding style and other smaller issues if larger issues remain unfixed and the driver eventually gets deleted anyway. I don't really know what needs to be done to get it moved out at all, since the driver never had a TODO file and the original thread [1] doesn't say much, so I don't know if it requires the hardware or not, but I suspect it does. Maybe you could work on another driver? Sorry, Kristina [1] http://marc.info/?t=12565885401r=1w=4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on cxt1e1?
On 24/06/14 15:44, Bob Beers wrote: No,I am not able to work on that. It probably should be removed. Bob Okay then. No one else has shown interest in it either in the past week, so I'll go ahead and remove it. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: winbond: remove driver
On 27/06/14 04:11, Greg KH wrote: On Mon, Jun 23, 2014 at 06:41:29PM +0300, Kristina Martšenko wrote: The driver hasn't been cleaned up and nobody is working to do so, so remove it. Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com Cc: Pavel Machek pa...@ucw.cz This patch didn't apply to my tree for some odd reason, can you please refresh it and resend? Strange, I refreshed my staging-next branch and the patch applies fine. Didn't get any conflicts when rebasing either. I'll resend it, though I don't think anything about the patch has changed. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on cxt1e1?
Hi Bob, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving cxt1e1 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on gdm72xx?
Hi Sage, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving gdm72xx out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on quickstart?
Hi Angelo, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving quickstart out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on silicom?
Hi Daniel, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving silicom out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on line6?
Hi Markus, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving line6 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on phison?
Hi Evan, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving phison out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on dgrp or serqt_usb2?
Hi Bill, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving dgrp or serqt_usb2 out of staging in over a year. Are there any plans to clean these drivers up and move them out soon? Because otherwise we're going to have to delete them, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on gdm72xx?
On 23/06/14 23:41, Ben Chan wrote: Hi Kristina and Greg, I can help migrate the gdm72xx driver from staging to mainline. I believe the issues in TODO have been addressed. That's great, thanks! Is there a migration process that I should follow? I don't think there's anything special you need to do, just move everything to the right place and send the patch to the network maintainer and netdev mailing list. Here is an example of another driver being moved out: http://www.spinics.net/lists/linux-usb/msg100924.html Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Fwd: Re: Anybody working on rtl8712?
On 21/06/14 20:52, Christian Lamparter wrote: On Saturday, June 21, 2014 06:45:07 PM Kristina Martšenko wrote: On 20/06/14 23:52, Christian Lamparter wrote: rtl8192su development is chugging along. It just doesn't take place on driverdev list. The driver reached feature parity with rtl8192cu for some time ago. Great, thanks for letting me know. If you plan to keep working on it, do you think it would be a good idea to add yourself and a link to your github to the staging driver's TODO file? That way people who find it and want to work on it can join your effort, instead of starting their own. Actually, this is already happening. I get mails about rtl8192su. So, people who are interested are definitely following the development. Ah, that's good then. However the hurdles for rtl8192su driver are quite high (3.15+ kernel [1]). This is due to the driver being based on rtlwifi framework (the devices shares a lot of common code with the rtl8192SE - the pcie version). The development takes place on top of wireless-testing.git, so it can be merged with the rest of the drivers. Yeah, I can see how that would slow development. (If someone is interested in the details: how a wireless drivers are mainlined. There's a nifty process plan right here: [0] - check it out!). (NB: my stance on the TODO: Leave it the way it is. After all, you want those free checkpatch.pl and smatch/sparse fixes, right?) I don't think it would affect the checkpatch/sparse cleanups, they'd still be sent for the staging driver. I just thought it might point people who want to help with the mac80211 conversion in your direction. But it's your call. But as with rtl8192cu, I would recommend adding just a friendly printk. I'm not sure what printk you're referring to. I think there's a reason why the development takes so long (The RTL8192S* chips have been around since 2008, 2009) and why we all have better things to do and write harsh responses. As far as I can tell, It would be great if Realtek could have a few dedicated devs, which take care of integrating their own linux drivers into /drivers/net/wireless instead of dumping it into /driver/staging. This might sounds like hobbyists wifi-devs are a bunch of *. However, other (wifi-)vendor (e.g.: Intel, Qualcom, TI, Broadcom and Marvell) have been participating for some time now. And their end-users are very happy as a result of this. Now, if only Realtek would join the party; that would be awesome. Regards, Chr [0] http://wireless.kernel.org/en/developers/process#Maintainer_chain [1] https://github.com/chunkeey/rtl8192su/issues/2 Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Fwd: Re: Anybody working on rtl8712?
On 21/06/14 21:24, Larry Finger wrote: On 06/21/2014 12:52 PM, Christian Lamparter wrote: I think there's a reason why the development takes so long (The RTL8192S* chips have been around since 2008, 2009) and why we all have better things to do and write harsh responses. As far as I can tell, It would be great if Realtek could have a few dedicated devs, which take care of integrating their own linux drivers into /drivers/net/wireless instead of dumping it into /driver/staging. This might sounds like hobbyists wifi-devs are a bunch of *. However, other (wifi-)vendor (e.g.: Intel, Qualcom, TI, Broadcom and Marvell) have been participating for some time now. And their end-users are very happy as a result of this. Now, if only Realtek would join the party; that would be awesome. OK, a little clarification seems to be necessary. First of all, I have no official connection with Realtek. I do not get paid, and I do not have any sort of NDA with them. In fact, I would refuse to sign one. What I know about the internals of their chips is derived from reading code that they publish. At one point, I needed a Linux driver for a D-Link DWA-130. I took the Realtek driver, fixed the problems when running it on 64-bit hardware and on big-endian machines, and submitted it to staging as r8712u. Shortly thereafter, the PCI group at Realsil (the Chinese affiliate of Realtek) asked me if I would help them get their mac80211 drivers into the kernel. That group has been quite active in adapting their coding styles and practices to what is required for Linux. The USB programming group is in Taiwan, and they are much less interested in getting their drivers into Linux. Unlike the PCIe group, I don't even get hardware from them. They did write rtl8192cu, but have not done much with it since. The drivers for newer chips can be built for FreeBSD, Windows, or Linux. In several cases, I have not even had the hardware, which makes it impossible to do much in the way of improvement other than stripping out the foreign code. Jes Sorensen of RedHat has taken on the maintenance of the RTL8723AU driver as he has that hardware. He is actively reworking it with tens of patches per week, but he has not yet tackled the conversion to mac80211. It should have much in common with the RTL8723AE, but it will still be a big job. The PCI group recently sent me new code for all the PCI devices, and I am working at getting it merged into the wireless-testing tree. Once that is done, I plan to entice them to take over the maintainers role for those drivers. What to do about the USB drivers is still an open question. Thanks for taking the time to share what you know about the situation. Really nice of you to put so much of your own time into these drivers too. Maybe Realtek's USB group will come around, eventually... Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on dgrp or serqt_usb2?
On 24/06/14 01:08, Bill Pemberton wrote: On 06/23/2014 04:26 PM, Kristina Martšenko wrote: Hi Bill, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving dgrp or serqt_usb2 out of staging in over a year. Are there any plans to clean these drivers up and move them out soon? Because otherwise we're going to have to delete them, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina In the case of serqt_usb2, I'm certainly not going to be working on it. If I had a multi-port version of one of those devices, I'd change the ssu100 driver to deal with them instead of fooling with the staging driver. In the case of dgrp, I no longer have access to the hardware so I'm not planning on doing any more work on it. So I've got no objections to removing both dgrp and serqt_usb2. Oh well, I'll be removing them then (unless someone else objects). Thanks for getting back to me so soon. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Fwd: Re: Anybody working on rtl8712?
On 20/06/14 23:52, Christian Lamparter wrote: On Friday, June 20, 2014 09:19:07 PM Xose Vazquez Perez wrote: Kristina wrote: I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving rtl8712 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Christian Lamparter chunk...@googlemail.com is working on a new driver based on mac80211: https://github.com/chunkeey/rtl8192su Thanks for pointing that out and forwarding the email to Christian. rtl8192su development is chugging along. It just doesn't take place on driverdev list. The driver reached feature parity with rtl8192cu for some time ago. Great, thanks for letting me know. If you plan to keep working on it, do you think it would be a good idea to add yourself and a link to your github to the staging driver's TODO file? That way people who find it and want to work on it can join your effort, instead of starting their own. But as with rtl8192cu, I would recommend adding just a friendly printk. I'm not sure what printk you're referring to. Yup, Realtek really outdid themselves with the USB devices. :) Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on rtl8712?
On 20/06/14 20:15, Larry Finger wrote: On 06/20/2014 10:40 AM, Kristina Martšenko wrote: Hi Larry and Florian, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving rtl8712 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Kristina, Wireless drivers that do not use mac80211 cannot be placed in the regular wireless tree, no matter how polished and finished they are. I agree finished isn't a good word for it, but I was referring to all the changes that need to be made, including porting to mac80211. Is having a rigid delete schedule in the best interests of the users? That driver is crap code, but it works and it does not crash! Hey, I'm just trying to figure out if there's any hope of it ever moving out of staging. If not, and we leave it in, then it sets a dangerous precedent. Why should anyone ever clean up their driver if they can just put it in staging and it will stay there forever? We end up with a larger and larger body of code in the kernel that's low quality, and that means more bugs etc. And that's not good for anyone, including the users. In this case, since Christian is working on it, I think the current driver can stay in. There has been an effort to develop a driver to replace it, but I am not involved in that effort. I am not even sure it would use mac80211, thus it might also be in staging. I have been kept busy incorporating the new PCIe devices whose drivers do satisfy the requirements for being placed in the regular tree, once the code is polished. Even so, two such drivers are currently in staging, and need to be moved in the next two or three cycles. Yes, I'm aware of your work on those, but didn't know about this one, hence the question. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on wlags49_h2?
On 21/06/14 22:46, Greg KH wrote: On Sat, Jun 21, 2014 at 06:35:41PM +0100, Dave Kilroy wrote: On 20/06/2014 17:18, Kristina Martšenko wrote: I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving wlags49_h2(5) out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Hi Kristina, I'm not working on anything for wlags49_h2. Great, no objection if we delete it? Henk also sent the following email to me earlier: On 21/06/14 20:28, Henk de Groot wrote: Hi Kistina, Yes, I understand the need for keeping the staging tree clean. I don't know anybody working on the driver anymore, the only changes in are those prompted by automated processed. I frequently check if the driver is still functional and it is. But frankly I don't know exactly what is needed to get the driver out of the staging phase, except maybe a rewrite of the Agere code, but I don't think anybody will bother with that. After all the chip only supports 801.11b and also only WEP and WPA-TPK security. I think it is okay to remove the driver, I don't think there is much interest in it any more and I don't think anybody will be rewriting it. But it is still a functional driver which just works for these Agere cards. Kind regards, Henk - pe1...@amsat.org Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on netlogic?
Great, thanks for the quick response. I saw the patches, hope to see more soon! Kristina On 18/06/14 15:16, Ganesan Ramalingam wrote: Hi Kristina, We are working on next set of patches for this driver, it is in final stage, will be posting it soon. Thanks, Ganesan -Original Message- From: Kristina Martšenko [mailto:kristina.martse...@gmail.com] Sent: Wednesday, June 18, 2014 5:17 PM To: Ganesan Ramalingam; Jayachandran Chandrashekaran Nair Cc: Greg KH; de...@driverdev.osuosl.org Subject: Anybody working on netlogic? Hi Ganesan and Jayachandran, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving netlogic out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on crystalhd?
On 19/06/14 04:03, Greg KH wrote: On Thu, Jun 19, 2014 at 12:07:38AM +, Naren (Narendra) Sankar wrote: We have EOL this part and have not been selling it for a while and there has been no new customer interest in a long time. So I am also ok with this moving off the kernel and being dropped. Great, thanks for the quick response. Kristina, can you make up a patch that deletes this driver? Yeah, I'll send one soon. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on panel?
Hi Willy, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving panel out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on rtl8712?
Hi Larry and Florian, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving rtl8712 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on tidspbridge?
Hi Omar, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving tidspbridge out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on winbond?
Hi Pavel, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving winbond out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on tidspbridge?
On 20/06/14 18:43, Kristina Martšenko wrote: Hi Omar, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving tidspbridge out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina Omar's email address in tidspbridge's TODO file seems to be outdated. Resending to more recent addresses which hopefully won't bounce. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on wlags49_h2?
Hi Henk, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving wlags49_h2(5) out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on bcm?
Hi Stephen, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving bcm out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on panel?
On 20/06/14 19:52, Willy Tarreau wrote: Hi Kristina, On Fri, Jun 20, 2014 at 06:35:03PM +0300, Kristina Mart?enko wrote: Hi Willy, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving panel out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. In fact I think we're facing the edge of the staging driver model : it works fine for everyone and people are used to use it from there. I'm absolutely convinced that this is the worst thing to do, but we're in the situation where doing nothing ensures it continues to work. It was submitted a long time ago by a user. I was not very happy by this since I knew I wouldn't be the person doing the clean up, but I understand that it allows users to have it ready. Yes, I know what you mean. On the other hand, if we keep it around, we have to keep every other staging driver around for the same reason - that it works, and somebody might want to use it. The end result is that there's an ever increasing amount of code in the kernel that's low quality, and will probably always be so. Since then, there have been multiple cleanup passes, I'm not even sure if it still makes sense that it remains in staging now. That's good, though if you don't know, then I think probably no one does. Someone should probably review it. If some help is needed from my side to move it to drivers/misc, I'll participate, of course, but I clearly won't spend a whole week rewriting it differently for example. Do you want to review it? The TODO file says the userspace API and major/minor usages need checking. If not, then Greg, what do you think would be the best thing to do with this driver? Thanks for responding so quickly, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on ced1401?
Hi Alois, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving ced1401 out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on crystalhd?
Hi Naren, Jarod, Scott, Manu, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving crystalhd out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on frontier?
Hi David, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving frontier out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on keucr?
Hi Al, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving keucr out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Anybody working on netlogic?
Hi Ganesan and Jayachandran, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving netlogic out of staging in over a year. Are there any plans to clean it up and move it out soon? Because otherwise we're going to have to delete the driver, as we don't want staging to become a permanent place for unfinished code. Thanks, Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: goldfish: switch from spinlock to mutex
On 04/04/14 16:30, Dan Carpenter wrote: On Fri, Apr 04, 2014 at 02:46:14PM +0300, Kristina Martšenko wrote: Yes, I didn't find any interrupt handlers either, which is partially why I thought it was (probably) safe. What's the other part of why it was safe? Put that stuff in the changelog. When we're reviewing patches we're always interested to know if it's safe. :) The other part was whether the code was allowed to sleep. I figured it probably was since it's only accessed from MTD callback functions and other drivers in drivers/mtd/devices/ also sleep in those functions (either by using mutexes or by calling schedule() directly). I didn't mention why I thought it was safe in the changelog because I thought maybe the reasons would seem too obvious to more experienced kernel developers. Should I test and resend the patch with a new changelog? Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: goldfish: switch from spinlock to mutex
On 03/04/14 13:13, Dan Carpenter wrote: On Thu, Apr 03, 2014 at 01:00:53PM +0300, Kristina Martšenko wrote: On 03/04/14 11:32, Dan Carpenter wrote: On Tue, Mar 25, 2014 at 01:45:09AM +0200, Kristina Martšenko wrote: Use a mutex instead of a spinlock in goldfish_nand.c, as suggested by the TODO list. Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com Have you tested this change? Nope, just compile-tested. After a day of trying to get the emulator to work I finally gave up and decided that it looked okay enough... I should have mentioned under the patch description that it wasn't tested, sorry. It's not a wrong thing to submit patches that you can't test, but in this case the irq save/restores make me nervous. I can't see that they served any purpose and it's certainly not unheard of for staging code to do pointless things for unexplainable reasons. But on the other hand, I would feel a lot more comfortable if this change were tested or if there were more comments about how the change is safe. I'm not sure I understand. A mutex doesn't disable interrupts, so the cpu irq flags should be the same after the mutex-protected code as they were before. I.e. it would have the same effect as the save/restore. Or am I missing something? In any case I can take another shot at getting the Android emulator to work so that I can test this. (Probably not anytime soon though.) Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: goldfish: switch from spinlock to mutex
On 04/04/14 14:04, Dan Carpenter wrote: On Fri, Apr 04, 2014 at 12:26:27PM +0300, Kristina Martšenko wrote: On 03/04/14 13:13, Dan Carpenter wrote: On Thu, Apr 03, 2014 at 01:00:53PM +0300, Kristina Martšenko wrote: On 03/04/14 11:32, Dan Carpenter wrote: On Tue, Mar 25, 2014 at 01:45:09AM +0200, Kristina Martšenko wrote: Use a mutex instead of a spinlock in goldfish_nand.c, as suggested by the TODO list. Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com Have you tested this change? Nope, just compile-tested. After a day of trying to get the emulator to work I finally gave up and decided that it looked okay enough... I should have mentioned under the patch description that it wasn't tested, sorry. It's not a wrong thing to submit patches that you can't test, but in this case the irq save/restores make me nervous. I can't see that they served any purpose and it's certainly not unheard of for staging code to do pointless things for unexplainable reasons. But on the other hand, I would feel a lot more comfortable if this change were tested or if there were more comments about how the change is safe. I'm not sure I understand. A mutex doesn't disable interrupts, so the cpu irq flags should be the same after the mutex-protected code as they were before. I.e. it would have the same effect as the save/restore. Or am I missing something? A mutex doesn't disable IRQs but the original code used spin_lock_irqsave() so the original code did disable IRQs. Looking at it now, I'm not sure there was a reason to disable IRQs... This driver doesn't have an IRQ handler. Your change is probably fine. Yes, I didn't find any interrupt handlers either, which is partially why I thought it was (probably) safe. Kristina ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: goldfish: switch from spinlock to mutex
Use a mutex instead of a spinlock in goldfish_nand.c, as suggested by
the TODO list.
Signed-off-by: Kristina Martšenko kristina.martse...@gmail.com
---
drivers/staging/goldfish/README | 1 -
drivers/staging/goldfish/goldfish_nand.c | 15 +++
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/goldfish/README b/drivers/staging/goldfish/README
index 93d65b0..183af00 100644
--- a/drivers/staging/goldfish/README
+++ b/drivers/staging/goldfish/README
@@ -5,7 +5,6 @@ Audio
NAND
-- Switch from spinlock to mutex
- Remove excess checking of parameters in calls
- Use dma coherent memory not kmalloc/__pa for the memory (this is just
a cleanliness issue not a correctness one)
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index eca0873..7f606f7 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -24,13 +24,14 @@
#include linux/vmalloc.h
#include linux/mtd/mtd.h
#include linux/platform_device.h
+#include linux/mutex.h
#include asm/div64.h
#include goldfish_nand_reg.h
struct goldfish_nand {
- spinlock_t lock;
+ struct mutexlock;
unsigned char __iomem *base;
struct cmd_params *cmd_params;
size_t mtd_count;
@@ -77,10 +78,9 @@ static u32 goldfish_nand_cmd(struct mtd_info *mtd, enum
nand_cmd cmd,
{
struct goldfish_nand *nand = mtd-priv;
u32 rv;
- unsigned long irq_flags;
unsigned char __iomem *base = nand-base;
- spin_lock_irqsave(nand-lock, irq_flags);
+ mutex_lock(nand-lock);
if (goldfish_nand_cmd_with_params(mtd, cmd, addr, len, ptr, rv)) {
writel(mtd - nand-mtd, base + NAND_DEV);
writel((u32)(addr 32), base + NAND_ADDR_HIGH);
@@ -90,7 +90,7 @@ static u32 goldfish_nand_cmd(struct mtd_info *mtd, enum
nand_cmd cmd,
writel(cmd, base + NAND_COMMAND);
rv = readl(base + NAND_RESULT);
}
- spin_unlock_irqrestore(nand-lock, irq_flags);
+ mutex_unlock(nand-lock);
return rv;
}
@@ -307,12 +307,11 @@ static int goldfish_nand_init_device(struct
platform_device *pdev,
u32 name_len;
u32 result;
u32 flags;
- unsigned long irq_flags;
unsigned char __iomem *base = nand-base;
struct mtd_info *mtd = nand-mtd[id];
char *name;
- spin_lock_irqsave(nand-lock, irq_flags);
+ mutex_lock(nand-lock);
writel(id, base + NAND_DEV);
flags = readl(base + NAND_DEV_FLAGS);
name_len = readl(base + NAND_DEV_NAME_LEN);
@@ -329,7 +328,7 @@ static int goldfish_nand_init_device(struct platform_device
*pdev,
goldfish nand dev%d: size %llx, page %d, extra %d, erase %d\n,
id, mtd-size, mtd-writesize,
mtd-oobsize, mtd-erasesize);
- spin_unlock_irqrestore(nand-lock, irq_flags);
+ mutex_unlock(nand-lock);
mtd-priv = nand;
@@ -405,7 +404,7 @@ static int goldfish_nand_probe(struct platform_device *pdev)
if (nand == NULL)
return -ENOMEM;
- spin_lock_init(nand-lock);
+ mutex_init(nand-lock);
nand-base = base;
nand-mtd_count = num_dev;
platform_set_drvdata(pdev, nand);
--
1.8.5.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
