[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121228212125.GA4615@avionic-0098.adnet.avionic-design.de>
Date: Fri, 28 Dec 2012 22:21:25 +0100
From: Thierry Reding <thierry.reding@...onic-design.de>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Terje Bergström <tbergstrom@...dia.com>,
"airlied@...ux.ie" <airlied@...ux.ie>,
"dev@...xeye.de" <dev@...xeye.de>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arto Merilainen <amerilainen@...dia.com>
Subject: Re: [PATCHv4 5/8] drm: tegra: Remove redundant host1x
On Mon, Dec 24, 2012 at 10:25:00PM -0700, Stephen Warren wrote:
> On 12/21/2012 11:50 PM, Terje Bergström wrote:
> > On 21.12.2012 16:36, Thierry Reding wrote:
> >> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
> >>> +static struct platform_driver tegra_drm_platform_driver = {
> >>> + .driver = {
> >>> + .name = "tegradrm",
> >>
> >> This should be "tegra-drm" to match the module name.
> >
> > We've actually created two problems.
> >
> > First is that the device name should match driver name which should
> > match module name. But host1x doesn't know the module name of tegradrm.
>
> There's no hard requirement for the device/driver name to match the
> module name. It's good thing to do, but nothing will blow up if it don't
> (modules can use MODULE_ALIAS() to declare which drivers they expose).
>
> But, what's the problem with host1x knowing the driver name; the host1x
> driver and tegradrm driver are both part of the same code-base, so this
> seems trivial to achieve.
Indeed. If we define the name to match the tegra-drm module name, then
just changing the above line is fine. This doesn't need to be automatic.
Making sure that both strings match in both drivers is enough.
> > Second problem is that host1x driver creates tegradrm device even if
> > tegradrm isn't loaded to system.
>
> That's fine. If there's no driver, the device simply won't be probe()d.
> That's just like a device node existing in device tree, but the driver
> for it not being enabled in the kernel, or the relevant module not being
> inserted.
>
> > These mean that the device has to be created in tegra-drm module to have
>
> I definitely disagree here.
Instead of going over this back and forth, I've decided to rewrite this
patch from scratch the way I think it should be done. Maybe that'll make
things clearer. I haven't tested it on real hardware yet because I don't
have access over the holidays, but I'll post the patch once I've
verified that it actually works. The code is based on patches 1-4 of
this series and is meant to replace patch 5.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists