From: Tony Lindgren <tony@atomide.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Date: Wed, 22 Feb 2012 18:57:28 +0000 [thread overview]
Message-ID: <20120222185728.GJ18185@atomide.com> (raw)
In-Reply-To: <1329898441.2070.10.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > Drivers should no longer use omap_read/write functions
> > but instead use ioremap + read/write functions.
> >
> > As some USB legacy code is still shared between omap1 and
> > omap2420, let's limit the omap_read/write to plat/usb.h.
> >
> > Also, let's make drivers/video/omap/lcdc.c depend on
> > ARCH_OMAP1 as it is not needed for omap2+.
>
> I'm ok with the lcdc.c change, but I also have a patch series that makes
> the same change, plus removes the omap2 code from drivers/video/omap/.
OK, I'll drop the lcdc.c change from my series as that should
only affect randconfig builds.
> Can you check the series, and give ack if the arch/arm side looks fine?
> It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Yeah great, I've acked those. Let's do a test merge when I
have these in cleanup branch, looks like the conflicts should
be trivial.
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Date: Wed, 22 Feb 2012 10:57:28 -0800 [thread overview]
Message-ID: <20120222185728.GJ18185@atomide.com> (raw)
In-Reply-To: <1329898441.2070.10.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > Drivers should no longer use omap_read/write functions
> > but instead use ioremap + read/write functions.
> >
> > As some USB legacy code is still shared between omap1 and
> > omap2420, let's limit the omap_read/write to plat/usb.h.
> >
> > Also, let's make drivers/video/omap/lcdc.c depend on
> > ARCH_OMAP1 as it is not needed for omap2+.
>
> I'm ok with the lcdc.c change, but I also have a patch series that makes
> the same change, plus removes the omap2 code from drivers/video/omap/.
OK, I'll drop the lcdc.c change from my series as that should
only affect randconfig builds.
> Can you check the series, and give ack if the arch/arm side looks fine?
> It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Yeah great, I've acked those. Let's do a test merge when I
have these in cleanup branch, looks like the conflicts should
be trivial.
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Date: Wed, 22 Feb 2012 10:57:28 -0800 [thread overview]
Message-ID: <20120222185728.GJ18185@atomide.com> (raw)
In-Reply-To: <1329898441.2070.10.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > Drivers should no longer use omap_read/write functions
> > but instead use ioremap + read/write functions.
> >
> > As some USB legacy code is still shared between omap1 and
> > omap2420, let's limit the omap_read/write to plat/usb.h.
> >
> > Also, let's make drivers/video/omap/lcdc.c depend on
> > ARCH_OMAP1 as it is not needed for omap2+.
>
> I'm ok with the lcdc.c change, but I also have a patch series that makes
> the same change, plus removes the omap2 code from drivers/video/omap/.
OK, I'll drop the lcdc.c change from my series as that should
only affect randconfig builds.
> Can you check the series, and give ack if the arch/arm side looks fine?
> It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Yeah great, I've acked those. Let's do a test merge when I
have these in cleanup branch, looks like the conflicts should
be trivial.
Tony
next prev parent reply other threads:[~2012-02-22 18:57 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 23:40 [PATCH 0/8] Split omap plat/io.h into local iomap.h files Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init() Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-22 8:09 ` Tomi Valkeinen
2012-02-22 8:09 ` Tomi Valkeinen
2012-02-22 8:09 ` Tomi Valkeinen
2012-02-22 19:05 ` Tony Lindgren
2012-02-22 19:05 ` Tony Lindgren
2012-02-22 19:05 ` Tony Lindgren
2012-02-22 22:17 ` Tony Lindgren
2012-02-22 22:17 ` Tony Lindgren
2012-02-22 22:17 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 2/8] ARM: OMAP2+: Move SDRC related functions from io.h into local common.h Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 3/8] ARM: OMAP: Move omap_init_consistent_dma_size() to " Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 4/8] ARM: OMAP1: Move 16xx GPIO system clock to platform init code Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-23 23:42 ` Tony Lindgren
2012-02-23 23:42 ` Tony Lindgren
2012-03-12 17:30 ` Grant Likely
2012-03-12 17:30 ` Grant Likely
2012-03-12 18:05 ` Tony Lindgren
2012-03-12 18:05 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 5/8] ARM: OMAP1: Move most of plat/io.h into local iomap.h Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-23 23:44 ` Tony Lindgren
2012-02-23 23:44 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 6/8] ARM: OMAP2+: " Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-23 23:46 ` Tony Lindgren
2012-02-23 23:46 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 7/8] ARM: OMAP: Remove plat/io.h by moving it into mach/io.h Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-22 2:24 ` Rob Herring
2012-02-22 2:24 ` Rob Herring
2012-02-24 0:06 ` Tony Lindgren
2012-02-24 0:06 ` Tony Lindgren
2012-02-24 18:22 ` Tony Lindgren
2012-02-24 18:22 ` Tony Lindgren
2012-02-27 3:47 ` Rob Herring
2012-02-27 3:47 ` Rob Herring
2012-02-29 1:47 ` Tony Lindgren
2012-02-29 1:47 ` Tony Lindgren
2012-02-29 1:49 ` Tony Lindgren
2012-02-29 1:49 ` Tony Lindgren
2012-02-29 23:59 ` Rob Herring
2012-02-29 23:59 ` Rob Herring
2012-03-01 0:11 ` Russell King - ARM Linux
2012-03-01 0:11 ` Russell King - ARM Linux
2012-03-01 0:39 ` Tony Lindgren
2012-03-01 0:39 ` Tony Lindgren
2012-03-01 1:03 ` Tony Lindgren
2012-03-01 1:03 ` Tony Lindgren
2012-03-01 3:34 ` Rob Herring
2012-03-01 3:34 ` Rob Herring
2012-03-01 3:46 ` Tony Lindgren
2012-03-01 3:46 ` Tony Lindgren
2012-03-01 3:53 ` Rob Herring
2012-03-01 3:53 ` Rob Herring
2012-03-01 4:54 ` Tony Lindgren
2012-03-01 4:54 ` Tony Lindgren
2012-02-21 23:40 ` [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-21 23:40 ` Tony Lindgren
2012-02-22 8:14 ` Tomi Valkeinen
2012-02-22 8:14 ` Tomi Valkeinen
2012-02-22 8:14 ` Tomi Valkeinen
2012-02-22 18:57 ` Tony Lindgren [this message]
2012-02-22 18:57 ` Tony Lindgren
2012-02-22 18:57 ` Tony Lindgren
2012-02-22 22:44 ` Tony Lindgren
2012-02-22 22:44 ` Tony Lindgren
2012-02-22 22:44 ` Tony Lindgren
2012-02-24 18:25 ` Tony Lindgren
2012-02-24 18:25 ` Tony Lindgren
2012-02-24 18:25 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120222185728.GJ18185@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.