Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300547 > unrolled thread

Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Thierry Reding <thierry.reding@gmail.com> - 2016-01-04 09:30 +0100
    Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Arnd Bergmann <arnd@arndb.de> - 2016-01-04 09:50 +0100
      Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Liviu Dudau <liviu.dudau@arm.com> - 2016-01-11 12:20 +0100
        Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Arnd Bergmann <arnd@arndb.de> - 2016-01-11 13:20 +0100
          Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Liviu Dudau <liviu.dudau@arm.com> - 2016-01-11 13:30 +0100
            Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Arnd Bergmann <arnd@arndb.de> - 2016-01-11 15:10 +0100
              Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency Liviu Dudau <liviu.dudau@arm.com> - 2016-01-11 15:20 +0100

#1300547 — Re: [PATCH 4/3] drm: arm-hdlcd: add explictit DRM dependency

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 01, 2016 at 11:04:07PM +0100, Arnd Bergmann wrote:
> CONFIG_DRM_HDLCD is a tristate option that depends on the boolean
> CONFIG_DRM_ARM, which in turn depends on the tristate CONFIG_DRM.
> The effect of this is that a configuration with CONFIG_DRM=m
> and CONFIG_DRM_HDLCD=y can be chosen, but won't link because the
> DRM core symbols are not reachable from builtin code:
> 
> drivers/built-in.o: In function `hdlcd_drm_unbind':
> drivers/gpu/drm/arm/hdlcd_drv.c:445: undefined reference to `drm_fbdev_cma_fini'
> drivers/gpu/drm/arm/hdlcd_drv.c:448: undefined reference to `drm_kms_helper_poll_fini'
> drivers/gpu/drm/arm/hdlcd_drv.c:450: undefined reference to `drm_vblank_cleanup'
> drivers/gpu/drm/arm/hdlcd_drv.c:452: undefined reference to `drm_irq_uninstall'
> drivers/gpu/drm/arm/hdlcd_drv.c:460: undefined reference to `drm_mode_config_cleanup'
> drivers/gpu/drm/arm/hdlcd_drv.c:461: undefined reference to `drm_dev_unregister'
> drivers/gpu/drm/arm/hdlcd_drv.c:462: undefined reference to `drm_dev_unref'
> ...
> 
> This adds another dependency on CONFIG_DRM to enforce that DRM_HDLCD
> cannot be builtin if DRM is not.

Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
a completely superfluous option to me. I don't think we've ever had the
equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd
need to start now. If ARM was going to add another driver it can simply
have a separate Kconfig entry. There should be no need to select the
vendor option first.

Thierry

[toc] | [next] | [standalone]

#1300557

On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> 
> Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> a completely superfluous option to me. I don't think we've ever had the
> equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd
> need to start now. If ARM was going to add another driver it can simply
> have a separate Kconfig entry. There should be no need to select the
> vendor option first.

Fine with me too. I vaguely remembered having seen some discussion about
this, so I decided to do a minimal fix, but I agree that would be more
in line with the other drivers.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1306089

On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> > 
> > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> > a completely superfluous option to me. I don't think we've ever had the
> > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd
> > need to start now. If ARM was going to add another driver it can simply
> > have a separate Kconfig entry. There should be no need to select the
> > vendor option first.
> 
> Fine with me too. I vaguely remembered having seen some discussion about
> this, so I decided to do a minimal fix, but I agree that would be more
> in line with the other drivers.
> 
> 	Arnd
> 

Arnd,

I'm OK with the whole series of Kconfig clean-up/fixes and I offer my appologies
for adding noise with my patchset. Please let me know how do you prefer to handle
them. I'm OK with merging your changes into my series before sending the pull
request to David Airlie.

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[toc] | [prev] | [next] | [standalone]

#1306120

