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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47CEF8C4B26E8C44B22B028A650E0EA9317D2B9D@DBDE01.ent.ti.com>
Date:	Tue, 31 Jan 2012 04:41:31 +0000
From:	"Gupta, Ajay Kumar" <ajay.gupta@...com>
To:	Sergei Shtylyov <sshtylyov@...sta.com>
CC:	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Pasupathy, Visuvanadan" <vichu@...com>,
	"Balbi, Felipe" <balbi@...com>
Subject: RE: RFC: usb: musb: Changes proposed for adding CPPI4.1 DMA

Hi Sergei,
> On 01/25/2012 06:22 PM, Gupta, Ajay Kumar wrote:
> 
> > As a next step to dma-engine based cppi4.1 driver implementation
> > this RFC has the overview of changes in the musb driver.
> > RFC on CPPI slave driver changes will follow next.
> 
> > Overview of changes in the musb driver
> > ======================================
> 
> > 1)Add a dma-engine.c file in the drivers/usb/musb folder
> > 2)This file will host the current musb dma APIs and translates them to
> >    dmaengine APIs.
> > 3)This will help to keep the changes in drivers/usb/musb/musb* files
> >    minimal and also to retain compatibility other DMA (Mentor etc.)
> >    drivers which are yet to be moved to drivers/dma
> > 4)drivers/usb/musb/dma-engine.c, will wrap the dmaengine APIs to
> >    make existing musb APIs compatible.
> > 5)drivers/usb/musb/dma-engine.c file will implement the filter
> >    functions and also implement .dma_controller_create (allocates
> >    &  provides "dma_controller" object) and .dma_controller_delete
> > 6)CPPI4.1 DMA specific queue and buffer management will be internal
> >    to slave CPPI DMA driver implementation.
> 
>     You mean drivers/dma/ driver?
yes.

> I think you are forgotting that CPPI 4.1 MUSB
> has some registers controlling DMA/interrupts beside those of CPPI 4.1
> controller and MUSB core itself. How do they fit in your scheme?

We have been discussing on how to handle these in slave driver and
would post our proposal in RFC for slave driver design. Do you have
any proposal?

Regards,
Ajay
> 
> WBR, Sergei
--
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