Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
On 12/12/2013 09:35 AM, Archit Taneja wrote: The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware blocks. We create libraries for these components such that the vpe driver and the vip driver(in future) can use these library funcs to configure the blocks. There are some points for which I would like comments: - For VPE, setting the format and colorspace for the source and destination queues is enough to determine how these blocks need to be configured and whether they need to be bypassed or not. So it didn't make sense to represent them as media controller entities. For VIP(driver not upstream yet), it's possible that there are multiple data paths which may or may not include these blocks. However, the current use cases don't require such flexibility. There may be a need to re-consider a media controller like setup once we work on the VIP driver. Is it a good idea in terms of user-space compatibilty if we use media controller framework in the future. As long as you don't need the mc, then there is no need to implement it. - These blocks will also require some custom control commands later on. For example, we may want to tell the scaler later on to perform bi-linear scaling, or perform peaking at a particular frequency. - The current series keeps the default scaler coefficients in a header file. These coefficients add a lot of lines of code in the kernel. Does it make more sense for the user application to pass the co-efficients to the kernel using an ioctl? Is there any driver which currenlty does this? I think it is good to keep it in the driver. Otherwise apps would be forced to set up the table. It's about 11 kilobyte in memory, which isn't that bad. The series is based on the branch: git://linuxtv.org/media_tree.git master Archit Taneja (8): v4l: ti-vpe: create a scaler block library v4l: ti-vpe: support loading of scaler coefficients v4l: ti-vpe: make vpe driver load scaler coefficients v4l: ti-vpe: enable basic scaler support v4l: ti-vpe: create a color space converter block library v4l: ti-vpe: Add helper to perform color conversion v4l: ti-vpe: enable CSC support for VPE v4l: ti-vpe: Add a type specifier to describe vpdma data format type drivers/media/platform/ti-vpe/Makefile |2 +- drivers/media/platform/ti-vpe/csc.c | 196 + drivers/media/platform/ti-vpe/csc.h | 68 ++ drivers/media/platform/ti-vpe/sc.c | 311 +++ drivers/media/platform/ti-vpe/sc.h | 208 + drivers/media/platform/ti-vpe/sc_coeff.h | 1342 ++ drivers/media/platform/ti-vpe/vpdma.c| 36 +- drivers/media/platform/ti-vpe/vpdma.h|7 + drivers/media/platform/ti-vpe/vpe.c | 251 -- drivers/media/platform/ti-vpe/vpe_regs.h | 187 - 10 files changed, 2335 insertions(+), 273 deletions(-) create mode 100644 drivers/media/platform/ti-vpe/csc.c create mode 100644 drivers/media/platform/ti-vpe/csc.h create mode 100644 drivers/media/platform/ti-vpe/sc.c create mode 100644 drivers/media/platform/ti-vpe/sc.h create mode 100644 drivers/media/platform/ti-vpe/sc_coeff.h For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com 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: [PATCH 0/2] v4l: ti-vpe: Some VPE fixes
On 12/17/2013 08:52 AM, Hans Verkuil wrote: On 12/03/2013 12:51 PM, Archit Taneja wrote: This series fixes 2 issues in the VPE driver. The first fix allows us to use UYVY color format for source and destination buffers. The second fix makes sure we don't set pixel format widths which the VPDMA HW can't support. None of these fixes are fatal, so they don't necessarily need to go in for the 3.13-rc fixes. Archit Taneja (2): v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format v4l: ti-vpe: make sure VPDMA line stride constraints are met drivers/media/platform/ti-vpe/vpdma.c | 4 +-- drivers/media/platform/ti-vpe/vpdma.h | 5 ++- drivers/media/platform/ti-vpe/vpdma_priv.h | 2 +- drivers/media/platform/ti-vpe/vpe.c| 53 ++ 4 files changed, 47 insertions(+), 17 deletions(-) For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com Ah, it's already merged. I missed that :-) 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
3fdfedaaa7f243f3347084231c64f6c1be0ba131 causes a regression
Hello Laurent, I was working on having a functional IOMMU/ISP for 3.14, and had an issue with an image completely distorted. Comparing with another kernel, I saw that PRV_HORZ_INFO and PRV_VERT_INFO differed. On the newer kernel, sph, eph, svl, and slv were all off-by 2, causing my final image to miss 4 pixels on each line, thus distorting the result. Your commit 3fdfedaaa7f243f3347084231c64f6c1be0ba131 '[media] omap3isp: preview: Lower the crop margins' indeed changes PRV_HORZ_INFO and PRV_VERT_INFO by removing the if() condition. Reverting it made my image to be valid again. FYI, my pipeline is: MT9V032 (SGRBG10 752x480) - CCDC - PREVIEW (UYVY 752x480) - RESIZER - out Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
Hi Hans, On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote: On 12/12/2013 09:35 AM, Archit Taneja wrote: The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware blocks. We create libraries for these components such that the vpe driver and the vip driver(in future) can use these library funcs to configure the blocks. There are some points for which I would like comments: - For VPE, setting the format and colorspace for the source and destination queues is enough to determine how these blocks need to be configured and whether they need to be bypassed or not. So it didn't make sense to represent them as media controller entities. For VIP(driver not upstream yet), it's possible that there are multiple data paths which may or may not include these blocks. However, the current use cases don't require such flexibility. There may be a need to re-consider a media controller like setup once we work on the VIP driver. Is it a good idea in terms of user-space compatibilty if we use media controller framework in the future. As long as you don't need the mc, then there is no need to implement it. The thing is that we want to use these blocks for a future capture hardware called VIP. A VIP port can capture multiple streams from different sensors in time slices, and each of those streams might be sharing the same hardware, but probably in different configurations. I'm not completely aware of media controller details, and whether it can help us here. I was just wondering if it would be a problem if we later realise that mc might be useful for some use cases. Would implementing it then break previous user space applications which don't call mc ioctls? - These blocks will also require some custom control commands later on. For example, we may want to tell the scaler later on to perform bi-linear scaling, or perform peaking at a particular frequency. - The current series keeps the default scaler coefficients in a header file. These coefficients add a lot of lines of code in the kernel. Does it make more sense for the user application to pass the co-efficients to the kernel using an ioctl? Is there any driver which currenlty does this? I think it is good to keep it in the driver. Otherwise apps would be forced to set up the table. It's about 11 kilobyte in memory, which isn't that bad. Okay. The series is based on the branch: git://linuxtv.org/media_tree.git master Archit Taneja (8): v4l: ti-vpe: create a scaler block library v4l: ti-vpe: support loading of scaler coefficients v4l: ti-vpe: make vpe driver load scaler coefficients v4l: ti-vpe: enable basic scaler support v4l: ti-vpe: create a color space converter block library v4l: ti-vpe: Add helper to perform color conversion v4l: ti-vpe: enable CSC support for VPE v4l: ti-vpe: Add a type specifier to describe vpdma data format type drivers/media/platform/ti-vpe/Makefile |2 +- drivers/media/platform/ti-vpe/csc.c | 196 + drivers/media/platform/ti-vpe/csc.h | 68 ++ drivers/media/platform/ti-vpe/sc.c | 311 +++ drivers/media/platform/ti-vpe/sc.h | 208 + drivers/media/platform/ti-vpe/sc_coeff.h | 1342 ++ drivers/media/platform/ti-vpe/vpdma.c| 36 +- drivers/media/platform/ti-vpe/vpdma.h|7 + drivers/media/platform/ti-vpe/vpe.c | 251 -- drivers/media/platform/ti-vpe/vpe_regs.h | 187 - 10 files changed, 2335 insertions(+), 273 deletions(-) create mode 100644 drivers/media/platform/ti-vpe/csc.c create mode 100644 drivers/media/platform/ti-vpe/csc.h create mode 100644 drivers/media/platform/ti-vpe/sc.c create mode 100644 drivers/media/platform/ti-vpe/sc.h create mode 100644 drivers/media/platform/ti-vpe/sc_coeff.h For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks for the review. Archit -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
On 12/17/13 12:19, Archit Taneja wrote: Hi Hans, On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote: On 12/12/2013 09:35 AM, Archit Taneja wrote: The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware blocks. We create libraries for these components such that the vpe driver and the vip driver(in future) can use these library funcs to configure the blocks. There are some points for which I would like comments: - For VPE, setting the format and colorspace for the source and destination queues is enough to determine how these blocks need to be configured and whether they need to be bypassed or not. So it didn't make sense to represent them as media controller entities. For VIP(driver not upstream yet), it's possible that there are multiple data paths which may or may not include these blocks. However, the current use cases don't require such flexibility. There may be a need to re-consider a media controller like setup once we work on the VIP driver. Is it a good idea in terms of user-space compatibilty if we use media controller framework in the future. As long as you don't need the mc, then there is no need to implement it. The thing is that we want to use these blocks for a future capture hardware called VIP. A VIP port can capture multiple streams from different sensors in time slices, and each of those streams might be sharing the same hardware, but probably in different configurations. I'm not completely aware of media controller details, and whether it can help us here. I was just wondering if it would be a problem if we later realise that mc might be useful for some use cases. Would implementing it then break previous user space applications which don't call mc ioctls? My understanding is that in the current vpe driver the mc won't be needed, so there is no point adding it. When implementing the vip capture driver the mc might be needed, but that should not require the vpe to add the mc API as well. It's a decision that has to be made per driver. When you start work on the vip driver it is probably a good idea to talk to Laurent and myself first to see whether the mc is needed or not. If you have a block diagram of the video hardware that you can share, then that will be quite useful. 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: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
Hi, On Tuesday 17 December 2013 05:19 PM, Hans Verkuil wrote: On 12/17/13 12:19, Archit Taneja wrote: Hi Hans, On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote: On 12/12/2013 09:35 AM, Archit Taneja wrote: The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware blocks. We create libraries for these components such that the vpe driver and the vip driver(in future) can use these library funcs to configure the blocks. There are some points for which I would like comments: - For VPE, setting the format and colorspace for the source and destination queues is enough to determine how these blocks need to be configured and whether they need to be bypassed or not. So it didn't make sense to represent them as media controller entities. For VIP(driver not upstream yet), it's possible that there are multiple data paths which may or may not include these blocks. However, the current use cases don't require such flexibility. There may be a need to re-consider a media controller like setup once we work on the VIP driver. Is it a good idea in terms of user-space compatibilty if we use media controller framework in the future. As long as you don't need the mc, then there is no need to implement it. The thing is that we want to use these blocks for a future capture hardware called VIP. A VIP port can capture multiple streams from different sensors in time slices, and each of those streams might be sharing the same hardware, but probably in different configurations. I'm not completely aware of media controller details, and whether it can help us here. I was just wondering if it would be a problem if we later realise that mc might be useful for some use cases. Would implementing it then break previous user space applications which don't call mc ioctls? My understanding is that in the current vpe driver the mc won't be needed, so there is no point adding it. When implementing the vip capture driver the mc might be needed, but that should not require the vpe to add the mc API as well. It's a decision that has to be made per driver. That's right, vpe doesn't need mc. It might be needed for vip. The reason I brought it up now is because some of the blocks like SC/CSC are replicated in VIP hardware, and I created them in a 'library' sort of way in this series. If vip driver uses mc, these blocks might need to become media entities. When you start work on the vip driver it is probably a good idea to talk to Laurent and myself first to see whether the mc is needed or not. Thanks, that'll be quite useful. I'll look up some mc documentation and drivers using mc myself as well. If you have a block diagram of the video hardware that you can share, then that will be quite useful. Thanks for the clarification. I don't think the DRA7x documentation is public yet. I'll try to look for a block diagram(or create one) and share it with the list. Archit -- 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: omap3isp device tree support
Hello Enrico, On 12/06/2013 11:54 AM, Enrico wrote: On Fri, Dec 6, 2013 at 11:31 AM, Florian Vaussard florian.vauss...@epfl.ch wrote: Hello, On 12/06/2013 11:13 AM, Enrico wrote: Hi, i know there is some work going on for omap3isp device tree support, but right now is it possible to enable it in some other way in a DT kernel? The DT support is not yet ready, but an RFC binding has been proposed. It won't be ready for 3.14. I've tried enabling it in board-generic.c (omap3_init_camera(...) with proper platform data) but it hangs early at boot, do someone know if it's possible and how to do it? I did the same a few days ago, and went through several problems (panics, half DT support,...). Now I am able to probe the ISP, I still have one kernel panic to fix. Hope to send the patches in 1 or 2 days. We are still in a transition period, but things should calm down in the coming releases. So I converted the iommu to DT (patches just sent), used pdata quirks for the isp / mtv9032 data, added a few patches from other people (mainly clk to fix a crash when deferring the omap3isp probe), and a few small hacks. I get a 3.13-rc3 (+ board-removal part from Tony Lindgren) to boot on DT with a working MT9V032 camera. The missing part is the DT binding for the omap3isp, but I guess that we will have to wait a bit more for this. If you want to test, I have a development tree here [1]. Any feedback is welcome. Cheers, Florian [1] https://github.com/vaussard/linux/commits/overo-for-3.14/iommu/dt -- 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
[RFC PATCH 7/6] adv7511: verify EDID header
Ignore EDID's where the header is wrong.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7511.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index f20450c..ee61894 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -965,26 +965,38 @@ static void adv7511_check_monitor_present_status(struct
v4l2_subdev *sd)
static bool edid_block_verify_crc(uint8_t *edid_block)
{
- int i;
uint8_t sum = 0;
+ int i;
for (i = 0; i 128; i++)
- sum += *(edid_block + i);
- return (sum == 0);
+ sum += edid_block[i];
+ return sum == 0;
}
-static bool edid_segment_verify_crc(struct v4l2_subdev *sd, u32 segment)
+static bool edid_verify_crc(struct v4l2_subdev *sd, u32 segment)
{
struct adv7511_state *state = get_adv7511_state(sd);
u32 blocks = state-edid.blocks;
uint8_t *data = state-edid.data;
- if (edid_block_verify_crc(data[segment * 256])) {
- if ((segment + 1) * 2 = blocks)
- return edid_block_verify_crc(data[segment * 256 +
128]);
+ if (!edid_block_verify_crc(data[segment * 256]))
+ return false;
+ if ((segment + 1) * 2 = blocks)
+ return edid_block_verify_crc(data[segment * 256 + 128]);
+ return true;
+}
+
+static bool edid_verify_header(struct v4l2_subdev *sd, u32 segment)
+{
+ static const u8 hdmi_header[] = {
+ 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
+ };
+ struct adv7511_state *state = get_adv7511_state(sd);
+ u8 *data = state-edid.data;
+
+ if (segment != 0)
return true;
- }
- return false;
+ return !memcmp(data, hdmi_header, sizeof(hdmi_header));
}
static bool adv7511_check_edid_status(struct v4l2_subdev *sd)
@@ -1013,9 +1025,10 @@ static bool adv7511_check_edid_status(struct v4l2_subdev
*sd)
state-edid.blocks = state-edid.data[0x7e] + 1;
v4l2_dbg(1, debug, sd, %s: %d blocks in total\n,
__func__, state-edid.blocks);
}
- if (!edid_segment_verify_crc(sd, segment)) {
+ if (!edid_verify_crc(sd, segment) ||
+ !edid_verify_header(sd, segment)) {
/* edid crc error, force reread of edid segment */
- v4l2_dbg(1, debug, sd, %s: edid crc error\n,
__func__);
+ v4l2_err(sd, %s: edid crc or header error\n,
__func__);
state-have_monitor = false;
adv7511_s_power(sd, false);
adv7511_s_power(sd, true);
--
1.8.4.rc3
--
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
[RFC PATCH 18/15] adv7604: initialize timings to CEA 640x480p59.94.
This timing must be supported by all HDMI equipment, so that's a
reasonable default.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 3f40616..f063162 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2207,6 +2207,8 @@ static struct i2c_client *adv7604_dummy_client(struct
v4l2_subdev *sd,
static int adv7604_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ static const struct v4l2_dv_timings cea640x480 =
+ V4L2_DV_BT_CEA_640X480P59_94;
struct adv7604_state *state;
struct adv7604_platform_data *pdata = client-dev.platform_data;
struct v4l2_ctrl_handler *hdl;
@@ -2234,7 +2236,8 @@ static int adv7604_probe(struct i2c_client *client,
v4l_err(client, No platform data!\n);
return -ENODEV;
}
- memcpy(state-pdata, pdata, sizeof(state-pdata));
+ state-pdata = *pdata;
+ state-timings = cea640x480;
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, adv7604_ops);
--
1.8.4.rc3
--
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
[RFC PATCH 17/15] adv7604: sync polarities from platform data
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 5 +++--
include/media/adv7604.h | 4
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index a1fa9a0..3f40616 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2126,9 +2126,10 @@ static int adv7604_core_init(struct v4l2_subdev *sd)
pdata-replicate_av_codes 1 |
pdata-invert_cbcr 0);
- /* TODO from platform data */
cp_write(sd, 0x69, 0x30); /* Enable CP CSC */
- io_write(sd, 0x06, 0xa6); /* positive VS and HS */
+
+ /* VS, HS polarities */
+ io_write(sd, 0x06, 0xa0 | pdata-inv_vs_pol 2 | pdata-inv_hs_pol
1);
/* Adjust drive strength */
io_write(sd, 0x14, 0x40 | pdata-dr_str 4 |
diff --git a/include/media/adv7604.h b/include/media/adv7604.h
index 0162c31..053b13c 100644
--- a/include/media/adv7604.h
+++ b/include/media/adv7604.h
@@ -107,6 +107,10 @@ struct adv7604_platform_data {
unsigned replicate_av_codes:1;
unsigned invert_cbcr:1;
+ /* IO register 0x06 */
+ unsigned inv_vs_pol:1;
+ unsigned inv_hs_pol:1;
+
/* IO register 0x14 */
unsigned dr_str:2;
unsigned dr_str_clk:2;
--
1.8.4.rc3
--
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
[RFC PATCH 16/15] adv7604: return immediately if the new timings are equal to what is configured
Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index cfeaaaf..a1fa9a0 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1423,6 +1423,11 @@ static int adv7604_s_dv_timings(struct v4l2_subdev *sd,
if (!timings)
return -EINVAL;
+ if (v4l2_match_dv_timings(state-timings, timings, 0)) {
+ v4l2_dbg(1, debug, sd, %s: no change\n, __func__);
+ return 0;
+ }
+
bt = timings-bt;
if ((is_analog_input(sd) bt-pixelclock 17000) ||
--
1.8.4.rc3
--
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
[RFC PATCH 23/22] adv7842: return 0 if no change in s_dv_timings
Return 0 if the new timings are equal to the current timings as
it caused extra cp-loss/lock interrupts.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7842.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index bafe3b5..82c57d7 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -1453,6 +1453,11 @@ static int adv7842_s_dv_timings(struct v4l2_subdev *sd,
if (state-mode == ADV7842_MODE_SDP)
return -ENODATA;
+ if (v4l2_match_dv_timings(state-timings, timings, 0)) {
+ v4l2_dbg(1, debug, sd, %s: no change\n, __func__);
+ return 0;
+ }
+
bt = timings-bt;
if (!v4l2_valid_dv_timings(timings, adv7842_get_dv_timings_cap(sd),
--
1.8.4.rc3
--
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
[RFC PATCH 24/22] adv7842: set LLC DLL phase from platform_data
The correct LLC DLL phase depends on the board layout, so this
should be part of the platform_data.
Verified-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7842.c | 6 +-
include/media/adv7842.h | 6 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 82c57d7..2eb4058 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -1591,9 +1591,6 @@ static void select_input(struct v4l2_subdev *sd,
afe_write(sd, 0x00, 0x00); /* power up ADC */
afe_write(sd, 0xc8, 0x00); /* phase control */
- io_write(sd, 0x19, 0x83); /* LLC DLL phase */
- io_write(sd, 0x33, 0x40); /* LLC DLL enable */
-
io_write(sd, 0xdd, 0x90); /* Manual 2x output clock */
/* script says register 0xde, which don't exist in manual */
@@ -2603,8 +2600,7 @@ static int adv7842_core_init(struct v4l2_subdev *sd)
io_write_and_or(sd, 0x20, 0xcf, 0x00);
/* LLC */
- /* Set phase to 16. TODO: get this from platform_data */
- io_write(sd, 0x19, 0x90);
+ io_write(sd, 0x19, 0x80 | pdata-llc_dll_phase);
io_write(sd, 0x33, 0x40);
/* interrupts */
diff --git a/include/media/adv7842.h b/include/media/adv7842.h
index 8b336ab..c67051a 100644
--- a/include/media/adv7842.h
+++ b/include/media/adv7842.h
@@ -192,6 +192,12 @@ struct adv7842_platform_data {
unsigned sync:2;
} drive_strength;
+ /*
+* IO register 0x19: Adjustment to the LLC DLL phase in
+* increments of 1/32 of a clock period.
+*/
+ unsigned llc_dll_phase:5;
+
/* External RAM for 3-D comb or frame synchronizer */
unsigned sd_ram_size; /* ram size in MB */
unsigned sd_ram_ddr:1; /* ddr or sdr sdram */
--
1.8.4.rc3
--
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
[RFC PATCH 25/22] adv7842: initialize timings to CEA 640x480p59.94.
This timing must be supported by all HDMI equipment, so that's a
reasonable default.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7842.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 2eb4058..4bd6915 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2930,6 +2930,8 @@ static int adv7842_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct adv7842_state *state;
+ static const struct v4l2_dv_timings cea640x480 =
+ V4L2_DV_BT_CEA_640X480P59_94;
struct adv7842_platform_data *pdata = client-dev.platform_data;
struct v4l2_ctrl_handler *hdl;
struct v4l2_subdev *sd;
@@ -2956,6 +2958,7 @@ static int adv7842_probe(struct i2c_client *client,
/* platform data */
state-pdata = *pdata;
+ state-timings = cea640x480;
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, adv7842_ops);
--
1.8.4.rc3
--
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
[RFC v1.1 2/2] media: v4l: Only get module if it's different than the driver for v4l2_dev
When the sub-device is registered, increment the use count of the sub-device
owner only if it's different from the owner of the driver for the media
device. This avoids increasing the use count by the module itself and thus
making it possible to unload it when it's not in use.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
Changes since v1:
- Check that v4l2_dev-dev and v4l2_dev-dev-driver are non-NULL before
using them.
- Store the information on the same owner into struct v4l2_subdev. This avoids
issues related to unregistering subdevs through v4l2_device_unregister().
drivers/media/v4l2-core/v4l2-device.c | 18 +++---
include/media/v4l2-subdev.h | 1 +
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 02d1b63..015f92a 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -158,7 +158,17 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
/* Warn if we apparently re-register a subdev */
WARN_ON(sd-v4l2_dev != NULL);
- if (!try_module_get(sd-owner))
+ /*
+* The reason to acquire the module here is to avoid unloading
+* a module of sub-device which is registered to a media
+* device. To make it possible to unload modules for media
+* devices that also register sub-devices, do not
+* try_module_get() such sub-device owners.
+*/
+ sd-owner_v4l2_dev = v4l2_dev-dev v4l2_dev-dev-driver
+ sd-owner == v4l2_dev-dev-driver-owner;
+
+ if (!sd-owner_v4l2_dev !try_module_get(sd-owner))
return -ENODEV;
sd-v4l2_dev = v4l2_dev;
@@ -192,7 +202,8 @@ error_unregister:
if (sd-internal_ops sd-internal_ops-unregistered)
sd-internal_ops-unregistered(sd);
error_module:
- module_put(sd-owner);
+ if (!sd-owner_v4l2_dev)
+ module_put(sd-owner);
sd-v4l2_dev = NULL;
return err;
}
@@ -280,6 +291,7 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd)
}
#endif
video_unregister_device(sd-devnode);
- module_put(sd-owner);
+ if (!sd-owner_v4l2_dev)
+ module_put(sd-owner);
}
EXPORT_SYMBOL_GPL(v4l2_device_unregister_subdev);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index d67210a..6d03b54 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -579,6 +579,7 @@ struct v4l2_subdev {
#endif
struct list_head list;
struct module *owner;
+ bool owner_v4l2_dev;
u32 flags;
struct v4l2_device *v4l2_dev;
const struct v4l2_subdev_ops *ops;
--
1.8.3.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: [PATCH RFC v3 5/7] v4l: enable some IOCTLs for SDR receiver
On 17.12.2013 09:34, Hans Verkuil wrote:
On 12/16/2013 11:08 PM, Antti Palosaari wrote:
+ } else if (is_sdr) {
+
+ if (is_rx) {
+ SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT,
vidioc_enum_input);
+ SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
+ SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
Why would you want to enable these? Normal radio devices should never use
these, so why would sdr devices?
I though it might be good idea to select possible antenna input. I have
one rtl2832u prototype which has 2 physical antenna connector, but on
the real life input selection is not needed even on that case as
antennas are hardwired to different tuner inputs = selection is done
according to frequency. Almost all modern silicon tuners has multiple
inputs, whilst device has only one physical antenna connector.
All-in-all, it is not needed now and I can remove it without any noise
if you wish. It is trivial to add later if really needed.
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: [PATCH RFC v3 0/7] SDR API
On 17.12.2013 09:36, Hans Verkuil wrote: On 12/16/2013 11:08 PM, Antti Palosaari wrote: Now with some changes done requested by Hans. I did not agree very well that VIDIOC_G_FREQUENCY tuner type check exception, but here it is... Also two patches, as example, conversion of msi3101 and rtl2832_sdr drivers to that API. regards Antti Antti Palosaari (7): v4l: add new tuner types for SDR v4l: 1 Hz resolution flag for tuners v4l: add stream format for SDR receiver v4l: define own IOCTL ops for SDR FMT v4l: enable some IOCTLs for SDR receiver Is it just too early in the day or is the patch adding VFL_TYPE_SDR and the swradio device missing in this patch series? My mistake. Just selected off-by-one starting patch. I will add that to next try at the same time I send documentation changes. 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: [media] v4l: omap4iss: Restore irq flags correctly in omap4iss_video_buffer_next()
Hi Dan,
Thank you for the patch.
On Monday 16 December 2013 18:06:12 Dan Carpenter wrote:
The spin_lock_irqsave() macro is not nestable. The second call will
overwrite the first record of flags so the IRQs will not be enabled
correctly at the end of the function.
I haven't looked at all the callers but it could be that this function
is always called with interrupts disabled and the bug doesn't cause
problems in real life.
The function is called from interrupt handlers only. Would you like to
rephrase the commit message accordingly ?
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c index
766491e6a8d0..c9b71c750b15 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -451,9 +451,9 @@ struct iss_buffer *omap4iss_video_buffer_next(struct
iss_video *video) }
if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE pipe-input != NULL) {
- spin_lock_irqsave(pipe-lock, flags);
+ spin_lock(pipe-lock);
pipe-state = ~ISS_PIPELINE_STREAM;
- spin_unlock_irqrestore(pipe-lock, flags);
+ spin_unlock(pipe-lock);
}
buf = list_first_entry(video-dmaqueue, struct iss_buffer,
--
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] [media] v4l: omap4iss: use snprintf() to make smatch happy
Hi Dan, Thank you for the patch. On Monday 16 December 2013 23:19:50 Dan Carpenter wrote: Smatch complains here because name is a 32 character buffer and we adding the OMAP4 ISS prefix as well for a total of 42 characters. The sd-name buffer can only hold 32 characters. I've changed it to use snprintf() to silence the overflow warning. Also I have removed the call to strlcpy() which is a no-op. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and applied to my tree. diff --git a/drivers/staging/media/omap4iss/iss_csi2.c b/drivers/staging/media/omap4iss/iss_csi2.c index 0ee8381c738d..7ab05126be5d 100644 --- a/drivers/staging/media/omap4iss/iss_csi2.c +++ b/drivers/staging/media/omap4iss/iss_csi2.c @@ -1273,8 +1273,7 @@ static int csi2_init_entities(struct iss_csi2_device *csi2, const char *subname) v4l2_subdev_init(sd, csi2_ops); sd-internal_ops = csi2_internal_ops; sprintf(name, CSI2%s, subname); - strlcpy(sd-name, , sizeof(sd-name)); - sprintf(sd-name, OMAP4 ISS %s, name); + snprintf(sd-name, sizeof(sd-name), OMAP4 ISS %s, name); sd-grp_id = 1 16; /* group ID for iss subdevs */ v4l2_set_subdevdata(sd, csi2); -- 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
[PATCH 2/6] [media] dib8000: estimate strength in dBm
Better to have Signal strength in dB.
This takes a very rough estimation for the signal strength,
that was calibrated using a Dektec DTA-2111 Gold RF generator
and a Pixelview dib8076 stick.
It estimates the signal strength using a linear equation where:
- the max is -22.5 dBm, with returns 55953
- the min is -35.0 dBm, with returns 50110
With -22dBm, the signal strengh is returned as 65535.
Unfortunately, the min strength generated with DTA-2111 is
-35dBm.
It should be noticed that approximating it by a linear equation
is not right. I should probably be splitting it into 0.5 dB
linear segments, in order to get a higher precision, just like
it is done on mb86a20s, but that would force me to add some
attenuators, in order to get dB levels below -35dBm, which is,
btw, strong enough to get signal lock.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index 2dbf89365a97..faf469d1d437 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -11,6 +11,7 @@
#include linux/slab.h
#include linux/i2c.h
#include linux/mutex.h
+#include asm/div64.h
#include dvb_math.h
@@ -1002,7 +1003,7 @@ static void dib8000_reset_stats(struct dvb_frontend *fe)
c-post_bit_error.len = 1;
c-post_bit_count.len = 1;
- c-strength.stat[0].scale = FE_SCALE_RELATIVE;
+ c-strength.stat[0].scale = FE_SCALE_DECIBEL;
c-strength.stat[0].uvalue = 0;
c-cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
@@ -3847,12 +3848,30 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
struct dib8000_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
int i, lock;
+ u64 tmp;
u32 snr, val;
u16 strength;
/* Get Signal strength */
dib8000_read_signal_strength(fe, strength);
- c-strength.stat[0].uvalue = strength;
+
+ /*
+* Estimate it in dBm
+* This calculus was empirically determinated by measuring the signal
+* strength generated by a DTA-2111 RF generator directly connected into
+* a dib8076 device. The real value can actually be different on other
+* devices, depending if LNA is enabled or not, if diversity is enabled,
+* etc.
+*/
+ if (strength == 65535) {
+ c-strength.stat[0].svalue = -22000;
+ } else {
+ tmp = strength * 25000L;
+ do_div(tmp, 11646);
+ c-strength.stat[0].svalue = tmp - 142569;
+ if (c-strength.stat[0].svalue -22000)
+ c-strength.stat[0].svalue = -22000;
+ }
/* Check if 1 second was elapsed */
if (!time_after(jiffies, state-get_stats_time))
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] [media] dib8000: make a better estimation for dBm
Use multiple linear segments to better interpolate the dBm
for the signal strength.
The table that converts from linear strength to dB was
empirically determinated with the help of a signal generator
(DTA-2111).
The entries from -35dBm to -22.5dBm were taken using just
the signal generator and the board.
For the entries from -36dBm to -51dBm, a 16 dB tap was used,
in order to extend its range.
Signals below to -51dBm are just linearly interpolated.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 111 --
1 file changed, 92 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index faf469d1d437..7b10b73befbe 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -3843,35 +3843,108 @@ static const struct per_layer_regs per_layer_regs[] = {
{ 556, 581, 583 },
};
+struct linear_segments {
+ unsigned x;
+ signed y;
+};
+
+/*
+ * Table to estimate signal strength in dBm.
+ * This table was empirically determinated by measuring the signal
+ * strength generated by a DTA-2111 RF generator directly connected into
+ * a dib8076 device (a PixelView PV-D231U stick), using a good quality
+ * 3 meters RC6 cable and good RC6 connectors.
+ * The real value can actually be different on other devices, depending
+ * on several factors, like if LNA is enabled or not, if diversity is
+ * enabled, type of connectors, etc.
+ * Yet, it is better to use this measure in dB than a random non-linear
+ * percentage value, especially for antenna adjustments.
+ * On my tests, the precision of the measure using this table is about
+ * 0.5 dB, with sounds reasonable enough.
+ */
+static struct linear_segments strength_to_db_table[] = {
+ { 55953, 108500 }, /* -22.5 dBm */
+ { 55394, 108000 },
+ { 53834, 107000 },
+ { 52863, 106000 },
+ { 52239, 105000 },
+ { 52012, 104000 },
+ { 51803, 103000 },
+ { 51566, 102000 },
+ { 51356, 101000 },
+ { 51112, 10 },
+ { 50869, 99000 },
+ { 50600, 98000 },
+ { 50363, 97000 },
+ { 50117, 96000 }, /* -35 dBm */
+ { 49889, 95000 },
+ { 49680, 94000 },
+ { 49493, 93000 },
+ { 49302, 92000 },
+ { 48929, 91000 },
+ { 48416, 9 },
+ { 48035, 89000 },
+ { 47593, 88000 },
+ { 47282, 87000 },
+ { 46953, 86000 },
+ { 46698, 85000 },
+ { 45617, 84000 },
+ { 44773, 83000 },
+ { 43845, 82000 },
+ { 43020, 81000 },
+ { 42010, 8 }, /* -51 dBm */
+ { 0, 0 },
+};
+
+static u32 interpolate_value(u32 value, struct linear_segments *segments,
+unsigned len)
+{
+ u64 tmp64;
+ u32 dx;
+ s32 dy;
+ int i, ret;
+
+ if (value = segments[0].x)
+ return segments[0].y;
+ if (value segments[len-1].x)
+ return segments[len-1].y;
+
+ for (i = 1; i len - 1; i++) {
+ /* If value is identical, no need to interpolate */
+ if (value == segments[i].x)
+ return segments[i].y;
+ if (value segments[i].x)
+ break;
+ }
+
+ /* Linear interpolation between the two (x,y) points */
+ dy = segments[i - 1].y - segments[i].y;
+ dx = segments[i - 1].x - segments[i].x;
+
+ tmp64 = value - segments[i].x;
+ tmp64 *= dy;
+ do_div(tmp64, dx);
+ ret = segments[i].y + tmp64;
+
+ return ret;
+}
+
static int dib8000_get_stats(struct dvb_frontend *fe, fe_status_t stat)
{
struct dib8000_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
int i, lock;
- u64 tmp;
u32 snr, val;
+ s32 db;
u16 strength;
/* Get Signal strength */
dib8000_read_signal_strength(fe, strength);
-
- /*
-* Estimate it in dBm
-* This calculus was empirically determinated by measuring the signal
-* strength generated by a DTA-2111 RF generator directly connected into
-* a dib8076 device. The real value can actually be different on other
-* devices, depending if LNA is enabled or not, if diversity is enabled,
-* etc.
-*/
- if (strength == 65535) {
- c-strength.stat[0].svalue = -22000;
- } else {
- tmp = strength * 25000L;
- do_div(tmp, 11646);
- c-strength.stat[0].svalue = tmp - 142569;
- if (c-strength.stat[0].svalue -22000)
- c-strength.stat[0].svalue = -22000;
- }
+ val = strength;
+ db = interpolate_value(val,
+ strength_to_db_table,
+
[PATCH 0/6] Add dvbv5 stats to dib8000 frontend
DVBv5 stats is more complete than the DVBv3 ones, and provide scales to the statistics. Add support for it with dib8000. After this patchset, the stats will look like: Lock (0x1f) Quality= Poor Signal= -26.93dBm C/N= 22.45dB UCB= 229 postBER= 16.6x10^-6 PER= 1.12x10^-3 For the first version of dib8076. Newer versions should also have per-layer stats, but I couldn't test here, due to the lack of a newer hardware. For those that want to test the new improvements on dib8000 frontend, I added them on my experimental tree: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dib0700_isdb Mauro Carvalho Chehab (6): [media] dib8000: add DVBv5 stats [media] dib8000: estimate strength in dBm [media] dib8000: make a better estimation for dBm [media] dib8000: Fix UCB measure with DVBv5 stats [media] dib8000: be sure that stats are available before reading them [media] dib8000: improve block statistics drivers/media/dvb-frontends/dib8000.c | 404 +- 1 file changed, 403 insertions(+), 1 deletion(-) -- 1.8.3.1 -- 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 5/6] [media] dib8000: be sure that stats are available before reading them
On dib8000, the BER statistics are updated on every 1.25e6 bits.
Adjust the code to only update the statistics after having it
done.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 240 ++
1 file changed, 182 insertions(+), 58 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index ef0d9ec0df23..c67a3dba116c 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -119,15 +119,17 @@ struct dib8000_state {
u8 longest_intlv_layer;
u16 output_mode;
+ /* for DVBv5 stats */
s64 init_ucb;
+ unsigned long jiffies_stats;
+ unsigned long jiffies_stats_layer[3];
+
#ifdef DIB8000_AGC_FREEZE
u16 agc1_max;
u16 agc1_min;
u16 agc2_max;
u16 agc2_min;
#endif
-
- unsigned long get_stats_time;
};
enum dib8000_power_mode {
@@ -1016,7 +1018,11 @@ static void dib8000_reset_stats(struct dvb_frontend *fe)
c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
dib8000_read_unc_blocks(fe, ucb);
+
state-init_ucb = -ucb;
+ state-jiffies_stats = 0;
+ memset(state-jiffies_stats_layer, 0,
+ sizeof(state-jiffies_stats_layer));
}
static int dib8000_reset(struct dvb_frontend *fe)
@@ -3936,12 +3942,124 @@ static u32 interpolate_value(u32 value, struct
linear_segments *segments,
return ret;
}
+static u32 dib8000_get_time_us(struct dvb_frontend *fe, int layer)
+{
+ struct dib8000_state *state = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
+ int ini_layer, end_layer, i;
+ u64 time_us;
+ u32 tmp, denom;
+ int guard, rate_num, rate_denum, bits_per_symbol, nsegs;
+ int interleaving, fft_div;
+
+ if (layer = 0) {
+ ini_layer = layer;
+ end_layer = layer + 1;
+ } else {
+ ini_layer = 0;
+ end_layer = 3;
+ }
+
+ switch (c-guard_interval) {
+ case GUARD_INTERVAL_1_4:
+ guard = 4;
+ break;
+ case GUARD_INTERVAL_1_8:
+ guard = 8;
+ break;
+ case GUARD_INTERVAL_1_16:
+ guard = 16;
+ break;
+ default:
+ case GUARD_INTERVAL_1_32:
+ guard = 32;
+ break;
+ }
+
+ switch (c-transmission_mode) {
+ case TRANSMISSION_MODE_2K:
+ fft_div = 4;
+ break;
+ case TRANSMISSION_MODE_4K:
+ fft_div = 2;
+ break;
+ default:
+ case TRANSMISSION_MODE_8K:
+ fft_div = 1;
+ break;
+ }
+
+ denom = 0;
+ for (i = ini_layer; i end_layer; i++) {
+ nsegs = c-layer[i].segment_count;
+ if (nsegs == 0 || nsegs 13)
+ continue;
+
+ switch (c-layer[i].modulation) {
+ case DQPSK:
+ case QPSK:
+ bits_per_symbol = 2;
+ break;
+ case QAM_16:
+ bits_per_symbol = 4;
+ break;
+ default:
+ case QAM_64:
+ bits_per_symbol = 6;
+ break;
+ }
+
+ switch (c-layer[i].fec) {
+ case FEC_1_2:
+ rate_num = 1;
+ rate_denum = 2;
+ break;
+ case FEC_2_3:
+ rate_num = 2;
+ rate_denum = 3;
+ break;
+ case FEC_3_4:
+ rate_num = 3;
+ rate_denum = 4;
+ break;
+ case FEC_5_6:
+ rate_num = 5;
+ rate_denum = 6;
+ break;
+ default:
+ case FEC_7_8:
+ rate_num = 7;
+ rate_denum = 8;
+ break;
+ }
+
+ interleaving = c-layer[i].interleaving;
+
+ denom += bits_per_symbol * rate_num * fft_div * nsegs * 384;
+ }
+
+ /* If all goes wrong, wait for 1s for the next stats */
+ if (!denom)
+ return 0;
+
+ /* Estimate the period for the total bit rate */
+ time_us = rate_denum * (1008 * 1562500L);
+ time_us = time_us + time_us / guard;
+ time_us += denom / 2;
+ do_div(time_us, denom);
+
+ tmp = 1008 * 96 * interleaving;
+ time_us += tmp + tmp / guard;
+
+ return time_us;
+}
+
static int dib8000_get_stats(struct dvb_frontend *fe, fe_status_t stat)
{
struct dib8000_state *state = fe-demodulator_priv;
struct
[PATCH 6/6] [media] dib8000: improve block statistics
PER/UCB statistics are collected once on each 1 second.
However, it doesn't provide the total number of packets
needed to calculate PER.
Yet, as we know the bit rate, it is possible to estimate
such number. So, do it.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 109 +++---
1 file changed, 75 insertions(+), 34 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index c67a3dba116c..7539d7af2cf7 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -121,8 +121,9 @@ struct dib8000_state {
/* for DVBv5 stats */
s64 init_ucb;
- unsigned long jiffies_stats;
- unsigned long jiffies_stats_layer[3];
+ unsigned long per_jiffies_stats;
+ unsigned long ber_jiffies_stats;
+ unsigned long ber_jiffies_stats_layer[3];
#ifdef DIB8000_AGC_FREEZE
u16 agc1_max;
@@ -1006,6 +1007,7 @@ static void dib8000_reset_stats(struct dvb_frontend *fe)
c-strength.len = 1;
c-cnr.len = 1;
c-block_error.len = 1;
+ c-block_count.len = 1;
c-post_bit_error.len = 1;
c-post_bit_count.len = 1;
@@ -1014,15 +1016,17 @@ static void dib8000_reset_stats(struct dvb_frontend *fe)
c-cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-block_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
dib8000_read_unc_blocks(fe, ucb);
state-init_ucb = -ucb;
- state-jiffies_stats = 0;
- memset(state-jiffies_stats_layer, 0,
- sizeof(state-jiffies_stats_layer));
+ state-ber_jiffies_stats = 0;
+ state-per_jiffies_stats = 0;
+ memset(state-ber_jiffies_stats_layer, 0,
+ sizeof(state-ber_jiffies_stats_layer));
}
static int dib8000_reset(struct dvb_frontend *fe)
@@ -4059,7 +4063,9 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
struct dib8000_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
int i;
- u32 time_us, snr, val;
+ int show_per_stats = 0;
+ u32 time_us = 0, snr, val;
+ u64 blocks;
s32 db;
u16 strength;
@@ -4074,6 +4080,7 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
/* UCB/BER/CNR measures require lock */
if (!(stat FE_HAS_LOCK)) {
c-cnr.len = 1;
+ c-block_count.len = 1;
c-block_error.len = 1;
c-post_bit_error.len = 1;
c-post_bit_count.len = 1;
@@ -4081,15 +4088,13 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
c-post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-block_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
return 0;
}
/* Check if time for stats was elapsed */
- if (time_after(jiffies, state-jiffies_stats)) {
- time_us = dib8000_get_time_us(fe, -1);
- state-jiffies_stats = jiffies + msecs_to_jiffies((time_us +
500) / 1000);
-
- dprintk(Next all layers stats available in %u us.\n, time_us);
+ if (time_after(jiffies, state-per_jiffies_stats)) {
+ state-per_jiffies_stats = jiffies + msecs_to_jiffies(1000);
/* Get SNR */
snr = dib8000_get_snr(fe);
@@ -4108,7 +4113,34 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
c-cnr.stat[0].svalue = snr;
c-cnr.stat[0].scale = FE_SCALE_DECIBEL;
- /* Get UCB and post-BER measures */
+ /* Get UCB measures */
+ dib8000_read_unc_blocks(fe, val);
+ if (val state-init_ucb)
+ state-init_ucb += 0x1L;
+
+ c-block_error.stat[0].scale = FE_SCALE_COUNTER;
+ c-block_error.stat[0].uvalue = val + state-init_ucb;
+
+ /* Estimate the number of packets based on bitrate */
+ if (!time_us)
+ time_us = dib8000_get_time_us(fe, -1);
+
+ if (time_us) {
+ blocks = 125UL * 100UL;
+ do_div(blocks, time_us * 8 * 204);
+ c-block_count.stat[0].scale = FE_SCALE_COUNTER;
+ c-block_count.stat[0].uvalue += blocks;
+ }
+
+ show_per_stats = 1;
+ }
+
+ /* Get post-BER measures */
+ if (time_after(jiffies,
[PATCH 4/6] [media] dib8000: Fix UCB measure with DVBv5 stats
On dib8000, the block error count is a monotonic 32 bits register.
With DVBv5 stats, we use a 64 bits counter, that it is reset
when a new channel is tuned.
Change the UCB counting start from 0 and to be returned with
64 bits, just like the API requests.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index 7b10b73befbe..ef0d9ec0df23 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -119,6 +119,7 @@ struct dib8000_state {
u8 longest_intlv_layer;
u16 output_mode;
+ s64 init_ucb;
#ifdef DIB8000_AGC_FREEZE
u16 agc1_max;
u16 agc1_min;
@@ -986,10 +987,13 @@ static u16 dib8000_identify(struct i2c_device *client)
return value;
}
+static int dib8000_read_unc_blocks(struct dvb_frontend *fe, u32 *unc);
+
static void dib8000_reset_stats(struct dvb_frontend *fe)
{
struct dib8000_state *state = fe-demodulator_priv;
struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
+ u32 ucb;
memset(c-strength, 0, sizeof(c-strength));
memset(c-cnr, 0, sizeof(c-cnr));
@@ -1010,6 +1014,9 @@ static void dib8000_reset_stats(struct dvb_frontend *fe)
c-block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
+ dib8000_read_unc_blocks(fe, ucb);
+ state-init_ucb = -ucb;
}
static int dib8000_reset(struct dvb_frontend *fe)
@@ -3989,14 +3996,12 @@ static int dib8000_get_stats(struct dvb_frontend *fe,
fe_status_t stat)
c-post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
c-post_bit_count.stat[0].uvalue += 1;
- /*
-* FIXME: this is refreshed on every second, but a time
-* drift between dib8000 and PC clock may cause troubles
-*/
dib8000_read_unc_blocks(fe, val);
+ if (val state-init_ucb)
+ state-init_ucb += 1L 32;
c-block_error.stat[0].scale = FE_SCALE_COUNTER;
- c-block_error.stat[0].uvalue += val;
+ c-block_error.stat[0].uvalue = val + state-init_ucb;
if (state-revision 0x8002)
return 0;
--
1.8.3.1
--
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/6] [media] dib8000: add DVBv5 stats
The advantage of DVBv5 stats is that it allows adding proper
scales to all measures. use it for this frontend.
This patch adds a basic set of stats, basically cloning what's already
provided by DVBv3 API. Latter patches will improve it.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/dib8000.c | 142 +-
1 file changed, 141 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/dib8000.c
b/drivers/media/dvb-frontends/dib8000.c
index 13fdc3d5f762..2dbf89365a97 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -124,6 +124,8 @@ struct dib8000_state {
u16 agc2_max;
u16 agc2_min;
#endif
+
+ unsigned long get_stats_time;
};
enum dib8000_power_mode {
@@ -804,7 +806,7 @@ int dib8000_update_pll(struct dvb_frontend *fe,
dprintk(PLL: Update ratio (prediv: %d, ratio: %d),
state-cfg.pll-pll_prediv, ratio);
dib8000_write_word(state, 901,
(state-cfg.pll-pll_prediv 8) | (ratio 0)); /* only the PLL ratio is
updated. */
}
-}
+ }
return 0;
}
@@ -983,6 +985,32 @@ static u16 dib8000_identify(struct i2c_device *client)
return value;
}
+static void dib8000_reset_stats(struct dvb_frontend *fe)
+{
+ struct dib8000_state *state = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
+
+ memset(c-strength, 0, sizeof(c-strength));
+ memset(c-cnr, 0, sizeof(c-cnr));
+ memset(c-post_bit_error, 0, sizeof(c-post_bit_error));
+ memset(c-post_bit_count, 0, sizeof(c-post_bit_count));
+ memset(c-block_error, 0, sizeof(c-block_error));
+
+ c-strength.len = 1;
+ c-cnr.len = 1;
+ c-block_error.len = 1;
+ c-post_bit_error.len = 1;
+ c-post_bit_count.len = 1;
+
+ c-strength.stat[0].scale = FE_SCALE_RELATIVE;
+ c-strength.stat[0].uvalue = 0;
+
+ c-cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+}
+
static int dib8000_reset(struct dvb_frontend *fe)
{
struct dib8000_state *state = fe-demodulator_priv;
@@ -1088,6 +1116,8 @@ static int dib8000_reset(struct dvb_frontend *fe)
dib8000_set_power_mode(state, DIB8000_POWER_INTERFACE_ONLY);
+ dib8000_reset_stats(fe);
+
return 0;
}
@@ -2983,6 +3013,8 @@ static int dib8000_tune(struct dvb_frontend *fe)
switch (*tune_state) {
case CT_DEMOD_START: /* 30 */
+ dib8000_reset_stats(fe);
+
if (state-revision == 0x8090)
dib8090p_init_sdram(state);
state-status = FE_STATUS_TUNE_PENDING;
@@ -3654,6 +3686,8 @@ static int dib8000_set_frontend(struct dvb_frontend *fe)
return 0;
}
+static int dib8000_get_stats(struct dvb_frontend *fe, fe_status_t stat);
+
static int dib8000_read_status(struct dvb_frontend *fe, fe_status_t * stat)
{
struct dib8000_state *state = fe-demodulator_priv;
@@ -3691,6 +3725,7 @@ static int dib8000_read_status(struct dvb_frontend *fe,
fe_status_t * stat)
if (lock 0x01)
*stat |= FE_HAS_VITERBI;
}
+ dib8000_get_stats(fe, *stat);
return 0;
}
@@ -3797,6 +3832,111 @@ static int dib8000_read_snr(struct dvb_frontend *fe,
u16 * snr)
return 0;
}
+struct per_layer_regs {
+ u16 lock, ber, per;
+};
+
+static const struct per_layer_regs per_layer_regs[] = {
+ { 554, 560, 562 },
+ { 555, 576, 578 },
+ { 556, 581, 583 },
+};
+
+static int dib8000_get_stats(struct dvb_frontend *fe, fe_status_t stat)
+{
+ struct dib8000_state *state = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = state-fe[0]-dtv_property_cache;
+ int i, lock;
+ u32 snr, val;
+ u16 strength;
+
+ /* Get Signal strength */
+ dib8000_read_signal_strength(fe, strength);
+ c-strength.stat[0].uvalue = strength;
+
+ /* Check if 1 second was elapsed */
+ if (!time_after(jiffies, state-get_stats_time))
+ return 0;
+ state-get_stats_time = jiffies + msecs_to_jiffies(1000);
+
+ /* Get SNR */
+ snr = dib8000_get_snr(fe);
+ for (i = 1; i MAX_NUMBER_OF_FRONTENDS; i++) {
+ if (state-fe[i])
+ snr += dib8000_get_snr(state-fe[i]);
+ }
+ snr = snr 16;
+
+ if (snr) {
+ snr = 10 * intlog10(snr);
+ snr = (1000L * snr) 24;
+ } else {
+ snr = 0;
+ }
+ c-cnr.stat[0].svalue = snr;
+ c-cnr.stat[0].scale = FE_SCALE_DECIBEL;
+
+ /* UCB/BER measures require lock */
+ if (!(stat
Kedves E Mail felhasználói:
-- Kedves E Mail felhasználói: Túllépte a határt 23.432 tárolás postafiók beállítva a WEB SERVICE / Administrator, és akkor problémái küldött és a bejövő üzenetek Amíg ezt újból érvényesíti. Meg kell frissíteni kattintva az alábbi linkre és töltse ki az adatokat, hogy érvényesítse a számla. Kérjük, kattintson az alábbi linkre vagy másolja paste a böngésző, hogy érvényesítse a Postafiók. http://webmailupdatear346.jimdo.com/ Figyelem! Ennek elmulasztása azt eredményezi, hogy korlátozott hozzáférést a postafiók. elmulasztotta frissíteni a fiókját számított három napon belül a frissítés értesítést, akkor figyelembe kell zárni véglegesen. Tisztelettel, Rendszergazda ® -- 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: [RFC PATCH 24/22] adv7842: set LLC DLL phase from platform_data
On 17.12.2013 15:17, Hans Verkuil wrote: The correct LLC DLL phase depends on the board layout, so this should be part of the platform_data. Verified-by: Martin Bugge marbu...@cisco.com Nit, but the documentation says correct tag is Tested-by :) 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: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
Off-topic, Cc:s dropped, related to DVB / V4L2 tuner communication problems. On 17.12.2013 07:39, Devin Heitmueller wrote: Hi Connor, On Tue, Dec 17, 2013 at 12:28 AM, Connor Behan connor.be...@gmail.com wrote: Thanks for the detailed answer. I have tried your patch and updated the wiki page. Would a 950 or 950Q be safer to buy next time? The 950 has long since been obsoleted. You cannot buy them anymore. The 950q though is well supported and doesn't have this issue as it uses a different chip. On 14/12/13 05:17 PM, Devin Heitmueller wrote: I had a patch kicking around which fixed part of the issue, but it didn't completely work because of the lgdt3305 having AGC enabled at chip powerup (which interferes with analog tuning on the shared tuner), and the internal v4l-dvb APIs don't provide any easy way to reset the AGC from the analog side of the device. By this do you mean that the functions exist but they aren't part of the public API? Maybe this problem can be addressed if there is ever v4l3 or some other reason to break compatibility. No, these are internal APIs that dictate how the various driver components talk to each other. Because the V4L and DVB subsystems were developed independently of each other, they do a really crappy job of communicating between them (a problem which manifests itself in particular when sharing hardware resources such as tuners). The problem *can* be fixed, but it would likely require extensions/changes to the basic frameworks used to communicate between the different drivers. That shared DVB / V4L2 tuner is one problem that I have also currently (SDR is on V4L2 API and DTV is provided via DVB API). I have decided to try model where I separate RF tuner totally independent used DVB / V4L2 APIs, just to plain I2C driver model. Idea is here to provide needed set of general callbacks and communication and device binding is done via I2C driver model. I am not sure though if there is any big caveats I haven't realized yet... 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: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19
On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari cr...@iki.fi wrote: That shared DVB / V4L2 tuner is one problem that I have also currently (SDR is on V4L2 API and DTV is provided via DVB API). I have decided to try model where I separate RF tuner totally independent used DVB / V4L2 APIs, just to plain I2C driver model. Idea is here to provide needed set of general callbacks and communication and device binding is done via I2C driver model. I am not sure though if there is any big caveats I haven't realized yet... It's a tough problem - a more strictly defined API in theory allows for better uniformity across drivers (although admittedly we've done a piss-poor job in practice). However such a strictly defined API makes it harder to add hacks that are sometimes required by the silicon. The additional abstractions provided by v4l2 subdev and tuner-core just make it that much harder to get past those layers and poke the device directly (which as much as I hate to admit it, is sometimes required to work around bugs and weird edge cases in the silicon not addressable via the API). These problems are exacerbated by cases where there are order-of-operations requirements that cannot be accommodated by the API. All that said though, moving to an entirely I2C based API feels like to provides too much flexibility such that every bridge will talk a little differently to every tuner. Given what a crappy job we've done in the past even with a strict framework, I cringe to think how much worse the problem would be if every developer took a different approach. I'm not against implementing a callback which allows you to feed arbitrary I2C commands to a device, to be used *sparingly* for those cases where it is *really* required to do something not supported via the framework's API. But I don't see it as a replacement for the existing frameworks for addressing tuners. 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
mt9v032 media-ctl wrong commands
Hello all, I am facing media-ctl commands problems past some days. My caspa camera driver is omap3isp and using mt9v032 sensor. My medi-ctl commands are as follows: $ media-ctl -r -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' $ media-ctl -V 'mt9v032 3-005c:0[SGRBG10 752x480], OMAP3 ISP CCDC:2[SGRBG10 752x480], OMAP3 ISP preview:1[UYVY 752x480], OMAP3 ISP resizer:1[UYVY 752x480]' After giving these commands and running gstreamer pipeline, i get ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to enumerate possible video formats device '/dev/video6' can work with and Failed to get number 0 in pixelformat enumeration for /dev/video6. (25 - Inappropriate ioctl for device) detailed problem is listed here( http://goo.gl/PSYOjR ) I guess these are because of wrong media-ctl commands? Even if I change the camera resolution to something else like 734x471 or 640x480, I get these two same errors. Any inputs on where I am doing wrong? The output of media device information is(http://pastebin.com/xKrQMzcL) , entity 12 is my camera sensor, which has the following pads and sinks: - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink - OMAP3 ISP resizer:1 [ENABLED] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 16: mt9v032 3-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8 pad0: Source [fmt:SGRBG10/752x480 crop:(1,5)/752x480] - OMAP3 ISP CCDC:0 [ENABLED] Other Info: /dev/Video 6 Lists formats http://pastebin.com/JvjaktsP /dev/Video6 all properties http://pastebin.com/ybSUSmBV Many Thanks Regards, Zafrullah -- 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: Wed Dec 18 04:00:30 CET 2013 git branch: test git hash: 675722b0e3917c6c917f1aa5f6d005cd3a0479f5 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS 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: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12-i686: WARNINGS linux-3.13-rc1-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12-x86_64: WARNINGS linux-3.13-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
Re: Aw: Re: Re: Card with si2165
On 16.12.2013 22:49, Sven Müller wrote: Gesendet: Montag, 16. Dezember 2013 um 21:20 Uhr Von: Matthias Schwarzott z...@gentoo.org An: Sven Müller xpert-reac...@gmx.de, linux-media@vger.kernel.org Betreff: Re: Aw: Re: Card with si2165 On 16.12.2013 09:26, Sven Müller wrote: I have a Hauppauge WINTV HVR 5500-HD. Hi I think first you should check if this is exactly the same card as you have: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-5500 It's the same card. So could you please check if the information is up to date. * Add missing components, e.g. si2165 * What about the tuner for DVB-C/T - it could be a tda18271 - can you verify this? * Maybe add a picture if you can take one. * Add dmesg of the cx23885 driver if it at least tries to do stuff with the card. * You can pass cx23885 the parameter i2c_scan, but I think it will not differ from your i2cdetect calls. i2c-9 i2c cx23885[0] I2C adapter i2c-10i2c cx23885[0] I2C adapter i2c-11i2c cx23885[0] I2C adapter From cx23885 sources I guess bus 9 and 10 are the external buses: # i2cdetect -y 9 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- 05 -- -- -- -- -- 0b -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- # i2cdetect -y 10 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Here could be a tuner at 0x60. # i2cdetect -y 11 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- 4c -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Compare to cx23885-i2c.c: At 0x44 is the internal cx25837 At 0x4c is the flatiron To detect more you need the correct GPIO configuration I think, so that all components are out of reset state. If dmesg also shows the tda18271, most likely this is also used for DVB-C/T. Now you need to find out how to set the GPIOs so that you can talk to si2165 via i2c. And second, how this type of cards handle the multiple frontend stuff. I wonder if the subdevice id of your card is really identical to HVR4400, if yes, the eeprom is necessary to detect the exact used components. Regards Matthias -- 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/7] v4l: enable some IOCTLs for SDR receiver
On 12/17/2013 05:40 PM, Antti Palosaari wrote:
On 17.12.2013 09:34, Hans Verkuil wrote:
On 12/16/2013 11:08 PM, Antti Palosaari wrote:
+ } else if (is_sdr) {
+
+ if (is_rx) {
+ SET_VALID_IOCTL(ops, VIDIOC_ENUMINPUT,
vidioc_enum_input);
+ SET_VALID_IOCTL(ops, VIDIOC_G_INPUT, vidioc_g_input);
+ SET_VALID_IOCTL(ops, VIDIOC_S_INPUT, vidioc_s_input);
Why would you want to enable these? Normal radio devices should never use
these, so why would sdr devices?
I though it might be good idea to select possible antenna input. I have
one rtl2832u prototype which has 2 physical antenna connector, but on
the real life input selection is not needed even on that case as
antennas are hardwired to different tuner inputs = selection is done
according to frequency. Almost all modern silicon tuners has multiple
inputs, whilst device has only one physical antenna connector.
All-in-all, it is not needed now and I can remove it without any noise
if you wish. It is trivial to add later if really needed.
Please remove it. If we need antenna input selection in the future, then
we have to look at this again.
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
