Re: PCTV 800i
John replied off list: http://linux-media.vger.kernel.narkive.com/kAviSkda/chipset-change-for-cx88-board-pinnacle-pctv-hd-800i Wonder if any code was ever integrated? It looks like basics of a patch was developed to support the card but it was incompatible with the existing cards and nobody took the time to understand how to differentiate between the older 800i and the newer 800i. So, the problem fell on the floor. I'll look through my card library. If I have an old _AND_ new rev then I'll find an hour and see if I can find an acceptable solution. Summary: PCTV released a new 800i (quite a while ago) changing the demodulator, which is why the existing driver doesn't work. I have a pair of 800i's with the S5H1409 demodulator, probably from when I did the original 800i support (2008): http://marc.info/?l=linux-dvbm=120032380226094w=2 I don't have a 800i with a s5h1411, so I can't really help without it. -- Steven Toth - 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
[RFCv3 1/2] device: add dma_params-max_segment_count
From: Rob Clark robdcl...@gmail.com
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark robdcl...@gmail.com
[sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
v3: include Robin Murphy's fix[1] for handling '0' as a value for
max_segment_count
v2: minor updates wrt comments on the first version
[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct
device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ if (dev-dma_parms dev-dma_parms-max_segment_count)
+ return dev-dma_parms-max_segment_count;
+ return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev-dma_parms) {
+ dev-dma_parms-max_segment_count = count;
+ return 0;
+ }
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev-dma_parms ?
--
1.9.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
[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
device_dma_parameters.
In case the attaching device's constraints don't match up, attach() fails.
At detach, the constraints are recalculated based on the remaining
attached devices.
Two helpers are added:
- dma_buf_get_constraints - which gives the current constraints as calculated
during each attach on the buffer till the time,
- dma_buf_recalc_constraints - which recalculates the constraints for all
currently attached devices for the 'paranoid' ones amongst us.
The idea of this patch is largely taken from Rob Clark's RFC at
https://lkml.org/lkml/2012/7/19/285, and the comments received on it.
Cc: Rob Clark robdcl...@gmail.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
v3:
- Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
constraints' calculation; has a nice side effect of letting us use
device_dma_parameters directly to list constraints.
- update the debugfs output to show constraint info as well.
v2: split constraints-sharing and allocation helpers
drivers/dma-buf/dma-buf.c | 126 +-
include/linux/dma-buf.h | 7 +++
2 files changed, 132 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..f363f1440803 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
return file-f_op == dma_buf_fops;
}
+static inline void init_constraints(struct device_dma_parameters *cons)
+{
+ cons-max_segment_count = (unsigned int)-1;
+ cons-max_segment_size = (unsigned int)-1;
+ cons-segment_boundary_mask = (unsigned long)-1;
+}
+
+/*
+ * calc_constraints - calculates if the new attaching device's constraints
+ * match, with the constraints of already attached devices; if yes, returns
+ * the constraints; else return ERR_PTR(-EINVAL)
+ */
+static int calc_constraints(struct device *dev,
+ struct device_dma_parameters *calc_cons)
+{
+ struct device_dma_parameters cons = *calc_cons;
+
+ cons.max_segment_count = min(cons.max_segment_count,
+ dma_get_max_seg_count(dev));
+ cons.max_segment_size = min(cons.max_segment_size,
+ dma_get_max_seg_size(dev));
+ cons.segment_boundary_mask = dma_get_seg_boundary(dev);
+
+ if (!cons.max_segment_count ||
+ !cons.max_segment_size ||
+ !cons.segment_boundary_mask) {
+ pr_err(Dev: %s's constraints don't match\n, dev_name(dev));
+ return -EINVAL;
+ }
+
+ *calc_cons = cons;
+
+ return 0;
+}
+
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ * useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ * helper.
+ * Returns recalculated constraints in recalc_cons, or error in the unlikely
+ * case when constraints of attached devices might have changed.
+ */
+static int recalc_constraints(struct dma_buf *dmabuf,
+ struct device_dma_parameters *recalc_cons)
+{
+ struct device_dma_parameters calc_cons;
+ struct dma_buf_attachment *attach;
+ int ret = 0;
+
+ init_constraints(calc_cons);
+
+ list_for_each_entry(attach, dmabuf-attachments, node) {
+ ret = calc_constraints(attach-dev, calc_cons);
+ if (ret)
+ return ret;
+ }
+ *recalc_cons = calc_cons;
+ return 0;
+}
+
/**
* dma_buf_export_named - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
@@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf-ops = ops;
dmabuf-size = size;
dmabuf-exp_name = exp_name;
+
+ init_constraints(dmabuf-constraints);
+
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
@@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
struct device *dev)
{
struct dma_buf_attachment *attach;
- int ret;
+ int ret = 0;
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
mutex_lock(dmabuf-lock);
+ if (calc_constraints(dev, dmabuf-constraints))
+ goto err_constraints;
+
if (dmabuf-ops-attach) {
ret = dmabuf-ops-attach(dmabuf, dev, attach);
Re: [PATCH] media: gspca_vc032x - wrong bytesperline
Sorry, forgot to include related link to kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91181 Ciao! Luca On 26/01/2015 11:38, Luca Bonissi wrote: Hi! I found a problem on vc032x gspca usb webcam subdriver: bytesperline property is wrong for YUYV and YVYU formats. With recent v4l-utils library (=0.9.1), that uses bytesperline for pixel format conversion, the result is a wrong jerky image. Patch tested on my laptop (USB webcam Logitech Orbicam 046d:0892). -- 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
dvt--scan-tables au-SunshineCoast corrections
Attn: Jonathon McCrohan, I expect you have already received an automated notification from ubuntu launchpad. I have just reported a new bug against this file to bring the multiplex frequencies up to date. I apologise for wimping out of your advice to patch against the original source! I have attached the same patch file as submitted to ubuntu. The change is very simple, so I hope my version doesn't inconvenience you too much. Best wishes, Brian --- au-SunshineCoast-2015-01-12-debianUnstable 2015-01-12 01:40:07.293353001 + +++ au-SunshineCoast-2015-01-12-brian 2015-01-12 01:45:44.788362414 + @@ -1,8 +1,8 @@ # Australia / Sunshine Coast -# SBS36 SBS *** +# SBS40 SBS *** [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 585625000 + FREQUENCY = 61350 BANDWIDTH_HZ = 700 CODE_RATE_HP = 2/3 CODE_RATE_LP = NONE @@ -12,10 +12,10 @@ HIERARCHY = NONE INVERSION = AUTO -# TNQ47 10 *** +# TNQ44 10 *** [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 662625000 + FREQUENCY = 64150 BANDWIDTH_HZ = 700 CODE_RATE_HP = 3/4 CODE_RATE_LP = NONE @@ -25,10 +25,10 @@ HIERARCHY = NONE INVERSION = AUTO -# ABQ62 ABC *** +# ABC41 ABC *** [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 767625000 + FREQUENCY = 62050 BANDWIDTH_HZ = 700 CODE_RATE_HP = 3/4 CODE_RATE_LP = NONE @@ -38,10 +38,10 @@ HIERARCHY = NONE INVERSION = AUTO -# STQ65 7 *** +# STQ42 7 *** [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 788625000 + FREQUENCY = 62750 BANDWIDTH_HZ = 700 CODE_RATE_HP = 3/4 CODE_RATE_LP = NONE @@ -51,10 +51,10 @@ HIERARCHY = NONE INVERSION = AUTO -# STQ68 WIN *** +# RTQ43 WIN *** [CHANNEL] DELIVERY_SYSTEM = DVBT - FREQUENCY = 80950 + FREQUENCY = 63450 BANDWIDTH_HZ = 700 CODE_RATE_HP = 3/4 CODE_RATE_LP = NONE
Re: [PATCH 1/2] media: v4l2-image-sizes.h: add SVGA, XGA and UXGA size definitions
Hi, Guennadi On 11/28/2014 4:13 AM, Guennadi Liakhovetski wrote: Hi Josh, On Thu, 27 Nov 2014, Josh Wu wrote: Hi, Guennadi On 11/26/2014 6:23 AM, Guennadi Liakhovetski wrote: Hi Josh, On Tue, 25 Nov 2014, Josh Wu wrote: Add SVGA, UXGA and XGA size definitions to v4l2-image-sizes.h. The definitions are sorted by alphabet order. Signed-off-by: Josh Wu josh...@atmel.com Thanks for your patches. I'm ok with these two, but the second of them depends on the first one, and the first one wouldn't (normally) be going via the soc-camera tree. Mauro, how would you prefer to handle this? Should I pick up and push to you both of them or postpone #2 until the next merge window? The first patch is already merged in the media_tree. If the soc-camera tree will be merged to the media_tree, then there should have no dependency issue. Am I understanding correct? Yes, then it should be ok! Just checking the status of this patch. I don't found this patch in media's tree or soc_camera's tree. Could you take this patch in your tree? Best Regards, Josh Wu Thanks Guennadi Best Regards, Josh Wu Thanks Guennadi --- include/media/v4l2-image-sizes.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/media/v4l2-image-sizes.h b/include/media/v4l2-image-sizes.h index 10daf92..c70c917 100644 --- a/include/media/v4l2-image-sizes.h +++ b/include/media/v4l2-image-sizes.h @@ -25,10 +25,19 @@ #define QVGA_WIDTH 320 #define QVGA_HEIGHT 240 +#define SVGA_WIDTH 800 +#define SVGA_HEIGHT680 + #define SXGA_WIDTH 1280 #define SXGA_HEIGHT 1024 #define VGA_WIDTH 640 #define VGA_HEIGHT 480 +#define UXGA_WIDTH 1600 +#define UXGA_HEIGHT1200 + +#define XGA_WIDTH 1024 +#define XGA_HEIGHT 768 + #endif /* _IMAGE_SIZES_H */ -- 1.9.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
Re: setting volatile v4l2-control
On 01/27/15 14:32, Jacek Anaszewski wrote: While testing the LED / flash API integration patches I noticed that the v4l2-controls marked as volatile with V4L2_CTRL_FLAG_VOLATILE flag behave differently than I would expect. Let's consider following use case: There is a volatile V4L2_CID_FLASH_INTENSITY v4l2 control with following constraints: min: 1 max: 100 step: 1 def: 1 1. Set the V4L2_CID_FLASH_INTENSITY control to 100. - as a result s_ctrl op is called 2. Set flash_brightness LED sysfs attribute to 10. 3. Set the V4L2_CID_FLASH_INTENSITY control to 100. - s_ctrl op isn't called This way we are unable to write a new value to the device, despite that the related setting was changed from the LED subsystem level. I would expect that if a control is marked volatile, then the v4l2-control framework should by default call g_volatile_ctrl op before set and not try to use the cached value. Is there some vital reason for not doing this? It's rather strange to have a writable volatile control. The semantics of this are ambiguous and I don't believe we have ever used such controls before. Actually, the commit log of this patch (never merged) gives some background information about this: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/commit/?h=volatilefix It's never been merged because I have never been certain how to handle such controls. Why do you have such controls in the first place? What is it supposed to do? 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: i.MX6 status for IPU/VPU/GPU
Hi Jean-Michel,
Long time no news of this. There are any progress?
I am interested in this. Can any of you send me the pdf of pipeline? I
want to take a look.
Regards,
Carlos S.
2014-10-24 15:42 GMT+02:00 Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com:
Hi Philipp,
2014-09-15 16:13 GMT+02:00 Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com:
2014-09-11 15:26 GMT+02:00 Philipp Zabel p.za...@pengutronix.de:
Hi Steve,
Am Mittwoch, den 10.09.2014, 18:17 -0700 schrieb Steve Longerbeam:
[...]
On 09/09/2014 10:40 AM, Philipp Zabel wrote:
[...]
I have in the meantime started to
implement everything that has a source or destination selector in the
Frame Synchronization Unit (FSU) as media entity. I wonder which of
these parts should reasonably be unified into a single entity:
[...]
SMFC0
SMFC1
SMFC2
SMFC3
I don't really see the need for an SMFC entity. The SMFC control can
be integrated into the CSI subdev.
Granted, this is currently is a theoretical question, but could we
handle a single MIPI link that carries two or more virtual channels with
different MIPI IDs this way?
IC preprocessor (input to VF and ENC, if I understood correctly)
IC viewfinder task (scaling, csc)
IC encoding task
IC post processing task
I see either three different IC subdev entities (IC prpenc, IC prpvf,
IC pp), or a single IC entity with three sink pads for each IC task.
The former could work, the latter won't allow to have pre and post
processing on separate pipelines.
IRT viewfinder task (rotation)
IRT encoding task
IRT post processing task
well, the IRT is really just a submodule enable bit, I see no need
for an IRT subdev, in fact IRT has already been folded into ipu-ic.c
as a simple submodule enable/disable. Rotation support can be
implemented as part of the IC entities.
My current understanding is that the IRT is strictly a mem2mem device
using its own DMA channels, which can be channel-linked to the IC (and
other blocks) in various ways.
VDIC (deinterlacing, combining)
I am thinking VDIC support can be part of the IC prpvf entity (well,
combining is not really on my radar, I haven't given that much thought).
(and probably some entry for DP/DC/DMFC for the direct
viewfinder path)
Ugh, I've been ignoring that path as well. Freescale's BSP releases
and sample code from their SDK's have no example code for the
direct-to-DP/DC/DMFC camera viewfinder path, so given the quality
of the imx TRM, this could be a challenge to implement. Have you
gotten this path to work?
Not yet, no.
I suppose the SMFC channels need to be separate because they can belong
to different pipelines (and each entity can only belong to one).
I see the chosen SMFC channel as an internal decision by the
CSI subdev.
Can we handle multiple outputs from a single CSI this way?
The three IC task entities could probably be combined with their
corresponding IRT task entity somehow, but that would be at the cost of
not being able to tell the kernel whether to rotate before or after
scaling, which might be useful when handling chroma subsampled formats.
I'm fairly sure IC rotation must always occur _after_ scaling. I.e.
raw frames are first passed through IC prpenc/prpvf/pp for scaling/CSC,
then EOF completion of that task is hardware linked to IRT.
There could be good reasons to do the rotation on the input side, for
example when upscaling or when the output is 4:2:2 subsampled. At least
the FSU registers suggest that channel linking the rotator before the IC
is possible. This probably won't be useful for the capture path in most
cases, but it might be for rotated playback.
I have put my current state up here:
git://git.pengutronix.de/git/pza/linux.git test/nitrogen6x-ipu-media
So far I've captured video through the SMFC on a Nitrogen6X board with
OV5652 parallel camera with this.
Thanks Phillip, I'll take a look! Sounds like a good place to start.
I assume this is with the video mux entity and CSI driver? I.e. no
IC entity support yet for scaling, CSC, or rotation.
Yes, exactly.
I have tried both of your branches (Steve and Philip) and they both
are interesting.
I easily added adv76xx devices to Steve's work, but there is no media
controller support, as you previously said.
I cannot get adv7611 working on Philip's branch. I tried to do the
same as your add OV5642 parallel camera commit, but I don't see a
link between csi and adv even though I asked for it in DT (I removed
not useful stuff in the following paste) :
i2c2 {
hdmiin1: adv7611@4c {
port {
hdmi0_out: endpoint@1 {
reg = 1;
remote_endpoint = csi0_from_adv7611;
};
};
};
csi0 {
csi0_from_adv7611: endpoint {
remote_endpoint = hdmi0_out;
};
};
Is
[PATCH 1/1] smiapp: Don't compile of_read_number() if CONFIG_OF isn't defined
of_read_number() is defined in of.h but does not return an error code, so that non-of implementation could simply return an error. Temporarily work around this until of_read_number() can be replaced by of_property_read_u64_array(). Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/i2c/smiapp/smiapp-core.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index b3c8125..d47eff5 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -2980,7 +2980,9 @@ static struct smiapp_platform_data *smiapp_get_pdata(struct device *dev) struct property *prop; __be32 *val; uint32_t asize; +#ifdef CONFIG_OF unsigned int i; +#endif int rval; if (!dev-of_node) @@ -3057,8 +3059,10 @@ static struct smiapp_platform_data *smiapp_get_pdata(struct device *dev) if (IS_ERR(val)) goto out_err; +#ifdef CONFIG_OF for (i = 0; i asize; i++) pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2); +#endif for (; asize 0; asize--) dev_dbg(dev, freq %d: %lld\n, asize - 1, -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Strange behaviour of sizeof(struct v4l2_queryctrl)
Hello to anyone,
I'm working on a problem with V4L2 on Linux Kernel 2.6.37.
The problem arise when I try to query a video device to list the
controls it provides.
When is call
ioctl(fd, VIDIOC_QUERYCTRL, queryctrl)
the function doesn't return 0 and errno is set to EINVAL
This happen for every control, even for the controls that the driver
provides (checked in the code) like brightness.
After adding a lot of printk in the videodev.ko module I found that the
problem is caused by a wrong value of VIDIOC_QUERYCTRL, that in the
kernel module is 0xC0485624 while in userspace application is 0xC0445624.
I digged the kernel source to understand what's happening, and
discovered the definition of VIDIOC_QUERYCTRL:
#define VIDIOC_QUERYCTRL_IOWR('V', 36, struct
v4l2_queryctrl)
dove:
#define _IOWR(type,nr,size) \
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
with
#define _IOC(dir,type,nr,size) \
(((dir) _IOC_DIRSHIFT) | \
((type) _IOC_TYPESHIFT) | \
((nr) _IOC_NRSHIFT) | \
((size) _IOC_SIZESHIFT))
and
#define _IOC_NRSHIFT0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
#define _IOC_NRBITS 8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 14
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IOC_TYPECHECK(t) (sizeof(t))
thus, the _IOC definition means:
_IOC(dir,type,nr,size) = [dir|size|type|nr]
that, for the aftermentioned values means:
0xC0445624 = [3|044|56|24] == size = 0x44 = 68
0xC0485624 = [3|048|56|24] == size = 0x48 = 72
To be sure that the number 68 and 72 are correct, I added a printk() in
the videodev.ko module and a println() in the userspace application to
print sizeof(struct v4l2_queryctrl), and the outputs are:
Kernel module:
printk([DBG] %s() ~ sizeof(struct v4l2_queryctrl): %u\n,
__func__, sizeof(struct v4l2_queryctrl));
= [DBG] videodev_init() ~ sizeof(struct v4l2_queryctrl): 72
Userspace application:
printf([dbg] sizeof(struct v4l2_queryctrl): %u\n,
sizeof(struct v4l2_queryctrl));
= [dbg] sizeof(struct v4l2_queryctrl): 68
In both cases (module and application), there is the inclusion of
linux/videodev2.h.
When I compiled the application I istructed the compiler to pick the
same kernel header of the module, with a proper CFLAGS += -IPATH in
the Makefile.
Any idea about this strangeness?
Regards
Francesco
--
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
cx23885 / DVBSky T9580: mpeg risc op code error
Hey folks, I seem to keep getting the this error after a day or two with my DVBSky T9580. The card appears to keep working regardless of the error but unfortunately whenever this occurs the Sky (UK)+ HD box downstairs goes completely bonkers (poor signal, blocking etc) until I tune to a service or restart the box. I'm only guessing here but I think whenever this happens the card must be sending some weird voltage to the dish interfering with the STB. dmesg output snip: [ 641.339516] cx23885[0]: mpeg risc op code error [ 641.339573] cx23885[0]: TS2 C - dma channel status dump [ 641.339580] cx23885[0]: cmds: init risc lo : 0xb6b8f000 [ 641.339586] cx23885[0]: cmds: init risc hi : 0x [ 641.339592] cx23885[0]: cmds: cdt base : 0x000105e0 [ 641.339597] cx23885[0]: cmds: cdt size : 0x000a [ 641.339603] cx23885[0]: cmds: iq base: 0x00010440 [ 641.339608] cx23885[0]: cmds: iq size: 0x0010 [ 641.339613] cx23885[0]: cmds: risc pc lo : 0xb6b8f008 [ 641.339618] cx23885[0]: cmds: risc pc hi : 0x [ 641.339623] cx23885[0]: cmds: iq wr ptr : 0x4112 [ 641.339629] cx23885[0]: cmds: iq rd ptr : 0x4110 [ 641.339634] cx23885[0]: cmds: cdt current: 0x00010618 [ 641.339639] cx23885[0]: cmds: pci target lo : 0xb7a51490 [ 641.339644] cx23885[0]: cmds: pci target hi : 0x [ 641.339649] cx23885[0]: cmds: line / byte: 0x0107 [ 641.339654] cx23885[0]: risc0: 0x1c0002f0 [ write sol eol count=752 ] [ 641.339664] cx23885[0]: risc1: 0xb7a51490 [ writerm eol irq2 irq1 23 21 18 cnt0 12 count=1168 ] [ 641.339676] cx23885[0]: risc2: 0x [ INVALID count=0 ] [ 641.339682] cx23885[0]: risc3: 0x1c0002f0 [ write sol eol count=752 ] [ 641.339690] cx23885[0]: (0x00010440) iq 0: 0x5d771378 [ writec sol eol irq1 22 21 20 18 cnt1 cnt0 12 count=888 ] [ 641.339703] cx23885[0]: (0x00010444) iq 1: 0xe09717e2 [ INVALID 23 20 18 cnt1 cnt0 12 count=2018 ] [ 641.339713] cx23885[0]: (0x00010448) iq 2: 0xb7a51780 [ writerm eol irq2 irq1 23 21 18 cnt0 12 count=1920 ] [ 641.339725] cx23885[0]: iq 3: 0x [ arg #1 ] [ 641.339730] cx23885[0]: iq 4: 0x1c0002f0 [ arg #2 ] [ 641.339735] cx23885[0]: (0x00010454) iq 5: 0xb7a51a70 [ writerm eol irq2 irq1 23 21 18 cnt0 12 count=2672 ] [ 641.339747] cx23885[0]: iq 6: 0x [ arg #1 ] [ 641.339752] cx23885[0]: iq 7: 0x1c0002f0 [ arg #2 ] [ 641.339757] cx23885[0]: (0x00010460) iq 8: 0xb7a51d60 [ writerm eol irq2 irq1 23 21 18 cnt0 12 count=3424 ] [ 641.339769] cx23885[0]: iq 9: 0x [ arg #1 ] [ 641.339774] cx23885[0]: iq a: 0x [ arg #2 ] [ 641.339779] cx23885[0]: (0x0001046c) iq b: 0x1c0002f0 [ write sol eol count=752 ] [ 641.339787] cx23885[0]: iq c: 0xb7a511a0 [ arg #1 ] [ 641.339791] cx23885[0]: iq d: 0x [ arg #2 ] [ 641.339796] cx23885[0]: (0x00010478) iq e: 0x1c0002f0 [ write sol eol count=752 ] [ 641.339804] cx23885[0]: iq f: 0xb7a51490 [ arg #1 ] [ 641.339810] cx23885[0]: iq 10: 0xd8ceeaa3 [ arg #2 ] [ 641.339813] cx23885[0]: fifo: 0x6000 - 0x7000 [ 641.339816] cx23885[0]: ctrl: 0x00010440 - 0x104a0 [ 641.339821] cx23885[0]: ptr1_reg: 0x68d0 [ 641.339826] cx23885[0]: ptr2_reg: 0x00010618 [ 641.339830] cx23885[0]: cnt1_reg: 0x [ 641.339835] cx23885[0]: cnt2_reg: 0x0003 [34157.452715] perf interrupt took too long (2510 2500), lowering kernel.perf_event_max_sample_rate to 5 Full log here: http://sprunge.us/KPXS Any help or assistance would greatly be received! Cheers. -- 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
[GIT FIXES FOR v3.19] smiapp compile fix for non-OF configuration
Hi Mauro, The recent smiapp OF support patches contained a small issue related to reading 64-bit numbers from the device tree, such that the compilation fails if CONFIG_OF is undefined. This patch provides a temporary fix to the matter. The proper one is to use of_property_read_u64_array(), but that's currently not exported. I've submitted a patch for that. Please pull. The following changes since commit e32b31ae45c18679c186e67aa41d0e2318cae487: [media] mb86a20s: remove unused debug modprobe parameter (2015-01-26 10:08:29 -0200) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git smiapp-of-compile for you to fetch changes up to 45fe24236dd638b170a7ca91a3aa0e9b2b153889: smiapp: Don't compile of_read_number() if CONFIG_OF isn't defined (2015-01-27 12:18:49 +0200) Sakari Ailus (1): smiapp: Don't compile of_read_number() if CONFIG_OF isn't defined drivers/media/i2c/smiapp/smiapp-core.c |4 1 file changed, 4 insertions(+) -- 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
Re: Strange behaviour of sizeof(struct v4l2_queryctrl)
Hello again,
I was able to solve the problem... now the userspace program use the
correct value for VIDIOC_QUERYCTRL.
Regards
Francesco
Il 27/01/2015 11:43, Francesco Marletta ha scritto:
Hello to anyone,
I'm working on a problem with V4L2 on Linux Kernel 2.6.37.
The problem arise when I try to query a video device to list the
controls it provides.
When is call
ioctl(fd, VIDIOC_QUERYCTRL, queryctrl)
the function doesn't return 0 and errno is set to EINVAL
This happen for every control, even for the controls that the driver
provides (checked in the code) like brightness.
After adding a lot of printk in the videodev.ko module I found that
the problem is caused by a wrong value of VIDIOC_QUERYCTRL, that in
the kernel module is 0xC0485624 while in userspace application is
0xC0445624.
I digged the kernel source to understand what's happening, and
discovered the definition of VIDIOC_QUERYCTRL:
#define VIDIOC_QUERYCTRL_IOWR('V', 36, struct
v4l2_queryctrl)
dove:
#define _IOWR(type,nr,size) \
_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
with
#define _IOC(dir,type,nr,size) \
(((dir) _IOC_DIRSHIFT) | \
((type) _IOC_TYPESHIFT) | \
((nr) _IOC_NRSHIFT) | \
((size) _IOC_SIZESHIFT))
and
#define _IOC_NRSHIFT0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
#define _IOC_NRBITS 8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 14
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U
#define _IOC_TYPECHECK(t) (sizeof(t))
thus, the _IOC definition means:
_IOC(dir,type,nr,size) = [dir|size|type|nr]
that, for the aftermentioned values means:
0xC0445624 = [3|044|56|24] == size = 0x44 = 68
0xC0485624 = [3|048|56|24] == size = 0x48 = 72
To be sure that the number 68 and 72 are correct, I added a printk()
in the videodev.ko module and a println() in the userspace application
to print sizeof(struct v4l2_queryctrl), and the outputs are:
Kernel module:
printk([DBG] %s() ~ sizeof(struct v4l2_queryctrl): %u\n,
__func__, sizeof(struct v4l2_queryctrl));
= [DBG] videodev_init() ~ sizeof(struct v4l2_queryctrl): 72
Userspace application:
printf([dbg] sizeof(struct v4l2_queryctrl): %u\n,
sizeof(struct v4l2_queryctrl));
= [dbg] sizeof(struct v4l2_queryctrl): 68
In both cases (module and application), there is the inclusion of
linux/videodev2.h.
When I compiled the application I istructed the compiler to pick the
same kernel header of the module, with a proper CFLAGS += -IPATH in
the Makefile.
Any idea about this strangeness?
Regards
Francesco
--
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 0/3] Introduce IIO interface for fingerprint sensors
Hi, On 23/01/15 14:05, Baluta, Teodora wrote: ... So why not v4l? These are effectively image sensors.. Well, here's why I don't think v4l would be the best option: - an image scanner could be implemented in the v4l subsystem, but it seems far more complicated for a simple fingerprint scanner - it usually has drivers for webcams, TVs or video streaming devices. The v4l subsystem (with all its support for colorspace, decoders, image compression, frame control) seems a bit of an overkill for a very straightforward fingerprint imaging sensor. Whilst those are there, I would doubt the irrelevant bits would put much burden on a fingerprint scanning driver. Been a while since I did anything in that area though so I could be wrong! IMO V4L is much better fit for this kind of devices than IIO. You can use just a subset of the API, it shouldn't take much effort to write a simple v4l2 capture driver, supporting fixed (probably vendor/chip specific) image format. I'm not sure if it's better to use the v4l2 controls [1], define a new v4l2 controls class for the fingerprint scanner processing features, rather than trying to pass raw data to user space and interpret it then in some library. I know there has been resistance to allowing passing unknown binary blobs to user space, due to possible abuses. [1] Documentation/video4linux/v4l2-controls.txt The fingerprint sensor acts more like a scanner device, so the closest type is the V4L2_CAP_VIDEO_CAPTURE. However, this is not a perfect match because the driver only sends an image, once, when triggered. Would it be a better alternative to define a new capability type? Or it would be acceptable to simply have a video device with no frame buffer or frame rate and the user space application to read from the character device /dev/videoX? I don't think a new capability is needed for just one buffer capture. The capture driver could just support read() and signal it by setting the V4L2_CAP_READWRITE capability flag [2], [3]. [2] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html#device-capabilities [3] http://linuxtv.org/downloads/v4l-dvb-apis/io.html#rw -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
drivers/dma-buf/dma-buf.c | 47 +-
drivers/gpu/drm/armada/armada_gem.c| 10 --
drivers/gpu/drm/drm_prime.c| 12 ---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
drivers/gpu/drm/tegra/gem.c| 10 --
drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
drivers/staging/android/ion/ion.c | 9 +++--
include/linux/dma-buf.h| 35 +++
14 files changed, 143 insertions(+), 50 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
* Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
* @exp_name: [in]name of the exporting module - useful for debugging.
* @resv: [in]reservation-object, NULL to allocate default one.
*
+ * All the above info comes from struct dma_buf_export_info.
+ *
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name,
- struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
{
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
- if (!resv)
+ if (!exp_info-resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent dma_buf[1] == dma_buf-resv */
alloc_size += 1;
- if (WARN_ON(!priv || !ops
- || !ops-map_dma_buf
- || !ops-unmap_dma_buf
- || !ops-release
- || !ops-kmap_atomic
- || !ops-kmap
- || !ops-mmap)) {
+ if (WARN_ON(!exp_info-priv
+ || !exp_info-ops
+ || !exp_info-ops-map_dma_buf
+ || !exp_info-ops-unmap_dma_buf
+ || !exp_info-ops-release
+ || !exp_info-ops-kmap_atomic
+ || !exp_info-ops-kmap
+ || !exp_info-ops-mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
- dmabuf-priv = priv;
- dmabuf-ops = ops;
- dmabuf-size = size;
- dmabuf-exp_name = exp_name;
+ dmabuf-priv = exp_info-priv;
+ dmabuf-ops = exp_info-ops;
+ dmabuf-size = exp_info-size;
+ dmabuf-exp_name = exp_info-exp_name;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
- if (!resv) {
- resv = (struct reservation_object *)dmabuf[1];
- reservation_object_init(resv);
+ if (!exp_info-resv) {
+ exp_info-resv = (struct reservation_object *)dmabuf[1];
+ reservation_object_init(exp_info-resv);
}
- dmabuf-resv = resv;
+ dmabuf-resv = exp_info-resv;
- file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
+ file =
[PATCH for v3.19] vivid: Y offset should depend on quant. range
When converting to or from Y'CbCr and R'G'B' the Y offset depends
on the quantization range: it's 0 for full and 16 for limited range.
But in the code it was hardcoded to 16. This messed up the brightness
of the generated pattern.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index fc9c653..34493f4 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -352,13 +352,14 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
{ COEFF(0.5, 224), COEFF(-0.4629, 224), COEFF(-0.0405, 224)
},
};
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
+ unsigned y_offset = full ? 0 : 16;
int lin_y, yc;
switch (tpg-real_ycbcr_enc) {
case V4L2_YCBCR_ENC_601:
case V4L2_YCBCR_ENC_XV601:
case V4L2_YCBCR_ENC_SYCC:
- rgb2ycbcr(full ? bt601_full : bt601, r, g, b, 16, y, cb, cr);
+ rgb2ycbcr(full ? bt601_full : bt601, r, g, b, y_offset, y, cb,
cr);
break;
case V4L2_YCBCR_ENC_BT2020:
rgb2ycbcr(bt2020, r, g, b, 16, y, cb, cr);
@@ -384,7 +385,7 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r, int
g, int b,
case V4L2_YCBCR_ENC_709:
case V4L2_YCBCR_ENC_XV709:
default:
- rgb2ycbcr(full ? rec709_full : rec709, r, g, b, 0, y, cb, cr);
+ rgb2ycbcr(full ? rec709_full : rec709, r, g, b, y_offset, y,
cb, cr);
break;
}
}
@@ -439,13 +440,14 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
{ COEFF(1, 219), COEFF(1.8814, 224), COEFF(0, 224) },
};
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
+ unsigned y_offset = full ? 0 : 16;
int lin_r, lin_g, lin_b, lin_y;
switch (tpg-real_ycbcr_enc) {
case V4L2_YCBCR_ENC_601:
case V4L2_YCBCR_ENC_XV601:
case V4L2_YCBCR_ENC_SYCC:
- ycbcr2rgb(full ? bt601_full : bt601, y, cb, cr, 16, r, g, b);
+ ycbcr2rgb(full ? bt601_full : bt601, y, cb, cr, y_offset, r, g,
b);
break;
case V4L2_YCBCR_ENC_BT2020:
ycbcr2rgb(bt2020, y, cb, cr, 16, r, g, b);
@@ -480,7 +482,7 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y, int
cb, int cr,
case V4L2_YCBCR_ENC_709:
case V4L2_YCBCR_ENC_XV709:
default:
- ycbcr2rgb(full ? rec709_full : rec709, y, cb, cr, 16, r, g, b);
+ ycbcr2rgb(full ? rec709_full : rec709, y, cb, cr, y_offset, r,
g, b);
break;
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES for v3.19] vivid: Y offset should depend on quant. range
I discovered this bug today and it explains why vivid behaved so strangely when generating full range Y'CbCr patterns. It was introduced in 3.19, so it would be really nice if this can be fixed before 3.19 is released. Regards, Hans The following changes since commit 8d44aeefcd79e9be3b6db4f37efc7544995b619e: [media] rtl28xxu: change module unregister order (2015-01-27 10:57:58 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19c for you to fetch changes up to 593a7b12b9dfe06ed39d6a22ebf8774992341130: vivid: Y offset should depend on quant. range (2015-01-27 17:46:17 +0100) Hans Verkuil (1): vivid: Y offset should depend on quant. range drivers/media/platform/vivid/vivid-tpg.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: setting volatile v4l2-control
On 01/27/2015 03:14 PM, Hans Verkuil wrote: On 01/27/15 14:32, Jacek Anaszewski wrote: While testing the LED / flash API integration patches I noticed that the v4l2-controls marked as volatile with V4L2_CTRL_FLAG_VOLATILE flag behave differently than I would expect. Let's consider following use case: There is a volatile V4L2_CID_FLASH_INTENSITY v4l2 control with following constraints: min: 1 max: 100 step: 1 def: 1 1. Set the V4L2_CID_FLASH_INTENSITY control to 100. - as a result s_ctrl op is called 2. Set flash_brightness LED sysfs attribute to 10. 3. Set the V4L2_CID_FLASH_INTENSITY control to 100. - s_ctrl op isn't called This way we are unable to write a new value to the device, despite that the related setting was changed from the LED subsystem level. I would expect that if a control is marked volatile, then the v4l2-control framework should by default call g_volatile_ctrl op before set and not try to use the cached value. Is there some vital reason for not doing this? It's rather strange to have a writable volatile control. The semantics of this are ambiguous and I don't believe we have ever used such controls before. Actually, the commit log of this patch (never merged) gives some background information about this: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/commit/?h=volatilefix It's never been merged because I have never been certain how to handle such controls. Why do you have such controls in the first place? What is it supposed to do? In case of integrated LED subsystem and V4L2 Flash API [1] a driver can be accessed from the level of either LED subsystem sysfs interface or v4l2-flash sub-device. Once the v4l2 sub-device is opened the LED subsystem sysfs interface is locked, but it gets released on sub-device closing. Since that moment the driver/device state can be changed through sysfs interface. When the sub-device is opened again it cannot be certain that the cached state of the controls reflects the actual state of the driver/device. That's why I made the shared settings volatile, maybe abusing the intended purpose of the related flags. [1] http://www.spinics.net/lists/linux-media/msg85351.html -- Best 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 05/66] rtl2830: convert driver to kernel I2C model
Em Tue, 23 Dec 2014 22:48:58 +0200
Antti Palosaari cr...@iki.fi escreveu:
Convert driver to kernel I2C model. Old DVB proprietary model is
still left there also.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/Kconfig| 2 +-
drivers/media/dvb-frontends/rtl2830.c | 167
+
drivers/media/dvb-frontends/rtl2830.h | 31 ++
drivers/media/dvb-frontends/rtl2830_priv.h | 2 +
4 files changed, 201 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index 6c75418..e8827fc 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -443,7 +443,7 @@ config DVB_CXD2820R
config DVB_RTL2830
tristate Realtek RTL2830 DVB-T
- depends on DVB_CORE I2C
+ depends on DVB_CORE I2C I2C_MUX
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Say Y when you want to support this frontend.
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 50e8b63..ec4a19c 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -767,6 +767,173 @@ static struct dvb_frontend_ops rtl2830_ops = {
.read_signal_strength = rtl2830_read_signal_strength,
};
+/*
+ * I2C gate/repeater logic
+ * We must use unlocked i2c_transfer() here because I2C lock is already taken
+ * by tuner driver. Gate is closed automatically after single I2C xfer.
+ */
+static int rtl2830_select(struct i2c_adapter *adap, void *mux_priv, u32
chan_id)
+{
+ struct i2c_client *client = mux_priv;
+ struct rtl2830_priv *priv = i2c_get_clientdata(client);
+ struct i2c_msg select_reg_page_msg[1] = {
+ {
+ .addr = priv-cfg.i2c_addr,
+ .flags = 0,
+ .len = 2,
+ .buf = \x00\x01,
+ }
+ };
+ struct i2c_msg gate_open_msg[1] = {
+ {
+ .addr = priv-cfg.i2c_addr,
+ .flags = 0,
+ .len = 2,
+ .buf = \x01\x08,
+ }
+ };
+ int ret;
+
+ /* select register page */
+ ret = __i2c_transfer(adap, select_reg_page_msg, 1);
+ if (ret != 1) {
+ dev_warn(client-dev, i2c write failed %d\n, ret);
+ if (ret = 0)
+ ret = -EREMOTEIO;
+ goto err;
+ }
+
+ priv-page = 1;
+
+ /* open tuner I2C repeater for 1 xfer, closes automatically */
+ ret = __i2c_transfer(adap, gate_open_msg, 1);
+ if (ret != 1) {
+ dev_warn(client-dev, i2c write failed %d\n, ret);
+ if (ret = 0)
+ ret = -EREMOTEIO;
+ goto err;
+ }
+
+ return 0;
+
+err:
+ dev_dbg(client-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
+}
+
+static struct dvb_frontend *rtl2830_get_dvb_frontend(struct i2c_client
*client)
+{
+ struct rtl2830_priv *priv = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, \n);
+
+ return priv-fe;
+}
+
+static struct i2c_adapter *rtl2830_get_i2c_adapter(struct i2c_client *client)
+{
+ struct rtl2830_priv *priv = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, \n);
+
+ return priv-adapter;
+}
+
+static int rtl2830_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct rtl2830_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *i2c = client-adapter;
+ struct rtl2830_priv *priv;
+ int ret;
+ u8 u8tmp;
+
+ dev_dbg(client-dev, \n);
+
+ if (pdata == NULL) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* allocate memory for the internal state */
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (priv == NULL) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ /* setup the state */
+ i2c_set_clientdata(client, priv);
+ priv-i2c = i2c;
+ priv-sleeping = true;
+ priv-cfg.i2c_addr = client-addr;
+ priv-cfg.xtal = pdata-clk;
+ priv-cfg.spec_inv = pdata-spec_inv;
+ priv-cfg.vtop = pdata-vtop;
+ priv-cfg.krf = pdata-krf;
+ priv-cfg.agc_targ_val = pdata-agc_targ_val;
+
+ /* check if the demod is there */
+ ret = rtl2830_rd_reg(priv, 0x000, u8tmp);
+ if (ret)
+ goto err_kfree;
+
+ /* create muxed i2c adapter for tuner */
+ priv-adapter = i2c_add_mux_adapter(client-adapter, client-dev,
+ client, 0, 0, 0, rtl2830_select, NULL);
+ if (priv-adapter == NULL) {
+ ret = -ENODEV;
+ goto err_kfree;
+ }
+
+ /* create dvb frontend */
+ memcpy(priv-fe.ops, rtl2830_ops, sizeof(priv-fe.ops));
+ priv-fe.ops.release = NULL;
+
setting volatile v4l2-control
While testing the LED / flash API integration patches I noticed that the v4l2-controls marked as volatile with V4L2_CTRL_FLAG_VOLATILE flag behave differently than I would expect. Let's consider following use case: There is a volatile V4L2_CID_FLASH_INTENSITY v4l2 control with following constraints: min: 1 max: 100 step: 1 def: 1 1. Set the V4L2_CID_FLASH_INTENSITY control to 100. - as a result s_ctrl op is called 2. Set flash_brightness LED sysfs attribute to 10. 3. Set the V4L2_CID_FLASH_INTENSITY control to 100. - s_ctrl op isn't called This way we are unable to write a new value to the device, despite that the related setting was changed from the LED subsystem level. I would expect that if a control is marked volatile, then the v4l2-control framework should by default call g_volatile_ctrl op before set and not try to use the cached value. Is there some vital reason for not doing this? -- Best 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: PCTV 800i
On Tue, Jan 27, 2015 at 12:25 AM, John Klug ski.brim...@gmail.com wrote: I moved it to a dual boot system, and it works in windows, and the same error in Linux. The chips are marked: Conexant CX23880 Samsung S5H1411 Cirrus CS5340CZZ Atmel ATMLH138 three out of four are a different part number than the Wiki. It is Board T1213044 stamped on back PCTV 800i Rev 1.1 Shield over tuner says pctv systems There are 5 APL1117 on both sides of the board. Since the tuner is probably under the shield I don't know a non-destructive method to get the part number. From: Steven Toth st...@kernellabs.com Date: Mon, Jan 26, 2015 at 6:44 AM Subject: Re: PCTV 800i To: John Klug ski.brim...@gmail.com Cc: Linux-Media linux-media@vger.kernel.org On Mon, Jan 26, 2015 at 12:50 AM, John Klug ski.brim...@gmail.com wrote: I have a new PCTV card with CX23880 (not CX23883 as shown in the picture): http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_HD_Card_(800i) The description is out of date with respect to my recent card. It did not work in 3.12.20, 3.17.7, and I finally downloaded the latest GIT of media_build to no avail (I have a 2nd card that is CX18, which is interspersed in the output). The error messages suggest one or more of the components on the board, or their I2C addresses have changed, or that your hardware is bad. Other than the Conexant PCI bridge, do the other components listed in the wiki page match the components on your physical device? John replied off list: http://linux-media.vger.kernel.narkive.com/kAviSkda/chipset-change-for-cx88-board-pinnacle-pctv-hd-800i Wonder if any code was ever integrated? It looks like basics of a patch was developed to support the card but it was incompatible with the existing cards and nobody took the time to understand how to differentiate between the older 800i and the newer 800i. So, the problem fell on the floor. I'll look through my card library. If I have an old _AND_ new rev then I'll find an hour and see if I can find an acceptable solution. Summary: PCTV released a new 800i (quite a while ago) changing the demodulator, which is why the existing driver doesn't work. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] SiLabs improvements
Em Wed, 10 Dec 2014 12:06:34 +0200 Antti Palosaari cr...@iki.fi escreveu: These are mostly small improvements, having very small functionality changes. Hmm... I was unable to pull it. Maybe this got already applied? Regards, Mauro regards Antti The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for you to fetch changes up to ade964f4a620194de8ae5c6f0719dd2ae7681b96: si2157: change firmware variable name and type (2014-12-06 23:32:14 +0200) Antti Palosaari (22): si2168: define symbol rate limits si2168: rename device state variable from 's' to 'dev' si2168: carry pointer to client instead of state si2168: get rid of own struct i2c_client pointer si2168: simplify si2168_cmd_execute() error path si2168: rename few things si2168: change firmware version print from debug to info si2168: change stream id debug log formatter si2168: add own goto label for kzalloc failure si2168: enhance firmware download routine si2168: remove unneeded fw variable initialization si2168: print chip version si2168: change firmware variable name and type si2157: rename device state variable from 's' to 'dev' si2157: simplify si2157_cmd_execute() error path si2157: carry pointer to client instead of state in tuner_priv si2157: change firmware download error handling si2157: trivial ID table changes si2157: add own goto label for kfree() on probe error si2157: print firmware version si2157: print chip version si2157: change firmware variable name and type drivers/media/dvb-frontends/si2168.c | 308 - drivers/media/dvb-frontends/si2168.h | 6 ++-- drivers/media/dvb-frontends/si2168_priv.h | 3 +- drivers/media/tuners/si2157.c | 189 +++ drivers/media/tuners/si2157_priv.h| 3 +- 5 files changed, 247 insertions(+), 262 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] SiLabs improvements
It is not pulled, try again. The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git silabs for you to fetch changes up to ade964f4a620194de8ae5c6f0719dd2ae7681b96: si2157: change firmware variable name and type (2014-12-06 23:32:14 +0200) Antti Palosaari (22): si2168: define symbol rate limits si2168: rename device state variable from 's' to 'dev' si2168: carry pointer to client instead of state si2168: get rid of own struct i2c_client pointer si2168: simplify si2168_cmd_execute() error path si2168: rename few things si2168: change firmware version print from debug to info si2168: change stream id debug log formatter si2168: add own goto label for kzalloc failure si2168: enhance firmware download routine si2168: remove unneeded fw variable initialization si2168: print chip version si2168: change firmware variable name and type si2157: rename device state variable from 's' to 'dev' si2157: simplify si2157_cmd_execute() error path si2157: carry pointer to client instead of state in tuner_priv si2157: change firmware download error handling si2157: trivial ID table changes si2157: add own goto label for kfree() on probe error si2157: print firmware version si2157: print chip version si2157: change firmware variable name and type drivers/media/dvb-frontends/si2168.c | 308 - drivers/media/dvb-frontends/si2168.h | 6 ++-- drivers/media/dvb-frontends/si2168_priv.h | 3 +- drivers/media/tuners/si2157.c | 189 +++ drivers/media/tuners/si2157_priv.h| 3 +- 5 files changed, 247 insertions(+), 262 deletions(-) Antti On 01/27/2015 03:01 PM, Mauro Carvalho Chehab wrote: Em Wed, 10 Dec 2014 12:06:34 +0200 Antti Palosaari cr...@iki.fi escreveu: These are mostly small improvements, having very small functionality changes. Hmm... I was unable to pull it. Maybe this got already applied? Regards, Mauro regards Antti The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for you to fetch changes up to ade964f4a620194de8ae5c6f0719dd2ae7681b96: si2157: change firmware variable name and type (2014-12-06 23:32:14 +0200) Antti Palosaari (22): si2168: define symbol rate limits si2168: rename device state variable from 's' to 'dev' si2168: carry pointer to client instead of state si2168: get rid of own struct i2c_client pointer si2168: simplify si2168_cmd_execute() error path si2168: rename few things si2168: change firmware version print from debug to info si2168: change stream id debug log formatter si2168: add own goto label for kzalloc failure si2168: enhance firmware download routine si2168: remove unneeded fw variable initialization si2168: print chip version si2168: change firmware variable name and type si2157: rename device state variable from 's' to 'dev' si2157: simplify si2157_cmd_execute() error path si2157: carry pointer to client instead of state in tuner_priv si2157: change firmware download error handling si2157: trivial ID table changes si2157: add own goto label for kfree() on probe error si2157: print firmware version si2157: print chip version si2157: change firmware variable name and type drivers/media/dvb-frontends/si2168.c | 308 - drivers/media/dvb-frontends/si2168.h | 6 ++-- drivers/media/dvb-frontends/si2168_priv.h | 3 +- drivers/media/tuners/si2157.c | 189 +++ drivers/media/tuners/si2157_priv.h| 3 +- 5 files changed, 247 insertions(+), 262 deletions(-) -- 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
Re: [GIT PULL] SiLabs improvements
Em Tue, 27 Jan 2015 19:27:54 +0200 Antti Palosaari cr...@iki.fi escreveu: It is not pulled, try again. The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git silabs == Ah, that pull request have a branch name ;) On the previous one, there was just the tree, without specifying any branch. I'll try to pull it latter today or tomorrow. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HW seek and TDA8290
It is possible to have HW seek support in TDA8290 cards as in recent TEA575x? -- 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 Jan 28 04:00:15 CET 2015 git branch: test git hash: 8d44aeefcd79e9be3b6db4f37efc7544995b619e gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-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: 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.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18-i686: ERRORS linux-3.19-rc4-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18-x86_64: ERRORS linux-3.19-rc4-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS ABI WARNING: change for arm-davinci smatch: 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
