From: Kevin Hilman <khilman@deeprootsystems.com>
To: Charulatha V <charu@ti.com>
Cc: linux-omap@vger.kernel.org, rnayak@ti.com, paul@pwsan.com,
tony@atomide.com
Subject: Re: [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS
Date: Tue, 06 Apr 2010 15:31:19 -0700 [thread overview]
Message-ID: <87hbnojjrc.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1270038239-1090-1-git-send-email-charu@ti.com> (Charulatha V.'s message of "Wed\, 31 Mar 2010 17\:53\:51 +0530")
Charulatha V <charu@ti.com> writes:
> This patch series is in preparation to adapt GPIO to HWMOD FW.
> It creates OMAP architecture specific gpio files to handle
> SoC specific gpio_init. The common plat-omap/gpio.c handles all
> common GPIO APIs.
>
> OMAP2PLUS GPIO module is implemented as early platform device and
> OMAP1 GPIO is still handled in old way via gpio_init from board files.
>
> Save/restore context, gpio_prepare_for_retention and
> gpio_resume_after_retention APIs are also handled in plat-omap layer.
> These APIs are currently not used in OMAP1, but still they might
> become common for different OMAP architectures in the future.
> Hence they are handled in plat-omap layer. If they need to be moved
> to mach-omap2 layer, additional patches may be sent during
> next version of this patch series.
>
> This patch series is generated on top of linux-omap-2.6 branch: master
> and tested on 3430SDP, 4430SDP & zoom3.
I have many problems with this series, but without going into the
specifics of each patch, I have a big problem with the general
approach being taken here.
You say this is in preparation for adaptation to hwmod, but in fact,
this series is duplicating a lot of the work you would get for free by
starting with hwmod.
You're generating a bunch of code that will be completely thrown away
with a hwmod conversion. Instead, you should *start* by using hwmod +
omap_device to generate the platform_devices for you. Doing this, you
will drop patches 2, 3 and 4 entirely (they are mostly identical
anyways, except for the search-and-replace) and also eliminate the
need for patch 5.
What is needed here is a way to introduce the platform_device
conversion without introducing signifcant functional changes at the
same time. Here's a proposal to do that, and which should also be
considerably easier to review for sanity:
- use hwmod + omap_device to generate (early) platform_devices
- modify plat-omap/gpio.c to use base addr and IRQ from platform_device
- modify plat-omap/gpio.c to get clocks based on 'struct device'
For an example, you can see the pm-wip/hwmods branch in my tree for
how this was done for UART and the pm-wip/mmc branch for how this was
done for MMC.
Kevin
next prev parent reply other threads:[~2010-04-06 22:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 12:23 [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS Charulatha V
2010-03-31 12:23 ` [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific header Charulatha V
2010-03-31 12:23 ` [PATCH 2/8] OMAP3:GPIO:Add support for early platform gpio device Charulatha V
2010-03-31 12:23 ` [PATCH 3/8] OMAP2:GPIO:Add " Charulatha V
2010-03-31 12:23 ` [PATCH 4/8] OMAP4:GPIO:Add " Charulatha V
2010-03-31 12:23 ` [PATCH 5/8] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support Charulatha V
2010-03-31 12:23 ` [PATCH 6/8] OMAP1:GPIO:Support for OMAP1 specific gpio Charulatha V
2010-03-31 12:23 ` [PATCH 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw Charulatha V
2010-03-31 12:23 ` [PATCH 8/8] OMAP:GPIO:Common platform code for all OMAPs Charulatha V
2010-04-01 9:34 ` Tony Lindgren
2010-04-01 9:32 ` [PATCH 7/8] OMAP2PLUS:GPIO:Move gpio_init from board files to init_common_hw Tony Lindgren
2010-04-01 10:50 ` Varadarajan, Charulatha
2010-04-06 22:13 ` Kevin Hilman
2010-04-01 9:30 ` [PATCH 5/8] OMAP2PLUS:GPIO:Add OMAP2PLUS specific gpio support Tony Lindgren
2010-04-06 22:08 ` Kevin Hilman
2010-04-01 7:26 ` [PATCH 3/8] OMAP2:GPIO:Add support for early platform gpio device Felipe Balbi
2010-04-01 8:53 ` Varadarajan, Charulatha
2010-04-01 8:58 ` Felipe Balbi
2010-04-01 9:16 ` Varadarajan, Charulatha
2010-04-01 7:23 ` [PATCH 2/8] OMAP3:GPIO:Add " Felipe Balbi
2010-04-01 8:58 ` Varadarajan, Charulatha
2010-04-01 9:12 ` Tony Lindgren
2010-04-01 9:19 ` Varadarajan, Charulatha
2010-04-01 9:13 ` Tony Lindgren
2010-04-01 10:49 ` Varadarajan, Charulatha
2010-04-01 9:31 ` Tony Lindgren
2010-04-01 10:50 ` Varadarajan, Charulatha
2010-04-01 7:17 ` [PATCH 1/8] OMAP:GPIO:Move architecture specific macros to specific header Felipe Balbi
2010-04-01 8:52 ` Varadarajan, Charulatha
2010-04-01 9:00 ` Felipe Balbi
2010-04-01 9:41 ` Tony Lindgren
2010-04-01 10:50 ` Varadarajan, Charulatha
2010-04-06 22:31 ` Kevin Hilman [this message]
2010-04-12 12:16 ` [PATCH 0/8 RFC] OMAP: GPIO: Split OMAP1 and OMAP2PLUS Varadarajan, Charulatha
2010-04-19 14:31 ` Kevin Hilman
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=87hbnojjrc.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=charu@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox