On Mon, Oct 21, 2019 at 09:18:07AM +, Brian Starkey wrote:
> On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> > On 10/18/19 2:57 PM, Ayan Halder wrote:
> > > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> > >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder
On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> On 10/18/19 2:57 PM, Ayan Halder wrote:
> > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> >>> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
On 10/18/19 2:57 PM, Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
>> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
>>> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
>
On Fri, Oct 18, 2019 at 11:57 AM Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> > On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> > > With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> > > follows :-
> > >
> > > [0.450562]
On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> > On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > > On Thu, Oct 17, 2019 at 12:29 PM Andrew
++ john.stu...@linaro.org (Sorry, somehow I am missing your email while
sending. :( )
On Fri, Oct 18, 2019 at 06:41:24PM +, Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > On Thu, Oct 17,
On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > > On 10/17/19 3:14 PM, John Stultz wrote:
> >
On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > But if the objection stands, do you have a proposal for
On Fri, Oct 18, 2019 at 2:55 AM Brian Starkey wrote:
> On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > But if the objection stands, do you have a proposal for an
On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > On 10/17/19 3:14 PM, John Stultz wrote:
> > > But if the objection stands, do you have a proposal for an alternative
> > > way to enumerate a subset of CMA heaps?
> > >
> >
On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> On 10/17/19 3:14 PM, John Stultz wrote:
> > But if the objection stands, do you have a proposal for an alternative
> > way to enumerate a subset of CMA heaps?
> >
> When in staging ION had to reach into the CMA framework as the other
>
On 10/17/19 3:14 PM, John Stultz wrote:
> On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote:
>> On 10/14/19 5:07 AM, Brian Starkey wrote:
>>> Hi Andrew,
>>>
>>> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
The CMA driver that registers these nodes will have to be
On Wed, Oct 16, 2019 at 10:41 AM Andrew F. Davis wrote:
> On 10/14/19 5:07 AM, Brian Starkey wrote:
> > Hi Andrew,
> >
> > On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
> >> The CMA driver that registers these nodes will have to be expanded to
> >> export them using this
On 10/14/19 5:07 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
>> The CMA driver that registers these nodes will have to be expanded to
>> export them using this framework as needed. We do something similar to
>> export SRAM nodes:
>>
On Wed, Oct 9, 2019 at 10:38 AM Ayan Halder wrote:
>
> On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
> > On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> > > Hello Christoph, everyone,
> > >
> > > On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
> > > >
> > > > Here
Hi Andrew,
On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
> The CMA driver that registers these nodes will have to be expanded to
> export them using this framework as needed. We do something similar to
> export SRAM nodes:
>
> https://lkml.org/lkml/2019/3/21/575
>
> Unlike
On 10/9/19 1:37 PM, Ayan Halder wrote:
> On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
>> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
>>> Hello Christoph, everyone,
>>>
>>> On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
Here is yet another pass at the
On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
> On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> > Hello Christoph, everyone,
> >
> > On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
> > >
> > > Here is yet another pass at the dma-buf heaps patchset Andrew
> > > and
On 9/6/19 2:47 PM, John Stultz wrote:
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a
On Tue, Sep 24, 2019 at 9:22 AM Ayan Halder wrote:
> I tested these patches using our internal test suite with Arm,komeda
> driver and the following node in dts
>
> reserved-memory {
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> ranges;
On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> Hello Christoph, everyone,
>
> On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
> >
> > Here is yet another pass at the dma-buf heaps patchset Andrew
> > and I have been working on which tries to destage a fair chunk
> > of ION
Hello Christoph, everyone,
On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
>
> Here is yet another pass at the dma-buf heaps patchset Andrew
> and I have been working on which tries to destage a fair chunk
> of ION functionality.
>
> The patchset implements per-heap devices which can be opened
>
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.
The interface is
23 matches
Mail list logo
