Am Freitag, den 16.11.2012, 11:00 -0500 schrieb Paul Gortmaker: > On 12-11-16 10:21 AM, Philipp Zabel wrote: > > Am Freitag, den 16.11.2012, 10:08 -0500 schrieb Paul Gortmaker: > >> On 12-11-16 05:30 AM, Philipp Zabel wrote: > >>> This patch depends on "genalloc: add a global pool list, > >>> allow to find pools by phys address", which provides the > >>> of_get_named_gen_pool function. > >>> > >>> Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> > >>> --- > >>> drivers/media/platform/Kconfig | 3 +-- > >>> drivers/media/platform/coda.c | 47 > >>> ++++++++++++++++++++++++++++------------ > >>> 2 files changed, 34 insertions(+), 16 deletions(-) > >>> > >>> diff --git a/drivers/media/platform/Kconfig > >>> b/drivers/media/platform/Kconfig > >>> index 181c768..09d45c6 100644 > >>> --- a/drivers/media/platform/Kconfig > >>> +++ b/drivers/media/platform/Kconfig > >>> @@ -130,10 +130,9 @@ if V4L_MEM2MEM_DRIVERS > >>> > >>> config VIDEO_CODA > >>> tristate "Chips&Media Coda multi-standard codec IP" > >>> - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC > >>> + depends on VIDEO_DEV && VIDEO_V4L2 > >> > >> What was the logic for reducing the dependency scope here? > >> Your commit log doesn't mention that at all, and when I see > >> things like that, I predict allyesconfig build failures, > >> unless there is a similar dependency elsewhere that isn't > >> visible in just the context of this patch alone. > >> > >> P. > > > > iram_alloc and iram_free are i.MX specific wrappers around > > gen_pool_alloc and gen_pool_free, located in <mach/iram.h>. > > Those were responsible for the dependency in the first place. > > So when I do an allyesconfig for sparc, or parisc or alpha, > and VIDEO_CODA gets selected, it will build just fine then?
I don't know, as I don't have compilers for those available right now. I'd like to know if it doesn't, though. It builds fine on x86 and mips, for example. > My point was that when you remove the ARCH_MXC dep, this > probably gets opened up as a viable option to a _lot_ more > platforms than you might want it exposed to. I don't see the problem. Isn't this a good thing? regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
