Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp662225imm; Fri, 13 Jul 2018 04:18:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfs5NiDkCAvkNY/fF2XF4p5t80sTB75J2Gs+6hag1du4WcUG59n6TIMO72Z92n3ZeQ2JJiH X-Received: by 2002:a17:902:b594:: with SMTP id a20-v6mr727035pls.140.1531480723563; Fri, 13 Jul 2018 04:18:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531480723; cv=none; d=google.com; s=arc-20160816; b=j57QVycpOUxBm5vV9mmHHS8duclFqe/wf2+2DH1ofh53x0RwLllpP8jbBa9nm1rTK5 JKySG2BGlnX8AQ1Q9AQgpFQ/i/00lIwomTWJsTszJdXhSJdivUx4dgAuI35goaov6IG2 O8eg1m2gvrGRBczNSNGRObzfZ9y4beR+ulvJp80ohqs0Q2/RHgnNqZ06OGbVucndGsxQ dIwCaX9UX/MrSpUobegyFvG19shDriejw0OrWtccziUNZ8RTmaJvkQYxMK7jAGs4abM6 nFAB8xXe6EmK0i0g6KWWDtLI6ZLboaXGHv5KLOlEG1acu7LVOkhuyacj6OATBjROhHcr pNng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=NMlsZM3ysw/cOF3r/wFkFGCV4kUI9hWIOd7QpGBD9A0=; b=qMMSNuDHULO5VJ6s8O2XG4hrMtHfjgxV1QaQaI40jHbgJkKpKzrqzMbVqGyPc4RNX7 l6SWKAV3Nm9jWwtAaVjHLqCXM74lVDhFnq3jJ+cw6HAOBQeG9O4PIQ4pzWIJkCC5yyS8 dtF1UZ6hw6dnvY3l24COf0MCFMiqaw3XGPI5wkO22YG88NBobl/sqySjWHQ+xTOM+f2x b0JnSrQgiWUts8YZTLzGO7QY7i0m29wuGLE4yjpzDVbsfgmIXGmciYrTpNSLQtN4h/DL p7+G/f3q7S8kN2AZVQ6Ru4DkEF3+AXYywK6Fdkaj+3v0d1WBqmhj1+ho+0MbdYJdTXHr GWUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="NuXVq/GT"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u22-v6si23038425plq.135.2018.07.13.04.18.28; Fri, 13 Jul 2018 04:18:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="NuXVq/GT"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729625AbeGMLcE (ORCPT + 99 others); Fri, 13 Jul 2018 07:32:04 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:42937 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727283AbeGMLcD (ORCPT ); Fri, 13 Jul 2018 07:32:03 -0400 Received: by mail-io0-f195.google.com with SMTP id r24-v6so30980076ioh.9 for ; Fri, 13 Jul 2018 04:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NMlsZM3ysw/cOF3r/wFkFGCV4kUI9hWIOd7QpGBD9A0=; b=NuXVq/GTZoMXPgCSvTH7zYu2y0zDRjGBq2R6C865g970+62EhEIyMCzTan7cNb+rqG 3xxaCEwfioJbHX6zgpiRIG8iCpfHchQK4OL20EdC6PcTNmUWj1jS6SCBteeqtbWHo2yU D9YXEFwmes1a47/7dj7Ks6uAoVXxf7cmXQHPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NMlsZM3ysw/cOF3r/wFkFGCV4kUI9hWIOd7QpGBD9A0=; b=H8nhLW3+1gMbsvezp//7Wwmg3M9KbH7MEFnXl28Ezv5lJ9Axja8CskiLRPCTfIBlAh bvcBg13pWMU3/wgAULS3tnktFq693++2DwzklX3O9U+7AeC/1zQp9Q0kcoEZZeE6P7gC 552QJN6fdkxRXCjcmbby3AD0/aEdfIDJQOe2itiO34Q6kXIRjUXqJKCNS8vumClmsWN2 AX51usneTfcswQwzIVItW/Uk1YyYqK0wioDHJbxwOyBOsgINNF+0smWVRD2QPDEu6ecb Gro2hr1CyT8Uxy1mO028ecnPYXNtOefPDSYaxtn8yoAOaDBWES5sJLPhHdyfzH+vlWO7 f60Q== X-Gm-Message-State: APt69E2vtt5wBWNoSnCoe6SYMjha7Ifjs4dKQEUqdUTsqVeBoekCJIcp NTWDE9Aa4nkSogAqiNpv/xrFx/kVF93oUKmqHj4iiA== X-Received: by 2002:a6b:e403:: with SMTP id u3-v6mr29645605iog.131.1531480669863; Fri, 13 Jul 2018 04:17:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:818f:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 04:17:49 -0700 (PDT) In-Reply-To: References: <1528809280-31116-1-git-send-email-ludovic.Barre@st.com> <1528809280-31116-3-git-send-email-ludovic.Barre@st.com> From: Ulf Hansson Date: Fri, 13 Jul 2018 13:17:49 +0200 Message-ID: Subject: Re: [PATCH 02/19] mmc: mmci: merge qcom dml feature into mmci dma To: Ludovic BARRE Cc: Rob Herring , Maxime Coquelin , Alexandre Torgue , Gerald Baeza , Linux ARM , Linux Kernel Mailing List , devicetree@vger.kernel.org, "linux-mmc@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11 July 2018 at 17:19, Ludovic BARRE wrote: > > > On 07/05/2018 05:26 PM, Ulf Hansson wrote: >> >> On 12 June 2018 at 15:14, Ludovic Barre wrote: >>> >>> From: Ludovic Barre >>> >>> 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 >>> --- >>> 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. [...] Kind regards Uffe