Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1409109pxb; Fri, 20 Nov 2020 08:47:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwqcCXn3ZJ7HAJhx/yhWsItGhI/zG3xiv88ujubK2BTM0oEHY1TH2ieYczA/V2xFgopp7Ar X-Received: by 2002:a17:906:af6b:: with SMTP id os11mr5994603ejb.270.1605890865764; Fri, 20 Nov 2020 08:47:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605890865; cv=none; d=google.com; s=arc-20160816; b=Wd3TZzqHjVZw7p3ZvQE1P8NA1RpGAHbb5mz6I4YzlhFhLFaIPOd8eLzncdnBB03h5O HaDa0F7BAT44OK5vt8XqptVZ+7oQH7+vKptegsfJ4g6bOKLEGnnMoTvnC4H705mKuFjY 914Tk/YaRZVvFyb82Cp0vciHMCLnXILZFtEWpyJ03BhsT+PM9GYc3FvBUumMEta3xePk JCNxISiVJaCyw6beTkgFYCho83IFfJGRkssR2jDc7GZCuLQMboGZOVg+p74a9YeUVCtY bAYw3mGWdr8k8exvzd5nBBr2gxAT4Dj6njFPADE8EQkj1Ix8Ch7psgI843TzvX7UGj1n e/nA== 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 :dkim-signature; bh=XfY08vrjtp3gNppAgC2INtj3l8RwQt/02jEKP7reLVg=; b=ez0ujzNLLp/IRmNeIQHJ5qYh/PwctLO/FpziLGP55MqBz0loemSeEXvm9gyDHEc/QG b2auA+J+pxRg+hgnCZQGXa5CXWVJhyYHQtR7RsCGLxqTdjLA9zL76/kXu49CNwWJsbus 7CmOhRVO2weuLMERySFAHN2BVzk2y97WJ+2OLIIMXZCh03qiQM8+PqSN8R8+6bVki1It MTRA0M0ZTCrcluOc2h+2VKOlWEm4Urt8Aa5kiha/NR8cvr5F6QX379ooIyr5xkdEP6jW 3pu2WNQ/PCXWR3xAvB5dnsecr81rfRA33I8H9KJLML22xcCGvfGp2SkIi9lm14k175OD jErQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm1 header.b=ubWJ2QHx; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=NlqauZ7c; 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=cerno.tech Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x3si2166854ejv.159.2020.11.20.08.47.18; Fri, 20 Nov 2020 08:47:45 -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=@cerno.tech header.s=fm1 header.b=ubWJ2QHx; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=NlqauZ7c; 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=cerno.tech Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730144AbgKTQmg (ORCPT + 99 others); Fri, 20 Nov 2020 11:42:36 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36103 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728685AbgKTQmf (ORCPT ); Fri, 20 Nov 2020 11:42:35 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7E52B5C0160; Fri, 20 Nov 2020 11:42:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 20 Nov 2020 11:42:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=XfY08vrjtp3gNppAgC2INtj3l8R wQt/02jEKP7reLVg=; b=ubWJ2QHxKdUgVLSQL2MwcyOWLpfWWnsO4FZnI+b7tab 84iclH7VT+sj/zaUEk9EHdhOBewpri4W+vWNRMdvrpTNqkgZG4cM20orxqjO69Qw mc2L00/9RRfHfdDwezRhPxIasTpVfph25HPiFqfHA401nZPlVNTMqm1ksJwIMJBX 0k2zddPdtpSW4MYQzsivE07gBEykv6Kmvsy0gJ/POMrXyVSKZOwvKI6T6VBHDj8X rw+gzOGFWDzGu7YNRZxlgRPJndVZZMnMhIA+3/XfwYpdvfAPWSI1T8YrLQDTIg14 nDy/4vuclOfVI4OJvQ0uU0v4HX323hwcOJgcW8DD+pw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XfY08v rjtp3gNppAgC2INtj3l8RwQt/02jEKP7reLVg=; b=NlqauZ7cuB0xKxDnf4XRHC QNtkTATSUTN8GPcmvX6JpTciF45Dco0qY2JTdWrJmHS8MDYEO4jy/odvSwFNTqM9 KWRq2fXKYQYmmdoe9M/Iz7PVUPlDumRST6/yOmftI3S32RFwr7dEjTCTJQHucsqS 1s1nQmqwzLafMBwIdBXp7oZreYz3umoi3RU+d/XOARkdtb4THkji1ygrMda+Mmmn wdqZ5hJyzVAI/7zU2gxofJRywFv9okLSlhMi/bgtgcOvgKDIvqBP7f2Hu0j0wS1y m7sAT4a57lhV3373itYlvAwrDEM4NQyQZSN92PYyGsZm5hzdNuPWTBQY46iHVg5g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegtddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 27BD53064AB8; Fri, 20 Nov 2020 11:42:33 -0500 (EST) Date: Fri, 20 Nov 2020 17:42:31 +0100 From: Maxime Ripard To: Wilken Gottwalt Cc: 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: <20201120164231.nmzxe5scwnfoyy3o@gilmour> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vl2s3l567u4phv4v" Content-Disposition: inline In-Reply-To: <20201119111343.74956eae@monster.powergraphx.local> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vl2s3l567u4phv4v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 i= nto the > > > coverletter and other documentation only tells how to split the patch= es. So > > > what would be the right way? A quick example based on my patch set wo= uld be > > > really helpful. > >=20 > > I mean, the split between your patches and so on is good, you got that = right > >=20 > > The thing I wanted better details on is the commit log itself, so the > > message attached to that patch. >=20 > Ah yes, I think I got it now. So basically add a nice summary of the cove= rletter > 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 co= res > > > > and the ARISC. How did you test this driver? > > >=20 > > > Yes, you are right, I should have mentioned this. I have a simple tes= t 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 t= o work > > > with my test kernel module, but I'm not sure if this is really suffic= ient. I > > > can provide the code for it if you like. What would be the best way? = Github? > > > Just mailing a patch? > > >=20 > > > The test module produces these results: > > >=20 > > > # insmod /lib/modules/5.9.8/kernel/drivers/hwspinlock/sunxi_hwspinloc= k_test.ko=20 > > > [ 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 ----- > >=20 > > 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? >=20 > 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) t= o take > a spinlock ... or at least take spinlocks periodically for a while and wa= tch it > on the linux side. Okay, I think I can do this. Though, I have to dig thr= ough > 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 Maxime --vl2s3l567u4phv4v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX7fx9wAKCRDj7w1vZxhR xVh5AQCo2PMZzvWUnDrdECdc1PSp7Bf2yleADRnK9iLu7nJNiwEA2ihSZ+VDLMUv CIRYjbGb8sYFp0wUHlGFQVEefyQhwAA= =X5hI -----END PGP SIGNATURE----- --vl2s3l567u4phv4v--