Re: [PATCH v10 1/2] [media] exynos5-is: Adds DT binding documentation
On 12/13/2013 06:12 AM, Arun Kumar K wrote:
From: Shaik Ameer Bashashaik.am...@samsung.com
The patch adds the DT binding doc for exynos5 SoC camera
subsystem.
Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com
Signed-off-by: Arun Kumar Karun...@samsung.com
---
.../bindings/media/exynos5250-camera.txt | 136
1 file changed, 136 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/exynos5250-camera.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5250-camera.txt
b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
new file mode 100644
index 000..0c36bc4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
@@ -0,0 +1,136 @@
+Samsung EXYNOS5 SoC Camera Subsystem
+
+
+The Exynos5 SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC-LITE,
+MIPI CSIS and FIMC-IS.
+
+The sub-device nodes are referenced using phandles in the common 'camera' node
+which also includes common properties of the whole subsystem not really
+specific to any single sub-device, like common camera port pins or the common
+camera bus clocks.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible : must be samsung,exynos5250-fimc
+- clocks : list of phandles and clock specifiers, corresponding
+ to entries in the clock-names property
+- clock-names : must contain sclk_bayer entry
+- samsung,csis : list of phandles to the mipi-csis device nodes
+- samsung,fimc-lite: list of phandles to the fimc-lite device nodes
+- samsung,fimc-is : phandle to the fimc-is device node
+
+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named default.
+
+'parallel-ports' node
+-
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A, camera B and RGB bay inputs.
+'reg' property in the port nodes specifies the input type:
+ 1 - parallel camport A
+ 2 - parallel camport B
+ 5 - RGB camera bay
+
+3, 4 are for MIPI CSI-2 bus and are already described in samsung-mipi-csis.txt
+
+Required properties:
+
+For describing the input type in the child nodes, the following properties
+have to be present in the parallel-ports node:
+- #address-cells: Must be 1
+- #size-cells: Must be 0
+
+Image sensor nodes
+--
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
+using the common video interfaces bindings, defined in video-interfaces.txt.
Hi Mark,
Could you have a look again at this binding ? Perhaps we could
get your Ack now so it can be merged through the media tree ?
Thanks,
Sylwester
+Example:
+
+ aliases {
+ fimc-lite0 =fimc_lite_0
+ };
+
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@1386 {
+ s5k6aa: sensor@3c {
+ compatible = samsung,s5k6aafx;
+ reg =0x3c;
+ vddio-supply =...;
+
+ clock-frequency =2400;
+ clocks =...;
+ clock-names = mclk;
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint =fimc0_ep;
+ bus-width =8;
+ hsync-active =0;
+ vsync-active =1;
+ pclk-sample =1;
+ };
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@1a {
+ compatible = samsung,s5c73m3;
+ reg =0x1a;
+ vddio-supply =...;
+
+ clock-frequency =2400;
+ clocks =...;
+ clock-names = mclk;
+
+ port {
+ s5c73m3_1: endpoint {
+ data-lanes =1 2 3 4;
+ remote-endpoint =csis0_ep;
+ };
+ };
+ };
+
+ camera {
+ compatible = samsung,exynos5250-fimc;
+ #address-cells =1;
+ #size-cells =1;
+ status = okay;
+
+ pinctrl-names = default;
+ pinctrl-0 =cam_port_a_clk_active;
+
+ samsung,csis =csis_0,csis_1;
+ samsung,fimc-lite =fimc_lite_0,fimc_lite_1,fimc_lite_2;
+ samsung,fimc-is =fimc_is;
+
+ /* parallel camera ports */
+ parallel-ports {
+ #address-cells =1;
+
Re: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs
Hi Abhilash, [ ... ] + * @nr_dvfs_level: Number of dvfs levels supported by member. + * @dvfs_table: Table containing supported ASV freqs and corresponding volts. + * @asv_grp: ASV group of member. + * @flags: ASV flags What are the ASV flags you had in mind ? Right now we don't have any, some thing like delayed init of asv table depending upon dev_node/user(instance) was coming in my mind. Actually I missed to remove it for the time being. Thanks for your review and other suggestions. Regards, Yadwinder -- 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 v2 1/4] power: asv: Add common ASV support for Samsung SoCs
Hi Tomasz,
Thanks for your thorough review and nice suggestions.
[snip]
+}
+
+static struct asv_member *asv_get_mem(enum asv_type_id asv_type)
I don't really like this enum based look-up. It's hard to define an enum
that covers any possible existing and future platforms that would not be
bloated with single platform specific entries. IMHO something string based
could be more scalable.
Yes, I also agree string based look-up will be better. I was thinking
to convert to it,
after initial discussion over the APIs.
+{
+ struct asv_member *asv_mem;
+ struct asv_info *asv_info;
+
+ list_for_each_entry(asv_mem, asv_list, node) {
+ asv_info = asv_mem-asv_info;
+ if (asv_type == asv_info-type)
+ return asv_mem;
+ }
Don't you need any kind of locking here? A mutex in add_asv_member()
suggests that read access to the list should be protected as well.
hmmm, yes should be their for completeness of code.
+
+ return NULL;
+}
+
+unsigned int asv_get_volt(enum asv_type_id target_type,
+ unsigned int target_freq)
Do you need this function at all? I believe this is all about populating
device's OPP array with frequencies and voltages according to its ASV
level. Users will be able to query for required voltage using standard OPP
calls then, without a need for ASV specific functions like this one.
Yes, I had put a comment in initial version after commit message :
Hopefully asv_get_volt() can go out in future, once all users start using OPP
library. , which seems to be missed in this version.
I had kept it for the time being in initial version, to keep it
usable(for testing) with
existing cpufreq drivers, which need to reworked and may take time.
[snip]
+
+ for (i = 0; i asv_info-nr_dvfs_level; i++) {
+ if (dev_pm_opp_add(dev, dvfs_table[i].freq * 1000,
+ dvfs_table[i].volt)) {
+ dev_warn(dev, Failed to add OPP %d\n,
+ dvfs_table[i].freq);
Hmm, shouldn't it be considered a failure instead?
hmm, not really always. Theoretically system with some less(failed to add)
levels can work. Moreover I had prefered to keep it only warning, just to
keep the behaviour of asv_init_opp_table() similar to that of its
counter part of_init_opp_table().
+ continue;
+ }
+ }
+
+ return 0;
+}
+
+static struct asv_member *asv_init_member(struct asv_info *asv_info)
+{
+ struct asv_member *asv_mem;
+ int ret = 0;
+
+ if (!asv_info) {
+ pr_err(No ASV info provided\n);
+ return NULL;
I'd suggest adopting the ERR_PTR() convention, which allows returning more
information about the error.
Will it be really usefull here?, as we are not checking return value
of any function.
Bur for some cases below, i will also like to get it used.
+ }
+
+ asv_mem = kzalloc(sizeof(*asv_mem), GFP_KERNEL);
+ if (!asv_mem) {
+ pr_err(Allocation failed for member: %s\n, asv_info-name);
+ return NULL;
+ }
[snip]
Hmm, I don't see a point of these three separate callbacks above.
In general, I'd suggest a different architecture. I'd see this more as:
1) Platform code registers static platform device to instantiate SoC ASV
driver.
2) SoC specific ASV driver probes, reads group ID from hardware register,
calls register_asv_member() with appropriate DVFS table for detected
group.
3) Driver using ASV calls asv_init_opp_table() with its struct device and
ASV member name, which causes the ASV code to fill device's operating
point using OPP calls.
Now client driver has all the information it needs and the work of ASV
subsystem is done. The control flow between drivers would be much simpler
and no callbacks would have to be called.
Architecture stated above seems to be a subset(one possible way of use),
of the proposed architecture. If someone really have nothing much to do,
he can adopt the above stated approach using this framework also,
callbacks are not mandatory.
Since we usually have more things to do other than only reading
fused group value and simply parsing a table index, so in drivers we have to
implement functions to segregate stuff and different people do it in
different way. Its an attempt to provide a way to keep structure(functions)
similar for easy understanding and factoring out of common code.
Moreover, I feels need of callbacks if we have to do something depending
upon(specific) the user/instance of ASV member. One thing came
in my mind was dev_node may be required if we may think of parsing
ASV table from DT and may be more things in future.
I would like to get rectified, other nit/suggestions stated by you in
next version.
Thanks Regards,
Yadwinder
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a
Re: [RFC v2 1/4] power: asv: Add common ASV support for Samsung SoCs
On Sunday 15 of December 2013 22:30:13 Yadwinder Singh Brar wrote:
[snip]
+
+ return NULL;
+}
+
+unsigned int asv_get_volt(enum asv_type_id target_type,
+ unsigned int target_freq)
Do you need this function at all? I believe this is all about populating
device's OPP array with frequencies and voltages according to its ASV
level. Users will be able to query for required voltage using standard OPP
calls then, without a need for ASV specific functions like this one.
Yes, I had put a comment in initial version after commit message :
Hopefully asv_get_volt() can go out in future, once all users start using OPP
library. , which seems to be missed in this version.
I had kept it for the time being in initial version, to keep it
usable(for testing) with
existing cpufreq drivers, which need to reworked and may take time.
Hmm, at the moment none of cpufreq drivers use ASV, so they need to be
reworked anyway to use it either by the means of a private get_volt
function or OPP framework. I agree that OPP may require more work,
though.
If we decide to keep this function in final version, a comment should be
added saying that its usage is deprecated in favor of generic OPP helpers.
[snip]
+
+ for (i = 0; i asv_info-nr_dvfs_level; i++) {
+ if (dev_pm_opp_add(dev, dvfs_table[i].freq * 1000,
+ dvfs_table[i].volt)) {
+ dev_warn(dev, Failed to add OPP %d\n,
+ dvfs_table[i].freq);
Hmm, shouldn't it be considered a failure instead?
hmm, not really always. Theoretically system with some less(failed to add)
levels can work. Moreover I had prefered to keep it only warning, just to
keep the behaviour of asv_init_opp_table() similar to that of its
counter part of_init_opp_table().
I'm not quite convinced about it. If dev_pm_opp_add() fails, doesn't it mean
that something broke seriously in upper layer and we should propagate the
error down? Especially when looking at opp_add(), the only failure
conditions I can find are memory allocation errors which mean that the
system is unlikely to operate correctly anyway.
+ continue;
+ }
+ }
+
+ return 0;
+}
+
+static struct asv_member *asv_init_member(struct asv_info *asv_info)
+{
+ struct asv_member *asv_mem;
+ int ret = 0;
+
+ if (!asv_info) {
+ pr_err(No ASV info provided\n);
+ return NULL;
I'd suggest adopting the ERR_PTR() convention, which allows returning more
information about the error.
Will it be really usefull here?, as we are not checking return value
of any function.
Why not? Here you have ERR_PTR(-EINVAL), then...
Bur for some cases below, i will also like to get it used.
+ }
+
+ asv_mem = kzalloc(sizeof(*asv_mem), GFP_KERNEL);
+ if (!asv_mem) {
+ pr_err(Allocation failed for member: %s\n, asv_info-name);
+ return NULL;
ERR_PTR(-ENOMEM) here.
These are two completely different error cases.
+ }
[snip]
Hmm, I don't see a point of these three separate callbacks above.
In general, I'd suggest a different architecture. I'd see this more as:
1) Platform code registers static platform device to instantiate SoC ASV
driver.
2) SoC specific ASV driver probes, reads group ID from hardware register,
calls register_asv_member() with appropriate DVFS table for detected
group.
3) Driver using ASV calls asv_init_opp_table() with its struct device and
ASV member name, which causes the ASV code to fill device's operating
point using OPP calls.
Now client driver has all the information it needs and the work of ASV
subsystem is done. The control flow between drivers would be much simpler
and no callbacks would have to be called.
Architecture stated above seems to be a subset(one possible way of use),
of the proposed architecture. If someone really have nothing much to do,
he can adopt the above stated approach using this framework also,
callbacks are not mandatory.
I believe that kernel design principles are to first start with something
simple and then if a real need for an extension shows up then extend
existing code base with missing features.
Since we usually have more things to do other than only reading
fused group value and simply parsing a table index, so in drivers we have to
implement functions to segregate stuff and different people do it in
different way. Its an attempt to provide a way to keep structure(functions)
similar for easy understanding and factoring out of common code.
I fail to see those more things. Could you elaborate a bit about them?
From what I see, all the potential ASV users need is a set of operating
points (frequency:voltage pairs) appropriate for the SoC we are running
on (i.e. matching our ASV group index). Is there
Re: [PATCH v2 1/1] ARM: dts: Add missing clocks for exynos4412 dwmmc node
Thanks for pointing out this, Tomasz. I'll use those patches instead. Regards, Alex On Sat, Dec 14, 2013 at 9:24 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Alex, On Saturday 14 of December 2013 13:21:30 Alex Ling wrote: This patch adds biu and ciu clocks for exynos4412 dwmmc node. Without this patch, dwmmc host driver will skip enabling the two clocks and it will break dwmmc host function on exynos4412. Tested on FriendlyARM TINY4412 board. Signed-off-by: Alex Ling kasiml...@gmail.com --- Changes for v2: - Fix patch description as Mark Rutland suggested arch/arm/boot/dts/exynos4412.dtsi |2 ++ 1 file changed, 2 insertions(+) The patch is correct, but unfortunately it's not the only thing that is wrong with MSHC device tree node for Exynos4x12. Please refer to my series fixing DW-MSHC support on Exynos4x12 (and enabling it on TRATS2 board): http://www.spinics.net/lists/arm-kernel/msg293652.html 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: [PATCH] ARM: s3c64xx: Do not select both CPU_V6 and CPU_V6K at the same time
On 12/14/13 05:15, Tomasz Figa wrote: To use V6K extensions, these symbols must not be selected at the same time, so this patch keeps only CPU_V6K selected for S3C64XX. Signed-off-by: Tomasz Figatomasz.f...@gmail.com --- arch/arm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b64a8ef..4df191b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -731,7 +731,6 @@ config ARCH_S3C64XX select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM select COMMON_CLK - select CPU_V6 select CPU_V6K select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG Squashed with previous patch for CPU_V6K. Thanks, Kukjin -- 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
[GIT PULL 1/7] Samsung fixes for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-fixes for you to fetch changes up to 236940d2c951a84735fdd7b958b5159eaf501784: ARM: dts: Update display clock frequency for Origen-4412 (2013-12-16 04:41:57 +0900) Samsung non-critical fixes for v3.14 - Switch FIFO mode for arch_enable_uart_fifo() - Add missing op_mode for PMIC on exynos5250-arndale - Add missing clock-frequency for CPU on exynos5250 - Fix typo samaung to samsung for exynos5420-pinctrl - Fix display clock-frequency for exynos4210/exynos4412-origen Alexander Shiyan (1): ARM: SAMSUNG: Fix switching FIFO in arch_enable_uart_fifo function Sachin Kamat (4): ARM: dts: Add missing op_mode property to PMIC on Arndale ARM: dts: Add missing frequency property to exynos5250 ARM: dts: Fix a typo in exynos5420-pinctrl.dtsi ARM: dts: Update display clock frequency for Origen-4412 Tushar Behera (1): ARM: dts: Update display clock frequency for Origen-4210 arch/arm/boot/dts/exynos4210-origen.dts | 2 +- arch/arm/boot/dts/exynos4412-origen.dts | 2 +- arch/arm/boot/dts/exynos5250-arndale.dts| 2 ++ arch/arm/boot/dts/exynos5250.dtsi | 2 ++ arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 2 +- arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++ 6 files changed, 9 insertions(+), 3 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
[GIT PULL 2/7] Samsung cleanup for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cleanup for you to fetch changes up to 7c394e7be4d267c02eaaac8fa197a7c1b023c99b: ARM: EXYNOS: Constify clksrc immutable register restore tables (2013-12-12 07:09:33 +0900) Samsung cleanup for v3.14 - remove unused SAMSUNG_GPIOLIB_4BIT and IRQF_DISABLED - constify immutable PMU data table and PM clksrc register - make const struct for sleep_save Daniel Kurtz (3): ARM: EXYNOS: Constify data tables for pmu ARM: SAMSUNG: Let s3c_pm_do_restore_*() take const sleep_save ARM: EXYNOS: Constify clksrc immutable register restore tables Michael Opdenacker (2): ARM: SAMSUNG: remove unused SAMSUNG_GPIOLIB_4BIT Kconfig parameter ARM: SAMSUNG: remove IRQF_DISABLED arch/arm/Kconfig| 1 - arch/arm/mach-exynos/pm.c | 4 ++-- arch/arm/mach-exynos/pmu.c | 14 +++--- arch/arm/mach-s3c24xx/dma.c | 2 +- arch/arm/mach-s3c24xx/simtec-usb.c | 3 +-- arch/arm/mach-s3c64xx/mach-smartq.c | 2 +- arch/arm/plat-samsung/Kconfig | 8 arch/arm/plat-samsung/include/plat/pm.h | 4 ++-- arch/arm/plat-samsung/pm.c | 4 ++-- 9 files changed, 16 insertions(+), 26 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
[GIT PULL 4/7] Samsung dev for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dev for you to fetch changes up to 70bacadbd07248576290de40cc217c06f0f2d3c3: ARM: S3C64XX: Select CPU_V6K instead of CPU_V6 (2013-12-16 04:08:51 +0900) Samsung updates for v3.14 - Skip eint_init() for pinctrl-exynos because of re-executing - Use CPU_V6K for S3C64XX(ARM1176JZF-s) instead of CPU_V6 Mateusz Krawczuk (1): ARM: SAMSUNG: if detected device tree skip irq init for S5P Tomasz Figa (1): ARM: S3C64XX: Select CPU_V6K instead of CPU_V6 arch/arm/Kconfig | 2 +- arch/arm/plat-samsung/s5p-irq-eint.c | 4 2 files changed, 5 insertions(+), 1 deletion(-) -- 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
[GIT PULL 3/7] Samsung defconfig for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig for you to fetch changes up to 54b56e62d20ac0de6e8e12b7efdaf3a1b9b6541c: ARM: exynos_defconfig: increase CONFIG_NR_CPUS value to 8 (2013-12-02 07:33:38 +0900) exynos_defconfig updates for v3.14 - increase number of CPU to 8 for EXYNOS SoCs Bartlomiej Zolnierkiewicz (1): ARM: exynos_defconfig: increase CONFIG_NR_CPUS value to 8 arch/arm/configs/exynos_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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
[GIT PULL 6/7] Samsung DT for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt for you to fetch changes up to e0b51c2eae8ebf10d80530b7a306818252206325: ARM: dts: Update Samsung sysreg binding document (2013-12-16 04:47:38 +0900) Samsung DT updates for v3.14 - Add support Octa Cores for exynos5420 : populate CPU node entries to 8 Cores : extend mct to support 8 local interrupts - Update dwmmc nodes for exynos5250 and exynos5420 : change status property of dwmmc nodes for exynos5250 : move dwmmc nodes from exynos5 to exynos5250 because it's different between exynos5250 and exynos5420 : rename mmc nodes from dwmmc for exynos5 SoCs : add dwmmc nodes for exynos5420 - Add G-Scaler nodes for exynos5420 - Add HS-i2c nodes in exynos5420 : High Speed I2C 7 channels (4 to 10) - Update sysreg binding and node name in exynos4 - Update min voltage on exynos5250-arndale - Move fifo-depth property from boards to exynos5250 SoC : because the fifo-depth property is SoC specific Chander Kashyap (2): clocksource: mct: extend mct to support 8 local interrupts for Exynos5420 ARM: dts: populate cpu node entries to 8 cpus for exynos5420 Leela Krishna Amudala (1): ARM: dts: Add device nodes for GScaler blocks for exynos5420 Sachin Kamat (4): ARM: dts: Update min voltage for vdd_arm on Arndale ARM: dts: Add hs-i2c nodes to exynos5420 ARM: dts: Fix sysreg node name in exynos4.dtsi ARM: dts: Update Samsung sysreg binding document Yuvaraj Kumar C D (5): ARM: dts: Move dwmmc nodes from exynos5.dtsi to exynos5250.dtsi ARM: dts: change status property of dwmmc nodes for exynos5250 ARM: dts: Move fifo-depth property from exynos5250 board dts ARM: dts: rename mmc dts node for exynos5 series ARM: dts: Add dwmmc DT nodes for exynos5420 SOC .../devicetree/bindings/arm/samsung/sysreg.txt | 7 +- .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 + arch/arm/boot/dts/cros5250-common.dtsi | 11 +- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos5.dtsi | 21 --- arch/arm/boot/dts/exynos5250-arndale.dts | 18 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 +- arch/arm/boot/dts/exynos5250-snow.dts | 2 +- arch/arm/boot/dts/exynos5250.dtsi | 36 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 33 arch/arm/boot/dts/exynos5420.dtsi | 194 - drivers/clocksource/exynos_mct.c | 4 + 12 files changed, 280 insertions(+), 66 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
[GIT PULL 5/7] Samsung irq for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-irq for you to fetch changes up to 9403ac88220d79f8822e22c875ad1ebd7ffbea6f: irqchip: exynos-combiner: remove hard-coded irq_base value (2013-12-02 07:15:51 +0900) Samsung irq update for v3.14 - use linear irq domain for exynos-combiner Chander Kashyap (1): irqchip: exynos-combiner: remove hard-coded irq_base value drivers/irqchip/exynos-combiner.c | 15 +++ 1 file changed, 3 insertions(+), 12 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
[GIT PULL 7/7] Samsung SoC for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-soc for you to fetch changes up to 538cfbb4c40ab59688236484138133b8e3e89220: ARM: dts: Add initial support for Arndale Octa board (2013-12-16 05:05:43 +0900) Samsung SoC updates for v3.14 - Add exynos5410 SoC and smdk5410 board support : add supporting SoC and board DT files : add clk-exynos5410 with using CCF - Add exynos5420-arndale-octa board support : basic supporting for Arndale Octa board Sachin Kamat (1): ARM: dts: Add initial support for Arndale Octa board Tarek Dakhran (3): ARM: EXYNOS: Add support for EXYNOS5410 SoC clk: exynos5410: register clocks using common clock framework ARM: dts: Add initial device tree support for EXYNOS5410 .../devicetree/bindings/clock/exynos5410-clock.txt | 54 + arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 72 +++ arch/arm/boot/dts/exynos5410.dtsi | 145 + arch/arm/boot/dts/exynos5420-arndale-octa.dts | 66 ++ arch/arm/mach-exynos/Kconfig | 10 + arch/arm/mach-exynos/common.c | 18 ++ arch/arm/mach-exynos/include/mach/map.h| 1 + arch/arm/mach-exynos/mach-exynos5-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 2 + arch/arm/plat-samsung/include/plat/cpu.h | 8 + arch/arm/plat-samsung/include/plat/map-s5p.h | 3 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5410.c | 239 + include/dt-bindings/clock/exynos5410.h | 32 +++ 15 files changed, 654 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts create mode 100644 arch/arm/boot/dts/exynos5410.dtsi create mode 100644 arch/arm/boot/dts/exynos5420-arndale-octa.dts create mode 100644 drivers/clk/samsung/clk-exynos5410.c create mode 100644 include/dt-bindings/clock/exynos5410.h -- 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 0/6] Exynos device tree clean-up for 3.14
Tomasz Figa wrote: This series intends to fix small problems with Exynos device tree sources that I spotted during my work on other things. The fixes are mostly stylistic, without any funtional changes introduced. Changes sinve v2: - Moved MSHC patches to separate series. - Rebased onto current linux-next. Changes since v1: - Addressed Stephen Warren's comments about MCT binding documentation. Tomasz Figa (6): Documentation: devicetree: Update Exynos MCT bindings description ARM: dts: exynos4: Drop interrupt controller properties from MCT nodes ARM: dts: exynos4x12: Move MCT node to exynos4x12.dtsi ARM: dts: exynos4: Simplify MCT interrupt map ARM: dts: exynos: Fix missing spaces after labels ARM: dts: exynos4: Add missing unit-address of sysreg node .../bindings/timer/samsung,exynos4210-mct.txt | 54 +++--- arch/arm/boot/dts/exynos4.dtsi | 6 +-- arch/arm/boot/dts/exynos4210.dtsi | 23 - arch/arm/boot/dts/exynos4212.dtsi | 24 +- arch/arm/boot/dts/exynos4412.dtsi | 28 +-- arch/arm/boot/dts/exynos4x12.dtsi | 20 arch/arm/boot/dts/exynos5.dtsi | 4 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 +-- arch/arm/boot/dts/exynos5440.dtsi | 2 +- 9 files changed, 78 insertions(+), 89 deletions(-) -- 1.8.4.3 Nice cleanup series. Thanks and will apply. - Kukjin -- 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 7/7] usb: dwc3: exynos: add pm_runtime support
Hi Felipe,
On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
Hi Felipe,
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
return 0;
}
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+ return clk_enable(exynos-clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).
I don't get what you mean but there is something that probably needs
fixing, I guess below makes it better:
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index c93919a..1e5720a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (pm_runtime_suspended(dev))
+ return 0;
+
return __dwc3_exynos_suspend(exynos);
}
Is that what you meant ?
Yes, this is exactly what I meant.
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 7/7] usb: dwc3: exynos: add pm_runtime support
Hi Felipe,
On Fri, Dec 13, 2013 at 01:56:18PM -0600, Felipe Balbi wrote:
On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
Hi Felipe,
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
return 0;
}
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+ return clk_enable(exynos-clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).
I don't get what you mean but there is something that probably needs
fixing, I guess below makes it better:
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index c93919a..1e5720a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (pm_runtime_suspended(dev))
+ return 0;
+
return __dwc3_exynos_suspend(exynos);
}
Is that what you meant ?
note, however, that this is *not* a case where we would fall today. See
that we pm_runtime_get() in probe and only pm_runtime_put() during
remove. So there would never be a case where we would try system
suspend
while device was already runtime suspended.
You are right, while runtime PM is blocked by get_sync() in probe, this
check
doesn't matter.
I have fixed all patches in my testing/next branch anyway, just to make
sure we're idiot-proof when it comes to implementing real runtime pm
later on :-)
cheers
--
balbi
Thank you
--
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
