On 23.06.14 15:40, Guillaume Gardet wrote:
Le 17/06/2014 13:42, Jean Delvare a écrit :
Le Wednesday 28 May 2014 à 13:55 +0200, Alexander Graf a écrit :
On 27.05.14 19:10, Guillaume Gardet wrote:
Le 27/05/2014 09:42, Jean Delvare a écrit :
I am wondering if our default armv7 kernel is supposed to support the shmobile architecture? I see the following: shmobile is an ARMv7 from Renesas. It seems there are some boards out, but I have no such boards here. Not sure if there are cheap "open" boards availaible.
# CONFIG_ARCH_SHMOBILE_LEGACY is not set CONFIG_ARCH_SHMOBILE=y CONFIG_ARCH_SHMOBILE_MULTI=y CONFIG_SHMOBILE_TIMER_HZ=128 CONFIG_I2C_SH_MOBILE=m # CONFIG_VIDEO_SH_MOBILE_CSI2 is not set # CONFIG_VIDEO_SH_MOBILE_CEU is not set CONFIG_DRM_SHMOBILE=m # CONFIG_FB_SH_MOBILE_LCDC is not set # CONFIG_FB_SH_MOBILE_MERAM is not set # CONFIG_SHMOBILE_IOMMU is not set
which gives me the feeling that we half-support it, which is not terribly useful. Can we make a decision and either enable all these drivers or disable shmobile support altogether? I don't care which way we go, but I would enjoy some consistency. I agree we should either drop it or get a full support.
Maybe Dirk, Alex and/or Andreas have an opinion about this SoC support? I don't see why we should proactively deactivate board support for systems that are successfully multiplatformed. On x86 we also don't deactivate support for a particular wifi card just because we don't happen to have it around, no?
The more coverage we have in the default kernel, the less effort a board bringup will be :). Sorry for the late reply. I tried enabling full SH_MOBILE support in the armv7hl/default kernel and this leads to the following changes:
+CONFIG_NEED_SG_DMA_LENGTH=y +CONFIG_ARM_DMA_USE_IOMMU=y +CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 -# CONFIG_VIDEO_SH_VOU is not set +CONFIG_VIDEO_SH_VOU=m -# CONFIG_VIDEO_SH_MOBILE_CSI2 is not set -# CONFIG_VIDEO_SH_MOBILE_CEU is not set +CONFIG_VIDEO_SH_MOBILE_CSI2=m +CONFIG_VIDEO_SH_MOBILE_CEU=m -# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_BACKLIGHT=y -# CONFIG_FB_SH_MOBILE_LCDC is not set +CONFIG_FB_SH_MOBILE_LCDC=m +CONFIG_FB_SH_MOBILE_HDMI=m -# CONFIG_FB_SH_MOBILE_MERAM is not set +CONFIG_FB_SH_MOBILE_MERAM=m -# CONFIG_SHMOBILE_IOMMU is not set +CONFIG_SHMOBILE_IPMMU=y +CONFIG_SHMOBILE_IPMMU_TLB=y +CONFIG_SHMOBILE_IOMMU=y +CONFIG_SHMOBILE_IOMMU_ADDRSIZE_2048MB=y +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_1024MB is not set +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_512MB is not set +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_256MB is not set +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_128MB is not set +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_64MB is not set +# CONFIG_SHMOBILE_IOMMU_ADDRSIZE_32MB is not set +CONFIG_SHMOBILE_IOMMU_L1SIZE=8192
This brings a couple questions: * This enables CONFIG_NEED_SG_DMA_LENGTH, CONFIG_ARM_DMA_USE_IOMMU and CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8. These changes affect the kernel as a whole. Is it a problem? I think it is ok, but would be nice to have another opinion. ;)
* This also enables CONFIG_FB_BACKLIGHT, I suppose this is OK. This is ok.
* CONFIG_SHMOBILE_IOMMU requires an address size to be selected. The default is 2 GB, I have no idea if this is right for us. I would say it isOK but I do not know SH Mobile SoC very well.
I can apply the above if you guys are fine with these changes. Me, I know too little about ARM to say if it's OK.
I should commit those changes. Alex, Dirk, any objection?
Not from my side :). I like IOMMUs. Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org