From: Lad, Prabhakar <[email protected]>
This patch series enables VPBE display driver on DM355.
This patch series is dependent on VPSS clock cleanup patches
(http://www.mail-archive.com/[email protected]/msg25613.html)
posted.
Changes for v8:
1: Removed extra line after break's and defines as pointed
by Sekhar.
2: Included Ack from Sekhar for the second patch of the series.
Changes for v7:
1: Fixed nits pointed by Sekhar for DM365 series.
Changes for v6:
1: Fixed nits pointed by Sekhar.
Changes for v5:
1: Rebased on 3.9, fix review comments pointed by Sekhar for DM365 series.
Changes for v4:
1: pass different platform names to handle different ip's.
Changes for v3:
1: Replaced obsolete preset API by timings API.
Changes for v2:
1: Removed VPSS clock alias for master and slave which was
sent for VPSS driver. since this patch was dependent on
patch[1]. I will revist this patch once MC(captrure driver)
goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html
Lad, Prabhakar (2):
ARM: davinci: dm355: add support for v4l2 video display
ARM: davinci: dm355 EVM: add support for VPBE display
arch/arm/mach-davinci/board-dm355-evm.c | 71 +++++++++++++-
arch/arm/mach-davinci/davinci.h | 3 +-
arch/arm/mach-davinci/dm355.c | 167 ++++++++++++++++++++++++++++++-
3 files changed, 233 insertions(+), 8 deletions(-)
--
1.7.4.1
From: Lad, Prabhakar <[email protected]>
Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm355.
Signed-off-by: Lad, Prabhakar <[email protected]>
---
arch/arm/mach-davinci/board-dm355-evm.c | 4 +-
arch/arm/mach-davinci/davinci.h | 3 +-
arch/arm/mach-davinci/dm355.c | 167 ++++++++++++++++++++++++++++++-
3 files changed, 166 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 147b8e1..37d12cc 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
- /* setup input configuration for VPFE input devices */
- dm355_set_vpfe_config(&vpfe_cfg);
dm355_init();
}
@@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, &dm355evm_mmc_config);
davinci_setup_mmc(1, &dm355evm_mmc_config);
+ dm355_init_video(&vpfe_cfg, NULL);
+
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index a9de512..c4d9be5 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -39,6 +39,7 @@
#define SYSMOD_VDAC_CONFIG 0x2c
#define SYSMOD_VIDCLKCTL 0x38
#define SYSMOD_VPSS_CLKCTL 0x44
+#define VPSS_MUXSEL_EXTCLK_ENABLE BIT(1)
#define VPSS_VENCCLKEN_ENABLE BIT(3)
#define VPSS_DACCLKEN_ENABLE BIT(4)
#define VPSS_PLLC2SYSCLK5_ENABLE BIT(5)
@@ -79,7 +80,7 @@ void __init dm355_init(void);
void dm355_init_spi0(unsigned chipselect_mask,
const struct spi_board_info *info, unsigned len);
void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
-void dm355_set_vpfe_config(struct vpfe_config *cfg);
+int dm355_init_video(struct vpfe_config *, struct vpbe_config *);
/* DM365 function declarations */
void __init dm365_init(void);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 8e98bb0..bf9a9d4 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -35,6 +35,8 @@
#include "asp.h"
#define DM355_UART2_BASE (IO_PHYS + 0x206000)
+#define DM355_OSD_BASE (IO_PHYS + 0x70200)
+#define DM355_VENC_BASE (IO_PHYS + 0x70400)
/*
* Device specific clocks
@@ -744,11 +746,146 @@ static struct platform_device vpfe_capture_dev = {
},
};
-void dm355_set_vpfe_config(struct vpfe_config *cfg)
+static struct resource dm355_osd_resources[] = {
+ {
+ .start = DM355_OSD_BASE,
+ .end = DM355_OSD_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm355_osd_dev = {
+ .name = DM355_VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_osd_resources),
+ .resource = dm355_osd_resources,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+static struct resource dm355_venc_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM355_VENC_BASE,
+ .end = DM355_VENC_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+ /* VDAC config register io space */
+ {
+ .start = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG,
+ .end = DAVINCI_SYSTEM_MODULE_BASE + SYSMOD_VDAC_CONFIG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct resource dm355_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* venc registers io space */
+ {
+ .start = DM355_VENC_BASE,
+ .end = DM355_VENC_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+ int field)
+{
+ switch (if_type) {
+ case V4L2_MBUS_FMT_SGRBG8_1X8:
+ davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+ break;
+ case V4L2_MBUS_FMT_YUYV10_1X20:
+ if (field)
+ davinci_cfg_reg(DM355_VOUT_FIELD);
+ else
+ davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ davinci_cfg_reg(DM355_VOUT_COUTL_EN);
+ davinci_cfg_reg(DM355_VOUT_COUTH_EN);
+
+ return 0;
+}
+
+static int dm355_venc_setup_clock(enum vpbe_enc_timings_type type,
+ unsigned int pclock)
{
- vpfe_capture_dev.dev.platform_data = cfg;
+ void __iomem *vpss_clk_ctrl_reg;
+
+ vpss_clk_ctrl_reg = DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL);
+
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(VPSS_DACCLKEN_ENABLE | VPSS_VENCCLKEN_ENABLE,
+ vpss_clk_ctrl_reg);
+ break;
+ case VPBE_ENC_DV_TIMINGS:
+ if (pclock > 27000000)
+ /*
+ * For HD, use external clock source since we cannot
+ * support HD mode with internal clocks.
+ */
+ writel(VPSS_MUXSEL_EXTCLK_ENABLE, vpss_clk_ctrl_reg);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
}
+static struct platform_device dm355_vpbe_display = {
+ .name = "vpbe-v4l2",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_v4l2_disp_resources),
+ .resource = dm355_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm355_venc_pdata = {
+ .setup_pinmux = dm355_vpbe_setup_pinmux,
+ .setup_clock = dm355_venc_setup_clock,
+};
+
+static struct platform_device dm355_venc_dev = {
+ .name = DM355_VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_venc_resources),
+ .resource = dm355_venc_resources,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = (void *)&dm355_venc_pdata,
+ },
+};
+
+static struct platform_device dm355_vpbe_dev = {
+ .name = "vpbe_controller",
+ .id = -1,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
/*----------------------------------------------------------------------*/
static struct map_desc dm355_io_desc[] = {
@@ -868,6 +1005,29 @@ void __init dm355_init(void)
davinci_map_sysmod();
}
+int __init dm355_init_video(struct vpfe_config *vpfe_cfg,
+ struct vpbe_config *vpbe_cfg)
+{
+ if (vpfe_cfg || vpbe_cfg)
+ platform_device_register(&dm355_vpss_device);
+
+ if (vpfe_cfg) {
+ vpfe_capture_dev.dev.platform_data = vpfe_cfg;
+ platform_device_register(&dm355_ccdc_dev);
+ platform_device_register(&vpfe_capture_dev);
+ }
+
+ if (vpbe_cfg) {
+ dm355_vpbe_dev.dev.platform_data = vpbe_cfg;
+ platform_device_register(&dm355_osd_dev);
+ platform_device_register(&dm355_venc_dev);
+ platform_device_register(&dm355_vpbe_dev);
+ platform_device_register(&dm355_vpbe_display);
+ }
+
+ return 0;
+}
+
static int __init dm355_init_devices(void)
{
if (!cpu_is_davinci_dm355())
@@ -875,9 +1035,6 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
- platform_device_register(&dm355_vpss_device);
- platform_device_register(&dm355_ccdc_dev);
- platform_device_register(&vpfe_capture_dev);
return 0;
}
--
1.7.4.1
From: Lad, Prabhakar <[email protected]>
add support for V4L2 video display to DM355 EVM.
Support for SD modes is provided, along with Composite
output
Signed-off-by: Lad, Prabhakar <[email protected]>
Acked-by: Sekhar Nori <[email protected]>
---
arch/arm/mach-davinci/board-dm355-evm.c | 69 ++++++++++++++++++++++++++++++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 37d12cc..1043506 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -242,6 +242,73 @@ static struct vpfe_config vpfe_cfg = {
.ccdc = "DM355 CCDC",
};
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
+ {
+ .name = "ntsc",
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_525_60,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 480,
+ .aspect = {11, 10},
+ .fps = {30000, 1001},
+ .left_margin = 0x79,
+ .upper_margin = 0x10,
+ },
+ {
+ .name = "pal",
+ .timings_type = VPBE_ENC_STD,
+ .std_id = V4L2_STD_625_50,
+ .interlaced = 1,
+ .xres = 720,
+ .yres = 576,
+ .aspect = {54, 59},
+ .fps = {25, 1},
+ .left_margin = 0x7E,
+ .upper_margin = 0x16
+ },
+};
+
+#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First those from venc followed by that
+ * from encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm355evm_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = DM355_VPBE_VENC_SUBDEV_NAME,
+ .default_mode = "ntsc",
+ .num_modes = ARRAY_SIZE(dm355evm_enc_preset_timing),
+ .modes = dm355evm_enc_preset_timing,
+ .if_params = V4L2_MBUS_FMT_FIXED,
+ },
+};
+
+static struct vpbe_config dm355evm_display_cfg = {
+ .module_name = "dm355-vpbe-display",
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = DM355_VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = DM355_VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm355evm_vpbe_outputs),
+ .outputs = dm355evm_vpbe_outputs,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
&dm355evm_dm9000,
&davinci_nand_device,
@@ -342,7 +409,7 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, &dm355evm_mmc_config);
davinci_setup_mmc(1, &dm355evm_mmc_config);
- dm355_init_video(&vpfe_cfg, NULL);
+ dm355_init_video(&vpfe_cfg, &dm355evm_display_cfg);
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
--
1.7.4.1
On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <[email protected]>
>
> This patch series enables VPBE display driver on DM355.
These (this and the DM365 one) patches look good to me. I need to get an
immutable branch from Mauro where dependencies are queued and then I can
generate a pull request for these for ARM SoC.
Thanks,
Sekhar
Hi Sekhar,
Em Mon, 8 Apr 2013 16:06:24 +0530
Sekhar Nori <[email protected]> escreveu:
> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> > From: Lad, Prabhakar <[email protected]>
> >
> > This patch series enables VPBE display driver on DM355.
>
> These (this and the DM365 one) patches look good to me. I need to get an
> immutable branch from Mauro where dependencies are queued and then I can
> generate a pull request for these for ARM SoC.
Are you mean a branch at the media development tree for you to sent
pull requests for me? If so, just use the "master" branch at the media
tree:
http://git.linuxtv.org/media_tree.git
The master branch there is never rebased. I'll likely start to have
topic branches on the next Kernel cycle, also at the same tree.
Regards,
Mauro
Hi Maruo,
On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
> Hi Sekhar,
>
> Em Mon, 8 Apr 2013 16:06:24 +0530
> Sekhar Nori <[email protected]> escreveu:
>
>> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
>>> From: Lad, Prabhakar <[email protected]>
>>>
>>> This patch series enables VPBE display driver on DM355.
>>
>> These (this and the DM365 one) patches look good to me. I need to get an
>> immutable branch from Mauro where dependencies are queued and then I can
>> generate a pull request for these for ARM SoC.
>
> Are you mean a branch at the media development tree for you to sent
> pull requests for me? If so, just use the "master" branch at the media
The pull request will be sent to my upstreams (ie the ARM SoC folks -
Arnd and Olof). Since the platform data patches need driver patches to
be applied first, I need a non-rebasing branch containing the driver
stuff which I can use a dependency and apply platform patches on top.
> tree:
> http://git.linuxtv.org/media_tree.git
>
> The master branch there is never rebased. I'll likely start to have
> topic branches on the next Kernel cycle, also at the same tree.
Ideally I will use the immutable branch which you will also use to send
pull request to Linus so there are not unnecessary merge conflicts. When
will those branches be ready?
Thanks,
Sekhar
Em Mon, 8 Apr 2013 17:17:34 +0530
Sekhar Nori <[email protected]> escreveu:
> Hi Maruo,
>
> On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
> > Hi Sekhar,
> >
> > Em Mon, 8 Apr 2013 16:06:24 +0530
> > Sekhar Nori <[email protected]> escreveu:
> >
> >> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> >>> From: Lad, Prabhakar <[email protected]>
> >>>
> >>> This patch series enables VPBE display driver on DM355.
> >>
> >> These (this and the DM365 one) patches look good to me. I need to get an
> >> immutable branch from Mauro where dependencies are queued and then I can
> >> generate a pull request for these for ARM SoC.
> >
> > Are you mean a branch at the media development tree for you to sent
> > pull requests for me? If so, just use the "master" branch at the media
>
> The pull request will be sent to my upstreams (ie the ARM SoC folks -
> Arnd and Olof). Since the platform data patches need driver patches to
> be applied first, I need a non-rebasing branch containing the driver
> stuff which I can use a dependency and apply platform patches on top.
Hmm... I generally wait for arch patches to be applied first, before
sending driver patches. If you're willing to do that, I suggest that
Arnd/Olof should put those patches on a separate topic branch, and
sending an upstream pull request for them after mine.
If the patches are trivial, maybe the better would be to put both
media and arm patches at the same tree, with the other maintainers'
ack.
>
> > tree:
> > http://git.linuxtv.org/media_tree.git
> >
> > The master branch there is never rebased. I'll likely start to have
> > topic branches on the next Kernel cycle, also at the same tree.
>
> Ideally I will use the immutable branch which you will also use to send
> pull request to Linus so there are not unnecessary merge conflicts. When
> will those branches be ready?
I use a tree at Kernel.org for Linus submission. I only pull the patches
there when I'm about to ask him to pull, and after being sure that those
patches were already successfully merged at -next tree for some time.
So, you should not base your tree there, as it will have there only the
patches that I already submitted.
Regards,
Mauro
On 4/8/2013 6:26 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 8 Apr 2013 17:17:34 +0530
> Sekhar Nori <[email protected]> escreveu:
>
>> Hi Maruo,
>>
>> On 4/8/2013 4:26 PM, Mauro Carvalho Chehab wrote:
>>> Hi Sekhar,
>>>
>>> Em Mon, 8 Apr 2013 16:06:24 +0530
>>> Sekhar Nori <[email protected]> escreveu:
>>>
>>>> On 4/8/2013 2:56 PM, Prabhakar lad wrote:
>>>>> From: Lad, Prabhakar <[email protected]>
>>>>>
>>>>> This patch series enables VPBE display driver on DM355.
>>>>
>>>> These (this and the DM365 one) patches look good to me. I need to get an
>>>> immutable branch from Mauro where dependencies are queued and then I can
>>>> generate a pull request for these for ARM SoC.
>>>
>>> Are you mean a branch at the media development tree for you to sent
>>> pull requests for me? If so, just use the "master" branch at the media
>>
>> The pull request will be sent to my upstreams (ie the ARM SoC folks -
>> Arnd and Olof). Since the platform data patches need driver patches to
>> be applied first, I need a non-rebasing branch containing the driver
>> stuff which I can use a dependency and apply platform patches on top.
>
> Hmm... I generally wait for arch patches to be applied first, before
> sending driver patches. If you're willing to do that, I suggest that
> Arnd/Olof should put those patches on a separate topic branch, and
> sending an upstream pull request for them after mine.
The patches can be put on a separate branch, but the branch wont build
without the driver changes (eg need defintion of VPBE_ENC_DV_TIMINGS
from include/media/davinci/vpbe_types.h).
So this will need a immutable branch from you to depend on so Linus's
tree won't have duplicate commits when Arnd/Olof send their pull request.
>
> If the patches are trivial, maybe the better would be to put both
> media and arm patches at the same tree, with the other maintainers'
> ack.
This seems to be the easiest path at the moment. I will ack the platform
parts and Prabhakar can issue a pull request for you. I have just
checked that these patches won't cause a merge conflict with anything
already queued through my tree.
Thanks,
Sekhar
On 4/8/2013 2:56 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar <[email protected]>
>
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm355.
>
> Signed-off-by: Lad, Prabhakar <[email protected]>
For patches 1/2 and 2/2:
Acked-by: Sekhar Nori <[email protected]>
Thanks,
Sekhar