Re: [PATCH v2 2/3] omap3: change ISP's IOMMU da_start address
On Wed, Mar 9, 2011 at 9:43 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
David Cohen wrote:
ISP doesn't consider 0x0 as a valid address, so it should explicitly
exclude first page from allowed 'da' range.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/mach-omap2/omap-iommu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index 3fc5dc7..3bea489 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -33,7 +33,7 @@ static struct iommu_device omap3_devices[] = {
.name = isp,
.nr_tlb_entries = 8,
.clk_name = cam_ick,
- .da_start = 0x0,
+ .da_start = 0x1000,
.da_end = 0xF000,
},
},
Hi David!
Hi Sakari,
Thanks for the patch.
And thanks for the comments. :)
My question is once again: is this necessary? My understanding is that
the IOMMU allows mapping the NULL address if the user wishes to map it
explicitly. da_end specifies the real hardware limit for the mapped top
address, da_start should do the same for bottom.
Hm. da_start/da_end in this case belong to OMAP3 IOMMU ISP VM. It
means they're related to OMAP3 ISP only. But they do not reflect the
hw limit, as the range limit is anything which fits in u32. They say
what's the range OMAP3 ISP is expecting to have mapped. And the answer
to this question is the first page is not expected. Then, why say the
opposite in da_start?
I think that the IOMMU users should be either able to rely that they get
no NULL allocated automatically for them. Do we want or not want it to
be part of the API? I don't think the ISP driver is a special case of
all the possible drivers using the IOMMU.
My understanding after this discussion is address 0x0 should be
allowed (what is done by patch 3/3 of this set). But as a safer
choice, it won't be returned without explicitly request (what is done
in path 1/3). Because of that, I'm OK in drop this patch 2/3. But then
there's one question which is the motivation for this change:
If the current OMAP3 ISP driver doesn't want the first page, (1)
should we pass a generic information and expect IOVMM driver to
correct it to ISP need or (2) should we pass the information which
reflects the real ISP driver's need?
My understanding is (2). But I'm fine with (1) as it will lead to the
same result.
On the other hand, probably there will be an API change at some point
for the IOMMU since as far as I remember, there are somewhat
established APIs for IOMMUs in existence.
At some point we need to find a standard for many IOMMU drivers. But
for now we need to stick with what we have. :)
Regards,
David Cohen
--
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 v3 0/2] omap: iovmm: Fix IOVMM check for fixed 'da'
Hi, Previous patch 2/3 was dropped in this new version. Patch 1 was updated according to a comment it got. --- IOVMM driver checks input 'da == 0' when mapping address to determine whether user wants fixed 'da' or not. At the same time, it doesn't disallow address 0x0 to be used, what creates an ambiguous situation. This patch set moves fixed 'da' check to the input flags. Br, David Cohen --- David Cohen (1): omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag Michael Jones (1): omap: iovmm: disallow mapping NULL address when IOVMF_DA_ANON is set arch/arm/plat-omap/include/plat/iovmm.h |2 -- arch/arm/plat-omap/iovmm.c | 27 --- 2 files changed, 12 insertions(+), 17 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] omap: iovmm: disallow mapping NULL address when IOVMF_DA_ANON is set
From: Michael Jones michael.jo...@matrix-vision.de
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL
address if da_start==0, which would then not get unmapped. Disallow
this again if IOVMF_DA_ANON is set. And spell variable 'alignment'
correctly.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
arch/arm/plat-omap/iovmm.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 6dc1296..ea7eab9 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -271,20 +271,21 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
size_t bytes, u32 flags)
{
struct iovm_struct *new, *tmp;
- u32 start, prev_end, alignement;
+ u32 start, prev_end, alignment;
if (!obj || !bytes)
return ERR_PTR(-EINVAL);
start = da;
- alignement = PAGE_SIZE;
+ alignment = PAGE_SIZE;
if (flags IOVMF_DA_ANON) {
- start = obj-da_start;
+ /* Don't map address 0 */
+ start = obj-da_start ? obj-da_start : alignment;
if (flags IOVMF_LINEAR)
- alignement = iopgsz_max(bytes);
- start = roundup(start, alignement);
+ alignment = iopgsz_max(bytes);
+ start = roundup(start, alignment);
} else if (start obj-da_start || start obj-da_end ||
obj-da_end - start bytes) {
return ERR_PTR(-EINVAL);
@@ -304,7 +305,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
goto found;
if (tmp-da_end = start flags IOVMF_DA_ANON)
- start = roundup(tmp-da_end + 1, alignement);
+ start = roundup(tmp-da_end + 1, alignment);
prev_end = tmp-da_end;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag
Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
to input 'da' address when mapping memory:
da == 0: IOVMF_DA_ANON
da != 0: IOVMF_DA_FIXED
It prevents IOMMU to map first page with fixed 'da'. To avoid such
issue, IOVMM will not automatically set IOVMF_DA_FIXED. It should now
come from the user throught 'flags' parameter when mapping memory.
As IOVMF_DA_ANON and IOVMF_DA_FIXED are mutually exclusive, IOVMF_DA_ANON
can be removed. The driver will now check internally if IOVMF_DA_FIXED
is set or not.
Signed-off-by: David Cohen daco...@gmail.com
---
arch/arm/plat-omap/include/plat/iovmm.h |2 --
arch/arm/plat-omap/iovmm.c | 14 +-
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
index bdc7ce5..32a2f6c 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -71,8 +71,6 @@ struct iovm_struct {
#define IOVMF_LINEAR_MASK (3 (2 + IOVMF_SW_SHIFT))
#define IOVMF_DA_FIXED (1 (4 + IOVMF_SW_SHIFT))
-#define IOVMF_DA_ANON (2 (4 + IOVMF_SW_SHIFT))
-#define IOVMF_DA_MASK (3 (4 + IOVMF_SW_SHIFT))
extern struct iovm_struct *find_iovm_area(struct iommu *obj, u32 da);
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index ea7eab9..51ef43e 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -279,7 +279,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
start = da;
alignment = PAGE_SIZE;
- if (flags IOVMF_DA_ANON) {
+ if (~flags IOVMF_DA_FIXED) {
/* Don't map address 0 */
start = obj-da_start ? obj-da_start : alignment;
@@ -304,7 +304,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
if (tmp-da_start start (tmp-da_start - start) = bytes)
goto found;
- if (tmp-da_end = start flags IOVMF_DA_ANON)
+ if (tmp-da_end = start ~flags IOVMF_DA_FIXED)
start = roundup(tmp-da_end + 1, alignment);
prev_end = tmp-da_end;
@@ -651,7 +651,6 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct
sg_table *sgt,
flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_MMIO;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
da = __iommu_vmap(obj, da, sgt, va, bytes, flags);
if (IS_ERR_VALUE(da))
@@ -691,7 +690,7 @@ EXPORT_SYMBOL_GPL(iommu_vunmap);
* @flags: iovma and page property
*
* Allocate @bytes linearly and creates 1-n-1 mapping and returns
- * @da again, which might be adjusted if 'IOVMF_DA_ANON' is set.
+ * @da again, which might be adjusted if 'IOVMF_DA_FIXED' is not set.
*/
u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes, u32 flags)
{
@@ -710,7 +709,6 @@ u32 iommu_vmalloc(struct iommu *obj, u32 da, size_t bytes,
u32 flags)
flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
flags |= IOVMF_ALLOC;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
sgt = sgtable_alloc(bytes, flags, da, 0);
if (IS_ERR(sgt)) {
@@ -781,7 +779,7 @@ static u32 __iommu_kmap(struct iommu *obj, u32 da, u32 pa,
void *va,
* @flags: iovma and page property
*
* Creates 1-1-1 mapping and returns @da again, which can be
- * adjusted if 'IOVMF_DA_ANON' is set.
+ * adjusted if 'IOVMF_DA_FIXED' is not set.
*/
u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t bytes,
u32 flags)
@@ -800,7 +798,6 @@ u32 iommu_kmap(struct iommu *obj, u32 da, u32 pa, size_t
bytes,
flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_MMIO;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
da = __iommu_kmap(obj, da, pa, va, bytes, flags);
if (IS_ERR_VALUE(da))
@@ -839,7 +836,7 @@ EXPORT_SYMBOL_GPL(iommu_kunmap);
* @flags: iovma and page property
*
* Allocate @bytes linearly and creates 1-1-1 mapping and returns
- * @da again, which might be adjusted if 'IOVMF_DA_ANON' is set.
+ * @da again, which might be adjusted if 'IOVMF_DA_FIXED' is not set.
*/
u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes, u32 flags)
{
@@ -859,7 +856,6 @@ u32 iommu_kmalloc(struct iommu *obj, u32 da, size_t bytes,
u32 flags)
flags = IOVMF_HW_MASK;
flags |= IOVMF_LINEAR;
flags |= IOVMF_ALLOC;
- flags |= (da ? IOVMF_DA_FIXED : IOVMF_DA_ANON);
da = __iommu_kmap(obj, da, pa, va, bytes, flags);
if (IS_ERR_VALUE(da))
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l2 saa7134
Hi, Is there anybody, who knows, how, the v4l2 saa7134 part works in kernel space? I mean I have a gt-p8000 tv card. It's a hybrid tuner. I started to modify the saa7134 driver, but I cannot see the control flaw, the call order. Furthermore I would like to debug my code like only switching a GPIO on a single chip. My card contains the following chips: saa7131e/03/g tda18271hd tda10048hn My future plan to create a gui, and control the 3 chips separately. But first of all, to make it work as a TV card on linux. Thanks. BR, Norbert -- 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 2/6] universal: i2c: add I2C controller 8 (HDMIPHY)
Tomasz Stanislawski wrote:
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv310/clock.c |6 +++
arch/arm/mach-s5pv310/include/mach/irqs.h |4 ++
arch/arm/mach-s5pv310/include/mach/map.h |1 +
arch/arm/plat-samsung/Kconfig |5 ++
arch/arm/plat-samsung/Makefile|1 +
arch/arm/plat-samsung/dev-i2c8.c | 68
+
arch/arm/plat-samsung/include/plat/devs.h |1 +
arch/arm/plat-samsung/include/plat/iic.h |1 +
8 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/dev-i2c8.c
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index d28fa6f..465beb9 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -685,6 +685,12 @@ static struct clk init_clocks_off[] = {
.parent = clk_aclk_100.clk,
.enable = s5pv310_clk_ip_peril_ctrl,
.ctrlbit= (1 13),
+ }, {
+ .name = i2c,
+ .id = 8,
+ .parent = clk_aclk_100.clk,
+ .enable = s5pv310_clk_ip_peril_ctrl,
+ .ctrlbit= (1 14),
},
};
diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach-
s5pv310/include/mach/irqs.h
index f6b99c6..f7ddc98 100644
--- a/arch/arm/mach-s5pv310/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv310/include/mach/irqs.h
@@ -77,6 +77,9 @@
#define IRQ_PDMA0COMBINER_IRQ(21, 0)
#define IRQ_PDMA1COMBINER_IRQ(21, 1)
+#define IRQ_HDMI COMBINER_IRQ(16, 0)
+#define IRQ_HDMI_I2C COMBINER_IRQ(16, 1)
+
#define IRQ_TIMER0_VIC COMBINER_IRQ(22, 0)
#define IRQ_TIMER1_VIC COMBINER_IRQ(22, 1)
#define IRQ_TIMER2_VIC COMBINER_IRQ(22, 2)
@@ -100,6 +103,7 @@
#define IRQ_IIC5 COMBINER_IRQ(27, 5)
#define IRQ_IIC6 COMBINER_IRQ(27, 6)
#define IRQ_IIC7 COMBINER_IRQ(27, 7)
+#define IRQ_IIC8 IRQ_HDMI_I2C
#define IRQ_HSMMC0 COMBINER_IRQ(29, 0)
#define IRQ_HSMMC1 COMBINER_IRQ(29, 1)
diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-
s5pv310/include/mach/map.h
index 576ba55..0aa0171 100644
--- a/arch/arm/mach-s5pv310/include/mach/map.h
+++ b/arch/arm/mach-s5pv310/include/mach/map.h
@@ -120,6 +120,7 @@
#define S3C_PA_IIC5 S5PV310_PA_IIC(5)
#define S3C_PA_IIC6 S5PV310_PA_IIC(6)
#define S3C_PA_IIC7 S5PV310_PA_IIC(7)
+#define S3C_PA_IIC8 S5PV310_PA_IIC(8)
#define S3C_PA_RTC S5PV310_PA_RTC
#define S3C_PA_WDT S5PV310_PA_WATCHDOG
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 32be05c..dd1fd15 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -211,6 +211,11 @@ config S3C_DEV_I2C7
help
Compile in platform device definition for I2C controller 7
+config S3C_DEV_I2C8
+ bool
+ help
+ Compile in platform device definitions for I2C channel 8 (HDMIPHY)
+
config S3C_DEV_FB
bool
help
diff --git a/arch/arm/plat-samsung/Makefile
b/arch/arm/plat-samsung/Makefile
index 7e92457..826ae4f 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_S3C_DEV_I2C4) += dev-i2c4.o
obj-$(CONFIG_S3C_DEV_I2C5) += dev-i2c5.o
obj-$(CONFIG_S3C_DEV_I2C6) += dev-i2c6.o
obj-$(CONFIG_S3C_DEV_I2C7) += dev-i2c7.o
+obj-$(CONFIG_S3C_DEV_I2C8) += dev-i2c8.o
obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o
obj-y+= dev-uart.o
obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
diff --git a/arch/arm/plat-samsung/dev-i2c8.c b/arch/arm/plat-samsung/dev-
i2c8.c
new file mode 100644
index 000..8edba7f
--- /dev/null
+++ b/arch/arm/plat-samsung/dev-i2c8.c
@@ -0,0 +1,68 @@
+/* linux/arch/arm/plat-samsung/dev-i2c7.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * S3C series device definition for i2c device 8
+ *
+ * Based on plat-samsung/dev-i2c8.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/gfp.h
+#include linux/kernel.h
+#include linux/string.h
+#include linux/platform_device.h
+
+#include mach/irqs.h
+#include mach/map.h
+
+#include plat/regs-iic.h
+#include plat/iic.h
+#include plat/devs.h
+#include plat/cpu.h
+
+static struct resource s3c_i2c_resource[] = {
+ [0] = {
+ .start = S3C_PA_IIC8,
+ .end =
Re: [PATCH 2/6] universal: i2c: add I2C controller 8 (HDMIPHY)
On Wed, Mar 9, 2011 at 9:00 PM, Kukjin Kim kgene@samsung.com wrote:
Tomasz Stanislawski wrote:
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv310/clock.c | 6 +++
arch/arm/mach-s5pv310/include/mach/irqs.h | 4 ++
arch/arm/mach-s5pv310/include/mach/map.h | 1 +
arch/arm/plat-samsung/Kconfig | 5 ++
arch/arm/plat-samsung/Makefile | 1 +
arch/arm/plat-samsung/dev-i2c8.c | 68
+
arch/arm/plat-samsung/include/plat/devs.h | 1 +
arch/arm/plat-samsung/include/plat/iic.h | 1 +
8 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/dev-i2c8.c
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index d28fa6f..465beb9 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -685,6 +685,12 @@ static struct clk init_clocks_off[] = {
.parent = clk_aclk_100.clk,
.enable = s5pv310_clk_ip_peril_ctrl,
.ctrlbit = (1 13),
+ }, {
+ .name = i2c,
+ .id = 8,
+ .parent = clk_aclk_100.clk,
+ .enable = s5pv310_clk_ip_peril_ctrl,
+ .ctrlbit = (1 14),
},
};
diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach-
s5pv310/include/mach/irqs.h
index f6b99c6..f7ddc98 100644
--- a/arch/arm/mach-s5pv310/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv310/include/mach/irqs.h
@@ -77,6 +77,9 @@
#define IRQ_PDMA0 COMBINER_IRQ(21, 0)
#define IRQ_PDMA1 COMBINER_IRQ(21, 1)
+#define IRQ_HDMI COMBINER_IRQ(16, 0)
+#define IRQ_HDMI_I2C COMBINER_IRQ(16, 1)
+
#define IRQ_TIMER0_VIC COMBINER_IRQ(22, 0)
#define IRQ_TIMER1_VIC COMBINER_IRQ(22, 1)
#define IRQ_TIMER2_VIC COMBINER_IRQ(22, 2)
@@ -100,6 +103,7 @@
#define IRQ_IIC5 COMBINER_IRQ(27, 5)
#define IRQ_IIC6 COMBINER_IRQ(27, 6)
#define IRQ_IIC7 COMBINER_IRQ(27, 7)
+#define IRQ_IIC8 IRQ_HDMI_I2C
#define IRQ_HSMMC0 COMBINER_IRQ(29, 0)
#define IRQ_HSMMC1 COMBINER_IRQ(29, 1)
diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-
s5pv310/include/mach/map.h
index 576ba55..0aa0171 100644
--- a/arch/arm/mach-s5pv310/include/mach/map.h
+++ b/arch/arm/mach-s5pv310/include/mach/map.h
@@ -120,6 +120,7 @@
#define S3C_PA_IIC5 S5PV310_PA_IIC(5)
#define S3C_PA_IIC6 S5PV310_PA_IIC(6)
#define S3C_PA_IIC7 S5PV310_PA_IIC(7)
+#define S3C_PA_IIC8 S5PV310_PA_IIC(8)
#define S3C_PA_RTC S5PV310_PA_RTC
#define S3C_PA_WDT S5PV310_PA_WATCHDOG
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 32be05c..dd1fd15 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -211,6 +211,11 @@ config S3C_DEV_I2C7
help
Compile in platform device definition for I2C controller 7
+config S3C_DEV_I2C8
+ bool
+ help
+ Compile in platform device definitions for I2C channel 8 (HDMIPHY)
+
config S3C_DEV_FB
bool
help
diff --git a/arch/arm/plat-samsung/Makefile
b/arch/arm/plat-samsung/Makefile
index 7e92457..826ae4f 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_S3C_DEV_I2C4) += dev-i2c4.o
obj-$(CONFIG_S3C_DEV_I2C5) += dev-i2c5.o
obj-$(CONFIG_S3C_DEV_I2C6) += dev-i2c6.o
obj-$(CONFIG_S3C_DEV_I2C7) += dev-i2c7.o
+obj-$(CONFIG_S3C_DEV_I2C8) += dev-i2c8.o
obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o
obj-y += dev-uart.o
obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
diff --git a/arch/arm/plat-samsung/dev-i2c8.c b/arch/arm/plat-samsung/dev-
i2c8.c
new file mode 100644
index 000..8edba7f
--- /dev/null
+++ b/arch/arm/plat-samsung/dev-i2c8.c
@@ -0,0 +1,68 @@
+/* linux/arch/arm/plat-samsung/dev-i2c7.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * S3C series device definition for i2c device 8
+ *
+ * Based on plat-samsung/dev-i2c8.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/gfp.h
+#include linux/kernel.h
+#include linux/string.h
+#include linux/platform_device.h
+
+#include mach/irqs.h
+#include mach/map.h
+
+#include plat/regs-iic.h
+#include plat/iic.h
+#include plat/devs.h
+#include plat/cpu.h
+
+static struct resource s3c_i2c_resource[] = {
+ [0]
RE: [PATCH v2 0/6] HDMI driver for Samsung S5PV310 platform
Hi all, As I know, S5P-TV(HDMI) stuff needs more discussion. I don't want to just merge platform devices which is not used anywhere. Besides, there are two schemes for it in mailing list now. I think we have to improve this next time and need to focus more on its driver now. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Tomasz Stanislawski wrote: From: Marek Szyprowski m.szyprow...@samsung.com Hello, I would like to present the second version of HDMI driver for S5PC210 platform. The driver is under a heavy development. The most recent changes are: 1. Minor bugs and fixes: - pink line on left side of display - premature start of VP's streaming - usage of free memory - usage of non-initialized variables - fixed sequence of power setup - dependencies in Kconfig 2. Integration with Runtime Power Managment and Power Domain driver. 3. The CMA was substituted by the SYSMMU driver. 4. Applying existing frameworks: - activation of HDMIPHY using clock API - control of power on HDMI-5V pin using regulator API 5. Moving all clocks and regulator management from platform to the drivers' code. 6. Redesigned the control of mixer's debugging. 7. Added a watchdog to deal with HW failures. Original HDMI driver RFC: == Introduction == The purpose of this RFC is to discuss the driver for a TV output interface available in upcoming Samsung SoC. The HW is able to generate digital and analog signals. Current version of the driver supports only digital output. Internally the driver uses videobuf2 framework, and CMA memory allocator. Not all of them are merged by now, but I decided to post the sources to start discussion driver's design. == Hardware description == The SoC contains a few HW sub-blocks: 1. Video Processor (VP). It is used for processing of NV12 data. An image stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally, post processing operations like brightness, sharpness and contrast adjustments could be performed. The output in YCbCr444 format is send to Mixer. 2. Mixer (MXR). The piece of hardware responsible for mixing and blending multiple data inputs before passing it to an output device. The MXR is capable of handling up to three image layers. One is the output of VP. Other two are images in RGB format (multiple variants are supported). The layers are scaled, cropped and blended with background color. The blending factor, and layers' priority are controlled by MXR's registers. The output is passed either to HDMI or TVOUT. 3. HDMI. The piece of HW responsible for generation of HDMI packets. It takes pixel data from mixer and transforms it into data frames. The output is send to HDMIPHY interface. 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets to HDMI connector. Basically, it contains a PLL that produces source clock for Mixer, VP and HDMI during streaming. 5. TVOUT. Generation of TV analog signal. (driver not implemented) 6. VideoDAC. Modulator for TVOUT signal. (driver not implemented) The diagram below depicts connection between all HW pieces. +---+ NV12 data ---dma---| Video | | Processor | +---+ | V +---+ RGB data ---dma---| | | Mixer | RGB data ---dma---| | +---+ | * dmux / +-* *--+ || VV +---++---+ |HDMI || TVOUT | +---++---+ || VV +---++---+ | HDMIPHY || VideoDAC | +---++---+ || VV HDMI Composite connector connector == Driver interface == The posted driver implements three V4L2 nodes. Every video node implements V4L2 output buffer. One of nodes corresponds to input of Video Processor. The other two nodes correspond to RGB inputs of Mixer. All nodes share the same output. It is one of the Mixer's outputs: TVOUT or HDMI. Changing output in one layer using S_OUTPUT would change outputs of all other video nodes. The same thing happens if one try to reconfigure output i.e. by calling S_DV_PRESET. However it not possible to change or reconfigure the output
Re: [PATCH v2 0/6] HDMI driver for Samsung S5PV310 platform
On Wed, Mar 9, 2011 at 9:11 PM, Kukjin Kim kgene@samsung.com wrote: Hi all, As I know, S5P-TV(HDMI) stuff needs more discussion. I don't want to just merge platform devices which is not used anywhere. Besides, there are two schemes for it in mailing list now. It's different one, which scheme is used at multimedia, platform devices are same. I think we have to improve this next time and need to focus more on its driver now. As you said, arch supports the platform devices, we focus on only driver itself. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Tomasz Stanislawski wrote: From: Marek Szyprowski m.szyprow...@samsung.com Hello, I would like to present the second version of HDMI driver for S5PC210 platform. The driver is under a heavy development. The most recent changes are: 1. Minor bugs and fixes: - pink line on left side of display - premature start of VP's streaming - usage of free memory - usage of non-initialized variables - fixed sequence of power setup - dependencies in Kconfig 2. Integration with Runtime Power Managment and Power Domain driver. 3. The CMA was substituted by the SYSMMU driver. 4. Applying existing frameworks: - activation of HDMIPHY using clock API - control of power on HDMI-5V pin using regulator API 5. Moving all clocks and regulator management from platform to the drivers' code. 6. Redesigned the control of mixer's debugging. 7. Added a watchdog to deal with HW failures. Original HDMI driver RFC: == Introduction == The purpose of this RFC is to discuss the driver for a TV output interface available in upcoming Samsung SoC. The HW is able to generate digital and analog signals. Current version of the driver supports only digital output. Internally the driver uses videobuf2 framework, and CMA memory allocator. Not all of them are merged by now, but I decided to post the sources to start discussion driver's design. == Hardware description == The SoC contains a few HW sub-blocks: 1. Video Processor (VP). It is used for processing of NV12 data. An image stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally, post processing operations like brightness, sharpness and contrast adjustments could be performed. The output in YCbCr444 format is send to Mixer. 2. Mixer (MXR). The piece of hardware responsible for mixing and blending multiple data inputs before passing it to an output device. The MXR is capable of handling up to three image layers. One is the output of VP. Other two are images in RGB format (multiple variants are supported). The layers are scaled, cropped and blended with background color. The blending factor, and layers' priority are controlled by MXR's registers. The output is passed either to HDMI or TVOUT. 3. HDMI. The piece of HW responsible for generation of HDMI packets. It takes pixel data from mixer and transforms it into data frames. The output is send to HDMIPHY interface. 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets to HDMI connector. Basically, it contains a PLL that produces source clock for Mixer, VP and HDMI during streaming. 5. TVOUT. Generation of TV analog signal. (driver not implemented) 6. VideoDAC. Modulator for TVOUT signal. (driver not implemented) The diagram below depicts connection between all HW pieces. +---+ NV12 data ---dma---| Video | | Processor | +---+ | V +---+ RGB data ---dma---| | | Mixer | RGB data ---dma---| | +---+ | * dmux / +-* *--+ | | V V +---+ +---+ | HDMI | | TVOUT | +---+ +---+ | | V V +---+ +---+ | HDMIPHY | | VideoDAC | +---+ +---+ | | V V HDMI Composite connector connector == Driver interface == The posted driver implements three V4L2 nodes. Every video node implements V4L2 output buffer. One of nodes corresponds to input of Video Processor. The other two nodes correspond to RGB inputs of Mixer. All nodes share the same output. It is one of the Mixer's outputs: TVOUT or HDMI. Changing
[PATCHv2 0/3] hwmem: Hardware memory driver
Hello everyone, The following patchset implements a hardware memory driver. The main purpose of hwmem is: * To allocate buffers suitable for use with hardware. Currently this means contiguous buffers. * To synchronize the caches for the allocated buffers. This is achieved by keeping track of when the CPU uses a buffer and when other hardware uses the buffer, when we switch from CPU to other hardware or vice versa the caches are synchronized. * To handle sharing of allocated buffers between processes i.e. import, export. Hwmem is available both through a user space API and through a kernel API. Here at ST-Ericsson we use hwmem for graphics buffers. Graphics buffers need to be contiguous due to our hardware, are passed between processes (usually application and window manager)and are part of usecases where performance is top priority so we can't afford to synchronize the caches unecessarily. Additions in v2: * Bugfixes * Added the possibility to map hwmem buffers in the kernel through hwmem_kmap/kunmap * Moved mach specific stuff to mach. Best regards Johan Mossberg Consultant at ST-Ericsson Johan Mossberg (3): hwmem: Add hwmem (part 1) hwmem: Add hwmem (part 2) hwmem: Add hwmem to ux500 arch/arm/mach-ux500/Makefile |2 +- arch/arm/mach-ux500/board-mop500.c |1 + arch/arm/mach-ux500/dcache.c | 266 + arch/arm/mach-ux500/devices.c | 31 ++ arch/arm/mach-ux500/include/mach/dcache.h | 26 + arch/arm/mach-ux500/include/mach/devices.h |1 + drivers/misc/Kconfig |1 + drivers/misc/Makefile |1 + drivers/misc/hwmem/Kconfig |7 + drivers/misc/hwmem/Makefile|3 + drivers/misc/hwmem/cache_handler.c | 510 ++ drivers/misc/hwmem/cache_handler.h | 61 +++ drivers/misc/hwmem/hwmem-ioctl.c | 455 drivers/misc/hwmem/hwmem-main.c| 799 include/linux/hwmem.h | 536 +++ 15 files changed, 2699 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-ux500/dcache.c create mode 100644 arch/arm/mach-ux500/include/mach/dcache.h create mode 100644 drivers/misc/hwmem/Kconfig create mode 100644 drivers/misc/hwmem/Makefile create mode 100644 drivers/misc/hwmem/cache_handler.c create mode 100644 drivers/misc/hwmem/cache_handler.h create mode 100644 drivers/misc/hwmem/hwmem-ioctl.c create mode 100644 drivers/misc/hwmem/hwmem-main.c create mode 100644 include/linux/hwmem.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] hwmem: Add hwmem (part 1)
Add hardware memory driver, part 1.
The main purpose of hwmem is:
* To allocate buffers suitable for use with hardware. Currently
this means contiguous buffers.
* To synchronize the caches for the allocated buffers. This is
achieved by keeping track of when the CPU uses a buffer and when
other hardware uses the buffer, when we switch from CPU to other
hardware or vice versa the caches are synchronized.
* To handle sharing of allocated buffers between processes i.e.
import, export.
Hwmem is available both through a user space API and through a
kernel API.
Signed-off-by: Johan Mossberg johan.xx.mossb...@stericsson.com
---
drivers/misc/Kconfig |1 +
drivers/misc/Makefile|1 +
drivers/misc/hwmem/Kconfig |7 +
drivers/misc/hwmem/Makefile |3 +
drivers/misc/hwmem/hwmem-ioctl.c | 455 ++
drivers/misc/hwmem/hwmem-main.c | 799 ++
include/linux/hwmem.h| 536 +
7 files changed, 1802 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/hwmem/Kconfig
create mode 100644 drivers/misc/hwmem/Makefile
create mode 100644 drivers/misc/hwmem/hwmem-ioctl.c
create mode 100644 drivers/misc/hwmem/hwmem-main.c
create mode 100644 include/linux/hwmem.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index cc8e49d..6d83fb8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -457,5 +457,6 @@ source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
source drivers/misc/iwmc3200top/Kconfig
source drivers/misc/ti-st/Kconfig
+source drivers/misc/hwmem/Kconfig
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 98009cc..698b4f6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_PCH_PHUB) += pch_phub.o
obj-y += ti-st/
obj-$(CONFIG_AB8500_PWM) += ab8500-pwm.o
+obj-$(CONFIG_HWMEM)+= hwmem/
diff --git a/drivers/misc/hwmem/Kconfig b/drivers/misc/hwmem/Kconfig
new file mode 100644
index 000..c161875
--- /dev/null
+++ b/drivers/misc/hwmem/Kconfig
@@ -0,0 +1,7 @@
+config HWMEM
+ bool Hardware memory driver
+ default n
+ help
+ This driver provides a way to allocate memory suitable for use with
+ both CPU and non-CPU hardware, handles the caches for allocated
+ memory and enables inter-process sharing of allocated memory.
diff --git a/drivers/misc/hwmem/Makefile b/drivers/misc/hwmem/Makefile
new file mode 100644
index 000..18da2ad
--- /dev/null
+++ b/drivers/misc/hwmem/Makefile
@@ -0,0 +1,3 @@
+hwmem-objs := hwmem-main.o hwmem-ioctl.o cache_handler.o
+
+obj-$(CONFIG_HWMEM) += hwmem.o
diff --git a/drivers/misc/hwmem/hwmem-ioctl.c b/drivers/misc/hwmem/hwmem-ioctl.c
new file mode 100644
index 000..69a15a6
--- /dev/null
+++ b/drivers/misc/hwmem/hwmem-ioctl.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * Hardware memory driver, hwmem
+ *
+ * Author: Marcus Lorentzon marcus.xm.lorent...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/idr.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/miscdevice.h
+#include linux/uaccess.h
+#include linux/mm_types.h
+#include linux/hwmem.h
+#include linux/device.h
+#include linux/sched.h
+
+static int hwmem_open(struct inode *inode, struct file *file);
+static int hwmem_ioctl_mmap(struct file *file, struct vm_area_struct *vma);
+static int hwmem_release_fop(struct inode *inode, struct file *file);
+static long hwmem_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg);
+static unsigned long hwmem_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags);
+
+static const struct file_operations hwmem_fops = {
+ .open = hwmem_open,
+ .mmap = hwmem_ioctl_mmap,
+ .unlocked_ioctl = hwmem_ioctl,
+ .release = hwmem_release_fop,
+ .get_unmapped_area = hwmem_get_unmapped_area,
+};
+
+static struct miscdevice hwmem_device = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = hwmem,
+ .fops = hwmem_fops,
+};
+
+struct hwmem_file {
+ struct mutex lock;
+ struct idr idr; /* id - struct hwmem_alloc*, ref counted */
+ struct hwmem_alloc *fd_alloc; /* Ref counted */
+};
+
+static s32 create_id(struct hwmem_file *hwfile, struct hwmem_alloc *alloc)
+{
+ int id, ret;
+
+ while (true) {
+ if (idr_pre_get(hwfile-idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ ret = idr_get_new_above(hwfile-idr, alloc, 1, id);
+ if (ret == 0)
+ break;
+ else if (ret != -EAGAIN)
+ return -ENOMEM;
[PATCHv2 3/3] hwmem: Add hwmem to ux500
Signed-off-by: Johan Mossberg johan.xx.mossb...@stericsson.com
---
arch/arm/mach-ux500/Makefile |2 +-
arch/arm/mach-ux500/board-mop500.c |1 +
arch/arm/mach-ux500/dcache.c | 266
arch/arm/mach-ux500/devices.c | 31
arch/arm/mach-ux500/include/mach/dcache.h | 26 +++
arch/arm/mach-ux500/include/mach/devices.h |1 +
6 files changed, 326 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-ux500/dcache.c
create mode 100644 arch/arm/mach-ux500/include/mach/dcache.h
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index b549a8f..b8f02aa 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -3,7 +3,7 @@
#
obj-y := clock.o cpu.o devices.o devices-common.o \
- id.o usb.o
+ id.o usb.o dcache.o
obj-$(CONFIG_UX500_SOC_DB5500) += cpu-db5500.o dma-db5500.o
obj-$(CONFIG_UX500_SOC_DB8500) += cpu-db8500.o devices-db8500.o prcmu.o
obj-$(CONFIG_MACH_U8500) += board-mop500.o board-mop500-sdi.o \
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 648da5a..3003b65 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -248,6 +248,7 @@ static void mop500_prox_deactivate(struct device *dev)
/* add any platform devices here - TODO */
static struct platform_device *platform_devs[] __initdata = {
mop500_gpio_keys_device,
+ ux500_hwmem_device,
};
#ifdef CONFIG_STE_DMA40
diff --git a/arch/arm/mach-ux500/dcache.c b/arch/arm/mach-ux500/dcache.c
new file mode 100644
index 000..314e78b
--- /dev/null
+++ b/arch/arm/mach-ux500/dcache.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2011
+ *
+ * Cache handler integration and data cache helpers.
+ *
+ * Author: Johan Mossberg johan.xx.mossb...@stericsson.com
+ * for ST-Ericsson.
+ *
+ * License terms: GNU General Public License (GPL), version 2.
+ */
+
+#include linux/hwmem.h
+#include linux/dma-mapping.h
+
+#include asm/pgtable.h
+#include asm/cacheflush.h
+#include asm/outercache.h
+#include asm/system.h
+
+/*
+ * Values are derived from measurements on HREFP_1.1_V32_OM_S10 running
+ * u8500-android-2.2_r1.1_v0.21.
+ *
+ * A lot of time can be spent trying to figure out the perfect breakpoints but
+ * for now I've chosen the following simple way.
+ *
+ * breakpoint = best_case + (worst_case - best_case) * 0.666
+ * The breakpoint is moved slightly towards the worst case because a full
+ * clean/flush affects the entire system so we should be a bit careful.
+ *
+ * BEST CASE:
+ * Best case is that the cache is empty and the system is idling. The case
+ * where the cache contains only targeted data could be better in some cases
+ * but it's hard to do measurements and calculate on that case so I choose the
+ * easier alternative.
+ *
+ * outer_clean_breakpoint = time_2_range_clean_on_empty_cache(
+ * complete_clean_on_empty_cache_time)
+ * outer_flush_breakpoint = time_2_range_flush_on_empty_cache(
+ * complete_flush_on_empty_cache_time)
+ *
+ * WORST CASE:
+ * Worst case is that the cache is filled with dirty non targeted data that
+ * will be used after the synchronization and the system is under heavy load.
+ *
+ * outer_clean_breakpoint = time_2_range_clean_on_empty_cache(
+ * complete_clean_on_full_cache_time +
+ * (complete_clean_on_full_cache_time -
+ * complete_clean_on_empty_cache_time))
+ * Plus (complete_flush_on_full_cache_time -
+ * complete_flush_on_empty_cache_time) because no one else can work when we
+ * hog the bus with our unecessary transfer.
+ * outer_flush_breakpoint = time_2_range_flush_on_empty_cache(
+ * complete_flush_on_full_cache_time * 2 +
+ * (complete_flush_on_full_cache_time -
+ * complete_flush_on_empty_cache_time) * 2)
+ *
+ * These values might have to be updated if changes are made to the CPU, L2$,
+ * memory bus or memory.
+ */
+/* 254069 */
+static const u32 outer_clean_breakpoint = 68041 + (347363 - 68041) * 0.666;
+/* 485414 */
+static const u32 outer_flush_breakpoint = 68041 + (694727 - 68041) * 0.666;
+
+static bool is_cache_exclusive(void);
+
+enum hwmem_alloc_flags cachi_get_cache_settings(
+ enum hwmem_alloc_flags requested_cache_settings)
+{
+ static const u32 CACHE_ON_FLAGS_MASK = HWMEM_ALLOC_HINT_CACHED |
+ HWMEM_ALLOC_HINT_CACHE_WB | HWMEM_ALLOC_HINT_CACHE_WT |
+ HWMEM_ALLOC_HINT_CACHE_NAOW | HWMEM_ALLOC_HINT_CACHE_AOW |
+ HWMEM_ALLOC_HINT_INNER_AND_OUTER_CACHE |
+
[PATCH 0/1] Add videobuf2 DMA pool allocator
Hello! The DMA pool allocator allocates a memory using dma_alloc_coherent(), creates a pool using generic allocator in the initialization. For every allocation requests, the allocator returns a part of its memory pool using generic allocator instead of new memory allocation. This allocator used for devices have below limitations. - the start address should be aligned - the range of memory access limited to the offset from the start address (= the allocation address should be existed in a constant offset from the start address) - the allocation address should be aligned * This patch is same previous sent one. But, It is based on git://linuxtv.org/media_tree.git tree, staging/for_v2.6.39 branch I would be grateful for your comments. This patch series contains: [PATCH 1/1] v4l: videobuf2: Add DMA pool allocator Best regards, Jeongtae Park Patch summary: Jeongtae Park (1): v4l: videobuf2: Add DMA pool allocator drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/videobuf2-dma-pool.c | 310 ++ include/media/videobuf2-dma-pool.h | 37 4 files changed, 355 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/videobuf2-dma-pool.c create mode 100644 include/media/videobuf2-dma-pool.hHello! The DMA pool allocator allocates a memory using dma_alloc_coherent(), creates a pool using generic allocator in the initialization. For every allocation requests, the allocator returns a part of its memory pool using generic allocator instead of new memory allocation. This allocator used for devices have below limitations. - the start address should be aligned - the range of memory access limited to the offset from the start address (= the allocation address should be existed in a constant offset from the start address) - the allocation address should be aligned * This patch is same previous sent one. But, It is based on git://linuxtv.org/media_tree.git tree, staging/for_v2.6.39 branch I would be grateful for your comments. This patch series contains: [PATCH 1/1] v4l: videobuf2: Add DMA pool allocator Best regards, Jeongtae Park Patch summary: Jeongtae Park (1): v4l: videobuf2: Add DMA pool allocator drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/videobuf2-dma-pool.c | 310 ++ include/media/videobuf2-dma-pool.h | 37 4 files changed, 355 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/videobuf2-dma-pool.c create mode 100644 include/media/videobuf2-dma-pool.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
[PATCH 1/1] v4l: videobuf2: Add DMA pool allocator
Add an implementation of DMA pool memory allocator and handling
routines for videobuf2. The DMA pool allocator allocates a memory
using dma_alloc_coherent(), creates a pool using generic allocator
in the initialization. For every allocation requests, the allocator
returns a part of its memory pool using generic allocator instead
of new memory allocation.
This allocator used for devices have below limitations.
- the start address should be aligned
- the range of memory access limited to the offset from the start
address (= the allocation address should be existed in a
constant offset from the start address)
- the allocation address should be aligned
Reviewed-by: Jonghun Han jonghun@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
This allocator used for s5p-mfc. s5p-mfc has above limitations.
The CMA and CMA allocator for videobuf2 can be resolve all of
described limitations, but the CMA merge schedule is not fixed yet.
Therefore CMA allocator for videobuf2 also cannot be used in the
driver currently. The s5p-mfc v4l2 driver can be validated with
the DMA pool allocator without CMA dependency.
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-dma-pool.c | 310 ++
include/media/videobuf2-dma-pool.h | 37
4 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-dma-pool.c
create mode 100644 include/media/videobuf2-dma-pool.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index e2f5a69..986019f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -66,6 +66,13 @@ config VIDEOBUF2_DMA_SG
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
tristate
+
+config VIDEOBUF2_DMA_POOL
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ select GENERIC_ALLOCATOR
+ tristate
+
#
# Multimedia Video device configuration
#
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ac54652..12fca52 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) +=
videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DMA_POOL) += videobuf2-dma-pool.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
diff --git a/drivers/media/video/videobuf2-dma-pool.c
b/drivers/media/video/videobuf2-dma-pool.c
new file mode 100644
index 000..59f4cba
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-pool.c
@@ -0,0 +1,310 @@
+/*
+ * videobuf2-dma-pool.c - DMA pool memory allocator for videobuf2
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * 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/slab.h
+#include linux/dma-mapping.h
+#include linux/genalloc.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+#define DMA_POOL_MAGIC 0x706F6F6C
+#define MAGIC_CHECK(is, should)\
+ if (unlikely((is) != (should))) { \
+ pr_err(magic mismatch: %x (expected %x)\n,\
+ (is), (should));\
+ BUG(); \
+ }
+
+static int debug;
+module_param(debug, int, 0644);
+
+#define dprintk(level, fmt, arg...)\
+ do {\
+ if (debug = level) \
+ printk(KERN_DEBUG vb2_dp: fmt, ## arg); \
+ } while (0)
+
+struct vb2_dma_pool_conf {
+ struct device *dev;
+ struct gen_pool *pool;
+ dma_addr_t paddr;
+ void*vaddr;
+ unsigned long size;
+ u32 magic;
+};
+
+struct vb2_dma_pool_buf {
+ struct vb2_dma_pool_conf*conf;
+ void*vaddr;
+ dma_addr_t paddr;
+ unsigned long size;
+ struct vm_area_struct *vma;
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_pool_put(void *buf_priv);
+
+static void *vb2_dma_pool_alloc(void
[PATCH v2 8/8] ARM: S5PV310: Add MFC v5.1 platform device support for SMDKV310
This patch adds MFC v5.1 platform device support for SMDKV310.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
arch/arm/mach-s5pv310/Kconfig |1 +
arch/arm/mach-s5pv310/mach-smdkv310.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index c87d7b4..ec39785 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -125,6 +125,7 @@ config MACH_SMDKV310
select S5PV310_DEV_PD
select S5PV310_SETUP_I2C1
select S5PV310_SETUP_SDHCI
+ select S5P_DEV_MFC
help
Machine support for Samsung SMDKV310
diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.c
b/arch/arm/mach-s5pv310/mach-smdkv310.c
index b1cddbf..bc7dfd4 100644
--- a/arch/arm/mach-s5pv310/mach-smdkv310.c
+++ b/arch/arm/mach-s5pv310/mach-smdkv310.c
@@ -166,6 +166,9 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
s5pv310_device_sysmmu,
samsung_asoc_dma,
smdkv310_smsc911x,
+#ifdef CONFIG_VIDEO_SAMSUNG_S5P_MFC
+ s5p_device_mfc,
+#endif
};
static void __init smdkv310_smsc911x_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] ARM: S5PV310: Add MFC v5.1 platform device support for SMDKC210
This patch adds MFC v5.1 platform device support for SMDKC210.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
arch/arm/mach-s5pv310/Kconfig |1 +
arch/arm/mach-s5pv310/mach-smdkc210.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 09c4c21..c87d7b4 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -89,6 +89,7 @@ config MACH_SMDKC210
select S5PV310_SETUP_I2C1
select S5PV310_SETUP_SDHCI
select S5PV310_DEV_SYSMMU
+ select S5P_DEV_MFC
help
Machine support for Samsung SMDKC210
S5PC210(MCP) is one of package option of S5PV310
diff --git a/arch/arm/mach-s5pv310/mach-smdkc210.c
b/arch/arm/mach-s5pv310/mach-smdkc210.c
index d9cab02..86bd10d 100644
--- a/arch/arm/mach-s5pv310/mach-smdkc210.c
+++ b/arch/arm/mach-s5pv310/mach-smdkc210.c
@@ -166,6 +166,9 @@ static struct platform_device *smdkc210_devices[]
__initdata = {
s5pv310_device_sysmmu,
samsung_asoc_dma,
smdkc210_smsc911x,
+#ifdef CONFIG_VIDEO_SAMSUNG_S5P_MFC
+ s5p_device_mfc,
+#endif
};
static void __init smdkc210_smsc911x_init(void)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/8] ARM: S5PV310: Add memory map support for MFC v5.1
This patch adds memroy map support for MFC v5.1. Reviewed-by: Peter Oh jaeryul...@samsung.com Signed-off-by: Jeongtae Park jtp.p...@samsung.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Kamil Debski k.deb...@samsung.com --- arch/arm/mach-s5pv310/include/mach/map.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-s5pv310/include/mach/map.h index 74d4006..fa7866a 100644 --- a/arch/arm/mach-s5pv310/include/mach/map.h +++ b/arch/arm/mach-s5pv310/include/mach/map.h @@ -73,6 +73,8 @@ #define S5PV310_PA_SROMC (0x1257) #define S5P_PA_SROMC S5PV310_PA_SROMC +#define S5PV310_PA_MFC 0x1340 + /* S/PDIF */ #define S5PV310_PA_SPDIF 0xE110 @@ -145,5 +147,6 @@ #define S3C_PA_WDT S5PV310_PA_WATCHDOG #define S5P_PA_MIPI_CSIS0 S5PV310_PA_MIPI_CSIS0 #define S5P_PA_MIPI_CSIS1 S5PV310_PA_MIPI_CSIS1 +#define S5P_PA_MFC S5PV310_PA_MFC #endif /* __ASM_ARCH_MAP_H */ -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] ARM: S5PV310: Add 'CONSISTENT_DMA_SIZE' definition for DMA pool allocator
This patch adds 'CONSISTENT_DMA_SIZE' definition for DMA pool allocator. Reviewed-by: Peter Oh jaeryul...@samsung.com Signed-off-by: Jeongtae Park jtp.p...@samsung.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Kamil Debski k.deb...@samsung.com --- arch/arm/mach-s5pv310/include/mach/memory.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv310/include/mach/memory.h b/arch/arm/mach-s5pv310/include/mach/memory.h index 1dffb48..f026870 100644 --- a/arch/arm/mach-s5pv310/include/mach/memory.h +++ b/arch/arm/mach-s5pv310/include/mach/memory.h @@ -14,6 +14,7 @@ #define __ASM_ARCH_MEMORY_H __FILE__ #define PHYS_OFFSETUL(0x4000) +#define CONSISTENT_DMA_SIZE(SZ_8M) /* Maximum of 256MiB in one bank */ #define MAX_PHYSMEM_BITS 32 -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] MFC 5.1 driver for S5PV310 (+encoder)
Hello, This patch series is the sencond version of the MFC 5.1 driver based on Kmail's nice work (Version 6). All of Kmail's features not incldue yet, but I hope it will be merge for few months with co-work. Current driver support H.264, H.263, MPEG4 encoding and use DMA pool allocator. I tried to use V4L2 control framework but some contorls of MFC need to handle per-buffer level. I will make-up some ideas for it soon. Most contents of cover letter are same previous Kamil's submmition. I just added encoding related items to the original one. I would be grateful for your comments. Original cover letter has been attached below. This patch series contains: [PATCH v2 1/8] media: Changes in include/linux/videodev2.h for MFC 5.1 [PATCH v2 2/8] ARM: S5PV310: Add clock support for MFC v5.1 [PATCH v2 3/8] ARM: S5PV310: Add memory map support for MFC v5.1 [PATCH v2 4/8] ARM: S5P: Add platform support for MFC v5.1 [PATCH v2 5/8] ARM: S5PV310: Add 'CONSISTENT_DMA_SIZE' definition for DMA pool allocator [PATCH v2 6/8] media: MFC: Add MFC v5.1 V4L2 driver [PATCH v2 7/8] ARM: S5PV310: Add MFC v5.1 platform device support for SMDKC210 [PATCH v2 8/8] ARM: S5PV310: Add MFC v5.1 platform device support for SMDKV310 Best regards, Jeongtae Park * Changelog: == Changes since v1 == 1) Heavily re-organized to devide decoder and encoder. 2) Support videobuf2 DMA-Pool allocator. 3) Support H.263, MPEG4 encoding. 4) Support B-Frame encoding. 4) Add per-buffer contorl handling. * Original cover letter: == Introduction == The purpose of this RFC is to discuss the driver for a hw video codec embedded in the new Samusng's SoCs. Multi Format Codec 5.1 is able to handle video decoding and encoding of in a range of formats. So far no hardware codec was supported in V4L2 and this would be the first one. I guess there are more similar device that would benefit from a V4L2 unified interface. I suggest a separate control class for codec devices - V4L2_CTRL_CLASS_CODEC. Internally the driver uses videobuf2 framework and CMA memory allocator. I am aware that those have not yet been merged, but I wanted to start discussion about the driver earlier so it could be merged sooner. The driver posted here is the initial version, so I suppose it will require more work. == Device interface == The driver principle is based on the idea of memory-to-memory devices: it provides two video nodes (decoder and encoder) and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. encoded video frames for decoder) and CAPTURE (for destination buffers, i.e. decoded raw video frames for decoder). The process of decoding video data from stream is a bit more complicated than typical memory-to-memory processing, that's why the m2m framework is not directly used (it is too limited for this case). The main reason for this is the fact that the CAPTURE buffers can be dequeued in a different order than they queued. The hw block decides which buffer has been completely processed. This is due to the structure of most compressed video streams - use of B frames causes that decoding and display order may be different. == Decoding initialization path == First the OUTPUT queue is initialized. With S_FMT the application chooses which video format to decode and what size should be the input buffer. Fourcc values have been defined for different codecs e.g. V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and mmaped. The stream header frame is loaded into the first buffer, queued and streaming is enabled. At this point the hardware is able to start processing the stream header and afterwards it will have information about the video dimensions and the size of the buffers with raw video data. The next step is setting up the CAPTURE queue and buffers. The width, height, buffer size and minimum number of buffers can be read with G_FMT call. The application can request more output buffer if necessary. After requesting and mmaping buffers the device is ready to decode video stream. The stream frames (ES frames) are written to the OUTPUT buffers, and decoded video frames can be read from the CAPTURE buffers. When no more source frames are present a single buffer with bytesused set to 0 should be queued. This will inform the driver that processing should be finished and it can dequeue all video frames that are still left. The number of such frames is dependent on the stream and its internal structure (how many frames had to be kept as reference frames for decoding, etc). == Encoding initialization path == First the encoding parameters should be set with S_EXT_CTRLS ioctl. Some paramters can be specific for codec type. Next, the CAPTURE queue is
[PATCH v2 4/8] ARM: S5P: Add platform support for MFC v5.1
Add platform support for MFC v5.1 is a module available
on S5PC110 and S5PC210 Samsung SoCs.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
arch/arm/plat-s5p/Kconfig |5 +++
arch/arm/plat-s5p/Makefile|1 +
arch/arm/plat-s5p/dev-mfc.c | 46 +
arch/arm/plat-samsung/include/plat/devs.h |2 +
4 files changed, 54 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-s5p/dev-mfc.c
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index deb3995..601b5b0 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -52,6 +52,11 @@ config S5P_DEV_FIMC2
help
Compile in platform device definitions for FIMC controller 2
+config S5P_DEV_MFC
+ bool
+ help
+ Compile in platform device definitions for MFC
+
config S5P_DEV_ONENAND
bool
help
diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
index 92efe1a..3577f2a 100644
--- a/arch/arm/plat-s5p/Makefile
+++ b/arch/arm/plat-s5p/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PM) += irq-pm.o
obj-$(CONFIG_S5P_DEV_FIMC0)+= dev-fimc0.o
obj-$(CONFIG_S5P_DEV_FIMC1)+= dev-fimc1.o
obj-$(CONFIG_S5P_DEV_FIMC2)+= dev-fimc2.o
+obj-$(CONFIG_S5P_DEV_MFC) += dev-mfc.o
obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o
obj-$(CONFIG_S5P_DEV_CSIS0)+= dev-csis0.o
obj-$(CONFIG_S5P_DEV_CSIS1)+= dev-csis1.o
diff --git a/arch/arm/plat-s5p/dev-mfc.c b/arch/arm/plat-s5p/dev-mfc.c
new file mode 100644
index 000..67afdae
--- /dev/null
+++ b/arch/arm/plat-s5p/dev-mfc.c
@@ -0,0 +1,46 @@
+/* linux/arch/arm/plat-s5p/dev-mfc.c
+ *
+ * Copyright (c) 2010 Samsung Electronics
+ *
+ * Base S5P MFC resource and device definitions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/ioport.h
+#include linux/dma-mapping.h
+
+#include mach/map.h
+#include plat/devs.h
+#include plat/irqs.h
+
+static struct resource s5p_mfc_resource[] = {
+ [0] = {
+ .start = S5P_PA_MFC,
+ .end= S5P_PA_MFC + SZ_64K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_MFC,
+ .end= IRQ_MFC,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static u64 s5p_mfc_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device s5p_device_mfc = {
+ .name = s5p-mfc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(s5p_mfc_resource),
+ .resource = s5p_mfc_resource,
+ .dev= {
+ .dma_mask = s5p_mfc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
diff --git a/arch/arm/plat-samsung/include/plat/devs.h
b/arch/arm/plat-samsung/include/plat/devs.h
index b4d208b..f3ca8db 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -134,6 +134,8 @@ extern struct platform_device s5p_device_fimc0;
extern struct platform_device s5p_device_fimc1;
extern struct platform_device s5p_device_fimc2;
+extern struct platform_device s5p_device_mfc;
+
extern struct platform_device s5p_device_mipi_csis0;
extern struct platform_device s5p_device_mipi_csis1;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] ARM: S5PV310: Add clock support for MFC v5.1
This patch adds clock support for MFC v5.1.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
arch/arm/mach-s5pv310/clock.c | 68 +++
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index fc7c2f8..88c7943 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -86,6 +86,11 @@ static int s5pv310_clk_ip_cam_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_CAM, clk, enable);
}
+static int s5pv310_clk_ip_mfc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
+}
+
static int s5pv310_clk_ip_image_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_CLKGATE_IP_IMAGE, clk, enable);
@@ -417,6 +422,11 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_cam_ctrl,
.ctrlbit= (1 2),
}, {
+ .name = mfc,
+ .id = -1,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= (1 0),
+ }, {
.name = fimc,
.id = 3,
.enable = s5pv310_clk_ip_cam_ctrl,
@@ -643,6 +653,54 @@ static struct clksrc_sources clkset_group = {
.nr_sources = ARRAY_SIZE(clkset_group_list),
};
+static struct clk *clkset_mout_mfc0_list[] = {
+ [0] = clk_mout_mpll.clk,
+ [1] = clk_sclk_apll.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc0 = {
+ .sources= clkset_mout_mfc0_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc0_list),
+};
+
+static struct clksrc_clk clk_mout_mfc0 = {
+ .clk= {
+ .name = mout_mfc0,
+ .id = -1,
+ },
+ .sources= clkset_mout_mfc0,
+ .reg_src= { .reg = S5P_CLKSRC_MFC, .shift = 0, .size = 1 },
+};
+
+static struct clk *clkset_mout_mfc1_list[] = {
+ [0] = clk_mout_epll.clk,
+ [1] = clk_sclk_vpll.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc1 = {
+ .sources= clkset_mout_mfc1_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc1_list),
+};
+
+static struct clksrc_clk clk_mout_mfc1 = {
+ .clk= {
+ .name = mout_mfc1,
+ .id = -1,
+ },
+ .sources= clkset_mout_mfc1,
+ .reg_src= { .reg = S5P_CLKSRC_MFC, .shift = 4, .size = 1 },
+};
+
+static struct clk *clkset_mout_mfc_list[] = {
+ [0] = clk_mout_mfc0.clk,
+ [1] = clk_mout_mfc1.clk,
+};
+
+static struct clksrc_sources clkset_mout_mfc = {
+ .sources= clkset_mout_mfc_list,
+ .nr_sources = ARRAY_SIZE(clkset_mout_mfc_list),
+};
+
static struct clk *clkset_mout_g2d0_list[] = {
[0] = clk_mout_mpll.clk,
[1] = clk_sclk_apll.clk,
@@ -814,6 +872,14 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_CAM, .shift = 28, .size = 4 },
}, {
.clk= {
+ .name = sclk_mfc,
+ .id = -1,
+ },
+ .sources = clkset_mout_mfc,
+ .reg_src = { .reg = S5P_CLKSRC_MFC, .shift = 8, .size = 1 },
+ .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
+ }, {
+ .clk= {
.name = sclk_cam,
.id = 0,
.enable = s5pv310_clksrc_mask_cam_ctrl,
@@ -1018,6 +1084,8 @@ static struct clksrc_clk *sysclks[] = {
clk_dout_mmc2,
clk_dout_mmc3,
clk_dout_mmc4,
+ clk_mout_mfc0,
+ clk_mout_mfc1,
};
static int xtal_rate;
diff --git a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
index b5c4ada..27b02e8 100644
--- a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
@@ -33,6 +33,7 @@
#define S5P_CLKSRC_TOP0S5P_CLKREG(0x0C210)
#define S5P_CLKSRC_TOP1S5P_CLKREG(0x0C214)
#define S5P_CLKSRC_CAM S5P_CLKREG(0x0C220)
+#define S5P_CLKSRC_MFC S5P_CLKREG(0x0C228)
#define S5P_CLKSRC_IMAGE S5P_CLKREG(0x0C230)
#define S5P_CLKSRC_LCD0S5P_CLKREG(0x0C234)
#define S5P_CLKSRC_LCD1S5P_CLKREG(0x0C238)
@@ -42,6 +43,7 @@
#define S5P_CLKDIV_TOP S5P_CLKREG(0x0C510)
#define S5P_CLKDIV_CAM S5P_CLKREG(0x0C520)
+#define S5P_CLKDIV_MFC
[PATCH v2 1/8] media: Changes in include/linux/videodev2.h for MFC 5.1
Add V4L2_CTRL_CLASS_CODEC and adds controls used by MFC 5.1 driver
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
include/linux/videodev2.h | 158 +
1 files changed, 158 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..37ed969 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -369,6 +369,19 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
*/
+#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264
*/
+#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263
*/
+#define V4L2_PIX_FMT_MPEG12 v4l2_fourcc('M', 'P', '1', '2') /* MPEG-1/2
*/
+#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /* MPEG-4
*/
+#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /* DivX
*/
+#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /* DivX 3.11
*/
+#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /* DivX 4.x
*/
+#define V4L2_PIX_FMT_DIVX500 v4l2_fourcc('D', 'X', '5', '2') /* DivX 5.0,
5.01, 5.02 */
+#define V4L2_PIX_FMT_DIVX503 v4l2_fourcc('D', 'X', '5', '3') /* DivX 5.03 ~
*/
+#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* XviD
*/
+#define V4L2_PIX_FMT_VC1 v4l2_fourcc('V', 'C', '1', 'A') /* VC-1
*/
+#define V4L2_PIX_FMT_VC1_RCV v4l2_fourcc('V', 'C', '1', 'R') /* VC-1 RCV
*/
+
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
#define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw
compress */
@@ -1016,6 +1029,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_CODEC 0x009c /* Codec control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1349,6 +1363,150 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type {
#define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP
(V4L2_CID_MPEG_CX2341X_BASE+10)
#define V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS
(V4L2_CID_MPEG_CX2341X_BASE+11)
+/* Codec class control IDs */
+#define V4L2_CID_CODEC_BASE(V4L2_CTRL_CLASS_CODEC | 0x900)
+#define V4L2_CID_CODEC_CLASS (V4L2_CTRL_CLASS_CODEC | 1)
+
+/* For both decoding and encoding */
+#define V4L2_CID_CODEC_LOOP_FILTER_H264(V4L2_CID_CODEC_BASE+0)
+enum v4l2_cid_codec_loop_filter_h264 {
+ V4L2_CID_CODEC_LOOP_FILTER_H264_ENABLE = 0,
+ V4L2_CID_CODEC_LOOP_FILTER_H264_DISABLE = 1,
+ V4L2_CID_CODEC_LOOP_FILTER_H264_DISABLE_AT_BOUNDARY = 2,
+};
+
+/* For decoding */
+#define V4L2_CID_CODEC_LOOP_FILTER_MPEG4_ENABLE
(V4L2_CID_CODEC_BASE+100)
+#define V4L2_CID_CODEC_DISPLAY_DELAY (V4L2_CID_CODEC_BASE+101)
+#define V4L2_CID_CODEC_REQ_NUM_BUFS(V4L2_CID_CODEC_BASE+102)
+#define V4L2_CID_CODEC_SLICE_INTERFACE (V4L2_CID_CODEC_BASE+103)
+#define V4L2_CID_CODEC_PACKED_PB (V4L2_CID_CODEC_BASE+104)
+#define V4L2_CID_CODEC_FRAME_TAG (V4L2_CID_CODEC_BASE+105)
+
+/* For encoding */
+/* common */
+enum v4l2_codec_switch {
+ V4L2_CODEC_SW_DISABLE = 0,
+ V4L2_CODEC_SW_ENABLE= 1,
+};
+enum v4l2_codec_switch_inv {
+ V4L2_CODEC_SW_INV_ENABLE= 0,
+ V4L2_CODEC_SW_INV_DISABLE = 1,
+};
+#define V4L2_CID_CODEC_GOP_SIZE
(V4L2_CID_CODEC_BASE+200)
+#define V4L2_CID_CODEC_MULTI_SLICE_MODE
(V4L2_CID_CODEC_BASE+201)
+enum v4l2_codec_multi_slice_mode {
+ V4L2_CODEC_MULTI_SLICE_MODE_DISABLE = 0,
+ V4L2_CODEC_MULTI_SLICE_MODE_MACROBLOCK_COUNT= 1,
+ V4L2_CODEC_MULTI_SLICE_MODE_BIT_COUNT = 3,
+};
+#define V4L2_CID_CODEC_MULTI_SLICE_MB (V4L2_CID_CODEC_BASE+202)
+#define V4L2_CID_CODEC_MULTI_SLICE_BIT (V4L2_CID_CODEC_BASE+203)
+#define V4L2_CID_CODEC_INTRA_REFRESH_MB
(V4L2_CID_CODEC_BASE+204)
+#define V4L2_CID_CODEC_PAD_CTRL_ENABLE (V4L2_CID_CODEC_BASE+205)
+#define V4L2_CID_CODEC_PAD_LUMA_VALUE (V4L2_CID_CODEC_BASE+206)
+#define V4L2_CID_CODEC_PAD_CB_VALUE(V4L2_CID_CODEC_BASE+207)
+#define V4L2_CID_CODEC_PAD_CR_VALUE(V4L2_CID_CODEC_BASE+208)
+#define V4L2_CID_CODEC_RC_FRAME_ENABLE (V4L2_CID_CODEC_BASE+209)
+#define
Re: [linux-dvb] Simultaneous recordings from one frontend
Le mercredi 09 mars 2011 à 14:41 +0100, Pascal Jürgens a écrit : Hi all, - the RTP streaming apps (dvblast, mumudvb, dvbyell etc.) are designed to allow multiple listeners. The ideal solution would be something like an interface-local ipv6 multicast (mumudvb recommends using a TTL of 0 to prevent packets from exiting the machine, but that seems like a cludge). Sadly, I haven't gotten that to work [4]. Hello With MuMuDVB you can stream to 127.0.0.1 with different ports for each channel Unfortunately the stable release is pretty old so it will be better if you use snapshots If you have question about how to configure it do do that you can contact me directly [4] dvblast, for example, gives warning: getaddrinfo error: Name or service not known error: Invalid target address for -d switch when using [ff01::1%eth0] as the target address. Additionally, I wasn't able to consume a regular ipv4 multicast with two instances of mplayer - the first one worked, the second one couldn't access the url. Concerning this issue I can give you a very simple program which dump traffic from a multicast address. The sockets options are set differently than mplayer so multiple instances can run simultaneously Regards -- Brice -- 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
Simultaneous recordings from one frontend
Hi all, SUMMARY: What's the best available tool for demultiplexing into multiple simultaneous recordings (files)? I'm looking for a way to record a program (video, audio, subtitle, teletext PIDs) to overlapping files (ie, files2 should start 5 minutes before file1 ends). This means that two readers need to access the card at once. As far as I can tell from past discussions [1], this is not a feature that's currently present or planned in the kernel. So while searching for a userspace app that is capable of this, I found two options[3]: - Adam Charrett's dvbstreamer [2] seems to run a sort-of ringbuffer and can output to streams and files. However, it's not all too stable, especially when using the remote control protocol and in low signal situations. - the RTP streaming apps (dvblast, mumudvb, dvbyell etc.) are designed to allow multiple listeners. The ideal solution would be something like an interface-local ipv6 multicast. Sadly, I haven't gotten that to work [4]. Hence my questions are: - Am I doing something wrong and is there actually an easy way to stream to two files locally? - Is there some other solution that I'm not aware of that fits my scenario perfectly? Thanks in advance, regards, Pascal Juergens [1] http://www.linuxtv.org/pipermail/linux-dvb/2008-February/024093.html / http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15413 [2] http://sourceforge.net/projects/dvbstreamer/ [3] There's also the Linux::DVB::DVBT perl extension, but in my tests it wasn't happy about recording anything: timed out waiting for data : Inappropriate ioctl for device at /usr/local/bin/dvbt-record line 53 [4] dvblast, for example, gives warning: getaddrinfo error: Name or service not known error: Invalid target address for -d switch when using [ff01::1%eth0] as the target address. Additionally, I wasn't able to consume a regular ipv4 multicast with two instances of mplayer - the first one worked, the second one couldn't access the url.-- 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
TT-budget S-1500b card support
Hi
I'm working with a new version of TT-budget S-1500 card; I think the old one is
going end of life.
Technotrend Systemtechnik GmbH Device 101b
I took a stab at getting it working with a guessy patch and help finding the
correct tuner i2c address from another fellow who has this card
(http://linuxtv.org/pipermail/linux-dvb/2011-February/032815.html)
I achieved lock and was able to capture sensible transport stream data from the
transponder however nearly half of it is being consistently being lost
somewhere.
I'll add a bit more info below but would anyone be able help me diagnose what
is
wrong or point me in the right direction?
The main board chips are the same as before (SAA7146AH, LNBP21PD) though the
tuner board is different now making use of STx0228 STB6000 and now provides a
loop through; the tuner casing has a label with BSBE1-D01A on it. (an older
1500 I have uses stv0299b,tsa5059t,tda8060ts with a BSBE1-502A label on it).
Does the following patch make sense?
diff -Naur budget-ci.c.orig budget-ci.c
--- budget-ci.c.orig2011-03-09 13:20:28.0 +
+++ budget-ci.c 2011-03-09 13:23:37.0 +
@@ -48,6 +48,8 @@
#include stb0899_cfg.h
#include stb6100.h
#include stb6100_cfg.h
+#include stv0288.h
+#include stb6000.h
#include lnbp21.h
#include bsbe1.h
#include bsru6.h
@@ -217,6 +219,7 @@
case 0x1017:
case 0x1019:
case 0x101a:
+ case 0x101b:
/* for the Technotrend 1500 bundled remote */
ir_codes = RC_MAP_TT_1500;
break;
@@ -1303,6 +1306,11 @@
.refclock = 2700,
};
+static struct stv0288_config tt1500_stv0288_config = {
+.demod_address = 0x68,
+.min_delay_ms = 100,
+};
+
static void frontend_init(struct budget_ci *budget_ci)
{
switch (budget_ci-budget.dev-pci-subsystem_device) {
@@ -1372,6 +1380,22 @@
}
break;
+case 0x101b:// TT S-1500B PCI
+budget_ci-budget.dvb_frontend = dvb_attach(stv0288_attach,
tt1500_stv0288_config, budget_ci-budget.i2c_adap);
+if (budget_ci-budget.dvb_frontend) {
+if (dvb_attach(stb6000_attach, budget_ci-budget.dvb_frontend,
0x63, budget_ci-budget.i2c_adap) != NULL) {
+if (!dvb_attach(lnbp21_attach, budget_ci-budget.dvb_frontend,
budget_ci-budget.i2c_adap, 0, 0)) {
+printk(%s: No LNBP21 found!\n, __func__);
+dvb_frontend_detach(budget_ci-budget.dvb_frontend);
+budget_ci-budget.dvb_frontend = NULL;
+}
+} else {
+dvb_frontend_detach(budget_ci-budget.dvb_frontend);
+budget_ci-budget.dvb_frontend = NULL;
+}
+}
+break;
+
case 0x101a: /* TT Budget-C-1501 (philips tda10023/philips tda8274A) */
budget_ci-budget.dvb_frontend = dvb_attach(tda10023_attach,
tda10023_config, budget_ci-budget.i2c_adap, 0x48);
if (budget_ci-budget.dvb_frontend) {
@@ -1513,6 +1537,7 @@
MAKE_BUDGET_INFO(ttbcci, TT-Budget-C-CI PCI, BUDGET_TT);
MAKE_BUDGET_INFO(ttc1501, TT-Budget C-1501 PCI, BUDGET_TT);
MAKE_BUDGET_INFO(tt3200, TT-Budget S2-3200 PCI, BUDGET_TT);
+MAKE_BUDGET_INFO(ttbs1500b, TT-Budget/S-1500B PCI, BUDGET_TT);
static struct pci_device_id pci_tbl[] = {
MAKE_EXTENSION_PCI(ttbci, 0x13c2, 0x100c),
@@ -1523,6 +1548,7 @@
MAKE_EXTENSION_PCI(ttbs2, 0x13c2, 0x1017),
MAKE_EXTENSION_PCI(ttc1501, 0x13c2, 0x101a),
MAKE_EXTENSION_PCI(tt3200, 0x13c2, 0x1019),
+ MAKE_EXTENSION_PCI(ttbs1500b, 0x13c2, 0x101b),
{
.vendor = 0,
}
I consistently get FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER
FE_HAS_VITERBI and when tuned correctly the BER and UCBLOCK count remain zero.
There are no errors in dmesg with respect to buffers overflowing and enabling
7146 driver debug didn't reveal any DMA transfer errors.
echo 0 /sys/module/dvb_core/parameters/dvb_powerdown_on_sleep
dvbtune -f 10847000 -s 22000 -p V -I 2 -c 3
Using DVB card ST STV0288 DVB-S
tuning DVB-S to L-Band:0, Pol:V Srate=2200, 22kHz=off
polling….
...
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
dvbsnoop -dvr /dev/dvb/adapter$A/dvr0 -demux /dev/dvb/adapter$A/demux0
-frontend
/dev/dvb/adapter$A/frontend0 -s ts -tsraw -s bandwidth
new 1500 with STV0288 showing loss of almost half the data
packets read: 189/(125497) d_time: 0.014 s = 20304.000 kbit/s (Avrg:
18686.020 kbit/s) [bad: 0]
packets read: 199/(125696) d_time: 0.016 s = 18706.000 kbit/s (Avrg:
18686.052 kbit/s) [bad: 0]
packets read: 197/(125893) d_time: 0.015 s = 19752.533 kbit/s (Avrg:
18687.630 kbit/s) [bad: 0]
old 1500 with STV0299 on same transponder
packets read: 349/(465593) d_time: 0.015 s = 34993.067 kbit/s (Avrg:
33763.350 kbit/s) [bad: 0]
packets read: 327/(465920) d_time: 0.015 s = 32787.200 kbit/s (Avrg:
Re: Simultaneous recordings from one frontend
Hi Pascal,
I've written a very small program that does just that :
https://svn.tuxicoman.be/listing.php?repname=dvbsplit
It's a quick hack, there is probably a better way to do this but at
least it works :)
To get the sources : svn checkout
https://svn.tuxicoman.be/svn/dvbsplit/trunk dvbsplit. Check the readme
for compilation.
You'll need to tune to the right TP with `{stc}zap -r`, then start it
and it will dump everything in the directory.
HTH,
Guy
On Wed, 9 Mar 2011 15:20:06 +0100
Pascal Jürgens lists.pascal.juerg...@googlemail.com wrote:
Hi all,
SUMMARY: What's the best available tool for demultiplexing into
multiple simultaneous recordings (files)?
I'm looking for a way to record a program (video, audio, subtitle,
teletext PIDs) to overlapping files (ie, files2 should start 5
minutes before file1 ends). This means that two readers need to
access the card at once. As far as I can tell from past discussions
[1], this is not a feature that's currently present or planned in the
kernel.
So while searching for a userspace app that is capable of this, I
found two options[3]:
- Adam Charrett's dvbstreamer [2] seems to run a sort-of ringbuffer
and can output to streams and files. However, it's not all too
stable, especially when using the remote control protocol and in low
signal situations.
- the RTP streaming apps (dvblast, mumudvb, dvbyell etc.) are
designed to allow multiple listeners. The ideal solution would be
something like an interface-local ipv6 multicast. Sadly, I haven't
gotten that to work [4].
Hence my questions are:
- Am I doing something wrong and is there actually an easy way to
stream to two files locally?
- Is there some other solution that I'm not aware of that fits my
scenario perfectly?
Thanks in advance,
regards,
Pascal Juergens
[1]
http://www.linuxtv.org/pipermail/linux-dvb/2008-February/024093.html /
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15413
[2] http://sourceforge.net/projects/dvbstreamer/
[3] There's also the Linux::DVB::DVBT perl extension, but in my tests
it wasn't happy about recording anything: timed out waiting for
data : Inappropriate ioctl for device at /usr/local/bin/dvbt-record
line 53
[4] dvblast, for example, gives warning: getaddrinfo error: Name or
service not known error: Invalid target address for -d switch when
using [ff01::1%eth0] as the target address. Additionally, I wasn't
able to consume a regular ipv4 multicast with two instances of
mplayer - the first one worked, the second one couldn't access the
url.-- 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: Simultaneous recordings from one frontend
Dear Guy,
I compiled your tool and from what I see, it demuxes the ts into separate
streams for each program.
While it's a very handy thing to have, I'm actually looking for something
slightly different.
I'm sorry if I didn't describe it very clearly.
What I'm looking to do is to record ONE and the same program into two different
files, but start and stop at distinct points in time.
This means that the recording schedule would look something like this:
Program arte:
file1 (start 11:55)(end 13:05) ...
file2 start(start 12:55)(end
14:05) ...
So far, Brice Dubost has already hinted that mumudb is able to stream the same
program to a unicast port on a loopback device, and I've been able to do
multiple simultaneous recording this way.
However, I'm still curious to see if there are other options :)
Thanks,
Pascal
On Mar 9, 2011, at 3:47 PM, Guy Martin wrote:
Hi Pascal,
I've written a very small program that does just that :
https://svn.tuxicoman.be/listing.php?repname=dvbsplit
It's a quick hack, there is probably a better way to do this but at
least it works :)
To get the sources : svn checkout
https://svn.tuxicoman.be/svn/dvbsplit/trunk dvbsplit. Check the readme
for compilation.
You'll need to tune to the right TP with `{stc}zap -r`, then start it
and it will dump everything in the directory.
HTH,
Guy
--
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
WinTV 1400 broken with recent versions?
Hey, is this driver going to be fixed anytime soon? It was working fine ago a half year/year. lspci: 06:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) uname -a: Linux lyra 2.6.37.1 #1 SMP PREEMPT Tue Feb 22 13:22:59 CET 2011 x86_64 x86_64 x86_64 GNU/Linux dmesg: xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware nothing works - if i do scan it finds nothing and those messages appear on dmesg. if i try to watch with the channels.conf from my other pc i can play nothing, all i get is those messages above. -- 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
WinTV 1400 broken with recent versions?
Hey, is this driver going to be fixed anytime soon? It was working fine ago a half year/year. lspci: 06:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) uname -a: Linux lyra 2.6.37.1 #1 SMP PREEMPT Tue Feb 22 13:22:59 CET 2011 x86_64 x86_64 x86_64 GNU/Linux dmesg: xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware nothing works - if i do scan it finds nothing and those messages appear on dmesg. if i try to watch with the channels.conf from my other pc i can play nothing, all i get is those messages above. -- 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: WinTV 1400 broken with recent versions?
On Mar 9, 2011, at 11:52 AM, Jean-Michel Bruenn wrote: Hey, is this driver going to be fixed anytime soon? It was working fine ago a half year/year. lspci: 06:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) uname -a: Linux lyra 2.6.37.1 #1 SMP PREEMPT Tue Feb 22 13:22:59 CET 2011 x86_64 x86_64 x86_64 GNU/Linux dmesg: xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware xc2028 1-0064: Loading firmware for type=BASE F8MHZ (3), id . xc2028 1-0064: i2c output error: rc = -6 (should be 64) xc2028 1-0064: -6 returned from send xc2028 1-0064: Error -22 while loading base firmware nothing works - if i do scan it finds nothing and those messages appear on dmesg. if i try to watch with the channels.conf from my other pc i can play nothing, all i get is those messages above. This may already be fixed, just not in 2.6.37.x yet. Can you give 2.6.38-rc8 (or later) a try and/or the media_build bits? http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] OMAP3-ISP lane shifter support
Add support for the ISP's lane shifter. To use the shifter, set different pixel formats at each end of the link at the CCDC input. This has only been tested shifting Y12 and SBGGR12 from a parallel sensor to Y8 and SBGGR8 (respectively) at the CCDC input. Support has also been added for other formats and other shifting values, but is untested. Shifting data coming from one of the serial sensor interfaces (CSI2a, etc) is also untested. As before, ccdc_try_format() does not check that the format at its input is compatible with the format coming from the sensor interface. This consistency check is first done when activating the pipeline. These patches apply to Laurent's media-0005-omap3isp branch, based on 2.6.38-rc5 Changes since v1: -added support for remaining 8-bit Bayer formats (SGBRG8_1X8 SRGGB8_1X8) -moved omap3isp_is_shiftable() from isp.c to ispvideo.c and return bool -moved 'shift' calculation from omap3isp_configure_bridge() to ccdc_configure() -added 'shift' arg to omap3isp_configure_bridge() -misc minor changes according to feedback (removed unnecessary tests, etc.) Michael Jones (4): v4l: add V4L2_PIX_FMT_Y12 format media: add 8-bit bayer formats and Y12 omap3isp: ccdc: support Y10/12, 8-bit bayer fmts omap3isp: lane shifter support drivers/media/video/omap3-isp/isp.c |6 +- drivers/media/video/omap3-isp/isp.h |5 +- drivers/media/video/omap3-isp/ispccdc.c | 32 +- drivers/media/video/omap3-isp/ispvideo.c | 97 + drivers/media/video/omap3-isp/ispvideo.h |3 + include/linux/v4l2-mediabus.h|7 ++- include/linux/videodev2.h|1 + 7 files changed, 126 insertions(+), 25 deletions(-) -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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 1/4] v4l: add V4L2_PIX_FMT_Y12 format
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 02da9e7..6fac463 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -288,6 +288,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale
*/
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale
*/
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
+#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
/* Palette formats */
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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 2/4] media: add 8-bit bayer formats and Y12
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 7054a7a..46caecd 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2013 */
+ /* YUV (including grey) - next is 0x2014 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
+ V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
@@ -67,9 +68,11 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
- /* Bayer - next is 0x3013 */
+ /* Bayer - next is 0x3015 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
+ V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
+ V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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/4] omap3isp: ccdc: support Y10/12, 8-bit bayer fmts
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3-isp/ispccdc.c |6 ++
drivers/media/video/omap3-isp/ispvideo.c | 12
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3-isp/ispccdc.c
b/drivers/media/video/omap3-isp/ispccdc.c
index e4d04ce..23000b6 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -43,6 +43,12 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12,
+ V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
diff --git a/drivers/media/video/omap3-isp/ispvideo.c
b/drivers/media/video/omap3-isp/ispvideo.c
index f16d787..3c3b3c4 100644
--- a/drivers/media/video/omap3-isp/ispvideo.c
+++ b/drivers/media/video/omap3-isp/ispvideo.c
@@ -48,6 +48,18 @@
static struct isp_format_info formats[] = {
{ V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
+ { V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y10_1X10, V4L2_PIX_FMT_Y10, 10, },
+ { V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12, V4L2_PIX_FMT_Y12, 12, },
+ { V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8, },
+ { V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8, },
+ { V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8, },
+ { V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8, },
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
{ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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 4/4] omap3isp: lane shifter support
To use the lane shifter, set different pixel formats at each end of
the link at the CCDC input.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3-isp/isp.c |6 +-
drivers/media/video/omap3-isp/isp.h |5 +-
drivers/media/video/omap3-isp/ispccdc.c | 26 +++-
drivers/media/video/omap3-isp/ispvideo.c | 97 +++--
drivers/media/video/omap3-isp/ispvideo.h |3 +
5 files changed, 108 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/omap3-isp/isp.c
b/drivers/media/video/omap3-isp/isp.c
index 08d90fe..68c6bcd 100644
--- a/drivers/media/video/omap3-isp/isp.c
+++ b/drivers/media/video/omap3-isp/isp.c
@@ -285,7 +285,8 @@ static void isp_power_settings(struct isp_device *isp, int
idle)
*/
void omap3isp_configure_bridge(struct isp_device *isp,
enum ccdc_input_entity input,
- const struct isp_parallel_platform_data *pdata)
+ const struct isp_parallel_platform_data *pdata,
+ int shift)
{
u32 ispctrl_val;
@@ -298,7 +299,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
switch (input) {
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
- ispctrl_val |= pdata-data_lane_shift ISPCTRL_SHIFT_SHIFT;
ispctrl_val |= pdata-clk_pol ISPCTRL_PAR_CLK_POL_SHIFT;
ispctrl_val |= pdata-bridge ISPCTRL_PAR_BRIDGE_SHIFT;
break;
@@ -319,6 +319,8 @@ void omap3isp_configure_bridge(struct isp_device *isp,
return;
}
+ ispctrl_val |= ((shift/2) ISPCTRL_SHIFT_SHIFT) ISPCTRL_SHIFT_MASK;
+
ispctrl_val = ~ISPCTRL_SYNC_DETECT_MASK;
ispctrl_val |= ISPCTRL_SYNC_DETECT_VSRISE;
diff --git a/drivers/media/video/omap3-isp/isp.h
b/drivers/media/video/omap3-isp/isp.h
index 21fa88b..3d13f8b 100644
--- a/drivers/media/video/omap3-isp/isp.h
+++ b/drivers/media/video/omap3-isp/isp.h
@@ -144,8 +144,6 @@ struct isp_reg {
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
- unsigned int width;
- unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
@@ -322,7 +320,8 @@ int omap3isp_pipeline_set_stream(struct isp_pipeline *pipe,
enum isp_pipeline_stream_state state);
void omap3isp_configure_bridge(struct isp_device *isp,
enum ccdc_input_entity input,
- const struct isp_parallel_platform_data *pdata);
+ const struct isp_parallel_platform_data *pdata,
+ int shift);
#define ISP_XCLK_NONE -1
#define ISP_XCLK_A 0
diff --git a/drivers/media/video/omap3-isp/ispccdc.c
b/drivers/media/video/omap3-isp/ispccdc.c
index 23000b6..923a08f 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -1120,21 +1120,39 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
struct isp_parallel_platform_data *pdata = NULL;
struct v4l2_subdev *sensor;
struct v4l2_mbus_framefmt *format;
+ int depth_in = 0, depth_out = 0;
+ int shift;
+ const struct isp_format_info *fmt_info;
+ struct v4l2_subdev_format fmt_src;
struct media_pad *pad;
unsigned long flags;
u32 syn_mode;
u32 ccdc_pattern;
+ pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
+ sensor = media_entity_to_v4l2_subdev(pad-entity);
if (ccdc-input == CCDC_INPUT_PARALLEL) {
- pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
- sensor = media_entity_to_v4l2_subdev(pad-entity);
pdata = ((struct isp_v4l2_subdevs_group *)sensor-host_priv)
-bus.parallel;
}
- omap3isp_configure_bridge(isp, ccdc-input, pdata);
+ /* set syncif.datsz */
+ fmt_src.pad = pad-index;
+ fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL, fmt_src)) {
+ fmt_info = omap3isp_video_format_info(fmt_src.format.code);
+ depth_in = fmt_info ? fmt_info-bpp : 0;
+ }
+
+ /* find CCDC input format */
+ fmt_info = omap3isp_video_format_info
+ (isp-isp_ccdc.formats[CCDC_PAD_SINK].code);
+ depth_out = fmt_info ? fmt_info-bpp : 0;
+
+ shift = depth_in - depth_out;
+ omap3isp_configure_bridge(isp, ccdc-input, pdata, shift);
- ccdc-syncif.datsz = pdata ? pdata-width : 10;
+ ccdc-syncif.datsz = depth_out;
ccdc_config_sync_if(ccdc, ccdc-syncif);
/* CCDC_PAD_SINK */
diff --git a/drivers/media/video/omap3-isp/ispvideo.c
Re: Simultaneous recordings from one frontend
On 03/09/2011 03:20 PM, Pascal Jürgens wrote:
SUMMARY: What's the best available tool for demultiplexing into multiple
simultaneous recordings (files)?
The kernel. There's no need to do that in userspace.
Any(*) number of tools may open a demux simultaneously, set up a filter
for the first PID with DMX_OUT_TSDEMUX_TAP and add any(*) number of TS
PIDs with DMX_ADD_PID. Data has to be read from demux, not from the
limited and IMHO obsolete dvr device.
In simplified code for PAT, PMT PID 0x80, Video PID 0x100, Audio PID 0x101:
int fd = open(/dev/dvb/adapter0/demux0, O_RDWR);
struct dmx_pes_filter_params f = {
.pid = 0, // PAT
.input = DMX_IN_FRONTEND, // live TV
.output = DMX_OUT_TSDEMUX_TAP, // TS packets!
.pes_type = DMX_PES_OTHER, // no decoding
.flags = DMX_IMMEDIATE_START,
};
uint16_t pid[] = { 0x80, 0x100, 0x101 };
ioctl(fd, DMX_SET_PES_FILTER, f);
for (int i = 0; i 3; i++)
ioctl(fd, DMX_ADD_PID, pid[i]);
ssize_t r;
unsigned char buf[N * 188];
while ((r = read(fd, buf, sizeof(buf)) = 0)
write(1, buf, r); // write to stdout
close(fd);
If there's no tool using this interface yet, it's probably time to write
or modify one,
Regards,
Andreas
*) Depending on available system resources.
--
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/2(7)] s5p fimc driver fixes
Hello, this is basically a resend of my previous s5p fimc driver bugfix change set including altered 2 out of 7. It's a result of my further struggle with the DMA engine and also a correction of the G_FMT ioctl function to return proper bytesperline/sizeimage for all supported formats. [PATCH 1/7] s5p-fimc: fix ISR and buffer handling for fimc-capture [PATCH 7/7] s5p-fimc: Fix G_FMT ioctl handler Following is the previous original change set summary. --- the following are a few bugfixes for s5p-fimc driver. These patches correct fimc output DMA handling and locking in m2m driver so there is no issues in m2m multi-instance operation. One of the patches adds missing g_fmt ioctl conversion to multiplanar formats. The patch series contains: [PATCH 1/7] s5p-fimc: fix ISR and buffer handling for fimc-capture [PATCH 2/7] s5p-fimc: Prevent oops when i2c adapter is not available [PATCH 3/7] s5p-fimc: Prevent hanging on device close and fix the locking [PATCH 4/7] s5p-fimc: Allow defining number of sensors at runtime [PATCH 5/7] s5p-fimc: Add a platform data entry for MIPI-CSI data alignment [PATCH 6/7] s5p-fimc: Use dynamic debug [PATCH 7/7] s5p-fimc: Fix G_FMT ioctl handler Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- 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 7/7] s5p-fimc: Fix G_FMT ioctl handler
Use pix_mp member of struct v4l2_format to return a format
description rather than pix. Also fill in the plane_fmt array.
This is a missing bit of conversion to the multiplanar API.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index b29937e..6c919b3 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -804,15 +804,33 @@ int fimc_vidioc_g_fmt_mplane(struct file *file, void
*priv,
{
struct fimc_ctx *ctx = priv;
struct fimc_frame *frame;
+ struct v4l2_pix_format_mplane *pixm;
+ int i;
frame = ctx_get_frame(ctx, f-type);
if (IS_ERR(frame))
return PTR_ERR(frame);
- f-fmt.pix.width= frame-width;
- f-fmt.pix.height = frame-height;
- f-fmt.pix.field= V4L2_FIELD_NONE;
- f-fmt.pix.pixelformat = frame-fmt-fourcc;
+ pixm = f-fmt.pix_mp;
+
+ pixm-width = frame-width;
+ pixm-height= frame-height;
+ pixm-field = V4L2_FIELD_NONE;
+ pixm-pixelformat = frame-fmt-fourcc;
+ pixm-colorspace= V4L2_COLORSPACE_JPEG;
+ pixm-num_planes= frame-fmt-memplanes;
+
+ for (i = 0; i pixm-num_planes; ++i) {
+ int bpl = frame-o_width;
+
+ if (frame-fmt-colplanes == 1) /* packed formats */
+ bpl = (bpl * frame-fmt-depth[0]) / 8;
+
+ pixm-plane_fmt[i].bytesperline = bpl;
+
+ pixm-plane_fmt[i].sizeimage = (frame-o_width *
+ frame-o_height * frame-fmt-depth[i]) / 8;
+ }
return 0;
}
@@ -907,6 +925,7 @@ int fimc_vidioc_try_fmt_mplane(struct file *file, void
*priv,
pix-height, 8, variant-pix_limit-scaler_dis_w, mod_y, 0);
pix-num_planes = fmt-memplanes;
+ pix-colorspace = V4L2_COLORSPACE_JPEG;
for (i = 0; i pix-num_planes; ++i) {
int bpl = pix-plane_fmt[i].bytesperline;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/2] Support controls at the subdev file handler level
Hi everybody, Here's a patch set that adds support for per-file-handle controls on V4L2 subdevs. The patches are work in progress, but I'm still sending them as Samsung expressed interest in a similar feature on V4L2 device nodes. Laurent Pinchart (2): v4l: subdev: Move file handle support to drivers v4l: subdev: Add support for file handler control handler drivers/media/video/v4l2-subdev.c | 144 +++- include/media/v4l2-subdev.h | 10 ++- 2 files changed, 84 insertions(+), 70 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/2] v4l: subdev: Move file handle support to drivers
Drivers sometimes need to embed the v4l2_subdev_fh structure into a
higher level driver-specific structure. As the v4l2_subdev_fh structure
is allocated by subdev core, this isn't possible.
Fix the problem by moving allocation and free of the structure to the
subdevices. Two helper functions v4l2_subdev_fh_open() and
v4l2_subdev_fh_close() can be used to fill the subdev file operations by
drivers that don't need to perform any specific operation in their open
and close handlers.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 126 -
include/media/v4l2-subdev.h |5 ++
2 files changed, 72 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 0b80644..5f23c9f 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -31,8 +31,10 @@
#include media/v4l2-fh.h
#include media/v4l2-event.h
-static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
+int v4l2_subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
+ int ret;
+
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
/* Allocate try format and crop in the same memory block */
fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
@@ -43,104 +45,110 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
struct v4l2_subdev *sd)
fh-try_crop = (struct v4l2_rect *)
(fh-try_fmt + sd-entity.num_pads);
#endif
+
+ ret = v4l2_fh_init(fh-vfh, sd-devnode);
+ if (ret)
+ goto error;
+
+ if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
+ ret = v4l2_event_init(fh-vfh);
+ if (ret)
+ goto error;
+
+ ret = v4l2_event_alloc(fh-vfh, sd-nevents);
+ if (ret)
+ goto error;
+ }
+
+ v4l2_fh_add(fh-vfh);
return 0;
+
+error:
+ v4l2_subdev_fh_exit(fh);
+ return ret;
}
+EXPORT_SYMBOL_GPL(v4l2_subdev_fh_init);
-static void subdev_fh_free(struct v4l2_subdev_fh *fh)
+void v4l2_subdev_fh_exit(struct v4l2_subdev_fh *fh)
{
+ v4l2_fh_del(fh-vfh);
+ v4l2_fh_exit(fh-vfh);
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
kfree(fh-try_fmt);
fh-try_fmt = NULL;
fh-try_crop = NULL;
#endif
}
+EXPORT_SYMBOL_GPL(v4l2_subdev_fh_exit);
-static int subdev_open(struct file *file)
+int v4l2_subdev_fh_open(struct v4l2_subdev *sd, struct file *file)
{
- struct video_device *vdev = video_devdata(file);
- struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
- struct v4l2_subdev_fh *subdev_fh;
-#if defined(CONFIG_MEDIA_CONTROLLER)
- struct media_entity *entity = NULL;
-#endif
+ struct v4l2_subdev_fh *fh;
int ret;
- subdev_fh = kzalloc(sizeof(*subdev_fh), GFP_KERNEL);
- if (subdev_fh == NULL)
+ fh = kzalloc(sizeof(*fh), GFP_KERNEL);
+ if (fh == NULL)
return -ENOMEM;
- ret = subdev_fh_init(subdev_fh, sd);
- if (ret) {
- kfree(subdev_fh);
- return ret;
- }
+ ret = v4l2_subdev_fh_init(fh, sd);
+ if (ret 0)
+ goto error;
- ret = v4l2_fh_init(subdev_fh-vfh, vdev);
- if (ret)
- goto err;
+ file-private_data = fh-vfh;
+ return 0;
- if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
- ret = v4l2_event_init(subdev_fh-vfh);
- if (ret)
- goto err;
+error:
+ v4l2_subdev_fh_exit(fh);
+ kfree(fh);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_fh_open);
- ret = v4l2_event_alloc(subdev_fh-vfh, sd-nevents);
- if (ret)
- goto err;
- }
+int v4l2_subdev_fh_close(struct v4l2_subdev *sd, struct file *file)
+{
+ struct v4l2_subdev_fh *fh = to_v4l2_subdev_fh(file-private_data);
+
+ v4l2_subdev_fh_exit(fh);
+ kfree(fh);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_fh_close);
+
+static int subdev_open(struct file *file)
+{
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ int ret;
- v4l2_fh_add(subdev_fh-vfh);
- file-private_data = subdev_fh-vfh;
#if defined(CONFIG_MEDIA_CONTROLLER)
if (sd-v4l2_dev-mdev) {
- entity = media_entity_get(sd-entity);
- if (!entity) {
- ret = -EBUSY;
- goto err;
- }
+ if (!media_entity_get(sd-entity))
+ return -EBUSY;
}
#endif
-
if (sd-internal_ops sd-internal_ops-open) {
- ret = sd-internal_ops-open(sd, subdev_fh);
- if (ret 0)
- goto err;
+ ret = sd-internal_ops-open(sd, file);
+
[PATCH/RFC 2/2] v4l: subdev: Add support for file handler control handler
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 18 +-
include/media/v4l2-subdev.h |5 +++--
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 5f23c9f..5d3a4bd 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -157,31 +157,31 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
struct v4l2_fh *vfh = file-private_data;
-#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
struct v4l2_subdev_fh *subdev_fh = to_v4l2_subdev_fh(vfh);
-#endif
+ struct v4l2_ctrl_handler *ctrl_handler = subdev_fh-ctrl_handler
+ ? subdev_fh-ctrl_handler : sd-ctrl_handler;
switch (cmd) {
case VIDIOC_QUERYCTRL:
- return v4l2_subdev_queryctrl(sd, arg);
+ return v4l2_queryctrl(ctrl_handler, arg);
case VIDIOC_QUERYMENU:
- return v4l2_subdev_querymenu(sd, arg);
+ return v4l2_querymenu(ctrl_handler, arg);
case VIDIOC_G_CTRL:
- return v4l2_subdev_g_ctrl(sd, arg);
+ return v4l2_g_ctrl(ctrl_handler, arg);
case VIDIOC_S_CTRL:
- return v4l2_subdev_s_ctrl(sd, arg);
+ return v4l2_s_ctrl(ctrl_handler, arg);
case VIDIOC_G_EXT_CTRLS:
- return v4l2_subdev_g_ext_ctrls(sd, arg);
+ return v4l2_g_ext_ctrls(ctrl_handler, arg);
case VIDIOC_S_EXT_CTRLS:
- return v4l2_subdev_s_ext_ctrls(sd, arg);
+ return v4l2_s_ext_ctrls(ctrl_handler, arg);
case VIDIOC_TRY_EXT_CTRLS:
- return v4l2_subdev_try_ext_ctrls(sd, arg);
+ return v4l2_try_ext_ctrls(ctrl_handler, arg);
case VIDIOC_DQEVENT:
if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 4671459..6229ffc 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -469,8 +469,8 @@ struct v4l2_subdev_ops {
struct v4l2_subdev_internal_ops {
int (*registered)(struct v4l2_subdev *sd);
void (*unregistered)(struct v4l2_subdev *sd);
- int (*open)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh);
- int (*close)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh);
+ int (*open)(struct v4l2_subdev *sd, struct file *file);
+ int (*close)(struct v4l2_subdev *sd, struct file *file);
};
#define V4L2_SUBDEV_NAME_SIZE 32
@@ -527,6 +527,7 @@ struct v4l2_subdev_fh {
struct v4l2_mbus_framefmt *try_fmt;
struct v4l2_rect *try_crop;
#endif
+ struct v4l2_ctrl_handler *ctrl_handler;
};
#define to_v4l2_subdev_fh(fh) \
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] davinci: vpfe: mdia controller implementation for capture
Hi Manjunath, On Tuesday 08 March 2011 06:43:59 Hadli, Manjunath wrote: On Sun, Mar 06, 2011 at 22:59:40, Laurent Pinchart wrote: On Sunday 06 March 2011 16:36:05 Manjunath Hadli wrote: Introduction This is the proposal of the initial version of design and implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports only continuous mode and not on-the-fly 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. You're welcome :-) Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, Resizer and other being individual character drivers. The CCDC, preview and resizer modules look very similar to their OMAP3 counterparts. I think we should aim at sharing code between the drivers. It's hard enough to develop, review and maintain one driver, let's not duplicate the effort. Laurent, the modules in DM365 and DM355 are based on ISIF (for image capture) IPIPEIF, IPIPE and these modules are very different from that of their OMAP3 counterparts both in terms of hardware features, implementation and registers. The naming is done as CCDC, Previewer and Resizer only because to make it simple in understanding and making it comfortable for the API users of DM644X. I am aware of the discussion you and Vaibhav had, where he mentioned your point to make these drivers similar, and after Poring through the specs in detail we concluded that the approach can be the same but code-re-use is be minimal. So, we have derived the top level approach from you while the core implementation of hardware programming comes from arago. I haven't checked all chips, but the DM644x ISP is very similar to the OMAP3 ISP. [snip] TODOs: == 1. Single shot implementation for previewer and resizer. 2. Seperation of v4l2 video related structures and routines to aid single shot implementation. 3. Support NV12 format 4. Move the files from char folder to drivers/media/video along with headers Why are the drivers in drivers/char for ? This is WIP where some of the files are in char dir from arago implementation. You can see item 4 in the TODO list where this movement is pending. OK. I'll review the driver when the code in drivers/char will be removed then :-) -- 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 1/4] v4l: add V4L2_PIX_FMT_Y12 format
Hi Michael,
Thanks for the patch.
On Wednesday 09 March 2011 17:07:40 Michael Jones wrote:
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 02da9e7..6fac463 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -288,6 +288,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4
Greyscale */
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
Greyscale */
+#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
Greyscale */
/* Palette formats */
Could you please also document the format in Documentation/DocBook/v4l ?
--
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 2/4] media: add 8-bit bayer formats and Y12
Hi Michael,
Thanks for the patch.
On Wednesday 09 March 2011 17:07:41 Michael Jones wrote:
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 7054a7a..46caecd 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2013 */
+ /* YUV (including grey) - next is 0x2014 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
+ V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
@@ -67,9 +68,11 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
- /* Bayer - next is 0x3013 */
+ /* Bayer - next is 0x3015 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
+ V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
+ V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
Could you please also document those formats in
Documentation/DocBook/v4l/subdev-formats.xml ?
--
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 3/4] omap3isp: ccdc: support Y10/12, 8-bit bayer fmts
Hi Michael,
Thanks for the patch.
On Wednesday 09 March 2011 17:07:42 Michael Jones wrote:
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3-isp/ispccdc.c |6 ++
drivers/media/video/omap3-isp/ispvideo.c | 12
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3-isp/ispccdc.c
b/drivers/media/video/omap3-isp/ispccdc.c index e4d04ce..23000b6 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -43,6 +43,12 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12,
+ V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
diff --git a/drivers/media/video/omap3-isp/ispvideo.c
b/drivers/media/video/omap3-isp/ispvideo.c index f16d787..3c3b3c4 100644
--- a/drivers/media/video/omap3-isp/ispvideo.c
+++ b/drivers/media/video/omap3-isp/ispvideo.c
@@ -48,6 +48,18 @@
static struct isp_format_info formats[] = {
{ V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
+ { V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y10_1X10, V4L2_PIX_FMT_Y10, 10, },
+ { V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12, V4L2_PIX_FMT_Y12, 12, },
+ { V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8, },
+ { V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8, },
+ { V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8, },
+ { V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8, },
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
{ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
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: WinTV 1400 broken with recent versions?
This may already be fixed, just not in 2.6.37.x yet. Can you give 2.6.38-rc8 (or later) a try and/or the media_build bits? Tried - Nope, same behaviour (same error messages in dmesg, no results by scan) http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I was unable to get that working; tried with 2.6.37.2 and 2.6.37.3 always getting invalid module format and yeah, i tried with reboot, i tried with a fresh variant.. Also tried ./build.sh and make install and such stuff in 2.6.38-rc8, same. -- 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/4] omap3isp: lane shifter support
Hi Michael,
Thanks for the patch.
On Wednesday 09 March 2011 17:07:43 Michael Jones wrote:
To use the lane shifter, set different pixel formats at each end of
the link at the CCDC input.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
[snip]
diff --git a/drivers/media/video/omap3-isp/isp.h
b/drivers/media/video/omap3-isp/isp.h index 21fa88b..3d13f8b 100644
--- a/drivers/media/video/omap3-isp/isp.h
+++ b/drivers/media/video/omap3-isp/isp.h
@@ -144,8 +144,6 @@ struct isp_reg {
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
- unsigned int width;
- unsigned int data_lane_shift:2;
I'm afraid you can't remove the data_lane_shift field completely. Board can
wire a 8 bits sensor to DATA[9:2] :-/ That needs to be taken into account as
well when computing the total shift value.
Hardware configuration can be done by adding the requested shift value to
data_lane_shift for parallel sensors in omap3isp_configure_bridge(), but we
also need to take it into account when validating the pipeline.
I'm not aware of any board requiring data_lane_shift at the moment though, so
we could just drop it now and add it back later when needed. This will avoid
making this patch more complex.
unsigned int clk_pol:1;
unsigned int bridge:4;
};
[snip]
diff --git a/drivers/media/video/omap3-isp/ispccdc.c
b/drivers/media/video/omap3-isp/ispccdc.c index 23000b6..923a08f 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -1120,21 +1120,39 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) struct isp_parallel_platform_data *pdata = NULL;
struct v4l2_subdev *sensor;
struct v4l2_mbus_framefmt *format;
+ int depth_in = 0, depth_out = 0;
Linux discourages the declaration of multiple variables on a single line.
Could you split this ? The depths should also be unsigned int's (as well as
the shift value below).
+ int shift;
+ const struct isp_format_info *fmt_info;
+ struct v4l2_subdev_format fmt_src;
struct media_pad *pad;
unsigned long flags;
u32 syn_mode;
u32 ccdc_pattern;
Could you keep variable declaration lines (mostly) sorted by line length ?
+ pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
+ sensor = media_entity_to_v4l2_subdev(pad-entity);
if (ccdc-input == CCDC_INPUT_PARALLEL) {
- pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
- sensor = media_entity_to_v4l2_subdev(pad-entity);
pdata = ((struct isp_v4l2_subdevs_group *)sensor-host_priv)
-bus.parallel;
}
You can remove the curly braces as the 'if' body now contains a single
statement.
- omap3isp_configure_bridge(isp, ccdc-input, pdata);
+ /* set syncif.datsz */
The following lines don't set syncif.datsz, so the comment is a bit
misleading. I think you can replace it with
/* Compute the lane shifter shift value to configure the bridge. */
or something similar, and remove the find CCDC input format comment below.
+ fmt_src.pad = pad-index;
+ fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL, fmt_src)) {
+ fmt_info = omap3isp_video_format_info(fmt_src.format.code);
+ depth_in = fmt_info ? fmt_info-bpp : 0;
omap3isp_video_format_info() won't return NULL, as it supports all formats
supported by the CCDC. You can thus skip the NULL check.
+ }
+
+ /* find CCDC input format */
+ fmt_info = omap3isp_video_format_info
+ (isp-isp_ccdc.formats[CCDC_PAD_SINK].code);
+ depth_out = fmt_info ? fmt_info-bpp : 0;
And here too.
+
+ shift = depth_in - depth_out;
+ omap3isp_configure_bridge(isp, ccdc-input, pdata, shift);
- ccdc-syncif.datsz = pdata ? pdata-width : 10;
+ ccdc-syncif.datsz = depth_out;
ccdc_config_sync_if(ccdc, ccdc-syncif);
/* CCDC_PAD_SINK */
diff --git a/drivers/media/video/omap3-isp/ispvideo.c
b/drivers/media/video/omap3-isp/ispvideo.c index 3c3b3c4..decc744 100644
--- a/drivers/media/video/omap3-isp/ispvideo.c
+++ b/drivers/media/video/omap3-isp/ispvideo.c
@@ -47,41 +47,59 @@
static struct isp_format_info formats[] = {
[snip]
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
- V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
+ V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
Should this be
V4L2_MBUS_FMT_SGRBG10_1X10, 0,
instead ? DPCM formats are not shiftable. It won't make any difference in
practice, as the format is already 8-bit wide, but you state in the flavor
field documentation that =0 if format is not shiftable.
+ V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
[snip]
@@ -98,6 +116,32 @@ omap3isp_video_format_info(enum v4l2_mbus_pixelcode
code) }
/*
+ *
Re: [PATCHv2 0/3] hwmem: Hardware memory driver
Hi, CCed updated Michal email address, One note, As Michal moved to google, Marek is works on CMA. We are also studying the hwmem and GEM. Thank you, Kyungmin Park On Wed, Mar 9, 2011 at 9:18 PM, johan.xx.mossb...@stericsson.com wrote: Hello everyone, The following patchset implements a hardware memory driver. The main purpose of hwmem is: * To allocate buffers suitable for use with hardware. Currently this means contiguous buffers. * To synchronize the caches for the allocated buffers. This is achieved by keeping track of when the CPU uses a buffer and when other hardware uses the buffer, when we switch from CPU to other hardware or vice versa the caches are synchronized. * To handle sharing of allocated buffers between processes i.e. import, export. Hwmem is available both through a user space API and through a kernel API. Here at ST-Ericsson we use hwmem for graphics buffers. Graphics buffers need to be contiguous due to our hardware, are passed between processes (usually application and window manager)and are part of usecases where performance is top priority so we can't afford to synchronize the caches unecessarily. Additions in v2: * Bugfixes * Added the possibility to map hwmem buffers in the kernel through hwmem_kmap/kunmap * Moved mach specific stuff to mach. Best regards Johan Mossberg Consultant at ST-Ericsson Johan Mossberg (3): hwmem: Add hwmem (part 1) hwmem: Add hwmem (part 2) hwmem: Add hwmem to ux500 arch/arm/mach-ux500/Makefile | 2 +- arch/arm/mach-ux500/board-mop500.c | 1 + arch/arm/mach-ux500/dcache.c | 266 + arch/arm/mach-ux500/devices.c | 31 ++ arch/arm/mach-ux500/include/mach/dcache.h | 26 + arch/arm/mach-ux500/include/mach/devices.h | 1 + drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/hwmem/Kconfig | 7 + drivers/misc/hwmem/Makefile | 3 + drivers/misc/hwmem/cache_handler.c | 510 ++ drivers/misc/hwmem/cache_handler.h | 61 +++ drivers/misc/hwmem/hwmem-ioctl.c | 455 drivers/misc/hwmem/hwmem-main.c | 799 include/linux/hwmem.h | 536 +++ 15 files changed, 2699 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-ux500/dcache.c create mode 100644 arch/arm/mach-ux500/include/mach/dcache.h create mode 100644 drivers/misc/hwmem/Kconfig create mode 100644 drivers/misc/hwmem/Makefile create mode 100644 drivers/misc/hwmem/cache_handler.c create mode 100644 drivers/misc/hwmem/cache_handler.h create mode 100644 drivers/misc/hwmem/hwmem-ioctl.c create mode 100644 drivers/misc/hwmem/hwmem-main.c create mode 100644 include/linux/hwmem.h -- 1.7.4.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- 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
Question on OpenCV camera support
Hi, I'm seeing that when using OpenCV there is no way to query video camera capabilities from within the API, you need to go straight into V4L stuff to get that info. I did a patch for enabling such capabilities but I'm looking into the appropriate forum for submitting the code, does anyone here can point me to the right forum/persons to achieve that? Thanks, Ignacio -- 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
Warsaw brainstorm meeting: be prepared!
Hi all! The last information I have indicates that we may have up to 14 developers attending the meeting. This is quite a large group for a brainstorming meeting. So in order to prevent chaos I would like to ask all participants to prepare for the meeting: - if your company has multiple participants present, then try to assign one spokesperson for each topic (or possibly subtopic). - Prepare by going through any links that are provided in the agende for each topic that is relevant for you. - Prepare your own ideas that you have for each relevant topic. We thought about having two tracks for parts of the meeting, but some key people need to be involved in pretty much all topics, so that doesn't work. Marek, it would be nice though if there is a second room available where a smaller group can discuss something separate from the main group. I don't know whether it will be needed or not, but it might be helpful. This weekend I will post the final agenda (although at the meeting itself we can add (small) items if necessary). The final agenda will be very close to the draft, though. See you all in Warsaw! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
