Re: [PATCH 0/8] Upstreaming the Android build and misc fixes

From: Emil Velikov <emil.l.velikov@gmail.com>
To: "Gore, Tim" <tim.gore@intel.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: emil.l.velikov@gmail.com,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/8] Upstreaming the Android build and misc fixes
Date: Tue, 29 Jul 2014 18:10:45 +0100	[thread overview]
Message-ID: <53D7D595.2080801@gmail.com> (raw)
In-Reply-To: <8FCC70911F3E9548866CA0E51893BCC31A1DE9E6@IRSMSX105.ger.corp.intel.com>

On 29/07/14 17:14, Gore, Tim wrote:
> 
> 
>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, July 28, 2014 4:22 PM
>> To: Emil Velikov
>> Cc: Daniel Vetter; Gore, Tim; dri-devel@lists.freedesktop.org
>> Subject: Re: [PATCH 0/8] Upstreaming the Android build and misc fixes
>>
>> On Mon, Jul 28, 2014 at 01:01:19PM +0100, Emil Velikov wrote:
>>> On 28/07/14 08:07, Daniel Vetter wrote:
>>>> On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
>>>>> A few updates:
>>>>>
>>>>>  - Naming the headers lists *_HEADERS caused autohell to hate us.
>>>>> Renamed to *_H_FILES
>>>>>  - Including the platform Android.mk files individually is not the
>>>>> right way to do. One needs to construct an array/list of Android.mks and
>> include it.
>>>>>
>>>>>  - The series including the above fixes can be found in branch
>>>>> fixes+android over at https://github.com/evelikov/libdrm.
>>>>
>>>> Adding Tim Gore who's working on Android.mk support for i-g-t from
>>>> our side and probably knows whom to poke for the intel side of
>>>> things for libdrm Android ports.
>>>> -Daniel
>>>>
>>> Thank you Daniel,
>>>
>>> In case it was not clear enough, some of these patches are taken from
>>> android-ia/external/drm. The very same are written by Intel employees
>>> AFAICT
>>> :) Would be great to hear if anyone is against the idea of getting
>>> Android.mks in the canonical repo.
>>
>> Oh, that's kinda why I want to drag the relevant people in from Intel's side.
>> Responsibility for Android builds have shifted around a bit the past few years
>> and Intel is big, so I'm trying to get hold off the right person. No success thus
>> far :(
>>
>> But personally I want this, just need to make sure that our own Android guys
>> see it and can start to help out. Occasionally it takes a while until they dare to
>> walk out of their hidings ;-) -Daniel
> 
> On the whole these look fine. Jon Bloomfield seemed happy with the overall idea.
>  3 comments.
>    1)  Patch 3 didn't apply cleanly, I assume because it
>         was based on a different branch (ie not master), but the difference was trivial.
>   2) The Android makefiles as they are will not build within the android tree. I am
>        Trying to get them to work at the moment.
The Android issue you've mentioned in the other email is fixed in the branch
mentioned above + I have squashed additional fixes over at fixes+android-v2 in
https://github.com/evelikov/libdrm. Will post these in just a moment.

>   3) Depending on which Android tree you have, the resulting libdrm may or may not
>        Work in there. I don't think the latest intel android tree is compatible with the
>       Upstream libdrm.
> 
Not sure what is the exact meaning of "compatible" is in this case. IMHO Intel
(if interested) can easily rebase their repo on top of upstream (as these
land) thus keep a smaller (if any) delta and ease development :)

-Emil

P.S. Who is Jon Bloomfield ?

>    Tim
> 
>>>
>>>
>>> -Emil
>>>
>>>>>
>>>>> -Emil
>>>>>
>>>>> On 27/07/14 19:25, Emil Velikov wrote:
>>>>>> Hello list,
>>>>>>
>>>>>> Recently I've had a go at the Anroid builds and I felt ...
>>>>>> inspired that there are (at least) two downstream repositories
>>>>>> that have the relevant Android build, yet all of them use 6+month old
>> libdrm.
>>>>>> Making even builds a pain in the neck :'(
>>>>>>
>>>>>> Are there any objections if we get the android build upstream ?
>>>>>> AFAICS it's nicely isolated from everything else + I've managed to
>>>>>> reuse all the source/headers lists.
>>>>>>
>>>>>> Note that the series lacks a couple of patches from the downstream
>>>>>> repos, yet adds support for radeon, nouveau and freedreno :)
>>>>>>
>>>>>> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other
>>>>>> intel specific "hacks". If people are happy with the series then
>>>>>> we can take a look at the final bits.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Emil
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch