Re: OMAP clock fast-forward: an introduction to six series
On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote: Hello Russell, On Wed, 28 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote: Per rmk's preferences, some patches have been 'compressed.' That is, some fix patches have been rolled into a single patch with the original. To ease cross-referencing with the linux-omap git tree, original commit IDs have been inserted into the patch messages. Also, what would have been an extremely long series has been split into six smaller, cumulative, roughly thematic patch series. If requested, I would be pleased to simply send one large series of the original, uncompressed patches. Thanks to the git and stgit authors and contributors: without those tools, this process would have been nearly impossible. Since this patch series was only really meant for me to do some follow-on work on it (to merge it into my tree) is it really necessary to submit this 70 patch series via slow email via several mailing lists? I posted the patches for final review and upstream merging. Not sure what the follow-on work is that you mention. But if it's additional development work, such as modifying the linux-omap clock code to use your recent clkdev code, that should really be discussed separately, and patches posted for comment to linux-omap, so the OMAP community has a chance to test it first. People on that list seem to be pretty reasonable... If that's what you thought I was offering, forget it. I wasn't. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP clock fast-forward: an introduction to six series
On Thu, Jan 29, 2009 at 08:11:17AM +, Russell King - ARM Linux wrote: On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote: Hello Russell, On Wed, 28 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote: Per rmk's preferences, some patches have been 'compressed.' That is, some fix patches have been rolled into a single patch with the original. To ease cross-referencing with the linux-omap git tree, original commit IDs have been inserted into the patch messages. Also, what would have been an extremely long series has been split into six smaller, cumulative, roughly thematic patch series. If requested, I would be pleased to simply send one large series of the original, uncompressed patches. Thanks to the git and stgit authors and contributors: without those tools, this process would have been nearly impossible. Since this patch series was only really meant for me to do some follow-on work on it (to merge it into my tree) is it really necessary to submit this 70 patch series via slow email via several mailing lists? I posted the patches for final review and upstream merging. Not sure what the follow-on work is that you mention. But if it's additional development work, such as modifying the linux-omap clock code to use your recent clkdev code, that should really be discussed separately, and patches posted for comment to linux-omap, so the OMAP community has a chance to test it first. People on that list seem to be pretty reasonable... If that's what you thought I was offering, forget it. I wasn't. I'll expand on that. When clockdomain and powerdomain support was added to the mainline kernel about six months ago, I specifically asked the question Is this everything for this new code and got told yes. I wanted to ensure that the new code I was merging was 100% up to date with mainline so we wouldn't have a constant drip of old patches to it. A few weeks later I pulled the omapzoom tree, which contains tony's tree and diffed the new code, finding some unmerged patches which I added _before_ that stuff went to Linus. Since then, I've asked Tony whether the clock code was 100% up to date and if not send me the patches. No patches ever came forward. So, with my work on OMAP first to sort out some of the utter crappyness in there (which Tony had accepted.) Tony whinged about it clashing with your work, but still no clock patches from you or Tony were forthcoming. Subsequent to that acceptance, and as a result of me getting utterly pissed off with waiting for something to happen, I converted OMAP over to use clkdev (so that OMAP can stop abusing the API and being used as a reason why new implementations should continue this abuse.) Again, Tony whinged about the big merge problem that this was creating. So I made an offer to manipulate _your_ changes to apply with my changes. That's the offer. The offer is not to merge your code and then think about what to do with mine possibly in a year or two's time. OMAP _is_ going to use the API correctly as soon as possible, no iffs or buts. Not taking the offer means that you and Tony have to deal with the merging issues. Accepting the offer means I do that work for you and publish the results back to you for your comment. Your call. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH B 06/10] OMAP3 pwrdm: add CORE SAR handling (for USBTLL module)
Hi Richard, On Thu, 29 Jan 2009, Paul Walmsley wrote: TLLSAR is not functional till ES3.1 (and beyound). Is it possible to flag it this way? Yes, it's easy in this case. Thanks for the note. I will send along an updated patch for this. N.B. - fixxing this required a separate change to the omap_chip flag system, so I'll send the two necessary patches to the linux-omap mailing list for further testing. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: update omap_chip flags; mark USBTLL SAR for ES3.1 only
Hello, this series marks USBTLL SAR as being available on ES3.1 and beyond only, per http://marc.info/?l=linux-arm-kernelm=123319614808833w=2 To do this, the omap_chip flags had to be updated. Now, ES2+ features are marked as CHIP_GE_OMAP3430ES2. ES3.1+ features are similarly marked as CHIP_GE_OMAP3430ES3_1. Tested on ES2.1 Beagle. Further testing on ES3+ boards is very welcome. --- Paul Walmsley (2): OMAP3 powerdomains: make USBTLL SAR only available on ES3.1 and beyond OMAP3: update ES level flags to discriminate between post-ES2 revisions arch/arm/mach-omap2/clockdomains.h |6 +++--- arch/arm/mach-omap2/id.c |7 ++- arch/arm/mach-omap2/powerdomains.h |4 ++-- arch/arm/mach-omap2/powerdomains34xx.h | 16 +--- arch/arm/plat-omap/include/mach/cpu.h | 26 -- 5 files changed, 40 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP3: update ES level flags to discriminate between post-ES2 revisions
Some OMAP3 chip behaviors change in ES levels after ES2. Modify the
existing omap_chip flags to add options for ES3.0 and ES3.1.
Add a new macro, CHIP_GE_OMAP3430ES2, to cover ES levels from ES2
onwards - a common pattern for OMAP3 features. Update all current
users of the omap_chip macros to use this new macro.
Also add CHIP_GE_OMAP3430ES3_1 to cover the USBTLL SAR errata case
(described and fixed in the following patch)
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomains.h |6 +++---
arch/arm/mach-omap2/id.c |7 ++-
arch/arm/mach-omap2/powerdomains34xx.h |8
arch/arm/plat-omap/include/mach/cpu.h | 26 --
4 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 3d4eaca..a21df93 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -185,7 +185,7 @@ static struct clockdomain sgx_clkdm = {
.pwrdm = { .name = sgx_pwrdm },
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
};
/*
@@ -240,7 +240,7 @@ static struct clockdomain usbhost_clkdm = {
.pwrdm = { .name = usbhost_pwrdm },
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_USBHOST_MASK,
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
};
static struct clockdomain per_clkdm = {
@@ -290,7 +290,7 @@ static struct clockdomain dpll4_clkdm = {
static struct clockdomain dpll5_clkdm = {
.name = dpll5_clkdm,
.pwrdm = { .name = dpll5_pwrdm },
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
};
#endif /* CONFIG_ARCH_OMAP34XX */
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 7cd1b2e..32ceaa6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -239,8 +239,13 @@ void __init omap2_check_revision(void)
omap_chip.oc = CHIP_IS_OMAP3430;
if (omap_rev() == OMAP3430_REV_ES1_0)
omap_chip.oc |= CHIP_IS_OMAP3430ES1;
- else if (omap_rev() OMAP3430_REV_ES1_0)
+ else if (omap_rev() = OMAP3430_REV_ES2_0
+omap_rev() = OMAP3430_REV_ES2_1)
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
+ else if (omap_rev() == OMAP3430_REV_ES3_0)
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
+ else if (omap_rev() == OMAP3430_REV_ES3_1)
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
} else {
pr_err(Uninitialized omap_chip, please fix!\n);
}
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index edfad42..6b9d126 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -221,7 +221,7 @@ static struct powerdomain core_34xx_es1_pwrdm = {
static struct powerdomain core_34xx_es2_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
.pwrsts = PWRSTS_OFF_RET_ON,
.dep_bit = OMAP3430_EN_CORE_SHIFT,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
@@ -263,7 +263,7 @@ static struct powerdomain dss_pwrdm = {
static struct powerdomain sgx_pwrdm = {
.name = sgx_pwrdm,
.prcm_offs= OMAP3430ES2_SGX_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
.wkdep_srcs = gfx_sgx_wkdeps,
.sleepdep_srcs= cam_gfx_sleepdeps,
/* XXX This is accurate for 3430 SGX, but what about GFX? */
@@ -331,7 +331,7 @@ static struct powerdomain neon_pwrdm = {
static struct powerdomain usbhost_pwrdm = {
.name = usbhost_pwrdm,
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
.wkdep_srcs = per_usbhost_wkdeps,
.sleepdep_srcs= dss_per_usbhost_sleepdeps,
.pwrsts = PWRSTS_OFF_RET_ON,
@@ -373,7 +373,7 @@ static struct powerdomain dpll4_pwrdm = {
static struct powerdomain dpll5_pwrdm = {
.name = dpll5_pwrdm,
.prcm_offs = PLL_MOD,
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+ .omap_chip =
RE: [PATCH] usb: musb: adding nop usb transceiver
We'll need something like this, yes.
This one looks to need a bit of tweaking yet though ...
probably that could be done after merge.
The state can need changing after one of the drivers is unregistered;
I didn't get this comment.
using __exit not __devexit is likely wrong (especially
given your MUSB patchlet);
Changed to __devexit/__devinit.
xceiv_to_nop() should be an inline function;
check otg_set_transceiver() value;
don't bother with dev_info();
Done.
and I'm not quite sure of the methods.
Plus I think it's probably best to include a utility
that board init code can call to register the NOP
transceiver device ... instead of cloning that bit of
code (in your second patch) into every board-*.c file
that needs it.
done. Added this nop_xceiv_register() which can be called from
board-init files to register NOP.
Please review the modified patch version below.
Thanks,
Ajay
=== cut here
Subject: [PATCH v2] usb: musb: adding nop usb transceiver
NOP transceiver is used by all the usb transceiver which are mostly
autonomous and doesn't require any programming or which are built
into the usb ip itself.NOP transceiver only allocates the memory
for struct xceiv and calls otg_set_transceiver() so function call
to otg_get_transceiver() will return a valid transceiver.
NOP transceiver device should be registered by calling
nop_xceiv_register() from platform files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
This version takes cares of David's comments and adds
platform_device_register() utility implemented in nop_xceiv_register()
method within same new file.
drivers/usb/otg/Kconfig |8 ++
drivers/usb/otg/Makefile|1 +
drivers/usb/otg/nop-usb-xceiv.c | 180 +++
3 files changed, 189 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/nop-usb-xceiv.c
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 8e8dbdb..8376b36 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -51,4 +51,12 @@ config TWL4030_USB
This transceiver supports high and full speed devices plus,
in host mode, low speed.
+config NOP_USB_XCEIV
+ tristate NOP USB Transceiver Driver
+ select USB_OTG_UTILS
+ help
+this driver is to be used by all the usb transceiver which are either
+built-in with usb ip or which are autonomous and doesn't require any
+phy programming such as ISP1x04 etc.
+
endif # USB || OTG
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index d73c7cf..2081678 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_USB_OTG_UTILS) += otg.o
obj-$(CONFIG_USB_GPIO_VBUS)+= gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
+obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
ccflags-$(CONFIG_USB_DEBUG)+= -DDEBUG
ccflags-$(CONFIG_USB_GADGET_DEBUG) += -DDEBUG
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
new file mode 100644
index 000..836f4e6
--- /dev/null
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -0,0 +1,180 @@
+/*
+ * drivers/usb/otg/nop-usb-xceiv.c
+ *
+ * NOP USB transceiver for all USB transceiver which are either built-in
+ * into USB IP or which are mostly autonomous.
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Ajay Kumar Gupta ajay.gu...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Current status:
+ * this is to add nop transceiver for all those phy which is
+ * autonomous such as isp1504 etc.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/usb/otg.h
+
+struct nop_usb_xceiv {
+ struct otg_transceiver otg;
+ struct device *dev;
+};
+
+static u64 nop_xceiv_dmamask = DMA_32BIT_MASK;
+
+static struct platform_device nop_xceiv_device = {
+ .name = nop_usb_xceiv,
+ .id = -1,
+ .dev = {
+ .dma_mask = nop_xceiv_dmamask,
+ .coherent_dma_mask = DMA_32BIT_MASK,
+ .platform_data = NULL,
+ },
+};
+
+void
Re: [PATCH C 05/13] OMAP2/3 clock: fix DPLL rate calculation
On Wed, Jan 28, 2009 at 12:08:23PM -0700, Paul Walmsley wrote:
+ if (cpu_is_omap24xx()) {
+
+ if (v == OMAP2XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP2XXX_EN_DPLL_FRBYPASS)
+ return clk-parent-rate;
+
+ } else if (cpu_is_omap34xx()) {
+
+ if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP3XXX_EN_DPLL_FRBYPASS)
+ return dd-bypass_clk-rate;
+
+ }
You shouldn't introduce two ways of doing the same thing. Make both
OMAP2 and OMAP3 behaviour the same so that you have less to think
about when looking at the code.
Also, when accepting patches, try to make sure that they conform to
the coding style, rather than repeatedly committing noisy coding style
cleanup patches.
So, the above should be:
+ if (cpu_is_omap24xx()) {
+ if (v == OMAP2XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP2XXX_EN_DPLL_FRBYPASS)
+ return dd-bypass_clk-rate;
+ } else if (cpu_is_omap34xx()) {
+ if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP3XXX_EN_DPLL_FRBYPASS)
+ return dd-bypass_clk-rate;
+ }
And this patch should be combined with the previous one which creates
the whole 'bypass_clk' thing. There's not much point to a patch which
just adds an unused field and initializers to a structure.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 06/13] OMAP3 clock: DPLLs should enter bypass if new rate is sys_ck
On Wed, Jan 28, 2009 at 12:08:26PM -0700, Paul Walmsley wrote:
static int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
{
u16 freqsel;
struct dpll_data *dd;
+ int ret;
So 'ret' is a new variable...
if (!clk || !rate)
return -EINVAL;
@@ -389,18 +393,32 @@ static int omap3_noncore_dpll_set_rate(struct clk *clk,
unsigned long rate)
if (rate == omap2_get_dpll_rate(clk))
return 0;
- if (dd-last_rounded_rate != rate)
- omap2_dpll_round_rate(clk, rate);
+ if (dd-bypass_clk-rate == rate
+ (clk-dpll_data-modes (1 DPLL_LOW_POWER_BYPASS))) {
- if (dd-last_rounded_rate == 0)
- return -EINVAL;
+ pr_debug(clock: %s: set rate: entering bypass.\n, clk-name);
+
+ ret = _omap3_noncore_dpll_bypass(clk);
which is assigned to...
+
Additional noise.
+ } else {
+
More noise.
+ if (dd-last_rounded_rate != rate)
+ omap2_dpll_round_rate(clk, rate);
- freqsel = _omap3_dpll_compute_freqsel(clk, dd-last_rounded_n);
- if (!freqsel)
- WARN_ON(1);
+ if (dd-last_rounded_rate == 0)
+ return -EINVAL;
- omap3_noncore_dpll_program(clk, dd-last_rounded_m, dd-last_rounded_n,
-freqsel);
+ freqsel = _omap3_dpll_compute_freqsel(clk, dd-last_rounded_n);
+ if (!freqsel)
+ WARN_ON(1);
+
+ pr_debug(clock: %s: set rate: locking rate to %lu.\n,
+ clk-name, rate);
+
+ ret = omap3_noncore_dpll_program(clk, dd-last_rounded_m,
+ dd-last_rounded_n, freqsel);
Assigned to again...
+
More noise.
+ }
omap3_dpll_recalc(clk);
But ret is never actually used.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 07/13] OMAP3 clock: recalculate DPLL subtree after bypass entry/exit
On Wed, Jan 28, 2009 at 12:08:29PM -0700, Paul Walmsley wrote: The DPLL's rate changes when it enters or leaves bypass, so the DPLL's rate and the rates of all dependent clocks need to be recalculated when this happens. Also, fix test for bypass to test against the appropriate bypass clock, rather than the parent clock (which is not the bypass clock for DPLL1 and DPLL2). Surely this is a bug fix to the previous patch? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 08/13] OMAP3 clock: put DPLL into bypass if bypass rate = clk-rate, not hardware rate
On Wed, Jan 28, 2009 at 12:08:32PM -0700, Paul Walmsley wrote: When a non-CORE DPLL is enabled via omap3_noncore_dpll_enable(), use the user's desired rate in clk-rate to determine whether to put the DPLL into bypass or lock mode, rather than reading the DPLL's current idle state from its hardware registers. This fixes a bug observed when leaving retention. Non-CORE DPLLs were not being relocked when downstream clocks re-enabled; rather, the DPLL entered bypass mode. Problem reported by Tero Kristo tero.kri...@nokia.com. linux-omap source commit is 8b1f0bd44fe490ec631230c8c040753a2bda8caa. Signed-off-by: Paul Walmsley p...@pwsan.com Signed-off-by: Tony Lindgren t...@atomide.com Cc: Tero Kristo tero.kri...@nokia.com Patch 6 did it this way. Patch 7 changed it to use omap2_get_dpll_rate() and this patch changes it back. What's the point of submitting all this detail? It's just pure noise. Collapse these three patches into one please. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 09/13] OMAP3 clock: fix non-CORE DPLL rate assignment bugs
On Wed, Jan 28, 2009 at 12:08:35PM -0700, Paul Walmsley wrote:
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 424eed6..c943043 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -270,7 +270,6 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
static int omap3_noncore_dpll_enable(struct clk *clk)
{
int r;
- long rate;
struct dpll_data *dd;
if (clk == dpll3_ck)
@@ -286,7 +285,7 @@ static int omap3_noncore_dpll_enable(struct clk *clk)
r = _omap3_noncore_dpll_lock(clk);
if (!r)
- clk-rate = rate;
+ clk-rate = omap2_get_dpll_rate(clk);
This whole patch can be viewed as another bug fix to patch 6.
@@ -429,6 +428,9 @@ static int omap3_noncore_dpll_set_rate(struct clk *clk,
unsigned long rate)
ret = omap3_noncore_dpll_program(clk, dd-last_rounded_m,
dd-last_rounded_n, freqsel);
+ if (!ret)
+ clk-rate = rate;
+
So this is creating:
if (...) {
ret = something;
if (!ret)
clk-rate = rate;
} else {
ret = something else;
if (!ret)
clk-rate = rate;
}
So why not make it easier to read and more obvious:
if (...) {
ret = something;
} else {
ret = something else;
}
if (!ret)
clk-rate = rate;
}
omap3_dpll_recalc(clk);
---
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 01/11] OMAP: Add clk_get_parent() for OMAP2/3
On Wed, Jan 28, 2009 at 12:18:16PM -0700, Paul Walmsley wrote: From: Mans Rullgard m...@mansr.com This makes clk_get_parent() work on OMAP2/3. This is clearly something that the generic code should be doing. It's not something specific to OMAP2/3. Please move it to arch/arm/plat-omap/clock.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 06/13] OMAP3 clock: DPLLs should enter bypass if new rate is sys_ck
On Wed, Jan 28, 2009 at 12:08:26PM -0700, Paul Walmsley wrote: This patch causes a DPLL to enter bypass when it is instructed to set its rate to that of its bypass clock. Previously this was only possible after setting the DPLL rate, then disabling and re-enabling it. The more I think about this, especially with reference to patch D1, the more I'm convinced this is not entirely the right approach. Patch D1 introduces the necessary mechanics to make clk_get_parent() work. If you use this on a PLL clock, and the PLL is in bypass mode, it returns the non-bypass clock. Now, I suspect that your first thought to resolving that would be to add some complexity to clk_get_parent(). I advise against that. Instead, arrange for clk-parent to _always_ point at the correct parent clock, whether the PLL is in bypass mode or not. In other words, encapsulate all the PLL mechanics localized inside the PLL handling code and don't let them leak outside that code. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH A 01/10] OMAP2/3: Add non-CORE DPLL rate set code and M, N programming
On Tue, Jan 27, 2009 at 07:12:47PM -0700, Paul Walmsley wrote:
+/* Non-CORE DPLL rate set code */
+
+/*
+ * omap3_noncore_dpll_program - set non-core DPLL M,N values directly
+ * @clk: struct clk * of DPLL to set
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ * @freqsel: FREQSEL value to set
+ *
+ * Program the DPLL with the supplied M, N values, and wait for the DPLL to
+ * lock.. Returns -EINVAL upon error, or 0 upon success.
+ */
+static int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16
freqsel)
+{
+ struct dpll_data *dd;
+ u32 v;
+
+ if (!clk)
+ return -EINVAL;
+
+ dd = clk-dpll_data;
+ if (!dd)
+ return -EINVAL;
Final point... this is only called from the function below, which also
checks that clk and clk-dpll_data are both non-NULL. So these checks
are unnecessary.
+static int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
+{
+ u16 freqsel;
+ struct dpll_data *dd;
+
+ if (!clk || !rate)
+ return -EINVAL;
+
+ dd = clk-dpll_data;
+ if (!dd)
+ return -EINVAL;
+
+ if (rate == omap2_get_dpll_rate(clk))
+ return 0;
+
+ if (dd-last_rounded_rate != rate)
+ omap2_dpll_round_rate(clk, rate);
+
+ if (dd-last_rounded_rate == 0)
+ return -EINVAL;
+
+ freqsel = _omap3_dpll_compute_freqsel(clk, dd-last_rounded_n);
+ if (!freqsel)
+ WARN_ON(1);
+
+ omap3_noncore_dpll_program(clk, dd-last_rounded_m, dd-last_rounded_n,
+freqsel);
+
+ omap3_dpll_recalc(clk);
+
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 11/11] Fix omap1 clock issues
On Wed, Jan 28, 2009 at 12:18:48PM -0700, Paul Walmsley wrote: From: Tony Lindgren t...@atomide.com This fixes booting, and is a step toward fixing things properly: - Make enable_reg u32 instead of u16 No, you're passing this to __raw_read/write, so it needs to be void __iomem *, not u32. If there's another patch doing that it needs to be combined with this one. The miniscule details of fixes upon fixes aren't interesting for submission purposes, and just adds extra unnecessary review load for upstream people. Ditto for anything else which is passed to __raw_read/write*. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 11/14] OMAP clock: track child clocks
On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
The price paid is additional runtime memory consumption - 8 bytes per
clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.
For OMAP3, that's 222 struct clks of which 182 are children, and indeed
222 * 8 + 182 * 16 gives about 4.5K. On OMAP2, it's 140 and 136,
giving 140 * 8 + 136 * 16 = 3.3K.
Moving struct clk_child into struct clk means that its clk and flags
members can be deleted, making it 8 bytes in size - effectively just
the list_head. We need a list_head for the 'children' as you have it.
So, that works out as 16 bytes per clock. That gives 3.5K on OMAP3
and 2.2K on OMAP2.
So, by taking that alternative approach, not only do you end up using
less memory, but you also don't have to have the overhead of your
custom memory bookkeeping.
The other change I'd suggest is that you have one function which deals
with setting the parent of a clock:
void clk_reparent(struct clk *child, struct clk *parent)
{
list_del_init(child-sibling);
if (parent)
list_add(child-sibling, parent-children);
child-parent = parent;
/* now do the debugfs renaming to reattach the child
to the proper parent */
}
which is a lot simpler than your omap_clk_add_child() and omap_clk_del_child().
These should be in the _core_ OMAP clock code, not just in the OMAP2
clock code. OMAP1 has child clocks as well as OMAP2.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Naming convention used in mux.c
Hi, Can anybody tell me the meaning of naming convention used in mux.c file, e.g. - MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) What the suffix AH8_ and J25_ means here? I looked into TRM and could not able to co-relate with any meaningful? Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Naming convention used in mux.c
Sending to the list in plain text, argh! -- Ashwin -- Forwarded message -- From: Ashwin Bihari abih...@gmail.com Date: Thu, Jan 29, 2009 at 10:45 AM Subject: Re: Naming convention used in mux.c To: Hiremath, Vaibhav hvaib...@ti.com Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org Vaibhav, I was also confused by that when I began playing with the OMAP and only found those references to make sense when I looked at the schematics of the board I'm working on. If you look at the Terminal Pin documents for your specific OMAP you will see the alphabet and numbers make sense. But you need to know which alphabet/number specifically is designated to a particular function and this is something the hardware engineer would do while connecting the OMAP to the rest of the peripherals on the board. Regards -- Ashwin On Thu, Jan 29, 2009 at 10:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote: Hi, Can anybody tell me the meaning of naming convention used in mux.c file, e.g. - MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) What the suffix AH8_ and J25_ means here? I looked into TRM and could not able to co-relate with any meaningful? Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP clock fast-forward: an introduction to six series
* Russell King - ARM Linux li...@arm.linux.org.uk [090129 00:31]: On Thu, Jan 29, 2009 at 08:11:17AM +, Russell King - ARM Linux wrote: On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote: Hello Russell, On Wed, 28 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote: Per rmk's preferences, some patches have been 'compressed.' That is, some fix patches have been rolled into a single patch with the original. To ease cross-referencing with the linux-omap git tree, original commit IDs have been inserted into the patch messages. Also, what would have been an extremely long series has been split into six smaller, cumulative, roughly thematic patch series. If requested, I would be pleased to simply send one large series of the original, uncompressed patches. Thanks to the git and stgit authors and contributors: without those tools, this process would have been nearly impossible. Since this patch series was only really meant for me to do some follow-on work on it (to merge it into my tree) is it really necessary to submit this 70 patch series via slow email via several mailing lists? I posted the patches for final review and upstream merging. Not sure what the follow-on work is that you mention. But if it's additional development work, such as modifying the linux-omap clock code to use your recent clkdev code, that should really be discussed separately, and patches posted for comment to linux-omap, so the OMAP community has a chance to test it first. People on that list seem to be pretty reasonable... If that's what you thought I was offering, forget it. I wasn't. I'll expand on that. When clockdomain and powerdomain support was added to the mainline kernel about six months ago, I specifically asked the question Is this everything for this new code and got told yes. I wanted to ensure that the new code I was merging was 100% up to date with mainline so we wouldn't have a constant drip of old patches to it. A few weeks later I pulled the omapzoom tree, which contains tony's tree and diffed the new code, finding some unmerged patches which I added _before_ that stuff went to Linus. Since then, I've asked Tony whether the clock code was 100% up to date and if not send me the patches. No patches ever came forward. So, with my work on OMAP first to sort out some of the utter crappyness in there (which Tony had accepted.) Tony whinged about it clashing with your work, but still no clock patches from you or Tony were forthcoming. Subsequent to that acceptance, and as a result of me getting utterly pissed off with waiting for something to happen, I converted OMAP over to use clkdev (so that OMAP can stop abusing the API and being used as a reason why new implementations should continue this abuse.) Again, Tony whinged about the big merge problem that this was creating. So I made an offer to manipulate _your_ changes to apply with my changes. That's the offer. The offer is not to merge your code and then think about what to do with mine possibly in a year or two's time. OMAP _is_ going to use the API correctly as soon as possible, no iffs or buts. Not taking the offer means that you and Tony have to deal with the merging issues. Accepting the offer means I do that work for you and publish the results back to you for your comment. Your call. To me it does not matter which way the stuff gets merged. We just need to get it all merged. If you guys can't get it merged and sorted out then it will all fall down on me. And then I have to use tools no smaller than a sledgehammer to merge it all, so the outcome won't be pretty! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP clock fast-forward: an introduction to six series
On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote: To me it does not matter which way the stuff gets merged. We just need to get it all merged. If you guys can't get it merged and sorted out then it will all fall down on me. And then I have to use tools no smaller than a sledgehammer to merge it all, so the outcome won't be pretty! Well, I've continued with my approach. 28 patches are currently merged onto a follow-on branch (scattered throughout the series but in order) and the result builds for my OMAP1, OMAP2 and OMAP3 test builds. Patches which I've provided non-trivial comments on by and large haven't been merged. Once I've worked through the set, I'll provide a final list of those outstanding so nothing should be lost. I would appreciate someone _bouncing_ (not forwarding) the patches I'm missing to li...@arm.linux.org.uk please. Those being D6, E2 and F2. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP clock fast-forward: an introduction to six series
* Russell King - ARM Linux li...@arm.linux.org.uk [090129 08:35]: On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote: To me it does not matter which way the stuff gets merged. We just need to get it all merged. If you guys can't get it merged and sorted out then it will all fall down on me. And then I have to use tools no smaller than a sledgehammer to merge it all, so the outcome won't be pretty! Well, I've continued with my approach. 28 patches are currently merged onto a follow-on branch (scattered throughout the series but in order) and the result builds for my OMAP1, OMAP2 and OMAP3 test builds. OK, only 32 more patches to go :) Patches which I've provided non-trivial comments on by and large haven't been merged. Once I've worked through the set, I'll provide a final list of those outstanding so nothing should be lost. I would appreciate someone _bouncing_ (not forwarding) the patches I'm missing to li...@arm.linux.org.uk please. Those being D6, E2 and F2. I'll bounce them to you. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] ARM: Do early I/O mapping if spinlock debugging is enabled
* David Brownell davi...@pacbell.net [090128 15:51]: On Wednesday 28 January 2009, Russell King - ARM Linux wrote: At least on OMAP, sched_clock() requires the I/O maps to be initialized. Spinlock debugging invokes sched_clock() very early. NAK. This doesn't and can't work on every platform out there. The only viable fix is that sched_clock() must NOT be used early. If the kernel is using sched_clock() early, that's a bug. So you're saying that spinlock debugging is buggy??? It used to be that CONFIG_PRINTK_TIME had a similar issue.. Anyways, dropping this patch from omap-fixes, sounds like how to fix it needs to get sorted out on LKML. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Naming convention used in mux.c
Thanks Ashwin, I got it. But I would recommend to have some kind of comment in mux.c which will mention this. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 From: Ashwin Bihari [mailto:abih...@gmail.com] Sent: Thursday, January 29, 2009 9:16 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: Naming convention used in mux.c Vaibhav, I was also confused by that when I began playing with the OMAP and only found those references to make sense when I looked at the schematics of the board I'm working on. If you look at the Terminal Pin documents for your specific OMAP you will see the alphabet and numbers make sense. But you need to know which alphabet/number specifically is designated to a particular function and this is something the hardware engineer would do while connecting the OMAP to the rest of the peripherals on the board. Regards -- Ashwin On Thu, Jan 29, 2009 at 10:34 AM, Hiremath, Vaibhav hvaib...@ti.com wrote: Hi, Can anybody tell me the meaning of naming convention used in mux.c file, e.g. - MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6, OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT) What the suffix AH8_ and J25_ means here? I looked into TRM and could not able to co-relate with any meaningful? Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP clock fast-forward: an introduction to six series
On Thu, Jan 29, 2009 at 08:53:35AM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [090129 08:42]: * Russell King - ARM Linux li...@arm.linux.org.uk [090129 08:35]: On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote: To me it does not matter which way the stuff gets merged. We just need to get it all merged. If you guys can't get it merged and sorted out then it will all fall down on me. And then I have to use tools no smaller than a sledgehammer to merge it all, so the outcome won't be pretty! Well, I've continued with my approach. 28 patches are currently merged onto a follow-on branch (scattered throughout the series but in order) and the result builds for my OMAP1, OMAP2 and OMAP3 test builds. OK, only 32 more patches to go :) I mean 42! You were closer first time around - there's 9 patches I'm not going to merge as they currently stand, which I've provided comments on. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Beagle PM hangs
Hi Kevin, On Wed, Jan 28, 2009 at 9:58 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Peter Reid ppeter.r...@gmail.com writes: Hi Kevin, I get hangs after boot on beagle with latest PM tree i have quite a few scripts that run on boot. have you seen this before? I have not, but I believe Koen has see something similar. I've mainly been testing just a minimal rootfs and a minimal set of drivers on Beagle so I can hit full-chip off in idle. I have a default omap3_beagle_defconfig with cpuidle, cpufreq enabled. It hangs after running the /etc boot scripts. The behaviour is random. Have seen this working randomly before. yet to debug this. Regards, reid. It would help if you could desribe your setup in more detail. What kernel config are you using, what rootfs are you using? Does it hang in the same spot every time? If so, what is going on when it hangs? Have you written anything to any of the /sys/power/* files? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 08/14] OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c
On Wed, Jan 28, 2009 at 12:27:51PM -0700, Paul Walmsley wrote: Previously the individual clock recalculation functions handled their own rate recalculation. This can be handled in the clk_set_rate(), clk_set_parent(), and recalculate_root_clocks() functions in plat-omap/clock.c. Removes duplicate code and clarifies the role of the recalc functions. I must say that this commit looks very much like a combination of my commits from November: [ARM] omap: move clock propagation into core omap clock code [ARM] omap: remove unnecessary calls to propagate_rate() [ARM] omap: move propagate_rate() calls into generic omap clock code which do basically the same thing a little more efficiently, and an additional patch from you to call -recalc after set_rate or reparenting a clock. So I think I can drop everything from this apart from the additional recalc calls, and the removal of those omap2_dpllcore_recalc() calls. Please confirm my suspicions. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] ARM: OMAP: Fix hsmmc init, v2
* Russell King - ARM Linux li...@arm.linux.org.uk [090128 11:08]:
On Wed, Jan 28, 2009 at 10:29:35AM -0800, Tony Lindgren wrote:
It accidentally broke while changing the name for the driver
to not to conflict with the other mmc driver.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/devices.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index ac15c23..d22529c 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -205,9 +205,15 @@ int __init omap_mmc_add(int id, unsigned long base,
unsigned long size,
{
struct platform_device *pdev;
struct resource res[OMAP_MMC_NR_RES];
+ char *name;
int ret;
- pdev = platform_device_alloc(mmci-omap, id);
+ if (cpu_class_is_omap1() || cpu_is_omap242x())
+ name = mmci-omap;
+ else
+ name = mmci-omap-hs;
+
+ pdev = platform_device_alloc(name, id);
if (!pdev)
return -ENOMEM;
This is error prone. I suggest instead:
int __init omap_mmc_add(const char *name, int id, unsigned long base,
unsigned long size, unsigned int irq,
struct omap_mmc_platform_data *data)
and moving that conditional up a level - OMAP1 not having it conditional,
and OMAP2 having the condition there along side the other in
omap2_init_mmc.
And, it's already in error. Look at these two conditionals closely:
from plat-omap/devices.c:
+ if (cpu_class_is_omap1() || cpu_is_omap242x())
+ name = mmci-omap;
+ else
+ name = mmci-omap-hs;
and from mach-omap2/devices.c::omap2_init_mmc():
if (cpu_is_omap2420())
size = OMAP2420_MMC_SIZE;
else
size = HSMMC_SIZE;
These disagree about which CPUs have HSMMC and which don't.
OK, here's the updated version.
Tony
From 0dffb5c57a1d76532e2f2c7398579bfce81c3e5c Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Thu, 29 Jan 2009 08:57:16 -0800
Subject: [PATCH] ARM: OMAP: Fix hsmmc init, v2
The naming accidentally broke while changing the name for the
driver to not to conflict with the other mmc driver.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 77382d8..ba5d7c0 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -181,7 +181,7 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data **mmc_data,
}
size = OMAP1_MMC_SIZE;
- omap_mmc_add(i, base, size, irq, mmc_data[i]);
+ omap_mmc_add(mmci-omap, i, base, size, irq, mmc_data[i]);
};
}
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9d7216f..ce03fa7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -421,6 +421,7 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
int nr_controllers)
{
int i;
+ char *name;
for (i = 0; i nr_controllers; i++) {
unsigned long base, size;
@@ -450,12 +451,14 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
continue;
}
- if (cpu_is_omap2420())
+ if (cpu_is_omap2420()) {
size = OMAP2420_MMC_SIZE;
- else
+ name = mmci-omap;
+ } else {
size = HSMMC_SIZE;
-
- omap_mmc_add(i, base, size, irq, mmc_data[i]);
+ name = mmci-omap-hs;
+ }
+ omap_mmc_add(name, i, base, size, irq, mmc_data[i]);
};
}
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index ac15c23..208dbb1 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -200,14 +200,15 @@ void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config,
/*
* Register MMC devices. Called from mach-omap1 and mach-omap2 device init.
*/
-int __init omap_mmc_add(int id, unsigned long base, unsigned long size,
- unsigned int irq, struct omap_mmc_platform_data *data)
+int __init omap_mmc_add(const char *name, int id, unsigned long base,
+unsigned long size, unsigned int irq,
+struct omap_mmc_platform_data *data)
{
struct platform_device *pdev;
struct resource res[OMAP_MMC_NR_RES];
int ret;
- pdev = platform_device_alloc(mmci-omap, id);
+ pdev = platform_device_alloc(name, id);
if (!pdev)
return -ENOMEM;
diff --git a/arch/arm/plat-omap/include/mach/mmc.h b/arch/arm/plat-omap/include/mach/mmc.h
index 031250f..73a9e15 100644
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -115,8 +115,9 @@ void omap1_init_mmc(struct omap_mmc_platform_data **mmc_data,
int nr_controllers);
void omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
int nr_controllers);
-int omap_mmc_add(int id, unsigned long base, unsigned long size,
- unsigned int irq, struct omap_mmc_platform_data *data);
+int omap_mmc_add(const char
git pull request for omap-fixes (Re: [PATCH 0/9] Omap fixes for 2.6.29-rc series, also one arm generic fix)
* Russell King - ARM Linux li...@arm.linux.org.uk [090128 11:21]: No other comments on 3,4,5,7 and 9. Here's the pull request for you. Tony The following changes since commit 18e352e4a73465349711a9324767e1b2453383e2: Linus Torvalds (1): Linux 2.6.29-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Aaro Koskinen (1): ARM: OMAP: gptimer min_delta_ns corrected Jarkko Nikula (1): ARM: OMAP: DMA: Fix uninitialized channel flags Juha Yrjola (1): ARM: OMAP: Fix race in OMAP2/3 DMA IRQ handling Kevin Hilman (1): ARM: OMAP: fix fault in enter_full_retention() Stanley.Miao (1): ARM: OMAP: Fix McBSP spin_lock deadlock Tony Lindgren (2): ARM: OMAP: Fix omap34xx revision detection for ES3.1 ARM: OMAP: Fix hsmmc init, v2 김규원 (1): ARM: OMAP: Mask interrupts when disabling interrupts, v2 arch/arm/mach-omap1/devices.c |2 +- arch/arm/mach-omap1/mcbsp.c | 98 ++--- arch/arm/mach-omap2/devices.c | 11 ++- arch/arm/mach-omap2/id.c|6 +- arch/arm/mach-omap2/irq.c |1 + arch/arm/mach-omap2/mcbsp.c | 145 ++- arch/arm/mach-omap2/sleep24xx.S |3 +- arch/arm/mach-omap2/timer-gp.c |3 +- arch/arm/plat-omap/devices.c|7 +- arch/arm/plat-omap/dma.c|5 +- arch/arm/plat-omap/include/mach/cpu.h |1 + arch/arm/plat-omap/include/mach/mcbsp.h |6 +- arch/arm/plat-omap/include/mach/mmc.h | 10 ++- arch/arm/plat-omap/mcbsp.c | 52 --- 14 files changed, 109 insertions(+), 241 deletions(-)
Re: [PATCH] OMAP3 McSPI: Adds context save/restore
On Wed, Jan 28, 2009 at 10:11:29AM +0100, ext Nayak, Rajendra wrote:
From: Hemanth V heman...@ti.com
This patch adds context save/restore feature to McSPI driver.
This has been tested by instrumenting the driver code i.e by
adding a McSPI softreset in omap2_mcspi_disable_clocks function.
This patch includes review comment fixes
Signed-off-by: Hemanth V heman...@ti.com
---
drivers/spi/omap2_mcspi.c | 97
--
1 files changed, 77 insertions(+), 20 deletions(-)
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-01-27
11:45:06.0 +0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2009-01-27 11:53:16.0
+0530
[...]
+static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
+{
+ struct spi_master *spi_cntrl;
+ spi_cntrl = mcspi-master;
+
+ /* McSPI: context restore */
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].sysconfig);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_CHCONF0,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].chconf0);
You have to restore this to the proper CHCONF register. And in the
current form you have to restore all of them.
+
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
+}
+static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
+{
+ clk_disable(mcspi-ick);
+ clk_disable(mcspi-fck);
+}
+
[...]
@@ -537,6 +593,8 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].chconf0 = l;
And here save it to a slot based on CS.
--Imre
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com
On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
used -
GPIO134 -- Enable/Disable TVP5146 interface
GPIO54 -- Enable/Disable Expansion Camera interface
GPIO136 -- Enable/Disable Camera (Sensor) interface
Added entry for the above GPIO's in mux.c and mux.h file
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/mux.c |6 ++
arch/arm/plat-omap/include/mach/mux.h |5 -
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 1556688..d226d81 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -471,6 +471,12 @@ MUX_CFG_34XX(AF5_34XX_GPIO142, 0x170,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX(AE5_34XX_GPIO143, 0x172,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AG4_34XX_GPIO134, 0x160,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(U8_34XX_GPIO54, 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX(AE4_34XX_GPIO136, 0x164,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
};
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 67fddec..ace037f 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -795,7 +795,10 @@ enum omap34xx_index {
AF6_34XX_GPIO140_UP,
AE6_34XX_GPIO141,
AF5_34XX_GPIO142,
- AE5_34XX_GPIO143
+ AE5_34XX_GPIO143,
+ AG4_34XX_GPIO134,
+ U8_34XX_GPIO54,
+ AE4_34XX_GPIO136,
};
struct omap_mux_cfg {
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com This is second version of OMAP3EVM Mulit-Media/Mass Market Daughter Card support. Fixes: - Cleaned unused header files, struct formating, and unused comments. - Pad/mux configuration handled in mux.ch - mux.ch related changes moved to seperate patch - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c to make more explicit. - Added some more meaningful name for Kconfig option TODO: - Camera sensor support (for future development). - Driver header file inclusion (dependency on ISP-Camera patches) I am working with Sergio to seperate/move header file to standard location. - Still need to fix naming convention for DC Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and saving it to file per frame. - Basic functionality of HSUSB Transceiver USB-83320 Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |8 +- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-dc-v4l.c | 348 +++ arch/arm/mach-omap2/board-omap3evm-dc.h | 42 4 files changed, 398 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc-v4l.c create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8fa650d..c1cf770 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -113,7 +113,7 @@ config MACH_OMAP_LDP bool OMAP3 LDP board depends on ARCH_OMAP3 ARCH_OMAP34XX -config MACH_OMAP2EVM +config MACH_OMAP2EVM bool OMAP 2530 EVM board depends on ARCH_OMAP2 ARCH_OMAP24XX @@ -125,6 +125,12 @@ config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP3EVM_MMDC + bool OMAP 3530 EVM Mass Market Daughter Card board + depends on MACH_OMAP3EVM + help + Set this if you've got a Mass Market Daughter Card board. + config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 631166d..45f52ca 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ usb-musb.o usb-ehci.o \ board-omap3evm-flash.o \ twl4030-generic-scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_MMDC) += board-omap3evm-dc-v4l.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ usb-musb.o usb-ehci.o \ mmc-twl4030.o \ diff --git a/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c b/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c new file mode 100644 index 000..a7b785e --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-dc-v4l.c @@ -0,0 +1,348 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-dc-v4l.c + * + * Driver for OMAP3 EVM Mass Market Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * Contributors: + * Anuj Aggarwal anuj.aggar...@ti.com + * Sivaraj R siva...@ti.com + * + * This package is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include linux/init.h +#include linux/i2c.h +#include linux/gpio.h +#include linux/videodev2.h + +#include mach/mux.h + +#include media/v4l2-int-device.h +#include media/tvp514x.h + +/* Include V4L2 ISP-Camera driver related header file */ +#include ../drivers/media/video/omap34xxcam.h +#include ../drivers/media/video/isp/ispreg.h + +#include board-omap3evm-dc.h + +#define MODULE_NAMEomap3evmdc + +/* Macro Definitions */ + +/* GPIO pins */ +#define GPIO134_SEL_TVP_Y (134) +#define GPIO54_SEL_EXP_CAM (54) +#define GPIO136_SEL_CAM(136) + +/* board internal information (BEGIN) */ + +/* I2C bus to which all I2C slave devices are attached */ +#define
Re: [PATCH E 11/14] OMAP clock: track child clocks
On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
+static int omap_clk_for_each_child(struct clk *clk, unsigned long
parent_rate,
+u8 rate_storage, int (*cb)(struct clk *, unsigned long, u8))
+{
+ struct clk_child *child;
+ int ret;
+
+ list_for_each_entry(child, clk-children, node) {
+ ret = (*cb)(child-clk, parent_rate, rate_storage);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+static int _do_propagate_rate(struct clk *clk, unsigned long parent_rate,
+ u8 rate_storage)
+{
+ if (clk-recalc)
+ clk-recalc(clk, parent_rate, rate_storage);
+ if (omap_clk_has_children(clk))
+ propagate_rate(clk, rate_storage);
+ return 0;
+}
/* Propagate rate to children */
void propagate_rate(struct clk *tclk, u8 rate_storage)
{
unsigned long parent_rate = 0;
if (tclk == NULL || IS_ERR(tclk))
return;
+ if (rate_storage == CURRENT_RATE)
+ parent_rate = tclk-rate;
+ else if (rate_storage == TEMP_RATE)
+ parent_rate = tclk-temp_rate;
+ omap_clk_for_each_child(tclk, parent_rate, rate_storage,
+ _do_propagate_rate);
}
This worries me. Calling this puts onto the stack:
- a frame for propagate_rate()
- a frame for omap_clk_for_each_child
- a frame for _do_propagate_rate
for every level of children. How close we get to overflowing the kernels
depends on how much each of those functions puts on the kernel stack.
However, since this is recursive, minimising the number of stack frames
is a good idea.
That's why I have in my patch:
[ARM] omap: move propagate_rate() calls into generic omap clock code
I've arranged for there to be the minimum of function nesting here.
I suggest keeping this.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for oprofile
Siarhei Siamashka siarhei.siamas...@nokia.com writes:
Signed-off-by: Siarhei Siamashka siarhei.siamas...@nokia.com
---
A second revision of gptimer oprofile patch
http://marc.info/?l=linux-omapm=123143937515088w=2
with the fixes suggested by Tony Lindgren
Timers from the CORE domain seem to work best on OMAP3.
Also tested the patch on Nokia 770 (OMAP1710).
Please let me know if anything else needs to be fixed.
Sorry to review this so late, but...
Why do you need to use a hardware timer for this? If you just need a
periodic event to fire, you should just use an hrtimer.
This would be a good way to make an oprofile model that is generic
and would not need any HW timer support.
Kevin
arch/arm/Kconfig |6 ++
arch/arm/oprofile/Makefile|1 +
arch/arm/oprofile/common.c|5 ++
arch/arm/oprofile/op_arm_model.h |2 +
arch/arm/oprofile/op_model_omap_gptimer.c | 93
+
5 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7fb201..8774136 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -160,6 +160,12 @@ config GENERIC_HARDIRQS_NO__DO_IRQ
if OPROFILE
+config OPROFILE_OMAP_GPTIMER
+ def_bool y
+ depends on ARCH_OMAP
+ select CONFIG_OMAP_32K_TIMER
+ select CONFIG_OMAP_DM_TIMER
+
config OPROFILE_ARMV6
def_bool y
depends on CPU_V6 !SMP
diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
index 88e31f5..fc2bc02 100644
--- a/arch/arm/oprofile/Makefile
+++ b/arch/arm/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_CPU_XSCALE)+= op_model_xscale.o
+oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
oprofile-$(CONFIG_OPROFILE_ARMV6)+= op_model_v6.o
oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 3fcd752..add3cb4 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -133,6 +133,11 @@ int __init oprofile_arch_init(struct oprofile_operations
*ops)
ops-backtrace = arm_backtrace;
+/* comes first, so that it can be overrided by a better implementation */
+#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
+ spec = op_omap_gptimer_spec;
+#endif
+
#ifdef CONFIG_CPU_XSCALE
spec = op_xscale_spec;
#endif
diff --git a/arch/arm/oprofile/op_arm_model.h
b/arch/arm/oprofile/op_arm_model.h
index 8c4e4f6..db936da 100644
--- a/arch/arm/oprofile/op_arm_model.h
+++ b/arch/arm/oprofile/op_arm_model.h
@@ -24,6 +24,8 @@ struct op_arm_model_spec {
extern struct op_arm_model_spec op_xscale_spec;
#endif
+extern struct op_arm_model_spec op_omap_gptimer_spec;
+
extern struct op_arm_model_spec op_armv6_spec;
extern struct op_arm_model_spec op_mpcore_spec;
extern struct op_arm_model_spec op_armv7_spec;
diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c
b/arch/arm/oprofile/op_model_omap_gptimer.c
new file mode 100644
index 000..98f7d2b
--- /dev/null
+++ b/arch/arm/oprofile/op_model_omap_gptimer.c
@@ -0,0 +1,93 @@
+/**
+ * OMAP gptimer based event monitor driver for oprofile
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Siarhei Siamashka siarhei.siamas...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/types.h
+#include linux/oprofile.h
+#include linux/interrupt.h
+#include linux/irq.h
+
+#include mach/dmtimer.h
+
+#include op_counter.h
+#include op_arm_model.h
+
+static struct omap_dm_timer *gptimer;
+
+static int gptimer_init(void)
+{
+ return 0;
+}
+
+static int gptimer_setup(void)
+{
+ return 0;
+}
+
+static irqreturn_t gptimer_interrupt(int irq, void *arg)
+{
+ omap_dm_timer_write_status(gptimer, OMAP_TIMER_INT_OVERFLOW);
+ oprofile_add_sample(get_irq_regs(), 0);
+ return IRQ_HANDLED;
+}
+
+static int gptimer_start(void)
+{
+ int err;
+ u32 count = counter_config[0].count;
+
+ BUG_ON(gptimer != NULL);
+ /* First try to request timers from CORE power domain for OMAP3 */
+ if (cpu_is_omap34xx()) {
+ gptimer = omap_dm_timer_request_specific(10);
+ if (gptimer == NULL)
+ gptimer = omap_dm_timer_request_specific(11);
+ }
+ /* Just any timer would be fine */
+ if (gptimer == NULL)
+ gptimer = omap_dm_timer_request();
+ if (gptimer == NULL)
+
RE: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
Thanks, Vaibhav Hiremath -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, January 30, 2009 1:03 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Jadav, Brijesh R; Shah, Hardik Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support On Thursday 29 January 2009 20:22:30 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This is second version of OMAP3EVM Mulit-Media/Mass Market Daughter Card support. Fixes: - Cleaned unused header files, struct formating, and unused comments. - Pad/mux configuration handled in mux.ch - mux.ch related changes moved to seperate patch - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c to make more explicit. - Added some more meaningful name for Kconfig option TODO: - Camera sensor support (for future development). - Driver header file inclusion (dependency on ISP-Camera patches) I am working with Sergio to seperate/move header file to standard location. - Still need to fix naming convention for DC Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and saving it to file per frame. What is the status of converting tvp5146 to v4l2_subdev? The longer it takes to convert it, the harder it will be now that you are starting to use this driver. v4l2_int_device should be phased out, preferably by 2.6.30. I'm more than happy to assist in this conversion, but please try to do this asap! [Hiremath, Vaibhav] Hans, I understand your concerns here. The TVP driver has strong dependency on ISP-Camera driver (Master) and without which it really doesn't make sense atleast for me. So actually I was trying to finish the ISP-Camera with V4L2-int and then migrate everything to the sub-devices. I am working with Sergio to finish this as early as possible. As far as sub-device framework is concerned, we have taken pro-active steps. If I understand correctly Davinci team here has already started migrating to the sub-device framework and the patches are under review internally. Soon you will see some patches on v4L mailing list for this. Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: adding nop usb transceiver
On Thursday 29 January 2009, Gupta, Ajay Kumar wrote: We'll need something like this, yes. This one looks to need a bit of tweaking yet though ... probably that could be done after merge. The state can need changing after one of the drivers is unregistered; I didn't get this comment. Basically, that almost all of the OTG state machine must be handled outside of this code. It's a bit of a puzzle how to partition that state machine between the drivers that need to collaborate on it. At this point I don't think there can be a single model that applies everywhere ... but maybe one could evolve over time. done. Added this nop_xceiv_register() which can be called from board-init files to register NOP. Please review the modified patch version below. Well, I count *two* patches. :) I'll tweak this one a bit. It's pretty close. That registration function should have a usb_*() prefix and not be declared in an MUSB-only header, since it could potentially be used with other OTG hardware. Thanks. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 11/14] OMAP clock: track child clocks
On Thu, Jan 29, 2009 at 03:14:01PM +, Russell King - ARM Linux wrote:
On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
The price paid is additional runtime memory consumption - 8 bytes per
clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.
For OMAP3, that's 222 struct clks of which 182 are children, and indeed
222 * 8 + 182 * 16 gives about 4.5K. On OMAP2, it's 140 and 136,
giving 140 * 8 + 136 * 16 = 3.3K.
Moving struct clk_child into struct clk means that its clk and flags
members can be deleted, making it 8 bytes in size - effectively just
the list_head. We need a list_head for the 'children' as you have it.
So, that works out as 16 bytes per clock. That gives 3.5K on OMAP3
and 2.2K on OMAP2.
So, by taking that alternative approach, not only do you end up using
less memory, but you also don't have to have the overhead of your
custom memory bookkeeping.
The other change I'd suggest is that you have one function which deals
with setting the parent of a clock:
void clk_reparent(struct clk *child, struct clk *parent)
{
list_del_init(child-sibling);
if (parent)
list_add(child-sibling, parent-children);
child-parent = parent;
/* now do the debugfs renaming to reattach the child
to the proper parent */
}
which is a lot simpler than your omap_clk_add_child() and
omap_clk_del_child().
These should be in the _core_ OMAP clock code, not just in the OMAP2
clock code. OMAP1 has child clocks as well as OMAP2.
And here is my version of this patch:
arch/arm/mach-omap2/clock.c |4 +-
arch/arm/plat-omap/clock.c | 49 +++
arch/arm/plat-omap/include/mach/clock.h |3 ++
3 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 56d9ea4..14bf566 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -175,7 +175,7 @@ void omap2_init_clksel_parent(struct clk *clk)
clk-name, clks-parent-name,
((clk-parent) ?
clk-parent-name : NULL));
- clk-parent = clks-parent;
+ clk_reparent(clk, clks-parent);
};
found = 1;
}
@@ -780,7 +780,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
if (clk-usecount 0)
_omap2_clk_enable(clk);
- clk-parent = new_parent;
+ clk_reparent(clk, new_parent);
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
clk-rate = new_parent-rate;
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 3688400..58e42b1 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -127,8 +127,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
if (ret == 0) {
if (clk-recalc)
clk-recalc(clk);
- if (clk-flags RATE_PROPAGATES)
- propagate_rate(clk);
+ propagate_rate(clk);
}
spin_unlock_irqrestore(clockfw_lock, flags);
@@ -150,8 +149,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
if (ret == 0) {
if (clk-recalc)
clk-recalc(clk);
- if (clk-flags RATE_PROPAGATES)
- propagate_rate(clk);
+ propagate_rate(clk);
}
spin_unlock_irqrestore(clockfw_lock, flags);
@@ -192,27 +190,34 @@ void followparent_recalc(struct clk *clk)
clk-rate = clk-parent-rate;
}
+void clk_reparent(struct clk *child, struct clk *parent)
+{
+ list_del_init(child-sibling);
+ if (parent)
+ list_add(child-sibling, parent-children);
+ child-parent = parent;
+
+ /* now do the debugfs renaming to reattach the child
+ to the proper parent */
+}
+
/* Propagate rate to children */
void propagate_rate(struct clk * tclk)
{
struct clk *clkp;
- if (tclk == NULL || IS_ERR(tclk))
- return;
-
- list_for_each_entry(clkp, clocks, node) {
- if (likely(clkp-parent != tclk))
- continue;
+ list_for_each_entry(clkp, tclk-children, sibling) {
if (clkp-recalc) {
unsigned long old_rate = clkp-rate;
clkp-recalc(clkp);
- if (clkp-rate != old_rate
- (clkp-flags RATE_PROPAGATES))
+ if (clkp-rate != old_rate)
propagate_rate(clkp);
}
}
}
+static LIST_HEAD(root_clks);
+
/**
* recalculate_root_clocks
Re: lowmemory android driver not needed?
Hi! I never expected it to be merged. I wrote it to allow us to ship a product. The top problem is, this file stay on non proper place. then, MM folks don't review at all. I think this patch need to receive MM folks review. This patch solves two problems for us: 1. It gives us more control over which process gets killed when we run out of memory. This can easily be fixed in the regular oom killer instead. 2. It prevents the system from getting unusable due to excessive demand paging. Before we added the low memory killer, we had devices stuck for many minutes before the system managed to allocate enough memory for the oom killer to kick in. The second problem is the most critical and if it is solved, we will not need this patch. Ok, maybe the best way forward is to create a demo that can be run on desktop machine, where machine misbehaves (like becomes useless for 10 minutes before OOM killer kicks in), then draw attetion of Andrew/Nick/etc? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM] [PATCH 2/6] DSPBRIDGE: Freeing allocated resources on rmmod
From: Omar Ramirez Luna x00o...@ti.com
Date: Wed, 28 Jan 2009 19:00:22 -0600
Subject: [PATCH] DSPBRIDGE: Freeing allocated resources on rmmod
This patch implements the cleanup of allocated resources whenever the
module is removed from the kernel.
Signed-off-by: Omar Ramirez Luna x00o...@ti.com
---
drivers/dsp/bridge/rmgr/drv_interface.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 126f5de..a756997 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -534,8 +534,28 @@ static void __exit bridge_exit(void)
{
dev_t devno;
bool ret;
+ DSP_STATUS dsp_status = DSP_SOK;
+ HANDLE hDrvObject = NULL;
+ struct PROCESS_CONTEXT*pCtxtclosed = NULL;
+
GT_0trace(driverTrace, GT_ENTER, - driver_exit\n);
+
+ dsp_status = CFG_GetObject((u32 *)hDrvObject, REG_DRV_OBJECT);
+ if (DSP_FAILED(dsp_status))
+ goto func_cont;
+
+ DRV_GetProcCtxtList(pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
+ while (pCtxtclosed != NULL) {
+ GT_1trace(driverTrace, GT_5CLASS, ***Cleanup of
+process***%d\n, pCtxtclosed-pid);
+ DRV_RemoveAllResources(pCtxtclosed);
+ PROC_Detach(pCtxtclosed-hProcessor);
+ DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
+pCtxtclosed, (void *)pCtxtclosed-pid);
+ pCtxtclosed = pCtxtclosed-next;;
+ }
+func_cont:
#ifndef CONFIG_DISABLE_BRIDGE_PM
#ifndef CONFIG_DISABLE_BRIDGE_DVFS
/* remove the constraints */
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH 3/6] DSPBRIDGE Fix for DCD stack overflow
From: Fernando Guzman Lugo x0095...@ti.com Date: Wed, 28 Jan 2009 19:23:24 -0600 Subject: [PATCH] DSPBRIDGE Fix for DCD stack overflow Fixed DCD stack buffer overflow. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- drivers/dsp/bridge/rmgr/dbdcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c index 129c16b..6fbe03f 100644 --- a/drivers/dsp/bridge/rmgr/dbdcd.c +++ b/drivers/dsp/bridge/rmgr/dbdcd.c @@ -473,7 +473,7 @@ DSP_STATUS DCD_GetObjectDef(IN struct DCD_MANAGER *hDcdMgr, u32 dwBufSize; /* Used by REG functions */ char szRegKey[REG_MAXREGPATHLENGTH]; char *szUuid; /*[MAXUUIDLEN];*/ - char szRegData[MAXUUIDLEN]; + char szRegData[REG_MAXREGPATHLENGTH]; char szSectName[MAXUUIDLEN + 2];/* .[UUID]\0 */ char *pszCoffBuf; u32 dwKeyLen; /* Len of REG key. */ -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH 5/6] DSPBRIDGE: Fixed race condition with DBLL target list
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 28 Jan 2009 19:29:25 -0600
Subject: [PATCH] DSPBRIDGE: Fixed race condition with DBLL target list
Fixed race condition with DBLL target list
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/rmgr/node.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 31d8de9..3242325 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -234,7 +234,6 @@ struct NODE_MGR {
struct GB_TMap *zChnlMap; /* Zero-Copy Channel alloc bit map */
struct NTFY_OBJECT *hNtfy; /* Manages registered notifications */
struct SYNC_CSOBJECT *hSync;/* For critical sections */
- struct SYNC_CSOBJECT *hAllocSync; /* For NODE_Alloc critical sections */
u32 ulFxnAddrs[NUMRMSFXNS]; /* RMS function addresses */
struct MSG_MGR *hMsg;
@@ -485,7 +484,7 @@ func_cont:
}
pNode-hNodeMgr = hNodeMgr;
/* This critical section protects GetNodeProps */
- status = SYNC_EnterCS(hNodeMgr-hAllocSync);
+ status = SYNC_EnterCS(hNodeMgr-hSync);
if (procId != DSP_UNIT)
goto func_cont3;
@@ -565,7 +564,7 @@ func_cont:
}
func_cont3:
- (void)SYNC_LeaveCS(hNodeMgr-hAllocSync);
+ (void)SYNC_LeaveCS(hNodeMgr-hSync);
func_cont1:
if (pAttrIn != NULL) {
/* Overrides of NBD properties */
@@ -1586,13 +1585,6 @@ DSP_STATUS NODE_CreateMgr(OUT struct NODE_MGR
**phNodeMgr,
status = SYNC_InitializeCS(pNodeMgr-hSync);
if (DSP_FAILED(status))
status = DSP_EMEMORY;
-
- if (DSP_SUCCEEDED(status)) {
- status = SYNC_InitializeCS(pNodeMgr-hAllocSync);
- if (DSP_FAILED(status))
- status = DSP_EMEMORY;
-
- }
}
if (DSP_SUCCEEDED(status)) {
pNodeMgr-chnlMap = GB_create(pNodeMgr-ulNumChnls);
@@ -2982,9 +2974,6 @@ static void DeleteNodeMgr(struct NODE_MGR *hNodeMgr)
if (hNodeMgr-hSync)
SYNC_DeleteCS(hNodeMgr-hSync);
- if (hNodeMgr-hSync)
- SYNC_DeleteCS(hNodeMgr-hAllocSync);
-
if (hNodeMgr-hStrmMgr)
STRM_Delete(hNodeMgr-hStrmMgr);
@@ -3342,6 +3331,12 @@ DSP_STATUS NODE_GetUUIDProps(DSP_HPROCESSOR hProcessor,
status = DSP_EFAIL;
}
+ /* Enter the critical section. This is needed because
+ * DCD_GetObjectDef will ultimately end up calling DBLL_open/close,
+ * which needs to be protected in order to not corrupt the zlib manager
+ * (COD). */
+ status = SYNC_EnterCS(hNodeMgr-hSync);
+
if (DSP_SUCCEEDED(status)) {
dcdNodeProps.pstrCreatePhaseFxn = NULL;
dcdNodeProps.pstrExecutePhaseFxn = NULL;
@@ -3366,6 +3361,9 @@ DSP_STATUS NODE_GetUUIDProps(DSP_HPROCESSOR hProcessor,
if (dcdNodeProps.pstrIAlgName)
MEM_Free(dcdNodeProps.pstrIAlgName);
}
+ /* Leave the critical section, we're done. */
+ (void)SYNC_LeaveCS(hNodeMgr-hSync);
+
}
return status;
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch/rfc 2.6.28-rc2] input: twl4030_keypad driver
On Wednesday, January 21, 2009 5:13 PM, David Brownell wrote:
Driver for the twl4030 family keypad controller. This controller
supports a key matrix of up to 8 rows by 8 columns. Board init
code passes a description of the key matrix to the driver.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
[SNIP]
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -255,11 +255,18 @@ struct twl4030_madc_platform_data {
int irq_line;
};
+/* Boards have uniqe mappings of {col, row} -- keycode.
+ * Column and row are 4 bits, but range only from 0..7;
+ * a PERSISTENT_KEY is always on and never reported.
+ */
+#define KEY_PERSISTENT 0x0080
+#define KEY(col, row, keycode) (((col) 28) | ((row) 24) |
(keycode))
The same KEY macro is defined in:
arch/arm/mach-pxa/include/mach/pxa27x_keypad.h
arch/arm/plat-omap/include/mach/keypad.h
I also have a keypad driver for the ep93xx that uses the same macro.
Shouldn't/couldn't this be generalized and added to the
include/linux/input.h file? Allowing 4-bits for row/col gives a maximum
key matrix of 16x16 keys which should be enough for just about anything.
Regards,
Hartley
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH 1/6] CSI2: Add function to change number of data lanes used.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 1/6] CSI2: Add function to change number of data
lanes
used.
Add new CSI2 function.
New function is isp_csi2_complexio_lanes_count().
Sets the number of CSI2 data lanes that should be used.
Signed-off-by: Dominic Curran dcur...@ti.com
Signed-off-by: Greg Hofer greg.ho...@hp.com
---
drivers/media/video/isp/ispcsi2.c | 33 +++--
drivers/media/video/isp/ispcsi2.h |5 +
2 files changed, 36 insertions(+), 2 deletions(-)
mode change 100644 = 100755 drivers/media/video/isp/ispcsi2.c
mode change 100644 = 100755 drivers/media/video/isp/ispcsi2.h
Index: omapzoom04/drivers/media/video/isp/ispcsi2.c
===
--- omapzoom04.orig/drivers/media/video/isp/ispcsi2.c
+++ omapzoom04/drivers/media/video/isp/ispcsi2.c
@@ -112,6 +112,11 @@ int isp_csi2_complexio_lanes_config(stru
currlanes_u-data[i] = true;
update_complexio_cfg1 = true;
}
+ /* If the lane position is non zero then we can assume that
+* the initial lane state is on.
+*/
+ if (currlanes-data[i].pos)
+ currlanes-data[i].state = ISP_CSI2_LANE_ON;
}
if (currlanes-clk.pos != reqcfg-clk.pos) {
@@ -158,9 +163,10 @@ int isp_csi2_complexio_lanes_update(bool
1));
reg |= (currlanes-data[i].pol
ISPCSI2_COMPLEXIO_CFG1_DATA_POL_SHIFT(i + 1));
- reg |= (currlanes-data[i].pos
+ if (currlanes-data[i].state == ISP_CSI2_LANE_ON)
+ reg |= (currlanes-data[i].pos
ISPCSI2_COMPLEXIO_CFG1_DATA_POSITION_SHIFT(i +
- 1));
+1));
currlanes_u-data[i] = false;
}
}
@@ -181,6 +187,29 @@ int isp_csi2_complexio_lanes_update(bool
}
/**
+ * isp_csi2_complexio_lanes_count - Turn data lanes on/off dynamically.
+ * @ cnt: Number of data lanes to enable.
+ *
+ * Always returns 0.
+ **/
+int isp_csi2_complexio_lanes_count(int cnt)
+{
+ struct isp_csi2_lanes_cfg *currlanes = current_csi2_cfg.lanes;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ if (i cnt)
+ currlanes-data[i].state = ISP_CSI2_LANE_ON;
+ else
+ currlanes-data[i].state = ISP_CSI2_LANE_OFF;
+ }
+
+ isp_csi2_complexio_lanes_update(true);
+ return 0;
+}
+EXPORT_SYMBOL(isp_csi2_complexio_lanes_count);
+
+/**
* isp_csi2_complexio_lanes_get - Gets CSI2 ComplexIO lanes configuration.
*
* Gets settings from HW registers and fills in the internal driver memory
Index: omapzoom04/drivers/media/video/isp/ispcsi2.h
===
--- omapzoom04.orig/drivers/media/video/isp/ispcsi2.h
+++ omapzoom04/drivers/media/video/isp/ispcsi2.h
@@ -20,6 +20,9 @@
#define OMAP_ISP_CSI2_API_H
#include linux/videodev2.h
+#define ISP_CSI2_LANE_OFF 0
+#define ISP_CSI2_LANE_ON 1
+
enum isp_csi2_irqevents {
OCP_ERR_IRQ = 0x4000,
SHORT_PACKET_IRQ = 0x2000,
@@ -63,6 +66,7 @@ enum isp_csi2_frame_mode {
struct csi2_lanecfg {
u8 pos;
u8 pol;
+ u8 state; /*Current state - 1-Used 0-Unused */
};
struct isp_csi2_lanes_cfg {
@@ -175,6 +179,7 @@ struct isp_csi2_cfg_update {
int isp_csi2_complexio_lanes_config(struct isp_csi2_lanes_cfg *reqcfg);
int isp_csi2_complexio_lanes_update(bool force_update);
+int isp_csi2_complexio_lanes_count(int cnt);
int isp_csi2_complexio_lanes_get(void);
int isp_csi2_complexio_power_autoswitch(bool enable);
int isp_csi2_complexio_power(enum isp_csi2_power_cmds power_cmd);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size for 8MP sensor.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size for 8MP
sensor.
A temporary buffer is created to hold the image while it is written by
Previewer module and then read by Resizer module. This is called LSC
Workaround. To take into account the Sony IMX046 8MP sensor that buffer
needs to be increased in size.
Changed the #defines to be upper case.
Patch also fixes the initialization of a couple of CCDC values.
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/isp/isp.c | 10 +-
drivers/media/video/isp/isp.h |4 ++--
drivers/media/video/isp/ispccdc.c |2 ++
3 files changed, 9 insertions(+), 7 deletions(-)
Index: omapzoom04/drivers/media/video/isp/isp.c
===
--- omapzoom04.orig/drivers/media/video/isp/isp.c
+++ omapzoom04/drivers/media/video/isp/isp.c
@@ -1172,20 +1172,20 @@ void omapisp_unset_callback()
**/
u32 isp_buf_allocation(void)
{
- buff_addr = (void *) vmalloc(buffer_size);
+ buff_addr = (void *) vmalloc(ISP_BUFFER_MAX_SIZE);
if (!buff_addr) {
printk(KERN_ERR Cannot allocate memory );
return -ENOMEM;
}
- sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, no_of_pages);
+ sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, ISP_BUFFER_MAX_PAGES);
if (!sglist_alloc) {
printk(KERN_ERR videobuf_vmalloc_to_sg error);
return -ENOMEM;
}
- num_sc = dma_map_sg(NULL, sglist_alloc, no_of_pages, 1);
- buff_addr_mapped = ispmmu_map_sg(sglist_alloc, no_of_pages);
+ num_sc = dma_map_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES, 1);
+ buff_addr_mapped = ispmmu_map_sg(sglist_alloc, ISP_BUFFER_MAX_PAGES);
if (!buff_addr_mapped) {
printk(KERN_ERR ispmmu_map_sg mapping failed );
return -ENOMEM;
@@ -1217,7 +1217,7 @@ void isp_buf_free(void)
{
if (alloc_done == 1) {
ispmmu_unmap(buff_addr_mapped);
- dma_unmap_sg(NULL, sglist_alloc, no_of_pages, 1);
+ dma_unmap_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES, 1);
kfree(sglist_alloc);
vfree(buff_addr);
alloc_done = 0;
Index: omapzoom04/drivers/media/video/isp/isp.h
===
--- omapzoom04.orig/drivers/media/video/isp/isp.h
+++ omapzoom04/drivers/media/video/isp/isp.h
@@ -69,8 +69,8 @@
#define NUM_ISP_CAPTURE_FORMATS(sizeof(isp_formats) /\
sizeof(isp_formats[0]))
#define ISP_WORKAROUND 1
-#define buffer_size (1024 * 1024 * 10)
-#define no_of_pages (buffer_size / (4 * 1024))
+#define ISP_BUFFER_MAX_SIZE (1024 * 1024 * 16)
+#define ISP_BUFFER_MAX_PAGES (ISP_BUFFER_MAX_SIZE / (4 * 1024))
typedef int (*isp_vbq_callback_ptr) (struct videobuf_buffer *vb);
typedef void (*isp_callback_t) (unsigned long status,
Index: omapzoom04/drivers/media/video/isp/ispccdc.c
===
--- omapzoom04.orig/drivers/media/video/isp/ispccdc.c
+++ omapzoom04/drivers/media/video/isp/ispccdc.c
@@ -1265,6 +1265,8 @@ int ispccdc_config_size(u32 input_w, u32
}
if (ispccdc_obj.ccdc_outfmt == CCDC_OTHERS_VP) {
+ ispccdc_obj.ccdcin_woffset = 0;
+ ispccdc_obj.ccdcin_hoffset = 0;
omap_writel((ispccdc_obj.ccdcin_woffset
ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
(ispccdc_obj.ccdcin_w
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH 3/6] IMX046: Add support for Sony imx046 sensor.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 3/6] IMX046: Add support for Sony imx046 sensor.
This patch adds the driver files for the Sony IMX046 8MP camera sensor.
Driver sets up the sensor to send frame data via the MIPI CSI2 i/f.
Sensor is setup to output the following base sizes:
- 3280 x 2464 (8MP)
- 3280 x 616 (2MP)
- 820 x 616
Sensor's output image format is Bayer10 (GrR/BGb).
Driver has V4L2 controls for:
- Exposure
- Analog Gain
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/Kconfig |8
drivers/media/video/Makefile |1
drivers/media/video/imx046.c | 1635 +++
drivers/media/video/imx046.h | 326
4 files changed, 1970 insertions(+)
create mode 100644 drivers/media/video/imx046.c
create mode 100644 drivers/media/video/imx046.h
Index: omapzoom04/drivers/media/video/Kconfig
===
--- omapzoom04.orig/drivers/media/video/Kconfig
+++ omapzoom04/drivers/media/video/Kconfig
@@ -334,6 +334,14 @@ config VIDEO_OV3640_CSI2
This enables the use of the CSI2 serial bus for the ov3640
camera.
+config VIDEO_IMX046
+ tristate Sony IMX046 sensor driver (8MP)
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX046 camera. It is currently working with the TI OMAP3
+ camera controller.
+
config VIDEO_SAA7110
tristate Philips SAA7110 video decoder
depends on VIDEO_V4L1 I2C
Index: omapzoom04/drivers/media/video/Makefile
===
--- omapzoom04.orig/drivers/media/video/Makefile
+++ omapzoom04/drivers/media/video/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_VIDEO_OV9640) += ov9640.o
obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o
obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_VIDEO_OV3640) += ov3640.o
+obj-$(CONFIG_VIDEO_IMX046) += imx046.o
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
Index: omapzoom04/drivers/media/video/imx046.c
===
--- /dev/null
+++ omapzoom04/drivers/media/video/imx046.c
@@ -0,0 +1,1635 @@
+/*
+ * drivers/media/video/imx046.c
+ *
+ * Sony imx046 sensor driver
+ *
+ *
+ * Copyright (C) 2008 Hewlett Packard
+ *
+ * Leverage mt9p012.c
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/i2c.h
+#include linux/delay.h
+#include media/v4l2-int-device.h
+
+#include imx046.h
+#include omap34xxcam.h
+#include isp/isp.h
+#include isp/ispcsi2.h
+
+
+#define IMX046_DRIVER_NAME imx046
+#define IMX046_MOD_NAME IMX046:
+
+#define I2C_M_WR 0
+
+
+/* from IMX046ES_registerSetting_I2C_MIPI_2lane_def_080925.xls */
+const static struct imx046_reg initial_list[] = {
+ {IMX046_REG_IMAGE_ORIENTATION, 0x03, I2C_8BIT},
+ {IMX046_REG_COARSE_INT_TIME, 0x0120, I2C_16BIT},
+ {IMX046_REG_ANALOG_GAIN_GLOBAL, 0x80, I2C_16BIT},
+ {0x300A, 0x80, I2C_8BIT},
+ {IMX046_REG_Y_OPBADDR_START_DI, 0x08, I2C_8BIT},
+ {IMX046_REG_Y_OPBADDR_END_DI, 0x37, I2C_8BIT},
+ {IMX046_REG_CHCODE_OUTCHSINGLE, 0x60, I2C_8BIT},
+ {IMX046_REG_OUTIF, 0x01, I2C_8BIT},
+ {IMX046_REG_RGPOF_RGPOFV2, 0x28, I2C_8BIT},
+ {IMX046_REG_CPCKAUTOEN, 0x00, I2C_8BIT},
+ {IMX046_REG_RGCPVFB, 0x60, I2C_8BIT},
+ {IMX046_REG_RGAZPDRV, 0x24, I2C_8BIT},
+ {IMX046_REG_RGAZTEST, 0x34, I2C_8BIT},
+ {IMX046_REG_RGVSUNLV, 0x3B, I2C_8BIT},
+ {IMX046_REG_CLPOWER, 0x30, I2C_8BIT},
+ {IMX046_REG_CLPOWERSP, 0x00, I2C_8BIT},
+ {IMX046_REG_ACLDIRV_TVADDCLP, 0x00, I2C_8BIT},
+ {IMX046_REG_OPB_CTRL, 0x0080, I2C_16BIT},
+ {0x30AB, 0x1C, I2C_8BIT},
+ {0x30B0, 0x32, I2C_8BIT},
+ {0x30B2, 0x83, I2C_8BIT},
+ {IMX046_REG_RAW10CH2V2P_LO, 0xD8, I2C_8BIT},
+ {IMX046_REG_RAW10CH2V2D_LO, 0x17, I2C_8BIT},
+ {IMX046_REG_COMP8CH1V2P_LO, 0xCF, I2C_8BIT},
+ {IMX046_REG_COMP8CH1V2D_LO, 0xF1, I2C_8BIT},
+ {IMX046_REG_RAW10CH1V2P_LO, 0xD8, I2C_8BIT},
+ {IMX046_REG_RAW10CH1V2D_LO, 0x17, I2C_8BIT},
+ {0x3302, 0x0A, I2C_8BIT},
+ {0x3303, 0x09, I2C_8BIT},
+ {IMX046_REG_RGTLPX, 0x05, I2C_8BIT},
+ {IMX046_REG_RGTCLKPREPARE, 0x04, I2C_8BIT},
+ {IMX046_REG_RGTCLKZERO, 0x15, I2C_8BIT},
+ {IMX046_REG_RGTCLKPRE, 0x03, I2C_8BIT},
+ {IMX046_REG_RGTCLKPOST, 0x13, I2C_8BIT},
+ {IMX046_REG_RGTCLKTRAIL, 0x05, I2C_8BIT},
+ {IMX046_REG_RGTHSEXIT, 0x0B, I2C_8BIT},
+ {0x302B, 0x38, I2C_8BIT}, /* for 18Mhz xclk */
+ {I2C_REG_TERM, I2C_VAL_TERM, I2C_LEN_TERM}
+};
+
+/**
+ * struct imx046_sensor - main structure for storage
[OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP board.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP
board.
Support for the Sony IMX046 sensor on the OMAP3430 SDP board.
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 197
1 file changed, 197 insertions(+)
Index: omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
@@ -45,6 +45,9 @@
#include ti-compat.h
#ifdef CONFIG_VIDEO_OMAP3
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
#include media/v4l2-int-device.h
#include ../drivers/media/video/omap34xxcam.h
#include ../drivers/media/video/isp/ispreg.h
@@ -52,9 +55,11 @@
#define FPGA_SPR_GPIO1_3v3 (0x1 14)
#define FPGA_GPIO6_DIR_CTRL(0x1 6)
static void __iomem *fpga_map_addr;
+
#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
#include ../drivers/media/video/mt9p012.h
#endif
+
#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
#include ../drivers/media/video/ov3640.h
#include ../drivers/media/video/isp/ispcsi2.h
@@ -71,6 +76,22 @@ static struct omap34xxcam_hw_config *hwc
#define OV3640_CSI2_PHY_TCLK_MISS 1
#define OV3640_CSI2_PHY_TCLK_SETTLE14
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) || defined(CONFIG_VIDEO_IMX046_MODULE)
+#include ../drivers/media/video/imx046.h
+#include ../drivers/media/video/isp/ispcsi2.h
+#define IMX046_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_CLOCK_LANE 1/* Clock lane position: 1 */
+#define IMX046_CSI2_DATA0_LANE 2/* Data0 lane position: 2 */
+#define IMX046_CSI2_DATA1_LANE 3/* Data1 lane position: 3 */
+#define IMX046_CSI2_PHY_THS_TERM 2
+#define IMX046_CSI2_PHY_THS_SETTLE 23
+#define IMX046_CSI2_PHY_TCLK_TERM 0
+#define IMX046_CSI2_PHY_TCLK_MISS 1
+#define IMX046_CSI2_PHY_TCLK_SETTLE14
+#endif
#endif
#ifdef CONFIG_VIDEO_DW9710
@@ -926,6 +947,176 @@ static struct ov3640_platform_data sdp34
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) || defined(CONFIG_VIDEO_IMX046_MODULE)
+
+static struct omap34xxcam_sensor_config imx046_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
+};
+
+static int imx046_sensor_set_prv_data(void *priv)
+{
+ struct omap34xxcam_hw_config *hwc = priv;
+
+ hwc-u.sensor.xclk = imx046_hwc.xclk;
+ hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-dev_index = 2;
+ hwc-dev_minor = 5;
+ hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
+ hwc-interface_type = ISP_CSIA;
+
+ hwc-csi2.hw_csi2.lanes.clock.polarity = IMX046_CSI2_CLOCK_POLARITY;
+ hwc-csi2.hw_csi2.lanes.clock.position = IMX046_CSI2_CLOCK_LANE;
+ hwc-csi2.hw_csi2.lanes.data[0].polarity = IMX046_CSI2_DATA0_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[0].position = IMX046_CSI2_DATA0_LANE;
+ hwc-csi2.hw_csi2.lanes.data[1].polarity = IMX046_CSI2_DATA1_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[1].position = IMX046_CSI2_DATA1_LANE;
+ hwc-csi2.hw_csi2.phy.ths_term = IMX046_CSI2_PHY_THS_TERM;
+ hwc-csi2.hw_csi2.phy.ths_settle = IMX046_CSI2_PHY_THS_SETTLE;
+ hwc-csi2.hw_csi2.phy.tclk_term = IMX046_CSI2_PHY_TCLK_TERM;
+ hwc-csi2.hw_csi2.phy.tclk_miss = IMX046_CSI2_PHY_TCLK_MISS;
+ hwc-csi2.hw_csi2.phy.tclk_settle = IMX046_CSI2_PHY_TCLK_SETTLE;
+ return 0;
+}
+
+static struct isp_interface_config imx046_if_config = {
+ .ccdc_par_ser = ISP_CSIA,
+ .dataline_shift = 0x0,
+ .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
+ .vdint0_timing = 0x0,
+ .vdint1_timing = 0x0,
+ .strobe = 0x0,
+ .prestrobe = 0x0,
+ .shutter = 0x0,
+ .prev_sph = 2,
+ .prev_slv = 0,
+ .wenlog = ISPCCDC_CFG_WENLOG_OR,
+ .dcsub = IMX046_BLACK_LEVEL_AVG,
+ .u.csi.crc = 0x0,
+ .u.csi.mode = 0x0,
+ .u.csi.edge = 0x0,
+ .u.csi.signalling = 0x0,
+ .u.csi.strobe_clock_inv = 0x0,
+ .u.csi.vs_edge = 0x0,
+ .u.csi.channel = 0x0,
+ .u.csi.vpclk = 0x2,
+ .u.csi.data_start = 0x0,
+ .u.csi.data_size = 0x0,
+ .u.csi.format = V4L2_PIX_FMT_SGRBG10,
+};
+
+
+static int imx046_sensor_power_set(enum v4l2_power power)
+{
+ struct isp_csi2_lanes_cfg lanecfg;
+ struct isp_csi2_phy_cfg phyconfig;
+ static enum v4l2_power previous_power = V4L2_POWER_OFF;
+ int err = 0;
+
+ switch (power) {
+ case V4L2_POWER_ON:
+ /* Power Up Sequence */
+
[OMAPZOOM][PATCH 6/6] Add support for Sony imx046 to OMAP zoom2 board.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 6/6] Add support for Sony imx046 to OMAP zoom2 board.
Support for the Sony IMX046 sensor on the OMAP Zoom2 board.
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/configs/omap_zoom2_defconfig |1
arch/arm/mach-omap2/board-zoom2.c | 206 +-
2 files changed, 205 insertions(+), 2 deletions(-)
Index: omapzoom04/arch/arm/configs/omap_zoom2_defconfig
===
--- omapzoom04.orig/arch/arm/configs/omap_zoom2_defconfig
+++ omapzoom04/arch/arm/configs/omap_zoom2_defconfig
@@ -994,6 +994,7 @@ CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_MT9P012 is not set
# CONFIG_VIDEO_DW9710 is not set
# CONFIG_VIDEO_OV3640 is not set
+CONFIG_VIDEO_IMX046=y
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA717X is not set
# CONFIG_VIDEO_TVP5150 is not set
Index: omapzoom04/arch/arm/mach-omap2/board-zoom2.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-zoom2.c
+++ omapzoom04/arch/arm/mach-omap2/board-zoom2.c
@@ -23,6 +23,7 @@
#include linux/synaptics_i2c_rmi.h
#include linux/spi/spi.h
#include linux/i2c/twl4030.h
+#include linux/mm.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -50,6 +51,30 @@
#include mach/prcm_34xx.h
#endif
+#ifdef CONFIG_VIDEO_OMAP3
+#include media/v4l2-int-device.h
+#include ../drivers/media/video/omap34xxcam.h
+#include ../drivers/media/video/isp/ispreg.h
+#if defined(CONFIG_VIDEO_IMX046) || defined(CONFIG_VIDEO_IMX046_MODULE)
+#include ../drivers/media/video/imx046.h
+#include ../drivers/media/video/isp/ispcsi2.h
+#define IMX046_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_CLOCK_LANE 1/* Clock lane position: 1 */
+#define IMX046_CSI2_DATA0_LANE 2/* Data0 lane position: 2 */
+#define IMX046_CSI2_DATA1_LANE 3/* Data1 lane position: 3 */
+#define IMX046_CSI2_PHY_THS_TERM 2
+#define IMX046_CSI2_PHY_THS_SETTLE 23
+#define IMX046_CSI2_PHY_TCLK_TERM 0
+#define IMX046_CSI2_PHY_TCLK_MISS 1
+#define IMX046_CSI2_PHY_TCLK_SETTLE14
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
+#endif
+#endif
+
#ifdef CONFIG_TOUCHSCREEN_SYNAPTICS
#define OMAP_SYNAPTICS_GPIO163
#endif
@@ -301,6 +326,175 @@ static struct twl4030_keypad_data ldp_kp
.irq= TWL4030_MODIRQ_KEYPAD,
};
+#if defined(CONFIG_VIDEO_IMX046) || defined(CONFIG_VIDEO_IMX046_MODULE)
+
+static struct omap34xxcam_sensor_config imx046_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
+};
+
+static int imx046_sensor_set_prv_data(void *priv)
+{
+ struct omap34xxcam_hw_config *hwc = priv;
+
+ hwc-u.sensor.xclk = imx046_hwc.xclk;
+ hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-dev_index = 2;
+ hwc-dev_minor = 5;
+ hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
+ hwc-interface_type = ISP_CSIA;
+
+ hwc-csi2.hw_csi2.lanes.clock.polarity = IMX046_CSI2_CLOCK_POLARITY;
+ hwc-csi2.hw_csi2.lanes.clock.position = IMX046_CSI2_CLOCK_LANE;
+ hwc-csi2.hw_csi2.lanes.data[0].polarity = IMX046_CSI2_DATA0_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[0].position = IMX046_CSI2_DATA0_LANE;
+ hwc-csi2.hw_csi2.lanes.data[1].polarity = IMX046_CSI2_DATA1_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[1].position = IMX046_CSI2_DATA1_LANE;
+ hwc-csi2.hw_csi2.phy.ths_term = IMX046_CSI2_PHY_THS_TERM;
+ hwc-csi2.hw_csi2.phy.ths_settle = IMX046_CSI2_PHY_THS_SETTLE;
+ hwc-csi2.hw_csi2.phy.tclk_term = IMX046_CSI2_PHY_TCLK_TERM;
+ hwc-csi2.hw_csi2.phy.tclk_miss = IMX046_CSI2_PHY_TCLK_MISS;
+ hwc-csi2.hw_csi2.phy.tclk_settle = IMX046_CSI2_PHY_TCLK_SETTLE;
+ return 0;
+}
+
+static struct isp_interface_config imx046_if_config = {
+ .ccdc_par_ser = ISP_CSIA,
+ .dataline_shift = 0x0,
+ .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
+ .vdint0_timing = 0x0,
+ .vdint1_timing = 0x0,
+ .strobe = 0x0,
+ .prestrobe = 0x0,
+ .shutter = 0x0,
+ .prev_sph = 2,
+ .prev_slv = 0,
+ .wenlog = ISPCCDC_CFG_WENLOG_OR,
+ .dcsub = IMX046_BLACK_LEVEL_AVG,
+ .u.csi.crc = 0x0,
+ .u.csi.mode = 0x0,
+ .u.csi.edge = 0x0,
+ .u.csi.signalling = 0x0,
+ .u.csi.strobe_clock_inv = 0x0,
+ .u.csi.vs_edge = 0x0,
+ .u.csi.channel = 0x0,
+ .u.csi.vpclk = 0x2,
+ .u.csi.data_start = 0x0,
+ .u.csi.data_size = 0x0,
+ .u.csi.format = V4L2_PIX_FMT_SGRBG10,
+};
+
+
+static int imx046_sensor_power_set(enum v4l2_power power)
+{
+ struct isp_csi2_lanes_cfg lanecfg;
+
RE: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size for 8MP sensor.
Thanks,
Vaibhav Hiremath
-Original Message-
From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
boun...@redhat.com] On Behalf Of Curran, Dominic
Sent: Friday, January 30, 2009 6:24 AM
To: linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size
for 8MP sensor.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 2/6] Increase isp workaround buffer size
for 8MP
sensor.
A temporary buffer is created to hold the image while it is written
by
Previewer module and then read by Resizer module. This is called LSC
Workaround. To take into account the Sony IMX046 8MP sensor that
buffer
needs to be increased in size.
Changed the #defines to be upper case.
Patch also fixes the initialization of a couple of CCDC values.
Signed-off-by: Dominic Curran dcur...@ti.com
---
drivers/media/video/isp/isp.c | 10 +-
drivers/media/video/isp/isp.h |4 ++--
drivers/media/video/isp/ispccdc.c |2 ++
3 files changed, 9 insertions(+), 7 deletions(-)
Index: omapzoom04/drivers/media/video/isp/isp.c
===
--- omapzoom04.orig/drivers/media/video/isp/isp.c
+++ omapzoom04/drivers/media/video/isp/isp.c
@@ -1172,20 +1172,20 @@ void omapisp_unset_callback()
**/
u32 isp_buf_allocation(void)
{
- buff_addr = (void *) vmalloc(buffer_size);
+ buff_addr = (void *) vmalloc(ISP_BUFFER_MAX_SIZE);
if (!buff_addr) {
printk(KERN_ERR Cannot allocate memory );
return -ENOMEM;
}
- sglist_alloc = videobuf_vmalloc_to_sg(buff_addr, no_of_pages);
+ sglist_alloc = videobuf_vmalloc_to_sg(buff_addr,
ISP_BUFFER_MAX_PAGES);
if (!sglist_alloc) {
printk(KERN_ERR videobuf_vmalloc_to_sg error);
return -ENOMEM;
}
- num_sc = dma_map_sg(NULL, sglist_alloc, no_of_pages, 1);
- buff_addr_mapped = ispmmu_map_sg(sglist_alloc, no_of_pages);
+ num_sc = dma_map_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES,
1);
+ buff_addr_mapped = ispmmu_map_sg(sglist_alloc,
ISP_BUFFER_MAX_PAGES);
if (!buff_addr_mapped) {
printk(KERN_ERR ispmmu_map_sg mapping failed );
return -ENOMEM;
@@ -1217,7 +1217,7 @@ void isp_buf_free(void)
{
if (alloc_done == 1) {
ispmmu_unmap(buff_addr_mapped);
- dma_unmap_sg(NULL, sglist_alloc, no_of_pages, 1);
+ dma_unmap_sg(NULL, sglist_alloc, ISP_BUFFER_MAX_PAGES,
1);
kfree(sglist_alloc);
vfree(buff_addr);
alloc_done = 0;
Index: omapzoom04/drivers/media/video/isp/isp.h
===
--- omapzoom04.orig/drivers/media/video/isp/isp.h
+++ omapzoom04/drivers/media/video/isp/isp.h
@@ -69,8 +69,8 @@
#define NUM_ISP_CAPTURE_FORMATS (sizeof(isp_formats) /\
sizeof(isp_formats[0]))
#define ISP_WORKAROUND 1
-#define buffer_size (1024 * 1024 * 10)
-#define no_of_pages (buffer_size / (4 * 1024))
+#define ISP_BUFFER_MAX_SIZE (1024 * 1024 * 16)
+#define ISP_BUFFER_MAX_PAGES (ISP_BUFFER_MAX_SIZE / (4 * 1024))
[Hiremath, Vaibhav] Is here (4 * 1024) indicates ISP-MMUSG page size
configuration or normal kernel page size?
If it is kernel page size, then we can use PAGE_SIZE macro instead of hard
coding.
typedef int (*isp_vbq_callback_ptr) (struct videobuf_buffer *vb);
typedef void (*isp_callback_t) (unsigned long status,
Index: omapzoom04/drivers/media/video/isp/ispccdc.c
===
--- omapzoom04.orig/drivers/media/video/isp/ispccdc.c
+++ omapzoom04/drivers/media/video/isp/ispccdc.c
@@ -1265,6 +1265,8 @@ int ispccdc_config_size(u32 input_w, u32
}
if (ispccdc_obj.ccdc_outfmt == CCDC_OTHERS_VP) {
+ ispccdc_obj.ccdcin_woffset = 0;
+ ispccdc_obj.ccdcin_hoffset = 0;
omap_writel((ispccdc_obj.ccdcin_woffset
ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
(ispccdc_obj.ccdcin_w
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-
requ...@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to OMAP3430 SDP board.
Thanks,
Vaibhav Hiremath
-Original Message-
From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
boun...@redhat.com] On Behalf Of Curran, Dominic
Sent: Friday, January 30, 2009 6:24 AM
To: linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
OMAP3430 SDP board.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 4/6] Add support for Sony imx046 to
OMAP3430 SDP board.
Support for the Sony IMX046 sensor on the OMAP3430 SDP board.
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 197
1 file changed, 197 insertions(+)
Index: omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ omapzoom04/arch/arm/mach-omap2/board-3430sdp.c
@@ -45,6 +45,9 @@
#include ti-compat.h
#ifdef CONFIG_VIDEO_OMAP3
+#ifndef CONFIG_TWL4030_CORE
+#error no power companion board defined!
+#endif
[Hiremath, Vaibhav] Do we really required to do this?
#include media/v4l2-int-device.h
#include ../drivers/media/video/omap34xxcam.h
#include ../drivers/media/video/isp/ispreg.h
@@ -52,9 +55,11 @@
#define FPGA_SPR_GPIO1_3v3 (0x1 14)
#define FPGA_GPIO6_DIR_CTRL (0x1 6)
static void __iomem *fpga_map_addr;
+
#if defined(CONFIG_VIDEO_MT9P012) ||
defined(CONFIG_VIDEO_MT9P012_MODULE)
#include ../drivers/media/video/mt9p012.h
#endif
+
#if defined(CONFIG_VIDEO_OV3640) ||
defined(CONFIG_VIDEO_OV3640_MODULE)
#include ../drivers/media/video/ov3640.h
#include ../drivers/media/video/isp/ispcsi2.h
@@ -71,6 +76,22 @@ static struct omap34xxcam_hw_config *hwc
#define OV3640_CSI2_PHY_TCLK_MISS1
#define OV3640_CSI2_PHY_TCLK_SETTLE 14
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) ||
defined(CONFIG_VIDEO_IMX046_MODULE)
+#include ../drivers/media/video/imx046.h
+#include ../drivers/media/video/isp/ispcsi2.h
+#define IMX046_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define IMX046_CSI2_CLOCK_LANE 1/* Clock lane
position: 1 */
+#define IMX046_CSI2_DATA0_LANE 2/* Data0 lane
position: 2 */
+#define IMX046_CSI2_DATA1_LANE 3/* Data1 lane
position: 3 */
+#define IMX046_CSI2_PHY_THS_TERM 2
+#define IMX046_CSI2_PHY_THS_SETTLE 23
+#define IMX046_CSI2_PHY_TCLK_TERM0
+#define IMX046_CSI2_PHY_TCLK_MISS1
+#define IMX046_CSI2_PHY_TCLK_SETTLE 14
+#endif
#endif
#ifdef CONFIG_VIDEO_DW9710
@@ -926,6 +947,176 @@ static struct ov3640_platform_data sdp34
#endif
+
+#if defined(CONFIG_VIDEO_IMX046) ||
defined(CONFIG_VIDEO_IMX046_MODULE)
+
+static struct omap34xxcam_sensor_config imx046_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = PAGE_ALIGN(3280 * 2464 * 2) * 2,
+};
+
[Hiremath, Vaibhav] You may want to align the structure, same comment I had
also received from Tony on MMDC support patch.
+static int imx046_sensor_set_prv_data(void *priv)
+{
+ struct omap34xxcam_hw_config *hwc = priv;
+
+ hwc-u.sensor.xclk = imx046_hwc.xclk;
+ hwc-u.sensor.sensor_isp = imx046_hwc.sensor_isp;
+ hwc-dev_index = 2;
+ hwc-dev_minor = 5;
+ hwc-dev_type = OMAP34XXCAM_SLAVE_SENSOR;
+ hwc-interface_type = ISP_CSIA;
+
+ hwc-csi2.hw_csi2.lanes.clock.polarity =
IMX046_CSI2_CLOCK_POLARITY;
+ hwc-csi2.hw_csi2.lanes.clock.position =
IMX046_CSI2_CLOCK_LANE;
+ hwc-csi2.hw_csi2.lanes.data[0].polarity =
IMX046_CSI2_DATA0_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[0].position =
IMX046_CSI2_DATA0_LANE;
+ hwc-csi2.hw_csi2.lanes.data[1].polarity =
IMX046_CSI2_DATA1_POLARITY;
+ hwc-csi2.hw_csi2.lanes.data[1].position =
IMX046_CSI2_DATA1_LANE;
+ hwc-csi2.hw_csi2.phy.ths_term = IMX046_CSI2_PHY_THS_TERM;
+ hwc-csi2.hw_csi2.phy.ths_settle = IMX046_CSI2_PHY_THS_SETTLE;
+ hwc-csi2.hw_csi2.phy.tclk_term = IMX046_CSI2_PHY_TCLK_TERM;
+ hwc-csi2.hw_csi2.phy.tclk_miss = IMX046_CSI2_PHY_TCLK_MISS;
+ hwc-csi2.hw_csi2.phy.tclk_settle =
IMX046_CSI2_PHY_TCLK_SETTLE;
+ return 0;
+}
+
+static struct isp_interface_config imx046_if_config = {
+ .ccdc_par_ser = ISP_CSIA,
+ .dataline_shift = 0x0,
+ .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
+ .vdint0_timing = 0x0,
+ .vdint1_timing = 0x0,
+ .strobe = 0x0,
+ .prestrobe = 0x0,
+ .shutter = 0x0,
+ .prev_sph = 2,
+ .prev_slv = 0,
+ .wenlog = ISPCCDC_CFG_WENLOG_OR,
+ .dcsub = IMX046_BLACK_LEVEL_AVG,
+ .u.csi.crc = 0x0,
+ .u.csi.mode = 0x0,
+ .u.csi.edge = 0x0,
+ .u.csi.signalling = 0x0,
+
RE: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
Thanks,
Vaibhav Hiremath
-Original Message-
From: video4linux-list-boun...@redhat.com [mailto:video4linux-list-
boun...@redhat.com] On Behalf Of Curran, Dominic
Sent: Friday, January 30, 2009 6:24 AM
To: linux-omap; video4linux-l...@redhat.com
Cc: greg.ho...@hp.com
Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
From: Dominic Curran dcur...@ti.com
Subject: [OMAPZOOM][PATCH 5/6] ZOOM2: Rename the zoom2 i2c struct.
Rename i2c structures to something sensible.
This patch is not specific for imx046 sensor.
Do this in preparation for i2c changes for imx046 sensor.
Signed-off-by: Greg Hofer greg.ho...@hp.com
Signed-off-by: Dominic Curran dcur...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: omapzoom04/arch/arm/mach-omap2/board-zoom2.c
===
--- omapzoom04.orig/arch/arm/mach-omap2/board-zoom2.c
+++ omapzoom04/arch/arm/mach-omap2/board-zoom2.c
@@ -472,7 +472,7 @@ static struct twl4030_platform_data ldp_
.keypad = ldp_kp_twl4030_data,
};
-static struct i2c_board_info __initdata ldp_i2c_boardinfo[] = {
+static struct i2c_board_info __initdata zoom2_i2c_bus1_info[] = {
[Hiremath, Vaibhav] I think zoom2_i2c1_info should be sufficient, since
i2c1,2,3 itself indicates bus.
{
I2C_BOARD_INFO(twl4030, 0x48),
.flags = I2C_CLIENT_WAKE,
@@ -507,7 +507,7 @@ static struct synaptics_i2c_rmi_platform
.power = synaptics_power,
};
-static struct i2c_board_info __initdata ldp3430_i2c_board_info[] =
{
+static struct i2c_board_info __initdata zoom2_i2c_bus2_info[] = {
{
I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME,
SYNAPTICS_I2C_ADDR),
.platform_data = ldp3430_synaptics_platform_data,
@@ -518,12 +518,12 @@ static struct i2c_board_info __initdata
static int __init omap_i2c_init(void)
{
- omap_register_i2c_bus(1, 2600, ldp_i2c_boardinfo,
- ARRAY_SIZE(ldp_i2c_boardinfo));
+ omap_register_i2c_bus(1, 2600, zoom2_i2c_bus1_info,
+ ARRAY_SIZE(zoom2_i2c_bus1_info));
#ifdef CONFIG_TOUCHSCREEN_SYNAPTICS
- ldp3430_i2c_board_info[0].irq =
OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
- omap_register_i2c_bus(2, 100, ldp3430_i2c_board_info,
- ARRAY_SIZE(ldp3430_i2c_board_info));
+ zoom2_i2c_bus2_info[0].irq =
OMAP_GPIO_IRQ(OMAP_SYNAPTICS_GPIO);
+ omap_register_i2c_bus(2, 100, zoom2_i2c_bus2_info,
+ ARRAY_SIZE(zoom2_i2c_bus2_info));
#endif
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-
requ...@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH C 06/13] OMAP3 clock: DPLLs should enter bypass if new rate is sys_ck
Hello Russell, this E-mail responds to your comments on patches C 04 through C 08. My understanding is that you'd like me to: 1. Compress patches C 04 through C 09; 2. Modify omap3_noncore_dpll_enable() to move the if (!ret) clk-rate = rate outside and below the conditional; 3. Remove some of the blank lines before and after braces in C 06; 4. Modify the DPLL bypass clock handling to change the DPLL's clk-parent, rather than return the bypass clock rate. The above all make sense to me, and #4, if it works in practice, should be a significant improvement over the existing code. If this is what you're looking for, I'll send a compressed, modified patch. Would you like it to be based on the codebase post C 03, or against another commit? regards, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH A 01/10] OMAP2/3: Add non-CORE DPLL rate set code and M, N programming
On Thu, 29 Jan 2009, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2009 at 07:12:47PM -0700, Paul Walmsley wrote:
+/* Non-CORE DPLL rate set code */
+
+/*
+ * omap3_noncore_dpll_program - set non-core DPLL M,N values directly
+ * @clk: struct clk * of DPLL to set
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ * @freqsel: FREQSEL value to set
+ *
+ * Program the DPLL with the supplied M, N values, and wait for the DPLL to
+ * lock.. Returns -EINVAL upon error, or 0 upon success.
+ */
+static int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16
freqsel)
+{
+ struct dpll_data *dd;
+ u32 v;
+
+ if (!clk)
+ return -EINVAL;
+
+ dd = clk-dpll_data;
+ if (!dd)
+ return -EINVAL;
Final point... this is only called from the function below, which also
checks that clk and clk-dpll_data are both non-NULL. So these checks
are unnecessary.
Okay. Do you want to take care of that in your merged version of this
patch, or would you like me to send an updated version, along with that
custom dpll4 set_rate function?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lowmemory android driver not needed?
On Thu, Jan 29, 2009 at 02:29:05PM +0900, KOSAKI Motohiro wrote: I never expected it to be merged. I wrote it to allow us to ship a product. Then, please write DON'T MERGE ME on the top of patch description. we can adjust our viewpoints. The code will live in the drivers/staging/ directory for now and not get merged into the main portion of the kernel tree until everyone can agree on it. But for now, it is useful and seems to work for a few million devices out there, so we can't just ignore it :) No. if author don't hope review and merge, we don't have any reason to reviewing. I don't think you understand the goal/model for the drivers/staging/ subdirectories. This is where drivers and other stand-alone chunks of code live while they are not yet up to the real mergable status for the rest of the kernel tree. I think staging is great activity, but I also think it is no good idea for kernel core piece. While there, they get cleaned up, fixed up, and then hopefully, merged into the main portion of the kernel tree when the proper subsystem maintainers say it is ok. The fact is simple more. if auther refuse to receive reviewing, the code don't clean up at all, don't fix up at all. then, dropping is better. But that's not true at all. And I'll be glad to fix up anything, I just need to make sure that the system still will work properly when doing so. Whenever code in these directories is loaded, it taints the kernel with a TAINT_CRAP flag so that everyone involved knows to ignore any bug reports. So while a review would be wonderful to have, it's not being asked for for this specific low-memory driver. I'd like to see your final version of what you proposed a while ago, if that goes into the kernel tree, then this chunk of code will merely be deleted entirely. Hope this helps explain things better, Again, I respect for your drivers/staging activity largely. then, I don't oppose any driver merge to staging. thanks. but I don't think driver/staging is good place for non driver code. The problem is, any patch must be reviewed by stakeholder, not maintenar only. then, the patch should post lkml and subsystem mailing list at first. I like reviewed code than unreviewed code. Heh, so do I. And this is an odd driver, I do know that. But it solves a real problem that can't be solved any other way currently, which is needed for a real system that is shipping. So, if it can't be solved any other way, do you have a way this kind of thing could be more correct? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 McSPI: Adds context save/restore
- Original Message -
From: Imre Deak imre.d...@nokia.com
To: ext Nayak, Rajendra rna...@ti.com
Cc: linux-omap@vger.kernel.org; Kevin Hilman
khil...@deeprootsystems.com; V, Hemanth heman...@ti.com
Sent: Friday, January 30, 2009 12:36 AM
Subject: Re: [PATCH] OMAP3 McSPI: Adds context save/restore
On Wed, Jan 28, 2009 at 10:11:29AM +0100, ext Nayak, Rajendra wrote:
From: Hemanth V heman...@ti.com
This patch adds context save/restore feature to McSPI driver.
This has been tested by instrumenting the driver code i.e by
adding a McSPI softreset in omap2_mcspi_disable_clocks function.
This patch includes review comment fixes
Signed-off-by: Hemanth V heman...@ti.com
---
drivers/spi/omap2_mcspi.c | 97
--
1 files changed, 77 insertions(+), 20 deletions(-)
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-01-27
11:45:06.0 +0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2009-01-27
11:53:16.0 +0530
[...]
+static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
+{
+ struct spi_master *spi_cntrl;
+ spi_cntrl = mcspi-master;
+
+ /* McSPI: context restore */
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
+ omap2_mcspi_ctx[spi_cntrl-bus_num -
1].modulctrl);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ omap2_mcspi_ctx[spi_cntrl-bus_num -
1].sysconfig);
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_CHCONF0,
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].chconf0);
You have to restore this to the proper CHCONF register. And in the
current form you have to restore all of them.
Currently only CS0 CHCONF i.e chconf0 is being saved and restored, since its
the only one configured and used
by the driver.
+
+
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
+ omap2_mcspi_ctx[spi_cntrl-bus_num -
1].wakeupenable);
+}
+static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
+{
+ clk_disable(mcspi-ick);
+ clk_disable(mcspi-fck);
+}
+
[...]
@@ -537,6 +593,8 @@
mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, l);
+ omap2_mcspi_ctx[spi_cntrl-bus_num - 1].chconf0 = l;
And here save it to a slot based on CS.
--Imre
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 01/11] OMAP: Add clk_get_parent() for OMAP2/3
On Thu, 29 Jan 2009, Russell King - ARM Linux wrote:
On Wed, Jan 28, 2009 at 12:18:16PM -0700, Paul Walmsley wrote:
From: Mans Rullgard m...@mansr.com
This makes clk_get_parent() work on OMAP2/3.
This is clearly something that the generic code should be doing.
It's not something specific to OMAP2/3. Please move it to
arch/arm/plat-omap/clock.c
Done; revised patch below.
- Paul
From: Mans Rullgard m...@mansr.com
Date: Thu Jan 29 23:26:35 2009 -0700
OMAP: Add clk_get_parent() for OMAP1/2/3
This makes clk_get_parent() work on OMAP.
linux-omap source commit is efd65273726b12e42c7225bd1703e5252bdb46c0.
Signed-off-by: Måns Rullgård m...@mansr.com
Signed-off-by: Tony Lindgren t...@atomide.com
[p...@pwsan.com: per rmk, made this function available on all OMAPs
and fixated its implementation]
Signed-off-by: Paul Walmsley p...@pwsan.com
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index be6aab9..eb59874 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -210,18 +210,7 @@ EXPORT_SYMBOL(clk_set_parent);
struct clk *clk_get_parent(struct clk *clk)
{
- unsigned long flags;
- struct clk * ret = NULL;
-
- if (clk == NULL || IS_ERR(clk))
- return ret;
-
- spin_lock_irqsave(clockfw_lock, flags);
- if (arch_clock-clk_get_parent)
- ret = arch_clock-clk_get_parent(clk);
- spin_unlock_irqrestore(clockfw_lock, flags);
-
- return ret;
+ return clk-parent;
}
EXPORT_SYMBOL(clk_get_parent);
diff --git a/arch/arm/plat-omap/include/mach/clock.h
b/arch/arm/plat-omap/include/mach/clock.h
index f6adf39..47c9a11 100644
--- a/arch/arm/plat-omap/include/mach/clock.h
+++ b/arch/arm/plat-omap/include/mach/clock.h
@@ -104,7 +104,6 @@ struct clk_functions {
long(*clk_round_rate)(struct clk *clk, unsigned long rate);
int (*clk_set_rate)(struct clk *clk, unsigned long rate);
int (*clk_set_parent)(struct clk *clk, struct clk *parent);
- struct clk *(*clk_get_parent)(struct clk *clk);
void(*clk_allow_idle)(struct clk *clk);
void(*clk_deny_idle)(struct clk *clk);
void(*clk_disable_unused)(struct clk *clk);
Re: lowmemory android driver not needed?
[Greg KH g...@kroah.com] but I don't think driver/staging is good place for non driver code. The problem is, any patch must be reviewed by stakeholder, not maintenar only. then, the patch should post lkml and subsystem mailing list at first. I like reviewed code than unreviewed code. Heh, so do I. And this is an odd driver, I do know that. But it solves a real problem that can't be solved any other way currently, which is needed for a real system that is shipping. So, if it can't be solved any other way, do you have a way this kind of thing could be more correct? I think a lot of the confusion here comes from Arve's earlier (very terse) remark: I never expected it to be merged. I wrote it to allow us to ship a product. At the risk of putting words in his mouth, I believe this should be parsed as we wrote this to solve problems necessary to ship products and did not expect it to be merged to mainline as-is. We'd love to get support for low memory process killing that works for our app model into the mainline. If that's by reworking this driver until it's acceptable or by implementing the same functionality a different way, making use of some other subsystem, or whatever, we're not particularly picky. Our goal is, eventually, to maintain as few patches outside of the kernel as possible so things can build out of the box. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 11/11] Fix omap1 clock issues
On Thu, 29 Jan 2009, Russell King - ARM Linux wrote: On Wed, Jan 28, 2009 at 12:18:48PM -0700, Paul Walmsley wrote: From: Tony Lindgren t...@atomide.com This fixes booting, and is a step toward fixing things properly: - Make enable_reg u32 instead of u16 No, you're passing this to __raw_read/write, so it needs to be void __iomem *, not u32. If there's another patch doing that it needs to be combined with this one. The miniscule details of fixes upon fixes aren't interesting for submission purposes, and just adds extra unnecessary review load for upstream people. Ditto for anything else which is passed to __raw_read/write*. Will build a revised patch for this and pass it to Tony for a boot test, then repost. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
