[PATCH 3/3] ARM: S5PV210: Removed code for setting clock rate of xusbxti
Since now xusbxti clock's default rate is set in clock.c file, there is no need to set it again in the machine file. Signed-off-by: Pankaj Dubey --- arch/arm/mach-s5pv210/mach-goni.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-s5pv210/mach-goni.c b/arch/arm/mach-s5pv210/mach-goni.c index 15edcae..02d31f4 100644 --- a/arch/arm/mach-s5pv210/mach-goni.c +++ b/arch/arm/mach-s5pv210/mach-goni.c @@ -947,7 +947,6 @@ static void __init goni_machine_init(void) /* KEYPAD */ samsung_keypad_set_platdata(&keypad_data); - clk_xusbxti.rate = 2400; platform_add_devices(goni_devices, ARRAY_SIZE(goni_devices)); } -- 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 2/3] ARM: EXYNOS: Removed code for setting clock rate of xusbxti
Since now xusbxti clock's default rate is set in clock.c file,
there is no need to set it again in the machine file.
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/mach-nuri.c |1 -
arch/arm/mach-exynos/mach-origen.c |1 -
arch/arm/mach-exynos/mach-smdk4x12.c |2 --
arch/arm/mach-exynos/mach-smdkv310.c |1 -
4 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 236bbe1..d9196b8 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1314,7 +1314,6 @@ static void __init nuri_machine_init(void)
nuri_camera_init();
nuri_ehci_init();
- clk_xusbxti.rate = 2400;
/* Last */
platform_add_devices(nuri_devices, ARRAY_SIZE(nuri_devices));
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index f56d027..4700456 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -702,7 +702,6 @@ static void __init origen_machine_init(void)
s3c_sdhci0_set_platdata(&origen_hsmmc0_pdata);
origen_ehci_init();
- clk_xusbxti.rate = 2400;
s5p_tv_setup();
s5p_i2c_hdmiphy_set_platdata(NULL);
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c
b/arch/arm/mach-exynos/mach-smdk4x12.c
index fcf2e0e..35b86ea 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -247,8 +247,6 @@ static struct platform_device *smdk4x12_devices[]
__initdata = {
static void __init smdk4x12_map_io(void)
{
- clk_xusbxti.rate = 2400;
-
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
s3c24xx_init_clocks(clk_xusbxti.rate);
s3c24xx_init_uarts(smdk4x12_uartcfgs, ARRAY_SIZE(smdk4x12_uartcfgs));
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c
b/arch/arm/mach-exynos/mach-smdkv310.c
index cec2afa..c7fb82f 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -363,7 +363,6 @@ static void __init smdkv310_machine_init(void)
s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
smdkv310_ehci_init();
- clk_xusbxti.rate = 2400;
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
--
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 1/3] ARM: S5P: Set default rate of xusbxti clock
From: Pankaj
Initialize xusbxti clock's default value here.
So that code duplication in all other mach-board.c can be avoided.
Signed-off-by: Pankaj Dubey
---
arch/arm/plat-s5p/clock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-s5p/clock.c b/arch/arm/plat-s5p/clock.c
index 5f84a3f..6fb9049 100644
--- a/arch/arm/plat-s5p/clock.c
+++ b/arch/arm/plat-s5p/clock.c
@@ -38,6 +38,7 @@ struct clk clk_ext_xtal_mux = {
struct clk clk_xusbxti = {
.name = "xusbxti",
.id = -1,
+ .rate = 2400,
};
struct clk s5p_clk_27m = {
--
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 0/3] Moving xusbxti clock setting in clock.c file.
Since there is code duplication in different mach-board.c file it is better to set default clock rate of xusbxti clock in plat-s5p/clock.c file. The patches are based on following commit on Kukjin's for-next branch. Pankaj (1): ARM: S5P: Set default rate of xusbxti clock Pankaj Dubey (2): ARM: EXYNOS: Removed code for setting clock rate of xusbxti ARM: S5PV210: Removed code for setting clock rate of xusbxti arch/arm/mach-exynos/mach-nuri.c |1 - arch/arm/mach-exynos/mach-origen.c |1 - arch/arm/mach-exynos/mach-smdk4x12.c |2 -- arch/arm/mach-exynos/mach-smdkv310.c |1 - arch/arm/mach-s5pv210/mach-goni.c|1 - arch/arm/plat-s5p/clock.c|1 + 6 files changed, 1 insertions(+), 6 deletions(-) -- 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] ARM: S5PV210: Add USB OTG gadget device support to SMDKV210 board
Hi Jingoo, On Tuesday 29 November 2011 09:17 AM, Jingoo Han wrote: [ snip ] diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c [ snip ] @@ -308,6 +310,8 @@ static void __init smdkv210_machine_init(void) samsung_bl_set(&smdkv210_bl_gpio_info,&smdkv210_bl_data); + clk_xusbxti.rate = 2400; + Would it be a good idea to set the default rate of clk_xusbxti in arch/arm/plat-s5p/clock.c and remove the explicit rate setting in all the machine files? Currently, the clock is also set in machine files for which ehci is enabled. platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices)); } -- Tushar Behera -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
On Fri, Dec 02, 2011 at 09:35:44AM +0900, Kyungmin Park wrote: > I'm not sure what's the next step at s3c64xx for generic power domain. > Related with exysno4 series, it's helpful to read following threads. > http://68.183.106.108/lists/linux-pm/msg26291.html > "I don't think we should control/gate the clocks with regarding power > domain" from Mr. Kim I tend to agree with him that gating the clocks automatically using runtime PM would be nice as if nothing else it saves code in drivers. I'm not sure how easy it's going to be to transition to doing that in one jump, though - there's a lot of SoCs sharing IP right back to S3C24xx. Of course it should be fairly easy for most of the domains on s3c64xx right now as there's only one actual driver involved in mainline, we should just be gating almost all of the clocks concerned immediately after we boot (assuming they aren't gated by default, I'd need to check) and never touching them again anyway. It'd only be the framebuffer clocks that'd need some work and for a first pass we could just mark the framebuffer domain as always on and get most of the win. Sometimes lack of driver support is a good thing :) -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
Hi Mark,
I'm not sure what's the next step at s3c64xx for generic power domain.
Related with exysno4 series, it's helpful to read following threads.
http://68.183.106.108/lists/linux-pm/msg26291.html
"I don't think we should control/gate the clocks with regarding power
domain" from Mr. Kim
Thank you,
Kyungmin Park
On 12/2/11, Mark Brown wrote:
> The S3C64xx SoCs contain a set of gateable power domains which can be
> enabled and disabled at runtime in order to save power. Use the generic
> power domain code to implement support for these in software, enabling
> runtime control of most domains:
>
> - ETM (not supported in mainline).
> - Domain G: 3D acceleration (no mainline support).
> - Domain V: MFC (no mainline support).
> - Domain I: JPEG and camera interface (no mainline support).
> - Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
> - Domain S: Security (no mainline support).
> - Domain F: LCD (driver already uses runtime PM), post processing and
>rotation (no mainline support).
>
> The IROM domain is marked as always enabled as we should arrange for it
> to be enabled when we suspend which will need a bit more work.
>
> Due to all the conditional device registration that the platform does
> wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
> into the power domain after the machines have registered, looking for
> platform data to tell if the device was registered. Since currently only
> Cragganmore actually sets up PM that is the only machine updated.
>
> Signed-off-by: Mark Brown
> ---
>
> Kikjin, this superceeds my previous patch unconditionally disabling some
> of the domains. I've given it quite a bit of testing and it appears to
> be working well on my systems though I'm not sure the power saving is
> really all that much to write home about.
>
> arch/arm/mach-s3c64xx/Kconfig |1 +
> arch/arm/mach-s3c64xx/mach-crag6410.c |2 +-
> arch/arm/mach-s3c64xx/pm.c | 173
> ++-
> arch/arm/plat-samsung/include/plat/pm.h |6 +
> 4 files changed, 179 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 4d8c489..5c6c22e 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -8,6 +8,7 @@ config PLAT_S3C64XX
> bool
> depends on ARCH_S3C64XX
> select SAMSUNG_WAKEMASK
> + select PM_GENERIC_DOMAINS
> default y
> help
> Base platform code for any Samsung S3C64XX device
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
> b/arch/arm/mach-s3c64xx/mach-crag6410.c
> index 98d42b3..4ce4a74 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -743,7 +743,7 @@ static void __init crag6410_machine_init(void)
>
> regulator_has_full_constraints();
>
> - s3c_pm_init();
> + s3c64xx_pm_init();
> }
>
> MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
> diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
> index b375cd5..aa7b5d1 100644
> --- a/arch/arm/mach-s3c64xx/pm.c
> +++ b/arch/arm/mach-s3c64xx/pm.c
> @@ -17,10 +17,12 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -31,6 +33,145 @@
> #include
> #include
>
> +struct s3c64xx_pm_domain {
> + char *const name;
> + u32 ena;
> + u32 pwr_stat;
> + struct generic_pm_domain pd;
> +};
> +
> +static int s3c64xx_pd_off(struct generic_pm_domain *domain)
> +{
> + struct s3c64xx_pm_domain *pd;
> + u32 val;
> +
> + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
> +
> + val = __raw_readl(S3C64XX_NORMAL_CFG);
> + val &= ~(pd->ena);
> + __raw_writel(val, S3C64XX_NORMAL_CFG);
> +
> + return 0;
> +}
> +
> +static int s3c64xx_pd_on(struct generic_pm_domain *domain)
> +{
> + struct s3c64xx_pm_domain *pd;
> + u32 val;
> + long retry = 100L;
> +
> + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
> +
> + val = __raw_readl(S3C64XX_NORMAL_CFG);
> + val |= pd->ena;
> + __raw_writel(val, S3C64XX_NORMAL_CFG);
> +
> + /* Not all domains provide power status readback */
> + if (pd->pwr_stat) {
> + while (retry--)
> + if (__raw_readl(S3C64XX_BLK_PWR_STAT) & pd->pwr_stat)
> + break;
> + if (!retry) {
> + pr_err("Failed to start domain %s\n", pd->name);
> + return -EBUSY;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
> + .name = "IROM",
> + .ena = S3C64XX_NORMALCFG_IROM_ON,
> + .pd = {
> + .power_off = s3c64xx_pd_off,
> + .power_on = s3c64xx_pd_on,
> + },
> +};
> +
> +static struct s3c64xx_pm_domain s3c64xx_pm_etm = {
> + .name = "ETM",
> +
Re: [PATCH 2/3] ARM: mach-shmobile: Use common always on power domain governor
On Thu, Dec 01, 2011 at 09:37:07PM +0100, Rafael J. Wysocki wrote: > On Thursday, December 01, 2011, Mark Brown wrote: > > Saves a tiny amount of code. > How so? It saves source code size when we get the second user, by itself you're right it doesn't achieve anything (except avoiding redundancy once 1/3 gets applied I guess). -- 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: Re: [PATCH 3/3] USB: Add S5P OHCI diver
Kukjin Kim wrote:
> Subject: RE: [PATCH 3/3] USB: Add S5P OHCI diver
>
> Jingoo Han wrote:
> >
> > This patch adds USB OHCI driver for Samsung S5P SoCs.
> >
> > Signed-off-by: Jingoo Han
> > ---
> > drivers/usb/Kconfig |1 +
> > drivers/usb/host/Kconfig|6 +
> > drivers/usb/host/ohci-hcd.c |5 +
> > drivers/usb/host/ohci-s5p.c | 273
> > +++
> > 4 files changed, 285 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/usb/host/ohci-s5p.c
> >
>
> (snip)
>
> > +#ifdef CONFIG_PM
> > +static int s5p_ohci_suspend(struct device *dev)
> > +{
> > + struct s5p_ohci_hcd *s5p_ohci = dev_get_drvdata(dev);
> > + struct usb_hcd *hcd = s5p_ohci->hcd;
> > + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct s5p_ohci_platdata *pdata = pdev->dev.platform_data;
> > + unsigned long flags;
> > + int rc = 0;
> > +
> > + /* Root hub was already suspended. Disable irq emission and
> > +* mark HW unaccessible, bail out if RH has been resumed. Use
> > +* the spinlock to properly synchronize with possible pending
> > +* RH suspend or resume activity.
> > +*
> > +* This is still racy as hcd->state is manipulated outside of
> > +* any locks =P But that will be a different fix.
> > +*/
> > + spin_lock_irqsave(&ohci->lock, flags);
> > + if (hcd->state != HC_STATE_SUSPENDED && hcd->state != HC_STATE_HALT)
> > {
> > + rc = -EINVAL;
> > + goto fail;
> > + }
> > +
> > + clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> > +
> > + if (pdata && pdata->phy_exit)
> > + pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
>
> Since ohci and echi share the code for control of phy, this can make a
> problem when this is used by module or doing suspend-to-resume. So need to
> sort it out.
OK, I will fix phy control function.
>
> And how about to use ohci-exynos instead of ohci-s5p? As you know, this
> can/will be used on EXYNOS SoCs.
OK, I will use ohci-exynos.
Thanks.
>
> Others, ok to me. If you address comments from me, you can add my ack.
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 2/3] ARM: mach-shmobile: Use common always on power domain governor
Hi,
On Thursday, December 01, 2011, Mark Brown wrote:
> Saves a tiny amount of code.
How so?
> Signed-off-by: Mark Brown
> ---
> arch/arm/mach-shmobile/pm-sh7372.c | 43 +--
> 1 files changed, 2 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c
> b/arch/arm/mach-shmobile/pm-sh7372.c
> index adf1765..5f7d575 100644
> --- a/arch/arm/mach-shmobile/pm-sh7372.c
> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -162,45 +162,6 @@ static bool pd_active_wakeup(struct device *dev)
> return active_wakeup ? active_wakeup(dev) : true;
> }
>
> -static bool sh7372_power_down_forbidden(struct dev_pm_domain *domain)
> -{
> - return false;
> -}
> -
> -struct dev_power_governor sh7372_always_on_gov = {
> - .power_down_ok = sh7372_power_down_forbidden,
> - .stop_ok = default_stop_ok,
> -};
> -
> -static int sh7372_stop_dev(struct device *dev)
> -{
> - int (*stop)(struct device *dev);
> -
> - stop = dev_gpd_data(dev)->ops.stop;
> - if (stop) {
> - int ret = stop(dev);
> - if (ret)
> - return ret;
> - }
> - return pm_clk_suspend(dev);
> -}
> -
> -static int sh7372_start_dev(struct device *dev)
> -{
> - int (*start)(struct device *dev);
> - int ret;
> -
> - ret = pm_clk_resume(dev);
> - if (ret)
> - return ret;
> -
> - start = dev_gpd_data(dev)->ops.start;
> - if (start)
> - ret = start(dev);
> -
> - return ret;
> -}
> -
The above functions are actually necessary, please don't remove them
without introducing replacements.
> void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd)
> {
> struct generic_pm_domain *genpd = &sh7372_pd->genpd;
> @@ -246,7 +207,7 @@ struct sh7372_pm_domain sh7372_d4 = {
>
> struct sh7372_pm_domain sh7372_a4r = {
> .bit_shift = 5,
> - .gov = &sh7372_always_on_gov,
> + .gov = &pm_domain_always_on_gov,
> .suspend = sh7372_a4r_suspend,
> .resume = sh7372_intcs_resume,
> .stay_on = true,
> @@ -262,7 +223,7 @@ struct sh7372_pm_domain sh7372_a3ri = {
>
> struct sh7372_pm_domain sh7372_a3sp = {
> .bit_shift = 11,
> - .gov = &sh7372_always_on_gov,
> + .gov = &pm_domain_always_on_gov,
> .no_debug = true,
> };
Thanks,
Rafael
--
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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Thu, Dec 01, 2011 at 04:29:17PM +0900, Kukjin Kim wrote: > Anyway, that touches many Samsung stuff so it would be better if you could > create separate topic branch which can be merged into Samsung tree. And if > required, please add my ack on them. Yes, I use topic-branches a lot :) This will end up in iommu/exynos or something like that. Joerg -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
The S3C64xx SoCs contain a set of gateable power domains which can be
enabled and disabled at runtime in order to save power. Use the generic
power domain code to implement support for these in software, enabling
runtime control of most domains:
- ETM (not supported in mainline).
- Domain G: 3D acceleration (no mainline support).
- Domain V: MFC (no mainline support).
- Domain I: JPEG and camera interface (no mainline support).
- Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
- Domain S: Security (no mainline support).
- Domain F: LCD (driver already uses runtime PM), post processing and
rotation (no mainline support).
The IROM domain is marked as always enabled as we should arrange for it
to be enabled when we suspend which will need a bit more work.
Due to all the conditional device registration that the platform does
wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
into the power domain after the machines have registered, looking for
platform data to tell if the device was registered. Since currently only
Cragganmore actually sets up PM that is the only machine updated.
Signed-off-by: Mark Brown
---
Kikjin, this superceeds my previous patch unconditionally disabling some
of the domains. I've given it quite a bit of testing and it appears to
be working well on my systems though I'm not sure the power saving is
really all that much to write home about.
arch/arm/mach-s3c64xx/Kconfig |1 +
arch/arm/mach-s3c64xx/mach-crag6410.c |2 +-
arch/arm/mach-s3c64xx/pm.c | 173 ++-
arch/arm/plat-samsung/include/plat/pm.h |6 +
4 files changed, 179 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 4d8c489..5c6c22e 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -8,6 +8,7 @@ config PLAT_S3C64XX
bool
depends on ARCH_S3C64XX
select SAMSUNG_WAKEMASK
+ select PM_GENERIC_DOMAINS
default y
help
Base platform code for any Samsung S3C64XX device
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 98d42b3..4ce4a74 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -743,7 +743,7 @@ static void __init crag6410_machine_init(void)
regulator_has_full_constraints();
- s3c_pm_init();
+ s3c64xx_pm_init();
}
MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index b375cd5..aa7b5d1 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -17,10 +17,12 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -31,6 +33,145 @@
#include
#include
+struct s3c64xx_pm_domain {
+ char *const name;
+ u32 ena;
+ u32 pwr_stat;
+ struct generic_pm_domain pd;
+};
+
+static int s3c64xx_pd_off(struct generic_pm_domain *domain)
+{
+ struct s3c64xx_pm_domain *pd;
+ u32 val;
+
+ pd = container_of(domain, struct s3c64xx_pm_domain, pd);
+
+ val = __raw_readl(S3C64XX_NORMAL_CFG);
+ val &= ~(pd->ena);
+ __raw_writel(val, S3C64XX_NORMAL_CFG);
+
+ return 0;
+}
+
+static int s3c64xx_pd_on(struct generic_pm_domain *domain)
+{
+ struct s3c64xx_pm_domain *pd;
+ u32 val;
+ long retry = 100L;
+
+ pd = container_of(domain, struct s3c64xx_pm_domain, pd);
+
+ val = __raw_readl(S3C64XX_NORMAL_CFG);
+ val |= pd->ena;
+ __raw_writel(val, S3C64XX_NORMAL_CFG);
+
+ /* Not all domains provide power status readback */
+ if (pd->pwr_stat) {
+ while (retry--)
+ if (__raw_readl(S3C64XX_BLK_PWR_STAT) & pd->pwr_stat)
+ break;
+ if (!retry) {
+ pr_err("Failed to start domain %s\n", pd->name);
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
+ .name = "IROM",
+ .ena = S3C64XX_NORMALCFG_IROM_ON,
+ .pd = {
+ .power_off = s3c64xx_pd_off,
+ .power_on = s3c64xx_pd_on,
+ },
+};
+
+static struct s3c64xx_pm_domain s3c64xx_pm_etm = {
+ .name = "ETM",
+ .ena = S3C64XX_NORMALCFG_DOMAIN_ETM_ON,
+ .pwr_stat = S3C64XX_BLKPWRSTAT_ETM,
+ .pd = {
+ .power_off = s3c64xx_pd_off,
+ .power_on = s3c64xx_pd_on,
+ },
+};
+
+static struct s3c64xx_pm_domain s3c64xx_pm_s = {
+ .name = "S",
+ .ena = S3C64XX_NORMALCFG_DOMAIN_S_ON,
+ .pwr_stat = S3C64XX_BLKPWRSTAT_S,
+ .pd = {
+ .power_off = s3c64xx_pd_off,
+ .power_on = s3c64xx_pd_on,
+ },
+};
+
+static struct s3c64xx_pm_domain s3c
[PATCH 2/3] ARM: mach-shmobile: Use common always on power domain governor
Saves a tiny amount of code.
Signed-off-by: Mark Brown
---
arch/arm/mach-shmobile/pm-sh7372.c | 43 +--
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-sh7372.c
b/arch/arm/mach-shmobile/pm-sh7372.c
index adf1765..5f7d575 100644
--- a/arch/arm/mach-shmobile/pm-sh7372.c
+++ b/arch/arm/mach-shmobile/pm-sh7372.c
@@ -162,45 +162,6 @@ static bool pd_active_wakeup(struct device *dev)
return active_wakeup ? active_wakeup(dev) : true;
}
-static bool sh7372_power_down_forbidden(struct dev_pm_domain *domain)
-{
- return false;
-}
-
-struct dev_power_governor sh7372_always_on_gov = {
- .power_down_ok = sh7372_power_down_forbidden,
- .stop_ok = default_stop_ok,
-};
-
-static int sh7372_stop_dev(struct device *dev)
-{
- int (*stop)(struct device *dev);
-
- stop = dev_gpd_data(dev)->ops.stop;
- if (stop) {
- int ret = stop(dev);
- if (ret)
- return ret;
- }
- return pm_clk_suspend(dev);
-}
-
-static int sh7372_start_dev(struct device *dev)
-{
- int (*start)(struct device *dev);
- int ret;
-
- ret = pm_clk_resume(dev);
- if (ret)
- return ret;
-
- start = dev_gpd_data(dev)->ops.start;
- if (start)
- ret = start(dev);
-
- return ret;
-}
-
void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd)
{
struct generic_pm_domain *genpd = &sh7372_pd->genpd;
@@ -246,7 +207,7 @@ struct sh7372_pm_domain sh7372_d4 = {
struct sh7372_pm_domain sh7372_a4r = {
.bit_shift = 5,
- .gov = &sh7372_always_on_gov,
+ .gov = &pm_domain_always_on_gov,
.suspend = sh7372_a4r_suspend,
.resume = sh7372_intcs_resume,
.stay_on = true,
@@ -262,7 +223,7 @@ struct sh7372_pm_domain sh7372_a3ri = {
struct sh7372_pm_domain sh7372_a3sp = {
.bit_shift = 11,
- .gov = &sh7372_always_on_gov,
+ .gov = &pm_domain_always_on_gov,
.no_debug = true,
};
--
1.7.7.3
--
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 1/3] PM: Provide an always on power domain governor
Since systems are likely to have power domains that can't be turned off
for various reasons at least temporarily while implementing power domain
support provide a default governor which will always refuse to power off
the domain, saving platforms having to implement their own.
Since the code is so tiny don't bother with a Kconfig symbol for it.
Signed-off-by: Mark Brown
---
drivers/base/power/domain_governor.c | 13 +
include/linux/pm_domain.h|2 ++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/base/power/domain_governor.c
b/drivers/base/power/domain_governor.c
index da78540..51527ee 100644
--- a/drivers/base/power/domain_governor.c
+++ b/drivers/base/power/domain_governor.c
@@ -141,3 +141,16 @@ struct dev_power_governor simple_qos_governor = {
.stop_ok = default_stop_ok,
.power_down_ok = default_power_down_ok,
};
+
+static bool always_on_power_down_ok(struct dev_pm_domain *domain)
+{
+ return false;
+}
+
+/**
+ * pm_genpd_gov_always_on - A governor implementing an always-on policy
+ */
+struct dev_power_governor pm_domain_always_on_gov = {
+ .power_down_ok = always_on_power_down_ok,
+ .stop_ok = default_stop_ok,
+};
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index fbb81bc..fda14f1 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -139,6 +139,7 @@ extern int pm_genpd_poweron(struct generic_pm_domain
*genpd);
extern bool default_stop_ok(struct device *dev);
+extern struct dev_power_governor pm_domain_always_on_gov;
#else
static inline struct generic_pm_domain *dev_to_genpd(struct device *dev)
@@ -192,6 +193,7 @@ static inline bool default_stop_ok(struct device *dev)
{
return false;
}
+#define pm_domain_always_on_gov NULL
#endif
static inline int pm_genpd_remove_callbacks(struct device *dev)
--
1.7.7.3
--
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
> -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
> 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
> >> 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-soc@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
> >> >> Signed-off-by: Girish K S
> >> >> ---
> >> >> Changes in v5:
> >> >> Reduced the case statements for better code readability.
> >> Removed
> >> >> unused macro definitions. Modified the tuning function
> >> prototype
> >> >> and definition to support tuning for both SD and eMMC
> cards.
> >> >> Changes in v4:
> >> >> Rebased onto chris-mmc/mmc-next branch. This patch is
> >> >> successfully
> >> >> applied on commit with id
> >> >> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
> >> >> Changes in v3:
> >> >> In the previous commits of chris-mmc/mmc-next branch, the
> >> patch
> >> >> with
> >> >> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9)
> defines
> >> >> caps2 for
> >> >> more capabilities. This patch version deletes the member
> >> >> ext_caps(created
> >> >> in my earlier patch) from struct mmc_host and reuses
> already
> >> >> accepted
> >> >> caps2 member.
> >> >> Changes in v2:
> >> >> Rebased to latest chris-mmc/mmc-next branch. Resolved
> >> indentation
> >> >> problems identified in review. This patch has to be applied
> >> >> before
> >> >> the patch released for modifying the printk messages.
> >> >> Changes in v1:
> >> >> Case statements in switch that produce same result have
> >> >> been combined to reduce repeated assignments.
> >> >> patch recreated after rebase to chris balls mmc-next
> branch.
> >> >>
> >> >> drivers/mmc/core/bus.c | 3 +-
> >> >> drivers/mmc/core/mmc.c | 77
> >> >>
> >> >> drivers/mmc/core/sd.c | 3 +-
> >> >> drivers/mmc/core/sdio.c | 4 ++-
> >> >> drivers/mmc/host/sdhci.c | 38 +-
> >> >> include/linux/mmc/card.h | 3 ++
> >> >> include/linux/mmc/host.h | 11 ++-
> >> >> include/linux/mmc/mmc.h | 66
> >> >> ++-
> >> >> include/linux/mmc/sdhci.h | 1 +
> >> >> 9 files changed, 185 insertions(+), 21 deletions(-)
> >> >>
> >> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> >> >> index 5639fdf..83c9f8d 100644
> >> >> --- a/drivers/mmc/core/bus.c
> >> >> +++ b/drivers/mmc/core/bus.c
> >> >> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> >> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> >> type);
> >> >> } else {
> >> >> - printk(KERN_INFO "%s: new %s%s%s card at address
> >> %04x\n",
> >> >> + pr_info("%s: new %s%s%s%s card at address %04x\n",
> >> >> mmc_hostname(card->host),
> >> >> mmc_card_uhs(card) ? "ultra high speed " :
> >> >> (mmc_card_highspeed(card) ? "high speed " :
> >> ""),
> >> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
> >> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> >> type, card->rca);
> >> >> }
> >> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> >> >> index a1223bd..f4124d6 100644
> >> >> --- a/drivers/mm
Re: [PATCH 1/2] ARM: exynos4: Fix build error due to 'gic_bank_offset' undeclared
On 01/12/11 15:24, Axel Lin wrote:
> Fix below build error:
> CC arch/arm/mach-exynos/cpu.o
> arch/arm/mach-exynos/cpu.c: In function 'exynos4_init_irq':
> arch/arm/mach-exynos/cpu.c:245: error: 'gic_bank_offset' undeclared (first
> use in this function)
> arch/arm/mach-exynos/cpu.c:245: error: (Each undeclared identifier is
> reported only once
> arch/arm/mach-exynos/cpu.c:245: error: for each function it appears in.)
> arch/arm/mach-exynos/cpu.c:243: warning: unused variable 'bank_offset'
> make[1]: *** [arch/arm/mach-exynos/cpu.o] Error 1
> make: *** [arch/arm/mach-exynos] Error 2
>
> Signed-off-by: Axel Lin
Arghhh... My bad. Thanks for fixing that.
Acked-by: Marc Zyngier
> ---
> arch/arm/mach-exynos/cpu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index fed62f4..c7cb462 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -240,7 +240,7 @@ static const struct of_device_id exynos4_dt_irq_match[] =
> {
> void __init exynos4_init_irq(void)
> {
> int irq;
> - unsigned int bank_offset;
> + unsigned int gic_bank_offset;
>
> gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
>
--
Jazz is not dead. It just smells funny...
--
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 2/2] ARM: exynos4: Fix build error
Trivial fix to fix below build error:
CC arch/arm/mach-exynos/mach-universal_c210.o
arch/arm/mach-exynos/mach-universal_c210.c:24: error: expected identifier or
'(' before '<' token
Signed-off-by: Axel Lin
---
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 48e85b0..cfc7d50 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -21,7 +21,7 @@
#include
#include
#include
-
+#include
#include
#include
--
1.7.5.4
--
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 1/2] ARM: exynos4: Fix build error due to 'gic_bank_offset' undeclared
Fix below build error:
CC arch/arm/mach-exynos/cpu.o
arch/arm/mach-exynos/cpu.c: In function 'exynos4_init_irq':
arch/arm/mach-exynos/cpu.c:245: error: 'gic_bank_offset' undeclared (first use
in this function)
arch/arm/mach-exynos/cpu.c:245: error: (Each undeclared identifier is reported
only once
arch/arm/mach-exynos/cpu.c:245: error: for each function it appears in.)
arch/arm/mach-exynos/cpu.c:243: warning: unused variable 'bank_offset'
make[1]: *** [arch/arm/mach-exynos/cpu.o] Error 1
make: *** [arch/arm/mach-exynos] Error 2
Signed-off-by: Axel Lin
---
arch/arm/mach-exynos/cpu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index fed62f4..c7cb462 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -240,7 +240,7 @@ static const struct of_device_id exynos4_dt_irq_match[] = {
void __init exynos4_init_irq(void)
{
int irq;
- unsigned int bank_offset;
+ unsigned int gic_bank_offset;
gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
--
1.7.5.4
--
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] ARM: exynos4: Fix for stall in case of cpu hotplug or sleep
On Thu, Dec 1, 2011 at 4:05 PM, Kukjin Kim wrote:
> Amit Daniel Kachhap wrote:
>>
>> This patch adds remove_irq in place of disable_irq which is
>> correct equivalent function for setup_irq used in
>> exynos4_mct_tick_init.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> Tested-by: Inderpal Singh
>> ---
>> arch/arm/mach-exynos/mct.c | 6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
>> index 97343df..959f251 100644
>> --- a/arch/arm/mach-exynos/mct.c
>> +++ b/arch/arm/mach-exynos/mct.c
>> @@ -428,9 +428,13 @@ int __cpuinit local_timer_setup(struct
>> clock_event_device *evt)
>>
>> void local_timer_stop(struct clock_event_device *evt)
>> {
>> + unsigned int cpu = smp_processor_id();
>> evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
>> if (mct_int_type == MCT_INT_SPI)
>> - disable_irq(evt->irq);
>> + if (cpu == 0)
>> + remove_irq(evt->irq, &mct_tick0_event_irq);
>> + else
>> + remove_irq(evt->irq, &mct_tick1_event_irq);
>
> Hmm, how about the cpu number is 2 or 3 on Quad-core?
> As you know, this should be used for all of EXYNOS SoCs.
This code change is specific for EXYNOS4210 where the MCT irq is SPI
type. Other exynos soc's (4412 etc) are not effected by this change.
I am adding the cpu stall log currently caused during cpu1 hotplug or
sleep/wakeup sequence. This commit fixes this.
root@localhost:~# echo 1 > /sys/devices/system/cpu/cpu1/online
CPU1: Booted secondary processor
Calibrating delay loop (skipped) already calibrated this CPU
CPU1: Unknown IPI message 0x1
INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0,
t=12002 jiffies)
[] (unwind_backtrace+0x0/0xfc) from []
(__rcu_pending+0x45c/0x4d8)
[] (__rcu_pending+0x45c/0x4d8) from []
(rcu_check_callbacks+0xb0/0x210)
[] (rcu_check_callbacks+0xb0/0x210) from []
(update_process_times+0x3c/0x50)
[] (update_process_times+0x3c/0x50) from []
(tick_sched_timer+0x94/0xd0)
[] (tick_sched_timer+0x94/0xd0) from []
(__run_hrtimer+0x44/0xd8)
[] (__run_hrtimer+0x44/0xd8) from []
(hrtimer_interrupt+0x100/0x330)
[] (hrtimer_interrupt+0x100/0x330) from []
(exynos4_mct_tick_isr+0x50/0x68)
[] (exynos4_mct_tick_isr+0x50/0x68) from []
(handle_irq_event_percpu+0x54/0x180)
[] (handle_irq_event_percpu+0x54/0x180) from []
(handle_irq_event+0x3c/0x5c)
[] (handle_irq_event+0x3c/0x5c) from []
(handle_fasteoi_irq+0x9c/0x104)
[] (handle_fasteoi_irq+0x9c/0x104) from []
(generic_handle_irq+0x34/0x3c)
[] (generic_handle_irq+0x34/0x3c) from []
(handle_IRQ+0x58/0xb8)
[] (handle_IRQ+0x58/0xb8) from [] (__irq_svc+0x6c/0xe8)
[] (__irq_svc+0x6c/0xe8) from []
(exynos4_enter_idle+0x2c/0x60)
[] (exynos4_enter_idle+0x2c/0x60) from []
(cpuidle_idle_call+0xb8/0x12c)
[] (cpuidle_idle_call+0xb8/0x12c) from []
(cpu_idle+0xac/0xf4)
[] (cpu_idle+0xac/0xf4) from [] (start_kernel+0x36c/0x378)
INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0,
t=12002 jiffies)
[] (unwind_backtrace+0x0/0xfc) from []
(__rcu_pending+0x45c/0x4d8)
[] (__rcu_pending+0x45c/0x4d8) from []
(rcu_check_callbacks+0x14c/0x210)
[] (rcu_check_callbacks+0x14c/0x210) from []
(update_process_times+0x3c/0x50)
[] (update_process_times+0x3c/0x50) from []
(tick_sched_timer+0x94/0xd0)
[] (tick_sched_timer+0x94/0xd0) from []
(__run_hrtimer+0x44/0xd8)
[] (__run_hrtimer+0x44/0xd8) from []
(hrtimer_interrupt+0x100/0x330)
[] (hrtimer_interrupt+0x100/0x330) from []
(exynos4_mct_tick_isr+0x50/0x68)
[] (exynos4_mct_tick_isr+0x50/0x68) from []
(handle_irq_event_percpu+0x54/0x180)
[] (handle_irq_event_percpu+0x54/0x180) from []
(handle_irq_event+0x3c/0x5c)
[] (handle_irq_event+0x3c/0x5c) from []
(handle_fasteoi_irq+0x9c/0x104)
[] (handle_fasteoi_irq+0x9c/0x104) from []
(generic_handle_irq+0x34/0x3c)
[] (generic_handle_irq+0x34/0x3c) from []
(handle_IRQ+0x58/0xb8)
[] (handle_IRQ+0x58/0xb8) from [] (__irq_svc+0x6c/0xe8)
[] (__irq_svc+0x6c/0xe8) from []
(exynos4_enter_idle+0x2c/0x60)
[] (exynos4_enter_idle+0x2c/0x60) from []
(cpuidle_idle_call+0xb8/0x12c)
[] (cpuidle_idle_call+0xb8/0x12c) from []
(cpu_idle+0xac/0xf4)
[] (cpu_idle+0xac/0xf4) from [] (start_kernel+0x36c/0x378)
Thanks,
Amit Daniel
>
>> else
>> disable_percpu_irq(IRQ_MCT_LOCALTIMER);
>> }
>> --
>> 1.7.1
>
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> 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
Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
On 1 December 2011 16:27, Subhash Jadavani 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
>> 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-soc@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
>> >> Signed-off-by: Girish K S
>> >> ---
>> >> Changes in v5:
>> >> Reduced the case statements for better code readability.
>> Removed
>> >> unused macro definitions. Modified the tuning function
>> prototype
>> >> and definition to support tuning for both SD and eMMC cards.
>> >> Changes in v4:
>> >> Rebased onto chris-mmc/mmc-next branch. This patch is
>> >> successfully
>> >> applied on commit with id
>> >> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
>> >> Changes in v3:
>> >> In the previous commits of chris-mmc/mmc-next branch, the
>> patch
>> >> with
>> >> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
>> >> caps2 for
>> >> more capabilities. This patch version deletes the member
>> >> ext_caps(created
>> >> in my earlier patch) from struct mmc_host and reuses already
>> >> accepted
>> >> caps2 member.
>> >> Changes in v2:
>> >> Rebased to latest chris-mmc/mmc-next branch. Resolved
>> indentation
>> >> problems identified in review. This patch has to be applied
>> >> before
>> >> the patch released for modifying the printk messages.
>> >> Changes in v1:
>> >> Case statements in switch that produce same result have
>> >> been combined to reduce repeated assignments.
>> >> patch recreated after rebase to chris balls mmc-next branch.
>> >>
>> >> drivers/mmc/core/bus.c | 3 +-
>> >> drivers/mmc/core/mmc.c | 77
>> >>
>> >> drivers/mmc/core/sd.c | 3 +-
>> >> drivers/mmc/core/sdio.c | 4 ++-
>> >> drivers/mmc/host/sdhci.c | 38 +-
>> >> include/linux/mmc/card.h | 3 ++
>> >> include/linux/mmc/host.h | 11 ++-
>> >> include/linux/mmc/mmc.h | 66
>> >> ++-
>> >> include/linux/mmc/sdhci.h | 1 +
>> >> 9 files changed, 185 insertions(+), 21 deletions(-)
>> >>
>> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> >> index 5639fdf..83c9f8d 100644
>> >> --- a/drivers/mmc/core/bus.c
>> >> +++ b/drivers/mmc/core/bus.c
>> >> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
>> >> mmc_card_ddr_mode(card) ? "DDR " : "",
>> >> type);
>> >> } else {
>> >> - printk(KERN_INFO "%s: new %s%s%s card at address
>> %04x\n",
>> >> + pr_info("%s: new %s%s%s%s card at address %04x\n",
>> >> mmc_hostname(card->host),
>> >> mmc_card_uhs(card) ? "ultra high speed " :
>> >> (mmc_card_highspeed(card) ? "high speed " :
>> ""),
>> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
>> >> mmc_card_ddr_mode(card) ? "DDR " : "",
>> >> type, card->rca);
>> >> }
>> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> >> index a1223bd..f4124d6 100644
>> >> --- a/drivers/mmc/core/mmc.c
>> >> +++ b/drivers/mmc/core/mmc.c
>> >> @@ -285,6 +285,27 @@ static int mmc_read_ext_csd(struct mmc_card
>> *card,
>> >> u8 *ext_csd)
>> >> }
>> >> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>> >> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
>> >> + case EXT_CSD_CARD_TYPE_SDR_ALL:
>> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
>> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
>> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
>> >> + card->ext_csd.hs_max_dtr = 2;
>> >> + card->ext_csd.card_type =
Re: s3c2440 / s3c2416 broken
I found the problem it was a merging error when I rebased my patch for my RS485 addition to the UART driver. I am however still having issues with the frame buffer displaying horizontal doted lines that shift the next pixels down by a number of pixels when certain colors are displayed. Thanks, Paul On Thu, Dec 1, 2011 at 1:30 AM, Kukjin Kim wrote: > > Thomas Abraham wrote: > > > > Hi Paul, > > > > On 10 November 2011 21:27, Paul Schilling > > wrote: > > > Here is my boot log including some u-boot stuff. The trace in my boot > > > log is concerning a > > > still broken GPIO bank M access that appears broken. > > > > Thanks for the log. But I could find out the cause of this issue. I > > will check again tomorrow with linux-3.2.0-rc1 on smdk2416. Any luck > > when using ramdisk or any clue with git bisect? > > > > Hi Paul, > > The problem still happens on your board now? > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > > > > > > Thanks, > > > Paul Schilling > > > > > > dm9000 i/o: 0x2300, id: 0x9a46 > > > > > > DM9000: running in 16 bit mode > > > > > > MAC: 12:23:34:88:99:00 > > > > > > BOOTP broadcast 1 > > > > > > BOOTP broadcast 2 > > > > > > BOOTP broadcast 3 > > > > > > DHCP client bound to address 10.5.16.68 > > > > > > TFTP from server 10.5.16.63; our IP address is 10.5.16.68 > > > > > > Filename 'schilpa/uImage-dev.bin'. > > > > > > Load address: 0xc0008000 > > > > > > Loading: * > > # > > > > > > > # > > > > > > > # > > > > > > > # > > > > > > > # > > > > > > > # > > > > > > > # > > > > > > ## > > > > > > done > > > > > > Bytes transferred = 2501760 (0x262c80) > > > > > > get_format > > > > > > 1 > > > > > > ## Booting kernel from Legacy Image at c0008000 ... > > > > > > Image Name: Linux-3.2.0-rc1+ > > > > > > Created: 2011-11-09 23:23:05 UTC > > > > > > Image Type: ARM Linux Kernel Image (uncompressed) > > > > > > Data Size: 2501696 Bytes = 2.4 MB > > > > > > Load Address: 30008000 > > > > > > Entry Point: 30008000 > > > > > > Verifying Checksum ... OK > > > > > > get_format > > > > > > 1 > > > > > > Loading Kernel Image ... OK > > > > > > OK > > > > > > > > > > > > Starting kernel ... > > > > > > > > > > > > Uncompressing Linux... done, booting the kernel. > > > > > > Linux version 3.2.0-rc1+ () (gcc version 4.3.3 (GCC) ) #53 PREEMPT > > > Wed Nov 9 17:23:00 CST 2011 > > > > > > CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 > > > > > > CPU: VIVT data cache, VIVT instruction cache > > > > > > Machine: CONDOR2416 > > > > > > Memory policy: ECC disabled, Data cache writeback > > > > > > CPU S3C2416/S3C2450 (id 0x32450003) > > > > > > S3C24XX Clocks, Copyright 2004 Simtec Electronics > > > > > > CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 > > MHz > > > > > > CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz > > > > > > On node 0 totalpages: 32768 > > > > > > free_area_init_node: node 0, pgdat c050955c, node_mem_map c053e000 > > > > > > Normal zone: 384 pages used for memmap > > > > > > Normal zone: 0 pages reserved > > > > > > Normal zone: 32384 pages, LIFO batch:7 > > > > > > pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 > > > > > > pcpu-alloc: [0] 0 > > > > > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: > > 32384 > > > > > > Kernel command line: console=ttySAC0,115200 loglevel=8 > > > > > s3cfb=dev:0,depth:16,xres:480,yres:272,vslen:60,hslen:17,left:41,right:68, > > upper:26,lower:6,pixclock:0 > > > root=/dev/mtdblock4 rw rootfstype=jffs2 ethaddr=12:23:34:88:99:00 > > > > > > PID hash table entries: 512 (order: -1, 2048 bytes) > > > > > > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > > > > > > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > > > > > > Memory: 64MB 64MB = 128MB total > > > > > > Memory: 124544k/124544k available, 6528k reserved, 0K highmem > > > > > > Virtual kernel memory layout: > > > > > > vector : 0x - 0x1000 ( 4 kB) > > > > > > fixmap : 0xfff0 - 0xfffe ( 896 kB) > > > > > > vmalloc : 0xcc80 - 0xf600 ( 664 MB) > > > > > > lowmem : 0xc000 - 0xcc00 ( 192 MB) > > > > > > modules : 0xbf00 - 0xc000 ( 16 MB) > > > > > > .text : 0xc0008000 - 0xc04992b8 (4677 kB) > > > > > > .init : 0xc049a000 - 0xc04dd000 ( 268 kB) > > > > > > .data : 0xc04d
RE: [PATCH 2/2] mmc: core: Support packed command for eMMC4.5 device
> Maya Erez wrote:
>> >> >> On Wed, Nov 2, 2011 at 1:33 PM, Seungwon Jeon
>>
>> >> wrote:
>> >> >> > @@ -980,12 +988,67 @@ static int mmc_blk_err_check(struct
>> mmc_card
>> >> *card,
>> >> >> > if (!brq->data.bytes_xfered)
>> >> >> > return MMC_BLK_RETRY;
>> >> >> >
>> >> >> > + if (mq_mrq->packed_cmd != MMC_PACKED_NONE) {
>> >> >> > + if (unlikely(brq->data.blocks << 9 !=
>> >> brq->data.bytes_xfered))
>> >> >> > + return MMC_BLK_PARTIAL;
>> >> >> > + else
>> >> >> > + return MMC_BLK_SUCCESS;
>> >> >> > + }
>> >> >> > +
>> >> >> > if (blk_rq_bytes(req) != brq->data.bytes_xfered)
>> >> >> > return MMC_BLK_PARTIAL;
>> >> >> >
>> >> >> > return MMC_BLK_SUCCESS;
>> >> >> > }
>> >> >> >
>> >> >> > +static int mmc_blk_packed_err_check(struct mmc_card *card, +
>> struct mmc_async_req *areq)
>> >> >> > +{
>> >> >> > + struct mmc_queue_req *mq_mrq = container_of(areq, struct
>> >> mmc_queue_req,
>> >> >> > + mmc_active);
>> +
>> int err, check, status;
>> >> >> > + u8 ext_csd[512];
>> >> >> > +
>> >> >> > + check = mmc_blk_err_check(card, areq);
>> >> >> > +
>> >> >> > + if (check == MMC_BLK_SUCCESS)
>> >> >> > + return check;
>> I think we need to check the status for all cases and not only in case
>> of
>> MMC_BLK_PARTIAL. For example, in cases where the header was traferred
>> successfully but had logic errors (wrong number of sectors etc.)
>> mmc_blk_err_check will return MMC_BLK_SUCCESS although the packed
>> commands
>> failed.
> Similarly, Sahitya Tummala is already mentioned this.
> Other error case will be checked in next version.
> The case you suggested is about read or write?
> Device may detect error and stop transferring the data.
Sahitya suggested to also check other error cases that mmc_blk_err_check
returns (such as MMC_BLK_CMD_ERR, MMC_BLK_ECC_ERR and MMC_BLK_DATA_ERR).
I suggest to also check the exception bit in the status even if
mmc_blk_err_check returned success, since mmc_blk_err_check might not
catch all the packed commands failures. One example for such a failure is
when the header of read packed commands will have logical error.
Thanks,
Maya
--
Seny by a Consultant for Qualcomm innovation center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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: Enable MDMA driver
This patch adds MDMA platform data and enables MDMA for DMA memcpy operation
Signed-off-by: Boojin Kim
---
arch/arm/mach-exynos/clock.c |8 +
arch/arm/mach-exynos/dma.c | 35
arch/arm/mach-exynos/include/mach/irqs.h |2 +
arch/arm/mach-exynos/include/mach/map.h|3 +-
arch/arm/plat-samsung/include/plat/dma-pl330.h |8 +
5 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 5d8d483..28e2842 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -782,6 +782,13 @@ static struct clk clk_pdma1 = {
.ctrlbit= (1 << 1),
};
+static struct clk clk_mdma1 = {
+ .name = "dma",
+ .devname= "dma-pl330.2",
+ .enable = exynos4_clk_ip_image_ctrl,
+ .ctrlbit= ((1 << 8) | (1 << 5) | (1 << 2)),
+};
+
struct clk *clkset_group_list[] = {
[0] = &clk_ext_xtal_mux,
[1] = &clk_xusbxti,
@@ -1294,6 +1301,7 @@ static struct clksrc_clk *sysclks[] = {
static struct clk *clk_cdev[] = {
&clk_pdma0,
&clk_pdma1,
+ &clk_mdma1,
};
static struct clksrc_clk *clksrc_cdev[] = {
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index b10fcd2..e89329e 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -139,6 +139,38 @@ struct amba_device exynos4_device_pdma1 = {
.periphid = 0x00041330,
};
+u8 mdma_peri[] = {
+ DMACH_MTOM_0,
+ DMACH_MTOM_1,
+ DMACH_MTOM_2,
+ DMACH_MTOM_3,
+ DMACH_MTOM_4,
+ DMACH_MTOM_5,
+ DMACH_MTOM_6,
+ DMACH_MTOM_7,
+};
+
+struct dma_pl330_platdata exynos4_mdma_pdata = {
+ .nr_valid_peri = ARRAY_SIZE(mdma_peri),
+ .peri_id = mdma_peri,
+};
+
+struct amba_device exynos4_device_mdma = {
+ .dev = {
+ .init_name = "dma-pl330.2",
+ .dma_mask = &dma_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &exynos4_mdma_pdata,
+ },
+ .res = {
+ .start = EXYNOS4_PA_MDMA1,
+ .end = EXYNOS4_PA_MDMA1 + SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+ .irq = {IRQ_MDMA1, NO_IRQ},
+ .periphid = 0x00041330,
+};
+
static int __init exynos4_dma_init(void)
{
if (of_have_populated_dt())
@@ -152,6 +184,9 @@ static int __init exynos4_dma_init(void)
dma_cap_set(DMA_CYCLIC, exynos4_pdma1_pdata.cap_mask);
amba_device_register(&exynos4_device_pdma1, &iomem_resource);
+ dma_cap_set(DMA_MEMCPY, exynos4_mdma_pdata.cap_mask);
+ amba_device_register(&exynos4_device_mdma, &iomem_resource);
+
return 0;
}
arch_initcall(exynos4_dma_init);
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h
b/arch/arm/mach-exynos/include/mach/irqs.h
index 713dd52..f7d73b1 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -43,6 +43,8 @@
#define IRQ_EINT15 IRQ_SPI(31)
#define IRQ_EINT16_31 IRQ_SPI(32)
+#define IRQ_MDMA0 IRQ_SPI(33)
+#define IRQ_MDMA1 IRQ_SPI(34)
#define IRQ_PDMA0 IRQ_SPI(35)
#define IRQ_PDMA1 IRQ_SPI(36)
#define IRQ_TIMER0_VIC IRQ_SPI(37)
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 058541d..03e2c99 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -67,7 +67,8 @@
#define EXYNOS4_PA_TWD 0x10500600
#define EXYNOS4_PA_L2CC0x10502000
-#define EXYNOS4_PA_MDMA0x1081
+#define EXYNOS4_PA_MDMA0 0x1081
+#define EXYNOS4_PA_MDMA1 0x1284
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
diff --git a/arch/arm/plat-samsung/include/plat/dma-pl330.h
b/arch/arm/plat-samsung/include/plat/dma-pl330.h
index c5eaad5..ecf23a8 100644
--- a/arch/arm/plat-samsung/include/plat/dma-pl330.h
+++ b/arch/arm/plat-samsung/include/plat/dma-pl330.h
@@ -82,6 +82,14 @@ enum dma_ch {
DMACH_SLIMBUS4_TX,
DMACH_SLIMBUS5_RX,
DMACH_SLIMBUS5_TX,
+ DMACH_MTOM_0,
+ DMACH_MTOM_1,
+ DMACH_MTOM_2,
+ DMACH_MTOM_3,
+ DMACH_MTOM_4,
+ DMACH_MTOM_5,
+ DMACH_MTOM_6,
+ DMACH_MTOM_7,
/* END Marker, also used to denote a reserved channel */
DMACH_MAX,
};
--
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] ARM: S5PV210: Add USB OTG gadget device support to SMDKV210 board
This patch adds USB OTG gadget device support to SMDKV210 board,
which can support USB high-speed gadget drivers.
Signed-off-by: Jingoo Han
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-smdkv210.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 646057a..e42fbdd 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -137,6 +137,7 @@ config MACH_SMDKV210
select S3C_DEV_I2C2
select S3C_DEV_RTC
select S3C_DEV_WDT
+ select S3C_DEV_USB_HSOTG
select SAMSUNG_DEV_ADC
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_IDE
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
b/arch/arm/mach-s5pv210/mach-smdkv210.c
index a9106c3..a56ae9a 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
/* Following are default values for UCON, ULCON and UFCON UART registers */
#define SMDKV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
@@ -225,6 +226,7 @@ static struct platform_device *smdkv210_devices[]
__initdata = {
&s3c_device_rtc,
&s3c_device_ts,
&s3c_device_wdt,
+ &s3c_device_usb_hsotg,
&s5pv210_device_ac97,
&s5pv210_device_iis0,
&s5pv210_device_spdif,
@@ -308,6 +310,8 @@ static void __init smdkv210_machine_init(void)
samsung_bl_set(&smdkv210_bl_gpio_info, &smdkv210_bl_data);
+ clk_xusbxti.rate = 2400;
+
platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices));
}
--
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 V5] mmc: core: HS200 mode support for eMMC 4.5
> -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
> 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-soc@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
> >> Signed-off-by: Girish K S
> >> ---
> >> Changes in v5:
> >> Reduced the case statements for better code readability.
> Removed
> >> unused macro definitions. Modified the tuning function
> prototype
> >> and definition to support tuning for both SD and eMMC cards.
> >> Changes in v4:
> >> Rebased onto chris-mmc/mmc-next branch. This patch is
> >> successfully
> >> applied on commit with id
> >> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
> >> Changes in v3:
> >> In the previous commits of chris-mmc/mmc-next branch, the
> patch
> >> with
> >> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
> >> caps2 for
> >> more capabilities. This patch version deletes the member
> >> ext_caps(created
> >> in my earlier patch) from struct mmc_host and reuses already
> >> accepted
> >> caps2 member.
> >> Changes in v2:
> >> Rebased to latest chris-mmc/mmc-next branch. Resolved
> indentation
> >> problems identified in review. This patch has to be applied
> >> before
> >> the patch released for modifying the printk messages.
> >> Changes in v1:
> >> Case statements in switch that produce same result have
> >> been combined to reduce repeated assignments.
> >> patch recreated after rebase to chris balls mmc-next branch.
> >>
> >> drivers/mmc/core/bus.c | 3 +-
> >> drivers/mmc/core/mmc.c | 77
> >>
> >> drivers/mmc/core/sd.c | 3 +-
> >> drivers/mmc/core/sdio.c | 4 ++-
> >> drivers/mmc/host/sdhci.c | 38 +-
> >> include/linux/mmc/card.h | 3 ++
> >> include/linux/mmc/host.h | 11 ++-
> >> include/linux/mmc/mmc.h | 66
> >> ++-
> >> include/linux/mmc/sdhci.h | 1 +
> >> 9 files changed, 185 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> >> index 5639fdf..83c9f8d 100644
> >> --- a/drivers/mmc/core/bus.c
> >> +++ b/drivers/mmc/core/bus.c
> >> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> type);
> >> } else {
> >> - printk(KERN_INFO "%s: new %s%s%s card at address
> %04x\n",
> >> + pr_info("%s: new %s%s%s%s card at address %04x\n",
> >> mmc_hostname(card->host),
> >> mmc_card_uhs(card) ? "ultra high speed " :
> >> (mmc_card_highspeed(card) ? "high speed " :
> ""),
> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
> >> mmc_card_ddr_mode(card) ? "DDR " : "",
> >> type, card->rca);
> >> }
> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> >> index a1223bd..f4124d6 100644
> >> --- a/drivers/mmc/core/mmc.c
> >> +++ b/drivers/mmc/core/mmc.c
> >> @@ -285,6 +285,27 @@ static int mmc_read_ext_csd(struct mmc_card
> *card,
> >> u8 *ext_csd)
> >> }
> >> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> >> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> >> + case EXT_CSD_CARD_TYPE_SDR_ALL:
> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
> >> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
> >> + card->ext_csd.hs_max_dtr = 2;
> >> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> >> + break;
> >> + case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
> >> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
> >> + case
RE: [PATCH] ARM: exynos4: Fix for stall in case of cpu hotplug or sleep
Amit Daniel Kachhap wrote:
>
> This patch adds remove_irq in place of disable_irq which is
> correct equivalent function for setup_irq used in
> exynos4_mct_tick_init.
>
> Signed-off-by: Amit Daniel Kachhap
> Tested-by: Inderpal Singh
> ---
> arch/arm/mach-exynos/mct.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index 97343df..959f251 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -428,9 +428,13 @@ int __cpuinit local_timer_setup(struct
> clock_event_device *evt)
>
> void local_timer_stop(struct clock_event_device *evt)
> {
> + unsigned int cpu = smp_processor_id();
> evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> if (mct_int_type == MCT_INT_SPI)
> - disable_irq(evt->irq);
> + if (cpu == 0)
> + remove_irq(evt->irq, &mct_tick0_event_irq);
> + else
> + remove_irq(evt->irq, &mct_tick1_event_irq);
Hmm, how about the cpu number is 2 or 3 on Quad-core?
As you know, this should be used for all of EXYNOS SoCs.
> else
> disable_percpu_irq(IRQ_MCT_LOCALTIMER);
> }
> --
> 1.7.1
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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: [RESEND][PATCH] ARM: EXYNOS: Fixed undefined symbol compilation error.
Pankaj Dubey wrote:
>
> Many drivers will fail to compile if compiled as module due to
> undefined symbol exynos4_ioremap.
> Fix has been added by exporting the same in cpu.c file.
>
> Signed-off-by: Pankaj Dubey
> ---
> arch/arm/mach-exynos/cpu.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index 8e09f34..027f65471 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -164,6 +165,7 @@ void __iomem *exynos4_ioremap(unsigned long phy,
> size_t size, unsigned int type)
>
> return __arm_ioremap(phy, size, type);
> }
> +EXPORT_SYMBOL(exynos4_ioremap);
>
> static void exynos_idle(void)
> {
> --
> 1.7.4.1
Hi Pankaj,
As we discussed internally, since Nicolas Pitre's vmalloc patch series this
can be dropped.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 1 December 2011 15:33, Subhash Jadavani 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-soc@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
>> Signed-off-by: Girish K S
>> ---
>> Changes in v5:
>> Reduced the case statements for better code readability. Removed
>> unused macro definitions. Modified the tuning function prototype
>> and definition to support tuning for both SD and eMMC cards.
>> Changes in v4:
>> Rebased onto chris-mmc/mmc-next branch. This patch is
>> successfully
>> applied on commit with id
>> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
>> Changes in v3:
>> In the previous commits of chris-mmc/mmc-next branch, the patch
>> with
>> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
>> caps2 for
>> more capabilities. This patch version deletes the member
>> ext_caps(created
>> in my earlier patch) from struct mmc_host and reuses already
>> accepted
>> caps2 member.
>> Changes in v2:
>> Rebased to latest chris-mmc/mmc-next branch. Resolved indentation
>> problems identified in review. This patch has to be applied
>> before
>> the patch released for modifying the printk messages.
>> Changes in v1:
>> Case statements in switch that produce same result have
>> been combined to reduce repeated assignments.
>> patch recreated after rebase to chris balls mmc-next branch.
>>
>> drivers/mmc/core/bus.c | 3 +-
>> drivers/mmc/core/mmc.c | 77
>>
>> drivers/mmc/core/sd.c | 3 +-
>> drivers/mmc/core/sdio.c | 4 ++-
>> drivers/mmc/host/sdhci.c | 38 +-
>> include/linux/mmc/card.h | 3 ++
>> include/linux/mmc/host.h | 11 ++-
>> include/linux/mmc/mmc.h | 66
>> ++-
>> include/linux/mmc/sdhci.h | 1 +
>> 9 files changed, 185 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> index 5639fdf..83c9f8d 100644
>> --- a/drivers/mmc/core/bus.c
>> +++ b/drivers/mmc/core/bus.c
>> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
>> mmc_card_ddr_mode(card) ? "DDR " : "",
>> type);
>> } else {
>> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
>> + pr_info("%s: new %s%s%s%s card at address %04x\n",
>> mmc_hostname(card->host),
>> mmc_card_uhs(card) ? "ultra high speed " :
>> (mmc_card_highspeed(card) ? "high speed " : ""),
>> + (mmc_card_hs200(card) ? "HS200 " : ""),
>> mmc_card_ddr_mode(card) ? "DDR " : "",
>> type, card->rca);
>> }
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index a1223bd..f4124d6 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -285,6 +285,27 @@ static int mmc_read_ext_csd(struct mmc_card *card,
>> u8 *ext_csd)
>> }
>> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
>> + case EXT_CSD_CARD_TYPE_SDR_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
>> + card->ext_csd.hs_max_dtr = 2;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
>> + break;
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
>> + card->ext_csd.hs_max_dtr = 2;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
>> + break;
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
>> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
>> + card->ext_csd.hs_max_dtr = 2;
>> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
>> + break;
>> case EXT_CSD_C
RE: Re: [PATCH 0/3] Support Samsung S5P OHCI device and driver
Greg KH wrote: > > On Mon, Nov 21, 2011 at 11:57:16AM +, Jingoo Han wrote: > > > -Original Message- > > > From: Greg KH [mailto:g...@kroah.com] > > > Sent: Friday, November 18, 2011 4:12 AM > > > To: Jingoo Han > > > Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; > > > linux-samsung-soc@vger.kernel.org; gre...@suse.de; > > > st...@rowland.harvard.edu; kgene@samsung.com; > yulgon@samsung.com; > > > jy0922.s...@samsung.com > > > Subject: Re: [PATCH 0/3] Support Samsung S5P OHCI device and driver > > > > > > On Tue, Nov 15, 2011 at 06:49:58AM +, Jingoo Han wrote: > > > > Hello. > > > > > > > > This patch series adds USB OHCI device and initial driver for > Samsung > > > > S5P SoCs and is based from Linux 3.2-rc1. I have tested on SMDKV310 > > > board > > > > using EXYNOS4. > > > > > > This is to be sent through some arm tree, not the usb tree, right? > > Right, 1st and 2nd patch are sent throught arm tree. > > However, 3rd patch is sent through the usb tree. > > Thanks. > > [PATCH 1/3] ARM: SAMSUNG: Add USB OHCI device > > [PATCH 2/3] ARM: EXYNOS: Add USB OHCI support to SMDKV310 board > > [PATCH 3/3] USB: Add S5P OHCI diver > Hi Greg, Sorry for late response. I came back today from family vacation... Anyway, > So the third patch does not depend on the first two? If it does, that > means I will get build errors in the USB tree when I apply that patch, > right? > > If so, then all three should go through a single tree. > Yes, right. This series would be handled in same tree so that we can avoid useless conflicts. I commented small thing on 3rd patch. So I think, if you're ok on his updated patch, it can be sent to upstream via Samsung tree. Or your tree with my ack? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 3/3] USB: Add S5P OHCI diver
Jingoo Han wrote:
>
> This patch adds USB OHCI driver for Samsung S5P SoCs.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/usb/Kconfig |1 +
> drivers/usb/host/Kconfig|6 +
> drivers/usb/host/ohci-hcd.c |5 +
> drivers/usb/host/ohci-s5p.c | 273
> +++
> 4 files changed, 285 insertions(+), 0 deletions(-)
> create mode 100644 drivers/usb/host/ohci-s5p.c
>
(snip)
> +#ifdef CONFIG_PM
> +static int s5p_ohci_suspend(struct device *dev)
> +{
> + struct s5p_ohci_hcd *s5p_ohci = dev_get_drvdata(dev);
> + struct usb_hcd *hcd = s5p_ohci->hcd;
> + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + struct platform_device *pdev = to_platform_device(dev);
> + struct s5p_ohci_platdata *pdata = pdev->dev.platform_data;
> + unsigned long flags;
> + int rc = 0;
> +
> + /* Root hub was already suspended. Disable irq emission and
> + * mark HW unaccessible, bail out if RH has been resumed. Use
> + * the spinlock to properly synchronize with possible pending
> + * RH suspend or resume activity.
> + *
> + * This is still racy as hcd->state is manipulated outside of
> + * any locks =P But that will be a different fix.
> + */
> + spin_lock_irqsave(&ohci->lock, flags);
> + if (hcd->state != HC_STATE_SUSPENDED && hcd->state != HC_STATE_HALT)
> {
> + rc = -EINVAL;
> + goto fail;
> + }
> +
> + clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> +
> + if (pdata && pdata->phy_exit)
> + pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
Since ohci and echi share the code for control of phy, this can make a
problem when this is used by module or doing suspend-to-resume. So need to
sort it out.
And how about to use ohci-exynos instead of ohci-s5p? As you know, this
can/will be used on EXYNOS SoCs.
Others, ok to me. If you address comments from me, you can add my ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
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-soc@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
> Signed-off-by: Girish K S
> ---
> Changes in v5:
> Reduced the case statements for better code readability. Removed
> unused macro definitions. Modified the tuning function prototype
> and definition to support tuning for both SD and eMMC cards.
> Changes in v4:
> Rebased onto chris-mmc/mmc-next branch. This patch is
> successfully
> applied on commit with id
> de022ed3fdc14808299b2fa66dbb1ed5ab921912.
> Changes in v3:
> In the previous commits of chris-mmc/mmc-next branch, the patch
> with
> commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
> caps2 for
> more capabilities. This patch version deletes the member
> ext_caps(created
> in my earlier patch) from struct mmc_host and reuses already
> accepted
> caps2 member.
> Changes in v2:
> Rebased to latest chris-mmc/mmc-next branch. Resolved indentation
> problems identified in review. This patch has to be applied
> before
> the patch released for modifying the printk messages.
> Changes in v1:
> Case statements in switch that produce same result have
> been combined to reduce repeated assignments.
> patch recreated after rebase to chris balls mmc-next branch.
>
> drivers/mmc/core/bus.c|3 +-
> drivers/mmc/core/mmc.c| 77
>
> drivers/mmc/core/sd.c |3 +-
> drivers/mmc/core/sdio.c |4 ++-
> drivers/mmc/host/sdhci.c | 38 +-
> include/linux/mmc/card.h |3 ++
> include/linux/mmc/host.h | 11 ++-
> include/linux/mmc/mmc.h | 66
> ++-
> include/linux/mmc/sdhci.h |1 +
> 9 files changed, 185 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index 5639fdf..83c9f8d 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type);
> } else {
> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> + pr_info("%s: new %s%s%s%s card at address %04x\n",
> mmc_hostname(card->host),
> mmc_card_uhs(card) ? "ultra high speed " :
> (mmc_card_highspeed(card) ? "high speed " : ""),
> + (mmc_card_hs200(card) ? "HS200 " : ""),
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type, card->rca);
> }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index a1223bd..f4124d6 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -285,6 +285,27 @@ static int mmc_read_ext_csd(struct mmc_card *card,
> u8 *ext_csd)
> }
> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> + case EXT_CSD_CARD_TYPE_SDR_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
> + break;
> case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
>EXT_CSD_CARD_TYPE_26:
> card->ext_csd.hs_max_dtr = 5200;
> @@ -699,6 +720,7 @@ static int
[PATCH 3/4] ARM Exynos4210-Nuri: remove compiler errors
Signed-off-by: MyungJoo Ham Signed-off-by: Kyungmin Park --- arch/arm/mach-exynos/mach-nuri.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index 236bbe1..4cef1fb 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -11,6 +11,8 @@ #include #include #include +#include +#include #include #include #include -- 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 4/4] ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver.
Support varying voltages:
- GPIODVS for Buck2 is removed.
- Voltage ragne for Buck2 is widen.
Support Buck2 regulator for Exynos4210-bus devfreq driver:
- Added device name for buck2 regulator
- Added exynos4210-busfreq platform device fro Nuri board.
Signed-off-by: MyungJoo Ham
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/mach-nuri.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 4cef1fb..dc4cc1d 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -436,7 +436,7 @@ static struct regulator_consumer_supply __initdata
max8997_buck1_[] = {
REGULATOR_SUPPLY("vdd_arm", NULL), /* CPUFREQ */
};
static struct regulator_consumer_supply __initdata max8997_buck2_[] = {
- REGULATOR_SUPPLY("vdd_int", NULL), /* CPUFREQ */
+ REGULATOR_SUPPLY("vdd_int", "exynos4210-busfreq.0"), /* CPUFREQ */
};
static struct regulator_consumer_supply __initdata max8997_buck3_[] = {
REGULATOR_SUPPLY("vdd", "mali_dev.0"), /* G3D of Exynos 4 */
@@ -747,7 +747,7 @@ static struct regulator_init_data __initdata
max8997_buck2_data = {
.constraints= {
.name = "VINT_1.1V_C210",
.min_uV = 90,
- .max_uV = 110,
+ .max_uV = 120,
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
.always_on = 1,
.state_mem = {
@@ -962,7 +962,6 @@ static struct max8997_platform_data __initdata
nuri_max8997_pdata = {
.regulators = nuri_max8997_regulators,
.buck125_gpios = { EXYNOS4_GPX0(5), EXYNOS4_GPX0(6), EXYNOS4_GPL0(0) },
- .buck2_gpiodvs = true,
.buck1_voltage[0] = 135, /* 1.35V */
.buck1_voltage[1] = 130, /* 1.3V */
@@ -1244,6 +1243,11 @@ static struct s3c2410_platform_i2c nuri_i2c0_platdata
__initdata = {
.sda_delay = 200,
};
+/* DEVFREQ controlling memory/bus */
+static struct platform_device exynos4_bus_devfreq = {
+ .name = "exynos4210-busfreq",
+};
+
static struct platform_device *nuri_devices[] __initdata = {
/* Samsung Platform Devices */
&s3c_device_i2c5, /* PMIC should initialize first */
@@ -1281,6 +1285,7 @@ static struct platform_device *nuri_devices[] __initdata
= {
&nuri_max8903_device,
&cam_vdda_fixed_rdev,
&cam_8m_12v_fixed_rdev,
+ &exynos4_bus_devfreq,
};
static void __init nuri_map_io(void)
--
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 2/4] PM/Devfreq: Add Exynos4210-bus device DVFS driver.
Exynos4210-memorybus device driver add DVFS capability for
Exynos4210-Bus (memory). The driver monitors PPMU counters of memory
controllers and adjusts operating frequencies and voltages with OPP.
Dependency (CONFIG_EXYNOS_ASV):
Exynos4210 ASV driver has been posted in the mailing list; however, it
si not yet upstreamed. Although the current revision of Exynos4210 ASV
patch does not contain "CONFIG_EXYNOS_ASV", we have added the symbol
to hide the dependent from compilers for now.
However, enabling ASV is essential in most Exynos4210 chips to reduce
the power consumption of Exynos4210 because without ASV, this Devfreq
driver assumes the worst case scenario, which consumes more power.
Signed-off-by: MyungJoo Ham
Signed-off-by: Kyungmin Park
---
drivers/devfreq/Kconfig| 12 +
drivers/devfreq/Makefile |3 +
drivers/devfreq/exynos4210_memorybus.c | 636
3 files changed, 651 insertions(+), 0 deletions(-)
create mode 100644 drivers/devfreq/exynos4210_memorybus.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 8f04910..5b1b252 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -65,4 +65,16 @@ config DEVFREQ_GOV_USERSPACE
comment "DEVFREQ Drivers"
+config ARM_EXYNOS4210_MEMORYBUS_DEVFREQ
+ bool "ARM Exynos4210 Memory Bus DEVFREQ Driver"
+ depends on CPU_EXYNOS4210
+ select ARCH_HAS_OPP
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ help
+ This adds the DEVFREQ driver for Exynos4210 memory bus.
+ This driver is supposed to support busses of other Exynos4 series
+ SoCs as well; however, for now, this driver supports Exynos4210
+ only. It reads PPMU counters of memory controllers and adjusts
+ the operating frequencies and voltages with OPP support.
+
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 4564a89..f002de5 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -3,3 +3,6 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) +=
governor_simpleondemand.o
obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+
+# DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS4210_MEMORYBUS_DEVFREQ) += exynos4210_memorybus.o
diff --git a/drivers/devfreq/exynos4210_memorybus.c
b/drivers/devfreq/exynos4210_memorybus.c
new file mode 100644
index 000..b950005
--- /dev/null
+++ b/drivers/devfreq/exynos4210_memorybus.c
@@ -0,0 +1,636 @@
+/* drivers/devfreq/exynos4210_memorybus.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ * MyungJoo Ham
+ *
+ * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
+ * This version supports EXYNOS4210 only. This changes bus frequencies
+ * and vddint voltages. Exynos4412/4212 should be able to be supported
+ * with minor modifications.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Exynos4 ASV has been in the mailing list, but not upstreamed, yet. */
+#ifdef CONFIG_EXYNOS_ASV
+extern unsigned int exynos_result_of_asv;
+#endif
+
+#include
+
+#include
+
+/* Assume that the bus is saturated if the utilization is 40% */
+#define BUS_SATURATION_RATIO 40
+
+enum ppmu_counter {
+ PPMU_PMNCNT0 = 0,
+ PPMU_PMCCNT1,
+ PPMU_PMNCNT2,
+ PPMU_PMNCNT3,
+ PPMU_PMNCNT_MAX,
+};
+struct exynos4_ppmu {
+ void __iomem *hw_base;
+ unsigned int ccnt;
+ unsigned int event;
+ unsigned int count[PPMU_PMNCNT_MAX];
+ bool ccnt_overflow;
+ bool count_overflow[PPMU_PMNCNT_MAX];
+};
+
+struct busfreq_data {
+ struct device *dev;
+ struct devfreq *devfreq;
+ bool disabled;
+ struct regulator *vdd_int;
+ struct opp *curr_opp;
+ struct exynos4_ppmu dmc[2];
+ struct notifier_block pm_notifier;
+
+ struct mutex lock;
+};
+
+enum busclk_level_idx {
+ LV_0 = 0,
+ LV_1,
+ LV_2,
+ LV_END
+};
+
+struct bus_opp_table {
+ unsigned int idx;
+ unsigned long mem_clk;
+ unsigned long volt;
+};
+
+struct bus_clkdiv {
+ unsigned int index;
+ unsigned int clkdiv;
+};
+
+static struct bus_opp_table exynos4_busclk_table[] = {
+ {LV_0, 40, 115},
+ {LV_1, 267000, 105},
+ {LV_2, 133000, 1025000},
+ {0, 0, 0},
+};
+
+/* Some chips have different operating voltages */
+static unsigned int exynos4_asv_volt[][LV_END] = {
+ {115, 105, 1025000},
+ {1125000, 1025000, 100},
+ {110, 100, 975000},
+
[PATCH 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
- Add DMC1
- Enlarge address space for DMC from 4k to 64k so that PPMU registers
may be accessed.
Signed-off-by: MyungJoo Ham
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/cpu.c |7 ++-
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 90ec247..8bdcba9 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
}, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
- .length = SZ_4K,
+ .length = SZ_64K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= (unsigned long)S5P_VA_DMC1,
+ .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
+ .length = SZ_64K,
.type = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_SROMC,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 058541d..870a980 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -57,6 +57,7 @@
#define EXYNOS4_PA_KEYPAD 0x100A
#define EXYNOS4_PA_DMC00x1040
+#define EXYNOS4_PA_DMC10x1041
#define EXYNOS4_PA_COMBINER0x1044
--
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 0/4] PM/Devfreq: Exynos4210 Bus/VDD_int
This patchset adds DVFS (Dynamic Voltage and Frequency Scaling) capability to Exynos4210 memory-bus and vdd_int of the SoC. The Exynos4210 Bus Devfreq driver uses PPMU counters of memory controllers (DMC0/DMC1 of Exynos4210), and adjusts OPP based on the current load. In other to support Exynos4210-bus devfreq driver (patch 2/4), we have added patches: 1/4: Enable DMC1, Enable PPMU for DMC0/1. 3/4: Remove compiler errors in Exynos4-Nuri board (Nuri is the test board for this driver) 4/4: Add Exynos4210-bus devfreq device to Nuri board. Note that any Exynos4210 board may add this capability by adding the platform device "exynos4210-busfreq" and provide a regulator (VDD_INT) to the added device. ASV (Adaptive Supply Voltage) capability has been introduced in the ARM-kernel mailing list. However, it has not been merged, yet. Thus, the device driver (exynos4210_memorybus.c) has a symbol "CONFIG_EXYNOS4_ASV" to block ASV-related code. With support of ASV, this devfreq driver reduces power consumption futher; most Exynos4210 SoCs have lower voltage requirement than the worst case (ASV number 0) scenario. MyungJoo Ham (4): ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC. PM/Devfreq: Add Exynos4210-bus device DVFS driver. ARM Exynos4210-Nuri: remove compiler errors ARM Exynos4210-Nuri: support Exynos4210-bus Devfreq driver. arch/arm/mach-exynos/cpu.c |7 +- arch/arm/mach-exynos/include/mach/map.h |1 + arch/arm/mach-exynos/mach-nuri.c| 13 +- drivers/devfreq/Kconfig | 12 + drivers/devfreq/Makefile|3 + drivers/devfreq/exynos4210_memorybus.c | 636 +++ 6 files changed, 668 insertions(+), 4 deletions(-) create mode 100644 drivers/devfreq/exynos4210_memorybus.c -- 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
