All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ben Chuang <benchuanggli@gmail.com>,
	ulf.hansson@linaro.org, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, ben.chuang@genesyslogic.com.tw,
	greg.tu@genesyslogic.com.tw
Subject: Re: [RFC PATCH V3 12/21] mmc: sdhci: UHS-II support, add hooks for additional operations
Date: Thu, 17 Sep 2020 11:31:13 +0900	[thread overview]
Message-ID: <20200917023113.GB3071249@laputa> (raw)
In-Reply-To: <6bf86b26-391a-0699-1818-d070357b9ddc@intel.com>

Adrian,

On Wed, Sep 16, 2020 at 01:00:35PM +0300, Adrian Hunter wrote:
> On 16/09/20 11:05 am, AKASHI Takahiro wrote:
> > Adrian,
> > 
> > Your comments are scattered over various functions, and so
> > I would like to address them in separate replies.
> > 
> > First, I'd like to discuss sdhci_[add|remove]_host().
> > 
> > On Fri, Aug 21, 2020 at 05:08:32PM +0300, Adrian Hunter wrote:
> >> On 10/07/20 2:10 pm, Ben Chuang wrote:
> >>> From: Ben Chuang <ben.chuang@genesyslogic.com.tw>
> >>>
> >>> In this commit, UHS-II related operations will be called via a function
> >>> pointer array, sdhci_uhs2_ops, in order to make UHS-II support as
> >>> a kernel module.
> >>> This array will be initialized only if CONFIG_MMC_SDHCI_UHS2 is enabled
> >>> and when the UHS-II module is loaded. Otherwise, all the functions
> >>> stay void.
> >>>
> >>> Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw>
> >>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>> ---
> > 
> >  (snip)
> > 
> >>>  		if (intmask & (SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE)) {
> >>>  			u32 present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
> >>>  				      SDHCI_CARD_PRESENT;
> >>> @@ -4717,6 +4812,14 @@ int sdhci_setup_host(struct sdhci_host *host)
> >>>  		/* This may alter mmc->*_blk_* parameters */
> >>>  		sdhci_allocate_bounce_buffer(host);
> >>>  
> >>> +	if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> >>> +	    host->version >= SDHCI_SPEC_400 &&
> >>> +	    sdhci_uhs2_ops.add_host) {
> >>> +		ret = sdhci_uhs2_ops.add_host(host, host->caps1);
> >>> +		if (ret)
> >>> +			goto unreg;
> >>> +	}
> >>> +
> >>
> >> I think you should look at creating uhs2_add_host() instead
> >>
> >>>  	return 0;
> >>>  
> >>>  unreg:
> >>> @@ -4738,6 +4841,8 @@ void sdhci_cleanup_host(struct sdhci_host *host)
> >>>  {
> >>>  	struct mmc_host *mmc = host->mmc;
> >>>  
> >>> +	/* FIXME: Do we have to do some cleanup for UHS2 here? */
> >>> +
> >>>  	if (!IS_ERR(mmc->supply.vqmmc))
> >>>  		regulator_disable(mmc->supply.vqmmc);
> >>>  
> >>> @@ -4766,6 +4871,14 @@ int __sdhci_add_host(struct sdhci_host *host)
> >>>  		mmc->cqe_ops = NULL;
> >>>  	}
> >>>  
> >>> +	if ((mmc->caps & MMC_CAP_UHS2) && !host->v4_mode) {
> >>> +		/* host doesn't want to enable UHS2 support */
> >>> +		mmc->caps &= ~MMC_CAP_UHS2;
> >>> +		mmc->flags &= ~MMC_UHS2_SUPPORT;
> >>> +
> >>> +		/* FIXME: Do we have to do some cleanup here? */
> >>> +	}
> >>> +
> >>>  	host->complete_wq = alloc_workqueue("sdhci", flags, 0);
> >>>  	if (!host->complete_wq)
> >>>  		return -ENOMEM;
> >>> @@ -4812,6 +4925,9 @@ int __sdhci_add_host(struct sdhci_host *host)
> >>>  unled:
> >>>  	sdhci_led_unregister(host);
> >>>  unirq:
> >>> +	if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> >>> +	    sdhci_uhs2_ops.remove_host)
> >>> +		sdhci_uhs2_ops.remove_host(host, 0);
> >>>  	sdhci_do_reset(host, SDHCI_RESET_ALL);
> >>>  	sdhci_writel(host, 0, SDHCI_INT_ENABLE);
> >>>  	sdhci_writel(host, 0, SDHCI_SIGNAL_ENABLE);
> >>> @@ -4869,6 +4985,10 @@ void sdhci_remove_host(struct sdhci_host *host, int dead)
> >>>  
> >>>  	sdhci_led_unregister(host);
> >>>  
> >>> +	if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> >>> +	    sdhci_uhs2_ops.remove_host)
> >>> +		sdhci_uhs2_ops.remove_host(host, dead);
> >>> +
> >>
> >> I think you should look at creating uhs2_remove_host() instead
> > 
> > You suggest that we will have separate sdhci_uhs2_[add|remove]_host(),
> > but I don't think it's always convenient.
> > 
> > UHS-II capable host will be set to call sdhci_uhs2_add_host() explicitly,
> > but we can't do that in case of pci and pltfm based drivers as they utilize
> > common helper functions, sdhci_pci_probe() and sdhci_pltfm_register(),
> > respectively.
> 
> sdhci-pci has an add_host op
> 
> sdhci_pltfm_init can be used instead of sdhci_pltfm_register
> 
> 
> > Therefore, we inevitably have to call sdhci_uhs2_add_host() there.
> > 
> > If so, why should we distinguish sdhci_uhs2_add_host from sdhci_uhs_add_host?
> > I don't see any good reason.
> > Moreover, as a result, there exists a mixed usage of sdhci_ interfaces
> > and sdhci_uhs2_ interfaces in sdhci-pci-core.c and sdhci-pltfm.c.
> > 
> > It sounds odd to me.
> 
> It is already done that way for cqhci.

