public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: David Brownell <david-b@pacbell.net>
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/4] HSMMC: Add support for the second controller
Date: Fri, 31 Oct 2008 09:35:03 -0700	[thread overview]
Message-ID: <20081031163503.GF13227@atomide.com> (raw)
In-Reply-To: <200810302341.24275.david-b@pacbell.net>

* David Brownell <david-b@pacbell.net> [081030 23:41]:
> On Thursday 30 October 2008, Tony Lindgren wrote:
> > * David Brownell <david-b@pacbell.net> [081030 20:12]:
> > >
> > > Related:  shouldn't hsmmc_init() accept a set of params, maybe even a struct,
> > > describing how each controller is wired?
> > > 
> > > 	- which controller (1, 2, 3)
> > > 	- how many data wires are used (1, 4, 8)
> > > 	- supported voltages (mask)
> > > 	- card detect gpio (or negative) ... assume gpio_to_irq(gpio) works
> > > 	- write protect gpio (or negative)
> > > 	- callback for updating the voltages
> > > 
> > > That would support more complete functionality ... and get away from
> > > the current hard-wiring of most of those parameters.
> > 
> > Yeah I don't know what the right solution is.. I was thinking about
> > passing the struct omap_mmc_platform_data to hsmmc_init, but then
> > again hsmmc.c does not know anything about the custom configurations
> > and the power functions. So right now hsmmc.c would only call
> > omap2_init_mmc() with the custom struct omap_mmc_platform_data.
> 
> Part of it is that "hsmmc.c" is really twl4030-specific glue,
> but it's misnamed as being more generic.
> 
> Glue to other kinds of interface should call omap2_init_mmc()
> directly ... the issue here is that the twl-specific stuff isn't
> quite generic enough yet.

OK, good point. Let's rename it to twl4030-hsmmc.c or something like
that.

> > Maybe we should just let the boards with non-standarad wiring additionally
> > initialize the other mmc controllers from board-*.c by calling
> > omap2_init_mmc()?
> 
> How about this instead:  boards pass an __initdata struct in, not a
> mask, and it's used to set up the current omap_mmc_platform_data.
> Struct should handle common TWL wiring options; maybe:
> 
> 	struct twl4030_hsmmc_info {
> 		u8	mmc;		/* controller 1/2/3 */
> 		u8	wires;		/* 1/4/8 wires */
> 		u8	twl_reg;	/* vmmc1/vmmc2 */
> 		bool	cd_debounce;	/* in case cd isn't on twl4030 */
> 		int	gpio_cd;	/* or -EINVAL */
> 		int	gpio_wp;	/* or -EINVAL */
> 	};
> 
> So for example Beagle would only set up MMC-1, 8-wires, VMMC1,
> debounced TWL GPIO-0 for CD, and some OMAP GPIO for WP ... while
> Overo would do the same with 4-wires and a different GPIO, then
> call hsmmc_init() again with a second struct for MMC-2, 4-wires,
> VMMC2, no CD, no WP.
> 
> That should be a simple tweak on top of what you've just sent,

Sounds good to me. The twl4030 voltages may require further
options, but that can be added later.

Tony

  reply	other threads:[~2008-10-31 16:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31  2:04 [PATCH 0/4] Init updates for hsmmc, also second controller Tony Lindgren
2008-10-31  2:04 ` [PATCH 1/4] HSMMC: Make hsmmc use omap_ctrl_read/write and existing defines Tony Lindgren
2008-10-31  2:04   ` [PATCH 2/4] HSMMC: Fix voltage defines, make card detect gpio controller specific Tony Lindgren
2008-10-31  2:04     ` [PATCH 3/4] HSMMC: Add support for the second controller Tony Lindgren
2008-10-31  2:04       ` [PATCH 4/4] HSMMC: Misc clean-up for hsmmc init Tony Lindgren
2008-10-31  3:12       ` [PATCH 3/4] HSMMC: Add support for the second controller David Brownell
2008-10-31  3:39         ` Tony Lindgren
2008-10-31  6:41           ` David Brownell
2008-10-31 16:35             ` Tony Lindgren [this message]
2008-10-31  4:05         ` Steve Sakoman
2008-10-31 10:00           ` David Brownell
2008-10-31 23:35             ` Steve Sakoman
2008-11-01  0:36               ` David Brownell
2008-11-01  2:31                 ` Felipe Balbi
2008-11-01  2:50                 ` Steve Sakoman
2008-11-01  3:02                   ` David Brownell
2008-11-01  3:11                     ` Steve Sakoman
2008-11-03 22:54             ` Steve Sakoman
2008-11-03 23:22               ` Tony Lindgren
2008-11-03 23:36               ` Steve Sakoman
2008-11-05 23:54                 ` David Brownell
2008-11-06  3:32                   ` Tony Lindgren
2008-11-06  7:09                     ` David Brownell
2008-11-06 17:04                       ` Tony Lindgren
2008-11-06 20:19                         ` Grazvydas Ignotas
2008-11-07  5:54                           ` David Brownell
2008-11-07  9:36                             ` Grazvydas Ignotas
2008-11-10 10:36                               ` Grazvydas Ignotas
2008-11-12 22:11                                 ` Tony Lindgren
2008-11-06 20:52                         ` David Brownell

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=20081031163503.GF13227@atomide.com \
    --to=tony@atomide.com \
    --cc=david-b@pacbell.net \
    --cc=linux-omap@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox