RE: [PATCH v2 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Hi Sylwester,
Thank you for your comments.
My responses inline.
Thanks and Regards,
-Manju
On Fri, Sep 02, 2011 at 02:17:49, Sylwester Nawrocki wrote:
Hi Manjunath,
A few comments below...
On 08/29/2011 05:07 PM, Manjunath Hadli wrote:
add support for dm3xx IPIPEIF hardware setup. This is the lowest
software layer for the dm3x vpfe driver which directly accesses
hardware. Add support for features like default pixel correction, dark
frame substraction and hardware setup.
Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netaguntenagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 317
+++
drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++
include/linux/dm3xx_ipipeif.h | 64 ++
3 files changed, 639 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h
create mode 100644 include/linux/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..ebc8895
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,317 @@
...
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc) {
+ u32 val;
+
+ /* Intialize val*/
+ val = 0;
s/Intialize/Initialize ? But this comment doesn't seem much helpful and could
probably be removed. Also it might be better to just do:
u32 val = 0;
Done.
+
+ if (dpc-en) {
+ val = (dpc-en 1) IPIPEIF_DPC2_EN_SHIFT;
+ val |= dpc-thr IPIPEIF_DPC2_THR_MASK;
+ }
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
...
+
+static int __devinit dm3xx_ipipeif_probe(struct platform_device
+*pdev) {
+ static resource_size_t res_len;
+ struct resource *res;
+ int status;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
resource_size(res) macro could be used here
Done.
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ ipipeif_base_addr = ioremap_nocache(res-start, res_len);
+ if (!ipipeif_base_addr) {
+ status = -EBUSY;
+ goto fail;
+ }
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+
+ return status;
+}
+
+static int dm3xx_ipipeif_remove(struct platform_device *pdev) {
+ struct resource *res;
+
+ iounmap(ipipeif_base_addr);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
release_mem_region(res-start, resource_size(res));
Done.
+ return 0;
+}
+
+static struct platform_driver dm3xx_ipipeif_driver = {
+ .driver = {
+ .name = dm3xx_ipipeif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(dm3xx_ipipeif_remove),
+ .probe = dm3xx_ipipeif_probe,
+};
+
+static int dm3xx_ipipeif_init(void)
+{
+ return platform_driver_register(dm3xx_ipipeif_driver);
+}
+
+static void dm3xx_ipipeif_exit(void)
+{
+ platform_driver_unregister(dm3xx_ipipeif_driver);
+}
+
+module_init(dm3xx_ipipeif_init);
+module_exit(dm3xx_ipipeif_exit);
+
+MODULE_LICENSE(GPL2);
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.h
b/drivers/media/video/davinci/dm3xx_ipipeif.h
new file mode 100644
index 000..f3289f0
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.h
@@ -0,0 +1,258 @@
+/*
...
+
+/* IPIPEIF Register Offsets from the base address */
+#define IPIPEIF_ENABLE (0x00)
+#define IPIPEIF_CFG1 (0x04)
+#define IPIPEIF_PPLN (0x08)
+#define IPIPEIF_LPFR (0x0c)
+#define IPIPEIF_HNUM (0x10)
+#define IPIPEIF_VNUM (0x14)
+#define IPIPEIF_ADDRU (0x18)
+#define IPIPEIF_ADDRL (0x1c)
+#define IPIPEIF_ADOFS (0x20)
+#define IPIPEIF_RSZ(0x24)
+#define IPIPEIF_GAIN (0x28)
+
+/* Below registers are available only on IPIPE 5.1 */
+#define IPIPEIF_DPCM (0x2c)
+#define IPIPEIF_CFG2 (0x30)
+#define IPIPEIF_INIRSZ (0x34)
+#define IPIPEIF_OCLIP (0x38)
+#define IPIPEIF_DTUDF (0x3c)
+#define IPIPEIF_CLKDIV (0x40)
+#define IPIPEIF_DPC1 (0x44)
+#define IPIPEIF_DPC2 (0x48)
+#define IPIPEIF_DFSGVL (0x4c)
RE: [PATCH v2 4/8] davinci: vpfe: add support for CCDC hardware for dm365
Thank you for these comments too. My responses inlined. -Manju On Fri, Sep 02, 2011 at 02:53:08, Sylwester Nawrocki wrote: Hi Manjunath, few more comments below.. On 08/29/2011 05:07 PM, Manjunath Hadli wrote: add support for ccdc on dm365 SoC. ccdc is responsible for capturing video data- both raw bayer through sync seperate signals and through BT656/1120 interfaces. This driver implements the hardware functionality. Mainly- setting of hardware, validation of parameters, and isr configuration. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Signed-off-by: Nagabhushana Netaguntenagabhushana.netagu...@ti.com --- drivers/media/video/davinci/ccdc_types.h | 43 + drivers/media/video/davinci/dm365_ccdc.c | 1519 + drivers/media/video/davinci/dm365_ccdc.h | 88 ++ drivers/media/video/davinci/dm365_ccdc_regs.h | 309 + include/linux/dm365_ccdc.h| 664 +++ 5 files changed, 2623 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/ccdc_types.h create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc.h create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 include/linux/dm365_ccdc.h ... +#define CCDC_LINEAR_LUT0_ADDR 0x1c7c000 +#define CCDC_LINEAR_LUT1_ADDR 0x1c7c400 + +/* Masks Shifts below */ +#define START_PX_HOR_MASK (0x7fff) +#define NUM_PX_HOR_MASK(0x7fff) +#define START_VER_ONE_MASK (0x7fff) +#define START_VER_TWO_MASK (0x7fff) +#define NUM_LINES_VER (0x7fff) + +/* gain - offset masks */ +#define GAIN_INTEGER_MASK (0x7) +#define GAIN_INTEGER_SHIFT (0x9) +#define GAIN_DECIMAL_MASK (0x1ff) +#define OFFSET_MASK(0xfff) +#define GAIN_SDRAM_EN_SHIFT(12) +#define GAIN_IPIPE_EN_SHIFT(13) +#define GAIN_H3A_EN_SHIFT (14) +#define OFST_SDRAM_EN_SHIFT(8) +#define OFST_IPIPE_EN_SHIFT(9) +#define OFST_H3A_EN_SHIFT (10) +#define GAIN_OFFSET_EN_MASK(0x7700) + +/* Culling */ +#define CULL_PAT_EVEN_LINE_SHIFT (8) + +/* CCDCFG register */ +#define CCDC_YCINSWP_RAW (0x00 4) +#define CCDC_YCINSWP_YCBCR (0x01 4) +#define CCDC_CCDCFG_FIDMD_LATCH_VSYNC (0x00 6) +#define CCDC_CCDCFG_WENLOG_AND (0x00 8) +#define CCDC_CCDCFG_TRGSEL_WEN (0x00 9) +#define CCDC_CCDCFG_EXTRG_DISABLE (0x00 10) +#define CCDC_LATCH_ON_VSYNC_DISABLE(0x01 15) +#define CCDC_LATCH_ON_VSYNC_ENABLE (0x00 15) +#define CCDC_DATA_PACK_MASK(0x03) +#define CCDC_DATA_PACK16 (0x0) +#define CCDC_DATA_PACK12 (0x1) +#define CCDC_DATA_PACK8(0x2) +#define CCDC_PIX_ORDER_SHIFT (11) +#define CCDC_PIX_ORDER_MASK(0x01) +#define CCDC_BW656_ENABLE (0x01 5) + +/* MODESET registers */ +#define CCDC_VDHDOUT_INPUT (0x00 0) +#define CCDC_INPUT_MASK(0x03) +#define CCDC_INPUT_SHIFT (12) +#define CCDC_RAW_INPUT_MODE(0x00) +#define CCDC_FID_POL_MASK (0x01) +#define CCDC_FID_POL_SHIFT (4) +#define CCDC_HD_POL_MASK (0x01) +#define CCDC_HD_POL_SHIFT (3) +#define CCDC_VD_POL_MASK (0x01) +#define CCDC_VD_POL_SHIFT (2) +#define CCDC_DATAPOL_NORMAL(0x00) +#define CCDC_DATAPOL_MASK (0x01) +#define CCDC_DATAPOL_SHIFT (6) +#define CCDC_EXWEN_DISABLE (0x00) +#define CCDC_EXWEN_MASK(0x01) +#define CCDC_EXWEN_SHIFT (5) +#define CCDC_FRM_FMT_MASK (0x01) +#define CCDC_FRM_FMT_SHIFT (7) +#define CCDC_DATASFT_MASK (0x07) +#define CCDC_DATASFT_SHIFT (8) +#define CCDC_LPF_SHIFT (14) +#define CCDC_LPF_MASK (0x1) + +/* GAMMAWD registers */ +#define CCDC_ALAW_GAMA_WD_MASK (0xf) +#define CCDC_ALAW_GAMA_WD_SHIFT(1) +#define CCDC_ALAW_ENABLE (0x01) +#define CCDC_GAMMAWD_CFA_MASK (0x01) +#define CCDC_GAMMAWD_CFA_SHIFT (5)
Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Hello. On 09/06/2011 06:36 PM, Sergei Shtylyov wrote: Signed-off-by: Murali Karicherim-kariche...@ti.com [...] + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); + pdctl |= 0x1; + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); ptcmd = 1 domain; __raw_writel(ptcmd, psc_base + PTCMD); @@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr, epcpr = __raw_readl(psc_base + EPCPR); } while epcpr domain) 1) == 0)); Does this work for ARM domain, i.e. does it require an external power supply too? Not sure. Will someone actively using the DaVinci platforms answer this question? I may try to verify on my DM6446 if I'll find the time... Hmm, DA8x0 documentation doesn't even mention the EPCPR register, so I'm not sure how this loop is supposed to work on those chips... unless this path is never actually executed -- which I'm trying to check now... Have verified that the patch was never being executed indeed. If I make it s/patch/path/ executed, the board happily locks up. I have experimented further and added code to power off domain 1 before powering it on in davinci_psc_config(). Strangely, it worked -- OMAP-L137 Application Processor System Reference Guide says that powering off domain 1 is not supported. The board still locks up while polling the EPCPR register -- which doesn't exist on DA8xx. So looks like this code has even more issues... I think we should add a check for DA8xx before that loop; I'll look into it... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Hello,. On 09/09/2011 06:56 PM, Sergei Shtylyov wrote: Signed-off-by: Murali Karicherim-kariche...@ti.com [...] + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); + pdctl |= 0x1; + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); ptcmd = 1 domain; __raw_writel(ptcmd, psc_base + PTCMD); @@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr, epcpr = __raw_readl(psc_base + EPCPR); } while epcpr domain) 1) == 0)); Does this work for ARM domain, i.e. does it require an external power supply too? Not sure. Will someone actively using the DaVinci platforms answer this question? I may try to verify on my DM6446 if I'll find the time... Hmm, DA8x0 documentation doesn't even mention the EPCPR register, so I'm not sure how this loop is supposed to work on those chips... unless this path is never actually executed -- which I'm trying to check now... Have verified that the patch was never being executed indeed. If I make it s/patch/path/ executed, the board happily locks up. I have experimented further and added code to power off domain 1 before powering it on in davinci_psc_config(). Strangely, it worked -- OMAP-L137 Application Processor System Reference Guide says that powering off domain 1 is not supported. The board still locks up while polling the EPCPR register -- which doesn't exist on DA8xx. BTW, I have tried the same on the DM6446 EVM board and there it locked up while polling the PTSTAT register after sent command to I power down the DSP domain. This seems to be in accordance with DM6446 datasheet which says that once powered on, DSP domain cannot be dynamically powered off. So I couldn't test the EPCPR polling loop on DM6446... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
On Fri, Sep 09, 2011 at 07:10:49PM +0530, Hadli, Manjunath wrote: Hi Sakari, On Thu, Sep 01, 2011 at 03:00:32, Sakari Ailus wrote: Hi Manju, Do you have the media device grap that would be typical for this hardware produced by media-ctl? That can be converted to postscript using dotfile. this would make it a little easier to understan this driver. Thanks. Sure. But can you be a little more elaborate on how you need this information? If you can tell me in little more detail about this that will help me make the information in a way that everyone can understand. Preferrably in PostScript format so it's easy to visualise the layout of the hardware that the driver supports, as the OMAP 3 ISP example was. Thanks and Regards, -Manju On Mon, Aug 29, 2011 at 08:37:11PM +0530, Manjunath Hadli wrote: changes from last patch set: 1. Made changes based on Sakari's feedback mainly: a. returned early to allow unindenting b. reformatting to shift the code to left where possible c. changed hex numbers to lower case d. corrected the defines according to module names. e. magic numbers removed. f. changed non-integer returning functions to void g. removed unwanted paranthses. h. fixed error codes. i. fixed some RESET_BIt code to what it was intended for. 2. reorganized the header files to move the kernel-only headers along with the c files and interface headers in the include folder. ... -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 4/8] davinci: vpfe: add support for CCDC hardware for dm365
Hi Manju,
On 09/09/2011 03:30 PM, Hadli, Manjunath wrote:
Thank you for these comments too.
My responses inlined.
-Manju
Thanks for addressing my comments.
On Fri, Sep 02, 2011 at 02:53:08, Sylwester Nawrocki wrote:
...
+/**
+ * ccdc float type S8Q8/U8Q8
+ */
+struct ccdc_float_8 {
+ /* 8 bit integer part */
+ unsigned char integer;
+ /* 8 bit decimal part */
+ unsigned char decimal;
+};
Isn't it better to use explicit width type, like u8, u16, etc. ?
Then we could just have:
+struct ccdc_float_8 {
+u8 integer;
+u8 decimal;
+};
This is an interface header which is also used by apps. So we have
kept it as unsigned char. Any suggestions on that?
OK, sorry, I haven't noticed that. Anyway, I think you could use the
double underscore prefixed types (__[u,s][8,32,16]), from linux/types.h.
They are widely used in in linux/videodev2.h for instance.
--
Regards,
Sylwester
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
L138/DA850 USB support in mainline?
What is the current level of support for USB on L138/DA850 in the mainline kernel? A similar question was asked here: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-Jul y/023201.html but not really answered. I'm curious because TI's site at: http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel seems to suggest that USB is still not there, but from reading forum posts it seems as if people are using USB on L138/DA850 with mainline kernels. We are currently using a TI release, but I would like to migrate to a mainline version. USB appears to be the only questionable feature at this point. Can anyone clarify what support might be missing before I take the time to make the jump, only to find out that it's not going to work anyway? I don't mind doing some work to glue pieces together, but if major functionality is missing, it would be nice to know beforehand. Thanks for the help! Brian Brian Niebuhr Principal Design Engineer EF Johnson 3900 NW 12th St. Ste. 200 Lincoln, NE 68521 402-479-8434 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ASoC: davinci-pcm: trivial: replace link with actual chan/link
The ambiguously named variable 'link' is used as a temporary throughout
davinci-pcm -- its presence makes grepping (and groking) the code
difficult.
Replace link with the value of link in almost all sites. The exception
is a couple places where the last-assigned link/chan needs to be
returned by a function -- in these cases, rename to last_link.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
---
sound/soc/davinci/davinci-pcm.c | 123 +++
1 files changed, 59 insertions(+), 64 deletions(-)
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index a49e667..d5fe08c 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -180,7 +180,6 @@ static void davinci_pcm_enqueue_dma(struct
snd_pcm_substream *substream)
{
struct davinci_runtime_data *prtd = substream-runtime-private_data;
struct snd_pcm_runtime *runtime = substream-runtime;
- int link = prtd-asp_link[0];
unsigned int period_size;
unsigned int dma_offset;
dma_addr_t dma_pos;
@@ -198,7 +197,8 @@ static void davinci_pcm_enqueue_dma(struct
snd_pcm_substream *substream)
fifo_level = prtd-params-fifo_level;
pr_debug(davinci_pcm: audio_set_dma_params_play channel = %d
- dma_ptr = %x period_size=%x\n, link, dma_pos, period_size);
+ dma_ptr = %x period_size=%x\n, prtd-asp_link[0], dma_pos,
+ period_size);
data_type = prtd-params-data_type;
count = period_size / data_type;
@@ -222,17 +222,19 @@ static void davinci_pcm_enqueue_dma(struct
snd_pcm_substream *substream)
}
acnt = prtd-params-acnt;
- edma_set_src(link, src, INCR, W8BIT);
- edma_set_dest(link, dst, INCR, W8BIT);
+ edma_set_src(prtd-asp_link[0], src, INCR, W8BIT);
+ edma_set_dest(prtd-asp_link[0], dst, INCR, W8BIT);
- edma_set_src_index(link, src_bidx, src_cidx);
- edma_set_dest_index(link, dst_bidx, dst_cidx);
+ edma_set_src_index(prtd-asp_link[0], src_bidx, src_cidx);
+ edma_set_dest_index(prtd-asp_link[0], dst_bidx, dst_cidx);
if (!fifo_level)
- edma_set_transfer_params(link, acnt, count, 1, 0, ASYNC);
+ edma_set_transfer_params(prtd-asp_link[0], acnt, count, 1, 0,
+ ASYNC);
else
- edma_set_transfer_params(link, acnt, fifo_level, count,
- fifo_level, ABSYNC);
+ edma_set_transfer_params(prtd-asp_link[0], acnt, fifo_level,
+ count, fifo_level,
+ ABSYNC);
}
static void davinci_pcm_dma_irq(unsigned link, u16 ch_status, void *data)
@@ -305,7 +307,6 @@ static int ping_pong_dma_setup(struct snd_pcm_substream
*substream)
unsigned int acnt = params-acnt;
/* divide by 2 for ping/pong */
unsigned int ping_size = snd_pcm_lib_period_bytes(substream) 1;
- int link = prtd-asp_link[1];
unsigned int fifo_level = prtd-params-fifo_level;
unsigned int count;
if ((data_type == 0) || (data_type 4)) {
@@ -316,28 +317,26 @@ static int ping_pong_dma_setup(struct snd_pcm_substream
*substream)
dma_addr_t asp_src_pong = iram_dma-addr + ping_size;
ram_src_cidx = ping_size;
ram_dst_cidx = -ping_size;
- edma_set_src(link, asp_src_pong, INCR, W8BIT);
+ edma_set_src(prtd-asp_link[1], asp_src_pong, INCR, W8BIT);
- link = prtd-asp_link[0];
- edma_set_src_index(link, data_type, data_type * fifo_level);
- link = prtd-asp_link[1];
- edma_set_src_index(link, data_type, data_type * fifo_level);
+ edma_set_src_index(prtd-asp_link[0], data_type,
+ data_type * fifo_level);
+ edma_set_src_index(prtd-asp_link[1], data_type,
+ data_type * fifo_level);
- link = prtd-ram_link;
- edma_set_src(link, runtime-dma_addr, INCR, W32BIT);
+ edma_set_src(prtd-ram_link, runtime-dma_addr, INCR, W32BIT);
} else {
dma_addr_t asp_dst_pong = iram_dma-addr + ping_size;
ram_src_cidx = -ping_size;
ram_dst_cidx = ping_size;
- edma_set_dest(link, asp_dst_pong, INCR, W8BIT);
+ edma_set_dest(prtd-asp_link[1], asp_dst_pong, INCR, W8BIT);
- link = prtd-asp_link[0];
- edma_set_dest_index(link, data_type, data_type * fifo_level);
- link = prtd-asp_link[1];
- edma_set_dest_index(link, data_type, data_type * fifo_level);
+ edma_set_dest_index(prtd-asp_link[0], data_type,
+ data_type *
