From patchwork Thu May 5 10:10:19 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martin X-Patchwork-Id: 7159 Return-path: Envelope-to: mchehab@pedra Delivery-date: Thu, 05 May 2011 07:21:39 -0300 Received: from mchehab by pedra with local (Exim 4.72) (envelope-from ) id 1QHvgh-0005XO-Gf for mchehab@pedra; Thu, 05 May 2011 07:21:39 -0300 Received: from casper.infradead.org [85.118.1.10] by pedra with IMAP (fetchmail-6.3.17) for (single-drop); Thu, 05 May 2011 07:21:39 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1QHvVu-0004SP-86; Thu, 05 May 2011 10:10:30 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753529Ab1EEKKV (ORCPT + 1 other); Thu, 5 May 2011 06:10:21 -0400 Received: from mail-iw0-f174.google.com ([209.85.214.174]:35739 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753528Ab1EEKKU (ORCPT ); Thu, 5 May 2011 06:10:20 -0400 Received: by iwn34 with SMTP id 34so1694512iwn.19 for ; Thu, 05 May 2011 03:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.210.70 with SMTP id gj6mr693543icb.236.1304590219941; Thu, 05 May 2011 03:10:19 -0700 (PDT) Received: by 10.42.225.7 with HTTP; Thu, 5 May 2011 03:10:19 -0700 (PDT) Date: Thu, 5 May 2011 12:10:19 +0200 Message-ID: Subject: omap3isp clock problems on Beagleboard xM. From: javier Martin To: linux-media@vger.kernel.org Cc: Guennadi Liakhovetski , Laurent Pinchart Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Sender: Hi, as you know I'm currently working on submitting mt9p031 driver to mainline, testing it with my Beagleboard xM. While I was trying to clean Guennadi's patches I ran into the attached patch which changes a call to "omap3isp_get(isp);" into "isp_enable_clocks(isp);". I don't think this is clean since it would unbalance the number of omap3isp_get() vs omap3isp_put() and we probably don't want that. What seems clear is if we don't apply this patch the clock is not actually enabled. According to my debugging results "isp_disable_clocks()" is never called, so, after the first call to "isp_enable_clocks()" there shouldn't be any need to enable the clocks again. Guennadi, do you know what is the cause of the problem? diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c index 472a693..6a6ea86 100644 --- a/drivers/media/video/omap3isp/isp.c +++ b/drivers/media/video/omap3isp/isp.c @@ -177,6 +177,8 @@ static void isp_disable_interrupts(struct isp_device *isp) isp_reg_writel(isp, 0, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0ENABLE); } +static int isp_enable_clocks(struct isp_device *isp); + /** * isp_set_xclk - Configures the specified cam_xclk to the desired frequency. * @isp: OMAP3 ISP device @@ -239,7 +241,7 @@ static u32 isp_set_xclk(struct isp_device *isp, u32 xclk, u8 xclksel) /* Do we go from stable whatever to clock? */ if (divisor >= 2 && isp->xclk_divisor[xclksel - 1] < 2) - omap3isp_get(isp); + isp_enable_clocks(isp); /* Stopping the clock. */ else if (divisor < 2 && isp->xclk_divisor[xclksel - 1] >= 2) omap3isp_put(isp);