Re: [PATCH 1/1] dma: actions: Fix lockdep splat for owl-dma

From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: "Andreas Färber" <afaerber@suse.de>
Cc: linux-actions@lists.infradead.org, linux-kernel@vger.kernel.org,
	Cristian Ciocaltea <cristian.ciocaltea@gmail.com>,
	Vinod Koul <vkoul@kernel.org>,
	dmaengine@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/1] dma: actions: Fix lockdep splat for owl-dma
Date: Wed, 29 Apr 2020 15:28:02 +0530	[thread overview]
Message-ID: <20200429095802.GB6443@Mani-XPS-13-9360> (raw)
In-Reply-To: <a70a2352-7b22-6b85-848b-94d9ee17c022@suse.de>

Hi Andreas,

On Wed, Apr 29, 2020 at 10:36:01AM +0200, Andreas Färber wrote:
> Am 28.04.20 um 20:18 schrieb Manivannan Sadhasivam:
> > On Tue, Apr 28, 2020 at 09:11:15PM +0300, Cristian Ciocaltea wrote:
> > > On Tue, Apr 28, 2020 at 10:19:21PM +0530, Manivannan Sadhasivam wrote:
> > > > On Tue, Apr 28, 2020 at 01:56:12PM +0300, Cristian Ciocaltea wrote:
> > > > > When the kernel is build with lockdep support and the owl-dma driver is
> > > > > used, the following message is shown:
> [...]
> > > > > The required fix is to use spin_lock_init() on the pchan lock before
> > > > > attempting to call any spin_lock_irqsave() in owl_dma_get_pchan().
> > > > 
> > > > Right, this is a bug. But while looking at the code now, I feel that we don't
> > > > need 'pchan->lock'. The idea was to protect 'pchan->vchan', but I think
> > > > 'od->lock' is the better candidate for that since it already protects it in
> > > > 'owl_dma_terminate_pchan'.
> > > > 
> > > > So I'd be happy if you remove the lock from 'pchan' and just directly use the
> > > > one in 'od'.
> > > > 
> > > > Out of curiosity, on which platform you're testing this?
> > > 
> > > Totally agree, I will send a new patch revision as soon as I do some
> > > more testing.
> > 
> > Coo[l], thanks!
> > 
> > > I'm currently experimenting on an Actions S500 based board (Roseapple Pi)
> > > trying to extend, if possible, the existing mainline support for those
> > > SoCs.
> > 
> > Awesome! It's great to see that Actions platform is seeing some attention
> > these days :)
> > 
> > > I don't have much progress so far, since I started quite recently
> > > and I also lack experience in the kernel development area, but I do my
> > > best to come back with more patches once I get a consistent functionality.
> > 
> > No worries. Feel free to reach out to me if you have any questions. There is
> > a lot of work to do and for sure it will be a good learning curve.
> > 
> > We do have an IRC channel (##linux-actions) for quick discussions. Fee[l] free
> > to join!
> 
> Please also CC the linux-actions mailing list on any patches:
> 
> https://lists.infradead.org/mailman/listinfo/linux-actions
> 
> Mani, do you have a 5.7-rc1 tree set up or should I queue patches this
> round?

I haven't set up the branch. You can do the maintainership duties for this
cycle.

> It still seems missing in MAINTAINERS, and then there's Matheus'
> patches in review.
> 

Yeah, the MAINTAINERS patch has fallen through cracks:

[PATCH v2 6/6] MAINTAINERS: Add linux-actions mailing list for Actions Semi

I did this as a part of S500 clk series. Feel free to pick it up.

Thanks,
Mani

> Thanks,
> Andreas
> 
> -- 
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel