On Tue, Aug 19, 2014 at 03:44:23PM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 19, 2014 at 07:15:07PM +0530, Vinod Koul wrote:
> > On Thu, Aug 14, 2014 at 09:57:53AM +0100, Russell King - ARM Linux wrote:
> > > It's got something to do with the async engine API, and seems to be
> > > somet
On Tue, Aug 19, 2014 at 07:15:07PM +0530, Vinod Koul wrote:
> On Thu, Aug 14, 2014 at 09:57:53AM +0100, Russell King - ARM Linux wrote:
> > It's got something to do with the async engine API, and seems to be
> > something to do with whether a descriptor can have other transactions
> > added to it,
On Thu, Aug 14, 2014 at 09:57:53AM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 14, 2014 at 10:53:01AM +0200, Ludovic Desroches wrote:
> > On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> > > The dmaengine is neither trivial nor properly documented at the moment,
> > > whic
On Thu, Aug 14, 2014 at 10:53:01AM +0200, Ludovic Desroches wrote:
> On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> > The dmaengine is neither trivial nor properly documented at the moment,
> > which
> > means a lot of trial and error development, which is not that good for such
On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> The dmaengine is neither trivial nor properly documented at the moment, which
> means a lot of trial and error development, which is not that good for such a
> central piece of the system.
>
> Attempt at making such a documentation.
On Sat, Aug 02, 2014 at 04:49:25PM +0200, Maxime Ripard wrote:
> > - residue callculation, though situation is much better now but still lots
> > of driver do it worng and folks do get it wrong
>
> What mistake in often made regarding the residue calculation?
- residue is for the descriptor aske
Hi Maxime,
On Wed, Jul 30, 2014 at 6:03 PM, Maxime Ripard
wrote:
> The dmaengine is neither trivial nor properly documented at the moment, which
> means a lot of trial and error development, which is not that good for such a
> central piece of the system.
>
> Attempt at making such a documentatio
On 08/02/2014 05:13 PM, Maxime Ripard wrote:
On Fri, Aug 01, 2014 at 08:09:17PM +0200, Lars-Peter Clausen wrote:
On 08/01/2014 07:15 PM, Vinod Koul wrote:
On Fri, Aug 01, 2014 at 10:57:07AM +0200, Maxime Ripard wrote:
On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote:
On 07/3
On Sat, Aug 02, 2014 at 04:17:14PM +0100, Russell King - ARM Linux wrote:
> On Sat, Aug 02, 2014 at 04:49:25PM +0200, Maxime Ripard wrote:
> > In the case of the call to device_control, especially in the
> > DMA_SLAVE_CONFIG case, but that also applies to pause/resume, are the
> > changes supposed
On Sat, Aug 02, 2014 at 04:29:21PM +0100, Russell King - ARM Linux wrote:
> On Sat, Aug 02, 2014 at 05:11:44PM +0200, Maxime Ripard wrote:
> > On Fri, Aug 01, 2014 at 03:53:26PM +0100, Russell King - ARM Linux wrote:
> > > > > > - That might just be my experience, but judging from previous
> > >
On Sat, Aug 02, 2014 at 05:11:44PM +0200, Maxime Ripard wrote:
> On Fri, Aug 01, 2014 at 03:53:26PM +0100, Russell King - ARM Linux wrote:
> > > > > - That might just be my experience, but judging from previous
> > > > > commits, DMA_PRIVATE is completely obscure, and we just set it
> > > > >
On Sat, Aug 02, 2014 at 04:49:25PM +0200, Maxime Ripard wrote:
> In the case of the call to device_control, especially in the
> DMA_SLAVE_CONFIG case, but that also applies to pause/resume, are the
> changes supposed to be immediates or can they happen later?
pause/resume are expected to operate s
On Fri, Aug 01, 2014 at 08:09:17PM +0200, Lars-Peter Clausen wrote:
> On 08/01/2014 07:15 PM, Vinod Koul wrote:
> >On Fri, Aug 01, 2014 at 10:57:07AM +0200, Maxime Ripard wrote:
> >>On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote:
> >>>On 07/31/2014 07:37 PM, Maxime Ripard wrote:
On Fri, Aug 01, 2014 at 03:53:26PM +0100, Russell King - ARM Linux wrote:
> > > > - That might just be my experience, but judging from previous
> > > > commits, DMA_PRIVATE is completely obscure, and we just set it
> > > > because it was making it work, without knowing what it was
> > > >
On Fri, Aug 01, 2014 at 10:43:06PM +0530, Vinod Koul wrote:
> On Thu, Jul 31, 2014 at 06:23:30PM +0200, Maxime Ripard wrote:
> > On Thu, Jul 31, 2014 at 05:26:28PM +0530, Vinod Koul wrote:
> >
> > Also, feel free to add anything that you feel like you keep saying
> > during the review. If mistakes
On 08/01/2014 07:15 PM, Vinod Koul wrote:
On Fri, Aug 01, 2014 at 10:57:07AM +0200, Maxime Ripard wrote:
On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote:
On 07/31/2014 07:37 PM, Maxime Ripard wrote:
On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote:
On 07/3
On Thu, Jul 31, 2014 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> DMA engine has lacked a lot of infrastructure for common patterns in
> drivers; some of that is solved by my efforts with the virt_dma.c
> support, and also various cleanups to existing drivers, but it's not
> easy to fix t
On Fri, Aug 01, 2014 at 10:57:07AM +0200, Maxime Ripard wrote:
> On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote:
> > On 07/31/2014 07:37 PM, Maxime Ripard wrote:
> > >On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote:
> > >>On 07/31/2014 06:13 PM, Maxime Ripard
On Thu, Jul 31, 2014 at 06:23:30PM +0200, Maxime Ripard wrote:
> On Thu, Jul 31, 2014 at 05:26:28PM +0530, Vinod Koul wrote:
>
> Also, feel free to add anything that you feel like you keep saying
> during the review. If mistakes keep coming, it's probably worth
> documenting what you expect.
I thi
On Thu, Jul 31, 2014 at 06:41:52PM +0200, Maxime Ripard wrote:
> You prove my point then. Vinod asks for GFP_NOWAIT in his
> reviews. Even though it doesn't change anything relative to the
> atomicity of the operations, the policy is still not the same.
The difference between GFP_NOWAIT and GFP_AT
On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote:
> On 07/31/2014 07:37 PM, Maxime Ripard wrote:
> >On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote:
> >>On 07/31/2014 06:13 PM, Maxime Ripard wrote:
> >>[...]
> >>> From what you're saying, and judging from the dr
On 07/31/2014 07:37 PM, Maxime Ripard wrote:
On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote:
On 07/31/2014 06:13 PM, Maxime Ripard wrote:
[...]
From what you're saying, and judging from the drivers that already
implement it, can't it be moved directly to the framework itsel
On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote:
> On 07/31/2014 06:13 PM, Maxime Ripard wrote:
> [...]
> > From what you're saying, and judging from the drivers that already
> >implement it, can't it be moved directly to the framework itself ?
> >
>
> What exactly do you mean b
On 07/31/2014 06:13 PM, Maxime Ripard wrote:
[...]
From what you're saying, and judging from the drivers that already
implement it, can't it be moved directly to the framework itself ?
What exactly do you mean by moving it directly to the framework? The
slave_caps API is part of the DMAengin
On Thu, Jul 31, 2014 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 31, 2014 at 09:44:40AM +0200, Maxime Ripard wrote:
> > I didn't miss it. But I feel like it describes quite nicely the slave
> > API, but doesn't help at all whenever you're writing a DMAengine driver.
>
> Ther
Hi Lars-Peter,
On Thu, Jul 31, 2014 at 02:44:56PM +0200, Lars-Peter Clausen wrote:
> On 07/31/2014 09:44 AM, Maxime Ripard wrote:
> [...]
> > - Having to set device_slave_caps or not?
>
> Yes. This should in my opinion be mandatory for new drivers.
Ok.
> One of the issues with the DMAengine
On Thu, Jul 31, 2014 at 05:26:28PM +0530, Vinod Koul wrote:
> On Thu, Jul 31, 2014 at 09:44:40AM +0200, Maxime Ripard wrote:
> > Hi Vinod,
> >
> > On Wed, Jul 30, 2014 at 09:36:07PM +0530, Vinod Koul wrote:
> > > On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> > > > The dmaengine
On Thu, Jul 31, 2014 at 09:44:40AM +0200, Maxime Ripard wrote:
> I didn't miss it. But I feel like it describes quite nicely the slave
> API, but doesn't help at all whenever you're writing a DMAengine driver.
There's actually two documents:
Documentation/crypto/async-tx-api.txt
Documentation/dma
On 07/31/2014 09:44 AM, Maxime Ripard wrote:
[...]
- Having to set device_slave_caps or not?
Yes. This should in my opinion be mandatory for new drivers. One of the
issues with the DMAengine API is that it is really hard to write generic
drivers that do not already know about the capabilit
On Thu, Jul 31, 2014 at 09:44:40AM +0200, Maxime Ripard wrote:
> Hi Vinod,
>
> On Wed, Jul 30, 2014 at 09:36:07PM +0530, Vinod Koul wrote:
> > On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> > > The dmaengine is neither trivial nor properly documented at the moment,
> > > which
>
Hi Vinod,
On Wed, Jul 30, 2014 at 09:36:07PM +0530, Vinod Koul wrote:
> On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> > The dmaengine is neither trivial nor properly documented at the moment,
> > which
> > means a lot of trial and error development, which is not that good for s
On Wed, Jul 30, 2014 at 06:03:13PM +0200, Maxime Ripard wrote:
> The dmaengine is neither trivial nor properly documented at the moment, which
> means a lot of trial and error development, which is not that good for such a
> central piece of the system.
>
> Attempt at making such a documentation.
32 matches
Mail list logo
