On 13 July 2018 at 15:08, Ludovic BARRE <ludovic.barre@xxxxxx> wrote: > > > On 07/13/2018 01:17 PM, Ulf Hansson wrote: >> >> On 11 July 2018 at 17:19, Ludovic BARRE <ludovic.barre@xxxxxx> wrote: >>> >>> >>> >>> On 07/05/2018 05:26 PM, Ulf Hansson wrote: >>>> >>>> >>>> On 12 June 2018 at 15:14, Ludovic Barre <ludovic.Barre@xxxxxx> wrote: >>>>> >>>>> >>>>> From: Ludovic Barre <ludovic.barre@xxxxxx> >>>>> >>>>> This patch integrates qcom dml feature into mmci_dma file. >>>>> Qualcomm Data Mover lite/local is already a variant of mmci dmaengine. >>>>> >>>>> Signed-off-by: Ludovic Barre <ludovic.barre@xxxxxx> >>>>> --- >>>>> drivers/mmc/host/Makefile | 1 - >>>>> drivers/mmc/host/mmci.c | 1 - >>>>> drivers/mmc/host/mmci.h | 35 ++++++++ >>>>> drivers/mmc/host/mmci_dma.c | 135 ++++++++++++++++++++++++++++- >>>>> drivers/mmc/host/mmci_qcom_dml.c | 177 >>>>> --------------------------------------- >>>>> drivers/mmc/host/mmci_qcom_dml.h | 31 ------- >>>>> 6 files changed, 169 insertions(+), 211 deletions(-) >>>>> delete mode 100644 drivers/mmc/host/mmci_qcom_dml.c >>>>> delete mode 100644 drivers/mmc/host/mmci_qcom_dml.h >>>> >>>> >>>> >>>> No, this is not the way to go. Instead I I think there are two options. >>>> >>>> 1) Keep mmci_qcom_dml.c|h and thus add new files for the stm32 dma >>>> variant. >>>> >>>> 2) Start by renaming mmci_qcom_dml.* to mmc_dma.* and then in the next >>>> step add the code for stm32 dma into the renamed files. >>>> >>>> I guess if there is some overlap in functionality, 2) may be best as >>>> it could easier avoid open coding. However, I am fine with whatever >>>> option and I expect that you knows what is best. >>> >>> >>> >>> After patch 01 & 05 comments: >>> I will try to define a mmci_ops which contain some functions pointer >>> called by mmci.c (core). >>> A variant defines its mmci_ops. >>> where do you define the specific function: >>> -in a single file, mmci-ops.c or other (for the name, I'm not inspirated) >>> -or in specific file for each variant mmci-qcom.c or mmci-stm32.c >>> >>> following the comment (above), I think we define a single file? >> >> >> If I understand the question, the problem is how we should assign the >> mmc host ops, which corresponds to the probed variant data!? >> >> I took a stub at it and posted two patches which I think you should be >> able to build upon. Please have a look. > > > I review your patch on mmci_host_ops and init, I agree with your series, > I was going in the same direction. > The comment above was on file organization, what do you prefer? > -a single file with: all callback and all mmci_host_ops of each variant > -or each variant in specific file (like sdhci): mmci-qcom.c | mmci-stm32.c The latter seems better. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
