From: [EMAIL PROTECTED] On Behalf Of Felipe Balbi
On Mon, Sep 15, 2008 at 12:11:46AM +0530, Vikram Pandita wrote:
Better still is to move the PHY issues to platform/board specific function.
Will try to submit a patch on that.
Any updates on this ?? Could you test the patches I sent you
On Mon, Sep 22, 2008 at 08:51:29PM +0530, ext Gadiyar, Anand wrote:
From: [EMAIL PROTECTED] On Behalf Of Felipe Balbi
On Mon, Sep 15, 2008 at 12:11:46AM +0530, Vikram Pandita wrote:
Better still is to move the PHY issues to platform/board specific
function.
Will try to submit a
On Mon, Sep 22, 2008 at 08:51:29PM +0530, ext Gadiyar, Anand wrote:
From: [EMAIL PROTECTED] On Behalf Of Felipe Balbi
On Mon, Sep 15, 2008 at 12:11:46AM +0530, Vikram Pandita wrote:
Better still is to move the PHY issues to platform/board specific
function.
Will try to
On Mon, Sep 22, 2008 at 09:00:26PM +0530, ext Gadiyar, Anand wrote:
Yes, it was related to DPLL5 I think. But with your patches plus that one
section of code commented out, EHCI was still working. So nothing broken yet.
Cool, so let's wait a bit more for clock updates, then we apply those,
Hello Anand,
On Thu, 18 Sep 2008, Gadiyar, Anand wrote:
Ideally the clock framework should be taking care of enabling DPLL5 when
the corresponding clocks are enabled, but this does not happen today.
It will do that now; but what it will not do is set DPLL5's rate
correctly.
@ Paul,
Hi Felipe, Paul,
-Original Message-
From: [EMAIL PROTECTED] On Behalf Of Felipe Balbi
Hi,
On Mon, Sep 15, 2008 at 12:11:46AM +0530, Pandita, Vikram wrote:
The issues mentioned are _not_ of omap34xx silicon, but of
the PHY (ISP1504 in SDP-USB expansion board).
Gotcha
-Original Message-
From: Felipe Balbi [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 1:06 AM
To: Felipe Balbi
Cc: Tony Lindgren; David Brownell; [EMAIL PROTECTED]; Linux OMAP Mailing
List; Pandita, Vikram
Subject: Re: [rfc] [patch] clean up to ehci-omap (Was: Re:
Hi,
On Mon, Sep 15, 2008 at 12:11:46AM +0530, Pandita, Vikram wrote:
The issues mentioned are _not_ of omap34xx silicon, but of the PHY (ISP1504
in SDP-USB expansion board).
Gotcha
Better still is to move the PHY issues to platform/board specific function.
Will try to submit a patch on
This one is RFC since I need someone to test it for me. I'm home now
without any hw so if anyone could validate if it works I'd be really
glad otherwise I'll test it tomorrow at work on my sdp.
= cut here =
From 194d26cae0e9093c4b1da4de531f6e5c16495678 Mon Sep 17 00:00:00 2001
From:
On Friday 12 September 2008, Felipe Balbi wrote:
/* Enusre bit is set */
My Cortex Mark-I (cerebral, humanoid) treats that as a compile error ... :)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* David Brownell [EMAIL PROTECTED] [080912 12:18]:
On Friday 12 September 2008, Felipe Balbi wrote:
/* Enusre bit is set */
My Cortex Mark-I (cerebral, humanoid) treats that as a compile error ... :)
Have you tried preprocessing with squint? :)
Tony
--
To unsubscribe from this
On Fri, Sep 12, 2008 at 12:21:59PM -0700, Tony Lindgren wrote:
* David Brownell [EMAIL PROTECTED] [080912 12:18]:
On Friday 12 September 2008, Felipe Balbi wrote:
/* Enusre bit is set */
My Cortex Mark-I (cerebral, humanoid) treats that as a compile error ... :)
Have you
On Fri, Sep 12, 2008 at 10:28:16PM +0300, Felipe Balbi wrote:
On Fri, Sep 12, 2008 at 12:21:59PM -0700, Tony Lindgren wrote:
* David Brownell [EMAIL PROTECTED] [080912 12:18]:
On Friday 12 September 2008, Felipe Balbi wrote:
/* Enusre bit is set */
My Cortex Mark-I
Hi Vikram,
Those issues mentioned on the ehci-omap driver, are them silicon
version related ? I mean, does it happen on all omap3 silicons or
doesn't it happen with only versions of them ?
Case the second, we can make the workarounds be applied based on runtime
checks instead of #ifdefs. That
From: David Brownell [EMAIL PROTECTED]
On Friday 12 September 2008, Gadiyar, Anand wrote:
1. TLL vs PHY mode needs to be set somewhere. Me thinks this information
ought
to come from board-specific data and the driver would need to set things up
accordingly. What would be a good way to
From: Felipe Balbi [EMAIL PROTECTED]
On Sat, Sep 13, 2008 at 01:31:12AM +0530, Gadiyar, Anand wrote:
Was planning on cleaning up this driver and sending to linux-omap as Tony
suggested, but I'm afraid I won't be able to look at it for a while.
So if you're going to be doing this anyway,
On Fri, Sep 12, 2008 at 2:06 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote:
From: Felipe Balbi [EMAIL PROTECTED]
On Sat, Sep 13, 2008 at 01:31:12AM +0530, Gadiyar, Anand wrote:
By the way, how do you propose to test this driver? Do you have the
expansion board for the SDP, or some other
On Friday 12 September 2008, Gadiyar, Anand wrote:
Sounds like code that can live in mach-omap2 and be called
when the drivers start or stop.
Yup. Then a lot of the code in that ehci-omap.c file would need
to be moved there to avoid duplicating code. Will do that when
I add the OHCI
18 matches
Mail list logo
