Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5924903ybv; Tue, 18 Feb 2020 06:35:02 -0800 (PST) X-Google-Smtp-Source: APXvYqysegmX1NO0L/q6y+vpiH2m8l4TPwhbFOOTgfxUcimJ7fAy16Z/2Zja/Elj4vY/+dUFCOyO X-Received: by 2002:a05:6808:98e:: with SMTP id a14mr1358686oic.8.1582036502487; Tue, 18 Feb 2020 06:35:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582036502; cv=none; d=google.com; s=arc-20160816; b=XPvKHBWdvZcHO3xAerQ5RZv01hkobVJwq+0Yfs6MGUZdQFZNDBr1x4BTo1kKlSfAsg tWKuJY8vFMGToLcyNdPL5e4OdgF80LE1dZ6O77FgIOB/7+rqArz25TZRITVI9XFHekYT YQHtoeDXMJuJgkyS/WT+3YDvddoP6lcBusoveJBF/21z1nTdeHtXD7MtMckfQ3VIv1tL D1yBbInY8oBD/BVQIso73V+Ba8iOSDGc5B91ccW50N0EQo4z2ZAaue+HTlr2FL2JzIkC 5I/jgGBtG+W0BclM0aIwLow1cc6AApfsHnJs4NpGEP5ixAT3NCz+76lHD0z5ruSggdZJ I9aQ== 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 :in-reply-to:references:mime-version; bh=KOIXE4bIVTMtMSJ4nNeYGItwymQm7+mx4c3tdkeHFNA=; b=Mvgds89cYYYcu6QQpEF/SYfmtNn/yT09rUzEYecxz68Dm5bPF3Yg8QkW4iQqCi0xr3 tbpghObR6/LpslebLbzmVkQieRn8d9aLXjF0bDLKBC4Us9Z3xv3TuWg5QAixXaKCIfgH /kzhko2uCxkZQLbNLJylHrcjhPW4jks1wb7vnkZ1XlM403bWEwyg4mVMDfqlwJOQq8Zc +vfcXrhpJAj0XEPLipTG5Uk9k68DZzqF4wHXE0nWYYTD1DcL89CDI9FI/jVz9HLnplkV 1hdFcCyiqxXB9eMgAmKj3RtPAuBYlssYg6jM7oOwaMNUieFcP/8WRT7kJgxm4aEgO1JU a6aA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v11si1756091otp.279.2020.02.18.06.34.50; Tue, 18 Feb 2020 06:35:02 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726667AbgBROe2 (ORCPT + 99 others); Tue, 18 Feb 2020 09:34:28 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:60043 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbgBROe1 (ORCPT ); Tue, 18 Feb 2020 09:34:27 -0500 Received: from mail-qk1-f174.google.com ([209.85.222.174]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N17cq-1jRTqs37es-012Zsb; Tue, 18 Feb 2020 15:34:24 +0100 Received: by mail-qk1-f174.google.com with SMTP id c188so19653118qkg.4; Tue, 18 Feb 2020 06:34:24 -0800 (PST) X-Gm-Message-State: APjAAAXU8S9gsbnFNkQ7k1CdHe6e5fnkN0RRBjLBv3sSruTQGuqg8jAB aPXnEnbjH+BiH6jq/jjsu44a9/I0EHfcFlHNEtM= X-Received: by 2002:a05:620a:909:: with SMTP id v9mr18633385qkv.138.1582036463546; Tue, 18 Feb 2020 06:34:23 -0800 (PST) MIME-Version: 1.0 References: <20200131135009.31477-1-manivannan.sadhasivam@linaro.org> <20200131135009.31477-12-manivannan.sadhasivam@linaro.org> <20200217164751.GA7305@Mani-XPS-13-9360> <20200218055142.GA29573@Mani-XPS-13-9360> In-Reply-To: <20200218055142.GA29573@Mani-XPS-13-9360> From: Arnd Bergmann Date: Tue, 18 Feb 2020 15:34:06 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 11/16] bus: mhi: core: Add support for data transfer To: Manivannan Sadhasivam Cc: gregkh , smohanad@codeaurora.org, Jeffrey Hugo , Kalle Valo , Bjorn Andersson , hemantk@codeaurora.org, linux-arm-msm , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:wHI0ayzfTGVitXbd/Vd26MMT06cd2aWO16fIFCN0Y/yUDOmnBRF 5zcgc+uC2DC/LuoEs8q4WeD7Gfdg8Vo2BAMsvmgihyO5h4BqUqsmsN08rBoYwkGLgn5uWe0 KnvXjOyJ62B+8VHdmzln0tYswe9saWTE2g60i24hLHV08fub/pfdQbYXNo5wtaP8IdqZN0G R+mm7UMfzMAIbMrb4mkgw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Se8YxxOWKU8=:vaNZusZ/eh0dHzLXNBJni/ W6VFub7iImA0LrzCNiGhs9nxX0ilhRMpX4A0YvCUwGA7gnU81VL8hf5pPY341QdIT1HnvdyLZ sQYWPP4Rg5MigIh7AjCeYCS1P6cdv0xsBNmhkcBQ5euLQm2pndL47BkOSeMAT76nqEAOFAAhg 6tRdj5ZBMBDomrTez4g9j4k8/FRTZFp+vDp+/rB7EHgcf6+/E1dovSiUysY51e7ocnVeLUNkt VHjXjefgFgmbRkPoI2fLYdElDcVmDuKTG5P1kQwezq+L4Z/OV3ride6gSNyh+yg/wbvpfIn62 ISrQWJIkqaB9AjhrYIxZGzrzJeVFO69F0sHY5Mn8LjflyE/htRnTErEwqnLG8k3uXV4Tgc2Bq 665lxJSbndA24DSc0piN5qLfsh0YqWDrQUWw0If6FDUKQ1O9GcWt/6TlheDyO1YE1+AbjObGS annJDdxehHfvA1RDrhoa5BwrhZ/O8cwl6kfvDdouJHLbwkSqJp0RJVoQse7HXimlxfgYMat2R 7Fzm1god3LR55LAhUrq0BJkgkMbV9Ms0ZptS/eFXYUxtH3M8WN+gxgmWjG9Q1ihFJAvI+T+0w 3UK14UIO4+r8Z31hz+vZ8miJWxN+v3uzqbEWNignspTkYdcP3DbT7QtX6mmOjvI9WXICTgUOa oSNO+kVvQgDau1gGTMgZFkA6L8gg35EG0f7grdKn45gywsULQh2R/fj6zasbzQMbnJEBY4sRM oSj8F2kqZ7SPi630QV0/7Q44oDFyvHBqDV14NOXF2HewWuhfbagkn0VCnnQZdW8W9uUi6KhFZ kVde7xqr19/qzLXpa4fHFrNfXcDWXILsdlXzMWdYu8LZtl3pqk= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 18, 2020 at 6:51 AM Manivannan Sadhasivam wrote: > On Mon, Feb 17, 2020 at 10:17:51PM +0530, Manivannan Sadhasivam wrote: > > On Mon, Feb 17, 2020 at 05:13:37PM +0100, Arnd Bergmann wrote: > > > On Fri, Jan 31, 2020 at 2:51 PM Manivannan Sadhasivam > > > wrote: > > > While looking through the driver to see how the DMA gets handled, I came > > > across the multitude of mhi_queue_* functions, which seems like a > > > layering violation to me, given that they are all implemented by the > > > core code as well, and the client driver needs to be aware of > > > which one to call. Are you able to lift these out of the common interface > > > and make the client driver call these directly, or maybe provide a direct > > > interface based on mhi_buf_info to replace these? > > > > > > > It sounds reasonable to me. Let me discuss this internally with Qcom guys to > > see if they have any objections. > > > > I looked into this in detail and found that the queue_xfer callbacks are tied > to the MHI channels. For instance, the callback gets attached to ul_chan (uplink > channel) and dl_chan (downlink channel) during controller registration. And > when the device driver calls the callback, the MHI stack calls respective queue > function for the relevant channel. For instance, > > ``` > int mhi_queue_transfer(struct mhi_device *mhi_dev, > enum dma_data_direction dir, void *buf, size_t len, > enum mhi_flags mflags) > { > if (dir == DMA_TO_DEVICE) > return mhi_dev->ul_chan->queue_xfer(mhi_dev, mhi_dev->ul_chan, > buf, len, mflags); > else > return mhi_dev->dl_chan->queue_xfer(mhi_dev, mhi_dev->dl_chan, > buf, len, mflags); > } > ``` > > If we use the direct queue API's this will become hard to handle. So, I'll keep > it as it is. Please have another look, this is exactly the part of the subsystem that I think should be replaced. For the caller, there should not be much difference between passing ul_chan/dl_chan or DMA_TO_DEVICE/DMA_FROM_DEVICE, so that too can be lifted to a higher level. Arnd