Re: [PATCH v4 3/5] ARM: EXYNOS: Add support for Exynos secure firmware
2012/11/22, Tomasz Figa t.f...@samsung.com:
Some Exynos-based boards contain secure firmware and must use firmware
operations to set up some hardware.
This patch adds firmware operations for Exynos secure firmware and a way
for board code and device tree to specify that they must be used.
Example of use:
In board code:
...MACHINE_START(...)
/* ... */
.init_early = exynos_firmware_init,
/* ... */
MACHINE_END
In device tree:
/ {
/* ... */
firmware@0203F000 {
compatible = samsung,secure-firmware;
reg = 0x0203F000 0x1000;
};
/* ... */
};
well. amazing, dts is used to describle hardware details, here the
firmware is just a software and reg is the memory the firmware will
use. is this something againest the dt rule?
but it is really simple.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
.../devicetree/bindings/arm/samsung-boards.txt | 10
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/common.h | 2 +
arch/arm/mach-exynos/firmware.c| 70
++
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
5 files changed, 84 insertions(+)
create mode 100644 arch/arm/mach-exynos/firmware.c
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 0bf68be..2168ed3 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -6,3 +6,13 @@ Required root node properties:
- compatible = should be one or more of the following.
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+
+Optional:
+- firmware node, specifying presence and type of secure firmware:
+- compatible: only samsung,secure-firmware is currently
supported
+- reg: address of non-secure SYSRAM used for communication with
firmware
+
+ firmware@0203F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0203F000 0x1000;
+ };
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index a031012..685e4a7 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_EXYNOS4_MCT) += mct.o
obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o
obj-$(CONFIG_ARCH_EXYNOS)+= exynos-smc.o
+obj-$(CONFIG_ARCH_EXYNOS)+= firmware.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index dac146d..5f1d393 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -22,6 +22,8 @@ void exynos4_restart(char mode, const char *cmd);
void exynos5_restart(char mode, const char *cmd);
void exynos_init_late(void);
+void exynos_firmware_init(void);
+
#ifdef CONFIG_PM_GENERIC_DOMAINS
int exynos_pm_late_initcall(void);
#else
diff --git a/arch/arm/mach-exynos/firmware.c
b/arch/arm/mach-exynos/firmware.c
new file mode 100644
index 000..88e3eed
--- /dev/null
+++ b/arch/arm/mach-exynos/firmware.c
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park kyungmin.p...@samsung.com
+ * Tomasz Figa t.f...@samsung.com
+ *
+ * This program is free software,you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+#include linux/init.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include asm/firmware.h
+
+#include mach/map.h
+
+#include smc.h
+
+static int exynos_do_idle(void)
+{
+exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
+return 0;
+}
+
+static int exynos_cpu_boot(int cpu)
+{
+ exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
+ return 0;
+}
+
+static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
+{
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+
+ __raw_writel(boot_addr, boot_reg);
+ return 0;
+}
+
+static const struct firmware_ops exynos_firmware_ops = {
+ .do_idle= exynos_do_idle,
+ .set_cpu_boot_addr = exynos_set_cpu_boot_addr,
+ .cpu_boot = exynos_cpu_boot,
+};
+
+void __init exynos_firmware_init(void)
+{
+ if (of_have_populated_dt()) {
+ struct device_node *nd;
+ const __be32 *addr;
+
+ nd = of_find_compatible_node(NULL, NULL,
+
Re: [PATCH v3 4/6] ARM: EXYNOS: Add support for Exynos secure firmware
2012/11/12, Tomasz Figa t.f...@samsung.com:
Hi Russel,
On Monday 12 of November 2012 09:51:14 Russell King - ARM Linux wrote:
+
+static int exynos_cpu_boot(int cpu)
+{
+ exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
+ return 0;
+}
Same for this (though, what _exactly_ is 'cpu', is it the physical CPU
number or the logical CPU number?)
Yes, it's the physical CPU number.
+
+static int exynos_cpu_boot_reg(int cpu, void __iomem **ptr)
+{
+ *ptr = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ return 0;
+}
This is really bad. What's it trying to do? What is the significance
of the 'ptr' returned? What if a platform doesn't have a boot register?
It returns a pointer to the area where boot code (secondary startup)
address must be stored.
This callback (just as all the firmware callbacks) is optional, if it is
not appropriate for given platform, it will not use it.
However, now when I think of it, it may be better to just add a callback
like set_boot_addr(cpu, addr), which would set boot address of given CPU
without exporting address of its boot register outside firmware code. Are
you OK with this kind of approach?
it seems the firmware_ops you are providing is just for samsung EXYNOS
SMC, esepecially for the boot of secondary physical cpu. then it
really should be namespaced.
more callbacks for a common secure monitor APIs might need to cover
1. boot of 2nd CPU
2. do_idle(might let the other RTOS running on secure mode to be schedued in)
3. call SMC, send param and get feedback from firmware
4. might need to handle the steal time of firmware, firmware is also
taking the CPU time, but linux doesn't know. it will affect the
scheduler of Linux.
Best regards,
--
Tomasz Figa
Samsung Poland RD Center
SW Solution Development, Linux Platform
-barry
--
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 v4 3/5] ARM: EXYNOS: Add support for Exynos secure firmware
On Wednesday 26 December 2012, Barry Song wrote:
/ {
/* ... */
firmware@0203F000 {
compatible = samsung,secure-firmware;
reg = 0x0203F000 0x1000;
};
/* ... */
};
well. amazing, dts is used to describle hardware details, here the
firmware is just a software and reg is the memory the firmware will
use. is this something againest the dt rule?
but it is really simple.
We have for a long time had DT bindings to describe firmware, e.g.
on IBM Power systems, I think this is fine.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 2/2] ASoC: SAMSUNG: Add DT support for i2s
Hi, On Mon, Dec 24, 2012 at 9:33 AM, Padma Venkat padma@gmail.com wrote: Hi, On Sat, Dec 22, 2012 at 12:32 AM, Kukjin Kim kgene@samsung.com wrote: Padma Venkat wrote: Hi, On Wed, Dec 19, 2012 at 10:39 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Dec 19, 2012 at 01:24:14PM +, Grant Likely wrote: On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna padm...@samsung.com wrote: +- compatible : samsung,samsung-i2s Isn't that kind of redundant? :-) The format of the compatible strings should be vendor,part- number-i2s. Please be specific about the part number that you're doing the binding for. For example; use samsung,exynos4210-i2s instead of samsung,exynos-i2s. There are actually versioned IPs here (where the versions are used publically in a few places) but it's not clearly documented which is which. It would be reasonable to use the IP versions here I think. Samsung has three i2s drivers one for s3c24xx, one for s3c2412 and one for rest of the platforms. The above mentioned other platforms has Version 3/4/5 of i2s controllers. This dt binding is for for the i2s Where is the version defined such as 3, 4, 5? So, what is the sound/soc/Samsung/s3c-i2s-v2.[ch]? Versions 3, 4, 5 are defined in dev-audio.c file of corresponding platforms. s3c-i2s-v2 is used in s3c2412 platform. driver that has support for Version 3/4/5 of i2s controller. So samsung,i2s-v5 is okay as compatible name? Please suggest me. I agree with using version here but we need some consensus about that. Any suggestions on i2s compatible name or samsung,i2s-v5 is okay? - 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 Thanks Padma Thanks Padma -- 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] usb: phy: samsung: Add support to set pmu isolation
Hi Doug,
On Fri, Dec 21, 2012 at 10:35 PM, Doug Anderson diand...@chromium.org wrote:
Vivek,
Nothing really serious below and things look good to me, but figured
I'd put a few nits in (sorry!).
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..09f06f8 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,31 @@ Required properties:
- compatible : should be samsung,exynos4210-usbphy
- reg : base physical address of the phy registers and length of memory
mapped
region.
+- #address-cells: should be 1.
+- #size-cells: should be 0.
Doesn't match your example. Probably should be 1.
Oops !! true it is 1, will amend this.
diff --git a/drivers/usb/phy/samsung-usbphy.c
b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..2260029 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ * @hostphy_en_mask: host phy enable mask for PHY CONTROL register
+ *
+ * having different mask for host and device type phy
+ * helps in setting independent masks in case of SoCs like
+ * S5PV210 in which PHY0 and PHY1 enable bits belong to same
+ * register placed at [0] and [1] respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at [0].
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
This is really a devphy_dis_mask, isn't it? AKA: setting to 1
disables the phy and setting to 0 enables the phy.
This is actually 'devphy_en_mask' only. We use it this way:
When pmu_isolation is true, meaning usbphy is isolated from pmu
so we are resetting this bit to disable usbphy, as there in
samsung_usbphy_set_isolation().
+ int hostphy_en_mask;
Code below always uses devphy and only ever inits devphy. I assume
future code will init / use hostphy? Worth moving the hostphy part in
that patch?
Sure will move this in forthcoming patch for host phy.
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +104,66 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*phyctrl_pmureg;
int ref_clk_freq;
- int cpu_type;
+ struct samsung_usbphy_drvdata *drv_data;
nit: const
Will make it const.
+static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_pmu;
+ u32 reg[2];
+ int ret;
+
+ if (!sphy-dev-of_node) {
+ dev_err(sphy-dev, Can't get usb-phy node\n);
+ return -ENODEV;
+ }
+
+ usbphy_pmu = of_get_child_by_name(sphy-dev-of_node, usbphy-pmu);
+ if (!usbphy_pmu)
+ dev_warn(sphy-dev, Can't get usb-phy pmu control node\n);
+
+ ret = of_property_read_u32_array(usbphy_pmu, reg, reg, 2);
nit: use ARRAY_SIZE(reg)
Sure will amend this.
+ if (!ret)
+ sphy-phyctrl_pmureg = ioremap(reg[0], reg[1]);
+
+ of_node_put(usbphy_pmu);
+
+ if (IS_ERR_OR_NULL(sphy-phyctrl_pmureg)) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control
register\n);
I don't think there's any cases where it matters (you'll error out of
the driver if you return an error here), but seems like it might be
nice to set sphy-phyctrl_pmureg to NULL here since other places test
this member against NULL only.
Isn't devm_kzallocing the memory for sphy setting sphy-phyctrl_pmureg to NULL ?
Then, does checking here for IS_ERR_OR_NULL(sphy-phyctrl_pmureg) has
a problem ?
Probably i am not getting what is expected here. :-(
+static inline struct samsung_usbphy_drvdata
+*samsung_usbphy_get_driver_data(struct platform_device *pdev)
{
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(samsung_usbphy_dt_match,
pdev-dev.of_node);
- return (int) match-data;
+ return (struct samsung_usbphy_drvdata *) match-data;
nit: no need for a cast here, I believe.
samsung_usbphy_get_driver_data() is returning (struct
samsung_usbphy_drvdata *)
and the data is actually (void *). So won't we need a cast here.
I am actually getting compile time warnings.
}
- return platform_get_device_id(pdev)-driver_data;
+ return ((struct samsung_usbphy_drvdata *)
+
[PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Changes form v3: - Removing the hostphy_en_mas since this gets used in forthcoming patches only when host phy support is added. - Resolving few nits: - using 'const' specifier for driver data structures. - using ARRAY_SIZE() instead of giving magic number for of_property_read_u32_array() Changes from v2: - Removed the phandle type of device node properties, instead using sub-nodes now. - Removed the property 'samsung,enable-mask' since it is SoC dependent (SoCs like S5PV210 and S3C64XX have different bits to enable/disable phy controller in comparison to exysno4210 onwards). - Maintaining the phy enable mask (which is SoC dependent) for device type phy and host type phy in the driver data. - Re-structuring to get device properties using sub-nodes for 'usbphy-pmu' Changes from v1: - Changed the name of property for phy handler from'samsung,usb-phyctrl' to 'samsung,usb-phyhandle' to make it look more generic. - Similarly 'samsung,phyctrl-reg' is changed to 'samsung,phyhandle-reg' - Added a check for 'samsung,usb-phyhandle' before getting node from phandle. - Putting the node using 'of_node_put()' which had been missed. - Adding necessary check for the pointer in 'samsung_usbphy_set_isolation()' to avoid any NULL pointer dereferencing. - Unmapping the register ioremapped in 'samsung_usbphy_parse_dt_param()'. Based on usb-next branch with Praveen Paneri's patches on top of it. - http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/134476.html - http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131763.html Vivek Gautam (1): usb: phy: samsung: Add support to set pmu isolation .../devicetree/bindings/usb/samsung-usbphy.txt | 31 drivers/usb/phy/samsung-usbphy.c | 145 +--- 2 files changed, 155 insertions(+), 21 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Adding support to parse device node data in order to get
required properties to set pmu isolation for usb-phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 31
drivers/usb/phy/samsung-usbphy.c | 145 +---
2 files changed, 155 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..6b873fd 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,34 @@ Required properties:
- compatible : should be samsung,exynos4210-usbphy
- reg : base physical address of the phy registers and length of memory mapped
region.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+
+- The child node 'usbphy-pmu' to the node usbphy should provide the following
+ information required by usb-phy controller to enable/disable the phy.
+ - reg : base physical address of PHY control register in PMU which
+ enables/disables the phy controller.
+ The size of this register is the total sum of size of all
phy-control
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one phy-control register (like in
S3C64XX) or
+ '0x8' in case we have two phy-control registers (like in Exynos4210)
+ and so on.
+
+Example:
+ - Exysno4210
+
+ usbphy@125B {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,exynos4210-usbphy;
+ reg = 0x125B 0x100;
+
+ usbphy-pmu {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10020704 0x8;
+ };
+ };
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..b9f4f42 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -60,20 +60,42 @@
#define MHZ (1000*1000)
#endif
+#define S3C64XX_USBPHY_ENABLE (0x1 16)
+#define EXYNOS_USBPHY_ENABLE (0x1 0)
+
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
};
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ *
+ * Here we have a separate mask for device type phy.
+ * Having different masks for host and device type phy helps
+ * in setting independent masks in case of SoCs like S5PV210,
+ * in which PHY0 and PHY1 enable bits belong to same register
+ * placed at [0] and [1] respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at [0].
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
+};
+
+/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
* @regs: usb phy register memory base
+ * @phyctrl_pmureg: usb device phy-control pmu register memory base
* @ref_clk_freq: reference clock frequency selection
- * @cpu_type: machine identifier
+ * @drv_data: driver data available for different cpu types
*/
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +103,67 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*phyctrl_pmureg;
int ref_clk_freq;
- int cpu_type;
+ const struct samsung_usbphy_drvdata *drv_data;
};
#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
+static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_pmu;
+ u32 reg[2];
+ int ret;
+
+ if (!sphy-dev-of_node) {
+ dev_err(sphy-dev, Can't get usb-phy node\n);
+ return -ENODEV;
+ }
+
+ usbphy_pmu = of_get_child_by_name(sphy-dev-of_node, usbphy-pmu);
+ if (!usbphy_pmu)
+ dev_warn(sphy-dev, Can't get usb-phy pmu control node\n);
+
+ ret = of_property_read_u32_array(usbphy_pmu, reg, reg,
+ ARRAY_SIZE(reg));
+ if (!ret)
+ sphy-phyctrl_pmureg = ioremap(reg[0], reg[1]);
+
+ of_node_put(usbphy_pmu);
+
+ if (IS_ERR_OR_NULL(sphy-phyctrl_pmureg)) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control register\n);
+ return
Re: [PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Hi Sylwester, On Wed, Dec 26, 2012 at 5:58 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Adding support to parse device node data in order to get required properties to set pmu isolation for usb-phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- Hope these changes align with what architectural changes you had suggested ? -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] EXYNOS4: Add device tree support for USB/EHCI
This patch set adds device tree upport for USB/EHCI device. Dongjin Kim (2): ARM: dts: Add EHCI device tree node for Exynos4 USB: ehci-s5p: Add to get interrupt from DT arch/arm/boot/dts/exynos4.dtsi |7 +++ arch/arm/mach-exynos/mach-exynos4-dt.c |9 + drivers/usb/host/ehci-s5p.c|8 +++- 3 files changed, 23 insertions(+), 1 deletion(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: Add EHCI device tree node for Exynos4
This patch adds EHCI device node on device tree for Exynos4 and defines its
default platform data, s5p_usb_phy_init and s5p_usb_phy_exit, so that those
function can be called from the driver.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
arch/arm/boot/dts/exynos4.dtsi |7 +++
arch/arm/mach-exynos/mach-exynos4-dt.c |9 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 92bca86..df1a9f0 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -140,6 +140,13 @@
status = disabled;
};
+ ehci@1258 {
+ compatible = samsung,exynos-ehci;
+ reg = 0x1258 0x100;
+ interrupts = 0 70 0;
+ status = disabled;
+ };
+
serial@1380 {
compatible = samsung,exynos4210-uart;
reg = 0x1380 0x100;
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 92757ff..c8a23f0 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
#include linux/of_platform.h
#include linux/serial_core.h
+#include linux/platform_data/usb-ehci-s5p.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -20,9 +21,15 @@
#include plat/cpu.h
#include plat/regs-serial.h
+#include plat/usb-phy.h
#include common.h
+static struct s5p_ehci_platdata s5p_ehci_platdata = {
+ .phy_init = s5p_usb_phy_init,
+ .phy_exit = s5p_usb_phy_exit,
+};
+
/*
* The following lookup table is used to override device names when devices
* are registered from device tree. This is temporarily added to enable
@@ -80,6 +87,8 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[]
__initconst = {
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_MDMA1, dma-pl330.2, NULL),
OF_DEV_AUXDATA(samsung,exynos4210-tmu, EXYNOS4_PA_TMU,
exynos-tmu, NULL),
+ OF_DEV_AUXDATA(samsung,exynos-ehci, EXYNOS4_PA_EHCI,
+ s5p-ehci, s5p_ehci_platdata),
{},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: ehci-s5p: Add to get interrupt from DT
This patch support to get interrupt resource from device tree as well as
platform device if ehci node is defined in device tree and it's irq is
described.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
drivers/usb/host/ehci-s5p.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..0fc5e5e 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -16,6 +16,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/platform_data/usb-ehci-s5p.h
#include plat/usb-phy.h
@@ -156,7 +157,12 @@ static int s5p_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- irq = platform_get_irq(pdev, 0);
+ if (pdev-dev.of_node)
+ irq = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ else {
+ irq = platform_get_irq(pdev, 0);
+ }
+
if (!irq) {
dev_err(pdev-dev, Failed to get IRQ\n);
err = -ENODEV;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: ehci-s5p: Add to get interrupt from DT
Hello.
On 12/26/2012 09:42 PM, Dongjin Kim wrote:
This patch support to get interrupt resource from device tree as well as
platform device if ehci node is defined in device tree and it's irq is
described.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
drivers/usb/host/ehci-s5p.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..0fc5e5e 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -16,6 +16,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/platform_data/usb-ehci-s5p.h
#include plat/usb-phy.h
@@ -156,7 +157,12 @@ static int s5p_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- irq = platform_get_irq(pdev, 0);
+ if (pdev-dev.of_node)
+ irq = irq_of_parse_and_map(pdev-dev.of_node, 0);
platform_get_irq() should still work for device tree based platform devices.
I don't see the point on the patch?
+ else {
+ irq = platform_get_irq(pdev, 0);
+ }
Hm, why {} out of the blue? Both arms of *if* are single-stratement.
+
No need for empty line here.
if (!irq) {
dev_err(pdev-dev, Failed to get IRQ\n);
err = -ENODEV;
WBR, Sergei
--
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] cpufreq: exynos: Add the missing cpufreq_cpu_put function
This patch adds the missing cpufreq_cpu_put function needed for returning the cpufreq policy instance. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- drivers/cpufreq/exynos-cpufreq.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 7012ea8..a2b7adc 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -208,6 +208,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block *notifier, } out: mutex_unlock(cpufreq_lock); + cpufreq_cpu_put(policy); return NOTIFY_OK; } -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
On 12/24/2012 09:13 AM, Vivek Gautam wrote:
These two changes look good to me. For both of them:
Reviewed-by: Doug Andersondiand...@chromium.org
Well, I have another idea. Yes, I know, specific chip name should be used.
But
you know the specific chip name in compatible can cause another confusion
on other SoC which has same IP. So I think, we need to consider to use
common name or any specific name not chip in compatible for IP/driver like
following?
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,synopsis-dwc3 },
Or if any version or something, how about following?
+ { .compatible = samsung,dwc-v3 },
Well, yes the newer SoCs with same IP using the chip name can cause some
confusion, but won't it be fine that -
Newer parts using the same core can claim compatibility by
including the older string in the compatible list - as quoted by Grant Likely
Or, can we try another option, using multiple compatible strings for
SoC specific
in of_match_table, so that we don't create any confusion by using same
compatible for newer SoCs also. Like,
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,exynos5250-dwc3 },
+ { .compatible =new SoC using same IP },
Yes, why not just use an SoC name where given IP first appeared ? I believe
IP revision numbers are not always well documented. Also when an IP is
instantiated multiple times in specific SoC, its revision number might not
be sufficient to determine the system integration details for each instance.
I think having version for some devices and SoC name for others just adds
to the confusion. Thus using specific chip name in the compatible property
seems more clear to me.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Hi, On 12/26/2012 02:56 PM, Vivek Gautam wrote: On Wed, Dec 26, 2012 at 5:58 PM, Vivek Gautamgautam.vi...@samsung.com wrote: Adding support to parse device node data in order to get required properties to set pmu isolation for usb-phy. Signed-off-by: Vivek Gautamgautam.vi...@samsung.com --- Hope these changes align with what architectural changes you had suggested ? It looks much better now, thanks! I had a few additional comments, please see my other reply. -- 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 v4] usb: phy: samsung: Add support to set pmu isolation
On Wed, Dec 26, 2012 at 05:58:32PM +0530, Vivek Gautam wrote:
+ if (!ret)
+ sphy-phyctrl_pmureg = ioremap(reg[0], reg[1]);
+
+ of_node_put(usbphy_pmu);
+
+ if (IS_ERR_OR_NULL(sphy-phyctrl_pmureg)) {
No. Learn what the error return values are from functions. Using the
wrong ones is buggy. ioremap() only ever returns NULL on error. You
must check against NULL, and not use the IS_ERR stuff.
+/*
+ * Set isolation here for phy.
+ * SOCs control this by controlling corresponding PMU registers
+ */
+static void samsung_usbphy_set_isolation(struct samsung_usbphy *sphy, int on)
+{
+ u32 reg;
+ int en_mask;
+
+ if (!sphy-phyctrl_pmureg) {
+ dev_warn(sphy-dev, Can't set pmu isolation\n);
+ return;
+ }
+
+ reg = readl(sphy-phyctrl_pmureg);
+
+ en_mask = sphy-drv_data-devphy_en_mask;
+
+ if (on)
+ writel(reg ~en_mask, sphy-phyctrl_pmureg);
+ else
+ writel(reg | en_mask, sphy-phyctrl_pmureg);
What guarantees that this read-modify-write sequence of this register safe?
And, btw, this can't be optimised very well because of the barrier inside
writel(). This would be better:
if (on)
reg = ~en_mask;
else
reg |= en_mask;
writel(reg, sphy-phyctrl_pmureg);
+static inline struct samsung_usbphy_drvdata
+*samsung_usbphy_get_driver_data(struct platform_device *pdev)
{
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(samsung_usbphy_dt_match,
pdev-dev.of_node);
- return (int) match-data;
+ return (struct samsung_usbphy_drvdata *) match-data;
match-data is a const void pointer. Is there a reason you need this
cast here? What if you made the returned pointer from this function
also const and fixed up all its users (no user should modify this
data.)
#ifdef CONFIG_OF
static const struct of_device_id samsung_usbphy_dt_match[] = {
{
.compatible = samsung,s3c64xx-usbphy,
- .data = (void *)TYPE_S3C64XX,
+ .data = (void *)usbphy_s3c64xx,
Why do you need this cast?
}, {
.compatible = samsung,exynos4210-usbphy,
- .data = (void *)TYPE_EXYNOS4210,
+ .data = (void *)usbphy_exynos4,
Ditto.
--
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: EXYNOS4: Add support for rtc wakeup
Set the gic arch extension callback to support rtc wakeup. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- arch/arm/mach-exynos/common.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c index 578a610..bf2ee1d 100644 --- a/arch/arm/mach-exynos/common.c +++ b/arch/arm/mach-exynos/common.c @@ -747,6 +747,8 @@ void __init exynos4_init_irq(void) * uses GIC instead of VIC. */ s5p_init_irq(NULL, 0); + + gic_arch_extn.irq_set_wake = s3c_irq_wake; } void __init exynos5_init_irq(void) -- 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
[PATCH 1/2] i2c: s3c2410: Initialize i2c-gpios[] with requested gpio lines
i2c-gpios[] is being used to free_gpios but it's not getting initialized. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- drivers/i2c/busses/i2c-s3c2410.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index a290d08..f1d1f1e 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -875,6 +875,8 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c) dev_err(i2c-dev, gpio [%d] request failed\n, gpio); goto free_gpio; } + + i2c-gpios[idx] = gpio; } return 0; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] i2c: s3c2410: free gpios in suspend function
While resuming the gpios are being requested again, hence we need to free the gpios before going to suspend otherwise it gives gpio request failed errors while resuming. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- drivers/i2c/busses/i2c-s3c2410.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index f1d1f1e..55c1762 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1172,6 +1172,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); + s3c24xx_i2c_dt_gpio_free(i2c); i2c-suspended = 1; return 0; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: s3c2410: free gpios in suspend function
On 27 December 2012 09:39, Inderpal Singh inderpal.si...@linaro.org wrote: While resuming the gpios are being requested again, hence we need to free the gpios before going to suspend otherwise it gives gpio request failed errors while resuming. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- drivers/i2c/busses/i2c-s3c2410.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index f1d1f1e..55c1762 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1172,6 +1172,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); + s3c24xx_i2c_dt_gpio_free(i2c); i2c-suspended = 1; return 0; -- 1.7.9.5 Please ignore this patch as this has been sent already at http://dics.voicecontrol.ro/process_mails/arata_discutia/174658/%5BPATCH%5D_i2c:_s3c2410:_Add_fix_for_i2c_suspend_resume.html Sorry for the noise !!! -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: s3c2410: Initialize i2c-gpios[] with requested gpio lines
On 27 December 2012 09:39, Inderpal Singh inderpal.si...@linaro.org wrote: i2c-gpios[] is being used to free_gpios but it's not getting initialized. Signed-off-by: Inderpal Singh inderpal.si...@linaro.org --- drivers/i2c/busses/i2c-s3c2410.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index a290d08..f1d1f1e 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -875,6 +875,8 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c) dev_err(i2c-dev, gpio [%d] request failed\n, gpio); goto free_gpio; } + + i2c-gpios[idx] = gpio; } return 0; -- 1.7.9.5 Please ignore this patch as this has been sent already at http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg10781.html Sorry for the noise !!! -- 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 1/3] ARM: dts: exynos5: Set up power domain for MFC,G-scaler,MAU and ISP
Hi all,
Any comments on this patch ?
Thanks,
Prasanna
On Thu, Dec 20, 2012 at 5:56 PM, Prasanna Kumar prasanna...@samsung.com wrote:
This patch adds device tree nodes for MFC,G-scaler,MAU and ISP power domains
of exynos5.It binds these power-domain nodes to repsective device tree nodes.
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 581e57a..71a37bd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -83,6 +83,7 @@
compatible = samsung,mfc-v6;
reg = 0x1100 0x1;
interrupts = 0 96 0;
+ samsung,power-domain = pd_mfc;
};
rtc {
@@ -283,6 +284,7 @@
samsung,supports-rstclr;
samsung,supports-secdai;
samsung,idma-addr = 0x0300;
+ samsung,power-domain = pd_mau;
};
i2s_1: i2s@12D6 {
@@ -578,28 +580,51 @@
};
};
+ pd_gsc: gsc-power-domain@0x10044000 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044000 0x20;
+ };
+
+ pd_isp: isp-power-domain@0x10044020 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044020 0x20;
+ };
+
+ pd_mfc: mfc-power-domain@0x10044040 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044040 0x20;
+ };
+
+ pd_mau: mau-power-domain@0x100440C0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440C0 0x20;
+ };
gsc_0: gsc@0x13e0 {
compatible = samsung,exynos5-gsc;
reg = 0x13e0 0x1000;
interrupts = 0 85 0;
+ samsung,power-domain = pd_gsc;
};
gsc_1: gsc@0x13e1 {
compatible = samsung,exynos5-gsc;
reg = 0x13e1 0x1000;
interrupts = 0 86 0;
+ samsung,power-domain = pd_gsc;
};
gsc_2: gsc@0x13e2 {
compatible = samsung,exynos5-gsc;
reg = 0x13e2 0x1000;
interrupts = 0 87 0;
+ samsung,power-domain = pd_gsc;
};
gsc_3: gsc@0x13e3 {
compatible = samsung,exynos5-gsc;
reg = 0x13e3 0x1000;
interrupts = 0 88 0;
+ samsung,power-domain = pd_gsc;
};
hdmi {
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Thanks
Prasanna Kumar
--
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
