| Message ID | 4194408.X82ccDjh5X@wuerfel |
|---|---|
| State | New |
| Headers | show |
On Fri, Jan 01, 2016 at 03:38:53PM +0100, Arnd Bergmann wrote: > The hdlcd driver has no build-time dependency on the SCPI clock > and the bogus 'select' causes a warning when SCPI is disabled: > > warning: (DRM_HDLCD) selects COMMON_CLK_SCPI which has unmet direct dependencies (COMMON_CLK && (ARM_SCPI_PROTOCOL || COMPILE_TEST)) > > This removes the select statement. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > Found two more bugs in the same driver, so this is now a patch series Reviewed-by: Thierry Reding <treding@nvidia.com>
On Fri, Jan 01, 2016 at 03:09:10PM +0100, Arnd Bergmann wrote: > The newly added DRM_HDLCD driver tries to select DMA_CMA, but that is > not necessarily possible, as not all configurations contain HAVE_DMA_CONTIGUOUS: > > warning: (DRM_HDLCD) selects DMA_CMA which has unmet direct dependencies (HAVE_DMA_CONTIGUOUS && CMA) > drivers/built-in.o: In function `dma_alloc_from_contiguous': > :(.text+0x1dee00): undefined reference to `cma_alloc' > drivers/built-in.o: In function `dma_release_from_contiguous': > :(.text+0x1dee24): undefined reference to `cma_release' > > This removes the 'select' statement. It is not needed because CMA is meant > to transparently change the behavior of dma_alloc_coherent to make it succeed > for larger allocations, but there is no actual build-time dependency, and > the driver can still work without CMA in many cases. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Fixes: 1561e558334d ("drm: Add support for ARM's HDLCD controller.") > --- > Found on ARM randconfig builds with yesterday's linux-next Reviewed-by: Thierry Reding <treding@nvidia.com>
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
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 >
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
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 >
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 5e8c8a86860b..2f4d3b7fb871 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -10,7 +10,6 @@ config DRM_HDLCD depends on DRM_ARM depends on COMMON_CLK select COMMON_CLK_SCPI - select DMA_CMA select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER help
The newly added DRM_HDLCD driver tries to select DMA_CMA, but that is not necessarily possible, as not all configurations contain HAVE_DMA_CONTIGUOUS: warning: (DRM_HDLCD) selects DMA_CMA which has unmet direct dependencies (HAVE_DMA_CONTIGUOUS && CMA) drivers/built-in.o: In function `dma_alloc_from_contiguous': :(.text+0x1dee00): undefined reference to `cma_alloc' drivers/built-in.o: In function `dma_release_from_contiguous': :(.text+0x1dee24): undefined reference to `cma_release' This removes the 'select' statement. It is not needed because CMA is meant to transparently change the behavior of dma_alloc_coherent to make it succeed for larger allocations, but there is no actual build-time dependency, and the driver can still work without CMA in many cases. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 1561e558334d ("drm: Add support for ARM's HDLCD controller.") --- Found on ARM randconfig builds with yesterday's linux-next