Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1965077pxb; Sat, 21 Nov 2020 04:26:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJy5uTxWJIdpKyA32AEKup6Wpy2H+0tRWzcuaC6ynaqzlENQg0jW6WjDj5A8GOna4SDljLd/ X-Received: by 2002:a50:9f2e:: with SMTP id b43mr29741103edf.239.1605961619266; Sat, 21 Nov 2020 04:26:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605961619; cv=none; d=google.com; s=arc-20160816; b=v1PEZVeeYQvEnj6RNdrsLtd21ftBruBOf4LnsJMVOTKrskGlcuUb+nom4xdtDG6YM4 Y09nmu5yNo0jhp+rOk/V9+WpGmglT59nB5/7t2tBMNWgicnCtM6B3qFc8IrEE/RaSkBr a/RlrARjYbLrBjr4w/kdKe0Qit24zf1WYb+ILI/8Q8ckAZzGnpglDVNkzIrnEPLypzvy 0HU7Pah6EeHsen1KXAHl8f/IzmOKPjYdvPYqRegB0rMCybTBV7Qz3tCmy/183eUaMYn1 iXsQ3HNwsX6/PNR9MoiA8j/YjNLUPwq6oXE2CryYxcnuzBvDgYHsnhnUawzADDmXa6qv QDBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:organization:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=SJDo8Rvs1t+7/d4s/FmW9/dpY7D+3OlGorzY35t8LgI=; b=O6GTEKXL1H9mazsWArWOjgUQekfOhzQAjgp5uPSw7jDWFH1Dv4shSf/ZXiDrL4tEwd FtmUGYdVw46TRQ+gcEzWALVKOxwYilg908HcWdcl+i0zvNkaPC9WjfEJssfHiZikZt9m gNnE1TCStCFOteKA27TF4s0kDg19Lo2QwMAvfXyHIvd58Bf55uVNqvI+EvHMswqduLHO ma2WDVPKO1OORmSIKNrGTFUWOrxbiQXFSSr1DRCOAkG76mSI5sj8O/Nd7ajp50UUeM+N ShBAlbydMBIjOgi9q36bvNwW7yuMdfCnXCD4WRbwg1fjeIKDjDejOcYJfOMnHXp2FTsV idqA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d24si3385881edj.373.2020.11.21.04.26.35; Sat, 21 Nov 2020 04:26:59 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727497AbgKUMXG (ORCPT + 99 others); Sat, 21 Nov 2020 07:23:06 -0500 Received: from smtp2207-205.mail.aliyun.com ([121.197.207.205]:52866 "EHLO smtp2207-205.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727191AbgKUMXE (ORCPT ); Sat, 21 Nov 2020 07:23:04 -0500 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07462001|-1;CH=green;DM=|CONTINUE|false|;DS=CONTINUE|ham_regular_dialog|0.410477-0.000193703-0.589329;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047209;MF=fuyao@allwinnertech.com;NM=1;PH=DS;RN=9;RT=9;SR=0;TI=SMTPD_---.IzZCTo2_1605961376; Received: from localhost(mailfrom:fuyao@allwinnertech.com fp:SMTPD_---.IzZCTo2_1605961376) by smtp.aliyun-inc.com(10.147.42.198); Sat, 21 Nov 2020 20:22:56 +0800 Date: Sat, 21 Nov 2020 20:22:55 +0800 From: fuyao To: Maxime Ripard Cc: Wilken Gottwalt , linux-kernel@vger.kernel.org, Ohad Ben-Cohen , Bjorn Andersson , Baolin Wang , Rob Herring , Chen-Yu Tsai , Jernej Skrabec Subject: Re: [PATCH 2/2] hwspinlock: add sunxi hardware spinlock support Message-ID: <20201121122255.GB22987@debian> Mail-Followup-To: Maxime Ripard , Wilken Gottwalt , linux-kernel@vger.kernel.org, Ohad Ben-Cohen , Bjorn Andersson , Baolin Wang , Rob Herring , Chen-Yu Tsai , Jernej Skrabec References: <149526a0ba8d18ebb68baa24e95d946ede90b4c0.1605693132.git.wilken.gottwalt@posteo.net> <20201118153733.jgiokn6jkwu6rv6c@gilmour.lan> <20201118203624.7221ba8b@monster.powergraphx.local> <20201119071523.5cbpgy2cpo5cmuev@gilmour.lan> <20201119111343.74956eae@monster.powergraphx.local> <20201120164231.nmzxe5scwnfoyy3o@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201120164231.nmzxe5scwnfoyy3o@gilmour> Organization: fuyao_love_xxt.Allwinnertech.Technology User-Agent: Mutt/1.12.1+6 (4c2f7c70) (2019-08-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 20, 2020 at 05:42:31PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Nov 19, 2020 at 11:13:43AM +0100, Wilken Gottwalt wrote: > > On Thu, 19 Nov 2020 08:15:23 +0100 > > Maxime Ripard wrote: > > > > can you help me here a bit? I still try to figure out how to do patch sets > > > > properly. Some kernel submitting documentation says everything goes into the > > > > coverletter and other documentation only tells how to split the patches. So > > > > what would be the right way? A quick example based on my patch set would be > > > > really helpful. > > > > > > I mean, the split between your patches and so on is good, you got that right > > > > > > The thing I wanted better details on is the commit log itself, so the > > > message attached to that patch. > > > > Ah yes, I think I got it now. So basically add a nice summary of the coverletter > > there. > > Yes, a bit more context as well. Eventually, this should be the > motivation on why this patch is useful. So what it can be used for, what > are the challenges, how it was tested, etc. > > The cover letter is usually here more to provide some meta-context: what > you expect from the maintainers / reviewers if it's an RFC, if there's > any feature missing or that could be added later on, etc. > > > > > > Most importantly, this hwspinlock is used to synchronize the ARM cores > > > > > and the ARISC. How did you test this driver? > > > > > > > > Yes, you are right, I should have mentioned this. I have a simple test kernel > > > > module for this. But I must admit, testing the ARISC is very hard and I have > > > > no real idea how to do it. Testing the hwspinlocks in general seems to work > > > > with my test kernel module, but I'm not sure if this is really sufficient. I > > > > can provide the code for it if you like. What would be the best way? Github? > > > > Just mailing a patch? > > > > > > > > The test module produces these results: > > > > > > > > # insmod /lib/modules/5.9.8/kernel/drivers/hwspinlock/sunxi_hwspinlock_test.ko > > > > [ 45.395672] [init] sunxi hwspinlock test driver start > > > > [ 45.400775] [init] start test locks > > > > [ 45.404263] [run ] testing 32 locks > > > > [ 45.407804] [test] testing lock 0 ----- > > > > [ 45.411652] [test] taking lock attempt #0 succeded > > > > [ 45.416438] [test] try taken lock attempt #0 > > > > [ 45.420735] [test] unlock/take attempt #0 > > > > [ 45.424752] [test] taking lock attempt #1 succeded > > > > [ 45.429556] [test] try taken lock attempt #1 > > > > [ 45.433823] [test] unlock/take attempt #1 > > > > [ 45.437862] [test] testing lock 1 ----- > > > > > > That doesn't really test for contention though, and dealing with > > > contention is mostly what this hardware is about. Could you make a small > > > test with crust to see if when the arisc has taken the lock, the ARM > > > cores can't take it? > > > > So the best solution would be to write a bare metal program that runs on the > > arisc and can be triggered from the linux side (the test kernel module) to take > > a spinlock ... or at least take spinlocks periodically for a while and watch it > > on the linux side. Okay, I think I can do this. Though, I have to dig through > > all this new stuff first. > > It doesn't have to be super complicated, just a loop that takes a lock, > sleeps for some time, and releases the lock should be enough to at least > validate that the lock is actually working > I think the difficulty is the bare metal program in arsic has little documentation. the arisc is usually used for standby, so don't provide detailed, and start it with boot0 or uboot. maybe we can run it use remoteproc to start it.