Received: by 10.192.165.156 with SMTP id m28csp1742734imm; Tue, 17 Apr 2018 04:56:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/YyFPQ3Jh1J4MZJaqGJYC2utJ00e70N7ugltSoK623lDXEdvRw1weAVSg9zLPckCqdYHYR X-Received: by 2002:a17:902:8ec4:: with SMTP id x4-v6mr1746126plo.391.1523966187214; Tue, 17 Apr 2018 04:56:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523966187; cv=none; d=google.com; s=arc-20160816; b=gRjmSV2ARAsbRTTep6kDYIf3QrJoju5qz6gn2WCtlkjIlbFm77JdKAfAqztlsw/yxS cHObjYH3+50CIj2CDQVVXKa6cHG7ptXviq0hh/6o80l5OYnw6bH6Qt/xx30JbWNMzWh+ EDWRizcN2Pisno60xM+b8N3FDveHWqSxxS/HrTT9tsIhkH9lcq6HA50VER+lqn/KtDvO i2S24/rC93AP5H+Y7i3vcGpZG5YMQkl+X3X/erHI+RXPeiIIshz4b/p9oO5phpx7I6Be FnFp04lh/c3GJxUKVBKnb9q59D4iPH5cn81dmmTXPdv4qgcBwn7tjVLS6eHJo/1U0aeM 6qOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=sCqB8U3k4bWyxa9xuaIxuNBxZud3X/8YsOOskulduVs=; b=FNPgVvbeKiefwbHQ33SFq4rERJiuIb3uNUfgsda6BMTV0Ohci/3+ObBD+bahLgPi9d WbaGD8jdk2rIlsub4vpHVLfc2iCOthAeLClNhQ9FABo/lGemj4VTmd1IT3HJe2JR9dkW jldKhvGNNmfn7s/ZKClQORns1I8lv1ZNixV6o8WDFoGZUeDnqibWmfUe5XsEJBfCQROE eaHXd1J00gj0Qg8HSiYj7Kh/YYVS+ssW9epCuUq67XhcfruHnfy14ePA/tOQlBaFpnkz U0z8WwnonMw2aEr5GvE6NEKMtAkJSJqTEVL0bP//GQvRyWiH7H1CWW2lcY2WxEB6sMHs /dew== 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 c66si11575423pga.494.2018.04.17.04.56.12; Tue, 17 Apr 2018 04:56:27 -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; 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 S1752732AbeDQLzF (ORCPT + 99 others); Tue, 17 Apr 2018 07:55:05 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:61271 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752546AbeDQLzD (ORCPT ); Tue, 17 Apr 2018 07:55:03 -0400 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w3HBrnHk008623; Tue, 17 Apr 2018 13:54:35 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2hbd6cxjb8-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Apr 2018 13:54:35 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8D59034; Tue, 17 Apr 2018 11:54:34 +0000 (GMT) Received: from Webmail-eu.st.com (gpxdag5node6.st.com [10.75.127.79]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3BE582AA6; Tue, 17 Apr 2018 11:54:34 +0000 (GMT) Received: from [10.48.0.167] (10.75.127.123) by GPXDAG5NODE6.st.com (10.75.127.79) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Apr 2018 13:54:33 +0200 Subject: Re: [PATCH v4 2/6] mfd: stm32-timers: add support for dmas To: Lee Jones CC: , , , , , , , , , , , References: <1523895561-4073-1-git-send-email-fabrice.gasnier@st.com> <1523895561-4073-3-git-send-email-fabrice.gasnier@st.com> <20180417071250.yhgl7c7apn7w53xf@dell> <34e30463-6236-a8e4-fd1f-6217612375eb@st.com> <20180417101009.do42adq24ltgw4lt@dell> From: Fabrice Gasnier Message-ID: <72e211c8-7342-7722-e3e8-75442560bdfe@st.com> Date: Tue, 17 Apr 2018 13:54:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180417101009.do42adq24ltgw4lt@dell> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.123] X-ClientProxiedBy: GPXDAG1NODE5.st.com (10.75.127.66) To GPXDAG5NODE6.st.com (10.75.127.79) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-17_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/17/2018 12:10 PM, Lee Jones wrote: > On Tue, 17 Apr 2018, Fabrice Gasnier wrote: > >> On 04/17/2018 09:12 AM, Lee Jones wrote: >>> On Mon, 16 Apr 2018, Fabrice Gasnier wrote: >>> >>>> STM32 Timers can support up to 7 DMA requests: >>>> - 4 channels, update, compare and trigger. >>>> Optionally request part, or all DMAs from stm32-timers MFD core. >>>> >>>> Also add routine to implement burst reads using DMA from timer registers. >>>> This is exported. So, it can be used by child drivers, PWM capture >>>> for instance (but not limited to). >>>> >>>> Signed-off-by: Fabrice Gasnier >>>> Reviewed-by: Benjamin Gaignard >>>> --- >>>> Changes in v4: >>>> - Lee's comments: Add kerneldoc header, better format comments. >>>> Changes in v3: >>>> - Basically Lee's comments: >>>> - rather create a struct stm32_timers_dma, and place a reference to it >>>> in existing ddata (instead of adding priv struct). >>>> - rather use a struct device in exported routine prototype, and use >>>> standard helpers instead of ddata. Get rid of to_stm32_timers_priv(). >>>> - simplify error handling in probe (remove a goto) >>>> - comment on devm_of_platform_*populate() usage. >>>> >>>> Changes in v2: >>>> - Abstract DMA handling from child driver: move it to MFD core >>>> - Add comments on optional dma support >>>> --- >>>> drivers/mfd/stm32-timers.c | 227 ++++++++++++++++++++++++++++++++++++++- >>>> include/linux/mfd/stm32-timers.h | 32 ++++++ >>>> 2 files changed, 257 insertions(+), 2 deletions(-) >>> >>> [...] >>> >>>> diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h >>>> index 2aadab6..a04d7a1 100644 >>>> --- a/include/linux/mfd/stm32-timers.h >>>> +++ b/include/linux/mfd/stm32-timers.h >>>> @@ -8,6 +8,8 @@ >>>> #define _LINUX_STM32_GPTIMER_H_ >>>> >>>> #include >>>> +#include >>>> +#include >>>> #include >>> >>> [...] >>> >>>> +struct stm32_timers_dma; >>>> + >>>> struct stm32_timers { >>>> struct clk *clk; >>>> struct regmap *regmap; >>>> u32 max_arr; >>>> + struct stm32_timers_dma *dma; /* Only to be used by the parent */ >>> >>> I'm confused. I thought the point of putting this comment in was so >>> that you could place the definition of 'stm32_timers_dma' and remove >>> the forward declaration? >> >> Hi Lee, >> >> Sorry, if I miss-understood the point then. So, do you wish I both: >> - move the full struct definition in above header ? >> - and keep this comment ? > > That was what I thought we agreed. Hi Lee, Ok, I'll update this in v5. BTW, I'll fix warning reported by Dan: > smatch warnings: drivers/mfd/stm32-timers.c:165 stm32_timers_dma_burst_read() warn: warn: dma_mapping_error() doesn't return an error code Thanks, Fabrice > However, I left the final decision to you. If you do not think this > is a reasonable i.e. the comment alone will not be enough to prevent > people from abusing the API, then leave it as it is. > > Bear in mind that I think this introduces a build dependency on the > MFD driver for *each and every* other source file which includes this > header. If you choose the current solution, you will need to handle > that accordingly. > >> +/** >> + * struct stm32_timers_dma - STM32 timer DMA handling. >> + * @completion: end of DMA transfer completion >> + * @phys_base: control registers physical base address >> + * @lock: protect DMA access >> + * @chan: DMA channel in use >> + * @chans: DMA channels available for this timer instance >> + */ >> +struct stm32_timers_dma { >> + struct completion completion; >> + phys_addr_t phys_base; >> + struct mutex lock; >> + struct dma_chan *chan; >> + struct dma_chan *chans[STM32_TIMERS_MAX_DMAS]; >> +}; >> >> This will basically expose the struct to child drivers. But I'm ok if >> you think this is acceptable. >> >> I can send a V5 if you wish... >> >> Please advise, >> Best regards, >> Fabrice >> >>> >>>> }; >>>> + >>>> +int stm32_timers_dma_burst_read(struct device *dev, u32 *buf, >>>> + enum stm32_timers_dmas id, u32 reg, >>>> + unsigned int num_reg, unsigned int bursts, >>>> + unsigned long tmo_ms); >>>> #endif >>> >