Re: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
Hello Eero,
On Thu, 5 Mar 2009, ext-eero.nurkk...@nokia.com wrote:
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
It is the bit 8 that is for FCLK. All other blocks in
OMAPs use the bit 8 for denying FCLK idling.
Hmm. Looking at the 34xx Rev O TRM register tables, it looks like most
modules use bit 9 to indicate that FCLK should be kept on and bit 8 to
indicate that the ICLK should be kept on? DSI, DISPC, SR, DMA4 are some
examples.
This of course contradicts some of the text, such as Table 16-6, 16-60,
and 18-4. CLOCKACTIVITY bits seem to attract documentation bugs; Table
4-554 and 15.3.1.4.1 are other examples.
This is an RFC, I'd like some discussion. Somebody
double-check this?
Suggest you doublecheck with TI. Richard Woodruff cc'ed; he might be able
to clarify.
- Paul
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0258b55..11057eb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -157,7 +157,7 @@
#define SYSC_AUTOIDLE_MASK (1 0)
#define SYSC_IDLEMODE_SMART 0x2
-#define SYSC_CLOCKACTIVITY_FCLK 0x2
+#define SYSC_CLOCKACTIVITY_FCLK 0x1
struct omap_i2c_dev {
--
1.5.2
--
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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
On Thu, 2009-03-05 at 09:42 +0100, ext Paul Walmsley wrote: Hello Eero, Hmm. Looking at the 34xx Rev O TRM register tables, it looks like most modules use bit 9 to indicate that FCLK should be kept on and bit 8 to indicate that the ICLK should be kept on? DSI, DISPC, SR, DMA4 are some examples. How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite for I2C than what's said in Table 18-44: I2C_SYSC!! Please, Richard? - Eero -- 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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
On Thu, 2009-03-05 at 10:46 +0200, Eero Nurkkala wrote: How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite for I2C than what's said in Table 18-44: I2C_SYSC!! Please, Richard? - Eero To answer to myself, I am 100% certain the McBSP FCLK is the bit 8. I should have sent a patch about that already.. Kind of worried as could they really change that much? From page to page and block to block and within a block...=) - Eero -- 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 09/10] OMAP2/3: Remove OMAP_PRM_REGADDR, OMAP_CM_REGADDR
Hello Richard
On Tue, 3 Mar 2009, Russell King - ARM Linux wrote:
On Tue, Mar 03, 2009 at 07:09:35AM -0800, Kevin Hilman wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Mon, Mar 02, 2009 at 07:48:07PM -0700, Paul Walmsley wrote:
Hi Kevin,
On Mon, 2 Mar 2009, Kevin Hilman wrote:
What about the rest of the *_PRM_REGADDR() accessor macro changes in
this patch?
The rest of the PM core code uses these and so does not build on top
of the Russell's omap-clks3 branch.
yes, all of the *_{PRM,CM}_REGADDR() work should be kept.
Well, in case it wasn't clear from my previous mail, I'm not merging this.
It was clear why you weren't merging the couple pieces that you
referenced, but it wasn't clear whether you had problems with the rest
of the patch.
Because it's just plain wrong. It persists in creating new instances of
crap that I've already removed, such as using 'u32' instead of void __iomem
pointers for register addresses.
It persists in the init-time fixup of addresses.
Sounds like there has been some miscommunication. From our previous
E-mail on this topic,
http://lkml.org/lkml/2009/1/29/32
... we agreed that the register rewriting part of this patch should not be
merged; and noted that the register base rewriting was removed by D 10.
(At the end of the six series, all virtual addresses are typed as void
__iomem *.)
The clkdm.name-clkdm.ptr fixup is unreliable without having a flag to
say whether it's been done or not.
Could we just add a simple CLOCK_INITED clock flag to resolve your
concerns here? Or are you referring to a different problem?
And so forth.
While the powerdomain stuff can be (and has been) failed, clocks can't be
failed as a result of the rewrites not working - since they're referenced
by other clocks, we'd need some way to ensure all childs of a failed parent
also fail.
This seems to be an inherent issue with the structure of the clock tree
itself, with parent pointers to static structures, rather than with
clockdomain rewriting. Undoubtedly we could put plenty more validity
checks into the clock code. The question is whether they would be worth
the code space/development time tradeoff. Most of the validity problems
observed during the last few years of work prompted checks to be added.
Moreover, the approach taken in the series of patches introducing it
requires some clocks to be split up just for the sake of supporting this
alternative method - I'm referring here to the creation of the mcbsp
src clocks.
It's true that the mcbsp_fck clocks needed to split to accomodate the PRCM
module + register offset change, but as noted before, I don't think it
affects anything in practice. It's an internal clock tree structure
detail that ultimately won't be exposed to the driver. It doesn't involve
any rewriting.
If I look at the remaining patch dependencies, then it works out as
something like this:
+---[A 09] OMAP2/3: Remove OMAP_PRM_REGADDR, OMAP_CM_REGADDR
+---[D 05] OMAP2 clock: add clk.prcm_mod field; annotate OMAP2xxx clocks
+---[D 06] OMAP3 clock: add prcm_mod field to OMAP3xxx clocks
+---[D 07] OMAP2/3 clock: add _omap2_clk_{read,write}_reg()
+---[D 08] OMAP2/3 clock: use clk-prcm_mod for all struct clk register addres
+---[D 09] OMAP2/3 clock: encode target IDLEST bits
+---[F 05] OMAP clock: add OMAP chip family-specific clk_register() option
+---[D 04] OMAP3 clock: split mcbspX_src_fck from mcbspX_fck
|
| +-[B 01] OMAP2/3 clock: combine clkdm, clkdm_name into union in struct clk
| +-[B 03] OMAP2/3 clockdomains: add CM, PRM, virt_opp_clkdm clockdomains
| +-[B 05] OMAP2/3 clock: add clockdomains to all remaining clocks; fix clkdm
| |
+-+-[F 12] OMAP2/3 McBSP: add temporary clockdomain fix for McBSP virtual cloc
|
+-[F 06] OMAP2/3 clock: every clock must have a clkdm
where D4 is a side effect of the way register addresses are being handled
(iow D6), and F12 is a side effect of requiring F6 and D4. Moreover,
the virt_opp_clkdm part of B03 is a side effect of F6.
If we're having to introduce work-arounds for ways things are being done,
that's a sure sign that the original change was not correct.
Or that we haven't yet had the opportunity to implement a more
wide-ranging code change, as is the case with the virt_opp_clkdm. That is
slated for removal; it's currently removed for OMAP3 in development code.
The working model has been to work on individual pieces separately, to
build towards an end-goal, rather than making a huge set of changes all at
once with multiple interlocking code pieces.
Patch F 12 is no longer needed, as we discussed earlier. It was only
needed because the old McBSP driver used some buggy custom clocks, and
this has already been fixed in the driver.
Also, from what I've heard, the register access issue is going to be far
larger and is going to require _significant_ rework when OMAP4 becomes
Re: [PATCH A 09/10] OMAP2/3: Remove OMAP_PRM_REGADDR, OMAP_CM_REGADDR
On Thu, 5 Mar 2009, Paul Walmsley wrote: Hello Richard (my apologies, of course this should have been, Hello Russell) - 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] DSPBRIDGE: Remove variables not used in cfgdefs.h
On Wed, Mar 4, 2009 at 8:11 PM, Fernando Guzman Lugo x0095...@ti.com wrote:
This patch removes some variable that are not used.
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 10 --
drivers/dsp/bridge/rmgr/drv.c | 2 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
index e7633b5..34a28f8
--- a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
@@ -77,15 +77,6 @@
u8 bIRQAttrib; /* IRQ Attribute */
u32 dwOffsetForMonitor; /* The Shared memory starts from
* dwMemBase + this offset */
- u32 dwBusType; /* Bus type for this device */
- u32 dwProgBase; /* DSP ProgBase */
- u32 dwProgLength; /* DSP ProgBase Length */
- u32 dwRegBase; /* DSP memory mapped register base */
- u32 dwRegLength; /* DSP Register Base Length */
- u32 ClientHandle; /* Client Handle */
- u32 SocketHandle; /* Socket and Function Pair */
- u32 CardInfo; /* This will be used as a context data in
- * in the CardRequestIRQ */
/*
* Info needed by NODE for allocating channels to communicate with
RMS:
* dwChnlOffset: Offset of RMS channels. Lower channels are
@@ -102,7 +93,6 @@
void __iomem *dwWdTimerDspBase;
void __iomem *dwMboxBase;
void __iomem *dwDmmuBase;
- u32 *dwDipiBase;
void __iomem *dwSysCtrlBase;
} ;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 2241f48..160d730
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1733,7 +1733,6 @@ static DSP_STATUS RequestBridgeResources(u32 dwContext,
s32 bRequest)
/* Second window is for DSP external memory shared with MPU */
if (DSP_SUCCEEDED(status)) {
/* for Linux, these are hard-coded values */
- pResources-dwBusType = 0;
pResources-bIRQRegisters = 0;
pResources-bIRQAttrib = 0;
pResources-dwOffsetForMonitor = 0;
@@ -1856,7 +1855,6 @@ static DSP_STATUS RequestBridgeResourcesDSP(u32
dwContext, s32 bRequest)
}
if (DSP_SUCCEEDED(status)) {
/* for Linux, these are hard-coded values */
- pResources-dwBusType = 0;
pResources-bIRQRegisters = 0;
pResources-bIRQAttrib = 0;
pResources-dwOffsetForMonitor = 0;
--
1.5.6.4
--
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
Couldn't apply :(
I guess you missed the following commit.
commit 3b313ff3e50d3c46c506e8939f92c406aa5b0bc6
Author: Ramesh Gupta G grgu...@ti.com
Date: Fri Feb 13 14:51:19 2009 +0530
patching file arch/arm/plat-omap/include/dspbridge/cfgdefs.h
Hunk #2 FAILED at 93.
1 out of 2 hunks FAILED -- saving rejects to file
arch/arm/plat-omap/include/dspbridge/cfgdefs.h.rej
patching file drivers/dsp/bridge/rmgr/drv.c
Hunk #1 succeeded at 1736 (offset 3 lines).
Hunk #2 succeeded at 1862 (offset 7 lines).
Cheers,
Ameya.
--
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] DSPBRIDGE: Change address resources to void __iomem *
On Wed, Mar 4, 2009 at 8:11 PM, Fernando Guzman Lugo x0095...@ti.com wrote:
This patch changes address resources to void __iomem *
Signed-off-by: Guzman Lugo Fernando x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 16
drivers/dsp/bridge/hw/hw_dspssC64P.c | 2 +-
drivers/dsp/bridge/hw/hw_dspssC64P.h | 2 +-
drivers/dsp/bridge/hw/hw_mbox.c | 30 +++--
drivers/dsp/bridge/hw/hw_mbox.h | 18
drivers/dsp/bridge/hw/hw_mmu.c | 43 ++--
drivers/dsp/bridge/hw/hw_mmu.h | 30 +++---
drivers/dsp/bridge/hw/hw_prcm.c | 26 ++--
drivers/dsp/bridge/hw/hw_prcm.h | 17
drivers/dsp/bridge/rmgr/drv.c | 52
drivers/dsp/bridge/rmgr/node.c | 2 +-
drivers/dsp/bridge/wmd/_tiomap.h | 2 +-
drivers/dsp/bridge/wmd/tiomap3430.c | 47 ++---
13 files changed, 145 insertions(+), 142 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
index ca96b3c..e7633b5
--- a/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/cfgdefs.h
@@ -96,14 +96,14 @@
u32 dwChnlOffset;
u32 dwChnlBufSize;
u32 dwNumChnls;
- u32 dwPrmBase;
- u32 dwCmBase;
- u32 dwPerBase;
- u32 dwWdTimerDspBase;
- u32 dwMboxBase;
- u32 dwDmmuBase;
- u32 dwDipiBase;
- u32 dwSysCtrlBase;
+ void __iomem *dwPrmBase;
+ void __iomem *dwCmBase;
+ void __iomem *dwPerBase;
+ void __iomem *dwWdTimerDspBase;
+ void __iomem *dwMboxBase;
+ void __iomem *dwDmmuBase;
+ u32 *dwDipiBase;
+ void __iomem *dwSysCtrlBase;
} ;
struct CFG_DSPMEMDESC {
diff --git a/drivers/dsp/bridge/hw/hw_dspssC64P.c
b/drivers/dsp/bridge/hw/hw_dspssC64P.c
index 0d0d45c..6aac57d
--- a/drivers/dsp/bridge/hw/hw_dspssC64P.c
+++ b/drivers/dsp/bridge/hw/hw_dspssC64P.c
@@ -34,7 +34,7 @@
#include IPIAccInt.h
/* HW FUNCTIONS */
-HW_STATUS HW_DSPSS_BootModeSet(const u32 baseAddress,
+HW_STATUS HW_DSPSS_BootModeSet(const void __iomem *baseAddress,
enum HW_DSPSYSC_BootMode_t bootMode,
const u32 bootAddress)
{
diff --git a/drivers/dsp/bridge/hw/hw_dspssC64P.h
b/drivers/dsp/bridge/hw/hw_dspssC64P.h
index 493effd..50f9af4
--- a/drivers/dsp/bridge/hw/hw_dspssC64P.h
+++ b/drivers/dsp/bridge/hw/hw_dspssC64P.h
@@ -41,7 +41,7 @@
#define HW_DSP_IDLEBOOT_ADDR 0x007E
- extern HW_STATUS HW_DSPSS_BootModeSet(const u32 baseAddress,
+ extern HW_STATUS HW_DSPSS_BootModeSet(const void __iomem *baseAddress,
enum HW_DSPSYSC_BootMode_t bootMode,
const u32 bootAddress);
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index bc61d64..93fa51e
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -36,7 +37,7 @@
struct MAILBOX_CONTEXT mboxsetting = {0x4, 0x1, 0x1};
/* Saves the mailbox context */
-HW_STATUS HW_MBOX_saveSettings(u32 baseAddress)
+HW_STATUS HW_MBOX_saveSettings(void __iomem *baseAddress)
{
HW_STATUS status = RET_OK;
@@ -50,7 +51,7 @@ HW_STATUS HW_MBOX_saveSettings(u32 baseAddress)
}
/* Restores the mailbox context */
-HW_STATUS HW_MBOX_restoreSettings(u32 baseAddress)
+HW_STATUS HW_MBOX_restoreSettings(void __iomem *baseAddress)
{
HW_STATUS status = RET_OK;
/* Restor IRQ enable status */
@@ -65,8 +66,8 @@ HW_STATUS HW_MBOX_restoreSettings(u32 baseAddress)
/* Reads a u32 from the sub module message box Specified. if there are no
* messages in the mailbox then and error is returned. */
-HW_STATUS HW_MBOX_MsgRead(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
- u32 *const pReadValue)
+HW_STATUS HW_MBOX_MsgRead(const void __iomem *baseAddress,
+ const HW_MBOX_Id_t mailBoxId, u32 *const pReadValue)
{
HW_STATUS status = RET_OK;
@@ -86,8 +87,8 @@ HW_STATUS HW_MBOX_MsgRead(const u32 baseAddress, const
HW_MBOX_Id_t mailBoxId,
}
/* Writes a u32 from the sub module message box Specified. */
-HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
- const u32 writeValue)
+HW_STATUS HW_MBOX_MsgWrite(const void __iomem *baseAddress,
+ const HW_MBOX_Id_t mailBoxId, const u32 writeValue)
{
HW_STATUS status = RET_OK;
@@ -105,8 +106,8 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress, const
Re: [PATCH 0/5] DSPBRIDGE: patches.
On Tue, Mar 3, 2009 at 2:00 AM, Guzman Lugo, Fernando x0095...@ti.com wrote: Hi, I am sending my patches again, now they are base on this commit: commit bacaa3dc169e11488faf17519a42c4e8641fc17e Author: Hiroshi DOYU hiroshi.d...@nokia.com Date: Mon Feb 16 10:43:15 2009 +0200 TIDSPBRIDGE: fix some build warnings I hope there will be not problems this time. Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- 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] omap3isp: Add ISP main driver and register definitions
Thanks for the comments, Alexey!
Alexey Klimov wrote:
+static int isp_probe(struct platform_device *pdev)
+{
+ struct isp_device *isp;
+ int ret_err = 0;
+ int i;
+
+ isp = kzalloc(sizeof(*isp), GFP_KERNEL);
+ if (!isp) {
+ dev_err(pdev-dev, could not allocate memory\n);
+ return -ENODEV;
return -ENOMEM; ?
Done.
+ }
+
+ platform_set_drvdata(pdev, isp);
+
+ isp-dev = pdev-dev;
+
+ for (i = 0; i = OMAP3_ISP_IOMEM_CSI2PHY; i++) {
+ struct resource *mem;
+ /* request the mem region for the camera registers */
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!mem) {
+ dev_err(isp-dev, no mem resource?\n);
+ return -ENODEV;
Maybe ENODEV is not apropriate here too..
What else it could be? ENOENT comes to mind but I'm not sure it's
significantly better.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
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: Problems while designing TPS65023 regulator driver
Mark, Thanks for the patch, it worked fine for me. I am facing one more problem now. I am setting boot_on flag in the constraints structure for all my regulators as they are enabled when the system is powered on. But still when I call regulator_disable() after doing a _get() on it, the call fails saying unbalanced disables for supply. Then I checked the same repository again and found commit 38db9f31d6dc6147b87692b3b5a8a32de1a6cbe6 (regulator: Allow boot_on regulators to be disabled by clients). But still, it is not allowing me to disable the regulator as soon as I do a get on it. Later, I found out that in set_machine_constraints(),ops-enable() is being called if the boot_on flag is set. What is the purpose of doing this? Since the regulator is already enabled, why we are calling the ops-enable() to do the same again? In my opinion, regulator_enable() should have been called to let the framework increase its usage count so that the user can disable the same as and when required. Thanks and Regards, Anuj Aggarwal -Original Message- From: Mark Brown [mailto:broo...@sirena.org.uk] Sent: Thursday, February 26, 2009 7:35 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org Subject: Re: Problems while designing TPS65023 regulator driver On Thu, Feb 26, 2009 at 02:41:54PM +0530, Aggarwal, Anuj wrote: Since all the five regulators can be controlled using a single i2c device, I made a single i2c_board_info structure in my platform specific file and put all the regulator_init_data information there: This is very common - most of the devices that have multiple regulators also have some other subsystems on them (eg, an RTC or a watchdog) and use a core driver in drivers/mfd with the individual functions of the device as child platform drivers so this hasn't come up much. Now, the problem is in the tps_65023_probe function. Since it will be called only once as there is only one i2c device, I have to register all the regulators in that only. But I am not able to communicate the same to the regulator core layer. Inside the regulator_register(), variable init_data, which equals to dev-platform_data, is always pointing to the first array member, which is coming from the evm specific file. And it fails to register my second regulator instance, set_consumer_device_supply() specifically failing for the second iteration. Because of this, the probe function fails. How should I handle this scenario? Am I missing something in my implementation? Use -next or the regulator git at: git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6 There the init data is passed as a parameter to regulator_register() rather than being read from the platform data so the problem goes away. The relevant commit is 8ec143c801ff0514ce92e69aa2f7bd48e73b9baa. [Please fix your mail client to wrap at 80 columns - currently you have no line breaks in paragraphs which makes your mails a bit hard to read and reply to.] -- 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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Eero Nurkkala Sent: Thursday, March 05, 2009 10:46 AM To: ext Paul Walmsley Cc: linux-omap@vger.kernel.org; Woodruff, Richard Subject: Re: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY On Thu, 2009-03-05 at 09:42 +0100, ext Paul Walmsley wrote: Hello Eero, Hmm. Looking at the 34xx Rev O TRM register tables, it looks like most modules use bit 9 to indicate that FCLK should be kept on and bit 8 to indicate that the ICLK should be kept on? DSI, DISPC, SR, DMA4 are some examples. How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite for I2C than what's said in Table 18-44: I2C_SYSC!! Yep, that does look nuts :(.. Have pinged internally.. Regards, Nishanth Menon -- 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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
On Thu, 2009-03-05 at 13:29 +0100, ext Menon, Nishanth wrote: Yep, that does look nuts :(.. Have pinged internally.. Regards, Nishanth Menon Thank you! Could you please consider taking a loot at every single block (SPI, I2C, DMA... etc). If I were you, I'd copy-paste the CLOCKACTIVITY features as is it to every single HW block. So it'd be coherent. I have a distant feeling that's what you've done, but TRM says something else.. - Eero -- 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: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY
-Original Message- From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com] Sent: Thursday, March 05, 2009 2:33 PM To: Menon, Nishanth Cc: ext Paul Walmsley; linux-omap@vger.kernel.org; Woodruff, Richard Subject: RE: [RFC] OMAP: I2C: Use correct bit for CLOCKACTIVITY Thank you! Could you please consider taking a loot at every single block (SPI, I2C, DMA... etc). If I were you, I'd copy-paste the CLOCKACTIVITY features as is it to every single HW block. So it'd be coherent. I have a distant feeling that's what you've done, but TRM says something else.. me? I am just a code junkie ;).. They wont let me write the TRM :(.. :D... Anyways, I am told internally that the right setting is the one given in table 18-44, i.e.: 9:8 CLOCKACTIVITY Clock Activity selection bits RW 0x0 0x0: Both clocks can be cut off 0x1: Only interface clock must be kept active; functional clock can be cut off 0x2: Only functional clock must be kept active; interface clock can be cut off 0x3: Both clocks must be kept active Have asked for the rest too.. But I am told that in case of these kind of issues, we should refer to the one in the register settings. Regards, Nishanth Menon -- 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 0/5] DSPBRIDGE: patches.
Hi Ameya, Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- The Bridge patches will be based on omapzoom tree. Thank you, Best regards, Hari -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ameya Palande Sent: Thursday, March 05, 2009 4:27 AM To: Guzman Lugo, Fernando Cc: Hiroshi DOYU; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] DSPBRIDGE: patches. On Tue, Mar 3, 2009 at 2:00 AM, Guzman Lugo, Fernando x0095...@ti.com wrote: Hi, I am sending my patches again, now they are base on this commit: commit bacaa3dc169e11488faf17519a42c4e8641fc17e Author: Hiroshi DOYU hiroshi.d...@nokia.com Date: Mon Feb 16 10:43:15 2009 +0200 TIDSPBRIDGE: fix some build warnings I hope there will be not problems this time. Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- 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: [PATCH 0/5] DSPBRIDGE: patches.
On Thu, Mar 5, 2009 at 3:18 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Hi Ameya, Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- The Bridge patches will be based on omapzoom tree. We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. -- Felipe Contreras -- 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: [pacth] I2C bug fixes for L-O and L-Z
Hello, Woodruff, Richard wrote: Recently one custom board was having some I2C issues. In looking at it a couple things stood out. I've attached a patches for l-o and l-z for anyone to comment on which cares. I hope these fixes are not ignored. Maybe they should be resent as they are missing from patchwork and there's some formatting issues. A. -- 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 0/5] DSPBRIDGE: patches.
Hi Felipe, We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2. 6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. -- I am sorry, as of now the Bridge patches will be based only on omapzoom tree. Thank you, Best regards, Hari -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Thursday, March 05, 2009 7:42 AM To: Kanigeri, Hari Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/5] DSPBRIDGE: patches. On Thu, Mar 5, 2009 at 3:18 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Hi Ameya, Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- The Bridge patches will be based on omapzoom tree. We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2. 6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. -- Felipe Contreras -- 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 0/5] DSPBRIDGE: patches.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Felipe Contreras
Sent: Thursday, March 05, 2009 3:42 PM
To: Kanigeri, Hari
Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 0/5] DSPBRIDGE: patches.
On Thu, Mar 5, 2009 at 3:18 PM, Kanigeri, Hari h-kanige...@ti.com wrote:
Hi Ameya,
Hi Fernando,
Are you using tidspbridge-pm branch from
http://gitorious.org/projects/lk/repos/mainline ?
Cheers,
Ameya.
-- The Bridge patches will be based on omapzoom tree.
We are in linux-omap, not omapzoom, and this is the tidspbridge branch
in linux-omap:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
2.6.git;a=shortlog;h=tidspbridge
I'm sure you don't want to increase the discrepancy between linux-omap
and omapzoom, so the patches sent to l-o should apply on top of the
l-o tidspbridge in order to be merged.
Yeah it gets real confusing. How about following the same rules for the
OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes:
Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah.
Helps to keep things in perspective..
Regards,
Nishanth Menon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
[PATCH] I2C: Call request_irq with IRQF_DISABLED
I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
(and thus LOCKDEP) are disabled.
Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
but IRQF_DISABLED is needed for proper behaviour.
Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0c3ed41..18af43f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev)
omap_i2c_init(dev);
isr = (dev-rev OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
- r = request_irq(dev-irq, isr, 0, pdev-name, dev);
+ r = request_irq(dev-irq, isr, IRQF_DISABLED, pdev-name, dev);
if (r) {
dev_err(dev-dev, failure requesting irq %i\n, dev-irq);
--
1.5.6.5
--
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 0/5] DSPBRIDGE: patches.
Nishant, Yeah it gets real confusing. How about following the same rules for the OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes: Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah. -- I agree with your suggestion. The subject should have OMAPZOOM to differentiate. Thank you, Best regards, Hari -Original Message- From: Menon, Nishanth Sent: Thursday, March 05, 2009 7:52 AM To: Felipe Contreras; Kanigeri, Hari Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux-omap@vger.kernel.org Subject: RE: [PATCH 0/5] DSPBRIDGE: patches. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Thursday, March 05, 2009 3:42 PM To: Kanigeri, Hari Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux- o...@vger.kernel.org Subject: Re: [PATCH 0/5] DSPBRIDGE: patches. On Thu, Mar 5, 2009 at 3:18 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Hi Ameya, Hi Fernando, Are you using tidspbridge-pm branch from http://gitorious.org/projects/lk/repos/mainline ? Cheers, Ameya. -- The Bridge patches will be based on omapzoom tree. We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- 2.6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. Yeah it gets real confusing. How about following the same rules for the OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes: Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah. Helps to keep things in perspective.. Regards, Nishanth Menon -- 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 0/5] DSPBRIDGE: patches.
Hi Hari, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari Sent: Thursday, March 05, 2009 3:52 PM To: Felipe Contreras Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux- o...@vger.kernel.org Subject: RE: [PATCH 0/5] DSPBRIDGE: patches. We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2. 6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. -- I am sorry, as of now the Bridge patches will be based only on omapzoom tree. Ok, so we have: a) omapzoom bridge b) linux omap bridge Impertinent question: what are our plans b/w these two? Regards, Nishanth Menon -- 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 0/5] DSPBRIDGE: patches.
On Thu, Mar 5, 2009 at 3:56 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Nishant, Yeah it gets real confusing. How about following the same rules for the OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes: Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah. -- I agree with your suggestion. The subject should have OMAPZOOM to differentiate. Nishanth has kindly explained me that this patch, sent to the l-o mailing list, is not meant for the l-o tree. A better way to differentiate patches specific for o-z is to send them to the o-z mailing list, instead of l-o, right? Tony: Or have you agreed with TI that these [OMAPZOOM] patches that don't apply on top of l-o are ok here? -- Felipe Contreras -- 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 9/9] omap34xxcam: Add camera driver
Alexey Klimov wrote:
+static int vidioc_g_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ f-fmt.pix = vdev-pix;
+ mutex_unlock(vdev-mutex);
H, you are using mutex_lock to lock reading from vdev structure..
Well, i don't if this is right approach. I am used to that mutex_lock is
used to prevent _changing_ of members in structure..
The vdev-mutex is acquired since we want to prevent concurrent access
to vdev-pix. Otherwise it might change while we are reading it, right?
+static int vidioc_s_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+ struct v4l2_pix_format pix_tmp;
+ struct v4l2_fract timeperframe;
+ int rval;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ if (vdev-streaming) {
+ rval = -EBUSY;
+ goto out;
+ }
Well, why don't remove goto, place return -EBUSY, and move mutex after
if (vdev-streaming) check ?
The streaming state may change in the meantime. See vidioc_streamon.
It's not very likely but possible as far as I understand.
+static int vidioc_reqbufs(struct file *file, void *fh,
+ struct v4l2_requestbuffers *b)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+ int rval;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ if (vdev-streaming) {
+ mutex_unlock(vdev-mutex);
+ return -EBUSY;
+ }
If i'm doing this i prefer to place mutex_lock after this
if(vdev-streaming) check.
Same here.
+static int omap34xxcam_device_register(struct v4l2_int_device *s)
+{
+ struct omap34xxcam_videodev *vdev = s-u.slave-master-priv;
+ struct omap34xxcam_hw_config hwc;
+ int rval;
+
+ /* We need to check rval just once. The place is here. */
I didn't understand this comment. You doing nothin in next few lines
with int variable rval(which introduced in this function). Is comment
talking about struct v4l2_int_device *s ?
Yes. If the g_priv() succeeds now it will succeed in future, too. This
comes from the platform data through the slave device.
+ /* Are we the first slave? */
+ if (vdev-slaves == 1) {
+ /* initialize the video_device struct */
+ vdev-vfd = video_device_alloc();
+ if (!vdev-vfd) {
+ dev_err(vdev-vfd-dev,
+ could not allocate video device struct\n);
Do i understand you code in right way ?
You call video_device_alloc() to get vdev-vfd. Then if vdev-vfd is
null(empty) you make message dev_err which based on vdev-vfd-dev but
dev-vfd allocating is failed.. If i'm not wrong you message will
provide kernel oops.
One more point here is that you use dev_err(vdev-vfd-dev before call
to video_device_alloc() in this function.
Indeed. Others hit this already. Thanks.
+static int __init omap34xxcam_init(void)
+{
+ struct omap34xxcam_device *cam;
+ int i;
+
+ cam = kzalloc(sizeof(*cam), GFP_KERNEL);
+ if (!cam) {
+ printk(KERN_ERR %s: could not allocate memory\n, __func__);
+ goto err;
If kzalloc failed you return -ENODEV; but this is ENOMEM error.
Yes. Will fix.
Thanks again for the comments.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
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] OMAP3: Fixed crash bug with serial + suspend
It was possible for an unhandled interrupt to occur if there was incoming
serial traffic during wakeup from suspend. This was caused by the code
in arch-arm/mach-omap2/serial.c keeping interrupt enabled all the time,
but not acking its interrupts. Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 15 +++
arch/arm/mach-omap2/serial.c | 14 ++
arch/arm/plat-omap/include/mach/serial.h |1 +
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9102cee..5a627db 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -629,7 +629,22 @@ static void omap3_pm_finish(void)
pm_idle = saved_idle;
}
+/* Hooks to enable / disable UART interrupts during suspend */
+static int omap3_pm_begin(suspend_state_t state)
+{
+ omap_uart_enable_irqs(0);
+ return 0;
+}
+
+static void omap3_pm_end(void)
+{
+ omap_uart_enable_irqs(1);
+ return;
+}
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap3_pm_begin,
+ .end= omap3_pm_end,
.prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
.finish = omap3_pm_finish,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 90f1c67..e77567a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -432,6 +432,20 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
WARN_ON(ret);
}
+void omap_uart_enable_irqs(int enable)
+{
+ int ret;
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node) {
+ if (enable)
+ ret = request_irq(uart-p-irq, omap_uart_interrupt,
+ IRQF_SHARED, serial idle, (void *)uart);
+ else
+ free_irq(uart-p-irq, (void *)uart);
+ }
+}
+
static ssize_t sleep_timeout_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
diff --git a/arch/arm/plat-omap/include/mach/serial.h
b/arch/arm/plat-omap/include/mach/serial.h
index 8e89585..7ca1f27 100644
--- a/arch/arm/plat-omap/include/mach/serial.h
+++ b/arch/arm/plat-omap/include/mach/serial.h
@@ -47,6 +47,7 @@ extern void omap_uart_check_wakeup(void);
extern void omap_uart_prepare_suspend(void);
extern void omap_uart_prepare_idle(int num);
extern void omap_uart_resume_idle(int num);
+extern void omap_uart_enable_irqs(int enable);
#endif
#endif
--
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 0/5] DSPBRIDGE: patches.
Hi, Ok, so we have: a) omapzoom bridge b) linux omap bridge Impertinent question: what are our plans b/w these two? A. omapzoom bridge -- As far as I know, this will be the master tree for the DSPBridge code. The Bridge patches will be based on this tree. I think it was already communicated some time ago that the linux-omap mailing list will be used for Bridge discussions and for sending the Bridge patches to OMAPZOOM. There is no separate mailing list for omapzoom. B. linux omap bridge -- I think this tree is maintained by Hiroshi by merging the patches that are sent to OMAPZOOM tree. The only difference that should be between the omapzoom tree and linux omap tree is the Power management. Omapzoom Bridge uses T.I Power management, where as the linux omap Bridge uses open source Power management. So, any patches related to open source power manaegment will be based on linux omap tree. The maintainer of linux omap Bridge tree should sync up the Bridge changes from the omapzoom tree. Thank you, Best regards, Hari -Original Message- From: Menon, Nishanth Sent: Thursday, March 05, 2009 8:05 AM To: Kanigeri, Hari; Felipe Contreras Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux-omap@vger.kernel.org Subject: RE: [PATCH 0/5] DSPBRIDGE: patches. Hi Hari, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari Sent: Thursday, March 05, 2009 3:52 PM To: Felipe Contreras Cc: Ameya Palande; Guzman Lugo, Fernando; Hiroshi DOYU; linux- o...@vger.kernel.org Subject: RE: [PATCH 0/5] DSPBRIDGE: patches. We are in linux-omap, not omapzoom, and this is the tidspbridge branch in linux-omap: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2. 6.git;a=shortlog;h=tidspbridge I'm sure you don't want to increase the discrepancy between linux-omap and omapzoom, so the patches sent to l-o should apply on top of the l-o tidspbridge in order to be merged. -- I am sorry, as of now the Bridge patches will be based only on omapzoom tree. Ok, so we have: a) omapzoom bridge b) linux omap bridge Impertinent question: what are our plans b/w these two? Regards, Nishanth Menon -- 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
where is struct constraint_id defined?
I am trying to build the OMAP3 graphics kernel module against
2.6.29-rc7-omap1 (from GIT), and have been running into problems getting
it to build.
Two problems were pretty easy: the TI code was including asm/resource.h
and asm/semaphore.h rather than linux/resource.h and
linux/semaphore.h.
Having made those changes, it builds all the way through to the TI
supplied sysutils_linux.c, which barfs with :
In file included from
/space/src/OMAP35x_Graphics_SDC_3_00_00_06/GFX_Linux_KM/services4/srvkm/env/linux/kbuild/../../../../../services4/system/omap3430/sysutils.c:28:
/space/src/OMAP35x_Graphics_SDC_3_00_00_06/GFX_Linux_KM/services4/srvkm/env/linux/kbuild/../../../../../services4/system/omap3430/sysutils_linux.c:154:
error: variable 'cnstr_id_vdd2' has initializer but incomplete type
(and many other errors).
The problem line of the code is:
static struct constraint_id cnstr_id_vdd2 = {
and I cannot find a definition of struct constraint_id anywhere in the
kernel.
Has this been renamed, or moved, or am I looking in the wrong place?
--
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 0/5] DSPBRIDGE: patches.
* Felipe Contreras felipe.contre...@gmail.com [090305 06:06]: On Thu, Mar 5, 2009 at 3:56 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Nishant, Yeah it gets real confusing. How about following the same rules for the OMAPZOOM kernel here too: any patch w.r.t OMAPZOOM comes: Subj: RE: [OMAPZOOM PATCH 0/5] DSPBRIDGE: blah blah blah. -- I agree with your suggestion. The subject should have OMAPZOOM to differentiate. Nishanth has kindly explained me that this patch, sent to the l-o mailing list, is not meant for the l-o tree. A better way to differentiate patches specific for o-z is to send them to the o-z mailing list, instead of l-o, right? Tony: Or have you agreed with TI that these [OMAPZOOM] patches that don't apply on top of l-o are ok here? Well as long as they're clearly tagged as OMAPZOOM, things don't get too confusing, so I'm OK with that. But in general I'm worried as it looks like the zoom tree is just piling up more and more hacks and ifdefs with no serious attempt to merge that code upstream. Everybody, we need to get the infrastructure pieces done properly and into the mainline tree so we can use that for all our omap needs. Sure some board specific hacks will be still needed here and there, and tons of the omap and driver patches already apply against the mainline kernel code. It's up to each developer to submit their patches through the right mailing lists to the mainline kernel. Piling up code into some other trees only increases the diff against the mainline tree. Everybody, when you see a piece of omap code that's not in the mainline kernel yet, whine and complain until the code gets integrated. 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 3/7] ARM: OMAP: Add command line option for I2C bus speed
* Tony Lindgren t...@atomide.com [090304 13:51]:
From: Jarkko Nikula jarkko.nik...@nokia.com
This patch adds a new command line option i2c_bus=bus_id,clkrate into
I2C bus registration helper. Purpose of the option is to override the
default board specific bus speed which is supplied by the
omap_register_i2c_bus.
The default bus speed is typically set to speed of slowest I2C chip on the
bus and overriding allow to use some experimental configurations or updated
chip versions without any kernel modifications.
Jarkko, this should also be in Documentation/kernel-parameters.txt. Can
you please reply with a patch for that, and I'll fold it into this
patch?
Also, maybe it should be called omap_i2c_bus instead of i2c_bus?
Regards,
Tony
Signed-off-by: Jarkko Nikula jarkko.nik...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/i2c.c | 54
+-
1 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 3e95954..aa70e43 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -119,6 +119,46 @@ static void __init omap_i2c_mux_pins(int bus)
omap_cfg_reg(scl);
}
+static int __init omap_i2c_nr_ports(void)
+{
+ int ports = 0;
+
+ if (cpu_class_is_omap1())
+ ports = 1;
+ else if (cpu_is_omap24xx())
+ ports = 2;
+ else if (cpu_is_omap34xx())
+ ports = 3;
+
+ return ports;
+}
+
+/**
+ * omap_i2c_bus_setup - Process command line options for the I2C bus speed
+ * @str: String of options
+ *
+ * This function allow to override the default I2C bus speed for given I2C
+ * bus with a command line option.
+ *
+ * Format: i2c_bus=bus_id,clkrate (in kHz)
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int __init omap_i2c_bus_setup(char *str)
+{
+ int ports;
+ int ints[3];
+
+ ports = omap_i2c_nr_ports();
+ get_options(str, 3, ints);
+ if (ints[0] 2 || ints[1] 1 || ints[1] ports)
+ return 0;
+ i2c_rate[ints[1] - 1] = ints[2];
+
+ return 1;
+}
+__setup(i2c_bus=, omap_i2c_bus_setup);
+
/**
* omap_register_i2c_bus - register I2C bus with device descriptors
* @bus_id: bus id counting from number 1
@@ -132,19 +172,12 @@ int __init omap_register_i2c_bus(int bus_id, u32
clkrate,
struct i2c_board_info const *info,
unsigned len)
{
- int ports, err;
+ int err;
struct platform_device *pdev;
struct resource *res;
resource_size_t base, irq;
- if (cpu_class_is_omap1())
- ports = 1;
- else if (cpu_is_omap24xx())
- ports = 2;
- else if (cpu_is_omap34xx())
- ports = 3;
-
- BUG_ON(bus_id 1 || bus_id ports);
+ BUG_ON(bus_id 1 || bus_id omap_i2c_nr_ports());
if (info) {
err = i2c_register_board_info(bus_id, info, len);
@@ -153,7 +186,8 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
}
pdev = omap_i2c_devices[bus_id - 1];
- *(u32 *)pdev-dev.platform_data = clkrate;
+ if (i2c_rate[bus_id - 1] == 0)
+ i2c_rate[bus_id - 1] = clkrate;
if (bus_id == 1) {
res = pdev-resource;
--
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
Embedded Linux Conference
Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. Regards, 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 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? -- 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: Fixed crash bug with serial + suspend
Tero Kristo tero.kri...@nokia.com writes:
It was possible for an unhandled interrupt to occur if there was incoming
serial traffic during wakeup from suspend. This was caused by the code
in arch-arm/mach-omap2/serial.c keeping interrupt enabled all the time,
but not acking its interrupts. Applies on top of PM branch.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Thanks, pushed to PM branch.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 15 +++
arch/arm/mach-omap2/serial.c | 14 ++
arch/arm/plat-omap/include/mach/serial.h |1 +
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9102cee..5a627db 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -629,7 +629,22 @@ static void omap3_pm_finish(void)
pm_idle = saved_idle;
}
+/* Hooks to enable / disable UART interrupts during suspend */
+static int omap3_pm_begin(suspend_state_t state)
+{
+ omap_uart_enable_irqs(0);
+ return 0;
+}
+
+static void omap3_pm_end(void)
+{
+ omap_uart_enable_irqs(1);
+ return;
+}
+
static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap3_pm_begin,
+ .end= omap3_pm_end,
.prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
.finish = omap3_pm_finish,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 90f1c67..e77567a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -432,6 +432,20 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
WARN_ON(ret);
}
+void omap_uart_enable_irqs(int enable)
+{
+ int ret;
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node) {
+ if (enable)
+ ret = request_irq(uart-p-irq, omap_uart_interrupt,
+ IRQF_SHARED, serial idle, (void *)uart);
+ else
+ free_irq(uart-p-irq, (void *)uart);
+ }
+}
+
static ssize_t sleep_timeout_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
diff --git a/arch/arm/plat-omap/include/mach/serial.h
b/arch/arm/plat-omap/include/mach/serial.h
index 8e89585..7ca1f27 100644
--- a/arch/arm/plat-omap/include/mach/serial.h
+++ b/arch/arm/plat-omap/include/mach/serial.h
@@ -47,6 +47,7 @@ extern void omap_uart_check_wakeup(void);
extern void omap_uart_prepare_suspend(void);
extern void omap_uart_prepare_idle(int num);
extern void omap_uart_resume_idle(int num);
+extern void omap_uart_enable_irqs(int enable);
#endif
#endif
--
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
--
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 2/2] ASoC: Add headset jack detection for SDP3430 machine driver
Add headset jack detection for SDP3430 boards using SoC jack
reporting interface. Headset detection on SDP3430 board is
achieved through TWL4030 GPIO_2 pin.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/omap/sdp3430.c | 43 +--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index 4eab4b4..715c648 100644
--- a/sound/soc/omap/sdp3430.c
+++ b/sound/soc/omap/sdp3430.c
@@ -28,6 +28,7 @@
#include sound/pcm.h
#include sound/soc.h
#include sound/soc-dapm.h
+#include sound/jack.h
#include asm/mach-types.h
#include mach/hardware.h
@@ -122,7 +123,7 @@ static int sdp3430_twl4030_init(struct snd_soc_codec *codec)
/* SDP3430 connected pins */
snd_soc_dapm_enable_pin(codec, Ext Mic);
snd_soc_dapm_enable_pin(codec, Ext Spk);
- snd_soc_dapm_enable_pin(codec, Headset Jack);
+ snd_soc_dapm_disable_pin(codec, Headset Jack);
/* TWL4030 not connected pins */
snd_soc_dapm_nc_pin(codec, AUXL);
@@ -144,6 +145,27 @@ static int sdp3430_twl4030_init(struct snd_soc_codec
*codec)
return ret;
}
+/* Headset jack */
+static struct snd_soc_jack hs_jack;
+
+/* Headset jack detection DAPM pins */
+static struct snd_soc_jack_pin hs_jack_pins[] = {
+ {
+ .pin = Headset Jack,
+ .mask = SND_JACK_HEADSET,
+ },
+};
+
+/* Headset jack detection gpios */
+static struct snd_soc_jack_gpio hs_jack_gpios[] = {
+ {
+ .gpio = (OMAP_MAX_GPIO_LINES + 2),
+ .name = hsdet-gpio,
+ .report = SND_JACK_HEADSET,
+ .debounce_time = 200,
+ },
+};
+
/* Digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link sdp3430_dai = {
.name = TWL4030,
@@ -194,7 +216,21 @@ static int __init sdp3430_soc_init(void)
if (ret)
goto err1;
- return 0;
+ /* Headset jack detection */
+ ret = snd_soc_jack_new(snd_soc_sdp3430, SDP3430 headset jack,
+ SND_JACK_HEADSET, hs_jack);
+ if (ret)
+ return ret;
+
+ ret = snd_soc_jack_add_pins(hs_jack, ARRAY_SIZE(hs_jack_pins),
+ hs_jack_pins);
+ if (ret)
+ return ret;
+
+ ret = snd_soc_jack_add_gpios(hs_jack, ARRAY_SIZE(hs_jack_gpios),
+ hs_jack_gpios);
+
+ return ret;
err1:
printk(KERN_ERR Unable to add platform device\n);
@@ -206,6 +242,9 @@ module_init(sdp3430_soc_init);
static void __exit sdp3430_soc_exit(void)
{
+ snd_soc_jack_free_gpios(hs_jack, ARRAY_SIZE(hs_jack_gpios),
+ hs_jack_gpios);
+
platform_device_unregister(sdp3430_snd_device);
}
module_exit(sdp3430_soc_exit);
--
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
[PATCH] input: twl4030-pwrbutton: avoid merge conflicts
sync up with the version going upstream.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
This patch is syncing with the fixed up version accepted in
mainline. Should be applied to avoid merge conflicts
on the next merge window.
drivers/input/misc/Kconfig |6 ++
drivers/input/misc/twl4030-pwrbutton.c | 87
2 files changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 9667b50..6fa9e38 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -196,6 +196,12 @@ config INPUT_CM109
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
+ help
+ Say Y here if you want to enable power key reporting via the
+ TWL4030 family of chips.
+
+ To compile this driver as a module, choose M here. The module will
+ be called twl4030_pwrbutton.
config INPUT_UINPUT
tristate User level driver support
diff --git a/drivers/input/misc/twl4030-pwrbutton.c
b/drivers/input/misc/twl4030-pwrbutton.c
index b0a9c9f..7150830 100644
--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -1,11 +1,10 @@
/**
- * drivers/i2c/chips/twl4030-pwrbutton.c
+ * twl4030-pwrbutton.c - TWL4030 Power Button Input Driver
*
- * Driver for sending triton2 power button event to input-layer
- *
- * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2008-2009 Nokia Corporation
*
* Written by Peter De Schrijver peter.de-schrij...@nokia.com
+ * Several fixes by Felipe Balbi felipe.ba...@nokia.com
*
* This file is subject to the terms and conditions of the GNU General
* Public License. See the file COPYING in the main directory of this
@@ -34,18 +33,18 @@
#define STS_HW_CONDITIONS 0xf
-static struct input_dev *powerbutton_dev;
-static struct device *dbg_dev;
-
-static irqreturn_t powerbutton_irq(int irq, void *dev_id)
+static irqreturn_t powerbutton_irq(int irq, void *_pwr)
{
+ struct input_dev *pwr = _pwr;
int err;
u8 value;
#ifdef CONFIG_LOCKDEP
/* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
-* we don't want and can't tolerate. Although it might be
-* friendlier not to borrow this thread context...
+* we don't want and can't tolerate since this is a threaded
+* IRQ and can sleep due to the i2c reads it has to issue.
+* Although it might be friendlier not to borrow this thread
+* context...
*/
local_irq_enable();
#endif
@@ -53,11 +52,11 @@ static irqreturn_t powerbutton_irq(int irq, void *dev_id)
err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_MASTER, value,
STS_HW_CONDITIONS);
if (!err) {
- input_report_key(powerbutton_dev, KEY_POWER,
-value PWR_PWRON_IRQ);
+ input_report_key(pwr, KEY_POWER, value PWR_PWRON_IRQ);
+ input_sync(pwr);
} else {
- dev_err(dbg_dev, twl4030: i2c error %d while reading TWL4030
-PM_MASTER STS_HW_CONDITIONS register\n, err);
+ dev_err(pwr-dev.parent, twl4030: i2c error %d while reading
+TWL4030 PM_MASTER STS_HW_CONDITIONS register\n, err);
}
return IRQ_HANDLED;
@@ -65,66 +64,64 @@ static irqreturn_t powerbutton_irq(int irq, void *dev_id)
static int __devinit twl4030_pwrbutton_probe(struct platform_device *pdev)
{
- int err = 0;
+ struct input_dev *pwr;
int irq = platform_get_irq(pdev, 0);
+ int err;
- dbg_dev = pdev-dev;
+ pwr = input_allocate_device();
+ if (!pwr) {
+ dev_dbg(pdev-dev, Can't allocate power button\n);
+ err = -ENOMEM;
+ goto out;
+ }
- /* PWRBTN == PWRON */
err = request_irq(irq, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
- twl4030-pwrbutton, NULL);
+ twl4030_pwrbutton, pwr);
if (err 0) {
- dev_dbg(pdev-dev, Can't get IRQ for power button: %d\n,
err);
- goto out;
- }
-
- powerbutton_dev = input_allocate_device();
- if (!powerbutton_dev) {
- dev_dbg(pdev-dev, Can't allocate power button\n);
- err = -ENOMEM;
- goto free_irq_and_out;
+ dev_dbg(pdev-dev, Can't get IRQ for pwrbutton: %d\n, err);
+ goto free_input_dev;
}
- powerbutton_dev-evbit[0] = BIT_MASK(EV_KEY);
- powerbutton_dev-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
- powerbutton_dev-name = triton2-pwrbutton;
+ pwr-evbit[0] = BIT_MASK(EV_KEY);
+ pwr-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ pwr-name = twl4030_pwrbutton;
+ pwr-phys =
Re: [PATCH] I2C: Call request_irq with IRQF_DISABLED
On Thu, Mar 05, 2009 at 03:54:24PM +0200, Ari Kauppi wrote: I have observed some Spurious IRQ's for I2C1 when all kernel hacking options (and thus LOCKDEP) are disabled. Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help but IRQF_DISABLED is needed for proper behaviour. Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com This driver should be in sync with mainline, the only missing commit is commit 3487568e15df6e133f5f55779dec614dbeb68a99 Author: Eero Nurkkala ext-eero.nurkk...@nokia.com Date: Tue Nov 25 13:03:46 2008 +0200 i2c: i2c-omap: Fix BUFSTAT_REG reading The number of bytes to be received is read from wrong place with all OMAPs with highspeed I2C support, which involves a FIFO and BUFSTAT_REG. It is the 6 bits starting from the bit 8 in the BUFSTAT_REG that indicate this amount of bytes to be read. Moreover, only the 6 LSB:s are relevant for the TXSTAT field. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com That and this one should be going via linux-i2c mainling list. Could you send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please keep linux-omap in the loop. That said, this makes sense and avoids that we get interrupts while handling a previous interrupt. Acked-by: Felipe Balbi felipe.ba...@nokia.com -- balbi -- 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 3/7] ARM: OMAP: Add command line option for I2C bus speed
On Thu, Mar 05, 2009 at 08:20:43AM -0800, Tony Lindgren wrote: Also, maybe it should be called omap_i2c_bus instead of i2c_bus? or maybe not, then other archs would have the opportunity to setup their own function to handle i2c_bus= cmdline without having to add a brand new arch_i2c_bus one ;-) -- balbi -- 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] I2C: Call request_irq with IRQF_DISABLED
On Thu, 5 Mar 2009 21:35:06 +0200, Felipe Balbi wrote: That and this one should be going via linux-i2c mainling list. Could you send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please keep linux-omap in the loop. Come on, folks, how many times will I have to repeat myself and what MAINTAINERS says? Patches to i2c-omap and every other i2c driver for embedded platforms go to Ben Dooks (Cc'd), not me. -- Jean Delvare -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: Situation 1 - Instance1: Select sensor 1, and Do queue/dequeue of buffers. - Instance2: If sensor 1 is currently selected, Begin loop requesting internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs) for performing user-side Auto-exposure, Auto White Balance, Auto Focus algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a result. Question: if you have multiple sensors, and sensor 1 is selected, can you still get statistics from sensor 2? Or is all this still limited to the selected sensor? Just want to make sure I understand it all. The ISP does have submodules and there are some ways of configuring the data path inside the ISP, but in general just one sensor can be used at a time in meaningful way. Sergio, please correct me if I'm wrong: the only case I know that you can do is to use the ISP normally (data flowing through pretty much all the ISP modules) with one sensor and write the output of another sensor directly to memory in one of the parallel/CCP2/CSI2 receivers. I guess there's no use case for this, however. So just one user at a time for the OMAP 3 ISP. Another thing comes to my mind, though. Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. That is probably what the driver should do, yes. The V4L2 spec leaves it up to the driver whether you can switch inputs while a capture is in progress. In this case I think it is perfectly reasonably for the driver to return -EBUSY. Ok. I'm not clear if this single-node idea is really helping the user to have a simpler usage in Situation 1, which I feel will become pretty common on this driver... The spec is pretty clear about this, and existing v4l2 applications also expect this behavior. Also, suppose you have two video nodes, what happens when you want to use the inactive node? How can you tell it is inactive? open() succeeds. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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] I2C: Call request_irq with IRQF_DISABLED
On Thu, Mar 05, 2009 at 09:03:35PM +0100, Jean Delvare wrote: On Thu, 5 Mar 2009 21:35:06 +0200, Felipe Balbi wrote: That and this one should be going via linux-i2c mainling list. Could you send Eero's patch and yours to Jean Delvare (i2c maintainer) ? Please keep linux-omap in the loop. Come on, folks, how many times will I have to repeat myself and what MAINTAINERS says? Patches to i2c-omap and every other i2c driver for embedded platforms go to Ben Dooks (Cc'd), not me. that was my bad, I didn't see Ben was already in Cc. -- balbi -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Thursday 05 March 2009 21:11:02 Sakari Ailus wrote: Hans Verkuil wrote: Situation 1 - Instance1: Select sensor 1, and Do queue/dequeue of buffers. - Instance2: If sensor 1 is currently selected, Begin loop requesting internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs) for performing user-side Auto-exposure, Auto White Balance, Auto Focus algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a result. Question: if you have multiple sensors, and sensor 1 is selected, can you still get statistics from sensor 2? Or is all this still limited to the selected sensor? Just want to make sure I understand it all. The ISP does have submodules and there are some ways of configuring the data path inside the ISP, but in general just one sensor can be used at a time in meaningful way. Sergio, please correct me if I'm wrong: the only case I know that you can do is to use the ISP normally (data flowing through pretty much all the ISP modules) with one sensor and write the output of another sensor directly to memory in one of the parallel/CCP2/CSI2 receivers. I guess there's no use case for this, however. So just one user at a time for the OMAP 3 ISP. Another thing comes to my mind, though. Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. This sounds like a codec interface as 'described' here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC It would be a first for V4L2 to have a driver that can do this, but I agree that that would be a single device that has both 'output' and 'capture'. That is probably what the driver should do, yes. The V4L2 spec leaves it up to the driver whether you can switch inputs while a capture is in progress. In this case I think it is perfectly reasonably for the driver to return -EBUSY. Ok. I'm not clear if this single-node idea is really helping the user to have a simpler usage in Situation 1, which I feel will become pretty common on this driver... The spec is pretty clear about this, and existing v4l2 applications also expect this behavior. Also, suppose you have two video nodes, what happens when you want to use the inactive node? How can you tell it is inactive? open() succeeds. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? Oh dear. Please don't use 'use counts'. It is perfectly acceptable and desirable to have multiple opens on the same video node. Only one file handle can do reading/writing/streaming, but others should be able to querying controls, set brightness, or whatever at the same time. Use counts are really bad and totally unnecessary. Only if another file handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it make sense to return -EBUSY for certain ioctls or read/write operations. Otherwise you shouldn't limit the user from opening the same device node as many times as he wants and use that to query the video device. There are unfortunately a whole bunch of existing v4l2 drivers that have this same limitation. These drivers are wrong. It is sadly not very easy to fix them, but I can try to prevent the same bug from appearing in new drivers. BTW, I looked at omap24xxcam_open(): data like fh-pix does *not* belong to the filehandle struct, it should be part of the top-level data structure. You want to be able to do simple things like querying a video node for the currently selected format. You can't do that if the format is stored in the filehandle! E.g.: you are streaming and you want to run v4l2-ctl --get-fmt-video to check what video format is being used. Things like this must be supported by a well-written v4l2 driver. Again, sadly quite a few v4l2 drivers do this wrong as well :-( I also see that cam-users is not decreased by one if omap24xxcam_sensor_enable() fails. Note that I'm looking at the code in the v4l-dvb repository, the linux-omap git tree might have fixed that already. Regards, Hans
RE: omap3 cpuidle interrupt latency
-Original Message- From: Premi, Sanjeev Sent: Wednesday, March 04, 2009 7:52 PM To: Premi, Sanjeev; Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: RE: omap3 cpuidle interrupt latency -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, March 03, 2009 3:54 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: RE: omap3 cpuidle interrupt latency -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, March 03, 2009 1:16 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: omap3 cpuidle interrupt latency Premi, Sanjeev pr...@ti.com writes: I have noticed large interrupt latency when the cpuidle is enabled. e.g. response time for ping goes from avg 10-20ms to 800-1000ms. (I am at HEAD of the 'pm' branch) Is it interrupt latency in general you are measuring? or just the interrupt latency for the smc network driver. I think what you are seeing is the result of the SMC IRQ not being configured as a wakeup source, thus a network interrupt will not wake the system, but you end up waiting for the next idle timer until the system wakes and handles the network interrupt. I used SMC as an example. The read over USB is also slow... I feel there is generic latency. Initially, I was suspecting the hrtimer functions taking long time. But that may not be the case. By default, I don't believe the GPIO interrupt used by the smc is configured as a wakeup source. Have you configured that GPIO as a wakeup source? My current measurements are based with all idle related flags 'sleep_while_idle', 'clocks_off_while_idle' and 'enable_off_mode' set at 0. Does WFI require a wakeup event? Even when system is not in 'off' stare? For simple debug, I replaced the _omap_sram_idle() processing with: __asm__ (dmb); __asm__ (dsb); __asm__ (wfi); Here, again behavior was same for ethernet. For more simplification, I focused on keypad and touchscreen. 1) Let the system stay idle for about 10secs 2) Press the keypad tap the touchscreen 3) cat /proc/interrupts While the keypad interrupts (via SYS_NIRQ) are getting updated; most of the TS interrupts (via GPIO) seem to be missing; With a busy loop in the background OR _omap_sram_idle() commented - not doing WFI - changes the behavior. Each tap on the TS is registered in /proc/interrupts. On Kevin's suggestion, I tried to disable cpuidle and repeat the experiment with omap_pm_idle () - with minor mods to ensure that WFI is executed. Results was same. While the UART is active (via 5 sec timeout) all taps on the touchscreen were detected. If the system is kept idle for about 10 secs, the interrupts are lost. ~sanjeev ~sanjeev Kevin The IRQs and FIQs are disabled at the beginning of the function omap3_enter_idle() but WFI is executed much later in _omap_sram_idle(). In between, there is only one check for pending IRQs - omap_irq_pending() If any interrupt occurs beyond this point is it considered by the WFI? To reduce this latency, I am planning to do either/both of thse: - Add more checks for pending IRQs - Reduce the time for which the IRQs and FIQs are disabled Benefits will depend upon the behavior of WFI. Best regards, Sanjeev -- 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 -- 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 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hello, all On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic dcur...@ti.com wrote: Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. -- Best regards, Klimov Alexey -- 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 4/5] OMAP3430SDP: Add support for Camera Kit v3
-Original Message- From: Alexey Klimov [mailto:klimov.li...@gmail.com] Sent: Thursday, March 05, 2009 4:05 PM To: Curran, Dominic Cc: DongSoo(Nathaniel) Kim; Aguirre Rodriguez, Sergio Alberto; linux- me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. Ah, I did not know that msleep() called scheduler. Thank you. -- 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
[APPLIED] [PATCH] input: twl4030-pwrbutton: avoid merge conflicts
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 1e2ac5195c19b440b0b095262e11b54c093916ee PatchWorks http://patchwork.kernel.org/patch/10147/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=1e2ac5195c19b440b0b095262e11b54c093916ee -- 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/rft 2.6.29-rc3-omap-git] omap3 evm: MMC switch support
* David Brownell davi...@pacbell.net [090208 12:25]: On Wednesday 04 February 2009, Pillai, Manikandan wrote: I tested the patch on the OMAP 3 EVM. I still find that the hotplug feature does not work on the OMAP3 EVM. The issue is that if I read the gpio_cd, I am getting the correct value on the gpio pin(INSERT = 0, PLUGOUT = 1) but the interrupts are not generated. The mmc0 interrupts always shows 0. Are you getting any other IRQs through the twl4030 code? There's not a lot of debugging I can do with this, since I don't have an EVM ... and since this seems to work OK on other boards. (Testing on SDP being easiest, since it's got a slot not tied down with MMC root.) This patch was basically sent as a seed, since nobody else seemed to be filling in the missing MMC/SD pieces on that board. I've pushed this, looks like the mux.[ch] changes had already been applied in another patch. Tony - Dave r...@172.24.190.49:~# cat /proc/interrupts CPU0 11: 0 INTC prcm 12: 4 INTC DMA 25: 0 INTC dispc 37: 1724 INTC gp timer 56: 267 INTC i2c_omap 57: 0 INTC i2c_omap 61: 0 INTC i2c_omap 72: 178 INTC serial idle, serial 73: 1 INTC serial idle 74: 1 INTC serial idle 83: 43 INTC mmc0 92: 0 INTC musb_hdrc 93: 0 INTC musb_hdrc 335: 0 GPIO ads7846 336: 3565 GPIO eth0 369: 0 twl4030 twl4030_keypad 378: 0 twl4030 twl4030_usb 384: 0 twl4030 mmc0 Err: 0 Regards Mani -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of David Brownell Sent: Thursday, February 05, 2009 4:53 AM To: OMAP Subject: [patch/rft 2.6.29-rc3-omap-git] omap3 evm: MMC switch support Update OMAP3 EVM board support to support the MMC/SD switches, when used with the twl4030 based power card. Also, less usefully, LEDB as a GPIO LED ... it's on the underside of the board, so it's probably not very useful to most folk. The LCD backlight is controlled by LEDA though; more useful, though its PWM mode might not be practical on this board (I don't know how that inductor will affect things). This is done from schematics, so it needs testing (and maybe some bugfixes) from folk with an EVM board. -- 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: [PATCH 0/1] Group and resource assignments for TWL4030
* David Brownell davi...@pacbell.net [090303 15:38]: On Friday 27 February 2009, Tony Lindgren wrote: * Peter 'p2' De Schrijver peter.de-schrij...@nokia.com [090215 08:49]: On Fri, Feb 13, 2009 at 09:55:21PM +0100, ext David Brownell wrote: On Tuesday 10 February 2009, Peter 'p2' De Schrijver wrote: This patch introduces support for board specific group assignments of TWL4030 resources. The resource type and type2 fields can also be specified. Do we have any real examples yet of needing to assign resources to anything other than P1 (processor)? Yes. On our custom hardware we use it to assign CLKEN to P3. P3 roughly translating to system running, with no regard to whether ARM(s) or DSP are active, yes? I've seen hardware which hooks CLKEN to the enable line for a 2.8V regulator, and REGEN to the enable line for a 2.5V regulator. Table 5-8 of the chip manual tells me those, along with HFCLOCK and a few other resources, are already assigned to the P3 (and P1 and P2) groups by device reset. So that use case isn't quite complete. At least some of this look like normal paranoia, to defend against hardware and bootloader oddities. ;) I'm not sure how those should be modeled within the regulator framework. My first thought is to just let those particular resources live outside that framework, until there's a need for another solution ... the main virtue of that framework is to have a standard way for Linux to manage things, but these are resources it won't be managing. The secondary virtue of visibility into hardware isn't very compelling here IMO. BTW, this should be discussed and integrated via the driver lists, in this case that's Samuel Ortiz and LKML. Actually this is related to the twl4030-power.c driver which has not yet gone upstream. I'm not sure there'd be much point to discussing this on the PM list though. So let me suggest a slightly different approach: - Peter updates $SUBJECT patch to address the comments from me (data shrink) and Felipe (use those RES_* symbols in res_config_addrs) - Tony merges that to the OMAP tree - Peter starts work on merging twl4030-power.c to mainline (discuss on LKML etc) There will be a few more issues to sort with this driver. There are section warnings generated by some of the platform code, and the generic script doesn't work at all on Beagle. This sounds OK to me as long as Peter is fine with that. 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
[APPLIED] [PATCH] omap3: Add base address definitions and resources for OMAP
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: d0afa95d172f66e2239e38e015e8536dc78e98db PatchWorks http://patchwork.kernel.org/patch/9871/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=d0afa95d172f66e2239e38e015e8536dc78e98db -- 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] ARM: OMAP2: Fix missing system control module exports
Hi,
* George G. Davis gda...@mvista.com [090302 08:19]:
When building ASoC drivers as modules for SND_OMAP_SOC_MCBSP based
targets, the build fails because omap_ctrl_{read,write}l lack exports.
So add the missing exports for omap_ctrl_{read,write}[bwl] to allow
building these ASoC (and other) drivers as modules.
I think Paul has some comments on how the clock framework should
handle this case without needing to export the omap_ctrl_read/write.
Regards,
Tony
Signed-off-by: George G. Davis gda...@mvista.com
Acked-by: Jarkko Nikula jarkko.nik...@nokia.com
---
arch/arm/mach-omap2/control.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 5f3aad9..6b14639 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -36,29 +36,35 @@ u8 omap_ctrl_readb(u16 offset)
{
return __raw_readb(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readb);
u16 omap_ctrl_readw(u16 offset)
{
return __raw_readw(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readw);
u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
__raw_writeb(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writeb);
void omap_ctrl_writew(u16 val, u16 offset)
{
__raw_writew(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writew);
void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
--
1.6.1.2.MVISTA
--
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: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi Alexey, On Fri, Mar 6, 2009 at 7:05 AM, Alexey Klimov klimov.li...@gmail.com wrote: Hello, all On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic dcur...@ti.com wrote: Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. I totally agree with you. But besides the udelay and mdelay accuracy issue, Sergio's power up timing for MT9P012 seems to delay too much. (not for lens controller.) I also have experience using MT9P012 sensor with other ISP, but in case of mine it took 600 to 800 ms for whole power up sequence. But if that delay depends on SDP board and Sergio had no options without making delay for that much, then it explains everything. So I'm saying if there was no other option than making long delay to bring up MT9P012 sensor properly, if I were Sergio I should rather use mdelay than udelay. But if that delay is necessary to bring up MT9P012 with SDP board, I have no idea what to say. In that case, Sergio should be right. Cheers, Nate -- Best regards, Klimov Alexey -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- 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] ARM: OMAP2: Fix missing system control module exports
Hi,
On Thu, Mar 05, 2009 at 04:43:09PM -0800, Tony Lindgren wrote:
Hi,
* George G. Davis gda...@mvista.com [090302 08:19]:
When building ASoC drivers as modules for SND_OMAP_SOC_MCBSP based
targets, the build fails because omap_ctrl_{read,write}l lack exports.
So add the missing exports for omap_ctrl_{read,write}[bwl] to allow
building these ASoC (and other) drivers as modules.
I think Paul has some comments on how the clock framework should
handle this case without needing to export the omap_ctrl_read/write.
Yeah, I figured direct calls to these from drivers was just
plain wrong to begin with (preemption issues come to mind
for one), but went with the quick fix. I'm all ears on
the proper fix...
--
Regards,
George
Regards,
Tony
Signed-off-by: George G. Davis gda...@mvista.com
Acked-by: Jarkko Nikula jarkko.nik...@nokia.com
---
arch/arm/mach-omap2/control.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 5f3aad9..6b14639 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -36,29 +36,35 @@ u8 omap_ctrl_readb(u16 offset)
{
return __raw_readb(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readb);
u16 omap_ctrl_readw(u16 offset)
{
return __raw_readw(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readw);
u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
__raw_writeb(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writeb);
void omap_ctrl_writew(u16 val, u16 offset)
{
__raw_writew(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writew);
void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
--
1.6.1.2.MVISTA
--
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: Embedded Linux Conference
Hello, I'm attending as a speaker for one session which title is Digital camera framework in Linux I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil hverk...@xs4all.nl wrote: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- 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: Embedded Linux Conference
That is great! I will let you know our plans soon. -Manju -Original Message- From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com] Sent: Friday, March 06, 2009 9:33 AM To: Hans Verkuil Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Hadli, Manjunath; Aguirre Rodriguez, Sergio Alberto; Hiremath, Vaibhav Subject: Re: Embedded Linux Conference Hello, I'm attending as a speaker for one session which title is Digital camera framework in Linux I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil hverk...@xs4all.nl wrote: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- 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 3/7] ARM: OMAP: Add command line option for I2C bus speed
On Thu, 5 Mar 2009 17:20:43 +0100 ext Tony Lindgren t...@atomide.com wrote: Jarkko, this should also be in Documentation/kernel-parameters.txt. Can you please reply with a patch for that, and I'll fold it into this patch? Ah, good, will do it over weekend - early next week. Probably better to handle as a separate patch for easier merging with kernel-parameters.txt? Also, maybe it should be called omap_i2c_bus instead of i2c_bus? I had similar thought as Felipe that it looks more generic this way. But don't know now immediately would multibuild will work? Was that your concern? E.g. __setup(i2c_bus=, arm_xxx_i2c_bus_setup); __setup(i2c_bus=, omap_i2c_bus_setup); Jarkko -- 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
