Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On 01/15/2015 10:34 PM, Mark Rutland wrote: > On Thu, Jan 15, 2015 at 12:52:38PM +, Chanwoo Choi wrote: >> On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi wrote: >>> Hi Mark, >>> >>> On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland wrote: On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: > Hi Kukjin, > > On 01/15/2015 01:02 AM, Daniel Lezcano wrote: >> On 01/14/2015 04:51 PM, Kukjin Kim wrote: >>> On 01/14/15 14:33, Chanwoo Choi wrote: >>> >>> Hi, >>> >>> + Doug, Olof >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. >>> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available >>> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is >>> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has >>> implemented it and additionally its access is faster than using memory >>> mapped register called SFR for MCT...so Doug submitted patch to use MCT >>> on 32bit exynos SoCs before. > > I know arch_timer. As you comment, ARCH timer would be used for system > timer for ARMv8. > But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I > checked it on > Exynos5433/EXynos7 User-manaual and tested it. > > I think that exynos_mct.c should support the Exynos 64-bit SoC > because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. > > Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos > User-manual never includes > the detailed information about for ARCH timer(e.g, clock for ARCH timer). > I knew that > I can get the document of ARCH timer for ARM official site but I think it > is insufficient > to implement ARCH timer on Exynos SoC. What do you mean by "insufficient to implement ARCH timer"? >>> >>> As I knew, timer must need the source clock. The clock for ARCH timer >>> has dependency on Exynos SoC, But I cannot find >> >> I'm so sorry about this mistake. I pressed the send button before >> completing reply. >> >> As I knew, timer must need the source clock. The clock for ARCH timer >> has dependency on Exynos SoC, But I cannot find the clock information >> for ARCH timer on Exynos SoC user-manual. >> >> When I tried to use ARCH timer on Exynos3250, It is not working. We >> can check this ARCH timer issue of Exynos3250 >> on following patch[1]: >> [1] http://www.spinics.net/lists/arm-kernel/msg322943.html > > Hmm. That is annoying. Your boot code should have been initialising this > already. Right, I want to resolve the issue for Exynos3250 but I don't have any information. Maybe this issue should be fixed by the architector of Exynos SoC or any samsung developer who can contact the information of ARCH timer. > The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. >> >> I agree that ARCH timer is mandatory. >> >> I just think that existing exynos-mct.c driver should support the Exynos5/7 >> SoC >> because released Exynos5/7 SoC includes already MCT IP for system timer. > > I'm not opposed to the MCT. My only concern is that a configured and > enabled architected timer is mandated by the boot protocol, and is a > prerequisite for a functioning kernel. Thanks for your opinion. As I replyed on previous mail, I agree that ARCH timer is necessary. Your initial response made it > sound like you expected the MCT alone to be sufficient. I didn't mean it. Best Regards, Chanwoo Choi -- 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 v3 00/16] thermal: exynos: Thermal code rework to use device tree
Hello, while looking through the patchset I noticed the following. In patch 07/16 code is added to drivers/cpufreq/exynos-cpufreq.c, which reminded me of the cpufreq patchset by Thomas Abraham. If I remember correctly then the ultimate goal of the cpufreq 'conversion' is to get rid of the exynos-cpufreq driver is use the cpufreq-cpu0 (now cpufreq-dt) driver for everything. Now, this cpufreq patchset hasn't been updated in a while, so I'm not sure if maybe plans have changed already. But if the goal still is to remove exynos-cpufreq in the end, wouldn't it be better to not add new (functionality-providing) code to it, like this series does? With best wishes, Tobias Lukasz Majewski wrote: > 1. Introduction > > Following patches aim to clean up the current implementation of the thermal > framework on Exynos devices. > > The main goal was to use a generic code for reading thermal configuration > (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files > were removed. > > Around 400 lines of code (LOC) were removed directly by this patch, which > is around 20% of the Exynos thermal code base. > > This work should NOT bring any functional changes to Exynos thermal > subsystem. > > 2. Patch-set structure > > Then the cpu_cooling functionality has been preserved to allow cooling > devices by reducing operating frequency. Definition of trip points and > cpufreq's cooling properties were moved to device tree. > > Then the rework of the way in which configuration data is provided to > the Exynos thermal subsystem was performed. Now device tree is used for > configuration. > > 3. Dead code removal > > Thermal support for some SoCs, previously available in the exynos_tmu_data.c > file, was removed since, as of (almost) 3.19-rc3, they didn't have TMU > bindings. > > Moreover, support for cpu_cooling devices was preserved only on those > SoCs which had available and working cpufreq driver. > > 4. Testing > > Test devices: > - Exynos4210 - Trats (TMU zone + cpu_cooling) > - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) > - Exynos5250 - Arndale (TMU zone + cpu_cooling) > - Exynos5420 - Arndale-octa (only TMU zones) > > Unfortunately, I don't posses Exynos5440 for testing. Its functionality > has been preserved in the code, but not tested on the hardware. I would > be grateful for help in testing. > > > 5. This work apply on the following tree: > > kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree > SHA1: 1813d80874699145f04af6b05ebab0a6419001fb > > Lukasz Majewski (16): > thermal: exynos: cosmetic: Correct comment format > thermal: exynos: Provide thermal_exynos.h file to be included in > device tree files > arm: dts: trats: Enable TMU on the Exynos4210 trats device > arm: dts: odroid: Add LD010 regulator node necessary for TMU on Odroid > thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device > arm: dts: Adding CPU cooling binding for Exynos SoCs > thermal: exynos: Modify exynos thermal code to use device tree for cpu > cooling configuration > thermal: exynos: dts: Add default definition of the TMU sensor > parameter > dts: Documentation: Extending documentation entry for exynos-thermal > thermal: dts: Default trip points definition for Exynos5420 SoCs > thermal: exynos: dts: Define default thermal-zones for Exynos4 > thermal: dts: exynos: Trip points and sensor configuration data for > Exynos5440 > thermal: exynos: dts: Provide device tree bindings identical to the > one in exynos_tmu_data.c > thermal: samsung: core: Exynos TMU rework to use device tree for > configuration > thermal: exynos: Remove exynos_thermal_common.[c|h] files > thermal: exynos: Remove exynos_tmu_data.c file > > .../devicetree/bindings/thermal/exynos-thermal.txt | 17 + > arch/arm/boot/dts/exynos3250.dtsi | 2 + > arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 +++ > arch/arm/boot/dts/exynos4.dtsi | 4 + > arch/arm/boot/dts/exynos4210-trats.dts | 19 + > arch/arm/boot/dts/exynos4210.dtsi | 26 +- > arch/arm/boot/dts/exynos4212.dtsi | 5 +- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 ++ > arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 ++ > arch/arm/boot/dts/exynos4412-trats2.dts| 15 + > arch/arm/boot/dts/exynos4412.dtsi | 5 +- > arch/arm/boot/dts/exynos4x12.dtsi | 1 + > arch/arm/boot/dts/exynos5250.dtsi | 25 +- > arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 ++ > arch/arm/boot/dts/exynos5420.dtsi | 28 ++ > arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 24 ++ > arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 ++ > arch/arm/boot/dts/exynos5440.dtsi | 18 + > drivers/cpufreq/exynos-cpufreq.c | 30 +- > drivers/thermal/samsung/Makefile
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello! Marek Szyprowski wrote: > I hope that HDMI display works fine for you. I checked with my panel just now and played around a bit with the DRM (opening, vsync, etc.). However on deinitialization the entire system locked up. I currently haven't hooked the board up to the serial console, otherwise I would've tried to extract some more meaningful information. Going to check again more thoroughly on the weekend what exactly triggers the lockup. With best wishes, Tobias -- 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: [GIT PULL RE-SEND] Samsung exynos7 updates for v3.20
On Thu, Jan 15, 2015 at 12:07:16AM +0900, Kukjin Kim wrote: > Hi, > > Sorry, I'm resending this pull-request because of missing signed-tag. > > Please pull. If any problems, please let me know. > > Thanks, > Kukjin > > The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: > > Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-dt-64 > > for you to fetch changes up to 6f56eef1f9aba3747c811780a4768618167d5c97: > > arm64: Enable ARMv8 based exynos7 SoC support (2014-12-23 00:19:08 +0900) Merged. -Olof -- 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: [GIT PULL RE-SEND] Samsung fixes for v3.19
On Thu, Jan 15, 2015 at 12:05:18AM +0900, Kukjin Kim wrote: > Hi, > > Oops, it's totally my fault and mistake. Actually my git command for > pull-request was correct but the git tool was old version :-( because > there are two git in my laptop, anyway sorry for that and I'm resending > with signed tag has been created before. > > Please pull if you're OK with my comments on your questions below. > > > The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: > > Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-fixes-3.19 > > for you to fetch changes up to 26d13bf77b8e59adf4953577ba48e1903545bf7f: > > ARM: exynos_defconfig: Enable LM90 driver (2015-01-12 17:16:32 +0900) > > > Samsung fixes for v3.19 > - exynos_defconfig: enable LM90 driver and display panel support >- HWMON >- SENSORS_LM90 >- Direct Rendering Manager (DRM) >- DRM bridge registration and lookup framework >- Parade ps8622/ps8625 eDP/LVDS bridge >- NXP ptn3460 eDP/LVDS bridge >- Exynos Fully Interactive Mobile Display controller (FIMD) >- Panel registration and lookup framework >- Simple panels >- Backlight & LCD device support > > - use pmu_system_controller phandle for dp phy > : DP PHY requires pmu_system_controller to handle PMU reg. now Merged. -Olof -- 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: remove unused DMA infrastructure
Am Donnerstag, 15. Januar 2015, 16:16:03 schrieb Arnd Bergmann: > Everything uses dmaengine now, so there is no reason to > keep this around any longer. Thanks to everyone who was involved > in moving the users over to use the dmaengine APIs. > > Signed-off-by: Arnd Bergmann very nice to see this finished :-) Reviewed-by: Heiko Stuebner -- 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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Tony Lindgren [150115 10:04]: > * Marc Zyngier [150115 09:31]: > > On 15/01/15 17:04, Tony Lindgren wrote: > > > * Marc Zyngier [150115 06:53]: > > >> On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon > > >> wrote: > > >>> On 14:28-20150115, Marc Zyngier wrote: > > >>>> Assuming the workaround I posted earlier works, the OMAP/DRA7 part of > > >>>> this series is going to require some rework too (I need to know where > > >>>> these legacy interrupts are attached: crossbar, WUGEN, or GIC?). > > >>>> > > >>> crossbar will never work with legacy static interrupts anyways - since > > >>> there was never a static interrupt possible - I believe we had removed > > >>> all the legacy hardcoded interrupt definitions for DRA7. ideally, they > > >>> should all be dt only now. > > >> > > >> Yes, I guessed as much after looking at the DRA7XX hwmod. > > >> > > >> So only OMAP4/5 is b0rken at the moment. I can probably work around it > > >> as I did in this example patch, just by changing the compatible strings > > >> for the xlate callback. Very ugly. > > > > > > For the -rc, it seems the wakeupen still needs a fix as based on grepping > > > for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? > > > > I think this one is fine. It computes the SPI number based on the hwirq > > coming from the GIC. That direction is completely unaffected by the > > linear domain stuff. It is only when you try to use a hardware IRQ as a > > Linux IRQ that you run into trouble. > > Yes OK that makes sense. And suspend and resume seem to work with your fix. FYI, to test suspend and resume with wakeups from the serial console, the uart wakeup events need to be enabled under sys: #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) for uart in $uarts; do echo enabled > $uart/wakeup 2>&1 done And after that suspending with echo mem > /sys/power/state should wake to a serial interrupt. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier [150115 09:31]: > On 15/01/15 17:04, Tony Lindgren wrote: > > * Marc Zyngier [150115 06:53]: > >> On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon wrote: > >>> On 14:28-20150115, Marc Zyngier wrote: > >>>> Assuming the workaround I posted earlier works, the OMAP/DRA7 part of > >>>> this series is going to require some rework too (I need to know where > >>>> these legacy interrupts are attached: crossbar, WUGEN, or GIC?). > >>>> > >>> crossbar will never work with legacy static interrupts anyways - since > >>> there was never a static interrupt possible - I believe we had removed > >>> all the legacy hardcoded interrupt definitions for DRA7. ideally, they > >>> should all be dt only now. > >> > >> Yes, I guessed as much after looking at the DRA7XX hwmod. > >> > >> So only OMAP4/5 is b0rken at the moment. I can probably work around it > >> as I did in this example patch, just by changing the compatible strings > >> for the xlate callback. Very ugly. > > > > For the -rc, it seems the wakeupen still needs a fix as based on grepping > > for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? > > I think this one is fine. It computes the SPI number based on the hwirq > coming from the GIC. That direction is completely unaffected by the > linear domain stuff. It is only when you try to use a hardware IRQ as a > Linux IRQ that you run into trouble. Yes OK that makes sense. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On 15/01/15 17:04, Tony Lindgren wrote: > * Marc Zyngier [150115 06:53]: >> On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon wrote: >>> On 14:28-20150115, Marc Zyngier wrote: >>>> Assuming the workaround I posted earlier works, the OMAP/DRA7 part of >>>> this series is going to require some rework too (I need to know where >>>> these legacy interrupts are attached: crossbar, WUGEN, or GIC?). >>>> >>> crossbar will never work with legacy static interrupts anyways - since >>> there was never a static interrupt possible - I believe we had removed >>> all the legacy hardcoded interrupt definitions for DRA7. ideally, they >>> should all be dt only now. >> >> Yes, I guessed as much after looking at the DRA7XX hwmod. >> >> So only OMAP4/5 is b0rken at the moment. I can probably work around it >> as I did in this example patch, just by changing the compatible strings >> for the xlate callback. Very ugly. > > For the -rc, it seems the wakeupen still needs a fix as based on grepping > for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? I think this one is fine. It computes the SPI number based on the hwirq coming from the GIC. That direction is completely unaffected by the linear domain stuff. It is only when you try to use a hardware IRQ as a Linux IRQ that you run into trouble. Thanks, M. -- 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
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier [150115 06:53]: > On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon wrote: > > On 14:28-20150115, Marc Zyngier wrote: > >> Assuming the workaround I posted earlier works, the OMAP/DRA7 part of > >> this series is going to require some rework too (I need to know where > >> these legacy interrupts are attached: crossbar, WUGEN, or GIC?). > >> > > crossbar will never work with legacy static interrupts anyways - since > > there was never a static interrupt possible - I believe we had removed > > all the legacy hardcoded interrupt definitions for DRA7. ideally, they > > should all be dt only now. > > Yes, I guessed as much after looking at the DRA7XX hwmod. > > So only OMAP4/5 is b0rken at the moment. I can probably work around it > as I did in this example patch, just by changing the compatible strings > for the xlate callback. Very ugly. For the -rc, it seems the wakeupen still needs a fix as based on grepping for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/16] thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c
Hi Eduardo,
> On Wed, Jan 14, 2015 at 02:41:11PM +0100, Lukasz Majewski wrote:
> > Presented device tree bindings provide data already hardcoded in the
> > exynos_tmu_data.c file.
> > After this commit, it should be possible to reuse common thermal
> > core framework in Exynos SoCs.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Add proper TMU entries for exynos3250.dtsi
> > Changes for v3:
> > - Remove "type" DT properties, which will be extracted from
> > compatible
> > - "samsung,tmu_" prefix for TMU specific properties has been added
> >
> > ---
> > arch/arm/boot/dts/exynos3250.dtsi | 2 ++
> > arch/arm/boot/dts/exynos4.dtsi| 4
> > arch/arm/boot/dts/exynos4210.dtsi | 21 -
> > arch/arm/boot/dts/exynos4x12.dtsi | 1 +
> > arch/arm/boot/dts/exynos5250.dtsi | 5 +++--
> > arch/arm/boot/dts/exynos5420.dtsi | 28
> > arch/arm/boot/dts/exynos5440.dtsi | 18 ++
> > 7 files changed, 76 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> > b/arch/arm/boot/dts/exynos3250.dtsi index 2246549..8cc078c 100644
> > --- a/arch/arm/boot/dts/exynos3250.dtsi
> > +++ b/arch/arm/boot/dts/exynos3250.dtsi
> > @@ -18,6 +18,7 @@
> > */
> >
> > #include "skeleton.dtsi"
> > +#include "exynos4-cpu-thermal.dtsi"
> > #include
> >
> > / {
> > @@ -188,6 +189,7 @@
> > interrupts = <0 216 0>;
> > clocks = <&cmu CLK_TMU_APBIF>;
> > clock-names = "tmu_apbif";
> > + #include "exynos4412-tmu-sensor-conf.dtsi"
> > status = "disabled";
> > };
> >
> > diff --git a/arch/arm/boot/dts/exynos4.dtsi
> > b/arch/arm/boot/dts/exynos4.dtsi index b8168f1..f18d746 100644
> > --- a/arch/arm/boot/dts/exynos4.dtsi
> > +++ b/arch/arm/boot/dts/exynos4.dtsi
> > @@ -645,4 +645,8 @@
> > samsung,sysreg = <&sys_reg>;
> > status = "disabled";
> > };
> > +
> > + tmu: tmu@100C {
> > + #include "exynos4412-tmu-sensor-conf.dtsi"
> > + };
> > };
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > b/arch/arm/boot/dts/exynos4210.dtsi index 2e66df8..7f0e012 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -21,6 +21,7 @@
> >
> > #include "exynos4.dtsi"
> > #include "exynos4210-pinctrl.dtsi"
> > +#include "exynos4-cpu-thermal.dtsi"
> >
> > / {
> > compatible = "samsung,exynos4210", "samsung,exynos4";
> > @@ -146,16 +147,34 @@
> > reg = <0x0386 0x1000>;
> > };
> >
> > - tmu@100C {
> > + tmu: tmu@100C {
> > compatible = "samsung,exynos4210-tmu";
> > interrupt-parent = <&combiner>;
> > reg = <0x100C 0x100>;
> > interrupts = <2 4>;
> > clocks = <&clock CLK_TMU_APBIF>;
> > clock-names = "tmu_apbif";
> > + samsung,tmu_gain = <15>;
> > + samsung,tmu_reference_voltage = <7>;
> > status = "disabled";
> > };
> >
> > + thermal-zones {
> > + cpu_thermal: cpu-thermal {
> > + trips {
> > + cpu_alert0: cpu-alert-0 {
> > + temperature = <85000>; /*
> > millicelsius */
> > + };
> > + cpu_alert1: cpu-alert-1 {
> > + temperature = <10>; /*
> > millicelsius */
> > + };
> > + cpu_alert2: cpu-alert-2 {
> > + temperature = <11>; /*
> > millicelsius */
> > + };
> > + };
> > + };
> > + };
> > +
> > g2d@1280 {
> > compatible = "samsung,s5pv210-g2d";
> > reg = <0x1280 0x1000>;
> > diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> > b/arch/arm/boot/dts/exynos4x12.dtsi index 93b7040..3ee2031 100644
> > --- a/arch/arm/boot/dts/exynos4x12.dtsi
> > +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> > @@ -19,6 +19,7 @@
> >
> > #include "exynos4.dtsi"
> > #include "exynos4x12-pinctrl.dtsi"
> > +#include "exynos4-cpu-thermal.dtsi"
> >
> > / {
> > aliases {
> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> > b/arch/arm/boot/dts/exynos5250.dtsi index dd5c3a0..07fd73a 100644
> > --- a/arch/arm/boot/dts/exynos5250.dtsi
> > +++ b/arch/arm/boot/dts/exynos5250.dtsi
> > @@ -20,7 +20,7 @@
> > #include
> > #include "exynos5.dtsi"
> > #include "exynos5250-pinctrl.dtsi"
> > -
> > +#include "exynos4-cpu-thermal.dtsi"
> > #include
> >
> > / {
> > @@ -236,12 +236,13 @@
> > status = "disabled";
> > };
> >
> > - tmu@1006 {
> > + tmu: tmu@1006 {
> > compatible = "samsung,exynos5250-tmu";
> > reg = <0x1006 0x100>;
> > interrupts = <0 65 0>;
> > clocks = <&clock CLK_TMU>;
> >
Re: [v3,06/16] arm: dts: Adding CPU cooling binding for Exynos SoCs
Hi Tobias, > Hello, > > I noticed that this patch mixes spaces and tabs a lot for indentation. Thanks for spotting. It is going to be fixed in v4 of this patch. > > With best wishes, > Tobias > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- 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: [RFC 0/3] mmc: Add dynamic frequency scaling
On 12 January 2015 at 10:23, Krzysztof Kozlowski wrote: > Hi, > > > I would like to hear some comments about idea of scaling MMC clock > frequency. The basic idea is to lower the clock when device is > completely idle or not busy enough. > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > as governor. In idle this gave benefits (less energy consumed during > idle): > 1. Trats2 (Exynos4412): 2.6% > 2. Rinato (Exynos3250): 1% > > but (especially on Rinato) it had impact on performance (probably > because ondemand triggering a little to late). What is interesting > manually changing the clock (without this patchset) gave slightly > bigger benefits. Maybe the devfreq introduces noticeable overhead? Could it be because of the polling interval being too long thus it being too slow to ramp up? That's a problem with all polling devfreq drivers, it has been proposed before using pm_qos to to reduce the polling interval when some event indicates that the utilization may grow abruptly in the near future. I don't think pm_qos is the best mechanism for that, maybe something new needs to be devised. Regards, Tomeu > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (3): > mmc: Add dynamic frequency scaling > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > ARM: dts: Use frequency scaling for MSHC > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > drivers/mmc/card/block.c | 247 > ++ > drivers/mmc/core/Kconfig | 16 ++ > drivers/mmc/core/core.h | 1 - > drivers/mmc/core/host.c | 2 + > include/linux/mmc/card.h | 8 + > include/linux/mmc/host.h | 3 + > 9 files changed, 282 insertions(+), 2 deletions(-) > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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 v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
Hi Eduardo,
> On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
> > This patch brings support for providing configuration via device
> > tree. Previously this data has been hardcoded in the
> > exynos_tmu_data.c file. Such approach was not scalable and very
> > often required copying the whole data.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
> > - Usage of of-thermal.c exported trip points table
> > Changes for v3:
> > - Adding exynos_of_get_soc_type() method to set SOC type from
> > device's compatible string
> > - "samsung,tmu_" prefix for TMU specific properties has been added
> >
> > ---
> > drivers/thermal/samsung/Makefile | 2 -
> > drivers/thermal/samsung/exynos_tmu.c | 345
> > +++
> > drivers/thermal/samsung/exynos_tmu.h | 53 +- 3 files changed,
> > 226 insertions(+), 174 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/Makefile
> > b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
> > --- a/drivers/thermal/samsung/Makefile
> > +++ b/drivers/thermal/samsung/Makefile
> > @@ -3,5 +3,3 @@
> > #
> > obj-$(CONFIG_EXYNOS_THERMAL) +=
> > exynos_thermal.o exynos_thermal-y :=
> > exynos_tmu.o -exynos_thermal-y +=
> > exynos_tmu_data.o
>
> Can this makefile change be part of the patch that removes
> exynos_tmu_data.c?
>
> > -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
> > exynos_thermal_common.o
>
> Can this makefile change be part of the patch that removes
> exynos_thermal_common.c?
Unfortunately, this code cannot be moved to the next patch, in which I
remove the files, since this causes build break of the series.
The code structure as is, provides working, bisectable thermal
solution - thermal and cpu_cooling functionality is preserved across
all commits in the series.
>
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..633a9e2 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -1,6 +1,10 @@
> > /*
> > * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
> > *
> > + * Copyright (C) 2014 Samsung Electronics
> > + * Bartlomiej Zolnierkiewicz
> > + * Lukasz Majewski
> > + *
> > * Copyright (C) 2011 Samsung Electronics
> > * Donggeun Kim
> > * Amit Daniel Kachhap
> > @@ -31,8 +35,8 @@
> > #include
> > #include
> >
> > -#include "exynos_thermal_common.h"
> > #include "exynos_tmu.h"
> > +#include "../thermal_core.h"
> >
> > /* Exynos generic registers */
> > #define EXYNOS_TMU_REG_TRIMINFO0x0
> > @@ -115,6 +119,7 @@
> > #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
> > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
> >
> > +#define MCELSIUS 1000
> > /**
> > * struct exynos_tmu_data : A structure to hold the private data
> > of the TMU driver
> > @@ -150,7 +155,8 @@ struct exynos_tmu_data {
> > struct clk *clk, *clk_sec;
> > u8 temp_error1, temp_error2;
> > struct regulator *regulator;
> > - struct thermal_sensor_conf *reg_conf;
> > + struct thermal_zone_device *tzd;
> > +
> > int (*tmu_initialize)(struct platform_device *pdev);
> > void (*tmu_control)(struct platform_device *pdev, bool on);
> > int (*tmu_read)(struct exynos_tmu_data *data);
> > @@ -159,6 +165,33 @@ struct exynos_tmu_data {
> > void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
> > };
> >
> > +static void exynos_report_trigger(struct exynos_tmu_data *p)
> > +{
> > + char data[10], *envp[] = { data, NULL };
> > + struct thermal_zone_device *tz = p->tzd;
> > + unsigned long temp;
> > + unsigned int i;
> > +
> > + if (!p) {
> > + pr_err("Wrong temperature configuration data\n");
> > + return;
> > + }
> > +
> > + thermal_zone_device_update(tz);
> > +
> > + mutex_lock(&tz->lock);
> > + /* Find the level for which trip happened */
> > + for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
> > + tz->ops->get_trip_temp(tz, i, &temp);
> > + if (tz->last_temperature < temp)
> > + break;
> > + }
> > +
> > + snprintf(data, sizeof(data), "%u", i);
> > + kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, envp);
> > + mutex_unlock(&tz->lock);
> > +}
> > +
> > /*
> > * TMU treats temperature as a mapped temperature code.
> > * The temperature is converted differently depending on the
> > calibration type. @@ -234,14 +267,25 @@ static void
> > sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
> > static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold,
> > bool falling) {
> > - struct exynos_tmu_platform_data *pdata = data->pdata;
> > + struct thermal_zone_device *tz = data->tzd;
> > + const struct thermal_trip * const trips =
> > +
[PATCH] ARM: SAMSUNG: remove unused DMA infrastructure
Everything uses dmaengine now, so there is no reason to keep this around any longer. Thanks to everyone who was involved in moving the users over to use the dmaengine APIs. Signed-off-by: Arnd Bergmann --- Documentation/arm/Samsung-S3C24XX/DMA.txt| 46 - arch/arm/mach-exynos/include/mach/dma.h | 26 - arch/arm/mach-s3c24xx/Kconfig| 42 - arch/arm/mach-s3c24xx/Makefile |7 - arch/arm/mach-s3c24xx/dma-s3c2410.c | 182 --- arch/arm/mach-s3c24xx/dma-s3c2412.c | 150 --- arch/arm/mach-s3c24xx/dma-s3c2440.c | 193 --- arch/arm/mach-s3c24xx/dma-s3c2443.c | 179 --- arch/arm/mach-s3c24xx/dma.c | 1465 -- arch/arm/mach-s3c24xx/include/mach/dma.h | 159 --- arch/arm/mach-s3c64xx/include/mach/dma.h | 15 - arch/arm/plat-samsung/Kconfig| 15 - arch/arm/plat-samsung/Makefile |6 - arch/arm/plat-samsung/dma-ops.c | 146 --- arch/arm/plat-samsung/dma.c | 84 -- arch/arm/plat-samsung/include/plat/dma-core.h| 22 - arch/arm/plat-samsung/include/plat/dma-ops.h | 69 - arch/arm/plat-samsung/include/plat/dma-pl330.h | 121 -- arch/arm/plat-samsung/include/plat/dma-s3c24xx.h | 73 -- arch/arm/plat-samsung/include/plat/dma.h | 130 -- arch/arm/plat-samsung/include/plat/regs-dma.h| 151 --- arch/arm/plat-samsung/s3c-dma-ops.c | 146 --- drivers/dma/Kconfig |2 +- 23 files changed, 1 insertion(+), 3428 deletions(-) diff --git a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt deleted file mode 100644 index 3ed82383efea.. --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt +++ /dev/null @@ -1,46 +0,0 @@ - S3C2410 DMA - === - -Introduction - - - The kernel provides an interface to manage DMA transfers - using the DMA channels in the CPU, so that the central - duty of managing channel mappings, and programming the - channel generators is in one place. - - -DMA Channel Ordering - - - Many of the range do not have connections for the DMA - channels to all sources, which means that some devices - have a restricted number of channels that can be used. - - To allow flexibility for each CPU type and board, the - DMA code can be given a DMA ordering structure which - allows the order of channel search to be specified, as - well as allowing the prohibition of certain claims. - - struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of DMA - channel numbers. The slots are searched in order for - the presence of a DMA channel number with DMA_CH_VALID - or-ed in. - - If the order has the flag DMA_CH_NEVER set, then after - checking the channel list, the system will return no - found channel, thus denying the request. - - A board support file can call s3c24xx_dma_order_set() - to register a complete ordering set. The routine will - copy the data, so the original can be discarded with - __initdata. - - -Authour - -Ben Dooks, -Copyright (c) 2007 Ben Dooks, Simtec Electronics -Licensed under the GPL v2 diff --git a/arch/arm/mach-exynos/include/mach/dma.h b/arch/arm/mach-exynos/include/mach/dma.h deleted file mode 100644 index 201842a3769e.. --- a/arch/arm/mach-exynos/include/mach/dma.h +++ /dev/null @@ -1,26 +0,0 @@ -/* - * Copyright (C) 2010 Samsung Electronics Co. Ltd. - * Jaswinder Singh - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#ifndef __MACH_DMA_H -#define __MACH_DMA_H - -/* This platform uses the common DMA API driver for PL330 */ -#include - -#endif /* __MACH_DMA_H */ diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 9eb22297cbe1..79c49ff77f6e 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -29,7 +29,6 @@ config CPU_S3C2410 default y select CPU_ARM920T select S3C2410_COMMON_CLK - select S3C2410_DMA if S3C24XX_DMA select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ select S3C2410_PM i
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon wrote: > On 14:28-20150115, Marc Zyngier wrote: >> Assuming the workaround I posted earlier works, the OMAP/DRA7 part of >> this series is going to require some rework too (I need to know where >> these legacy interrupts are attached: crossbar, WUGEN, or GIC?). >> > crossbar will never work with legacy static interrupts anyways - since > there was never a static interrupt possible - I believe we had removed > all the legacy hardcoded interrupt definitions for DRA7. ideally, they > should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. M. -- 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
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On 14:28-20150115, Marc Zyngier wrote: > Assuming the workaround I posted earlier works, the OMAP/DRA7 part of > this series is going to require some rework too (I need to know where > these legacy interrupts are attached: crossbar, WUGEN, or GIC?). > crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. -- Regards, Nishanth Menon -- 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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On Wed, Jan 14 2015 at 10:28:14 pm GMT, Tony Lindgren wrote:
> * Marc Zyngier [150112 10:30]:
>> OMAP4/5 has been (ab)using the gic_arch_extn to provide
>> wakeup from suspend, and it makes a lot of sense to convert
>> this code to use stacked domains instead.
>>
>> This patch does just this, updating the DT files to actually
>> reflect what the HW provides.
>>
>> BIG FAT WARNING: because the DTs were so far lying by not
>> exposing the WUGEN HW block, kernels with this patch applied
>> won't have any suspend-resume facility when booted with old DTs,
>> and old kernels with updated DTs won't even boot.
>>
>> On a platform with this patch applied, the system looks like
>> this:
>>
>> root@bacon-fat:~# cat /proc/interrupts
>> CPU0 CPU1
>> 16: 0 0 WUGEN 37 gp_timer
>> 19: 233799 155916 GIC 27 arch_timer
>> 23: 0 0 WUGEN 9 l3-dbg-irq
>> 24: 1 0 WUGEN 10 l3-app-irq
>> 27:282 0 WUGEN 13 omap-dma-engine
>> 44: 0 0 4ae1.gpio 13 DMA
>
> FYI, the legacy irq numbers are now all wrong since commit
> 9a1091ef0017 ("irqchip: gic: Support hierarchy irq domain.").
>
> Started a separate thread "Regression with legacy IRQ numbers
> caused by 9a1091ef0017" on it, will give these a try once
> that's sorted out.
Assuming the workaround I posted earlier works, the OMAP/DRA7 part of
this series is going to require some rework too (I need to know where
these legacy interrupts are attached: crossbar, WUGEN, or GIC?).
Thanks,
M.
--
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
Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block
Hi, On 15/01/15 06:49, Padma Venkat wrote: > I posted patches after re-basing on your tree and after incorporating > all comments from Vivek. > Below is the link > http://www.spinics.net/lists/linux-samsung-soc/msg40992.html > > Can you pick the patches? Sure, I'm not forgetting it. I've updated the exynos7 branch with your v2 patches. 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: [v3,06/16] arm: dts: Adding CPU cooling binding for Exynos SoCs
Hello, I noticed that this patch mixes spaces and tabs a lot for indentation. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello!
On 2015-01-15 11:06, Marek Szyprowski wrote:
The issues with FIMC / DRM FIMC are not related to HDMI patches. They
will
be handled separately. For the time being simply please disable Exynos
IPP
(or Exynos DRM FIMC) feature in your kernel configuration.
Confirming that disabling the IPP removes the __clk_{unprepare,disable}
warnings.
I hope that HDMI display works fine for you.
I haven't got a HDMI display here atm, testing later!
With best wishes,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
On 2015-01-15 11:41, Joonyoung Shim wrote: I posted a patch to fix it already. http://www.spinics.net/lists/dri-devel/msg75039.html Thanks. Thanks for heads up, I can confirm that applying the patch removes the warning from the mixer. With best wishes, Tobias -- 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: dts: Fix CLK_UART_ISP_SCLK clock assignment in exynos4x12.dtsi
Assign proper FIMC-IS UART gate clock in the device DT node and not
use the SRC_MASK gate. This fixes regression introduced in commit
a37c82a3b3c0910019abfd22a97be1f ("clk: samsung: exynos4: Remove
SRC_MASK_ISP gates").
Without this change exynos4 fimc-is driver fails to probe with an
error log:
[1.842447] ERROR: could not get clock /camera/fimc-is@1200:uart(13)
[1.848529] exynos4-fimc-is 1200.fimc-is: failed to get clock: uart
[1.855275] exynos4-fimc-is: probe of 1200.fimc-is failed with error -2
Signed-off-by: Sylwester Nawrocki
---
Kukjin, could you take this patch into your tree ? I have been applying it
for several kernel releases now to get the Exynos4 FIMC driver even passing
probing.
Thanks,
Sylwester
arch/arm/boot/dts/exynos4x12.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 93b7040..86e1800 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -225,7 +225,7 @@
<&clock CLK_DIV_ISP0>,<&clock CLK_DIV_ISP1>,
<&clock CLK_DIV_MCUISP0>,
<&clock CLK_DIV_MCUISP1>,
-<&clock CLK_SCLK_UART_ISP>,
+<&clock CLK_UART_ISP_SCLK>,
<&clock CLK_ACLK200>, <&clock CLK_DIV_ACLK200>,
<&clock CLK_ACLK400_MCUISP>,
<&clock CLK_DIV_ACLK400_MCUISP>;
--
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: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Thu, Jan 15, 2015 at 12:52:38PM +, Chanwoo Choi wrote: > On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi wrote: > > Hi Mark, > > > > On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland wrote: > >> On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: > >>> Hi Kukjin, > >>> > >>> On 01/15/2015 01:02 AM, Daniel Lezcano wrote: > >>> > On 01/14/2015 04:51 PM, Kukjin Kim wrote: > >>> >> On 01/14/15 14:33, Chanwoo Choi wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> + Doug, Olof > >>> >> > >>> >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is > >>> >>> only used > >>> >>> for Exynos 32bit SoC. > >>> >>> > >>> >> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is > >>> >> available > >>> >> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture > >>> >> is > >>> >> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has > >>> >> implemented it and additionally its access is faster than using memory > >>> >> mapped register called SFR for MCT...so Doug submitted patch to use MCT > >>> >> on 32bit exynos SoCs before. > >>> > >>> I know arch_timer. As you comment, ARCH timer would be used for system > >>> timer for ARMv8. > >>> But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I > >>> checked it on > >>> Exynos5433/EXynos7 User-manaual and tested it. > >>> > >>> I think that exynos_mct.c should support the Exynos 64-bit SoC > >>> because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. > >>> > >>> Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos > >>> User-manual never includes > >>> the detailed information about for ARCH timer(e.g, clock for ARCH timer). > >>> I knew that > >>> I can get the document of ARCH timer for ARM official site but I think it > >>> is insufficient > >>> to implement ARCH timer on Exynos SoC. > >> > >> What do you mean by "insufficient to implement ARCH timer"? > > > > As I knew, timer must need the source clock. The clock for ARCH timer > > has dependency on Exynos SoC, But I cannot find > > I'm so sorry about this mistake. I pressed the send button before > completing reply. > > As I knew, timer must need the source clock. The clock for ARCH timer > has dependency on Exynos SoC, But I cannot find the clock information > for ARCH timer on Exynos SoC user-manual. > > When I tried to use ARCH timer on Exynos3250, It is not working. We > can check this ARCH timer issue of Exynos3250 > on following patch[1]: > [1] http://www.spinics.net/lists/arm-kernel/msg322943.html Hmm. That is annoying. Your boot code should have been initialising this already. > >> The architected timer is mandatory in ARMv8, and required by the arm64 > >> kernel. > >> > >> Additional timers may be requried if you want to put all CPUs into low > >> power states where the timer logic may be disabled and/or lose state, > >> but regardless the architected timers are necessary. > > I agree that ARCH timer is mandatory. > > I just think that existing exynos-mct.c driver should support the Exynos5/7 > SoC > because released Exynos5/7 SoC includes already MCT IP for system timer. I'm not opposed to the MCT. My only concern is that a configured and enabled architected timer is mandated by the boot protocol, and is a prerequisite for a functioning kernel. Your initial response made it sound like you expected the MCT alone to be sufficient. Thanks, Mark. -- 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 RESEND] pwm: samsung: Fix output race on disabling
Hi Sjoerd,
Thanks for the patch. I posted some comments inline, though.
2015-01-08 7:58 GMT+09:00 Sjoerd Simons :
> When disabling the samsung PWM the output state remains at the level it
> was in the end of a pwm cycle. In other words, calling pwm_disable when
> at 100% duty will keep the output active, while at all other setting the
> output will go/stay inactive. On top of that the samsung PWM settings are
> double-buffered, which means the new settings only get applied at the
> start of a new PWM cycle.
>
> This results in a race if the PWM is at 100% duty and a driver calls:
> pwm_config (pwm, 0, period);
> pwm_disable (pwm);
>
> In this case the PWMs output will unexpectedly stay active, unless a new
> PWM cycle happened to start between the register writes in _config and
> _disable. As far as i can tell this is a regression introduced by 3bdf878,
> before that a call to pwm_config would call pwm_samsung_enable which,
> while heavy-handed, made sure the expected settings were live.
>
> To resolve this, while not re-introducing the issues 3bdf878 (flickering
> as the PWM got reset while in a PWM cycle). Only force an update of the
> settings when at 100% duty, which shouldn't have a noticeable effect on
> the output but is enough to ensure the behaviour is as expected on
> disable.
>
> Signed-off-by: Sjoerd Simons
> ---
> drivers/pwm/pwm-samsung.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index 3e9b583..3e252dc 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -335,6 +335,27 @@ static int pwm_samsung_config(struct pwm_chip *chip,
> struct pwm_device *pwm,
> writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
> writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
>
> + /* In case the PWM is currently at 100% duty, trigger a manual update
> to
> +* prevent unexpected results when disabling the pwm */
IMHO it wouldn't be a bad idea to specify exactly what those
unexpected results are and why a manual update helps instead of
repeating the same thing that can be understood from reading the code.
nit: According to CodingStyle multi-line comments should start and end
with empty line, i.e.
/*
* Line 1
* Line 2
*/
nit: s/pwm/PWM/
nit: Missing dot at the end of the sentence.
> + if (chan->period_ns/chan->tin_ns == chan->duty_ns/chan->tin_ns) {
This check looks really heavy weight and is not really obvious at
first look (especially the need to divide both sides by chan->tin_ns
to account for integer rounding). Maybe instead you could read back
tcmp before writing the new one and compare it with -1U?
Also nit (if you decide to keep the condition as is): There should be
spaces on both sides of the slash.
> + unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
> + u32 tcon;
> + unsigned long flags;
> +
> + dev_dbg(our_chip->chip.dev, "Forcing manual update");
> +
> + spin_lock_irqsave(&samsung_pwm_lock, flags);
> +
> + tcon = readl(our_chip->base + REG_TCON);
> + tcon |= TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, our_chip->base + REG_TCON);
> +
> + tcon &= ~TCON_MANUALUPDATE(tcon_chan);
> + writel(tcon, our_chip->base + REG_TCON);
> +
> + spin_unlock_irqrestore(&samsung_pwm_lock, flags);
> + }
I would move out the contents of the if block above to a separate
helper function, e.g. pwm_samsung_manual_update().
Best regards,
Tomasz
--
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 v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi wrote: > Hi Mark, > > On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland wrote: >> On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: >>> Hi Kukjin, >>> >>> On 01/15/2015 01:02 AM, Daniel Lezcano wrote: >>> > On 01/14/2015 04:51 PM, Kukjin Kim wrote: >>> >> On 01/14/15 14:33, Chanwoo Choi wrote: >>> >> >>> >> Hi, >>> >> >>> >> + Doug, Olof >>> >> >>> >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is >>> >>> only used >>> >>> for Exynos 32bit SoC. >>> >>> >>> >> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available >>> >> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is >>> >> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has >>> >> implemented it and additionally its access is faster than using memory >>> >> mapped register called SFR for MCT...so Doug submitted patch to use MCT >>> >> on 32bit exynos SoCs before. >>> >>> I know arch_timer. As you comment, ARCH timer would be used for system >>> timer for ARMv8. >>> But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I >>> checked it on >>> Exynos5433/EXynos7 User-manaual and tested it. >>> >>> I think that exynos_mct.c should support the Exynos 64-bit SoC >>> because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. >>> >>> Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos >>> User-manual never includes >>> the detailed information about for ARCH timer(e.g, clock for ARCH timer). I >>> knew that >>> I can get the document of ARCH timer for ARM official site but I think it >>> is insufficient >>> to implement ARCH timer on Exynos SoC. >> >> What do you mean by "insufficient to implement ARCH timer"? > > As I knew, timer must need the source clock. The clock for ARCH timer > has dependency on Exynos SoC, But I cannot find I'm so sorry about this mistake. I pressed the send button before completing reply. As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find the clock information for ARCH timer on Exynos SoC user-manual. When I tried to use ARCH timer on Exynos3250, It is not working. We can check this ARCH timer issue of Exynos3250 on following patch[1]: [1] http://www.spinics.net/lists/arm-kernel/msg322943.html > >> >> The architected timer is mandatory in ARMv8, and required by the arm64 >> kernel. >> >> Additional timers may be requried if you want to put all CPUs into low >> power states where the timer logic may be disabled and/or lose state, >> but regardless the architected timers are necessary. I agree that ARCH timer is mandatory. I just think that existing exynos-mct.c driver should support the Exynos5/7 SoC because released Exynos5/7 SoC includes already MCT IP for system timer. Best Regards, Chanwoo Choi -- 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 v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
Hi Mark, On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland wrote: > On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: >> Hi Kukjin, >> >> On 01/15/2015 01:02 AM, Daniel Lezcano wrote: >> > On 01/14/2015 04:51 PM, Kukjin Kim wrote: >> >> On 01/14/15 14:33, Chanwoo Choi wrote: >> >> >> >> Hi, >> >> >> >> + Doug, Olof >> >> >> >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is >> >>> only used >> >>> for Exynos 32bit SoC. >> >>> >> >> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available >> >> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is >> >> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has >> >> implemented it and additionally its access is faster than using memory >> >> mapped register called SFR for MCT...so Doug submitted patch to use MCT >> >> on 32bit exynos SoCs before. >> >> I know arch_timer. As you comment, ARCH timer would be used for system timer >> for ARMv8. >> But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked >> it on >> Exynos5433/EXynos7 User-manaual and tested it. >> >> I think that exynos_mct.c should support the Exynos 64-bit SoC >> because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. >> >> Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos >> User-manual never includes >> the detailed information about for ARCH timer(e.g, clock for ARCH timer). I >> knew that >> I can get the document of ARCH timer for ARM official site but I think it is >> insufficient >> to implement ARCH timer on Exynos SoC. > > What do you mean by "insufficient to implement ARCH timer"? As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find > > The architected timer is mandatory in ARMv8, and required by the arm64 > kernel. > > Additional timers may be requried if you want to put all CPUs into low > power states where the timer logic may be disabled and/or lose state, > but regardless the architected timers are necessary. > > Thanks, > Mark. > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: > Hi Kukjin, > > On 01/15/2015 01:02 AM, Daniel Lezcano wrote: > > On 01/14/2015 04:51 PM, Kukjin Kim wrote: > >> On 01/14/15 14:33, Chanwoo Choi wrote: > >> > >> Hi, > >> > >> + Doug, Olof > >> > >>> This patch adds the support for Exynos 64bit SoC. The delay_timer is only > >>> used > >>> for Exynos 32bit SoC. > >>> > >> Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available > >> on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is > >> including ARM ARCH timer (ARM Generic Timer) and exynos7 also has > >> implemented it and additionally its access is faster than using memory > >> mapped register called SFR for MCT...so Doug submitted patch to use MCT > >> on 32bit exynos SoCs before. > > I know arch_timer. As you comment, ARCH timer would be used for system timer > for ARMv8. > But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked > it on > Exynos5433/EXynos7 User-manaual and tested it. > > I think that exynos_mct.c should support the Exynos 64-bit SoC > because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. > > Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual > never includes > the detailed information about for ARCH timer(e.g, clock for ARCH timer). I > knew that > I can get the document of ARCH timer for ARM official site but I think it is > insufficient > to implement ARCH timer on Exynos SoC. What do you mean by "insufficient to implement ARCH timer"? The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
+Cc Inki Dae. Hi, On 01/15/2015 07:26 PM, Marek Szyprowski wrote: > Hello, > > On 2015-01-15 11:10, Tobias Jakobi wrote: >> Marek Szyprowski wrote: This is on a ODROID-X2. >>> The issues with FIMC / DRM FIMC are not related to HDMI patches. They will >>> be handled separately. For the time being simply please disable Exynos IPP >>> (or Exynos DRM FIMC) feature in your kernel configuration. >>> >>> I hope that HDMI display works fine for you. >> OK, I'll check without FIMC again later this day, but what about the >> warning (?) from the mixer: >> exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! >> >> Should this go away as well, when I disable the FIMC? > > Well, I also got this warning. It looks that pm_runtime in Exynos DRM got > changed > recently and the bug is somewhere there. We will also check this issue. > I posted a patch to fix it already. http://www.spinics.net/lists/dri-devel/msg75039.html Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello, On 2015-01-15 11:10, Tobias Jakobi wrote: Marek Szyprowski wrote: This is on a ODROID-X2. The issues with FIMC / DRM FIMC are not related to HDMI patches. They will be handled separately. For the time being simply please disable Exynos IPP (or Exynos DRM FIMC) feature in your kernel configuration. I hope that HDMI display works fine for you. OK, I'll check without FIMC again later this day, but what about the warning (?) from the mixer: exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! Should this go away as well, when I disable the FIMC? Well, I also got this warning. It looks that pm_runtime in Exynos DRM got changed recently and the bug is somewhere there. We will also check this issue. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Marek Szyprowski wrote: This is on a ODROID-X2. > > The issues with FIMC / DRM FIMC are not related to HDMI patches. They will > be handled separately. For the time being simply please disable Exynos IPP > (or Exynos DRM FIMC) feature in your kernel configuration. > > I hope that HDMI display works fine for you. > > Best regards OK, I'll check without FIMC again later this day, but what about the warning (?) from the mixer: exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! Should this go away as well, when I disable the FIMC? With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello,
On 2015-01-14 16:25, Tobias Jakobi wrote:
Hello,
I've applied v6 of the HDMI patchset (together with the patches the set
depends on) onto torvalds/master, but I'm seeing a lot of warnings
(coming from __clk_{unprepare,disable}) that seem to originate from the
fimc subsystem.
Since the patchset also changes PM domain handling (which shows up in
the log as well), I was wondering if this is related?
Full boot log here:
http://www.math.uni-bielefeld.de/~tjakobi/archive/clk_warnings.txt
That's the tree I'm currently using:
https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.19.y
(maybe I'm missing something here?)
With best wishes,
Tobias
PS: This is on a ODROID-X2.
The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
be handled separately. For the time being simply please disable Exynos IPP
(or Exynos DRM FIMC) feature in your kernel configuration.
I hope that HDMI display works fine for you.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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: [RFC 0/3] mmc: Add dynamic frequency scaling
On 15 January 2015 at 10:20, Krzysztof Kozlowski wrote: > On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: >> + Mike, Stephen (Clock maintainers) >> >> On 12 January 2015 at 10:23, Krzysztof Kozlowski >> wrote: >> > Hi, >> > >> > >> > I would like to hear some comments about idea of scaling MMC clock >> > frequency. The basic idea is to lower the clock when device is >> > completely idle or not busy enough. >> >> We already have host drivers that implements runtime PM support. >> Typically that would mean the clock will be gated once the device >> becomes runtime PM suspended. >> >> Why should we decrease the frequency of an already gated clock? > > In case of idle state you're right that clkgate would be better. But > what about finding a compromise between high performance (high > frequency) and energy saving for different loads on MMC? I guess a compromise could be beneficial for some SOC and use cases. At least I remember, ST-Ericsson's UX500 SOC had such an out of tree hack to track MMC load. > > The frequency scaling could help in that case. Anyway I should prepare > some more benchmarks for such conditions. Seems reasonable and please do! Kind regards Uffe -- 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 v3 2/7] ARM: Exynos: add support for sub-power domains
Hello All,
I'm sorry for missing some CC: in this patch, when I posted v3 to
mailing list.
It looks that CC: lines got lost after git am + git format-patch.
Ulf, could you also ack this patch, so Kukjin can finally merge the whole
series to Samsung kernel tree?
On 2015-01-14 14:44, Marek Szyprowski wrote:
This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences for devices
like TV Mixer or Camera ISP, which needs to have more than one power
domain enabled to be operational.
Based on previous work by Amit Daniel Kachhap .
Signed-off-by: Marek Szyprowski
---
.../bindings/arm/exynos/power_domain.txt | 2 ++
arch/arm/mach-exynos/pm_domains.c | 28 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index f4445e5..1e09703 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,8 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+- power-domains: phandle pointing to the parent power domain, for more details
+see Documentation/devicetree/bindings/power/power_domain.txt
Node of a device using power domains must have a power-domains property
defined with a phandle to respective power domain.
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..37266a8 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -161,6 +161,34 @@ no_clk:
of_genpd_add_provider_simple(np, &pd->pd);
}
+ /* Assign the child power domains to their parents */
+ for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
+ struct generic_pm_domain *child_domain, *parent_domain;
+ struct of_phandle_args args;
+
+ args.np = np;
+ args.args_count = 0;
+ child_domain = of_genpd_get_from_provider(&args);
+ if (!child_domain)
+ continue;
+
+ if (of_parse_phandle_with_args(np, "power-domains",
+"#power-domain-cells", 0, &args) != 0)
+ continue;
+
+ parent_domain = of_genpd_get_from_provider(&args);
+ if (!parent_domain)
+ continue;
+
+ if (pm_genpd_add_subdomain(parent_domain, child_domain))
+ pr_warn("%s failed to add subdomain: %s\n",
+ parent_domain->name, child_domain->name);
+ else
+ pr_info("%s has as child subdomain: %s.\n",
+ parent_domain->name, child_domain->name);
+ of_node_put(np);
+ }
+
return 0;
}
arch_initcall(exynos4_pm_init_power_domain);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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: power: reset: add driver for Hardkernel's Odroid boards
Marek Szyprowski wrote: > Right. This patch was posted some time ago and reboot handling on ARM SoCs > have been changed recently in v3.19-rc1. I will post an updated version of > this patch soon. > > Best regards Thanks for the update! Going to wait for the new version then. Wish best wishes, Tobias -- 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: [RFC 0/3] mmc: Add dynamic frequency scaling
On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: > + Mike, Stephen (Clock maintainers) > > On 12 January 2015 at 10:23, Krzysztof Kozlowski > wrote: > > Hi, > > > > > > I would like to hear some comments about idea of scaling MMC clock > > frequency. The basic idea is to lower the clock when device is > > completely idle or not busy enough. > > We already have host drivers that implements runtime PM support. > Typically that would mean the clock will be gated once the device > becomes runtime PM suspended. > > Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Best regards, Krzysztof > I think this boils done to how DVFS transitions can be triggered from > the clock drivers, right? > > Currently the clock framework supports this through clock rate change > notifiers. Should we have clock notifiers for clk_prepare|unprepare() > as well? I do remember that someone posted patches for that a while > ago, but those were rejected. > > Mike, Stephen - comments? > > Kind regards > Uffe > > > > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > > as governor. In idle this gave benefits (less energy consumed during > > idle): > > 1. Trats2 (Exynos4412): 2.6% > > 2. Rinato (Exynos3250): 1% > > > > but (especially on Rinato) it had impact on performance (probably > > because ondemand triggering a little to late). What is interesting > > manually changing the clock (without this patchset) gave slightly > > bigger benefits. Maybe the devfreq introduces noticeable overhead? > > > > > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > > > Best regards, > > Krzysztof > > > > > > Krzysztof Kozlowski (3): > > mmc: Add dynamic frequency scaling > > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > > ARM: dts: Use frequency scaling for MSHC > > > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > > drivers/mmc/card/block.c | 247 > > ++ > > drivers/mmc/core/Kconfig | 16 ++ > > drivers/mmc/core/core.h | 1 - > > drivers/mmc/core/host.c | 2 + > > include/linux/mmc/card.h | 8 + > > include/linux/mmc/host.h | 3 + > > 9 files changed, 282 insertions(+), 2 deletions(-) > > > > -- > > 1.9.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/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
On Wed, 2015-01-14 at 14:56 +0100, Lukasz Majewski wrote: > Hi Sjoerd, > Could you review v2 of this patch series? > > http://www.spinics.net/lists/devicetree/msg63159.html I skimmed it yesterday, I'll try to find some time to send you my review comments later in the week/start of next. Do you happen to have a git branch with these patches in? That would make it convenient for me to give your patches a spin on my XU3 -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Hi Eduardo,
> On Wed, Jan 14, 2015 at 04:01:06PM +0100, Lukasz Majewski wrote:
> > Hi Eduardo,
> >
> > > On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
> > > > On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
> > > > > Odroid U3 fan can work without being registered as OF cooling
> > > > > device (with CONFIG_THERMAL_OF disabled).
> > > > > In this situation it can be controlled via PWM entry at
> > > > > /sys/class/hwmon/hwmon0/pwm1.
> > > > >
> > > > > Therefore, the thermal_of_cooling_device_register() function
> > > > > needs a stub to allow clean compilation.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski
> > > >
> > > > Acked-by: Eduardo Valentin
> > >
> > > Sorry, too fast,
> > >
> > > This is actually
> > > Nacked-by: Eduardo Valentin
> > >
> > > :-)
> > >
> > > I get this error:
> > > drivers/thermal/thermal_core.c:1210:1: error: redefinition of
> > > ‘thermal_of_cooling_device_register’
> > > thermal_of_cooling_device_register(struct device_node *np,
> > > ^
> > > In file included from drivers/thermal/thermal_core.c:34:0:
> > > include/linux/thermal.h:321:1: note: previous definition of
> > > ‘thermal_of_cooling_device_register’ was here
> > >thermal_of_cooling_device_register(struct device_node *np,
> > > ^
> > >
> > >
> > > We provide the function in thermal core even if CONFIG_THERMAL_OF
> > > is not set.
> >
> > Unfortunately the PWM fan subsystem can work perfectly fine without
> > CONFIG_THERMAL.
> >
>
> Now I understand what you are trying to do.
>
> > I think that it would be enough to make something like this in
> > the ./include/linux/thermal.h:
> >
> > #ifdef CONFIG_THERMAL
> Well, I think it should be the opposite here:
>
> #ifndef CONFIG_THERMAL
>
> that is, if no config thermal, then you provide the stub not the other
> way around.
This seems like a better solution :-).
Thanks.
>
> > static inline struct thermal_cooling_device *
> > thermal_of_cooling_device_register(struct
> > device_node *np, char *type, void *devdata,
> >const struct
> > thermal_cooling_device_ops *ops) {
> > return NULL;
> > }
> > #else
> > [ already present declaration of
> > thermal_of_cooling_device_register() ]
> > #endif /* CONFIG_THERMAL */
>
>
> >
> >
> >
> > > >
> > > > > ---
> > > > > Changes for v2:
> > > > > - None
> > > > > ---
> > > > > include/linux/thermal.h | 14 +++---
> > > > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > > > > index 2de3d9e..871123c 100644
> > > > > --- a/include/linux/thermal.h
> > > > > +++ b/include/linux/thermal.h
> > > > > @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct
> > > > > device *dev, int id, void *data, const struct
> > > > > thermal_zone_of_device_ops *ops); void
> > > > > thermal_zone_of_sensor_unregister(struct device *dev, struct
> > > > > thermal_zone_device *tz); +struct thermal_cooling_device *
> > > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > > +char *type, void *devdata,
> > > > > +const struct
> > > > > thermal_cooling_device_ops *); #else
> > > > > static inline struct thermal_zone_device *
> > > > > thermal_zone_of_sensor_register(struct device *dev, int id,
> > > > > void *data, @@ -342,6 +346,13 @@ void
> > > > > thermal_zone_of_sensor_unregister(struct device *dev, {
> > > > > }
> > > > >
> > > > > +static inline struct thermal_cooling_device *
> > > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > > +char *type, void *devdata,
> > > > > +const struct
> > > > > thermal_cooling_device_ops *ops) +{
> > > > > + return NULL;
> > > > > +}
> > > > > #endif
> > > > > struct thermal_zone_device
> > > > > *thermal_zone_device_register(const char *, int, int, void *,
> > > > > struct thermal_zone_device_ops *, @@ -357,9 +368,6 @@ void
> > > > > thermal_zone_device_update(struct thermal_zone_device *);
> > > > > struct thermal_cooling_device
> > > > > *thermal_cooling_device_register(char *, void *, const struct
> > > > > thermal_cooling_device_ops *); -struct thermal_cooling_device
> > > > > * -thermal_of_cooling_device_register(struct device_node *np,
> > > > > char *, void *,
> > > > > -const struct
> > > > > thermal_cooling_device_ops *); void
> > > > > thermal_cooling_device_unregister(struct
> > > > > thermal_cooling_device *); struct thermal_zone_device
> > > > > *thermal_zone_get_zone_by_name(const char *name); int
> > > > > thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
> > > > > long *temp); -- 2.0.0.rc2
> > > > >
> > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRP
[PATCH 0/3] ARM: dts: Regulator changes and fuel gauge for exynos4412-trats2
Hi Kukjin, I grouped into one patchset already posted patches for Trats2 board: 1. Fuel gauge: https://lkml.org/lkml/2015/1/7/167 2. Suspend configuration for max77686 regulators: https://lkml.org/lkml/2014/10/29/262 3. GPIO control for max77686 regulators: https://lkml.org/lkml/2015/1/5/230 The necessary changes in max77686 regulator driver were already applied by Mark Brown. Best regards, Krzysztof Krzysztof Kozlowski (3): ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node ARM: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control arch/arm/boot/dts/exynos4412-trats2.dts | 115 ++-- 1 file changed, 65 insertions(+), 50 deletions(-) -- 1.9.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: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node
Add node for fuel gauge present in Maxim 77693 PMIC. This allows control
over battery charging state on Trats2 board.
The fuel gauge is compatible with max17042 battery driver (Maxim
17042/17047/17050). Although datasheet rev 2.2 for MAX77693 describes
fuel gauge as Maxim 17042-like, the chip on Trats2 board identifies
itself as Maxim 17047-like.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..595ad4ba6977 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -15,6 +15,7 @@
/dts-v1/;
#include "exynos4412.dtsi"
#include
+#include
/ {
model = "Samsung Trats 2 based on Exynos4412";
@@ -24,6 +25,7 @@
i2c9 = &i2c_ak8975;
i2c10 = &i2c_cm36651;
i2c11 = &i2c_max77693;
+ i2c12 = &i2c_max77693_fuel;
};
memory {
@@ -552,6 +554,22 @@
};
};
+ i2c_max77693_fuel: i2c-gpio-3 {
+ compatible = "i2c-gpio";
+ gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>, <&gpf1 4 GPIO_ACTIVE_HIGH>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ max77693-fuel-gauge@36 {
+ compatible = "maxim,max17047";
+ interrupt-parent = <&gpx2>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reg = <0x36>;
+ };
+ };
+
mmc@1255 {
num-slots = <1>;
broken-cd;
--
1.9.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 3/3] ARM: dts: exynos4412-trats2: Switch max77686 regulators to GPIO control
Remove fixed regulators (duplicating what max77686 provides) and
add GPIO enable control to max77686 regulators.
This gives the system full control over those regulators. Previously
the state of such regulators was a mixture of what max77686 driver set
over I2C and what regulator-fixed set through GPIO.
Removal of 'regulator-always-on' from CAM_ISP_CORE_1.2V (buck9) allows
disabling it when it is not used. Previously this regulator was always
enabled because its enable state is a OR of:
- ENB9 GPIO (turned always on by regulator-fixed),
- BUCK9EN field in BUCK9CTRL register (off by max77686 through I2C).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index ef05139506e6..8611c07c2e41 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -58,15 +58,6 @@
#address-cells = <1>;
#size-cells = <0>;
- vemmc_reg: regulator-0 {
- compatible = "regulator-fixed";
- regulator-name = "VMEM_VDD_2.8V";
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
- gpio = <&gpk0 2 0>;
- enable-active-high;
- };
-
cam_io_reg: voltage-regulator-1 {
compatible = "regulator-fixed";
regulator-name = "CAM_SENSOR_A";
@@ -94,16 +85,6 @@
enable-active-high;
};
- cam_isp_core_reg: voltage-regulator-4 {
- compatible = "regulator-fixed";
- regulator-name = "CAM_ISP_CORE_1.2V_EN";
- regulator-min-microvolt = <120>;
- regulator-max-microvolt = <120>;
- gpio = <&gpm0 3 0>;
- enable-active-high;
- regulator-always-on;
- };
-
ps_als_reg: voltage-regulator-5 {
compatible = "regulator-fixed";
regulator-name = "LED_A_3.0V";
@@ -405,6 +386,7 @@
regulator-name = "VTF_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ maxim,ena-gpios = <&gpy2 0
GPIO_ACTIVE_HIGH>;
};
ldo22_reg: ldo22 {
@@ -412,6 +394,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ maxim,ena-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
ldo23_reg: ldo23 {
@@ -518,6 +501,7 @@
regulator-name = "VMEM_VDDF_3.0V";
regulator-min-microvolt = <285>;
regulator-max-microvolt = <285>;
+ maxim,ena-gpios = <&gpk0 2
GPIO_ACTIVE_HIGH>;
};
buck9_reg: buck9 {
@@ -525,6 +509,7 @@
regulator-name = "CAM_ISP_CORE_1.2V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <120>;
+ maxim,ena-gpios = <&gpm0 3
GPIO_ACTIVE_HIGH>;
};
};
};
@@ -587,7 +572,7 @@
broken-cd;
non-removable;
card-detect-delay = <200>;
- vmmc-supply = <&vemmc_reg>;
+ vmmc-supply = <&ldo22_reg>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <0>;
samsung,dw-mshc-sdr-timing = <2 3>;
--
1.9.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: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.
Additionally remove old and not supported bindings:
- regulator-mem-off
- regulator-mem-idle
- regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Chanwoo Choi
---
Previously this was part of [1] patchset. There were no changes in this
patch since last version (v6) of that patchset.
[1] https://lkml.org/lkml/2014/10/29/261
---
arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 595ad4ba6977..ef05139506e6 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -227,7 +227,6 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
};
ldo2_reg: ldo2 {
@@ -236,7 +235,9 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo3_reg: ldo3 {
@@ -245,7 +246,6 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
- regulator-mem-on;
};
ldo4_reg: ldo4 {
@@ -254,7 +254,6 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
- regulator-mem-on;
};
ldo5_reg: ldo5 {
@@ -263,7 +262,6 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
- regulator-mem-on;
};
ldo6_reg: ldo6 {
@@ -272,7 +270,9 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo7_reg: ldo7 {
@@ -281,7 +281,9 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo8_reg: ldo8 {
@@ -289,7 +291,9 @@
regulator-name = "VMIPI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
- regulator-mem-off;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo9_reg: ldo9 {
@@ -297,7 +301,6 @@
regulator-name = "CAM_ISP_MIPI_1.2V";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
+ Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski wrote: > Hi, > > > I would like to hear some comments about idea of scaling MMC clock > frequency. The basic idea is to lower the clock when device is > completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > as governor. In idle this gave benefits (less energy consumed during > idle): > 1. Trats2 (Exynos4412): 2.6% > 2. Rinato (Exynos3250): 1% > > but (especially on Rinato) it had impact on performance (probably > because ondemand triggering a little to late). What is interesting > manually changing the clock (without this patchset) gave slightly > bigger benefits. Maybe the devfreq introduces noticeable overhead? > > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (3): > mmc: Add dynamic frequency scaling > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > ARM: dts: Use frequency scaling for MSHC > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > drivers/mmc/card/block.c | 247 > ++ > drivers/mmc/core/Kconfig | 16 ++ > drivers/mmc/core/core.h | 1 - > drivers/mmc/core/host.c | 2 + > include/linux/mmc/card.h | 8 + > include/linux/mmc/host.h | 3 + > 9 files changed, 282 insertions(+), 2 deletions(-) > > -- > 1.9.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/2] clk: exynos-audss: Fix memory leak on driver unbind or probe failure
On śro, 2015-01-14 at 14:25 -0800, Mike Turquette wrote:
> Quoting Stephen Boyd (2015-01-08 13:23:13)
> > On 01/05/2015 01:52 AM, Krzysztof Kozlowski wrote:
> > > The memory allocated by basic clock divider/gate/mux (struct clk_gate,
> > > clk_divider and clk_mux) was leaking. During driver unbind or probe
> > > failure the driver only unregistered the clocks.
> > >
> > > Use clk_unregister_{gate,divider,mux} to release all resources.
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > >
> >
> > Reviewed-by: Stephen Boyd
>
> I've applied both patches to clk-next. Krzysztof, let me know if you
> would prefer to take the audss patch through the samsung clock branch
> instead (to include it in a later pull request).
Thanks! I'm fine with applying them to clk-next.
Best regards,
Krzysztof
>
> Regards,
> Mike
>
> >
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
--
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
