Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3416658pxu; Mon, 30 Nov 2020 02:40:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEkEurWuOYGISpdDx+AbRwufGvLy6mZbWIJIm6RVuuzQPHa/Vd0SMCMXwTGy8IKevC20o8 X-Received: by 2002:a17:906:3608:: with SMTP id q8mr20130804ejb.39.1606732817886; Mon, 30 Nov 2020 02:40:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606732817; cv=none; d=google.com; s=arc-20160816; b=bG9m/s1Gbo66GtWRgySDZZ95B/f0XkHtAJZepuChtlWJ41XbptaZgwu8HHbhzu4/Kc aP8QtBPZgLTDlwvq4+32sbR9NEgw3YSEXA3rTAK3h6SHackYQylrVeYwaFIuRwWmXIEV O1jLantpKhHW6ba23wJXQI/AZSn/y6W+Dszd7IQ9amqbeTcJGSa7VVw1S6Sv2qITnrbn f411eLdic4FVl22fbFUkTAUuIlkgzau1dn7H226890qZ7kmlyekpPMprIw6AQRMy+2Eg 7YjDdJh2F77YMFvwX9lcvnJKkuHU2QaPmsZ4EDktW/xwNoilDcQj6g4kDJ5O1Hy9zrb4 eeeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JhpB/t5kCjjYRTw+xINHPebhKoCjmMuMSHZrMIpoK54=; b=Qp3dy+RT7lTYFB1B9HAu09maILGxOiswhPMXB9goSg/z+TsjubeBEglbU+cs7+JwCZ yS8MUFI/Q/l9HyxYyqZWv68tyBKG5UWoTEoIEYeaQBZGVIVjolD5fmZaESrZG6fPnJYK mivzwrtpTO6Xae88SQtOeMySDQ9A7BB9KW/s2yU6RzvulOjffpsPywMWrvMtOKmAGwBf tnH4+jUypjluJYeXYTjb1ufu8GFFKYKHIoig0V8fiVDUGPeKA+UKNdGgkfrxzF/FIyXR 3AR0XaRrLhEdxBsTNLOiEkhjT7eiWgLa7KmSdbOea2xLERkXVW6qcJeYGPpG77ZT1cNd DO/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZurS9jYa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z41si11133355ede.250.2020.11.30.02.39.55; Mon, 30 Nov 2020 02:40:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZurS9jYa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728758AbgK3Kf5 (ORCPT + 99 others); Mon, 30 Nov 2020 05:35:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728748AbgK3Kf4 (ORCPT ); Mon, 30 Nov 2020 05:35:56 -0500 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBB9FC0613CF for ; Mon, 30 Nov 2020 02:35:10 -0800 (PST) Received: by mail-pj1-x1042.google.com with SMTP id l23so173849pjg.1 for ; Mon, 30 Nov 2020 02:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JhpB/t5kCjjYRTw+xINHPebhKoCjmMuMSHZrMIpoK54=; b=ZurS9jYa+SkfPr8aONBeaAoWbwdGYcdP319Zi7pFHcGkGWQD6suhIhZiM6hdXlNYJX NLWoXceltubUgVj5mFTsaGcWP+mqyNizBlqC3MjekPidqQ16FKtKMupb5yuJhRnsJcCc HgqlZGwdWIfHqbGt8E0uja48kJ+L7QIVOuj5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JhpB/t5kCjjYRTw+xINHPebhKoCjmMuMSHZrMIpoK54=; b=qD3jkfgOlacBenGHHkTQWfuCApOQwKXzQm1Lq8or0XMwcUqb/em7BUw9UMdBxFM7Th 5vRe3ANLSFt+815Z2nmMp5hU/pJlJ8fAnxPd3Fd3gNjNsDkgH5m/1mIpkDrWkqYW3CbF FvqNzFls0Pag/Pz2WuoVZy51BHIyMCs2qFUiH/U8WNXO4CoxhzkCnNfzxRFpcm2+nFFN wsEQ43gD/jJ8KOyWKqfU8Usg3SiJMwhZO2G197v718qog0+xv3S/W3F8TxrfWn37V4bv kkQX6xDr/OZUMT6G1DpA54+LDraBD9fAW0c5N2WbVHC2iF4jZjYk94yFERRE3EhMgMRH 5wkA== X-Gm-Message-State: AOAM532OkTaWvowVNcKGflgZymKr4GRuY7Pq6o4k3p9F//Iiss02pRW1 hZUtJ7DqKd6r0yrHzUQc2GmAqQ== X-Received: by 2002:a17:90a:3d0c:: with SMTP id h12mr26010674pjc.177.1606732510116; Mon, 30 Nov 2020 02:35:10 -0800 (PST) Received: from chromium.org ([2401:fa00:1:b:f693:9fff:fef4:a8fc]) by smtp.gmail.com with ESMTPSA id m18sm21844330pjl.41.2020.11.30.02.35.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Nov 2020 02:35:09 -0800 (PST) Date: Mon, 30 Nov 2020 18:35:05 +0800 From: Ikjoon Jang To: Crystal Guo Cc: p.zabel@pengutronix.de, robh+dt@kernel.org, matthias.bgg@gmail.com, devicetree@vger.kernel.org, yong.liang@mediatek.com, stanley.chu@mediatek.com, srv_heupstream@mediatek.com, seiya.wang@mediatek.com, linux-kernel@vger.kernel.org, fan.chen@mediatek.com, linux-mediatek@lists.infradead.org, yingjoe.chen@mediatek.com, s-anna@ti.com, linux-arm-kernel@lists.infradead.org Subject: Re: [v6,2/3] reset-controller: ti: introduce a new reset handler Message-ID: <20201130103505.GA3019533@chromium.org> References: <20200930022159.5559-1-crystal.guo@mediatek.com> <20200930022159.5559-3-crystal.guo@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200930022159.5559-3-crystal.guo@mediatek.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 10:21:58AM +0800, Crystal Guo wrote: > Introduce ti_syscon_reset() to integrate assert and deassert together. > If some modules need do serialized assert and deassert operations > to reset itself, reset_control_reset can be called for convenience. > > Such as reset-qcom-aoss.c, it integrates assert and deassert together > by 'reset' method. MTK Socs also need this method to perform reset. > > Signed-off-by: Crystal Guo Reviewed-by: Ikjoon Jang > --- > drivers/reset/reset-ti-syscon.c | 40 ++++++++++++++++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/drivers/reset/reset-ti-syscon.c b/drivers/reset/reset-ti-syscon.c > index a2635c21db7f..5d1f8306cd4f 100644 > --- a/drivers/reset/reset-ti-syscon.c > +++ b/drivers/reset/reset-ti-syscon.c > @@ -15,15 +15,22 @@ > * GNU General Public License for more details. > */ > > +#include > #include > #include > #include > +#include > #include > #include > #include > > #include > > +struct mediatek_reset_data { > + unsigned char *reset_bits; > + unsigned int reset_duration_us; > +}; > + > /** > * struct ti_syscon_reset_control - reset control structure > * @assert_offset: reset assert control register offset from syscon base > @@ -56,6 +63,7 @@ struct ti_syscon_reset_data { > struct regmap *regmap; > struct ti_syscon_reset_control *controls; > unsigned int nr_controls; > + const struct mediatek_reset_data *reset_data; > }; > > #define to_ti_syscon_reset_data(rcdev) \ > @@ -158,9 +166,29 @@ static int ti_syscon_reset_status(struct reset_controller_dev *rcdev, > !(control->flags & STATUS_SET); > } > > +static int ti_syscon_reset(struct reset_controller_dev *rcdev, > + unsigned long id) > +{ > + struct ti_syscon_reset_data *data = to_ti_syscon_reset_data(rcdev); > + int ret; > + > + if (data->reset_data) { > + ret = ti_syscon_reset_assert(rcdev, id); > + if (ret) > + return ret; > + usleep_range(data->reset_data->reset_duration_us, > + data->reset_data->reset_duration_us * 2); > + There are many users using assert() and deassert() seperately without any delay between them. If there's a timing requirement between assertion and deassertion, shouldn't there be a same amount of delay in assert? > + return ti_syscon_reset_deassert(rcdev, id); > + } else { > + return -ENOTSUPP; > + } > +} > + > static const struct reset_control_ops ti_syscon_reset_ops = { > .assert = ti_syscon_reset_assert, > .deassert = ti_syscon_reset_deassert, > + .reset = ti_syscon_reset, > .status = ti_syscon_reset_status, > }; > > @@ -182,7 +210,11 @@ static int ti_syscon_reset_probe(struct platform_device *pdev) > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > - list = of_get_property(np, "ti,reset-bits", &size); > + data->reset_data = of_device_get_match_data(&pdev->dev); > + if (data->reset_data) > + list = of_get_property(np, data->reset_data->reset_bits, &size); > + else > + list = of_get_property(np, "ti,reset-bits", &size); > if (!list || (size / sizeof(*list)) % 7 != 0) { > dev_err(dev, "invalid DT reset description\n"); > return -EINVAL; > @@ -217,8 +249,14 @@ static int ti_syscon_reset_probe(struct platform_device *pdev) > return devm_reset_controller_register(dev, &data->rcdev); > } > > +static const struct mediatek_reset_data mtk_reset_data = { > + .reset_bits = "mediatek,reset-bits", > + .reset_duration_us = 10, > +}; > + > static const struct of_device_id ti_syscon_reset_of_match[] = { > { .compatible = "ti,syscon-reset", }, > + { .compatible = "mediatek,syscon-reset", .data = &mtk_reset_data}, > { /* sentinel */ }, > }; > MODULE_DEVICE_TABLE(of, ti_syscon_reset_of_match);