2016ë
08ì 25ì¼ 21:14ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Thu, Aug 25, 2016 at 08:45:25PM +0900, Inki Dae wrote:
>>
>>
>> 2016ë
08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
2016ë
08ì 24ì¼ 20:57ì
2016ë
08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>>
>>
>> 2016ë
08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
Hi,
2016ë
08ì 23ì¼
2016ë
08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>> Hi,
>>
>> 2016ë
08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Hi,
>>>
>>> On 22 August 2016 at 16:23, Rob Clark wrote:
I guess a lot comes down to 'how
On Thu, Aug 25, 2016 at 08:45:25PM +0900, Inki Dae wrote:
>
>
> 2016ë
08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
> >>
> >>
> >> 2016ë
08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> >>> On Wed, Aug 24, 2016 at
On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>
>
> 2016ë
08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
> >> Hi,
> >>
> >> 2016ë
08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> >>> Hi,
> >>>
> >>> On 22
Hi,
2016ë
08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi,
>
> On 22 August 2016 at 16:23, Rob Clark wrote:
>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>> the thing'.. at that point, I think you especially don't want a
>> per-blit kernel interface.
>
>
On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
> Hi,
>
> 2016ë
08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> > Hi,
> >
> > On 22 August 2016 at 16:23, Rob Clark wrote:
> >> I guess a lot comes down to 'how long before hw designers bolt a CP to
> >> the thing'.. at that
Hi,
On 22 August 2016 at 16:23, Rob Clark wrote:
> I guess a lot comes down to 'how long before hw designers bolt a CP to
> the thing'.. at that point, I think you especially don't want a
> per-blit kernel interface.
Regardless of whether or not we want it, we already _have_ it, in the
form of
On 22 August 2016 at 19:44, Marek Szyprowski
wrote:
> Dear all,
>
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
>
In STM SoC we have hardware block doing scaling/colorspace conversion,
we have decide to use v4l2 mem2mem API for it:
https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html
the code is here:
On Mon, Aug 22, 2016 at 11:59:24AM +0200, Christian König wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> > Dear all,
> >
> > This is the initial proposal for extending DRM API with generic support for
> > hardware modules, which can be used for processing image data from the one
> >
Hello Marek,
Marek Szyprowski wrote:
> Dear Tobias
>
>
> On 2016-08-22 12:07, Tobias Jakobi wrote:
>> Hey Marek,
>>
>> I had a quick look at the series and I really like the new approach.
>>
>> I was wondering about the following though. If I understand this
>> correctly I can only perform m2m
Dear Tobias
On 2016-08-22 12:07, Tobias Jakobi wrote:
> Hey Marek,
>
> I had a quick look at the series and I really like the new approach.
>
> I was wondering about the following though. If I understand this
> correctly I can only perform m2m operations on buffers which are
> registered as
Hey Marek,
I had a quick look at the series and I really like the new approach.
I was wondering about the following though. If I understand this
correctly I can only perform m2m operations on buffers which are
registered as framebuffers. Is this possible to weaken that requirements
such that
Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> Dear all,
>
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
> rotation,
Dear all,
This is the initial proposal for extending DRM API with generic support for
hardware modules, which can be used for processing image data from the one
memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. In this
On Mon, Aug 22, 2016 at 5:59 AM, Christian König
wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
>>
>> Dear all,
>>
>> This is the initial proposal for extending DRM API with generic support
>> for
>> hardware modules, which can be used for processing image data from the one
>> memory
17 matches
Mail list logo
