On Mon, Mar 11, 2019 at 05:51:39PM +0100, Christian König wrote: > Am 11.03.19 um 17:39 schrieb Hans de Goede: > > Hi, > > > > On 07-02-19 09:59, Thomas Zimmermann wrote: > > > Almost all TTM-based drivers use the same values for the mmap-able > > > range of BO addresses. Each driver therefore duplicates the > > > DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not > > > configurable by drivers. > > > > > > This patch set replaces driver-specific configuration with a single > > > setup. All code is located within TTM. TTM and GEM share the same > > > range for mmap-able BOs. > > > > > > Thomas Zimmermann (5): > > > staging/vboxvideo: Use same BO mmap offset as other drivers > > > drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant > > > drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init() > > > drm/ttm: Quick-test mmap offset in ttm_bo_mmap() > > > drm: Use the same mmap-range offset and size for GEM and TTM > > > > Note I'm about to push a patch-series to drm-misc-next which moves > > vboxvideo out of staging and I see that this series has not landed > > in drm-misc-next yet, so it will needs to be rebased. > > Mhm, TTM is usually not pushed upstream through drm-misc-next, so that will > certainly collide with the next TTM pull request. > > So can you wait with that or should I make an exception and merge this > change though drm-misc-next? Other options: - Get amdgpu added to drm-tip and linux-next so we have a heads-up about the conflict. That's usually good enough to avoid the broken merge conflict. - Do a topic branch, pull it into both trees. - Really stuff ttm into a shared tree if it's meant to be shared infrastructure :-P Waiting+rebasing is imo the worst option, and usually not needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
