Re: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On Sat, Aug 11, 2012 at 10:15 PM, Mauro Carvalho Chehab wrote: > Devin/Antti, > > As Juergen mentioned your help on this patch, do you mind helping reviewing > and testing it? I guided Juergen through the creation of the patch via #linuxtv a couple of weeks ago. While I'm generally confident that it should work (and it does address his basic issue), I hadn't had the time to stare at the code long enough to see what other side effects it might produce. I'm tied up in other projects right now and am not confident I will have cycles to look at this closer. Antti, if you want to give it some cycles, this would be a good fix to get upstream (and you've already been looking at dvb_frontend.c for quite a while, so I believe you would be able to spot a problem if one exists). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
Devin/Antti,
As Juergen mentioned your help on this patch, do you mind helping reviewing
and testing it?
Touching on those semaphores can be very tricky, as anything wrong may cause
a driver hangup. So, it is great to have more pair of eyes looking on it.
While I didn't test the code (too busy trying to clean up my long queue -
currently with still 200+ patches left), I did a careful review at the
semaphore code there, and it seems this approach will work.
At least, the first hunk looks perfect for me. The second hunk seems
a little more worrying, as the dvb core might be waiting forever for
a lock on a device that was already removed.
In order to test it in practice, I think we need to remove an USB device
by hand while tuning it, and see if the core will not lock the device
forever.
What do you think?
Mauro
Mensagem original
Assunto: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
Data: Wed, 1 Aug 2012 00:22:16 +0200
De: Juergen Lock
Para: linux-media@vger.kernel.org
CC: hsela...@c2i.net
That likely fxes this MythTV ticket:
http://code.mythtv.org/trac/ticket/10830
(which btw affects all usb tuners I tested as well, pctv452e,
dib0700, af9015) pctv452e is still possibly broken with MythTV
even after this fix; it does work with VDR here tho despite I2C
errors.
Reduced testcase:
http://people.freebsd.org/~nox/tmp/ioctltst.c
Thanx to devinheitmueller and crope from #linuxtv for helping with
this fix! :)
Signed-off-by: Juergen Lock
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -604,6 +604,7 @@ static int dvb_frontend_thread(void *dat
enum dvbfe_algo algo;
bool re_tune = false;
+ bool semheld = false;
dprintk("%s\n", __func__);
@@ -627,6 +628,8 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
+ if (!down_interruptible (&fepriv->sem))
+ semheld = true;
fepriv->exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -742,6 +745,8 @@ restart:
fepriv->exit = DVB_FE_NO_EXIT;
mb();
+ if (semheld)
+ up(&fepriv->sem);
dvb_frontend_wakeup(fe);
return 0;
}
@@ -1804,16 +1809,20 @@ static int dvb_frontend_ioctl(struct fil
dprintk("%s (%d)\n", __func__, _IOC_NR(cmd));
- if (fepriv->exit != DVB_FE_NO_EXIT)
+ if (down_interruptible (&fepriv->sem))
+ return -ERESTARTSYS;
+
+ if (fepriv->exit != DVB_FE_NO_EXIT) {
+ up(&fepriv->sem);
return -ENODEV;
+ }
if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
(_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
-cmd == FE_DISEQC_RECV_SLAVE_REPLY))
+cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
+ up(&fepriv->sem);
return -EPERM;
-
- if (down_interruptible (&fepriv->sem))
- return -ERESTARTSYS;
+ }
if ((cmd == FE_SET_PROPERTY) || (cmd == FE_GET_PROPERTY))
err = dvb_frontend_ioctl_properties(file, cmd, parg);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [media] adv7180: remove {query/g_/s_}ctrl
Em 31-07-2012 17:20, Federico Vaga escreveu: > I'm sorry for the email duplication, I press the wrong key on git-send email. > Ignore these emails. Sorry > Ok, I'll mark those patches as "RFC" per your request. Regards, mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Q: c->bandwidth_hz = (c->symbol_rate * rolloff) / 100
Hi Antti, Em 11-08-2012 21:22, Antti Palosaari escreveu: > Hellou > > I saw there is nowadays logic in dvb-frontend which calculates bandwidth_hz > value in cache. Calculation formula seems to be correct. But that makes me > wonder if that is wise as it gives occupied bandwidth instead of nominal. For > example I have typical DVB-C annex A, 8 MHz bandwidth, symbol rate 6875000 > and roll-off factor 0.15. That gives calculation result is 7 906 250 Hz for > nominal 8 000 000 Hz channel. > > This value is used only by tuner. Only visible effect is thus every tuner > driver should use if statement to compare to find out nominal value as tuner > chips usually configures low-pass filter steps of 8/7/6/5 MHz. > > For me it sounds better if tuner just gets nominal bandwidth - maybe > calculating real used bw could be nice too as it is possible to return > userspace. > > Shortly: I see it better to give nominal RF channel value for tuner. That's a good point. I had the same kind of doubt when I fixed DVB-C with 6MHz bandwidth. On all tuners I know, the saw filter can be configured only with a multiple of 1 MHz steps, but assuming that this will always be true seems a bad practice. For example one of the possible bandwidth ranges for DVB-T2 is now 1.712 MHz. Also, it should be noticed that nothing prevents a cable operator to have low res channels using a 1.712 MHz bandwidth space, or some non-standard spacing. If you take a look at the symbol rates used on w_scan, you'll see that there are some weird values there (most of them using 1.15 roll-off factor): -S set DVB-C symbol rate, see table: 0 = 6.9000 MSymbol/s 1 = 6.8750 MSymbol/s 2 = 6.9565 MSymbol/s 3 = 6.9560 MSymbol/s 4 = 6.9520 MSymbol/s 5 = 6.9500 MSymbol/s 6 = 6.7900 MSymbol/s 7 = 6.8110 MSymbol/s 8 = 6.2500 MSymbol/s 9 = 6.1110 MSymbol/s 10 = 6.0860 MSymbol/s 11 = 5.9000 MSymbol/s 12 = 5.4830 MSymbol/s 13 = 5.2170 MSymbol/s 14 = 5.1560 MSymbol/s 15 = 5. MSymbol/s 16 = 4. MSymbol/s 17 = 3.4500 MSymbol/s On the above, you'll see bandwidths of 3.96 MHz, 4.6 MHz, 5,75 MHz, etc. Just rounding it up to the next integer value might not be the right thing to do, especially if the cable operator is not spacing channels on a multiple of 1 MHz channel table. So, a DVB-T2 capable tuner that supports such narrow bandwidth may allow using a fractional MHz stepping for the saw filter. Thinking on theese, I opted to do the step rounding inside the drivers, and not at the DVB core. The way it is coded, userspace programs can round it up to the next closest bandwidth, in order to show 7,9 MHz as 8 MHz, and Kernel drivers can round it to the closest supported saw filter. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR 1600 - Analog goes south again
On Sat, 2012-08-11 at 19:22 -0400, Andy Walls wrote: > On Fri, 2012-08-10 at 18:04 -0400, Bob Lightfoot wrote: > > Dear Media List Members: > > I have been using my Hauppage HVR1600 on Centos 6 for some time > > and getting good analog reception. Now the other day for a reason I > > have not been able to determine the Analog quit working and I have not > > had success restoring it. I'm looking for the usual helpful > > suggestions I've gotten from this group in the past. Here has been my > > troubleshooting to date. > > 1. Verified that analog signal is present in cable by hooking a TV to > > cable. > > 2. Reinstalled all latest v4l and v4l2 drivers from atrpms.net > > packages. These are what has worked in past. > > > Please try to use a DVD player or camera on the S-Video or CVBS analog > video input and L/R line in audio input, instead of the tuner. (Use > 'v4l2-ctl' on /dev/videoN to set the input.) That will narrow down > whether or not this is an analog tuner problem. > > Obviously check cables and connectors for breaks, including inspecting, > as best you can, the connector on the HVR-1600 itself. > > With analog problems, I always encourgae people to double-check their > cable plant: > http://ivtvdriver.org/index.php/Howto:Improve_signal_quality > > Also as a temporary test, you may want to run a line from the analog > source straight to the HVR-1600 with no splits, to see if things start > to work. > > > v4l2-ctl --log-status shows video signal not present > > > Status Log: > > > > > > cx18-0: = START STATUS CARD #0 = > > > cx18-0: Version: 1.5.1 Card: Hauppauge HVR-1600 > > > tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 5267091 > > tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93 > > tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) > > tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08) > > tveeprom 4-0050: audio processor is CX23418 (idx 38) > > tveeprom 4-0050: decoder processor is CX23418 (idx 31) > > > tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter > > > cx18-0 843: Video signal: not present > > > cx18-0 843: Detected format: NTSC-M > > cx18-0 843: Specified standard: NTSC-M > > cx18-0 843: Specified video input: Composite 7 > > cx18-0 843: Specified audioclock freq: 48000 Hz > > cx18-0 843: Detected audio mode: mono > > cx18-0 843: Detected audio standard: no detected audio standard > > cx18-0 843: Audio muted: yes > > cx18-0 843: Audio microcontroller: running > > cx18-0 843: Configured audio standard: automatic detection > > cx18-0 843: Configured audio system: BTSC > > cx18-0 843: Specified audio input: Tuner (In8) > > > cx18-0 843: Preferred audio mode: stereo cx18-0 > > > gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 > > > tuner 5-0061: Tuner mode: analog TV > > tuner 5-0061: Frequency: 67.25 MHz > > 67.25 MHz is US analog broadcast channel 4 (the default channel to which > the cx18 driver sets the tuner upon module load). Make sure you have an > analog signal on channel 4. > > Otherwise tune the channel freq using 'ivtv-ctl' or 'v4l2-ctl' Ooops. I meant to say 'ivtv-tune' instead of 'ivtv-ctl'. -Andy > on /dev/videoN. If using 'v4l2-ctl', analog frequency tables for North > America are here: > > http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies > http://en.wikipedia.org/wiki/North_American_cable_television_frequencies > > > tuner 5-0061: Standard:0x1000 > > cs5345 4-004c: Input: 1 > > cs5345 4-004c: Volume: 0 dB > > cx18-0: Video Input: Tuner 1 > > > cx18-0: Audio Input: Tuner 1 > > cx18-0: GPIO: direction 0x3001, value 0x3001 > > cx18-0: Tuner: TV > > cx18-0: Stream Type: MPEG-2 Program Stream > > cx18-0: Stream VBI Format: No VBI > > cx18-0: Audio Sampling Frequency: 48 kHz cx18-0: Audio Encoding: MPEG-1/2 > > Layer > > > II cx18-0: Audio Layer II Bitrate: 224 kbps cx18-0: Audio Stereo > > > Mode: Stereo cx18-0: Audio Stereo Mode Extension: Bound 4 inactive > > > cx18-0: Audio Emphasis: No Emphasis cx18-0: Audio CRC: No CRC > > > cx18-0: Audio Mute: false cx18-0: Video Encoding: MPEG-2 cx18-0: > > > Video Aspect: 4x3 cx18-0: Video B Frames: 2 cx18-0: Video GOP Size: > > > 15 cx18-0: Video GOP Closure: true cx18-0: Video Bitrate Mode: > > > Variable Bitrate cx18-0: Video Bitrate: 600 cx18-0: Video Peak > > > Bitrate: 800 cx18-0: Video Temporal Decimation: 0 cx18-0: Video > > > Mute: false cx18-0: Video Mute YUV: 32896 cx18-0: Spatial Filter > > > Mode: Manual cx18-0: Spatial Filter: 0 cx18-0: Spatial Luma Filter > > > Type: 1D Horizontal cx18-0: Spatial Chroma Filter Type: 1D > > > Horizontal cx18-0: Temporal Filter Mode: Manual cx18-0: Temporal > > > Filter: 8 cx18-0: Median Filter Type: Off cx18-0: Median Luma > > > Filter Minimum: 0 inactive cx18-0: Median Luma Filter
Re: [PATCH] [media] iguanair: various fixes
Em 31-07-2012 07:37, Sean Young escreveu:
> This fixes:
> - rx_overflow while holding down any down button on a nec remote
> - suspend/resume
> - stop receiver on rmmod
> - advertise rx_resolution and timeout properly
> - code simplify
> - ignore unsupported firmware versions
Please don't mix several different things on the same patch; it makes
harder for review and, if any of these changes break, a git revert would
change a lot of unrelated things. It also makes hard for bug disect.
Tip: "git citool" helps a lot to break messy patches into smaller, concise
ones.
Thanks!
Mauro
>
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/Kconfig| 8 +-
> drivers/media/rc/iguanair.c | 206
> ++--
> 2 files changed, 107 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 5180390..fa1745c 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -264,8 +264,12 @@ config IR_IGUANA
> depends on RC_CORE
> select USB
> ---help---
> -Say Y here if you want to use the IgaunaWorks USB IR Transceiver.
> -Both infrared receive and send are supported.
> +Say Y here if you want to use the IguanaWorks USB IR Transceiver.
> +Both infrared receive and send are supported. If you want to
> +change the ID or the pin config, use the user space driver from
> +IguanaWorks.
> +
> +Only firmware 0x0205 and later is supported.
>
> To compile this driver as a module, choose M here: the module will
> be called iguanair.
> diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
> index 5e2eaf8..aa7f34f 100644
> --- a/drivers/media/rc/iguanair.c
> +++ b/drivers/media/rc/iguanair.c
> @@ -35,9 +35,9 @@ struct iguanair {
> struct device *dev;
> struct usb_device *udev;
>
> - int pipe_in, pipe_out;
> + int pipe_out;
> + uint16_t version;
> uint8_t bufsize;
> - uint8_t version[2];
>
> struct mutex lock;
>
> @@ -61,20 +61,21 @@ struct iguanair {
> };
>
> #define CMD_GET_VERSION 0x01
> -#define CMD_GET_BUFSIZE 0x11
> #define CMD_GET_FEATURES 0x10
> +#define CMD_GET_BUFSIZE 0x11
> +#define CMD_RECEIVER_ON 0x12
> +#define CMD_RECEIVER_OFF 0x14
> #define CMD_SEND 0x15
> -#define CMD_EXECUTE 0x1f
> +#define CMD_GET_ID 0x1f
> #define CMD_RX_OVERFLOW 0x31
> #define CMD_TX_OVERFLOW 0x32
> -#define CMD_RECEIVER_ON 0x12
> -#define CMD_RECEIVER_OFF 0x14
>
> #define DIR_IN 0xdc
> #define DIR_OUT 0xcd
>
> #define MAX_PACKET_SIZE 8u
> #define TIMEOUT 1000
> +#define RX_RESOLUTION21330
>
> struct packet {
> uint16_t start;
> @@ -82,11 +83,6 @@ struct packet {
> uint8_t cmd;
> };
>
> -struct response_packet {
> - struct packet header;
> - uint8_t data[4];
> -};
> -
> struct send_packet {
> struct packet header;
> uint8_t length;
> @@ -96,10 +92,46 @@ struct send_packet {
> uint8_t payload[0];
> };
>
> +/*
> + * The hardware advertises a polling interval of 10ms. This is far too
> + * slow and will cause regular rx overflows.
> + */
> +static int int_urb_interval(struct usb_device *udev)
> +{
> + switch (udev->speed) {
> + case USB_SPEED_HIGH:
> + return 4;
> + case USB_SPEED_LOW:
> + return 1;
> + case USB_SPEED_FULL:
> + default:
> + return 1;
> + }
> +}
> +
> static void process_ir_data(struct iguanair *ir, unsigned len)
> {
> if (len >= 4 && ir->buf_in[0] == 0 && ir->buf_in[1] == 0) {
> switch (ir->buf_in[3]) {
> + case CMD_GET_VERSION:
> + if (len == 6) {
> + ir->version = (ir->buf_in[5] << 8) |
> + ir->buf_in[4];
> + complete(&ir->completion);
> + }
> + break;
> + case CMD_GET_BUFSIZE:
> + if (len >= 5) {
> + ir->bufsize = ir->buf_in[4];
> + complete(&ir->completion);
> + }
> + break;
> + case CMD_GET_FEATURES:
> + if (len > 5) {
> + ir->cycle_overhead = ir->buf_in[5];
> + complete(&ir->completion);
> + }
> + break;
> case CMD_TX_OVERFLOW:
> ir->tx_overflow = true;
> case CMD_RECEIVER_OFF:
> @@ -109,6 +141,7 @@ static void process_ir_data(struct iguanair *ir, unsigned
> len)
> break;
> case CM
Q: c->bandwidth_hz = (c->symbol_rate * rolloff) / 100
Hellou I saw there is nowadays logic in dvb-frontend which calculates bandwidth_hz value in cache. Calculation formula seems to be correct. But that makes me wonder if that is wise as it gives occupied bandwidth instead of nominal. For example I have typical DVB-C annex A, 8 MHz bandwidth, symbol rate 6875000 and roll-off factor 0.15. That gives calculation result is 7 906 250 Hz for nominal 8 000 000 Hz channel. This value is used only by tuner. Only visible effect is thus every tuner driver should use if statement to compare to find out nominal value as tuner chips usually configures low-pass filter steps of 8/7/6/5 MHz. For me it sounds better if tuner just gets nominal bandwidth - maybe calculating real used bw could be nice too as it is possible to return userspace. Shortly: I see it better to give nominal RF channel value for tuner. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: boot slow down
On Wed, 2012-08-08 at 13:18 -0400, bjloc...@lockie.ca wrote: > How hard would it be to get an official kernel option not to load firmware Submit a patch for the cx23885 driver to the list. It could add a module option so the user can specify not to load cx23885-av firmware (and maybe CX23417 firmware too). The new module option could be set on your kernel commandline: cx23885.no_firmware_load=1 Honestly though such a patch problably won't fly. The real solution, that the cx23885 driver needs anyway, is to inhibit the load of all firmware during the device probe by the kernel, and load them on the first device open (like the ivtv and cx18 drivers do for analog). There are at least 2 places in the PCI device probe routine of the cx23885 driver, where firmware is requested. Here is the call chain: cx23885_initdev() cx23885_dev_setup() cx23885_card_setup() v4l2_subdev_call(dev->sd_cx25840, core, load_fw); cx25840_load_fw() cx23885_initialize() cx25840_work_handler() cx25840_loadfw() request_firmware() cx23885_417_register() cx23885_initialize_codec() cx23885_load_firmware() request_firmware() The calls to v4l2_subdev_call(dev->sd_cx25840, core, load_fw); and cx23885_417_register() (or cx23885_initialize_codec()) really need to be deferred to comply with new udev requirements for driver behavior. > OR be able to set the timeout? That would probably be harder politically, even if the code were not harder. No driver is supposed to be loading firmware during its device probes. Once userspace is up, /sys/class/firmware/timeout can be manipulated very early, before any device would be requesting firmware. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DVB-S2 multistream support
On 08/12/2012 01:55 AM, CrazyCat wrote:
Fixed patch.
We asked you to merge isdbs_ts_id, dvbt2_plp_id and dvbs2_mis_id to one
as those are logically same thing from the user-point of view.
Technically those differs, but that is userspace API so underlying
technique should not matter.
It is some more work for you, but it should not be such big issue you
cannot do. So please use few hours and merge all those. I think correct
name is DTV_STREAM_ID. So remove isdbs_ts_id, dvbt2_plp_id and
dvbs2_mis_id. Add new variable stream_id. As DTV_ISDBS_TS_ID and
DTV_DVBT2_PLP_ID already exists you should make some logic those could
be still used.
regards
Antti
Signed-off-by: Evgeny Plehov
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..7813165 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -948,6 +948,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c->isdbs_ts_id = 0;
c->dvbt2_plp_id = 0;
+ c->dvbs2_mis_id = -1;
switch (c->delivery_system) {
case SYS_DVBS:
@@ -1049,6 +1050,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_DVBS2_MIS_ID, 1, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1436,6 +1439,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_DVBS2_MIS_ID:
+ tvp->u.data = c->dvbs2_mis_id;
+ break;
+
default:
return -EINVAL;
}
@@ -1786,6 +1793,10 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_DVBS2_MIS_ID:
+ c->dvbs2_mis_id = tvp->u.data;
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 7c64c09..cf10b05 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -374,6 +374,9 @@ struct dtv_frontend_properties {
/* DVB-T2 specifics */
u32 dvbt2_plp_id;
+ /* DVB-S2 specifics */
+ u32 dvbs2_mis_id;
+
/* ATSC-MH specifics */
u8 atscmh_fic_ver;
u8 atscmh_parade_id;
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index ea86a56..a9c2bc5 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3425,6 +3425,33 @@ err:
return -1;
}
+static int stv090x_set_mis(struct stv090x_state *state, int mis)
+{
+ u32 reg;
+
+ if (mis < 0 || mis > 255) {
+ dprintk(FE_DEBUG, 1, "Disable MIS filtering");
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x00);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+ goto err;
+ } else {
+ dprintk(FE_DEBUG, 1, "Enable MIS filtering - %d", mis);
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x01);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIENTRY, mis) < 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIBITENA, 0xff) < 0)
+ goto err;
+ }
+ return 0;
+err:
+ dprintk(FE_ERROR, 1, "I/O error");
+ return -1;
+}
+
static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
{
struct stv090x_state *state = fe->demodulator_priv;
@@ -3447,6 +3474,8 @@ static enum dvbfe_search stv090x_search(struct
dvb_frontend *fe)
state->search_range = 500;
}
+ stv090x_set_mis(state, props->dvbs2_mis_id);
+
if (stv090x_algo(state) == STV090x_RANGEOK) {
dprintk(FE_DEBUG, 1, "Search success!");
return DVBFE_ALGO_SEARCH_SUCCESS;
@@ -4798,6 +4827,9 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
}
}
+ if (state->internal->dev_ver >= 0x30)
+ state->frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
/* workaround for stuck DiSEqC output */
if (config->diseqc_envelope_mode)
stv090x_send_diseqc_burst(&state->frontend, SEC_MINI_A);
diff --git a/include/linux/dv
Re: HVR 1600 - Analog goes south again
On Fri, 2012-08-10 at 18:04 -0400, Bob Lightfoot wrote: > Dear Media List Members: > I have been using my Hauppage HVR1600 on Centos 6 for some time > and getting good analog reception. Now the other day for a reason I > have not been able to determine the Analog quit working and I have not > had success restoring it. I'm looking for the usual helpful > suggestions I've gotten from this group in the past. Here has been my > troubleshooting to date. > 1. Verified that analog signal is present in cable by hooking a TV to > cable. > 2. Reinstalled all latest v4l and v4l2 drivers from atrpms.net > packages. These are what has worked in past. Please try to use a DVD player or camera on the S-Video or CVBS analog video input and L/R line in audio input, instead of the tuner. (Use 'v4l2-ctl' on /dev/videoN to set the input.) That will narrow down whether or not this is an analog tuner problem. Obviously check cables and connectors for breaks, including inspecting, as best you can, the connector on the HVR-1600 itself. With analog problems, I always encourgae people to double-check their cable plant: http://ivtvdriver.org/index.php/Howto:Improve_signal_quality Also as a temporary test, you may want to run a line from the analog source straight to the HVR-1600 with no splits, to see if things start to work. > v4l2-ctl --log-status shows video signal not present > > Status Log: > > > > cx18-0: = START STATUS CARD #0 = > > cx18-0: Version: 1.5.1 Card: Hauppauge HVR-1600 > tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 5267091 > tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93 > tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) > tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 4-0050: audio processor is CX23418 (idx 38) > tveeprom 4-0050: decoder processor is CX23418 (idx 31) > > tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter > > cx18-0 843: Video signal: not present > > cx18-0 843: Detected format: NTSC-M > cx18-0 843: Specified standard: NTSC-M > cx18-0 843: Specified video input: Composite 7 > cx18-0 843: Specified audioclock freq: 48000 Hz > cx18-0 843: Detected audio mode: mono > cx18-0 843: Detected audio standard: no detected audio standard > cx18-0 843: Audio muted: yes > cx18-0 843: Audio microcontroller: running > cx18-0 843: Configured audio standard: automatic detection > cx18-0 843: Configured audio system: BTSC > cx18-0 843: Specified audio input: Tuner (In8) > > cx18-0 843: Preferred audio mode: stereo cx18-0 > > gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 > > tuner 5-0061: Tuner mode: analog TV > tuner 5-0061: Frequency: 67.25 MHz 67.25 MHz is US analog broadcast channel 4 (the default channel to which the cx18 driver sets the tuner upon module load). Make sure you have an analog signal on channel 4. Otherwise tune the channel freq using 'ivtv-ctl' or 'v4l2-ctl' on /dev/videoN. If using 'v4l2-ctl', analog frequency tables for North America are here: http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies http://en.wikipedia.org/wiki/North_American_cable_television_frequencies > tuner 5-0061: Standard:0x1000 > cs5345 4-004c: Input: 1 > cs5345 4-004c: Volume: 0 dB > cx18-0: Video Input: Tuner 1 > > cx18-0: Audio Input: Tuner 1 > cx18-0: GPIO: direction 0x3001, value 0x3001 > cx18-0: Tuner: TV > cx18-0: Stream Type: MPEG-2 Program Stream > cx18-0: Stream VBI Format: No VBI > cx18-0: Audio Sampling Frequency: 48 kHz cx18-0: Audio Encoding: MPEG-1/2 > Layer > > II cx18-0: Audio Layer II Bitrate: 224 kbps cx18-0: Audio Stereo > > Mode: Stereo cx18-0: Audio Stereo Mode Extension: Bound 4 inactive > > cx18-0: Audio Emphasis: No Emphasis cx18-0: Audio CRC: No CRC > > cx18-0: Audio Mute: false cx18-0: Video Encoding: MPEG-2 cx18-0: > > Video Aspect: 4x3 cx18-0: Video B Frames: 2 cx18-0: Video GOP Size: > > 15 cx18-0: Video GOP Closure: true cx18-0: Video Bitrate Mode: > > Variable Bitrate cx18-0: Video Bitrate: 600 cx18-0: Video Peak > > Bitrate: 800 cx18-0: Video Temporal Decimation: 0 cx18-0: Video > > Mute: false cx18-0: Video Mute YUV: 32896 cx18-0: Spatial Filter > > Mode: Manual cx18-0: Spatial Filter: 0 cx18-0: Spatial Luma Filter > > Type: 1D Horizontal cx18-0: Spatial Chroma Filter Type: 1D > > Horizontal cx18-0: Temporal Filter Mode: Manual cx18-0: Temporal > > Filter: 8 cx18-0: Median Filter Type: Off cx18-0: Median Luma > > Filter Minimum: 0 inactive cx18-0: Median Luma Filter Maximum: 255 > > inactive cx18-0: Median Chroma Filter Minimum: 0 inactive cx18-0: > > Median Chroma Filter Maximum: 255 inactive cx18-0: Insert > > Navigation Packets: false cx18-0: Status flags: 0x0021 cx18-0: > > Stream encoder MPEG: status 0x, 0% of 2048 KiB (64 buffers) in > > use cx18-0: Stream en
Re: [PATCH] DVB-S2 multistream support
Fixed patch.
Signed-off-by: Evgeny Plehov
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index aebcdf2..7813165 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -948,6 +948,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c->isdbs_ts_id = 0;
c->dvbt2_plp_id = 0;
+ c->dvbs2_mis_id = -1;
switch (c->delivery_system) {
case SYS_DVBS:
@@ -1049,6 +1050,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+ _DTV_CMD(DTV_DVBS2_MIS_ID, 1, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1436,6 +1439,10 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
break;
+ case DTV_DVBS2_MIS_ID:
+ tvp->u.data = c->dvbs2_mis_id;
+ break;
+
default:
return -EINVAL;
}
@@ -1786,6 +1793,10 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
break;
+ case DTV_DVBS2_MIS_ID:
+ c->dvbs2_mis_id = tvp->u.data;
+ break;
+
default:
return -EINVAL;
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 7c64c09..cf10b05 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -374,6 +374,9 @@ struct dtv_frontend_properties {
/* DVB-T2 specifics */
u32 dvbt2_plp_id;
+ /* DVB-S2 specifics */
+ u32 dvbs2_mis_id;
+
/* ATSC-MH specifics */
u8 atscmh_fic_ver;
u8 atscmh_parade_id;
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index ea86a56..a9c2bc5 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3425,6 +3425,33 @@ err:
return -1;
}
+static int stv090x_set_mis(struct stv090x_state *state, int mis)
+{
+ u32 reg;
+
+ if (mis < 0 || mis > 255) {
+ dprintk(FE_DEBUG, 1, "Disable MIS filtering");
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x00);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+ goto err;
+ } else {
+ dprintk(FE_DEBUG, 1, "Enable MIS filtering - %d", mis);
+ reg = STV090x_READ_DEMOD(state, PDELCTRL1);
+ STV090x_SETFIELD_Px(reg, FILTER_EN_FIELD, 0x01);
+ if (STV090x_WRITE_DEMOD(state, PDELCTRL1, reg) < 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIENTRY, mis) < 0)
+ goto err;
+ if (STV090x_WRITE_DEMOD(state, ISIBITENA, 0xff) < 0)
+ goto err;
+ }
+ return 0;
+err:
+ dprintk(FE_ERROR, 1, "I/O error");
+ return -1;
+}
+
static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
{
struct stv090x_state *state = fe->demodulator_priv;
@@ -3447,6 +3474,8 @@ static enum dvbfe_search stv090x_search(struct
dvb_frontend *fe)
state->search_range = 500;
}
+ stv090x_set_mis(state, props->dvbs2_mis_id);
+
if (stv090x_algo(state) == STV090x_RANGEOK) {
dprintk(FE_DEBUG, 1, "Search success!");
return DVBFE_ALGO_SEARCH_SUCCESS;
@@ -4798,6 +4827,9 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
}
}
+ if (state->internal->dev_ver >= 0x30)
+ state->frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
/* workaround for stuck DiSEqC output */
if (config->diseqc_envelope_mode)
stv090x_send_diseqc_burst(&state->frontend, SEC_MINI_A);
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index f50d405..b37996e 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -62,6 +62,7 @@ typedef enum fe_caps {
FE_CAN_8VSB = 0x20,
FE_CAN_16VSB= 0x40,
FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace
for newer APIs, indicate this. */
+ FE_CAN_MULTISTREAM = 0x400, /* frontend supports
DVB-S2 multistream filtering */
FE_CAN_TURBO_FEC= 0x800, /* frontend supports
"turbo fec modulation" */
FE_CAN_2G_MODULATION= 0
Re: [PATCH]Omicom S2 PCI support
Ok, fixed patch.
Signed-off-by: Evgeny Plehov
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index b21bcce..7e6e43a 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -50,6 +50,8 @@
#include "stv6110x.h"
#include "stv090x.h"
#include "isl6423.h"
+#include "lnbh24.h"
+
static int diseqc_method;
module_param(diseqc_method, int, 0444);
@@ -679,6 +681,62 @@ static void frontend_init(struct budget *budget)
}
}
break;
+
+ case 0x1020: { /* Omicom S2 */
+ struct stv6110x_devctl *ctl;
+ saa7146_setgpio(budget->dev, 2, SAA7146_GPIO_OUTLO);
+ msleep(50);
+ saa7146_setgpio(budget->dev, 2, SAA7146_GPIO_OUTHI);
+ msleep(250);
+
+ budget->dvb_frontend = dvb_attach(stv090x_attach,
+
&tt1600_stv090x_config,
+ &budget->i2c_adap,
+
STV090x_DEMODULATOR_0);
+
+ if (budget->dvb_frontend) {
+ printk(KERN_INFO "budget: Omicom S2
detected\n");
+
+ ctl = dvb_attach(stv6110x_attach,
+budget->dvb_frontend,
+&tt1600_stv6110x_config,
+&budget->i2c_adap);
+
+ if (ctl) {
+ tt1600_stv090x_config.tuner_init
= ctl->tuner_init;
+ tt1600_stv090x_config.tuner_sleep
= ctl->tuner_sleep;
+ tt1600_stv090x_config.tuner_set_mode
= ctl->tuner_set_mode;
+
tt1600_stv090x_config.tuner_set_frequency = ctl->tuner_set_frequency;
+
tt1600_stv090x_config.tuner_get_frequency = ctl->tuner_get_frequency;
+
tt1600_stv090x_config.tuner_set_bandwidth = ctl->tuner_set_bandwidth;
+
tt1600_stv090x_config.tuner_get_bandwidth = ctl->tuner_get_bandwidth;
+ tt1600_stv090x_config.tuner_set_bbgain
= ctl->tuner_set_bbgain;
+ tt1600_stv090x_config.tuner_get_bbgain
= ctl->tuner_get_bbgain;
+ tt1600_stv090x_config.tuner_set_refclk
= ctl->tuner_set_refclk;
+ tt1600_stv090x_config.tuner_get_status
= ctl->tuner_get_status;
+
+ /* call the init function once to
initialize
+ tuner's clock output divider and
demod's
+ master clock */
+ if (budget->dvb_frontend->ops.init)
+
budget->dvb_frontend->ops.init(budget->dvb_frontend);
+
+ if (dvb_attach(lnbh24_attach,
+ budget->dvb_frontend,
+ &budget->i2c_adap,
+ LNBH24_PCL | LNBH24_TTX,
+ LNBH24_TEN, 0x14>>1) ==
NULL) {
+ printk(KERN_ERR
+ "No LNBH24 found!\n");
+ goto error_out;
+ }
+ } else {
+ printk(KERN_ERR "%s: No STV6110(A)
Silicon Tuner found!\n", __func__);
+ goto error_out;
+ }
+ }
+ }
+ break;
}
if (budget->dvb_frontend == NULL) {
@@ -759,6 +817,7 @@ MAKE_BUDGET_INFO(fsacs0, "Fujitsu Siemens Activy Budget-S
PCI (rev GR/grundig fr
MAKE_BUDGET_INFO(fsacs1, "Fujitsu Siemens Activy Budget-S PCI (rev AL/alps
frontend)", BUDGET_FS_ACTIVY);
MAKE_BUDGET_INFO(fsact, "Fujitsu Siemens Activy Budget-T PCI (rev
GR/Grundig frontend)", BUDGET_FS_ACTIVY);
MAKE_BUDGET_INFO(fsact1, "Fujitsu Siemens Activy Budget-T PCI (rev AL/ALPS
TDHD1-204A)", BUDGET_FS_ACTIVY);
+MAKE_BUDGET_INFO(omicom, "Omicom S2 PCI", BUDGET_TT);
static struct pci_device_id pci_tbl[] = {
MAKE_EXTENSION_PCI(ttbs, 0x13c2, 0x1003),
@@ -772,6 +831,7 @@ static struct pci_device_id pci_tbl[] = {
MAKE_EXTENSION_PCI(fsacs0,0x1131, 0x4f61),
MAKE_EXTENSION_PCI(fsact1, 0x1131
Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
On Saturday 11 of August 2012 21:32:15 Sylwester Nawrocki wrote: > On 08/11/2012 08:39 PM, Tomasz Figa wrote: > > Hi, > > > > On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: > >> Hi all, > >> > >> This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera > >> host interface. My intention was to create a V4L2 driver that would > >> work > >> with standard applications like Gstreamer or mplayer, and yet exposing > >> possibly all features available in the hardware. > >> > >> It took me several weeks to do this work in my (limited) spare time. > >> Finally I've got something that is functional and I think might be > >> useful for others, so I'm publishing this initial version. It > >> hopefully doesn't need much tweaking or corrections, at least as far > >> as S3C244X is concerned. It has not been tested on S3C64XX SoCs, as I > >> don't have the hardware. However, the driver has been designed with > >> covering S3C64XX as well in mind, and I've already taken care of some > >> differences between S3C2444X and S3C64XX. Mem-to-mem features are not > >> yet supported, but these are quite separate issue and could be easily > >> added as a next step.> > > I will try to test it on S3C6410 in some reasonably near future and > > report any needed corrections. > > Sounds great, thanks. I have not tested the driver yet, but I am looking through the code and it seems like S3C6410 (at least according to the documentation) supports far more pixel formats than defined in the driver. Both preview and scaler paths are supposed to support 420/422 planar, 422 interleaved and 565/666/888 formats. Also two distinct planar 420 formats exist that simply differ by plane order YUV420 (currently supported in your driver) and YVU420 (with Cb and Cr planes swapped). It should be pretty straightforward to add support for the latter. Best regards, Tomasz Figa > > > Currently I am using a modified s5p-fimc driver in my project, but it > > supports only the codec path of S3C64xx and any needed stream > > duplication and rescaling is done in later processing, so it might be > > wise to migrate to yours. > > Yeah, the s3c camif is quite different from the s5p one. Thus the > s3c-camif driver might be a much better starting point for S3C6410. I > could test any changes for s3c6410 back on s3c2440 and incorporate the > verified ones into some common stable git branch. > > -- > > Regards, > Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Aug 11 19:00:28 CEST 2012 git hash:1240ad56edfdd9ccc70d9cbce6da7d5d939d5e83 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] [media] iguanair: Fix return value on transmit
On Fri, Aug 10, 2012 at 08:28:03PM +0100, Sean Young wrote: > Transmit returned 0 after sending and failed to send anything if the amount > exceeded its buffer size. Also fix some minor errors. > > Signed-off-by: Sean Young I'm sorry, this patch series wasn't diffed against the right tree, so it won't apply. I'll need to rediff and retest. In the mean time any review comments would be appreciated. Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter wrote: >> >> + >> >> +/** >> >> + * dma_fence_wait - wait for a fence to be signaled >> >> + * >> >> + * @fence: [in]The fence to wait on >> >> + * @intr:[in]if true, do an interruptible wait >> >> + * @timeout: [in]absolute time for timeout, in jiffies. >> > >> > I don't quite like this, I think we should keep the styl of all other >> > wait_*_timeout functions and pass the arg as timeout in jiffies (and also >> > the same return semantics). Otherwise well have funny code that needs to >> > handle return values differently depending upon whether it waits upon a >> > dma_fence or a native object (where it would us the wait_*_timeout >> > functions directly). >> >> We did start out this way, but there was an ugly jiffies roll-over >> problem that was difficult to deal with properly. Using an absolute >> time avoided the problem. > > Well, as-is the api works differently than all the other _timeout apis > I've seen in the kernel, which makes it confusing. Also, I don't quite see > what jiffies wraparound issue there is? iirc, the problem was in dmabufmgr, in dmabufmgr_wait_completed_cpu().. with an absolute timeout, it could loop over all the fences without having to adjust the timeout for the elapsed time. Otherwise it had to adjust the timeout and keep track of when the timeout elapsed without confusing itself via rollover. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] nec-decoder: fix NEC decoding for Pioneer Laserdisc CU-700 remote
Em 31-07-2012 07:37, Sean Young escreveu:
> This remote sends a header pulse of 8150us followed by a space of 4000us.
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/ir-nec-decoder.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/rc/ir-nec-decoder.c
> b/drivers/media/rc/ir-nec-decoder.c
> index 3c9431a..2ca509e 100644
> --- a/drivers/media/rc/ir-nec-decoder.c
> +++ b/drivers/media/rc/ir-nec-decoder.c
> @@ -70,7 +70,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
> ir_raw_event ev)
> if (!ev.pulse)
> break;
>
> - if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2)) {
> + if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT * 2)) {
> data->is_nec_x = false;
> data->necx_repeat = false;
> } else if (eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT /
> 2))
> @@ -86,7 +86,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
> ir_raw_event ev)
> if (ev.pulse)
> break;
>
> - if (eq_margin(ev.duration, NEC_HEADER_SPACE, NEC_UNIT / 2)) {
> + if (eq_margin(ev.duration, NEC_HEADER_SPACE, NEC_UNIT)) {
> data->state = STATE_BIT_PULSE;
> return 0;
> } else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT /
> 2)) {
>
The timings above are adjusted for 9000us/4500us, with a tolerance of 281,250us.
You're changing the pulse tolerance to 1125us for pulse, and 562,5us for space.
I double-checked: this shouldn't interfere with the other decoders, so it could
be possible to apply it, without causing regressions.
I'll apply it.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] winbond-cir: Fix initialization
Hi David,
Em 31-07-2012 07:37, Sean Young escreveu:
> The serial driver will detect the winbond cir device as a serial port,
> since it looks exactly like a serial port unless you know what it is
> from the PNP ID.
>
> Winbond CIR 00:04: Region 0x2f8-0x2ff already in use!
> Winbond CIR 00:04: disabled
> Winbond CIR: probe of 00:04 failed with error -16
Please review this patch.
>
> Signed-off-by: Sean Young
> ---
> drivers/media/rc/winbond-cir.c | 21 -
> drivers/tty/serial/8250/8250.c | 1 +
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
> index 54ee348..20a0bbb 100644
> --- a/drivers/media/rc/winbond-cir.c
> +++ b/drivers/media/rc/winbond-cir.c
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define DRVNAME "winbond-cir"
> @@ -957,6 +958,7 @@ wbcir_probe(struct pnp_dev *device, const struct
> pnp_device_id *dev_id)
> struct device *dev = &device->dev;
> struct wbcir_data *data;
> int err;
> + struct resource *io;
>
> if (!(pnp_port_len(device, 0) == EHFUNC_IOMEM_LEN &&
> pnp_port_len(device, 1) == WAKEUP_IOMEM_LEN &&
> @@ -1049,7 +1051,24 @@ wbcir_probe(struct pnp_dev *device, const struct
> pnp_device_id *dev_id)
> goto exit_release_wbase;
> }
>
> - if (!request_region(data->sbase, SP_IOMEM_LEN, DRVNAME)) {
> + io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> +
> + /*
> + * The winbond cir device looks exactly like an NS16550A serial port
> + * unless you know what it is. We've got here via the PNP ID.
> + */
> +#ifdef CONFIG_SERIAL_8250
> + if (!io) {
> + struct uart_port port = { .iobase = data->sbase };
> + int line = serial8250_find_port(&port);
> + if (line >= 0) {
> + serial8250_unregister_port(line);
Hmm... Not sure if it makes sense, but perhaps the unregistering code
should be reverting serial8250_unregister_port(line).
> +
> + io = request_region(data->sbase, SP_IOMEM_LEN, DRVNAME);
> + }
> + }
> +#endif
> + if (!io) {
> dev_err(dev, "Region 0x%lx-0x%lx already in use!\n",
> data->sbase, data->sbase + SP_IOMEM_LEN - 1);
> err = -EBUSY;
> diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
> index 5c27f7e..d38615f 100644
> --- a/drivers/tty/serial/8250/8250.c
> +++ b/drivers/tty/serial/8250/8250.c
> @@ -2914,6 +2914,7 @@ int serial8250_find_port(struct uart_port *p)
> }
> return -ENODEV;
> }
> +EXPORT_SYMBOL(serial8250_find_port);
>
> #define SERIAL8250_CONSOLE &serial8250_console
> #else
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Sat, Aug 11, 2012 at 06:00:46PM +0200, Maarten Lankhorst wrote:
> Op 11-08-12 17:14, Rob Clark schreef:
> > On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> >>> +/**
> >>> + * dma_fence_signal - signal completion of a fence
> >>> + * @fence: the fence to signal
> >>> + *
> >>> + * All registered callbacks will be called directly (synchronously) and
> >>> + * all blocked waters will be awoken. This should be always be called on
> >>> + * software only fences, or alternatively be called after
> >>> + * dma_fence_ops::enable_signaling is called.
> >> I think we need to be cleare here when dma_fence_signal can be called:
> >> - for a sw-only fence (i.e. created with dma_fence_create)
> >> dma_fence_signal _must_ be called under all circumstances.
> >> - for any other fences, dma_fence_signal may be called, but it _must_ be
> >> called once the ->enable_signalling func has been called and return 0
> >> (i.e. success).
> >> - it may be called only _once_.
>
> As we discussed on irc it might be beneficial to be able to have it called
> twice, the second time would be a noop, however.
Agreed.
[snip]
> >>> + /* At this point, if enable_signaling returns any error
> >>> + * a wakeup has to be performanced regardless.
> >>> + * -ENOENT signals fence was already signaled. Any other
> >>> error
> >>> + * inidicates a catastrophic hardware error.
> >>> + *
> >>> + * If any hardware error occurs, nothing can be done against
> >>> + * it, so it's treated like the fence was already signaled.
> >>> + * No synchronization can be performed, so we have to assume
> >>> + * the fence was already signaled.
> >>> + */
> >>> + ret = fence->ops->enable_signaling(fence);
> >>> + if (ret) {
> >>> + signaled = true;
> >>> + dma_fence_signal(fence);
> >> I think we should call dma_fence_signal only for -ENOENT and pass all
> >> other errors back as-is. E.g. on -ENOMEM or so we might want to retry ...
>
> Also discussed on irc, boolean might be a better solution until we start
> dealing with
> hardware on fire. :) This would however likely be dealt in the same way as
> signaling,
> however.
Agreed.
[snip]
> >>> +
> >>> + if (!ret) {
> >>> + cb->base.flags = 0;
> >>> + cb->base.func = __dma_fence_wake_func;
> >>> + cb->base.private = priv;
> >>> + cb->fence = fence;
> >>> + cb->func = func;
> >>> + __add_wait_queue(&fence->event_queue, &cb->base);
> >>> + }
> >>> + spin_unlock_irqrestore(&fence->event_queue.lock, flags);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(dma_fence_add_callback);
> >> I think for api completenes we should also have a
> >> dma_fence_remove_callback function.
> > We did originally but Maarten found it was difficult to deal with
> > properly when the gpu's hang. I think his alternative was just to
> > require the hung driver to signal the fence. I had kicked around the
> > idea of a dma_fence_cancel() alternative to signal that could pass an
> > error thru to the waiting driver.. although not sure if the other
> > driver could really do anything differently at that point.
>
> No, there is a very real reason I removed dma_fence_remove_callback. It is
> absolutely non-trivial to cancel it once added, since you have to deal with
> all kinds of race conditions.. See i915_gem_reset_requests in my git tree:
> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=673c4b2550bc63ec134bca47a95dabd617a689ce
I don't see the point in that code ... Why can't we drop the kref
_outside_ of the critical section protected by event_queue_lock? Then you
pretty much have an open-coded version of dma_fence_callback_cancel in
there.
> This is the only way to do it completely deadlock/memory corruption free
> since you essentially have a locking inversion to avoid. I had it wrong
> the first 2 times too, even when I knew about a lot of the locking
> complications. If you want to do it, in most cases it will likely be easier
> to just eat the signal and ignore it instead of canceling.
>
> >>> +
> >>> +/**
> >>> + * dma_fence_wait - wait for a fence to be signaled
> >>> + *
> >>> + * @fence: [in]The fence to wait on
> >>> + * @intr:[in]if true, do an interruptible wait
> >>> + * @timeout: [in]absolute time for timeout, in jiffies.
> >> I don't quite like this, I think we should keep the styl of all other
> >> wait_*_timeout functions and pass the arg as timeout in jiffies (and also
> >> the same return semantics). Otherwise well have funny code that needs to
> >> handle return values differently depending upon whether it waits upon a
> >> dma_fence or a native object (where it would us the wait_*_timeout
> >> functions directly).
> > We did start out this way, but there was an ugly jiffies roll
Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
On 08/11/2012 08:39 PM, Tomasz Figa wrote: > Hi, > > On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote: >> Hi all, >> >> This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera >> host interface. My intention was to create a V4L2 driver that would work >> with standard applications like Gstreamer or mplayer, and yet exposing >> possibly all features available in the hardware. >> >> It took me several weeks to do this work in my (limited) spare time. >> Finally I've got something that is functional and I think might be useful >> for others, so I'm publishing this initial version. It hopefully doesn't >> need much tweaking or corrections, at least as far as S3C244X is >> concerned. It has not been tested on S3C64XX SoCs, as I don't have the >> hardware. However, the driver has been designed with covering S3C64XX as >> well in mind, and I've already taken care of some differences between >> S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but >> these are quite separate issue and could be easily added as a next step. > > I will try to test it on S3C6410 in some reasonably near future and report > any needed corrections. Sounds great, thanks. > Currently I am using a modified s5p-fimc driver in my project, but it > supports only the codec path of S3C64xx and any needed stream duplication > and rescaling is done in later processing, so it might be wise to migrate > to yours. Yeah, the s3c camif is quite different from the s5p one. Thus the s3c-camif driver might be a much better starting point for S3C6410. I could test any changes for s3c6410 back on s3c2440 and incorporate the verified ones into some common stable git branch. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Sat, Aug 11, 2012 at 10:14:40AM -0500, Rob Clark wrote:
> On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> > On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> >> +
> >> + if (!ret) {
> >> + cb->base.flags = 0;
> >> + cb->base.func = __dma_fence_wake_func;
> >> + cb->base.private = priv;
> >> + cb->fence = fence;
> >> + cb->func = func;
> >> + __add_wait_queue(&fence->event_queue, &cb->base);
> >> + }
> >> + spin_unlock_irqrestore(&fence->event_queue.lock, flags);
> >> +
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_fence_add_callback);
> >
> > I think for api completenes we should also have a
> > dma_fence_remove_callback function.
>
> We did originally but Maarten found it was difficult to deal with
> properly when the gpu's hang. I think his alternative was just to
> require the hung driver to signal the fence. I had kicked around the
> idea of a dma_fence_cancel() alternative to signal that could pass an
> error thru to the waiting driver.. although not sure if the other
> driver could really do anything differently at that point.
Well, the idea is not to cancel all callbacks, but just a single one, in
case a driver wants to somehow abort the wait. E.g. when the own gpu dies
I guess we should clear all these fence callbacks so that they can't
clobber the hw state after the reset.
> >> +
> >> +/**
> >> + * dma_fence_wait - wait for a fence to be signaled
> >> + *
> >> + * @fence: [in]The fence to wait on
> >> + * @intr:[in]if true, do an interruptible wait
> >> + * @timeout: [in]absolute time for timeout, in jiffies.
> >
> > I don't quite like this, I think we should keep the styl of all other
> > wait_*_timeout functions and pass the arg as timeout in jiffies (and also
> > the same return semantics). Otherwise well have funny code that needs to
> > handle return values differently depending upon whether it waits upon a
> > dma_fence or a native object (where it would us the wait_*_timeout
> > functions directly).
>
> We did start out this way, but there was an ugly jiffies roll-over
> problem that was difficult to deal with properly. Using an absolute
> time avoided the problem.
Well, as-is the api works differently than all the other _timeout apis
I've seen in the kernel, which makes it confusing. Also, I don't quite see
what jiffies wraparound issue there is?
> > Also, I think we should add the non-_timeout variants, too, just for
> > completeness.
This request here has the same reasons, essentially: If we offer a
dma_fence wait api that matches the usual wait apis closely, it's harder
to get their usage wrong. I know that i915 has some major cludge for a
wait_seqno interface internally, but that's no reason to copy that
approach ;-)
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.6-rc1] Mediabus And Pixel format supported by DM365
Em 06-08-2012 06:36, Prabhakar Lad escreveu: > Hi Mauro, > > Sorry, the subject of course should have been "GIT PULL FOR v3.7" Hi Prabhakar, Please only send patches for the API together with the drivers that require it, e. g. with dm365 patches. Thanks! Mauro > > Thx, > --Prabhakar > > On Monday 06 August 2012 12:45 PM, Prabhakar Lad wrote: >> Hi Mauro, >> >> Can you please pull the following patches, which add medibus and pixel >> format supported by DM365. >> >> Thanks and Regards, >> --Prabhakar Lad >> >> >> The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: >> >> Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) >> >> are available in the git repository at: >> git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git mc_dm365_mbus_fmt >> >> Manjunath Hadli (2): >> media: add new mediabus format enums for dm365 >> v4l2: add new pixel formats supported on dm365 >> >> .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++ >> Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + >> Documentation/DocBook/media/v4l/pixfmt.xml |2 + >> Documentation/DocBook/media/v4l/subdev-formats.xml | 250 >> +++- >> include/linux/v4l2-mediabus.h | 10 +- >> include/linux/videodev2.h |8 + >> 6 files changed, 358 insertions(+), 8 deletions(-) >> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml >> create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml >> ___ >> Davinci-linux-open-source mailing list >> davinci-linux-open-sou...@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
Hi,
On Saturday 11 of August 2012 20:06:13 Sylwester Nawrocki wrote:
> Hi all,
>
> This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera
> host interface. My intention was to create a V4L2 driver that would work
> with standard applications like Gstreamer or mplayer, and yet exposing
> possibly all features available in the hardware.
>
> It took me several weeks to do this work in my (limited) spare time.
> Finally I've got something that is functional and I think might be useful
> for others, so I'm publishing this initial version. It hopefully doesn't
> need much tweaking or corrections, at least as far as S3C244X is
> concerned. It has not been tested on S3C64XX SoCs, as I don't have the
> hardware. However, the driver has been designed with covering S3C64XX as
> well in mind, and I've already taken care of some differences between
> S3C2444X and S3C64XX. Mem-to-mem features are not yet supported, but
> these are quite separate issue and could be easily added as a next step.
I will try to test it on S3C6410 in some reasonably near future and report
any needed corrections.
Currently I am using a modified s5p-fimc driver in my project, but it
supports only the codec path of S3C64xx and any needed stream duplication
and rescaling is done in later processing, so it might be wise to migrate
to yours.
Best regards,
Tomasz Figa
> The patch to follow only adds the CAMIF driver, the other two required
> for the camera on Mini2440 board to work (OV9650 sensor driver and the
> board file patch) can be found in branch s3c-camif-v3.5 in git
> repository:
>
> git://github.com/snawrocki/linux.git
>
> Gitweb: https://github.com/snawrocki/linux/commits/s3c-camif-v3.5
>
> These patches are based off of stable v3.5 kernel.
>
> The S3C-CAMIF driver exposes one v4l2 subdev and two capture video nodes
> - for the "codec" and "preview" data paths. For minimum functionality
> there is no need to touch the subdev device node in user space. However
> it is recommended for best results.
>
> For my tests I used nice Mini2440 BSP from Pengutronix, which already
> contains various applications, like Gstreamer, v4l2-ctl or even
> media-ctl. It's available at
> http://www.pengutronix.de/oselas/bsp/pengutronix/index_en.html.
>
> I've tested the driver with mplayer and Gstreamer, also simultaneous
> capture from the "preview" and "codec" video nodes. The codec path
> camera preview at framebuffer can be started, for example, with
> following command:
>
> # gst-launch v4l2src device=/dev/video0 !
> video/x-raw-yuv,width=320,height= 240 ! ffmpegcolorspace ! fbdevsink
>
> In order to select the preview video node (which supports only RGB pixel
> formats) /dev/video0 need to be replaced with /dev/video1, e.g.
>
> # gst-launch v4l2src device=/dev/video1 !
> video/x-raw-rgb,bpp=32,endianness= 4321,depth=32,width=320,height=240 !
> ffmpegcolorspace ! fbdevsink
>
> In this case I'm getting slightly incorrect color representation, still
> need to figure out why this happens.
>
> The supported pixel formats are listed in the attached
> supported_pixel_formats.txt file.
>
> The camera test pattern is exposed through a private control at the
> subdev node, all supported controls are listed in attached
> supported_controls.txt file. The test pattern can be enabled e.g. with
> command:
>
> # v4l2-ctl -d /dev/v4l-subdev1 --set-ctrl=test_pattern=1
>
>
> A note about the driver's internals
>
> The S3C-CAMIF driver sets at the camera input ("catchcam") (default)
> pixel format as retrieved from the sensor subdev. This happens during
> driver's initialization, so there is no need to touch the subdev in user
> space to capture video from the camera. If pixel resolution selected at
> /dev/video? differs from the one set at camera input (S3C-CAMIF subdev
> pad 0), the image frames will be resized accordingly, taking into
> account the resizer's capabilities.
>
> To change pixel format at the sensor subdev and the camif input, so those
> better match our target capture resolution, following commands can be
> used:
>
> media-ctl --set-v4l2 '"OV9650":0 [fmt: YUYV2X8/640x640]'
> media-ctl --set-v4l2 '"S3C-CAMIF":0 [fmt: YUYV2X8/640x640]'
>
> The only requirement is that these formats are same, otherwise it won't
> be possible to start streaming and VIDIOC_STREAMON will fail wit -EPIPE
> errno.
>
> The video node numbering might be different, if there are other V4L2
> drivers in the system. It can be easily checked with media-ctl utility
> (media-ctl -p), my configuration was as in attached camif_media_info.txt
> log.
>
> I've run v4l2-compliance on both video nodes, the results can be found in
> file v4l2_compliance_log.txt.
>
> A graph depicting device topology can be generated from attached
> camif_graph.dot file (which was created with 'media-ctl --print-dot'),
> with following command:
>
> # cat camif_graph.dot | dot -Tpdf > camif_graph.pdf
> # evince camif_graph.pdf
>
> There is still some more work need
[PATCH 0/2] media: Replace easycap driver with stk1160
Hi! Here's the stk1160 inclusion patch, splitted as two patches (easycap removal and stk1160 add) as requested by Mauro. I'd like to thanks Hans, Sylwester, Takashi and Mauro (and everyone else) for their reviewing and their help. Regards, Ezequiel. Ezequiel Garcia (2): staging: media: Remove easycap driver media: Add stk1160 new driver (easycap replacement) drivers/media/video/Kconfig |2 + drivers/media/video/Makefile |1 + drivers/media/video/stk1160/Kconfig | 20 + drivers/media/video/stk1160/Makefile | 11 + drivers/media/video/stk1160/stk1160-ac97.c | 153 + drivers/media/video/stk1160/stk1160-core.c | 432 +++ drivers/media/video/stk1160/stk1160-i2c.c| 294 ++ drivers/media/video/stk1160/stk1160-reg.h| 93 + drivers/media/video/stk1160/stk1160-v4l.c| 738 drivers/media/video/stk1160/stk1160-video.c | 518 +++ drivers/media/video/stk1160/stk1160.h| 208 ++ drivers/staging/media/Kconfig|2 - drivers/staging/media/Makefile |1 - drivers/staging/media/easycap/Kconfig| 30 - drivers/staging/media/easycap/Makefile | 10 - drivers/staging/media/easycap/README | 141 - drivers/staging/media/easycap/easycap.h | 567 --- drivers/staging/media/easycap/easycap_ioctl.c| 2443 - drivers/staging/media/easycap/easycap_low.c | 968 - drivers/staging/media/easycap/easycap_main.c | 4239 -- drivers/staging/media/easycap/easycap_settings.c | 696 drivers/staging/media/easycap/easycap_sound.c| 750 drivers/staging/media/easycap/easycap_testcard.c | 155 - 23 files changed, 2470 insertions(+), 10002 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] S3C244X/S3C64XX SoC camera host interface driver
Hi all,
This patch adds a driver for Samsung S3C244X/S3C64XX SoC series camera host
interface. My intention was to create a V4L2 driver that would work with
standard applications like Gstreamer or mplayer, and yet exposing possibly
all features available in the hardware.
It took me several weeks to do this work in my (limited) spare time.
Finally I've got something that is functional and I think might be useful
for others, so I'm publishing this initial version. It hopefully doesn't
need much tweaking or corrections, at least as far as S3C244X is concerned.
It has not been tested on S3C64XX SoCs, as I don't have the hardware.
However, the driver has been designed with covering S3C64XX as well in mind,
and I've already taken care of some differences between S3C2444X and S3C64XX.
Mem-to-mem features are not yet supported, but these are quite separate
issue and could be easily added as a next step.
The patch to follow only adds the CAMIF driver, the other two required for
the camera on Mini2440 board to work (OV9650 sensor driver and the board
file patch) can be found in branch s3c-camif-v3.5 in git repository:
git://github.com/snawrocki/linux.git
Gitweb: https://github.com/snawrocki/linux/commits/s3c-camif-v3.5
These patches are based off of stable v3.5 kernel.
The S3C-CAMIF driver exposes one v4l2 subdev and two capture video nodes
- for the "codec" and "preview" data paths. For minimum functionality
there is no need to touch the subdev device node in user space. However it
is recommended for best results.
For my tests I used nice Mini2440 BSP from Pengutronix, which already contains
various applications, like Gstreamer, v4l2-ctl or even media-ctl. It's
available at http://www.pengutronix.de/oselas/bsp/pengutronix/index_en.html.
I've tested the driver with mplayer and Gstreamer, also simultaneous capture
from the "preview" and "codec" video nodes. The codec path camera preview at
framebuffer can be started, for example, with following command:
# gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height=
240 ! ffmpegcolorspace ! fbdevsink
In order to select the preview video node (which supports only RGB pixel
formats) /dev/video0 need to be replaced with /dev/video1, e.g.
# gst-launch v4l2src device=/dev/video1 ! video/x-raw-rgb,bpp=32,endianness=
4321,depth=32,width=320,height=240 ! ffmpegcolorspace ! fbdevsink
In this case I'm getting slightly incorrect color representation, still need
to figure out why this happens.
The supported pixel formats are listed in the attached
supported_pixel_formats.txt file.
The camera test pattern is exposed through a private control at the subdev
node, all supported controls are listed in attached supported_controls.txt
file. The test pattern can be enabled e.g. with command:
# v4l2-ctl -d /dev/v4l-subdev1 --set-ctrl=test_pattern=1
A note about the driver's internals
The S3C-CAMIF driver sets at the camera input ("catchcam") (default) pixel
format as retrieved from the sensor subdev. This happens during driver's
initialization, so there is no need to touch the subdev in user space to
capture video from the camera. If pixel resolution selected at /dev/video?
differs from the one set at camera input (S3C-CAMIF subdev pad 0), the
image frames will be resized accordingly, taking into account the resizer's
capabilities.
To change pixel format at the sensor subdev and the camif input, so those
better match our target capture resolution, following commands can be used:
media-ctl --set-v4l2 '"OV9650":0 [fmt: YUYV2X8/640x640]'
media-ctl --set-v4l2 '"S3C-CAMIF":0 [fmt: YUYV2X8/640x640]'
The only requirement is that these formats are same, otherwise it won't be
possible to start streaming and VIDIOC_STREAMON will fail wit -EPIPE errno.
The video node numbering might be different, if there are other V4L2
drivers in the system. It can be easily checked with media-ctl utility
(media-ctl -p), my configuration was as in attached camif_media_info.txt
log.
I've run v4l2-compliance on both video nodes, the results can be found in
file v4l2_compliance_log.txt.
A graph depicting device topology can be generated from attached
camif_graph.dot file (which was created with 'media-ctl --print-dot'),
with following command:
# cat camif_graph.dot | dot -Tpdf > camif_graph.pdf
# evince camif_graph.pdf
There is still some more work needed to make the OV9650 sensor driver ready
for the mainline, I'm planning to take care of it in near future. As for
the CAMIF driver, I might try to push it upstream if it doesn't take too
much of my time and there is enough interest from the users side.
Feature requests or bug reports are welcome.
Regards,
Sylwester
---
Sylwester Nawrocki (1):
V4L: Add driver for S3C244X/S3C64XX SoC series camera interface
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile |1 +
drivers/media/video/s3c-camif/Makefile|5 +
drivers/media/v
Re: [Linaro-mm-sig] [PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2)
Op 10-08-12 21:57, Daniel Vetter schreef:
> On Fri, Aug 10, 2012 at 04:57:58PM +0200, Maarten Lankhorst wrote:
>> This type of fence can be used with hardware synchronization for simple
>> hardware that can block execution until the condition
>> (dma_buf[offset] - value) >= 0 has been met.
>>
>> A software fallback still has to be provided in case the fence is used
>> with a device that doesn't support this mechanism. It is useful to expose
>> this for graphics cards that have an op to support this.
>>
>> Some cards like i915 can export those, but don't have an option to wait,
>> so they need the software fallback.
>>
>> I extended the original patch by Rob Clark.
>>
>> v1: Original
>> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
>> not much was left of the file. Lots of documentation added.
>>
>> Signed-off-by: Maarten Lankhorst
> Patch looks good, two bikesheds inline. Either way
> Reviewed-by: Daniel Vetter
>
>> ---
>> drivers/base/dma-fence.c | 21 +++
>> include/linux/dma-fence.h | 61
>> +
>> 2 files changed, 82 insertions(+)
>>
>> diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
>> index 93448e4..4092a58 100644
>> --- a/drivers/base/dma-fence.c
>> +++ b/drivers/base/dma-fence.c
>> @@ -266,3 +266,24 @@ struct dma_fence *dma_fence_create(void *priv)
>> return fence;
>> }
>> EXPORT_SYMBOL_GPL(dma_fence_create);
>> +
>> +static int seqno_enable_signaling(struct dma_fence *fence)
>> +{
>> +struct dma_seqno_fence *seqno_fence = to_seqno_fence(fence);
>> +return seqno_fence->enable_signaling(seqno_fence);
>> +}
>> +
>> +static void seqno_release(struct dma_fence *fence)
>> +{
>> +struct dma_seqno_fence *f = to_seqno_fence(fence);
>> +
>> +if (f->release)
>> +f->release(f);
>> +dma_buf_put(f->sync_buf);
>> +}
>> +
>> +const struct dma_fence_ops dma_seqno_fence_ops = {
>> +.enable_signaling = seqno_enable_signaling,
>> +.release = seqno_release
>> +};
>> +EXPORT_SYMBOL_GPL(dma_seqno_fence_ops);
>> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
>> index e0ceddd..3ef0da0 100644
>> --- a/include/linux/dma-fence.h
>> +++ b/include/linux/dma-fence.h
>> @@ -91,6 +91,19 @@ struct dma_fence_ops {
>> void (*release)(struct dma_fence *fence);
>> };
>>
>> +struct dma_seqno_fence {
>> +struct dma_fence base;
>> +
>> +struct dma_buf *sync_buf;
>> +uint32_t seqno_ofs;
>> +uint32_t seqno;
>> +
>> +int (*enable_signaling)(struct dma_seqno_fence *fence);
>> +void (*release)(struct dma_seqno_fence *fence);
> I think using dma_fence_ops here is the better color. We lose type-safety
> at compile-time, but still keep type-safety at runtime (thanks to
> to_dma_seqno_fence). In addition people seem to like to constify function
> pointers, we'd save a pointer and if we extend the sw dma_fence interface.
Ok, will change.
>> +};
>> +
>> +extern const struct dma_fence_ops dma_seqno_fence_ops;
>> +
>> struct dma_fence *dma_fence_create(void *priv);
>>
>> /**
>> @@ -121,4 +134,52 @@ int dma_fence_wait(struct dma_fence *fence, bool intr,
>> unsigned long timeout);
>> int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
>> dma_fence_func_t func, void *priv);
>>
>> +/**
>> + * to_seqno_fence - cast a dma_fence to a dma_seqno_fence
>> + * @fence: dma_fence to cast to a dma_seqno_fence
>> + *
>> + * Returns NULL if the dma_fence is not a dma_seqno_fence,
>> + * or the dma_seqno_fence otherwise.
>> + */
>> +static inline struct dma_seqno_fence *
>> +to_seqno_fence(struct dma_fence *fence)
>> +{
>> +if (fence->ops != &dma_seqno_fence_ops)
>> +return NULL;
>> +return container_of(fence, struct dma_seqno_fence, base);
>> +}
> I think adding an is_dma_seqno_fence would be nice ...
#define is_dma_seqno_fence !!to_dma_seqno_fence
The first thing you would do after finding out it's a seqno fence
is calling to_dma_seqno_fence, otherwise why would you care?
As such the check was pointless and deleted.
My bikeshed, go build your own!
>> +
>> +/**
>> + * dma_seqno_fence_init - initialize a seqno fence
>> + * @fence: dma_seqno_fence to initialize
>> + * @sync_buf: buffer containing the memory location to signal on
>> + * @seqno_ofs: the offset within @sync_buf
>> + * @seqno: the sequence # to signal on
>> + * @priv: value of priv member
>> + * @enable_signaling: callback which is called when some other device is
>> + *waiting for sw notification of fence
>> + * @release: callback called during destruction before object is freed.
>> + *
>> + * This function initializes a struct dma_seqno_fence with passed
>> parameters,
>> + * and takes a reference on sync_buf which is released on fence destruction.
>> + */
>> +static inline void
>> +dma_seqno_fence_init(struct dma_seqno_fence *fence,
>> +struct dma_buf *sync_buf,
>> +uint32_t seqno
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
Hey,
Op 11-08-12 17:14, Rob Clark schreef:
> On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
>> On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
>>> A dma-fence can be attached to a buffer which is being filled or consumed
>>> by hw, to allow userspace to pass the buffer without waiting to another
>>> device. For example, userspace can call page_flip ioctl to display the
>>> next frame of graphics after kicking the GPU but while the GPU is still
>>> rendering. The display device sharing the buffer with the GPU would
>>> attach a callback to get notified when the GPU's rendering-complete IRQ
>>> fires, to update the scan-out address of the display, without having to
>>> wake up userspace.
>>>
>>> A dma-fence is transient, one-shot deal. It is allocated and attached
>>> to one or more dma-buf's. When the one that attached it is done, with
>>> the pending operation, it can signal the fence.
>>>
>>> + dma_fence_signal()
>>>
>>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>>> with a dma-buf.
>>>
>>> TODO maybe need some helper fxn for simple devices, like a display-
>>> only drm/kms device which simply wants to wait for exclusive fence to
>>> be signaled, and then attach a non-exclusive fence while scanout is in
>>> progress.
>>>
>>> The one pending on the fence can add an async callback:
>>> + dma_fence_add_callback()
>>> The callback can optionally be cancelled with remove_wait_queue()
>>>
>>> Or wait synchronously (optionally with timeout or interruptible):
>>> + dma_fence_wait()
>>>
>>> A default software-only implementation is provided, which can be used
>>> by drivers attaching a fence to a buffer when they have no other means
>>> for hw sync. But a memory backed fence is also envisioned, because it
>>> is common that GPU's can write to, or poll on some memory location for
>>> synchronization. For example:
>>>
>>> fence = dma_buf_get_fence(dmabuf);
>>> if (fence->ops == &bikeshed_fence_ops) {
>>> dma_buf *fence_buf;
>>> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
>>> ... tell the hw the memory location to wait on ...
>>> } else {
>>> /* fall-back to sw sync * /
>>> dma_fence_add_callback(fence, my_cb);
>>> }
>>>
>>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>>> between IP blocks, it could be supported as an alternate implementation
>>> with it's own fence ops in a similar way.
>>>
>>> To facilitate other non-sw implementations, the enable_signaling callback
>>> can be used to keep track if a device not supporting hw sync is waiting
>>> on the fence, and in this case should arrange to call dma_fence_signal()
>>> at some point after the condition has changed, to notify other devices
>>> waiting on the fence. If there are no sw waiters, this can be skipped to
>>> avoid waking the CPU unnecessarily. The handler of the enable_signaling
>>> op should take a refcount until the fence is signaled, then release its ref.
>>>
>>> The intention is to provide a userspace interface (presumably via eventfd)
>>> later, to be used in conjunction with dma-buf's mmap support for sw access
>>> to buffers (or for userspace apps that would prefer to do their own
>>> synchronization).
>> I think the commit message should be cleaned up: Kill the TODO, rip out
>> the bikeshed_fence and otherwise update it to the latest code.
Agreed.
>>> v1: Original
>>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>>> that dma-fence didn't need to care about the sw->hw signaling path
>>> (it can be handled same as sw->sw case), and therefore the fence->ops
>>> can be simplified and more handled in the core. So remove the signal,
>>> add_callback, cancel_callback, and wait ops, and replace with a simple
>>> enable_signaling() op which can be used to inform a fence supporting
>>> hw->hw signaling that one or more devices which do not support hw
>>> signaling are waiting (and therefore it should enable an irq or do
>>> whatever is necessary in order that the CPU is notified when the
>>> fence is passed).
>>> v3: Fix locking fail in attach_fence() and get_fence()
>>> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
>>> we decided that we need to be able to attach one fence to N dma-buf's,
>>> so using the list_head in dma-fence struct would be problematic.
>>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and
>>> dma-buf-manager.
>>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
>>> comments
>>> about checking if fence fired or not. This is broken by design.
>>> waitqueue_active during destruction is now fatal, since the signaller
>>> should be holding a reference in enable_signalling until it signalled
>>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>>> in the dma_fence_callback handler, so that no cleanup needs to be
>>> perform
Re: boot slow down
On Wed, Aug 08, 2012 at 01:18:33PM -0400, bjloc...@lockie.ca wrote: > > How hard would it be to get an official kernel option not to load firmware > OR be able to set the timeout? I think the right solution is that the failure of the user space program that is expected to load the firmware is considered as such, so the error could be returned by request_firmware() immediately. There could be reasons why it behaves the way it does currently as I don't know the details. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Fri, Aug 10, 2012 at 2:32 PM, Daniel Vetter wrote: > On Fri, Aug 10, 2012 at 04:57:43PM +0200, Maarten Lankhorst wrote: >> Documentation says that code requiring dma-buf should add it to >> select, so inline fallbacks are not going to be used. A link error >> will make it obvious what went wrong, instead of silently doing >> nothing at runtime. >> >> Signed-off-by: Maarten Lankhorst > > I've botched it more than once to update these when creating new dma-buf > code. Hence > > Reviewed-by: Daniel Vetter yeah, I think the fallbacks date back to when it was a user configurable option, rather than something select'd by drivers using dmabuf, and we just never went back to clean up. Let's drop the fallbacks. Reviewed-by: Rob Clark > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
>> A dma-fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering. The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
>>
>> A dma-fence is transient, one-shot deal. It is allocated and attached
>> to one or more dma-buf's. When the one that attached it is done, with
>> the pending operation, it can signal the fence.
>>
>> + dma_fence_signal()
>>
>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>> with a dma-buf.
>>
>> TODO maybe need some helper fxn for simple devices, like a display-
>> only drm/kms device which simply wants to wait for exclusive fence to
>> be signaled, and then attach a non-exclusive fence while scanout is in
>> progress.
>>
>> The one pending on the fence can add an async callback:
>> + dma_fence_add_callback()
>> The callback can optionally be cancelled with remove_wait_queue()
>>
>> Or wait synchronously (optionally with timeout or interruptible):
>> + dma_fence_wait()
>>
>> A default software-only implementation is provided, which can be used
>> by drivers attaching a fence to a buffer when they have no other means
>> for hw sync. But a memory backed fence is also envisioned, because it
>> is common that GPU's can write to, or poll on some memory location for
>> synchronization. For example:
>>
>> fence = dma_buf_get_fence(dmabuf);
>> if (fence->ops == &bikeshed_fence_ops) {
>> dma_buf *fence_buf;
>> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
>> ... tell the hw the memory location to wait on ...
>> } else {
>> /* fall-back to sw sync * /
>> dma_fence_add_callback(fence, my_cb);
>> }
>>
>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>> between IP blocks, it could be supported as an alternate implementation
>> with it's own fence ops in a similar way.
>>
>> To facilitate other non-sw implementations, the enable_signaling callback
>> can be used to keep track if a device not supporting hw sync is waiting
>> on the fence, and in this case should arrange to call dma_fence_signal()
>> at some point after the condition has changed, to notify other devices
>> waiting on the fence. If there are no sw waiters, this can be skipped to
>> avoid waking the CPU unnecessarily. The handler of the enable_signaling
>> op should take a refcount until the fence is signaled, then release its ref.
>>
>> The intention is to provide a userspace interface (presumably via eventfd)
>> later, to be used in conjunction with dma-buf's mmap support for sw access
>> to buffers (or for userspace apps that would prefer to do their own
>> synchronization).
>
> I think the commit message should be cleaned up: Kill the TODO, rip out
> the bikeshed_fence and otherwise update it to the latest code.
>
>>
>> v1: Original
>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>> that dma-fence didn't need to care about the sw->hw signaling path
>> (it can be handled same as sw->sw case), and therefore the fence->ops
>> can be simplified and more handled in the core. So remove the signal,
>> add_callback, cancel_callback, and wait ops, and replace with a simple
>> enable_signaling() op which can be used to inform a fence supporting
>> hw->hw signaling that one or more devices which do not support hw
>> signaling are waiting (and therefore it should enable an irq or do
>> whatever is necessary in order that the CPU is notified when the
>> fence is passed).
>> v3: Fix locking fail in attach_fence() and get_fence()
>> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
>> we decided that we need to be able to attach one fence to N dma-buf's,
>> so using the list_head in dma-fence struct would be problematic.
>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
>> comments
>> about checking if fence fired or not. This is broken by design.
>> waitqueue_active during destruction is now fatal, since the signaller
>> should be holding a reference in enable_signalling until it signalled
>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>> in the dma_fence_callback handler, so that no cleanup needs to be
>> performed.
>> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
>> fence wasn't signaled yet, for example for hardware fence
[PATCH 2/4] radio-shark*: Call cancel_work_sync from disconnect rather then release
This removes the need for shark_led_work to take the v4l2 lock.
Signed-off-by: Hans de Goede
---
drivers/media/radio/radio-shark.c | 13 ++---
drivers/media/radio/radio-shark2.c | 12 ++--
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index 6117132..05e12bf 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -181,14 +181,6 @@ static void shark_led_work(struct work_struct *work)
container_of(work, struct shark_device, led_work);
int i, res, brightness, actual_len;
- /*
-* We use the v4l2_dev lock and registered bit to ensure the device
-* does not get unplugged and unreffed while we're running.
-*/
- mutex_lock(&shark->tea.mutex);
- if (!video_is_registered(&shark->tea.vd))
- goto leave;
-
for (i = 0; i < 3; i++) {
if (!test_and_clear_bit(i, &shark->brightness_new))
continue;
@@ -208,8 +200,6 @@ static void shark_led_work(struct work_struct *work)
v4l2_err(&shark->v4l2_dev, "set LED %s error: %d\n",
shark->led_names[i], res);
}
-leave:
- mutex_unlock(&shark->tea.mutex);
}
static void shark_led_set_blue(struct led_classdev *led_cdev,
@@ -259,6 +249,8 @@ static void usb_shark_disconnect(struct usb_interface *intf)
for (i = 0; i < NO_LEDS; i++)
led_classdev_unregister(&shark->leds[i]);
+ cancel_work_sync(&shark->led_work);
+
v4l2_device_put(&shark->v4l2_dev);
}
@@ -266,7 +258,6 @@ static void usb_shark_release(struct v4l2_device *v4l2_dev)
{
struct shark_device *shark = v4l2_dev_to_shark(v4l2_dev);
- cancel_work_sync(&shark->led_work);
v4l2_device_unregister(&shark->v4l2_dev);
kfree(shark->transfer_buffer);
kfree(shark);
diff --git a/drivers/media/radio/radio-shark2.c
b/drivers/media/radio/radio-shark2.c
index fc0289d..217483c 100644
--- a/drivers/media/radio/radio-shark2.c
+++ b/drivers/media/radio/radio-shark2.c
@@ -166,13 +166,6 @@ static void shark_led_work(struct work_struct *work)
struct shark_device *shark =
container_of(work, struct shark_device, led_work);
int i, res, brightness, actual_len;
- /*
-* We use the v4l2_dev lock and registered bit to ensure the device
-* does not get unplugged and unreffed while we're running.
-*/
- mutex_lock(&shark->tea.mutex);
- if (!video_is_registered(&shark->tea.vd))
- goto leave;
for (i = 0; i < 2; i++) {
if (!test_and_clear_bit(i, &shark->brightness_new))
@@ -191,8 +184,6 @@ static void shark_led_work(struct work_struct *work)
v4l2_err(&shark->v4l2_dev, "set LED %s error: %d\n",
shark->led_names[i], res);
}
-leave:
- mutex_unlock(&shark->tea.mutex);
}
static void shark_led_set_blue(struct led_classdev *led_cdev,
@@ -231,6 +222,8 @@ static void usb_shark_disconnect(struct usb_interface *intf)
for (i = 0; i < NO_LEDS; i++)
led_classdev_unregister(&shark->leds[i]);
+ cancel_work_sync(&shark->led_work);
+
v4l2_device_put(&shark->v4l2_dev);
}
@@ -238,7 +231,6 @@ static void usb_shark_release(struct v4l2_device *v4l2_dev)
{
struct shark_device *shark = v4l2_dev_to_shark(v4l2_dev);
- cancel_work_sync(&shark->led_work);
v4l2_device_unregister(&shark->v4l2_dev);
kfree(shark->transfer_buffer);
kfree(shark);
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] radio-shark*: Only compile led support when CONFIG_LED_CLA
Hi All, Here is the second revision of my patch-set to fix the build breakage when the radio-shark* drivers are enabled and CONFIG_LED_CLASS is not enabled. This new version introduces 2 new cleanup / preparation patches, and take into account the remarks from Mauro's review of v1. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] radio-shark: Only compile led support when CONFIG_LED_CLASS is set
Signed-off-by: Hans de Goede
---
drivers/media/radio/radio-shark.c | 135 ++
1 file changed, 79 insertions(+), 56 deletions(-)
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index 05e12bf..e1970bf 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -35,6 +35,11 @@
#include
#include
+#if defined(CONFIG_LEDS_CLASS) || \
+(defined(CONFIG_LEDS_CLASS_MODULE) && defined(CONFIG_RADIO_SHARK_MODULE))
+#define SHARK_USE_LEDS 1
+#endif
+
/*
* Version Information
*/
@@ -56,44 +61,18 @@ MODULE_LICENSE("GPL");
enum { BLUE_LED, BLUE_PULSE_LED, RED_LED, NO_LEDS };
-static void shark_led_set_blue(struct led_classdev *led_cdev,
- enum led_brightness value);
-static void shark_led_set_blue_pulse(struct led_classdev *led_cdev,
-enum led_brightness value);
-static void shark_led_set_red(struct led_classdev *led_cdev,
- enum led_brightness value);
-
-static const struct led_classdev shark_led_templates[NO_LEDS] = {
- [BLUE_LED] = {
- .name = "%s:blue:",
- .brightness = LED_OFF,
- .max_brightness = 127,
- .brightness_set = shark_led_set_blue,
- },
- [BLUE_PULSE_LED] = {
- .name = "%s:blue-pulse:",
- .brightness = LED_OFF,
- .max_brightness = 255,
- .brightness_set = shark_led_set_blue_pulse,
- },
- [RED_LED] = {
- .name = "%s:red:",
- .brightness = LED_OFF,
- .max_brightness = 1,
- .brightness_set = shark_led_set_red,
- },
-};
-
struct shark_device {
struct usb_device *usbdev;
struct v4l2_device v4l2_dev;
struct snd_tea575x tea;
+#ifdef SHARK_USE_LEDS
struct work_struct led_work;
struct led_classdev leds[NO_LEDS];
char led_names[NO_LEDS][32];
atomic_t brightness[NO_LEDS];
unsigned long brightness_new;
+#endif
u8 *transfer_buffer;
u32 last_val;
@@ -175,6 +154,7 @@ static struct snd_tea575x_ops shark_tea_ops = {
.read_val = shark_read_val,
};
+#ifdef SHARK_USE_LEDS
static void shark_led_work(struct work_struct *work)
{
struct shark_device *shark =
@@ -235,21 +215,78 @@ static void shark_led_set_red(struct led_classdev
*led_cdev,
schedule_work(&shark->led_work);
}
+static const struct led_classdev shark_led_templates[NO_LEDS] = {
+ [BLUE_LED] = {
+ .name = "%s:blue:",
+ .brightness = LED_OFF,
+ .max_brightness = 127,
+ .brightness_set = shark_led_set_blue,
+ },
+ [BLUE_PULSE_LED] = {
+ .name = "%s:blue-pulse:",
+ .brightness = LED_OFF,
+ .max_brightness = 255,
+ .brightness_set = shark_led_set_blue_pulse,
+ },
+ [RED_LED] = {
+ .name = "%s:red:",
+ .brightness = LED_OFF,
+ .max_brightness = 1,
+ .brightness_set = shark_led_set_red,
+ },
+};
+
+static int shark_register_leds(struct shark_device *shark, struct device *dev)
+{
+ int i, retval;
+
+ INIT_WORK(&shark->led_work, shark_led_work);
+ for (i = 0; i < NO_LEDS; i++) {
+ shark->leds[i] = shark_led_templates[i];
+ snprintf(shark->led_names[i], sizeof(shark->led_names[0]),
+shark->leds[i].name, shark->v4l2_dev.name);
+ shark->leds[i].name = shark->led_names[i];
+ retval = led_classdev_register(dev, &shark->leds[i]);
+ if (retval) {
+ v4l2_err(&shark->v4l2_dev,
+"couldn't register led: %s\n",
+shark->led_names[i]);
+ return retval;
+ }
+ }
+ return 0;
+}
+
+static void shark_unregister_leds(struct shark_device *shark)
+{
+ int i;
+
+ for (i = 0; i < NO_LEDS; i++)
+ led_classdev_unregister(&shark->leds[i]);
+
+ cancel_work_sync(&shark->led_work);
+}
+#else
+static int shark_register_leds(struct shark_device *shark, struct device *dev)
+{
+ v4l2_warn(&shark->v4l2_dev,
+ "CONFIG_LED_CLASS not enabled, LED support disabled\n");
+ return 0;
+}
+static inline void shark_unregister_leds(struct shark_device *shark) { }
+#endif
+
static void usb_shark_disconnect(struct usb_interface *intf)
{
struct v4l2_device *v4l2_dev = usb_get_intfdata(intf);
struct shark_device *shark = v4l2_dev_to_shark(v4l2_dev);
- int i;
mutex_lock(&shark->tea.mutex);
v4l2_device_disconnect(&shark->v4l2_dev);
snd_tea575x_exit(&shark->tea);
[PATCH 4/4] radio-shark2: Only compile led support when CONFIG_LED_CLASS is set
Signed-off-by: Hans de Goede
---
drivers/media/radio/radio-shark2.c | 122 ++---
1 file changed, 73 insertions(+), 49 deletions(-)
diff --git a/drivers/media/radio/radio-shark2.c
b/drivers/media/radio/radio-shark2.c
index 217483c..7b4efdf 100644
--- a/drivers/media/radio/radio-shark2.c
+++ b/drivers/media/radio/radio-shark2.c
@@ -35,6 +35,11 @@
#include
#include "radio-tea5777.h"
+#if defined(CONFIG_LEDS_CLASS) || \
+(defined(CONFIG_LEDS_CLASS_MODULE) && defined(CONFIG_RADIO_SHARK2_MODULE))
+#define SHARK_USE_LEDS 1
+#endif
+
MODULE_AUTHOR("Hans de Goede ");
MODULE_DESCRIPTION("Griffin radioSHARK2, USB radio receiver driver");
MODULE_LICENSE("GPL");
@@ -43,7 +48,6 @@ static int debug;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0-1)");
-
#define SHARK_IN_EP0x83
#define SHARK_OUT_EP 0x05
@@ -54,36 +58,18 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
enum { BLUE_LED, RED_LED, NO_LEDS };
-static void shark_led_set_blue(struct led_classdev *led_cdev,
- enum led_brightness value);
-static void shark_led_set_red(struct led_classdev *led_cdev,
- enum led_brightness value);
-
-static const struct led_classdev shark_led_templates[NO_LEDS] = {
- [BLUE_LED] = {
- .name = "%s:blue:",
- .brightness = LED_OFF,
- .max_brightness = 127,
- .brightness_set = shark_led_set_blue,
- },
- [RED_LED] = {
- .name = "%s:red:",
- .brightness = LED_OFF,
- .max_brightness = 1,
- .brightness_set = shark_led_set_red,
- },
-};
-
struct shark_device {
struct usb_device *usbdev;
struct v4l2_device v4l2_dev;
struct radio_tea5777 tea;
+#ifdef SHARK_USE_LEDS
struct work_struct led_work;
struct led_classdev leds[NO_LEDS];
char led_names[NO_LEDS][32];
atomic_t brightness[NO_LEDS];
unsigned long brightness_new;
+#endif
u8 *transfer_buffer;
};
@@ -161,6 +147,7 @@ static struct radio_tea5777_ops shark_tea_ops = {
.read_reg = shark_read_reg,
};
+#ifdef SHARK_USE_LEDS
static void shark_led_work(struct work_struct *work)
{
struct shark_device *shark =
@@ -208,21 +195,72 @@ static void shark_led_set_red(struct led_classdev
*led_cdev,
schedule_work(&shark->led_work);
}
+static const struct led_classdev shark_led_templates[NO_LEDS] = {
+ [BLUE_LED] = {
+ .name = "%s:blue:",
+ .brightness = LED_OFF,
+ .max_brightness = 127,
+ .brightness_set = shark_led_set_blue,
+ },
+ [RED_LED] = {
+ .name = "%s:red:",
+ .brightness = LED_OFF,
+ .max_brightness = 1,
+ .brightness_set = shark_led_set_red,
+ },
+};
+
+static int shark_register_leds(struct shark_device *shark, struct device *dev)
+{
+ int i, retval;
+
+ INIT_WORK(&shark->led_work, shark_led_work);
+ for (i = 0; i < NO_LEDS; i++) {
+ shark->leds[i] = shark_led_templates[i];
+ snprintf(shark->led_names[i], sizeof(shark->led_names[0]),
+shark->leds[i].name, shark->v4l2_dev.name);
+ shark->leds[i].name = shark->led_names[i];
+ retval = led_classdev_register(dev, &shark->leds[i]);
+ if (retval) {
+ v4l2_err(&shark->v4l2_dev,
+"couldn't register led: %s\n",
+shark->led_names[i]);
+ return retval;
+ }
+ }
+ return 0;
+}
+
+static void shark_unregister_leds(struct shark_device *shark)
+{
+ int i;
+
+ for (i = 0; i < NO_LEDS; i++)
+ led_classdev_unregister(&shark->leds[i]);
+
+ cancel_work_sync(&shark->led_work);
+}
+#else
+static int shark_register_leds(struct shark_device *shark, struct device *dev)
+{
+ v4l2_warn(&shark->v4l2_dev,
+ "CONFIG_LED_CLASS not enabled, LED support disabled\n");
+ return 0;
+}
+static inline void shark_unregister_leds(struct shark_device *shark) { }
+#endif
+
static void usb_shark_disconnect(struct usb_interface *intf)
{
struct v4l2_device *v4l2_dev = usb_get_intfdata(intf);
struct shark_device *shark = v4l2_dev_to_shark(v4l2_dev);
- int i;
mutex_lock(&shark->tea.mutex);
v4l2_device_disconnect(&shark->v4l2_dev);
radio_tea5777_exit(&shark->tea);
mutex_unlock(&shark->tea.mutex);
- for (i = 0; i < NO_LEDS; i++)
- led_classdev_unregister(&shark->leds[i]);
-
- cancel_work_sync(&shark->led_work);
+ shark_unregister_leds(shark);
v4l2_device_put(&shark->v4l2_dev);
}
@@ -240,7 +278,7 @@ static int
[PATCH 1/4] radio-shark*: Remove work-around for dangling pointer in usb intfdata
Recent kernels properly clear the usb intfdata pointer when another driver fails to bind (in the radio-shark* case the usbhid driver would try to bind first. Signed-off-by: Hans de Goede --- drivers/media/radio/radio-shark.c | 9 - drivers/media/radio/radio-shark2.c | 9 - 2 files changed, 18 deletions(-) diff --git a/drivers/media/radio/radio-shark.c b/drivers/media/radio/radio-shark.c index c2ead23..6117132 100644 --- a/drivers/media/radio/radio-shark.c +++ b/drivers/media/radio/radio-shark.c @@ -286,15 +286,6 @@ static int usb_shark_probe(struct usb_interface *intf, if (!shark->transfer_buffer) goto err_alloc_buffer; - /* -* Work around a bug in usbhid/hid-core.c, where it leaves a dangling -* pointer in intfdata causing v4l2-device.c to not set it. Which -* results in usb_shark_disconnect() referencing the dangling pointer -* -* REMOVE (as soon as the above bug is fixed, patch submitted) -*/ - usb_set_intfdata(intf, NULL); - shark->v4l2_dev.release = usb_shark_release; v4l2_device_set_name(&shark->v4l2_dev, DRV_NAME, &shark_instance); retval = v4l2_device_register(&intf->dev, &shark->v4l2_dev); diff --git a/drivers/media/radio/radio-shark2.c b/drivers/media/radio/radio-shark2.c index b9575de..fc0289d 100644 --- a/drivers/media/radio/radio-shark2.c +++ b/drivers/media/radio/radio-shark2.c @@ -258,15 +258,6 @@ static int usb_shark_probe(struct usb_interface *intf, if (!shark->transfer_buffer) goto err_alloc_buffer; - /* -* Work around a bug in usbhid/hid-core.c, where it leaves a dangling -* pointer in intfdata causing v4l2-device.c to not set it. Which -* results in usb_shark_disconnect() referencing the dangling pointer -* -* REMOVE (as soon as the above bug is fixed, patch submitted) -*/ - usb_set_intfdata(intf, NULL); - shark->v4l2_dev.release = usb_shark_release; v4l2_device_set_name(&shark->v4l2_dev, DRV_NAME, &shark_instance); retval = v4l2_device_register(&intf->dev, &shark->v4l2_dev); -- 1.7.11.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] radio-shark: Only compile led support when CONFIG_LED_CLASS is set
Hi,
On 08/10/2012 10:15 PM, Mauro Carvalho Chehab wrote:
Em 10-08-2012 16:58, Hans de Goede escreveu:
Reported-by: Dadiv Rientjes
Signed-off-by: Hans de Goede
---
drivers/media/radio/radio-shark.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index c2ead23..f746ed0 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -27,7 +27,6 @@
#include
#include
-#include
#include
#include
#include
@@ -35,6 +34,12 @@
#include
#include
+#if defined(CONFIG_LEDS_CLASS) || \
+(defined(CONFIG_LEDS_CLASS_MODULE) && defined(CONFIG_RADIO_SHARK_MODULE))
+#include
Conditionally including headers is not a good thing.
Ok, I will make it unconditional then.
...
static void usb_shark_disconnect(struct usb_interface *intf)
{
struct v4l2_device *v4l2_dev = usb_get_intfdata(intf);
struct shark_device *shark = v4l2_dev_to_shark(v4l2_dev);
+#ifdef SHARK_USE_LEDS
int i;
+#endif
mutex_lock(&shark->tea.mutex);
v4l2_device_disconnect(&shark->v4l2_dev);
snd_tea575x_exit(&shark->tea);
mutex_unlock(&shark->tea.mutex);
+#ifdef SHARK_USE_LEDS
for (i = 0; i < NO_LEDS; i++)
led_classdev_unregister(&shark->leds[i]);
+#endif
v4l2_device_put(&shark->v4l2_dev);
}
That looks ugly.
Agreed.
Maybe you could code it on a different way.
You could be move all shark_use_leds together into the same place at
the code, like:
Sounds good, although I will still need to set a SHARK_USE_LEDS define at
the top of the file, to avoid having unused members in struct shark_device, not
that the compiler will complain but having them there for no good reason seems
undesirable.
#if defined(CONFIG_LEDS_CLASS) || \
(defined(CONFIG_LEDS_CLASS_MODULE) && defined(CONFIG_RADIO_SHARK_MODULE))
static void shark_led_set_blue(struct led_classdev *led_cdev,
...
.brightness_set = shark_led_set_red,
},
};
static void shark_led_disconnect(...)
{
...
}
static void shark_led_release(...)
{
...
}
static void shark_led_register(...)
{
...
}
#else
static inline void shark_led_disconnect(...) { };
static inline void shark_led_release(...) { };
static inline void shark_led_register(...)
{
printk(KERN_WARN "radio-shark: CONFIG_LED_CLASS not enabled. LEDs won't
work\n");
}
#endif
And let the rest of the code to call the shark_led functions, as if LEDS aren't
enabled,
the function stubs won't produce any code (well, except for the above error
notice).
The same comment also applies to patch 2.
Ok new versions of the 2 patches coming up (should be there in 2 hours or so, I
want
to both compile and run-time test them both with / without leds).
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
