[PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 select USE_OF help -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V1] mmc: core: Add host capability check for power class
This patch adds a check whether the host supports maximum current value
obtained from the device's extended csd register for a selected interface
voltage and frequency.
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v1:
reduced the number of comparisons as per Hein's suggestion
drivers/mmc/core/mmc.c | 21 +
include/linux/mmc/card.h |4
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 006e932..e7f1902 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -688,6 +688,27 @@ static int mmc_select_powerclass(struct mmc_card *card,
pwrclass_val = (pwrclass_val EXT_CSD_PWR_CL_4BIT_MASK)
EXT_CSD_PWR_CL_4BIT_SHIFT;
+ if (pwrclass_val = MMC_MAX_CURRENT_800)
+ pwrclass_val = MMC_MAX_CURRENT_800;
+ else if (pwrclass_val = MMC_MAX_CURRENT_600)
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ else if (pwrclass_val = MMC_MAX_CURRENT_400)
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ else if (pwrclass_val = MMC_MAX_CURRENT_200)
+ pwrclass_val = MMC_MAX_CURRENT_200;
+ else
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
+ if ((pwrclass_val == MMC_MAX_CURRENT_800)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_800))
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ if ((pwrclass_val == MMC_MAX_CURRENT_600)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_600))
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ if ((pwrclass_val == MMC_MAX_CURRENT_400)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_400))
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
/* If the power class is different from the default value */
if (pwrclass_val 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 9478a6b..c5e031a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -195,6 +195,10 @@ struct mmc_part {
#define MMC_BLK_DATA_AREA_GP (12)
};
+#define MMC_MAX_CURRENT_200(0)
+#define MMC_MAX_CURRENT_400(7)
+#define MMC_MAX_CURRENT_600(11)
+#define MMC_MAX_CURRENT_800(13)
/*
* MMC device
*/
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] make s5p64x0_defconfig build error
On Wed, Dec 14, 2011 at 04:57:10AM +, Axel Lin wrote: I got below build error on linux-next 20111213. CC arch/arm/kernel/process.o In file included from arch/arm/mach-s5p64x0/include/mach/system.h:16, from arch/arm/kernel/process.c:64: arch/arm/plat-samsung/include/plat/system-reset.h:19:2: error: #error Fix me up make[1]: *** [arch/arm/kernel/process.o] Error 1 make: *** [arch/arm/kernel] Error 2 The clue is in the commit message: commit d0f7e2beabe6a116152ccc31959b6654b6ef0071 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Dec 6 12:57:02 2011 + ARM: restart: Temporary #error to persuade platform maintainers to take the restart changes seriously Force builds to fail to ensure that platform maintainers take the restart changes seriously, and sort out fixing their code before the next merge window. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Will -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/8] common: dma-mapping: change alloc/free_coherent method to more generic alloc/free_attrs
Hello, On Sunday, December 11, 2011 11:46 PM Stephen Rothwell wrote: On Fri, 09 Dec 2011 17:39:56 +0100 Marek Szyprowski m.szyprow...@samsung.com wrote: Introduce new alloc/free/mmap methods that take attributes argument. alloc/free_coherent can be implemented on top of the new alloc/free calls with NULL attributes. dma_alloc_non_coherent can be implemented using DMA_ATTR_NONCOHERENT attribute, dma_alloc_writecombine can also use separate DMA_ATTR_WRITECOMBINE attribute. This way the drivers will get more generic, platform independent way of allocating dma memory buffers with specific parameters. One more attribute can be usefull: DMA_ATTR_NOKERNELVADDR. Buffers with such attribute will not have valid kernel virtual address. They might be usefull for drivers that only exports the DMA buffers to userspace (like for example V4L2 or ALSA). mmap method is introduced to let the drivers create a user space mapping for a DMA buffer in generic, architecture independent way. TODO: update all dma_map_ops clients for all architectures To give everyone some chance, you should come up with a transition plan rather than this attempt to fix everyone at once approach. You could (for example) just add the new methods now and only remove them in the following merge window when all the architectures have had a chance to migrate. And, in fact, (as I presume you know) this patch just breaks everyone with no attempt to cope. Yes, I know that. Next version will include correct fix for this issue as well as adjustments for other architectures. I was asked to post a current version of DMA-mapping IOMMU integration patch rebased on the latest kernel and I wanted to this before going for holidays to let others to work with the latest version. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Regards, Shawn select USE_OF help -- 1.7.4.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 4/5] highbank: Unconditionally require l2x0 L2 cache controller support
On Wed, Dec 14, 2011 at 07:37:32AM -0600, Rob Herring wrote: On 12/14/2011 05:39 AM, Dave Martin wrote: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the Highbank SoC. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html Doesn't this need to be above the SOB? Otherwise: You may be right ... certainly I see no reason _not_ to change it. So I'll change it. Acked-by: Rob Herring rob.herr...@calxeda.com Thanks ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Thanks Richard Regards, Shawn select USE_OF help -- 1.7.4.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
Just a thought (not sure if it's explicitly specified in 4.5 spec or not): Do we really need to perform bus test in HS200 mode? because in HS200, we are anyways going to perform the tuning sequence (which achieves what bus test command does). Regards, Subhash -Original Message- From: Saugata Das [mailto:saugata@linaro.org] Sent: Tuesday, December 13, 2011 11:03 AM To: Girish K S Cc: Subhash Jadavani; linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-soc@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 13 December 2011 10:13, Girish K S girish.shivananja...@linaro.org wrote: On 12 December 2011 12:20, Girish K S girish.shivananja...@linaro.org wrote: On 5 December 2011 20:29, Saugata Das saugata@linaro.org wrote: Hi Girish Please refer to Figure 71 (HS200 device output timing) of the MMC- 4.5 spec. It shows that both CMD and DATA[7-0] will have some latency till valid window. This implies that even the CMD line will need tuning for reading the response. The specification talks about identifying sampling point for data lines by reading tuning blocks. Based on host controller capability, even the CMD line will get the good sample point during the same tuning sequence. We need to have the tuning done (execute_tuning) soon after switching to HS200 mode and 200MHz clock. If i make a change as per subhash suggestionset bus width before setting the HS200 mode. then it will affect the entire frame work of mmc which is developed as per Annexure A6.1 A.6.2 A.6.3 (mentions the steps for bus initialization). can any of you suggest a way to do this. Note that, we need to make this modification only for HS200 mode. For DDR mode, it is required that we keep the current way (i.e. setting BUS_WIDTH after HS_TIMING). Any inputs on this Regards Saugata On 5 December 2011 16:59, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: Girish K S [mailto:girish.shivananja...@linaro.org] Sent: Monday, December 05, 2011 12:20 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 5 December 2011 11:46, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: Girish K S [mailto:girish.shivananja...@linaro.org] Sent: Friday, December 02, 2011 5:08 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 2 December 2011 00:02, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Thursday, December 01, 2011 7:48 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 1 December 2011 16:27, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Thursday, December 01, 2011 3:58 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 1 December 2011 15:33, Subhash Jadavani subha...@codeaurora.org wrote: Hi Girish, -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux- mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Wednesday, November 30, 2011 2:24 PM To: linux-...@vger.kernel.org Cc: patc...@linaro.org; linux-samsung- s...@vger.kernel.org; subha...@codeaurora.org; Girish K S; Chris Ball Subject: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 This patch adds the support of the HS200 bus speed for eMMC 4.5 devices. The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and host modules have been touched to add support for this module. It is necessary to know the card type in the sdhci.c file to add support for eMMC tuning function. So card.h file is included to import the card data structure. cc: Chris Ball c...@laptop.org Signed-off-by: Girish K S girish.shivananja...@linaro.org --- Changes in v5: Reduced the case statements for better code readability. Removed
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
* Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote: * Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 To clarify, are you suggesting we retain this patch, or not? (If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select CACHE_L2X0 here -- unless we have specific kconfigs for the different security variants of omap.) Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
* Dave Martin dave.mar...@linaro.org [111214 09:58]: On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote: * Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 To clarify, are you suggesting we retain this patch, or not? I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree. (If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select CACHE_L2X0 here -- unless we have specific kconfigs for the different security variants of omap.) Well we can detect if it's an HS omap, but we may not know what SMI it uses for enabling and disabling L2.. That can depend on the board version. Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is pretty important from debugging cache issues point of view. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] make s5p64x0_defconfig build error
On Wed, 14 Dec 2011, Russell King - ARM Linux wrote: On Wed, Dec 14, 2011 at 12:32:44PM +, Will Deacon wrote: On Wed, Dec 14, 2011 at 04:57:10AM +, Axel Lin wrote: I got below build error on linux-next 20111213. CC arch/arm/kernel/process.o In file included from arch/arm/mach-s5p64x0/include/mach/system.h:16, from arch/arm/kernel/process.c:64: arch/arm/plat-samsung/include/plat/system-reset.h:19:2: error: #error Fix me up make[1]: *** [arch/arm/kernel/process.o] Error 1 make: *** [arch/arm/kernel] Error 2 The clue is in the commit message: commit d0f7e2beabe6a116152ccc31959b6654b6ef0071 Author: Russell King rmk+ker...@arm.linux.org.uk Date: Tue Dec 6 12:57:02 2011 + ARM: restart: Temporary #error to persuade platform maintainers to take the restart changes seriously Force builds to fail to ensure that platform maintainers take the restart changes seriously, and sort out fixing their code before the next merge window. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Indeed, and note the date, and how long its taken for just one of the platforms to be noticed. It seems to me that no one really cares about whether six of the seven platforms which have the #error build or don't build, so I really think there's a simple solution to this at the next merge window - delete any platform which hasn't _at_ _least_ responded with a proposed patch to this. The platform maintainers have had _enough_ notice of this - by not responding, they're quite simply an obstacle to further consolidation, and we're not going to go through months of waiting for their response time and time again. I've posted the patches to the mailing list, I've copied them asking for help, I've chased them several times, and now they have a #error to deal with. If none of this gets their attention (it seems it doesn't), then frankly their platform is unmaintained, it will be broken at the next merge window, and therefore _should_ be deleted. So... unless things change, we can expect Gemini, almost all Samsung stuff, shmobile, vt8500, and Telechips TCC8k to be at least broken at the next merge window. Let me add to this by pointing to this piece of code in arch/arm/include/asm/pgtable.h: |/* This is a temporary hack until shmobile's DMA area size is sorted out */ |#ifdef CONFIG_ARCH_SHMOBILE |#warning SH-Mobile's consistent DMA size conflicts with VMALLOC_END by 144MB |#undef VMALLOC_END |#define VMALLOC_END 0xF600UL |#endif Again, the reason for this is in the commit message. My hope was that, by the central nature of this header file, the build would be sufficiently overwhelmed with #warning noise that the maintainers would manifest themselves and come forth with the needed fix. After repeated inquiries to the listed maintainers in the MAINTAINERS file, I still didn't receive any feedback at this point, and I still can't find a reason for the current state of things either by looking at the concerned code or the related Git commit logs. So if no one cares about this platform then I propose to delete it for v3.3 as well. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
On 12/14/2011 12:39 PM, Tony Lindgren wrote: * Dave Martin dave.mar...@linaro.org [111214 09:58]: On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote: * Dave Martin dave.mar...@linaro.org [111214 03:08]: If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. There are HS and GP omaps (High Security and General Purpose). GP omaps do have full control of the L2. Also HS omaps most likely provide control over enabling and disabling L2 depending how the secure code is implemented. BTW, the real problem is that because the secure code is implemented in various ways, we don't really have any handling for it in Linux. The SMI instruction numbers don't seem to be standardized at all, and can mean different things on different boards, even different board versions :( Sounds like devicetree is the only safe way to deal with the L2 control options. Regards, Tony This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html --- arch/arm/mach-omap2/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bb1b670..94e568a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -41,11 +41,11 @@ config ARCH_OMAP4 bool TI OMAP4 default y depends on ARCH_OMAP2PLUS + select CACHE_L2X0 select CPU_V7 select ARM_GIC select HAVE_SMP select LOCAL_TIMERS if SMP - select MIGHT_HAVE_CACHE_L2X0 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 -- 1.7.4.1 To clarify, are you suggesting we retain this patch, or not? I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree. This already exists with l2x0_of_init. OMAP just needs to start using it. It will initialize the l2 if present in the DT and skip it if not present. Rob (If we only know what l2x0 support will be needed once the dts is parsed at runtime, there could be an argument for keeping the select CACHE_L2X0 here -- unless we have specific kconfigs for the different security variants of omap.) Well we can detect if it's an HS omap, but we may not know what SMI it uses for enabling and disabling L2.. That can depend on the board version. Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is pretty important from debugging cache issues point of view. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support
* Rob Herring robherri...@gmail.com [111214 12:30]: On 12/14/2011 12:39 PM, Tony Lindgren wrote: I think we should keep L2 configurable for omaps until we have some way of getting the configuration dynamically or from device tree. This already exists with l2x0_of_init. OMAP just needs to start using it. It will initialize the l2 if present in the DT and skip it if not present. That's great, that will allow doing the right thing with setting up how to enable and disable it :) Considering that, this patch should be OK to apply: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] make s5p64x0_defconfig build error
On Thu, Dec 15, 2011 at 01:30:13AM +0200, Denis Kuzmenko wrote: On 12/14/2011 09:12 PM, Russell King - ARM Linux wrote: On Wed, Dec 14, 2011 at 12:32:44PM +, Will Deacon wrote: On Wed, Dec 14, 2011 at 04:57:10AM +, Axel Lin wrote: So... unless things change, we can expect Gemini, almost all Samsung stuff, shmobile, vt8500, and Telechips TCC8k to be at least broken at the next merge window. Mini2440 march (s3c24xx platform) is not broken in v3.2-rc5. Does that mean that s3c24xx is untouched by this issue or this means that I should use linux-next? Most of the completed changes are in linux-next for the restart changes. I have some additional commits (which were posted to the list as the 3rd sub-series), which I'm not planning to submit in their current form - they move things _towards_ sorting out the samsung stuff, but they're all incomplete. These continue to be a part of my 'reset' branch. Basically, the comments in the commit summary line marked with XXX need addressing - and folk need to get out of the habbit of thinking it's an include file, it must go into somewhere called 'include'. Instead, put includes local to a set of files in a directory in that same directory. Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sun Nov 6 16:22:23 2011 + ARM: restart: plat-samsung: remove plat/reset.h and s5p_reset_hook Now that s5p_reset_hook is unused, we can get rid of plat/reset.h and the s5p_reset_hook code in plat/system-reset.h. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sun Nov 6 16:20:11 2011 + ARM: restart: s5pv210: use new restart hook XXX WIP XXX WHY IS THERE NO LOCAL HEADERS IN arch/arm/mach-exynos4 XXX Hook these platforms restart code into the new restart hook rather than using arch_reset(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Author: Russell King rmk+ker...@arm.linux.org.uk Date: Sun Nov 6 13:24:20 2011 + ARM: restart: exynos4: use new restart hook XXX WIP XXX WHY IS THERE NO LOCAL HEADERS IN arch/arm/mach-exynos4 XXX Hook these platforms restart code into the new restart hook rather than using arch_reset(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] make s5p64x0_defconfig build error
Hi Kukjin, Axel and Will, thanks for pointing out. Oops, I couldn't have much time to follow up :( But let me look at that in this weekend and I know, it can be escaped before merge window :) I also found the same build errors by: make s5pc100_defconfig make s5pv210_defconfig make exynos4_defconfig Regards, Axel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Wed, Dec 14, 2011 at 03:01:19PM +, Dave Martin wrote: On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Yes, I think it's more precise. Shawn? Thansk Richard Cheers ---Dave ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 5/5] imx6q: Remove unconditional dependency on l2x0 L2 cache support
On Thu, Dec 15, 2011 at 09:02:20AM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 03:01:19PM +, Dave Martin wrote: On Wed, Dec 14, 2011 at 10:05:04PM +0800, Richard Zhao wrote: On Wed, Dec 14, 2011 at 09:26:24PM +0800, Shawn Guo wrote: Hi Dave, Sorry for that I did not look into previous post to point it out. On Wed, Dec 14, 2011 at 11:39:41AM +, Dave Martin wrote: The i.MX6 Quad SoC will work without the l2x0 L2 cache controller support built into the kernel, so this patch removes the dependency on CACHE_L2X0 and selects MIGHT_HAVE_CACHE_L2X0 instead. This makes the l2x0 support optional, so that it can be turned off when desired for debugging purposes etc. Thanks to Shawn Guo for this suggestion. [1] Signed-off-by: Dave Martin dave.mar...@linaro.org [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html --- arch/arm/mach-imx/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a3d61..1fb93f2 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -609,13 +609,13 @@ comment i.MX6 family: config SOC_IMX6Q bool i.MX6 Quad support select ARM_GIC - select CACHE_L2X0 select CPU_V7 select HAVE_ARM_SCU select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC select HAVE_SMP + select MIGHT_HAVE_CACHE_L2X0 The option SOC_IMX6Q is only available when ARCH_IMX_V6_V7 is selected. Since MIGHT_HAVE_CACHE_L2X0 has been selected by ARCH_IMX_V6_V7 in patch #1, this line seems redundant here. Would it be better keep this one and remove patch #1 one? imx5 doesn't have l2x0. Do you mean to remove MIGHT_HAVE_CACHE_L2X0 from ARCH_IMX_V6_V7, and select it only from SOC_IMX6Q? Yes, I think it's more precise. Shawn? No. * imx5 hardware does have L2, and it's just not set up in the kernel (I do not know why). * Currently, ARCH_IMX_V6_V7 only covers imx3 and imx6, and both are calling l2x0 init function to set L2 up. * When we merge mach-mx5 into mach-imx to have ARCH_IMX_V6_V7 cover imx3, imx5 and imx6, there is no reason for us to not set L2 up for imx5 too. So MIGHT_HAVE_CACHE_L2X0 really should be selected by ARCH_IMX_V6_V7. -- Regards, Shawn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
On 14 December 2011 20:50, Subhash Jadavani subha...@codeaurora.org wrote: Just a thought (not sure if it's explicitly specified in 4.5 spec or not): Do we really need to perform bus test in HS200 mode? because in HS200, we are anyways going to perform the tuning sequence (which achieves what bus test command does). you are right. i have removed it in the modified version. It does only tuning and power class selection Regards, Subhash -Original Message- From: Saugata Das [mailto:saugata@linaro.org] Sent: Tuesday, December 13, 2011 11:03 AM To: Girish K S Cc: Subhash Jadavani; linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-soc@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 13 December 2011 10:13, Girish K S girish.shivananja...@linaro.org wrote: On 12 December 2011 12:20, Girish K S girish.shivananja...@linaro.org wrote: On 5 December 2011 20:29, Saugata Das saugata@linaro.org wrote: Hi Girish Please refer to Figure 71 (HS200 device output timing) of the MMC- 4.5 spec. It shows that both CMD and DATA[7-0] will have some latency till valid window. This implies that even the CMD line will need tuning for reading the response. The specification talks about identifying sampling point for data lines by reading tuning blocks. Based on host controller capability, even the CMD line will get the good sample point during the same tuning sequence. We need to have the tuning done (execute_tuning) soon after switching to HS200 mode and 200MHz clock. If i make a change as per subhash suggestionset bus width before setting the HS200 mode. then it will affect the entire frame work of mmc which is developed as per Annexure A6.1 A.6.2 A.6.3 (mentions the steps for bus initialization). can any of you suggest a way to do this. Note that, we need to make this modification only for HS200 mode. For DDR mode, it is required that we keep the current way (i.e. setting BUS_WIDTH after HS_TIMING). Any inputs on this Regards Saugata On 5 December 2011 16:59, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: Girish K S [mailto:girish.shivananja...@linaro.org] Sent: Monday, December 05, 2011 12:20 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 5 December 2011 11:46, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: Girish K S [mailto:girish.shivananja...@linaro.org] Sent: Friday, December 02, 2011 5:08 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 2 December 2011 00:02, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Thursday, December 01, 2011 7:48 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 1 December 2011 16:27, Subhash Jadavani subha...@codeaurora.org wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Thursday, December 01, 2011 3:58 PM To: Subhash Jadavani Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux- samsung- s...@vger.kernel.org; Chris Ball Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 On 1 December 2011 15:33, Subhash Jadavani subha...@codeaurora.org wrote: Hi Girish, -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux- mmc- ow...@vger.kernel.org] On Behalf Of Girish K S Sent: Wednesday, November 30, 2011 2:24 PM To: linux-...@vger.kernel.org Cc: patc...@linaro.org; linux-samsung- s...@vger.kernel.org; subha...@codeaurora.org; Girish K S; Chris Ball Subject: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5 This patch adds the support of the HS200 bus speed for eMMC 4.5 devices. The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and host modules have been touched to add support for this module. It is necessary to know the card type in the sdhci.c file to add support for eMMC tuning function. So card.h file is included to import the card data structure. cc: Chris Ball c...@laptop.org
[PATCH V2] mmc: core: Add host capability check for power class
This patch adds a check whether the host supports maximum current value
obtained from the device's extended csd register for a selected interface
voltage and frequency.
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v2:
deleted a unnecessary if else condition identified by subhash J
Changes in v1:
reduced the number of comparisons as per Hein's suggestion
drivers/mmc/core/mmc.c | 19 +++
include/linux/mmc/card.h |4
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 006e932..b9ef777 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -688,6 +688,25 @@ static int mmc_select_powerclass(struct mmc_card *card,
pwrclass_val = (pwrclass_val EXT_CSD_PWR_CL_4BIT_MASK)
EXT_CSD_PWR_CL_4BIT_SHIFT;
+ if (pwrclass_val = MMC_MAX_CURRENT_800)
+ pwrclass_val = MMC_MAX_CURRENT_800;
+ else if (pwrclass_val = MMC_MAX_CURRENT_600)
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ else if (pwrclass_val = MMC_MAX_CURRENT_400)
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ else
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
+ if ((pwrclass_val == MMC_MAX_CURRENT_800)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_800))
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ if ((pwrclass_val == MMC_MAX_CURRENT_600)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_600))
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ if ((pwrclass_val == MMC_MAX_CURRENT_400)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_400))
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
/* If the power class is different from the default value */
if (pwrclass_val 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 9478a6b..c5e031a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -195,6 +195,10 @@ struct mmc_part {
#define MMC_BLK_DATA_AREA_GP (12)
};
+#define MMC_MAX_CURRENT_200(0)
+#define MMC_MAX_CURRENT_400(7)
+#define MMC_MAX_CURRENT_600(11)
+#define MMC_MAX_CURRENT_800(13)
/*
* MMC device
*/
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-next] make s5p64x0_defconfig build error
On Wed, Dec 14, 2011 at 07:12:05PM +, Russell King - ARM Linux wrote: On Wed, Dec 14, 2011 at 12:32:44PM +, Will Deacon wrote: ARM: restart: Temporary #error to persuade platform maintainers to take the restart changes seriously Force builds to fail to ensure that platform maintainers take the restart changes seriously, and sort out fixing their code before the next merge window. Indeed, and note the date, and how long its taken for just one of the platforms to be noticed. I noticed s3c64xx the day you added that change but just deleted the code so I could carry on working after my initial attempts to figure out what this was about took too long. It seems to me that no one really cares about whether six of the seven platforms which have the #error build or don't build, so I really think there's a simple solution to this at the next merge window - delete any platform which hasn't _at_ _least_ responded with a proposed patch to this. Do you have any references to this stuff? I did make some effort to understand what needed to be done but the patch doesn't mention which restart changes are needed and my grovelling around in git wasn't turning up enough context to tell me what was supposed to be happening instead. Frankly I've no need for that code in my systems so if it's a problem I'd just throw the restart code away if it was that or breakage. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: EXYNOS: Configure ARM_NR_BANKS for EXYNOS4
This patch increases the number of bank for EXYNOS4 to support bigger than 2GB memory on it. Signed-off-by: Boojin Kim boojin@samsung.com --- arch/arm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 928cbcc..5c90dee 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1127,7 +1127,7 @@ source arch/arm/mm/Kconfig config ARM_NR_BANKS int - default 16 if ARCH_EP93XX + default 16 if ARCH_EP93XX || ARCH_EXYNOS4 default 8 config IWMMXT -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DMA: PL330: Support MEMTOMEM transmit without barrier operation.
PL330 r1p0 version fixed the lockup error being on r0p0.
This patch supports the DMA transmit without barrier operation
if the revision is the next of r0p0.
Signed-off-by: Boojin Kim boojin@samsung.com
---
arch/arm/include/asm/hardware/pl330.h |5 +
drivers/dma/pl330.c | 26 +-
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/hardware/pl330.h
b/arch/arm/include/asm/hardware/pl330.h
index ed38e32..1f4d7cb 100644
--- a/arch/arm/include/asm/hardware/pl330.h
+++ b/arch/arm/include/asm/hardware/pl330.h
@@ -144,6 +144,11 @@ enum pl330_reqtype {
#define CRD0xe14
#define PERIPH_ID 0xfe0
+#define PERIPH_REV_SHIFT 20
+#define PERIPH_REV_MASK0xf
+#define PERIPH_REV_R0P00
+#define PERIPH_REV_R1P01
+#define PERIPH_REV_R1P12
#define PCELL_ID 0xff0
#define CR0_PERIPH_REQ_SET (1 0)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 3214ced..d87d884 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -129,6 +129,7 @@ struct pl330_reqcfg {
enum pl330_dstcachectrl dcctl;
enum pl330_srccachectrl scctl;
enum pl330_byteswap swap;
+ struct pl330_config *pcfg;
};
/*
@@ -438,6 +439,11 @@ static inline u32 get_id(struct pl330_info *pi, u32 off)
return id;
}
+static inline u32 get_revision(u32 periph_id)
+{
+ return (periph_idPERIPH_REV_SHIFT)PERIPH_REV_MASK;
+}
+
static inline u32 _emit_ADDH(unsigned dry_run, u8 buf[],
enum pl330_dst da, u16 val)
{
@@ -1026,12 +1032,21 @@ static inline int _ldst_memtomem(unsigned dry_run, u8
buf[],
const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
+ struct pl330_config *pcfg = pxs-r-cfg-pcfg;
- while (cyc--) {
- off += _emit_LD(dry_run, buf[off], ALWAYS);
- off += _emit_RMB(dry_run, buf[off]);
- off += _emit_ST(dry_run, buf[off], ALWAYS);
- off += _emit_WMB(dry_run, buf[off]);
+ /* check lock-up free version */
+ if (get_revision(pcfg-periph_id) = PERIPH_REV_R1P0) {
+ while (cyc--) {
+ off += _emit_LD(dry_run, buf[off], ALWAYS);
+ off += _emit_ST(dry_run, buf[off], ALWAYS);
+ }
+ } else {
+ while (cyc--) {
+ off += _emit_LD(dry_run, buf[off], ALWAYS);
+ off += _emit_RMB(dry_run, buf[off]);
+ off += _emit_ST(dry_run, buf[off], ALWAYS);
+ off += _emit_WMB(dry_run, buf[off]);
+ }
}
return off;
@@ -2398,6 +2413,7 @@ static struct dma_pl330_desc *pl330_get_desc(struct
dma_pl330_chan *pch)
async_tx_ack(desc-txd);
desc-req.peri = peri_id ? pch-chan.chan_id : 0;
+ desc-rqcfg.pcfg = pch-dmac-pif.pcfg;
dma_async_tx_descriptor_init(desc-txd, pch-chan);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iommu: Initialize domain-handler in iommu_domain_alloc()
Since it is not guaranteed that an iommu driver initializes in its domain_init() function, it must be initialized with NULL to prevent calling a function in an arbitrary location when iommu fault occurred. Signed-off-by: KyongHo Cho pullip@samsung.com --- drivers/iommu/iommu.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 7cc3c65..1afb896 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -148,6 +148,7 @@ struct iommu_domain *iommu_domain_alloc(struct bus_type *bus) return NULL; domain-ops = bus-iommu_ops; + domain-handler = NULL; ret = domain-ops-domain_init(domain); if (ret) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] mmc: core: Add host capability check for power class
On 15 December 2011 11:33, amit kachhap amit.kach...@linaro.org wrote:
On Thu, Dec 15, 2011 at 9:28 AM, Girish K S
girish.shivananja...@linaro.org wrote:
This patch adds a check whether the host supports maximum current value
obtained from the device's extended csd register for a selected interface
voltage and frequency.
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v2:
deleted a unnecessary if else condition identified by subhash J
Changes in v1:
reduced the number of comparisons as per Hein's suggestion
drivers/mmc/core/mmc.c | 19 +++
include/linux/mmc/card.h | 4
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 006e932..b9ef777 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -688,6 +688,25 @@ static int mmc_select_powerclass(struct mmc_card *card,
pwrclass_val = (pwrclass_val EXT_CSD_PWR_CL_4BIT_MASK)
EXT_CSD_PWR_CL_4BIT_SHIFT;
+ if (pwrclass_val = MMC_MAX_CURRENT_800)
Hi girish,
These checks can be made like ,
if (pwrclass_val MMC_MAX_CURRENT_800)
pwrclass_val = MMC_MAX_CURRENT_800;
Applicable in all below conditional checks.
I feel that should be OK. Since there will be no significant
improvement or side effects with the current implementation.
Thanks,
Amit D
+ pwrclass_val = MMC_MAX_CURRENT_800;
+ else if (pwrclass_val = MMC_MAX_CURRENT_600)
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ else if (pwrclass_val = MMC_MAX_CURRENT_400)
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ else
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
+ if ((pwrclass_val == MMC_MAX_CURRENT_800)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_800))
+ pwrclass_val = MMC_MAX_CURRENT_600;
+ if ((pwrclass_val == MMC_MAX_CURRENT_600)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_600))
+ pwrclass_val = MMC_MAX_CURRENT_400;
+ if ((pwrclass_val == MMC_MAX_CURRENT_400)
+ !(card-host-caps MMC_CAP_MAX_CURRENT_400))
+ pwrclass_val = MMC_MAX_CURRENT_200;
+
/* If the power class is different from the default value */
if (pwrclass_val 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 9478a6b..c5e031a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -195,6 +195,10 @@ struct mmc_part {
#define MMC_BLK_DATA_AREA_GP (12)
};
+#define MMC_MAX_CURRENT_200 (0)
+#define MMC_MAX_CURRENT_400 (7)
+#define MMC_MAX_CURRENT_600 (11)
+#define MMC_MAX_CURRENT_800 (13)
/*
* MMC device
*/
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
