Re: [PATCH] ARM: davinci: dm644x: fix out range signal for ED
On 10/4/2012 7:23 PM, Prabhakar Lad wrote: Sekhar On Thu, Oct 4, 2012 at 12:43 PM, Sekhar Nori nsek...@ti.com wrote: On 10/4/2012 10:22 AM, Prabhakar Lad wrote: Hi Sekhar, On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori nsek...@ti.com wrote: On 10/3/2012 12:05 PM, Prabhakar wrote: From: Lad, Prabhakar prabhakar@ti.com while testing display on dm644x, for ED out-range signals was observed. This patch fixes appropriate clock setting for ED. Can you please clarify what you mean by out range signal? Are there any user visible artifacts on the display? What was the clock being provided earlier and what is the value after this patch? Also, is the issue severe enough that this patch should be applied to stable tree as well? Ideally a clock of 54Mhz is required for enhanced definition to work, which it was actually set to but while testing I noticed out-of-range signal. The out-of-range signal is often caused when the field rate is above the rate that the television will handle. When this is the case the TV or monitor displays Out-Of-Range Signal. Reducing the clock fixed it. now the clock is set to 27Mhz. So, is the requirement for ED 54MHz or lower? Still trying to explain myself how 27MHz is working where a 54MHz is required. I guess there is also a lower limit on what the frequency should be? Ideally its 54Mhz, but I see in the datasheet for AD7342/3 [1] it can also work at 27Mhz too. So, based on this discussion I think a better description would be: Fix the video clock setting when custom timings are used with pclock = 27MHz. Existing clock selection uses PLL2 mode which results in a 54MHz clock where as using the MXI mode results in a 27MHz clock (which is the one actually desired). This affects the Enhanced Definition (ED) support on DM644x. Without this patch, out-range signals errors are were observed on the TV. An out-of-range signal is often caused when the field rate is above the rate that the television will handle. Is this accurate? In future, please try to be descriptive in patch description as it will help understand what the patch is doing and why (which in turn will lead to the patch getting accepted faster). Also I assume you need this patch in v3.7? Or can I send it for v3.8? Thanks, Sekhar ___ 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] ARM: davinci: dm644x: fix out range signal for ED
Sekhar, On Fri, Oct 26, 2012 at 1:05 PM, Sekhar Nori nsek...@ti.com wrote: On 10/4/2012 7:23 PM, Prabhakar Lad wrote: Sekhar On Thu, Oct 4, 2012 at 12:43 PM, Sekhar Nori nsek...@ti.com wrote: On 10/4/2012 10:22 AM, Prabhakar Lad wrote: Hi Sekhar, On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori nsek...@ti.com wrote: On 10/3/2012 12:05 PM, Prabhakar wrote: From: Lad, Prabhakar prabhakar@ti.com while testing display on dm644x, for ED out-range signals was observed. This patch fixes appropriate clock setting for ED. Can you please clarify what you mean by out range signal? Are there any user visible artifacts on the display? What was the clock being provided earlier and what is the value after this patch? Also, is the issue severe enough that this patch should be applied to stable tree as well? Ideally a clock of 54Mhz is required for enhanced definition to work, which it was actually set to but while testing I noticed out-of-range signal. The out-of-range signal is often caused when the field rate is above the rate that the television will handle. When this is the case the TV or monitor displays Out-Of-Range Signal. Reducing the clock fixed it. now the clock is set to 27Mhz. So, is the requirement for ED 54MHz or lower? Still trying to explain myself how 27MHz is working where a 54MHz is required. I guess there is also a lower limit on what the frequency should be? Ideally its 54Mhz, but I see in the datasheet for AD7342/3 [1] it can also work at 27Mhz too. So, based on this discussion I think a better description would be: Fix the video clock setting when custom timings are used with pclock = 27MHz. Existing clock selection uses PLL2 mode which results in a 54MHz clock where as using the MXI mode results in a 27MHz clock (which is the one actually desired). This affects the Enhanced Definition (ED) support on DM644x. Without this patch, out-range signals errors are were observed on the TV. An out-of-range signal is often caused when the field rate is above the rate that the television will handle. Is this accurate? In future, please try to be descriptive in patch description as it will help understand what the patch is doing and why (which in turn will lead to the patch getting accepted faster). Looks good. I'll make sure to have descriptive commit message hence forth. Also I assume you need this patch in v3.7? Or can I send it for v3.8? Since its a fix it would be good if its queued for v3.7. Regards, --Prabhakar Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC PATCH v3 00/16] DMA Engine support for AM33XX
On Thu, Oct 18, 2012 at 6:26 AM, Matt Porter mpor...@ti.com wrote: Changes since v2: - Rebased on 3.7-rc1 - Fixed bug in DT/pdata parsing first found by Gururaja that turned out to be masked by some toolchains - Dropped unused mach-omap2/devices.c hsmmc patch - Added AM33XX crossbar DMA event mux support - Added am335x-evm support Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties TODO: - Add dmaengine support for per-channel caps so the hack to set the maximum segments can be replaced with a query to the dmaengine driver This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. This pretty far along and looks great. Reviewed-by: russ.d...@ti.com The series applies on top of 3.7-rc1 and the following patches: - GPMC fails to reserve memory fix: http://www.spinics.net/lists/linux-omap/msg79675.html - TPS65910 regulator fix: https://patchwork.kernel.org/patch/1593651/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. Matt Porter (16): dmaengine: edma: fix slave config dependency on direction ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM33XX ARM: edma: add AM33XX crossbar event support dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI support Documentation/devicetree/bindings/dma/ti-edma.txt | 51 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- arch/arm/Kconfig |1 + arch/arm/boot/dts/am335x-bone.dts | 23 + arch/arm/boot/dts/am335x-evm.dts | 15 + arch/arm/boot/dts/am33xx.dtsi | 101 ++ arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1841 arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/board-da830-evm.c|4 +- arch/arm/mach-davinci/board-da850-evm.c|8 +-
Re: [PATCH v2] arch/arm/mach-davinci/board-dm646x-evm.c: Remove unecessary semicolon
On 9/18/2012 10:29 PM, Peter Senna Tschudin wrote: Found by http://coccinelle.lip6.fr/ Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com Queuing this for v3.8 Thanks, Sekhar ___ 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/6] ARM: davinci: Changed pr_warning() to pr_warn()
Hello. It's not a good idea to send multiple patches with the same subject. Actually, in this case it's worth merging all 4 patches into one. On 26-10-2012 0:35, Robert Tivy wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '%s:, __func__' instead Signed-off-by: Robert Tivy rt...@ti.com --- Clean up files that will be otherwise modified in subsequent patch. Applies to v3.5 tag (commit 28a33cbc24e4256c143dce96c7d93bf423229f92) of Linus' mainline kernel at git.kernel.org. 3.5 is too old. Why not to 3.6 or even 3.7-rc2? diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 0149fb4..bbb3c73 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] @@ -1046,21 +1046,19 @@ static int __init da850_evm_config_emac(void) } if (ret) - pr_warning(da850_evm_init: cpgmac/rmii mux setup failed: %d\n, - ret); + pr_warn(%s: cpgmac/rmii mux setup failed: %d\n, + __func__, ret); /* configure the CFGCHIP3 register for RMII or MII */ __raw_writel(val, cfg_chip3_base); ret = davinci_cfg_reg(DA850_GPIO2_6); if (ret) - pr_warning(da850_evm_init:GPIO(2,6) mux setup - failed\n); + pr_warn(%s:GPIO(2,6) mux setup failed\n, __func__); Worth inserting space after colon here. 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] ARM: davinci: dm644x: move the dereference below the NULL test
On 9/10/2012 10:19 AM, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn The dereference should be moved below the NULL test. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Queuing this for inclusion in v3.8 Thanks, Sekhar ___ 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] davinci: fix the uart number in the comment
On 9/13/2012 11:34 PM, Henrique Camargo wrote: The bit 0 of the field is uart0 and the bit 1 is uart1 and so on. Signed-off-by: Henrique Camargo henri...@henriquecamargo.com Queuing this for v3.8. Added an ARM: prefix to subject line since this is an arch/arm/ patch. Please take care of this next time on. Thanks, Sekhar ___ 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 v1] DaVinci: dm365: added sdram dma clock divide ratio management
Hi Davide,
On Thu, Oct 4, 2012 at 9:18 PM, Davide Bonfanti
davide.bonfa...@bticino.it wrote:
This patch applies to: v2.6.32.17-6450-g6725c92
commit 74f19831af149656f705b3b8a8c32bdf8c1c74fb
The CLKDIV register is then used to select a divide ratio of the SDRAM(DMA)
clock for the pixel clock frequency which is used to clock the data into the
PCLK.
The CLKDIV register is then used to select a divide ratio of the SDRAM(DMA)
clock for the pixel clock frequency which is used to clock the data into the
PCLK. The value of this register depends on the resize ratios of the IPIPE
resizers and the available SDRAM system bandwidth.
Once defined input and output resolutions to the Resizer, the clock must be
at least MAX(input_resolution, output_resolution) * framerate. This is a rough
approximation, the resizer needs some additional lines and pixels at the
frames
edges so a slightly higher clock than above is needed. A 12.5% of increment is
implemented.
If resizer clock is too high, then what will happen is that resizer will try
to
read pixels at every clock cycle. If there is someone else running in the
system (VPSS capture or ARM or codec) then if the resizer will fail to read
the
pixel at any given moment due to other master using the DDR at that time, IT
WILL ABORT the operation causing an incomplete frame in memory.
Thanks for the patch. The patch is on a code base which is not being
maintained now.
And as of now there isn’t support for dm365 in mainline as to rebase this patch.
Regards,
--Prabhakar
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
Signed-off-by: Angelo Aresi angelo.ar...@bticino.it
---
drivers/char/dm365_ipipe.c | 48
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/char/dm365_ipipe.c b/drivers/char/dm365_ipipe.c
index a945122..6161875 100644
--- a/drivers/char/dm365_ipipe.c
+++ b/drivers/char/dm365_ipipe.c
@@ -33,6 +33,8 @@
#include linux/videodev2.h
#include media/davinci/dm365_ipipe.h
#include media/davinci/imp_hw_if.h
+#include media/davinci/vpfe_capture.h
+#include linux/clk.h
#include mach/irqs.h
@@ -599,6 +601,43 @@ static void calculate_resize_ratios(struct ipipe_params
*param, int index)
(param-rsz_rsc_param[index].o_vsz + 1);
}
+/* calculate_sdram_dma_divide_ratio()
+ * calculate the divide ratio of the SDRAM(DMA). This is called after
setting
+ * the input/output size since the speed depends on video size and framrate
+ */
+static void calculate_sdram_dma_divide_ratio(struct ipipe_params *param,
+struct v4l2_fract fps)
+{
+ struct clk *vpss_clk;
+ unsigned long vpss_rate, pixels = 0;
+
+ vpss_clk = clk_get(NULL, vpss_master);
+ vpss_rate = clk_get_rate(vpss_clk);
+ clk_put(vpss_clk);
+
+ pixels = (param-ipipe_hsz + 1) * (param-ipipe_vsz + 1);
+ if (param-rsz_en[RSZ_A]) {
+ if (pixels (param-rsz_rsc_param[RSZ_A].o_hsz + 1) *
+(param-rsz_rsc_param[RSZ_A].o_vsz + 1))
+ pixels = (param-rsz_rsc_param[RSZ_A].o_hsz + 1) *
+(param-rsz_rsc_param[RSZ_A].o_vsz + 1);
+ }
+ if (param-rsz_en[RSZ_B]) {
+ if (pixels (param-rsz_rsc_param[RSZ_B].o_hsz + 1) *
+(param-rsz_rsc_param[RSZ_B].o_vsz + 1))
+ pixels = (param-rsz_rsc_param[RSZ_B].o_hsz + 1) *
+(param-rsz_rsc_param[RSZ_B].o_vsz + 1);
+ }
+ param-ipipeif_param.var.if_5_1.clk_div.m = 1; /*numerator*/
+ /* apply a 12.5% of margin for front/back porch */
+ pixels += pixels 3;
+
+ param-ipipeif_param.var.if_5_1.clk_div.n = vpss_rate /
+ (pixels * fps.denominator / fps.numerator);
+ param-ipipeif_param.clock_select = SDRAM_CLK;
+
+}
+
static int ipipe_do_hw_setup(struct device *dev, void *config)
{
struct ipipe_params *param = (struct ipipe_params *)config;
@@ -615,6 +654,9 @@ static int ipipe_do_hw_setup(struct device *dev, void
*config)
calculate_resize_ratios(param, RSZ_A);
if (param-rsz_en[RSZ_B])
calculate_resize_ratios(param, RSZ_B);
+ calculate_sdram_dma_divide_ratio(param,
+ ((struct vpfe_device *)
+ dev_get_drvdata(dev))-std_info.fps);
ret = ipipe_hw_setup(param);
}
mutex_unlock(oper_state.lock);
@@ -3132,6 +3174,9 @@ static int configure_resizer_in_ss_mode(struct device
*dev,
(param-rsz_rsc_param[RSZ_B].o_vsz + 1);
}
}
+ calculate_sdram_dma_divide_ratio(param,
+
Re: [PATCH] davinci: check for presence of channel controller on slot alloc
+ Matt, who is doing the DMA engine conversion for EDMA
On 9/12/2012 11:44 PM, Cyril Chemparathy wrote:
This patch adds a check for the presence of the channel controller when
trying to allocate a slot. Without this fix, the kernel panics with a NULL
pointer dereference when the dma-engine drivers are probed.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index a685e97..2fee31e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -743,6 +743,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -ENODEV;
I am ok with this patch, although I wonder if a better error is -ENXIO
or even -EINVAL (since its most likely the result of a wrong argument).
This patch will conflict with the EDMA movement series that Matt is
doing and he should probably include it in his series to avoid
conflicts. From the description it appears to be not required for v3.7
anyway.
Thanks,
Sekhar
___
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] davinci: check for presence of channel controller on slot alloc
On Fri, Oct 26, 2012 at 05:09:17PM +0530, Sekhar Nori wrote:
+ Matt, who is doing the DMA engine conversion for EDMA
On 9/12/2012 11:44 PM, Cyril Chemparathy wrote:
This patch adds a check for the presence of the channel controller when
trying to allocate a slot. Without this fix, the kernel panics with a NULL
pointer dereference when the dma-engine drivers are probed.
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index a685e97..2fee31e 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -743,6 +743,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -ENODEV;
I am ok with this patch, although I wonder if a better error is -ENXIO
or even -EINVAL (since its most likely the result of a wrong argument).
This patch will conflict with the EDMA movement series that Matt is
doing and he should probably include it in his series to avoid
conflicts. From the description it appears to be not required for v3.7
anyway.
I'll add this to the am33xx dmaengine series with -EINVAL, thanks.
-Matt
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC PATCH v3 05/16] ARM: edma: add AM33XX crossbar event support
On Thu, Oct 18, 2012 at 18:56:44, Porter, Matt wrote:
Adds support for the per-EDMA channel event mux. This is required
for any peripherals using DMA crossbar mapped events.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 63
+++-
include/linux/platform_data/edma.h |1 +
2 files changed, 63 insertions(+), 1 deletion(-)
..snip..
..snip..
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] 2;
+ offset = 2;
+ mux = __raw_readl((void *)((u32)xbar + offset));
+ mux = (~(0xff shift));
+ mux |= (xbar_chans[i][0] shift);
+ __raw_writel(mux, (void *)((u32)xbar + offset));
This method of calculating Xbar Channel offset has a bug that
the code breaks with unaligned access trap error when requested
channel to be mapped is odd.
This was fixed in Arago tree [1]. Kindly verify
+ }
+
+ pdata-xbar_chans = xbar_chans;
+
+ return 0;
+}
+
..snip..
..snip..
[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=c08d3cb557adf71c79aeefb3395455824e83
Regards,
Gururaja
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND-PATCH] media:davinci: clk - {prepare/unprepare} for common clk
On 10/25/2012 09:12 AM, Prabhakar Lad wrote:
Hi Murali,
Thanks for the patch. I'll queue this patch for 3.8.
Please check with Sekhar as well. This is a preparation patch for common
clk framework support. ALso fixes some bugs on the existing code. As the
clk
patches are dependent on these patches, I would suggest you queue this
against 3.7 rcx.
Murali
On Mon, Oct 22, 2012 at 9:06 PM, Murali Karicheri m-kariche...@ti.com wrote:
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare().
Also fixes some issues related to clk clean up in the driver
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Acked-by: Lad, Prabhakar prabhakar@ti.com
Tested-by: Lad, Prabhakar prabhakar@ti.com
Regards,
--Prabhakar
---
rebased to v3.7-rc1
drivers/media/platform/davinci/dm355_ccdc.c |8 ++--
drivers/media/platform/davinci/dm644x_ccdc.c | 16 ++--
drivers/media/platform/davinci/isif.c|5 -
drivers/media/platform/davinci/vpbe.c| 10 +++---
drivers/media/platform/davinci/vpif.c|8
5 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index ce0e413..030950d 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -1003,7 +1003,7 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.mclk);
goto fail_nomap;
}
- if (clk_enable(ccdc_cfg.mclk)) {
+ if (clk_prepare_enable(ccdc_cfg.mclk)) {
status = -ENODEV;
goto fail_mclk;
}
@@ -1014,7 +1014,7 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.sclk);
goto fail_mclk;
}
- if (clk_enable(ccdc_cfg.sclk)) {
+ if (clk_prepare_enable(ccdc_cfg.sclk)) {
status = -ENODEV;
goto fail_sclk;
}
@@ -1034,8 +1034,10 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
printk(KERN_NOTICE %s is registered with vpfe.\n, ccdc_hw_dev.name);
return 0;
fail_sclk:
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.sclk);
fail_mclk:
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
fail_nomap:
iounmap(ccdc_cfg.base_addr);
@@ -1050,6 +1052,8 @@ static int dm355_ccdc_remove(struct platform_device *pdev)
{
struct resource *res;
+ clk_disable_unprepare(ccdc_cfg.sclk);
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
clk_put(ccdc_cfg.sclk);
iounmap(ccdc_cfg.base_addr);
diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c
b/drivers/media/platform/davinci/dm644x_ccdc.c
index ee7942b..0215ab6 100644
--- a/drivers/media/platform/davinci/dm644x_ccdc.c
+++ b/drivers/media/platform/davinci/dm644x_ccdc.c
@@ -994,7 +994,7 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.mclk);
goto fail_nomap;
}
- if (clk_enable(ccdc_cfg.mclk)) {
+ if (clk_prepare_enable(ccdc_cfg.mclk)) {
status = -ENODEV;
goto fail_mclk;
}
@@ -1005,7 +1005,7 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.sclk);
goto fail_mclk;
}
- if (clk_enable(ccdc_cfg.sclk)) {
+ if (clk_prepare_enable(ccdc_cfg.sclk)) {
status = -ENODEV;
goto fail_sclk;
}
@@ -1013,8 +1013,10 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
printk(KERN_NOTICE %s is registered with vpfe.\n, ccdc_hw_dev.name);
return 0;
fail_sclk:
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.sclk);
fail_mclk:
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
fail_nomap:
iounmap(ccdc_cfg.base_addr);
@@ -1029,6 +1031,8 @@ static int dm644x_ccdc_remove(struct platform_device
*pdev)
{
struct resource *res;
+ clk_disable_unprepare(ccdc_cfg.mclk);
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.mclk);
clk_put(ccdc_cfg.sclk);
iounmap(ccdc_cfg.base_addr);
@@ -1046,8 +1050,8 @@ static int dm644x_ccdc_suspend(struct device *dev)
/* Disable CCDC */
ccdc_enable(0);
/* Disable both master and slave clock */
- clk_disable(ccdc_cfg.mclk);
- clk_disable(ccdc_cfg.sclk);
+ clk_disable_unprepare(ccdc_cfg.mclk);
+ clk_disable_unprepare(ccdc_cfg.sclk);
RE: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn()
Thanks for your comments, Sergei. Please see below... -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Friday, October 26, 2012 2:46 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; Nori, Sekhar Subject: Re: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn() Hello. It's not a good idea to send multiple patches with the same subject. Actually, in this case it's worth merging all 4 patches into one. My first patch submission had them all as one patch, but Sekhar asked that they be split into 4 separate patches to make the merge easier. I can make each one have a different subject, though. On 26-10-2012 0:35, Robert Tivy wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '%s:, __func__' instead Signed-off-by: Robert Tivy rt...@ti.com --- Clean up files that will be otherwise modified in subsequent patch. Applies to v3.5 tag (commit 28a33cbc24e4256c143dce96c7d93bf423229f92) of Linus' mainline kernel at git.kernel.org. 3.5 is too old. Why not to 3.6 or even 3.7-rc2? I will attempt to recreate this patch series on 3.7-rc2, although I will need to change it to use the newer rproc APIs and data structures. diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach- davinci/board-da850-evm.c index 0149fb4..bbb3c73 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] @@ -1046,21 +1046,19 @@ static int __init da850_evm_config_emac(void) } if (ret) - pr_warning(da850_evm_init: cpgmac/rmii mux setup failed: %d\n, - ret); + pr_warn(%s: cpgmac/rmii mux setup failed: %d\n, + __func__, ret); /* configure the CFGCHIP3 register for RMII or MII */ __raw_writel(val, cfg_chip3_base); ret = davinci_cfg_reg(DA850_GPIO2_6); if (ret) - pr_warning(da850_evm_init:GPIO(2,6) mux setup - failed\n); + pr_warn(%s:GPIO(2,6) mux setup failed\n, __func__); Worth inserting space after colon here. Will do. WBR, Sergei Thanks Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
