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 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.