On Mon, Dec 08, 2014 at 10:49:56PM +0100, Lars-Peter Clausen wrote:
> On 12/08/2014 07:38 PM, Maxime Ripard wrote:
> [...]
> >>And lastly noone blamed you for being late, if things were rosy they
> >>would have been merged over the weekend and been in today's next,
> >>but...
> >
> >I totally under
On Mon, Dec 08, 2014 at 07:38:53PM +0100, Maxime Ripard wrote:
> On Mon, Dec 08, 2014 at 09:58:43PM +0530, Vinod Koul wrote:
> I totally understand your point. And I actually am a bit uncomfortable
> merging this so late too, and I'd actually prefer to have it merged
> for 3.20. But this is a huge
On 12/08/2014 07:38 PM, Maxime Ripard wrote:
[...]
And lastly noone blamed you for being late, if things were rosy they
would have been merged over the weekend and been in today's next,
but...
I totally understand your point. And I actually am a bit uncomfortable
merging this so late too, and I
On Mon, Dec 08, 2014 at 09:58:43PM +0530, Vinod Koul wrote:
> > > So bit sceptical for merging now. I will send the patches which I have
> > > applied on top of this
> >
> > Which is why I wanted to merge this at the *beginning* of the
> > development cycle in the first place
> >
> > These pa
On Mon, Dec 08, 2014 at 03:18:07PM +0100, Maxime Ripard wrote:
> On Mon, Dec 08, 2014 at 11:47:46AM +0530, Vinod Koul wrote:
> > On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > As we discussed a couple of weeks ago, this is the third attempt at
> > > creating a
On Mon, Dec 08, 2014 at 07:00:47PM +0530, Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 10:32:47AM +0100, Ludovic Desroches wrote:
> > On Mon, Dec 08, 2014 at 11:47:46AM +0530, Vinod Koul wrote:
> > > On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > As we di
On Mon, Dec 08, 2014 at 11:47:46AM +0530, Vinod Koul wrote:
> On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > As we discussed a couple of weeks ago, this is the third attempt at
> > creating a generic behaviour for slave capabilities retrieval so that
> > generic lay
On Mon, Dec 08, 2014 at 10:32:47AM +0100, Ludovic Desroches wrote:
> On Mon, Dec 08, 2014 at 11:47:46AM +0530, Vinod Koul wrote:
> > On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > As we discussed a couple of weeks ago, this is the third attempt at
> > > creati
On Mon, Dec 08, 2014 at 11:47:46AM +0530, Vinod Koul wrote:
> On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > As we discussed a couple of weeks ago, this is the third attempt at
> > creating a generic behaviour for slave capabilities retrieval so that
> > generic lay
On Mon, Nov 17, 2014 at 02:41:54PM +0100, Maxime Ripard wrote:
> Hi,
>
> As we discussed a couple of weeks ago, this is the third attempt at
> creating a generic behaviour for slave capabilities retrieval so that
> generic layers using dmaengine can actually rely on that.
>
> That has been done m
Hi,
As we discussed a couple of weeks ago, this is the third attempt at
creating a generic behaviour for slave capabilities retrieval so that
generic layers using dmaengine can actually rely on that.
That has been done mostly through two steps: by moving out the
sub-commands of the device_control
11 matches
Mail list logo
