Re: [PATCH] s5p-tv: Include missing v4l2-dv-timings.h header file
On 08/18/2013 10:00 PM, Sylwester Nawrocki wrote: Include the v4l2-dv-timings.h header file which in the s5p-tv driver which was supposed to be updated in commit 2576415846bcbad3c0a6885fc44f95083710 [media] v4l2: move dv-timings related code to v4l2-dv-timings.c This fixes following build error: drivers/media/platform/s5p-tv/hdmi_drv.c: In function ‘hdmi_s_dv_timings’: drivers/media/platform/s5p-tv/hdmi_drv.c:628:3: error: implicit declaration of function ‘v4l_match_dv_timings’ Cc: Hans Verkuil hans.verk...@cisco.com Acked-by: Hans Verkuil hans.verk...@cisco.com My apologies for missing this one. Regards, Hans Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/platform/s5p-tv/hdmi_drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c b/drivers/media/platform/s5p-tv/hdmi_drv.c index 1b34c36..f9af2c2 100644 --- a/drivers/media/platform/s5p-tv/hdmi_drv.c +++ b/drivers/media/platform/s5p-tv/hdmi_drv.c @@ -37,6 +37,7 @@ #include media/v4l2-common.h #include media/v4l2-dev.h #include media/v4l2-device.h +#include media/v4l2-dv-timings.h #include regs-hdmi.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
Hauppauge WinTV MiniStick firmware not loading
Hi, I have a Hauppauge WinTV MiniStick that wouldn't work anymore with recent linux kernels. Right now I'm running kernel version 3.10.6 in Arch Linux. Plugging the device results in usb 1-1.5.1: new high-speed USB device number 9 using ehci-pci smscore_load_firmware_family2: line: 986: sending MSG_SMS_DATA_VALIDITY_REQ expecting 0xcfed1755 smscore_onresponse: line: 1565: MSG_SMS_DATA_VALIDITY_RES, checksum = 0xcfed1755 instead of smscore_set_device_mode: firmware download success: sms1xxx-hcw-55xxx-dvbt-02.fw Other people reported the same issue: * https://bbs.archlinux.org/viewtopic.php?pid=1309369 * https://bugzilla.kernel.org/show_bug.cgi?id=60645 I would appreciate any help on getting this problem fixed. Thanks, Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] drm/nouveau: rework to new fence interface
nouveau was a bit tricky, it has no support for interrupts on nv84, so I added
an extra call to nouveau_fence_update in nouveau_fence_emit to increase
the chance slightly that deferred work gets triggered.
This patch depends on the vblank locking fix for the definitions of
nouveau_event_enable_locked and nouveau_event_disable_locked.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..78714e4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -35,88 +35,115 @@
#include engine/fifo.h
-struct fence_work {
- struct work_struct base;
- struct list_head head;
- void (*func)(void *);
- void *data;
-};
+static const struct fence_ops nouveau_fence_ops_uevent;
+static const struct fence_ops nouveau_fence_ops_legacy;
static void
nouveau_fence_signal(struct nouveau_fence *fence)
{
- struct fence_work *work, *temp;
+ __fence_signal(fence-base);
+ list_del(fence-head);
- list_for_each_entry_safe(work, temp, fence-work, head) {
- schedule_work(work-base);
- list_del(work-head);
+ if (fence-base.ops == nouveau_fence_ops_uevent
+ fence-event.head.next) {
+ struct nouveau_event *event;
+
+ list_del(fence-event.head);
+ fence-event.head.next = NULL;
+
+ event = container_of(fence-base.lock, typeof(*event), lock);
+ if (!--event-index[0].refs)
+ event-disable(event, 0);
}
- fence-channel = NULL;
- list_del(fence-head);
+ fence_put(fence-base);
}
void
nouveau_fence_context_del(struct nouveau_fence_chan *fctx)
{
struct nouveau_fence *fence, *fnext;
- spin_lock(fctx-lock);
- list_for_each_entry_safe(fence, fnext, fctx-pending, head) {
+
+ spin_lock_irq(fctx-lock);
+ list_for_each_entry_safe(fence, fnext, fctx-pending, head)
nouveau_fence_signal(fence);
- }
- spin_unlock(fctx-lock);
+ spin_unlock_irq(fctx-lock);
}
void
-nouveau_fence_context_new(struct nouveau_fence_chan *fctx)
+nouveau_fence_context_new(struct nouveau_channel *chan, struct
nouveau_fence_chan *fctx)
{
+ struct nouveau_fifo *pfifo = nouveau_fifo(chan-drm-device);
+
+ fctx-lock = pfifo-uevent-lock;
INIT_LIST_HEAD(fctx-flip);
INIT_LIST_HEAD(fctx-pending);
- spin_lock_init(fctx-lock);
}
+struct nouveau_fence_work {
+ struct work_struct work;
+ struct fence_cb cb;
+ void (*func)(void *);
+ void *data;
+};
+
static void
nouveau_fence_work_handler(struct work_struct *kwork)
{
- struct fence_work *work = container_of(kwork, typeof(*work), base);
+ struct nouveau_fence_work *work = container_of(kwork, typeof(*work),
work);
work-func(work-data);
kfree(work);
}
+static void nouveau_fence_work_cb(struct fence *fence, struct fence_cb *cb)
+{
+ struct nouveau_fence_work *work = container_of(cb, typeof(*work), cb);
+
+ schedule_work(work-work);
+}
+
+/*
+ * In an ideal world, read would not assume the channel context is still alive.
+ * This function may be called from another device, running into free memory
as a
+ * result. The drm node should still be there, so we can derive the index from
+ * the fence context.
+ */
+static bool nouveau_fence_is_signaled(struct fence *f)
+{
+ struct nouveau_fence *fence = container_of(f, struct nouveau_fence,
base);
+ struct nouveau_channel *chan = fence-channel;
+ struct nouveau_fence_chan *fctx = chan-fence;
+
+ return (int)(fctx-read(chan) - fence-base.seqno) = 0;
+}
+
void
nouveau_fence_work(struct nouveau_fence *fence,
void (*func)(void *), void *data)
{
- struct nouveau_channel *chan = fence-channel;
- struct nouveau_fence_chan *fctx;
- struct fence_work *work = NULL;
+ struct nouveau_fence_work *work;
- if (nouveau_fence_done(fence)) {
- func(data);
- return;
- }
+ if (fence_is_signaled(fence-base))
+ goto err;
- fctx = chan-fence;
work = kmalloc(sizeof(*work), GFP_KERNEL);
if (!work) {
WARN_ON(nouveau_fence_wait(fence, false, false));
- func(data);
- return;
- }
-
- spin_lock(fctx-lock);
- if (!fence-channel) {
- spin_unlock(fctx-lock);
- kfree(work);
- func(data);
- return;
+ goto err;
}
- INIT_WORK(work-base, nouveau_fence_work_handler);
+ INIT_WORK(work-work, nouveau_fence_work_handler);
work-func = func;
work-data = data;
- list_add(work-head, fence-work);
- spin_unlock(fctx-lock);
+
+ if
[RFC PATCH] drm/radeon: rework to new fence interface
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9f19259..971284e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
#include linux/wait.h
#include linux/list.h
#include linux/kref.h
+#include linux/fence.h
#include ttm/ttm_bo_api.h
#include ttm/ttm_bo_driver.h
@@ -114,9 +115,6 @@ extern int radeon_aspm;
/* max number of rings */
#define RADEON_NUM_RINGS 6
-/* fence seq are set to this number when signaled */
-#define RADEON_FENCE_SIGNALED_SEQ 0LL
-
/* internal ring indices */
/* r1xx+ has gfx CP ring */
#define RADEON_RING_TYPE_GFX_INDEX 0
@@ -285,12 +283,15 @@ struct radeon_fence_driver {
};
struct radeon_fence {
+ struct fence base;
+
struct radeon_device*rdev;
- struct kref kref;
/* protected by radeon_fence.lock */
uint64_tseq;
/* RB, DMA, etc. */
unsignedring;
+
+ wait_queue_t fence_wake;
};
int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -2039,6 +2040,7 @@ struct radeon_device {
struct radeon_mman mman;
struct radeon_fence_driver fence_drv[RADEON_NUM_RINGS];
wait_queue_head_t fence_queue;
+ unsignedfence_context;
struct mutexring_lock;
struct radeon_ring ring[RADEON_NUM_RINGS];
boolib_pool_ready;
@@ -2117,11 +2119,6 @@ u32 cik_mm_rdoorbell(struct radeon_device *rdev, u32
offset);
void cik_mm_wdoorbell(struct radeon_device *rdev, u32 offset, u32 v);
/*
- * Cast helper
- */
-#define to_radeon_fence(p) ((struct radeon_fence *)(p))
-
-/*
* Registers read write functions.
*/
#define RREG8(reg) readb((rdev-rmmio) + (reg))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 63398ae..d76a187 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1150,6 +1150,7 @@ int radeon_device_init(struct radeon_device *rdev,
for (i = 0; i RADEON_NUM_RINGS; i++) {
rdev-ring[i].idx = i;
}
+ rdev-fence_context = fence_context_alloc(RADEON_NUM_RINGS);
DRM_INFO(initializing kernel modesetting (%s 0x%04X:0x%04X
0x%04X:0x%04X).\n,
radeon_family_name[rdev-family], pdev-vendor, pdev-device,
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index ddb8f8e..92a1576 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -39,6 +39,15 @@
#include radeon.h
#include radeon_trace.h
+static const struct fence_ops radeon_fence_ops;
+
+#define to_radeon_fence(p) \
+ ({ \
+ struct radeon_fence *__f; \
+ __f = container_of((p), struct radeon_fence, base); \
+ __f-base.ops == radeon_fence_ops ? __f : NULL;\
+ })
+
/*
* Fences
* Fences mark an event in the GPUs pipeline and are used
@@ -111,14 +120,17 @@ int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
{
+ u64 seq = ++rdev-fence_drv[ring].sync_seq[ring];
+
/* we are protected by the ring emission mutex */
*fence = kmalloc(sizeof(struct radeon_fence), GFP_KERNEL);
if ((*fence) == NULL) {
return -ENOMEM;
}
- kref_init(((*fence)-kref));
+ __fence_init((*fence)-base, radeon_fence_ops,
+rdev-fence_queue.lock, rdev-fence_context + ring, seq);
(*fence)-rdev = rdev;
- (*fence)-seq = ++rdev-fence_drv[ring].sync_seq[ring];
+ (*fence)-seq = seq;
(*fence)-ring = ring;
radeon_fence_ring_emit(rdev, ring, *fence);
trace_radeon_fence_emit(rdev-ddev, (*fence)-seq);
@@ -126,15 +138,38 @@ int radeon_fence_emit(struct radeon_device *rdev,
}
/**
- * radeon_fence_process - process a fence
+ * radeon_fence_check_signaled - callback from fence_queue
*
- * @rdev: radeon_device pointer
- * @ring: ring index the fence is associated with
- *
- * Checks the current fence value and wakes the fence queue
- * if the sequence number has increased (all asics).
+ * this function is called with fence_queue lock held, which is also used
+ * for the fence locking itself, so unlocked variants are used for
+ * fence_signal, and remove_wait_queue.
*/
-void radeon_fence_process(struct radeon_device *rdev, int ring)
+static int radeon_fence_check_signaled(wait_queue_t *wait, unsigned mode, int
flags, void *key)
+{
+ struct radeon_fence *fence;
+
[PATCH v2 1/5] [media] exynos-mscl: Add new driver for M-Scaler
This patch adds support for M-Scaler (M2M Scaler) device which is a
new device for scaling, blending, color fill and color space
conversion on EXYNOS5 SoCs.
This device supports the followings as key feature.
input image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB, L8A8 and L8
output image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB
input rotation
- 0/90/180/270 degree, X/Y/XY Flip
scale ratio
- 1/4 scale down to 16 scale up
color space conversion
- RGB to YUV / YUV to RGB
Size
- Input : 16x16 to 8192x8192
- Output: 4x4 to 8192x8192
alpha blending, color fill
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-regs.c | 318
drivers/media/platform/exynos-mscl/mscl-regs.h | 282 +
2 files changed, 600 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.c
create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.h
diff --git a/drivers/media/platform/exynos-mscl/mscl-regs.c
b/drivers/media/platform/exynos-mscl/mscl-regs.c
new file mode 100644
index 000..9354afc
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-regs.c
@@ -0,0 +1,318 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/delay.h
+#include linux/platform_device.h
+
+#include mscl-core.h
+
+void mscl_hw_set_sw_reset(struct mscl_dev *dev)
+{
+ u32 cfg;
+
+ cfg = readl(dev-regs + MSCL_CFG);
+ cfg |= MSCL_CFG_SOFT_RESET;
+
+ writel(cfg, dev-regs + MSCL_CFG);
+}
+
+int mscl_wait_reset(struct mscl_dev *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(50);
+ u32 cfg, reset_done = 0;
+
+ while (time_before(jiffies, end)) {
+ cfg = readl(dev-regs + MSCL_CFG);
+ if (!(cfg MSCL_CFG_SOFT_RESET)) {
+ reset_done = 1;
+ break;
+ }
+ usleep_range(10, 20);
+ }
+
+ /* write any value to r/w reg and read it back */
+ while (reset_done) {
+
+ /* [TBD] need to define number of tries before returning
+* -EBUSY to the caller
+*/
+
+ writel(MSCL_CFG_SOFT_RESET_CHECK_VAL,
+ dev-regs + MSCL_CFG_SOFT_RESET_CHECK_REG);
+ if (MSCL_CFG_SOFT_RESET_CHECK_VAL ==
+ readl(dev-regs + MSCL_CFG_SOFT_RESET_CHECK_REG))
+ return 0;
+ }
+
+ return -EBUSY;
+}
+
+void mscl_hw_set_irq_mask(struct mscl_dev *dev, int interrupt, bool mask)
+{
+ u32 cfg;
+
+ switch (interrupt) {
+ case MSCL_INT_TIMEOUT:
+ case MSCL_INT_ILLEGAL_BLEND:
+ case MSCL_INT_ILLEGAL_RATIO:
+ case MSCL_INT_ILLEGAL_DST_HEIGHT:
+ case MSCL_INT_ILLEGAL_DST_WIDTH:
+ case MSCL_INT_ILLEGAL_DST_V_POS:
+ case MSCL_INT_ILLEGAL_DST_H_POS:
+ case MSCL_INT_ILLEGAL_DST_C_SPAN:
+ case MSCL_INT_ILLEGAL_DST_Y_SPAN:
+ case MSCL_INT_ILLEGAL_DST_CR_BASE:
+ case MSCL_INT_ILLEGAL_DST_CB_BASE:
+ case MSCL_INT_ILLEGAL_DST_Y_BASE:
+ case MSCL_INT_ILLEGAL_DST_COLOR:
+ case MSCL_INT_ILLEGAL_SRC_HEIGHT:
+ case MSCL_INT_ILLEGAL_SRC_WIDTH:
+ case MSCL_INT_ILLEGAL_SRC_CV_POS:
+ case MSCL_INT_ILLEGAL_SRC_CH_POS:
+ case MSCL_INT_ILLEGAL_SRC_YV_POS:
+ case MSCL_INT_ILLEGAL_SRC_YH_POS:
+ case MSCL_INT_ILLEGAL_SRC_C_SPAN:
+ case MSCL_INT_ILLEGAL_SRC_Y_SPAN:
+ case MSCL_INT_ILLEGAL_SRC_CR_BASE:
+ case MSCL_INT_ILLEGAL_SRC_CB_BASE:
+ case MSCL_INT_ILLEGAL_SRC_Y_BASE:
+ case MSCL_INT_ILLEGAL_SRC_COLOR:
+ case MSCL_INT_FRAME_END:
+ break;
+ default:
+ return;
+ }
+ cfg = readl(dev-regs + MSCL_INT_EN);
+ if (mask)
+ cfg |= interrupt;
+ else
+ cfg = ~interrupt;
+ writel(cfg, dev-regs + MSCL_INT_EN);
+}
+
+void mscl_hw_set_input_addr(struct mscl_dev *dev, struct mscl_addr *addr)
+{
+ dev_dbg(dev-pdev-dev, src_buf: 0x%X, cb: 0x%X, cr: 0x%X,
+ addr-y, addr-cb, addr-cr);
+ writel(addr-y, dev-regs +
[PATCH v2 2/5] [media] exynos-mscl: Add core functionality for the M-Scaler driver
This patch adds the core functionality for the M-Scaler driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-core.c | 1312
drivers/media/platform/exynos-mscl/mscl-core.h | 549 ++
2 files changed, 1861 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h
diff --git a/drivers/media/platform/exynos-mscl/mscl-core.c
b/drivers/media/platform/exynos-mscl/mscl-core.c
new file mode 100644
index 000..4a3a851
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-core.c
@@ -0,0 +1,1312 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
+
+#include mscl-core.h
+
+#define MSCL_CLOCK_GATE_NAME mscl
+
+static const struct mscl_fmt mscl_formats[] = {
+ {
+ .name = YUV 4:2:0 non-contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12M,
+ .depth = { 8, 4 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+
+ }, {
+ .name = YUV 4:2:0 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12,
+ .depth = { 12 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = YUV 4:2:0 n.c. 2p, Y/CbCr tiled,
+ .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+ .depth = { 8, 4 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC),
+ .is_tiled = true,
+ }, {
+ .name = YUV 4:2:2 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV16,
+ .depth = { 16 },
+ .color = MSCL_YUV422,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV422_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = YUV 4:4:4 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV24,
+ .depth = { 24 },
+ .color = MSCL_YUV444,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV444_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565X,
+ .depth = { 16 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_RGB565,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = XRGB-1555, 16 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB555,
+ .depth = { 16 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_ARGB1555,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = XRGB-, 32 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+ .depth = { 32 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_ARGB,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name
[PATCH v2 4/5] [media] exynos-mscl: Add DT bindings for M-Scaler driver
This patch adds the DT binding documentation for the exynos5
based M-Scaler device driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
.../devicetree/bindings/media/exynos5-mscl.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-mscl.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-mscl.txt
b/Documentation/devicetree/bindings/media/exynos5-mscl.txt
new file mode 100644
index 000..5c9d1b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-mscl.txt
@@ -0,0 +1,34 @@
+* Samsung Exynos5 M-Scaler device
+
+M-Scaler is used for scaling, blending, color fill and color space
+conversion on EXYNOS5 SoCs.
+
+Required properties:
+- compatible: should be samsung,exynos5-mscl
+- reg: should contain M-Scaler physical address location and length.
+- interrupts: should contain M-Scaler interrupt number
+- clocks: should contain the clock number according to CCF
+- clock-names: should be mscl
+
+Example:
+
+ mscl_0: mscl@0x1280 {
+ compatible = samsung,exynos5-mscl;
+ reg = 0x1280 0x1000;
+ interrupts = 0 220 0;
+ clocks = clock 381;
+ clock-names = mscl;
+ };
+
+Aliases:
+Each M-Scaler node should have a numbered alias in the aliases node,
+in the form of msclN, N = 0...2. M-Scaler driver uses these aliases
+to retrieve the device IDs using of_alias_get_id() call.
+
+Example:
+
+aliases {
+ mscl0 =mscl_0;
+ mscl1 =mscl_1;
+ mscl2 =mscl_2;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Exynos5 M-Scaler Driver
This patch adds support for M-Scaler (M2M Scaler) device which is a new device for scaling, blending, color fill and color space conversion on EXYNOS5 SoCs. This device supports the following as key features. input image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB, L8A8 and L8 output image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB input rotation - 0/90/180/270 degree, X/Y/XY Flip scale ratio - 1/4 scale down to 16 scale up color space conversion - RGB to YUV / YUV to RGB Size - Input : 16x16 to 8192x8192 - Output: 4x4 to 8192x8192 alpha blending, color fill Rebased on: --- git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master Changes from v1: --- 1] Split the previous single patch into multiple patches. 2] Added DT binding documentation. 3] Removed the unnecessary header file inclusions. 4] Fix the condition check in mscl_prepare_address for swapping cb/cr addresses. Shaik Ameer Basha (5): [media] exynos-mscl: Add new driver for M-Scaler [media] exynos-mscl: Add core functionality for the M-Scaler driver [media] exynos-mscl: Add m2m functionality for the M-Scaler driver [media] exynos-mscl: Add DT bindings for M-Scaler driver [media] exynos-mscl: Add Makefile for M-Scaler driver .../devicetree/bindings/media/exynos5-mscl.txt | 34 + drivers/media/platform/Kconfig |8 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos-mscl/Makefile|3 + drivers/media/platform/exynos-mscl/mscl-core.c | 1312 drivers/media/platform/exynos-mscl/mscl-core.h | 549 drivers/media/platform/exynos-mscl/mscl-m2m.c | 763 drivers/media/platform/exynos-mscl/mscl-regs.c | 318 + drivers/media/platform/exynos-mscl/mscl-regs.h | 282 + 9 files changed, 3270 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-mscl.txt create mode 100644 drivers/media/platform/exynos-mscl/Makefile create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] [media] exynos-mscl: Add Makefile for M-Scaler driver
This patch adds the Makefile for the M-Scaler (M2M scaler). Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- drivers/media/platform/Kconfig |8 drivers/media/platform/Makefile |1 + drivers/media/platform/exynos-mscl/Makefile |3 +++ 3 files changed, 12 insertions(+) create mode 100644 drivers/media/platform/exynos-mscl/Makefile diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 08de865..bff437a 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -201,6 +201,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC help This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler. +config VIDEO_SAMSUNG_EXYNOS_MSCL + tristate Samsung Exynos M-Scaler driver + depends on OF VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5 + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + This is a v4l2 driver for Samsung EXYNOS5 SoC M-Scaler. + config VIDEO_SH_VEU tristate SuperH VEU mem2mem video processing driver depends on VIDEO_DEV VIDEO_V4L2 GENERIC_HARDIRQS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index eee28dd..2452b09 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_MSCL)+= exynos-mscl/ obj-$(CONFIG_BLACKFIN) += blackfin/ diff --git a/drivers/media/platform/exynos-mscl/Makefile b/drivers/media/platform/exynos-mscl/Makefile new file mode 100644 index 000..c9ffcd8 --- /dev/null +++ b/drivers/media/platform/exynos-mscl/Makefile @@ -0,0 +1,3 @@ +exynos-mscl-objs := mscl-core.o mscl-m2m.o mscl-regs.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_MSCL)+= exynos-mscl.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] [media] exynos-mscl: Add m2m functionality for the M-Scaler driver
This patch adds the memory to memory (m2m) interface functionality
for the M-Scaler driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-m2m.c | 763 +
1 file changed, 763 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c
diff --git a/drivers/media/platform/exynos-mscl/mscl-m2m.c
b/drivers/media/platform/exynos-mscl/mscl-m2m.c
new file mode 100644
index 000..fecbb57
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-m2m.c
@@ -0,0 +1,763 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include mscl-core.h
+
+static int mscl_m2m_ctx_stop_req(struct mscl_ctx *ctx)
+{
+ struct mscl_ctx *curr_ctx;
+ struct mscl_dev *mscl = ctx-mscl_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(mscl-m2m.m2m_dev);
+ if (!mscl_m2m_pending(mscl) || (curr_ctx != ctx))
+ return 0;
+
+ mscl_ctx_state_lock_set(MSCL_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(mscl-irq_queue,
+ !mscl_ctx_state_is_set(MSCL_CTX_STOP_REQ, ctx),
+ MSCL_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int mscl_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-mscl_dev-pdev-dev);
+
+ return ret 0 ? 0 : ret;
+}
+
+static int mscl_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-mscl_dev-pdev-dev);
+
+ return 0;
+}
+
+void mscl_m2m_job_finish(struct mscl_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-mscl_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+
+static void mscl_m2m_job_abort(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+static int mscl_get_bufs(struct mscl_ctx *ctx)
+{
+ struct mscl_frame *s_frame, *d_frame;
+ struct vb2_buffer *src_vb, *dst_vb;
+ int ret;
+
+ s_frame = ctx-s_frame;
+ d_frame = ctx-d_frame;
+
+ src_vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, src_vb, s_frame, s_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, dst_vb, d_frame, d_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb-v4l2_buf.timestamp = src_vb-v4l2_buf.timestamp;
+
+ return 0;
+}
+
+static void mscl_m2m_device_run(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ struct mscl_dev *mscl;
+ unsigned long flags;
+ int ret;
+ bool is_set = false;
+
+ if (WARN(!ctx, null hardware context\n))
+ return;
+
+ mscl = ctx-mscl_dev;
+ spin_lock_irqsave(mscl-slock, flags);
+
+ set_bit(ST_M2M_PEND, mscl-state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (mscl-m2m.ctx != ctx) {
+ dev_dbg(mscl-pdev-dev,
+ mscl-m2m.ctx = 0x%p, current_ctx = 0x%p,
+ mscl-m2m.ctx, ctx);
+ ctx-state |= MSCL_PARAMS;
+ mscl-m2m.ctx = ctx;
+ }
+
+ is_set = (ctx-state MSCL_CTX_STOP_REQ) ? 1 : 0;
+ ctx-state = ~MSCL_CTX_STOP_REQ;
+ if (is_set) {
+ wake_up(mscl-irq_queue);
+ goto put_device;
+ }
+
+ ret = mscl_get_bufs(ctx);
+ if (ret) {
+ dev_dbg(mscl-pdev-dev, Wrong address);
+ goto put_device;
+ }
+
+ mscl_hw_address_queue_reset(ctx);
+ mscl_set_prefbuf(mscl, ctx-s_frame);
+ mscl_hw_set_input_addr(mscl, ctx-s_frame.addr);
+
Re: [v2] mt9v032: Use the common clock framework
Hi Peter, On Tuesday 13 August 2013 04:31:30 Peter A. Bigot wrote: FWIW: I found it necessary to use this along with http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/board/overo/ mt9v032 to get the Caspa to work on Gumstix under Linux 3.10. That's expected :-) Work is still needed to implement device tree support in the OMAP3 ISP driver, after that we shouldn't need any board code modification anymore. (Without configuring the clock the device won't respond to I2C operations. It still doesn't work right, but that may not be a driver problem. It's also necessary under 3.8, which has serious problems with CCDC idle messages that I haven't tracked down yet.) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/5] Exynos5 M-Scaler Driver
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Shaik Ameer Basha Sent: Monday, August 19, 2013 7:59 PM To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org Cc: s.nawro...@samsung.com; posc...@google.com; arun...@samsung.com; shaik.am...@samsung.com Subject: [PATCH v2 0/5] Exynos5 M-Scaler Driver This patch adds support for M-Scaler (M2M Scaler) device which is a new device for scaling, blending, color fill and color space conversion on EXYNOS5 SoCs. All Exynos5 SoCs really have this IP? It seems that only Exynos5420 and maybe Exynos5410 have this IP, NOT Exynos5250. Please check it again and describe it surely over the all patch series. Thanks, Inki Dae This device supports the following as key features. input image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB, L8A8 and L8 output image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB input rotation - 0/90/180/270 degree, X/Y/XY Flip scale ratio - 1/4 scale down to 16 scale up color space conversion - RGB to YUV / YUV to RGB Size - Input : 16x16 to 8192x8192 - Output: 4x4 to 8192x8192 alpha blending, color fill Rebased on: --- git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master Changes from v1: --- 1] Split the previous single patch into multiple patches. 2] Added DT binding documentation. 3] Removed the unnecessary header file inclusions. 4] Fix the condition check in mscl_prepare_address for swapping cb/cr addresses. Shaik Ameer Basha (5): [media] exynos-mscl: Add new driver for M-Scaler [media] exynos-mscl: Add core functionality for the M-Scaler driver [media] exynos-mscl: Add m2m functionality for the M-Scaler driver [media] exynos-mscl: Add DT bindings for M-Scaler driver [media] exynos-mscl: Add Makefile for M-Scaler driver .../devicetree/bindings/media/exynos5-mscl.txt | 34 + drivers/media/platform/Kconfig |8 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos-mscl/Makefile|3 + drivers/media/platform/exynos-mscl/mscl-core.c | 1312 drivers/media/platform/exynos-mscl/mscl-core.h | 549 drivers/media/platform/exynos-mscl/mscl-m2m.c | 763 drivers/media/platform/exynos-mscl/mscl-regs.c | 318 + drivers/media/platform/exynos-mscl/mscl-regs.h | 282 + 9 files changed, 3270 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5- mscl.txt create mode 100644 drivers/media/platform/exynos-mscl/Makefile create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] drm/radeon: rework to new fence interface
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(rdev-fence_drv[ring].last_seq, seq) seq);
- if (wake) {
+ if (wake)
rdev-fence_drv[ring].last_activity = jiffies;
- wake_up_all(rdev-fence_queue);
- }
+ return wake;
}
Very bad idea, when sequence numbers change, you always want to wake up
the whole fence queue here.
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+ struct radeon_fence *fence = to_radeon_fence(f);
+
+ if (atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq ||
+ !fence-rdev-ddev-irq_enabled)
+ return false;
+
Do I get that right that you rely on IRQs to be enabled and working
here? Cause that would be a quite bad idea from the conceptual side.
+ radeon_irq_kms_sw_irq_get(fence-rdev, fence-ring);
+
+ if (__radeon_fence_process(fence-rdev, fence-ring))
+ wake_up_all_locked(fence-rdev-fence_queue);
+
+ /* did fence get signaled after we enabled the sw irq? */
+ if (atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq) {
+ radeon_irq_kms_sw_irq_put(fence-rdev, fence-ring);
+ return false;
+ }
+
+ fence-fence_wake.flags = 0;
+ fence-fence_wake.private = NULL;
+ fence-fence_wake.func = radeon_fence_check_signaled;
+ __add_wait_queue(fence-rdev-fence_queue, fence-fence_wake);
+ fence_get(f);
+
+ return true;
+}
+
/**
* radeon_fence_signaled - check if a fence has signaled
*
Christian.
--
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 v2 4/5] [media] exynos-mscl: Add DT bindings for M-Scaler driver
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shaik Ameer Basha
Sent: Monday, August 19, 2013 7:59 PM
To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: s.nawro...@samsung.com; posc...@google.com; arun...@samsung.com;
shaik.am...@samsung.com
Subject: [PATCH v2 4/5] [media] exynos-mscl: Add DT bindings for M-Scaler
driver
This patch adds the DT binding documentation for the exynos5
based M-Scaler device driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
.../devicetree/bindings/media/exynos5-mscl.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-
mscl.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-mscl.txt
b/Documentation/devicetree/bindings/media/exynos5-mscl.txt
new file mode 100644
index 000..5c9d1b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-mscl.txt
@@ -0,0 +1,34 @@
+* Samsung Exynos5 M-Scaler device
+
+M-Scaler is used for scaling, blending, color fill and color space
+conversion on EXYNOS5 SoCs.
+
+Required properties:
+- compatible: should be samsung,exynos5-mscl
If Exynos5410/5420 have same IP,
samsung,exynos5410-mscl for M Scaler IP in Exynos5410/5420
Else,
Compatible: should be one of the following:
(a) samsung,exynos5410-mscl for M Scaler IP in Exynos5410
(b) samsung,exynos5420-mscl for M Scaler IP in Exynos5420
+- reg: should contain M-Scaler physical address location and length.
+- interrupts: should contain M-Scaler interrupt number
+- clocks: should contain the clock number according to CCF
+- clock-names: should be mscl
+
+Example:
+
+ mscl_0: mscl@0x1280 {
+ compatible = samsung,exynos5-mscl;
samsung,exynos5410-mscl;
+ reg = 0x1280 0x1000;
+ interrupts = 0 220 0;
+ clocks = clock 381;
+ clock-names = mscl;
+ };
+
+Aliases:
+Each M-Scaler node should have a numbered alias in the aliases node,
+in the form of msclN, N = 0...2. M-Scaler driver uses these aliases
+to retrieve the device IDs using of_alias_get_id() call.
+
+Example:
+
+aliases {
+ mscl0 =mscl_0;
+ mscl1 =mscl_1;
+ mscl2 =mscl_2;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v2 3/5] [media] exynos-mscl: Add m2m functionality for the M-Scaler driver
On 08/19/2013 12:58 PM, Shaik Ameer Basha wrote:
This patch adds the memory to memory (m2m) interface functionality
for the M-Scaler driver.
Just one small comment below...
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-m2m.c | 763
+
1 file changed, 763 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c
diff --git a/drivers/media/platform/exynos-mscl/mscl-m2m.c
b/drivers/media/platform/exynos-mscl/mscl-m2m.c
new file mode 100644
index 000..fecbb57
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-m2m.c
@@ -0,0 +1,763 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include mscl-core.h
+
+static int mscl_m2m_ctx_stop_req(struct mscl_ctx *ctx)
+{
+ struct mscl_ctx *curr_ctx;
+ struct mscl_dev *mscl = ctx-mscl_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(mscl-m2m.m2m_dev);
+ if (!mscl_m2m_pending(mscl) || (curr_ctx != ctx))
+ return 0;
+
+ mscl_ctx_state_lock_set(MSCL_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(mscl-irq_queue,
+ !mscl_ctx_state_is_set(MSCL_CTX_STOP_REQ, ctx),
+ MSCL_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int mscl_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-mscl_dev-pdev-dev);
+
+ return ret 0 ? 0 : ret;
+}
+
+static int mscl_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-mscl_dev-pdev-dev);
+
+ return 0;
+}
+
+void mscl_m2m_job_finish(struct mscl_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-mscl_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+
+static void mscl_m2m_job_abort(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+static int mscl_get_bufs(struct mscl_ctx *ctx)
+{
+ struct mscl_frame *s_frame, *d_frame;
+ struct vb2_buffer *src_vb, *dst_vb;
+ int ret;
+
+ s_frame = ctx-s_frame;
+ d_frame = ctx-d_frame;
+
+ src_vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, src_vb, s_frame, s_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, dst_vb, d_frame, d_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb-v4l2_buf.timestamp = src_vb-v4l2_buf.timestamp;
+
+ return 0;
+}
+
+static void mscl_m2m_device_run(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ struct mscl_dev *mscl;
+ unsigned long flags;
+ int ret;
+ bool is_set = false;
+
+ if (WARN(!ctx, null hardware context\n))
+ return;
+
+ mscl = ctx-mscl_dev;
+ spin_lock_irqsave(mscl-slock, flags);
+
+ set_bit(ST_M2M_PEND, mscl-state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (mscl-m2m.ctx != ctx) {
+ dev_dbg(mscl-pdev-dev,
+ mscl-m2m.ctx = 0x%p, current_ctx = 0x%p,
+ mscl-m2m.ctx, ctx);
+ ctx-state |= MSCL_PARAMS;
+ mscl-m2m.ctx = ctx;
+ }
+
+ is_set = (ctx-state MSCL_CTX_STOP_REQ) ? 1 : 0;
+ ctx-state = ~MSCL_CTX_STOP_REQ;
+ if (is_set) {
+ wake_up(mscl-irq_queue);
+ goto put_device;
+ }
+
+ ret = mscl_get_bufs(ctx);
+ if (ret) {
+ dev_dbg(mscl-pdev-dev, Wrong address);
+ goto put_device;
+ }
+
+ mscl_hw_address_queue_reset(ctx);
+ mscl_set_prefbuf(mscl,
Re: [PATCH v2 2/5] [media] exynos-mscl: Add core functionality for the M-Scaler driver
On 08/19/2013 12:58 PM, Shaik Ameer Basha wrote:
This patch adds the core functionality for the M-Scaler driver.
Some more comments below...
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-core.c | 1312
drivers/media/platform/exynos-mscl/mscl-core.h | 549 ++
2 files changed, 1861 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h
diff --git a/drivers/media/platform/exynos-mscl/mscl-core.c
b/drivers/media/platform/exynos-mscl/mscl-core.c
new file mode 100644
index 000..4a3a851
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-core.c
@@ -0,0 +1,1312 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
+
+#include mscl-core.h
+
+#define MSCL_CLOCK_GATE_NAME mscl
+
+static const struct mscl_fmt mscl_formats[] = {
+ {
+ .name = YUV 4:2:0 non-contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12M,
+ .depth = { 8, 4 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+
+ }, {
+ .name = YUV 4:2:0 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV12,
+ .depth = { 12 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = YUV 4:2:0 n.c. 2p, Y/CbCr tiled,
+ .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+ .depth = { 8, 4 },
+ .color = MSCL_YUV420,
+ .corder = MSCL_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV420_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC),
+ .is_tiled = true,
+ }, {
+ .name = YUV 4:2:2 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV16,
+ .depth = { 16 },
+ .color = MSCL_YUV422,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV422_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = YUV 4:4:4 contig. 2p, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV24,
+ .depth = { 24 },
+ .color = MSCL_YUV444,
+ .corder = MSCL_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .mscl_color = MSCL_YUV444_2P_Y_UV,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565X,
+ .depth = { 16 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_RGB565,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = XRGB-1555, 16 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB555,
+ .depth = { 16 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_ARGB1555,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC | MSCL_FMT_DST),
+ }, {
+ .name = XRGB-, 32 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+ .depth = { 32 },
+ .color = MSCL_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mscl_color = MSCL_ARGB,
+ .mscl_color_fmt_type = (MSCL_FMT_SRC |
Re: [PATCH v2 3/5] [media] exynos-mscl: Add m2m functionality for the M-Scaler driver
On 08/19/2013 02:58 PM, Hans Verkuil wrote:
On 08/19/2013 12:58 PM, Shaik Ameer Basha wrote:
This patch adds the memory to memory (m2m) interface functionality
for the M-Scaler driver.
Just one small comment below...
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-m2m.c | 763
+
1 file changed, 763 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c
diff --git a/drivers/media/platform/exynos-mscl/mscl-m2m.c
b/drivers/media/platform/exynos-mscl/mscl-m2m.c
new file mode 100644
index 000..fecbb57
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-m2m.c
@@ -0,0 +1,763 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include mscl-core.h
+
+static int mscl_m2m_ctx_stop_req(struct mscl_ctx *ctx)
+{
+struct mscl_ctx *curr_ctx;
+struct mscl_dev *mscl = ctx-mscl_dev;
+int ret;
+
+curr_ctx = v4l2_m2m_get_curr_priv(mscl-m2m.m2m_dev);
+if (!mscl_m2m_pending(mscl) || (curr_ctx != ctx))
+return 0;
+
+mscl_ctx_state_lock_set(MSCL_CTX_STOP_REQ, ctx);
+ret = wait_event_timeout(mscl-irq_queue,
+!mscl_ctx_state_is_set(MSCL_CTX_STOP_REQ, ctx),
+MSCL_SHUTDOWN_TIMEOUT);
+
+return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int mscl_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+struct mscl_ctx *ctx = q-drv_priv;
+int ret;
+
+ret = pm_runtime_get_sync(ctx-mscl_dev-pdev-dev);
+
+return ret 0 ? 0 : ret;
+}
+
+static int mscl_m2m_stop_streaming(struct vb2_queue *q)
+{
+struct mscl_ctx *ctx = q-drv_priv;
+int ret;
+
+ret = mscl_m2m_ctx_stop_req(ctx);
+if (ret == -ETIMEDOUT)
+mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+pm_runtime_put(ctx-mscl_dev-pdev-dev);
+
+return 0;
+}
+
+void mscl_m2m_job_finish(struct mscl_ctx *ctx, int vb_state)
+{
+struct vb2_buffer *src_vb, *dst_vb;
+
+if (!ctx || !ctx-m2m_ctx)
+return;
+
+src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+if (src_vb dst_vb) {
+v4l2_m2m_buf_done(src_vb, vb_state);
+v4l2_m2m_buf_done(dst_vb, vb_state);
+
+v4l2_m2m_job_finish(ctx-mscl_dev-m2m.m2m_dev,
+ctx-m2m_ctx);
+}
+}
+
+
+static void mscl_m2m_job_abort(void *priv)
+{
+struct mscl_ctx *ctx = priv;
+int ret;
+
+ret = mscl_m2m_ctx_stop_req(ctx);
+if (ret == -ETIMEDOUT)
+mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+static int mscl_get_bufs(struct mscl_ctx *ctx)
+{
+struct mscl_frame *s_frame, *d_frame;
+struct vb2_buffer *src_vb, *dst_vb;
+int ret;
+
+s_frame = ctx-s_frame;
+d_frame = ctx-d_frame;
+
+src_vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ret = mscl_prepare_addr(ctx, src_vb, s_frame, s_frame-addr);
+if (ret)
+return ret;
+
+dst_vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ret = mscl_prepare_addr(ctx, dst_vb, d_frame, d_frame-addr);
+if (ret)
+return ret;
+
+dst_vb-v4l2_buf.timestamp = src_vb-v4l2_buf.timestamp;
+
+return 0;
+}
+
+static void mscl_m2m_device_run(void *priv)
+{
+struct mscl_ctx *ctx = priv;
+struct mscl_dev *mscl;
+unsigned long flags;
+int ret;
+bool is_set = false;
+
+if (WARN(!ctx, null hardware context\n))
+return;
+
+mscl = ctx-mscl_dev;
+spin_lock_irqsave(mscl-slock, flags);
+
+set_bit(ST_M2M_PEND, mscl-state);
+
+/* Reconfigure hardware if the context has changed. */
+if (mscl-m2m.ctx != ctx) {
+dev_dbg(mscl-pdev-dev,
+mscl-m2m.ctx = 0x%p, current_ctx = 0x%p,
+mscl-m2m.ctx, ctx);
+ctx-state |= MSCL_PARAMS;
+mscl-m2m.ctx = ctx;
+}
+
+is_set = (ctx-state MSCL_CTX_STOP_REQ) ? 1 : 0;
+ctx-state = ~MSCL_CTX_STOP_REQ;
+if (is_set) {
+wake_up(mscl-irq_queue);
+goto put_device;
+}
+
+ret = mscl_get_bufs(ctx);
+if (ret) {
+dev_dbg(mscl-pdev-dev, Wrong address);
+goto put_device;
+}
+
+mscl_hw_address_queue_reset(ctx);
+mscl_set_prefbuf(mscl, ctx-s_frame);
+
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; You probably want to use the [name-]gpios convention here (see Documentation/devicetree/bindings/gpio/gpio.txt), so something like stbyn-gpios and rstn-gpios. Pawel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On Mon, Aug 19, 2013 at 02:18:27PM +0100, Andrzej Hajda wrote:
Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor
with embedded SoC ISP.
The driver exposes the sensor as two V4L2 subdevices:
- S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
no controls.
- S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
pre/post ISP cropping, downscaling via selection API, controls.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
v5
- removed non-standard samsung hflip/vflip device tree bindings
v4
- GPL changed to GPLv2,
- bitfields replaced by u8,
- cosmetic changes,
- corrected s_stream flow,
- gpio pins are no longer exported,
- added I2C addresses to subdev names,
- CIS subdev registration postponed after
succesfull HW initialization,
- added enums for pads,
- selections are initialized only during probe,
- default resolution changed to 1600x1200,
- state-error pattern removed from few other functions,
- entity link creation moved to registered callback.
v3:
- narrowed state-error usage to i2c and power errors,
- private gain controls replaced by red/blue balance user controls,
- added checks to devicetree gpio node parsing
v2:
- lower-cased driver name,
- removed underscore from regulator names,
- removed platform data code,
- v4l controls grouped in anonymous structs,
- added s5k5baf_clear_error function,
- private controls definitions moved to uapi header file,
- added v4l2-controls.h reservation for private controls,
- corrected subdev registered/unregistered code,
- .log_status sudbev op set to v4l2 helper,
- moved entity link creation to probe routines,
- added cleanup on error to probe function.
---
.../devicetree/bindings/media/samsung-s5k5baf.txt | 51 +
MAINTAINERS|7 +
drivers/media/i2c/Kconfig |7 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k5baf.c| 1980
5 files changed, 2046 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
create mode 100644 drivers/media/i2c/s5k5baf.c
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
new file mode 100644
index 000..b1f2fde
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
@@ -0,0 +1,51 @@
+Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP
+-
+
+Required properties:
+
+- compatible : samsung,s5k5baf;
+- reg: I2C slave address of the sensor;
+- vdda-supply: analog power supply 2.8V (2.6V to 3.0V);
+- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V)
+or 2.8V (2.6V to 3.0);
+- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V)
+or 2.8V (2.5V to 3.1V);
+- gpios : GPIOs connected to STDBYN and RSTN pins,
+in order: STBYN, RSTN;
+- clock-frequency : master clock frequency in Hz;
Why is this necessary? Could you not just require having a clocks
property? You could then get equivalent functionality to the
clock-frequency property by having a fixed-clock node if you don't ahve
a real clock specifier to wire up.
+
+Optional properties:
+
+- clocks : contains the sensor's master clock specifier;
+- clock-names: contains mclk entry;
+
+The device node should contain one 'port' child node with one child
'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those
nodes.
+
+endpoint node
+-
+
+- data-lanes : (optional) an array specifying active physical MIPI-CSI2
+ data output lanes and their mapping to logical lanes; the
+ array's content is unused, only its length is meaningful;
Is that a property of the driver, or does the design of the hardware
mean that this can never encode useful information?
What does the length of the property imply?
+
+Example:
+
+s5k5bafx@2d {
+ compatible = samsung,s5k5baf;
+ reg = 0x2d;
+ vdda-supply = cam_io_en_reg;
+ vddreg-supply = vt_core_15v_reg;
+ vddio-supply = vtcam_reg;
+ gpios = gpl2 0 1,
+ gpl2 1 1;
+ clock-frequency = 2400;
+
+ port {
+ s5k5bafx_ep: endpoint {
+ remote-endpoint = csis1_ep;
+ data-lanes = 1;
+ };
+ };
+};
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
avermedia A306 / PCIe-minicard (laptop)
Hello I have this card since months, http://www.avermedia.com/avertv/Product/ProductDetail.aspx?Id=376SI=true I have finally retested it with the cx23885 driver : card=39 If I could do anything to identify : [ 2.414734] cx23885[0]: i2c scan: found device @ 0x66 [???] Or hookup the xc5000 etc I'll be more than glad . root@medeb:~# dmesg | grep -i cx [ 2.140445] cx23885 driver version 0.0.3 loaded [ 2.140949] CORE cx23885[0]: subsystem: 1461:c139, board: AVerTV Hybrid Express Slim HC81R [card=39,insmod option] [ 2.375411] cx23885[0]: scan bus 0: [ 2.387018] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom] [ 2.393978] cx23885[0]: scan bus 1: [ 2.407961] cx23885[0]: i2c scan: found device @ 0xc2 [tuner/mt2131/tda8275/xc5000/xc3028] [ 2.412550] cx23885[0]: scan bus 2: [ 2.414734] cx23885[0]: i2c scan: found device @ 0x66 [???] [ 2.415569] cx23885[0]: i2c scan: found device @ 0x88 [cx25837] [ 2.416062] cx23885[0]: i2c scan: found device @ 0x98 [flatiron] [ 2.450115] cx25840 3-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [ 3.090011] cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 3.111328] cx23885[0]: registered device video1 [v4l2] [ 3.111597] cx23885[0]: registered device vbi0 [ 3.111884] cx23885[0]: registered ALSA audio device [ 4.690855] cx23885_dev_checkrevision() Hardware revision = 0xb0 [ 4.691054] cx23885[0]/0: found at :05:00.0, rev: 2, irq: 18, latency: 0, mmio: 0xd300 [ 325.767037] usbcore: registered new interface driver cx231xx [ 325.767948] cx231xx: Cx231xx dvb Extension initialized [ 347.921336] cx231xx: Cx231xx dvb Extension removed [ 354.682367] cx231xx_dvb: `' invalid for parameter `debug' [ 358.874607] cx231xx: Cx231xx dvb Extension initialized [ 365.393339] cx231xx: Cx231xx dvb Extension removed [ 367.306463] cx231xx: Cx231xx dvb Extension initialized root@medeb:~# also tuner-xc2028 sees it [ 2.407961] cx23885[0]: i2c scan: found device @ 0xc2 [tuner/mt2131/tda8275/xc5000/xc3028] [ 3.110806] xc2028: Xcv2028/3028 init called! [ 3.110809] xc2028 2-0061: creating new instance [ 3.111025] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner [ 3.111218] xc2028 2-0061: xc2028_set_config called [ 3.112079] xc2028 2-0061: request_firmware_nowait(): OK [ 3.112080] xc2028 2-0061: load_all_firmwares called [ 3.112082] xc2028 2-0061: Loading 81 firmware images from xc3028L-v36.fw, type: xc2028 firmware, ver 3.6 [ 3.112088] xc2028 2-0061: Reading firmware type BASE F8MHZ (3), id 0, size=9144. [ 3.112095] xc2028 2-0061: Reading firmware type BASE F8MHZ MTS (7), id 0, size=9030. [ 3.112101] xc2028 2-0061: Reading firmware type BASE FM (401), id 0, size=9054. [ 3.112109] xc2028 2-0061: Reading firmware type BASE FM INPUT1 (c01), id 0, size=9068. [ 3.112114] xc2028 2-0061: Reading firmware type BASE (1), id 0, size=9132. [ 3.112120] xc2028 2-0061: Reading firmware type BASE MTS (5), id 0, size=9006. [ 3.112123] xc2028 2-0061: Reading firmware type (0), id 7, size=161. [ 3.112124] xc2028 2-0061: Reading firmware type MTS (4), id 7, size=169. [ 3.112126] xc2028 2-0061: Reading firmware type (0), id 7, size=161. [ 3.112127] xc2028 2-0061: Reading firmware type MTS (4), id 7, size=169. [ 3.112128] xc2028 2-0061: Reading firmware type (0), id 7, size=161. [ 3.112130] xc2028 2-0061: Reading firmware type MTS (4), id 7, size=169. [ 3.112133] xc2028 2-0061: Reading firmware type (0), id 7, size=161. [ 3.112137] xc2028 2-0061: Reading firmware type MTS (4), id 7, size=169. [ 3.112138] xc2028 2-0061: Reading firmware type (0), id e0, size=161. [ 3.112140] xc2028 2-0061: Reading firmware type MTS (4), id e0, size=169. [ 3.112141] xc2028 2-0061: Reading firmware type (0), id e0, size=161. [ 3.112143] xc2028 2-0061: Reading firmware type MTS (4), id e0, size=169. [ 3.112144] xc2028 2-0061: Reading firmware type (0), id 20, size=161. [ 3.112146] xc2028 2-0061: Reading firmware type MTS (4), id 20, size=169. [ 3.112147] xc2028 2-0061: Reading firmware type (0), id 400, size=161. [ 3.112149] xc2028 2-0061: Reading firmware type MTS (4), id 400, size=169. [ 3.112151] xc2028 2-0061: Reading firmware type D2633 DTV6 ATSC (10030), id 0, size=149. [ 3.112153] xc2028 2-0061: Reading firmware type D2620 DTV6 QAM (68), id 0, size=149. [ 3.112154] xc2028 2-0061: Reading firmware type D2633 DTV6 QAM (70), id 0, size=149. [ 3.112156] xc2028 2-0061: Reading firmware type D2620 DTV7 (88), id 0, size=149. [ 3.112158] xc2028 2-0061: Reading firmware type D2633 DTV7 (90), id 0, size=149. [ 3.112159] xc2028 2-0061: Reading firmware type D2620 DTV78 (108), id 0, size=149. [ 3.112161] xc2028 2-0061: Reading firmware type D2633 DTV78 (110), id 0, size=149. [ 3.112163] xc2028 2-0061: Reading firmware type D2620 DTV8 (208), id 0, size=149. [ 3.112164] xc2028 2-0061: Reading
[RFCv2 PATCH 00/20] dv-timings/adv7604/ad9389b fixes and new adv7511/adv7842 drivers
This second patch series combines these two earlier patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg65582.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg65510.html While rebasing the new drivers on the latest code I realized that it made more sense to combine the two and to improve the v4l2-dv-timings functions a bit. The first 17 patches apply a bunch of fixes from the internal Cisco tree and it adds a number of improvements to v4l2-dv-timings. If there are no comments regarding those patches, then I intend to make a pull request for them later this week. The final three patches add the new adv7842 and adv7511 drivers. Changes since RFCv1 for those last three: - use the new v4l2_*_dv_timings helpers - use devm_kzalloc TODO: - adv7604 needs to use the new dv-timings helpers as well. It's done for the adv7842, but not yet for the adv7604. - STD handling in adv7842 can be improved: at the moment the s_std value does not set the hardware correctly (the hardware is always set to autodetect). - the adv internal IP blocks are quite similar and parts of it can be refactored. In particular notifier, control and event IDs can easily be shared. - the adv7xxx_check_dv_timings callback should notify the v4l2_device as well in case there are additional constraints in the bridge driver. These TODOs do not block merging these new drivers IMHO and can be done later. 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
[RFCv2 PATCH 02/20] adv7604: debounce format change notifications
From: Mats Randgaard matra...@cisco.com
The bridge driver is only notified when the input status has changed
since the previous interrupt.
Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 3ec7ec0..d093092 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -77,6 +77,7 @@ struct adv7604_state {
struct delayed_work delayed_work_enable_hotplug;
bool connector_hdmi;
bool restart_stdi_once;
+ u32 prev_input_status;
/* i2c clients */
struct i2c_client *i2c_avlink;
@@ -1535,6 +1536,7 @@ static int adv7604_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
{
struct adv7604_state *state = to_state(sd);
u8 fmt_change, fmt_change_digital, tx_5v;
+ u32 input_status;
/* format change */
fmt_change = io_read(sd, 0x43) 0x98;
@@ -1545,9 +1547,18 @@ static int adv7604_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
io_write(sd, 0x6c, fmt_change_digital);
if (fmt_change || fmt_change_digital) {
v4l2_dbg(1, debug, sd,
- %s: ADV7604_FMT_CHANGE, fmt_change = 0x%x,
fmt_change_digital = 0x%x\n,
+ %s: fmt_change = 0x%x, fmt_change_digital = 0x%x\n,
__func__, fmt_change, fmt_change_digital);
- v4l2_subdev_notify(sd, ADV7604_FMT_CHANGE, NULL);
+
+ adv7604_g_input_status(sd, input_status);
+ if (input_status != state-prev_input_status) {
+ v4l2_dbg(1, debug, sd,
+ %s: input_status = 0x%x, prev_input_status =
0x%x\n,
+ __func__, input_status,
state-prev_input_status);
+ state-prev_input_status = input_status;
+ v4l2_subdev_notify(sd, ADV7604_FMT_CHANGE, NULL);
+ }
+
if (handled)
*handled = true;
}
@@ -1953,6 +1964,10 @@ static int adv7604_probe(struct i2c_client *client,
return -ENOMEM;
}
+ /* initialize variables */
+ state-restart_stdi_once = true;
+ state-prev_input_status = ~0;
+
/* platform data */
if (!pdata) {
v4l_err(client, No platform data!\n);
@@ -2036,7 +2051,6 @@ static int adv7604_probe(struct i2c_client *client,
v4l2_err(sd, failed to create all i2c clients\n);
goto err_i2c;
}
- state-restart_stdi_once = true;
/* work queues */
state-work_queues = create_singlethread_workqueue(client-name);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 10/20] v4l2-dv-timings: add v4l2_print_dv_timings helper
From: Hans Verkuil hans.verk...@cisco.com
Drivers often have to log the contents of a dv_timings struct. Adding
this helper will make it easier for drivers to do so.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dv-timings.c | 49 +++
include/media/v4l2-dv-timings.h | 9 ++
2 files changed, 58 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 72cf224..917e58c 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -223,6 +223,55 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
}
EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
+ const struct v4l2_dv_timings *t, bool detailed)
+{
+ const struct v4l2_bt_timings *bt = t-bt;
+ u32 htot, vtot;
+
+ if (t-type != V4L2_DV_BT_656_1120)
+ return;
+
+ htot = V4L2_DV_BT_FRAME_WIDTH(bt);
+ vtot = V4L2_DV_BT_FRAME_HEIGHT(bt);
+
+ if (prefix == NULL)
+ prefix = ;
+
+ pr_info(%s: %s%ux%u%s%u (%ux%u)\n, dev_prefix, prefix,
+ bt-width, bt-height, bt-interlaced ? i : p,
+ (htot * vtot) 0 ? ((u32)bt-pixelclock / (htot * vtot)) : 0,
+ htot, vtot);
+
+ if (!detailed)
+ return;
+
+ pr_info(%s: horizontal: fp = %u, %ssync = %u, bp = %u\n,
+ dev_prefix, bt-hfrontporch,
+ (bt-polarities V4L2_DV_HSYNC_POS_POL) ? + : -,
+ bt-hsync, bt-hbackporch);
+ pr_info(%s: vertical: fp = %u, %ssync = %u, bp = %u\n,
+ dev_prefix, bt-vfrontporch,
+ (bt-polarities V4L2_DV_VSYNC_POS_POL) ? + : -,
+ bt-vsync, bt-vbackporch);
+ pr_info(%s: pixelclock: %llu\n, dev_prefix, bt-pixelclock);
+ pr_info(%s: flags (0x%x):%s%s%s%s\n, dev_prefix, bt-flags,
+ (bt-flags V4L2_DV_FL_REDUCED_BLANKING) ?
+REDUCED_BLANKING : ,
+ (bt-flags V4L2_DV_FL_CAN_REDUCE_FPS) ?
+CAN_REDUCE_FPS : ,
+ (bt-flags V4L2_DV_FL_REDUCED_FPS) ?
+REDUCED_FPS : ,
+ (bt-flags V4L2_DV_FL_HALF_LINE) ?
+HALF_LINE : );
+ pr_info(%s: standards (0x%x):%s%s%s%s\n, dev_prefix, bt-standards,
+ (bt-standards V4L2_DV_BT_STD_CEA861) ? CEA : ,
+ (bt-standards V4L2_DV_BT_STD_DMT) ? DMT : ,
+ (bt-standards V4L2_DV_BT_STD_CVT) ? CVT : ,
+ (bt-standards V4L2_DV_BT_STD_GTF) ? GTF : );
+}
+EXPORT_SYMBOL_GPL(v4l2_print_dv_timings);
+
/*
* CVT defines
* Based on Coordinated Video Timings Standard
diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 4c7bb54..696e5c2 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -76,6 +76,15 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings
*measured,
const struct v4l2_dv_timings *standard,
unsigned pclock_delta);
+/** v4l2_print_dv_timings() - log the contents of a dv_timings struct
+ * @dev_prefix:device prefix for each log line.
+ * @prefix: additional prefix for each log line, may be NULL.
+ * @t:the timings data.
+ * @detailed: if true, give a detailed log.
+ */
+void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
+ const struct v4l2_dv_timings *t, bool detailed);
+
/** v4l2_detect_cvt - detect if the given timings follow the CVT standard
* @frame_height - the total height of the frame (including blanking) in lines.
* @hfreq - the horizontal frequency in Hz.
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 07/20] ad9389b: trigger edid re-read by power-cycle chip
From: Martin Bugge marbu...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 52384e8..545aabb 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -855,8 +855,10 @@ static void ad9389b_edid_handler(struct work_struct *work)
* (DVI connectors are particularly prone to this problem). */
if (state-edid.read_retries) {
state-edid.read_retries--;
- /* EDID read failed, trigger a retry */
- ad9389b_wr(sd, 0xc9, 0xf);
+ v4l2_dbg(1, debug, sd, %s: edid read failed\n,
__func__);
+ state-have_monitor = false;
+ ad9389b_s_power(sd, false);
+ ad9389b_s_power(sd, true);
queue_delayed_work(state-work_queue,
state-edid_handler, EDID_DELAY);
return;
@@ -1019,7 +1021,6 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev
*sd)
segment = ad9389b_rd(sd, 0xc4);
if (segment = EDID_MAX_SEGM) {
v4l2_err(sd, edid segment number too big\n);
- state-have_monitor = false;
return false;
}
v4l2_dbg(1, debug, sd, %s: got segment %d\n, __func__, segment);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 03/20] adv7604: pixel-clock depends on deep-color-mode
From: Martin Bugge marbu...@cisco.com
The frequency calculation has to take deep-color mode into account.
While we're at it, also log the deep-color mode in log_status.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d093092..6ffe25a 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -992,6 +992,11 @@ static inline bool no_lock_tmds(struct v4l2_subdev *sd)
return (io_read(sd, 0x6a) 0xe0) != 0xe0;
}
+static inline bool is_hdmi(struct v4l2_subdev *sd)
+{
+ return hdmi_read(sd, 0x05) 0x80;
+}
+
static inline bool no_lock_sspd(struct v4l2_subdev *sd)
{
/* TODO channel 2 */
@@ -1244,12 +1249,21 @@ static int adv7604_query_dv_timings(struct v4l2_subdev
*sd,
V4L2_DV_INTERLACED : V4L2_DV_PROGRESSIVE;
if (DIGITAL_INPUT) {
+ uint32_t freq;
+
timings-type = V4L2_DV_BT_656_1120;
bt-width = (hdmi_read(sd, 0x07) 0x0f) * 256 + hdmi_read(sd,
0x08);
bt-height = (hdmi_read(sd, 0x09) 0x0f) * 256 + hdmi_read(sd,
0x0a);
- bt-pixelclock = (hdmi_read(sd, 0x06) * 100) +
+ freq = (hdmi_read(sd, 0x06) * 100) +
((hdmi_read(sd, 0x3b) 0x30) 4) * 25;
+ if (is_hdmi(sd)) {
+ /* adjust for deep color mode */
+ unsigned bits_per_channel = ((hdmi_read(sd, 0x0b)
0x60) 4) + 8;
+
+ freq = freq * 8 / bits_per_channel;
+ }
+ bt-pixelclock = freq;
bt-hfrontporch = (hdmi_read(sd, 0x20) 0x03) * 256 +
hdmi_read(sd, 0x21);
bt-hsync = (hdmi_read(sd, 0x22) 0x03) * 256 +
@@ -1637,7 +1651,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
u8 avi_len;
u8 avi_ver;
- if (!(hdmi_read(sd, 0x05) 0x80)) {
+ if (!is_hdmi(sd)) {
v4l2_info(sd, receive DVI-D signal (AVI infoframe not
supported)\n);
return;
}
@@ -1698,6 +1712,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
RGB limited range (16-235),
RGB full range (0-255),
};
+ char *deep_color_mode_txt[4] = {
+ 8-bits per channel,
+ 10-bits per channel,
+ 12-bits per channel,
+ 16-bits per channel (not supported)
+ };
v4l2_info(sd, -Chip status-\n);
v4l2_info(sd, Chip power: %s\n, no_power(sd) ? off : on);
@@ -1756,7 +1776,9 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
v4l2_info(sd, -HDMI status-\n);
v4l2_info(sd, HDCP encrypted content: %s\n,
hdmi_read(sd, 0x05) 0x40 ? true : false);
-
+ if (is_hdmi(sd))
+ v4l2_info(sd, deep color mode: %s\n,
+ deep_color_mode_txt[(hdmi_read(sd,
0x0b) 5) 0x3]);
print_avi_infoframe(sd);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 05/20] adv7604: print flags and standards in timing information
From: Mats Randgaard matra...@cisco.com
Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 34fcdf3..e732c9b 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1052,7 +1052,8 @@ static int adv7604_g_input_status(struct v4l2_subdev *sd,
u32 *status)
/* --- */
static void adv7604_print_timings(struct v4l2_subdev *sd,
- struct v4l2_dv_timings *timings, const char *txt, bool detailed)
+ struct v4l2_dv_timings *timings,
+ const char *txt, bool detailed)
{
struct v4l2_bt_timings *bt = timings-bt;
u32 htot, vtot;
@@ -1069,18 +1070,32 @@ static void adv7604_print_timings(struct v4l2_subdev
*sd,
(htot * vtot)) : 0,
htot, vtot);
- if (detailed) {
- v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
- bt-hfrontporch,
- (bt-polarities V4L2_DV_HSYNC_POS_POL) ? +
: -,
- bt-hsync, bt-hbackporch);
- v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
- bt-vfrontporch,
- (bt-polarities V4L2_DV_VSYNC_POS_POL) ? +
: -,
- bt-vsync, bt-vbackporch);
- v4l2_info(sd, pixelclock: %lld, flags: 0x%x, standards:
0x%x\n,
- bt-pixelclock, bt-flags, bt-standards);
- }
+ if (!detailed)
+ return;
+
+ v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
+ bt-hfrontporch,
+ (bt-polarities V4L2_DV_HSYNC_POS_POL) ? + : -,
+ bt-hsync, bt-hbackporch);
+ v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
+ bt-vfrontporch,
+ (bt-polarities V4L2_DV_VSYNC_POS_POL) ? + : -,
+ bt-vsync, bt-vbackporch);
+ v4l2_info(sd, pixelclock: %lld\n, bt-pixelclock);
+ v4l2_info(sd, flags (0x%x):%s%s%s%s\n, bt-flags,
+ (bt-flags V4L2_DV_FL_REDUCED_BLANKING) ?
+Reduced blanking, : ,
+ (bt-flags V4L2_DV_FL_CAN_REDUCE_FPS) ?
+Can reduce FPS, : ,
+ (bt-flags V4L2_DV_FL_REDUCED_FPS) ?
+Reduced FPS, : ,
+ (bt-flags V4L2_DV_FL_HALF_LINE) ?
+Half line, : );
+ v4l2_info(sd, standards (0x%x):%s%s%s%s\n, bt-standards,
+ (bt-standards V4L2_DV_BT_STD_CEA861) ? CEA, : ,
+ (bt-standards V4L2_DV_BT_STD_DMT) ? DMT, : ,
+ (bt-standards V4L2_DV_BT_STD_CVT) ? CVT : ,
+ (bt-standards V4L2_DV_BT_STD_GTF) ? GTF : );
}
struct stdi_readback {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 16/20] v4l2-dv-timings: rename v4l2_dv_valid_timings to v4l2_valid_dv_timings
From: Hans Verkuil hans.verk...@cisco.com
All other functions follow the v4l2_foo_dv_timings pattern, do the same for
this function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 2 +-
drivers/media/i2c/ths8200.c | 2 +-
drivers/media/v4l2-core/v4l2-dv-timings.c | 10 +-
include/media/v4l2-dv-timings.h | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index bb74fb6..fc60851 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -648,7 +648,7 @@ static int ad9389b_s_dv_timings(struct v4l2_subdev *sd,
v4l2_dbg(1, debug, sd, %s:\n, __func__);
/* quick sanity check */
- if (!v4l2_dv_valid_timings(timings, ad9389b_timings_cap))
+ if (!v4l2_valid_dv_timings(timings, ad9389b_timings_cap))
return -EINVAL;
/* Fill the optional fields .standards and .flags in struct
v4l2_dv_timings
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index 580bd1b..6abf0fb 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -378,7 +378,7 @@ static int ths8200_s_dv_timings(struct v4l2_subdev *sd,
v4l2_dbg(1, debug, sd, %s:\n, __func__);
- if (!v4l2_dv_valid_timings(timings, ths8200_timings_cap))
+ if (!v4l2_valid_dv_timings(timings, ths8200_timings_cap))
return -EINVAL;
if (!v4l2_find_dv_timings_cap(timings, ths8200_timings_cap, 10)) {
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index f515997..a77f201 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -131,7 +131,7 @@ const struct v4l2_dv_timings v4l2_dv_timings_presets[] = {
};
EXPORT_SYMBOL_GPL(v4l2_dv_timings_presets);
-bool v4l2_dv_valid_timings(const struct v4l2_dv_timings *t,
+bool v4l2_valid_dv_timings(const struct v4l2_dv_timings *t,
const struct v4l2_dv_timings_cap *dvcap)
{
const struct v4l2_bt_timings *bt = t-bt;
@@ -153,7 +153,7 @@ bool v4l2_dv_valid_timings(const struct v4l2_dv_timings *t,
return false;
return true;
}
-EXPORT_SYMBOL_GPL(v4l2_dv_valid_timings);
+EXPORT_SYMBOL_GPL(v4l2_valid_dv_timings);
int v4l2_enum_dv_timings_cap(struct v4l2_enum_dv_timings *t,
const struct v4l2_dv_timings_cap *cap)
@@ -162,7 +162,7 @@ int v4l2_enum_dv_timings_cap(struct v4l2_enum_dv_timings *t,
memset(t-reserved, 0, sizeof(t-reserved));
for (i = idx = 0; v4l2_dv_timings_presets[i].bt.width; i++) {
- if (v4l2_dv_valid_timings(v4l2_dv_timings_presets + i, cap)
+ if (v4l2_valid_dv_timings(v4l2_dv_timings_presets + i, cap)
idx++ == t-index) {
t-timings = v4l2_dv_timings_presets[i];
return 0;
@@ -178,11 +178,11 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
{
int i;
- if (!v4l2_dv_valid_timings(t, cap))
+ if (!v4l2_valid_dv_timings(t, cap))
return false;
for (i = 0; i v4l2_dv_timings_presets[i].bt.width; i++) {
- if (v4l2_dv_valid_timings(v4l2_dv_timings_presets + i, cap)
+ if (v4l2_valid_dv_timings(v4l2_dv_timings_presets + i, cap)
v4l2_match_dv_timings(t, v4l2_dv_timings_presets + i,
pclock_delta)) {
*t = v4l2_dv_timings_presets[i];
return true;
diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 0fe310b..bd59df8 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -27,14 +27,14 @@
*/
extern const struct v4l2_dv_timings v4l2_dv_timings_presets[];
-/** v4l2_dv_valid_timings() - are these timings valid?
+/** v4l2_valid_dv_timings() - are these timings valid?
* @t: the v4l2_dv_timings struct.
* @cap: the v4l2_dv_timings_cap capabilities.
*
* Returns true if the given dv_timings struct is supported by the
* hardware capabilities, returns false otherwise.
*/
-bool v4l2_dv_valid_timings(const struct v4l2_dv_timings *t,
+bool v4l2_valid_dv_timings(const struct v4l2_dv_timings *t,
const struct v4l2_dv_timings_cap *cap);
/** v4l2_enum_dv_timings_cap() - Helper function to enumerate possible DV
timings based on capabilities
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 20/20] MAINTAINERS: add entries for adv7511 and adv7842.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS | 12 1 file changed, 12 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index bf61e04..e50819b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -580,12 +580,24 @@ L:linux-media@vger.kernel.org S: Maintained F: drivers/media/i2c/ad9389b* +ANALOG DEVICES INC ADV7511 DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv7511* + ANALOG DEVICES INC ADV7604 DRIVER M: Hans Verkuil hans.verk...@cisco.com L: linux-media@vger.kernel.org S: Maintained F: drivers/media/i2c/adv7604* +ANALOG DEVICES INC ADV7842 DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv7842* + ANALOG DEVICES INC ASOC CODEC DRIVERS M: Lars-Peter Clausen l...@metafoo.de L: device-drivers-de...@blackfin.uclinux.org -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 19/20] adv7511: add new video encoder.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv7511.c | 1192 +++
include/media/adv7511.h | 49 ++
4 files changed, 1253 insertions(+)
create mode 100644 drivers/media/i2c/adv7511.c
create mode 100644 include/media/adv7511.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 847b711..d18be19 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -429,6 +429,17 @@ config VIDEO_ADV7393
To compile this driver as a module, choose M here: the
module will be called adv7393.
+config VIDEO_ADV7511
+ tristate Analog Devices ADV7511 encoder
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices ADV7511 video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7511.
+
config VIDEO_AD9389B
tristate Analog Devices AD9389B encoder
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b4cf972..9f462df 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
+obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
new file mode 100644
index 000..c85aa47
--- /dev/null
+++ b/drivers/media/i2c/adv7511.c
@@ -0,0 +1,1192 @@
+/*
+ * Analog Devices ADV7511 HDMI Transmitter Device Driver
+ *
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/gpio.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-dv-timings.h
+#include media/adv7511.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+MODULE_DESCRIPTION(Analog Devices ADV7511 HDMI Transmitter Device Driver);
+MODULE_AUTHOR(Hans Verkuil);
+MODULE_LICENSE(GPL);
+
+#define MASK_ADV7511_EDID_RDY_INT 0x04
+#define MASK_ADV7511_MSEN_INT 0x40
+#define MASK_ADV7511_HPD_INT0x80
+
+#define MASK_ADV7511_HPD_DETECT 0x40
+#define MASK_ADV7511_MSEN_DETECT0x20
+#define MASK_ADV7511_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+#define ADV7511_MAX_WIDTH 1920
+#define ADV7511_MAX_HEIGHT 1200
+#define ADV7511_MIN_PIXELCLOCK 2000
+#define ADV7511_MAX_PIXELCLOCK 22500
+
+/*
+**
+*
+* Arrays with configuration parameters for the ADV7511
+*
+**
+*/
+
+struct i2c_reg_value {
+ unsigned char reg;
+ unsigned char value;
+};
+
+struct adv7511_state_edid {
+ /* total number of blocks */
+ u32 blocks;
+ /* Number of segments read */
+ u32 segments;
+ uint8_t data[EDID_MAX_SEGM * 256];
+ /* Number of EDID read retries left */
+ unsigned read_retries;
+ bool complete;
+};
+
+struct adv7511_state {
+ struct adv7511_platform_data pdata;
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_ctrl_handler hdl;
+ int chip_revision;
+ uint8_t i2c_edid_addr;
+ uint8_t i2c_cec_addr;
+ /* Is the adv7511 powered on? */
+ bool power_on;
+ /* Did we receive hotplug and rx-sense signals? */
+ bool have_monitor;
+ /* timings from s_dv_timings */
+ struct v4l2_dv_timings dv_timings;
+ /*
[RFCv2 PATCH 17/20] v4l2-dv-timings: add callback to handle exceptions
From: Hans Verkuil hans.verk...@cisco.com
In most cases the v4l2_bt_timings_cap struct has all the information
necessary to determine valid timings, but occasionally there are exceptions.
Add a callback function to be able to test for those exceptions.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 7 ---
drivers/media/i2c/ths8200.c | 9 +---
drivers/media/v4l2-core/v4l2-dv-timings.c | 25 +++
include/media/v4l2-dv-timings.h | 34 +--
4 files changed, 55 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index fc60851..8369786 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -648,12 +648,12 @@ static int ad9389b_s_dv_timings(struct v4l2_subdev *sd,
v4l2_dbg(1, debug, sd, %s:\n, __func__);
/* quick sanity check */
- if (!v4l2_valid_dv_timings(timings, ad9389b_timings_cap))
+ if (!v4l2_valid_dv_timings(timings, ad9389b_timings_cap, NULL, NULL))
return -EINVAL;
/* Fill the optional fields .standards and .flags in struct
v4l2_dv_timings
if the format is one of the CEA or DMT timings. */
- v4l2_find_dv_timings_cap(timings, ad9389b_timings_cap, 0);
+ v4l2_find_dv_timings_cap(timings, ad9389b_timings_cap, 0, NULL, NULL);
timings-bt.flags = ~V4L2_DV_FL_REDUCED_FPS;
@@ -691,7 +691,8 @@ static int ad9389b_g_dv_timings(struct v4l2_subdev *sd,
static int ad9389b_enum_dv_timings(struct v4l2_subdev *sd,
struct v4l2_enum_dv_timings *timings)
{
- return v4l2_enum_dv_timings_cap(timings, ad9389b_timings_cap);
+ return v4l2_enum_dv_timings_cap(timings, ad9389b_timings_cap,
+ NULL, NULL);
}
static int ad9389b_dv_timings_cap(struct v4l2_subdev *sd,
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index 6abf0fb..a58a8f6 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -378,10 +378,12 @@ static int ths8200_s_dv_timings(struct v4l2_subdev *sd,
v4l2_dbg(1, debug, sd, %s:\n, __func__);
- if (!v4l2_valid_dv_timings(timings, ths8200_timings_cap))
+ if (!v4l2_valid_dv_timings(timings, ths8200_timings_cap,
+ NULL, NULL))
return -EINVAL;
- if (!v4l2_find_dv_timings_cap(timings, ths8200_timings_cap, 10)) {
+ if (!v4l2_find_dv_timings_cap(timings, ths8200_timings_cap, 10,
+ NULL, NULL)) {
v4l2_dbg(1, debug, sd, Unsupported format\n);
return -EINVAL;
}
@@ -411,7 +413,8 @@ static int ths8200_g_dv_timings(struct v4l2_subdev *sd,
static int ths8200_enum_dv_timings(struct v4l2_subdev *sd,
struct v4l2_enum_dv_timings *timings)
{
- return v4l2_enum_dv_timings_cap(timings, ths8200_timings_cap);
+ return v4l2_enum_dv_timings_cap(timings, ths8200_timings_cap,
+ NULL, NULL);
}
static int ths8200_dv_timings_cap(struct v4l2_subdev *sd,
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index a77f201..ee52b9f4 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -132,7 +132,9 @@ const struct v4l2_dv_timings v4l2_dv_timings_presets[] = {
EXPORT_SYMBOL_GPL(v4l2_dv_timings_presets);
bool v4l2_valid_dv_timings(const struct v4l2_dv_timings *t,
- const struct v4l2_dv_timings_cap *dvcap)
+ const struct v4l2_dv_timings_cap *dvcap,
+ v4l2_check_dv_timings_fnc fnc,
+ void *fnc_handle)
{
const struct v4l2_bt_timings *bt = t-bt;
const struct v4l2_bt_timings_cap *cap = dvcap-bt;
@@ -151,18 +153,21 @@ bool v4l2_valid_dv_timings(const struct v4l2_dv_timings
*t,
(bt-interlaced !(caps V4L2_DV_BT_CAP_INTERLACED)) ||
(!bt-interlaced !(caps V4L2_DV_BT_CAP_PROGRESSIVE)))
return false;
- return true;
+ return fnc == NULL || fnc(t, fnc_handle);
}
EXPORT_SYMBOL_GPL(v4l2_valid_dv_timings);
int v4l2_enum_dv_timings_cap(struct v4l2_enum_dv_timings *t,
-const struct v4l2_dv_timings_cap *cap)
+const struct v4l2_dv_timings_cap *cap,
+v4l2_check_dv_timings_fnc fnc,
+void *fnc_handle)
{
u32 i, idx;
memset(t-reserved, 0, sizeof(t-reserved));
for (i = idx = 0; v4l2_dv_timings_presets[i].bt.width; i++) {
- if (v4l2_valid_dv_timings(v4l2_dv_timings_presets + i, cap)
+ if (v4l2_valid_dv_timings(v4l2_dv_timings_presets + i, cap,
+ fnc, fnc_handle)
[RFCv2 PATCH 15/20] v4l2-dv-timings: export the timings list.
From: Hans Verkuil hans.verk...@cisco.com
Some drivers need to be able to access the full list of timings.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dv-timings.c | 18 ++
include/media/v4l2-dv-timings.h | 4
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index c2f5af7..f515997 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -26,7 +26,7 @@
#include linux/v4l2-dv-timings.h
#include media/v4l2-dv-timings.h
-static const struct v4l2_dv_timings timings[] = {
+const struct v4l2_dv_timings v4l2_dv_timings_presets[] = {
V4L2_DV_BT_CEA_640X480P59_94,
V4L2_DV_BT_CEA_720X480I59_94,
V4L2_DV_BT_CEA_720X480P59_94,
@@ -127,7 +127,9 @@ static const struct v4l2_dv_timings timings[] = {
V4L2_DV_BT_DMT_2560X1600P75,
V4L2_DV_BT_DMT_2560X1600P85,
V4L2_DV_BT_DMT_2560X1600P120_RB,
+ { }
};
+EXPORT_SYMBOL_GPL(v4l2_dv_timings_presets);
bool v4l2_dv_valid_timings(const struct v4l2_dv_timings *t,
const struct v4l2_dv_timings_cap *dvcap)
@@ -159,10 +161,10 @@ int v4l2_enum_dv_timings_cap(struct v4l2_enum_dv_timings
*t,
u32 i, idx;
memset(t-reserved, 0, sizeof(t-reserved));
- for (i = idx = 0; i ARRAY_SIZE(timings); i++) {
- if (v4l2_dv_valid_timings(timings + i, cap)
+ for (i = idx = 0; v4l2_dv_timings_presets[i].bt.width; i++) {
+ if (v4l2_dv_valid_timings(v4l2_dv_timings_presets + i, cap)
idx++ == t-index) {
- t-timings = timings[i];
+ t-timings = v4l2_dv_timings_presets[i];
return 0;
}
}
@@ -179,10 +181,10 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
if (!v4l2_dv_valid_timings(t, cap))
return false;
- for (i = 0; i ARRAY_SIZE(timings); i++) {
- if (v4l2_dv_valid_timings(timings + i, cap)
- v4l2_match_dv_timings(t, timings + i, pclock_delta)) {
- *t = timings[i];
+ for (i = 0; i v4l2_dv_timings_presets[i].bt.width; i++) {
+ if (v4l2_dv_valid_timings(v4l2_dv_timings_presets + i, cap)
+ v4l2_match_dv_timings(t, v4l2_dv_timings_presets + i,
pclock_delta)) {
+ *t = v4l2_dv_timings_presets[i];
return true;
}
}
diff --git a/include/media/v4l2-dv-timings.h b/include/media/v4l2-dv-timings.h
index 43f6b67..0fe310b 100644
--- a/include/media/v4l2-dv-timings.h
+++ b/include/media/v4l2-dv-timings.h
@@ -23,6 +23,10 @@
#include linux/videodev2.h
+/** v4l2_dv_timings_presets: list of all dv_timings presets.
+ */
+extern const struct v4l2_dv_timings v4l2_dv_timings_presets[];
+
/** v4l2_dv_valid_timings() - are these timings valid?
* @t: the v4l2_dv_timings struct.
* @cap: the v4l2_dv_timings_cap capabilities.
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 13/20] adv7604/ad9389b/ths8200: decrease min_pixelclock to 25MHz
From: Hans Verkuil hans.verk...@cisco.com
The CEA-861 standard allows for the 640x480 format at 25.175 MHz.
Ensure that that's allowed according to the struct v4l2_bt_timings_cap.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 2 +-
drivers/media/i2c/adv7604.c | 2 +-
drivers/media/i2c/ths8200.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 1c6d352..bb74fb6 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -631,7 +631,7 @@ static const struct v4l2_dv_timings_cap ad9389b_timings_cap
= {
.bt = {
.max_width = 1920,
.max_height = 1200,
- .min_pixelclock = 2700,
+ .min_pixelclock = 2500,
.max_pixelclock = 17000,
.standards = V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index a1a9d1e..5b54ba1 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1162,7 +1162,7 @@ static int adv7604_dv_timings_cap(struct v4l2_subdev *sd,
cap-type = V4L2_DV_BT_656_1120;
cap-bt.max_width = 1920;
cap-bt.max_height = 1200;
- cap-bt.min_pixelclock = 2700;
+ cap-bt.min_pixelclock = 2500;
if (DIGITAL_INPUT)
cap-bt.max_pixelclock = 22500;
else
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index 49041e5..580bd1b 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -49,7 +49,7 @@ static const struct v4l2_dv_timings_cap ths8200_timings_cap =
{
.bt = {
.max_width = 1920,
.max_height = 1080,
- .min_pixelclock = 2700,
+ .min_pixelclock = 2500,
.max_pixelclock = 14850,
.standards = V4L2_DV_BT_STD_CEA861,
.capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 01/20] v4l2-dv-timings: fix CVT calculation
From: Martin Bugge marbu...@cisco.com
This patch fixes two errors that caused incorrect format detections:
The first bug is in the calculation of the vertical backporch: the combined
period of vsync and backporch must *exceed* a certain minimum value, and not
be equal to it.
The second bug is a rounding error in the reduced blanking calculation:
expand the ideal_duty_cylce to be in parts per ten thousand to avoid
rounding errors.
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dv-timings.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index f20b316..72cf224 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -286,14 +286,14 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned
hfreq, unsigned vsync,
/* Vertical */
if (reduced_blanking) {
v_fp = CVT_RB_V_FPORCH;
- v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 199) / 100;
v_bp -= vsync + v_fp;
if (v_bp CVT_RB_MIN_V_BPORCH)
v_bp = CVT_RB_MIN_V_BPORCH;
} else {
v_fp = CVT_MIN_V_PORCH_RND;
- v_bp = (CVT_MIN_VSYNC_BP * hfreq + 99) / 100 - vsync;
+ v_bp = (CVT_MIN_VSYNC_BP * hfreq + 199) / 100 - vsync;
if (v_bp CVT_MIN_V_BPORCH)
v_bp = CVT_MIN_V_BPORCH;
@@ -337,17 +337,16 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned
hfreq, unsigned vsync,
frame_width = image_width + CVT_RB_H_BLANK;
} else {
+ unsigned ideal_duty_cycle_per_myriad =
+ 100 * CVT_C_PRIME - (CVT_M_PRIME * 10) / hfreq;
int h_blank;
- unsigned ideal_duty_cycle = CVT_C_PRIME - (CVT_M_PRIME * 1000)
/ hfreq;
- h_blank = (image_width * ideal_duty_cycle + (100 -
ideal_duty_cycle) / 2) /
- (100 - ideal_duty_cycle);
- h_blank = h_blank - h_blank % (2 * CVT_CELL_GRAN);
+ if (ideal_duty_cycle_per_myriad 2000)
+ ideal_duty_cycle_per_myriad = 2000;
- if (h_blank * 100 / image_width 20) {
- h_blank = image_width / 5;
- h_blank = (h_blank + 0x7) ~0x7;
- }
+ h_blank = image_width * ideal_duty_cycle_per_myriad /
+ (1 - ideal_duty_cycle_per_myriad);
+ h_blank = (h_blank / (2 * CVT_CELL_GRAN)) * 2 * CVT_CELL_GRAN;
pix_clk = (image_width + h_blank) * hfreq;
pix_clk = (pix_clk / CVT_PXL_CLK_GRAN) * CVT_PXL_CLK_GRAN;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 12/20] v4l2-dv-timings: rename v4l_match_dv_timings to v4l2_match_dv_timings
From: Hans Verkuil hans.verk...@cisco.com
It's the only function in v4l2-dv-timings.c with the v4l prefix instead
of v4l2. Make it consistent with the other functions.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 4 ++--
drivers/media/platform/s5p-tv/hdmi_drv.c | 2 +-
drivers/media/usb/hdpvr/hdpvr-video.c | 2 +-
drivers/media/v4l2-core/v4l2-dv-timings.c | 12 ++--
include/media/v4l2-dv-timings.h | 8
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index ba8602c..a1a9d1e 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -763,7 +763,7 @@ static int find_and_set_predefined_video_timings(struct
v4l2_subdev *sd,
int i;
for (i = 0; predef_vid_timings[i].timings.bt.width; i++) {
- if (!v4l_match_dv_timings(timings,
predef_vid_timings[i].timings,
+ if (!v4l2_match_dv_timings(timings,
predef_vid_timings[i].timings,
DIGITAL_INPUT ? 25 : 100))
continue;
io_write(sd, 0x00, predef_vid_timings[i].vid_std); /* video std
*/
@@ -1183,7 +1183,7 @@ static void
adv7604_fill_optional_dv_timings_fields(struct v4l2_subdev *sd,
int i;
for (i = 0; adv7604_timings[i].bt.width; i++) {
- if (v4l_match_dv_timings(timings, adv7604_timings[i],
+ if (v4l2_match_dv_timings(timings, adv7604_timings[i],
DIGITAL_INPUT ? 25 : 100)) {
*timings = adv7604_timings[i];
break;
diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 1b34c36..4ad9374 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -625,7 +625,7 @@ static int hdmi_s_dv_timings(struct v4l2_subdev *sd,
int i;
for (i = 0; i ARRAY_SIZE(hdmi_timings); i++)
- if (v4l_match_dv_timings(hdmi_timings[i].dv_timings,
+ if (v4l2_match_dv_timings(hdmi_timings[i].dv_timings,
timings, 0))
break;
if (i == ARRAY_SIZE(hdmi_timings)) {
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index e68245a..0500c417 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -642,7 +642,7 @@ static int vidioc_s_dv_timings(struct file *file, void *_fh,
if (dev-status != STATUS_IDLE)
return -EBUSY;
for (i = 0; i ARRAY_SIZE(hdpvr_dv_timings); i++)
- if (v4l_match_dv_timings(timings, hdpvr_dv_timings + i, 0))
+ if (v4l2_match_dv_timings(timings, hdpvr_dv_timings + i, 0))
break;
if (i == ARRAY_SIZE(hdpvr_dv_timings))
return -EINVAL;
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 917e58c..1a9d393 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -181,7 +181,7 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
for (i = 0; i ARRAY_SIZE(timings); i++) {
if (v4l2_dv_valid_timings(timings + i, cap)
- v4l_match_dv_timings(t, timings + i, pclock_delta)) {
+ v4l2_match_dv_timings(t, timings + i, pclock_delta)) {
*t = timings[i];
return true;
}
@@ -191,16 +191,16 @@ bool v4l2_find_dv_timings_cap(struct v4l2_dv_timings *t,
EXPORT_SYMBOL_GPL(v4l2_find_dv_timings_cap);
/**
- * v4l_match_dv_timings - check if two timings match
+ * v4l2_match_dv_timings - check if two timings match
* @t1 - compare this v4l2_dv_timings struct...
* @t2 - with this struct.
* @pclock_delta - the allowed pixelclock deviation.
*
* Compare t1 with t2 with a given margin of error for the pixelclock.
*/
-bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
- const struct v4l2_dv_timings *t2,
- unsigned pclock_delta)
+bool v4l2_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta)
{
if (t1-type != t2-type || t1-type != V4L2_DV_BT_656_1120)
return false;
@@ -221,7 +221,7 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
return true;
return false;
}
-EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+EXPORT_SYMBOL_GPL(v4l2_match_dv_timings);
void v4l2_print_dv_timings(const char *dev_prefix, const char *prefix,
const struct v4l2_dv_timings *t, bool detailed)
diff --git
[RFCv2 PATCH 09/20] ad9389b: change initial register configuration in ad9389b_setup()
From: Mats Randgaard matra...@cisco.com - register 0x17: CSC scaling factor was set to +/- 2.0. This register is set by ad9389b_csc_conversion_mode() to the right value. - register 0x3b: bits for pixel repetition and CSC was set to zero, but that is the default value. Signed-off-by: Mats Randgaard matra...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/i2c/ad9389b.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c index d78fd3d..92cdb25 100644 --- a/drivers/media/i2c/ad9389b.c +++ b/drivers/media/i2c/ad9389b.c @@ -894,11 +894,9 @@ static void ad9389b_setup(struct v4l2_subdev *sd) ad9389b_wr_and_or(sd, 0x15, 0xf1, 0x0); /* Output format: RGB 4:4:4 */ ad9389b_wr_and_or(sd, 0x16, 0x3f, 0x0); - /* CSC fixed point: +/-2, 1st order interpolation 4:2:2 - 4:4:4 up - conversion, Aspect ratio: 16:9 */ - ad9389b_wr_and_or(sd, 0x17, 0xe1, 0x0e); - /* Disable pixel repetition and CSC */ - ad9389b_wr_and_or(sd, 0x3b, 0x9e, 0x0); + /* 1st order interpolation 4:2:2 - 4:4:4 up conversion, + Aspect ratio: 16:9 */ + ad9389b_wr_and_or(sd, 0x17, 0xf9, 0x06); /* Output format: RGB 4:4:4, Active Format Information is valid. */ ad9389b_wr_and_or(sd, 0x45, 0xc7, 0x08); /* Underscanned */ -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 11/20] ad9389b/adv7604/ths8200: use new v4l2_print_dv_timings helper.
From: Hans Verkuil hans.verk...@cisco.com
These three drivers all have code to log the dv_timings contents. Replace
that code with the new helper function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 17 +++--
drivers/media/i2c/adv7604.c | 61 ++---
drivers/media/i2c/ths8200.c | 38 ++--
3 files changed, 14 insertions(+), 102 deletions(-)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 92cdb25..1c6d352 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -443,20 +443,11 @@ static int ad9389b_log_status(struct v4l2_subdev *sd)
vic_detect, vic_sent);
}
}
- if (state-dv_timings.type == V4L2_DV_BT_656_1120) {
- struct v4l2_bt_timings *bt = bt = state-dv_timings.bt;
- u32 frame_width = V4L2_DV_BT_FRAME_WIDTH(bt);
- u32 frame_height = V4L2_DV_BT_FRAME_HEIGHT(bt);
- u32 frame_size = frame_width * frame_height;
-
- v4l2_info(sd, timings: %ux%u%s%u (%ux%u). Pix freq. = %u Hz.
Polarities = 0x%x\n,
- bt-width, bt-height, bt-interlaced ? i : p,
- frame_size 0 ? (unsigned)bt-pixelclock / frame_size
: 0,
- frame_width, frame_height,
- (unsigned)bt-pixelclock, bt-polarities);
- } else {
+ if (state-dv_timings.type == V4L2_DV_BT_656_1120)
+ v4l2_print_dv_timings(sd-name, timings: ,
+ state-dv_timings, false);
+ else
v4l2_info(sd, no timings set\n);
- }
return 0;
}
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e732c9b..ba8602c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1051,53 +1051,6 @@ static int adv7604_g_input_status(struct v4l2_subdev
*sd, u32 *status)
/* --- */
-static void adv7604_print_timings(struct v4l2_subdev *sd,
- struct v4l2_dv_timings *timings,
- const char *txt, bool detailed)
-{
- struct v4l2_bt_timings *bt = timings-bt;
- u32 htot, vtot;
-
- if (timings-type != V4L2_DV_BT_656_1120)
- return;
-
- htot = htotal(bt);
- vtot = vtotal(bt);
-
- v4l2_info(sd, %s %dx%d%s%d (%dx%d),
- txt, bt-width, bt-height, bt-interlaced ? i : p,
- (htot * vtot) 0 ? ((u32)bt-pixelclock /
- (htot * vtot)) : 0,
- htot, vtot);
-
- if (!detailed)
- return;
-
- v4l2_info(sd, horizontal: fp = %d, %ssync = %d, bp = %d\n,
- bt-hfrontporch,
- (bt-polarities V4L2_DV_HSYNC_POS_POL) ? + : -,
- bt-hsync, bt-hbackporch);
- v4l2_info(sd, vertical: fp = %d, %ssync = %d, bp = %d\n,
- bt-vfrontporch,
- (bt-polarities V4L2_DV_VSYNC_POS_POL) ? + : -,
- bt-vsync, bt-vbackporch);
- v4l2_info(sd, pixelclock: %lld\n, bt-pixelclock);
- v4l2_info(sd, flags (0x%x):%s%s%s%s\n, bt-flags,
- (bt-flags V4L2_DV_FL_REDUCED_BLANKING) ?
-Reduced blanking, : ,
- (bt-flags V4L2_DV_FL_CAN_REDUCE_FPS) ?
-Can reduce FPS, : ,
- (bt-flags V4L2_DV_FL_REDUCED_FPS) ?
-Reduced FPS, : ,
- (bt-flags V4L2_DV_FL_HALF_LINE) ?
-Half line, : );
- v4l2_info(sd, standards (0x%x):%s%s%s%s\n, bt-standards,
- (bt-standards V4L2_DV_BT_STD_CEA861) ? CEA, : ,
- (bt-standards V4L2_DV_BT_STD_DMT) ? DMT, : ,
- (bt-standards V4L2_DV_BT_STD_CVT) ? CVT : ,
- (bt-standards V4L2_DV_BT_STD_GTF) ? GTF : );
-}
-
struct stdi_readback {
u16 bl, lcf, lcvs;
u8 hs_pol, vs_pol;
@@ -1360,8 +1313,8 @@ found:
}
if (debug 1)
- adv7604_print_timings(sd, timings,
- adv7604_query_dv_timings:, true);
+ v4l2_print_dv_timings(sd-name, adv7604_query_dv_timings: ,
+ timings, true);
return 0;
}
@@ -1403,8 +1356,8 @@ static int adv7604_s_dv_timings(struct v4l2_subdev *sd,
if (debug 1)
- adv7604_print_timings(sd, timings,
- adv7604_s_dv_timings:, true);
+ v4l2_print_dv_timings(sd-name, adv7604_s_dv_timings: ,
+ timings, true);
return 0;
}
@@ -1770,8
[RFCv2 PATCH 06/20] ad9389b: no monitor if EDID is wrong
From: Mats Randgaard matra...@cisco.com
state-have_monitor is set to false if the EDID that is read from
the monitor has too many segments or wrong CRC.
Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/ad9389b.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 7e68d8f..52384e8 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -1019,6 +1019,7 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev
*sd)
segment = ad9389b_rd(sd, 0xc4);
if (segment = EDID_MAX_SEGM) {
v4l2_err(sd, edid segment number too big\n);
+ state-have_monitor = false;
return false;
}
v4l2_dbg(1, debug, sd, %s: got segment %d\n, __func__, segment);
@@ -1032,6 +1033,8 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev
*sd)
}
if (!edid_segment_verify_crc(sd, segment)) {
/* edid crc error, force reread of edid segment */
+ v4l2_err(sd, %s: edid crc error\n, __func__);
+ state-have_monitor = false;
ad9389b_s_power(sd, false);
ad9389b_s_power(sd, true);
return false;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 14/20] v4l2-dv-timings: fill in type field
From: Hans Verkuil hans.verk...@cisco.com The detect_cvt/gtf functions didn't fill in the type field. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/v4l2-dv-timings.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c b/drivers/media/v4l2-core/v4l2-dv-timings.c index 1a9d393..c2f5af7 100644 --- a/drivers/media/v4l2-core/v4l2-dv-timings.c +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c @@ -408,6 +408,7 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync, h_fp = h_blank - hsync - h_bp; } + fmt-type = V4L2_DV_BT_656_1120; fmt-bt.polarities = polarities; fmt-bt.width = image_width; fmt-bt.height = image_height; @@ -527,6 +528,7 @@ bool v4l2_detect_gtf(unsigned frame_height, h_fp = h_blank / 2 - hsync; + fmt-type = V4L2_DV_BT_656_1120; fmt-bt.polarities = polarities; fmt-bt.width = image_width; fmt-bt.height = image_height; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 04/20] adv7604: improve log_status for HDMI/DVI-D signals
From: Mats Randgaard matra...@cisco.com
Don't log if there is no signal.
If there is a signal, then also log HDCP and audio status.
Signed-off-by: Mats Randgaard matra...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7604.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 6ffe25a..34fcdf3 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1758,6 +1758,9 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
adv7604_print_timings(sd, timings, Detected format:, true);
adv7604_print_timings(sd, state-timings, Configured format:, true);
+ if (no_signal(sd))
+ return 0;
+
v4l2_info(sd, -Color space-\n);
v4l2_info(sd, RGB quantization range ctrl: %s\n,
rgb_quantization_range_txt[state-rgb_quantization_range]);
@@ -1767,18 +1770,41 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
(reg_io_0x02 0x02) ? RGB : YCbCr,
(reg_io_0x02 0x04) ? (16-235) : (0-255),
((reg_io_0x02 0x04) ^ (reg_io_0x02 0x01)) ?
- enabled : disabled);
+ enabled : disabled);
v4l2_info(sd, Color space conversion: %s\n,
csc_coeff_sel_rb[cp_read(sd, 0xfc) 4]);
- /* Digital video */
- if (DIGITAL_INPUT) {
- v4l2_info(sd, -HDMI status-\n);
- v4l2_info(sd, HDCP encrypted content: %s\n,
- hdmi_read(sd, 0x05) 0x40 ? true : false);
- if (is_hdmi(sd))
- v4l2_info(sd, deep color mode: %s\n,
- deep_color_mode_txt[(hdmi_read(sd,
0x0b) 5) 0x3]);
+ if (!DIGITAL_INPUT)
+ return 0;
+
+ v4l2_info(sd, -%s status-\n, is_hdmi(sd) ? HDMI : DVI-D);
+ v4l2_info(sd, HDCP encrypted content: %s\n, (hdmi_read(sd, 0x05)
0x40) ? true : false);
+ v4l2_info(sd, HDCP keys read: %s%s\n,
+ (hdmi_read(sd, 0x04) 0x20) ? yes : no,
+ (hdmi_read(sd, 0x04) 0x10) ? ERROR : );
+ if (!is_hdmi(sd)) {
+ bool audio_pll_locked = hdmi_read(sd, 0x04) 0x01;
+ bool audio_sample_packet_detect = hdmi_read(sd, 0x18) 0x01;
+ bool audio_mute = io_read(sd, 0x65) 0x40;
+
+ v4l2_info(sd, Audio: pll %s, samples %s, %s\n,
+ audio_pll_locked ? locked : not locked,
+ audio_sample_packet_detect ? detected : not
detected,
+ audio_mute ? muted : enabled);
+ if (audio_pll_locked audio_sample_packet_detect) {
+ v4l2_info(sd, Audio format: %s\n,
+ (hdmi_read(sd, 0x07) 0x20) ?
multi-channel : stereo);
+ }
+ v4l2_info(sd, Audio CTS: %u\n, (hdmi_read(sd, 0x5b) 12) +
+ (hdmi_read(sd, 0x5c) 8) +
+ (hdmi_read(sd, 0x5d) 0xf0));
+ v4l2_info(sd, Audio N: %u\n, ((hdmi_read(sd, 0x5d) 0x0f)
16) +
+ (hdmi_read(sd, 0x5e) 8) +
+ hdmi_read(sd, 0x5f));
+ v4l2_info(sd, AV Mute: %s\n, (hdmi_read(sd, 0x04) 0x40) ?
on : off);
+
+ v4l2_info(sd, Deep color mode: %s\n,
deep_color_mode_txt[(hdmi_read(sd, 0x0b) 0x60) 5]);
+
print_avi_infoframe(sd);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP DQBUF hangs
Su Jiaquan jiaquan.lnx at gmail.com writes:
Hello,
Hi Tom,
On Thu, Aug 15, 2013 at 10:15 PM, Tom Bassai_Dai at gmx.net wrote:
Hello,
I'm working with an OMAP3 DM3730 processor module with a ov3640 camera
module attached on parallel interface. I'm using Linux 3.5 and an
application which builds the pipeline and grabs an image like the
media-ctl and the yavta tools.
I configured the pipeline to:
sensor-ccdc-memory
When I call ioctl with DQBUF the calling functions are:
isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait -
wait_event_interruptible
The last function waits until the state of the buffer will be reseted
somehow. Can someone tell my which function sets the state of the buffer? Am
I missing an interrupt?
Best Regards, Tom
I'm not familar with omap3isp, but from the code, the wait queue is
released by function ccdc_isr_buffer-omap3isp_video_buffer_next.
You are either missing a interrupt, or running out of buffer, or found
a buffer under run.
Jiaquan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
you are right. it seems that the list of the ccdc has no buffer left,
because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in
my log. But I don't understand what I need to do to solve the problem.
What I do is:
- configure the pipeline
- open the video device
- do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type =
V4L2_BUF_TYPE_VIDEO_CAPTURE)
- do ioctl VIDIOC_QUERYBUF
- do ioctl VIDIOC_STREAMON
- do ioctl VIDIOC_QBUF
without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem.
Does anyone have an idea what I need to do to solve this problem?
static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
{
printk(TOM ccdc_isr_buffer ##\n);
struct isp_pipeline *pipe = to_isp_pipeline(ccdc-subdev.entity);
struct isp_device *isp = to_isp_device(ccdc);
struct isp_buffer *buffer;
int restart = 0;
/* The CCDC generates VD0 interrupts even when disabled (the datasheet
* doesn't explicitly state if that's supposed to happen or not, so it
* can be considered as a hardware bug or as a feature, but we have to
* deal with it anyway). Disabling the CCDC when no buffer is available
* would thus not be enough, we need to handle the situation explicitly.
*/
printk(TOM ccdc_isr_buffer 1 ##\n);
if (list_empty(ccdc-video_out.dmaqueue))
{
printk(TOM ccdc_isr_buffer ERROR 1 ##\n);
goto done;
}
/* We're in continuous mode, and memory writes were disabled due to a
* buffer underrun. Reenable them now that we have a buffer. The buffer
* address has been set in ccdc_video_queue.
*/
printk(TOM ccdc_isr_buffer 2 ##\n);
if (ccdc-state == ISP_PIPELINE_STREAM_CONTINUOUS ccdc-underrun) {
restart = 1;
ccdc-underrun = 0;
printk(TOM ccdc_isr_buffer ERROR 2 ##\n);
goto done;
}
printk(TOM ccdc_isr_buffer 3 ##\n);
if (ccdc_sbl_wait_idle(ccdc, 1000)) {
printk(TOM ccdc_isr_buffer ERROR 3 ##\n);
dev_info(isp-dev, CCDC won't become idle!\n);
goto done;
}
printk(TOM ccdc_isr_buffer 4 ##\n);
buffer = omap3isp_video_buffer_next(ccdc-video_out);
if (buffer != NULL) {
ccdc_set_outaddr(ccdc, buffer-isp_addr);
restart = 1;
}
printk(TOM ccdc_isr_buffer 5 ##\n);
pipe-state |= ISP_PIPELINE_IDLE_OUTPUT;
if (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT
isp_pipeline_ready(pipe))
omap3isp_pipeline_set_stream(pipe,
ISP_PIPELINE_STREAM_SINGLESHOT);
printk(TOM ccdc_isr_buffer DONE ##\n);
done:
return restart;
}
Regards, Tom
--
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 1/3] adv7842: add new video decoder driver.
On 08/16/2013 12:10 PM, Scott Jiang wrote:
+
+static int adv7842_g_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *fmt)
+{
+ struct adv7842_state *state = to_state(sd);
+
+ fmt-width = state-timings.bt.width;
+ fmt-height = state-timings.bt.height;
+ fmt-code = V4L2_MBUS_FMT_FIXED;
+ fmt-field = V4L2_FIELD_NONE;
+
+ if (state-mode == ADV7842_MODE_SDP) {
+ /* SPD block */
+ if (!(sdp_read(sd, 0x5A) 0x01))
+ return -EINVAL;
+ fmt-width = 720;
+ /* valid signal */
+ if (state-norm V4L2_STD_525_60)
+ fmt-height = 480;
+ else
+ fmt-height = 576;
+ fmt-colorspace = V4L2_COLORSPACE_SMPTE170M;
+ return 0;
+ }
+
I believe someone use SDP mode to capture 480i instead of 480p.
I think we can add a table to map adv7842 output setting and v4l format.
The driver as it stands only supports progressive output from the chip, because
that is all we support in our products (interlaced video conferencing? Nah, not
a good idea...).
I don't think I can easily test it (if at all!), so I leave this as an
exercise for the reader.
+static int adv7842_s_std(struct v4l2_subdev *sd, v4l2_std_id norm)
+{
+ struct adv7842_state *state = to_state(sd);
+
+ v4l2_dbg(1, debug, sd, %s:\n, __func__);
+
+ if (state-mode != ADV7842_MODE_SDP)
+ return -ENODATA;
+
+ if (norm V4L2_STD_ALL) {
+ state-norm = norm;
+ return 0;
+ }
+ return -EINVAL;
+}
Why is there no hardware operation?
if (std == V4L2_STD_NTSC_443)
val = 0x20;
else if (std == V4L2_STD_PAL_60)
val = 0x10;
else if (std == V4L2_STD_PAL_Nc)
val = 0x08;
else if (std == V4L2_STD_PAL_M)
val = 0x04;
else if (std V4L2_STD_NTSC)
val = 0x02;
else if (std V4L2_STD_PAL)
val = 0x01;
else if (std V4L2_STD_SECAM)
val = 0x40;
else
return -EINVAL;
/* force the digital core into a specific video standard */
sdp_write(sd, 0x0, val);
/* wait 100ms, otherwise color will be lost */
msleep(100);
state-std = std;
return 0;
I checked with Martin Bugge who wrote this and the reason is that apparently
forcing
the core to a specific standard will break the querystd functionality.
That said, this can definitely be improved by only forcing the standard when
you start
streaming and reverting to the autodetect mode when streaming stops. QUERYSTD
can return
-EBUSY when streaming is on.
I would prefer to do this in a separate patch later, though, as this will take
some
time to implement and especially test.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:
On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 10 July 2013, Alan Stern wrote:
This isn't right. There are USB host controllers that use PIO, not
DMA. The HAS_DMA dependency should go with the controller driver, not
the USB core.
On the other hand, the USB core does call various routines like
dma_unmap_single. It ought to be possible to compile these calls even
when DMA isn't enabled. That is, they should be defined as do-nothing
stubs.
The asm-generic/dma-mapping-broken.h file intentionally causes link
errors, but that could be changed.
The better approach in my mind would be to replace code like
if (hcd-self.uses_dma)
with
if (IS_ENABLED(CONFIG_HAS_DMA) hcd-self.uses_dma) {
which will reliably cause that reference to be omitted from object code,
but not stop giving link errors for drivers that actually require
DMA.
This can be done for drivers/usb/core/hcd.c.
But I'm a bit puzzled by drivers/usb/core/buffer.c. E.g.
void *hcd_buffer_alloc(...)
{
/* some USB hosts just use PIO */
if (!bus-controller-dma_mask
!(hcd-driver-flags HCD_LOCAL_MEM)) {
I don't remember the full story. You should check with the person who
added the HCD_LOCAL_MEM flag originally.
So if DMA is not used (!hcd-self.uses_dma, i.e. bus-controller-dma_mask
is zero), and HCD_LOCAL_MEM is set, we still end up calling dma_pool_alloc()?
(Naively, I'm not so familiar with the USB code) I'd expect it to use
kmalloc() instead?
Maybe what happens in this case is that some sort of hook causes the
allocation to be made from a special memory-mapped region on board the
controller.
Alan Stern
--
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: avermedia A306 / PCIe-minicard (laptop)
On 08/19/2013 05:18 PM, remi wrote: Hello I have this card since months, http://www.avermedia.com/avertv/Product/ProductDetail.aspx?Id=376SI=true I have finally retested it with the cx23885 driver : card=39 If I could do anything to identify : [2.414734] cx23885[0]: i2c scan: found device @ 0x66 [???] Or hookup the xc5000 etc I'll be more than glad . ps: i opened it up a while ago,i saw an af9013 chip ? dvb-tuner looks like maybe the device @ 0x66 i2c I will double check , and re-write-down all the chips , i think 3 . You have to identify all the chips, for DVB-T there is tuner missing. USB-interface: cx23885 DVB-T demodulator: AF9013 RF-tuner: ? If there is existing driver for used RF-tuner it comes nice hacking project for some newcomer. It is just tweaking and hacking to find out all settings. AF9013 driver also needs likely some changes, currently it is used only for devices having AF9015 with integrated AF9013, or AF9015 dual devices having AF9015 + external AF9013 providing second tuner. I have bought quite similar AverMedia A301 ages back as I was looking for that AF9013 model, but maybe I have bought just wrong one... :) regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP DQBUF hangs
On Mon, Aug 19, 2013 at 4:53 PM, Tom bassai_...@gmx.net wrote: you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Even if you are sure your application works, try with media-ctl + yavta first so you can send logs that everybody understand. Did you check you have interrupts during capture? (cat /proc/interrupts before and after yavta, look for omap3isp or something like that). Enrico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On 08/19/2013 03:25 PM, Pawel Moll wrote: On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; You probably want to use the [name-]gpios convention here (see Documentation/devicetree/bindings/gpio/gpio.txt), so something like stbyn-gpios and rstn-gpios. Unless using multiple named properties is really preferred over a single gpios property I would like to keep the single property containing a list of GPIOs. Each list entry has clearly defined meaning and it seems simpler to me to reference the GPIOs by index, rather than by name. This also saves a few bytes in dtb and there is no need to store the list of names in the driver. Thanks, 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 RESEND] i2c: move of helpers into the core
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de --- Sigh, hitting the CC threshold on vger again. So resending to the lists only. BTW this patch is based on -rc4 and was tested on an AT91 board. More tests very welcome. Thanks! Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include linux/module.h #include linux/of.h #include linux/of_device.h -#include linux/of_i2c.h #include linux/platform_device.h #include linux/slab.h #include linux/platform_data/dma-atmel.h @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(dev-adapter); - dev_info(dev-dev, AT91 i2c bus driver.\n); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include linux/dma-mapping.h #include linux/of_device.h #include linux/of_platform.h -#include linux/of_i2c.h #include sysdev/fsl_soc.h #include asm/cpm.h @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* -* register OF I2C devices -*/ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index fa55605..62be3b3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,7 +38,6 @@ #include linux/slab.h #include
RE: DVR card SAA7134/SAA7135HL unknown
As long as you found a card number that works, it shouldn't matter. BTW, do you have its card info, like manufacturer, Model number, picture, ..., etc.? What's your app? If you only use it for video surveillance and don't need stereo audio, you may use a low cost capture card, like Sensoray Model 812 (http://www.sensoray.com/products/812.htm) for your application. Best, Charlie X. Liu @ Sensoray Company, Inc. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Jody Gugelhupf Sent: Saturday, August 17, 2013 12:55 PM To: linux-media@vger.kernel.org Subject: Re: DVR card SAA7134/SAA7135HL unknown thanks, but that does not work 33,33,33,33,33,33,33,33 97,97,97,97,97,97,97,97 both do seem to work, maybe even more, but i wonder how to determine the best/right one or does that not matter? thx in advance jody - Original Message - From: Charlie X. Liu char...@sensoray.com To: 'Jody Gugelhupf' knuef...@yahoo.com; linux-media@vger.kernel.org Cc: Sent: Saturday, August 17, 2013 12:28:41 AM Subject: RE: DVR card SAA7134/SAA7135HL unknown You may use card=73,73,73,73,73,73,73,73 -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Jody Gugelhupf Sent: Friday, August 16, 2013 1:42 AM To: linux-media@vger.kernel.org Subject: Re: DVR card SAA7134/SAA7135HL unknown Seems like something went wrong with pastebin, here the info again, would really appreciate some help: http://pastebin.com/TUTpkc0F - Original Message - From: Jody Gugelhupf knuef...@yahoo.com To: linux-media@vger.kernel.org linux-media@vger.kernel.org Cc: Sent: Thursday, August 15, 2013 7:15:25 PM Subject: DVR card SAA7134/SAA7135HL unknown hi all :) trying to get this 8 channel dvr card to work in linux, but I get this: Board is currently unknown. You might try to use the card=nr saa7134: insmod option to specify which board do you have, but this is saa7134: somewhat risky, as might damage your card. It is better to ask saa7134: for support at linux-media@vger.kernel.org. so here I am. I have not tried to set the card myself as I don't know what number to use. Was hoping I could get some help here to get it working. Some info I collected so far can be found here http://pastebin.ca/2430477 any ideas what I might try next or what card to specify? thank you in advance for any help. jody -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 07:59 PM, Wolfram Sang wrote:
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver. So, fix the drivers and documentation, too.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Sigh, hitting the CC threshold on vger again. So resending to the lists only.
BTW this patch is based on -rc4 and was tested on an AT91 board. More tests
very welcome. Thanks!
drivers/i2c/busses/i2c-s3c2410.c|2 -
drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 -
For these:
Acked-by: Sylwester Nawrocki s.nawro...@amsung.com
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6:
Applying: i2c: move of helpers into the core
fatal: sha1 information is lacking or useless
(drivers/i2c/busses/i2c-powermac.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 i2c: move of helpers into the core
One nitpick below..
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..321b7ca 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -23,7 +23,11 @@
SMBus 2.0 support by Mark Studebaker mdsxyz...@yahoo.com and
Jean Delvare kh...@linux-fr.org
Mux support by Rodolfo Giometti giome...@enneenne.com and
- Michael Lawnick michael.lawnick@nsn.com */
+ Michael Lawnick michael.lawnick@nsn.com
+ OF support is copyright (c) 2008 Jochen Friedrich joc...@scram.de
+ (based on a previous patch from Jon Smirl jonsm...@gmail.com) and
+ (c) 2013 Wolfram Sang w...@the-dreams.de
+ */
#include linux/module.h
#include linux/kernel.h
@@ -35,7 +39,9 @@
#include linux/init.h
#include linux/idr.h
#include linux/mutex.h
+#include linux/of.h
#include linux/of_device.h
+#include linux/of_irq.h
#include linux/completion.h
#include linux/hardirq.h
#include linux/irqflags.h
@@ -954,6 +960,102 @@ static void i2c_scan_static_board_info(struct
i2c_adapter *adapter)
up_read(__i2c_board_lock);
}
+/* of support code */
/* OF support code */
or
/*
* Device Tree support code.
*/
?
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+ void *result;
+ struct device_node *node;
+
+ /* Only register child devices if the adapter has a node pointer set */
+ if (!adap-dev.of_node)
+ return;
+
+ dev_dbg(adap-dev, of_i2c: walking child nodes\n);
+
+ for_each_available_child_of_node(adap-dev.of_node, node) {
+ struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
+ const __be32 *addr;
+ int len;
+
+ dev_dbg(adap-dev, of_i2c: register %s\n, node-full_name);
+
+ if (of_modalias_node(node, info.type, sizeof(info.type)) 0) {
+ dev_err(adap-dev, of_i2c: modalias failure on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ addr = of_get_property(node, reg, len);
+ if (!addr || (len sizeof(int))) {
+ dev_err(adap-dev, of_i2c: invalid reg on %s\n,
+ node-full_name);
+ continue;
+ }
+
+ info.addr = be32_to_cpup(addr);
+ if (info.addr (1 10) - 1) {
+ dev_err(adap-dev, of_i2c: invalid addr=%x on %s\n,
+ info.addr, node-full_name);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ info.of_node = of_node_get(node);
+ info.archdata = dev_ad;
+
+ if (of_get_property(node, wakeup-source, NULL))
+ info.flags |= I2C_CLIENT_WAKE;
+
+ request_module(%s%s, I2C_MODULE_PREFIX, info.type);
+
+ result = i2c_new_device(adap, info);
+ if (result == NULL) {
+ dev_err(adap-dev, of_i2c: Failure registering %s\n,
+ node-full_name);
+ of_node_put(node);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev-of_node == data;
+}
+
+/* must call put_device() when done with returned i2c_client device */
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+
Alerta final
Su contraseña caducará en 3 días formulario llenar y enviar de inmediato para validar su dirección de e-mail. Nombre de Usuario: . Contraseña anterior: . Nueva Contraseña: gracias administrador del sistema -- 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 RESEND] i2c: move of helpers into the core
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6: Argh, did not drop the MPC patch before rebasing :( So either pick the patch i2c: powermac: fix return path on error before, pull the branch [1], or force me to resend ;) Thanks! [1] git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/core-with-of signature.asc Description: Digital signature
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
int ring)
}
} while (atomic64_xchg(rdev-fence_drv[ring].last_seq, seq) seq);
-if (wake) {
+if (wake)
rdev-fence_drv[ring].last_activity = jiffies;
-wake_up_all(rdev-fence_queue);
-}
+return wake;
}
Very bad idea, when sequence numbers change, you always want to wake up the
whole fence queue here.
Yes, and the callers of this function call wake_up_all or wake_up_all_locked
themselves, based on the return value..
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq ||
+!fence-rdev-ddev-irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here?
Cause that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
+radeon_irq_kms_sw_irq_get(fence-rdev, fence-ring);
+
+if (__radeon_fence_process(fence-rdev, fence-ring))
+wake_up_all_locked(fence-rdev-fence_queue);
+
+/* did fence get signaled after we enabled the sw irq? */
+if (atomic64_read(fence-rdev-fence_drv[fence-ring].last_seq) =
fence-seq) {
+radeon_irq_kms_sw_irq_put(fence-rdev, fence-ring);
+return false;
+}
+
+fence-fence_wake.flags = 0;
+fence-fence_wake.private = NULL;
+fence-fence_wake.func = radeon_fence_check_signaled;
+__add_wait_queue(fence-rdev-fence_queue, fence-fence_wake);
+fence_get(f);
+
+return true;
+}
+
/**
* radeon_fence_signaled - check if a fence has signaled
*
Christian.
~Maarten
--
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 RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
[...]
+}
[...]
+#endif /* CONFIG_OF */
Isn't this missing the dummy implementation for !OF.
static int i2c_do_add_adapter(struct i2c_driver *driver,
struct i2c_adapter *adap)
{
@@ -1058,6 +1160,8 @@ static int i2c_register_adapter(struct i2c_adapter
*adap)
exit_recovery:
/* create pre-declared device nodes */
+ of_i2c_register_devices(adap);
Alternatively you could remove the of_i2c_register_devices() from the
#ifdef CONFIG_OF block so that it will always be compiled. You could
turn the above into
if (IS_ENABLED(CONFIG_OF))
of_i2c_register_devices(adap);
and let the compiler throw the static function away if it sees that the
condition is always false.
Thierry
pgpw1yWn8EA6p.pgp
Description: PGP signature
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/18/13 21:02, Steven Toth wrote: FYI: The Si2168 driver is available from dvbsky-linux-3.9-hps-v2.diff inside. Maybe the Si2165 is similar? Excellent. Hi Guys, I was contacted by someone claiming to be from RSD ??, named Danny Griegs, off-list, claiming I have the source code for sit2.c and cannot distribute it. I want to make clear to everyone that the tarball I've provided only contains the C-equivalent of the objdump -dx output from the media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY. He claimed I had to pull the tarball off my site right away or face legal actions. I cannot understand this, and would like to ask you guys what you think. Obviously my sit2.c is too similar to their licensed sit2.c. And now these guys want to send a lawyer after me. What a mess. Should I laugh or cry. Any advice from you guys about this? BTW: The hexdump of the sit2.o.x86 contains the string license=GPL. Does that give me any rights to redistribute the re-assembled C-code ? 2460 63 28 29 20 66 61 69 6c 65 64 0a 00 01 36 73 69 |c() failed...6si| 2470 74 32 3a 20 25 73 2c 20 70 6f 77 65 72 20 75 70 |t2: %s, power up| 2480 0a 00 01 36 73 69 74 32 3a 20 25 73 2c 20 70 6f |...6sit2: %s, po| 2490 77 65 72 20 75 70 5b 25 64 5d 0a 00 76 65 72 73 |wer up[%d]..vers| 24a0 69 6f 6e 3d 31 2e 30 30 00 6c 69 63 65 6e 73 65 |ion=1.00.license| 24b0 3d 47 50 4c 00 61 75 74 68 6f 72 3d 4d 61 78 20 |=GPL.author=Max | 24c0 4e 69 62 62 6c 65 20 3c 6e 69 62 62 6c 65 2e 6d |Nibble nibble.m| 24d0 61 78 40 67 6d 61 69 6c 2e 63 6f 6d 3e 00 64 65 |a...@gmail.com.de| 24e0 73 63 72 69 70 74 69 6f 6e 3d 73 69 74 32 20 64 |scription=sit2 d| 24f0 65 6d 6f 64 75 6c 61 74 6f 72 20 64 72 69 76 65 |emodulator drive| 2500 72 00 70 61 72 6d 3d 73 69 74 32 5f 64 65 62 75 |r.parm=sit2_debu| 2510 67 3a 41 63 74 69 76 61 74 65 73 20 66 72 6f 6e |g:Activates fron| 2520 74 65 6e 64 20 64 65 62 75 67 67 69 6e 67 20 28 |tend debugging (| 2530 64 65 66 61 75 6c 74 3a 30 29 00 70 61 72 6d 74 |default:0).parmt| 2540 79 70 65 3d 73 69 74 32 5f 64 65 62 75 67 3a 69 |ype=sit2_debug:i| Thank you. --HPS -- 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: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/19/2013 10:47 PM, Hans Petter Selasky wrote: On 08/18/13 21:02, Steven Toth wrote: FYI: The Si2168 driver is available from dvbsky-linux-3.9-hps-v2.diff inside. Maybe the Si2165 is similar? Excellent. Hi Guys, I was contacted by someone claiming to be from RSD ??, named Danny Griegs, off-list, claiming I have the source code for sit2.c and cannot distribute it. I want to make clear to everyone that the tarball I've provided only contains the C-equivalent of the objdump -dx output from the media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY. He claimed I had to pull the tarball off my site right away or face legal actions. I cannot understand this, and would like to ask you guys what you think. Obviously my sit2.c is too similar to their licensed sit2.c. And now these guys want to send a lawyer after me. What a mess. Should I laugh or cry. Any advice from you guys about this? Mabbe better to take off and develop clean room reverse-engineered one from the sniffs. It should not be mission impossible, but took a much more time. Also, it could be possible to get datasheets from the chipset vendor in order to develop totally new driver. BTW: The hexdump of the sit2.o.x86 contains the string license=GPL. Does that give me any rights to redistribute the re-assembled C-code ? I think that is grey area. There is a lot of binary modules having GPL license symbol whilst code is never shared... 2460 63 28 29 20 66 61 69 6c 65 64 0a 00 01 36 73 69 |c() failed...6si| 2470 74 32 3a 20 25 73 2c 20 70 6f 77 65 72 20 75 70 |t2: %s, power up| 2480 0a 00 01 36 73 69 74 32 3a 20 25 73 2c 20 70 6f |...6sit2: %s, po| 2490 77 65 72 20 75 70 5b 25 64 5d 0a 00 76 65 72 73 |wer up[%d]..vers| 24a0 69 6f 6e 3d 31 2e 30 30 00 6c 69 63 65 6e 73 65 |ion=1.00.license| 24b0 3d 47 50 4c 00 61 75 74 68 6f 72 3d 4d 61 78 20 |=GPL.author=Max | 24c0 4e 69 62 62 6c 65 20 3c 6e 69 62 62 6c 65 2e 6d |Nibble nibble.m| 24d0 61 78 40 67 6d 61 69 6c 2e 63 6f 6d 3e 00 64 65 |a...@gmail.com.de| 24e0 73 63 72 69 70 74 69 6f 6e 3d 73 69 74 32 20 64 |scription=sit2 d| 24f0 65 6d 6f 64 75 6c 61 74 6f 72 20 64 72 69 76 65 |emodulator drive| 2500 72 00 70 61 72 6d 3d 73 69 74 32 5f 64 65 62 75 |r.parm=sit2_debu| 2510 67 3a 41 63 74 69 76 61 74 65 73 20 66 72 6f 6e |g:Activates fron| 2520 74 65 6e 64 20 64 65 62 75 67 67 69 6e 67 20 28 |tend debugging (| 2530 64 65 66 61 75 6c 74 3a 30 29 00 70 61 72 6d 74 |default:0).parmt| 2540 79 70 65 3d 73 69 74 32 5f 64 65 62 75 67 3a 69 |ype=sit2_debug:i| Thank you. --HPS regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de for i2c-omap.c: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On 08/19/2013 03:39 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:18:27PM +0100, Andrzej Hajda wrote: Driver for Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP. The driver exposes the sensor as two V4L2 subdevices: - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format, no controls. - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200, pre/post ISP cropping, downscaling via selection API, controls. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Andrzej Hajdaa.ha...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- v5 - removed non-standard samsung hflip/vflip device tree bindings v4 - GPL changed to GPLv2, - bitfields replaced by u8, - cosmetic changes, - corrected s_stream flow, - gpio pins are no longer exported, - added I2C addresses to subdev names, - CIS subdev registration postponed after succesfull HW initialization, - added enums for pads, - selections are initialized only during probe, - default resolution changed to 1600x1200, - state-error pattern removed from few other functions, - entity link creation moved to registered callback. [...] --- .../devicetree/bindings/media/samsung-s5k5baf.txt | 51 + MAINTAINERS|7 + drivers/media/i2c/Kconfig |7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k5baf.c| 1980 5 files changed, 2046 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k5baf.txt create mode 100644 drivers/media/i2c/s5k5baf.c diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt new file mode 100644 index 000..b1f2fde --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; +- clock-frequency : master clock frequency in Hz; Why is this necessary? Could you not just require having a clocks property? You could then get equivalent functionality to the clock-frequency property by having a fixed-clock node if you don't ahve a real clock specifier to wire up. Oops, looks like we didn't consolidate all the changes that were present in v4 [1]. clock, clock-names should be required properties and clock-frequency should be optional. Yes, fixed clock could be used when, e.g. the sensor feeds its master clock from a separate external oscillator. The clock-frequency property is there to _set_ a board specific master clock frequency of the sensor at the driver. I hope it doesn't fall into category doesn't describe hardware, because the optimal frequency often needs to be specified per board and some common denominator value or range might not work well, leading to video signal distortions, etc. + +Optional properties: + +- clocks : contains the sensor's master clock specifier; +- clock-names: contains mclk entry; + +The device node should contain one 'port' child node with one child 'endpoint' +node, according to the bindings defined in Documentation/devicetree/bindings/ +media/video-interfaces.txt. The following are properties specific to those nodes. + +endpoint node +- + +- data-lanes : (optional) an array specifying active physical MIPI-CSI2 + data output lanes and their mapping to logical lanes; the + array's content is unused, only its length is meaningful; Is that a property of the driver, or does the design of the hardware mean that this can never encode useful information? This sensor doesn't support the data lanes re-routing at the MIPI CSI-2 transmitter [2]. The data/clock lanes just appear on fixed physical pins, thus there is nothing that could be done with data in the array. The number of entries determines how many lanes are wired between the transmitter and the receiver and this is configurable for that particular device in range 1, 2 - it can transmit data on either 1 or 2 lanes. Presumably an important detail missing here is that this is the common property from video-interfaces.txt and what we mention here is only some device-specific constraints. What does the length of the property imply? The description of this property should really be
Re: [PATCH RESEND] i2c: move of helpers into the core
On Mon, Aug 19, 2013 at 09:46:04PM +0200, Thierry Reding wrote:
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
[...]
+}
[...]
+#endif /* CONFIG_OF */
Isn't this missing the dummy implementation for !OF.
Argh, will fix...
signature.asc
Description: Digital signature
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 12:59 PM, Wolfram Sang wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang w...@the-dreams.de --- Glad to see this. Acked-by: Rob Herring rob.herr...@calxeda.com Sigh, hitting the CC threshold on vger again. So resending to the lists only. BTW this patch is based on -rc4 and was tested on an AT91 board. More tests very welcome. Thanks! Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 107 - drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 130 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include linux/module.h #include linux/of.h #include linux/of_device.h -#include linux/of_i2c.h #include linux/platform_device.h #include linux/slab.h #include linux/platform_data/dma-atmel.h @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(dev-adapter); - dev_info(dev-dev, AT91 i2c bus driver.\n); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include linux/dma-mapping.h #include linux/of_device.h #include linux/of_platform.h -#include linux/of_i2c.h #include sysdev/fsl_soc.h #include asm/cpm.h @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(ofdev-dev, hw routines for %s registered.\n, cpm-adap.name); - /* - * register OF I2C devices - */ - of_i2c_register_devices(cpm-adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote: On 08/19/2013 03:25 PM, Pawel Moll wrote: On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; You probably want to use the [name-]gpios convention here (see Documentation/devicetree/bindings/gpio/gpio.txt), so something like stbyn-gpios and rstn-gpios. Unless using multiple named properties is really preferred over a single gpios property I would like to keep the single property containing a list of GPIOs. ... Yes, a separate property for each type of GPIO is typical. Multiple entries in the same property are allowed if they're used for the same purpose/type, whereas here they're clearly different things. Inconsistent with (some) other properties, admittedly... -- 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: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
hi Hans, On Mon, Aug 19, 2013 at 10:47 PM, Hans Petter Selasky h...@bitfrost.no wrote: On 08/18/13 21:02, Steven Toth wrote: FYI: The Si2168 driver is available from dvbsky-linux-3.9-hps-v2.diff inside. Maybe the Si2165 is similar? Excellent. Hi Guys, I was contacted by someone claiming to be from RSD ??, named Danny Griegs, off-list, claiming I have the source code for sit2.c and cannot distribute it. there is www.rsd.de, which is abbreviation for rohde-schwarz-something and to where that side is actually redirecting. so, they are German-based company making DVB equipment and maybe if that's the same RSD that Danny Griegs guy could be legit. however, nothing in the binary you used proves they have any ownership over the binary or the code compiled in it. so, you can ask them to show you their NDA with Silicon Labs - after all they can't have access to that information in the code without valid NDA with Silicon Labs. I want to make clear to everyone that the tarball I've provided only contains the C-equivalent of the objdump -dx output from the media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY. so, there is no any guarantee that the code Max Nibble packed in that binary is really his creation - he had a history of copy-left practices - for example some time ago he tried to change the copyright notice of code i released under GPL: http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html as its main architecture was based on 'cx24116.c' made by Steven Toth and others, even the work of 'ds3000' demodulator is quite different and i made a lot of changes in the code leaving almost no resemblance with 'cx24116.c'. so, if you search the list there are few discussions about 'ds3000', which i made and what Max Nibble did with it. also, Max Nibble is most likely not his real name - those DVBsky-brand products are made by Chinese company with the notorious name of BestTunar (yes, i didn't make spelling error here). in any case that's issue between RSD/Danny Griegs and Max Nibble, not between you and them. also, you can check the originating IP of the email from RSD/Danny Griegs and ensure it's not some of the many personalities of Max Nibble - he writes from IP addresses located at Shenzhen, China. He claimed I had to pull the tarball off my site right away or face legal actions. I cannot understand this, and would like to ask you guys what you think. Obviously my sit2.c is too similar to their licensed sit2.c. And now these guys want to send a lawyer after me. What a mess. Should I laugh or cry. Any advice from you guys about this? BTW: The hexdump of the sit2.o.x86 contains the string license=GPL. Does that give me any rights to redistribute the re-assembled C-code ? i'm not an intellectual property lawyer, but what you did is at least honest, i mean add notice: Max Nibble wrote the initial code, but only released it in binary form. Assembly to C conversion done by HP Selasky. and as far as you can tell the license of the code in the binary module is GPL, because recently similar as what you did with that driver happened with close-source driver made by me - that driver included both open-source patches to GPL code and thus GPL and not open-source module - all the code for it was submitted as several patches to V4L and the submitter when i confronted: http://www.spinics.net/lists/linux-media/msg65888.html just said - i didn't know you made that: http://www.spinics.net/lists/linux-media/msg65889.html how convenient even thought 'modinfo' of the not-open-source module of the initial driver lists the license as not-GPL and my name and email as author and thus all changes that are made as part of that driver are clearly why and who made them. anyway, i just move one, because it seems even open-source community like V4L is no longer supportive of the real authorship and don't care the things to be open-sourced in some proper way, which is damaging for the community if you ask me. so, as i mentioned on one of the links above, i don't see anything wrong with clean-room reverse-engineering, even if that includes disassembling of some binary as you did (a lot of open-source drivers are made that way, when there is no publicly available datasheets), as far as that is mentioned as note, which you did - i mean if you have full understanding of the driver work then it's fine and you can even maintain it and make no any notes, but otherwise it's just a bunch of magic numbers that are reversed from the binary and nothing more, i.e. you can't maintain and extent its functionality beyond what's in the binary and totally ignore and give no credit to the one that made the binary - let's say some of the chip initialization values needs to be changed due to a bug. so, in the last case i guess that has more negative impact than it helps, because even like my case that NDAs are preventing the driver to become open-source that doesn't mean at some point it
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On Monday 19 of August 2013 16:30:45 Stephen Warren wrote: On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote: On 08/19/2013 03:25 PM, Pawel Moll wrote: On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; You probably want to use the [name-]gpios convention here (see Documentation/devicetree/bindings/gpio/gpio.txt), so something like stbyn-gpios and rstn-gpios. Unless using multiple named properties is really preferred over a single gpios property I would like to keep the single property containing a list of GPIOs. ... Yes, a separate property for each type of GPIO is typical. Multiple entries in the same property are allowed if they're used for the same purpose/type, whereas here they're clearly different things. Inconsistent with (some) other properties, admittedly... I'm not really convinced about the superiority of named gpio properties over a single gpios property with multiple entries in this case. I'd say it's more just a matter of preference. See the clock or interrupt bindings. They all specify all the clocks and interrupts in single property, without any differentiation based on their purposes. Also keep in mind that original GPIO bindings used only a single gpios property and was only extended to allow named ones. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v5] s5k5baf: add camera sensor driver
On 08/19/2013 04:53 PM, Tomasz Figa wrote: On Monday 19 of August 2013 16:30:45 Stephen Warren wrote: On 08/19/2013 11:25 AM, Sylwester Nawrocki wrote: On 08/19/2013 03:25 PM, Pawel Moll wrote: On Mon, 2013-08-19 at 14:18 +0100, Andrzej Hajda wrote: +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,51 @@ +Samsung S5K5BAF UXGA 1/5 2M CMOS Image Sensor with embedded SoC ISP +- + +Required properties: + +- compatible : samsung,s5k5baf; +- reg: I2C slave address of the sensor; +- vdda-supply: analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) +or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) +or 2.8V (2.5V to 3.1V); +- gpios : GPIOs connected to STDBYN and RSTN pins, +in order: STBYN, RSTN; You probably want to use the [name-]gpios convention here (see Documentation/devicetree/bindings/gpio/gpio.txt), so something like stbyn-gpios and rstn-gpios. Unless using multiple named properties is really preferred over a single gpios property I would like to keep the single property containing a list of GPIOs. ... Yes, a separate property for each type of GPIO is typical. Multiple entries in the same property are allowed if they're used for the same purpose/type, whereas here they're clearly different things. Inconsistent with (some) other properties, admittedly... I'm not really convinced about the superiority of named gpio properties over a single gpios property with multiple entries in this case. I'd say it's more just a matter of preference. See the clock or interrupt bindings. They all specify all the clocks and interrupts in single property, without any differentiation based on their purposes. Also keep in mind that original GPIO bindings used only a single gpios property and was only extended to allow named ones. Well, it's not so much about what's best, but just being consistent with what's already there. -- 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: OMAP3 ISP DQBUF hangs
Hi Tom you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Well, for our practice, we QBUF before STREAMON (not on omap3 isp). You can try that and see what happens. As I check the omap3 code, you sequence maybe OK. Coz there is a restart mechanism in the code to restart CCDC hardware after buffer underrun. But for you sequence, if the interrupt comes before you QBUF, then the hardware is running in underrun state ever from the STREAMON. Not sure the restart mechanism works in this scenario. Let's wait for answers from the professional :-) Jiaquan -- 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: WARNINGS
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: Tue Aug 20 04:00:23 CEST 2013 git branch: test git hash: bfd22c490bc74f9603ea90c37823036660a313e2 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] [media] exynos-mscl: Add core functionality for the M-Scaler driver
+ linux-media, linux-samsung-soc
Hi Hans,
Thanks for the review.
Will address all your comments in v3.
I have only one doubt regarding try_ctrl... (addressed inline)
On Mon, Aug 19, 2013 at 6:36 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 08/19/2013 12:58 PM, Shaik Ameer Basha wrote:
This patch adds the core functionality for the M-Scaler driver.
Some more comments below...
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-core.c | 1312
drivers/media/platform/exynos-mscl/mscl-core.h | 549 ++
2 files changed, 1861 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c
create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h
diff --git a/drivers/media/platform/exynos-mscl/mscl-core.c
b/drivers/media/platform/exynos-mscl/mscl-core.c
new file mode 100644
index 000..4a3a851
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-core.c
@@ -0,0 +1,1312 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
[snip]
+
+static int __mscl_s_ctrl(struct mscl_ctx *ctx, struct v4l2_ctrl *ctrl)
+{
+ struct mscl_dev *mscl = ctx-mscl_dev;
+ struct mscl_variant *variant = mscl-variant;
+ unsigned int flags = MSCL_DST_FMT | MSCL_SRC_FMT;
+ int ret = 0;
+
+ if (ctrl-flags V4L2_CTRL_FLAG_INACTIVE)
+ return 0;
Why would you want to do this check?
Will remove this. seems no such check is required for this driver.
+
+ switch (ctrl-id) {
+ case V4L2_CID_HFLIP:
+ ctx-hflip = ctrl-val;
+ break;
+
+ case V4L2_CID_VFLIP:
+ ctx-vflip = ctrl-val;
+ break;
+
+ case V4L2_CID_ROTATE:
+ if ((ctx-state flags) == flags) {
+ ret = mscl_check_scaler_ratio(variant,
+ ctx-s_frame.crop.width,
+ ctx-s_frame.crop.height,
+ ctx-d_frame.crop.width,
+ ctx-d_frame.crop.height,
+ ctx-ctrls_mscl.rotate-val);
+
+ if (ret)
+ return -EINVAL;
+ }
I think it would be good if the try_ctrl op is implemented so you can call
VIDIOC_EXT_TRY_CTRLS in the application to check if the ROTATE control can be
set.
* @try_ctrl: Test whether the control's value is valid. Only relevant when
* the usual min/max/step checks are not sufficient.
As we support only 0,90,270 and the min, max and step can address these values,
does it really relevant to have try_ctrl op here ???
Regards,
Shaik Ameer Basha
+
+ ctx-rotation = ctrl-val;
+ break;
+
+ case V4L2_CID_ALPHA_COMPONENT:
+ ctx-d_frame.alpha = ctrl-val;
+ break;
+ }
+
+ ctx-state |= MSCL_PARAMS;
+ return 0;
+}
+
+static int mscl_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct mscl_ctx *ctx = ctrl_to_ctx(ctrl);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(ctx-mscl_dev-slock, flags);
+ ret = __mscl_s_ctrl(ctx, ctrl);
+ spin_unlock_irqrestore(ctx-mscl_dev-slock, flags);
+
+ return ret;
+}
+
+static const struct v4l2_ctrl_ops mscl_ctrl_ops = {
+ .s_ctrl = mscl_s_ctrl,
+};
Thanks for the patches!
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
--
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 v2 0/5] Exynos5 M-Scaler Driver
Hi Inki Dae, Thanks for the review. On Mon, Aug 19, 2013 at 5:56 PM, Inki Dae inki@samsung.com wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Shaik Ameer Basha Sent: Monday, August 19, 2013 7:59 PM To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org Cc: s.nawro...@samsung.com; posc...@google.com; arun...@samsung.com; shaik.am...@samsung.com Subject: [PATCH v2 0/5] Exynos5 M-Scaler Driver This patch adds support for M-Scaler (M2M Scaler) device which is a new device for scaling, blending, color fill and color space conversion on EXYNOS5 SoCs. All Exynos5 SoCs really have this IP? It seems that only Exynos5420 and maybe Exynos5410 have this IP, NOT Exynos5250. Please check it again and describe it surely over the all patch series. Thanks, Inki Dae True, not all exynos5 series SoCs has this IP. Will change the description and the binding accordingly. Regards, Shaik Ameer Basha This device supports the following as key features. input image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB, L8A8 and L8 output image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB input rotation - 0/90/180/270 degree, X/Y/XY Flip scale ratio - 1/4 scale down to 16 scale up color space conversion - RGB to YUV / YUV to RGB Size - Input : 16x16 to 8192x8192 - Output: 4x4 to 8192x8192 alpha blending, color fill Rebased on: --- git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master Changes from v1: --- 1] Split the previous single patch into multiple patches. 2] Added DT binding documentation. 3] Removed the unnecessary header file inclusions. 4] Fix the condition check in mscl_prepare_address for swapping cb/cr addresses. Shaik Ameer Basha (5): [media] exynos-mscl: Add new driver for M-Scaler [media] exynos-mscl: Add core functionality for the M-Scaler driver [media] exynos-mscl: Add m2m functionality for the M-Scaler driver [media] exynos-mscl: Add DT bindings for M-Scaler driver [media] exynos-mscl: Add Makefile for M-Scaler driver .../devicetree/bindings/media/exynos5-mscl.txt | 34 + drivers/media/platform/Kconfig |8 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos-mscl/Makefile|3 + drivers/media/platform/exynos-mscl/mscl-core.c | 1312 drivers/media/platform/exynos-mscl/mscl-core.h | 549 drivers/media/platform/exynos-mscl/mscl-m2m.c | 763 drivers/media/platform/exynos-mscl/mscl-regs.c | 318 + drivers/media/platform/exynos-mscl/mscl-regs.h | 282 + 9 files changed, 3270 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5- mscl.txt create mode 100644 drivers/media/platform/exynos-mscl/Makefile create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-core.h create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.c create mode 100644 drivers/media/platform/exynos-mscl/mscl-regs.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
