Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp242234imm; Wed, 18 Jul 2018 01:06:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdvvrXghk2ELdwoQnSDDc4p0P6U3H2XKyRg4b3eVPW6x46yihDRD19ia+WU5UlCtFTNOk2M X-Received: by 2002:a63:4c21:: with SMTP id z33-v6mr4766564pga.383.1531901172216; Wed, 18 Jul 2018 01:06:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531901172; cv=none; d=google.com; s=arc-20160816; b=QK4nKNIMrthJOVRwLXAJPfY46gKcaAu0z37p90NgQ3n1dIzFl3HVNjJGHNYygs1P0l MOvp5V+K7+OFLvQxbAAKwqcgDX+L731YcRoWGEaiENp84wOki5HdCLthiENCQAqrHpob z6/6Rh2bYM4C+dK5nDQ0R/43l+wiGpXDMca2RgnXbAL/8IciwX1M7W9YslUbcaG75k1R V9/j1qp1LvaaIXy/UjiqegUaA+LqFDNk5d3hbo5ltLIiaQ/9Rd6wKXg1qtcn42mFZZbD 1RWMSfmqSa5LmgSFKesHxZOnEFRi47CCc0eblOE93+FB+XSc9ZduSNUNEBSpJj7U34dI SgOg== 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:organization:message-id:date:subject:cc:to :from:dkim-signature:arc-authentication-results; bh=r1Y3xD6N7WKEYXt+Q926Okt9kVptVbfXGrXq52YCGpI=; b=Tbcv00t++wsXF2drC3gu8fnxAglgeAKXTjoQC7zK2l+G0uWTYu/dyjf4lJYO4TAptV Hz/VlNzvJVtc785A0s2jyp4bkIEv3hOXOn9BjYF5yo5FshwYqL7yUmqARsGB8ZN1RQMN aDCsaOBl7WSuNwke2zlaeAuFCPEOENp/Av1NKOkLQdX3Q4HnLqDBb556XRXtxMzfWZI4 s/tFxL2HWz80QkMWcqXjCioQh+dPpUH7tx4VqH+4qITtgTdwnxZJP1zwv51PVl8ka2px JLbaQnEc15M9szLcjXC+lF39W4IzTe+J7GG2aKrBWIdgzGDmt0KPqFQQMesA98+7lpQ5 3OKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=LY4PdutH; 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 d2-v6si2623850pla.359.2018.07.18.01.05.56; Wed, 18 Jul 2018 01:06:12 -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; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=LY4PdutH; 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 S1727477AbeGRImC (ORCPT + 99 others); Wed, 18 Jul 2018 04:42:02 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:51636 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbeGRImB (ORCPT ); Wed, 18 Jul 2018 04:42:01 -0400 Received: from avalon.localnet (unknown [IPv6:2a02:587:8041:9d00:717d:d1d9:bcc8:c702]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id C32CBB7F; Wed, 18 Jul 2018 10:05:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1531901118; bh=dct1ju3xbBcx8BzHtIEJA0VGjWtu0xmfpnNabBz2cY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LY4PdutHFg1nhRCm0WpAyIfIWz/0l/k4+y62LAE6RIRcw1dxnkkBvK2/LWJTsW1DU eSCHV6iR/B+Pt0pcXT0HFnSdM8ulCd0tv4CS87Mhvt7kYIvx9oBQhFeXxSv7WMo0vG 6nt0uiN2To7QzK+PtYd9+azqcqHZji0LbIfHc/bc= From: Laurent Pinchart To: Sean Wang Cc: matthias.bgg@kernel.org, ulrich.hecht+renesas@gmail.com, ck.hu@mediatek.com, p.zabel@pengutronix.de, airlied@linux.ie, robh+dt@kernel.org, mark.rutland@arm.com, mturquette@baylibre.com, sboyd@codeaurora.org, lee.jones@linaro.org, davem@davemloft.net, gregkh@linuxfoundation.org, mchehab@kernel.org, rdunlap@infradead.org, pi-cheng.chen@linaro.org, linux-clk@vger.kernel.org, linux@armlinux.org.uk, matthias.bgg@gmail.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger Subject: Re: [resend PATCH v4 4/5] drm/mediatek: Add support for mmsys through a pdev Date: Wed, 18 Jul 2018 11:05:49 +0300 Message-ID: <51066716.k5MkZnrqCl@avalon> Organization: Ideas on Board Oy In-Reply-To: <1531882655.8953.83.camel@mtkswgap22> References: <20180717220328.792-1-matthias.bgg@kernel.org> <20180717220328.792-5-matthias.bgg@kernel.org> <1531882655.8953.83.camel@mtkswgap22> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sean, On Wednesday, 18 July 2018 05:57:35 EEST Sean Wang wrote: > On Wed, 2018-07-18 at 00:03 +0200, matthias.bgg@kernel.org wrote: > > From: Matthias Brugger > > > > The MMSYS subsystem includes clocks and drm components. > > This patch adds an initailization path through a platform device > > for the clock part, so that both drivers get probed from the same > > device tree compatible. > > Sorry for that I should have a response earlier for the series. > > Some points I felt they're not exactly right and should be fixed up > before we're moving on > > Currently, drm driver have a wrong reference to the dt-binding, > "mediatek,mt2701-mmsys" or "mediatek,mt8173-mmsys", they should be all > for the subsystem exporting clock and reset line such common resource to > its sub-devices. Every subsystem has a similar shape. I hope mmsys > shouldn't be an exception. > > DRM device needs to have its own dt-binding show how connections between > DRM components being made and its node should be put under mmsys node. > > In this way, it becomes easy to see how the topology of the subsystem is > and grows, like a tree "device tree", instead of hiding the details in > the implementation. > > The similar example we already did for audsys on mt2701 and mt7623 as > below > > audsys: clock-controller@11220000 { > compatible = "mediatek,mt7623-audsys", > "mediatek,mt2701-audsys", > "syscon"; > ... > > afe: audio-controller { > compatible = "mediatek,mt7623-audio", > "mediatek,mt2701-audio"; > > ... > }; > }; This looks very strange to me. I'm not familiar with the hardware architecture, but a clock controller that includes an audio controller seems like a very weird design. It's usually the other way around, you have an audio controller, and it also contains hardware that produces clocks, and possibly handles miscellaneous audio-related routing tasks. I would thus expect the reverse in the device tree: afe: audio-controller@11220000 { compatible = "mediatek,mt7623-audio", "mediatek,mt2701-audio"; .. audsys: clock-controller { compatible = "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"; ... }; }; And if audsys only exposes clocks, you don't even need a subnode to represent it, the audio controller itself can be a clock provider. afe: audio-controller@11220000 { compatible = "mediatek,mt7623-audio", "mediatek,mt2701-audio"; #clock-cells = <1>; .. }; > > Signed-off-by: Matthias Brugger > > --- > > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 18 ++++++++++++++++++ > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++ > > 2 files changed, 20 insertions(+) > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index dd249cf5121e..c946aea722e5 > > 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > @@ -173,6 +173,7 @@ static const struct mtk_mmsys_driver_data > > mt2701_mmsys_driver_data = {> > > .ext_path = mt2701_mtk_ddp_ext, > > .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext), > > .shadow_register = true, > > > > + .clk_drv_name = "clk-mt2701-mm", > > > > }; > > > > static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = { > > > > @@ -180,6 +181,7 @@ static const struct mtk_mmsys_driver_data > > mt8173_mmsys_driver_data = {> > > .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main), > > .ext_path = mt8173_mtk_ddp_ext, > > .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext), > > > > + .clk_drv_name = "clk-mt8173-mm", > > > > }; > > > > static int mtk_drm_kms_init(struct drm_device *drm) > > > > @@ -411,6 +413,19 @@ static int mtk_drm_probe(struct platform_device > > *pdev) > > > > if (IS_ERR(private->config_regs)) > > > > return PTR_ERR(private->config_regs); > > > > + if (private->data->clk_drv_name) { > > + private->clk_dev = platform_device_register_data(dev, > > + private->data->clk_drv_name, -1, > > + NULL, 0); > > + > > + if (IS_ERR(private->clk_dev)) { > > + pr_err("failed to register %s platform device\n", > > + private->data->clk_drv_name); > > + > > + return PTR_ERR(private->clk_dev); > > + } > > + } > > + > > > > /* Iterate over sibling DISP function blocks */ > > for_each_child_of_node(dev->of_node- >parent, node) { > > > > const struct of_device_id *of_id; > > > > @@ -515,6 +530,9 @@ static int mtk_drm_remove(struct platform_device > > *pdev) > > > > for (i = 0; i < DDP_COMPONENT_ID_MAX; i++) > > > > of_node_put(private->comp_node[i]); > > > > + if (private->clk_dev) > > + platform_device_unregister(private->clk_dev); > > + > > > > return 0; > > > > } > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.h index 86cec19193c4..200eee5de419 > > 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h > > @@ -34,11 +34,13 @@ struct mtk_mmsys_driver_data { > > > > const enum mtk_ddp_comp_id *ext_path; > > unsigned int ext_len; > > bool shadow_register; > > > > + const char *clk_drv_name; > > > > }; > > > > struct mtk_drm_private { > > > > struct drm_device *drm; > > struct device *dma_dev; > > > > + struct platform_device *clk_dev; > > > > unsigned int num_pipes; -- Regards, Laurent Pinchart