build problem
Hello, I run Ubuntu 12.04 64b. I'm using USB - ID 048d:9135 Integrated Technology Express, Inc. Zolid Mini DVB-T Stick with linux-media build-ed drivers - as described here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I just have to build it again after every kernel update - OK. But last time - I have done the same as every time, but the build process failed: $ git clone --depth=1 git://linuxtv.org/media_build.git $ cd media_build/ $ ./build --verbose but it ends with error ... ** * Start building * ** make -C /home/hugo/tmp/media_build/v4l allyesconfig make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' No version yet, using 3.2.0-61-generic make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' make[2]: Entering directory `/home/hugo/tmp/media_build/linux' Applying patches for kernel 3.2.0-61-generic patch -s -f -N -p1 -i ../backports/api_version.patch patch -s -f -N -p1 -i ../backports/pr_fmt.patch The text leading up to this was: -- |diff --git a/drivers/media/usb/gspca/dtcs033.c b/drivers/media/usb/gspca/dtcs033.c |index 5e42c71..ba01a3e 100644 |--- a/drivers/media/usb/gspca/dtcs033.c |+++ b/drivers/media/usb/gspca/dtcs033.c -- No file to patch. Skipping patch. 1 out of 1 hunk ignored make[2]: *** [apply_patches] Error 1 make[2]: Leaving directory `/home/hugo/tmp/media_build/linux' make[1]: *** [allyesconfig] Error 2 make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make: *** [allyesconfig] Error 2 can't select all drivers at ./build line 490. xxx Please help me to get my TV working again. Thanks --kapetr -- 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: build problem
On 05/07/2014 07:45 AM, kap...@mizera.cz wrote: Hello, I run Ubuntu 12.04 64b. I'm using USB - ID 048d:9135 Integrated Technology Express, Inc. Zolid Mini DVB-T Stick with linux-media build-ed drivers - as described here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I just have to build it again after every kernel update - OK. But last time - I have done the same as every time, but the build process failed: $ git clone --depth=1 git://linuxtv.org/media_build.git $ cd media_build/ $ ./build --verbose but it ends with error The archive ./build downloads is missing a file for some reason. It may be a few days before it is fixed since the maintainer of that file is attending a conference. I've told Mauro that it is broken. In the meantime this should work, although it will be slow since it has to clone the git tree: ./build --main-git Regards, Hans ... ** * Start building * ** make -C /home/hugo/tmp/media_build/v4l allyesconfig make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' No version yet, using 3.2.0-61-generic make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' make[2]: Entering directory `/home/hugo/tmp/media_build/linux' Applying patches for kernel 3.2.0-61-generic patch -s -f -N -p1 -i ../backports/api_version.patch patch -s -f -N -p1 -i ../backports/pr_fmt.patch The text leading up to this was: -- |diff --git a/drivers/media/usb/gspca/dtcs033.c b/drivers/media/usb/gspca/dtcs033.c |index 5e42c71..ba01a3e 100644 |--- a/drivers/media/usb/gspca/dtcs033.c |+++ b/drivers/media/usb/gspca/dtcs033.c -- No file to patch. Skipping patch. 1 out of 1 hunk ignored make[2]: *** [apply_patches] Error 1 make[2]: Leaving directory `/home/hugo/tmp/media_build/linux' make[1]: *** [allyesconfig] Error 2 make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make: *** [allyesconfig] Error 2 can't select all drivers at ./build line 490. xxx Please help me to get my TV working again. Thanks --kapetr -- 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
build problem - from git
Hello, I run Ubuntu 12.04 64b. I'm using USB - ID 048d:9135 Integrated Technology Express, Inc. Zolid Mini DVB-T Stick with linux-media build-ed drivers - as described here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I just have to build it again after every kernel update - OK. But last time - I have done the same as every time, but the build process failed: $ git clone --depth=1 git://linuxtv.org/media_build.git $ cd media_build/ $ ./build --verbose but it ends with error ... ** * Start building * ** make -C /home/hugo/tmp/media_build/v4l allyesconfig make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' No version yet, using 3.2.0-61-generic make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make[1]: Entering directory `/home/hugo/tmp/media_build/v4l' make[2]: Entering directory `/home/hugo/tmp/media_build/linux' Applying patches for kernel 3.2.0-61-generic patch -s -f -N -p1 -i ../backports/api_version.patch patch -s -f -N -p1 -i ../backports/pr_fmt.patch The text leading up to this was: -- |diff --git a/drivers/media/usb/gspca/dtcs033.c b/drivers/media/usb/gspca/dtcs033.c |index 5e42c71..ba01a3e 100644 |--- a/drivers/media/usb/gspca/dtcs033.c |+++ b/drivers/media/usb/gspca/dtcs033.c -- No file to patch. Skipping patch. 1 out of 1 hunk ignored make[2]: *** [apply_patches] Error 1 make[2]: Leaving directory `/home/hugo/tmp/media_build/linux' make[1]: *** [allyesconfig] Error 2 make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l' make: *** [allyesconfig] Error 2 can't select all drivers at ./build line 490. xxx Please help me to get my TV working again. Thanks --kapetr -- 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/RFC v3 5/5] media: Add registration helpers for V4L2 flash sub-devices
On 05/06/2014 11:10 AM, Sakari Ailus wrote:
Hi Jacek,
On Tue, May 06, 2014 at 08:44:41AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 05/02/2014 01:06 PM, Sakari Ailus wrote:
[...]
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct led_ctrl *config,
+ u32 intensity)
Fits on a single line.
+{
+ return intensity / config-step;
Shouldn't you first decrement the minimum before the division?
Brightness level 0 means that led is off. Let's consider following case:
intensity - 15625
config-step - 15625
intensity / config-step = 1 (the lowest possible current level)
In V4L2 controls the minimum is not off, and zero might not be a possible
value since minimum isn't divisible by step.
I wonder how to best take that into account.
I've assumed that in MODE_TORCH a led is always on. Switching
the mode to MODE_FLASH or MODE_OFF turns the led off.
This way we avoid the problem with converting 0 uA value to
led_brightness, as available torch brightness levels start from
the minimum current level value and turning the led off is
accomplished on transition to MODE_OFF or MODE_FLASH, by
calling brightness_set op with led_brightness = 0.
I'm not sure if we understood the issue the same way. My concern was that if
the intensity isn't a multiple of step (but intensity - min is), the above
formula won't return a valid result (unless I miss something).
Please note that v4l2_flash_intensity_to_led_brightness is called only
from s_ctrl callback, and thus it expects to get the intensity aligned
to the step value, so it will always be a multiple of step.
Is it possible that s_ctrl callback would be passed a non-aligned
control value?
In a nutshell: value - min is aligned but value is not. Please see
validate_new() in drivers/media/v4l2-core/v4l2-ctrls.c .
Still, to my mind, value is aligned.
Below I execute the calculation steps one by one
according to the V4L2_CTRL_TYPE_INTEGER case in the
validate_new function:
c-value = 35000
val = c-value + step / 2; // 35000 + 15625 / 2 = 42812
val = clamp(val, min, max); // val = 42812
offset = val - min; // 42812 - 15625 = 27187
offset = step * (offset / step); // 15625 * (27187 / 15625) = 15625
c-value = min + offset; // 15625 + 15625 = 31250
Value is aligned to the nearest step.
Please spot any discrepancies in my way of thinking if there
are any :)
Regards,
Jacek Anaszewski
--
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/RFC v3 5/5] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
On Wed, May 07, 2014 at 09:20:17AM +0200, Jacek Anaszewski wrote:
On 05/06/2014 11:10 AM, Sakari Ailus wrote:
Hi Jacek,
On Tue, May 06, 2014 at 08:44:41AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 05/02/2014 01:06 PM, Sakari Ailus wrote:
[...]
+static inline enum led_brightness
v4l2_flash_intensity_to_led_brightness(
+ struct led_ctrl *config,
+ u32 intensity)
Fits on a single line.
+{
+ return intensity / config-step;
Shouldn't you first decrement the minimum before the division?
Brightness level 0 means that led is off. Let's consider following case:
intensity - 15625
config-step - 15625
intensity / config-step = 1 (the lowest possible current level)
In V4L2 controls the minimum is not off, and zero might not be a possible
value since minimum isn't divisible by step.
I wonder how to best take that into account.
I've assumed that in MODE_TORCH a led is always on. Switching
the mode to MODE_FLASH or MODE_OFF turns the led off.
This way we avoid the problem with converting 0 uA value to
led_brightness, as available torch brightness levels start from
the minimum current level value and turning the led off is
accomplished on transition to MODE_OFF or MODE_FLASH, by
calling brightness_set op with led_brightness = 0.
I'm not sure if we understood the issue the same way. My concern was that
if
the intensity isn't a multiple of step (but intensity - min is), the above
formula won't return a valid result (unless I miss something).
Please note that v4l2_flash_intensity_to_led_brightness is called only
from s_ctrl callback, and thus it expects to get the intensity aligned
to the step value, so it will always be a multiple of step.
Is it possible that s_ctrl callback would be passed a non-aligned
control value?
In a nutshell: value - min is aligned but value is not. Please see
validate_new() in drivers/media/v4l2-core/v4l2-ctrls.c .
Still, to my mind, value is aligned.
Below I execute the calculation steps one by one
according to the V4L2_CTRL_TYPE_INTEGER case in the
validate_new function:
c-value = 35000
val = c-value + step / 2; // 35000 + 15625 / 2 = 42812
val = clamp(val, min, max); // val = 42812
offset = val - min; // 42812 - 15625 = 27187
offset = step * (offset / step); // 15625 * (27187 / 15625) = 15625
c-value = min + offset; // 15625 + 15625 = 31250
Value is aligned to the nearest step.
Please spot any discrepancies in my way of thinking if there
are any :)
min is aligned to step above. This is not necessarily the case. And if min
is not aligned, neither is value.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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
vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
Hi, I have a driver which is MUXING out data taking in multiple inputs. It has been found in certain cases, at the minimum 40 buffers are required to be queued before it could MUX out anything. Currently, VIDEO_MAX_FRAME is restricting the max size to 32. This can be over-ridden in driver queue_setup, but, it is making it mandatory to use always a particular count. So, it takes the independence from application to allocate any count 32. So, is it okay to revise this limit or introduce a new queue-depth variable which could be used in conjuction with VIDEO_MAX_FRAME to determine the num_buffers. Regards, Divneil -- 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: vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
Hi Divneil, On 05/07/14 11:37, Divneil Wadhawan wrote: Hi, I have a driver which is MUXING out data taking in multiple inputs. It has been found in certain cases, at the minimum 40 buffers are required to be queued before it could MUX out anything. Currently, VIDEO_MAX_FRAME is restricting the max size to 32. This can be over-ridden in driver queue_setup, but, it is making it mandatory to use always a particular count. So, it takes the independence from application to allocate any count 32. So, is it okay to revise this limit or introduce a new queue-depth variable which could be used in conjuction with VIDEO_MAX_FRAME to determine the num_buffers. Hmm, I always wondered when this would happen. The right approach would be to add a VB2_MAX_FRAME define to videobuf2-core.h and use that in any v4l2 driver that uses videobuf2. VIDEO_MAX_FRAME really shouldn't be in a public API, but I don't think we can remove it since it's been there for ages. The maximum number of frames is really a property of vb2 (and the older videobuf, but I don't want to tamper with that) and as such it would be no problem increasing it to 64. In theory we could make the number of maximum frames driver specific, but it would be more trouble than it's worth at the moment IMHO. If we ever get drivers that need more than 64 buffers, then we can always reconsider. Which driver are you using? Is it something that you or someone else is likely to upstream to the linux kernel? 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
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Cheers Kishon -- 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: vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
Hi Hans Hmm, I always wondered when this would happen. :) In theory we could make the number of maximum frames driver specific, but it would be more trouble than it's worth at the moment IMHO. You mean to say adding a new field in struct vb2_queue. Hmm, I will nod yes, because, the requirement for me is no more than 64. Which driver are you using? Is it something that you or someone else is likely to upstream to the linux kernel? It's again TSMUXER. There are new data types defined, and some other stuff. I cannot commit on this, however, I am currently seeing this driver. Regards, Divneil -- 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] [media] s5p-mfc: Dequeue sequence header after STREAMON
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane. This used to still work fine until this patch
was merged b3379c6201bb3555298cdbf0aa004af260f2a6a4.
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index d64b680..4fd1034 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state: state of the output buffers queue
* @src_bufs: information on allocated source buffers
* @dst_bufs: information on allocated destination buffers
+ * @header_mb: buf pointer of the encoded sequence header
* @sequence: counter for the sequence number for v4l2
* @dec_dst_flag: flags for buffers queued in the hardware
* @dec_src_buf_size: size of the buffer for source buffers in decoding
@@ -607,6 +608,7 @@ struct s5p_mfc_ctx {
int src_bufs_cnt;
struct s5p_mfc_buf dst_bufs[MFC_MAX_BUFFERS];
int dst_bufs_cnt;
+ struct s5p_mfc_buf *header_mb;
unsigned int sequence;
unsigned long dec_dst_flag;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a9a23e1..e7dddb0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -787,7 +787,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
ctx-dst_queue_cnt--;
vb2_set_plane_payload(dst_mb-b, 0,
s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev));
- vb2_buffer_done(dst_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = dst_mb;
spin_unlock_irqrestore(dev-irqlock, flags);
}
@@ -845,6 +845,10 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
unsigned int strm_size;
unsigned long flags;
+ if (ctx-header_mb) {
+ vb2_buffer_done(ctx-header_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = NULL;
+ }
slice_type = s5p_mfc_hw_call(dev-mfc_ops, get_enc_slice_type, dev);
strm_size = s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev);
mfc_debug(2, Encoded slice type: %d\n, slice_type);
--
1.7.9.5
--
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: vb2_reqbufs() is not allowing more than VIDEO_MAX_FRAME
On 05/07/14 13:26, Divneil Wadhawan wrote: Hi Hans Hmm, I always wondered when this would happen. :) In theory we could make the number of maximum frames driver specific, but it would be more trouble than it's worth at the moment IMHO. You mean to say adding a new field in struct vb2_queue. No, just add a VB2_MAX_FRAME define and use that everywhere in vb2 and any driver depending on vb2 instead of VIDEO_MAX_FRAME. The VIDEO_MAX_FRAME define is used for vb2 internal array sizes, and those need to be increased. So replacing VIDEO_MAX_FRAME by VB2_MAX_FRAME is the easiest approach. Regards, Hans Hmm, I will nod yes, because, the requirement for me is no more than 64. Which driver are you using? Is it something that you or someone else is likely to upstream to the linux kernel? It's again TSMUXER. There are new data types defined, and some other stuff. I cannot commit on this, however, I am currently seeing this driver. Regards, Divneil -- 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] [media] s5p-mfc: Update scratch buffer size for VP8 encoder
From: Kiran AVND avnd.ki...@samsung.com Scratch buffer size updated for vp8 encoding as per the latest v7 firmware. As the new macro increases the scratch buffer size, it is backward compatible with the older firmware too. Signed-off-by: Kiran AVND avnd.ki...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/regs-mfc-v7.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h index 82c96fa..1a5c6fd 100644 --- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h @@ -54,6 +54,7 @@ (SZ_1M + ((w) * 144) + (8192 * (h)) + 49216) #define S5P_FIMV_SCRATCH_BUF_SIZE_VP8_ENC_V7(w, h) \ - (((w) * 48) + (((w) + 1) / 2 * 128) + 144 + 8192) + (((w) * 48) + 8192 + w) + 1) / 2) * 128) + 144 + \ + ((w) * 16) * ((h) * 16)) * 3) / 2) * 4)) #endif /*_REGS_MFC_V7_H*/ -- 1.7.9.5 -- 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
https://bugzilla.kernel.org/show_bug.cgi?id=75591
I had problems with uvc with the linux-3.15 kernel, all rc's When uvc is added I have problems with pulse audio that prevents firefox from functioning. disabling pulse audio allows firefox to work properly. on shut down and reboot watchdog does not stop and systemd says it cannot unmount some directorys. With uvc removed all works as they should. -- 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
V4L control units
Moikka What is preferred way implement controls that could have some known unit or unknown unit? For example for gain controls, I would like to offer gain in unit of dB (decibel) and also some unknown driver specific unit. Should I two controls, one for each unit? Like that V4L2_CID_RF_TUNER_LNA_GAIN_AUTO V4L2_CID_RF_TUNER_LNA_GAIN V4L2_CID_RF_TUNER_LNA_GAIN_dB 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
V4L control units
Moikka What is preferred way implement controls that could have some known unit or unknown unit? For example for gain controls, I would like to offer gain in unit of dB (decibel) and also some unknown driver specific unit. Should I two controls, one for each unit? Like that V4L2_CID_RF_TUNER_LNA_GAIN_AUTO V4L2_CID_RF_TUNER_LNA_GAIN V4L2_CID_RF_TUNER_LNA_GAIN_dB 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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Regards, Tomasz Stanislawski Cheers Kishon -- 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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
[CCing more DT-folks :)] On 07.05.2014 16:19, Rahul Sharma wrote: On 7 May 2014 19:06, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Thanks Tomasz, Ok got it. lets discuss it again and conclude it. @Kishon, DT-folks, The original RFC patch from Tomasz (at https://lkml.org/lkml/2013/10/21/313) added simple phy driver as Generic-simple-phy with these properties: + of_property_read_u32(dev-of_node, mask, sphy-mask); + of_property_read_u32(dev-of_node, on-value, sphy-on_value); + of_property_read_u32(dev-of_node, off-value, sphy-off_value); Shall we consider the same solution again for generic simple phy driver which just expose on/off control through register bit. Regards, Rahul Sharma Regards, Tomasz Stanislawski Cheers Kishon ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Best regards, Tomasz -- 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] mt9p031: Really disable Black Level Calibration in test pattern mode
The digital side of the Black Level Calibration (BLC) function must be
disabled when generating a test pattern to avoid artifacts in the image.
The driver disables BLC correctly at the hardware level, but the feature
gets reenabled by v4l2_ctrl_handler_setup() the next time the device is
powered on.
Fix this by marking the BLC controls as inactive when generating a test
pattern, and ignoring control set requests on inactive controls.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/mt9p031.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 33daace..9102b23 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -655,6 +655,9 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
u16 data;
int ret;
+ if (ctrl-flags V4L2_CTRL_FLAG_INACTIVE)
+ return 0;
+
switch (ctrl-id) {
case V4L2_CID_EXPOSURE:
ret = mt9p031_write(client, MT9P031_SHUTTER_WIDTH_UPPER,
@@ -709,8 +712,16 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
MT9P031_READ_MODE_2_ROW_MIR, 0);
case V4L2_CID_TEST_PATTERN:
+ /* The digital side of the Black Level Calibration function must
+* be disabled when generating a test pattern to avoid artifacts
+* in the image. Activate (deactivate) the BLC-related controls
+* when the test pattern is enabled (disabled).
+*/
+ v4l2_ctrl_activate(mt9p031-blc_auto, ctrl-val == 0);
+ v4l2_ctrl_activate(mt9p031-blc_offset, ctrl-val == 0);
+
if (!ctrl-val) {
- /* Restore the black level compensation settings. */
+ /* Restore the BLC settings. */
if (mt9p031-blc_auto-cur.val != 0) {
ret = mt9p031_s_ctrl(mt9p031-blc_auto);
if (ret 0)
@@ -735,9 +746,7 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
if (ret 0)
return ret;
- /* Disable digital black level compensation when using a test
-* pattern.
-*/
+ /* Disable digital BLC when generating a test pattern. */
ret = mt9p031_set_mode2(mt9p031, MT9P031_READ_MODE_2_ROW_BLC,
0);
if (ret 0)
--
Regards,
Laurent Pinchart
--
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] au0828: fix logic of tuner disconnection
On Tue, May 6, 2014 at 11:58 PM, cb.xi...@samsung.com wrote: From: Changbing Xiong cb.xi...@samsung.com The driver crashed when the tuner was disconnected while restart stream operations are still being performed. Fixed by adding a flag in struct au0828_dvb to indicate whether restart stream operations can be performed. If the stream gets misaligned, the work of restart stream operations are usually scheduled for many times in a row. If tuner is disconnected at this time and some of restart stream operations are still not flushed, then the driver crashed due to accessing the resource which used in restart stream operations has been released. Signed-off-by: Changbing Xiong cb.xi...@samsung.com I haven't yet reviewed the logic in detail, but at a minimum this should really be two patches - one to address the disconnect bug and a second to deal with failure to cancel to the worker thread. Also, you need to pick a name for the variable that is more explanatory than flag. Please resubmit this as two separate patches with flag renamed, and I will then look at the actual implementation to see if it causes any problems. Thanks, 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
[PATCH] TerraTec Cinergy Hybrid T USB XS with demodulator MT352 is not detect by em28xx
Hi,
I have Terratec Cinergy Hybrid T USB XS 00cd:0042, I'm trying to make
it work with kernel 3.14.3 but I have a problem.
With old kernel 2.6 this device was working, but now I thought there
is a little misconfiguration in driver em28xx.
I looking information on this link
http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS
and my device can have ZL10353 or MT352 demulator, my device has MT352
and has a Em2880 usb bridge.
Here the dmesg with original kernel 3.14.3
[ 670.727877] usb 3-1: new high-speed USB device number 5 using xhci_hcd
[ 670.865134] usb 3-1: New USB device found, idVendor=0ccd, idProduct=0042
[ 670.865147] usb 3-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 670.865154] usb 3-1: Product: Cinergy Hybrid T USB XS
[ 670.865160] usb 3-1: Manufacturer: TerraTec Electronic GmbH
[ 670.900385] em28xx: New device TerraTec Electronic GmbH Cinergy
Hybrid T USB XS @ 480 Mbps (0ccd:0042, interface 0, class 0)
[ 670.900391] em28xx: Video interface 0 found: isoc
[ 670.900393] em28xx: DVB interface 0 found: isoc
[ 670.900431] em28xx: chip ID is em2882/3
[ 671.070669] em2882/3 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x303d5d95
[ 671.070677] em2882/3 #0: EEPROM info:
[ 671.070681] em2882/3 #0: AC97 audio (5 sample rates)
[ 671.070684] em2882/3 #0: 500mA max power
[ 671.070689] em2882/3 #0: Table at offset 0x06, strings=0x329e,
0x346a, 0x
[ 671.070696] em2882/3 #0: Identified as Terratec Cinnergy Hybrid T
USB XS (em2882) (card=55)
[ 671.070701] em2882/3 #0: analog set to isoc mode.
[ 671.070704] em2882/3 #0: dvb set to isoc mode.
[ 671.070823] usbcore: registered new interface driver em28xx
[ 671.082716] em2882/3 #0: Binding DVB extension
[ 671.140861] em2882/3 #0: /2: dvb frontend not attached. Can't attach xc3028
[ 671.140875] em28xx: Registered (Em28xx dvb Extension) extension
[ 671.144670] em2882/3 #0: Registering input extension
[ 671.145161] Registered IR keymap rc-terratec-cinergy-xs
[ 671.145394] input: em28xx IR (em2882/3 #0) as
/devices/pci:00/:00:14.0/usb3/3-1/rc/rc0/input22
[ 671.145823] rc0: em28xx IR (em2882/3 #0) as
/devices/pci:00/:00:14.0/usb3/3-1/rc/rc0
[ 671.145927] em2882/3 #0: Input extension successfully initalized
[ 671.145933] em28xx: Registered (Em28xx Input Extension) extension
I have firmware 2.7 in /lib/firmware, but the problem is not the firmware.
in the source file drivers/media/usb/em28xx/em28xx-cards.c
my device is configured as
{ USB_DEVICE(0x0ccd, 0x0042),
.driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
but for this configuration in drivers/media/usb/em28xx/em28xx-dvb.c only zl10353
is tried to attach for dvb adapter, in my case there is an issue.
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
case EM2882_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_EMPIRE_DUAL_TV:
dvb-fe[0] = dvb_attach(zl10353_attach,
em28xx_zl10353_xc3028_no_i2c_gate,
dev-i2c_adap[dev-def_i2c_bus]);
if (em28xx_attach_xc3028(0x61, dev) 0) {
result = -EINVAL;
goto out_free;
}
break;
I tried this patch
--- /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c.orig
2014-05-06 16:59:58.0 +0200
+++ /usr/src/linux-3.14.3/drivers/media/usb/em28xx/em28xx-cards.c
2014-05-07 15:18:31.719524453 +0200
@@ -2233,7 +2233,7 @@
{ USB_DEVICE(0x0ccd, 0x005e),
.driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
{ USB_DEVICE(0x0ccd, 0x0042),
- .driver_info = EM2882_BOARD_TERRATEC_HYBRID_XS },
+ .driver_info = EM2880_BOARD_TERRATEC_HYBRID_XS },
{ USB_DEVICE(0x0ccd, 0x0043),
.driver_info = EM2870_BOARD_TERRATEC_XS },
{ USB_DEVICE(0x0ccd, 0x008e), /* Cinergy HTC USB XS Rev. 1 */
so my device became a EM2880_BOARD_TERRATEC_HYBRID_XS and in
em28xx-dvb.c also MT352 is tried to attach
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
case EM2882_BOARD_DIKOM_DK300:
case EM2882_BOARD_KWORLD_VS_DVBT:
dvb-fe[0] = dvb_attach(zl10353_attach,
em28xx_zl10353_xc3028_no_i2c_gate,
dev-i2c_adap[dev-def_i2c_bus]);
if (dvb-fe[0] == NULL) {
/* This board could have either a zl10353 or a mt352.
If the chip id isn't for zl10353, try mt352 */
dvb-fe[0] = dvb_attach(mt352_attach,
terratec_xs_mt352_cfg,
dev-i2c_adap[dev-def_i2c_bus]);
}
if (em28xx_attach_xc3028(0x61, dev) 0) {
cron job: media_tree daily build: OK
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: Thu May 8 04:00:18 CEST 2014 git branch: test git hash: 393cbd8dc532c1ebed60719da8d379f50d445f28 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API 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
