[opensuse-kernel] shmobile support in armv7hl/default kernel
Hi Guillaume, Andreas and all, I am wondering if our default armv7 kernel is supposed to support the shmobile architecture? I see the following: # 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. Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi, Le 27/05/2014 09:42, Jean Delvare a écrit :
Hi Guillaume, Andreas and all,
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? Guillaume -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 27.05.14 19:10, Guillaume Gardet wrote:
Hi,
Le 27/05/2014 09:42, Jean Delvare a écrit :
Hi Guillaume, Andreas and all,
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 :). Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 28.05.2014 13:55, schrieb Alexander Graf:
On 27.05.14 19:10, Guillaume Gardet wrote:
Le 27/05/2014 09:42, Jean Delvare a écrit :
Hi Guillaume, Andreas and all,
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 :).
I was going to reply that this is a directional question: In the past I had the impression that we only enabled things based on demand from our users and being able to test it on hardware. It seems that has changed lately towards enabling anything that doesn't hurt us in terms of kernel flavors and that may be useful to anyone. That would speak for enabling it. Practically, I'm not so sure what exactly is covered by "shmobile". There was a module with EMMA EV2: http://www.emtrion.de/dimm_emev2_en.php There's a Japenese Armadillo-800 EVA board with R-Mobile A1: http://armadillo.atmark-techno.com/armadillo-800-EVA There's also the automotive R-Car series with more interesting specs (big.LITTLE) that unfortunately they've been very tight-lipped about - might be separate from shmobile. Them not following up on business cards and emails could be considered an argument against enabling support for their SoCs as long as no one in the community actively asks for it. Then there's a Genmai board from Renesas, a module from emtrion and a low-cost Hachiko board from ArchiTech with the new RZ/A. The latter I recently inquired ArchiTech/Silica about - currently that board is shipping with only 10 MB on-chip SRAM, which I guess will be too little for openSUSE. http://www.renesas.eu/products/tools/introductory_evaluation_tools/starterki... http://www.emtrion.de/rzah_en.php http://www.architechboards.org/product/hachiko-board Cheers, 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
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? * This also enables CONFIG_FB_BACKLIGHT, I suppose 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 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. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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? Guillaume -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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
participants (4)
-
Alexander Graf
-
Andreas Färber
-
Guillaume Gardet
-
Jean Delvare