RE: [PATCH v2 2/8] ARM: S5PV310: Add clock support for MFC v5.1
Jeongtae Park wrote:
>
> This patch adds clock support for MFC v5.1.
>
> Reviewed-by: Peter Oh
> Signed-off-by: Jeongtae Park
> Cc: Marek Szyprowski
> Cc: Kamil Debski
> ---
> 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_TOP0 S5P_CLKREG(0x0C210)
> #define S5P_CLKSRC_TOP1 S5P_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_LCD0 S5P_CLKREG(0x0C234)
> #define S5P_CLKSRC_LCD1 S5P_CLKREG(0x0C238)
> @@ -42,6 +43,7 @@
>
> #define S5P_CLKDIV_TOP
RE: [RFC/PATCH v7 2/5] MFC: Add MFC 5.1 driver to plat-s5p
Kamil Debski wrote:
>
> This patch adds platform support for Multi Format Codec 5.1.
> MFC 5.1 is capable of handling a range of video codecs and this driver
> provides V4L2 interface for video decoding.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-s5pv310/clock.c | 28 -
> arch/arm/mach-s5pv310/include/mach/map.h|2 +
> arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
> arch/arm/plat-s5p/Kconfig |5 ++
> arch/arm/plat-s5p/Makefile |2 +-
> arch/arm/plat-s5p/dev-mfc.c | 49
> +++
> arch/arm/plat-samsung/include/plat/devs.h |1 +
> 7 files changed, 88 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/plat-s5p/dev-mfc.c
>
> diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
> index f142b8c..d28fa6f 100644
> --- a/arch/arm/mach-s5pv310/clock.c
> +++ b/arch/arm/mach-s5pv310/clock.c
> @@ -523,6 +523,11 @@ static struct clk init_clocks_off[] = {
> .enable = s5pv310_clk_ip_lcd1_ctrl,
> .ctrlbit= (1 << 0),
> }, {
> + .name = "mfc",
> + .id = -1,
> + .enable = s5pv310_clk_ip_mfc_ctrl,
Where is "s5pv310_clk_ip_mfc_ctrl" in your patch or mainline?
Please make sure that your patch can be applied into current maintainer's
tree before submitting.
> + .ctrlbit= (1 << 0),
> + }, {
> .name = "hsmmc",
> .id = 0,
> .parent = &clk_aclk_133.clk,
> @@ -734,6 +739,18 @@ static struct clksrc_sources clkset_group = {
> .nr_sources = ARRAY_SIZE(clkset_group_list),
> };
>
> +static struct clk *clkset_group1_list[] = {
What group1? We can know it is used for MFC now, but if there is in just
clock.c, can't do it.
> + [0] = &clk_mout_mpll.clk,
> + [1] = &clk_sclk_apll.clk,
> + [2] = &clk_mout_epll.clk,
> + [3] = &clk_sclk_vpll.clk,
As you know, above sources are not connected to one same MUX, so should be
separated.
> +};
> +
> +static struct clksrc_sources clkset_group1 = {
> + .sources= clkset_group1_list,
> + .nr_sources = ARRAY_SIZE(clkset_group1_list),
> +};
> +
> static struct clk *clkset_mout_g2d0_list[] = {
> [0] = &clk_mout_mpll.clk,
> [1] = &clk_sclk_apll.clk,
> @@ -1076,7 +1093,16 @@ static struct clksrc_clk clksrcs[] = {
> .ctrlbit= (1 << 16),
> },
> .reg_div = { .reg = S5P_CLKDIV_FSYS3, .shift = 8, .size = 8
},
> - }
> + }, {
> + .clk= {
> + .name = "sclk_mfc",
> + .id = -1,
> + },
> + .sources = &clkset_group1,
> + .reg_src = { .reg = S5P_CLKSRC_MFC, .shift = 8, .size = 1 },
> + .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
> + },
> +
> };
>
> /* Clock initialization code */
> diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-
> s5pv310/include/mach/map.h
> index 0db3a47..576ba55 100644
> --- a/arch/arm/mach-s5pv310/include/mach/map.h
> +++ b/arch/arm/mach-s5pv310/include/mach/map.h
> @@ -29,6 +29,7 @@
> #define S5PV310_PA_FIMC1 0x1181
> #define S5PV310_PA_FIMC2 0x1182
> #define S5PV310_PA_FIMC3 0x1183
> +#define S5PV310_PA_MFC 0x1340
> #define S5PV310_PA_I2S0 0x0383
> #define S5PV310_PA_I2S1 0xE310
> #define S5PV310_PA_I2S2 0xE2A0
> @@ -129,6 +130,7 @@
> #define S5P_PA_FIMC1 S5PV310_PA_FIMC1
> #define S5P_PA_FIMC2 S5PV310_PA_FIMC2
> #define S5P_PA_FIMC3 S5PV310_PA_FIMC3
> +#define S5P_PA_MFC S5PV310_PA_MFC
> #define S5P_PA_ONENAND S5PC210_PA_ONENAND
> #define S5P_PA_ONENAND_DMA S5PC210_PA_ONENAND_DMA
> #define S5P_PA_SDRAM S5PV310_PA_SDRAM
> diff --git a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
b/arch/arm/mach-
> s5pv310/include/mach/regs-clock.h
> index 9ef5f0c..f6b8181 100644
> --- a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
> +++ b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
> @@ -176,4 +176,7 @@
>
> #define S5P_EPLL_CON S5P_EPLL_CON0
>
> +/* MFC related */
> +#define S5P_CLKSRC_MFC S5P_CLKREG(0x0C228)
> +#define S5P_CLKDIV_MFC S5P_CLKREG(0x0C528)
> #endif /* __ASM_ARCH_REGS_CLOCK_H */
> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
> index 4166964..ea9032e 100644
> --- a/arch/arm/plat-s5p/Kconfig
> +++ b/arch/arm/plat-s5p/Kconfig
> @@ -5,6 +5,11 @@
> #
> # Licensed under GPLv2
>
> +config S5P_DEV_MFC
Re: [RFC] HDMI-CEC proposal, ver 2
Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: > Not every tx status is applicable for all modes, see table 1. > > |-| > |Av link Mode | CEC | 1 | 2 | 3 | > |-| > | Status | | | | | > |-| > | TX_OK | a | n/a | a | n/a | > |-| > | TX_ARB_LOST| a | n/a | a | a | > |-| > | TX_RETRY_TIMEOUT| a | n/a | a | a | > |-| > | TX_BROADCAST_REJECT | a | n/a | a | n/a | > |-| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. > * AV link mode 1: > In mode 1 the frame length is fixed to 21 bits (including the > start sequence). > Some of these bits (Qty 1 - 6) can be arbitrated by the > receiver to signal supported formats/standards. > conf: > enable: true/false > upstream_Qty: QTY bits 1-6 > downstream_Qty: QTY bits 1-6 > || > | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | > || > | Qty bits | x| x | 6 | 5 | 4 | 3 | 2 | 1 | > || > Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... > * AV link mode 1: > Frame received/transmitted: > head: > |-| > | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | > |-| > | head bits: |x | DIR | /PAS | /NAS | /DES | > |-| > Qty: Quality bits 1 - 16; > |---| > | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | > |---| > | Qty bits |x| 16 | 15 - 2 | 1 | > |---| > x: not used Is Qty-1 or Qty-16 the bit sent after /DES? > In blocking mode only: > tx_status: tx status. > tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated > during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. > * AV link mode 3: TBD. Chances are that nobody ever used this > len: length of message in bits, maximum 96 bits. > msg: the raw message received/transmitted. (without the start > sequence). > tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Daniel -- 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: Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I'll add the following kernel debug info for what it's worth: - Mar 12 11:22:51 mythtv kernel: [ 14.025097] saa7130/34: v4l2 driver version 0.2.16 loaded Mar 12 11:22:51 mythtv kernel: [ 14.026609] saa7134 :00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Mar 12 11:22:51 mythtv kernel: [ 14.026617] saa7133[0]: found at :00:09.0, rev: 209, irq: 17, latency: 32, mmio: 0xec00 Mar 12 11:22:51 mythtv kernel: [ 14.026625] saa7133[0]: subsystem: 1043:4857, board: Asus Tiger Rev:1.00 [card=152,autodetected] Mar 12 11:22:51 mythtv kernel: [ 14.026649] saa7133[0]: board init: gpio is 0 Mar 12 11:22:51 mythtv kernel: [ 14.200257] saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Mar 12 11:22:51 mythtv kernel: [ 14.200268] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200279] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 b6 ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200288] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200298] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200307] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200316] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200326] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200335] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200344] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200354] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200363] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200372] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200382] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200391] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200400] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.660189] tuner 1-004b: chip found @ 0x96 (saa7133[0]) Mar 12 11:22:56 mythtv kernel: [ 21.620280] saa7133[0]: registered device video0 [v4l2] Mar 12 11:22:56 mythtv kernel: [ 21.620403] saa7133[0]: registered device vbi0 Mar 12 11:22:56 mythtv kernel: [ 21.620513] saa7133[0]: registered device radio0 Mar 12 11:23:03 mythtv kernel: [ 28.860185] DVB: registering new adapter (saa7133[0]) - Now on the latest reboot I am getting the below. - Mar 12 11:24:13 mythtv kernel: [ 98.240211] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... Mar 12 11:24:13 mythtv kernel: [ 98.48] tda1004x: setting up plls for 48MHz sampling clock Mar 12 11:24:15 mythtv kernel: [ 100.930007] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:15 mythtv kernel: [ 100.930012] tda1004x: trying to boot from eeprom Mar 12 11:24:16 mythtv kernel: [ 101.180011] tda1004x: found firmware revision 80 -- invalid Mar 12 11:24:16 mythtv kernel: [ 101.180017] tda1004x: firmware upload failed Mar 12 11:24:16 mythtv kernel: [ 102.14] tda1004x: setting up plls for 48MHz sampling clock Mar 12 11:24:18 mythtv kernel: [ 103.480013] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:18 mythtv kernel: [ 103.480018] tda1004x: waiting for firmware upload... Mar 12 11:24:19 mythtv kernel: [ 104.780010] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:19 mythtv kernel: [ 104.780015] tda1004x: trying to boot from eeprom Mar 12 11:24:22 mythtv kernel: [ 107.400011] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:22 mythtv kernel: [ 107.400016] tda1004x: waiting for firmware upload... Mar 12 11:25:22 mythtv kernel: [ 167.160013] tda1004x: found firmware revision 0 -- invalid Mar 12 11:25:22 mythtv kernel: [ 167.160021] tda1004x: firmware upload failed Mar 12 11:25:25 mythtv kernel: [ 170.840045] tda1004x: found firmware revision 80 -- invalid Mar 12 11:25:25 mythtv kernel: [ 170.840051] tda1004x: firmware upload failed -- A previous boot up had the card reporting: Nothing has changed between power cycles. - Mar 12 09:22:15 mythtv kernel: [ 67.010115] DVB: registering new adapter (saa7133[1]) Mar 12 09:22:15 mythtv kernel: [ 67.010121] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... Mar 12 09:22:15 mythtv kernel: [ 67.170007] tda1004x: setting up plls for 48MHz sampling clock Mar 12 09:22:17 myt
RE: [PATCH 1/7] ARM: S5PV310: Add platform definitions for FIMC
Marek Szyprowski wrote: > > From: Sylwester Nawrocki > > Add support for fourth FIMC platform device definition and define > resources for FIMC modules on S5PV310 machines. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > Signed-off-by: Marek Szyprowski > --- > arch/arm/mach-s5pv310/cpu.c|7 > arch/arm/mach-s5pv310/include/mach/irqs.h |4 ++ > arch/arm/mach-s5pv310/include/mach/map.h |8 > arch/arm/plat-s5p/Kconfig |5 +++ > arch/arm/plat-s5p/Makefile |1 + > arch/arm/plat-s5p/dev-fimc3.c | 43 > > arch/arm/plat-samsung/include/plat/devs.h |1 + > arch/arm/plat-samsung/include/plat/fimc-core.h |5 +++ > 8 files changed, 74 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/plat-s5p/dev-fimc3.c > > diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c > index 0db0fb6..0bdb0b0 100644 > --- a/arch/arm/mach-s5pv310/cpu.c > +++ b/arch/arm/mach-s5pv310/cpu.c > @@ -21,6 +21,8 @@ > #include > #include > #include > +#include > +#include > > #include > > @@ -114,6 +116,11 @@ void __init s5pv310_map_io(void) > s5pv310_default_sdhci1(); > s5pv310_default_sdhci2(); > s5pv310_default_sdhci3(); > + > + s3c_fimc_setname(0, "s5pv310-fimc"); > + s3c_fimc_setname(1, "s5pv310-fimc"); > + s3c_fimc_setname(2, "s5pv310-fimc"); > + s3c_fimc_setname(3, "s5pv310-fimc"); > } > > void __init s5pv310_init_clocks(int xtal) > diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach- > s5pv310/include/mach/irqs.h > index 536b0b5..0e99968 100644 > --- a/arch/arm/mach-s5pv310/include/mach/irqs.h > +++ b/arch/arm/mach-s5pv310/include/mach/irqs.h > @@ -107,6 +107,10 @@ > > #define IRQ_MIPI_CSIS0 COMBINER_IRQ(30, 0) > #define IRQ_MIPI_CSIS1 COMBINER_IRQ(30, 1) > +#define IRQ_FIMC0COMBINER_IRQ(32, 0) > +#define IRQ_FIMC1COMBINER_IRQ(32, 1) > +#define IRQ_FIMC2COMBINER_IRQ(33, 0) > +#define IRQ_FIMC3COMBINER_IRQ(33, 1) > > #define IRQ_ONENAND_AUDI COMBINER_IRQ(34, 0) > > diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach- > s5pv310/include/mach/map.h > index 901657f..0db3a47 100644 > --- a/arch/arm/mach-s5pv310/include/mach/map.h > +++ b/arch/arm/mach-s5pv310/include/mach/map.h > @@ -25,6 +25,10 @@ > > #define S5PV310_PA_SYSRAM0x02025000 > > +#define S5PV310_PA_FIMC0 0x1180 > +#define S5PV310_PA_FIMC1 0x1181 > +#define S5PV310_PA_FIMC2 0x1182 > +#define S5PV310_PA_FIMC3 0x1183 > #define S5PV310_PA_I2S0 0x0383 > #define S5PV310_PA_I2S1 0xE310 > #define S5PV310_PA_I2S2 0xE2A0 > @@ -121,6 +125,10 @@ > #define S5P_PA_CHIPIDS5PV310_PA_CHIPID > #define S5P_PA_MIPI_CSIS0S5PV310_PA_MIPI_CSIS0 > #define S5P_PA_MIPI_CSIS1S5PV310_PA_MIPI_CSIS1 > +#define S5P_PA_FIMC0 S5PV310_PA_FIMC0 > +#define S5P_PA_FIMC1 S5PV310_PA_FIMC1 > +#define S5P_PA_FIMC2 S5PV310_PA_FIMC2 > +#define S5P_PA_FIMC3 S5PV310_PA_FIMC3 > #define S5P_PA_ONENAND S5PC210_PA_ONENAND > #define S5P_PA_ONENAND_DMA S5PC210_PA_ONENAND_DMA > #define S5P_PA_SDRAM S5PV310_PA_SDRAM > diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig > index 557f8c5..0db2a7a 100644 > --- a/arch/arm/plat-s5p/Kconfig > +++ b/arch/arm/plat-s5p/Kconfig > @@ -60,6 +60,11 @@ config S5P_DEV_FIMC2 > help > Compile in platform device definitions for FIMC controller 2 > > +config S5P_DEV_FIMC3 > + bool > + help > + Compile in platform device definitions for FIMC controller 3 > + > config S5P_DEV_ONENAND > bool > help > diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile > index ce5a0a7..cfcd1db 100644 > --- a/arch/arm/plat-s5p/Makefile > +++ b/arch/arm/plat-s5p/Makefile > @@ -28,6 +28,7 @@ obj-$(CONFIG_SUSPEND) += 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_FIMC3) += dev-fimc3.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-fimc3.c b/arch/arm/plat-s5p/dev-fimc3.c > new file mode 100644 > index 000..ef31bec > --- /dev/null > +++ b/arch/arm/plat-s5p/dev-fimc3.c > @@ -0,0 +1,43 @@ > +/* linux/arch/arm/plat-s5p/dev-fimc3.c > + * > + * Copyright (c) 2010 Samsung Electronics > + * > + * Base S5P FIMC3 resource and device definitions > + * > + * This program is free software; you
Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I just bought a pair of what are a version of the My Cinema 7131 Hybrid cards. The kernel reports it as saa7134: Asus Tiger revision 1.0, subsys 1043:4857 I did inititially try Mythbuntu 10.04 but the firmware upload seemed to fail fairly consistently. Restarting with v10.10 the firmware loads but I can't seem to scan the channels with Mythbackend - it has a 0% signal and 100% signal to noise. I am using MythTV 0.24 with Avenard's latest patches. This version of the card has written on the silkscreen Tiger rev 3.02, a sticker that says Tiger_8M AA.F7.C0.01 (which would appear to be the latest firmware for this card on Asus's support site) but there is only one RF connector on CON1. CON2 is not fitted nor is the IR receiver. Now I saw mentioned on a list that to get DVB working on this card in Linux you need to connect the TV antenna to the FM port, which I suspect is the one not fitted. The latest Windows drivers for this card is circa 2009. Two questions: - Is there some sort of SAA7134 module argument I need to use to get this particular card working on the TV RF input? - Why does the kernel show the firmware is being reloaded every time MythTV seems to want to talk to the card? This slows down access as it seems to take about 30 seconds for the firmware to install each time. I am happy to provide whatever debug dumps or more info if need be. -- 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 Fri, Mar 11, 2011 at 6:30 PM, wrote: > >> Doesn't seem weird to me at all. This is a pretty uncommon card, so >> it is entirely possible that many revisions could go by without >> someone noticing a regression. I know for example that the HVR-1500Q >> (the US version of that board) was broken for months and nobody >> noticed. > > Well. How was it solved at the hvr-1500q? :) Any other information i > could provide maybe? It's not clear to me that it ever was resolved for the 1500q. If the goal is for it to get fixed, it's usually a matter of getting a sample unit in the hands of a developer who knows how to debug the issue. A common problem is the lack of overlap between people who have the board versus people who know what to do with it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV 1400 broken with recent versions?
> Doesn't seem weird to me at all. This is a pretty uncommon card, so > it is entirely possible that many revisions could go by without > someone noticing a regression. I know for example that the HVR-1500Q > (the US version of that board) was broken for months and nobody > noticed. Well. How was it solved at the hvr-1500q? :) Any other information i could provide maybe? -- 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 Fri, Mar 11, 2011 at 6:04 PM, wrote: > > Hey, > > i tried to revert that patch manually (e.g. switching into the directory, > vim cx23885-i2c.c, removing the stuff which was added), then "make clean" > "make distclean" followed by "./build.sh" then make rmmod, then plugged in > the card, dmesg shows it loaded the card correctly, all fine, then i did > ./scan Scanlist.txt and i get the same i2c related errors. Did a reboot > just to verify, still getting those, scan gives no results always "tuning > failed". > > Then i reverted another patch (just to make sure.. > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commit;h=f4acb3c4ccca74f5448354308f917e87ce83505a) > - However, this didn't help. So, the problem might be somewhere else. > > I did some more research and it seems i'm not the only one with those > issues, tho nearly none gets answers regarding this trouble, e.g.: > > (same card - also expresscard, december 2010) > http://www.spinics.net/lists/linux-media/msg27042.html > (not the same card, tho similar error, hvr 1500, i got hvr 1400 - februar > 2009) > http://www.linuxtv.org/pipermail/linux-dvb/2009-February/031839.html > > I'm running out of ideas where the problem might be located. i also tried > to switch the firmware by extracting the firmware manually, didn't help. > There's a low power version and another one available, tried to replace, > didn't work neither. > > So it seems, this driver is broken at least since december 2010. Totally > weird why there's such a mess, i know for sure that this WAS working. Doesn't seem weird to me at all. This is a pretty uncommon card, so it is entirely possible that many revisions could go by without someone noticing a regression. I know for example that the HVR-1500Q (the US version of that board) was broken for months and nobody noticed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV 1400 broken with recent versions?
Hey, i tried to revert that patch manually (e.g. switching into the directory, vim cx23885-i2c.c, removing the stuff which was added), then "make clean" "make distclean" followed by "./build.sh" then make rmmod, then plugged in the card, dmesg shows it loaded the card correctly, all fine, then i did ./scan Scanlist.txt and i get the same i2c related errors. Did a reboot just to verify, still getting those, scan gives no results always "tuning failed". Then i reverted another patch (just to make sure.. http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commit;h=f4acb3c4ccca74f5448354308f917e87ce83505a) - However, this didn't help. So, the problem might be somewhere else. I did some more research and it seems i'm not the only one with those issues, tho nearly none gets answers regarding this trouble, e.g.: (same card - also expresscard, december 2010) http://www.spinics.net/lists/linux-media/msg27042.html (not the same card, tho similar error, hvr 1500, i got hvr 1400 - februar 2009) http://www.linuxtv.org/pipermail/linux-dvb/2009-February/031839.html I'm running out of ideas where the problem might be located. i also tried to switch the firmware by extracting the firmware manually, didn't help. There's a low power version and another one available, tried to replace, didn't work neither. So it seems, this driver is broken at least since december 2010. Totally weird why there's such a mess, i know for sure that this WAS working. Anyone, any idea? Maybe something wrong configured in kernel? Might running native 64bit the cause (no multilib/32bit compat libs here)? > I knew this all seemed too familiar... :) > > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commit;h=67914b5c400d6c213f9e56d7547a2038ab5c06f4 > > Its already being reverted for 2.6.38 final (hopefully -- Mauro included > that in the pull req sent to Linus today). -- 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: compilation warnings/errors
On Fri, 11 Mar 2011, Mauro Carvalho Chehab wrote: > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c: In function 'pvr2_v4l2_do_ioctl': > /home/mchehab/new_build/v4l/pvrusb2-v4l2.c:798:23: warning: variable 'cap' > set but not used [-Wunused-but-set-variable] I will look into these. I'm a little puzzled right now since silly stuff like this usually doesn't get by me. Unfortunately I can't look at it right this minute. Expect to hear from me on Sunday. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] Ngene cam device name
Andreas Oberritter wrote: On 03/10/2011 04:29 PM, Issa Gorissen wrote: As the cxd20099 driver is in staging due to abuse of the sec0 device, this patch renames it to cam0. The sec0 device is not in use and can be removed That doesn't solve anything. Besides, your patch doesn't even do what you describe. Wouldn't it be possible to extend the current CA API? If not, shouldn't a new API be created that covers both old and new requirements? It's rather unintuitive that some CAMs appear as ca0, while others as cam0. Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write transport stream. To me it looks like an extension of the current API. The sec name needs changing obviously, but there seem to be some other problems too. If it was that easy to fix, it wouldn't be in staging today. Regards, Andreas Regards, Martin -- 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] Ngene cam device name
Andreas Oberritter writes: > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote: > > Now, according to Mauro comments, he has put this code into staging > > because of > > the usage of sec0 name for a cam device. > > > > Please comment on Oliver's explanations from this thread > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html > > Oliver explained that he's not going to put work into this driver, > because he's not using it. > > Until now, I haven't heard any reasons for just adding another device > node other than it being easier than defining a proper interface. The > fact that a solution "just works as is" is not sufficient to move a > driver from staging. IMO the CI driver should not have been included at > all in its current shape. Unless you want to move the writing to/reading from the CI module into ioctls of the ci device you need another node. Even nicer would be having the control messages moved to ioctls and the TS IO in read/write of ci, but this would break the old interface. What kind of proper interface were you thinking about? Regarding usage of dvr/demux mentioned in the linked thread above, this would add major overhead and lots more nodes. You would need dvr0/demux0 for output and dvr1/demux1 for input and both would PID-filter the stream yet again although it probably already was when being read from the demux or dvr device belonging to the tuner. Regards, Ralph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.39] One more docbook fix
With this fix the spec compiles without any errors. Regards, Hans The following changes since commit 41f3becb7bef489f9e8c35284dd88a1ff59b190c: [media] V4L DocBook: update V4L2 version (2011-03-11 18:09:02 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (1): Fix 'ID nv12mt already defined' error Documentation/DocBook/v4l/pixfmt-nv12mt.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 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
Re: [PATCH] Ngene cam device name
>> On 03/10/2011 04:29 PM, Issa Gorissen wrote: >>> As the cxd20099 driver is in staging due to abuse of the sec0 device, > this >>> patch renames it to cam0. The sec0 device is not in use and can be > removed >> >> That doesn't solve anything. Besides, your patch doesn't even do what >> you describe. >> >> Wouldn't it be possible to extend the current CA API? If not, shouldn't >> a new API be created that covers both old and new requirements? >> >> It's rather unintuitive that some CAMs appear as ca0, while others as cam0. >> >> If it was that easy to fix, it wouldn't be in staging today. >> >> Regards, >> Andreas > > > Yes indeed, this patch is missing the update of dnames arrays in dvbdev.c > > Now, according to Mauro comments, he has put this code into staging because of > the usage of sec0 name for a cam device. > > Please comment on Oliver's explanations from this thread > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html Oliver explained that he's not going to put work into this driver, because he's not using it. Until now, I haven't heard any reasons for just adding another device node other than it being easier than defining a proper interface. The fact that a solution "just works as is" is not sufficient to move a driver from staging. IMO the CI driver should not have been included at all in its current shape. Regards, Andreas -- 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 v3 0/2] omap: iovmm: Fix IOVMM check for fixed 'da'
* David Cohen [110309 01:16]: > 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. Applying these. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] cpia2: Fix some gcc 4.6 warnings when debug is disabled
cpia2_core.c:529:14: warning: variable 'dir' set but not used
[-Wunused-but-set-variable]
cpia2_core.c:526:5: warning: variable 'block_index' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cpia2/cpia2_core.c
b/drivers/media/video/cpia2/cpia2_core.c
index aaffca8..ee91e29 100644
--- a/drivers/media/video/cpia2/cpia2_core.c
+++ b/drivers/media/video/cpia2/cpia2_core.c
@@ -519,22 +519,16 @@ int cpia2_do_command(struct camera_data *cam,
* cpia2_send_command
*
*/
+
+#define DIR(cmd) ((cmd->direction == TRANSFER_WRITE) ? "Write" : "Read")
+#define BINDEX(cmd) (cmd->req_mode & 0x03)
+
int cpia2_send_command(struct camera_data *cam, struct cpia2_command *cmd)
{
u8 count;
u8 start;
- u8 block_index;
u8 *buffer;
int retval;
- const char* dir;
-
- if (cmd->direction == TRANSFER_WRITE) {
- dir = "Write";
- } else {
- dir = "Read";
- }
-
- block_index = cmd->req_mode & 0x03;
switch (cmd->req_mode & 0x0c) {
case CAMERAACCESS_TYPE_RANDOM:
@@ -542,32 +536,32 @@ int cpia2_send_command(struct camera_data *cam, struct
cpia2_command *cmd)
start = 0;
buffer = (u8 *) & cmd->buffer;
if (debugs_on & DEBUG_REG)
- DBG("%s Random: Register block %s\n", dir,
- block_name[block_index]);
+ DBG("%s Random: Register block %s\n", DIR(cmd),
+ block_name[BINDEX(cmd)]);
break;
case CAMERAACCESS_TYPE_BLOCK:
count = cmd->reg_count;
start = cmd->start;
buffer = cmd->buffer.block_data;
if (debugs_on & DEBUG_REG)
- DBG("%s Block: Register block %s\n", dir,
- block_name[block_index]);
+ DBG("%s Block: Register block %s\n", DIR(cmd),
+ block_name[BINDEX(cmd)]);
break;
case CAMERAACCESS_TYPE_MASK:
count = cmd->reg_count * sizeof(struct cpia2_reg_mask);
start = 0;
buffer = (u8 *) & cmd->buffer;
if (debugs_on & DEBUG_REG)
- DBG("%s Mask: Register block %s\n", dir,
- block_name[block_index]);
+ DBG("%s Mask: Register block %s\n", DIR(cmd),
+ block_name[BINDEX(cmd)]);
break;
case CAMERAACCESS_TYPE_REPEAT: /* For patch blocks only */
count = cmd->reg_count;
start = cmd->start;
buffer = cmd->buffer.block_data;
if (debugs_on & DEBUG_REG)
- DBG("%s Repeat: Register block %s\n", dir,
- block_name[block_index]);
+ DBG("%s Repeat: Register block %s\n", DIR(cmd),
+ block_name[BINDEX(cmd)]);
break;
default:
LOG("%s: invalid request mode\n",__func__);
@@ -584,10 +578,10 @@ int cpia2_send_command(struct camera_data *cam, struct
cpia2_command *cmd)
for (i = 0; i < cmd->reg_count; i++) {
if((cmd->req_mode & 0x0c) == CAMERAACCESS_TYPE_BLOCK)
KINFO("%s Block: [0x%02X] = 0x%02X\n",
- dir, start + i, buffer[i]);
+ DIR(cmd), start + i, buffer[i]);
if((cmd->req_mode & 0x0c) == CAMERAACCESS_TYPE_RANDOM)
KINFO("%s Random: [0x%02X] = 0x%02X\n",
- dir, cmd->buffer.registers[i].index,
+ DIR(cmd), cmd->buffer.registers[i].index,
cmd->buffer.registers[i].value);
}
}
--
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 1/2] [media] several drivers: Fix a few gcc 4.6 warnings
au0828-dvb.c:99:6: warning: variable 'ptr' set but not used
[-Wunused-but-set-variable]
au0828-video.c:1180:25: warning: variable 'maxheight' set but not used
[-Wunused-but-set-variable]
au0828-video.c:1180:15: warning: variable 'maxwidth' set but not used
[-Wunused-but-set-variable]
bttv-input.c:196:16: warning: variable 'current_jiffies' set but not used
[-Wunused-but-set-variable]
Those variables are not used at all, so just remove them.
Cc: Steven Toth
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/au0828/au0828-dvb.c
b/drivers/media/video/au0828/au0828-dvb.c
index f1edf1d..5182167 100644
--- a/drivers/media/video/au0828/au0828-dvb.c
+++ b/drivers/media/video/au0828/au0828-dvb.c
@@ -96,7 +96,6 @@ static struct tda18271_config hauppauge_woodbury_tunerconfig
= {
/*---*/
static void urb_completion(struct urb *purb)
{
- u8 *ptr;
struct au0828_dev *dev = purb->context;
int ptype = usb_pipetype(purb->pipe);
@@ -114,8 +113,6 @@ static void urb_completion(struct urb *purb)
return;
}
- ptr = (u8 *)purb->transfer_buffer;
-
/* Feed the transport payload into the kernel demux */
dvb_dmx_swfilter_packets(&dev->dvb.demux,
purb->transfer_buffer, purb->actual_length / 188);
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index 9c475c6..6ad83a1 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1177,10 +1177,6 @@ static int au0828_set_format(struct au0828_dev *dev,
unsigned int cmd,
int ret;
int width = format->fmt.pix.width;
int height = format->fmt.pix.height;
- unsigned int maxwidth, maxheight;
-
- maxwidth = 720;
- maxheight = 480;
if (format->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index e8b64bc..677d70c 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -193,12 +193,10 @@ static void bttv_rc5_timer_end(unsigned long data)
{
struct bttv_ir *ir = (struct bttv_ir *)data;
struct timeval tv;
- unsigned long current_jiffies;
u32 gap;
u32 rc5 = 0;
/* get time */
- current_jiffies = jiffies;
do_gettimeofday(&tv);
/* avoid overflow with gap >1s */
--
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
Re: [cron job] v4l-dvb daily build: ERRORS
Hi Sylwester, Pawel,
The daily build reports this warning when building for i686:
media_build/v4l/videobuf2-dma-contig.c: In function 'vb2_dma_contig_cookie':
media_build/v4l/videobuf2-dma-contig.c:81:9: warning: cast to pointer from
integer of different size
This refers to the void * cast in this function:
static void *vb2_dma_contig_cookie(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return (void *)buf->paddr;
}
buf->paddr is of type dma_addr_t.
The reason for the warning is that for this build CONFIG_ARCH_DMA_ADDR_T_64BIT
is set to 'y'. A dma_addr_t address can be 64 bit on a 32 bit architecture (and
vice versa). See the comments in include/asm-generic/types.h.
Can you take a look at this? This is potentially dangerous.
Regards,
Hans
On Friday, March 11, 2011 20:31:35 Hans Verkuil wrote:
> This message is generated daily by a cron job that builds v4l-dvb for
> the kernels and architectures in the list below.
>
> Results of the daily build of v4l-dvb:
>
> date:Fri Mar 11 19:00:45 CET 2011
> git hash:97c6bc5e15e60c0c15ff028c03af2cf42ad9a07e
> gcc version: i686-linux-gcc (GCC) 4.5.1
> host hardware:x86_64
> host os: 2.6.32.5
>
> linux-git-armv5: OK
> linux-git-armv5-davinci: OK
> linux-git-armv5-ixp: OK
> linux-git-armv5-omap2: OK
> linux-git-i686: OK
> linux-git-m32r: OK
> linux-git-mips: WARNINGS
> linux-git-powerpc64: OK
> linux-git-x86_64: OK
> linux-2.6.31.12-i686: WARNINGS
> linux-2.6.32.6-i686: WARNINGS
> linux-2.6.33-i686: WARNINGS
> linux-2.6.34-i686: WARNINGS
> linux-2.6.35.3-i686: WARNINGS
> linux-2.6.36-i686: WARNINGS
> linux-2.6.37-i686: WARNINGS
> linux-2.6.31.12-x86_64: WARNINGS
> linux-2.6.32.6-x86_64: WARNINGS
> linux-2.6.33-x86_64: WARNINGS
> linux-2.6.34-x86_64: WARNINGS
> linux-2.6.35.3-x86_64: WARNINGS
> linux-2.6.36-x86_64: WARNINGS
> linux-2.6.37-x86_64: WARNINGS
> spec-git: ERRORS
> sparse: ERRORS
>
> Detailed results are available here:
>
> http://www.xs4all.nl/~hverkuil/logs/Friday.log
>
> Full logs are available here:
>
> http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2
>
> The V4L-DVB specification failed to build, but the last compiled spec is here:
>
> http://www.xs4all.nl/~hverkuil/spec/media.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Mar 11 19:00:45 CET 2011 git hash:97c6bc5e15e60c0c15ff028c03af2cf42ad9a07e gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.39] DocBook validation fixes
The following changes since commit 97c6bc5e15e60c0c15ff028c03af2cf42ad9a07e: [media] altera-ci.h: add missing inline (2011-03-11 14:17:05 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (2): V4L doc fixes V4L DocBook: update V4L2 version. Documentation/DocBook/v4l/dev-subdev.xml | 46 +++--- .../DocBook/v4l/media-ioc-enum-entities.xml|6 +- Documentation/DocBook/v4l/subdev-formats.xml | 64 ++-- Documentation/DocBook/v4l/v4l2.xml |2 +- 4 files changed, 59 insertions(+), 59 deletions(-) -- 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
Re: compilation warnings/errors
Em 11-03-2011 16:20, Hans Verkuil escreveu: > On Friday, March 11, 2011 19:28:59 Mauro Carvalho Chehab wrote: >> Hi Hans/Matti >> >> I did a compilation of the media_build tree against Fedora Rawhide, to check >> what warnings are happening >> with gcc 4.6, as it is easier to me to just run a VM with Rawhide than to >> keep an updated set of gcc >> compiled by me on some place. >> >> The compilation, however, ended earlier due to some errors at TI WL1273 FM >> driver. >> >> I'm enclosing the warnings and errors when compiling media_build on Fedora >> rawhide. >> >> Rawhide kernel is 2.6.38-rc7 - 32 bits (probably plus some Fedora patches - >> in general, backports from the -next tree). >> >> I suspect that this could be due to some platform_data that might be at >> -next or at -rc7 that are not >> present on my tree, but it would be great to take a look on it, otherwise >> I'll may have problems when >> merging it upstream or submitting it to -next. > > radio-wl1273 depends on include/linux/mfd/wl1273-core.h. This header was > changed > for 2.6.39. Since this header is also used in drivers/mfd I think the best > approach is not to build this driver for 2.6.38. The alternative would be to > copy the header and drivers/mfd/wl1273-core.c as well and make sure it is > configured and compiled. IMHO it's not worth the effort for a platform driver. Agreed. > > Regards, > > Hans > >> >> Could you please take a look on it? >> >> Thanks! >> Mauro. >> >> >> /home/mchehab/new_build/v4l/au0828-dvb.c: In function 'urb_completion': >> /home/mchehab/new_build/v4l/au0828-dvb.c:99:6: warning: variable 'ptr' set >> but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/au0828-video.c: In function >> 'au0828_irq_callback': >> /home/mchehab/new_build/v4l/au0828-video.c:126:6: warning: variable 'rc' set >> but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/au0828-video.c: In function 'au0828_set_format': >> /home/mchehab/new_build/v4l/au0828-video.c:1180:25: warning: variable >> 'maxheight' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/au0828-video.c:1180:15: warning: variable >> 'maxwidth' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/bttv-input.c: In function 'bttv_rc5_timer_end': >> /home/mchehab/new_build/v4l/bttv-input.c:196:16: warning: variable >> 'current_jiffies' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cpia2_core.c: In function 'cpia2_send_command': >> /home/mchehab/new_build/v4l/cpia2_core.c:529:14: warning: variable 'dir' set >> but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cpia2_core.c:526:5: warning: variable >> 'block_index' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-alsa-main.c: In function 'cx18_alsa_exit': >> /home/mchehab/new_build/v4l/cx18-alsa-main.c:281:6: warning: variable 'ret' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function >> 'snd_cx18_pcm_capture_open': >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:156:6: warning: variable 'ret' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function >> 'snd_cx18_pcm_capture_close': >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:202:6: warning: variable 'ret' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function >> 'snd_cx18_pcm_hw_params': >> /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:255:6: warning: variable 'ret' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-streams.c: In function >> 'cx18_stop_v4l2_encode_stream': >> /home/mchehab/new_build/v4l/cx18-streams.c:786:16: warning: variable 'then' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx18-mailbox.c: In function 'cx18_api_call': >> /home/mchehab/new_build/v4l/cx18-mailbox.c:540:6: warning: variable 'state' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-audio.c: In function >> 'snd_cx231xx_hw_capture_params': >> /home/mchehab/new_build/v4l/cx231xx-audio.c:510:6: warning: variable 'ret' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-audio.c:509:31: warning: variable >> 'format' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-audio.c:509:25: warning: variable 'rate' >> set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-audio.c:509:15: warning: variable >> 'channels' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-audio.c: In function >> 'snd_cx231xx_capture_trigger': >> /home/mchehab/new_build/v4l/cx231xx-audio.c:572:6: warning: variable >> 'retval' set but not used [-Wunused-but-set-variable] >> /home/mchehab/new_build/v4l/cx231xx-video.c: In function 'cx231xx
Re: compilation warnings/errors
On Friday, March 11, 2011 19:28:59 Mauro Carvalho Chehab wrote: > Hi Hans/Matti > > I did a compilation of the media_build tree against Fedora Rawhide, to check > what warnings are happening > with gcc 4.6, as it is easier to me to just run a VM with Rawhide than to > keep an updated set of gcc > compiled by me on some place. > > The compilation, however, ended earlier due to some errors at TI WL1273 FM > driver. > > I'm enclosing the warnings and errors when compiling media_build on Fedora > rawhide. > > Rawhide kernel is 2.6.38-rc7 - 32 bits (probably plus some Fedora patches - > in general, backports from the -next tree). > > I suspect that this could be due to some platform_data that might be at -next > or at -rc7 that are not > present on my tree, but it would be great to take a look on it, otherwise > I'll may have problems when > merging it upstream or submitting it to -next. radio-wl1273 depends on include/linux/mfd/wl1273-core.h. This header was changed for 2.6.39. Since this header is also used in drivers/mfd I think the best approach is not to build this driver for 2.6.38. The alternative would be to copy the header and drivers/mfd/wl1273-core.c as well and make sure it is configured and compiled. IMHO it's not worth the effort for a platform driver. Regards, Hans > > Could you please take a look on it? > > Thanks! > Mauro. > > > /home/mchehab/new_build/v4l/au0828-dvb.c: In function 'urb_completion': > /home/mchehab/new_build/v4l/au0828-dvb.c:99:6: warning: variable 'ptr' set > but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/au0828-video.c: In function 'au0828_irq_callback': > /home/mchehab/new_build/v4l/au0828-video.c:126:6: warning: variable 'rc' set > but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/au0828-video.c: In function 'au0828_set_format': > /home/mchehab/new_build/v4l/au0828-video.c:1180:25: warning: variable > 'maxheight' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/au0828-video.c:1180:15: warning: variable > 'maxwidth' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/bttv-input.c: In function 'bttv_rc5_timer_end': > /home/mchehab/new_build/v4l/bttv-input.c:196:16: warning: variable > 'current_jiffies' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cpia2_core.c: In function 'cpia2_send_command': > /home/mchehab/new_build/v4l/cpia2_core.c:529:14: warning: variable 'dir' set > but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cpia2_core.c:526:5: warning: variable > 'block_index' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-alsa-main.c: In function 'cx18_alsa_exit': > /home/mchehab/new_build/v4l/cx18-alsa-main.c:281:6: warning: variable 'ret' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function > 'snd_cx18_pcm_capture_open': > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:156:6: warning: variable 'ret' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function > 'snd_cx18_pcm_capture_close': > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:202:6: warning: variable 'ret' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function > 'snd_cx18_pcm_hw_params': > /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:255:6: warning: variable 'ret' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-streams.c: In function > 'cx18_stop_v4l2_encode_stream': > /home/mchehab/new_build/v4l/cx18-streams.c:786:16: warning: variable 'then' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx18-mailbox.c: In function 'cx18_api_call': > /home/mchehab/new_build/v4l/cx18-mailbox.c:540:6: warning: variable 'state' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-audio.c: In function > 'snd_cx231xx_hw_capture_params': > /home/mchehab/new_build/v4l/cx231xx-audio.c:510:6: warning: variable 'ret' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-audio.c:509:31: warning: variable > 'format' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-audio.c:509:25: warning: variable 'rate' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-audio.c:509:15: warning: variable > 'channels' set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-audio.c: In function > 'snd_cx231xx_capture_trigger': > /home/mchehab/new_build/v4l/cx231xx-audio.c:572:6: warning: variable 'retval' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new_build/v4l/cx231xx-video.c: In function 'cx231xx_isoc_copy': > /home/mchehab/new_build/v4l/cx231xx-video.c:331:17: warning: variable 'outp' > set but not used [-Wunused-but-set-variable] > /home/mchehab/new
Re: What is the driver for "0c45:6413 Microdia" webcam?
Hi, On 03/11/2011 07:04 PM, Chen, Xianwen wrote: Hi there, I'm having a hard time locating the proper driver for "0c45:6413 Microdia" webcam. I consulted "Documentation/video4linux/gspca.txt", but didn't find such a device. The 6413 is a UVC compatible camera / controller from Microdia, as such it should use the uvcvideo driver. Basically on any modern Linux distribution, it should just work as soon as you plug it in. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter To: Issa Gorissen Cc: linux-media@vger.kernel.org, r...@metzlerbros.de Subject: Re: [PATCH] Ngene cam device name > On 03/10/2011 04:29 PM, Issa Gorissen wrote: > > As the cxd20099 driver is in staging due to abuse of the sec0 device, this > > patch renames it to cam0. The sec0 device is not in use and can be removed > > That doesn't solve anything. Besides, your patch doesn't even do what > you describe. > > Wouldn't it be possible to extend the current CA API? If not, shouldn't > a new API be created that covers both old and new requirements? > > It's rather unintuitive that some CAMs appear as ca0, while others as cam0. > > If it was that easy to fix, it wouldn't be in staging today. > > Regards, > Andreas Yes indeed, this patch is missing the update of dnames arrays in dvbdev.c Now, according to Mauro comments, he has put this code into staging because of the usage of sec0 name for a cam device. Please comment on Oliver's explanations from this thread http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html Thx -- Issa > > > Signed-off-by: Issa Gorissen > > --- > > drivers/media/dvb/dvb-core/dvbdev.h |2 +- > > drivers/media/dvb/ngene/ngene-core.c |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/dvb/dvb-core/dvbdev.h > > b/drivers/media/dvb/dvb-core/dvbdev.h > > index fcc6ae9..dcac27d 100644 > > --- a/drivers/media/dvb/dvb-core/dvbdev.h > > +++ b/drivers/media/dvb/dvb-core/dvbdev.h > > @@ -40,7 +40,7 @@ > > > > #define DVB_DEVICE_VIDEO 0 > > #define DVB_DEVICE_AUDIO 1 > > -#define DVB_DEVICE_SEC2 > > +#define DVB_DEVICE_CAM2 > > #define DVB_DEVICE_FRONTEND 3 > > #define DVB_DEVICE_DEMUX 4 > > #define DVB_DEVICE_DVR5 > > diff --git a/drivers/media/dvb/ngene/ngene-core.c > > b/drivers/media/dvb/ngene/ngene-core.c > > index 175a0f6..6be2d7c 100644 > > --- a/drivers/media/dvb/ngene/ngene-core.c > > +++ b/drivers/media/dvb/ngene/ngene-core.c > > @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan) > > set_transfer(&chan->dev->channel[2], 1); > > dvb_register_device(adapter, &chan->ci_dev, > > &ngene_dvbdev_ci, (void *) chan, > > - DVB_DEVICE_SEC); > > + DVB_DEVICE_CAM); > > if (!chan->ci_dev) > > goto err; > > } > > -- > > 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
compilation warnings/errors
Hi Hans/Matti I did a compilation of the media_build tree against Fedora Rawhide, to check what warnings are happening with gcc 4.6, as it is easier to me to just run a VM with Rawhide than to keep an updated set of gcc compiled by me on some place. The compilation, however, ended earlier due to some errors at TI WL1273 FM driver. I'm enclosing the warnings and errors when compiling media_build on Fedora rawhide. Rawhide kernel is 2.6.38-rc7 - 32 bits (probably plus some Fedora patches - in general, backports from the -next tree). I suspect that this could be due to some platform_data that might be at -next or at -rc7 that are not present on my tree, but it would be great to take a look on it, otherwise I'll may have problems when merging it upstream or submitting it to -next. Could you please take a look on it? Thanks! Mauro. /home/mchehab/new_build/v4l/au0828-dvb.c: In function 'urb_completion': /home/mchehab/new_build/v4l/au0828-dvb.c:99:6: warning: variable 'ptr' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/au0828-video.c: In function 'au0828_irq_callback': /home/mchehab/new_build/v4l/au0828-video.c:126:6: warning: variable 'rc' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/au0828-video.c: In function 'au0828_set_format': /home/mchehab/new_build/v4l/au0828-video.c:1180:25: warning: variable 'maxheight' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/au0828-video.c:1180:15: warning: variable 'maxwidth' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/bttv-input.c: In function 'bttv_rc5_timer_end': /home/mchehab/new_build/v4l/bttv-input.c:196:16: warning: variable 'current_jiffies' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cpia2_core.c: In function 'cpia2_send_command': /home/mchehab/new_build/v4l/cpia2_core.c:529:14: warning: variable 'dir' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cpia2_core.c:526:5: warning: variable 'block_index' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-alsa-main.c: In function 'cx18_alsa_exit': /home/mchehab/new_build/v4l/cx18-alsa-main.c:281:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function 'snd_cx18_pcm_capture_open': /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:156:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function 'snd_cx18_pcm_capture_close': /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:202:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-alsa-pcm.c: In function 'snd_cx18_pcm_hw_params': /home/mchehab/new_build/v4l/cx18-alsa-pcm.c:255:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-streams.c: In function 'cx18_stop_v4l2_encode_stream': /home/mchehab/new_build/v4l/cx18-streams.c:786:16: warning: variable 'then' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx18-mailbox.c: In function 'cx18_api_call': /home/mchehab/new_build/v4l/cx18-mailbox.c:540:6: warning: variable 'state' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-audio.c: In function 'snd_cx231xx_hw_capture_params': /home/mchehab/new_build/v4l/cx231xx-audio.c:510:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-audio.c:509:31: warning: variable 'format' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-audio.c:509:25: warning: variable 'rate' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-audio.c:509:15: warning: variable 'channels' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-audio.c: In function 'snd_cx231xx_capture_trigger': /home/mchehab/new_build/v4l/cx231xx-audio.c:572:6: warning: variable 'retval' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-video.c: In function 'cx231xx_isoc_copy': /home/mchehab/new_build/v4l/cx231xx-video.c:331:17: warning: variable 'outp' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-video.c: In function 'cx231xx_bulk_copy': /home/mchehab/new_build/v4l/cx231xx-video.c:434:17: warning: variable 'outp' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-video.c: In function 'cx231xx_reset_video_buffer': /home/mchehab/new_build/v4l/cx231xx-video.c:704:7: warning: variable 'outp' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-core.c: In function 'cx231xx_set_mode': /home/mchehab/new_build/v4l/cx231xx-core.c:696:6: warning: variable 'errCode' set but not used [-Wunused-but-set-variable] /home/mchehab/new_build/v4l/cx231xx-core.c: In function 'c
What is the driver for "0c45:6413 Microdia" webcam?
Hi there, I'm having a hard time locating the proper driver for "0c45:6413 Microdia" webcam. I consulted "Documentation/video4linux/gspca.txt", but didn't find such a device. Here is the lsusb output: Bus 001 Device 003: ID 0c45:6413 Microdia Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Any hint, please? Xianwen -- 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
Media Controller API: Thanks to all who worked on it!
Hi all! Today the Media Controller (and the OMAP3 driver that uses it!) was merged. This is a major achievement after approximately three years of work. I think I contacted Manju Hadli from Texas Instruments early 2008 and the first RFC was posted July 18th 2008: http://lists-archives.org/video4linux/23652-rfc-add-support-to-query-and-change-connections-inside-a-media-device.html After rereading this RFC I am pleased to say that it closely resembles the final version. The main difference is that the concept of 'media processors' morphed eventually into the sub-device concept. It was clear from the beginning that the only way the Media Controller could be implemented was if the V4L2 core framework (what little there was at the time) was substantially expanded. And the multiple incompatible APIs towards those i2c drivers had to be resolved first since that blocked much of the framework development and in turn the MC development. It took more than a year to get that sorted (mostly, there is still some work to be done for soc-camera drivers) and to create the required core framework components, but on September 10th 2009 the second version of the RFC was posted: http://www.mail-archive.com/linux-media@vger.kernel.org/msg09462.html This formed the foundation of the final version we have today. Laurent Pinchart took that and did all the hard work of actually implementing this for the OMAP3 driver on behalf of Nokia. I wanted to thank all of you who worked on this, and my special thanks go to Manju (for without our discussions in 2008 none of this would have happened), Laurent (for obvious reasons!), Sakari (for helping convince Nokia to fund this work) and of course Mauro (for brainstorming, reviewing and finally merging it!). We now have (I hope) a very strong framework to build on in the coming years. There is still much work to be done, but this was 'the big one' and I am very pleased to see this merged. Thank you! 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
Re: [PATCH] V4L: soc-camera: Add support for custom host mmap
On Tue, 8 Mar 2011, Sergio Aguirre wrote: > Hi Guennadi, > > On 03/08/2011 01:17 AM, Guennadi Liakhovetski wrote: > > Hi Sergio > > > > On Mon, 7 Mar 2011, Sergio Aguirre wrote: > > > > > This helps redirect mmap calls to custom memory managers which > > > already have preallocated space to use by the device. > > > > > > Otherwise, device might not support the allocation attempted > > > generically by videobuf. > > > > > > Signed-off-by: Sergio Aguirre > > > --- > > > drivers/media/video/soc_camera.c |7 ++- > > > include/media/soc_camera.h |2 ++ > > > 2 files changed, 8 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/media/video/soc_camera.c > > > b/drivers/media/video/soc_camera.c > > > index 59dc71d..d361ba0 100644 > > > --- a/drivers/media/video/soc_camera.c > > > +++ b/drivers/media/video/soc_camera.c [snip] > > > + if (ici->ops->mmap) > > > + err = ici->ops->mmap(&icd->vb_vidq, icd, vma); > > > + else > > > + err = videobuf_mmap_mapper(&icd->vb_vidq, vma); > > > > You're patching an old version of soc-camera. Please use a current one > > with support for videobuf2. Further, wouldn't it be possible for you to > > just replace the videobuf mmap_mapper() (videobuf2 q->mem_ops->mmap()) > > method? I am not sure how possible this is, maybe one of videobuf2 experts > > could help us? BTW, you really should be using the videobuf2 API. I looked a bit more at videobuf2. Wouldn't it satisfy your needs if you just provide an own struct vb2_mem_ops, copy all its fields from your required memory allocator, and only replace the .mmap method? Please, try, if this would work for you. Then you won't need any changes to soc_camera.c Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: soc-camera: Store negotiated buffer settings
On 03/11/2011 10:48 AM, Guennadi Liakhovetski wrote: On Fri, 11 Mar 2011, Sergio Aguirre wrote: Hi Guennadi, On 03/11/2011 10:36 AM, Guennadi Liakhovetski wrote: On Tue, 8 Mar 2011, Sergio Aguirre wrote: Hi Guennadi, On 03/08/2011 01:19 AM, Guennadi Liakhovetski wrote: On Mon, 7 Mar 2011, Sergio Aguirre wrote: This fixes the problem in which a host driver sets a personalized sizeimage or bytesperline field, and gets ignored when doing G_FMT. Can you tell what that personalised value is? Is it not covered by soc_mbus_bytes_per_line()? Maybe something like a JPEG format? In my case, my omap4_camera driver requires to have a bytesperline which is a multiple of 32, and sometimes (depending on the internal HW blocks used) a page aligned byte offset between lines. For example, I want to use such configuration that, for an NV12 buffer, I require a 4K offset between lines, so the vaues are: pix->bytesperline = PAGE_SIZE; pix->sizeimage = pix->bytesperline * height * 3 / 2; Which I filled in TRY_FMT/S_FMT ioctl calls. Ok, I think, I agree with this. Until now we didn't have drivers, that wanted to pad data. Even the pxa270 driver adjusts the frame format (see pxa_camera.c::pxa_camera_try_fmt() and the call to v4l_bound_align_image() there in the YUV422P case) to avoid padding, even though that's a different kind of padding - between planes. So, if line padding - as in your case - is indeed needed, I agree, that the correct way to support that is to implement driver-specific bytesperline and sizeimage calculations and, logically, those values should be used in soc_camera_g_fmt_vid_cap(). I'll just change your patch a bit - I'll use "u32" types instead of "__u32" - this is a kernel internal struct and we don't need user-space exported types. Ok, thanks. You're right about u32 type... my bad. So, I'll change that, rebase to: git://linuxtv.org/media_tree.gitstaging/for_v2.6.39 And resubmit for review. No problem. Np, I've already committed (locally, not pushed yet) this patch with only changed field types and a bit shuffled lines to group size-related and format-related assignments together. Oh ok. That's good! Thanks for doing that. :) Thanks, Sergio Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: soc-camera: Store negotiated buffer settings
On Fri, 11 Mar 2011, Sergio Aguirre wrote: > Hi Guennadi, > > On 03/11/2011 10:36 AM, Guennadi Liakhovetski wrote: > > On Tue, 8 Mar 2011, Sergio Aguirre wrote: > > > > > Hi Guennadi, > > > > > > On 03/08/2011 01:19 AM, Guennadi Liakhovetski wrote: > > > > On Mon, 7 Mar 2011, Sergio Aguirre wrote: > > > > > > > > > This fixes the problem in which a host driver > > > > > sets a personalized sizeimage or bytesperline field, > > > > > and gets ignored when doing G_FMT. > > > > > > > > Can you tell what that personalised value is? Is it not covered by > > > > soc_mbus_bytes_per_line()? Maybe something like a JPEG format? > > > > > > In my case, my omap4_camera driver requires to have a bytesperline which > > > is a > > > multiple of 32, and sometimes (depending on the internal HW blocks used) a > > > page aligned byte offset between lines. > > > > > > For example, I want to use such configuration that, for an NV12 buffer, I > > > require a 4K offset between lines, so the vaues are: > > > > > > pix->bytesperline = PAGE_SIZE; > > > pix->sizeimage = pix->bytesperline * height * 3 / 2; > > > > > > Which I filled in TRY_FMT/S_FMT ioctl calls. > > > > Ok, I think, I agree with this. Until now we didn't have drivers, that > > wanted to pad data. Even the pxa270 driver adjusts the frame format (see > > pxa_camera.c::pxa_camera_try_fmt() and the call to v4l_bound_align_image() > > there in the YUV422P case) to avoid padding, even though that's a > > different kind of padding - between planes. So, if line padding - as in > > your case - is indeed needed, I agree, that the correct way to support > > that is to implement driver-specific bytesperline and sizeimage > > calculations and, logically, those values should be used in > > soc_camera_g_fmt_vid_cap(). > > > > I'll just change your patch a bit - I'll use "u32" types instead of > > "__u32" - this is a kernel internal struct and we don't need user-space > > exported types. > > Ok, thanks. > > You're right about u32 type... my bad. > > So, I'll change that, rebase to: > > git://linuxtv.org/media_tree.git staging/for_v2.6.39 > > And resubmit for review. No problem. Np, I've already committed (locally, not pushed yet) this patch with only changed field types and a bit shuffled lines to group size-related and format-related assignments together. Thanks Guennadi > > Regards, > Sergio > > > > > Thanks > > Guennadi > > > > > So, next time a driver tries a G_FMT, it currently gets recalculated by > > > a prefixed table (which comes from soc_mbus_bytes_per_line), which won't > > > give > > > me what i had set before. And it will also recalculate a size image based > > > on > > > this wrong bytesperline * height, which is also wrong, (lacks the * 3 / 2 > > > for > > > NV12). > > > > > > Regards, > > > Sergio > > > > > > > > > > > Thanks > > > > Guennadi > > > > > > > > > > > > > > Signed-off-by: Sergio Aguirre > > > > > --- > > > > >drivers/media/video/soc_camera.c |9 - > > > > >include/media/soc_camera.h |2 ++ > > > > >2 files changed, 6 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/media/video/soc_camera.c > > > > > b/drivers/media/video/soc_camera.c > > > > > index a66811b..59dc71d 100644 > > > > > --- a/drivers/media/video/soc_camera.c > > > > > +++ b/drivers/media/video/soc_camera.c > > > > > @@ -363,6 +363,8 @@ static int soc_camera_set_fmt(struct > > > > > soc_camera_device > > > > > *icd, > > > > > icd->user_width = pix->width; > > > > > icd->user_height= pix->height; > > > > > icd->colorspace = pix->colorspace; > > > > > + icd->bytesperline = pix->bytesperline; > > > > > + icd->sizeimage = pix->sizeimage; > > > > > icd->vb_vidq.field = > > > > > icd->field = pix->field; > > > > > > > > > > @@ -608,12 +610,9 @@ static int soc_camera_g_fmt_vid_cap(struct file > > > > > *file, void *priv, > > > > > pix->height = icd->user_height; > > > > > pix->field = icd->vb_vidq.field; > > > > > pix->pixelformat= icd->current_fmt->host_fmt->fourcc; > > > > > - pix->bytesperline = soc_mbus_bytes_per_line(pix->width, > > > > > - > > > > > icd->current_fmt->host_fmt); > > > > > + pix->bytesperline = icd->bytesperline; > > > > > pix->colorspace = icd->colorspace; > > > > > - if (pix->bytesperline< 0) > > > > > - return pix->bytesperline; > > > > > - pix->sizeimage = pix->height * pix->bytesperline; > > > > > + pix->sizeimage = icd->sizeimage; > > > > > dev_dbg(&icd->dev, "current_fmt->fourcc: 0x%08x\n", > > > > > icd->current_fmt->host_fmt->fourcc); > > > > > return 0; > > > > > diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h > > > > > index 9386db8..de81370 100644 > > > > > --- a/include/media/soc_camera.h > > > > > +++ b/includ
Re: [PATCH] V4L: soc-camera: Add support for custom host mmap
On 03/08/2011 07:45 AM, Guennadi Liakhovetski wrote:
On Tue, 8 Mar 2011, Sergio Aguirre wrote:
Hi Guennadi,
On 03/08/2011 01:17 AM, Guennadi Liakhovetski wrote:
Hi Sergio
On Mon, 7 Mar 2011, Sergio Aguirre wrote:
This helps redirect mmap calls to custom memory managers which
already have preallocated space to use by the device.
Otherwise, device might not support the allocation attempted
generically by videobuf.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/soc_camera.c |7 ++-
include/media/soc_camera.h |2 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 59dc71d..d361ba0 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -512,6 +512,7 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
static int soc_camera_mmap(struct file *file, struct vm_area_struct
*vma)
{
struct soc_camera_device *icd = file->private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd->dev.parent);
This doesn't seem to be needed
It's needed to call the custom mmaper.
ici->ops->mmap
Oops, sorry, diff context has confused me "@@ -512,6 +512,7 @@ static
ssize_t soc_camera_read(";-)
No worries. :)
Otherwise, how can I access the soc camera host ops?
int err;
dev_dbg(&icd->dev, "mmap called, vma=0x%08lx\n", (unsigned long)vma);
@@ -519,7 +520,11 @@ static int soc_camera_mmap(struct file *file, struct
vm_area_struct *vma)
if (icd->streamer != file)
return -EBUSY;
- err = videobuf_mmap_mapper(&icd->vb_vidq, vma);
+ /* Check for an interface custom mmaper */
mmapper - double 'p'
Oops. Will fix.
+ if (ici->ops->mmap)
+ err = ici->ops->mmap(&icd->vb_vidq, icd, vma);
+ else
+ err = videobuf_mmap_mapper(&icd->vb_vidq, vma);
You're patching an old version of soc-camera. Please use a current one
with support for videobuf2. Further, wouldn't it be possible for you to
just replace the videobuf mmap_mapper() (videobuf2 q->mem_ops->mmap())
method? I am not sure how possible this is, maybe one of videobuf2 experts
could help us? BTW, you really should be using the videobuf2 API.
I'm basing this patches on mainline, commit:
commit 214d93b02c4fe93638ad268613c9702a81ed9192
Merge: ad4a4a8 077f8ec
Author: Linus Torvalds
Date: Mon Mar 7 13:15:02 2011 -0800
Merge branch 'omap-fixes-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
And i don't see videobuf2 there.
Should I rebase my patches on another tree?
Yes, please use
git://linuxtv.org/media_tree.gitstaging/for_v2.6.39
Ok, I'll do this later on. I'm currently developing my driver on an
internal TI tree, based on 2.6.35.6 Android kernel, and rebasing just
generic v4l2 changes to send for review.
I still need to try this driver out in mainline for the Pandaboard, and
then I'll rebase everything on top of videobuf2 framework.
Bottom line: Holding this patch for now :)
Thanks for your time!
Sergio
otherwise you can also base on linux-next if you like.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: soc-camera: Store negotiated buffer settings
Hi Guennadi,
On 03/11/2011 10:36 AM, Guennadi Liakhovetski wrote:
On Tue, 8 Mar 2011, Sergio Aguirre wrote:
Hi Guennadi,
On 03/08/2011 01:19 AM, Guennadi Liakhovetski wrote:
On Mon, 7 Mar 2011, Sergio Aguirre wrote:
This fixes the problem in which a host driver
sets a personalized sizeimage or bytesperline field,
and gets ignored when doing G_FMT.
Can you tell what that personalised value is? Is it not covered by
soc_mbus_bytes_per_line()? Maybe something like a JPEG format?
In my case, my omap4_camera driver requires to have a bytesperline which is a
multiple of 32, and sometimes (depending on the internal HW blocks used) a
page aligned byte offset between lines.
For example, I want to use such configuration that, for an NV12 buffer, I
require a 4K offset between lines, so the vaues are:
pix->bytesperline = PAGE_SIZE;
pix->sizeimage = pix->bytesperline * height * 3 / 2;
Which I filled in TRY_FMT/S_FMT ioctl calls.
Ok, I think, I agree with this. Until now we didn't have drivers, that
wanted to pad data. Even the pxa270 driver adjusts the frame format (see
pxa_camera.c::pxa_camera_try_fmt() and the call to v4l_bound_align_image()
there in the YUV422P case) to avoid padding, even though that's a
different kind of padding - between planes. So, if line padding - as in
your case - is indeed needed, I agree, that the correct way to support
that is to implement driver-specific bytesperline and sizeimage
calculations and, logically, those values should be used in
soc_camera_g_fmt_vid_cap().
I'll just change your patch a bit - I'll use "u32" types instead of
"__u32" - this is a kernel internal struct and we don't need user-space
exported types.
Ok, thanks.
You're right about u32 type... my bad.
So, I'll change that, rebase to:
git://linuxtv.org/media_tree.gitstaging/for_v2.6.39
And resubmit for review. No problem.
Regards,
Sergio
Thanks
Guennadi
So, next time a driver tries a G_FMT, it currently gets recalculated by
a prefixed table (which comes from soc_mbus_bytes_per_line), which won't give
me what i had set before. And it will also recalculate a size image based on
this wrong bytesperline * height, which is also wrong, (lacks the * 3 / 2 for
NV12).
Regards,
Sergio
Thanks
Guennadi
Signed-off-by: Sergio Aguirre
---
drivers/media/video/soc_camera.c |9 -
include/media/soc_camera.h |2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index a66811b..59dc71d 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -363,6 +363,8 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
icd->user_width = pix->width;
icd->user_height = pix->height;
icd->colorspace = pix->colorspace;
+ icd->bytesperline= pix->bytesperline;
+ icd->sizeimage = pix->sizeimage;
icd->vb_vidq.field =
icd->field = pix->field;
@@ -608,12 +610,9 @@ static int soc_camera_g_fmt_vid_cap(struct file
*file, void *priv,
pix->height = icd->user_height;
pix->field = icd->vb_vidq.field;
pix->pixelformat = icd->current_fmt->host_fmt->fourcc;
- pix->bytesperline= soc_mbus_bytes_per_line(pix->width,
- icd->current_fmt->host_fmt);
+ pix->bytesperline= icd->bytesperline;
pix->colorspace = icd->colorspace;
- if (pix->bytesperline< 0)
- return pix->bytesperline;
- pix->sizeimage = pix->height * pix->bytesperline;
+ pix->sizeimage = icd->sizeimage;
dev_dbg(&icd->dev, "current_fmt->fourcc: 0x%08x\n",
icd->current_fmt->host_fmt->fourcc);
return 0;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 9386db8..de81370 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -30,6 +30,8 @@ struct soc_camera_device {
s32 user_width;
s32 user_height;
enum v4l2_colorspace colorspace;
+ __u32 bytesperline; /* for padding, zero if unused */
+ __u32 sizeimage;
unsigned char iface;/* Host number */
unsigned char devnum; /* Device number per host */
struct soc_camera_sense *sense; /* See comment in struct definition */
--
1.7.1
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: soc-camera: Store negotiated buffer settings
On Tue, 8 Mar 2011, Sergio Aguirre wrote:
> Hi Guennadi,
>
> On 03/08/2011 01:19 AM, Guennadi Liakhovetski wrote:
> > On Mon, 7 Mar 2011, Sergio Aguirre wrote:
> >
> > > This fixes the problem in which a host driver
> > > sets a personalized sizeimage or bytesperline field,
> > > and gets ignored when doing G_FMT.
> >
> > Can you tell what that personalised value is? Is it not covered by
> > soc_mbus_bytes_per_line()? Maybe something like a JPEG format?
>
> In my case, my omap4_camera driver requires to have a bytesperline which is a
> multiple of 32, and sometimes (depending on the internal HW blocks used) a
> page aligned byte offset between lines.
>
> For example, I want to use such configuration that, for an NV12 buffer, I
> require a 4K offset between lines, so the vaues are:
>
> pix->bytesperline = PAGE_SIZE;
> pix->sizeimage = pix->bytesperline * height * 3 / 2;
>
> Which I filled in TRY_FMT/S_FMT ioctl calls.
Ok, I think, I agree with this. Until now we didn't have drivers, that
wanted to pad data. Even the pxa270 driver adjusts the frame format (see
pxa_camera.c::pxa_camera_try_fmt() and the call to v4l_bound_align_image()
there in the YUV422P case) to avoid padding, even though that's a
different kind of padding - between planes. So, if line padding - as in
your case - is indeed needed, I agree, that the correct way to support
that is to implement driver-specific bytesperline and sizeimage
calculations and, logically, those values should be used in
soc_camera_g_fmt_vid_cap().
I'll just change your patch a bit - I'll use "u32" types instead of
"__u32" - this is a kernel internal struct and we don't need user-space
exported types.
Thanks
Guennadi
> So, next time a driver tries a G_FMT, it currently gets recalculated by
> a prefixed table (which comes from soc_mbus_bytes_per_line), which won't give
> me what i had set before. And it will also recalculate a size image based on
> this wrong bytesperline * height, which is also wrong, (lacks the * 3 / 2 for
> NV12).
>
> Regards,
> Sergio
>
> >
> > Thanks
> > Guennadi
> >
> > >
> > > Signed-off-by: Sergio Aguirre
> > > ---
> > > drivers/media/video/soc_camera.c |9 -
> > > include/media/soc_camera.h |2 ++
> > > 2 files changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/media/video/soc_camera.c
> > > b/drivers/media/video/soc_camera.c
> > > index a66811b..59dc71d 100644
> > > --- a/drivers/media/video/soc_camera.c
> > > +++ b/drivers/media/video/soc_camera.c
> > > @@ -363,6 +363,8 @@ static int soc_camera_set_fmt(struct soc_camera_device
> > > *icd,
> > > icd->user_width = pix->width;
> > > icd->user_height= pix->height;
> > > icd->colorspace = pix->colorspace;
> > > + icd->bytesperline = pix->bytesperline;
> > > + icd->sizeimage = pix->sizeimage;
> > > icd->vb_vidq.field =
> > > icd->field = pix->field;
> > >
> > > @@ -608,12 +610,9 @@ static int soc_camera_g_fmt_vid_cap(struct file
> > > *file, void *priv,
> > > pix->height = icd->user_height;
> > > pix->field = icd->vb_vidq.field;
> > > pix->pixelformat= icd->current_fmt->host_fmt->fourcc;
> > > - pix->bytesperline = soc_mbus_bytes_per_line(pix->width,
> > > - icd->current_fmt->host_fmt);
> > > + pix->bytesperline = icd->bytesperline;
> > > pix->colorspace = icd->colorspace;
> > > - if (pix->bytesperline< 0)
> > > - return pix->bytesperline;
> > > - pix->sizeimage = pix->height * pix->bytesperline;
> > > + pix->sizeimage = icd->sizeimage;
> > > dev_dbg(&icd->dev, "current_fmt->fourcc: 0x%08x\n",
> > > icd->current_fmt->host_fmt->fourcc);
> > > return 0;
> > > diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> > > index 9386db8..de81370 100644
> > > --- a/include/media/soc_camera.h
> > > +++ b/include/media/soc_camera.h
> > > @@ -30,6 +30,8 @@ struct soc_camera_device {
> > > s32 user_width;
> > > s32 user_height;
> > > enum v4l2_colorspace colorspace;
> > > + __u32 bytesperline; /* for padding, zero if unused */
> > > + __u32 sizeimage;
> > > unsigned char iface;/* Host number */
> > > unsigned char devnum; /* Device number per host */
> > > struct soc_camera_sense *sense; /* See comment in struct
> > > definition */
> > > --
> > > 1.7.1
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Friday 11 March 2011, Marek Szyprowski wrote: > > > > does not support IOMMUs, but that could be changed by wrapping it > > > > using the include/asm-generic/dma-mapping-common.h infrastructure. > > > > > > ARM dma-mapping framework also requires some additional research for > > > better DMA > > > support (there are still issues with multiple mappings to be resolved). > > > > You mean mapping the same memory into multiple devices, or a different > > problem? > > Mapping the same memory area multiple times with different cache settings is > not > legal on ARMv7+ systems. Currently the problems might caused by the low-memory > kernel linear mapping and second mapping created for example by > dma_alloc_coherent() > function. Yes, I know this problem, but I don't think the case you describe is a serious limitation (there are more interesting cases, though): dma_map_single() etc will create additional *bus* addresses for a physical address, not additional virtual addresses. dma_alloc_coherent should allocate memory that is not also mapped cached, which is what I thought we do correctly. Arnd -- 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] Ngene cam device name
On 03/10/2011 04:29 PM, Issa Gorissen wrote: > As the cxd20099 driver is in staging due to abuse of the sec0 device, this > patch renames it to cam0. The sec0 device is not in use and can be removed That doesn't solve anything. Besides, your patch doesn't even do what you describe. Wouldn't it be possible to extend the current CA API? If not, shouldn't a new API be created that covers both old and new requirements? It's rather unintuitive that some CAMs appear as ca0, while others as cam0. If it was that easy to fix, it wouldn't be in staging today. Regards, Andreas > Signed-off-by: Issa Gorissen > --- > drivers/media/dvb/dvb-core/dvbdev.h |2 +- > drivers/media/dvb/ngene/ngene-core.c |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/dvb/dvb-core/dvbdev.h > b/drivers/media/dvb/dvb-core/dvbdev.h > index fcc6ae9..dcac27d 100644 > --- a/drivers/media/dvb/dvb-core/dvbdev.h > +++ b/drivers/media/dvb/dvb-core/dvbdev.h > @@ -40,7 +40,7 @@ > > #define DVB_DEVICE_VIDEO 0 > #define DVB_DEVICE_AUDIO 1 > -#define DVB_DEVICE_SEC2 > +#define DVB_DEVICE_CAM2 > #define DVB_DEVICE_FRONTEND 3 > #define DVB_DEVICE_DEMUX 4 > #define DVB_DEVICE_DVR5 > diff --git a/drivers/media/dvb/ngene/ngene-core.c > b/drivers/media/dvb/ngene/ngene-core.c > index 175a0f6..6be2d7c 100644 > --- a/drivers/media/dvb/ngene/ngene-core.c > +++ b/drivers/media/dvb/ngene/ngene-core.c > @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan) > set_transfer(&chan->dev->channel[2], 1); > dvb_register_device(adapter, &chan->ci_dev, > &ngene_dvbdev_ci, (void *) chan, > - DVB_DEVICE_SEC); > + DVB_DEVICE_CAM); > if (!chan->ci_dev) > goto err; > } > -- > 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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Friday 11 March 2011 16:40:42 Mauro Carvalho Chehab wrote: > Em 07-03-2011 08:57, Mauro Carvalho Chehab escreveu: > > Em 05-03-2011 17:48, Laurent Pinchart escreveu: > > > > Added both patches and folded them as requested, and added the remaining > > patches after my review. The new tree is at: > > > > http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/m > > edia_controller > > > > The pending issues for merging it to the main devel branch are: > > - omap3isp private control description; > > - a renaming patch to make directory name and file names consistent. > > Tree updated with the patches from: > git://linuxtv.org/pinchartl/media.git media-for-mauro Thanks. > > - a chapter describing how *MBUS* and fourcc formats are related; > > Still needed. For now, I'll merge what we currently have at the master > devel tree, but we still need such chapter to be written, in order to have > the media controller for .39. I plan to discuss this topic during the brainstorming meeting. > > - a description about how to lock between MBUS/fourcc get/set format; > > We had some discussions about it, but we didn't reach to a conclusion. Documentation/media-framework.txt already states that "If other operations need to be disallowed on streaming entities (such as changing entities configuration parameters) drivers can explictly check the media_entity stream_count field to find out if an entity is streaming. This operation must be done with the media_device graph_mutex held." > I'd like to see something documented at the v4l framework about that. IMO, > this is a good theme for the V4L "brainstorm" meeting. > > I also like to have a patch adding such docs for .39. OK, we'll discuss the topic during the meeting and I'll work on documentation. > Could you please double-check if everything went fine on my merge at: > > http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/me > dia_controller Before I merge it at the media-tree? Everything is there. Thanks a lot. -- 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: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 07-03-2011 08:57, Mauro Carvalho Chehab escreveu: > Em 05-03-2011 17:48, Laurent Pinchart escreveu: > Added both patches and folded them as requested, and added the remaining > patches after my review. The new tree is at: > > http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller > > The pending issues for merging it to the main devel branch are: > - omap3isp private control description; > - a renaming patch to make directory name and file names consistent. Tree updated with the patches from: git://linuxtv.org/pinchartl/media.git media-for-mauro > - a chapter describing how *MBUS* and fourcc formats are related; Still needed. For now, I'll merge what we currently have at the master devel tree, but we still need such chapter to be written, in order to have the media controller for .39. > - a description about how to lock between MBUS/fourcc get/set format; We had some discussions about it, but we didn't reach to a conclusion. I'd like to see something documented at the v4l framework about that. IMO, this is a good theme for the V4L "brainstorm" meeting. I also like to have a patch adding such docs for .39. Could you please double-check if everything went fine on my merge at: http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller Before I merge it at the media-tree? Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello, On Friday, March 11, 2011 4:15 PM Arnd Bergmann wrote: > On Friday 11 March 2011, Marek Szyprowski wrote: > > On Friday, March 11, 2011 3:08 PM Arnd Bergmann wrote: > > > > > On Friday 11 March 2011, Marek Szyprowski wrote: > > > > > The iommu API is not really meant to be KVM specific, it's just that > > > > > the > > > > > in-tree users are basically limited to KVM at the moment. Another > > > > > user that > > > > > is coming up soon is the vmio device driver that can be used to > > > > > transparently > > > > > pass devices to user space. The idea behind the IOMMU API is that you > > > > > can > > > > > map arbitrary bus addresses to physical memory addresses, but it does > > > > > not > > > > > deal with allocating the bus addresses or providing buffer management > > > > > such > > > > > as cache flushes. > > > > > > > > Yea, I've noticed this and this basically what we expect from iommu > > > > driver. > > > > However the iommu.h API requires a separate call to map each single > > > > memory page. > > > > This is quite ineffective approach and imho the API need to be extended > > > > to allow > > > > mapping of the arbitrary set of pages. > > > > > > We can always discuss extensions to the existing infrastructure, adding > > > an interface for mapping an array of page pointers in the iommu API > > > sounds like a good idea. > > > > We will investigate this API further. From the first sight it looks it > > won't take > > much work to port/rewrite our driver to fit into iommu.h API. > > Ok, sounds good. > > > > I also think that we should not really have separate iommu and dma-mapping > > > interfaces, but rather have a portable way to define an iommu so that it > > > can be used through the dma-mapping interfaces. I'm not asking you to > > > do that as a prerequisite to merging your driver, but it may be good to > > > keep in mind that the current situation is still lacking and that any > > > suggestion for improving this as part of your work to support the > > > samsung IOMMU is welcome. > > > > Well creating a portable iommu framework and merging it with dma-mapping > > interface > > looks like a much harder (and time consuming) task. There is definitely a > > need for > > it. I hope that it can be developed incrementally starting from the current > > iommu.h > > and dma-mapping.h interfaces. > > Yes, that is the idea. Maybe we should add it to the list things that the > Linaro kernel working group can target for the November release? > > > Please note that there might be some subtle differences > > in the hardware that such framework must be aware. The first obvious one is > > the > > hardware design. Some platform has central iommu unit, other (like Samsung > > Exynos4) > > has a separate iommu unit per each device driver (this is still a > > simplification, > > because a video codec device has 2 memory interfaces and 2 iommu units). > > Currently > > I probably have not enough knowledge to predict the other possible issues > > that need > > to be taken into account in the portable and generic iommu/dma-mapping > > frame-work. > > The dma-mapping API can deal well with one IOMMU per device, but would > need some tricks to work with one device that has two separate IOMMUs. We need to investigate the internals of dma-mapping API first. Right now I know too little in this area. > I'm not very familar with the iommu API, but in the common KVM scenario, > you need one IOMMU per device, so it should handle that just fine as well. Well, afair there are also systems with one central iommu module, which is shared between devices. I have no idea how such model will fit into the dma-mapping API. > > > Note that the ARM implementation of the dma-mapping.h interface currently > > > does not support IOMMUs, but that could be changed by wrapping it > > > using the include/asm-generic/dma-mapping-common.h infrastructure. > > > > ARM dma-mapping framework also requires some additional research for better > > DMA > > support (there are still issues with multiple mappings to be resolved). > > You mean mapping the same memory into multiple devices, or a different > problem? Mapping the same memory area multiple times with different cache settings is not legal on ARMv7+ systems. Currently the problems might caused by the low-memory kernel linear mapping and second mapping created for example by dma_alloc_coherent() function. Best regards -- Marek Szyprowski Samsung Poland R&D 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
Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Friday 11 March 2011, Marek Szyprowski wrote: > On Friday, March 11, 2011 3:08 PM Arnd Bergmann wrote: > > > On Friday 11 March 2011, Marek Szyprowski wrote: > > > > The iommu API is not really meant to be KVM specific, it's just that the > > > > in-tree users are basically limited to KVM at the moment. Another user > > > > that > > > > is coming up soon is the vmio device driver that can be used to > > > > transparently > > > > pass devices to user space. The idea behind the IOMMU API is that you > > > > can > > > > map arbitrary bus addresses to physical memory addresses, but it does > > > > not > > > > deal with allocating the bus addresses or providing buffer management > > > > such > > > > as cache flushes. > > > > > > Yea, I've noticed this and this basically what we expect from iommu > > > driver. > > > However the iommu.h API requires a separate call to map each single > > > memory page. > > > This is quite ineffective approach and imho the API need to be extended > > > to allow > > > mapping of the arbitrary set of pages. > > > > We can always discuss extensions to the existing infrastructure, adding > > an interface for mapping an array of page pointers in the iommu API > > sounds like a good idea. > > We will investigate this API further. From the first sight it looks it won't > take > much work to port/rewrite our driver to fit into iommu.h API. Ok, sounds good. > > I also think that we should not really have separate iommu and dma-mapping > > interfaces, but rather have a portable way to define an iommu so that it > > can be used through the dma-mapping interfaces. I'm not asking you to > > do that as a prerequisite to merging your driver, but it may be good to > > keep in mind that the current situation is still lacking and that any > > suggestion for improving this as part of your work to support the > > samsung IOMMU is welcome. > > Well creating a portable iommu framework and merging it with dma-mapping > interface > looks like a much harder (and time consuming) task. There is definitely a > need for > it. I hope that it can be developed incrementally starting from the current > iommu.h > and dma-mapping.h interfaces. Yes, that is the idea. Maybe we should add it to the list things that the Linaro kernel working group can target for the November release? > Please note that there might be some subtle differences > in the hardware that such framework must be aware. The first obvious one is > the > hardware design. Some platform has central iommu unit, other (like Samsung > Exynos4) > has a separate iommu unit per each device driver (this is still a > simplification, > because a video codec device has 2 memory interfaces and 2 iommu units). > Currently > I probably have not enough knowledge to predict the other possible issues > that need > to be taken into account in the portable and generic iommu/dma-mapping > frame-work. The dma-mapping API can deal well with one IOMMU per device, but would need some tricks to work with one device that has two separate IOMMUs. I'm not very familar with the iommu API, but in the common KVM scenario, you need one IOMMU per device, so it should handle that just fine as well. > > Note that the ARM implementation of the dma-mapping.h interface currently > > does not support IOMMUs, but that could be changed by wrapping it > > using the include/asm-generic/dma-mapping-common.h infrastructure. > > ARM dma-mapping framework also requires some additional research for better > DMA > support (there are still issues with multiple mappings to be resolved). You mean mapping the same memory into multiple devices, or a different problem? Arnd -- 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 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello, On Friday, March 11, 2011 3:08 PM Arnd Bergmann wrote: > On Friday 11 March 2011, Marek Szyprowski wrote: > > > The iommu API is not really meant to be KVM specific, it's just that the > > > in-tree users are basically limited to KVM at the moment. Another user > > > that > > > is coming up soon is the vmio device driver that can be used to > > > transparently > > > pass devices to user space. The idea behind the IOMMU API is that you can > > > map arbitrary bus addresses to physical memory addresses, but it does not > > > deal with allocating the bus addresses or providing buffer management such > > > as cache flushes. > > > > Yea, I've noticed this and this basically what we expect from iommu driver. > > However the iommu.h API requires a separate call to map each single memory > > page. > > This is quite ineffective approach and imho the API need to be extended to > > allow > > mapping of the arbitrary set of pages. > > We can always discuss extensions to the existing infrastructure, adding > an interface for mapping an array of page pointers in the iommu API > sounds like a good idea. We will investigate this API further. From the first sight it looks it won't take much work to port/rewrite our driver to fit into iommu.h API. > I also think that we should not really have separate iommu and dma-mapping > interfaces, but rather have a portable way to define an iommu so that it > can be used through the dma-mapping interfaces. I'm not asking you to > do that as a prerequisite to merging your driver, but it may be good to > keep in mind that the current situation is still lacking and that any > suggestion for improving this as part of your work to support the > samsung IOMMU is welcome. Well creating a portable iommu framework and merging it with dma-mapping interface looks like a much harder (and time consuming) task. There is definitely a need for it. I hope that it can be developed incrementally starting from the current iommu.h and dma-mapping.h interfaces. Please note that there might be some subtle differences in the hardware that such framework must be aware. The first obvious one is the hardware design. Some platform has central iommu unit, other (like Samsung Exynos4) has a separate iommu unit per each device driver (this is still a simplification, because a video codec device has 2 memory interfaces and 2 iommu units). Currently I probably have not enough knowledge to predict the other possible issues that need to be taken into account in the portable and generic iommu/dma-mapping frame-work. > Note that the ARM implementation of the dma-mapping.h interface currently > does not support IOMMUs, but that could be changed by wrapping it > using the include/asm-generic/dma-mapping-common.h infrastructure. ARM dma-mapping framework also requires some additional research for better DMA support (there are still issues with multiple mappings to be resolved). Best regards -- Marek Szyprowski Samsung Poland R&D 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
Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Friday 11 March 2011, Marek Szyprowski wrote: > > The iommu API is not really meant to be KVM specific, it's just that the > > in-tree users are basically limited to KVM at the moment. Another user that > > is coming up soon is the vmio device driver that can be used to > > transparently > > pass devices to user space. The idea behind the IOMMU API is that you can > > map arbitrary bus addresses to physical memory addresses, but it does not > > deal with allocating the bus addresses or providing buffer management such > > as cache flushes. > > Yea, I've noticed this and this basically what we expect from iommu driver. > However the iommu.h API requires a separate call to map each single memory > page. > This is quite ineffective approach and imho the API need to be extended to > allow > mapping of the arbitrary set of pages. We can always discuss extensions to the existing infrastructure, adding an interface for mapping an array of page pointers in the iommu API sounds like a good idea. I also think that we should not really have separate iommu and dma-mapping interfaces, but rather have a portable way to define an iommu so that it can be used through the dma-mapping interfaces. I'm not asking you to do that as a prerequisite to merging your driver, but it may be good to keep in mind that the current situation is still lacking and that any suggestion for improving this as part of your work to support the samsung IOMMU is welcome. Note that the ARM implementation of the dma-mapping.h interface currently does not support IOMMUs, but that could be changed by wrapping it using the include/asm-generic/dma-mapping-common.h infrastructure. Arnd -- 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 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello, On Friday, March 11, 2011 12:51 PM Arnd Bergmann wrote: > On Friday 11 March 2011, Marek Szyprowski wrote: > > > > We followed the style of iommu API for other mainline ARM platforms (both > > OMAP and MSM > > also have custom API for their iommu modules). I've briefly checked > > include/linux/iommu.h > > API and I've noticed that it has been designed mainly for KVM support. > > There is also > > include/linux/intel-iommu.h interface, but I it is very specific to intel > > gfx chips. > > The MSM code actually uses the generic iommu.h code, using register_iommu, so > the drivers can use the regular iommu_map. > > I believe the omap code predates the iommu API, and should really be changed > to use that. At least it was added before I started reviewing the code. > > The iommu API is not really meant to be KVM specific, it's just that the > in-tree users are basically limited to KVM at the moment. Another user that > is coming up soon is the vmio device driver that can be used to transparently > pass devices to user space. The idea behind the IOMMU API is that you can > map arbitrary bus addresses to physical memory addresses, but it does not > deal with allocating the bus addresses or providing buffer management such > as cache flushes. Yea, I've noticed this and this basically what we expect from iommu driver. However the iommu.h API requires a separate call to map each single memory page. This is quite ineffective approach and imho the API need to be extended to allow mapping of the arbitrary set of pages. > > Is there any example how include/linux/dma-mapping.h interface can be used > > for iommu > > mappings? > > The dma-mapping API is the normal interface that you should use for IOMMUs > that sit between DMA devices and kernel memory. The idea is that you > completely abstract the concept of an IOMMU so the device driver uses > the same code for talking to a device with an IOMMU and another device with > a linear mapping or an swiotlb bounce buffer. > > This means that the user of the dma-mapping API does not get to choose the > bus addresses, but instead you use the API to get a bus address for a > chunk of memory, and then you can pass that address to a device. > > See arch/powerpc/kernel/iommu.c and arch/x86/kernel/amd_iommu.c for common > examples of how this is implemented. The latter one actually implements > both the iommu_ops for iommu.h and dma_map_ops for dma-mapping.h. Thanks for your comments! We will check how is it suitable for our case. Best regards -- Marek Szyprowski Samsung Poland R&D 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
Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Friday 11 March 2011, Marek Szyprowski wrote: > > We followed the style of iommu API for other mainline ARM platforms (both > OMAP and MSM > also have custom API for their iommu modules). I've briefly checked > include/linux/iommu.h > API and I've noticed that it has been designed mainly for KVM support. There > is also > include/linux/intel-iommu.h interface, but I it is very specific to intel gfx > chips. The MSM code actually uses the generic iommu.h code, using register_iommu, so the drivers can use the regular iommu_map. I believe the omap code predates the iommu API, and should really be changed to use that. At least it was added before I started reviewing the code. The iommu API is not really meant to be KVM specific, it's just that the in-tree users are basically limited to KVM at the moment. Another user that is coming up soon is the vmio device driver that can be used to transparently pass devices to user space. The idea behind the IOMMU API is that you can map arbitrary bus addresses to physical memory addresses, but it does not deal with allocating the bus addresses or providing buffer management such as cache flushes. > Is there any example how include/linux/dma-mapping.h interface can be used > for iommu > mappings? The dma-mapping API is the normal interface that you should use for IOMMUs that sit between DMA devices and kernel memory. The idea is that you completely abstract the concept of an IOMMU so the device driver uses the same code for talking to a device with an IOMMU and another device with a linear mapping or an swiotlb bounce buffer. This means that the user of the dma-mapping API does not get to choose the bus addresses, but instead you use the API to get a bus address for a chunk of memory, and then you can pass that address to a device. See arch/powerpc/kernel/iommu.c and arch/x86/kernel/amd_iommu.c for common examples of how this is implemented. The latter one actually implements both the iommu_ops for iommu.h and dma_map_ops for dma-mapping.h. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] HDMI-CEC proposal, ver 2
Hi
This is an updated version of the proposal for adding an api for
HDMI-CEC to V4L2.
Main difference is the support of AV.link EN 50157-2-[123]. (thanks to
Daniel Glöckner)
Author: Martin Bugge
Date: Fri, 11th of March 2010
=
This is a proposal for adding a Consumer Electronic Control (CEC) API to
V4L2.
This document describes the changes and new ioctls needed.
Version 1.
Initial version
Version 2.
Added support for AV.link EN 50157-2-[123].
Background
==
CEC is a protocol that provides high-level control functions between
various audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface
Specification (HDMI).
In short: CEC uses pin 13 on the HDMI connector to transmit and receive
small data-packets
(maximum 16 bytes including a 1 byte header) at low data
rates (~400 bits/s).
A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link, see [3].
Due to this the proposed ioctls and events are meant to cover expansion
for the protocols in [3].
References
==
[1] High-Definition Multimedia Interface Specification version 1.3a,
Supplement 1 Consumer Electronic Control (CEC).
http://www.hdmi.org/manufacturer/specification.aspx
[2]
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
[3] Domestic and similar electronic equipment interconnection requirements
AV.link. EN 50157-2-[123]
Proposed solution
=
Two new ioctls:
VIDIOC_AV_LINK_CAP (read)
VIDIOC_AV_LINK_CMD (read/write)
VIDIOC_AV_LINK_CAP:
---
#define AV_LINK_CAP_MODE_CEC (1 << 0)
#define AV_LINK_CAP_MODE_1 (1 << 1)
#define AV_LINK_CAP_MODE_2 (1 << 2)
#define AV_LINK_CAP_MODE_3 (1 << 3)
struct vl2_av_link_cap {
__u32 capabilities;
__u32 logicaldevices;
__u32 reserved[14];
};
The capabilities field will indicate which protocols/formats this HW
supports.
* AV link mode CEC:
logicaldevices: 1 -> 14, this HW supports n logical devices
simultaneously.
* AV link mode 1:
logicaldevices: not used.
* AV link mode 2:
Same as AV link mode CEC.
* AV link mode 3:
logicaldevices: not used.
reserved: for future use.
VIDIOC_AV_LINK_CMD:
---
The command ioctl is used both for configuration and to receive/transmit
data.
/* mode 1 */
struct avl_mode1_conf {
__u32 enable;
__u32 upstream_Qty;
__u32 downstream_Qty;
};
struct avl_mode1 {
__u32 head;
__u32 Qty;
__u32 tx_status;
__u32 tx_status_Qty;
};
/* mode 2, 3 and CEC */
struct avl_conf {
__u32 enable;
__u32 index;
__u32 addr;
};
struct avl {
__u32 len;
__u8 msg[16];
__u32 tx_status;
};
struct v4l2_av_link_cmd {
__u32 command;
__u32 mode;
__u32 reserved[2];
union {
struct avl_mode1_conf avlm1_conf;
struct avl_mode1 avlm1;
struct avl_conf conf;
struct avl avl;
__u32 raw[12];
};
};
/* command */
#define V4L2_AV_LINK_CMD_CONF (1)
#define V4L2_AV_LINK_CMD_TX (2)
#define V4L2_AV_LINK_CMD_RX (3)
/* mode */
#define AV_LINK_CMD_MODE_CEC (1)
#define AV_LINK_CMD_MODE_1 (2)
#define AV_LINK_CMD_MODE_2 (3)
#define AV_LINK_CMD_MODE_3 (4)
/* Tx status */
#define V4L2_AV_LINK_STAT_TX_OK (0)
#define V4L2_AV_LINK_STAT_TX_ARB_LOST (1)
#define V4L2_AV_LINK_STAT_TX_RETRY_TIMEOUT (2)
#define V4L2_AV_LINK_STAT_TX_BROADCAST_REJECT (3)
Not every tx status is applicable for all modes, see table 1.
|-|
|Av link Mode | CEC | 1 | 2 | 3 |
|-|
| Status | | | | |
|-|
| TX_OK | a | n/a | a | n/a |
|-|
| TX_ARB_LOST| a | n/a | a | a |
|-|
| TX_RETRY_TIMEOUT| a | n/a | a | a |
|-|
| TX_BROADCAST_REJECT | a | n/a | a | n/a |
|-|
Table 1: tx status versus mode.
a: applicable
n/a: not applicable
Configuration command:
--
* AV link mode CEC:
Must be done for each logical device address which is to be
enabled on this HW. Maximum number of logical devices
is found with the capability ioctl.
conf:
index: 0 -> number_of_logical_devices-1
enable: true/false
addr: logical address
* AV link mode 1:
In mode 1 the frame l
Re: [PATCH v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format
On Fri, 11 Mar 2011 10:38:08 +0100 Michael Jones wrote: > On 03/11/2011 10:21 AM, Antonio Ospite wrote: > > Hi Michael, > > > > are you going to release also Y12 conversion routines for libv4lconvert? > > > > Regards, > >Antonio > > > > Hi Antonio, > > As I am neither a user nor developer of libv4lconvert, I am not planning > on adding Y12 conversion routines there. Hopefully somebody else will > step up. Maybe you? > I asked just for curiosity as I don't have any device producing this Y12 format, however I _might_ play with it if you can provide some Y12 (or Y10) raw frames. I am playing with some compressed variant of Y10 and I am exploring different ways to add support for those formats to libv4l. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpnjrBzC4wkU.pgp Description: PGP signature
[GIT PULL FOR 2.6.39] videobuf2 and s5p fimc driver fixes
Hi Mauro, please pull from git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro for a couple of videobuf2 and s5p fimc driver fixes and updates. Included is also the missing Docbook documentation for NV12MT format. The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro Andrzej Pietrasiewicz (2): v4l2: vb2-dma-sg: fix memory leak v4l2: vb2-dma-sg: fix potential security hole Kamil Debski (1): v4l: Documentation for the NV12MT format Marek Szyprowski (3): v4l2: vb2: fix queue reallocation and REQBUFS(0) case v4l2: vb2: one more fix for REQBUFS() v4l2: vb2: simplify __vb2_queue_free function Sungchun Kang (1): s5p-fimc: fix ISR and buffer handling for fimc-capture Sylwester Nawrocki (6): s5p-fimc: Prevent oops when i2c adapter is not available s5p-fimc: Prevent hanging on device close and fix the locking s5p-fimc: Allow defining number of sensors at runtime s5p-fimc: Add a platform data entry for MIPI-CSI data alignment s5p-fimc: Use dynamic debug s5p-fimc: Fix G_FMT ioctl handler Documentation/DocBook/media-entities.tmpl|1 + Documentation/DocBook/v4l/nv12mt.gif | Bin 0 -> 2108 bytes Documentation/DocBook/v4l/nv12mt_example.gif | Bin 0 -> 6858 bytes Documentation/DocBook/v4l/pixfmt-nv12mt.xml | 74 +++ Documentation/DocBook/v4l/pixfmt.xml |1 + drivers/media/video/s5p-fimc/fimc-capture.c | 104 -- drivers/media/video/s5p-fimc/fimc-core.c | 279 ++ drivers/media/video/s5p-fimc/fimc-core.h | 50 -- drivers/media/video/s5p-fimc/fimc-reg.c |6 +- drivers/media/video/videobuf2-core.c | 24 ++- drivers/media/video/videobuf2-dma-sg.c |4 +- include/media/s5p_fimc.h |9 +- 12 files changed, 329 insertions(+), 223 deletions(-) create mode 100644 Documentation/DocBook/v4l/nv12mt.gif create mode 100644 Documentation/DocBook/v4l/nv12mt_example.gif create mode 100644 Documentation/DocBook/v4l/pixfmt-nv12mt.xml Best regards, -- Sylwester Nawrocki Samsung Poland R&D 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
Re: [PATCH v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format
On 03/11/2011 10:21 AM, Antonio Ospite wrote: > Hi Michael, > > are you going to release also Y12 conversion routines for libv4lconvert? > > Regards, >Antonio > Hi Antonio, As I am neither a user nor developer of libv4lconvert, I am not planning on adding Y12 conversion routines there. Hopefully somebody else will step up. Maybe you? -Michael 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
Re: [PATCH v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format
On Fri, 11 Mar 2011 09:05:46 +0100 Michael Jones wrote: > Signed-off-by: Michael Jones > --- > Documentation/DocBook/v4l/pixfmt-y12.xml | 79 > ++ > include/linux/videodev2.h|1 + > 2 files changed, 80 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/v4l/pixfmt-y12.xml > Hi Michael, are you going to release also Y12 conversion routines for libv4lconvert? Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgphcaBRmszVs.pgp Description: PGP signature
RE: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello, On Thursday, March 10, 2011 3:52 PM Arnd Bergmann wrote: > On Friday 04 March 2011, Marek Szyprowski wrote: > > From: Andrzej Pietrasiewicz > > > > This patch performs a complete rewrite of sysmmu driver for Samsung > > platform: > > - the new version introduces an api to construct device private page > > tables and enables to use device private address space mode > > - simplified the resource management: no more single platform > > device with 32 resources is needed, better fits into linux driver model, > > each sysmmu instance has it's own resource definition > > - added support for sysmmu clocks > > - some other minor API chages required by upcoming videobuf2 allocator > > > > Signed-off-by: Andrzej Pietrasiewicz > > Signed-off-by: Kyungmin Park > > Signed-off-by: Marek Szyprowski > > Please explain why create a new IOMMU API when we already have two > generic ones (include/linux/iommu.h and include/linux/dma-mapping.h). > > Is there something that cannot be done with the common code? > The first approach should be to extend the existing APIs to > do what you need. We followed the style of iommu API for other mainline ARM platforms (both OMAP and MSM also have custom API for their iommu modules). I've briefly checked include/linux/iommu.h API and I've noticed that it has been designed mainly for KVM support. There is also include/linux/intel-iommu.h interface, but I it is very specific to intel gfx chips. Is there any example how include/linux/dma-mapping.h interface can be used for iommu mappings? Best regards -- Marek Szyprowski Samsung Poland R&D 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
Re: [PATCH v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format
Hi Michael, Thanks for the patch. On Friday 11 March 2011 09:05:46 Michael Jones wrote: > Signed-off-by: Michael Jones > --- > Documentation/DocBook/v4l/pixfmt-y12.xml | 79 +++ > include/linux/videodev2.h|1 + > 2 files changed, 80 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/v4l/pixfmt-y12.xml You also need to modify Documentation/DocBook/v4l/pixfmt.xml (and Documentation/DocBook/media-entities.tmpl) to include pixfmt-y12.xml, otherwise the new documentation file won't be used. Search for 'sub-y16' for an example. -- 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 v3 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
---
drivers/media/video/omap3-isp/isp.c |7 ++-
drivers/media/video/omap3-isp/isp.h |5 +-
drivers/media/video/omap3-isp/ispccdc.c | 27 ++--
drivers/media/video/omap3-isp/ispvideo.c | 108 --
drivers/media/video/omap3-isp/ispvideo.h |3 +
5 files changed, 120 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/omap3-isp/isp.c
b/drivers/media/video/omap3-isp/isp.c
index 08d90fe..866ce09 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,9 +299,9 @@ 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;
+ shift += pdata->data_lane_shift*2;
break;
case CCDC_INPUT_CSI2A:
@@ -319,6 +320,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..6f0ff1a 100644
--- a/drivers/media/video/omap3-isp/isp.h
+++ b/drivers/media/video/omap3-isp/isp.h
@@ -130,7 +130,6 @@ struct isp_reg {
/**
* struct isp_parallel_platform_data - Parallel interface platform data
- * @width: Parallel bus width in bits (8, 10, 11 or 12)
* @data_lane_shift: Data lane shifter
* 0 - CAMEXT[13:0] -> CAM[13:0]
* 1 - CAMEXT[13:2] -> CAM[11:0]
@@ -144,7 +143,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..bbcf619 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -1120,21 +1120,38 @@ 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;
+ const struct isp_format_info *fmt_info;
+ struct v4l2_subdev_format fmt_src;
+ unsigned int depth_out = 0;
+ unsigned int depth_in = 0;
struct media_pad *pad;
unsigned long flags;
+ unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
- if (ccdc->input == CCDC_INPUT_PARALLEL) {
- pad = media_entity_remote_source(&ccdc->pads[CCDC_PAD_SINK]);
- sensor = media_entity_to_v4l2_subdev(pad->entity);
+ pad = media_entity_remote_source(&ccdc->pads[CCDC_PAD_SINK]);
+ sensor = media_entity_to_v4l2_subdev(pad->entity);
+ if (ccdc->input == CCDC_INPUT_PARALLEL)
pdata = &((struct isp_v4l2_subdevs_group *)sensor->host_priv)
->bus.parallel;
+
+ /* Compute shift value for lane shifter to configure the bridge. */
+ 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->bpp;
}
- omap3isp_configure_bridge(isp, ccdc->input, pdata);
+ fmt_info = omap3isp_video_format_info
+ (isp->i
[PATCH v3 3/4] omap3isp: ccdc: support Y10/12, 8-bit bayer fmts
Signed-off-by: Michael Jones
Acked-by: Laurent Pinchart
---
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 v3 2/4] media: add 8-bit bayer formats and Y12
Signed-off-by: Michael Jones
---
Documentation/DocBook/v4l/subdev-formats.xml | 59 ++
include/linux/v4l2-mediabus.h|7 ++-
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml
b/Documentation/DocBook/v4l/subdev-formats.xml
index 2fed9be..37e5bc6 100644
--- a/Documentation/DocBook/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
@@ -456,6 +456,23 @@
b1
b0
+
+ V4L2_MBUS_FMT_SGBRG8_1X8
+ 0x3013
+
+ -
+ -
+ -
+ -
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+
V4L2_MBUS_FMT_SGRBG8_1X8
0x3002
@@ -473,6 +490,23 @@
g1
g0
+
+ V4L2_MBUS_FMT_SRGGB8_1X8
+ 0x3014
+
+ -
+ -
+ -
+ -
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+
V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8
0x300b
@@ -2159,6 +2193,31 @@
u1
u0
+
+ V4L2_MBUS_FMT_Y12_1X12
+ 0x2013
+
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ y11
+ y10
+ y9
+ y8
+ y7
+ y6
+ y5
+ y4
+ y3
+ y2
+ y1
+ y0
+
V4L2_MBUS_FMT_UYVY8_1X16
0x200f
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 7054a7a..de5c159 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,7 +47,7 @@ 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_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
@@ -60,6 +60,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b,
V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c,
+ V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f,
V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
@@ -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 v3 1/4] v4l: add V4L2_PIX_FMT_Y12 format
Signed-off-by: Michael Jones
---
Documentation/DocBook/v4l/pixfmt-y12.xml | 79 ++
include/linux/videodev2.h|1 +
2 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-y12.xml
diff --git a/Documentation/DocBook/v4l/pixfmt-y12.xml
b/Documentation/DocBook/v4l/pixfmt-y12.xml
new file mode 100644
index 000..ff417b8
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y12.xml
@@ -0,0 +1,79 @@
+
+
+V4L2_PIX_FMT_Y12 ('Y12 ')
+&manvol;
+
+
+V4L2_PIX_FMT_Y12
+Grey-scale image
+
+
+Description
+
+This is a grey-scale image with a depth of 12 bits per pixel. Pixels
+are stored in 16-bit words with unused high bits padded with 0. The least
+significant byte is stored at lower memory addresses (little-endian).
+
+
+ V4L2_PIX_FMT_Y12 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start + 0:
+ Y'00low
+ Y'00high
+ Y'01low
+ Y'01high
+ Y'02low
+ Y'02high
+ Y'03low
+ Y'03high
+
+
+ start + 8:
+ Y'10low
+ Y'10high
+ Y'11low
+ Y'11high
+ Y'12low
+ Y'12high
+ Y'13low
+ Y'13high
+
+
+ start + 16:
+ Y'20low
+ Y'20high
+ Y'21low
+ Y'21high
+ Y'22low
+ Y'22high
+ Y'23low
+ Y'23high
+
+
+ start + 24:
+ Y'30low
+ Y'30high
+ Y'31low
+ Y'31high
+ Y'32low
+ Y'32high
+ Y'33low
+ Y'33high
+
+
+
+
+
+
+
+
+
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 v3 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 v2: -new formats are also added to Documentation/DocBook/v4l/ -reintroduce .data_lane_shift for sensors whose LSB is not aligned with sensor interfaces's LSB. -style changes according to feedback 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 Documentation/DocBook/v4l/pixfmt-y12.xml | 79 +++ Documentation/DocBook/v4l/subdev-formats.xml | 59 ++ drivers/media/video/omap3-isp/isp.c |7 +- drivers/media/video/omap3-isp/isp.h |5 +- drivers/media/video/omap3-isp/ispccdc.c | 33 +++- drivers/media/video/omap3-isp/ispvideo.c | 108 ++ drivers/media/video/omap3-isp/ispvideo.h |3 + include/linux/v4l2-mediabus.h|7 +- include/linux/videodev2.h|1 + 9 files changed, 276 insertions(+), 26 deletions(-) create mode 100644 Documentation/DocBook/v4l/pixfmt-y12.xml -- 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
