lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1202031114560.6211@axis700.grange>
Date:	Fri, 3 Feb 2012 11:21:46 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	"Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@...esas.com>
cc:	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	Vinod Koul <vinod.koul@...el.com>,
	Magnus Damm <magnus.damm@...il.com>, linux-mmc@...r.kernel.org,
	alsa-devel@...a-project.org, linux-serial@...r.kernel.org,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 1/7 v2] dmaengine: add a simple dma library

On Fri, 3 Feb 2012, Shimoda, Yoshihiro wrote:

> Hi Guennadi-san,
> 
> 2012/02/03 7:19, Guennadi Liakhovetski wrote:
> [ snip ]
> >>
> >> Thank you for your comment.
> >>
> >> I investigaed the issue. I found out the renesas_usbhs driver may
> >> call tx_submit() in the callback() of the dma-simple finally.
> > 
> > Sorry, in my first reply to this your email I misread the renesas_usbhs 
> > for an issue with your new SUDMAC driver. Since this is not the case and 
> > my patch seems to be causing a regression, I'll look at it.
> 
> Thank you for the comment.
> 
> I found out that if the "power_up" is 0 in the sample_tx_submit(),
> the pm_state will be changed to "PENDING".
> And then, even if the renesas_usbhs calls dma_async_issue_pending(),
> the dma-simple driver doesn't call the simple_chan_xfer_ld_queue().
> This is because the driver will call the simple_chan_xfer_ld_queue()
> when the pm_state is "ESTABLISHED" only.
> 
> So I guess that we have to modify the simple_issue_pending().

Ok, I looked at this code, there's now a comment in simple_tx_submit():

	if (power_up) {
		...
	} else {
		/*
		 * Tell .device_issue_pending() not to run the queue, interrupts
		 * will do it anyway
		 */
		schan->pm_state = DMA_SIMPLE_PM_PENDING;
	}

And that's exactly what should be happening: an interrupt should trigger 
the IRQ thread should call simple_chan_xfer_ld_queue(), so, looks like the 
interrupt is not coming? It's also strange, why and how it worked without 
dma-simple? I don't think I changed that with the transition... 
Investigating.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