Okay, if it is your policy, I will follow that.
Then, I'm going to add
- remove_host field to struct sdhci_pci_fixes
- a controller specific helper function to each driver (only pci-gli for now)
  even though it looks quite generic.

  sdhci_gli_[add|remove]_host(struct sdhci_pci_slot *slot)
  {
      return sdhci_uhs2_[add|remove]_host(slot->host);
  }

# Or do you want to create a file like sdhci-uhs2-pci.c for those functions?

-Takahiro Akashi

> > 
> > -Takahiro Akashi
> > 
> > 
> >>
> >>>  	if (!dead)
> >>>  		sdhci_do_reset(host, SDHCI_RESET_ALL);
> >>>  
> >>>
> >>
> 

  reply	other threads:[~2020-09-17  2:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 11:10 [RFC PATCH V3 12/21] mmc: sdhci: UHS-II support, add hooks for additional operations Ben Chuang
2020-08-21 14:08 ` Adrian Hunter
2020-09-16  8:05   ` AKASHI Takahiro
2020-09-16 10:00     ` Adrian Hunter
2020-09-17  2:31       ` AKASHI Takahiro [this message]
2020-09-17  4:52         ` Adrian Hunter
2020-09-17  5:16           ` AKASHI Takahiro
2020-09-17  5:12   ` AKASHI Takahiro
2020-09-17 10:12     ` Ben Chuang
2020-09-18  1:15       ` AKASHI Takahiro
2020-09-18 10:27         ` Ben Chuang
2020-09-24  9:46           ` AKASHI Takahiro
2020-09-25  7:59             ` Ben Chuang
2020-09-18  6:38   ` AKASHI Takahiro
2020-09-18 10:50     ` Ben Chuang
2020-09-24  9:57       ` AKASHI Takahiro
2020-09-25  7:55         ` Ben Chuang
2020-09-24  9:35   ` AKASHI Takahiro
2020-09-25  9:02     ` Adrian Hunter

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=20200917023113.GB3071249@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=ben.chuang@genesyslogic.com.tw \
    --cc=benchuanggli@gmail.com \
    --cc=greg.tu@genesyslogic.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.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.