From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AF07C433FE for ; Thu, 10 Mar 2022 08:56:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234989AbiCJI5o (ORCPT ); Thu, 10 Mar 2022 03:57:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233910AbiCJI5n (ORCPT ); Thu, 10 Mar 2022 03:57:43 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6D72137589 for ; Thu, 10 Mar 2022 00:56:40 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id m11-20020a17090a7f8b00b001beef6143a8so4620589pjl.4 for ; Thu, 10 Mar 2022 00:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NstX+8MhKuPX15Q3Cn5v2S4ksEEmS5rE+lUKfrbEsw8=; b=ufeSvo1sQx1GrTcOvT9d/3N9WKIDvvcuLEVv1XMrqvjhNBOsb3S/D/ywRVvLpDZ1gx VjEh9QwiiHECtppmL9I+hOaTMzJh3wxJjQPkW+VJp5YH26L1iTXBmdntDz71yum+n6OJ RxUVf5/0+z24LAy6r63oQ625LtXWdR8udDYJ5KrYgyskXkigkfZ8+x9ZzNdaqF7ZcQI0 VIE1/S63xfQeOsXDnjLhyXCAX2N/NfRoh72LuaGt/m9Bg2OgGG14487eBvFnY+EzFBuX hLXo2J6rDiipQjbyobC+TjSea1ee2FTtHySmQ8DJcD7+7sbpIWlG4L1kTC7evymD/aYR WLTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NstX+8MhKuPX15Q3Cn5v2S4ksEEmS5rE+lUKfrbEsw8=; b=FT+QgLmvGo8LLsz80xDBAa2IiPr+FFO/gqxrLQoxuQcWl0wA6mbPioNcohLbWzsyr/ Wq0Nrwa49MfWEwBv0f6Mpb8622pYMVhRb8AkPqhS02OrvF6BHij6fdM8JXkxZ7vfTbcI PeOWKox+LRLLnH+dpoGTm3waGB2cw60PXKpkb2waOQMA4jblxMzT36131aTVFdBuPsLQ 5iqTQm4bW055EjvxCFBU45E+lJ/aviKBGgnjAR8PKV0+4ik145z+huj33xhDp11zA8qc hh2X8uoDWKcX0H02f5OX2rUipLiqCB/Xwe+jUFh00eRmuA6HL0Ma/oVKqZpc2kfBcsAR Lguw== X-Gm-Message-State: AOAM531O1ZRU3qiTWu1Lxt7Ypmhcp98rQYG9H3/Sc9hXvhJd3QeYCKag 0UST+bK1bvESWhHh77dPITab X-Google-Smtp-Source: ABdhPJzpvBqjItWH6Y5efU0r6nSLlA/IznpzdKlRZVZXLRVaXJg0uUl5/M6ZsuV1UbrxfGvYcDzjcw== X-Received: by 2002:a17:903:22cd:b0:151:a884:d444 with SMTP id y13-20020a17090322cd00b00151a884d444mr3855855plg.141.1646902600187; Thu, 10 Mar 2022 00:56:40 -0800 (PST) Received: from thinkpad ([117.193.208.22]) by smtp.gmail.com with ESMTPSA id rm8-20020a17090b3ec800b001bcd57956desm5149383pjb.51.2022.03.10.00.56.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Mar 2022 00:56:39 -0800 (PST) Date: Thu, 10 Mar 2022 14:26:32 +0530 From: Manivannan Sadhasivam To: Serge Semin Cc: Frank Li , Serge Semin , gustavo.pimentel@synopsys.com, hongxing.zhu@nxp.com, l.stach@pengutronix.de, linux-imx@nxp.com, linux-pci@vger.kernel.org, dmaengine@vger.kernel.org, lznuaa@gmail.com, vkoul@kernel.org, lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com, bhelgaas@google.com, shawnguo@kernel.org Subject: Re: [PATCH v3 1/6] dmaengine: dw-edma: fix dw_edma_probe() can't be call globally Message-ID: <20220310085632.GE4869@thinkpad> References: <20220307224750.18055-1-Frank.Li@nxp.com> <20220309133940.3le2ma24aqlhips4@mobilestation> <20220309181233.GC134091@thinkpad> <20220309190123.dnivojpqhl52o5vc@mobilestation> <20220310062242.GB4869@thinkpad> <20220310084112.2vhvvnl6pmlkfg36@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220310084112.2vhvvnl6pmlkfg36@mobilestation> Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Mar 10, 2022 at 11:41:12AM +0300, Serge Semin wrote: > On Thu, Mar 10, 2022 at 11:52:42AM +0530, Manivannan Sadhasivam wrote: > > On Wed, Mar 09, 2022 at 10:01:23PM +0300, Serge Semin wrote: > > > > [...] > > > > > > I'm afraid that this will not work for all cases (unless I miss something). As > > > > Zhi Li pointed out, there are places where only chip pointer will be passed and > > > > we'd need to extract the private data (dw_edma) from it. > > > > > > > > Tbh I also considered your idea but because of the above mentioned issue and > > > > also referring to other implementations like gpiochip, I settled with Frank's > > > > idea of copying the fields. > > > > > > What places are these? I see the only obstacle is the dw_edma_remove() > > > method. But it's easily fixable. > > > > Yeah, right. I overlooked that part. > > > > > Except that, everything else is more > > > or less straightforward (just a few methods need to have prototypes > > > converted to accepting dw_edma instead dw_edma_chip). > > > > > > In order to make the code design more coherent, we need to split up > > > private data and device/platform info. As I see it dw_edma_chip is > > > nothing but a chip info data. The eDMA driver is supposed to mainly > > > use and pass it's private data, not the platform info. It will greatly > > > improve the code readability and maintainability. Such approach will > > > also prevent a temptation of adding new private data fields into the > > > dw_edma_chip structure since reaching the pointer to dw_edma will be > > > much easier that getting the dw_edma_chip data. In this case > > > dw_edma_chip will be something like i2c_board_info in i2c. > > > > > > Ideally dw_edma_chip could be a temporarily defined device info, which > > > memory after the dw_edma_probe() method invocation could be freed. But > > > in order to implement that we'd need a bit more modifications > > > introduced. > > > > > > > > While at it, we should also consider adding an ops structure for passing the > > callbacks from controller drivers. Currently the eDMA driver has the callbacks > > defined in v0-core.c but it is used directly instead of as a callback. > > Are you saying about DBI/Native IOs? If so seems reasonable. Though in > my case it isn't required.) The only problem was a dword-aligned access, > which has been created in the DW eDMA driver by default. > It is not causing any problem but it doesn't look correct to me. Btw, do you have a patch for DWORD access? If so, please share. We are also facing the problem and like to see how to are handling it. Thanks, Mani > -Sergey > > > > > This should anyway needs to be fixed when another version of the IP get's added. > > > > Thanks, > > Mani