On Mon, Mar 01, 2010 at 04:02:36PM +0100, ext Enric Balletbo i Serra wrote:
From: Enric Balletbo i Serra
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra
I'm happy with the explanation:
Acked-by: Felipe Balbi
---
arch/arm/mach-omap2/board-igep0020.c
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 wr
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 wrote:
>
> Your problem is likely caused by pulling
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, March 15, 2010 5:49 PM
>
> 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
This check is invalid, since we haven't filled the
omap_revision var at this point.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/serial.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
in
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
---
arch/arm/mach-omap2/serial.c | 12 ++--
1 files changed, 6 insertions(+), 6
There's no more serial ports available, so, doesn't make sense
to create 4 device nodes.
Signed-off-by: Sergio Aguirre
---
arch/arm/configs/omap_zoom2_defconfig |2 +-
arch/arm/configs/omap_zoom3_defconfig |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/con
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
---
arch/arm/mach-omap2/board-zoom-debugboard.c |2 +-
1 files cha
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
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
1 files changed,
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 poin
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre
---
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
index a0a2a11..504d2
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
---
* Aguirre, Sergio [100315 14:47]:
>
>
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Monday, March 15, 2010 4:15 PM
> > * Aguirre, Sergio [100315 13:33]:
> > > Tony,
> > >
> > > Please find attached pull request for your convenience.
> >
> >
> >
> > > The following changes since com
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, March 15, 2010 4:15 PM
> * Aguirre, Sergio [100315 13:33]:
> > Tony,
> >
> > Please find attached pull request for your convenience.
>
>
>
> > The following changes since commit
> a842b5f9ce70e1b738eabb4d719860070180ed1c:
> > Tony
* Aguirre, Sergio [100315 13:33]:
> Tony,
>
> Please find attached pull request for your convenience.
> The following changes since commit a842b5f9ce70e1b738eabb4d719860070180ed1c:
> Tony Lindgren (1):
> Revert "omap: Add DSI regulator supply to OMAP3EVM board file"
>
> are availabl
* Scott Ellis [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 should
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 volta
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, S
> 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 t
* Felipe Balbi [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 avoiding
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
> > fu
* Felipe Balbi [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 functions with
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 __in
Hi Linus,
Please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-fixes-for-linus
Regards,
Tony
The following changes since commit 57d54889cd00db2752994b389ba714138652e60c:
Linus Torvalds (1):
Linux 2.6.34-rc1
are available in th
Hi,
On Mon, Mar 15, 2010 at 07:20:29PM +0100, Enric Balletb? i Serra wrote:
> > please don't top-post. Read more at [1].
>
> Sorry
np
> Yes, IGEP v1 is available but it's a different platform with different
> processor
> and aren't compatible.
>
> See http://www.igep-platform.com.
>
> - IGE
* Tony Lindgren [100315 11:35]:
> * Cory Maccarrone [100309 15:38]:
> > On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren 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
* Kevin Hilman [100312 16:38]:
> "Gopinath, Thara" 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; Menon, Nishanth; Cou
Tony Lindgren 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 current
* Felipe Balbi [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 dev24xx.c and dev44
Tero Kristo writes:
> From: Tero Kristo
>
> This patch contains following improvements:
> - Only RX interrupt will now kick the sleep prevent timer
> - TX fifo status is checked before disabling clocks, this will prevent
> on-going transmission to be cut
> - Smartidle is now enabled/disabled o
* Cory Maccarrone [100309 15:38]:
> On Tue, Mar 9, 2010 at 7:56 AM, Tony Lindgren 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 disabled. If I add in that che
Hi,
2010/3/15 Felipe Balbi :
> 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 with different pr
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 mac
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
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
* Ben Gamari [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. omap_mux_init_gpio
* Scott Ellis [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.
>
> Signed-off-by: Scott Ellis
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 co
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,
> -
* Premi, Sanjeev [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 arch/arm/plat-omap/inc
On Mon, 15 Mar 2010 08:25:09 -0400, Philip Balister 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 sure? Is thi
On Mon, 15 Mar 2010 10:38:38 -0400, Ned Forrester 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
http://goldnerlab.physics.umass.edu/~bgamari/schematic.png.
- Ben
--
To un
Thanks for your reply!
On Mon, 15 Mar 2010 11:55:56 +0900, jassi brar wrote:
> a) You might as well want to verify your SPIDEV setup by using the same pins
> in GPIO mode and controlling them by gpio-bitbanging i/f ... first on both
> boards and then on either, to more accurately diagnose the pr
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 vo
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 arch/arm/
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 g
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
> >>
> >> This patch enables the use of vdds_sdi regulator in S
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
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: Rog
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
From: Enric Balletbo i Serra
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/mach-omap2/board-igep0020.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-oma
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 > /sys/devices/pl
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 platfor
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 conditionall
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
> From: Roger Quadros
>
> 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
> ---
> drivers/video/
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
> >
> > Panel enable/disable is now done inside display manager,
> > so don't need to do it again.
> >
>
> This looks correct, thanks.
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
> From: Roger Quadros
>
> 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 "unsubscribe linux
On Fri, 2010-03-12 at 16:27 +0100, Quadros Roger (Nokia-D/Helsinki)
wrote:
> From: Roger Quadros
>
> 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 the DSS2 core.
>
>
57 matches
Mail list logo
