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
| ||
|
Date: Fri, 09 Dec 2016 11:34:36 +0000 From: Måns Rullgård <mans@...sr.com> To: Sebastian Frias <sf84@...oste.net> Cc: Vinod Koul <vinod.koul@...el.com>, Mason <slash.tmp@...e.fr>, Russell King <linux@....linux.org.uk>, dmaengine@...r.kernel.org, Linus Walleij <linus.walleij@...aro.org>, Dan Williams <dan.j.williams@...el.com>, LKML <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Jon Mason <jdmason@...zu.us>, Mark Brown <broonie@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, Lee Jones <lee.jones@...aro.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Arnd Bergmann <arnd@...db.de>, Maxime Ripard <maxime.ripard@...e-electrons.com>, Dave Jiang <dave.jiang@...el.com>, Peter Ujfalusi <peter.ujfalusi@...com>, Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>, Thibaud Cornic <thibaud_cornic@...madesigns.com> Subject: Re: Tearing down DMA transfer setup after DMA client has finished Sebastian Frias <sf84@...oste.net> writes: > On 09/12/16 07:59, Vinod Koul wrote: >> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote: >>> Vinod Koul <vinod.koul@...el.com> writes: >>> >>>> To make it efficient, disregarding your Sbox HW issue, the solution is >>>> virtual channels. You can delink physical channels and virtual channels. If >>>> one has SW controlled MUX then a channel can service any client. For few >>>> controllers request lines are hard wired so they cant use any channel. But >>>> if you dont have this restriction then driver can queue up many transactions >>>> from different controllers. >>> >>> Have you been paying attention at all? This exactly what the driver >>> ALREADY DOES. >> >> And have you read what the question was? I wrote the driver. I think I know what Mason and I are asking. > I think many people appreciate the quick turn around time and > responsiveness of knowledgeable people making constructive remarks in > this thread, but it looks we are slowly drifting away from the main > problem. > > If we had to sum up the discussion, the current DMA API/framework in > Linux seems to lack a way to properly handle this HW (or if it has a > way, the information got lost somewhere). > > What concrete solution do you propose? > > Alternatively, one can think of the current issue (i.e.: the fact that > the IRQ arrives "too soon") in a different way. Instead of thinking > the IRQ indicates "transfer complete", it is indicating "ready to > accept another command", which in practice (and with proper API > support) can translate into efficient queuing of DMA operations. For multiple back to back transfers to the same peripheral, it is indeed a slight optimisation. What's apparently lacking is some way of doing a full flush -- Måns Rullgård
Powered by blists - more mailing lists