Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp812014ybx; Tue, 5 Nov 2019 06:01:39 -0800 (PST) X-Google-Smtp-Source: APXvYqyptNrn9gZb7tQ2CkMQ0wc5nojtGytWSMIa+0e28FhOvfTsbt7m427367vad6HG93+2+V+3 X-Received: by 2002:a17:906:6bc4:: with SMTP id t4mr30471503ejs.1.1572962499088; Tue, 05 Nov 2019 06:01:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572962499; cv=none; d=google.com; s=arc-20160816; b=bL7OBQJq2UNSN4oyESj6Y/TAXHlQrfG708H4YL45WYZ+XeGnBJwCzd+c818UGo6vBp 1tWNtuheyex01/P11SLRPu8X1h1Lhv/X4Yp/4gS93Y+vQ7pZCdpxD6VF71WCxC102DYJ mT600IhcBgLwZYq0fmp01VCM9hs7OHuiyScX8h39NOiuzDNBK6aDmfkoV/UuoLCjHYfI 87iGMlYQ8zR1URun51KDtSKRKj8AIMfXZhCe1D2dtzymvK5UtQnLB7OzVYcCJrELLK+r tpunHdv6bivzbNU5XTjOzzBku3SQTSZkfvax483pVcMDvI7nevIl24s+7z0xODFiM1hp hvtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CDIxaK5XX1he2V+PqxXF4SxUgffAFMYXkaPiJpN+d6I=; b=Af1Mc86ynoaIcBXGLslUpx0GRmIztK3Yj8Klt2U+1r2Y9FDUHmpdN6mJbyx/o6nBDX 7BnRUwYkLhJyv83WtSQfLCw9liyAuh2fvGyvpZytD5M1J6aEOS3eNOm7KonjfwiNNuUc rs1IAedZvsPAf6+6AywKs2D+Mexj/D1LfS6/cxA7GGXVblYeNFSCs4yj/zQqFFTSmEGl VsQK+XmlhUG3oCOr15gLKiQs5Cc3XDiWnCO1FjLDYZ6Y7wrFWS2b9mQx+679Fd6Ijqh6 OQqq+3jKrmY+D5lZdCkY+uz4nkG8O/aDD3jOM4ySEAVXH4oxQUd7bg0/g1Eysb4N6VsF O2WA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b="E0m/5SMG"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x17si5054837ejs.178.2019.11.05.06.01.14; Tue, 05 Nov 2019 06:01:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b="E0m/5SMG"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389331AbfKEN6b (ORCPT + 99 others); Tue, 5 Nov 2019 08:58:31 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:41218 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389113AbfKEN6a (ORCPT ); Tue, 5 Nov 2019 08:58:30 -0500 Received: by mail-oi1-f196.google.com with SMTP id e9so13681905oif.8 for ; Tue, 05 Nov 2019 05:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CDIxaK5XX1he2V+PqxXF4SxUgffAFMYXkaPiJpN+d6I=; b=E0m/5SMGe2TSs7mwIepFgaoMTW6j0pYIdgrE1mK4HxLg49ptKy3Z4dZyjyKTHAqNzm UM6fbse3CY7TZDGzrJSsLgThswDSyPyRTzFNTvX7+rMU2RncGQTKMlSOHswSWP9z4gDY 5k7FYJeJn/XMzFh7hh2ZKN2RGGXVyacV995Ac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CDIxaK5XX1he2V+PqxXF4SxUgffAFMYXkaPiJpN+d6I=; b=JF7DQ/x2Ti2TN5RxH+PlHwvZ1L6Up5JCqstM/D84w1CHyAWRnn87tfdSbDXd51B9hb rGI4COtvHAVPRsOSHVDFamDihK/vq9OC7rGnpIifs7ZIxhE47UGfbKzF3B90bYgEkzSN dwDYBUlvr6WMRBhucei0LZxdpVKYvVDkFJ9UqXTcHB6kyyDFSJuSW/QtpuMLq96jF7of UnNyNQjYymMaapFNHUEEHHyh2Obfu6yuOyZASZ0lO0E92vSmagVox2YF5nqUyFqUxXML Wb8Sx6kZPSuW7IzFiTHAfeOxE4ZXlR5okCZ2q22FDr29u9I2FJY3DLpiKbEecHacdscJ F49w== X-Gm-Message-State: APjAAAVQshvNiIC5+yhCsJoVXei/cXiCJrxsGvyyfnay4rEqnUumKSOB iG//eCCjjm/3GRXRWUI9vUqt/HU1qc+e5hKHwQUvMg== X-Received: by 2002:aca:b805:: with SMTP id i5mr4232004oif.110.1572962309401; Tue, 05 Nov 2019 05:58:29 -0800 (PST) MIME-Version: 1.0 References: <20191025234834.28214-1-john.stultz@linaro.org> <20191104095823.GD10326@phenom.ffwll.local> <20191105094259.GX10326@phenom.ffwll.local> <5b591240-43c8-495a-e9c9-881a2997c492@ti.com> In-Reply-To: <5b591240-43c8-495a-e9c9-881a2997c492@ti.com> From: Daniel Vetter Date: Tue, 5 Nov 2019 14:58:18 +0100 Message-ID: Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules To: "Andrew F. Davis" Cc: John Stultz , lkml , Sandeep Patil , Mike Rapoport , Chenbo Feng , Alistair Strachan , Liam Mark , Yue Hu , dri-devel , Hridya Valsaraju , Andrew Morton , Pratik Patel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 5, 2019 at 2:30 PM Andrew F. Davis wrote: > > On 11/5/19 4:42 AM, Daniel Vetter wrote: > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: > >> On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: > >>> On Fri, Oct 25, 2019 at 11:48:32PM +0000, John Stultz wrote: > >>>> Now that the DMA BUF heaps core code has been queued, I wanted > >>>> to send out some of the pending changes that I've been working > >>>> on. > >>>> > >>>> For use with Android and their GKI effort, it is desired that > >>>> DMA BUF heaps are able to be loaded as modules. This is required > >>>> for migrating vendors off of ION which was also recently changed > >>>> to support modules. > >>>> > >>>> So this patch series simply provides the necessary exported > >>>> symbols and allows the system and CMA drivers to be built > >>>> as modules. > >>>> > >>>> Due to the fact that dmabuf's allocated from a heap may > >>>> be in use for quite some time, there isn't a way to safely > >>>> unload the driver once it has been loaded. Thus these > >>>> drivers do no implement module_exit() functions and will > >>>> show up in lsmod as "[permanent]" > >>>> > >>>> Feedback and thoughts on this would be greatly appreciated! > >>> > >>> Do we actually want this? > >> > >> I guess that always depends on the definition of "we" :) > >> > >>> I figured if we just state that vendors should set up all the right > >>> dma-buf heaps in dt, is that not enough? > >> > >> So even if the heaps are configured via DT (which at the moment there > >> is no such binding, so that's not really a valid method yet), there's > >> still the question of if the heap is necessary/makes sense on the > >> device. And the DT would only control the availability of the heap > >> interface, not if the heap driver is loaded or not. > > > > Hm I thought the cma regions are configured in DT? How does that work if > > it's not using DT? > > > >> On the HiKey/HiKey960 boards, we have to allocate contiguous buffers > >> for the display framebuffer. So gralloc uses ION to allocate from the > >> CMA heap. However on the db845c, it has no such restrictions, so the > >> CMA heap isn't necessary. > > > > Why do you have a CMA region for the 2nd board if you don't need it? > > _That_ sounds like some serious memory waster, not a few lines of code > > loaded for nothing :-) > > > >> With Android's GKI effort, there needs to be one kernel that works on > >> all the devices, and they are using modules to try to minimize the > >> amount of memory spent on functionality that isn't universally needed. > >> So on devices that don't need the CMA heap, they'd probably prefer not > >> to load the CMA dmabuf heap driver, so it would be best if it could be > >> built as a module. If we want to build the CMA heap as a module, the > >> symbols it uses need to be exported. > > > > Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not. > > > >>> Exporting symbols for no real in-tree users feels fishy. > >> > >> I'm submitting an in-tree user here. So I'm not sure what you mean? I > >> suspect you're thinking there is some hidden/nefarious plan here, but > >> really there isn't. > > > > I was working under the assumption that you're only exporting the symbols > > for other heaps, and keep the current ones in-tree. Are there even any > > out-of-tree dma-buf heaps still? out-of-tree and legit different use-case > > I mean ofc, not just out-of-tree because inertia :-) > > Not sure what you mean here, hopefully all the heaps can be "in-tree" > some day. > > https://patchwork.kernel.org/patch/10863957/ No idea this is good or bad, where's the userspace for it? > Plus some non-caching heaps and one that forces early allocation of our > PAT (gart like) IP. Hm, so essentially we'd need to move _all_ drm allocators into dma-buf heaps, for all drivers? Can't just do this for TI only ... > All this stuff is going into our evil vendor tree next cycle (if not > upstream by then :)), if we want some of these "specialty" heaps to go > into generic kernel builds at some point they will need to be modules if > the core is. > > Although I am still thinking Heaps should be always built in + system + > CMA heaps, then the rando heaps could be modules if needed. Yeah that's what I'd expected to happen. Speciality heaps for when you have the relevant something unusual (and I'm not sure whether upstream does want something unusual really, the above examples from you sound a bit strange). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch