From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752214AbbJSNjD (ORCPT ); Mon, 19 Oct 2015 09:39:03 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:47704 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750904AbbJSNjB (ORCPT ); Mon, 19 Oct 2015 09:39:01 -0400 Date: Mon, 19 Oct 2015 14:38:20 +0100 From: Russell King - ARM Linux To: Liviu Dudau Cc: David Airlie , Daniel Vetter , Philipp Zabel , Mark Yao , Heiko Stuebner , dri-devel , linux-rockchip , LAKML , LKML Subject: Re: [RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters. Message-ID: <20151019133820.GD32532@n2100.arm.linux.org.uk> References: <1445257313-7147-1-git-send-email-Liviu.Dudau@arm.com> <1445257313-7147-2-git-send-email-Liviu.Dudau@arm.com> <20151019122537.GZ32532@n2100.arm.linux.org.uk> <20151019130258.GU3394@e106497-lin.cambridge.arm.com> <20151019132638.GB32532@n2100.arm.linux.org.uk> <20151019133255.GV3394@e106497-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151019133255.GV3394@e106497-lin.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 19, 2015 at 02:32:55PM +0100, Liviu Dudau wrote: > On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > > > Please don't move this into here, it's completely inappropriate. Just > > > > because something makes use of this does not mean they only support > > > > 32-bit DMA. Besides, this has nothing to do with whether or not it's > > > > OF-based or not. > > > > > > Understood. My thinking process was that component-based drivers are all > > > OF-enabled (how else do you make use of the framework?) and 32-bit DMA is > > > present in 2 out of 3 drivers that are converted, so it looks to be common > > > enough that adding it to armada would not hurt. It was all done in the name of > > > collecting common code in a single function. > > > > Which is an utterly crap reason. > > > > It's also not appropriate. I'm really not sure why you think that moving > > this here would in any way be appropriate - from my point of view, the > > mere proposal is utterly insane. > > The proposal is to collect similar code present in DRM drivers that act as > component masters in one place in order to reduce code duplication. I want to > add another DRM driver that will make use of the same code and did not see > any reason to copy paste one of the slightly similar versions that are now > peppered in the drivers/drm drivers. I know why people want to set the DMA mask on the "software" component, and that's drivers/gpu/drm/drm_gem_cma_helper.c, which wants to use drm->dev as the struct device to allocate memory against. That's not really appropriate, and probably ought to get fixed. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.