On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
We don't want dpi_init() to fail in any case as it will prevent us
from using DSS2 if we don't have DSI in the system. This is because
dpi_init() is done unconditionally by
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
Panel enable/disable is now done inside display manager,
so don't need to do it again.
This looks correct, thanks.
Tomi
--
To unsubscribe from this list: send the line
On Mon, 2010-03-15 at 10:32 +0100, Tomi Valkeinen wrote:
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
Panel enable/disable is now done inside display manager,
so don't need to do it again.
This looks
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi regulator in SDI subsystem.
We can disable the vdds_sdi voltage when not in use to save
power.
Signed-off-by: Roger Quadros
Hi,
Valkeinen Tomi (Nokia-D/Helsinki) wrote:
I don't think this is quite correct. dpi_init_display() will be called
for all DPI displays, which means that it may be called more than once.
dpi_init() is meant for global initializations.
Perhaps it would be best to have DPI compiled
When the MUSB is configured as host mode or OTG mode, the xceiv-state
will be set to OTG_STATE_A_IDLE or OTG_STATE_B_IDLE unconditionally
during init process. These init states can change to other
states When the MUSB module detects id pin change, devices connect or
disconnect.
But on some
On omap2/3 series platforms, the musb can't raise id pin change
detection interrupt, so we must change otg mode through sysfs
interface manually. Currently when the musb is in B mode, if we
want musb to be changed to A mode, we should plug a mini-A cable
and then execute echo host
From: Enric Balletbo i Serra eballe...@iseebcn.com
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/mach-omap2/board-igep0020.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Hello.
Wang Hui wrote:
On omap2/3 series platforms, the musb can't raise id pin change
detection interrupt, so we must change otg mode through sysfs
interface manually. Currently when the musb is in B mode, if we
want musb to be changed to A mode, we should plug a mini-A cable
and then execute
Hi,
Valkeinen Tomi (Nokia-D/Helsinki) wrote:
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi regulator in SDI subsystem.
We can disable the vdds_sdi voltage when not in use to save
On Mon, 2010-03-15 at 12:26 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
Hi,
Valkeinen Tomi (Nokia-D/Helsinki) wrote:
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
From: Roger Quadros roger.quad...@nokia.com
This patch enables the use of vdds_sdi
On 03/14/2010 10:44 PM, Ben Gamari wrote:
Hey all,
As I've mentioned here in the past, I am currently putting together a board for
doing analog data acquisition on the BeagleBoard platform. Unfortunately, I
have wasted nearly the entire weekend trying to accomplish the (one would
think) simple
Hi all,
While trying to build kernel from master, I encounter many errors (pasted
below).
I believe the reason is missing headers - plat/resource.h and smartreflex.h
...but I couldn't find them in the tree.
premi # ls -l arch/arm/plat-omap/include/plat/res*
ls: No match.
premi # ls -l
On 03/14/2010 10:44 PM, Ben Gamari wrote:
When measuring the SIMO signal on the expansion connector with my
daughterboard
connected, I noticed that the daughterboard's level shifter appeared to be
driving the signal higher than it should, to ~2.9 Volts. I then checked the
1.8V rail voltage
On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester nforres...@whoi.edu wrote:
I'd be happy to check your circuit for you, if it were posted in a more
widely used format. How about a PDF of the schematic.
Certainly, it's a available at
On Mon, 15 Mar 2010 08:25:09 -0400, Philip Balister phi...@balister.org wrote:
For some reason you need to set the clock pin as an input. Here is the
config for mcspi1 that is working for me:
MUX_VAL(CP(MCSPI1_CLK), (IEN | PTD | DIS | M0)) /*McSPI1_CLK*/\
(from u-boot)
Are you
* Premi, Sanjeev pr...@ti.com [100315 07:30]:
Hi all,
While trying to build kernel from master, I encounter many errors (pasted
below).
I believe the reason is missing headers - plat/resource.h and smartreflex.h
...but I couldn't find them in the tree.
premi # ls -l
Hi,
On Mon, Mar 01, 2010 at 04:02:36PM +0100, Enric Balletbo i Serra wrote:
@@ -458,13 +458,13 @@ static struct omap_musb_board_data musb_board_data = {
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
-
On Mon, Mar 15, 2010 at 02:22:38PM +0300, Sergei Shtylyov wrote:
The whole musb_platform_set_mode() seems to be implemented
incorrectly on OMAPs -- it shouldn't touch the DevCtl.Session bit. This
correct. It should be changing the id pin rules just like in tusb6010.c
function should
* Scott Ellis sc...@jumpnowtek.com [100314 10:22]:
The McSPI_CHxCONF.CLKD register field has different limits for
the OMAP3 then the OMAP24xx. New max_clk_div field added to
mcspi platform config structure to keep track of this.
Revised patch to not break multi-omap booting.
* Ben Gamari bgamari.f...@gmail.com [100314 19:41]:
P.P.S. Is it just me or does the omap_pinmux interface need some refinement.
Using it has been an exercise in frustration, between extremely sparse
documentation, quirky behavior (I still haven't figure out how to get gpio_130
configured.
Hello,
Felipe, sorry but I don't understand your questions,m maybe I'm
missing something.
All IGEP v2 boards uses USB1HS EHCI port. My mistake was suppose that
port_mode[1] -- EHCI USB1HS but this is not correct, the EHCI USB1HS
is port_mode[0]. This patch only fixes this.
Best regards,
Enric
Hi,
please don't top-post. Read more at [1].
On Mon, Mar 15, 2010 at 06:07:48PM +0100, Enric Balletb? i Serra wrote:
Felipe, sorry but I don't understand your questions,m maybe I'm
missing something.
is there a IGEP v1 board available ? Are there any developers around
using it ? If true, you
Hi,
On Mon, Mar 15, 2010 at 09:32:46AM -0700, Tony Lindgren wrote:
Hmm now it looks like you're missing 3630 handling?
a bit unrelated but Tony, would you mind looking at patches splitting
devices.c into something like dev34xx.c dev24xx.c and dev44xx.c ??
personally I think we should have
Hi,
2010/3/15 Felipe Balbi m...@felipebalbi.com:
Hi,
please don't top-post. Read more at [1].
Sorry
is there a IGEP v1 board available ? Are there any developers around
using it ? If true, you should try to be backwards compatible.
Yes, IGEP v1 is available but it's a different platform
* Cory Maccarrone darkstar6...@gmail.com [100309 15:38]:
On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren t...@atomide.com wrote:
Does your system boot without any patches if DEBUG_LL is not set
in your .config?
No, it doesn't. Seems like the debugging code is still trying to run,
even
* Felipe Balbi m...@felipebalbi.com [100315 10:59]:
Hi,
On Mon, Mar 15, 2010 at 09:32:46AM -0700, Tony Lindgren wrote:
Hmm now it looks like you're missing 3630 handling?
a bit unrelated but Tony, would you mind looking at patches splitting
devices.c into something like dev34xx.c
Tony Lindgren t...@atomide.com writes:
[...]
Here's another one to add to omap-testing then.
This one has been submitted to linux-i2c a couple times and been in
the OMAP PM branch for a while.
OK, let's add that to omap-testing after we're done with the initial
fixes. This does not
* Kevin Hilman khil...@deeprootsystems.com [100312 16:38]:
Gopinath, Thara th...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, March 02, 2010 11:58 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com;
* Tony Lindgren t...@atomide.com [100315 11:35]:
* Cory Maccarrone darkstar6...@gmail.com [100309 15:38]:
On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren t...@atomide.com wrote:
Does your system boot without any patches if DEBUG_LL is not set
in your .config?
No, it doesn't. Seems
Hi,
On Mon, Mar 15, 2010 at 11:52:13AM -0700, Tony Lindgren wrote:
Yeah I've been thinking about that too earlier. We could have common
devices.c with the init code, then dev24xx.c and dev34xx.c et al
would just call the common init functions with something like this:
static int __init
* Felipe Balbi m...@felipebalbi.com [100315 12:12]:
Hi,
On Mon, Mar 15, 2010 at 11:52:13AM -0700, Tony Lindgren wrote:
Yeah I've been thinking about that too earlier. We could have common
devices.c with the init code, then dev24xx.c and dev34xx.c et al
would just call the common init
Hi,
On Mon, Mar 15, 2010 at 12:29:10PM -0700, Tony Lindgren wrote:
could be, but we already have separated clk, pm, cpuidle, mux and soon
to become devices. So pretty much the base support is already splitted,
then why not completely avoiding ifdefs also with dma (which today is
full of
* Felipe Balbi m...@felipebalbi.com [100315 12:30]:
Hi,
On Mon, Mar 15, 2010 at 12:29:10PM -0700, Tony Lindgren wrote:
could be, but we already have separated clk, pm, cpuidle, mux and soon
to become devices. So pretty much the base support is already splitted,
then why not completely
Hmm now it looks like you're missing 3630 handling?
If the max_clk_div is 0x0f for 2420 and 2430, then you
can just check for cpu_is_omap24xx(). If it's only
different for 2420, then you can check for cpu_is_omap2420().
That way it should be more future proof, and you don't
need to
Tony,
Please find attached pull request for your convenience.
Regards,
Sergio
-Original Message-
From: Aguirre, Sergio
Sent: Friday, March 12, 2010 2:00 PM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Kevin Hilman; Pandita, Vikram; Paul
Walmsley; Felipe Balbi; Aguirre, Sergio
On 03/15/2010 11:57 AM, Ben Gamari wrote:
When measuring the SIMO signal on the expansion connector with my
daughterboard
connected, I noticed that the daughterboard's level shifter appeared to be
driving the signal higher than it should, to ~2.9 Volts. I then checked the
1.8V rail voltage
* Scott Ellis sc...@jumpnowtek.com [100315 13:27]:
Hmm now it looks like you're missing 3630 handling?
If the max_clk_div is 0x0f for 2420 and 2430, then you
can just check for cpu_is_omap24xx(). If it's only
different for 2420, then you can check for cpu_is_omap2420().
That way it
* Aguirre, Sergio saagui...@ti.com [100315 13:33]:
Tony,
Please find attached pull request for your convenience.
snip
The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c:
Tony Lindgren (1):
Revert omap: Add DSI regulator supply to OMAP3EVM board file
* Aguirre, Sergio saagui...@ti.com [100315 14:47]:
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, March 15, 2010 4:15 PM
* Aguirre, Sergio saagui...@ti.com [100315 13:33]:
Tony,
Please find attached pull request for your convenience.
snip
The following
This is for protecting a wrong mapping attempt of a zero-based
physical address.
The result is that, no serial port will be attempted to be mapped.
Also add an additional protection for NULL clocks before attempting
to enable them (if above condition applies)
Signed-off-by: Sergio Aguirre
Hi,
This series contains fixes for omap2/3/4 serial code, and are
fixing:
- Avoid doing ioremap of a zero-based physical address.
(causing a kernel panic during early init on 3630boards)
- Unproper omap_revision check during uart globals setup.
(omap_revision is not yet filled at that
This is useless, since in Zoom2/3 boards, the ports aren't even
physically accessible.
They must be explicitly initted in the board-zoom2.c, board-zoom3.c
and board-3630sdp.c files instead.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
it's the only port that's going to be initialized in
Zoom 2/3 boards.
So, it doesn't make sense to keep the hardcoded 3 value anymore.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-zoom-debugboard.c |
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
There's no more serial ports available, so, doesn't make sense
to create 4 device nodes.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/configs/omap_zoom2_defconfig |2 +-
arch/arm/configs/omap_zoom3_defconfig |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
As we have a struct device populated at the time we are
printing the errors, using dev_* macros makes more sense,
as could give a better idea where the error/warning came from.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 12 ++--
1 files changed, 6
This check is invalid, since we haven't filled the
omap_revision var at this point.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/serial.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, March 15, 2010 5:49 PM
snip
OK, thanks. One more thing: Please repost your fixes one more
time with LAKML Cc'd for review. Then assuming no more comments, I'll
merge them into omap-fixes-for-linus.
Done.
Meanwhile, I'll merge
Thank you very much for your response. As you might have gathered, I seem to
have it working but your feedback is really appreciated. I hope to do another
run of these boards with these fixes.
On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester nforres...@whoi.edu wrote:
Your problem is likely
On 03/15/2010 09:06 PM, Ben Gamari wrote:
Thank you very much for your response. As you might have gathered, I seem to
have it working but your feedback is really appreciated. I hope to do another
run of these boards with these fixes.
On Mon, 15 Mar 2010 16:57:27 -0400, Ned Forrester
51 matches
Mail list logo
