Am 07.07.2014 17:30, schrieb Guillaume Gardet:
Le 07/07/2014 17:22, Andreas Färber a écrit :
Le 06/07/2014 17:50, Andreas Färber a écrit :
* Samsung Exynos is now in default flavor, drop exynos flavor Did you test it on an exynos board? Since it's not building due to OMAP, how could I? Question is how to
Am 07.07.2014 09:54, schrieb Guillaume Gardet: proceed. If no one knows a fix, my proposal would be to disable the offending OMAP DRM code, so that we have a build at all, to test on the other boards.
What is the problem with OMAP DRM? Do you have some build log somewhere?
With the "default" config: $ make -j5 modules [...] CC [M] drivers/gpu/drm/omapdrm/omap_plane.o CC [M] drivers/iio/gyro/itg3200_core.o drivers/gpu/drm/omapdrm/omap_plane.c: In function ‘omap_plane_pre_apply’: drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 5 has type ‘dma_addr_t’ [-Werror=format=] DBG("%d,%d %08x %08x", info->pos_x, info->pos_y, ^ drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ [-Werror=format=] cc1: all warnings being treated as errors CC [M] drivers/gpu/drm/nouveau/core/engine/graph/nv35.o scripts/Makefile.build:273: recipe for target 'drivers/gpu/drm/omapdrm/omap_plane.o' failed make[4]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1 scripts/Makefile.build:434: recipe for target 'drivers/gpu/drm/omapdrm' failed make[3]: *** [drivers/gpu/drm/omapdrm] Error 2 CC [M] drivers/gpu/drm/nouveau/core/engine/graph/nv40.o make[3]: *** Warte auf noch nicht beendete Prozesse... [...] scripts/Makefile.build:434: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:434: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 make[1]: *** Warte auf noch nicht beendete Prozesse...
I do have several -rc2 and -rc3 based Exynos boards running and checked for USB, PHY, DRM, etc. drivers to be enabled.
Driver compiled and driver working are two different things. ;)
Before dropping the -exynos flavour, it would be great to test -default on exynos based boards. No?
Again, to test -default, we need a building kernel-default first. Like I said above, I have drivers *running* on multiple Exynos devices: * Spring (5250; with device tree being upstreamed), * Arndale Octa (5420; with kernel patch for U-Boot memory brokenness not yet in -rc3 - regression from 3.15 but we never had a successful 3.15 build), * ODROID-XU (5410; device tree WIP, no USB yet - no regression since new in 3.16). I further tested -rc3 on * Zynq based Parallella (with device tree being upstreamed) and * APQ8064 based IFC6410 (with downstream Linaro patches for SD etc.), as well as -rc2 on * Cubietruck (no serial output, but booting). Difference is that for practical reasons I avoid modules locally and started based on exynos_defconfig/multi_v7_defconfig. But if the drivers build, they should work as modules, too. Anyway, whether a driver is working or not shouldn't keep us from updating to the latest kernel in :HEAD. I get the feeling you don't understand why we had -exynos: There simply isn't the old-style Exynos-with-device-trees machine any more that required its own exynos flavor, so it's just options and drivers we enable in -default now. And if some option were missing, it's certainly easier to enable them based on a config that's in kernel-source.git than everyone starting over based on the 3.15 config. So I clearly disagree that leaving an exynos flavor around is of any value - it's preserved in git history. If you insist, we could split up the config update into just make oldconfig, Exynos driver enabling, etc. but I hadn't seen you do so, so I considered it unnecessary. What's left Exynos-side (which was what I had in mind when cautioning against dropping it previously) is S5PV210 and S5PC100, which are not yet converted to multi-platform; but they were not in -exynos before, as they are separate machines, and I do not see a reason to do a new -s5pv210 flavor now when S5PV210 is scheduled for conversion to multi-platform and S5PC100 is being dropped for 3.17. The S5PC210 armStoneA8 required its own downstream machine, so I'm waiting for the upstream conversion to put together a .dts for it if no one beats me to it. Also, none of this should block building arm64 and armv6hl 3.16 kernels. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org