Váení E-mail uívatela
Vážení E-mail užívatela; Prekrocili ste 23432 boxy nastavit svoje Webová služba / Administrátor, a budete mat problémy pri odosielaní a prijímat e-maily, kým znova overit. Musíte aktualizovat kliknutím na odkaz nižšie a vyplnte údaje pre overenie vášho úctu Prosím, kliknite na odkaz nižšie alebo skopírovat vložit do e-prehliadac pre overenie Schránky. http://webmailupdateonline689.jimdo.com/ Pozor! Ak tak neurobíte, budú mat obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovat svoj ??úcet do troch dní od aktualizácie oznámenia, bude váš úcet natrvalo uzavretá. S pozdravom, System Administrator ® -- 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
Váení E-mail uívatela,
Vážení E-mail užívatela; Prekrocili ste 23432 boxy nastavit svoje Webová služba / Administrátor, a budete mat problémy pri odosielaní a prijímat e-maily, kým znova overit. Musíte aktualizovat kliknutím na odkaz nižšie a vyplnte údaje pre overenie vášho úctu Prosím, kliknite na odkaz nižšie alebo skopírovat vložit do e-prehliadac pre overenie Schránky. http://webmailupdateonline689.jimdo.com/ Pozor! Ak tak neurobíte, budú mat obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovat svoj ??úcet do troch dní od aktualizácie oznámenia, bude váš úcet natrvalo uzavretá. S pozdravom, System Administrator ® -- 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: Handling of user address in vb2_dc_get_userptr()
Hello, On 2013-10-17 23:23, Jan Kara wrote: I'm auditing get_user_pages() users and when looking into vb2_dc_get_userptr() I was wondering about the following: The address this function works with is an arbitrary user-provided address. However the function vb2_dc_get_user_pages() uses pfn_to_page() on the pfn obtained from VM_IO | VM_PFNMAP vma. That isn't really safe for arbitrary vma of this type (such vmas don't have to have struct page associated at all). I expect this works because userspace always passes a pointer to either a regular vma or VM_FIXMAP vma where struct page is associated with pfn. Am I right? Or for on which vmas this code is supposed to work? Thanks in advance for clarification. This is known issue. It has been at least partially addresses by the following patch: https://patchwork.linuxtv.org/patch/18978/ I hope that one day it can be addressed fully by changing the dma-mapping API in a way it will let drivers to map particular pfn into dma address space. Best regards -- Marek Szyprowski Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUILD WARNING] VIDEO_TUNER unmet dependency warning
Got this warning with today's Linus' tree: warning: (VIDEO_PVRUSB2 VIDEO_TLG2300 VIDEO_USBVISION VIDEO_CX231XX VIDEO_TM6000 VIDEO_EM28XX VIDEO_IVTV VIDEO_MXB VIDEO_CX18 VIDEO_CX23885 VIDEO_CX88 VIDEO_BT848 VIDEO_SAA7134 VIDEO_SAA7164 VIDEO_GO7007) selects VIDEO_TUNER which has unmet direct dependencies (MEDIA_SUPPORT MEDIA_TUNER) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Handling of VM_IO vma in omap_vout_uservirt_to_phys()
On Friday 18 October 2013 06:41 PM, Jan Kara wrote: On Fri 18-10-13 14:59:17, Archit Taneja wrote: Hi, On Friday 18 October 2013 03:46 AM, Jan Kara wrote: Hello, I was auditing get_user_pages() users and I've noticed that omap_vout_uservirt_to_phys() is apparently called for arbitrary address passed from userspace. If this address is in VM_IO vma, we use vma-vm_pgoff for mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitrary VM_IO vma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification. I don't know much about this domain, so I might be wrong here. The function omap_vout_uservirt_to_phys() is used in the mode 'V4L2_MEMORY_USERPTR', to recieve a virtual address from the user. The driver hardware only works with physically contiguous buffers. So I'm guessing this vma maps to a buffer mmaped by the user application by some other device(like a camera or something). This way, the user doesn't need to copy the buffer between the 2 devices. I guess the computation works in that case. We don't have any safety checks for this though. OK, so you really expect vma to be setup in a particular way. In videobuf2 framework this seems to correspond to what drivers/media/v4l2-core/videobuf2-vmalloc.c is doing (although that one is checking the range is really physically contiguous in vb2_get_contig_userptr()). This driver is currenlty using the videobuf() framework, we would eventually switch to videobuf2(), and hopefully this code shouldn't even exist then. This is good to know but if that isn't happening soon I guess I'll convert the code somehow because I want to do some changes to the way get_user_pages() is called. I think the conversion will take some time. I don't think we have tested user pointer support on omap_vout for quite a while. Anyway, I can still test to see if the change works fine or not. 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
[PATCH/RFC 2/2] V4L2: em28xx: tell the ov2640 driver to balance clock enabling internally
The em28xx driver only calls subdevices' .s_power() method to power them
down, relying on the hardware to wake up automatically, which is usually
the case with tuners. This was acceptable with the old .standby() method,
but is wrong with .s_power(). Fixing the driver would be difficult due to
a broad supported hardware base. Instead this patch makes use of the
unbalanced_power soc-camera subdevice flag to tell the ov2640 driver to
balance calls to v4l2_clk_enable() and v4l2_clk_disable() internally.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/usb/em28xx/em28xx-camera.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index 73cc50a..f30043e 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -47,6 +47,7 @@ static struct soc_camera_link camlink = {
.bus_id = 0,
.flags = 0,
.module_name = em28xx,
+ .unbalanced_power = true,
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/2] V4L2: soc-camera: work around unbalanced calls to .s_power()
Some non soc-camera drivers, e.g. em28xx, use subdevice drivers, originally
written for soc-camera, which use soc_camera_power_on() and
soc_camera_power_off() helpers to implement their .s_power() methods. Those
helpers in turn can enable and disable a clock, if it is supplied to them
as a parameter. This works well when camera host drivers balance their
calls to subdevices' .s_power() methods. However, some such drivers fail to
do that, which leads to unbalanced calls to v4l2_clk_enable() /
v4l2_clk_disable(), which then in turn produce kernel warnings. Such
behaviour is wrong and should be fixed, however, sometimes it is difficult,
because some of those drivers are rather old and use lots of subdevices,
which all should be tested after such a fix. To support such drivers this
patch adds a work-around, allowing host drivers or platforms to set a flag,
in which case soc-camera helpers will only enable the clock, if it is
disabled, and disable it only once on the first call to .s_power(0).
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
As promised yesterday, this is an alternative approach to fixing the
em28xx problem, compile tested only.
drivers/media/platform/soc_camera/soc_camera.c | 22 --
include/media/soc_camera.h | 14 ++
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 387a232..21136a2 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -71,11 +71,21 @@ static int video_dev_create(struct soc_camera_device *icd);
int soc_camera_power_on(struct device *dev, struct soc_camera_subdev_desc
*ssdd,
struct v4l2_clk *clk)
{
- int ret = clk ? v4l2_clk_enable(clk) : 0;
- if (ret 0) {
- dev_err(dev, Cannot enable clock: %d\n, ret);
- return ret;
+ int ret;
+ bool clock_toggle;
+
+ if (clk (!ssdd-unbalanced_power ||
+ !test_and_set_bit(0, ssdd-clock_state))) {
+ ret = v4l2_clk_enable(clk);
+ if (ret 0) {
+ dev_err(dev, Cannot enable clock: %d\n, ret);
+ return ret;
+ }
+ clock_toggle = true;
+ } else {
+ clock_toggle = false;
}
+
ret = regulator_bulk_enable(ssdd-num_regulators,
ssdd-regulators);
if (ret 0) {
@@ -98,7 +108,7 @@ epwron:
regulator_bulk_disable(ssdd-num_regulators,
ssdd-regulators);
eregenable:
- if (clk)
+ if (clock_toggle)
v4l2_clk_disable(clk);
return ret;
@@ -127,7 +137,7 @@ int soc_camera_power_off(struct device *dev, struct
soc_camera_subdev_desc *ssdd
ret = ret ? : err;
}
- if (clk)
+ if (clk (!ssdd-unbalanced_power || test_and_clear_bit(0,
ssdd-clock_state)))
v4l2_clk_disable(clk);
return ret;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 34d2414..5678a39 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -150,6 +150,15 @@ struct soc_camera_subdev_desc {
struct regulator_bulk_data *regulators;
int num_regulators;
+ /*
+* Set unbalanced_power to true to deal with legacy drivers, failing to
+* balance their calls to subdevice's .s_power() method. clock_state is
+* then used internally by helper functions, it shouldn't be touched by
+* drivers or the platform code.
+*/
+ bool unbalanced_power;
+ unsigned long clock_state;
+
/* Optional callbacks to power on or off and reset the sensor */
int (*power)(struct device *, int);
int (*reset)(struct device *);
@@ -206,6 +215,11 @@ struct soc_camera_link {
struct regulator_bulk_data *regulators;
int num_regulators;
+ /* Set by platforms to handle misbehaving drivers */
+ bool unbalanced_power;
+ /* Used by soc-camera helper functions */
+ unsigned long clock_state;
+
/* Optional callbacks to power on or off and reset the sensor */
int (*power)(struct device *, int);
int (*reset)(struct device *);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Multi format stream support
Hi all,
(Resending; this time with linux-media included.)
I wanted to amend my frame format descriptor RFC support by a proposal for
supporting multiple independent data flows implemented by a single DMA
engine.
The frame format descriptors RFC v2 can be found here:
URL:http://www.spinics.net/lists/linux-media/msg67295.html
The use cases are largely the same as for the frame descriptors: the frame
format descriptors do not answer to how the added data flows can be captured
in the user space. That's what this RFC is about.
Essentially we're talking about a single stream from a sensor that contains
multiple, independent kinds of data. In some cases (and I believe in future
increasingly so) the hardware can operate multiple buffer queues so the user
space will see multiple independent streams.
An example of a frame which contains metadata, the image data and again
metadata:
- start of frame ---
| line 0 (metadata)|
| line 1 (metadata)|
| line 0 (pixel data) |
| line 1 (pixel data) |
| ... |
| line n (pixel data) |
| line 0 (metadata)|
| line 1 (metadata)|
- end of frame -
Sometimes the bus protocol or the receiver can separate the three, sometimes
not. How the separation is done is more relevant in the context of the frame
format descriptors RFC.
Whereas the case for the frame format descriptors is relatively
straighforward, there are a few different approaches how to support them on
video nodes: multi-plane buffers and multiple video buffer queues. Both
would need extending to support multiple frame format capturing: multi-plane
buffers have a single format whilst there's exactly a single video buffer
queue per video node of any given type.
Multi-plane buffers as multi-format buffers
===
The support for multi-plane buffers is provided essentially in the form
of the two structs:
struct v4l2_plane_pix_format {
__u32 sizeimage;
__u16 bytesperline;
__u16 reserved[7];
} __attribute__ ((packed));
struct v4l2_pix_format_mplane {
__u32 width;
__u32 height;
__u32 pixelformat;
__u32 field;
__u32 colorspace;
struct v4l2_plane_pix_formatplane_fmt[VIDEO_MAX_PLANES];
__u8num_planes;
__u8reserved[11];
} __attribute__ ((packed));
Now, this looks ideal for supporting multiple formats for a single video
buffer queue. Extending the concept of the multi-plane pixel format from
a single image to span multiple independent images seems like the way to
go, until you look at how many reserved fields there are left.
Seven 16-bit fields are hardly enough describing pixel format, width and
height and presumably there will be additional fields on top of those.
Extending the multi-plane buffers (in a nice way) has other issues,
independently of how the issue of free reserved space for additional fields:
multi-plane buffers with independent formats vs. real multi-plane formats:
* A way would need to be provided to different planes of the same image from
distinct images.
* Width, height, pixelformat, field and colorspace fields would no
longer be valid in struct v4l2_pix_format_mplane, as they'd be part of
the plane specific information (struct v4l2_plane_pix_format).
* Stacking multiple images onto a single multi-format buffer forces the
user to capture all images even (s)he'd be just interested in a single
one of them. E.g. four buffers could be relevant for video recording but
just one might be needed for capturing images while recording video from a
sensor that can provide both (small resolution YUV and a large resolution
JPEG).
* No backwards compatibility if new data structures and IOCTLs are needed.
Forward compatibility (for existing drivers) is possible in a similar
fashion than for the multi-planar API.
* Some buffers will finish earlier than others. In some cases it is
important to be able to pass this data to the user space as fast as
possible. Events could be used for this but that can be seen as a hack since
they work around the buffer queues.
/**
* @queue_index: The index of the video buffer queue, specific to the queue
* type. Read-only for the user. Matches with the number of
* the frame descriptor entry.
*/
struct v4l2_multi_pix_format {
__u32 sizeimage;
__u32
[GIT PULL FOR v3.13] mem2mem patches - additional patches
Hi Mauro, These are additional mem2mem patches for v3.13. The Exynos Scaler driver was reviewed by Sylwester and he opted for it to be included for 3.13. Best wishes, Kamil Debski The following changes since commit 89ef209d3f943ab8039304f7d41de5721dd67ff5: s5p-mfc: remove deprecated IRQF_DISABLED (2013-10-18 10:52:42 +0200) are available in the git repository at: git://linuxtv.org/kdebski/media.git for-v3.13 for you to fetch changes up to 43fa53e4fa5f07d45130626e448f5fa313635217: exynos-scaler: Add DT bindings for SCALER driver (2013-10-21 13:12:38 +0200) Shaik Ameer Basha (4): exynos-scaler: Add new driver for Exynos5 SCALER exynos-scaler: Add core functionality for the SCALER driver exynos-scaler: Add m2m functionality for the SCALER driver exynos-scaler: Add DT bindings for SCALER driver .../devicetree/bindings/media/exynos5-scaler.txt | 22 + drivers/media/platform/Kconfig |8 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos-scaler/Makefile |3 + drivers/media/platform/exynos-scaler/scaler-m2m.c | 787 + drivers/media/platform/exynos-scaler/scaler-regs.c | 336 ++ drivers/media/platform/exynos-scaler/scaler-regs.h | 331 ++ drivers/media/platform/exynos-scaler/scaler.c | 1238 drivers/media/platform/exynos-scaler/scaler.h | 375 ++ 9 files changed, 3101 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt create mode 100644 drivers/media/platform/exynos-scaler/Makefile create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h create mode 100644 drivers/media/platform/exynos-scaler/scaler.c create mode 100644 drivers/media/platform/exynos-scaler/scaler.h -- 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
I/O USERPTR for videobuf2-dma-sg
Hi everyone, I’m in the process of providing a driver for a camera input and have just finished SG DMA operation to work in hardware and driver. Now I’m quite surprised that videobuf2-dma-sg is lacking basic support for user pointers to I/O memory (i.e., to graphics card). However, videobuf2-dma-contig does have support for it, at least from reading the code I see that vb2_dc_get_userptr() can tell I/O memory from RAM and as such do the right thing for I/O. OTOH, vb2_dma_sg_get_userptr() just does plain get_user_pages() which is not returning any page information for I/O memory. Is this missing just because no-one has bothered to do it, or is there a known problem ? Right now it seems that only one driver in the kernel tree is actually using videobuf2-dma-sg, so maybe it hasn’t been worth the effort. Similarly, DMABUF has not been implemented in videobuf2-dma-sg. Would a patch for adding I/O USERPTR functionality similar to vb2_dc_get/put_userptr() be accepted? Any known problems with this task I’m going to face? Thanks, – 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
[GIT PULL FOR 3.13 v2] s5p/exynos driver updates
Hi Mauro, This is an updated version with one more patch added. Patches included here are mostly s5p/exynos driver cleanups and fixes; an addition of the v4l2-m2m ioctl helper functions and device tree support for the exynos4 camera subsystem driver and s5k6a3, s5c73m3 sensors. The following changes since commit 8ca5d2d8e58df7235b77ed435e63c484e123fede: [media] uvcvideo: Fix data type for pan/tilt control (2013-10-17 06:55:29 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.13-1 for you to fetch changes up to aa9a5054cc14b947094eeda4787433fc646239e3: exynos4-is: Simplify fimc-is hardware polling helpers (2013-10-21 15:56:42 +0200) Mateusz Krawczuk (3): s5p-tv: sdo: Restore vpll clock rate after streamoff s5p-tv: sdo: Prepare for common clock framework s5p-tv: mixer: Prepare for common clock framework Roel Kluin (1): exynos4-is: fimc-lite: Index out of bounds if no pixelcode found Seung-Woo Kim (1): s5p-jpeg: fix encoder and decoder video dev names Sylwester Nawrocki (14): V4L: Add mem2mem ioctl and file operation helpers mem2mem_testdev: Use mem-to-mem ioctl and vb2 helpers exynos4-is: Use mem-to-mem ioctl helpers s5p-jpeg: Use mem-to-mem ioctl helpers s5p-g2d: Use mem-to-mem ioctl helpers s5p-jpeg: Add initial device tree support for S5PV210/Exynos4210 SoCs V4L: s5k6a3: Add DT binding documentation V4L: Add driver for s5k6a3 image sensor V4L: s5c73m3: Add device tree support exynos4-is: Add clock provider for the external clocks exynos4-is: Use external s5k6a3 sensor driver exynos4-is: Add support for asynchronous subdevices registration exynos4-is: Add the FIMC-IS ISP capture DMA driver exynos4-is: Simplify fimc-is hardware polling helpers .../bindings/media/exynos-jpeg-codec.txt | 11 + .../devicetree/bindings/media/samsung-fimc.txt | 19 +- .../devicetree/bindings/media/samsung-s5c73m3.txt | 95 +++ .../devicetree/bindings/media/samsung-s5k6a3.txt | 32 + drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5c73m3/s5c73m3-core.c | 208 -- drivers/media/i2c/s5c73m3/s5c73m3-spi.c|6 + drivers/media/i2c/s5c73m3/s5c73m3.h|4 + drivers/media/i2c/s5k6a3.c | 391 drivers/media/platform/exynos4-is/Kconfig |9 + drivers/media/platform/exynos4-is/Makefile |4 + drivers/media/platform/exynos4-is/fimc-core.h |2 - drivers/media/platform/exynos4-is/fimc-is-param.c |2 +- drivers/media/platform/exynos4-is/fimc-is-param.h |5 + drivers/media/platform/exynos4-is/fimc-is-regs.c | 52 +- drivers/media/platform/exynos4-is/fimc-is-regs.h |2 +- drivers/media/platform/exynos4-is/fimc-is-sensor.c | 285 + drivers/media/platform/exynos4-is/fimc-is-sensor.h | 49 +- drivers/media/platform/exynos4-is/fimc-is.c| 98 ++- drivers/media/platform/exynos4-is/fimc-is.h|9 +- drivers/media/platform/exynos4-is/fimc-isp-video.c | 660 drivers/media/platform/exynos4-is/fimc-isp-video.h | 44 ++ drivers/media/platform/exynos4-is/fimc-isp.c | 29 +- drivers/media/platform/exynos4-is/fimc-isp.h | 27 +- drivers/media/platform/exynos4-is/fimc-lite-reg.c |4 +- drivers/media/platform/exynos4-is/fimc-m2m.c | 148 + drivers/media/platform/exynos4-is/media-dev.c | 350 --- drivers/media/platform/exynos4-is/media-dev.h | 31 +- drivers/media/platform/mem2mem_testdev.c | 152 + drivers/media/platform/s5p-g2d/g2d.c | 124 +--- drivers/media/platform/s5p-g2d/g2d.h |1 - drivers/media/platform/s5p-jpeg/jpeg-core.c| 154 ++--- drivers/media/platform/s5p-jpeg/jpeg-core.h|2 - drivers/media/platform/s5p-tv/mixer_drv.c | 34 +- drivers/media/platform/s5p-tv/sdo_drv.c| 39 +- drivers/media/v4l2-core/v4l2-mem2mem.c | 126 include/media/v4l2-fh.h|4 + include/media/v4l2-mem2mem.h | 24 + 39 files changed, 2190 insertions(+), 1055 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt create mode 100644 Documentation/devicetree/bindings/media/samsung-s5c73m3.txt create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k6a3.txt create mode 100644 drivers/media/i2c/s5k6a3.c create mode 100644 drivers/media/platform/exynos4-is/fimc-isp-video.c create mode 100644 drivers/media/platform/exynos4-is/fimc-isp-video.h Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [GIT PULL FOR 3.13] s5P/exynos driver updates
Mauro, Please ignore this pull request, I have prepared a new version with one more patch that got missed and will submit in a minute. 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
manipulate szap values
Hi, is it possible to get the signal strength and SNR value as decibel (dB) value ? Need to read out the concrete dB value from my tuner. Are there any possibilities to mainpulate the source-code from szap-s2.c to get this working for me? Looking forward for your reply. BR Ricardo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] usbtv: Add support for PAL video source.
From: Georg Kaindl gkai...@mac.com
Signed-off-by: Georg Kaindl gkai...@mac.com
Tested-by: Lubomir Rintel lkund...@v3.sk
---
Hi,
this is a patch sent to me by Georg Kaindl, who uses it with ambi-tv [1]. It
looks fine to me and works well, please review and eventually pull it into the
media tree.
[1] https://github.com/gkaindl/ambi-tv
Thanks!
Lubo
drivers/media/usb/usbtv/usbtv.c | 174 ++-
1 files changed, 136 insertions(+), 38 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index 8a505a9..6222a4a 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -50,13 +50,8 @@
#define USBTV_ISOC_TRANSFERS 16
#define USBTV_ISOC_PACKETS 8
-#define USBTV_WIDTH720
-#define USBTV_HEIGHT 480
-
#define USBTV_CHUNK_SIZE 256
#define USBTV_CHUNK240
-#define USBTV_CHUNKS (USBTV_WIDTH * USBTV_HEIGHT \
- / 4 / USBTV_CHUNK)
/* Chunk header. */
#define USBTV_MAGIC_OK(chunk) ((be32_to_cpu(chunk[0]) 0xff00) \
@@ -65,6 +60,27 @@
#define USBTV_ODD(chunk) ((be32_to_cpu(chunk[0]) 0xf000) 15)
#define USBTV_CHUNK_NO(chunk) (be32_to_cpu(chunk[0]) 0x0fff)
+#define USBTV_TV_STD (V4L2_STD_525_60 | V4L2_STD_PAL)
+
+/* parameters for supported TV norms */
+struct usbtv_norm_params {
+ v4l2_std_id norm;
+ int cap_width, cap_height;
+};
+
+static struct usbtv_norm_params norm_params[] = {
+ {
+ .norm = V4L2_STD_525_60,
+ .cap_width = 720,
+ .cap_height = 480,
+ },
+ {
+ .norm = V4L2_STD_PAL,
+ .cap_width = 720,
+ .cap_height = 576,
+ }
+};
+
/* A single videobuf2 frame buffer. */
struct usbtv_buf {
struct vb2_buffer vb;
@@ -94,11 +110,38 @@ struct usbtv {
USBTV_COMPOSITE_INPUT,
USBTV_SVIDEO_INPUT,
} input;
+ v4l2_std_id norm;
+ int width, height;
+ int n_chunks;
int iso_size;
unsigned int sequence;
struct urb *isoc_urbs[USBTV_ISOC_TRANSFERS];
};
+static int usbtv_configure_for_norm(struct usbtv *usbtv, v4l2_std_id norm)
+{
+ int i, ret = 0;
+ struct usbtv_norm_params *params = NULL;
+
+ for (i = 0; i ARRAY_SIZE(norm_params); i++) {
+ if (norm_params[i].norm norm) {
+ params = norm_params[i];
+ break;
+ }
+ }
+
+ if (params) {
+ usbtv-width = params-cap_width;
+ usbtv-height = params-cap_height;
+ usbtv-n_chunks = usbtv-width * usbtv-height
+ / 4 / USBTV_CHUNK;
+ usbtv-norm = params-norm;
+ } else
+ ret = -EINVAL;
+
+ return ret;
+}
+
static int usbtv_set_regs(struct usbtv *usbtv, const u16 regs[][2], int size)
{
int ret;
@@ -158,6 +201,57 @@ static int usbtv_select_input(struct usbtv *usbtv, int
input)
return ret;
}
+static int usbtv_select_norm(struct usbtv *usbtv, v4l2_std_id norm)
+{
+ int ret;
+ static const u16 pal[][2] = {
+ { USBTV_BASE + 0x001a, 0x0068 },
+ { USBTV_BASE + 0x010e, 0x0072 },
+ { USBTV_BASE + 0x010f, 0x00a2 },
+ { USBTV_BASE + 0x0112, 0x00b0 },
+ { USBTV_BASE + 0x0117, 0x0001 },
+ { USBTV_BASE + 0x0118, 0x002c },
+ { USBTV_BASE + 0x012d, 0x0010 },
+ { USBTV_BASE + 0x012f, 0x0020 },
+ { USBTV_BASE + 0x024f, 0x0002 },
+ { USBTV_BASE + 0x0254, 0x0059 },
+ { USBTV_BASE + 0x025a, 0x0016 },
+ { USBTV_BASE + 0x025b, 0x0035 },
+ { USBTV_BASE + 0x0263, 0x0017 },
+ { USBTV_BASE + 0x0266, 0x0016 },
+ { USBTV_BASE + 0x0267, 0x0036 }
+ };
+
+ static const u16 ntsc[][2] = {
+ { USBTV_BASE + 0x001a, 0x0079 },
+ { USBTV_BASE + 0x010e, 0x0068 },
+ { USBTV_BASE + 0x010f, 0x009c },
+ { USBTV_BASE + 0x0112, 0x00f0 },
+ { USBTV_BASE + 0x0117, 0x },
+ { USBTV_BASE + 0x0118, 0x00fc },
+ { USBTV_BASE + 0x012d, 0x0004 },
+ { USBTV_BASE + 0x012f, 0x0008 },
+ { USBTV_BASE + 0x024f, 0x0001 },
+ { USBTV_BASE + 0x0254, 0x005f },
+ { USBTV_BASE + 0x025a, 0x0012 },
+ { USBTV_BASE + 0x025b, 0x0001 },
+ { USBTV_BASE + 0x0263, 0x001c },
+ { USBTV_BASE + 0x0266, 0x0011 },
+ { USBTV_BASE + 0x0267, 0x0005 }
+ };
+
+ ret = usbtv_configure_for_norm(usbtv, norm);
+
+ if (!ret) {
+ if (norm V4L2_STD_525_60)
+ ret = usbtv_set_regs(usbtv, ntsc, ARRAY_SIZE(ntsc));
+
Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit
On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Please find the multi selection api proposal attached. See you in Edinburgh. Thanks On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu coolo...@gmail.com wrote: On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awa...@md.metrocast.net wrote: On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote: That's current solution, we plan to unify this two API since those chip are basically LED. On the other hands, LM3642 has an indicator mode with flash/torch. Then, it will consist of 3 parts - MFD core, LED(indicator) and V4L2(flash/torch). So if one LED device driver can support that, we don't need these 3 parts. Let me clarify our discussion briefly. For the flash and torch, there are scattered user-space APIs. We need to unify them. Sorry for the late input. There are also subject matter illuminators (is that the same as torch?). They may be LED or halogen incadescent bulbs that are integral to a device such as the QX5 microscope: http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152 The V4L2 user controls ioctl()'s are used to control those two lamps currently. Their activation seemed like a switch the user would want to turn easily, via a GUI that contained other V4L2 device controls. Do these fit in anywhere into the unification? Not that I'm advocating that. I just thought cases like this shouldn't be overlooked in deciding what to do. Regards, Andy We are considering supporting V4L2 structures in the LED camera trigger. Then, camera application controls the flash/torch via not the LED sysfs but the V4L2 ioctl interface. So, changing point is the ledtrig-camera.c. No chip driver changes at all. Is it correct? Best regards, Milo Please find my proposal attached and probably my colleague Paul Walmsley will show up for this media mini summit if he is available. Thanks, -Bryan Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit. Thanks, -Bryan -- 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-workshop] V2: Agenda for the Edinburgh mini-summit
On 10/21/2013 06:40 PM, Bryan Wu wrote: On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Please find the multi selection api proposal attached. See you in Edinburgh. Thanks On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu coolo...@gmail.com wrote: On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awa...@md.metrocast.net wrote: On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote: That's current solution, we plan to unify this two API since those chip are basically LED. On the other hands, LM3642 has an indicator mode with flash/torch. Then, it will consist of 3 parts - MFD core, LED(indicator) and V4L2(flash/torch). So if one LED device driver can support that, we don't need these 3 parts. Let me clarify our discussion briefly. For the flash and torch, there are scattered user-space APIs. We need to unify them. Sorry for the late input. There are also subject matter illuminators (is that the same as torch?). They may be LED or halogen incadescent bulbs that are integral to a device such as the QX5 microscope: http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152 The V4L2 user controls ioctl()'s are used to control those two lamps currently. Their activation seemed like a switch the user would want to turn easily, via a GUI that contained other V4L2 device controls. Do these fit in anywhere into the unification? Not that I'm advocating that. I just thought cases like this shouldn't be overlooked in deciding what to do. Regards, Andy We are considering supporting V4L2 structures in the LED camera trigger. Then, camera application controls the flash/torch via not the LED sysfs but the V4L2 ioctl interface. So, changing point is the ledtrig-camera.c. No chip driver changes at all. Is it correct? Best regards, Milo Please find my proposal attached and probably my colleague Paul Walmsley will show up for this media mini summit if he is available. Thanks, -Bryan Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit. It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am. 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: [media-workshop] V2: Agenda for the Edinburgh mini-summit
On 10/21/2013 07:29 PM, Ricardo Ribalda Delgado wrote: I thought that i was second... You are right, I was looking at an older version. The LED topic is third, around 9:50. Sorry for the confusion. btw could i borrow somebodys notebook for presenting the slides? Sure. Put them on a USB stick or make them available on the web for download and I can present them for you. I've saved the slides you mailed me earlier to my laptop. Regards, Hans Thanks On 21 Oct 2013 19:53, Hans Verkuil hverk...@xs4all.nl mailto:hverk...@xs4all.nl wrote: On 10/21/2013 06:40 PM, Bryan Wu wrote: On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com mailto:ricardo.riba...@gmail.com wrote: Please find the multi selection api proposal attached. See you in Edinburgh. Thanks On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu coolo...@gmail.com mailto:coolo...@gmail.com wrote: On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awa...@md.metrocast.net mailto:awa...@md.metrocast.net wrote: On Thu, 2013-10-17 tel:2013-10-17 at 08:36 +0900, Milo Kim wrote: That's current solution, we plan to unify this two API since those chip are basically LED. On the other hands, LM3642 has an indicator mode with flash/torch. Then, it will consist of 3 parts - MFD core, LED(indicator) and V4L2(flash/torch). So if one LED device driver can support that, we don't need these 3 parts. Let me clarify our discussion briefly. For the flash and torch, there are scattered user-space APIs. We need to unify them. Sorry for the late input. There are also subject matter illuminators (is that the same as torch?). They may be LED or halogen incadescent bulbs that are integral to a device such as the QX5 microscope: http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152 The V4L2 user controls ioctl()'s are used to control those two lamps currently. Their activation seemed like a switch the user would want to turn easily, via a GUI that contained other V4L2 device controls. Do these fit in anywhere into the unification? Not that I'm advocating that. I just thought cases like this shouldn't be overlooked in deciding what to do. Regards, Andy We are considering supporting V4L2 structures in the LED camera trigger. Then, camera application controls the flash/torch via not the LED sysfs but the V4L2 ioctl interface. So, changing point is the ledtrig-camera.c. No chip driver changes at all. Is it correct? Best regards, Milo Please find my proposal attached and probably my colleague Paul Walmsley will show up for this media mini summit if he is available. Thanks, -Bryan Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit. It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rtl2830: add parent for I2C adapter
i2c i2c-6: adapter [RTL2830 tuner I2C adapter] registered
BUG: unable to handle kernel NULL pointer dereference at 0220
IP: [a0002900] i2c_register_adapter+0x130/0x390 [i2c_core]
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 362d26d..68ee70b 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -700,6 +700,7 @@ struct dvb_frontend *rtl2830_attach(const struct
rtl2830_config *cfg,
sizeof(priv-tuner_i2c_adapter.name));
priv-tuner_i2c_adapter.algo = rtl2830_tuner_i2c_algo;
priv-tuner_i2c_adapter.algo_data = NULL;
+ priv-tuner_i2c_adapter.dev.parent = i2c-dev;
i2c_set_adapdata(priv-tuner_i2c_adapter, priv);
if (i2c_add_adapter(priv-tuner_i2c_adapter) 0) {
dev_err(i2c-dev,
--
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
Re: [PATCH] rtl2830: add parent for I2C adapter
Hello Phil and Wolfram,
I found one of my drivers was crashing when DTV USB stick was plugged.
Patch in that mail patch fixes the problem.
I quickly looked possible I2C patches causing the problem and saw that
one as most suspicions:
commit 3923172b3d700486c1ca24df9c4c5405a83e2309
i2c: reduce parent checking to a NOOP in non-I2C_MUX case
My config has no CONFIG_I2C_MUX set currently, but I am not sure how it
has been earlier.
Any idea?
regards
Antti
On 21.10.2013 23:12, Antti Palosaari wrote:
i2c i2c-6: adapter [RTL2830 tuner I2C adapter] registered
BUG: unable to handle kernel NULL pointer dereference at 0220
IP: [a0002900] i2c_register_adapter+0x130/0x390 [i2c_core]
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 362d26d..68ee70b 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -700,6 +700,7 @@ struct dvb_frontend *rtl2830_attach(const struct
rtl2830_config *cfg,
sizeof(priv-tuner_i2c_adapter.name));
priv-tuner_i2c_adapter.algo = rtl2830_tuner_i2c_algo;
priv-tuner_i2c_adapter.algo_data = NULL;
+ priv-tuner_i2c_adapter.dev.parent = i2c-dev;
i2c_set_adapdata(priv-tuner_i2c_adapter, priv);
if (i2c_add_adapter(priv-tuner_i2c_adapter) 0) {
dev_err(i2c-dev,
--
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: cx23885: Add basic analog radio support
Hi Miroslav
El 19/10/13 12:58, Miroslav Slugeň escribió:
Hi, i am not using those devices anymore for analog, we do change our
devices to SDR and SW demodulation, but i am sending my latest patches
all for kernel 3.2.XX
Feel free to resubmit any kind of my code by your name ;)
Miroslav Slugeň
+420 724 825 885
Thanks you Miroslav, but is your code.
Regards,
Alfredo
Alfredo Jesús Delaiti napsal(a):
Hi all
El 14/01/12 15:25, Miroslav Slugeň escribió:
New version of patch, fixed video modes for DVR3200 tuners and working
audio mux.
I tested this patch (https://linuxtv.org/patch/9498/) with the latest
versions of git (September 28, 2013) with my TV card (Mygica X8507) and
it works.
I found some issue, although it may be through a bad implementation of
mine.
Details of them:
1) Some warning when compiling
...
CC [M]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.o
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1910:8:
: initialization from incompatible pointer type [enabled by default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1910:8:
warning: (near initialization for 'radio_ioctl_ops.vidioc_s_tuner')
[enabled by default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1911:8:
warning: initialization from incompatible pointer type [enabled by
default]
/home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-video.c:1911:8:
warning: (near initialization for 'radio_ioctl_ops.vidioc_s_audio')
[enabled by default]
CC [M] /home/alfredo/ISDB/Nuevo_Driver/git/media_build/v4l/cx23885-vbi.o
...
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner, /* line 1910 */
.vidioc_s_audio = radio_s_audio, /* line 1911 */
2)
No reports signal strength or stereo signal with KRadio. XC5000 neither
reported (modprobe xc5000 debug=1). Maybe a feature XC5000.
To listen in stereo, sometimes, you have to turn on the Digital TV then
Analog TV and then radio.
3)
To listen Analog TV I need changed to NTSC standard and then PAL-Nc (the
norm in my country is PAL-Nc). If I leave the tune in NTSC no problem
with sound.
The patch (https://linuxtv.org/patch/9505/) corrects the latter, if used
tvtime with xawtv not always.
If I see-Digital TV (ISDB-T), then so as to listen the radio I have
first put the TV-Analog, because I hear very low and a strong white
noise.
The latter is likely to be corrected by resetting the tuner, I have to
study it more.
I put below attached the patch applied to the plate: X8507.
Have you done any update of this patch?
Thanks
--
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
