From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucas Stach Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x Date: Wed, 05 Dec 2012 13:02:03 +0100 Message-ID: <1354708923.1503.56.camel@tellur> References: <1353935954-13763-1-git-send-email-tbergstrom@nvidia.com> <1353935954-13763-7-git-send-email-tbergstrom@nvidia.com> <20121205083335.GA20984@avionic-0098.adnet.avionic-design.de> <50BF1DAA.8030805@nvidia.com> <20121205111332.GA25676@avionic-0098.adnet.avionic-design.de> <50BF345A.8050201@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <50BF345A.8050201-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Terje =?ISO-8859-1?Q?Bergstr=F6m?= Cc: Thierry Reding , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org" , Arto Merilainen List-Id: linux-tegra@vger.kernel.org Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergstr=C3=B6m: [...] >=20 > > The problem that this solves is that the DRM driver needs to be bou= nd to > > a specific platform device. None of the DRM subdevices are suitable > > because they are only part of the whole DRM device. I think that ho= st1x > > is the only device that fits here. > >=20 > > Note that this is only an administrative problem. It shouldn't inte= rfere > > with the way host1x works. The goal is that the DRM device is regis= tered > > at the proper hierarchical location. > >=20 > > The circular dependency is indeed a problem, though. Quite frankly = I > > have no idea how to solve this. However the approach taken in the > > current patch will break several other requirements as I already > > explained. >=20 > The problem with doing drm_platform_init() with host1x device as > parameter is that drm_get_platform_dev() will take control of drvdata= =2E > We'd need to put host1x specific struct host1x pointer to some other > place and I'm not sure what that place could be. >=20 > You're right in that binding to a sub-device is not a nice way. DRM > framework just needs a "struct device" to bind to. exynos seems to so= lve > this by introducing a virtual device and bind to that. I'm not sure i= f > this is the best way, but worth considering? >=20 I also think the introduction of a dummy platform device to aggregate the various DRM devices would be the best way to keep a clean interface between host1x and the tegradrm parts. But I haven't thought through how to instantiate such a dummy device without clobbering the device tree and sprinkling global data all over the driver. Perhaps the host1x driver could instantiate such a device and only provide a single API entry point to make this dummy-drm-device known to it's subdevices. This way we don't have to move all the drm specific aggregation of devices into host1x and could keep the API a bi= t leaner. Obviously this solution would not get around the circular dependency completely, but would cut down on it a bit. Regards, Lucas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751930Ab2LEMCI (ORCPT ); Wed, 5 Dec 2012 07:02:08 -0500 Received: from ns.km20343-01.keymachine.de ([84.19.182.79]:34632 "EHLO km20343-01.keymachine.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750803Ab2LEMCF (ORCPT ); Wed, 5 Dec 2012 07:02:05 -0500 Message-ID: <1354708923.1503.56.camel@tellur> Subject: Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x From: Lucas Stach To: Terje =?ISO-8859-1?Q?Bergstr=F6m?= Cc: Thierry Reding , "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Arto Merilainen Date: Wed, 05 Dec 2012 13:02:03 +0100 In-Reply-To: <50BF345A.8050201@nvidia.com> References: <1353935954-13763-1-git-send-email-tbergstrom@nvidia.com> <1353935954-13763-7-git-send-email-tbergstrom@nvidia.com> <20121205083335.GA20984@avionic-0098.adnet.avionic-design.de> <50BF1DAA.8030805@nvidia.com> <20121205111332.GA25676@avionic-0098.adnet.avionic-design.de> <50BF345A.8050201@nvidia.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström: [...] > > > The problem that this solves is that the DRM driver needs to be bound to > > a specific platform device. None of the DRM subdevices are suitable > > because they are only part of the whole DRM device. I think that host1x > > is the only device that fits here. > > > > Note that this is only an administrative problem. It shouldn't interfere > > with the way host1x works. The goal is that the DRM device is registered > > at the proper hierarchical location. > > > > The circular dependency is indeed a problem, though. Quite frankly I > > have no idea how to solve this. However the approach taken in the > > current patch will break several other requirements as I already > > explained. > > The problem with doing drm_platform_init() with host1x device as > parameter is that drm_get_platform_dev() will take control of drvdata. > We'd need to put host1x specific struct host1x pointer to some other > place and I'm not sure what that place could be. > > You're right in that binding to a sub-device is not a nice way. DRM > framework just needs a "struct device" to bind to. exynos seems to solve > this by introducing a virtual device and bind to that. I'm not sure if > this is the best way, but worth considering? > I also think the introduction of a dummy platform device to aggregate the various DRM devices would be the best way to keep a clean interface between host1x and the tegradrm parts. But I haven't thought through how to instantiate such a dummy device without clobbering the device tree and sprinkling global data all over the driver. Perhaps the host1x driver could instantiate such a device and only provide a single API entry point to make this dummy-drm-device known to it's subdevices. This way we don't have to move all the drm specific aggregation of devices into host1x and could keep the API a bit leaner. Obviously this solution would not get around the circular dependency completely, but would cut down on it a bit. Regards, Lucas