On Monday 11 January 2016 11:12:56 Liviu Dudau wrote:
> On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> > On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> > > 
> > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> > > a completely superfluous option to me. I don't think we've ever had the
> > > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd
> > > need to start now. If ARM was going to add another driver it can simply
> > > have a separate Kconfig entry. There should be no need to select the
> > > vendor option first.
> > 
> > Fine with me too. I vaguely remembered having seen some discussion about
> > this, so I decided to do a minimal fix, but I agree that would be more
> > in line with the other drivers.
> > 
> >       Arnd
> > 
> 
> Arnd,
> 
> I'm OK with the whole series of Kconfig clean-up/fixes and I offer my appologies
> for adding noise with my patchset. Please let me know how do you prefer to handle
> them. I'm OK with merging your changes into my series before sending the pull
> request to David Airlie.

Please merge them into your tree if you have some other changes to send to him.

I just realized that these are in your own git tree at the moment, not
in drm-next. I guess that means you will rebase the whole series after -rc1 and
submit it into linux-4.6, right?

If so, just fold my fixes into your patches when you rebase.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1306129

On Mon, Jan 11, 2016 at 01:18:55PM +0100, Arnd Bergmann wrote:
> On Monday 11 January 2016 11:12:56 Liviu Dudau wrote:
> > On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote:
> > > On Monday 04 January 2016 09:24:16 Thierry Reding wrote:
> > > > 
> > > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like
> > > > a completely superfluous option to me. I don't think we've ever had the
> > > > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd
> > > > need to start now. If ARM was going to add another driver it can simply
> > > > have a separate Kconfig entry. There should be no need to select the
> > > > vendor option first.
> > > 
> > > Fine with me too. I vaguely remembered having seen some discussion about
> > > this, so I decided to do a minimal fix, but I agree that would be more
> > > in line with the other drivers.
> > > 
> > >       Arnd
> > > 
> > 
> > Arnd,
> > 
> > I'm OK with the whole series of Kconfig clean-up/fixes and I offer my appologies
> > for adding noise with my patchset. Please let me know how do you prefer to handle
> > them. I'm OK with merging your changes into my series before sending the pull
> > request to David Airlie.
> 
> Please merge them into your tree if you have some other changes to send to him.
> 
> I just realized that these are in your own git tree at the moment, not
> in drm-next. I guess that means you will rebase the whole series after -rc1 and
> submit it into linux-4.6, right?

Yes, that is the plan.

> 
> If so, just fold my fixes into your patches when you rebase.

OK, will do. Repeating the question on another thread: are you OK with me carrying
the Juno .dts changes through drm-next for HDLCD and you picking up Robin Murphy's
patch? AFAIK those are the only changes at the moment until Sudeep re-submits the
Juno r2 dts changes.

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[toc] | [prev] | [next] | [standalone]

#1306269

On Monday 11 January 2016 12:26:44 Liviu Dudau wrote:
> > If so, just fold my fixes into your patches when you rebase.
> 
> OK, will do. Repeating the question on another thread: are you OK with me carrying
> the Juno .dts changes through drm-next for HDLCD and you picking up Robin Murphy's
> patch? AFAIK those are the only changes at the moment until Sudeep re-submits the
> Juno r2 dts changes.

Is there a strong reason for it? Usually the preferred way is to merge all
dts changes through arm-soc, but we can make exceptions if necessary.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1306285

On Mon, Jan 11, 2016 at 02:49:10PM +0100, Arnd Bergmann wrote:
> On Monday 11 January 2016 12:26:44 Liviu Dudau wrote:
> > > If so, just fold my fixes into your patches when you rebase.
> > 
> > OK, will do. Repeating the question on another thread: are you OK with me carrying
> > the Juno .dts changes through drm-next for HDLCD and you picking up Robin Murphy's
> > patch? AFAIK those are the only changes at the moment until Sudeep re-submits the
> > Juno r2 dts changes.
> 
> Is there a strong reason for it? Usually the preferred way is to merge all
> dts changes through arm-soc, but we can make exceptions if necessary.

No strong reason, just packing the series in a logical way. I'm happy to split the
pull requests. Will send the dts changes to you then.

Best regards,
Liviu

> 
> 	Arnd
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web