linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Balaji T K <balajitk@ti.com>
Cc: Andreas Fenkart <afenkart@gmail.com>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	Chris Ball <cjb@laptop.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Felipe Balbi <balbi@ti.com>, Daniel Mack <zonque@gmail.com>,
	linux-doc@vger.kernel.org, linux-mmc <linux-mmc@vger.kernel.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
Date: Tue, 19 Nov 2013 07:49:09 -0800	[thread overview]
Message-ID: <20131119154909.GD10317@atomide.com> (raw)
In-Reply-To: <528A3EB2.1010103@ti.com>

* Balaji T K <balajitk@ti.com> [131118 08:23]:
> On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
> >2013/11/18 Michael Trimarchi <michael@amarulasolutions.com>:
> >>On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart <afenkart@gmail.com> wrote:
> >>>  static int omap_hsmmc_card_detect(struct device *dev, int slot)
> >>>  {
> >>>         struct omap_hsmmc_host *host = dev_get_drvdata(dev);
> >>>@@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
> >>>         } else
> >>>                 pdata->slots[0].gpio_wp = -EINVAL;
> >>>
> >>>+       if (gpio_is_valid(pdata->slots[0].gpio_cirq)) {
> >>>+               pdata->slots[0].sdio_irq =
> >>>+                               gpio_to_irq(pdata->slots[0].gpio_cirq);
> >>
> >>What is this? re-assign the platform data?
> >
> >Seems like, I didn't pay attention to this.
> >Simply kept in line how the write protection/read only pins are managed.
> >I'd rather not change this part, or not changing it as part of adding
> >sdio IRQ support it.
> >
> >Maybe somebody else on the list can explain why the platform data
> >contains elements
> >that are modified during runtime.
> >
> >- set_power / get_ro function callbacks
> >- ocr_mask.
> >
> Hi,
> 
> few params were passed via platform data in non-DT case and never cached
> in internal data structure, with non-dt support going away soon, I am
> planning to cleanup pdata usage in the driver when it gets to DT only support.

The issue of pdata tinkering needs to be fixed first as it will cause nasty
issues when the module is reprobed. 

Note that it's still possible to pass platform data in the device tree case
as auxdata. And we probably need to do that for the pbias register handling
until we have a driver for that.

Talking of the pbias driver, any news on it?

To recap, we basically we need a minimal separate driver that exposes the
control module pbias register as a regulator to the hsmmc driver. I don't see
that we can remove the platform data from the driver before that's done.

Regards,

Tony

  reply	other threads:[~2013-11-19 15:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18  7:53 [PATCH v3 0/3] mmc: omap_hsmmc: Enable SDIO IRQ Andreas Fenkart
2013-11-18  7:53 ` [PATCH v3 1/3] " Andreas Fenkart
2013-11-18  7:53 ` [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x Andreas Fenkart
2013-11-18 10:03   ` Michael Trimarchi
2013-11-18 12:15     ` Andreas Fenkart
2013-11-18 16:22       ` Balaji T K
2013-11-19 15:49         ` Tony Lindgren [this message]
2013-11-19 15:59           ` Balaji T K
2013-11-19 16:19             ` Tony Lindgren
2013-11-21 11:37               ` Andreas Fenkart
2013-11-21 11:58                 ` Balaji T K
2014-06-30 12:23             ` Andreas Fenkart
2013-11-19 13:18   ` Ulf Hansson
2013-11-19 13:37     ` Andreas Fenkart
2013-11-19 15:09       ` Ulf Hansson
2013-11-18  7:54 ` [PATCH v3 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux Andreas Fenkart
  -- strict thread matches above, loose matches on Subject: below --
2013-11-25 13:26 [PATCH v3 0/3] mmc: omap_hsmmc: Enable SDIO IRQ Andreas Fenkart
2013-11-25 13:26 ` [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x Andreas Fenkart
2013-11-25 22:46   ` Tony Lindgren
2013-11-26  1:16     ` Felipe Balbi
2013-11-26 18:06       ` Tony Lindgren
2013-11-27 16:59     ` Balaji T K
2013-11-27 17:04       ` 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=20131119154909.GD10317@atomide.com \
    --to=tony@atomide.com \
    --cc=afenkart@gmail.com \
    --cc=balajitk@ti.com \
    --cc=balbi@ti.com \
    --cc=cjb@laptop.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=michael@amarulasolutions.com \
    --cc=zonque@gmail.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;
as well as URLs for NNTP newsgroup(s).