On 24/09/20 12:35 pm, AKASHI Takahiro wrote:
> Adrian,
>
> This is, hopefully, my last reply to your comments on this patch#12.
>
> Regarding _request() and _send_command() (and more),
>
> 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@xxxxxxxxxxxxxxxxxxx>
>>>
>>> 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.
>>>
> (snip)
>
>> Again, this is what I want to avoid. I would like to have 3 kinds of functions:
>> - SD mode only
>> - UHS-II only
>> - SD functions with no UHS-II code, that can also be used by UHS-II
>> i.e. I don't want to mix UHS-II code and SD mode code in the same function.
>>
>> I think sdhci-uhs2.c should provide a request function and a send_command function.
>> I would start by removing everything you may not need, and then see if you have any problems.
>> e.g.
>>
>> void uhs2_request(struct mmc_host *mmc, struct mmc_request *mrq)
>> {
>> struct sdhci_host *host = mmc_priv(mmc);
>> struct mmc_command *cmd;
>> unsigned long flags;
>>
>> if (!host->uhs2_mode) {
>> sdhci_request(mmc, mrq);
>> return;
>> }
>>
>> spin_lock_irqsave(&host->lock, flags);
>> uhs2_send_command(host, cmd);
>> spin_unlock_irqrestore(&host->lock, flags);
>> }
>> EXPORT_SYMBOL_GPL(uhs2_request);
>>
>> For sdhci_prepare_data(), I would factor out the dma part, so
>>
>> static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
>> {
>> struct mmc_data *data = cmd->data;
>>
>> sdhci_initialize_data(host, data);
>>
>> sdhci_prepare_dma(host, data);
>>
>> sdhci_set_block_info(host, data);
>> }
>>
>> The you could export sdhci_initialize_data() and sdhci_prepare_dma() for uhs2.
>>
>>> }
>>>
>>> #if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
>>> @@ -1439,6 +1463,13 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
>>> u16 mode = 0;
>>> struct mmc_data *data = cmd->data;
>>>
>>> + if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
>>> + host->mmc->flags & MMC_UHS2_SUPPORT) {
>>> + if (sdhci_uhs2_ops.set_transfer_mode)
>>> + sdhci_uhs2_ops.set_transfer_mode(host, cmd);
>>> + return;
>>> + }
>>> +
>>
>> Once you provide uhs2_request() and uhs2_send_command(), the transfer mode setting can be done in sdhci-uhs2.c
>
> If I try to make changes as you suggested above, a lot of other uhs2-flavored
> functions will also be created due to calling dependency/sequences
> and for "completeness" compared to uhs counterparts.
> They probably include
> sdhci_uhs2_prepare_data()
> sdhci_uhs2_external_dma_prepare_data()
> sdhci_uhs2_send_command()
> sdhci_uhs2_send_command_try()
> sdhci_uhs2_send_tuning()
> sdhci_uhs2_request()
> sdhci_uhs2_request_atomic()
> sdhci_uhs2_thread_irq()
> sdhci_uhs2_irq()
> sdhci_uhs2_cmd_irq()
> sdhci_uhs2_finish_command()
> sdhci_uhs2_resume_host()
> __sdhci_uhs2_add_host()
> sdhci_uhs2_add_host()
> (Some may not be used under the current drivers.)
>
> In addition, a bunch of functions in sdhci.c will also have to be exported
> to uhs2 as "global" functions instead of "static."
>
> Is this all that you expect to see?
Yes. Add what you need.
