Re: [PATCH] spi: s3c64xx: Add fix for crash in spi suspend/resume
On Wed, Nov 07, 2012 at 11:40:12AM +0530, Naveen Krishna Chatradhi wrote: From: Abhilash Kesavan a.kesa...@samsung.com The SPI driver makes a gpio_request during initialization. The requested gpios need to be populated as part of the s3c64xx_spi_driver_data so that they can be released during suspend and requested again during resume. Applied, thanks. signature.asc Description: Digital signature
[PATCH 1/1] ARM: EXYNOS: Make combiner_of_init function static
Silences the following warning:
arch/arm/mach-exynos/common.c:576:12: warning:
symbol 'combiner_of_init' was not declared. Should it be static?
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 4e577f6..5b35d71 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -573,7 +573,8 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
#ifdef CONFIG_OF
-int __init combiner_of_init(struct device_node *np, struct device_node *parent)
+static int __init combiner_of_init(struct device_node *np,
+ struct device_node *parent)
{
void __iomem *combiner_base;
--
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/1] ARM: EXYNOS: Add missing static storage class specifiers in clock-exynos5.c
Fixes the following warnings:
arch/arm/mach-exynos/clock-exynos5.c:300:19: warning:
symbol 'exynos5_clk_mout_mpll' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:475:12: warning:
symbol 'exynos5_clkset_aclk_top_list' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:480:23: warning:
symbol 'exynos5_clkset_aclk' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:494:12: warning:
symbol 'exynos5_clkset_aclk_333_166_list' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:499:23: warning:
symbol 'exynos5_clkset_aclk_333_166' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:989:12: warning:
symbol 'exynos5_clkset_group_list' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1002:23: warning:
symbol 'exynos5_clkset_group' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1218:19: warning:
symbol 'exynos5_clk_sclk_fimd1' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1499:20: warning:
symbol 'exynos5_clock_syscore_ops' was not declared. Should it be static?
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index a88e0d9..e48d7c2 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -297,7 +297,7 @@ static struct clksrc_sources exynos5_clk_src_mpll = {
.nr_sources = ARRAY_SIZE(exynos5_clk_src_mpll_list),
};
-struct clksrc_clk exynos5_clk_mout_mpll = {
+static struct clksrc_clk exynos5_clk_mout_mpll = {
.clk = {
.name = mout_mpll,
},
@@ -472,12 +472,12 @@ static struct clksrc_clk exynos5_clk_pclk_acp = {
/* Core list of CMU_TOP side */
-struct clk *exynos5_clkset_aclk_top_list[] = {
+static struct clk *exynos5_clkset_aclk_top_list[] = {
[0] = exynos5_clk_mout_mpll_user.clk,
[1] = exynos5_clk_mout_bpll_user.clk,
};
-struct clksrc_sources exynos5_clkset_aclk = {
+static struct clksrc_sources exynos5_clkset_aclk = {
.sources= exynos5_clkset_aclk_top_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_aclk_top_list),
};
@@ -491,12 +491,12 @@ static struct clksrc_clk exynos5_clk_aclk_400 = {
.reg_div = { .reg = EXYNOS5_CLKDIV_TOP0, .shift = 24, .size = 3 },
};
-struct clk *exynos5_clkset_aclk_333_166_list[] = {
+static struct clk *exynos5_clkset_aclk_333_166_list[] = {
[0] = exynos5_clk_mout_cpll.clk,
[1] = exynos5_clk_mout_mpll_user.clk,
};
-struct clksrc_sources exynos5_clkset_aclk_333_166 = {
+static struct clksrc_sources exynos5_clkset_aclk_333_166 = {
.sources= exynos5_clkset_aclk_333_166_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_aclk_333_166_list),
};
@@ -986,7 +986,7 @@ static struct clk exynos5_clk_fimd1 = {
.ctrlbit= (1 0),
};
-struct clk *exynos5_clkset_group_list[] = {
+static struct clk *exynos5_clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = NULL,
[2] = exynos5_clk_sclk_hdmi24m,
@@ -999,7 +999,7 @@ struct clk *exynos5_clkset_group_list[] = {
[9] = exynos5_clk_mout_cpll.clk,
};
-struct clksrc_sources exynos5_clkset_group = {
+static struct clksrc_sources exynos5_clkset_group = {
.sources= exynos5_clkset_group_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
@@ -1215,7 +1215,7 @@ static struct clksrc_clk exynos5_clk_sclk_spi2 = {
.reg_div = { .reg = EXYNOS5_CLKDIV_PERIC2, .shift = 8, .size = 8 },
};
-struct clksrc_clk exynos5_clk_sclk_fimd1 = {
+static struct clksrc_clk exynos5_clk_sclk_fimd1 = {
.clk= {
.name = sclk_fimd,
.devname= exynos5-fb.1,
@@ -1496,7 +1496,7 @@ static void exynos5_clock_resume(void)
#define exynos5_clock_resume NULL
#endif
-struct syscore_ops exynos5_clock_syscore_ops = {
+static struct syscore_ops exynos5_clock_syscore_ops = {
.suspend= exynos5_clock_suspend,
.resume = exynos5_clock_resume,
};
--
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] i2c: samsung: resume race fix
Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson ol...@chromium.org Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- drivers/i2c/busses/i2c-s3c2410.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index 3e0335f..dbaf920 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1134,10 +1134,10 @@ static int s3c24xx_i2c_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); - i2c-suspended = 0; clk_prepare_enable(i2c-clk); s3c24xx_i2c_init(i2c); clk_disable_unprepare(i2c-clk); + i2c-suspended = 0; return 0; } -- 1.7.9.5 -- 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] i2c: samsung: resume race fix
On Wed, 07 Nov 2012 15:58:26 +0530, Naveen Krishna Chatradhi wrote: Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. I thought that the suspend order was children first and the resume order was parent first? If this can really happen then I am afraid this is an issue for more than just i2c-s3c2410. The proposed solution is also not really satisfactory, as the i2c client will certainly still fail to resume properly (the only improvement is that now the failure is no longer silent.) Signed-off-by: Olof Johansson ol...@chromium.org Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- drivers/i2c/busses/i2c-s3c2410.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index 3e0335f..dbaf920 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1134,10 +1134,10 @@ static int s3c24xx_i2c_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); - i2c-suspended = 0; clk_prepare_enable(i2c-clk); s3c24xx_i2c_init(i2c); clk_disable_unprepare(i2c-clk); + i2c-suspended = 0; return 0; } Acked-by: Jean Delvare kh...@linux-fr.org (Not perfect but still better than before.) -- Jean Delvare -- 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: Fix the WFI instruction opcode definition.
On 6 November 2012 11:24, Kukjin Kim kgene@samsung.com wrote: BTW, if mach-exynos includes ARMv8 later?...ARMv8 platform codes will be put in the arch/arm/ or arch/arm/64/ if some platform codes share with ARMv7? Just wondering... If mach-exynos would support ARMv8 at some point, I would expect most of the code to go under various drivers/ subsystems (mfd, power etc.). I don't see any point in using opcodes. For wfi just use a macro or cpu_do_idle() (as Rob said, it does the required dsb as well). I'm also pushing for a standard hotplug.c implementation that is shared by multiple platforms and uses the power state coordination interface implemented by the firmware. -- Catalin -- 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: Make s3c_device_i2c0 always use id 0
This patch removes compatibility definitions added long time ago when
clock ids were used instead of devnames that were needed for platforms
with only one i2c controller with id -1 (some s3c24xx's).
Because currently devname field is used for matching device instances to
clocks and if no devname is provided (as in clock-s3c2412.c and
common-s3c2443.c for i2c clock, both in arch/arm/mach-s3c24xx) the clock
is being matched only by name, so s3c_device_i2c0 can always have id 0.
This patch solves the issue with i2c0 broken on boards where its the
only i2c controller used, tested on Origen.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s3c64xx/clock.c | 4
arch/arm/plat-samsung/devs.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 28041e8..0fd7417 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -138,11 +138,7 @@ static struct clk init_clocks_off[] = {
.ctrlbit= S3C_CLKCON_PCLK_TSADC,
}, {
.name = i2c,
-#ifdef CONFIG_S3C_DEV_I2C1
.devname= s3c2440-i2c.0,
-#else
- .devname= s3c2440-i2c,
-#endif
.parent = clk_p,
.enable = s3c64xx_pclk_ctrl,
.ctrlbit= S3C_CLKCON_PCLK_IIC,
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 52dfa8f..bc50b20 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -486,11 +486,7 @@ static struct resource s3c_i2c0_resource[] = {
struct platform_device s3c_device_i2c0 = {
.name = s3c2410-i2c,
-#ifdef CONFIG_S3C_DEV_I2C1
.id = 0,
-#else
- .id = -1,
-#endif
.num_resources = ARRAY_SIZE(s3c_i2c0_resource),
.resource = s3c_i2c0_resource,
};
--
1.8.0
--
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: origen: Add missing USB regulators
This patch adds missing USB OTG regulators needed for s3c-hsotg driver
to work on Origen board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-origen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index d8dc6d7..ddf6358 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -100,6 +100,8 @@ static struct regulator_consumer_supply __initdata
ldo3_consumer[] = {
REGULATOR_SUPPLY(vddcore, s5p-mipi-csis.0), /* MIPI */
REGULATOR_SUPPLY(vdd, exynos4-hdmi), /* HDMI */
REGULATOR_SUPPLY(vdd_pll, exynos4-hdmi), /* HDMI */
+ REGULATOR_SUPPLY(vusb_d, s3c-hsotg), /* OTG */
+ REGULATOR_SUPPLY(vusb_a, s3c-hsotg), /* OTG */
};
static struct regulator_consumer_supply __initdata ldo6_consumer[] = {
REGULATOR_SUPPLY(vddio, s5p-mipi-csis.0), /* MIPI */
--
1.8.0
--
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: Exynos5250: Enabling dwc3-exynos driver
Hi,
On Tue, Nov 6, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/clock-exynos5.c| 24
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
drivers/usb/Kconfig |1 +
5 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index cf6a02d..52bca54 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,6 +68,12 @@
interrupts = 0 96 0;
};
+ dwc3 {
shouldn't this be usb@1200 ??
Kept this in accordance with controller's name, similar to the change
in following:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.html
Needs to be changed ?
+ compatible = samsung,exynos-dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ };
+
rtc {
compatible = samsung,s3c6410-rtc;
reg = 0x101E 0x100;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index a88e0d9..ee094ee 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -740,6 +740,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_fsys_ctrl ,
.ctrlbit= (1 18),
}, {
+ .name = usbdrd30,
+ .parent = exynos5_clk_aclk_200.clk,
+ .enable = exynos5_clk_ip_fsys_ctrl,
+ .ctrlbit= (1 19),
+ }, {
.name = usbotg,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 7),
@@ -1004,6 +1009,16 @@ struct clksrc_sources exynos5_clkset_group = {
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
+struct clk *exynos5_clkset_usbdrd30_list[] = {
+ [0] = exynos5_clk_mout_mpll.clk,
+ [1] = exynos5_clk_mout_cpll.clk,
looks like [0] and [1] indexes are unnecessary ?!? Not sure about
mach-exynos' preferred array initialization style, though ;-)
These are in sync with code-style in mach-exynos/clock-exynos5.c
Probably this is how it is used with mach-exynos.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 4c90b51..0454b8a 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,7 @@ config USB_ARCH_HAS_EHCI
# some non-PCI HCDs implement xHCI
config USB_ARCH_HAS_XHCI
boolean
+ default y if ARCH_EXYNOS5
NAK, this should be done on your arch/arm/mach-exynos/Kconfig. Just
select USB_ARCH_HAS_XHCI.
Oops !! Sure, will move this to arch/arm/mach-exynos/Kconfig.
--
balbi
--
Thanks Regards
Vivek
--
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 1/2] USB: PHY: Add support for USB 3.0 phy for exynos5250
Hi, On Wed, Nov 7, 2012 at 5:10 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi, I have a few comments. Please see below... On 11/06/2012 04:36 PM, Vivek Gautam wrote: Adding support for USB3.0 phy for dwc3 controller on exynso5250 SOC. exynso - exynos Sure, will correct this. Signed-off-by: Vivek Gautamgautam.vi...@samsung.com --- drivers/usb/phy/samsung-usbphy.c| 337 +++ include/linux/usb/samsung_usb_phy.h |1 + 2 files changed, 338 insertions(+), 0 deletions(-) diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 3b4863d..e3b5fb1 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -167,6 +167,99 @@ #define EXYNOS5_PHY_OTG_TUNE (0x40) +/* USB 3.0: DRD */ +#define EXYNOS5_DRD_LINKSYSTEM (0x04) + +#define LINKSYSTEM_FLADJ_MASK (0x3f 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL(1 27) + +#define EXYNOS5_DRD_PHYUTMI(0x08) + +#define PHYUTMI_OTGDISABLE (1 6) +#define PHYUTMI_FORCESUSPEND (1 1) +#define PHYUTMI_FORCESLEEP (1 0) + +#define EXYNOS5_DRD_PHYPIPE(0x0C) Would be nice to put all hex numbers in lower case. Sure, will put the hex numbers in sync. + +#define EXYNOS5_DRD_PHYCLKRST (0x10) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 21) +#define PHYCLKRST_SSC_RANGE(_x)((_x) 21) + +#define PHYCLKRST_SSC_EN (1 20) +#define PHYCLKRST_REF_SSP_EN (1 19) +#define PHYCLKRST_REF_CLKDIV2 (1 18) + +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) +#define PHYCLKRST_MPLL_MULTIPLIER(_x) ((_x) 11) Is this macro-definition going to be used anywhere else except the 5 definitions below ? Is this really helpful ? In anything else than forcing you to use questionable line breaking below ? +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF \ How about simply defining it as #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF(0x19 11) ? Yes, we can write the way as suggested. Will amend this. + PHYCLKRST_MPLL_MULTIPLIER(0x19) +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF \ + PHYCLKRST_MPLL_MULTIPLIER(0x02) +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF\ + PHYCLKRST_MPLL_MULTIPLIER(0x68) +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF\ + PHYCLKRST_MPLL_MULTIPLIER(0x7d) +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF \ + PHYCLKRST_MPLL_MULTIPLIER(0x02) + +#define PHYCLKRST_FSEL_MASK(0x3f 5) +#define PHYCLKRST_FSEL(_x) ((_x) 5) Ditto. Will amend this. +#define PHYCLKRST_FSEL_PAD_100MHZ \ + PHYCLKRST_FSEL(0x27) +#define PHYCLKRST_FSEL_PAD_24MHZ \ + PHYCLKRST_FSEL(0x2a) +#define PHYCLKRST_FSEL_PAD_20MHZ \ + PHYCLKRST_FSEL(0x31) +#define PHYCLKRST_FSEL_PAD_19_2MHZ \ + PHYCLKRST_FSEL(0x38) + +#define PHYCLKRST_RETENABLEN (1 4) + +#define PHYCLKRST_REFCLKSEL_MASK (0x03 2) +#define PHYCLKRST_REFCLKSEL(_x)((_x) 2) Ditto. Will amend this. +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK \ + PHYCLKRST_REFCLKSEL(2) +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK \ + PHYCLKRST_REFCLKSEL(3) + +#define PHYCLKRST_PORTRESET(1 1) +#define PHYCLKRST_COMMONONN(1 0) + +#define EXYNOS5_DRD_PHYREG0(0x14) +#define EXYNOS5_DRD_PHYREG1(0x18) + +#define EXYNOS5_DRD_PHYPARAM0 (0x1C) + +#define PHYPARAM0_REF_USE_PAD (0x1 31) +#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f 26) +#define PHYPARAM0_REF_LOSLEVEL (0x9 26) + +#define EXYNOS5_DRD_PHYPARAM1 (0x20) + +#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f 0) +#define PHYPARAM1_PCS_TXDEEMPH (0x1C) + +#define EXYNOS5_DRD_PHYTERM(0x24) + +#define EXYNOS5_DRD_PHYTEST(0x28) + +#define PHYTEST_POWERDOWN_SSP (1 3) +#define PHYTEST_POWERDOWN_HSP (1 2) + +#define EXYNOS5_DRD_PHYADP (0x2C) + +#define EXYNOS5_DRD_PHYBATCHG (0x30) + +#define PHYBATCHG_UTMI_CLKSEL (0x1 2) + +#define EXYNOS5_DRD_PHYRESUME (0x34) +#define
Re: [PATCH] ARM: EXYNOS: origen: Add missing USB regulators
On Wednesday 07 of November 2012 14:01:19 Tomasz Figa wrote:
This patch adds missing USB OTG regulators needed for s3c-hsotg driver
to work on Origen board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-origen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c index d8dc6d7..ddf6358 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -100,6 +100,8 @@ static struct regulator_consumer_supply __initdata
ldo3_consumer[] = { REGULATOR_SUPPLY(vddcore, s5p-mipi-csis.0), /*
MIPI */
REGULATOR_SUPPLY(vdd, exynos4-hdmi), /* HDMI */
REGULATOR_SUPPLY(vdd_pll, exynos4-hdmi), /* HDMI */
+ REGULATOR_SUPPLY(vusb_d, s3c-hsotg), /* OTG */
+ REGULATOR_SUPPLY(vusb_a, s3c-hsotg), /* OTG */
};
static struct regulator_consumer_supply __initdata ldo6_consumer[] = {
REGULATOR_SUPPLY(vddio, s5p-mipi-csis.0), /* MIPI */
It's worth noting that this patch is based on board file of Origen in
Linaro tree
http://git.linaro.org/gitweb?p=landingteams/working/samsung/kernel;a=summary
branch samsung-linux-3.6-2012.10
and not confirmed with respective board schematics (although verified
working on an Origen board).
Personally I find these two consumers, which are supposed to provided with
completely different voltages, connected to a single regulator a bit
suspicious, so someone who know details of this board should ack or
correct this patch.
Best regards,
--
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform
--
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: dts: exynos4: Add support for Exynos4x12 SoCs
Hi Kgene, On Wednesday 07 of November 2012 11:26:42 Kukjin Kim wrote: Kukjin Kim wrote: Tomasz Figa wrote: This patch adds device tree sources for Exynos4x12 SoC series (currently Exynos4212 and Exynos4412) and enables mach-exynos4-dt to support these SoCs. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/boot/dts/exynos4212.dtsi | 28 arch/arm/boot/dts/exynos4412.dtsi | 28 arch/arm/boot/dts/exynos4x12.dtsi | 31 +++ arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++ 4 files changed, 89 insertions(+) create mode 100644 arch/arm/boot/dts/exynos4212.dtsi create mode 100644 arch/arm/boot/dts/exynos4412.dtsi create mode 100644 arch/arm/boot/dts/exynos4x12.dtsi Looks good to me, applied. [...] +/include/ exynos4x12-pinctrl.dtsi BTW, I think, above line should be added when exynos4x12-pinctrl patches applied. Yes, you are right. Seems like a rebase error on my side. Can you fix it or should I send a fixed version? Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Linux Platform -- 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: Exynos5250: Enabling dwc3-exynos driver
Hi,
On Wed, Nov 07, 2012 at 06:55:03PM +0530, Vivek Gautam wrote:
Hi,
On Tue, Nov 6, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/clock-exynos5.c| 24
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
drivers/usb/Kconfig |1 +
5 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index cf6a02d..52bca54 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,6 +68,12 @@
interrupts = 0 96 0;
};
+ dwc3 {
shouldn't this be usb@1200 ??
Kept this in accordance with controller's name, similar to the change
in following:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.html
Needs to be changed ?
I'll leave it to DT experts, but I was under the impression that we
should be using generic functionality names (usb, i2c, spi, uart, gpio,
etc) instead of the IP name. IP name is something more for compatible
flag.
Don't take my word for it though :-) DT experts are the ones with final
saying
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: Exynos5250: Enabling dwc3-exynos driver
Hi Vivek, Felipe,
On Wednesday 07 of November 2012 18:43:22 Felipe Balbi wrote:
Hi,
On Wed, Nov 07, 2012 at 06:55:03PM +0530, Vivek Gautam wrote:
Hi,
On Tue, Nov 6, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/clock-exynos5.c| 24
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
drivers/usb/Kconfig |1 +
5 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi index cf6a02d..52bca54 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,6 +68,12 @@
interrupts = 0 96 0;
};
+ dwc3 {
shouldn't this be usb@1200 ??
Kept this in accordance with controller's name, similar to the change
in following:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.
html
Needs to be changed ?
I'll leave it to DT experts, but I was under the impression that we
should be using generic functionality names (usb, i2c, spi, uart, gpio,
etc) instead of the IP name. IP name is something more for compatible
flag.
Don't take my word for it though :-) DT experts are the ones with final
saying
Wrt node name, as far as I am aware of, there is no strict convention of
naming nodes, but the way you suggested is better in terms of readability -
you don't have to know this particular IP to find out what it is used for.
Similar thing is with @addr in node names. I've been always adding @addr to
the name whenever the node had reg property inside (with the same address
of course), but I'm not sure if there is a strict convention here.
Best regards,
Tomasz Figa
--
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: EXYNOS: Make s3c_device_i2c0 always use id 0
On 11/07/2012 02:00 PM, Tomasz Figa wrote: This patch removes compatibility definitions added long time ago when clock ids were used instead of devnames that were needed for platforms with only one i2c controller with id -1 (some s3c24xx's). Because currently devname field is used for matching device instances to clocks and if no devname is provided (as in clock-s3c2412.c and common-s3c2443.c for i2c clock, both in arch/arm/mach-s3c24xx) the clock is being matched only by name, so s3c_device_i2c0 can always have id 0. This patch solves the issue with i2c0 broken on boards where its the only i2c controller used, tested on Origen. Signed-off-by: Tomasz Figat.f...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- 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 1/2] USB: PHY: Add support for USB 3.0 phy for exynos5250
On 11/07/2012 02:35 PM, Vivek Gautam wrote:
@@ -180,10 +273,12 @@ enum samsung_cpu_type {
/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
+ * @phy3: transceiver structure for USB 3.0
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
* @regs: usb phy register memory base
+ * @regs_phy3: usb 3.0 phy register memory base
* @ref_clk_freq: reference clock frequency selection
* @cpu_type: machine identifier
* @phy_type: It keeps track of the PHY type.
@@ -191,10 +286,12 @@ enum samsung_cpu_type {
*/
struct samsung_usbphy {
struct usb_phy phy;
+ struct usb_phy phy3;
struct samsung_usbphy_data *plat;
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*regs_phy3;
Wouldn't it be better to create a new data structure for USB 3.0
and embedding it here, rather than adding multiple fields with 3
suffix ? E.g.
struct {
void __iomem*phy_regs;
struct usb_phy phy;
} usb3;
?
Yes, thanks for suggesting. This way things will look clearer.
Will update this.
And why do you need to duplicate those fields in first place ?
I guess phy and phy3 are dependant and you can't register 2 PHYs
separately ?
Controllers like DWC3 needs two different PHYs. One of USB2 type and
one of USB3 type. So we needed to register two separate PHYs.
OK, I was just wondering if there is any dependency between those two phys
so you need to aggregate them in one struct samsung_usbphy, rather than
creating two separate struct samsung_usbphy objects for them.
+/*
+ * The function passed to the usb driver for phy initialization
+ */
static int samsung_usbphy_init(struct usb_phy *phy)
{
struct samsung_usbphy *sphy;
@@ -570,6 +872,8 @@ static int __devinit samsung_usbphy_probe(struct
platform_device *pdev)
struct device *dev =pdev-dev;
struct resource *phy_mem;
void __iomem*phy_base;
+ struct resource *phy3_mem;
+ void __iomem*phy3_base = NULL;
struct clk *clk;
int ret = 0;
@@ -618,7 +922,38 @@ static int __devinit samsung_usbphy_probe(struct
platform_device *pdev)
sphy-clk = clk;
+ if (sphy-cpu_type == TYPE_EXYNOS5250) {
+ phy3_mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!phy3_mem) {
+ dev_err(dev, %s: missing mem resource\n, __func__);
+ return -ENODEV;
+ }
+
+ phy3_base = devm_request_and_ioremap(dev, phy3_mem);
+ if (!phy3_base) {
+ dev_err(dev, %s: register mapping failed\n, __func__);
+ return -ENXIO;
+ }
+ }
+
+ sphy-regs_phy3 = phy3_base;
+ sphy-phy3.dev = sphy-dev;
+ sphy-phy3.label= samsung-usbphy3;
+ sphy-phy3.init = samsung_usbphy3_init;
+ sphy-phy3.shutdown = samsung_usbphy3_shutdown;
+
ret = usb_add_phy(sphy-phy, USB_PHY_TYPE_USB2);
+ if (ret)
+ return ret;
+
+ if (sphy-cpu_type != TYPE_EXYNOS5250) {
+ dev_warn(dev, Not a valid cpu_type for USB 3.0\n);
+ } else {
+ ret = usb_add_phy(sphy-phy3, USB_PHY_TYPE_USB3);
+ if (ret)
+ return ret;
2 redundant lines here.
Will two returns under if return not error codes ? The last return
actually returns success.
If still it needs modification, will do that.
It's up to you how you structure it. The last return returns whatever
value ret has. I can't see what is an advantage of doing something like:
if (ret)
return ret;
return ret;
--
Thanks,
Sylwester
--
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: S3C244X/S3C64XX SoC camera host interface driver questions
On 11/06/2012 10:34 PM, Andrey Gusakov wrote: Hi. Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? Work! I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h It use significantly different init sequence. Some of settings described in Application note for ov9650, some look like magic. I guess there are many ways the sensor can be configured initially. I'd like to keep this initialization sequence as thin as possible, and to move relevant settings to corresponding v4l2 controls. Then after v4l2_control_handler_setup() is called, following the initial register list write, the sensor would be configured into some known state. I realize it might be more difficult in practice than it sounds now. :-) Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works if you enable it, without additional changes to the clock handling ? Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are power domains and the camera power domain needs to be enabled for the CAMIF operation. The pm_runtime_* calls in the driver are supposed to ensure that. I wonder why it works for you without PM_RUNTIME, i.e. how comes the power domain is enabled. It is supposed to be off by default. I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? Patches adding image effect are welcome. I'm bit to busy to play with these things, other than I don't have hardware to test it. I wasn't really aware of CAMIF in s3c2450. I think a separate variant data structure would need to be defined for s3c2450. If anyone ever needs it it could be added easily. For now I'll pretend this version doesn't exist. :-) -- Regards, Sylwester -- 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: S3C24XX: Add clkdev entry for camif-upll clock
The s3c-camif driver uses camera clock conn_id for the camif-upll
(s3c244x) and camera (s3c64xx) platform clock. By adding this new
clkdev entry the platform differences are isolated from the driver.
Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com
---
arch/arm/mach-s3c24xx/clock-s3c2440.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c
b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index 4407b17..04b87ec 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -161,6 +161,7 @@ static struct clk_lookup s3c2440_clk_lookup[] = {
CLKDEV_INIT(NULL, clk_uart_baud1, s3c24xx_uclk),
CLKDEV_INIT(NULL, clk_uart_baud2, clk_p),
CLKDEV_INIT(NULL, clk_uart_baud3, s3c2440_clk_fclk_n),
+ CLKDEV_INIT(s3c2440-camif, camera, s3c2440_clk_cam_upll),
};
static int __init_refok s3c2440_clk_add(struct device *dev, struct
subsys_interface *sif)
--
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/2] ARM: S3C64XX: Statically define parent clock of the camera clock
The camera clock defined in arch/arm/mach-s3c64xx/clock.c has null
clock source mux control register as it can have only one parent
clock. In such cases there is a need to configure the parent clock
statically, otherwise s3c_set_clksrc() bails out with an error message
no parent clock specified leaving the parent clock not configured.
Define statically the parent clock so it is possible to get or set rate
of the camera clock.
Reported-by: In-Bae Jeong kukya...@gmail.com
Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com
---
arch/arm/mach-s3c64xx/clock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 28041e8..85b9cf1 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -744,6 +744,7 @@ static struct clksrc_clk clksrcs[] = {
.name = camera,
.ctrlbit= S3C_CLKCON_SCLK_CAM,
.enable = s3c64xx_sclk_ctrl,
+ .parent = clk_h2,
},
.reg_div= { .reg = S3C_CLK_DIV0, .shift = 20, .size = 4
},
.reg_src= { .reg = NULL, .shift = 0, .size = 0 },
--
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: SAMSUNG: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
On Wednesday, November 07, 2012 9:31 PM Jingoo Han wrote The correct value for VIDCON1_VSTATUS_FRONTPORCH is 3, not 0. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com According to the datasheet, 3 is right value. Acked-by: Jingoo Han jg1@samsung.com --- include/video/samsung_fimd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index 7ae6c07..263ed4b 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -82,7 +82,7 @@ #define VIDCON1_VSTATUS_VSYNC(0x0 13) #define VIDCON1_VSTATUS_BACKPORCH(0x1 13) #define VIDCON1_VSTATUS_ACTIVE (0x2 13) -#define VIDCON1_VSTATUS_FRONTPORCH (0x0 13) +#define VIDCON1_VSTATUS_FRONTPORCH (0x3 13) #define VIDCON1_VCLK_MASK(0x3 9) #define VIDCON1_VCLK_HOLD(0x0 9) #define VIDCON1_VCLK_RUN (0x1 9) -- 1.8.0 -- 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
[PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
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 0/4] thermal: Add support for interrupt based notification to thermal layer
The patch submitted by Jonghwa Lee (https://patchwork.kernel.org/patch/1683441/) adds support for interrupt based notification to thermal layer. This is a good feature but the current thermal framework needs polling/regular notification for invoking suitable cooling action. So adding 2 new thermal trend type to implement this feature. All these patches are based on thermal maintainer next tree. git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next Amit Daniel Kachhap (3): thermal: Add new thermal trend type to support quick cooling thermal: exynos: Miscellaneous fixes to support falling threshold interrupt thermal: exynos: Use the new thermal trend type for quick cooling action. Jonghwa Lee (1): Thermal: exynos: Add support for temperature falling interrupt. drivers/thermal/exynos_thermal.c | 105 +++--- drivers/thermal/step_wise.c | 19 - include/linux/platform_data/exynos_thermal.h |3 + include/linux/thermal.h |2 + 4 files changed, 80 insertions(+), 49 deletions(-) -- 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] Thermal: exynos: Add support for temperature falling interrupt.
From: Jonghwa Lee jonghwa3@samsung.com
This patch introduces using temperature falling interrupt in exynos
thermal driver. Former patch, it only use polling way to check
whether if system themperature is fallen. However, exynos SOC also
provides temperature falling interrupt way to do same things by hw.
This feature is not supported in exynos4210.
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/exynos_thermal.c | 81 +++---
include/linux/platform_data/exynos_thermal.h |3 +
2 files changed, 49 insertions(+), 35 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index 7772d16..f6667e8 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -94,6 +94,7 @@
#define SENSOR_NAME_LEN16
#define MAX_TRIP_COUNT 8
#define MAX_COOLING_DEVICE 4
+#define MAX_THRESHOLD_LEVS 4
#define ACTIVE_INTERVAL 500
#define IDLE_INTERVAL 1
@@ -125,6 +126,7 @@ struct exynos_tmu_data {
struct thermal_trip_point_conf {
int trip_val[MAX_TRIP_COUNT];
int trip_count;
+ u8 trigger_falling;
};
struct thermal_cooling_conf {
@@ -174,7 +176,8 @@ static int exynos_set_mode(struct thermal_zone_device
*thermal,
mutex_lock(th_zone-therm_dev-lock);
- if (mode == THERMAL_DEVICE_ENABLED)
+ if (mode == THERMAL_DEVICE_ENABLED
+ !th_zone-sensor_conf-trip_data.trigger_falling)
th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
else
th_zone-therm_dev-polling_delay = 0;
@@ -413,7 +416,8 @@ static void exynos_report_trigger(void)
break;
}
- if (th_zone-mode == THERMAL_DEVICE_ENABLED) {
+ if (th_zone-mode == THERMAL_DEVICE_ENABLED
+ !th_zone-sensor_conf-trip_data.trigger_falling) {
if (i 0)
th_zone-therm_dev-polling_delay = ACTIVE_INTERVAL;
else
@@ -452,7 +456,8 @@ static int exynos_register_thermal(struct
thermal_sensor_conf *sensor_conf)
th_zone-therm_dev = thermal_zone_device_register(sensor_conf-name,
EXYNOS_ZONE_COUNT, 0, NULL, exynos_dev_ops, NULL, 0,
- IDLE_INTERVAL);
+ sensor_conf-trip_data.trigger_falling ?
+ 0 : IDLE_INTERVAL);
if (IS_ERR(th_zone-therm_dev)) {
pr_err(Failed to register thermal zone device\n);
@@ -559,8 +564,9 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
{
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata = data-pdata;
- unsigned int status, trim_info, rising_threshold;
- int ret = 0, threshold_code;
+ unsigned int status, trim_info;
+ unsigned int rising_threshold = 0, falling_threshold = 0;
+ int ret = 0, threshold_code, i, trigger_levs = 0;
mutex_lock(data-lock);
clk_enable(data-clk);
@@ -585,6 +591,11 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
(data-temp_error2 != 0))
data-temp_error1 = pdata-efuse_value;
+ /* Count trigger levels to be enabled */
+ for (i = 0; i MAX_THRESHOLD_LEVS; i++)
+ if (pdata-trigger_levels[i])
+ trigger_levs++;
+
if (data-soc == SOC_ARCH_EXYNOS4210) {
/* Write temperature code for threshold */
threshold_code = temp_to_code(data, pdata-threshold);
@@ -594,44 +605,38 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
}
writeb(threshold_code,
data-base + EXYNOS4210_TMU_REG_THRESHOLD_TEMP);
-
- writeb(pdata-trigger_levels[0],
- data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL0);
- writeb(pdata-trigger_levels[1],
- data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL1);
- writeb(pdata-trigger_levels[2],
- data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL2);
- writeb(pdata-trigger_levels[3],
- data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL3);
+ for (i = 0; i trigger_levs; i++)
+ writeb(pdata-trigger_levels[i],
+ data-base + EXYNOS4210_TMU_REG_TRIG_LEVEL0 + i * 4);
writel(EXYNOS4210_TMU_INTCLEAR_VAL,
data-base + EXYNOS_TMU_REG_INTCLEAR);
} else if (data-soc == SOC_ARCH_EXYNOS) {
- /* Write temperature code for threshold */
- threshold_code = temp_to_code(data, pdata-trigger_levels[0]);
- if (threshold_code 0) {
- ret = threshold_code;
- goto out;
- }
-
[PATCH 3/4] thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
the the event that caused the interrupt.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/exynos_thermal.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c
index f6667e8..bbaff56 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -82,7 +82,7 @@
#define EXYNOS_TRIMINFO_RELOAD 0x1
#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
-#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 16)
+#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 12)
#define EXYNOS_MUX_ADDR_VALUE 6
#define EXYNOS_MUX_ADDR_SHIFT 20
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
@@ -365,12 +365,19 @@ static int exynos_get_temp(struct thermal_zone_device
*thermal,
static int exynos_get_trend(struct thermal_zone_device *thermal,
int trip, enum thermal_trend *trend)
{
- if (thermal-temperature = trip)
+ int ret = 0;
+ unsigned long trip_temp;
+
+ ret = exynos_get_trip_temp(thermal, trip, trip_temp);
+ if (ret 0)
+ return ret;
+
+ if (thermal-temperature = trip_temp)
*trend = THERMAL_TREND_RAISING;
else
*trend = THERMAL_TREND_DROPPING;
- return 0;
+ return ret;
}
/* Operation callback functions for thermal zone */
static struct thermal_zone_device_ops const exynos_dev_ops = {
@@ -704,10 +711,9 @@ static void exynos_tmu_work(struct work_struct *work)
struct exynos_tmu_data *data = container_of(work,
struct exynos_tmu_data, irq_work);
+ exynos_report_trigger();
mutex_lock(data-lock);
clk_enable(data-clk);
-
-
if (data-soc == SOC_ARCH_EXYNOS)
writel(EXYNOS_TMU_CLEAR_RISE_INT |
EXYNOS_TMU_CLEAR_FALL_INT,
@@ -715,10 +721,8 @@ static void exynos_tmu_work(struct work_struct *work)
else
writel(EXYNOS4210_TMU_INTCLEAR_VAL,
data-base + EXYNOS_TMU_REG_INTCLEAR);
-
clk_disable(data-clk);
mutex_unlock(data-lock);
- exynos_report_trigger();
enable_irq(data-irq);
}
--
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 2/4] ARM: EXYNOS: PL330 MDMA1 fix for revision 0 of Exynos4210 SOC
Bartlomiej Zolnierkiewicz wrote:
Hmm...above change and adding definition of EXYNOS_PA_S_MDMA1 address
can fix the problem you commented on EXYNOS4210 Rev0 without others?...
The problem is affecting only EXYNOS4210 Rev0 and the fix is applied only
for case when soc_is_exynos4210() samsung_rev() == EXYNOS4210_REV_0,
or did you mean something else?
Yeah, I know. I mean just adding secure mdma1 address is enough for
exynos4210 rev0.
8-
@@ -275,6 +275,9 @@ static int __init exynos_dma_init(void)
exynos_pdma1_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4210_pdma1_peri);
exynos_pdma1_pdata.peri_id = exynos4210_pdma1_peri;
+
+ if (samsung_rev() == EXYNOS4210_REV_0)
+ exynos_mdma1_device.res.start = EXYNOS4_PA_S_MDMA1;
} else if (soc_is_exynos4212() || soc_is_exynos4412()) {
exynos_pdma0_pdata.nr_valid_peri =
ARRAY_SIZE(exynos4212_pdma0_peri);
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..0abfe78 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -90,6 +90,7 @@
#define EXYNOS4_PA_MDMA0 0x1081
#define EXYNOS4_PA_MDMA1 0x1285
+#define EXYNOS4_PA_S_MDMA1 0x1284
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
#define EXYNOS5_PA_MDMA0 0x1080
8
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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] ARM: EXYNOS5: Remove wrongly placed usb2.0 PHY_CFG definition from PMU_REG
Jingoo Han wrote: On Friday, October 05, 2012 10:27 PM Vivek Gautam wrote EXYNOS5_USB_CFG macro should actually point to USB20PHY_CFG system register (base addr + 0x230). It's wrongly placed in regs-pmu. Actual register at offset 0x230 in PMU is SEQ_TRANSITION4. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com As you mentioned, this definition is wrong. So, it should be removed. Reviewed-by: Jingoo Han jg1@samsung.com Applied, thanks. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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] ARM: EXYNOS: Make s3c_device_i2c0 always use id 0
Sylwester Nawrocki wrote: On 11/07/2012 02:00 PM, Tomasz Figa wrote: This patch removes compatibility definitions added long time ago when clock ids were used instead of devnames that were needed for platforms with only one i2c controller with id -1 (some s3c24xx's). Because currently devname field is used for matching device instances to clocks and if no devname is provided (as in clock-s3c2412.c and common-s3c2443.c for i2c clock, both in arch/arm/mach-s3c24xx) the clock is being matched only by name, so s3c_device_i2c0 can always have id 0. This patch solves the issue with i2c0 broken on boards where its the only i2c controller used, tested on Origen. Signed-off-by: Tomasz Figat.f...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Applied, thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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] ARM: dts: exynos4: Add support for Exynos4x12 SoCs
Tomasz Figa wrote: [...] +/include/ exynos4x12-pinctrl.dtsi BTW, I think, above line should be added when exynos4x12-pinctrl patches applied. Yes, you are right. Seems like a rebase error on my side. Can you fix it or should I send a fixed version? I did, thanks ;-) Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, 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 1/1] ARM: EXYNOS: Make combiner_of_init function static
Sachin Kamat wrote:
Silences the following warning:
arch/arm/mach-exynos/common.c:576:12: warning:
symbol 'combiner_of_init' was not declared. Should it be static?
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 4e577f6..5b35d71 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -573,7 +573,8 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
#ifdef CONFIG_OF
-int __init combiner_of_init(struct device_node *np, struct device_node
*parent)
+static int __init combiner_of_init(struct device_node *np,
+struct device_node *parent)
{
void __iomem *combiner_base;
--
1.7.4.1
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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 1/1] ARM: EXYNOS: Add missing static storage class specifiers in clock-exynos5.c
Sachin Kamat wrote:
Fixes the following warnings:
arch/arm/mach-exynos/clock-exynos5.c:300:19: warning:
symbol 'exynos5_clk_mout_mpll' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:475:12: warning:
symbol 'exynos5_clkset_aclk_top_list' was not declared. Should it be
static?
arch/arm/mach-exynos/clock-exynos5.c:480:23: warning:
symbol 'exynos5_clkset_aclk' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:494:12: warning:
symbol 'exynos5_clkset_aclk_333_166_list' was not declared. Should it be
static?
arch/arm/mach-exynos/clock-exynos5.c:499:23: warning:
symbol 'exynos5_clkset_aclk_333_166' was not declared. Should it be
static?
arch/arm/mach-exynos/clock-exynos5.c:989:12: warning:
symbol 'exynos5_clkset_group_list' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1002:23: warning:
symbol 'exynos5_clkset_group' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1218:19: warning:
symbol 'exynos5_clk_sclk_fimd1' was not declared. Should it be static?
arch/arm/mach-exynos/clock-exynos5.c:1499:20: warning:
symbol 'exynos5_clock_syscore_ops' was not declared. Should it be static?
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-
exynos/clock-exynos5.c
index a88e0d9..e48d7c2 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -297,7 +297,7 @@ static struct clksrc_sources exynos5_clk_src_mpll = {
.nr_sources = ARRAY_SIZE(exynos5_clk_src_mpll_list),
};
-struct clksrc_clk exynos5_clk_mout_mpll = {
+static struct clksrc_clk exynos5_clk_mout_mpll = {
.clk = {
.name = mout_mpll,
},
@@ -472,12 +472,12 @@ static struct clksrc_clk exynos5_clk_pclk_acp = {
/* Core list of CMU_TOP side */
-struct clk *exynos5_clkset_aclk_top_list[] = {
+static struct clk *exynos5_clkset_aclk_top_list[] = {
[0] = exynos5_clk_mout_mpll_user.clk,
[1] = exynos5_clk_mout_bpll_user.clk,
};
-struct clksrc_sources exynos5_clkset_aclk = {
+static struct clksrc_sources exynos5_clkset_aclk = {
.sources= exynos5_clkset_aclk_top_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_aclk_top_list),
};
@@ -491,12 +491,12 @@ static struct clksrc_clk exynos5_clk_aclk_400 = {
.reg_div = { .reg = EXYNOS5_CLKDIV_TOP0, .shift = 24, .size = 3 },
};
-struct clk *exynos5_clkset_aclk_333_166_list[] = {
+static struct clk *exynos5_clkset_aclk_333_166_list[] = {
[0] = exynos5_clk_mout_cpll.clk,
[1] = exynos5_clk_mout_mpll_user.clk,
};
-struct clksrc_sources exynos5_clkset_aclk_333_166 = {
+static struct clksrc_sources exynos5_clkset_aclk_333_166 = {
.sources= exynos5_clkset_aclk_333_166_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_aclk_333_166_list),
};
@@ -986,7 +986,7 @@ static struct clk exynos5_clk_fimd1 = {
.ctrlbit= (1 0),
};
-struct clk *exynos5_clkset_group_list[] = {
+static struct clk *exynos5_clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = NULL,
[2] = exynos5_clk_sclk_hdmi24m,
@@ -999,7 +999,7 @@ struct clk *exynos5_clkset_group_list[] = {
[9] = exynos5_clk_mout_cpll.clk,
};
-struct clksrc_sources exynos5_clkset_group = {
+static struct clksrc_sources exynos5_clkset_group = {
.sources= exynos5_clkset_group_list,
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
@@ -1215,7 +1215,7 @@ static struct clksrc_clk exynos5_clk_sclk_spi2 = {
.reg_div = { .reg = EXYNOS5_CLKDIV_PERIC2, .shift = 8, .size = 8 },
};
-struct clksrc_clk exynos5_clk_sclk_fimd1 = {
+static struct clksrc_clk exynos5_clk_sclk_fimd1 = {
.clk= {
.name = sclk_fimd,
.devname= exynos5-fb.1,
@@ -1496,7 +1496,7 @@ static void exynos5_clock_resume(void)
#define exynos5_clock_resume NULL
#endif
-struct syscore_ops exynos5_clock_syscore_ops = {
+static struct syscore_ops exynos5_clock_syscore_ops = {
.suspend= exynos5_clock_suspend,
.resume = exynos5_clock_resume,
};
--
1.7.4.1
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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] ARM: Exynos5250: Enabling dwc3-exynos driver
Hi,
On Wed, Nov 7, 2012 at 10:48 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vivek, Felipe,
On Wednesday 07 of November 2012 18:43:22 Felipe Balbi wrote:
Hi,
On Wed, Nov 07, 2012 at 06:55:03PM +0530, Vivek Gautam wrote:
Hi,
On Tue, Nov 6, 2012 at 10:13 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/clock-exynos5.c| 24
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
drivers/usb/Kconfig |1 +
5 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi index cf6a02d..52bca54 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,6 +68,12 @@
interrupts = 0 96 0;
};
+ dwc3 {
shouldn't this be usb@1200 ??
Kept this in accordance with controller's name, similar to the change
in following:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.
html
Needs to be changed ?
I'll leave it to DT experts, but I was under the impression that we
should be using generic functionality names (usb, i2c, spi, uart, gpio,
etc) instead of the IP name. IP name is something more for compatible
flag.
Don't take my word for it though :-) DT experts are the ones with final
saying
Wrt node name, as far as I am aware of, there is no strict convention of
naming nodes, but the way you suggested is better in terms of readability -
you don't have to know this particular IP to find out what it is used for.
Similar thing is with @addr in node names. I've been always adding @addr to
the name whenever the node had reg property inside (with the same address
of course), but I'm not sure if there is a strict convention here.
Better to make things more readable ;-)
It will be nice that i change this to dwc3 as well as ehci and ohci in
the change:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.
Thanks for suggestions.
I shall also update the Documentation/devicetree/bindings. I missed
that here :-(
Best regards,
Tomasz Figa
--
Thanks Regards
Vivek
--
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/2] ARM: EXYNOS: change the name of USB ohci header
Jingoo Han wrote:
This patch changes the name of USB ohci header from 'usb-exynos.h'
to 'usb-ohci-exynos.h'. This is because this header file has
the platdata for only Exynos ohci.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/mach-exynos/dev-ohci.c|2 +-
arch/arm/mach-exynos/mach-origen.c |2 +-
arch/arm/mach-exynos/mach-smdkv310.c |2 +-
drivers/usb/host/ohci-exynos.c |2 +-
.../{usb-exynos.h = usb-ohci-exynos.h}|0
5 files changed, 4 insertions(+), 4 deletions(-)
rename include/linux/platform_data/{usb-exynos.h = usb-ohci-exynos.h}
(100%)
diff --git a/arch/arm/mach-exynos/dev-ohci.c b/arch/arm/mach-exynos/dev-
ohci.c
index 4244d02..d5bc129 100644
--- a/arch/arm/mach-exynos/dev-ohci.c
+++ b/arch/arm/mach-exynos/dev-ohci.c
@@ -12,7 +12,7 @@
#include linux/dma-mapping.h
#include linux/platform_device.h
-#include linux/platform_data/usb-exynos.h
+#include linux/platform_data/usb-ohci-exynos.h
#include mach/irqs.h
#include mach/map.h
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-
exynos/mach-origen.c
index c931ce1..2bbfa8e 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -26,7 +26,7 @@
#include linux/platform_data/i2c-s3c2410.h
#include linux/platform_data/s3c-hsotg.h
#include linux/platform_data/usb-ehci-s5p.h
-#include linux/platform_data/usb-exynos.h
+#include linux/platform_data/usb-ohci-exynos.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-
exynos/mach-smdkv310.c
index 063cb94..c70eaad 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -23,7 +23,7 @@
#include linux/platform_data/i2c-s3c2410.h
#include linux/platform_data/s3c-hsotg.h
#include linux/platform_data/usb-ehci-s5p.h
-#include linux/platform_data/usb-exynos.h
+#include linux/platform_data/usb-ohci-exynos.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 20a5008..acf9a4b 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -14,7 +14,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/platform_device.h
-#include linux/platform_data/usb-exynos.h
+#include linux/platform_data/usb-ohci-exynos.h
#include plat/usb-phy.h
struct exynos_ohci_hcd {
diff --git a/include/linux/platform_data/usb-exynos.h
b/include/linux/platform_data/usb-ohci-exynos.h
similarity index 100%
rename from include/linux/platform_data/usb-exynos.h
rename to include/linux/platform_data/usb-ohci-exynos.h
--
1.7.1
Looks OK to me, but I need ack from Felipe Balbi?
Felipe, are you OK on this? If so, I'd like to pick this up in my tree.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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 1/4] thermal: Add new thermal trend type to support quick cooling
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
I can write such a governor if you do not have time to.
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
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 1/4] thermal: Add new thermal trend type to support quick cooling
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
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 v2 0/2] Enable ehci and ohci devices for exynos5250
Changes from v1: - Changed the device node names from 'ehci' and 'ohci' to 'usb@1211' and 'usb@1212' as per discussion for the change 'http://www.spinics.net/lists/linux-usb/msg73993.html' - Rebased on for-next branch of linux-samsung. Vivek Gautam (2): ARM: Exynos5250: Enabling ehci-s5p driver ARM: Exynos5250: Enabling ohci-exynos driver .../devicetree/bindings/usb/exynos-usb.txt | 40 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++ arch/arm/boot/dts/exynos5250.dtsi | 12 ++ arch/arm/mach-exynos/include/mach/map.h|2 + arch/arm/mach-exynos/mach-exynos5-dt.c |4 ++ 5 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt -- 1.7.6.5 -- 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 v2 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
5 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..833f5cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos-ehci for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@1211 {
+ compatible = samsung,exynos-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 405009c..7c8064f 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -193,4 +193,8 @@
hdmi {
hpd-gpio = gpx3 7 0xf 1 3;
};
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index cf6a02d..2995445 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -238,6 +238,12 @@
#size-cells = 0;
};
+ usb@1211 {
+ compatible = samsung,exynos-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index ef4958b..9a86b99 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -197,6 +197,7 @@
#define EXYNOS4_PA_EHCI0x1258
#define EXYNOS4_PA_OHCI0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_EHCI0x1211
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ed37273..f60994e 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -86,6 +86,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
exynos5-hdmi, NULL),
OF_DEV_AUXDATA(samsung,exynos5-mixer, 0x1445,
exynos5-mixer, NULL),
+ OF_DEV_AUXDATA(samsung,exynos-ehci, EXYNOS5_PA_EHCI,
+ s5p-ehci, NULL),
{},
};
--
1.7.6.5
--
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
