* [PATCH v2 0/2] Move sdhci-s3c platform helper into driver
From: Thomas Abraham @ 2011-09-14 7:09 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v1:
- Rebased with 'for-next' branch of
http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
(tested with commit id a08b7e19811181309da2306338027fe1d3f8001d at the
tip of the for-next branch, not sure if there have been further
commits after that).
The platform helper that sets up the default sdhci-s3c controller
configuration can be removed and moved into the sdhci-s3c driver.
This platform helper is removed for s3c2416, s3c64xx, s5pc100,
s5pv210 and Exynos4 platforms.
Since the platform helper function pointer was being passed in the
platform data of sdhci-s3c driver, the removal of this pointer from
the platform data is step closer to complete device tree support for
sdhci-s3c driver.
This patchset has been tested on the following platforms.
SMDK2416, SMDK6410, SMDKC100, SMDKV210 and SMDKV310.
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci-s3c: add default controller configuration
From: Thomas Abraham @ 2011-09-14 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315984158-29651-1-git-send-email-thomas.abraham@linaro.org>
The default controller configuration which was previously setup by
platform helper functions is moved into the driver.
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
drivers/mmc/host/sdhci-s3c.c | 28 +++++++++++++++++-----------
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 2bd7bf4..d891682 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -203,17 +203,23 @@ static void sdhci_s3c_set_clock(struct sdhci_host *host, unsigned int clock)
writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL2);
}
- /* reconfigure the hardware for new clock rate */
-
- {
- struct mmc_ios ios;
-
- ios.clock = clock;
-
- if (ourhost->pdata->cfg_card)
- (ourhost->pdata->cfg_card)(ourhost->pdev, host->ioaddr,
- &ios, NULL);
- }
+ /* reprogram default hardware configuration */
+ writel(S3C64XX_SDHCI_CONTROL4_DRIVE_9mA,
+ host->ioaddr + S3C64XX_SDHCI_CONTROL4);
+
+ ctrl = readl(host->ioaddr + S3C_SDHCI_CONTROL2);
+ ctrl |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
+ S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
+ S3C_SDHCI_CTRL2_ENFBCLKRX |
+ S3C_SDHCI_CTRL2_DFCNT_NONE |
+ S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
+ writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL2);
+
+ /* reconfigure the controller for new clock rate */
+ ctrl = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
+ if (clock < 25 * 1000000)
+ ctrl |= (S3C_SDHCI_CTRL3_FCSEL3 | S3C_SDHCI_CTRL3_FCSEL2);
+ writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL3);
}
/**
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v2 2/2] arm: samsung: remove sdhci default configuration setup platform helper
From: Thomas Abraham @ 2011-09-14 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315984158-29651-2-git-send-email-thomas.abraham@linaro.org>
The sdhci platform helper function that sets up the default controller
configuration is removed for all Samsung platforms since such default
controller configuration can be handled by the driver.
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/setup-sdhci.c | 47 -----------------------
arch/arm/mach-s3c2416/setup-sdhci.c | 37 ------------------
arch/arm/mach-s3c64xx/setup-sdhci.c | 48 -----------------------
arch/arm/mach-s5pc100/setup-sdhci.c | 42 --------------------
arch/arm/mach-s5pv210/setup-sdhci.c | 41 --------------------
arch/arm/plat-samsung/include/plat/sdhci.h | 57 ----------------------------
arch/arm/plat-samsung/platformdata.c | 2 -
7 files changed, 0 insertions(+), 274 deletions(-)
diff --git a/arch/arm/mach-exynos4/setup-sdhci.c b/arch/arm/mach-exynos4/setup-sdhci.c
index 1e83f8c..92937b4 100644
--- a/arch/arm/mach-exynos4/setup-sdhci.c
+++ b/arch/arm/mach-exynos4/setup-sdhci.c
@@ -10,16 +10,7 @@
* published by the Free Software Foundation.
*/
-#include <linux/kernel.h>
#include <linux/types.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-
-#include <linux/mmc/card.h>
-#include <linux/mmc/host.h>
-
-#include <plat/regs-sdhci.h>
/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
@@ -29,41 +20,3 @@ char *exynos4_hsmmc_clksrcs[4] = {
[2] = "sclk_mmc", /* mmc_bus */
[3] = NULL,
};
-
-void exynos4_setup_sdhci_cfg_card(struct platform_device *dev, void __iomem *r,
- struct mmc_ios *ios, struct mmc_card *card)
-{
- u32 ctrl2, ctrl3;
-
- /* don't need to alter anything according to card-type */
-
- ctrl2 = readl(r + S3C_SDHCI_CONTROL2);
-
- /* select base clock source to HCLK */
-
- ctrl2 &= S3C_SDHCI_CTRL2_SELBASECLK_MASK;
-
- /*
- * clear async mode, enable conflict mask, rx feedback ctrl, SD
- * clk hold and no use debounce count
- */
-
- ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
- /* Tx and Rx feedback clock delay control */
-
- if (ios->clock < 25 * 1000000)
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
- S3C_SDHCI_CTRL3_FCSEL2 |
- S3C_SDHCI_CTRL3_FCSEL1 |
- S3C_SDHCI_CTRL3_FCSEL0);
- else
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
- writel(ctrl2, r + S3C_SDHCI_CONTROL2);
- writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/mach-s3c2416/setup-sdhci.c b/arch/arm/mach-s3c2416/setup-sdhci.c
index ed34fad..cee5395 100644
--- a/arch/arm/mach-s3c2416/setup-sdhci.c
+++ b/arch/arm/mach-s3c2416/setup-sdhci.c
@@ -12,17 +12,7 @@
* published by the Free Software Foundation.
*/
-#include <linux/kernel.h>
#include <linux/types.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-
-#include <linux/mmc/card.h>
-#include <linux/mmc/host.h>
-
-#include <plat/regs-sdhci.h>
-#include <plat/sdhci.h>
/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
@@ -32,30 +22,3 @@ char *s3c2416_hsmmc_clksrcs[4] = {
[2] = "hsmmc-if",
/* [3] = "48m", - note not successfully used yet */
};
-
-void s3c2416_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
- u32 ctrl2, ctrl3;
-
- ctrl2 = __raw_readl(r + S3C_SDHCI_CONTROL2);
- ctrl2 &= S3C_SDHCI_CTRL2_SELBASECLK_MASK;
- ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
- if (ios->clock < 25 * 1000000)
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
- S3C_SDHCI_CTRL3_FCSEL2 |
- S3C_SDHCI_CTRL3_FCSEL1 |
- S3C_SDHCI_CTRL3_FCSEL0);
- else
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
- __raw_writel(ctrl2, r + S3C_SDHCI_CONTROL2);
- __raw_writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c b/arch/arm/mach-s3c64xx/setup-sdhci.c
index f344a22..c75a71b 100644
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ b/arch/arm/mach-s3c64xx/setup-sdhci.c
@@ -12,17 +12,7 @@
* published by the Free Software Foundation.
*/
-#include <linux/kernel.h>
#include <linux/types.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-
-#include <linux/mmc/card.h>
-#include <linux/mmc/host.h>
-
-#include <plat/regs-sdhci.h>
-#include <plat/sdhci.h>
/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
@@ -32,41 +22,3 @@ char *s3c64xx_hsmmc_clksrcs[4] = {
[2] = "mmc_bus",
/* [3] = "48m", - note not successfully used yet */
};
-
-void s3c6400_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
- u32 ctrl2, ctrl3;
-
- ctrl2 = readl(r + S3C_SDHCI_CONTROL2);
- ctrl2 &= S3C_SDHCI_CTRL2_SELBASECLK_MASK;
- ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
- if (ios->clock < 25 * 1000000)
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
- S3C_SDHCI_CTRL3_FCSEL2 |
- S3C_SDHCI_CTRL3_FCSEL1 |
- S3C_SDHCI_CTRL3_FCSEL0);
- else
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
- pr_debug("%s: CTRL 2=%08x, 3=%08x\n", __func__, ctrl2, ctrl3);
- writel(ctrl2, r + S3C_SDHCI_CONTROL2);
- writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
-
-void s3c6410_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
- writel(S3C64XX_SDHCI_CONTROL4_DRIVE_9mA, r + S3C64XX_SDHCI_CONTROL4);
-
- s3c6400_setup_sdhci_cfg_card(dev, r, ios, card);
-}
diff --git a/arch/arm/mach-s5pc100/setup-sdhci.c b/arch/arm/mach-s5pc100/setup-sdhci.c
index be25879..6418c6e 100644
--- a/arch/arm/mach-s5pc100/setup-sdhci.c
+++ b/arch/arm/mach-s5pc100/setup-sdhci.c
@@ -11,17 +11,7 @@
* published by the Free Software Foundation.
*/
-#include <linux/kernel.h>
#include <linux/types.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-
-#include <linux/mmc/card.h>
-#include <linux/mmc/host.h>
-
-#include <plat/regs-sdhci.h>
-#include <plat/sdhci.h>
/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
@@ -31,35 +21,3 @@ char *s5pc100_hsmmc_clksrcs[4] = {
[2] = "sclk_mmc", /* mmc_bus */
/* [3] = "48m", - note not successfully used yet */
};
-
-
-void s5pc100_setup_sdhci0_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
- u32 ctrl2, ctrl3;
-
- /* don't need to alter anything according to card-type */
-
- writel(S3C64XX_SDHCI_CONTROL4_DRIVE_9mA, r + S3C64XX_SDHCI_CONTROL4);
-
- ctrl2 = readl(r + S3C_SDHCI_CONTROL2);
- ctrl2 &= S3C_SDHCI_CTRL2_SELBASECLK_MASK;
- ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
- if (ios->clock < 25 * 1000000)
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
- S3C_SDHCI_CTRL3_FCSEL2 |
- S3C_SDHCI_CTRL3_FCSEL1 |
- S3C_SDHCI_CTRL3_FCSEL0);
- else
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
- writel(ctrl2, r + S3C_SDHCI_CONTROL2);
- writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/mach-s5pv210/setup-sdhci.c b/arch/arm/mach-s5pv210/setup-sdhci.c
index a83b6c9..6b8ccc4 100644
--- a/arch/arm/mach-s5pv210/setup-sdhci.c
+++ b/arch/arm/mach-s5pv210/setup-sdhci.c
@@ -10,17 +10,7 @@
* published by the Free Software Foundation.
*/
-#include <linux/kernel.h>
#include <linux/types.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-
-#include <linux/mmc/card.h>
-#include <linux/mmc/host.h>
-
-#include <plat/regs-sdhci.h>
-#include <plat/sdhci.h>
/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
@@ -30,34 +20,3 @@ char *s5pv210_hsmmc_clksrcs[4] = {
[2] = "sclk_mmc", /* mmc_bus */
/* [3] = NULL, - reserved */
};
-
-void s5pv210_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
- u32 ctrl2, ctrl3;
-
- /* don't need to alter anything according to card-type */
-
- writel(S3C64XX_SDHCI_CONTROL4_DRIVE_9mA, r + S3C64XX_SDHCI_CONTROL4);
-
- ctrl2 = readl(r + S3C_SDHCI_CONTROL2);
- ctrl2 &= S3C_SDHCI_CTRL2_SELBASECLK_MASK;
- ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
- if (ios->clock < 25 * 1000000)
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
- S3C_SDHCI_CTRL3_FCSEL2 |
- S3C_SDHCI_CTRL3_FCSEL1 |
- S3C_SDHCI_CTRL3_FCSEL0);
- else
- ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
- writel(ctrl2, r + S3C_SDHCI_CONTROL2);
- writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-samsung/include/plat/sdhci.h
index 4a65520..e7b3c75 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -55,10 +55,6 @@ enum clk_types {
* cd_type == S3C_SDHCI_CD_GPIO
* @ext_cd_gpio_invert: invert values for external CD gpio line
* @cfg_gpio: Configure the GPIO for a specific card bit-width
- * @cfg_card: Configure the interface for a specific card and speed. This
- * is necessary the controllers and/or GPIO blocks require the
- * changing of driver-strength and other controls dependent on
- * the card and speed of operation.
*
* Initialisation data specific to either the machine or the platform
* for the device driver to use or call-back when configuring gpio or
@@ -80,10 +76,6 @@ struct s3c_sdhci_platdata {
int state));
void (*cfg_gpio)(struct platform_device *dev, int width);
- void (*cfg_card)(struct platform_device *dev,
- void __iomem *regbase,
- struct mmc_ios *ios,
- struct mmc_card *card);
};
/* s3c_sdhci_set_platdata() - common helper for setting SDHCI platform data
@@ -139,17 +131,11 @@ extern void exynos4_setup_sdhci3_cfg_gpio(struct platform_device *, int w);
#ifdef CONFIG_S3C2416_SETUP_SDHCI
extern char *s3c2416_hsmmc_clksrcs[4];
-extern void s3c2416_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void s3c2416_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s3c2416_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c2416_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = s3c2416_setup_sdhci_cfg_card;
#endif /* CONFIG_S3C_DEV_HSMMC */
}
@@ -158,7 +144,6 @@ static inline void s3c2416_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s3c2416_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c2416_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = s3c2416_setup_sdhci_cfg_card;
#endif /* CONFIG_S3C_DEV_HSMMC1 */
}
@@ -172,17 +157,11 @@ static inline void s3c2416_default_sdhci1(void) { }
#ifdef CONFIG_S3C64XX_SETUP_SDHCI
extern char *s3c64xx_hsmmc_clksrcs[4];
-extern void s3c6400_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void s3c6400_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
#endif
}
@@ -191,7 +170,6 @@ static inline void s3c6400_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
#endif
}
@@ -200,21 +178,14 @@ static inline void s3c6400_default_sdhci2(void)
#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
- s3c_hsmmc2_def_platdata.cfg_card = s3c6400_setup_sdhci_cfg_card;
#endif
}
-extern void s3c6410_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void s3c6410_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
#endif
}
@@ -223,7 +194,6 @@ static inline void s3c6410_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
#endif
}
@@ -232,7 +202,6 @@ static inline void s3c6410_default_sdhci2(void)
#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
- s3c_hsmmc2_def_platdata.cfg_card = s3c6410_setup_sdhci_cfg_card;
#endif
}
@@ -251,17 +220,11 @@ static inline void s3c6400_default_sdhci2(void) { }
#ifdef CONFIG_S5PC100_SETUP_SDHCI
extern char *s5pc100_hsmmc_clksrcs[4];
-extern void s5pc100_setup_sdhci0_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void s5pc100_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s5pc100_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = s5pc100_setup_sdhci0_cfg_card;
#endif
}
@@ -270,7 +233,6 @@ static inline void s5pc100_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s5pc100_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = s5pc100_setup_sdhci0_cfg_card;
#endif
}
@@ -279,7 +241,6 @@ static inline void s5pc100_default_sdhci2(void)
#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s5pc100_setup_sdhci2_cfg_gpio;
- s3c_hsmmc2_def_platdata.cfg_card = s5pc100_setup_sdhci0_cfg_card;
#endif
}
@@ -295,17 +256,11 @@ static inline void s5pc100_default_sdhci2(void) { }
#ifdef CONFIG_S5PV210_SETUP_SDHCI
extern char *s5pv210_hsmmc_clksrcs[4];
-extern void s5pv210_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void s5pv210_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s5pv210_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = s5pv210_setup_sdhci_cfg_card;
#endif
}
@@ -314,7 +269,6 @@ static inline void s5pv210_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s5pv210_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = s5pv210_setup_sdhci_cfg_card;
#endif
}
@@ -323,7 +277,6 @@ static inline void s5pv210_default_sdhci2(void)
#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s5pv210_setup_sdhci2_cfg_gpio;
- s3c_hsmmc2_def_platdata.cfg_card = s5pv210_setup_sdhci_cfg_card;
#endif
}
@@ -332,7 +285,6 @@ static inline void s5pv210_default_sdhci3(void)
#ifdef CONFIG_S3C_DEV_HSMMC3
s3c_hsmmc3_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc3_def_platdata.cfg_gpio = s5pv210_setup_sdhci3_cfg_gpio;
- s3c_hsmmc3_def_platdata.cfg_card = s5pv210_setup_sdhci_cfg_card;
#endif
}
@@ -348,17 +300,11 @@ static inline void s5pv210_default_sdhci3(void) { }
#ifdef CONFIG_EXYNOS4_SETUP_SDHCI
extern char *exynos4_hsmmc_clksrcs[4];
-extern void exynos4_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card);
-
static inline void exynos4_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
s3c_hsmmc0_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = exynos4_setup_sdhci0_cfg_gpio;
- s3c_hsmmc0_def_platdata.cfg_card = exynos4_setup_sdhci_cfg_card;
#endif
}
@@ -367,7 +313,6 @@ static inline void exynos4_default_sdhci1(void)
#ifdef CONFIG_S3C_DEV_HSMMC1
s3c_hsmmc1_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = exynos4_setup_sdhci1_cfg_gpio;
- s3c_hsmmc1_def_platdata.cfg_card = exynos4_setup_sdhci_cfg_card;
#endif
}
@@ -376,7 +321,6 @@ static inline void exynos4_default_sdhci2(void)
#ifdef CONFIG_S3C_DEV_HSMMC2
s3c_hsmmc2_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = exynos4_setup_sdhci2_cfg_gpio;
- s3c_hsmmc2_def_platdata.cfg_card = exynos4_setup_sdhci_cfg_card;
#endif
}
@@ -385,7 +329,6 @@ static inline void exynos4_default_sdhci3(void)
#ifdef CONFIG_S3C_DEV_HSMMC3
s3c_hsmmc3_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc3_def_platdata.cfg_gpio = exynos4_setup_sdhci3_cfg_gpio;
- s3c_hsmmc3_def_platdata.cfg_card = exynos4_setup_sdhci_cfg_card;
#endif
}
diff --git a/arch/arm/plat-samsung/platformdata.c b/arch/arm/plat-samsung/platformdata.c
index 6de1a38..4c9a207 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -50,8 +50,6 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata *pd,
set->max_width = pd->max_width;
if (pd->cfg_gpio)
set->cfg_gpio = pd->cfg_gpio;
- if (pd->cfg_card)
- set->cfg_card = pd->cfg_card;
if (pd->host_caps)
set->host_caps |= pd->host_caps;
if (pd->clk_type)
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
From: Jassi Brar @ 2011-09-14 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4x0isAUgmTkRavUC6p3K38ho70A+q8Pp2cMLnxbgMEL7Q@mail.gmail.com>
On Wed, Sep 14, 2011 at 12:16 PM, Barry Song <21cnbao@gmail.com> wrote:
>> Anyways, every case can be easily expressed using the generic api
>> I proposed. See 'struct xfer_template' in https://lkml.org/lkml/2011/8/12/128
>>
>> Roughly speaking, the following should be done...
>> Client driver :-
>> **************
>> For a 'Rectangular' transfer (2d-dma.PNG) :-
>> ? ? ?xfer_template.numf = Ylen; ?/* height of rectangle */
>> ? ? ?xfer_template.frame_size = 1;
>> ? ? ?xfer_template.sgl[0].size = Xlen; /* width of rectangle */
>> ? ? ?xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
>
> For prima2:
>
> xfer_template.numf = ylen + 1
> xfer_template.frame_size = 1;
> xfer_template.sgl[0].size = xlen;
> xfer_template.sgl[0].icg = dma_width - xlen;
>
All is same as I suggested except for 'numf'.
You might want to keep 'numf' same as well. Because the client
driver shouldn't need to know that the DMAC's register expect "+1" value.
Remember the client is supposed to be reusable over other DMACs as well.
So, rather in the DMAC driver, please do
schan->ylen = xfer_template.numf + 1;
>> DMAC driver :-
>> ***************
>> ? ? ?if (xfer_template.frame_size == 1) {
>> ? ? ? ? ? /* rectangle */
>> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size;
>> ? ? ? ? ? schan->width = schan->xlen + xfer_template.sgl[0].icg;
>> ? ? ?} else if (xfer_template.frame_size == 2 &&
>> ? ? ? ? ? ? ? ? ?xfer_template.numf == 1 &&
>> ? ? ? ? ? ? ? ? ?xfer_template.sgl[1].size == xfer_template.sgl[0].icg){
>> ? ? ? ? ? /* a line and some */
>> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size + ?xfer_template.sgl[1].size.
>> ? ? ? ? ? schan->width = xfer_template.sgl[0].size;
>> ? ? ?} else {
>> ? ? ? ? ? /* _Hardware_ doesn't support the transfer as such. *
>> ? ? ? ? ? return -EINVAL;
>> ? ? ?}
>> ? ? ?schan->ylen = xfer_template.numf /* -1? */;
>>
>
> For prima2:
> xfer_template.frame_size is always 1, then
> schan->xlen = xfer_template.sgl[0].size;
> schan->width = schan->xlen + xfer_template.sgl[0].icg;
>
Ok, you don't need the 'else if' clause because as you said
{xlen > width} is not an option.
But you do need the other two checks, so that the DMAC driver
cleanly rejects any interleaved-format that it doesn't support.
Point being, the clients and DMAC drivers are supposed to be
very 'promiscuous' - any Client could be 'riding' any DMAC ;)
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Siarhei Siamashka @ 2011-09-14 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2VFSwL7hCmGpHXx_UKKwK3dbhNRGQB1bwvcD-YC1Qj-AQ@mail.gmail.com>
On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> Hi Siarhei,
>
> Interesting feature, and it's not samsung soc issue, so add the arm
> mailing list.
> It checked and the see the read performance improvement from 868MiB/s
> to 981MiB/s with lmbench.
Maybe lmbench does not try very hard to get the best out of the
hardware? On my origenboard, I'm getting ~1.15GB/s performance for the
standard LDM/STM based memcpy from libc-ports, which is ~2.3GB/s
memory bandwidth if both reads and writes are accounted separately.
> It's helpful to test other SoC., e.g., OMAP4, STE and so on.
The current (?) state of the support for this feature in OMAP4 is
explained here by Richard Woodruff:
http://groups.google.com/group/pandaboard/msg/dfd2d2e1336d435b
> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
> and should be zero (SBZ).
This PL310 thing seems to have been renamed to "CoreLink Level 2 Cache
Controller L2C-310" in later revisions, and its Prefetch Control
Register is described here:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/CHDHIECI.html
Sorry for the confusing subject.
Regarding bit 27 ('Double linefill on WRAP read disable'), it seems to
reduce the impact of enabling double linefill on the random access
latency as measured by my self-written simple memory benchmark
program:
http://github.com/downloads/ssvb/ssvb-membench/ssvb-membench-0.1.tar.gz
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Thomas Hellstrom @ 2011-09-14 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001c01cc72a2$d872c390$89584ab0$%dae@samsung.com>
On 09/14/2011 07:55 AM, Inki Dae wrote:
>
>
>> -----Original Message-----
>> From: Rob Clark [mailto:robdclark at gmail.com]
>> Sent: Wednesday, September 14, 2011 11:26 AM
>> To: Inki Dae
>> Cc: Thomas Hellstrom; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
>> linux-arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae<inki.dae@samsung.com> wrote:
>>
>>> Hi Thomas.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>>>> Sent: Monday, September 12, 2011 3:32 PM
>>>> To: Rob Clark
>>>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
>>>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>>>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>>>
>>>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>>>>
>>>>> On 09/10/2011 07:31 PM, Rob Clark wrote:
>>>>>
>>>>>> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
>>>>>> Hellstrom<thomas@shipmail.org> wrote:
>>>>>>
>>>>>>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>>>>>>>
>>>>>>>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now
>>>>>>>>
>> enables
>>
>>>>>>>> only FIMD yet but we will add HDMI support also in the future.
>>>>>>>>
>>>>>>>> from now on, I will remove RFC prefix because I think we have got
>>>>>>>> comments
>>>>>>>> enough.
>>>>>>>>
>>>>>>>> this patch is based on git repository below:
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>>>>>>>> branch name: drm-next
>>>>>>>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>>>>>>>>
>>>>>>>> you can refer to our working repository below:
>>>>>>>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
>>>>>>>> branch name: samsung-drm
>>>>>>>>
>>>>>>>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>>>>>>>> based on Linux framebuffer) but couldn't so because lowlevel codes
>>>>>>>> of s3c-fb.c are included internally and so FIMD module of this
>>>>>>>> driver has
>>>>>>>> its own lowlevel codes.
>>>>>>>>
>>>>>>>> We used GEM framework for buffer management and DMA
>>>>>>>>
>> APIs(dma_alloc_*)
>>
>>>>>>>> for buffer allocation. by using DMA API, we could use CMA later.
>>>>>>>>
>>>>>>>> Refer to this link for CMA(Continuous Memory Allocator):
>>>>>>>> http://lkml.org/lkml/2011/7/20/45
>>>>>>>>
>>>>>>>> this driver supports only physically continuous memory(non-iommu).
>>>>>>>>
>>>>>>>> Links to previous versions of the patchset:
>>>>>>>> v1:< https://lwn.net/Articles/454380/>
>>>>>>>> v2:< http://www.spinics.net/lists/kernel/msg1224275.html>
>>>>>>>> v3:< http://www.gossamer-
>>>>>>>>
>> threads.com/lists/linux/kernel/1423684>
>>
>>>>>>>> Changelog v2:
>>>>>>>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>>>>>>>>
>>>>>>>> this feature maps user address space to physical memory
>>>>>>>>
>> region
>>
>>>>>>>> once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
>>>>>>>>
>> ioctl.
>>
>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>
>>>>>>>> Changelog v3:
>>>>>>>> DRM: Support multiple irq.
>>>>>>>>
>>>>>>>> FIMD and HDMI have their own irq handler but DRM Framework
>>>>>>>>
>> can
>>
>>>>>>>> regiter
>>>>>>>> only one irq handler this patch supports mutiple irq for
>>>>>>>> Samsung SoC.
>>>>>>>>
>>>>>>>> DRM: Consider modularization.
>>>>>>>>
>>>>>>>> each DRM, FIMD could be built as a module.
>>>>>>>>
>>>>>>>> DRM: Have indenpendent crtc object.
>>>>>>>>
>>>>>>>> crtc isn't specific to SoC Platform so this patch gets a crtc
>>>>>>>> to be used as common object.
>>>>>>>> created crtc could be attached to any encoder object.
>>>>>>>>
>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>
>>>>>>>> Changelog v4:
>>>>>>>> DRM: remove is_defult from samsung_fb.
>>>>>>>>
>>>>>>>> is_default isn't used for default framebuffer.
>>>>>>>>
>>>>>>>> DRM: code refactoring to fimd module.
>>>>>>>> this patch is be considered with multiple display objects and
>>>>>>>> would use its own request_irq() to register a irq handler
>>>>>>>> instead of
>>>>>>>> drm framework's one.
>>>>>>>>
>>>>>>>> DRM: remove find_samsung_drm_gem_object()
>>>>>>>>
>>>>>>>> DRM: move kernel private data structures and definitions to driver
>>>>>>>> folder.
>>>>>>>>
>>>>>>>> samsung_drm.h would contain only public information for
>>>>>>>>
>>> userspace
>>>
>>>>>>>> ioctl interface.
>>>>>>>>
>>>>>>>> DRM: code refactoring to gem modules.
>>>>>>>> buffer module isn't dependent of gem module anymore.
>>>>>>>>
>>>>>>>> DRM: fixed security issue.
>>>>>>>>
>>>>>>>> DRM: remove encoder porinter from specific connector.
>>>>>>>>
>>>>>>>> samsung connector doesn't need to have generic encoder.
>>>>>>>>
>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>
>>>>>>>> Signed-off-by: Inki Dae<inki.dae@samsung.com>
>>>>>>>> Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
>>>>>>>> Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
>>>>>>>> Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>>>>>>>> + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>>>>>>>> samsung_drm_gem_create_ioctl,
>>>>>>>> + DRM_UNLOCKED | DRM_AUTH),
>>>>>>>>
>>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> With reference my previous security comment.
>>>>>>>
>>>>>>> Let's say you have a compromised video player running as a DRM
>>>>>>> client, that
>>>>>>> tries to repeatedly allocate huge GEM buffers...
>>>>>>>
>>>>>>> What will happen when all DMA memory is exhausted? Will this cause
>>>>>>> other
>>>>>>> device drivers to see an OOM, or only DRM?
>>>>>>>
>>>>>>> The old DRI model basically allowed any authorized DRI client to
>>>>>>> exhaust
>>>>>>> video ram or AGP memory, but never system memory. Newer DRI drivers
>>>>>>> typically only allow DRI masters to do that.
>>>>>>> as
>>>>>>>
>>>>>>> I don't think an authorized DRI client should be able to easily
>>>>>>>
>>>> exhaust
>>>>
>>>>>>> resources (DMA memory) used by other device drivers causing them to
>>>>>>> fail.
>>>>>>>
>>>>>> I'm not entirely sure what else can be done, other than have a
>>>>>> threshold on max MB allocatable of buffer memory..
>>>>>>
>>>>> Yes, I think that's what needs to be done, and that threshold should
>>>>> be low enough to keep other device drivers running in the worst
>>>>> allocation case.
>>>>>
>>>>>
>>>>>> In the samsung driver case, he is only allocating scanout memory
>>>>>>
>> from
>>
>>>>>> CMA, so the limit will be the CMA region size.. beyond that you
>>>>>>
>> can't
>>
>>>>>> get physically contiguous memory. So I think this driver is safe.
>>>>>>
>>>>> It's not really what well-behaved user-space drivers do that should
>>>>>
>> be
>>
>>>>> a concern, but what compromized application *might* do that is a
>>>>>
>>> concern.
>>>
>>>> Hmm. I might have missed your point here. If the buffer allocation
>>>>
>> ioctl
>>
>>>> only allows allocating CMA memory, then I agree the driver fits the old
>>>> DRI security model, as long as no other devices on the platform will
>>>> ever use CMA.
>>>>
>>>> But in that case, there really should be a way for the driver to say
>>>> "Hey, all CMA memory on this system is mine", in the same way
>>>> traditional video drivers can claim the VRAM PCI resource.
>>>>
>>>>
>>> CMA could reserve memory region for a specific driver so DRM Client
>>>
>> could
>>
>>> request memory allocation from only the region.
>>>
>>>
>>>> This is to avoid the possibility that future drivers that need CMA will
>>>> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>>>>
>>>>
>>> Thomas, if any application has root authority for ill-purpose then isn't
>>>
>> it
>>
>>> possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
>>> authority. I know DRM Framework gives any root application DRM_AUTH
>>> authority for compatibility.
>>>
>> DRM_AUTH just means that the client has authenticated w/ X11 (meaning
>> that it has permission to connect to x server)..
>>
>>
> Yes, I understood so. but see drm_open_helper() of drm_fops.c file please.
> in this function, you can see a line below.
> /* for compatibility root is always authenticated */
> priv->authenticated = capable(CAP_SYS_ADMIN)
>
> I think the code above says that any application with root permission is
> authenticated.
>
>
Yes, that is true. A root client may be assumed to have AUTH
permissions, but the inverse does not hold, meaning that an AUTH client
may *not* be assumed to have root permissions. I think there is a
ROOT_ONLY ioctl flag for that.
The problem I'm seeing compared to other drivers is the following:
Imagine for example that you have a disc driver that allocates temporary
memory out of the same DMA pool as the DRM driver.
Now you have a video player that is a DRM client. It contains a security
flaw and is compromized by somebody trying to play a specially crafted
video stream. The video player starts to allocate gem buffers until it
receives an -ENOMEM. Then it stops allocating and does nothing.
Now the system tries an important disc access (paging for example). This
fails, because the video player has exhausted all DMA memory and the
disc driver fails to allocate.
The system is dead.
The point is:
If there is a chance that other drivers will use the same DMA/CMA pool
as the DRM driver, DRM must leave enough DMA/CMA memory for those
drivers to work.
The difference compared to other drm drivers:
There are other drm drivers that work the same way, with a static
allocator. For example "via" and "sis". But those drivers completely
claim the resources they are using. Nobody else is expected to use VRAM
/ AGP.
In the Samsung case, it's not clear to me whether the DMA/CMA pool *can*
be shared with other devices.
If it is, IMHO you must implement an allocation limit in DRM, if not,
the driver should probably be safe.
Thanks,
Thomas
>
>> But I think that since memory allocation is limited to the size of the
>> CMA region, that this puts a reasonable cap of the memory that can be
>> allocated by the client. If this is a problem, it certainly isn't the
>> worst problem. You could still limit via file permissions the users
>> that can open the DRM device file, so it is really no worse than other
>> devices like v4l2..
>>
>> BR,
>> -R
>>
>>
>>
>>>> /Thomas
>>>>
>>>>
>>>
>>>
>>>
>
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Kyungmin Park @ 2011-09-14 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACY+gR2TX35XaVLiN7s_PkY4r=G1i3LMhHzSJJiaAOSoYDGwfg@mail.gmail.com>
On Wed, Sep 14, 2011 at 4:43 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park <kmpark@infradead.org> wrote:
>> Hi Siarhei,
>>
>> Interesting feature, and it's not samsung soc issue, so add the arm
>> mailing list.
>> It checked and the see the read performance improvement from 868MiB/s
>> to 981MiB/s with lmbench.
>
> Maybe lmbench does not try very hard to get the best out of the
> hardware? On my origenboard, I'm getting ~1.15GB/s performance for the
> standard LDM/STM based memcpy from libc-ports, which is ~2.3GB/s
> memory bandwidth if both reads and writes are accounted separately.
>
>> It's helpful to test other SoC., e.g., OMAP4, STE and so on.
>
> The current (?) state of the support for this feature in OMAP4 is
> explained here by Richard Woodruff:
> ? ?http://groups.google.com/group/pandaboard/msg/dfd2d2e1336d435b
>
>> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
>> and should be zero (SBZ).
>
> This PL310 thing seems to have been renamed to "CoreLink Level 2 Cache
> Controller L2C-310" in later revisions, and its Prefetch Control
> Register is described here:
> ? ?http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/CHDHIECI.html
Thanks for link. it has 27-bit description. but does it correct bit
description for exynos4 PL310?
I mean I received the PL310 TRM with exynos4 chip used. there's no
27-bit description. it's just reserved bit.
Can it enable the 27-bit at exynos4210? or can be used for exynos4212 or later?
Thank you,
Kyungmin Park
>
> Sorry for the confusing subject.
>
> Regarding bit 27 ('Double linefill on WRAP read disable'), it seems to
> reduce the impact of enabling double linefill on the random access
> latency as measured by my self-written simple memory benchmark
> program:
> ? ?http://github.com/downloads/ssvb/ssvb-membench/ssvb-membench-0.1.tar.gz
>
> --
> Best regards,
> Siarhei Siamashka
>
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Siarhei Siamashka @ 2011-09-14 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2Ww9J8h34Nub=gz=xR5767T7X=S+gk58o4HU809mdB52Q@mail.gmail.com>
On Wed, Sep 14, 2011 at 10:57 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> On Wed, Sep 14, 2011 at 4:43 PM, Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
>> On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park <kmpark@infradead.org> wrote:
>>> Hi Siarhei,
>>>
>>> Interesting feature, and it's not samsung soc issue, so add the arm
>>> mailing list.
>>> It checked and the see the read performance improvement from 868MiB/s
>>> to 981MiB/s with lmbench.
>>
>> Maybe lmbench does not try very hard to get the best out of the
>> hardware? On my origenboard, I'm getting ~1.15GB/s performance for the
>> standard LDM/STM based memcpy from libc-ports, which is ~2.3GB/s
>> memory bandwidth if both reads and writes are accounted separately.
>>
>>> It's helpful to test other SoC., e.g., OMAP4, STE and so on.
>>
>> The current (?) state of the support for this feature in OMAP4 is
>> explained here by Richard Woodruff:
>> ? ?http://groups.google.com/group/pandaboard/msg/dfd2d2e1336d435b
>>
>>> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
>>> and should be zero (SBZ).
>>
>> This PL310 thing seems to have been renamed to "CoreLink Level 2 Cache
>> Controller L2C-310" in later revisions, and its Prefetch Control
>> Register is described here:
>> ? ?http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/CHDHIECI.html
> Thanks for link. it has 27-bit description. but does it correct bit
> description for exynos4 PL310?
> I mean I received the PL310 TRM with exynos4 chip used. there's no
> 27-bit description. it's just reserved bit.
> Can it enable the 27-bit at exynos4210? or can be used for exynos4212 or later?
That's a good point. I think it is exynos4210 that is used in
origenboard. And according to the value in Cache ID Register
(0x4100c4c5), it has r3p0 revision of L2C-310. Which means that the
Prefetch Control Register is actually described at:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246d/CHDHIECI.html
And bit 27 is indeed reserved. However flipping it seems to have some
measurable impact on performance (unless I screwed up the benchmarks),
so maybe it does something but is undocumented? In any case, I agree
that it's better not to mess up with this bit.
By the way, does anybody have L2C-310 errata list? Is double linefill
actually safe to use in r3p0?
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Russell King - ARM Linux @ 2011-09-14 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315288107-14689-2-git-send-email-shawn.guo@linaro.org>
On Tue, Sep 06, 2011 at 01:48:26PM +0800, Shawn Guo wrote:
> If ARM core gets powered off during suspend, L2 cache controller
> has to be reinitialized by resume procedure.
>
> The patch removes __init annotation from a few initialization
> functions to make the reinitialization possible. For example,
> platform resume function can call l2x0_of_init() to get L2 cache
> back to work.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> arch/arm/include/asm/hardware/cache-l2x0.h | 2 +-
> arch/arm/mm/cache-l2x0.c | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
> index d22765c..d270310 100644
> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
> @@ -89,7 +89,7 @@
> #define L2X0_ADDR_FILTER_EN 1
>
> #ifndef __ASSEMBLY__
> -extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
> +extern void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
> #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
> extern int l2x0_of_init(__u32 aux_val, __u32 aux_mask);
> #else
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index c035b9a..7835cb6 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -280,7 +280,7 @@ static void l2x0_disable(void)
> spin_unlock_irqrestore(&l2x0_lock, flags);
> }
>
> -void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
> +void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
> {
> __u32 aux;
> __u32 cache_id;
I'm unconvinced about the wise-ness of this. We read-modify-write the
auxillary control register, which means some bits are preserved from
the initial boot. If the boot loader sets the L2 cache up for normal
boot and not for resume, we'll end up with different L2 cache settings.
We've historically seen this kind of thing with boot loaders over the
years, to the point where systems boot at one CPU clock rate but resume
at some other CPU clock rate.
So, it may be wiser to implement a 'save' and 'restore' interface
instead so that we can be sure that things are setup in the same way
after resume.
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Santosh @ 2011-09-14 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914084237.GC6267@n2100.arm.linux.org.uk>
On Wednesday 14 September 2011 02:12 PM, Russell King - ARM Linux wrote:
> On Tue, Sep 06, 2011 at 01:48:26PM +0800, Shawn Guo wrote:
>> If ARM core gets powered off during suspend, L2 cache controller
>> has to be reinitialized by resume procedure.
>>
>> The patch removes __init annotation from a few initialization
>> functions to make the reinitialization possible. For example,
>> platform resume function can call l2x0_of_init() to get L2 cache
>> back to work.
>>
>> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
>> ---
>> arch/arm/include/asm/hardware/cache-l2x0.h | 2 +-
>> arch/arm/mm/cache-l2x0.c | 10 +++++-----
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
>> index d22765c..d270310 100644
>> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
>> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
>> @@ -89,7 +89,7 @@
>> #define L2X0_ADDR_FILTER_EN 1
>>
>> #ifndef __ASSEMBLY__
>> -extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
>> +extern void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
>> #if defined(CONFIG_CACHE_L2X0)&& defined(CONFIG_OF)
>> extern int l2x0_of_init(__u32 aux_val, __u32 aux_mask);
>> #else
>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>> index c035b9a..7835cb6 100644
>> --- a/arch/arm/mm/cache-l2x0.c
>> +++ b/arch/arm/mm/cache-l2x0.c
>> @@ -280,7 +280,7 @@ static void l2x0_disable(void)
>> spin_unlock_irqrestore(&l2x0_lock, flags);
>> }
>>
>> -void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
>> +void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
>> {
>> __u32 aux;
>> __u32 cache_id;
>
> I'm unconvinced about the wise-ness of this. We read-modify-write the
> auxillary control register, which means some bits are preserved from
> the initial boot. If the boot loader sets the L2 cache up for normal
> boot and not for resume, we'll end up with different L2 cache settings.
>
> We've historically seen this kind of thing with boot loaders over the
> years, to the point where systems boot at one CPU clock rate but resume
> at some other CPU clock rate.
>
> So, it may be wiser to implement a 'save' and 'restore' interface
> instead so that we can be sure that things are setup in the same way
> after resume.
>
I agree with Russell and has same concern when I commented on V1 of this
patch.
As mentioned earlier, you need to save only once since non of the L2
configuration values will change. So 'save ones' and 'restore always
when context lost' should be the right way to go about it.
Regards
Santosh
^ permalink raw reply
* [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility
From: Shawn Guo @ 2011-09-14 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315978906-15829-1-git-send-email-nico@fluxnic.net>
On Wed, Sep 14, 2011 at 01:41:40AM -0400, Nicolas Pitre wrote:
> This is the latest incarnation of my patch series allowing a DTB
> to be appended to zImage, including the ATAG conversion wrapper and
> other minor cleanups.
>
> This can also be pulled from:
>
> git://git.linaro.org/people/nico/linux zImage_DTB_append
>
> This works for me on the test setup I have.
> ACKs/Tested-By's would be appreciated.
>
Tested-by: Shawn Guo <shawn.guo@linaro.org> (on imx6q)
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] ARM: tegra: Remove redundant change to the CPSR in headsmp.S
From: Dave Martin @ 2011-09-14 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRSoSYhuqPC+SmCNk4dseok0vs02su0kihKNqXGpCvUvSg@mail.gmail.com>
On Tue, Sep 13, 2011 at 06:46:48PM -0700, Colin Cross wrote:
> On Mon, Sep 12, 2011 at 9:52 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > Colin, can you comment on this?
> >
> > On Wed, Sep 07, 2011 at 05:00:53PM +0100, Dave Martin wrote:
> >> At secondary_startup, the MSR CPSR_cxsf, #0xd3 is not compatible
> >> with Thumb-2 and also unmasks asynchronous aborts (CPSR.A bit
> >> forced to zero -- this is probably unintentional).
> >>
> >> Any remotely sane bootloader should be putting each secondary CPU
> >> in the appropriate state _before_ entering the kernel anyway.
> >> Otherwise, disabling interrupts on entry to the kernel isn't going
> >> to fix it.
> >>
> >> Therefore this patch just removes the MSR instruction.
> >>
> >> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> >> ---
> >>
> >> I make assumptions about the bootloader in this patch. ?If someone with
> >> Tegra knowledge can please comment and/or test, that would be much
> >> appreciated, thanks.
> >>
> >> ?arch/arm/mach-tegra/headsmp.S | ? ?1 -
> >> ?1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
> >> index b5349b2..6ec4790 100644
> >> --- a/arch/arm/mach-tegra/headsmp.S
> >> +++ b/arch/arm/mach-tegra/headsmp.S
> >> @@ -48,7 +48,6 @@ ENTRY(v7_invalidate_l1)
> >> ?ENDPROC(v7_invalidate_l1)
> >>
> >> ?ENTRY(tegra_secondary_startup)
> >> - ? ? msr ? ? cpsr_fsxc, #0xd3
> >> ? ? ? ? ?bl ? ? ?v7_invalidate_l1
> >> ? ? ? mrc ? ? p15, 0, r0, c0, c0, 5
> >> ? ? ? ? ?and ?r0, r0, #15
> >
> > My rationale here is that the CPU boots straight into the
> > correct mode -- if there is any boot code before we get here,
> > then it should already have established the correct mode, otherwise
> > we're likely to get problems which "MSR" by itself isn't going to
> > fix -- such as stray interrupts for example.
> >
> > If that feels unsafe however, we should still to be able to write
> >
> > ? ? ? ?cpsid ? aif, #SVC_MODE
> >
> > (which is the compact v6/v7-compatible way to set all the interrupt
> > mask bits and get into a specific mode)
>
> Tegra boots with one cpu enabled, and the other in reset. The cpu
> needs to be initialized from scratch by the kernel. Does cpsid aif,
> #SVC_MODE compile to the same instruction as the msr instruction?
CPUs power on in SVC mode with all interrupts masked, so it should
be safe to assume that the CPU is already in this state (this is actually
_required_ by Documentation/arm/Booting). If the CPU booted with a
random mode and random interrupt masks, no system could boot reliably...
However, it's harmless to set the state explicitly if we want to be
extra safe.
My assumption is that the unmasking of asynchronous aborts done by
msr CPSR_cxsf, #0xd3 is unintentional -- i.e., this is a copy-paste
of code which would have been correct prior to ARMv6 (when there
was no separate 'A' interrupt class).
cps is a distinct instruction, introduced in ARMv6.
The advantages are that it can be used to control the A bit, and
doesn't clobber the T bit (or other CPSR bits).
Since mach-tegra doesn't apply to any platform older than ARMv6,
use of this instruction seems reasonable.
cpsid aif disables all three kinds of interrupt.
With regard to Thumb-2 kernels, what code is responsible for
performing the jump to tegra_secondary_startup?
If the jump is done by making an exception return from some firmware,
you may find you hit tegra_secondary_starup in ARM state, and
everything will go horribly wrong...
It could be worth making the secondary kernel entry point ARM code
unconditionally (just as is now done for the primary kernel entry
point).
Cheers
---Dave
^ permalink raw reply
* [PATCH 01/11] clk: Add a generic clock infrastructure
From: Mark Brown @ 2011-09-14 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <decbd6943536eae1bddda9765ac5b267.squirrel@www.codeaurora.org>
On Tue, Sep 13, 2011 at 07:22:17PM -0700, Saravana Kannan wrote:
> On Wed, August 24, 2011 6:15 am, Mark Brown wrote:
> > -struct clk;
> > +static inline int clk_prepare(struct clk *clk) { return 0; }
> > +static inline void clk_unprepare(struct clk *clk) { }
> You should add might_sleep() inside these stubs. That way, if any device
> driver developers wants to move over to the new APIs before their arch
> does, they get to see the warnings when they call prepare/unprepare in
> atomic context.
Just to repeat previous clarifications as I said when I reposted I've no
intention of working on this, I'm just republishing Jeremy's work as
Mike needed a copy.
^ permalink raw reply
* [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
From: Barry Song @ 2011-09-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY36xmq3mKpWOn+ZZuvPehRkSGe720WrQtMie2C-udgZyQ@mail.gmail.com>
2011/9/14 Jassi Brar <jassisinghbrar@gmail.com>:
> On Wed, Sep 14, 2011 at 12:16 PM, Barry Song <21cnbao@gmail.com> wrote:
>
>>> Anyways, every case can be easily expressed using the generic api
>>> I proposed. See 'struct xfer_template' in https://lkml.org/lkml/2011/8/12/128
>>>
>>> Roughly speaking, the following should be done...
>>> Client driver :-
>>> **************
>>> For a 'Rectangular' transfer (2d-dma.PNG) :-
>>> ? ? ?xfer_template.numf = Ylen; ?/* height of rectangle */
>>> ? ? ?xfer_template.frame_size = 1;
>>> ? ? ?xfer_template.sgl[0].size = Xlen; /* width of rectangle */
>>> ? ? ?xfer_template.sgl[0].icg = start_addr_Y(n) - end_addr_Y(n-1);
>>
>> For prima2:
>>
>> xfer_template.numf = ylen + 1
>> xfer_template.frame_size = 1;
>> xfer_template.sgl[0].size = xlen;
>> xfer_template.sgl[0].icg = dma_width - xlen;
>>
> All is same as I suggested except for 'numf'.
> You might want to keep 'numf' same as well. Because the client
> driver shouldn't need to know that the DMAC's register expect "+1" value.
> Remember the client is supposed to be reusable over other DMACs as well.
> So, rather in the DMAC driver, please do
> ? ?schan->ylen = xfer_template.numf + 1;
clients should not know any thing like xlen, ylen, dma_width, which
are all dmac driver cares. clients only need to know the generic xfer.
here i am just listing the relationship between client and dmac driver
to get the confirmation from you and make sure i haven't
misunderstood your api :-)
>
>
>>> DMAC driver :-
>>> ***************
>>> ? ? ?if (xfer_template.frame_size == 1) {
>>> ? ? ? ? ? /* rectangle */
>>> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size;
>>> ? ? ? ? ? schan->width = schan->xlen + xfer_template.sgl[0].icg;
>>> ? ? ?} else if (xfer_template.frame_size == 2 &&
>>> ? ? ? ? ? ? ? ? ?xfer_template.numf == 1 &&
>>> ? ? ? ? ? ? ? ? ?xfer_template.sgl[1].size == xfer_template.sgl[0].icg){
>>> ? ? ? ? ? /* a line and some */
>>> ? ? ? ? ? schan->xlen = xfer_template.sgl[0].size + ?xfer_template.sgl[1].size.
>>> ? ? ? ? ? schan->width = xfer_template.sgl[0].size;
>>> ? ? ?} else {
>>> ? ? ? ? ? /* _Hardware_ doesn't support the transfer as such. *
>>> ? ? ? ? ? return -EINVAL;
>>> ? ? ?}
>>> ? ? ?schan->ylen = xfer_template.numf /* -1? */;
>>>
>>
>> For prima2:
>> xfer_template.frame_size is always 1, then
>> schan->xlen = xfer_template.sgl[0].size;
>> schan->width = schan->xlen + xfer_template.sgl[0].icg;
>>
> Ok, you don't need the 'else if' clause because as you said
> {xlen > width} is not an option.
> But you do need the other two checks, so that the DMAC driver
> cleanly rejects any interleaved-format that it doesn't support.
>
> Point being, the clients and DMAC drivers are supposed to be
> very 'promiscuous' - any Client could be 'riding' any DMAC ;)
yes. of course.
>
-barry
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Barry Song @ 2011-09-14 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914084237.GC6267@n2100.arm.linux.org.uk>
2011/9/14 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, Sep 06, 2011 at 01:48:26PM +0800, Shawn Guo wrote:
>> If ARM core gets powered off during suspend, L2 cache controller
>> has to be reinitialized by resume procedure.
>>
>> The patch removes __init annotation from a few initialization
>> functions to make the reinitialization possible. ?For example,
>> platform resume function can call l2x0_of_init() to get L2 cache
>> back to work.
>>
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>> ---
>> ?arch/arm/include/asm/hardware/cache-l2x0.h | ? ?2 +-
>> ?arch/arm/mm/cache-l2x0.c ? ? ? ? ? ? ? ? ? | ? 10 +++++-----
>> ?2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
>> index d22765c..d270310 100644
>> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
>> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
>> @@ -89,7 +89,7 @@
>> ?#define L2X0_ADDR_FILTER_EN ? ? ? ? ?1
>>
>> ?#ifndef __ASSEMBLY__
>> -extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
>> +extern void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
>> ?#if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
>> ?extern int l2x0_of_init(__u32 aux_val, __u32 aux_mask);
>> ?#else
>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>> index c035b9a..7835cb6 100644
>> --- a/arch/arm/mm/cache-l2x0.c
>> +++ b/arch/arm/mm/cache-l2x0.c
>> @@ -280,7 +280,7 @@ static void l2x0_disable(void)
>> ? ? ? spin_unlock_irqrestore(&l2x0_lock, flags);
>> ?}
>>
>> -void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
>> +void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
>> ?{
>> ? ? ? __u32 aux;
>> ? ? ? __u32 cache_id;
>
> I'm unconvinced about the wise-ness of this. ?We read-modify-write the
> auxillary control register, which means some bits are preserved from
> the initial boot. ?If the boot loader sets the L2 cache up for normal
> boot and not for resume, we'll end up with different L2 cache settings.
>
> We've historically seen this kind of thing with boot loaders over the
> years, to the point where systems boot at one CPU clock rate but resume
> at some other CPU clock rate.
>
> So, it may be wiser to implement a 'save' and 'restore' interface
> instead so that we can be sure that things are setup in the same way
> after resume.
could we have an outer_cache save/restore as below,
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
void (*flush_range)(unsigned long, unsigned long);
void (*flush_all)(void);
void (*inv_all)(void);
void (*disable)(void);
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
void (*set_debug)(unsigned long);
+ void (*save)(void);
+ void (*restore)(void);
};
then let cache-l2x0.c fill the two callbacks, and all systems call
outer_save/outer_restore?
-barry
^ permalink raw reply
* [ltt-dev] LTTng 2.0 on ARM
From: Dave Martin @ 2011-09-14 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFDrCav6sVzmapfN3YL8omYKc2NHorHuHMXh49dBbzw1Xg@mail.gmail.com>
On Tue, Sep 13, 2011 at 11:14:47PM +0530, Rabin Vincent wrote:
> On Tue, Sep 13, 2011 at 21:20, Mathieu Desnoyers
> <compudj@krystal.dyndns.org> wrote:
> > * Avik Sil (avik.sil at linaro.org) wrote:
> >> On Tuesday 13 September 2011 12:35 AM, Mathieu Desnoyers wrote:
> >> > * Avik Sil (avik.sil at linaro.org) wrote:
> >> >> [ 1139.173522] vmalloc_sync_all_sym: c00a1d14
> >> >> [ 1139.180877] Internal error: Oops - undefined instruction: 0 [#1]
> >> >> PREEMPT SMP
> >> >> [ 1139.191284] Modules linked in: lttng_ftrace(+)
> >> >> [ 1139.198974] CPU: 1 ? ?Not tainted ?(3.0.0-1004-linaro-omap #6)
> >> >> [ 1139.208099] PC is at vmalloc_sync_all+0x0/0x8
> >> >> [ 1139.215667] LR is at init_module+0x1c/0x28 [lttng_ftrace]
> >> >> [ 1139.224304] pc : [<c00a1d14>] ? ?lr : [<bf800211>] ? ?psr: 60000113
> >> >> [ 1139.224304] sp : ebb11f50 ?ip : 00000000 ?fp : 00000000
> >> >> [ 1139.242401] r10: 00000000 ?r9 : 00000000 ?r8 : c06a2f00
> >> >> [ 1139.250793] r7 : bf8001f5 ?r6 : 00000000 ?r5 : 00182008 ?r4 : c00a1d14
> >> >> [ 1139.260559] r3 : 271aed1f ?r2 : ebb11f44 ?r1 : bf8003a6 ?r0 : 00000034
> >> >> [ 1139.270233] Flags: nZCv ?IRQs on ?FIQs on ?Mode SVC_32 ?ISA ARM
> [...]
> >> Disassembly of section .text:
> >>
> >> c00a1d14 <vmalloc_sync_all>:
> >> c00a1d14: ? ? b500 ? ? ? ? ? ?push ? ?{lr}
> >> c00a1d16: ? ? f76a fa9d ? ? ? bl ? ? ?c000c254 <__gnu_mcount_nc>
> >> c00a1d1a: ? ? 4770 ? ? ? ? ? ?bx ? ? ?lr
> >>
> [...]
> >> >
> >> > We have to keep in mind that this could also be a ftrace function tracer
> >> > bug, in which case the surrounding of 0xc00a1d14 from the vmlinux image
> >> > will not match the instructions in memory. Can you dump the hex content
> >> > around 0xc00a1d14 just before the vmalloc_sync_all gets called and
> >> > compare with the disassembly ?
> >>
> >> The hex content dump shows:
> >>
> >> [ ?150.810119] c00a1d14: b500 f85d eb04 4770
> >>
> >> So it seems your guess is right, the content of vmlinux image
> >> surrounding 0xc00a1d14 is not matching the instruction in memory. By
> >> grepping objdump I found that instruction 'f85d eb04' translates to
> >> "ldr.w ? ? ? ?lr, [sp], #4".
> >
> > I'm adding the ARM function tracer developers in CC. Maybe they can
> > enlighten us.
>
> ftrace has indeed overwritten the instructions here, but it's done it
> correctly. The problem here is that you're trying to execute a Thumb-2
> function in ARM mode. This is unrelated to ftrace, I've reproduced it
> here with a Thumb-2 kernel without ftrace enabled with just this code:
>
> static int __init late(void)
> {
> void (*v)(void);
>
> v = (void *) kallsyms_lookup_name("vmalloc_sync_all");
> printk("%s addr %p\n", __func__, v);
>
> v();
>
> return 0;
> }
> late_initcall(late);
>
> which leads to this:
>
> late addr c010ed7c
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
> CPU: 0 Not tainted (3.1.0-rc2+ #339)
> PC is at late+0x4/0x28
> LR is at late+0x17/0x28
> pc : [<c010ed80>] lr : [<c010ed93>] psr: 40000013
> sp : c782dfb0 ip : 00000000 fp : 00000000
> r10: 00000000 r9 : 00000000 r8 : 00000000
> r7 : 00000033 r6 : 00000000 r5 : c010ed7d r4 : c010ed7c
> r3 : c010ed7c r2 : c782dfa4 r1 : c00f0963 r0 : 00000025
> Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 50c53c7d Table: 0000406a DAC: 00000015
> Process swapper (pid: 1, stack limit = 0xc782c2f0)
> Stack: (0xc782dfb0 to 0xc782e000)
> dfa0: c011ab7c c010b66b 00000000 00000000
> dfc0: 0000007f c01295ac c000ca81 c011ab7c c011ab94 c000ca81 00000033 00000000
> dfe0: 00000000 c010b765 00000000 00000000 c010b701 c000ca81 00000000 00000000
> [<c010ed80>] (late+0x4/0x28) from [<c010b66b>] (do_one_initcall+0x63/0xf8)
> [<c010b66b>] (do_one_initcall+0x63/0xf8) from [<c010b765>]
> (kernel_init+0x65/0xd8)
> [<c010b765>] (kernel_init+0x65/0xd8) from [<c000ca81>]
> (kernel_thread_exit+0x1/0x6)
> Code: c0125e20 c01307ac 47702000 4806b510 (f81ef727)
>
> The problem is that the addresses returned by kallsyms_lookup_name()
> does not have the zero bit, which is what is expected for Thumb
> functions because the BLX instruction which is used to call them uses
> this bit to determines which mode to switch into. Since it's cleared,
> you switch to ARM mode and attempt to execute Thumb-2 code, with obvious
> results.
>
> A cursory look at the parties involved shows that nm doesn't show the
> zero bit (even though it's set in the vmlinux symbol table), and
> scripts/kallsyms builds the table by parsing nm's output.
It's not quite as simple as saying "the output of nm is wrong" though...
When getting the address of a function, there are actually two
separate answers:
a) the pointer which can be used to call the function
b) the address of the start of the function body
On many arches these they are identical, but on some they are different.
On ARM, they are identical for ARM code but different for Thumb code
(because the Thumb bit must be set in case (a) but not in case (b))
It may be worth looking at what is done in the kernel for ia64 and ppc64.
I believe that (a) and (b) are quite different for these because
functions are called through descriptors. Don't quote me on that though:
I'm mostly ignorant about these arches.
For the Thumb-2 kernel case, we can probably hack around this: there
are various places in the kernel where we just force-set the Thumb bit
in addresses without really knowing what the target code is. We get
away with this because the kernel is (very nearly) 100% Thumb code
for a Thumb-2 kernel.
However, if the kernel already has a correct approach for solving this
problem, we should probably be using it.
Cheers
---Dave
^ permalink raw reply
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
From: Santosh @ 2011-09-14 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913202701.GF24252@atomide.com>
On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
> * Santosh Shilimkar<santosh.shilimkar@ti.com> [110904 06:22]:
>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> and they can be drained only with stongly ordered accesses.
>
> This is not correct, strongly ordered access does not guarantee
> anything here. If it fixes issues, it's because it makes the writes
> to reach the device faster. Strongly ordered does not affect anything
> outside ARM, so the bus access won't change.
>
What I said is the aync bridges WB and what is said is correct
from MPU accesses point of view.
It's not about faster or slower. With device memory the, writes
can get stuck into write buffers where as with SO, the write buffers
will be bypassed.
The behaviours is limited to the MPU side async bridge boundary which
is the problem. The statement is not for l3 and l4 interconnect which
probably you mean.
There is always a hardware signal to communicate CPU at async bridges
to ensure that data is not stuck in these bridges before CPU
clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
and the dual channel makes it even worst since both pipes have the
same BUG. So what we are doing is issuing SO write/read accesses
on these pipes so that there is nothing stuck there before MPU
hits low power states and also avoids any race conditions when
both channels are used together by some initiators. The behaviour
is validated at RTL level and there is no ambiguity about it.
May be you have mistaken the L3 and L4 as the interconnect levels
in this case.
Regards
Santosh
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Vinod Koul @ 2011-09-14 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY25NTbtRPOw-KH8U4zA1Bo8q0BDM8SXyrsobG7NEv8edg@mail.gmail.com>
On Wed, 2011-09-14 at 12:00 +0530, Jassi Brar wrote:
> On Wed, Sep 14, 2011 at 11:31 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
> >> This patchset adds support DMA generic APIs for samsung DMA.
> >>
> >> The changes from V7 is following:
> >> - Divides patch file.
> >> : The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8 patchset.
> >> The O3 patch is only for DMA_SLAVE_CONFIG command.
> >> The 04 patch is only for DMA_TERMINATE_ALL command.
> >> - Code clean-up
> >> : Remove unnecessary code on 05 patch.
> >>
> >> [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
> >> [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
> >> [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
> >> [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
> >> [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
> >> [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
> >> [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
> >> [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
> >> [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
> >> [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
> >> [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
> >> [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
> >> [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
> >> [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
> >> [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
> >> [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for dma direction
> > Thanks,
> >
> > I have pushed these into my samsung-dma branch, Fixed the typos in the
> > changelog of patch 4.
> >
> > Please check and let me know if all are fine, I will push them to my
> > next tomorrow
> >
> > If anyone has concerns on this series please let me know by tomorrow
> >
>
> I have no concern about patches modifying samsung specific code.
>
> Of the patches touching common pl330 code, I had acked Patch-1,2,3 & 5
> in previous revisions already. So for them, you may add my
> Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Ok
>
> The changelog for [PATCH v8 04/16] is misleading - we don't need any
> modification for the reason mentioned in changelog. But the modification
> has positive side-effect of preventing callbacks during terminate_all which
> is no way understood from the changelog. So I would like to changelog
> corrected.
I thought change log was correct in depicting what patch does and Boojin
had replied.... I will check again...
--
~Vinod
^ permalink raw reply
* [PATCH v7 14/26] gpio/omap: remove unnecessary bit-masking for read access
From: Sergei Shtylyov @ 2011-09-14 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-15-git-send-email-tarun.kanti@ti.com>
Hello.
On 13-09-2011 17:02, Tarun Kanti DebBarma wrote:
> Remove un-necessary bit masking. Since the register are 4 byte aligned
> and readl would work as is. The 'enabled' mask is already taking care
> to mask for bank width.
> Signed-off-by: Charulatha V<charu@ti.com>
> Signed-off-by: Tarun Kanti DebBarma<tarun.kanti@ti.com>
> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> ---
> drivers/gpio/gpio-omap.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 876e387..d614c6d 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -571,8 +571,6 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> enabled = _get_gpio_irqbank_mask(bank);
> isr_saved = isr = __raw_readl(isr_reg)& enabled;
>
> - if (cpu_is_omap15xx()&& (bank->method == METHOD_MPUIO))
> - isr&= 0x0000ffff;
>
Should have removed the now unneeded empty line too.
> if (bank->level_mask)
> level_mask = bank->level_mask& enabled;
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Kukjin Kim @ 2011-09-14 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACY+gR2oRqEA80Ura9Wp5cDW7b-Cjo+KVnfuA-PBHbFZKfRpwQ@mail.gmail.com>
Siarhei Siamashka wrote:
>
> On Wed, Sep 14, 2011 at 10:57 AM, Kyungmin Park <kmpark@infradead.org>
> wrote:
> > On Wed, Sep 14, 2011 at 4:43 PM, Siarhei Siamashka
> > <siarhei.siamashka@gmail.com> wrote:
> >> On Wed, Sep 14, 2011 at 9:08 AM, Kyungmin Park <kmpark@infradead.org>
> wrote:
> >>> Hi Siarhei,
> >>>
> >>> Interesting feature, and it's not samsung soc issue, so add the arm
> >>> mailing list.
> >>> It checked and the see the read performance improvement from 868MiB/s
> >>> to 981MiB/s with lmbench.
> >>
> >> Maybe lmbench does not try very hard to get the best out of the
> >> hardware? On my origenboard, I'm getting ~1.15GB/s performance for the
> >> standard LDM/STM based memcpy from libc-ports, which is ~2.3GB/s
> >> memory bandwidth if both reads and writes are accounted separately.
> >>
> >>> It's helpful to test other SoC., e.g., OMAP4, STE and so on.
> >>
> >> The current (?) state of the support for this feature in OMAP4 is
> >> explained here by Richard Woodruff:
> >> http://groups.google.com/group/pandaboard/msg/dfd2d2e1336d435b
> >>
> >>> BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit
> >>> and should be zero (SBZ).
> >>
> >> This PL310 thing seems to have been renamed to "CoreLink Level 2 Cache
> >> Controller L2C-310" in later revisions, and its Prefetch Control
> >> Register is described here:
> >> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/CHDHIECI.html
> > Thanks for link. it has 27-bit description. but does it correct bit
> > description for exynos4 PL310?
> > I mean I received the PL310 TRM with exynos4 chip used. there's no
> > 27-bit description. it's just reserved bit.
> > Can it enable the 27-bit at exynos4210? or can be used for exynos4212 or later?
>
> That's a good point. I think it is exynos4210 that is used in
> origenboard. And according to the value in Cache ID Register
> (0x4100c4c5), it has r3p0 revision of L2C-310. Which means that the
> Prefetch Control Register is actually described at:
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246d/CHDHIECI.html
> And bit 27 is indeed reserved. However flipping it seems to have some
> measurable impact on performance (unless I screwed up the benchmarks),
> so maybe it does something but is undocumented? In any case, I agree
> that it's better not to mess up with this bit.
>
Hi all,
Please adding me in Cc for Samsung stuff...
> By the way, does anybody have L2C-310 errata list? Is double linefill
> actually safe to use in r3p0?
>
No. it is _not_ safe on EXYNOS4210.
Since L2C-310 ERRTA, current EXYNOS4210 cannot enable double linefill feature and as Siarhei said, need to check its version of L2C-310 in Cache ID register before enabling it. As a note, it's possible to enable it on EXYNOS4212 SoC and in opposite of Siarhei's patch, enabling WRAP read is better on it. Actually my colleague, Boojin Kim is testing it so that can submit it soon.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Kukjin Kim @ 2011-09-14 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315980099.26251.498.camel@vkoul-udesk3>
Vinod Koul wrote:
>
> On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
> > This patchset adds support DMA generic APIs for samsung DMA.
> >
> > The changes from V7 is following:
> > - Divides patch file.
> > : The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8
> patchset.
> > The O3 patch is only for DMA_SLAVE_CONFIG command.
> > The 04 patch is only for DMA_TERMINATE_ALL command.
> > - Code clean-up
> > : Remove unnecessary code on 05 patch.
> >
> > [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
> > [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
> > [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
> > [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling
> DMA_TERMINATE_ALL command
> > [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
> > [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
> > [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
> > [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
> > [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
> > [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
> > [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
> > [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
> > [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
> > [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
> > [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
> > [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for
> dma direction
> Thanks,
>
> I have pushed these into my samsung-dma branch, Fixed the typos in the
> changelog of patch 4.
>
> Please check and let me know if all are fine, I will push them to my
> next tomorrow
>
Hi Vinod,
Thanks for your applying.
When you push them to your next, I will merge samsung-dma branch to my -next to avoid conflicts.
If any problems, please let me know.
> If anyone has concerns on this series please let me know by tomorrow
Thanks again.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
From: Jassi Brar @ 2011-09-14 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315999032.26251.501.camel@vkoul-udesk3>
On 14 September 2011 16:47, Vinod Koul <vinod.koul@intel.com> wrote:
>> The changelog for [PATCH v8 04/16] is misleading - we don't need any
>> modification for the reason mentioned in changelog. But the modification
>> has positive side-effect of preventing callbacks during terminate_all which
>> is no way understood from the changelog. So I would like to changelog
>> corrected.
> I thought change log was correct in depicting what patch does and Boojin
> had replied.... I will check again...
I didn't reply because I ran out of ways to explain the same thing in
different words.
^ permalink raw reply
* [PATCH v2 1/6] OMAP3: id: remove identification codes that only correspond to marketing names
From: Paul Walmsley @ 2011-09-14 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212801.26161.47980.stgit@dusk>
The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits. Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.
The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
as the OMAP3430, with some features disabled via eFuse bits. Identify
these devices internally as part of the OMAP3430 family.
Remove the old OMAP35XX_CLASS, which actually covered two very different
chip families. The OMAP3503/3515/3525/3530 chips will now be covered by
OMAP343X_CLASS, since the silicon appears to be identical. For the
OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.
Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
revision of this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
This second version fixes a stupid bug that would have definitely caused
problems with the first patch version on AM3517/3505 devices. Still not
sure if it works correctly, though, since I don't have an AM3517/3505
board here to test. Testing help very welcome.
arch/arm/mach-omap2/id.c | 17 ++++++-----------
arch/arm/plat-omap/include/plat/cpu.h | 14 +++++---------
2 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..723e2f8 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -304,14 +304,15 @@ static void __init omap3_check_revision(void)
}
break;
case 0xb868:
- /* Handle OMAP35xx/AM35xx devices
+ /*
+ * Handle OMAP/AM 3505/3517 devices
*
- * Set the device to be OMAP3505 here. Actual device
+ * Set the device to be OMAP3517 here. Actual device
* is identified later based on the features.
*
* REVISIT: AM3505/AM3517 should have their own CHIP_IS
*/
- omap_revision = OMAP3505_REV(rev);
+ omap_revision = OMAP3517_REV(rev);
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
@@ -442,26 +443,20 @@ static void __init omap3_cpuinfo(void)
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
- omap_revision = OMAP3517_REV(rev);
+ if (omap3_has_sgx())
strcpy(cpu_name, "AM3517");
- } else {
- /* Already set in omap3_check_revision() */
+ else
strcpy(cpu_name, "AM3505");
- }
} else if (cpu_is_ti816x()) {
strcpy(cpu_name, "TI816X");
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, "OMAP3430/3530");
} else if (omap3_has_iva()) {
- omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, "OMAP3525");
} else if (omap3_has_sgx()) {
- omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, "OMAP3515");
} else {
- omap_revision = OMAP3503_REV(rev);
strcpy(cpu_name, "OMAP3503");
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..34df171 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -262,7 +262,7 @@ IS_OMAP_TYPE(2422, 0x2422)
IS_OMAP_TYPE(2423, 0x2423)
IS_OMAP_TYPE(2430, 0x2430)
IS_OMAP_TYPE(3430, 0x3430)
-IS_OMAP_TYPE(3505, 0x3505)
+IS_OMAP_TYPE(3505, 0x3517)
IS_OMAP_TYPE(3517, 0x3517)
#define cpu_is_omap310() 0
@@ -354,8 +354,9 @@ IS_OMAP_TYPE(3517, 0x3517)
(!omap3_has_sgx()) && \
(omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
-# define cpu_is_omap3505() is_omap3505()
# define cpu_is_omap3517() is_omap3517()
+# define cpu_is_omap3505() (cpu_is_omap3517() && \
+ !omap3_has_sgx())
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
# define cpu_is_ti816x() is_ti816x()
@@ -397,13 +398,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (OMAP_REVBITS_01 << 8))
#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
-#define OMAP35XX_CLASS 0x35000034
-#define OMAP3503_REV(v) (OMAP35XX_CLASS | (0x3503 << 16) | (v << 8))
-#define OMAP3515_REV(v) (OMAP35XX_CLASS | (0x3515 << 16) | (v << 8))
-#define OMAP3525_REV(v) (OMAP35XX_CLASS | (0x3525 << 16) | (v << 8))
-#define OMAP3530_REV(v) (OMAP35XX_CLASS | (0x3530 << 16) | (v << 8))
-#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 << 16) | (v << 8))
-#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 << 16) | (v << 8))
+#define OMAP3517_CLASS 0x35170034
+#define OMAP3517_REV(v) (OMAP3517_CLASS | (v << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kukjin Kim @ 2011-09-14 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2V6Sfjmjupj5oBd_5vziBa4iezBpRfK9tNECrFO5sSfLw@mail.gmail.com>
Kyungmin Park wrote:
>
> Hi,
>
> It's required for boot universal c210 w/ EVT0 chip.
> Can you include it at 3.1 fixed branch?
>
Sure, will apply into samsung-fixes for 3.1.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Thank you,
> Kyungmin Park
>
> On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
> > Commit 069d4e743 removed support for local timers and forced to use MCT
as
> > event source. However MCT is not operating properly on early revision
(EVT0)
> > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0, so
> that
> > commit broke support for it. This patch provides a workaround that
enables
> > UniversalC210 boards to boot again. s5p-timer is used as an event
source.
> >
> > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
> > ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
> > ?2 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
> > index 9d62e13..2aad73f 100644
> > --- a/arch/arm/mach-exynos4/Kconfig
> > +++ b/arch/arm/mach-exynos4/Kconfig
> > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
> > ?config MACH_UNIVERSAL_C210
> > ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> > ? ? ? ?select CPU_EXYNOS4210
> > + ? ? ? select S5P_HRT
> > + ? ? ? select CLKSRC_MMIO
> > + ? ? ? select HAVE_SCHED_CLOCK
> > ? ? ? ?select S5P_GPIO_INT
> > ? ? ? ?select S5P_DEV_FIMC0
> > ? ? ? ?select S5P_DEV_FIMC1
> > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
b/arch/arm/mach-
> exynos4/mach-universal_c210.c
> > index 0e280d1..ca9e7b7 100644
> > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> > @@ -34,6 +34,7 @@
> > ?#include <plat/mfc.h>
> > ?#include <plat/sdhci.h>
> > ?#include <plat/pd.h>
> > +#include <plat/s5p-time.h>
> >
> > ?#include <mach/map.h>
> >
> > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
> > ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> > ? ? ? ?s3c24xx_init_clocks(24000000);
> > ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs,
ARRAY_SIZE(universal_uartcfgs));
> > + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
> > ?}
> >
> > ?static void __init universal_reserve(void)
> > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
> "UNIVERSAL_C210")
> > ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
> > ? ? ? ?.map_io ? ? ? ? = universal_map_io,
> > ? ? ? ?.init_machine ? = universal_machine_init,
> > - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> > + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
> > ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
> > ?MACHINE_END
> > --
> > 1.7.1.569.g6f426
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
linux-samsung-soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* [PATCH] OMAP2+: hwmod: remove OMAP_CHIP*
From: Paul Walmsley @ 2011-09-14 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnOOkz2ZkhPSafTLxUUH2bSVoRrYA44-C1+yku8naYaRz3w@mail.gmail.com>
Hello Gra?vydas,
On Mon, 5 Sep 2011, Grazvydas Ignotas wrote:
> On Mon, Sep 5, 2011 at 5:43 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> > index 84cc0bd..d7138070 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> <snip>
>
> >
> > ?int __init omap3xxx_hwmod_init(void)
> > ?{
> > - ? ? ? return omap_hwmod_register(omap3xxx_hwmods);
> > + ? ? ? int r;
> > + ? ? ? struct omap_hwmod **h = NULL;
> > +
> > + ? ? ? /* Register hwmods common to all OMAP3 */
> > + ? ? ? r = omap_hwmod_register(omap3xxx_hwmods);
> > + ? ? ? if (!r)
> > + ? ? ? ? ? ? ? return r;
> > +
> > + ? ? ? /*
> > + ? ? ? ?* Register hwmods common to individual OMAP3 families, all
> > + ? ? ? ?* silicon revisions (e.g., 34xx, or AM3505/3517, or 36xx)
> > + ? ? ? ?* All possible revisions should be included in this conditional.
> > + ? ? ? ?*/
> > + ? ? ? if (omap_rev() == OMAP3430_REV_ES1_0 ||
> > + ? ? ? ? ? omap_rev() == OMAP3430_REV_ES2_0 ||
> > + ? ? ? ? ? omap_rev() == OMAP3430_REV_ES2_1 ||
> > + ? ? ? ? ? omap_rev() == OMAP3430_REV_ES3_0 ||
> > + ? ? ? ? ? omap_rev() == OMAP3430_REV_ES3_1 ||
> > + ? ? ? ? ? omap_rev() == OMAP3430_REV_ES3_1_2) {
> > + ? ? ? ? ? ? ? h = omap34xx_hwmods;
> > + ? ? ? } else if (omap_rev() & OMAP3505_REV(0)) {
> > + ? ? ? ? ? ? ? h = am35xx_hwmods;
>
> This check will be always true I think?
Thanks for the review; you are absolutely right and this will be fixed.
> Why not just use cpu_is_omap3xxx() for these tests, since it does same
> omap_rev() call but only once per family?
cpu_is_omap*() doesn't do what one would expect :-(
For example, cpu_is_omap34xx() returns 1 on not only 34xx, but also 36xx
and 3517/3505. Unfortunately, we don't currently do a good job of
separating SoC family detection from individual SoC detection.
If your objection is to the multiple calls to omap_rev(), those do indeed
appear in the source to be potentially expensive function calls --
although the compiler should inline them. Just to be sure, the
next revision will use a variable.
regards
- Paul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox