Hi,
Thanks for reposting this, it's been a while since the last review round
so I've taken a closer look at it.
Lots of comments below.
-Olof
On Wed, Jan 27, 2010 at 03:26:56PM +0530, Govindraj.R wrote:
> >From 869dde60756b2115c35d97f8e2daf014cb1af08e Mon Sep 17 00:00:00 2001
> From: Govindra
Don't assume that gpmc_l3_clk is on, enable it before touching
configuration registers.
Signed-off-by: Olof Johansson
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e86f5ca..dea72f3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -
On Thu, Jan 07, 2010 at 09:03:11PM -0400, Francisco Alecrim wrote:
> From: Francisco Alecrim
>
> include/linux/usb.h: In function 'usb_mark_last_busy':
> include/linux/usb.h:561: error: 'struct usb_device' has no member named
> 'last_busy'
>
> Option USB_OTG selects USB_SUSPEND but doesn't selec
c: Greg Kroah-Hartman
> Cc: Olof Johansson
Acked-by: Olof Johansson
--
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
pe Balbi
>
> Now this patch looks ok.
Don't you mean Acked-by?
Anyway, also:
Acked-by: Olof Johansson
-Olof
--
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
On Mon, Jan 04, 2010 at 06:18:08PM +0530, Maulik wrote:
>
> >>not omap-specific. How about USB: instead ?
>
> [Maulik] Yes this can go through linux-usb.
>
> > +#if defined(CONFIG_USB_NOP_XCEIV)
> > /* sometimes transceivers are accessed only through e.g. ULPI */
> > extern void usb_nop_xceiv_
Hi,
On Wed, Dec 30, 2009 at 07:56:38PM +0530, Maulik Mankad wrote:
> --- felipe_musb.orig/arch/arm/mach-omap2/board-4430sdp.c
> +++ felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
> @@ -73,11 +75,21 @@ static void __init omap_4430sdp_init_irq
> omap_gpio_init();
> }
>
> +static struct om
Hi,
On Fri, Dec 18, 2009 at 08:18:52AM +, Russell King - ARM Linux wrote:
> On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote:
> > Hi Catalin,
> >
> > You may have already run into this, but if not, looks like commit
> > 115b22474eb1905da2f606a057da345583d3 breaks compile for
he drivers that had references to the
codec weren't enabled. Turns out the Makefile was using the wrong
config option to enable them. Patch below.
Reported-by: Anand Gadiyar
Signed-off-by: Olof Johansson
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index d49458a..3db8a6c 100
Hi,
{removing invalid lkml-like addressee}
On Thu, Dec 10, 2009 at 11:19:52AM +0530, Anand Gadiyar wrote:
> Select sound codecs to allow this defconfig to build again
You need to fix the config option dependencies/selects, updating the
defconfig just papers over the real problem.
> Also, sync u
On Wed, Dec 09, 2009 at 01:36:57AM +0530, Hiremath, Vaibhav wrote:
> [Hiremath, Vaibhav] I understand, but if we put the patches on master for
> whatever period of time available, people can try and validate it.
>
> Some people are forward porting the patches (earlier versions submitted) or
> p
On Wed, Dec 09, 2009 at 12:19:22AM +0530, Hiremath, Vaibhav wrote:
> > Wait until DSS2 patches have been merged. I don't want the extra
> > complexity of board/panel patches, there's enough work with just the
> > half-megabyte DSS patches =).
> >
> [Hiremath, Vaibhav] Tomi and Tony,
>
> Now sinc
On Wed, Nov 18, 2009 at 07:09:10PM +0530, Anand Gadiyar wrote:
> omap3: zoom2/3: make MMC slot work again
>
> Commit 12f8dfb56 accidentally broke MMC on zoom2/3.
> The .vmmc1 field of zoom_twldata was deleted. Restoring it
> allows the MMC slot to work again
Hmm. This was posted 2 weeks ago and n
The OMAP usb header file will move in the same merge window as this
driver is getting introduced in, so update the driver now instead of
making a merge-order-dependent patch later on through linux-omap.
Signed-off-by: Olof Johansson
Acked-by: Tony Lindgren
---
Greg, see below for history
On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
> Ah, you're talking about pin muxing configuration, right? Yes, that
> GPIO binding deals with controllers, not pin mux. Pin mux is very
> much an SoC specific thing that isn't mapped easily to a generic
> binding.
Yep.
> On the 52
On Wed, Dec 02, 2009 at 08:12:34AM +0200, Menon, Nishanth wrote:
> why not make this a #ifdef instead if we need it some other time, a #if
> 0 and it's intention might not be readable without doing a git annotate
> in a few months time..
Just remove the code. The old implementation is still there
On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:
> Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
> connections in the device tree:
> Documentation/powerpc/dts-bindings/gpio/gpio.txt
That binding is more about documenting a bank of GPIO pins, while
chips like O
On Tue, Dec 01, 2009 at 04:08:19PM -0800, Tony Lindgren wrote:
> Hi,
>
> * Olof Johansson [091201 12:06]:
> > Having one combined defconfig that is the superset of the individual
> > defconfigs for OMAP3 platforms is useful for easily finding build
> > errors. Not to m
Having one combined defconfig that is the superset of the individual
defconfigs for OMAP3 platforms is useful for easily finding build
errors. Not to mention convenient as a base if you want to boot several
platforms with a single kernel image.
Signed-off-by: Olof Johansson
---
Changed since
On Tue, Dec 01, 2009 at 09:29:42AM +0530, Pandita, Vikram wrote:
>
>
> >-Original Message-
> >From: linux-omap-ow...@vger.kernel.org
> >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Olof
>
> >+# CONFIG_OMAP_LL_DEBUG_UART1 is not set
> >+# CONFIG_OMAP_LL_DEBUG_UART2 is not set
>
Having one combined defconfig that is the superset of the individual
defconfigs for OMAP3 platforms is useful for easily finding build
errors. Not to mention convenient as a base if you want to boot several
platforms with a single kernel image.
Signed-off-by: Olof Johansson
---
Changed since
On Mon, Nov 30, 2009 at 11:17:47AM +0530, Gadiyar, Anand wrote:
> Olof Johansson wrote:
>
> > Having one combined defconfig that is the superset of the individual
> > defconfigs for OMAP3 platforms is useful for easily finding build
> > errors. Not to mention convenient
Having one combined defconfig that is the superset of the individual
defconfigs for OMAP3 platforms is useful for easily finding build
errors. Not to mention convenient as a base if you want to boot several
platforms with a single kernel image.
Signed-off-by: Olof Johansson
---
Tony, I
Refreshed version of previous patch from Tomi, so keeping his S-o-b.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Olof Johansson
---
I'm not 100% sure how to wire up the power supplies. I'm still missing
the one required for VENC to work.
Tomi, I also noticed that DSS2 seems a b
On Wed, Nov 25, 2009 at 02:35:56PM +0530, Gadiyar, Anand wrote:
> Olof Johansson wrote:
> >
> > The OMAP usb header file has moved, update the driver so it
> > will build.
> >
> > Signed-off-by: Olof Johansson
> >
> > ---
> >
> > Gr
On Wed, Nov 25, 2009 at 02:35:56PM +0530, Gadiyar, Anand wrote:
> Olaf Johansson wrote:
> >
> > The OMAP usb header file has moved, update the driver so it
> > will build.
> >
> > Signed-off-by: Olof Johansson
> >
> > ---
> >
> > Gr
The OMAP usb header file has moved, update the driver so it will build.
Signed-off-by: Olof Johansson
---
Greg, any chance you can just ack this so Tony can merge it through his
tree for .33? The header files changes in question are going in through
that tree.
Thanks,
-Olof
diff --git a
OMAP34XX has EHCI, so select USB_ARCH_HAS_EHCI.
Signed-off-by: Olof Johansson
---
On Sat, Nov 07, 2009 at 01:16:32AM +0530, Anand Gadiyar wrote:
> usb: ehci: Allow EHCI to be built on OMAP3
>
> OMAP3 chips have a built-in EHCI controller.
> The recently introduced omap ehci-hcd d
G, Manjunath Kondaiah wrote:
You should allow both of them to be enabled at the same time, so the
same
kernel can for example be booted on a ZOOM2 with debug board
attached
(8250 on GPMC), or on a beagle/overo board.
Making them exclusive would be a step backwards.
More so, selecting both
On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote:
>
>
> > -Original Message-
> > From: Olof Johansson [mailto:o...@lixom.net]
> > Sent: Monday, November 23, 2009 10:36 PM
> > To: Govindraj; g...@lixom.net
> > Cc: Tony Lindgren;
On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote:
> I have not seen any comments on this patch series yet.
>
> Tony,
> Is there something I need to modify?
>
> Or it can be unstreamed now?
Oh, and by the way, serial drivers are preferrably merged through Greg
K-H (gre...@suse.de). So Cc
On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote:
> I have not seen any comments on this patch series yet.
>
> Tony,
> Is there something I need to modify?
Govindaj,
I'm having problems with these patches on Zoom2 with debug board, since
they don't seem to coexist very well together wit
Overo needs the same changes as the other platforms do for the ehci changes.
Also, roll in the corresponding change from Steve Sakoman fixing the
port setup (removing the redundant GPIO setup and switching to port 2).
Signed-off-by: Olof Johansson
---
diff --git a/arch/arm/mach-omap2/board
3_1 that's supposed to be used.
Signed-off-by: Olof Johansson
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index f77a99d..301e7b6 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -235,7 +235,7 @@ static void omap_usb_utmi_i
Overo needs the same changes as the other boards do for the ehci changes.
Signed-off-by: Olof Johansson
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 17f2318..3994974 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board
The OMAP EHCI glue code has a layer of driver state struct between
the platform_device and usb_hcd. So it can't use the generic
usb_hcd_platform_shutdown.
This fixes a panic at reboot time.
Signed-off-by: Olof Johansson
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-o
On Sep 7, 2009, at 8:02 AM, Premi, Sanjeev wrote:
I think it is a great step in the right direction. My only concern is
that the usage conventions are confusing:
OMAP3_HAS_FEATURE(neon, NEON)
[sp] This is only used to declare a function that would translate to:
unsigned int omap3_has_ne
Hi,
On Mon, Sep 07, 2009 at 11:33:32AM +0530, Premi, Sanjeev wrote:
> > What's the purpose of most of these checks in the first place? I can
> > see two immediate needs:
> >
> > 1) To check for various errata and do appropriate workarounds
>
> [sp] I believe the only need would be to make easy
On Thu, Sep 03, 2009 at 04:14:28PM +0530, Premi, Sanjeev wrote:
> Hi,
>
> Currently there are multiple mechanisms for identifying the si revisions.
>
> Most places the comparison is against omap_rev() as a whole number. Example:
>
> arch/arm/mach-omap2/board-3430sdp.c:695:if (omap_rev() >
>
301 - 339 of 339 matches
Mail list logo
