[PATCH] v4l/s5p-mfc: added support for end of stream handling in MFC encoder
s5p-mfc encoder after receiving V4L2_ENC_CMD_STOP command
will instruct MFC device to release all encoded frames.
After dequeuing last encoded frame driver will generate
V4L2_EVENT_EOS event.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Finally I have found a way to send end-of-stream command to MFC encoder AFTER
the last frame. This way no v4l API change is required.
---
drivers/media/video/s5p-mfc/s5p_mfc.c| 43 +++
drivers/media/video/s5p-mfc/s5p_mfc_common.h |5 +-
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c |8 ++-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|4 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 102 -
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 48 ++---
6 files changed, 174 insertions(+), 36 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index 9bb68e7..d814227 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -19,6 +19,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/videodev2.h
+#include media/v4l2-event.h
#include linux/workqueue.h
#include media/videobuf2-core.h
#include regs-mfc.h
@@ -539,6 +540,40 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx
*ctx,
}
}
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
+unsigned int reason, unsigned int err)
+{
+ struct s5p_mfc_dev *dev = ctx-dev;
+ struct s5p_mfc_buf *mb_entry;
+
+ mfc_debug(2, Stream completed);
+
+ s5p_mfc_clear_int_flags(dev);
+ ctx-int_type = reason;
+ ctx-int_err = err;
+ ctx-state = MFCINST_FINISHED;
+
+ spin_lock(dev-irqlock);
+ if (!list_empty(ctx-dst_queue)) {
+ mb_entry = list_entry(ctx-dst_queue.next, struct s5p_mfc_buf,
+ list);
+ list_del(mb_entry-list);
+ ctx-dst_queue_cnt--;
+ vb2_set_plane_payload(mb_entry-b, 0, 0);
+ vb2_buffer_done(mb_entry-b, VB2_BUF_STATE_DONE);
+ }
+ spin_unlock(dev-irqlock);
+
+ if (ctx-dst_queue_cnt == 0)
+ clear_work_bit(ctx);
+
+ if (test_and_clear_bit(0, dev-hw_lock) == 0)
+ WARN_ON(1);
+
+ s5p_mfc_clock_off();
+ wake_up(ctx-queue);
+}
+
/* Interrupt processing */
static irqreturn_t s5p_mfc_irq(int irq, void *priv)
{
@@ -614,6 +649,11 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
case S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET:
s5p_mfc_handle_init_buffers(ctx, reason, err);
break;
+
+ case S5P_FIMV_R2H_CMD_ENC_COMPLETE_RET:
+ s5p_mfc_handle_stream_complete(ctx, reason, err);
+ break;
+
default:
mfc_debug(2, Unknown int reason\n);
s5p_mfc_clear_int_flags(dev);
@@ -882,9 +922,12 @@ static unsigned int s5p_mfc_poll(struct file *file,
goto end;
}
mutex_unlock(dev-mfc_mutex);
+ poll_wait(file, ctx-fh.wait, wait);
poll_wait(file, src_q-done_wq, wait);
poll_wait(file, dst_q-done_wq, wait);
mutex_lock(dev-mfc_mutex);
+ if (v4l2_event_pending(ctx-fh))
+ rc |= POLLPRI;
spin_lock_irqsave(src_q-done_lock, flags);
if (!list_empty(src_q-done_list))
src_vb = list_first_entry(src_q-done_list, struct vb2_buffer,
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
index bd5706a..8871f0d 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
@@ -146,6 +146,9 @@ enum s5p_mfc_decode_arg {
MFC_DEC_RES_CHANGE,
};
+#define MFC_BUF_FLAG_USED (1 0)
+#define MFC_BUF_FLAG_EOS (1 1)
+
struct s5p_mfc_ctx;
/**
@@ -161,7 +164,7 @@ struct s5p_mfc_buf {
} raw;
size_t stream;
} cookie;
- int used;
+ int flags;
};
/**
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
index 08a5cfe..84c5b8f 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
@@ -78,7 +78,7 @@ int s5p_mfc_alloc_and_load_firmware(struct s5p_mfc_dev *dev)
}
dev-bank1 = s5p_mfc_bitproc_phys;
b_base = vb2_dma_contig_memops.alloc(
- dev-alloc_ctx[MFC_BANK2_ALLOC_CTX], 1
MFC_BANK2_ALIGN_ORDER);
+ dev-alloc_ctx[MFC_BANK2_ALLOC_CTX], 1 MFC_BASE_ALIGN_ORDER);
if (IS_ERR(b_base)) {
vb2_dma_contig_memops.put(s5p_mfc_bitproc_buf);
s5p_mfc_bitproc_phys = 0;
@@ -98,7 +98,11 @@ int s5p_mfc_alloc_and_load_firmware(struct s5p_mfc_dev *dev)
Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Hi Mauro, On Mon, 25 Jun 2012 17:06:28 -0300, Mauro Carvalho Chehab wrote: That's said, IMO, the best approach is to do: 1) add support for asynchronous probe at device core, for devices that requires firmware at probe(). The async_probe() will only be active if !usermodehelper_disabled. 2) export the I2C i2c_lock_adapter()/i2c_unlock_adapter() interface. Both functions are already exported since kernel 2.6.32. However these functions were originally made public for the shared pin case, where two pins can be used for either I2C or something else, and we have to prevent I2C usage when the other function is used. This does not help in your case. What you need additionally is that unlocked flavors of some i2c transfer functions (at least i2c_transfer itself) are exported as well. This isn't necessarily trivial though, as the locking and unlocking are taking place inside i2c_transfer(), not at its boundaries. I'm looking into this now. -- Jean Delvare -- 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 1/2] [media] drxk: Make the QAM demodulator command configurable.
Martin Blumenstingl writes: Currently there are two different commands: the old command which takes 4 parameters, and a newer one with just takes 2 parameters. Hi, are you sure about this? From what I have been told, the 2 parameter command is in the firmware ROM and older loadable/patch firmwares. Newer firmwares provided the 4 parameter command. Regards, Ralph -- 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 7/8] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
On Thu, 28 Jun 2012, Laurent Pinchart wrote:
Hi Guennadi,
Thanks for the review.
On Thursday 21 June 2012 23:15:14 Guennadi Liakhovetski wrote:
On Wed, 23 May 2012, Laurent Pinchart wrote:
-static int soc_camera_power_off(struct soc_camera_device *icd,
- struct soc_camera_link *icl)
+int soc_camera_power_off(struct device *dev, struct soc_camera_link *icl)
{
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int ret = v4l2_subdev_call(sd, core, s_power, 0);
-
- if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV)
- return ret;
+ int ret;
if (icl-power) {
- ret = icl-power(icd-control, 0);
- if (ret 0) {
- dev_err(icd-pdev,
+ ret = icl-power(dev, 0);
+ if (ret 0)
+ dev_err(dev,
Platform failed to power-off the camera.\n);
- return ret;
- }
}
ret = regulator_bulk_disable(icl-num_regulators,
icl-regulators);
This is also a change in behaviour: currently if any of power-off stages
fails we bail out. With this patch you change it to continue with the next
stage. I'm not sure which one is more correct, but at least I wouldn't
silently change it under the counter ;-)
During power off I think it's better to continue to the next stage. Would you
like me to split this to another patch, or to mention it in the commit
message
?
Ok, since this patch is so big and touches so mane other drivers, I think
it'd be cleaner splitting this into a separate patch, preferably - before
this one.
@@ -1070,7 +1076,7 @@ static int soc_camera_probe(struct soc_camera_device
*icd)
* again after initialisation, even though it shouldn't be needed, we
* don't do any IO here.
*/
- ret = soc_camera_power_on(icd, icl);
+ ret = soc_camera_power_on(NULL, icl);
Oops, no good... I think, at least dev_err() et al. don't like being
called with NULL dev... But even without that, I think, this looks so bad,
that it defeats the whole conversion... IIRC, you didn't like keeping the
original soc-camera platform device pointer for icl-power(), because non
soc-camera hosts and platforms don't have that device and would have to
either pass NULL or some other device pointer. Now, we're switching all
icl-power() calls to point to the physical device, which is largely
useless also for soc-camera platforms (they'd have to go back to the
original platform device if they wish to use that pointer at all), all -
except one - in which we pass NULL... So, what's the point? :) I really
would keep the soc-camera platform device pointer for icl-power().
There would be a slight difficulty to get to that pointer in
soc_camera_power_*(). Just passing a subdevice pointer to it and using
v4l2_get_subdev_hostdata(sd) isn't sufficient, because that would only
work in the soc-camera environment. If the same client driver is running
outside of it, v4l2_get_subdev_hostdata(sd) might well point to something
completely different. So, we need a way to distinguish, whether this
client is running on an soc-camera host or not. It is possible to have a
system with two cameras - one connected to the SoC interface and another
one to USB with both sensors using soc-camera services. Only one of them
is associated with an soc-camera device, and another one is not. One way
to distinguish this would be to scan the devices list in soc_camera.c to
see, whether any icd-link == icl. If the client is found - we pass its
platform device pointer to icl-power(). If not - pass NULL. The wrapper
inline function would then become
return soc_camera_s_power(icl, on);
Do you see any problems with this approach?
If I had proposed such a hack I would have sworn you would have rejected it
;-)
Of course, what did you expect? ;-)
My first idea was to get rid of the device pointer completely. None of the
platform callbacks use it. You didn't really like that, as it would make
implementation of a future platform that would require the device pointer
more
complex.
Not only this. Pushing a patch that touches drivers, arch/sh and arch/arm
is something, that doesn't seem to be favoured very highly these days.
You'd need something as ugly as - (1) add a new callback without the
device pointer and convert soc-camera to check-and-call both, (2) port all
platforms to the new one, (3) remove the old one. All this for no
practical gain, especially since they'll be gone soon with DT:-)
I've thus decided to switch to pass the physical struct device
associated with the device to the power functions, down to the board code. I
don't think board code would need to go back to the original platform device
to discriminate between devices, checking the physical device properties
(such
as the I2C
Re: [git:v4l-dvb/for_v3.6] [media] gspca-core: Fix buffers staying in queued state after a stream_off
Hi, On 06/29/2012 07:10 AM, Ben Hutchings wrote: On Mon, 2012-06-11 at 21:06 +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] gspca-core: Fix buffers staying in queued state after a stream_off Author: Hans de Goede hdego...@redhat.com Date:Tue May 22 11:24:05 2012 -0300 This fixes a regression introduced by commit f7059ea and should be backported to all supported stable kernels which have this commit. Signed-off-by: Hans de Goede hdego...@redhat.com Tested-by: Antonio Ospite osp...@studenti.unina.it CC: sta...@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com [...] This surely can't both be so important that it should go into stable updates, yet so unimportant that it can wait for 3.6. You're right. This patch was part of a pull-request titled: [GIT PULL FIXES FOR 3.5]: gspca radio fixes Mauro, as the title of the mail suggested this pull-req contains only fixes, which should really go into 3.5. Esp. The one pointed out by Ben, but for example also the bttv fixes really belong in 3.5 (another user has already independently verified that they fix the radio on his bttv card too). They really are all bug-fixes :) 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] i2c: Export an unlocked flavor of i2c_transfer
Some drivers (in particular for TV cards) need exclusive access to
their I2C buses for specific operations. Export an unlocked flavor
of i2c_transfer to give them full control.
The unlocked flavor has the following limitations:
* Obviously, caller must hold the i2c adapter lock.
* No debug messages are logged. We don't want to log messages while
holding a rt_mutex.
* No check is done on the existence of adap-algo-master_xfer. It
is thus the caller's responsibility to ensure that the function is
OK to call.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
Mauro, would this be OK with you?
drivers/i2c/i2c-core.c | 44 +---
include/linux/i2c.h|3 +++
2 files changed, 36 insertions(+), 11 deletions(-)
--- linux-3.5-rc4.orig/drivers/i2c/i2c-core.c 2012-06-05 16:22:59.0
+0200
+++ linux-3.5-rc4/drivers/i2c/i2c-core.c2012-06-29 12:41:04.707793937
+0200
@@ -1312,6 +1312,37 @@ module_exit(i2c_exit);
*/
/**
+ * __i2c_transfer - unlocked flavor of i2c_transfer
+ * @adap: Handle to I2C bus
+ * @msgs: One or more messages to execute before STOP is issued to
+ * terminate the operation; each message begins with a START.
+ * @num: Number of messages to be executed.
+ *
+ * Returns negative errno, else the number of messages executed.
+ *
+ * Adapter lock must be held when calling this function. No debug logging
+ * takes place. adap-algo-master_xfer existence isn't checked.
+ */
+int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+{
+ unsigned long orig_jiffies;
+ int ret, try;
+
+ /* Retry automatically on arbitration loss */
+ orig_jiffies = jiffies;
+ for (ret = 0, try = 0; try = adap-retries; try++) {
+ ret = adap-algo-master_xfer(adap, msgs, num);
+ if (ret != -EAGAIN)
+ break;
+ if (time_after(jiffies, orig_jiffies + adap-timeout))
+ break;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(__i2c_transfer);
+
+/**
* i2c_transfer - execute a single or combined I2C message
* @adap: Handle to I2C bus
* @msgs: One or more messages to execute before STOP is issued to
@@ -1325,8 +1356,7 @@ module_exit(i2c_exit);
*/
int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
- unsigned long orig_jiffies;
- int ret, try;
+ int ret;
/* REVISIT the fault reporting model here is weak:
*
@@ -1364,15 +1394,7 @@ int i2c_transfer(struct i2c_adapter *ada
i2c_lock_adapter(adap);
}
- /* Retry automatically on arbitration loss */
- orig_jiffies = jiffies;
- for (ret = 0, try = 0; try = adap-retries; try++) {
- ret = adap-algo-master_xfer(adap, msgs, num);
- if (ret != -EAGAIN)
- break;
- if (time_after(jiffies, orig_jiffies + adap-timeout))
- break;
- }
+ ret = __i2c_transfer(adap, msgs, num);
i2c_unlock_adapter(adap);
return ret;
--- linux-3.5-rc4.orig/include/linux/i2c.h 2012-06-05 16:23:05.0
+0200
+++ linux-3.5-rc4/include/linux/i2c.h 2012-06-29 10:29:47.865621249 +0200
@@ -68,6 +68,9 @@ extern int i2c_master_recv(const struct
*/
extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
int num);
+/* Unlocked flavor */
+extern int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
+ int num);
/* This is the very generalized SMBus access routine. You probably do not
want to use this, though; one of the functions below may be much easier,
--
Jean Delvare
--
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: DVB core enhancements - comments please?
Em 29-06-2012 02:03, Antti Palosaari escreveu: On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote: Em 27-06-2012 21:33, Antti Palosaari escreveu: SDR - Softaware Defined Radio support DVB API -- * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461 * there is existing devices that are SDR (RTL2832U rtl-sdr) * SDR is quite near what is digital TV streaming * study what is needed * new delivery system for frontend API called SDR? * some core changes needed, like status (is locked etc) * how about demuxer? * stream conversion, inside Kernel? * what are new parameters needed for DVB API? Let's not mix APIs: the radio control should use the V4L2 API, as this is not DVB. The V4L2 API has already everything needed for radio. The only missing part ther is the audio stream. However, there are a few drivers that provide audio via the radio device node, using read()/poll() syscalls, like pvrusb. On this specific driver, audio comes through a MPEG stream. As SDR provides audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to set/retrieve the type of audio stream, for SDR, but maybe it better to just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that the audio will come though the radio node and if the format is MPEG or SDR. SDR is not a radio in mean of V4L2 analog audio radios. Why not? There's nothing at V4L2 API that limits it to analog, otherwise it couldn't be used by digital cameras. SDR can receive all kind of signals, analog audio, analog television, digital radio, digital television, cellular phones, etc. You can even receive DVB-T, but hardware I have is not capable to receive such wide stream. The V4L2 API has everything to control receivers. What it doesn't have (and it doesn't make sense to have, as such thing would just duplicate existing features at DVB API) are the per delivery-system specific demodulator properties and PID filtering. That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime? Yes. There are lots of drivers that do that. There are even a few that allow to control the frontend and demod via DVB API and to receive streams via V4L2 mmap or read API. 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: DVB core enhancements - comments please?
On 06/29/2012 03:02 PM, Mauro Carvalho Chehab wrote: Em 29-06-2012 02:03, Antti Palosaari escreveu: On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote: Em 27-06-2012 21:33, Antti Palosaari escreveu: SDR - Softaware Defined Radio support DVB API -- * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461 * there is existing devices that are SDR (RTL2832U rtl-sdr) * SDR is quite near what is digital TV streaming * study what is needed * new delivery system for frontend API called SDR? * some core changes needed, like status (is locked etc) * how about demuxer? * stream conversion, inside Kernel? * what are new parameters needed for DVB API? Let's not mix APIs: the radio control should use the V4L2 API, as this is not DVB. The V4L2 API has already everything needed for radio. The only missing part ther is the audio stream. However, there are a few drivers that provide audio via the radio device node, using read()/poll() syscalls, like pvrusb. On this specific driver, audio comes through a MPEG stream. As SDR provides audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to set/retrieve the type of audio stream, for SDR, but maybe it better to just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that the audio will come though the radio node and if the format is MPEG or SDR. SDR is not a radio in mean of V4L2 analog audio radios. Why not? There's nothing at V4L2 API that limits it to analog, otherwise it couldn't be used by digital cameras. SDR can receive all kind of signals, analog audio, analog television, digital radio, digital television, cellular phones, etc. You can even receive DVB-T, but hardware I have is not capable to receive such wide stream. The V4L2 API has everything to control receivers. What it doesn't have (and it doesn't make sense to have, as such thing would just duplicate existing features at DVB API) are the per delivery-system specific demodulator properties and PID filtering. That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime? Yes. There are lots of drivers that do that. There are even a few that allow to control the frontend and demod via DVB API and to receive streams via V4L2 mmap or read API. Could you give closest example? In that case I have RTL2832 DVB-T frontend which I want to change SDR mode. What are the those existing DVB frontend drivers look example. 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: DVB core enhancements - comments please?
On 06/29/2012 02:24 PM, Patrick Boettcher wrote: On Friday 29 June 2012 08:03:16 Antti Palosaari wrote: On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote: Em 27-06-2012 21:33, Antti Palosaari escreveu: SDR - Softaware Defined Radio support DVB API -- * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu re/44461 * there is existing devices that are SDR (RTL2832U rtl-sdr) * SDR is quite near what is digital TV streaming * study what is needed * new delivery system for frontend API called SDR? * some core changes needed, like status (is locked etc) * how about demuxer? * stream conversion, inside Kernel? * what are new parameters needed for DVB API? Let's not mix APIs: the radio control should use the V4L2 API, as this is not DVB. The V4L2 API has already everything needed for radio. The only missing part ther is the audio stream. However, there are a few drivers that provide audio via the radio device node, using read()/poll() syscalls, like pvrusb. On this specific driver, audio comes through a MPEG stream. As SDR provides audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to set/retrieve the type of audio stream, for SDR, but maybe it better to just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that the audio will come though the radio node and if the format is MPEG or SDR. SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive all kind of signals, analog audio, analog television, digital radio, digital television, cellular phones, etc. You can even receive DVB-T, but hardware I have is not capable to receive such wide stream. That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime? It could be possible that neither the DVB-API nor the V4L2 API is the right user-interface for such devices. The output of such devices is the acquisition of raw (digitalized) data of a signal and here signal is meant in the sense of anything which can be digitalized (e.g.: sensors, tuners, ADCs). Such device will surely be have a device-specific (user-space?) library to do the post/pre-processing before putting this data into a generic format. Generic format for SDR is Complex. I had some plans to do that conversion inside Kernel. That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2 provides a device-specific control path (to configure the hardware) if not somewhere else, or something new needs to be created. For me DVB API sounds very easy to implement. At the minimum only new delivery system and conversion to Complex. If you skip stream conversion and add only new delivery system, it is just single line of code to DVB frontend (at the most simplest case). V4L2 sounds hard for me since I have never done anything with it. But surely I can implement it as V4L2 too if it is correct way and there is someone who could give some tips how to proceed. 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
[Query] Clearing V4L2_BUF_FLAG_MAPPED flag on a videobuf2 buffer after munmap
Hi all, So, I've been trying to test the REQBUFS(0) from libv4l2 with my omap4iss device, and I've hit the following problem: So, I basically do the basic IOCTL sequence: open(/dev/video0) VIDIOC_QUERYCAP VIDIOC_ENUM_FMT VIDIOC_ENUM_FRAMESIZES VIDIOC_ENUM_FRAMEINTERVALS VIDIOC_S_FMT (w = 640, h = 480, pixfmt = V4L2_PIX_FMT_YUYV, type = V4L2_BUF_TYPE_VIDEO_CAPTURE) VIDIOC_S_PARM (capability = V4L2_CAP_TIMEPERFRAME, timeperframe = 1/30) VIDIOC_REQBUFS (count = 6, MMAP) Loop for 6 times: VIDIOC_QUERYBUF (to get buff length) mmap(length) Loop for 6 times: VIDIOC_QBUF(index = 0-5) VIDIOC_STREAMON (Loop to poll, DQBUF and QBUF the same buffer) VIDIOC_STREAMOFF Loop for 6 times: munmap() VIDIOC_REQBUFS (count = 0, MMAP) ... And in this call, it fails on libv4l2 level, since it checks all buffers to see if they're mapped, by doign QUERYBUF on each index, and checking for V4L2_BUF_FLAG_MAPPED flag. Now, digging deep into how this flag is populated, I noticed the following: I notice that in drivers/media/video/videobuf2-core.c, inside: vb2_querybuf() - __fill_v4l2_buffer() There's this condition: if (vb-num_planes_mapped == vb-num_planes) b-flags |= V4L2_BUF_FLAG_MAPPED; The problem is that, even if i did a munmap, the count of vb-num_planes_mapped is not decreased... :/ How's this supposed to work? Do I need to do something in my driver to avoid this flag to be set? Regards, Sergio -- 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: DVB core enhancements - comments please?
On Friday 29 June 2012 13:24:52 Patrick Boettcher wrote: That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2 *argl* I wanted to say, ... should _not_ sit on the DVB-API... -- Patrick. Kernel Labs Inc. 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
RE: dib0700 can't enable debug messages
Hello, did you enable the DVB USB debugging (CONFIG_DVB_USB_DEBUG) in your kernel configuration? regards, Olivier From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On Behalf Of cedric.dew...@telfort.nl [cedric.dew...@telfort.nl] Sent: Thursday, June 28, 2012 7:18 AM To: linux-media@vger.kernel.org Subject: dib0700 can't enable debug messages Hi all, I would like to see some debug messages from the dib0700 driver. I have tried to enable debug messages like this, following the instructions found here: http://www.linuxtv.org/wiki/index.php/Template:Making-it-work:dvb-usb-dib0700 # rmmod dvb_usb_dib0700 # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug=1 # rmmod dvb_usb_dib0700 # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug=2 # rmmod dvb_usb_dib0700 # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug=4 # rmmod dvb_usb_dib0700 # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug=8 # rmmod dvb_usb_dib0700 # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug 8 Error: could not insert module /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz: Invalid parameters # insmod /lib/modules/3.3.7-1-ARCH/kernel/drivers/media/dvb/dvb-usb/dvb-usb-dib0700.ko.gz debug=15 # rmmod dvb_usb_dib0700 # modprobe dvb_usb_dib0700 debug=15 The messaegs in /var/log/messages are the same in all the above cases: Jun 28 00:46:27 localhost kernel: [29669.758363] dvb-usb: found a 'Pinnacle PCTV 73e SE' in warm state. Jun 28 00:46:27 localhost kernel: [29669.758428] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 28 00:46:27 localhost kernel: [29669.758619] DVB: registering new adapter (Pinnacle PCTV 73e SE) Jun 28 00:46:27 localhost kernel: [29669.970031] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... Jun 28 00:46:28 localhost kernel: [29670.177652] DiB0070: successfully identified Jun 28 00:46:28 localhost kernel: [29670.177669] Registered IR keymap rc-dib0700-rc5 Jun 28 00:46:28 localhost kernel: [29670.177887] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc6/input31 Jun 28 00:46:28 localhost kernel: [29670.178061] rc6: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc6 Jun 28 00:46:28 localhost kernel: [29670.178274] dvb-usb: schedule remote query interval to 50 msecs. Jun 28 00:46:28 localhost kernel: [29670.178278] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. Jun 28 00:46:28 localhost kernel: [29670.178426] usbcore: registered new interface driver dvb_usb_dib0700 Jun 28 00:47:25 localhost kernel: [29727.435215] usbcore: deregistering interface driver dvb_usb_dib0700 Jun 28 00:47:25 localhost acpid: input device has been disconnected, fd 20 Jun 28 00:47:25 localhost kernel: [29727.444744] dvb-usb: Pinnacle PCTV 73e SE successfully deinitialized and disconnected. Jun 28 00:47:27 localhost kernel: [29729.807075] dvb-usb: found a 'Pinnacle PCTV 73e SE' in warm state. Jun 28 00:47:27 localhost kernel: [29729.807151] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 28 00:47:27 localhost kernel: [29729.807828] DVB: registering new adapter (Pinnacle PCTV 73e SE) Jun 28 00:47:27 localhost kernel: [29730.023174] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... Jun 28 00:47:28 localhost kernel: [29730.230923] DiB0070: successfully identified Jun 28 00:47:28 localhost kernel: [29730.230940] Registered IR keymap rc-dib0700-rc5 Jun 28 00:47:28 localhost kernel: [29730.231159] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc7/input32 Jun 28 00:47:28 localhost kernel: [29730.231336] rc7: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc7 Jun 28 00:47:28 localhost kernel: [29730.231543] dvb-usb: schedule remote query interval to 50 msecs. Jun 28 00:47:28 localhost kernel: [29730.231547] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. Jun 28 00:47:28 localhost kernel: [29730.231692] usbcore: registered new interface driver dvb_usb_dib0700 Jun 28 00:48:08 localhost kernel: [29770.891230] usbcore: deregistering interface driver dvb_usb_dib0700 Jun 28 00:48:08 localhost acpid: input device has been disconnected, fd 20 Jun 28 00:48:08 localhost kernel: [29770.902035] dvb-usb: Pinnacle PCTV 73e SE successfully deinitialized and disconnected. Jun 28 00:48:11 localhost kernel: [29773.181745] dvb-usb: found a 'Pinnacle PCTV 73e SE' in warm state. Jun 28 00:48:11 localhost kernel: [29773.181812] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 28 00:48:11 localhost kernel:
Re: DVB core enhancements - comments please?
Em 29-06-2012 08:24, Patrick Boettcher escreveu: On Friday 29 June 2012 08:03:16 Antti Palosaari wrote: On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote: Em 27-06-2012 21:33, Antti Palosaari escreveu: SDR - Softaware Defined Radio support DVB API -- * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu re/44461 * there is existing devices that are SDR (RTL2832U rtl-sdr) * SDR is quite near what is digital TV streaming * study what is needed * new delivery system for frontend API called SDR? * some core changes needed, like status (is locked etc) * how about demuxer? * stream conversion, inside Kernel? * what are new parameters needed for DVB API? Let's not mix APIs: the radio control should use the V4L2 API, as this is not DVB. The V4L2 API has already everything needed for radio. The only missing part ther is the audio stream. However, there are a few drivers that provide audio via the radio device node, using read()/poll() syscalls, like pvrusb. On this specific driver, audio comes through a MPEG stream. As SDR provides audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to set/retrieve the type of audio stream, for SDR, but maybe it better to just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that the audio will come though the radio node and if the format is MPEG or SDR. SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive all kind of signals, analog audio, analog television, digital radio, digital television, cellular phones, etc. You can even receive DVB-T, but hardware I have is not capable to receive such wide stream. That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime? It could be possible that neither the DVB-API nor the V4L2 API is the right user-interface for such devices. The output of such devices is the acquisition of raw (digitalized) data of a signal and here signal is meant in the sense of anything which can be digitalized (e.g.: sensors, tuners, ADCs). Such device will surely be have a device-specific (user-space?) library to do the post/pre-processing before putting this data into a generic format. That's one more reason why using the V4L2 API is better: at the V4L2 API, the output format is represented by a 32 bits unique code. There are several standard fourcc codes there, plus several proprietary formats represented. The decoding between the proprietary formats is done via libv4l. Libv4l can be used with any pre-compiled userspace application, via LD_PRELOAD, although almost all V4L2 userspace applications[1] are using the libv4l to decode data. Adding SDR decoding there should not be hard. [1] Radio applications don't use it yet, as almost all radio devices output audio via ALSA API, so some work will be needed there to add SDR radio support. That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2 provides a device-specific control path (to configure the hardware) if not somewhere else, or something new needs to be created. *argl* I wanted to say, ... should _not_ sit on the DVB-API... Agreed. Tuning with the V4L2 API is more direct, as doesn't have any threads looking for DVB demod status, in order to do frequency zig-zag. It also have support for hardware frequency scanning, which can be an interesting feature if supported. 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 1/2] [media] drxk: Make the QAM demodulator command configurable.
Em 29-06-2012 12:58, Martin Blumenstingl escreveu: Hi Ralph, are you sure about this? From what I have been told, the 2 parameter command is in the firmware ROM and older loadable/patch firmwares. Newer firmwares provided the 4 parameter command. The firmwares in the ROM are a good point. I discussed with Mauro Carvalho Chehab before I started writing my patch, and he told me that the only (loadable) firmware that uses the old command is the drxk_a3.mc one. But you are right, there is some firmware (for DVB-C, afaik it's NOT for DVB-T) stored in the ROM. If I find out that the ROM uses the old command then I'll probably try making this smart: old_qam_demod_cmd will be an int with the following possible values: * -1: unknown - trial and error approach will be used (afterwards this will be updated to either 0 or 1) * 0: use the 2-parameter command * 1: use the 4-parameter command I'll also try to guess a smart default value: -1 will be used if no firmware was given. Otherwise 0 will be the default. The remaining two drxk_config instances that are still using the old firmware will be set to 1 (like in my first patch). I didn't tell old command, or at least not in the sense of old firmware. I told that the first drivers (ddbridge and mantis), based on drxk_ac3.mc firmware, use the 4-parameters variant, while the other drivers use the 2-parameters variant. Anyway, using the name old for such parameter is not a good idea. IMHO, you should use something like qam_demod_needs_4_parameters for this config data, or, maybe number_of_qam_demod_parameters. If number_of_qam_demod_parameters is not 2 or 4, try both ways. So, a device driver that won't specify it will be auto-probed. If everything goes right then I'll be able to test and update my patch tonight. Regards, Martin -- 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 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 1/2] [media] drxk: Make the QAM demodulator command configurable.
Hi, I didn't tell old command, or at least not in the sense of old firmware. I told that the first drivers (ddbridge and mantis), based on drxk_ac3.mc firmware, use the 4-parameters variant, while the other drivers use the 2-parameters variant. Oh sorry, I must have gotten that wrong. Anyway, using the name old for such parameter is not a good idea. IMHO, you should use something like qam_demod_needs_4_parameters for this config data, or, maybe number_of_qam_demod_parameters. Sounds good. If number_of_qam_demod_parameters is not 2 or 4, try both ways. So, a device driver that won't specify it will be auto-probed. Ok, I'll keep the existing order: - first try the 4-parameter one - then try the 2-parameter one And I'll update the variable then to make sure we're not doing that trial-and-error thing twice. I'll also update all drxk_config instances where I'm sure that they're using the (newer) 2-parameter method. Thanks you two for you feedback! Regards, Martin -- 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] openSUSE hints for media_build
Hello again,
sorry, attachment missing.
Kind regards,
Georg Jansing
Am 29.06.2012 18:26, schrieb Georg Jansing:
Hello everybody,
I was trying to install Linux TV Kernel Modules via your media_build
git repo/scripts. Since I am on openSUSE and there are no installation
hints yet, and I needed to look up the correct packages anyways, here
is a small patch that adds the corresponding infomation to your script.
I hope, the formulation for adding the perl buildservice repository
(something like Ubuntu's PPAs) is clear enough. Please also be warned,
that I never did anything in perl yet, so I don't know if I chose the
best/perl way to add the repo message.
Sadly, the media_build drivers did not work for me, but with the
script I could at least compile them correctly (I think ;-)).
Kind regards,
Georg Jansing
From 7c622ca8df674a5b39c3e6c60cc69000f021e395 Mon Sep 17 00:00:00 2001
From: Georg Jansing jans...@am.uni-duesseldorf.de
Date: Fri, 29 Jun 2012 18:38:46 +0200
Subject: [PATCH] Add installation hints for openSUSE.
---
build | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/build b/build
index e023f6b..3384fdd 100755
--- a/build
+++ b/build
@@ -91,6 +91,38 @@ sub give_ubuntu_hints()
printf(You should run:\n\tsudo apt-get install $install\n);
}
+sub give_opensuse_hints()
+{
+ my $install;
+
+ my %map = (
+ lsdiff = patchutils,
+ Digest::SHA = perl-Digest-SHA1,
+ Proc::ProcessTable = perl-Proc-ProcessTable,
+ );
+
+ my $need_perl_repo = 0;
+
+ foreach my $prog (@missing) {
+ print ERROR: please install \$prog\, otherwise, build won't work.\n;
+ if (defined($map{$prog})) {
+ $install .= . $map{$prog};
+ } else {
+ $install .= . $prog;
+ }
+ if ($prog eq Proc::ProcessTable) {
+ $need_perl_repo = 1;
+ }
+ }
+
+ printf(You should run:\n\tsudo zypper install $install\n);
+
+ if ($need_perl_repo) {
+ printf(\nThe Proc::ProcessTable perl module can be found in the perl buildservice repository. );
+ printf(Add with the command (replacing 12.1 with your openSUSE release version):\n);
+ printf(\tsudo zypper ar http://download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_12.1/ perl\n);
+ }
+}
sub give_arch_linux_hints()
{
@@ -152,6 +185,10 @@ sub give_hints()
give_ubuntu_hints;
return;
}
+ if ($system_release =~ /openSUSE/) {
+ give_opensuse_hints;
+ return;
+ }
if ($system_release =~ /Arch Linux/) {
give_arch_linux_hints;
return;
--
1.7.7
[PATCH] openSUSE hints for media_build
Hello everybody, I was trying to install Linux TV Kernel Modules via your media_build git repo/scripts. Since I am on openSUSE and there are no installation hints yet, and I needed to look up the correct packages anyways, here is a small patch that adds the corresponding infomation to your script. I hope, the formulation for adding the perl buildservice repository (something like Ubuntu's PPAs) is clear enough. Please also be warned, that I never did anything in perl yet, so I don't know if I chose the best/perl way to add the repo message. Sadly, the media_build drivers did not work for me, but with the script I could at least compile them correctly (I think ;-)). Kind regards, Georg Jansing -- 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
AverTVHD Volar Max (h286DU)
Hello all, I'm currently working on an automated process to increase the number of online Closed Captions for the hearing-impaired community on a popular video-streaming service. I've had a successful proof-of-concept on mac and PC platforms, but to take this process to scale, I'd like to design a linux solution. The device I'm currently using is the AverTVHD Volar Max (h286DU). I've attempted to use the Aver-supplied drivers in Ubuntu 10.4 and 9.10 to no avail. Any help in developing a working driver / installation method for my device would be greatly appreciated by me, and, potentially, a very large and very under-represented audience of hard-of-hearing. Thanks for any support in this matter, and for all the development done up to this point. 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: AverTVHD Volar Max (h286DU)
On Fri, Jun 29, 2012 at 12:49 PM, aschu...@bright.net wrote: Hello all, I'm currently working on an automated process to increase the number of online Closed Captions for the hearing-impaired community on a popular video-streaming service. I've had a successful proof-of-concept on mac and PC platforms, but to take this process to scale, I'd like to design a linux solution. The device I'm currently using is the AverTVHD Volar Max (h286DU). I've attempted to use the Aver-supplied drivers in Ubuntu 10.4 and 9.10 to no avail. Any help in developing a working driver / installation method for my device would be greatly appreciated by me, and, potentially, a very large and very under-represented audience of hard-of-hearing. Thanks for any support in this matter, and for all the development done up to this point. Given you're looking to do this on a large scale, you might be better suited to choose a device that is actively maintained by the LinuxTV community rather than a device that the vendor shipped a driver for years ago, is not in the mainline kernel, and as far as I know doesn't work with current kernels. Just a suggestion though. 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
Re: AverTVHD Volar Max (h286DU)
Hi Devin I agree. What device would you suggest? Is there one which seems to be most popular / robust? Thanks 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: AverTVHD Volar Max (h286DU)
On Fri, Jun 29, 2012 at 1:19 PM, aschu...@bright.net wrote: Hi Devin I agree. What device would you suggest? Is there one which seems to be most popular / robust? That depends largely on your use case. Do you need to actually save the video, or just extract the captions (if you want to save the video, getting a board with an onboard MPEG encoder would be useful). Do you need to support digital ATSC/ClearQAM streams as well as analog? How many streams do you need to capture in a single PC? Any restrictions on bus type (USB/PCI/PCIe)? 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
Re: AverTVHD Volar Max (h286DU)
I don't need to save the video, except that I'm using CC extractor, which expects an Mpeg-2 file. I'd like to capture as many streams from one tuner as possible (one reason for working in the Linux environment), the vendor-provided applications do not allow me to run parallel instances. I'm hoping I can get around that - does that seem naive? I do need ATSC/Clear QAM support. Analog is not necessary. USB is preferable because I'm testing with a laptop. Thanks again for the advice, a -- 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.5] S5P driver fixes
Hi Mauro, On 06/28/2012 06:29 PM, Sylwester Nawrocki wrote: The following changes since commit 433002d69888238b16f8ea9434447feaa1fc9bf0: Merge remote-tracking branch 'party-public/v4l-fimc-fixes' into v4l-fixes (2012-06-27 16:28:08 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes for you to fetch changes up to f8a623efac978987be818a0a9d2d407791a066e4: Revert [media] V4L: JPEG class documentation corrections (2012-06-27 16:31:20 +0200) Kamil Debski (1): s5p-mfc: Fixed setup of custom controls in decoder and encoder Sylwester Nawrocki (2): s5p-fimc: Add missing FIMC-LITE file operations locking This patch depends on my previous pull request: http://patchwork.linuxtv.org/patch/11503 Revert [media] V4L: JPEG class documentation corrections Documentation/DocBook/media/v4l/controls.xml |2 +- Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 --- drivers/media/video/s5p-fimc/fimc-lite.c | 61 - drivers/media/video/s5p-mfc/s5p_mfc_dec.c |1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c |1 + 5 files changed, 47 insertions(+), 25 deletions(-) Sorry, I messed up this pull request by rebasing it onto wrong branch. Here it is corrected, against staging/for_v3.5 and on top of merged v4l-fimc-fixes branch, as per http://patchwork.linuxtv.org/patch/11503 The following changes since commit 96fc9f0f51d6b0d807aeb1f6e38485a3de429fd4: s5p-fimc: Stop media entity pipeline if fimc_pipeline_validate fails (2012-06-05 13:28:25 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-fixes for you to fetch changes up to c7de5370086a948c67cb7eeb5f25178c8979b0fe: Revert [media] V4L: JPEG class documentation corrections (2012-06-29 16:00:33 +0200) Kamil Debski (1): s5p-mfc: Fixed setup of custom controls in decoder and encoder Sylwester Nawrocki (2): s5p-fimc: Add missing FIMC-LITE file operations locking Revert [media] V4L: JPEG class documentation corrections Documentation/DocBook/media/v4l/controls.xml |2 +- Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 --- drivers/media/video/s5p-fimc/fimc-lite.c | 61 - drivers/media/video/s5p-mfc/s5p_mfc_dec.c |1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c |1 + 5 files changed, 47 insertions(+), 25 deletions(-) --- 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: AverTVHD Volar Max (h286DU)
On Fri, Jun 29, 2012 at 1:57 PM, aschu...@bright.net wrote: I don't need to save the video, except that I'm using CC extractor, which expects an Mpeg-2 file. I'd like to capture as many streams from one tuner as possible (one reason for working in the Linux environment), the vendor-provided applications do not allow me to run parallel instances. I'm hoping I can get around that - does that seem naive? I do need ATSC/Clear QAM support. Analog is not necessary. USB is preferable because I'm testing with a laptop. If you don't need analog then that makes things considerably simpler. The tuner will already deliver MPEG-2 (since that's what the broadcaster is sending), and tuners can be configured to deliver a full stream for cases where there are multiple channels on the same frequency. That said though, you are limited by the number of physical tuners in that a single tuner can only be on one frequency at a time. What you need to understand is that different products have different numbers of tuners. For example, the Hauppauge HVR-950q has a single tuner which can be shared for analog and digital while the HVR-2250 has two tuners (each of which can tune to a single analog or digital channel). There is no inherent limitation under Linux which prevents you from having multiple tuners in use in parallel. In fact it's actually quite common (many MythTV users for example record several programs at the same time since they have multiple tuners installed). 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
Re: AverTVHD Volar Max (h286DU)
Great info. I'm less familiar with the way that Cable is transmitted, but I do understand that ATSC carries multiple channels per frequency. Are you suggesting that I could capture a single stream from a single tuner which would contain several channels, and pull the CC data for all of those channels from a single stream? Would QAM work similarly? ( Assuming the feed is unencrypted ) I've found that most, if not all, cable boxes do not pass through CC data, because they are meant to interpret it and pass it on with customized formatting and whatnot, so another scaling challenge will be finding a feed that I can use without a cable box. OTA broadcasts have been my testing ground because they are so readily available. a -- 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: ERRORS
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:Fri Jun 29 19:00:20 CEST 2012 git hash:a99817ca60d206be3645d156f755cf065e949c58 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: WARNINGS 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-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 apps: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: AverTVHD Volar Max (h286DU)
On Fri, Jun 29, 2012 at 3:10 PM, aschu...@bright.net wrote: Great info. I'm less familiar with the way that Cable is transmitted, but I do understand that ATSC carries multiple channels per frequency. Are you suggesting that I could capture a single stream from a single tuner which would contain several channels, and pull the CC data for all of those channels from a single stream? Would QAM work similarly? ( Assuming the feed is unencrypted ) Yes, QAM is very similar. On many cable systems, while there may be fifteen or twenty unencrypted channels, they are spread across only three our four actual frequencies (meaning 3-4 tuners could grab effectively all the unencrypted channels at the same time). I've found that most, if not all, cable boxes do not pass through CC data, because they are meant to interpret it and pass it on with customized formatting and whatnot, so another scaling challenge will be finding a feed that I can use without a cable box. OTA broadcasts have been my testing ground because they are so readily available. Yeah, the fact that many cable boxes don't provide a way to expose CC data other than their inserting the decoded text into the video is pretty frustrating. Bear in mind though that since you don't care about the video then as long as the cable box has standard definition outputs then it may very well include the CC data (HD component and HDMI don't have a way to send CC data, but the older standard def outputs still do). You should definitely look at the Cablecard based devices such as the HD HomeRun Prime, Ceton InfiniTV, or Hauppauge DCR-2650. These devices will allow you to get to the unencrypted streams including CC data (assuming that the channel is marked copy freely). 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
Re: stk1160 linux driver
Hey Gianluca, On Mon, Jun 25, 2012 at 11:47 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Jun 25, 2012 at 10:36 AM, Ezequiel Garcia elezegar...@gmail.com wrote: Others issue related to memory allocation on platforms like ARM with limited coherent memory (if the device is unplugged/replugged often, the device won't be able to allocate the URB buffers), as well as As Devin says there maybe some issues with memory allocation I've added a module parameter for stk1160 named keep_buffers that could be used to reduce memory fragmentation. You may want to test the latest patch: http://patchwork.linuxtv.org/patch/13148/ If you have any problems/questions feel free to ask. Thanks, Ezequiel. -- 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: [Query] Clearing V4L2_BUF_FLAG_MAPPED flag on a videobuf2 buffer after munmap
On Fri, Jun 29, 2012 at 9:13 AM, Sergio Aguirre sergio.a.agui...@gmail.com wrote: Hi all, So, I've been trying to test the REQBUFS(0) from libv4l2 with my omap4iss device, and I've hit the following problem: Actually... nevermind :( I just realized that multiple fixes went in after 3.1. This problem i had is on a Android ICS kernel, which is v3.0, and didn't had some REQBUFS(0) patches. Very sorry for the noise. Regards, Sergio So, I basically do the basic IOCTL sequence: open(/dev/video0) VIDIOC_QUERYCAP VIDIOC_ENUM_FMT VIDIOC_ENUM_FRAMESIZES VIDIOC_ENUM_FRAMEINTERVALS VIDIOC_S_FMT (w = 640, h = 480, pixfmt = V4L2_PIX_FMT_YUYV, type = V4L2_BUF_TYPE_VIDEO_CAPTURE) VIDIOC_S_PARM (capability = V4L2_CAP_TIMEPERFRAME, timeperframe = 1/30) VIDIOC_REQBUFS (count = 6, MMAP) Loop for 6 times: VIDIOC_QUERYBUF (to get buff length) mmap(length) Loop for 6 times: VIDIOC_QBUF(index = 0-5) VIDIOC_STREAMON (Loop to poll, DQBUF and QBUF the same buffer) VIDIOC_STREAMOFF Loop for 6 times: munmap() VIDIOC_REQBUFS (count = 0, MMAP) ... And in this call, it fails on libv4l2 level, since it checks all buffers to see if they're mapped, by doign QUERYBUF on each index, and checking for V4L2_BUF_FLAG_MAPPED flag. Now, digging deep into how this flag is populated, I noticed the following: I notice that in drivers/media/video/videobuf2-core.c, inside: vb2_querybuf() - __fill_v4l2_buffer() There's this condition: if (vb-num_planes_mapped == vb-num_planes) b-flags |= V4L2_BUF_FLAG_MAPPED; The problem is that, even if i did a munmap, the count of vb-num_planes_mapped is not decreased... :/ How's this supposed to work? Do I need to do something in my driver to avoid this flag to be set? Regards, Sergio -- 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 1/4] [media] drxk: change it to use request_firmware_nowait()
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as they all seem to have an
internal firmware. So, only the firmware update will take a little longer
to happen.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 109 +++
drivers/media/dvb/frontends/drxk_hard.h |3 +
2 files changed, 72 insertions(+), 40 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 60b868f..4cb8d1e 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -5968,29 +5968,9 @@ error:
return status;
}
-static int load_microcode(struct drxk_state *state, const char *mc_name)
-{
- const struct firmware *fw = NULL;
- int err = 0;
-
- dprintk(1, \n);
-
- err = request_firmware(fw, mc_name, state-i2c-dev.parent);
- if (err 0) {
- printk(KERN_ERR
- drxk: Could not load firmware file %s.\n, mc_name);
- printk(KERN_INFO
- drxk: Copy %s to your hotplug directory!\n, mc_name);
- return err;
- }
- err = DownloadMicrocode(state, fw-data, fw-size);
- release_firmware(fw);
- return err;
-}
-
static int init_drxk(struct drxk_state *state)
{
- int status = 0;
+ int status = 0, n = 0;
enum DRXPowerMode powerMode = DRXK_POWER_DOWN_OFDM;
u16 driverVersion;
@@ -6073,8 +6053,12 @@ static int init_drxk(struct drxk_state *state)
if (status 0)
goto error;
- if (state-microcode_name)
- load_microcode(state, state-microcode_name);
+ if (state-fw) {
+ status = DownloadMicrocode(state, state-fw-data,
+ state-fw-size);
+ if (status 0)
+ goto error;
+ }
/* disable token-ring bus through OFDM block for possible ucode
upload */
status = write16(state, SIO_OFDM_SH_OFDM_RING_ENABLE__A,
SIO_OFDM_SH_OFDM_RING_ENABLE_OFF);
@@ -6167,6 +6151,20 @@ static int init_drxk(struct drxk_state *state)
state-m_DrxkState = DRXK_POWERED_DOWN;
} else
state-m_DrxkState = DRXK_STOPPED;
+
+ /* Initialize the supported delivery systems */
+ n = 0;
+ if (state-m_hasDVBC) {
+ state-frontend.ops.delsys[n++] = SYS_DVBC_ANNEX_A;
+ state-frontend.ops.delsys[n++] = SYS_DVBC_ANNEX_C;
+ strlcat(state-frontend.ops.info.name, DVB-C,
+ sizeof(state-frontend.ops.info.name));
+ }
+ if (state-m_hasDVBT) {
+ state-frontend.ops.delsys[n++] = SYS_DVBT;
+ strlcat(state-frontend.ops.info.name, DVB-T,
+ sizeof(state-frontend.ops.info.name));
+ }
}
error:
if (status 0)
@@ -6175,11 +6173,44 @@ error:
return status;
}
+static void load_firmware_cb(const struct firmware *fw,
+void *context)
+{
+ struct drxk_state *state = context;
+
+ if (!fw) {
+ printk(KERN_ERR
+ drxk: Could not load firmware file %s.\n,
+ state-microcode_name);
+ printk(KERN_INFO
+ drxk: Copy %s to your hotplug directory!\n,
+ state-microcode_name);
+ state-microcode_name = NULL;
+
+ /*
+* As firmware is now load asynchronous, it is not possible
+* anymore to fail at frontend attach. We might silently
+* return here, and hope that the driver won't crash.
+* We might also change all DVB callbacks to return -ENODEV
+* if the device is not initialized.
+* As the DRX-K devices have their own internal firmware,
+* let's just hope that it will match a firmware revision
+* compatible with this driver and proceed.
+*/
+ }
+ state-fw = fw;
+
+ init_drxk(state);
+}
+
static void drxk_release(struct dvb_frontend *fe)
{
struct drxk_state *state = fe-demodulator_priv;
dprintk(1, \n);
+ if (state-fw)
+ release_firmware(state-fw);
+
kfree(state);
}
@@ -6371,10 +6402,9 @@ static struct dvb_frontend_ops drxk_ops = {
struct dvb_frontend *drxk_attach(const struct drxk_config *config,
struct i2c_adapter *i2c)
{
-
[PATCH 3/4] [media] drxk: Lock I2C bus during firmware load
Don't allow other devices at the same I2C bus to use it during
firmware load, in order to prevent using the device while it is
not on a sane state.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 29 +++--
drivers/media/dvb/frontends/drxk_hard.h |3 +++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 5b3a17c..87cb3f0 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/firmware.h
#include linux/i2c.h
+#include linux/hardirq.h
#include asm/div64.h
#include dvb_frontend.h
@@ -308,10 +309,30 @@ static u32 Log10Times100(u32 x)
/* I2C **/
//
+static int drxk_i2c_lock(struct drxk_state *state)
+{
+ i2c_lock_adapter(state-i2c);
+ state-drxk_i2c_exclusive_lock = true;
+
+ return 0;
+}
+
+static void drxk_i2c_unlock(struct drxk_state *state)
+{
+ if (!state-drxk_i2c_exclusive_lock)
+ return;
+
+ i2c_unlock_adapter(state-i2c);
+ state-drxk_i2c_exclusive_lock = false;
+}
+
static int drxk_i2c_transfer(struct drxk_state *state, struct i2c_msg *msgs,
unsigned len)
{
- return i2c_transfer(state-i2c, msgs, len);
+ if (state-drxk_i2c_exclusive_lock)
+ return __i2c_transfer(state-i2c, msgs, len);
+ else
+ return i2c_transfer(state-i2c, msgs, len);
}
static int i2c_read1(struct drxk_state *state, u8 adr, u8 *val)
@@ -5982,6 +6003,7 @@ static int init_drxk(struct drxk_state *state)
dprintk(1, \n);
if ((state-m_DrxkState == DRXK_UNINITIALIZED)) {
+ drxk_i2c_lock(state);
status = PowerUpDevice(state);
if (status 0)
goto error;
@@ -6171,10 +6193,13 @@ static int init_drxk(struct drxk_state *state)
strlcat(state-frontend.ops.info.name, DVB-T,
sizeof(state-frontend.ops.info.name));
}
+ drxk_i2c_unlock(state);
}
error:
- if (status 0)
+ if (status 0) {
+ drxk_i2c_unlock(state);
printk(KERN_ERR drxk: Error %d on %s\n, status, __func__);
+ }
return status;
}
diff --git a/drivers/media/dvb/frontends/drxk_hard.h
b/drivers/media/dvb/frontends/drxk_hard.h
index 36677cd..c35ab2b 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -325,6 +325,9 @@ struct drxk_state {
enum DRXPowerMode m_currentPowerMode;
+ /* when true, avoids other devices to use the I2C bus */
+ bool drxk_i2c_exclusive_lock;
+
/*
* Configurable parameters at the driver. They stores the values found
* at struct drxk_config.
--
1.7.10.2
--
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 4/4] [media] drxk: prevent doing something wrong when init is not ok
If firmware is not loaded for some reason, or if it is not ready
yet, it makes no sense to honour to any DVB callbacks.
So, return -EAGAIN, as the error condition may be temporary.
If the device doesn't initialize, either because it requires a
firmware or because there's an error during init_drxk, returns
-ENODEV, to indicate such error, on all DVB callbacks.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 58 ++-
drivers/media/dvb/frontends/drxk_hard.h | 10 +-
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 87cb3f0..8fa28bb 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -2851,7 +2851,7 @@ static int ConfigureI2CBridge(struct drxk_state *state,
bool bEnableBridge)
dprintk(1, \n);
if (state-m_DrxkState == DRXK_UNINITIALIZED)
- goto error;
+ return 0;
if (state-m_DrxkState == DRXK_POWERED_DOWN)
goto error;
@@ -6197,6 +6197,7 @@ static int init_drxk(struct drxk_state *state)
}
error:
if (status 0) {
+ state-m_DrxkState = DRXK_NO_DEV;
drxk_i2c_unlock(state);
printk(KERN_ERR drxk: Error %d on %s\n, status, __func__);
}
@@ -6209,6 +6210,7 @@ static void load_firmware_cb(const struct firmware *fw,
{
struct drxk_state *state = context;
+ dprintk(1, : %s\n, fw ? firmware loaded : firmware not loaded);
if (!fw) {
printk(KERN_ERR
drxk: Could not load firmware file %s.\n,
@@ -6250,6 +6252,12 @@ static int drxk_sleep(struct dvb_frontend *fe)
struct drxk_state *state = fe-demodulator_priv;
dprintk(1, \n);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return 0;
+
ShutDown(state);
return 0;
}
@@ -6259,6 +6267,10 @@ static int drxk_gate_ctrl(struct dvb_frontend *fe, int
enable)
struct drxk_state *state = fe-demodulator_priv;
dprintk(1, %s\n, enable ? enable : disable);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+
return ConfigureI2CBridge(state, enable ? true : false);
}
@@ -6271,6 +6283,12 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
dprintk(1, \n);
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
if (!fe-ops.tuner_ops.get_if_frequency) {
printk(KERN_ERR
drxk: Error: get_if_frequency() not defined at tuner.
Can't work without it!\n);
@@ -6324,6 +6342,12 @@ static int drxk_read_status(struct dvb_frontend *fe,
fe_status_t *status)
u32 stat;
dprintk(1, \n);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
*status = 0;
GetLockStatus(state, stat, 0);
if (stat == MPEG_LOCK)
@@ -6337,8 +6361,15 @@ static int drxk_read_status(struct dvb_frontend *fe,
fe_status_t *status)
static int drxk_read_ber(struct dvb_frontend *fe, u32 *ber)
{
+ struct drxk_state *state = fe-demodulator_priv;
+
dprintk(1, \n);
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
*ber = 0;
return 0;
}
@@ -6350,6 +6381,12 @@ static int drxk_read_signal_strength(struct dvb_frontend
*fe,
u32 val = 0;
dprintk(1, \n);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
ReadIFAgc(state, val);
*strength = val 0x;
return 0;
@@ -6361,6 +6398,12 @@ static int drxk_read_snr(struct dvb_frontend *fe, u16
*snr)
s32 snr2;
dprintk(1, \n);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
GetSignalToNoise(state, snr2);
*snr = snr2 0x;
return 0;
@@ -6372,6 +6415,12 @@ static int drxk_read_ucblocks(struct dvb_frontend *fe,
u32 *ucblocks)
u16 err;
dprintk(1, \n);
+
+ if (state-m_DrxkState == DRXK_NO_DEV)
+ return -ENODEV;
+ if (state-m_DrxkState == DRXK_UNINITIALIZED)
+ return -EAGAIN;
+
DVBTQAMGetAccPktErr(state, err);
*ucblocks = (u32) err;
return 0;
@@ -6380,9 +6429,16 @@ static int drxk_read_ucblocks(struct dvb_frontend
[PATCH 2/4] [media] drxk: pass drxk priv struct instead of I2C adapter to i2c calls
As it will be using the unlocked version of i2c_transfer during
firmware loads, make sure that the priv state routine will be
used on all I2C calls, in preparation for the next patch that
will implement an exclusive lock mode to be used during firmware
load, at drxk_init.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 34 ++-
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 4cb8d1e..5b3a17c 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -308,16 +308,22 @@ static u32 Log10Times100(u32 x)
/* I2C **/
//
-static int i2c_read1(struct i2c_adapter *adapter, u8 adr, u8 *val)
+static int drxk_i2c_transfer(struct drxk_state *state, struct i2c_msg *msgs,
+unsigned len)
+{
+ return i2c_transfer(state-i2c, msgs, len);
+}
+
+static int i2c_read1(struct drxk_state *state, u8 adr, u8 *val)
{
struct i2c_msg msgs[1] = { {.addr = adr, .flags = I2C_M_RD,
.buf = val, .len = 1}
};
- return i2c_transfer(adapter, msgs, 1);
+ return drxk_i2c_transfer(state, msgs, 1);
}
-static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+static int i2c_write(struct drxk_state *state, u8 adr, u8 *data, int len)
{
int status;
struct i2c_msg msg = {
@@ -330,7 +336,7 @@ static int i2c_write(struct i2c_adapter *adap, u8 adr, u8
*data, int len)
printk(KERN_CONT %02x, data[i]);
printk(KERN_CONT \n);
}
- status = i2c_transfer(adap, msg, 1);
+ status = drxk_i2c_transfer(state, msg, 1);
if (status = 0 status != 1)
status = -EIO;
@@ -340,7 +346,7 @@ static int i2c_write(struct i2c_adapter *adap, u8 adr, u8
*data, int len)
return status;
}
-static int i2c_read(struct i2c_adapter *adap,
+static int i2c_read(struct drxk_state *state,
u8 adr, u8 *msg, int len, u8 *answ, int alen)
{
int status;
@@ -351,7 +357,7 @@ static int i2c_read(struct i2c_adapter *adap,
.buf = answ, .len = alen}
};
- status = i2c_transfer(adap, msgs, 2);
+ status = drxk_i2c_transfer(state, msgs, 2);
if (status != 2) {
if (debug 2)
printk(KERN_CONT : ERROR!\n);
@@ -394,7 +400,7 @@ static int read16_flags(struct drxk_state *state, u32 reg,
u16 *data, u8 flags)
len = 2;
}
dprintk(2, (0x%08x, 0x%02x)\n, reg, flags);
- status = i2c_read(state-i2c, adr, mm1, len, mm2, 2);
+ status = i2c_read(state, adr, mm1, len, mm2, 2);
if (status 0)
return status;
if (data)
@@ -428,7 +434,7 @@ static int read32_flags(struct drxk_state *state, u32 reg,
u32 *data, u8 flags)
len = 2;
}
dprintk(2, (0x%08x, 0x%02x)\n, reg, flags);
- status = i2c_read(state-i2c, adr, mm1, len, mm2, 4);
+ status = i2c_read(state, adr, mm1, len, mm2, 4);
if (status 0)
return status;
if (data)
@@ -464,7 +470,7 @@ static int write16_flags(struct drxk_state *state, u32 reg,
u16 data, u8 flags)
mm[len + 1] = (data 8) 0xff;
dprintk(2, (0x%08x, 0x%04x, 0x%02x)\n, reg, data, flags);
- return i2c_write(state-i2c, adr, mm, len + 2);
+ return i2c_write(state, adr, mm, len + 2);
}
static int write16(struct drxk_state *state, u32 reg, u16 data)
@@ -495,7 +501,7 @@ static int write32_flags(struct drxk_state *state, u32 reg,
u32 data, u8 flags)
mm[len + 3] = (data 24) 0xff;
dprintk(2, (0x%08x, 0x%08x, 0x%02x)\n, reg, data, flags);
- return i2c_write(state-i2c, adr, mm, len + 4);
+ return i2c_write(state, adr, mm, len + 4);
}
static int write32(struct drxk_state *state, u32 reg, u32 data)
@@ -542,7 +548,7 @@ static int write_block(struct drxk_state *state, u32
Address,
printk(KERN_CONT %02x, pBlock[i]);
printk(KERN_CONT \n);
}
- status = i2c_write(state-i2c, state-demod_address,
+ status = i2c_write(state, state-demod_address,
state-Chunk[0], Chunk + AdrLength);
if (status 0) {
printk(KERN_ERR drxk: %s: i2c write error at addr
0x%02x\n,
@@ -568,17 +574,17 @@ int PowerUpDevice(struct drxk_state *state)
dprintk(1, \n);
- status = i2c_read1(state-i2c, state-demod_address, data);
+ status = i2c_read1(state, state-demod_address, data);
if (status 0) {
do
[PATCH 0/4] drxk: use request_firmware_nowait()
This patch series should be applied after i2c: Export an unlocked flavor of i2c_transfer. It converts the drxk driver to use request_firmware_nowait() and prevents I2C bus usage during firmware load. If firmware load doesn't happen and the device cannot be reset due to that, -ENODEV will be returned to all dvb callbacks. Mauro Carvalho Chehab (4): [media] drxk: change it to use request_firmware_nowait() [media] drxk: pass drxk priv struct instead of I2C adapter to i2c calls [media] drxk: Lock I2C bus during firmware load [media] drxk: prevent doing something wrong when init is not ok drivers/media/dvb/frontends/drxk_hard.c | 228 +++ drivers/media/dvb/frontends/drxk_hard.h | 16 ++- 2 files changed, 187 insertions(+), 57 deletions(-) -- 1.7.10.2 -- 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: AverTVHD Volar Max (h286DU)
On Fri, 2012-06-29 at 15:55 -0400, Devin Heitmueller wrote: On Fri, Jun 29, 2012 at 3:10 PM, aschu...@bright.net wrote: I've found that most, if not all, cable boxes do not pass through CC data, because they are meant to interpret it and pass it on with customized formatting and whatnot, so another scaling challenge will be finding a feed that I can use without a cable box. OTA broadcasts have been my testing ground because they are so readily available. Yeah, the fact that many cable boxes don't provide a way to expose CC data other than their inserting the decoded text into the video is pretty frustrating. Bear in mind though that since you don't care about the video then as long as the cable box has standard definition outputs then it may very well include the CC data (HD component and HDMI don't have a way to send CC data, but the older standard def outputs still do). And for the SD analog outputs (CVBS or S-Video) of such boxes you would need an analog capture device in you Linux system. There are at least a few devices supported under linux that provide VBI data (e.g. CC) output independent of the digitized video. FWIW, I have noticed that ATSC OTA to analog NTSC converter boxes output a very nicely formed CC signal in the VBI. I have no experience with cable boxes. 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
stb0899: fix not locking DVB-S transponder
Is the patch below still necessary to make the skystar HD2 working correctly ? https://patchwork.kernel.org/patch/753382/-- 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
