Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2854607imd; Sun, 28 Oct 2018 20:12:30 -0700 (PDT) X-Google-Smtp-Source: AJdET5dAcTrSlYGbAdIPHKI8f8dQNqOOpk+jiyWG2bhM4ilHbmMJEA0qRqWj7WoqhOkHGbJE/5au X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr12615268plq.24.1540782750310; Sun, 28 Oct 2018 20:12:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540782750; cv=none; d=google.com; s=arc-20160816; b=oj0EF4bMZIG2OgTn2G0saqdVK8TQ8C51kWlufjMSGQuL0C/P+HrJyECvd1KC50H2X2 sIyKV34gVbazj7i+6zjVXOUqnIDAjE9yKpC6sgQ9yFY+ihc3a+Uysc3tGgZmd/5e5EaJ U32JfIjpl1xVMkLFLy92viNOuJyTYGXovstX2BTugRUM0rkQjfp+siYGNmMo7akClms/ qfpEAWHyrNIHj9vieKsgcpxPfEaFO84QLx5llCHZdh3Sai9q2ok94uGtIlisYF1U/2g2 ey2otLMwNLc9mrfoJhivhd2ZcLk0CrzbzZP8kDcPfnyCJhNjnj2tDRTnM/uZqPYbwkwB jXpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=XRw99MIts7cxJObunTVP+p4/bsxslXlNTpql/RdSz1I=; b=GGYIO5X1ThWMTaO+3GDIhT+ls3xRRaF81+iQq0haugyO32sTGluCHyiCIWXJIU8K3J x+EcD7/Kms5c+4yAibtQPC5FN9IuK7YgmD6zlz0O0MbO2XsqRqlJpiFto3JWdi2eSCHa yA3AL0V8TPPEpj6N19IukYDqosBUP6li7b1tdOQuo5MPgbnrs3ZGW11oxLS/+W+7FoBQ 5xa6Jz3vFygrFWuo9TVX7W5CQObkgPOtviJXQmL77XjDOwJT9VAAQMW/NM27hsjg+o3k 4I77yOIhnDkSmMX9NpK02RSPF8zneFVODrrDCa10OHxZ9wTVFfn4ckOZ151GtI3vFhMr SWmA== ARC-Authentication-Results: i=1; mx.google.com; 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 201-v6si9933056pfv.169.2018.10.28.20.12.15; Sun, 28 Oct 2018 20:12:30 -0700 (PDT) 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; 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 S1729257AbeJ2L6f (ORCPT + 99 others); Mon, 29 Oct 2018 07:58:35 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:28296 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729142AbeJ2L6f (ORCPT ); Mon, 29 Oct 2018 07:58:35 -0400 X-UUID: 91b3b6bc22aa4b4ea569d6bf4406d0a8-20181029 X-UUID: 91b3b6bc22aa4b4ea569d6bf4406d0a8-20181029 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 2080718267; Mon, 29 Oct 2018 11:11:18 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs03n2.mediatek.inc (172.21.101.182) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 11:11:16 +0800 Received: from [172.21.77.4] (172.21.77.4) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 29 Oct 2018 11:11:16 +0800 Message-ID: <1540782676.13715.4.camel@mtksdaap41> Subject: Re: [PATCH 3/3] drm/mediatek: Use drm_gem_cma_object instead of mtk_drm_gem_obj From: CK Hu To: Daniel Vetter CC: Daniel Vetter , David Airlie , Gustavo Padovan , Maarten Lankhorst , Sean Paul , "Philipp Zabel" , Matthias Brugger , , , , , Date: Mon, 29 Oct 2018 11:11:16 +0800 In-Reply-To: <20181026102156.GH21967@phenom.ffwll.local> References: <1540538523-1973-1-git-send-email-ck.hu@mediatek.com> <1540538523-1973-4-git-send-email-ck.hu@mediatek.com> <20181026102156.GH21967@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-SNTS-SMTP: 796F07C8841D1A99995A87FD48162DFBD488881728D65E08D8630C4E444656732000:8 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi,Daniel: On Fri, 2018-10-26 at 12:21 +0200, Daniel Vetter wrote: > On Fri, Oct 26, 2018 at 03:22:03PM +0800, CK Hu wrote: > > After adding dma_dev in struct drm_device and > > drm_gem_cma_dumb_create_no_kmap(), drm_gem_cma_object could replace > > mtk_drm_gem_obj, so use drm_gem_cma_object instead of mtk_drm_gem_obj to > > reduce redundant code. > > > > Signed-off-by: CK Hu > > A few questions/thoughts: > > - Why do you need both drm_device->dev and drm_device->dma_dev? Can't you > just register the drm_device with the right struct device? > In [1], mmsys is the drm driver and ovl0 and ovl1 is the sub device which has dma function. In this drm, there are two crtc and each one is comprised of many component. This is an example of mt8173: crtc0: ovl0, color0, aal, od, rdma0, ufoe, dsi0 crtc1: ovl1, color1, gamma, rdma1, dpi0 In the device node of ovl0 and ovl1, there is a 'iommus' parameter in it, so use dma_alloc_xxx() and dma_map_xxx() with that device would get iova rather than pa. I don't think it's a good idea to register ovl0 or ovl1 as drm device because each one is just a component in a pipeline. mmsys controls the clock and routing of multi-media system which include this drm system, so it's better to register mmsys as drm device. Maybe we could move 'iommus' parameter from ovl device to mmsys device, so the dma device changes from ovl device to mmsys device. I'm not sure this would be a good choice, how do you think? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v4.19 > - You don't use drm_gem_prime_import_dev, so prime import isn't using the > right device either. Yes, you are right. I'm not familiar with whore drm core, so I start to modify what Mediatek drm use. But this function still works for the drm device that itself is dma device. If one day there is a drm device which itself is not a dma device and need this function, send a patch to modify this function and test it with that drm device. If you want me to modify all in advance, I'm ok but need others to test it because Mediatek drm driver does not use them. > > - exynos seems to have the same or at least similar issue, stronger case > for your patches if you can solve both. I'm still Mediatek's employee. If I modify other company's driver and it is not a MUST-BE for Mediatek, Mediatek may think I give contribution to other company. So I've better not to modify exynos driver. > - I'd start out with using struct drm_gem_cma_object in mtk (similar to > what vc4 does), and then reusing as much as possible of the existing > helpers. And then looking later on what's still left (like the support > for leaving out the virtual mapping). I'm not clear what vc4 does. It looks like that you want me to redefine mtk_drm_gem_obj based on drm_gem_cma_object. So it would be like struct mtk_drm_gem_obj { struct drm_gem_cma_object base; void *cookie; unsigned long dma_attrs; }; I could try to modify as this and see what have left. Regards, CK > > -Daniel > [Snip...] > > --- > > -- > > 1.9.1 > > >