Am 03.05.19 um 14:27 schrieb Thomas Zimmermann:
> cc: nor...@tronnes.org
Actually cc him
> Am 03.05.19 um 14:07 schrieb Koenig, Christian:
>> Am 03.05.19 um 14:01 schrieb Daniel Vetter:
>>> [CAUTION: External Email]
>>>
>>> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann
>>> wrote:
Hi
cc: nor...@tronnes.org
Am 03.05.19 um 14:07 schrieb Koenig, Christian:
> Am 03.05.19 um 14:01 schrieb Daniel Vetter:
>> [CAUTION: External Email]
>>
>> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann
>> wrote:
>>> Hi Christian,
>>>
>>> would you review the whole patch set? Daniel mentioned
Am 03.05.19 um 14:01 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann wrote:
>> Hi Christian,
>>
>> would you review the whole patch set? Daniel mentioned that he'd prefer
>> to leave the review to memory-mgmt developers.
> I think Noralf
On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann wrote:
>
> Hi Christian,
>
> would you review the whole patch set? Daniel mentioned that he'd prefer
> to leave the review to memory-mgmt developers.
I think Noralf Tronnes or Gerd Hoffmann would also make good reviewers
for this, fairly close to
Hi Christian,
would you review the whole patch set? Daniel mentioned that he'd prefer
to leave the review to memory-mgmt developers.
Best regards
Thomas
Am 30.04.19 um 11:35 schrieb Koenig, Christian:
> Am 30.04.19 um 11:23 schrieb Sam Ravnborg:
>> [CAUTION: External Email]
>>
>> Hi Thomas.
>>
On Mon, Apr 29, 2019 at 09:58:55PM +0200, Sam Ravnborg wrote:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent and use u32,
On Mon, Apr 29, 2019 at 09:58:55PM +0200, Sam Ravnborg wrote:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent and use u32,
Am 30.04.19 um 11:23 schrieb Sam Ravnborg:
> [CAUTION: External Email]
>
> Hi Thomas.
>
+
+/**
+ * Returns the container of type drm_gem_vram_object
+ * for field bo.
+ * @bo: the VRAM buffer object
+ * Returns: The containing GEM VRAM object
+
Hi Thomas.
> >> +
> >> +/**
> >> + * Returns the container of type drm_gem_vram_object
> >> + * for field bo.
> >> + * @bo: the VRAM buffer object
> >> + * Returns: The containing GEM VRAM object
> >> + */
> >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo(
> >> +
Hi,
thanks for the feedback.
Am 29.04.19 um 21:58 schrieb Sam Ravnborg:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent
Hi Thomas.
Some minor things and some bikeshedding too.
One general^Wbikeshedding thing - unint32_t is used in many places.
And then s64 in one place.
Seems like two concepts are mixed.
Maybe be consistent and use u32, s32 everywhere?
I did not read the code carefully enough to understand it.
I
The type |struct drm_gem_vram_object| implements a GEM object for simple
framebuffer devices with dedicated video memory. The BO is either located
in VRAM or system memory.
The implementation has been created from the respective code in ast,
bochs and mgag200. These drivers copy their
12 matches
Mail list logo
