Re: [PATCH v3 03/16] clk: exynos5420: update clocks for GSCL and MSCL blocks
Hi Shaik
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch adds the missing GSCL and MSCL block clocks
and corrects some wrong parent-child relationships.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Looks ok
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 41
+---
include/dt-bindings/clock/exynos5420.h |2 +-
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 972da5d..c3c8ceb 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -80,6 +80,7 @@
#define DIV_PERIC4 0x10568
#define SCLK_DIV_ISP0 0x10580
#define SCLK_DIV_ISP1 0x10584
+#define DIV2_RATIO00x10590
#define GATE_BUS_TOP 0x10700
#define GATE_BUS_FSYS0 0x10740
#define GATE_BUS_PERIC 0x10750
@@ -165,6 +166,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_PERIC4,
SCLK_DIV_ISP0,
SCLK_DIV_ISP1,
+ DIV2_RATIO0,
GATE_BUS_TOP,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
@@ -572,6 +574,11 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
DIV(0, dout_pre_spi1, dout_spi1, DIV_PERIC4, 16, 8),
DIV(0, dout_pre_spi2, dout_spi2, DIV_PERIC4, 24, 8),
+ /* GSCL Block */
+ DIV(0, dout_gscl_blk_300, mout_user_aclk300_gscl,
+ DIV2_RATIO0, 4, 2),
+ DIV(0, dout_gscl_blk_333, aclk333_432_gscl, DIV2_RATIO0, 6, 2),
+
/* ISP Block */
DIV(0, dout_aclk400_isp, mout_aclk400_isp, DIV_TOP0, 0, 3),
DIV(0, dout_aclk333_432_isp0, mout_aclk333_432_isp0,
@@ -666,9 +673,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE(CLK_SCLK_USBD301, sclk_unipro, dout_unipro,
SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_SCLK_GSCL_WA, sclk_gscl_wa, aclK333_432_gscl,
+ GATE(CLK_SCLK_GSCL_WA, sclk_gscl_wa, mout_user_aclk333_432_gscl,
GATE_TOP_SCLK_GSCL, 6, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_SCLK_GSCL_WB, sclk_gscl_wb, aclk333_432_gscl,
+ GATE(CLK_SCLK_GSCL_WB, sclk_gscl_wb, mout_user_aclk333_432_gscl,
GATE_TOP_SCLK_GSCL, 7, CLK_SET_RATE_PARENT, 0),
/* Display */
@@ -766,22 +773,25 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE(CLK_GSCL0, gscl0, aclk300_gscl, GATE_IP_GSCL0, 0, 0, 0),
GATE(CLK_GSCL1, gscl1, aclk300_gscl, GATE_IP_GSCL0, 1, 0, 0),
- GATE(CLK_CLK_3AA, clk_3aa, aclk300_gscl, GATE_IP_GSCL0, 4, 0, 0),
+ GATE(CLK_FIMC_3AA, fimc_3aa, aclk333_432_gscl,
+ GATE_IP_GSCL0, 4, 0, 0),
- GATE(CLK_SMMU_3AA, smmu_3aa, aclk333_432_gscl, GATE_IP_GSCL1, 2,
0,
- 0),
- GATE(CLK_SMMU_FIMCL0, smmu_fimcl0, aclk333_432_gscl,
+ GATE(CLK_SMMU_3AA, smmu_3aa, dout_gscl_blk_333,
+ GATE_IP_GSCL1, 2, 0, 0),
+ GATE(CLK_SMMU_FIMCL0, smmu_fimcl0, dout_gscl_blk_333,
GATE_IP_GSCL1, 3, 0, 0),
- GATE(CLK_SMMU_FIMCL1, smmu_fimcl1, aclk333_432_gscl,
+ GATE(CLK_SMMU_FIMCL1, smmu_fimcl1, dout_gscl_blk_333,
GATE_IP_GSCL1, 4, 0, 0),
- GATE(CLK_SMMU_GSCL0, smmu_gscl0, aclk300_gscl, GATE_IP_GSCL1, 6,
0,
- 0),
- GATE(CLK_SMMU_GSCL1, smmu_gscl1, aclk300_gscl, GATE_IP_GSCL1, 7,
0,
- 0),
- GATE(CLK_GSCL_WA, gscl_wa, aclk300_gscl, GATE_IP_GSCL1, 12, 0, 0),
- GATE(CLK_GSCL_WB, gscl_wb, aclk300_gscl, GATE_IP_GSCL1, 13, 0, 0),
- GATE(CLK_SMMU_FIMCL3, smmu_fimcl3,, aclk333_432_gscl,
+ GATE(CLK_SMMU_GSCL0, smmu_gscl0, dout_gscl_blk_300,
+ GATE_IP_GSCL1, 6, 0, 0),
+ GATE(CLK_SMMU_GSCL1, smmu_gscl1, dout_gscl_blk_300,
+ GATE_IP_GSCL1, 7, 0, 0),
+ GATE(CLK_GSCL_WA, gscl_wa, sclk_gscl_wa, GATE_IP_GSCL1, 12, 0, 0),
+ GATE(CLK_GSCL_WB, gscl_wb, sclk_gscl_wb, GATE_IP_GSCL1, 13, 0, 0),
+ GATE(CLK_SMMU_FIMCL3, smmu_fimcl3,, dout_gscl_blk_333,
GATE_IP_GSCL1, 16, 0, 0),
+ GATE(0, fimc_lite0, aclk333_432_gscl, GATE_IP_GSCL0, 5, 0, 0),
+ GATE(0, fimc_lite1, aclk333_432_gscl, GATE_IP_GSCL0, 6, 0, 0),
GATE(CLK_FIMC_LITE3, fimc_lite3, aclk333_432_gscl,
GATE_IP_GSCL1, 17, 0, 0),
@@ -818,6 +828,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1, GATE_IP_DISP1, 9,
0,
0),
+ /* gating of aclk300_gscl causes system hang. It should not be gated.
*/
[nit] Probably
Re: [PATCH v3 04/16] clk: exynos5420: correct clock parents for mscl sysmmu
Hi Shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index c3c8ceb..9da85ac 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -579,6 +579,9 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
DIV2_RATIO0, 4, 2),
DIV(0, dout_gscl_blk_333, aclk333_432_gscl, DIV2_RATIO0, 6, 2),
+ /* MSCL Blk */
+ DIV(0, dout_mscl_blk, aclk400_mscl, DIV2_RATIO0, 28, 2),
+
/* ISP Block */
DIV(0, dout_aclk400_isp, mout_aclk400_isp, DIV_TOP0, 0, 3),
DIV(0, dout_aclk333_432_isp0, mout_aclk333_432_isp0,
@@ -820,12 +823,12 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE(CLK_MSCL0, mscl0, aclk400_mscl, GATE_IP_MSCL, 0, 0, 0),
GATE(CLK_MSCL1, mscl1, aclk400_mscl, GATE_IP_MSCL, 1, 0, 0),
GATE(CLK_MSCL2, mscl2, aclk400_mscl, GATE_IP_MSCL, 2, 0, 0),
- GATE(CLK_SMMU_MSCL0, smmu_mscl0, aclk400_mscl, GATE_IP_MSCL, 8, 0,
- 0),
- GATE(CLK_SMMU_MSCL1, smmu_mscl1, aclk400_mscl, GATE_IP_MSCL, 9, 0,
- 0),
- GATE(CLK_SMMU_MSCL2, smmu_mscl2, aclk400_mscl, GATE_IP_MSCL, 10,
0,
- 0),
+ GATE(CLK_SMMU_MSCL0, smmu_mscl0, dout_mscl_blk,
+ GATE_IP_MSCL, 8, 0, 0),
+ GATE(CLK_SMMU_MSCL1, smmu_mscl1, dout_mscl_blk,
+ GATE_IP_MSCL, 9, 0, 0),
+ GATE(CLK_SMMU_MSCL2, smmu_mscl2, dout_mscl_blk,
+ GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1, GATE_IP_DISP1, 9,
0,
0),
/* gating of aclk300_gscl causes system hang. It should not be gated.
*/
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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 v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v6:
- Addressed review comments:
-- Sorted config entries in Kconfig and Makefile
-- Made #define to_usbdrd_phy(inst) to a static inline routine.
-- Restructured exynos5_rate_to_clk() as suggested.
-- Amended 'val' field for regmap_update_bits() in the routine
exynos5_usbdrd_phy_isol().
-- Removed sentinel entry from exynos5_usbdrd_phy_cfg[] struct.
-- Removed check for 'match' entry in probe().
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 627
4 files changed, 679 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..daa1707 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -159,6 +159,17 @@ config PHY_EXYNOS5250_USB2
particular SoC is compiled in the driver. In case of Exynos 5250 four
phys are available - device, host, HSIC0 and HSIC.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
config PHY_XGENE
tristate APM X-Gene 15Gbps PHY support
depends on HAS_IOMEM OF (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..333ba98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_PHY_SAMSUNG_USB2)+=
phy-samsung-usb2.o
obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..bc381e3
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@
[PATCH v7 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v6:
- Rebased on top of [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver.
drivers/phy/phy-exynos5-usbdrd.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index bc381e3..6e8540e 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -23,6 +23,7 @@
#include linux/mutex.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/regulator/consumer.h
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -170,6 +171,7 @@ struct exynos5_usbdrd_phy {
} phys[EXYNOS5_DRDPHYS_NUM];
u32 extrefclk;
struct clk *ref_clk;
+ struct regulator *vbus;
};
static inline
@@ -438,6 +440,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -445,10 +448,24 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd-ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd-vbus) {
+ ret = regulator_enable(phy_drd-vbus);
+ if (ret) {
+ dev_err(phy_drd-dev, Failed to enable VBUS supply\n);
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst-phy_cfg-phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd-ref_clk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -461,6 +478,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst-phy_cfg-phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd-vbus)
+ regulator_disable(phy_drd-vbus);
+
clk_disable_unprepare(phy_drd-ref_clk);
return 0;
@@ -583,6 +604,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return ret;
}
+ /* Get Vbus regulator */
+ phy_drd-vbus = devm_regulator_get(dev, vbus);
+ if (IS_ERR(phy_drd-vbus)) {
+ ret = PTR_ERR(phy_drd-vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS supply regulator\n);
+ phy_drd-vbus = NULL;
+ }
+
dev_vdbg(dev, Creating usbdrd_phy phy\n);
for (i = 0; i EXYNOS5_DRDPHYS_NUM; i++) {
--
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 v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
Hi Tomasz, Please share your opinion. Regards, Rahul Sharma On 26 April 2014 16:31, Kukjin Kim kgene@samsung.com wrote: Rahul Sharma wrote: Hi Kukjin, Hi, Need this macro to enable build for clock driver. I found it in your patch, clk/exynos5260: add clock file for exynos5260. For consistency, I'm fine on this, if Tomasz has no objection me to pick this into samsung tree for the 5260 clock stuff drivers/clk/samsung/Makefile. Thanks, Kukjin Regards, Rahul Sharma. On 22 April 2014 15:36, Kukjin Kim kgene@samsung.com wrote: Tomasz Figa wrote: On 16.04.2014 10:08, Sachin Kamat wrote: Hi Tomasz, On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Rahul, On 16.04.2014 05:58, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach- exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y Is this patch necessary now? After Sachin's consolidation series there are no per SoC entries anymore. Kukjin still wanted individual SoCs to be selectable. Please refer [1]. [1] http://www.spinics.net/lists/devicetree/msg27040.html I don't think any valid reason was presented there. Features in code should not be selected using #ifdef CONFIG_ anymore, so I don't really see any reason to not proceed with this consolidation. Olof, Arnd? Hi, Yeah, in this case, nothing happened with adding SOC_EXYNOS5260. So I don't have any idea why this is required. - 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 2/2 v4] i2c: exynos5: configure fifo_depth based on HSI2C module variant
Hello Wolfram, On 13 March 2014 00:50, Wolfram Sang w...@the-dreams.de wrote: On Fri, Feb 07, 2014 at 10:13:15AM +0530, Naveen Krishna Chatradhi wrote: fifo_depth of the HSI2C is not constant Exynos5420 and Exynos5250 supports fifo_depth of 64bytes Exynos5260 supports fifo_depth of 16bytes. This patch configures the fifo_depth based on HSI2C modules version. Signed-off-by: Naveen Krishna Chatradhi ich.nav...@samsung.com [For finding out the difference and initial contribution] Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com I know Tomasz said differently, but I prefer the patches squashed (and the commit message extended). Please accept my apologies for coming back late on this CL. Will squash and fix the compilation error and submit. Thanks, -- Shine bright, (: Nav :) -- 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 02/16] clk: exynos5420: add clocks for ISP block
Hi Alim,
Thanks for the review comments.
On Fri, Apr 25, 2014 at 10:14 AM, Alim Akhtar alim.akh...@gmail.com wrote:
Hi Shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch adds missing clocks for ISP block
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 80
++
1 file changed, 80 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 389d4b1..972da5d 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -57,6 +57,7 @@
#define SRC_FSYS 0x10244
#define SRC_PERIC0 0x10250
#define SRC_PERIC1 0x10254
+#define SRC_ISP0x10270
#define SRC_TOP10 0x10280
#define SRC_TOP11 0x10284
#define SRC_TOP12 0x10288
@@ -77,12 +78,15 @@
#define DIV_PERIC2 0x10560
#define DIV_PERIC3 0x10564
#define DIV_PERIC4 0x10568
+#define SCLK_DIV_ISP0 0x10580
+#define SCLK_DIV_ISP1 0x10584
#define GATE_BUS_TOP 0x10700
#define GATE_BUS_FSYS0 0x10740
#define GATE_BUS_PERIC 0x10750
#define GATE_BUS_PERIC10x10754
#define GATE_BUS_PERIS00x10760
#define GATE_BUS_PERIS10x10764
+#define GATE_TOP_SCLK_ISP 0x10870
#define GATE_IP_GSCL0 0x10910
#define GATE_IP_GSCL1 0x10920
#define GATE_IP_MFC0x1092c
@@ -145,6 +149,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SRC_MASK_FSYS,
SRC_MASK_PERIC0,
SRC_MASK_PERIC1,
+ SRC_ISP,
DIV_TOP0,
DIV_TOP1,
DIV_TOP2,
@@ -158,12 +163,15 @@ static unsigned long exynos5420_clk_regs[] __initdata
= {
DIV_PERIC2,
DIV_PERIC3,
DIV_PERIC4,
+ SCLK_DIV_ISP0,
+ SCLK_DIV_ISP1,
GATE_BUS_TOP,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
GATE_BUS_PERIS1,
+ GATE_TOP_SCLK_ISP,
GATE_IP_GSCL0,
GATE_IP_GSCL1,
GATE_IP_MFC,
@@ -250,6 +258,15 @@ PNAME(mout_user_aclk200_fsys_p)= {fin_pll,
mout_sw_aclk200_fsys};
PNAME(mout_sw_aclk200_fsys2_p) = {dout_aclk200_fsys2, mout_sclk_spll};
PNAME(mout_user_aclk200_fsys2_p) = {fin_pll, mout_sw_aclk200_fsys2};
+PNAME(mout_sw_aclk400_isp_p) = {dout_aclk400_isp, mout_sclk_spll};
+PNAME(mout_user_aclk400_isp_p) = {fin_pll, mout_sw_aclk400_isp};
+
+PNAME(mout_sw_aclk333_432_isp0_p) = {dout_aclk333_432_isp0,
+ mout_sclk_spll};
+PNAME(mout_user_aclk333_432_isp0_p) = {fin_pll,
mout_sw_aclk333_432_isp0};
+
+PNAME(mout_sw_aclk333_432_isp_p) = {dout_aclk333_432_isp,
mout_sclk_spll};
+PNAME(mout_user_aclk333_432_isp_p) = {fin_pll, mout_sw_aclk333_432_isp};
PNAME(mout_sw_aclk200_p) = {dout_aclk200, mout_sclk_spll};
PNAME(mout_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
@@ -265,6 +282,7 @@ PNAME(mout_user_aclk166_p) = {fin_pll,
mout_sw_aclk166};
PNAME(mout_sw_aclk266_p) = {dout_aclk266, mout_sclk_spll};
PNAME(mout_user_aclk266_p) = {fin_pll, mout_sw_aclk266};
+PNAME(mout_user_aclk266_isp_p) = {fin_pll, mout_sw_aclk266};
PNAME(mout_sw_aclk333_432_gscl_p) = {dout_aclk333_432_gscl,
mout_sclk_spll};
PNAME(mout_user_aclk333_432_gscl_p) = {fin_pll,
mout_sw_aclk333_432_gscl};
@@ -448,6 +466,31 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
+ MUX(0, mout_aclk400_isp, mout_group1_p, SRC_TOP0, 0, 2),
+ MUX(0, mout_sw_aclk400_isp, mout_sw_aclk400_isp_p,
+ SRC_TOP10, 0, 1),
+ MUX(0, mout_user_aclk400_isp, mout_user_aclk400_isp_p,
+ SRC_TOP3, 0, 1),
+ MUX(0, mout_aclk333_432_isp0, mout_group4_p, SRC_TOP1, 12, 2),
+ MUX(0, mout_sw_aclk333_432_isp0, mout_sw_aclk333_432_isp0_p,
+ SRC_TOP11, 12, 1),
+ MUX(0, mout_user_aclk333_432_isp0, mout_user_aclk333_432_isp0_p,
+ SRC_TOP4, 12, 1),
+ MUX(0, mout_aclk333_432_isp, mout_group4_p,
+ SRC_TOP1, 4, 2),
+ MUX(0, mout_sw_aclk333_432_isp, mout_sw_aclk333_432_isp_p,
+ SRC_TOP11, 4, 1),
+ MUX(0, mout_user_aclk333_432_isp, mout_user_aclk333_432_isp_p,
+ SRC_TOP4, 4, 1),
+ MUX(0, mout_user_aclk266_isp, mout_user_aclk266_isp_p,
+ SRC_TOP4, 16, 1),
+
It is nice to sort then based on the same order as mentioned in there
register discription. Thats really halps in fast review. And to be
Re: [PATCH 1/2 v4] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
Hello Wolfram,
On 13 March 2014 00:48, Wolfram Sang w...@the-dreams.de wrote:
On Fri, Feb 07, 2014 at 10:12:51AM +0530, Naveen Krishna Chatradhi wrote:
This patch adds a new compatible and uses variant struct to support
HSI2C module on Exynos5260. Updates the Documentation dt bindings.
Also resets the module as an init sequence (Needed by Exynos5260).
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch has clearly not been tested :( Build failure!
comma was missing, Not sure, how i missed it.
Will fix it.
+struct exynos_hsi2c_variant {
+ unsigned intfifo_depth;
+};
Why so many tabs? In general, I'd prefer one space.
- exynos5_i2c_init(i2c);
+ exynos5_i2c_reset(i2c);
Is this a related change?
Exynos5260 needs the HSI2C module to be reset during the init.
As per Tomasz's comment on earlier version. We will reset the status
during init for every SoC.
--
Shine bright,
(: Nav :)
--
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 v12 00/31] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote: The current exynos-iommu(System MMU) driver does not work autonomously since it is lack of support for power management of peripheral blocks. For example, MFC device driver must ensure that its System MMU is disabled before MFC block is power-down not to invalidate IOTLB in the System MMU when I/O memory mapping is changed. Because a System MMU resides in the same H/W block, access to control registers of System MMU while the H/W block is turned off must be prohibited. This set of changes solves the above problem with setting each System MMUs as the parent of the device which owns the System MMU to receive the information when the device is turned off or turned on. Another big change to the driver is the support for devicetree. The bindings for System MMU is described in Documentation/devicetree/bindings/arm/samsung/system-mmu.txt Sorry I've been absent from the review so far. Most of the patches seem entirely reasonable to me, but I'm worried about the DT binding aspect. We are going to see more systems shipping with IOMMUs now, and we are seeing an increasing number of submissions for 64-bit systems. We really have to work out what the DT representation for IOMMUs should look like in general before adding another ad-hod implementation that is private to one driver. 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
[PATCH] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
HSI2C module on Exynos5260 differs from current modules in
following ways:
1. HSI2C on Exynos5260 has fifo_depth of 16bytes
2. Module needs to be reset as a part of init sequence.
Hence, Following changes are involved.
1. Add a new compatible string and Updates the Documentation dt bindings.
2. Introduce a variant struct to support the changes in H/W
3. Reset the module during init. Thus, bringing the module back
to default state irrespective of what firmware did with it.
Signed-off-by: Naveen Krishna Chatradhi ich.nav...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
This patch is under review at https://lkml.org/lkml/2014/2/6/590
and https://lkml.org/lkml/2014/2/6/151
As per Wolfram's comments, both the patches were squashed here.
.../devicetree/bindings/i2c/i2c-exynos5.txt| 11 +++-
drivers/i2c/busses/i2c-exynos5.c | 67
2 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
index 056732c..d4745e3 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -5,7 +5,14 @@ at various speeds ranging from 100khz to 3.4Mhz.
Required properties:
- compatible: value should be.
- - samsung,exynos5-hsi2c, for i2c compatible with exynos5 hsi2c.
+ - samsung,exynos5-hsi2c, (DEPRECATED)
+ for i2c compatible with HSI2C available
+ on Exynos5250 and Exynos5420 SoCs.
+ - samsung,exynos5250-hsi2c, for i2c compatible with HSI2C available
+ on Exynos5250 and Exynos5420 SoCs.
+ - samsung,exynos5260-hsi2c, for i2c compatible with HSI2C available
+ on Exynos5260 SoCs.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -26,7 +33,7 @@ Optional properties:
Example:
hsi2c@12ca {
- compatible = samsung,exynos5-hsi2c;
+ compatible = samsung,exynos5250-hsi2c;
reg = 0x12ca 0x100;
interrupts = 56;
clock-frequency = 10;
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 00af0a0..043d6d8 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -76,12 +76,6 @@
#define HSI2C_RXFIFO_TRIGGER_LEVEL(x) ((x) 4)
#define HSI2C_TXFIFO_TRIGGER_LEVEL(x) ((x) 16)
-/* As per user manual FIFO max depth is 64bytes */
-#define HSI2C_FIFO_MAX 0x40
-/* default trigger levels for Tx and Rx FIFOs */
-#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
-#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
-
/* I2C_TRAILING_CTL Register bits */
#define HSI2C_TRAILING_COUNT (0xf)
@@ -183,14 +177,54 @@ struct exynos5_i2c {
* 2. Fast speed upto 1Mbps
*/
int speed_mode;
+
+ /* Version of HS-I2C Hardware */
+ struct exynos_hsi2c_variant *variant;
+};
+
+/**
+ * struct exynos_hsi2c_variant - platform specific HSI2C driver data
+ * @fifo_depth: the fifo depth supported by the HSI2C module
+ *
+ * Specifies platform specific configuration of HSI2C module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct exynos_hsi2c_variant {
+ unsigned intfifo_depth;
+};
+
+static const struct exynos_hsi2c_variant exynos5250_hsi2c_data = {
+ .fifo_depth = 64,
+};
+
+static const struct exynos_hsi2c_variant exynos5260_hsi2c_data = {
+ .fifo_depth = 16,
};
static const struct of_device_id exynos5_i2c_match[] = {
- { .compatible = samsung,exynos5-hsi2c },
- {},
+ {
+ .compatible = samsung,exynos5-hsi2c,
+ .data = exynos5250_hsi2c_data
+ }, {
+ .compatible = samsung,exynos5250-hsi2c,
+ .data = exynos5250_hsi2c_data
+ }, {
+ .compatible = samsung,exynos5260-hsi2c,
+ .data = exynos5260_hsi2c_data
+ }, {},
};
MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
+static inline struct exynos_hsi2c_variant *exynos5_i2c_get_variant
+ (struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos5_i2c_match, pdev-dev.of_node);
+ return (struct exynos_hsi2c_variant *)match-data;
+}
+
static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
{
writel(readl(i2c-regs + HSI2C_INT_STATUS),
@@ -415,7 +449,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
fifo_status = readl(i2c-regs + HSI2C_FIFO_STATUS);
fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
[PATCH 2/4] usb: ehci-exynos: Use struct device instead of platform_device
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-exynos.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..4d763dc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -50,9 +50,8 @@ struct exynos_ehci_hcd {
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
-static void exynos_setup_vbus_gpio(struct platform_device *pdev)
+static void exynos_setup_vbus_gpio(struct device *dev)
{
- struct device *dev = pdev-dev;
int err;
int gpio;
@@ -88,7 +87,7 @@ static int exynos_ehci_probe(struct platform_device *pdev)
if (err)
return err;
- exynos_setup_vbus_gpio(pdev);
+ exynos_setup_vbus_gpio(pdev-dev);
hcd = usb_create_hcd(exynos_ehci_hc_driver,
pdev-dev, dev_name(pdev-dev));
--
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 v9 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework
From: Kamil Debski k.deb...@samsung.com
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/exynos-usb.txt | 18 +++
drivers/usb/host/ehci-exynos.c | 143 +---
2 files changed, 141 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 03b7e43..4f368b0 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+ One phy per port. Each port should have its 'reg' entry.
+ - reg: port number on EHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings; specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
};
OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 4d763dc..caeadb4 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
@@ -42,14 +43,119 @@
static const char hcd_name[] = ehci-exynos;
static struct hc_driver __read_mostly exynos_ehci_hc_driver;
+#define PHY_NUMBER 3
struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
+static int exynos_ehci_get_phy(struct device *dev,
+ struct exynos_ehci_hcd *exynos_ehci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ehci-phy)) {
+ ret = PTR_ERR(exynos_ehci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(dev, Failed to get usb2 phy\n);
+ exynos_ehci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+ } else {
+ exynos_ehci-otg = exynos_ehci-phy-otg;
+ }
+
+ for_each_available_child_of_node(dev-of_node, child) {
+ ret = of_property_read_u32(child, reg, phy_number);
+ if (ret) {
+ dev_err(dev, Failed to parse device tree\n);
+ of_node_put(child);
+ goto fail_phy;
+ }
+ if (phy_number = PHY_NUMBER) {
+ dev_err(dev, Invalid number of PHYs\n);
+ of_node_put(child);
+ ret = -EINVAL;
+ goto fail_phy;
+ }
+ phy = devm_of_phy_get(dev, child, 0);
+ of_node_put(child);
+ if (IS_ERR(phy)) {
+ ret =
[PATCH v3 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/exynos-usb.txt | 19 +++
drivers/usb/host/ohci-exynos.c | 129 +---
2 files changed, 132 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..03b7e43 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,15 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be usbhost.
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+ One phy per port. Each port should have its 'reg' entry.
+ - reg: port number on OHCI controller, e.g
+ On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+ - phys: from the *Generic PHY* bindings specifying phy used by port.
+ - phy-names: from the *Generic PHY* bindings specifying name of phy
+used by the port.
Example:
usb@1212 {
@@ -47,6 +56,16 @@ Example:
clocks = clock 285;
clock-names = usbhost;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2phy 1;
+ phy-names = host;
+ status = disabled;
+ };
+
};
DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 05f00e3..011ccde 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -33,28 +34,122 @@ static struct hc_driver __read_mostly
exynos_ohci_hc_driver;
#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)-priv)
+#define PHY_NUMBER 3
struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g[PHY_NUMBER];
};
-static void exynos_ohci_phy_enable(struct device *dev)
+static int exynos_ohci_get_phy(struct device *dev,
+ struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct device_node *child;
+ struct phy *phy;
+ int phy_number;
+ int ret = 0;
+
+ exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci-phy)) {
+ ret = PTR_ERR(exynos_ohci-phy);
+ /* This is the case when PHY config is disabled */
+ if (ret == -ENXIO || ret == -ENODEV) {
+ dev_dbg(dev, Failed to get usb2 phy\n);
+ exynos_ohci-phy = NULL;
+ ret = 0;
+ } else if (ret == -EPROBE_DEFER) {
+ goto fail_phy;
+ } else {
+ dev_err(dev, no usb2 phy configured\n);
+ goto fail_phy;
+ }
+ } else {
+ exynos_ohci-otg = exynos_ohci-phy-otg;
+ }
+
+ /* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so that in absence of supporting dts
+* changes the functionality doesn't break.
+* Once we move the ohci dt nodes to use new generic phys,
+* we can remove support for older PHY in this driver.
+*/
+ for_each_available_child_of_node(dev-of_node, child) {
+ ret = of_property_read_u32(child, reg, phy_number);
+ if (ret) {
+ dev_err(dev, Failed to parse device tree\n);
+ of_node_put(child);
+ goto fail_phy;
+ }
+ if (phy_number = PHY_NUMBER) {
+ dev_err(dev, Invalid number of PHYs\n);
+ of_node_put(child);
+ ret = -EINVAL;
+ goto fail_phy;
+ }
+ phy = devm_of_phy_get(dev, child, 0);
+ of_node_put(child);
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ /* This
[PATCH 1/4] usb: ohci-exynos: Use struct device instead of platform_device
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..05f00e3 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -39,18 +39,18 @@ struct exynos_ohci_hcd {
struct usb_otg *otg;
};
-static void exynos_ohci_phy_enable(struct platform_device *pdev)
+static void exynos_ohci_phy_enable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
usb_phy_init(exynos_ohci-phy);
}
-static void exynos_ohci_phy_disable(struct platform_device *pdev)
+static void exynos_ohci_phy_disable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
@@ -139,7 +139,7 @@ skip_phy:
platform_set_drvdata(pdev, hcd);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(pdev-dev);
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
@@ -150,7 +150,7 @@ skip_phy:
return 0;
fail_add_hcd:
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(pdev-dev);
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
@@ -168,7 +168,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(pdev-dev);
clk_disable_unprepare(exynos_ohci-clk);
@@ -190,7 +190,6 @@ static int exynos_ohci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int rc = ohci_suspend(hcd, do_wakeup);
@@ -200,7 +199,7 @@ static int exynos_ohci_suspend(struct device *dev)
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(dev);
clk_disable_unprepare(exynos_ohci-clk);
@@ -211,14 +210,13 @@ static int exynos_ohci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev= to_platform_device(dev);
clk_prepare_enable(exynos_ohci-clk);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(dev);
ohci_resume(hcd, false);
--
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 v3 0/4] usb: ehci/ohci-exynos: Move to generic phy framework
Based and tested on 'usb-next' branch of Greg's usb tree, with relevant device tree patches[1] Changes from v2: - Added two patches in the series for some cleanup. usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device - Addressed review comments. -- Moved exynos_ohci_phyg_on()/off routines inside exynos_ohci_phy_enable()/disable. -- Added functions exynos_ehci_phy_enable() and exynos_ehci_phy_disable() and moved exynos_ehci_phyg_on()/off routines respectively in them. -- Added necessary checks. Kamil Debski (1): usb: ehci-exynos: Change to use phy provided by the generic phy framework Vivek Gautam (3): usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device usb: ohci-exynos: Add facility to use phy provided by the generic phy framework .../devicetree/bindings/usb/exynos-usb.txt | 37 + drivers/usb/host/ehci-exynos.c | 148 +--- drivers/usb/host/ohci-exynos.c | 141 --- 3 files changed, 280 insertions(+), 46 deletions(-) -- 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 v3 0/4] usb: ehci/ohci-exynos: Move to generic phy framework
Based and tested on 'usb-next' branch of Greg's usb tree, with relevant device tree patches[1] Changes from v2: - Added two patches in the series for some cleanup. usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device - Addressed review comments. -- Moved exynos_ohci_phyg_on()/off routines inside exynos_ohci_phy_enable()/disable. -- Added functions exynos_ehci_phy_enable() and exynos_ehci_phy_disable() and moved exynos_ehci_phyg_on()/off routines respectively in them. -- Added necessary checks. Kamil Debski (1): usb: ehci-exynos: Change to use phy provided by the generic phy framework Vivek Gautam (3): usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device usb: ohci-exynos: Add facility to use phy provided by the generic phy framework .../devicetree/bindings/usb/exynos-usb.txt | 37 + drivers/usb/host/ehci-exynos.c | 148 +--- drivers/usb/host/ohci-exynos.c | 141 --- 3 files changed, 280 insertions(+), 46 deletions(-) -- 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 v3 0/4] usb: ehci/ohci-exynos: Move to generic phy framework
On Mon, Apr 28, 2014 at 2:55 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Based and tested on 'usb-next' branch of Greg's usb tree, with relevant device tree patches[1] [1] [PATCH v7 0/2] dts: Add usb2phy to Exynos 5250 http://www.spinics.net/lists/linux-usb/msg106427.html Changes from v2: - Added two patches in the series for some cleanup. usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device - Addressed review comments. -- Moved exynos_ohci_phyg_on()/off routines inside exynos_ohci_phy_enable()/disable. -- Added functions exynos_ehci_phy_enable() and exynos_ehci_phy_disable() and moved exynos_ehci_phyg_on()/off routines respectively in them. -- Added necessary checks. Kamil Debski (1): usb: ehci-exynos: Change to use phy provided by the generic phy framework Vivek Gautam (3): usb: ohci-exynos: Use struct device instead of platform_device usb: ehci-exynos: Use struct device instead of platform_device usb: ohci-exynos: Add facility to use phy provided by the generic phy framework .../devicetree/bindings/usb/exynos-usb.txt | 37 + drivers/usb/host/ehci-exynos.c | 148 +--- drivers/usb/host/ohci-exynos.c | 141 --- 3 files changed, 280 insertions(+), 46 deletions(-) -- 1.7.10.4 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 v6] clk: Exynos5250: Add clocks for G3D
This patch adds the required clocks for ARM Mali IP
in Exynos5250.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v5
- Addressed comments from Tomasz Figa
http://www.spinics.net/lists/arm-kernel/msg326118.html
Changes from v4
- Rebased on latest kernel
- Added macros
Changes from v3
- Renamed some clocks as per Tomasz Figa's comments
Changes from v2
- Rebased on clk-next
Changes from v1
- Removed exporting of parent DIV clock for g3d
as per Tomsz Figa's comment.
---
drivers/clk/samsung/clk-exynos5250.c | 15 ++-
include/dt-bindings/clock/exynos5250.h |4 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee442..df02526 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -37,6 +37,7 @@
#define VPLL_CON0 0x10140
#define GPLL_CON0 0x10150
#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
#define SRC_TOP2 0x10218
#define SRC_TOP3 0x1021c
#define SRC_GSCL 0x10220
@@ -71,6 +72,7 @@
#define GATE_IP_GSCL 0x10920
#define GATE_IP_DISP1 0x10928
#define GATE_IP_MFC0x1092c
+#define GATE_IP_G3D0x10930
#define GATE_IP_GEN0x10934
#define GATE_IP_FSYS 0x10944
#define GATE_IP_PERIC 0x10950
@@ -100,6 +102,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_CPU0,
SRC_CORE1,
SRC_TOP0,
+ SRC_TOP1,
SRC_TOP2,
SRC_TOP3,
SRC_GSCL,
@@ -133,6 +136,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_PERIC5,
GATE_IP_GSCL,
GATE_IP_MFC,
+ GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_FSYS,
GATE_IP_PERIC,
@@ -189,10 +193,12 @@ PNAME(mout_vpllsrc_p) = { fin_pll, sclk_hdmi27m };
PNAME(mout_vpll_p) = { mout_vpllsrc, fout_vpll };
PNAME(mout_cpll_p) = { fin_pll, fout_cpll };
PNAME(mout_epll_p) = { fin_pll, fout_epll };
+PNAME(mout_gpll_p) = { fin_pll, fout_gpll };
PNAME(mout_mpll_user_p)= { fin_pll, mout_mpll };
PNAME(mout_bpll_user_p)= { fin_pll, mout_bpll };
PNAME(mout_aclk166_p) = { mout_cpll, mout_mpll_user };
PNAME(mout_aclk200_p) = { mout_mpll_user, mout_bpll_user };
+PNAME(mout_aclk400_p) = { mout_aclk400_g3d_mid, mout_gpll };
PNAME(mout_aclk200_sub_p) = { fin_pll, div_aclk200 };
PNAME(mout_aclk266_sub_p) = { fin_pll, div_aclk266 };
PNAME(mout_aclk333_sub_p) = { fin_pll, div_aclk333 };
@@ -273,12 +279,16 @@ static struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = {
MUX(0, mout_aclk166, mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, mout_aclk200, mout_aclk200_p, SRC_TOP0, 12, 1),
MUX(0, mout_aclk333, mout_aclk166_p, SRC_TOP0, 16, 1),
+ MUX(0, mout_aclk400_g3d_mid, mout_aclk200_p, SRC_TOP0, 20, 1),
+
+ MUX(0, mout_aclk400_g3d, mout_aclk400_p, SRC_TOP1, 28, 1),
MUX(0, mout_cpll, mout_cpll_p, SRC_TOP2, 8, 1),
MUX(0, mout_epll, mout_epll_p, SRC_TOP2, 12, 1),
MUX(0, mout_vpll, mout_vpll_p, SRC_TOP2, 16, 1),
MUX(0, mout_mpll_user, mout_mpll_user_p, SRC_TOP2, 20, 1),
MUX(0, mout_bpll_user, mout_bpll_user_p, SRC_TOP2, 24, 1),
+ MUX(CLK_MOUT_GPLL, mout_gpll, mout_gpll_p, SRC_TOP2, 28, 1),
MUX(0, mout_aclk200_disp1_sub, mout_aclk200_sub_p, SRC_TOP3, 4, 1),
MUX(0, mout_aclk266_gscl_sub, mout_aclk266_sub_p, SRC_TOP3, 8, 1),
@@ -351,6 +361,8 @@ static struct samsung_div_clock exynos5250_div_clks[]
__initdata = {
DIV(0, div_aclk200, mout_aclk200, DIV_TOP0, 12, 3),
DIV(0, div_aclk266, mout_mpll_user, DIV_TOP0, 16, 3),
DIV(0, div_aclk333, mout_aclk333, DIV_TOP0, 20, 3),
+ DIV(0, div_aclk400_g3d, mout_aclk400_g3d, DIV_TOP0,
+ 24, 3),
DIV(0, div_aclk66_pre, mout_mpll_user, DIV_TOP1, 24, 3),
@@ -533,7 +545,8 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
0),
GATE(CLK_SMMU_MFCL, smmu_mfcl, mout_aclk333_sub, GATE_IP_MFC, 2, 0,
0),
-
+ GATE(CLK_G3D, g3d, div_aclk400_g3d, GATE_IP_G3D, 0,
+ CLK_SET_RATE_PARENT, 0),
GATE(CLK_ROTATOR, rotator, div_aclk266, GATE_IP_GEN, 1, 0, 0),
GATE(CLK_JPEG, jpeg, div_aclk166, GATE_IP_GEN, 2, 0, 0),
GATE(CLK_MDMA1, mdma1, div_aclk266, GATE_IP_GEN, 4, 0, 0),
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..a3c6777 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -150,11 +150,13 @@
#define CLK_G2D345
#define CLK_MDMA0 346
#define CLK_SMMU_MDMA0 347
+#define CLK_G3D348
/* mux
[PATCH] clk: exynos5420: Add clock IDs needed by GPU
Adds IDs for the clocks needed by the ARM Mali GPU
in exynos5420.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |4 ++--
include/dt-bindings/clock/exynos5420.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 60b2681..7a9e3b4 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -362,7 +362,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_aclk66_psgen, aclk66_peric_p, SRC_TOP5, 4, 1),
MUX(0, mout_user_aclk333_g2d, user_aclk333_g2d_p, SRC_TOP5, 8, 1),
MUX(0, mout_user_aclk266_g2d, user_aclk266_g2d_p, SRC_TOP5, 12, 1),
- MUX_A(0, mout_user_aclk_g3d, user_aclk_g3d_p,
+ MUX_A(CLK_MOUT_G3D, mout_user_aclk_g3d, user_aclk_g3d_p,
SRC_TOP5, 16, 1, aclkg3d),
MUX(0, mout_user_aclk300_jpeg, user_aclk300_jpeg_p,
SRC_TOP5, 20, 1),
@@ -372,7 +372,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
SRC_TOP5, 28, 1),
MUX(0, sclk_mpll, mpll_p, SRC_TOP6, 0, 1),
- MUX(0, sclk_vpll, vpll_p, SRC_TOP6, 4, 1),
+ MUX(CLK_MOUT_VPLL, sclk_vpll, vpll_p, SRC_TOP6, 4, 1),
MUX(0, sclk_spll, spll_p, SRC_TOP6, 8, 1),
MUX(0, sclk_ipll, ipll_p, SRC_TOP6, 12, 1),
MUX(0, sclk_rpll, rpll_p, SRC_TOP6, 16, 1),
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 5eefd88..54db8b3 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -178,6 +178,8 @@
/* mux clocks */
#define CLK_MOUT_HDMI 640
+#define CLK_MOUT_G3D 641
+#define CLK_MOUT_VPLL 642
/* divider clocks */
#define CLK_DOUT_PIXEL 768
--
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 1/4] usb: ohci-exynos: Use struct device instead of platform_device
On Monday, April 28, 2014 6:25 PM, Vivek Gautam wrote:
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 9cf80cb..05f00e3 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -39,18 +39,18 @@ struct exynos_ohci_hcd {
struct usb_otg *otg;
};
-static void exynos_ohci_phy_enable(struct platform_device *pdev)
+static void exynos_ohci_phy_enable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
usb_phy_init(exynos_ohci-phy);
}
-static void exynos_ohci_phy_disable(struct platform_device *pdev)
+static void exynos_ohci_phy_disable(struct device *dev)
{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
@@ -139,7 +139,7 @@ skip_phy:
platform_set_drvdata(pdev, hcd);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(pdev-dev);
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
@@ -150,7 +150,7 @@ skip_phy:
return 0;
fail_add_hcd:
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(pdev-dev);
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
@@ -168,7 +168,7 @@ static int exynos_ohci_remove(struct platform_device
*pdev)
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(pdev-dev);
clk_disable_unprepare(exynos_ohci-clk);
@@ -190,7 +190,6 @@ static int exynos_ohci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int rc = ohci_suspend(hcd, do_wakeup);
@@ -200,7 +199,7 @@ static int exynos_ohci_suspend(struct device *dev)
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_disable(pdev);
+ exynos_ohci_phy_disable(dev);
clk_disable_unprepare(exynos_ohci-clk);
@@ -211,14 +210,13 @@ static int exynos_ohci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
- struct platform_device *pdev= to_platform_device(dev);
clk_prepare_enable(exynos_ohci-clk);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_enable(pdev);
+ exynos_ohci_phy_enable(dev);
ohci_resume(hcd, false);
--
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/4] usb: ehci-exynos: Use struct device instead of platform_device
On Monday, April 28, 2014 6:26 PM, Vivek Gautam wrote:
Change to use struct device instead of struct platform_device
for some static functions.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-exynos.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..4d763dc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -50,9 +50,8 @@ struct exynos_ehci_hcd {
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)-priv)
-static void exynos_setup_vbus_gpio(struct platform_device *pdev)
+static void exynos_setup_vbus_gpio(struct device *dev)
{
- struct device *dev = pdev-dev;
int err;
int gpio;
@@ -88,7 +87,7 @@ static int exynos_ehci_probe(struct platform_device *pdev)
if (err)
return err;
- exynos_setup_vbus_gpio(pdev);
+ exynos_setup_vbus_gpio(pdev-dev);
hcd = usb_create_hcd(exynos_ehci_hc_driver,
pdev-dev, dev_name(pdev-dev));
--
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 v12 18/31] iommu/exynos: allow having multiple System MMUs for a master H/W
On 04/27/2014 01:07 PM, Shaik Ameer Basha wrote: From: Cho KyongHo pullip@samsung.com Some master device descriptor like fimc-is which is an abstraction of very complex H/W may have multiple System MMUs. For those devices, the design of the link between System MMU and its master H/W is needed to be reconsidered. A link structure, sysmmu_list_data is introduced that provides a link to master H/W and that has a pointer to the device descriptor of a System MMU. Given a device descriptor of a master H/W, it is possible to traverse all System MMUs that must be controlled along with the master H/W. Signed-off-by: Cho KyongHo pullip@samsung.com Since you are posting the patches, you should also add your Signed-of-by. --- drivers/iommu/exynos-iommu.c | 545 ++ 1 file changed, 335 insertions(+), 210 deletions(-) diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index fefedec3..c2e6365 100755 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c [ ... ] static int sysmmu_pm_genpd_save_state(struct device *dev) @@ -1215,7 +1349,7 @@ static int sysmmu_pm_genpd_save_state(struct device *dev) ret = cb(dev); if (ret == 0) - sysmmu_save_state(client-sysmmu); + sysmmu_save_state(dev); client is now unused, remove the variable. return ret; } @@ -1238,13 +1372,13 @@ static int sysmmu_pm_genpd_restore_state(struct device *dev) if (!cb dev-driver dev-driver-pm) cb = dev-driver-pm-runtime_resume; - sysmmu_restore_state(client-sysmmu); + sysmmu_restore_state(dev); if (cb) ret = cb(dev); if (ret) - sysmmu_save_state(client-sysmmu); + sysmmu_restore_state(dev); client is now unused, remove the variable. -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
+- mmu-masters: A phandle to device nodes representing the master for which
+ the System MMU can provide a translation. Any additional
values
+ after the phandle will be ignored because a System MMU never
+ have two or more masters. #stream-id-cells specified in the
+ master's node will be also ignored.
+ If more than one phandle is specified, only the first phandle
+ will be treated.
This seems completely backwards: Why would you list the masters for an IOMMU
in the IOMMU node?
The master should have a standard property pointing to the IOMMU instead.
We don't have a generic binding for IOMMUs yet it seems, but the time is
overdue to make one.
Consider this NAKed until there is a generic binding for IOMMUs that all
relevant developers have agreed to.
I'd like to take this opportunity and revive one of the hibernating
patch sets that we have for Tegra. The last effort to get things merged
was back in January I think. I haven't bothered to look up the reference
since it's probably good to start from scratch anyway.
The latest version of the binding that was under discussion back then I
think looked something like this:
device@... {
iommus = iommu [spec][, other_iommu [other_spec]...];
};
And possibly with a iommu-names property to go along with that. The idea
being that a device can be a master on possibly multiple IOMMUs. Using
the above it would also be possible to have one device be multiple
masters on the same IOMMU.
On Tegra the specifier would be used to encode a memory controller's
client ID. One discussion point back at the time was to encode the ID as
a bitmask to allow more than a single master per entry. Another solution
which I think is a little cleaner and more generic, would be to use one
entry per master and use a single cell to encode the client ID. Devices
with multiple clients to the same IOMMU could then use multiple entries
referencing the same IOMMU.
I've added Hiroshi Doyu on Cc since he knows the Tegra IOMMU best.
Hiroshi, can you summarize exactly what the proposed bindings were. If
my memory serves me well they were mostly along the lines of what Arnd
proposes here, and perhaps they are something that can also be used for
Exynos.
Will Deacon (I think) had some comments on the earlier discussion as
well, so I've added him on Cc for visibility. Sorry if I'm confusing you
with someone else, Will. In that case perhaps you know who to include in
the discussion from the ARM side.
Also adding Stephen Warren for visibility.
Thierry
pgpNkQwva4gNA.pgp
Description: PGP signature
[PATCH 3/7 v8] crypto:s5p-sss: Add support for SSS module on Exynos
This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Change since v6:
None
Change since v5:
1. Rewritten the interrupt definition in the documentation
2. Added Reviewed-by: Tomasz Figa t.f...@samsung.com
.../devicetree/bindings/crypto/samsung-sss.txt | 15 ++-
drivers/crypto/s5p-sss.c | 107 +++-
2 files changed, 95 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
index 3876f71..1702773 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -8,16 +8,25 @@ The SSS module in S5PV210 SoC supports the following:
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
Required properties:
- compatible : Should contain entries for this and backward compatible
SSS versions:
- samsung,s5pv210-secss for S5PV210 SoC.
+ - samsung,exynos4210-secss for Exynos4210, Exynos4212, Exynos4412,
Exynos5250,
+ Exynos5260 and Exynos5420 SoCs.
- reg : Offset and length of the register set for the module
- interrupts : interrupt specifiers of SSS module interrupts, should contain
- two entries:
- - first : feed control interrupt,
- - second : hash interrupt.
+ following entries:
+ - first : feed control interrupt (required for all variants),
+ - second : hash interrupt (required only for
samsung,s5pv210-secss).
- clocks : list of clock phandle and specifier pairs for all clocks listed in
clock-names property.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index c6aafe8..37e0598 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
#define SSS_REG_FCPKDMAO0x005C
/* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL0x00
#define SSS_AES_BYTESWAP_DI _BIT(11)
#define SSS_AES_BYTESWAP_DO _BIT(10)
#define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,25 @@
#define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
#define SSS_AES_MODE_DECRYPT_BIT(0)
-#define SSS_REG_AES_STATUS 0x4004
+#define SSS_REG_AES_STATUS 0x04
#define SSS_AES_BUSY_BIT(2)
#define SSS_AES_INPUT_READY _BIT(1)
#define SSS_AES_OUTPUT_READY_BIT(0)
-#define SSS_REG_AES_IN_DATA(s) (0x4010 + (s 2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s 2))
-#define SSS_REG_AES_IV_DATA(s) (0x4030 + (s 2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s 2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s 2))
+#define SSS_REG_AES_IN_DATA(s) (0x10 + (s 2))
+#define SSS_REG_AES_OUT_DATA(s)(0x20 + (s 2))
+#define SSS_REG_AES_IV_DATA(s) (0x30 + (s 2))
+#define SSS_REG_AES_CNT_DATA(s)(0x40 + (s 2))
+#define SSS_REG_AES_KEY_DATA(s)(0x80 + (s 2))
#define SSS_REG(dev, reg) ((dev)-ioaddr + (SSS_REG_##reg))
#define SSS_READ(dev, reg) __raw_readl(SSS_REG(dev, reg))
#define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
+#define SSS_AES_REG(dev, reg) ((dev)-aes_ioaddr + SSS_REG_##reg)
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val), \
+ SSS_AES_REG(dev, reg))
+
/* HW engine modes */
#define FLAGS_AES_DECRYPT _BIT(0)
#define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -146,6 +150,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_variant - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_variant {
+
[PATCH 4/7 v8] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com Acked-by: Herbert Xu herb...@gondor.apana.org.au CC: David S. Miller da...@davemloft.net CC: Vladimir Zapolskiy vzapols...@gmail.com TO: linux-cry...@vger.kernel.org CC: linux-samsung-soc@vger.kernel.org --- Changes since v7: Added Acked-by from Herbert Xu Change since v6: None Change since v5: None drivers/crypto/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 03ccdb0..f066fa2 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -301,14 +301,14 @@ config CRYPTO_DEV_SAHARA found in some Freescale i.MX chips. config CRYPTO_DEV_S5P - tristate Support for Samsung S5PV210 crypto accelerator - depends on ARCH_S5PV210 + tristate Support for Samsung S5PV210/Exynos crypto accelerator + depends on ARCH_S5PV210 || ARCH_EXYNOS select CRYPTO_AES select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. - Select this to offload Samsung S5PV210 or S5PC110 from AES + Select this to offload Samsung S5PV210 or S5PC110, Exynos from AES algorithms execution. config CRYPTO_DEV_NX -- 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 6/7 v8] crypto:s5p-sss: Use clk_prepare/clk_unprepare
This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
drivers/crypto/s5p-sss.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 0ffc042..ea7d478 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -645,7 +645,11 @@ static int s5p_aes_probe(struct platform_device *pdev)
return -ENOENT;
}
- clk_enable(pdata-clk);
+ err = clk_prepare_enable(pdata-clk);
+ if (err 0) {
+ dev_err(dev, Enabling SSS clk failed, err %d\n, err);
+ return err;
+ }
spin_lock_init(pdata-lock);
@@ -706,7 +710,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
tasklet_kill(pdata-tasklet);
err_irq:
- clk_disable(pdata-clk);
+ clk_disable_unprepare(pdata-clk);
s5p_dev = NULL;
@@ -726,7 +730,7 @@ static int s5p_aes_remove(struct platform_device *pdev)
tasklet_kill(pdata-tasklet);
- clk_disable(pdata-clk);
+ clk_disable_unprepare(pdata-clk);
s5p_dev = NULL;
--
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 7/7 v8] crypto:s5p-sss: Look for the next request in the queue
Currently, the driver enqueues a request only if the busy bit is
false. And every request initiates a dequeue. If 2 requests arrive
simultaneously, only one of them will be dequeued.
To avoid this senario, we will enqueue the next request irrespective
of the system condition (that is what queue is here for). Also
schedule at a tasklet immediatly after the current request is done.
The tasklet will dequeue the next request in the queue, giving
continuous loop. tasklet will exit if there are no requests in the
queue.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
drivers/crypto/s5p-sss.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index ea7d478..47c568e 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -330,8 +330,12 @@ static void s5p_aes_tx(struct s5p_aes_dev *dev)
}
s5p_set_dma_outdata(dev, dev-sg_dst);
- } else
+ } else {
s5p_aes_complete(dev, err);
+
+ dev-busy = true;
+ tasklet_schedule(dev-tasklet);
+ }
}
static void s5p_aes_rx(struct s5p_aes_dev *dev)
@@ -469,10 +473,13 @@ static void s5p_tasklet_cb(unsigned long data)
spin_lock_irqsave(dev-lock, flags);
backlog = crypto_get_backlog(dev-queue);
async_req = crypto_dequeue_request(dev-queue);
- spin_unlock_irqrestore(dev-lock, flags);
- if (!async_req)
+ if (!async_req) {
+ dev-busy = false;
+ spin_unlock_irqrestore(dev-lock, flags);
return;
+ }
+ spin_unlock_irqrestore(dev-lock, flags);
if (backlog)
backlog-complete(backlog, -EINPROGRESS);
@@ -491,14 +498,13 @@ static int s5p_aes_handle_req(struct s5p_aes_dev *dev,
int err;
spin_lock_irqsave(dev-lock, flags);
+ err = ablkcipher_enqueue_request(dev-queue, req);
if (dev-busy) {
- err = -EAGAIN;
spin_unlock_irqrestore(dev-lock, flags);
goto exit;
}
dev-busy = true;
- err = ablkcipher_enqueue_request(dev-queue, req);
spin_unlock_irqrestore(dev-lock, flags);
tasklet_schedule(dev-tasklet);
@@ -683,6 +689,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
}
}
+ pdata-busy = false;
pdata-variant = variant;
pdata-dev = dev;
platform_set_drvdata(pdev, pdata);
--
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 5/7 v8] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate iv buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
drivers/crypto/s5p-sss.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 37e0598..0ffc042 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
{
void __iomem *keystart;
- memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
+ if (iv)
+ memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
if (keylen == AES_KEYSIZE_256)
keystart = dev-aes_ioaddr + SSS_REG_AES_KEY_DATA(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/7 v8] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
Changes since v5:
Rewritten the interrupt definition in the documentation
.../devicetree/bindings/crypto/samsung-sss.txt | 26
drivers/crypto/s5p-sss.c |8 ++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..3876f71
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,26 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - samsung,s5pv210-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : interrupt specifiers of SSS module interrupts, should contain
+ two entries:
+ - first : feed control interrupt,
+ - second : hash interrupt.
+
+- clocks : list of clock phandle and specifier pairs for all clocks listed in
+ clock-names property.
+- clock-names : list of device clock input names; should contain one entry
+ secss.
+
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 2876fa3..c6aafe8 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = samsung,s5pv210-secss },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -672,6 +679,7 @@ static struct platform_driver s5p_aes_crypto = {
.driver = {
.owner = THIS_MODULE,
.name = s5p-secss,
+ .of_match_table = s5p_sss_dt_match,
},
};
--
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/7 v8] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource 0 and hash interrupt as 1.
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
Changes since v5:
None
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index be45762..2876fa3 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -587,29 +587,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
spin_lock_init(pdata-lock);
- pdata-irq_hash = platform_get_irq_byname(pdev, hash);
- if (pdata-irq_hash 0) {
- err = pdata-irq_hash;
- dev_warn(dev, hash interrupt is not available.\n);
+ pdata-irq_fc = platform_get_irq(pdev, 0);
+ if (pdata-irq_fc 0) {
+ err = pdata-irq_fc;
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, hash interrupt is not available.\n);
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- pdata-irq_fc = platform_get_irq_byname(pdev, feed control);
- if (pdata-irq_fc 0) {
- err = pdata-irq_fc;
- dev_warn(dev, feed control interrupt is not available.\n);
+ pdata-irq_hash = platform_get_irq(pdev, 1);
+ if (pdata-irq_hash 0) {
+ err = pdata-irq_hash;
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, feed control interrupt is not available.\n);
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
--
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 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt -- 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] ARM: dts: Remove vmmc-supply for mmc@12220000 on arndale-octa board
Hi Sachin, On Mon, Apr 28, 2014 at 05:30:19AM +0100, Sachin Kamat wrote: On 26 April 2014 16:49, Kukjin Kim kgene@samsung.com wrote: Javi Merino wrote: On Fri, Apr 25, 2014 at 09:35:35PM +0100, Tomasz Figa wrote: On 25.04.2014 22:30, Javi Merino wrote: On Fri, Apr 25, 2014 at 09:16:30PM +0100, Tomasz Figa wrote: On 25.04.2014 22:11, Javi Merino wrote: d726ca2d3316 (ARM: dts: Add vmmc-supply to MMC on arndale-octa board) added the vmmc-supply to nodes mmc@1220 and mmc@1222 of the DT. However, this makes the kernel fail to boot on the arndale-octa spews: [5.06] dwmmc_exynos 1220.mmc: num-slots property not found, assuming 1 slot is available [5.065000] platform 1220.mmc: Driver dwmmc_exynos requests probe deferral [5.075000] dwmmc_exynos 1222.mmc: num-slots property not found, assuming 1 slot is available [5.085000] platform 1222.mmc: Driver dwmmc_exynos requests probe deferral And eventually hangs. Without the vmmc-supply property in the mmc@1222 node, the kernel boots again. Signed-off-by: Javi Merino javi.mer...@arm.com --- Hi, Note that I don't know *why* removing the property works, all I know is that 3.15-rc2 fails to boot on my Arndale Octa unless I apply this patch. Are you sure you have the required PMIC driver enabled in your kernel config? I configured the kernel using exynos_defconfig and that gives me: # CONFIG_PMIC_ADP5520 is not set # CONFIG_PMIC_DA903X is not set Should I be using other defconfig for this board? exynos_defconfig used to work in 3.14. Cheers, Well, unfortunately exynos_defconfig is known to be far from being reasonable. Right now it should be considered just as a base to configure the kernel for Exynos SoCs. Most of board specific options (and many of SoC-wide ones) need to be selected manually. Anyway, with the number of Exynos boards supported in mainline, I don't think we will be ever going to enable all options for all the supported boards by default in defconfig, especially considering the fact that we will be moving to generic multi_v7_defconfig and likely dropping exynos_defconfig completely. Well, keeping exynos_defconfig would be helpful even if exynos multiplatform is available. Please see the case of omap2plus_defconfig? As for now, I believe you should just make sure yourself that any options relevant to your board are enabled. Great. And I assume that there isn't a list of those options in the web. So how do I know what options are relevant to my board? By sending emails to linux-samsung-soc whenever it fails to boot? I think, we need to enable all of regarding configs for each exynos boards so that exynos_defconfig can cover whenever. You need the following patch to mount the MMC. Without this the regulator will not be enabled which is required by MMC. ARM: exynos_defconfig: Enable HS-I2C http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27527 Yes, that's the bit that I was missing. With that patch 3.15-rc2 boots on my Arndale Octa. Kukjin, can you please apply this patch? You can add my Tested-by for Arndale Octa. Thanks! Javi -- 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 v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
+- mmu-masters: A phandle to device nodes representing the master for
which
+ the System MMU can provide a translation. Any additional
values
+ after the phandle will be ignored because a System MMU
never
+ have two or more masters. #stream-id-cells specified in
the
+ master's node will be also ignored.
+ If more than one phandle is specified, only the first
phandle
+ will be treated.
This seems completely backwards: Why would you list the masters for an IOMMU
in the IOMMU node?
The master should have a standard property pointing to the IOMMU instead.
We don't have a generic binding for IOMMUs yet it seems, but the time is
overdue to make one.
Consider this NAKed until there is a generic binding for IOMMUs that all
relevant developers have agreed to.
I'd like to take this opportunity and revive one of the hibernating
patch sets that we have for Tegra. The last effort to get things merged
was back in January I think. I haven't bothered to look up the reference
since it's probably good to start from scratch anyway.
The latest version of the binding that was under discussion back then I
think looked something like this:
device@... {
iommus = iommu [spec][, other_iommu [other_spec]...];
};
And possibly with a iommu-names property to go along with that. The idea
being that a device can be a master on possibly multiple IOMMUs. Using
the above it would also be possible to have one device be multiple
masters on the same IOMMU.
Yes, that seems reasonable. Just one question: How would you represent a
device that has multiple masters, with at least one connected to an IOMMU
and another one connected to memory directly, without going to the IOMMU?
On Tegra the specifier would be used to encode a memory controller's
client ID. One discussion point back at the time was to encode the ID as
a bitmask to allow more than a single master per entry. Another solution
which I think is a little cleaner and more generic, would be to use one
entry per master and use a single cell to encode the client ID. Devices
with multiple clients to the same IOMMU could then use multiple entries
referencing the same IOMMU.
I'm not completely following here. Are you talking about the generic
binding, or the part that is tegra specific for the specifier?
My first impression is that the generic binding should just allow an
arbitrary specifier with a variable #iommu-cells, and leave the format
up to the IOMMU driver. A lot of drivers probably only support one
master, so they can just set #iommu-cells=0, others might require
IDs that do not fit into one cell.
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 v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
+- mmu-masters: A phandle to device nodes representing the master for
which
+ the System MMU can provide a translation. Any
additional values
+ after the phandle will be ignored because a System MMU
never
+ have two or more masters. #stream-id-cells specified
in the
+ master's node will be also ignored.
+ If more than one phandle is specified, only the first
phandle
+ will be treated.
This seems completely backwards: Why would you list the masters for an
IOMMU
in the IOMMU node?
The master should have a standard property pointing to the IOMMU instead.
We don't have a generic binding for IOMMUs yet it seems, but the time is
overdue to make one.
Consider this NAKed until there is a generic binding for IOMMUs that all
relevant developers have agreed to.
I'd like to take this opportunity and revive one of the hibernating
patch sets that we have for Tegra. The last effort to get things merged
was back in January I think. I haven't bothered to look up the reference
since it's probably good to start from scratch anyway.
The latest version of the binding that was under discussion back then I
think looked something like this:
device@... {
iommus = iommu [spec][, other_iommu [other_spec]...];
};
And possibly with a iommu-names property to go along with that. The idea
being that a device can be a master on possibly multiple IOMMUs. Using
the above it would also be possible to have one device be multiple
masters on the same IOMMU.
Yes, that seems reasonable. Just one question: How would you represent a
device that has multiple masters, with at least one connected to an IOMMU
and another one connected to memory directly, without going to the IOMMU?
Heh, I don't think I've ever thought about that use-case. I guess I was
always assuming that in the absence of an IOMMU the device would simply
access memory directly. From what I can tell that's how Tegra works at
least. If the IOMMU is not enabled for a given client, that client will
access physical memory untranslated.
I suppose if that really must be represented then a global dummy IOMMU
could be introduced to help with these cases.
On Tegra the specifier would be used to encode a memory controller's
client ID. One discussion point back at the time was to encode the ID as
a bitmask to allow more than a single master per entry. Another solution
which I think is a little cleaner and more generic, would be to use one
entry per master and use a single cell to encode the client ID. Devices
with multiple clients to the same IOMMU could then use multiple entries
referencing the same IOMMU.
I'm not completely following here. Are you talking about the generic
binding, or the part that is tegra specific for the specifier?
My first impression is that the generic binding should just allow an
arbitrary specifier with a variable #iommu-cells, and leave the format
up to the IOMMU driver.
Yes, I was getting ahead of myself. The idea was to have #iommu-cells
and allow the specifier to be IOMMU-specific. On Tegra that would
translate to the memory controller client ID, on other devices I suspect
something similar might exist, but for the generic binding it should be
completely opaque and hence irrelevant.
Really just like any of the other bindings that have foos and #foo-cells
properties.
A lot of drivers probably only support one
master, so they can just set #iommu-cells=0, others might require
IDs that do not fit into one cell.
You mean #iommu-cells = 1 for devices that only require one master?
There still has to be one cell to specify which master. Unless perhaps
if they can be arbitrarily assigned. I guess even if there's a fixed
mapping that applies to one SoC generation, it might be good to still
employ a specifier and have the mapping in DT for flexibility.
Thierry
pgpADPyGxVp3v.pgp
Description: PGP signature
Re: [RFC PATCH v2 2/3] ARM: EXYNOS: Move pmu specific header files under linux/mfd/samsung
Moving Exynos PMU specific header file into include/linux/mfd/samsung thus updated affected files under mach-exynos to use new location of these header files. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/cpuidle.c |4 +- arch/arm/mach-exynos/exynos-pmu.h | 31 --- arch/arm/mach-exynos/exynos.c |2 +- arch/arm/mach-exynos/hotplug.c |2 +- arch/arm/mach-exynos/platsmp.c |2 +- arch/arm/mach-exynos/pm.c |4 +- arch/arm/mach-exynos/pmu.c |5 +- arch/arm/mach-exynos/regs-pmu.h | 308 --- include/linux/mfd/samsung/exynos-pmu.h | 31 +++ include/linux/mfd/samsung/exynos-regs-pmu.h | 308 +++ 10 files changed, 348 insertions(+), 349 deletions(-) delete mode 100644 arch/arm/mach-exynos/exynos-pmu.h delete mode 100644 arch/arm/mach-exynos/regs-pmu.h create mode 100644 include/linux/mfd/samsung/exynos-pmu.h create mode 100644 include/linux/mfd/samsung/exynos-regs-pmu.h Can you resubmit this using the -M option for format-patch please? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
On Fri, 25 Apr 2014, Pankaj Dubey wrote: This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/Makefile |2 - arch/arm/mach-exynos/pmu.c| 521 - drivers/mfd/Kconfig |9 + drivers/mfd/Makefile |1 + drivers/mfd/exynos-pmu.c | 521 + 6 files changed, 533 insertions(+), 523 deletions(-) delete mode 100644 arch/arm/mach-exynos/pmu.c create mode 100644 drivers/mfd/exynos-pmu.c Same with this patch, `git format-patch -M`. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
On 04/28/2014 08:21 PM, Lee Jones wrote: On Fri, 25 Apr 2014, Pankaj Dubey wrote: This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 + arch/arm/mach-exynos/Makefile |2 - arch/arm/mach-exynos/pmu.c| 521 - drivers/mfd/Kconfig |9 + drivers/mfd/Makefile |1 + drivers/mfd/exynos-pmu.c | 521 + 6 files changed, 533 insertions(+), 523 deletions(-) delete mode 100644 arch/arm/mach-exynos/pmu.c create mode 100644 drivers/mfd/exynos-pmu.c Same with this patch, `git format-patch -M`. OK, I will resubmit this series. -- Best Regards, Pankaj Dubey -- 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 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. Lee, I don't mind if I apply this and send a pull request to you or I pull a tag from you with this in - what's easiest for you? I'm happy to do it. Doug, Can you send the patch-set again with all of the *-bys and ensure I'm on TO or CC please? It looks as if you've already applied 1, 3, and 4. I've sent up 2 and 5 again with collected tags. https://patchwork.kernel.org/patch/4042761/ https://patchwork.kernel.org/patch/4042751/ I think we have this sorted now. I sent a pull-request to Mark this morning. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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
[RESUBMIT RFC PATCH v2 0/3] Add support for Exynos PMU driver
This patch series moves PMU implementation from mach-exynos/pmu.c to drivers/mfd/exynos-pmu.c. Patch v1 was posted as RFC [1]. In case of ARM32 we had machine folder such as mach-exynos but moving forward with ARM64 SoC support we can not have any more such machine folders, keeping that in mind we have planned to move PMU implementation out of machine folder, so that common piece of code can be reused. This patch series is based on kgene for-next and depends on following patch series a) [PATCH v2 0/5] Add PMU node for Exynos SoCs https://lkml.org/lkml/2014/4/25/216 b) [PATCH v2 00/10] ARM: Exynos: PMU cleanup and refactoring for using DT https://lkml.org/lkml/2014/4/25/252 1) [RFC PATCH 0/2] Add support for Exynos PMU driver https://lkml.org/lkml/2014/4/2/69 Changes since v1: - Rebased on Kukjin Kim's for-next (3.15_rc1 tag) - Added patch: Move PMU specific definitions from common.h - Added patch: Move pmu specific header files under linux/mfd/samsung - Removed patch: ARM: EXYNOS: remove arch specific PMU implementation As suggested breaking down patches into smalled pieces for better review. Also modified all changes in pmu.c under mach-exynos itself and then prepared patches moving files from mach-exynos to drivers/mfd Pankaj Dubey (2): ARM: EXYNOS: Move pmu specific header files under linux/mfd/samsung drivers: mfd: Add support for Exynos PMU driver Younggun Jang (1): ARM: EXYNOS: Move PMU specific definitions from common.h arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- arch/arm/mach-exynos/common.h | 17 --- arch/arm/mach-exynos/cpuidle.c |3 +- arch/arm/mach-exynos/exynos.c |2 +- arch/arm/mach-exynos/hotplug.c |2 +- arch/arm/mach-exynos/platsmp.c |2 +- arch/arm/mach-exynos/pm.c |3 +- drivers/mfd/Kconfig|9 ++ drivers/mfd/Makefile |1 + .../mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |5 ++-- include/linux/mfd/samsung/exynos-pmu.h | 31 .../linux/mfd/samsung/exynos-regs-pmu.h|0 13 files changed, 52 insertions(+), 27 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (99%) create mode 100644 include/linux/mfd/samsung/exynos-pmu.h rename arch/arm/mach-exynos/regs-pmu.h = include/linux/mfd/samsung/exynos-regs-pmu.h (100%) -- 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
[RESUBMIT RFC PATCH v2 1/3] ARM: EXYNOS: Move PMU specific definitions from common.h
From: Younggun Jang yg1004.j...@samsung.com
This patch moves PMU specific definitions into a new file
as exynos-pmu.h. This will help in making PMU implementation
independent of common.h header.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/cpuidle.c|1 +
arch/arm/mach-exynos/exynos-pmu.h | 31 +++
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c|2 +-
5 files changed, 34 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ad5128e..d848ede 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -38,24 +38,7 @@ extern struct smp_operations exynos_smp_ops;
extern void exynos_cpu_die(unsigned int cpu);
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END 0x
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
extern unsigned long l2x0_regs_phys;
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern struct regmap *get_exynos_pmuregmap(void);
extern void __iomem *get_exynos_pmuaddr(void);
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 5dcdd46..ff3be9c 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -32,6 +32,7 @@
#include common.h
#include regs-pmu.h
+#include exynos-pmu.h
#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..1cc857b
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * 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.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+#define PMU_TABLE_END 0x
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e4c10d4..103ab92 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -37,6 +37,7 @@
#include common.h
#include regs-pmu.h
#include regs-sys.h
+#include exynos-pmu.h
static struct regmap *pmu_regmap;
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index abcf753..d020557 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -16,7 +16,7 @@
#include linux/slab.h
#include linux/mfd/syscon.h
-#include common.h
+#include exynos-pmu.h
#include regs-pmu.h
enum exynos_pmu_id {
--
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
[RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 2f60c90..79559b4 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -27,6 +27,7 @@ config ARCH_EXYNOS4 select PM_GENERIC_DOMAINS if PM_RUNTIME select S5P_DEV_MFC select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS4 SoCs based systems @@ -38,6 +39,7 @@ config ARCH_EXYNOS5 select HAVE_SMP select PINCTRL select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index a656dbe..19fdf17 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -18,8 +18,6 @@ obj-$(CONFIG_PM_SLEEP)+= pm.o sleep.o obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o obj-$(CONFIG_CPU_IDLE) += cpuidle.o -obj-$(CONFIG_ARCH_EXYNOS) += pmu.o - obj-$(CONFIG_SMP) += platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..fd48870 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1203,6 +1203,15 @@ config MFD_STW481X in various ST Microelectronics and ST-Ericsson embedded Nomadik series. +config MFD_EXYNOS_PMU + tristate Support Exynos Power Managment Unit + depends on ARM || ARM64 + help + Exynos SoC have Power Management Unit (PMU) which controls power and + operation state of Exynos SoC in two different ways. This driver + provides impmentation of PMU driver and provides basic functionality + required during these operation state. + menu Multimedia Capabilities Port drivers depends on ARCH_SA1100 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..7c43d07 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,4 @@ obj-$(CONFIG_MFD_RETU) += retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X) += stw481x.o +obj-$(CONFIG_MFD_EXYNOS_PMU) += exynos-pmu.o diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/mfd/exynos-pmu.c similarity index 100% rename from arch/arm/mach-exynos/pmu.c rename to drivers/mfd/exynos-pmu.c -- 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 v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Monday 28 April 2014 13:18:03 Thierry Reding wrote:
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
And possibly with a iommu-names property to go along with that. The idea
being that a device can be a master on possibly multiple IOMMUs. Using
the above it would also be possible to have one device be multiple
masters on the same IOMMU.
Yes, that seems reasonable. Just one question: How would you represent a
device that has multiple masters, with at least one connected to an IOMMU
and another one connected to memory directly, without going to the IOMMU?
Heh, I don't think I've ever thought about that use-case. I guess I was
always assuming that in the absence of an IOMMU the device would simply
access memory directly. From what I can tell that's how Tegra works at
least. If the IOMMU is not enabled for a given client, that client will
access physical memory untranslated.
I suppose if that really must be represented then a global dummy IOMMU
could be introduced to help with these cases.
It's actually not too uncommon: you can have e.g. the lower 2GB mapped
directly from the device address space into the host memory, but have
an iommu that translates accesses from some range in the upper 2GB of
the 32-bit address space into full 64-bit addresses.
This use case makes no sense if you use the IOMMU for isolation
or virtualization, but it gives better performance for lowmem access
when the only reason to have the IOMMU is to map highmem addresses.
On Tegra the specifier would be used to encode a memory controller's
client ID. One discussion point back at the time was to encode the ID as
a bitmask to allow more than a single master per entry. Another solution
which I think is a little cleaner and more generic, would be to use one
entry per master and use a single cell to encode the client ID. Devices
with multiple clients to the same IOMMU could then use multiple entries
referencing the same IOMMU.
I'm not completely following here. Are you talking about the generic
binding, or the part that is tegra specific for the specifier?
My first impression is that the generic binding should just allow an
arbitrary specifier with a variable #iommu-cells, and leave the format
up to the IOMMU driver.
Yes, I was getting ahead of myself. The idea was to have #iommu-cells
and allow the specifier to be IOMMU-specific. On Tegra that would
translate to the memory controller client ID, on other devices I suspect
something similar might exist, but for the generic binding it should be
completely opaque and hence irrelevant.
Really just like any of the other bindings that have foos and #foo-cells
properties.
Ok.
A lot of drivers probably only support one
master, so they can just set #iommu-cells=0, others might require
IDs that do not fit into one cell.
You mean #iommu-cells = 1 for devices that only require one master?
I meant an IOMMU device that acts as the slave for exactly one device,
even if that device has multiple master ports.
There still has to be one cell to specify which master. Unless perhaps
if they can be arbitrarily assigned. I guess even if there's a fixed
mapping that applies to one SoC generation, it might be good to still
employ a specifier and have the mapping in DT for flexibility.
let me clarify by example:
iommu@1 {
compatible = some,simple-iommu;
reg = 1;
#iommu-cells = 0; /* supports only one master */
};
iommu@2 {
compatible = some,other-iommu;
reg = 3;
#iommu-cells = 1; /* contains master ID */
};
iommu@3 {
compatible = some,windowed-iommu;
reg = 2;
#iommu-cells = 2; /* contains dma-window */
};
device@4 {
compatible = some,ethernet;
iommus = /iommu@1;
};
device@5 {
compatible = some,dmaengine;
iommus = /iommu@2 0x4000 0x100,
/iommu@3 0x101;
};
The device at address 4 has a one-one relationship with iommu@1, so there
is no need for any data. device@5 has two master ports. One is connected to
an IOMMU that has a per-device aperture, device@5 can only issue transfers
to the 256MB area at 0x4000, and the IOMMU will have to put entries for
this device into that address. The second master port is connected to
iommu@3, which uses a master ID that gets passed along with each transfer,
so that needs to be put into the IOTLBs.
A variation would be to not use #iommu-cells at all, but provide a
#address-cells / #size-cells pair in the IOMMU, and have a translation
as we do for dma-ranges. This is probably most flexible.
One completely open question that I just noticed is how the kernel should
deal with the case of
Re: [PATCH v2 3/6] rtc: s5m: Use shorter time of register update
Set the time needed for updating alarm and time registers to 0.45 ms. The default is 7.32 ms which is too long and leads to warnings when setting alarm or time: s5m-rtc: waiting for UDR update, reached max number of retries Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com --- drivers/rtc/rtc-s5m.c | 7 +++ include/linux/mfd/samsung/rtc.h | 10 ++ For the MFD changes: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [RESUBMIT RFC PATCH v2 2/3] ARM: EXYNOS: Move pmu specific header files under linux/mfd/samsung
Moving Exynos PMU specific header file into include/linux/mfd/samsung
thus updated affected files under mach-exynos to use new location of
these header files.
CC: Sangbeom Kim sbki...@samsung.com
CC: Samuel Ortiz sa...@linux.intel.com
CC: Lee Jones lee.jo...@linaro.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/cpuidle.c|4 ++--
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/hotplug.c|2 +-
arch/arm/mach-exynos/platsmp.c|2 +-
arch/arm/mach-exynos/pm.c |4 ++--
arch/arm/mach-exynos/pmu.c|5
++---
{arch/arm/mach-exynos = include/linux/mfd/samsung}/exynos-pmu.h |0
.../regs-pmu.h = include/linux/mfd/samsung/exynos-regs-pmu.h |0
8 files changed, 9 insertions(+), 10 deletions(-)
rename {arch/arm/mach-exynos = include/linux/mfd/samsung}/exynos-pmu.h
(100%)
rename arch/arm/mach-exynos/regs-pmu.h =
include/linux/mfd/samsung/exynos-regs-pmu.h (100%)
Patch looks okay to me.
With an Exynos Ack I'd like to take it through the MFD tree.
Acked-by: Lee Jones lee.jo...@linaro.org
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) [...] diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..fd48870 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1203,6 +1203,15 @@ config MFD_STW481X in various ST Microelectronics and ST-Ericsson embedded Nomadik series. +config MFD_EXYNOS_PMU + tristate Support Exynos Power Managment Unit + depends on ARM || ARM64 + help + Exynos SoC have Power Management Unit (PMU) which controls power and + operation state of Exynos SoC in two different ways. This driver + provides impmentation of PMU driver and provides basic functionality + required during these operation state. + The help should be indented. Take a look at the other entries. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) So I just took a look at the code as zero changes looks suspicious to me. The driver can not simply be copied and pasted into the MFD subsystem in its current state. The fundamental question is; is this chip actually an MFD? What does it do besides Power Management? diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 2f60c90..79559b4 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -27,6 +27,7 @@ config ARCH_EXYNOS4 select PM_GENERIC_DOMAINS if PM_RUNTIME select S5P_DEV_MFC select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS4 SoCs based systems @@ -38,6 +39,7 @@ config ARCH_EXYNOS5 select HAVE_SMP select PINCTRL select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index a656dbe..19fdf17 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -18,8 +18,6 @@ obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o obj-$(CONFIG_CPU_IDLE) += cpuidle.o -obj-$(CONFIG_ARCH_EXYNOS)+= pmu.o - obj-$(CONFIG_SMP)+= platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..fd48870 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1203,6 +1203,15 @@ config MFD_STW481X in various ST Microelectronics and ST-Ericsson embedded Nomadik series. +config MFD_EXYNOS_PMU + tristate Support Exynos Power Managment Unit + depends on ARM || ARM64 + help + Exynos SoC have Power Management Unit (PMU) which controls power and + operation state of Exynos SoC in two different ways. This driver + provides impmentation of PMU driver and provides basic functionality + required during these operation state. + menu Multimedia Capabilities Port drivers depends on ARCH_SA1100 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..7c43d07 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,4 @@ obj-$(CONFIG_MFD_RETU)+= retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X)+= stw481x.o +obj-$(CONFIG_MFD_EXYNOS_PMU) += exynos-pmu.o diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/mfd/exynos-pmu.c similarity index 100% rename from arch/arm/mach-exynos/pmu.c rename to drivers/mfd/exynos-pmu.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: EXYNOS5: Add PMU settings for exynos5420
Hi Tomasz,
On Wed, Apr 16, 2014 at 12:27 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
Basically the same comments apply as for the series:
[PATCH v2 0/3] Add initial support of PMU for exynos5260
(https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg27339.html)
In addition to above, please see some comments inline.
On 27.03.2014 07:13, Vikas Sajjan wrote:
Add intial PMU settings for exynos5420. This is required for
future S2R and Switching support.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h | 10 ++
arch/arm/mach-exynos/pmu.c | 307
+++
arch/arm/mach-exynos/regs-pmu.h | 228 +
3 files changed, 545 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83..347afc2 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -15,6 +15,16 @@
#include linux/reboot.h
#include linux/of.h
+#define EXYNOS5420_USE_STANDBY_WFI_ALL (EXYNOS5420_ARM_USE_STANDBY_WFI0
\
+| EXYNOS5420_ARM_USE_STANDBY_WFI1
\
+| EXYNOS5420_ARM_USE_STANDBY_WFI2
\
+| EXYNOS5420_ARM_USE_STANDBY_WFI3
\
+| EXYNOS5420_KFC_USE_STANDBY_WFI0
\
+| EXYNOS5420_KFC_USE_STANDBY_WFI1
\
+| EXYNOS5420_KFC_USE_STANDBY_WFI2
\
+|
EXYNOS5420_KFC_USE_STANDBY_WFI3)
+
+
void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
struct map_desc;
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 05c7ce1..f69a6ed 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -12,9 +12,14 @@
#include linux/io.h
#include linux/kernel.h
#include linux/bug.h
+#include linux/cpumask.h
+#include linux/delay.h
+#include linux/pm.h
#include plat/cpu.h
+#include asm/cputype.h
+
#include common.h
#include regs-pmu.h
@@ -318,6 +323,212 @@ static const struct exynos_pmu_conf
exynos5250_pmu_config[] = {
{ PMU_TABLE_END,},
};
+static const struct exynos_pmu_conf exynos5420_pmu_config[] = {
+ /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0,
0x0, 0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0,
0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0,
0x0, 0x0} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1,
0x0, 0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x1,
0x0, 0x0} },
+ { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0,
0x0, 0x0} },
+ {
Re: [PATCH V2 2/3] ARM: EXYNOS5: Support Suspend-to-RAM on EXYNOS5420
Hi Tomasz,
On Wed, Apr 16, 2014 at 12:33 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
Basically same comments as for the series for Exynos5260. Also see more
comments inline.
On 27.03.2014 07:13, Vikas Sajjan wrote:
Adds Suspend-to-RAM support for EXYNOS5420
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c| 148
++
arch/arm/mach-exynos/regs-pmu.h |4 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |2 +
drivers/clk/samsung/clk-exynos5420.c | 32 ++
4 files changed, 167 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..aa3c2c8 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -59,6 +59,16 @@ static struct sleep_save exynos_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
+static struct sleep_save exynos5420_cpustate_save[] = {
+ SAVE_ITEM(EXYNOS5420_VA_CPU_STATE),
+};
+
+static struct sleep_save exynos5420_reg_save[] = {
+ SAVE_ITEM(EXYNOS5_SYS_DISP1_BLK_CFG),
+ SAVE_ITEM(S5P_PMU_SPARE3),
+};
+
+
/*
* GIC wake-up support
*/
@@ -81,7 +91,7 @@ static int exynos_irq_set_wake(struct irq_data *data,
unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5420())
wkup_irq = exynos5250_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
@@ -109,7 +119,15 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ /*
+* Clear IRAM register for cpu state so that primary CPU does
+* not enter low power start in U-Boot.
+* This is specific to exynos5420 SoC only.
+*/
+ if (soc_is_exynos5420())
+ __raw_writel(0x0, EXYNOS5420_VA_CPU_STATE);
+
+ if (soc_is_exynos5250() || soc_is_exynos5420())
flush_cache_all();
/* issue the standby signal into the pm unit. */
@@ -135,6 +153,20 @@ static void exynos_pm_prepare(void)
tmp = __raw_readl(EXYNOS5_JPEG_MEM_OPTION);
tmp = ~EXYNOS5_OPTION_USE_RETENTION;
__raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
+ } else if (soc_is_exynos5420()) {
+
nit: Unnecessary blank line.
OK.
+ s3c_pm_do_save(exynos5420_reg_save,
+ ARRAY_SIZE(exynos5420_reg_save));
+
+ /*
+* The cpu state needs to be saved and restored so that
the
+* secondary CPUs will enter low power start. Though the
U-Boot
+* is setting the cpu state with low power flag, the
kernel
+* needs to restore it back in case, the primary cpu fails
to
+* suspend for any reason
+*/
+ s3c_pm_do_save(exynos5420_cpustate_save,
+ ARRAY_SIZE(exynos5420_cpustate_save));
}
/* Set value of power down register for sleep mode */
@@ -145,11 +177,34 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
__raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+
+ if (soc_is_exynos5420()) {
+
+ tmp = __raw_readl(EXYNOS5_ARM_L2_OPTION);
+ tmp = ~EXYNOS5_USE_RETENTION;
+ __raw_writel(tmp, EXYNOS5_ARM_L2_OPTION);
+
+ tmp = __raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
+ tmp |= EXYNOS5420_UFS;
+ __raw_writel(tmp, EXYNOS5420_SFR_AXI_CGDIS1);
+
+ tmp = __raw_readl(EXYNOS5420_ARM_COMMON_OPTION);
+ tmp = ~EXYNOS5420_L2RSTDISABLE_VALUE;
+ __raw_writel(tmp, EXYNOS5420_ARM_COMMON_OPTION);
+ tmp = __raw_readl(EXYNOS5420_FSYS2_OPTION);
+ tmp |= EXYNOS5420_EMULATION;
+ __raw_writel(tmp, EXYNOS5420_FSYS2_OPTION);
+ tmp = __raw_readl(EXYNOS5420_PSGEN_OPTION);
+ tmp |= EXYNOS5420_EMULATION;
+ __raw_writel(tmp, EXYNOS5420_PSGEN_OPTION);
+ }
+
}
static int exynos_pm_suspend(void)
{
unsigned long tmp;
+ unsigned long cluster_id;
/* Setting Central Sequence Register for power down mode */
@@ -159,10 +214,20 @@ static int exynos_pm_suspend(void)
/* Setting SEQ_OPTION register */
- tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
- __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+ if (soc_is_exynos5420()) {
+ cluster_id = (read_cpuid(CPUID_MPIDR) 8) 0xf;
+ if (!cluster_id)
+ __raw_writel(EXYNOS5420_ARM_USE_STANDBY_WFI0,
+
Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote:
On Monday 28 April 2014 13:18:03 Thierry Reding wrote:
On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
And possibly with a iommu-names property to go along with that. The idea
being that a device can be a master on possibly multiple IOMMUs. Using
the above it would also be possible to have one device be multiple
masters on the same IOMMU.
Yes, that seems reasonable. Just one question: How would you represent a
device that has multiple masters, with at least one connected to an IOMMU
and another one connected to memory directly, without going to the IOMMU?
Heh, I don't think I've ever thought about that use-case. I guess I was
always assuming that in the absence of an IOMMU the device would simply
access memory directly. From what I can tell that's how Tegra works at
least. If the IOMMU is not enabled for a given client, that client will
access physical memory untranslated.
I suppose if that really must be represented then a global dummy IOMMU
could be introduced to help with these cases.
It's actually not too uncommon: you can have e.g. the lower 2GB mapped
directly from the device address space into the host memory, but have
an iommu that translates accesses from some range in the upper 2GB of
the 32-bit address space into full 64-bit addresses.
This use case makes no sense if you use the IOMMU for isolation
or virtualization, but it gives better performance for lowmem access
when the only reason to have the IOMMU is to map highmem addresses.
Thinking about this some more, isn't the non-IOMMU master something we
can completely ignore in the DT? Or at least it shouldn't be handled by
the IOMMU bindings because, well, it's not an IOMMU to begin with.
Perhaps it's something that should be described using dma-ranges?
A lot of drivers probably only support one
master, so they can just set #iommu-cells=0, others might require
IDs that do not fit into one cell.
You mean #iommu-cells = 1 for devices that only require one master?
I meant an IOMMU device that acts as the slave for exactly one device,
even if that device has multiple master ports.
Okay, makes sense. I guess depending on the nature of the IOMMU it might
make sense not to expose it as an IOMMU at all. For example if it lives
completely within the register space of its master device. In that case
it could be directly programmed from the device's driver.
There still has to be one cell to specify which master. Unless perhaps
if they can be arbitrarily assigned. I guess even if there's a fixed
mapping that applies to one SoC generation, it might be good to still
employ a specifier and have the mapping in DT for flexibility.
let me clarify by example:
iommu@1 {
compatible = some,simple-iommu;
reg = 1;
#iommu-cells = 0; /* supports only one master */
};
iommu@2 {
compatible = some,other-iommu;
reg = 3;
#iommu-cells = 1; /* contains master ID */
};
iommu@3 {
compatible = some,windowed-iommu;
reg = 2;
#iommu-cells = 2; /* contains dma-window */
};
device@4 {
compatible = some,ethernet;
iommus = /iommu@1;
};
device@5 {
compatible = some,dmaengine;
iommus = /iommu@2 0x4000 0x100,
/iommu@3 0x101;
};
The device at address 4 has a one-one relationship with iommu@1, so there
is no need for any data. device@5 has two master ports. One is connected to
an IOMMU that has a per-device aperture, device@5 can only issue transfers
to the 256MB area at 0x4000, and the IOMMU will have to put entries for
this device into that address. The second master port is connected to
iommu@3, which uses a master ID that gets passed along with each transfer,
so that needs to be put into the IOTLBs.
The above sounds reasonable to me with the exception of the DMA window
specifier. Isn't that precisely the information that we currently
describe using the dma-ranges property?
A variation would be to not use #iommu-cells at all, but provide a
#address-cells / #size-cells pair in the IOMMU, and have a translation
as we do for dma-ranges. This is probably most flexible.
I'm not sure I follow. Wouldn't that require masters to be children of
the IOMMU DT nodes for that to work out? Also how would that work for
cases where more data than the address ranges (such as the master ID) is
needed to operate the IOMMU?
One completely open question that I just noticed is how the kernel should
deal with the case of multiple IOMMUs attached to one master: the
data structures we have assume that we know exactly how to do DMA by
setting the per-device
Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls
Daniel,
On Sun, Apr 27, 2014 at 6:25 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Apr 25, 2014 at 8:17 AM, Ajay kumar ajayn...@gmail.com wrote:
We can call panel_enable/disable at the right point. Even the bridge chips
expect the same. So, I am not ok with combining the bridge and panel and
calling the fxn pointers from crtc_helpers.
So, either we leave it the way it is in this patch (call drm_panel
functions at right points) or
we don't use drm_panel to control the panel sequence and instead use few DT
properties and regulators, inside the bridge chip driver.
That wasn't really suggested, but instead the idea was to provide a
default drm_bridge which wraps the drm_panel so that you could more
easily chain them up.
What do you mean by default drm_bridge?
I just want to clear few things. Let me explain what I have understood:
What I understand is that Rob wants me to create a common
structure which wraps up drm_panel and drm_bridge into a single structure:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */ == Really not sure why
this is needed!
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
And now, the above function becomes a common function
(also with an ordering issue btw panel and bridge).
Where do we keep it? And, where do we call it from?
Also I'm not really happy that the bridge callbacks have been added to
the drm helpers (I'd prefer if driver callbacks would bear that
responsibility). But you can always create your own drm_bridge
integration.
Do you mean, the bridge calls should be moved out of common drm_helper
functions and called from platform specific drivers instead?
In any case your concern that drivers need to control
when certain callbacks are called is shared by everyone here afaics.
And I also don't see any issues with Rob's proposal in this regard.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Please let me know if my understanding is correct and correct me if
there is a misconception.
Regards,
Ajay 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
Re: [PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables
On Sun, Apr 27, 2014 at 12:37:35PM +0900, Jungseok Lee wrote: On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote: On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote: [ ... ] This is overly complicated. For 4 levels we set x0 to be: ttbr1 + 2*PAGE_SIZE. For 4-levels, we set x0 to be ttbr1 + PAGE_SIZE, then inside the create_pgd_entry macro, we check the VA for FIXADDR_TOP then add another PAGE_SIZE. This is presumably done so the same PUD is used for the swapper block map and the FIXADDR map. Is it too complicated to understand the logic? 1) For 4 levels: PAGE_SIZE is added for FIXADDR map and x0 is passed to create pgd entry. 2) For =4 levels: PAGE_SIZE is added in the create_pgd_entry macro since FIXADDR map info is needed to create pud entry. However, I agree that the code should be revised if other people feel like it is a labyrinthine logic. If you assume that the PUD always follows the PGD for 4-levels, then you can remove this #ifdef and the conditional VA logic in set_pgd_entry. To make the logic simpler for 4 levels, you could call create_pud_entry in the middle of create_pgd_entry, then put down the actual pgd after. create_pud_entry should distinguish block map from FIXADDR map although PUD always follows the PGD in case of 4 levels. If we would like to avoid unnecessary #ifdef, the conditional logic should be introduced in create_ pgd_entry macro. I cannot find the best way even though I've tried to figure it out. I would like to find out the most clear and self-descriptive expression. Could you give an idea on how to remove both conditional VA logic and #ifdef? Hello Jungseok, I had the following logic in my head: It compiles and runs on the model, but I've not tried it in anger. = .macro create_pud_entry, pgd, tbl, virt, pud, tmp1, tmp2 #ifdef CONFIG_ARM64_4_LEVELS add \tbl, \tbl, #PAGE_SIZE // bump tbl 1 page up. // to make room for pud add \pud, \pgd, #PAGE_SIZE // pgd points to pud which // follows pgd lsr \tmp1, \virt, #PUD_SHIFT and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index orr \tmp2, \tbl, #3 // PUD entry table type str \tmp2, [\pud, \tmp1, lsl #3] #else mov \pud, \tbl // pgd points to section table // directly for 4 levels #endif .endm /* * Macro to populate the PGD for the corresponding block entry in the next * level (tbl) for the given virtual address. * * Preserves: pgd, virt * Corrupts:tmp1, tmp2, tmp3 * Returns: tbl - page where block mappings can be placed * (changed to make room for pud with 4levels, preserved otherwise) */ .macro create_pgd_entry, pgd, tbl, virt, tmp1, tmp2, tmp3 create_pud_entry \pgd, \tbl, \virt, \tmp3, \tmp1, \tmp2 lsr \tmp1, \virt, #PGDIR_SHIFT and \tmp1, \tmp1, #PTRS_PER_PGD - 1 // PGD index orr \tmp2, \tmp3, #3// PGD entry table type str \tmp2, [\pgd, \tmp1, lsl #3] .endm = [Note I've changed the extra argument to create_pgd_entry to be at the end to make it easier to diff callers] So essentially, we bump up tbl if we are running with 4 levels of page table. We put the pgd down after the pud, and this allows us to sneak a pud in after the pgd if we need to, otherwise it points to the target for the section mapping. Does this work for you? (I go cross-eyed with too much assembler, so could have easily missed something). + create_pgd_entry x26, x0, x1, x5, x6, x7 So before this patch we have the following created by __create_page_tables: ++ --- TEXT_OFFSET + PHYS_OFFSET | FIXADDR (pmd or pte) | ++ | block map (pmd or pte) | ++ | PGDs for swapper | ++ --- TTBR1 swapper_pg_dir | block map for idmap| ++ | PGDs for idmap | ++ --- TTBR0 idmap_pg_dir After the patch, for 4 levels activated we have: ++ --- TEXT_OFFSET + PHYS_OFFSET | FIXADDR (ptes) | ++ | block map (ptes) | ++ | PUDs for swapper | ++ | PGDs for swapper | ++ --- TTBR1 swapper_pg_dir | block map for idmap| ++ | PUDs for idmap | ++ | PGDs for idmap | ++ --- TTBR0 idmap_pg_dir and
Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
Hi YoungJun,
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 ++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
[snip]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
[snip]
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+ struct drm_connector *connector = panel-connector;
+ struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_create(connector-dev);
+ if (!mode) {
+ DRM_ERROR(failed to create a new display mode\n);
+ return 0;
+ }
+
+ drm_display_mode_from_videomode(ctx-vm, mode);
+ mode-width_mm = ctx-width_mm;
+ mode-height_mm = ctx-height_mm;
+ connector-display_info.width_mm = mode-width_mm;
+ connector-display_info.height_mm = mode-height_mm;
+
+ mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ mode-private = (void *)ctx-cpu_timings;
Wouldn't it make sense to create a new get_interface_params (or similar)
operation for drm_panel to query interface configuration parameters
instead of shoving it in the mode private field ?
You mean new get_interface_params operation is different from
get_modes() ?
Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.
I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.
Could you explain it in more detail?
The idea is that the interface parameters (RD/WR signals timings in this case,
but this could also include MIPI DSI lane configuration or any other kind of
physical interface parameters) are distinct from the video modes.
Do you see a need to tie tie interface parameters with drm_display_mode ? Can
they be mode-specific ? In any case I'd like not to use the private field of
drm_display_mode. If we need to tie both information together then it should
be done in a standard way.
--
Regards,
Laurent Pinchart
--
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 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
On Mon, 28 Apr 2014, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
+static int exynos_ohci_phy_enable(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int i;
+ int ret = 0;
- if (exynos_ohci-phy)
- usb_phy_init(exynos_ohci-phy);
+ if (exynos_ohci-phy) {
+ ret = usb_phy_init(exynos_ohci-phy);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; ret == 0 i PHY_NUMBER; i++)
+ if (exynos_ohci-phy_g[i])
+ ret = phy_power_on(exynos_ohci-phy_g[i]);
+ if (ret)
+ for (i--; i = 0; i--)
+ if (exynos_ohci-phy_g[i])
+ phy_power_off(exynos_ohci-phy_g[i]);
Do you want to call usb_phy_shutdown() at this point?
+
+ return ret;
}
-static void exynos_ohci_phy_disable(struct device *dev)
+static int exynos_ohci_phy_disable(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int i;
+ int ret = 0;
if (exynos_ohci-phy)
usb_phy_shutdown(exynos_ohci-phy);
+
+ for (i = 0; i PHY_NUMBER; i++)
+ if (exynos_ohci-phy_g[i])
+ ret = phy_power_off(exynos_ohci-phy_g[i]);
+
+ return ret;
}
This return value is practically meaningless. It is the status from
the last PHY only; any errors involving the other PHYs have been lost.
You may as well make this function return void.
@@ -210,13 +302,18 @@ static int exynos_ohci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int ret;
clk_prepare_enable(exynos_ohci-clk);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_enable(dev);
+ ret = exynos_ohci_phy_enable(dev);
+ if (ret) {
+ dev_err(dev, Failed to enable USB phy\n);
Do you want to call clk_disable_unprepare() here?
+ return ret;
+ }
ohci_resume(hcd, false);
Alan Stern
--
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 v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On 04/28/2014 05:18 AM, Thierry Reding wrote: On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote: ... A lot of drivers probably only support one master, so they can just set #iommu-cells=0, others might require IDs that do not fit into one cell. You mean #iommu-cells = 1 for devices that only require one master? There still has to be one cell to specify which master. Unless perhaps if they can be arbitrarily assigned. I guess even if there's a fixed mapping that applies to one SoC generation, it might be good to still employ a specifier and have the mapping in DT for flexibility. #iommu-cells doesn't include the phandle, so if you want the client references to be: property = iommu; then that's #iommu-cells=0, whereas: property = iommu N; is #iommu-cells=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 00/16] Another 16 L2C patches
On Mon, Apr 28, 2014 at 11:27:09AM -0600, Stephen Warren wrote: On 04/28/2014 11:12 AM, Stephen Warren wrote: On 04/28/2014 10:56 AM, Russell King - ARM Linux wrote: So, in response to Matt Porter's complaint about breaking prima2, here's another 16 patches which changes the way the L2 cache is initialised on many platforms. This series moves towards a situation where the generic code initialises the L2 cache itself, with as little help as possible from board specific code. A number of platforms are left alone because they're more complex - these should still eventually be converted. At some point in the near future, I will see about sorting out their ordering wrt the previous patch set. For the time being, they apply on top of the existing l2c changes. Are the existing l2c changes in next-20140428? If not, is there a git branch I can pull to test the whole thing, rather than tracking down and applying the existing l2c changes first? I guess they must be in linux-next, since this series applies cleanly on top of it. So, patches 2/16 (ARM: l2c: add platform independent core L2 cache initialisation) and 7/16 (ARM: l2c: convert tegra to generic l2c initialisation), Tested-by: Stephen Warren swar...@nvidia.com (On an NVIDIA Tegra20 Seaboard/Springbank board, on top of next-20140428) I do see one error in dmesg during boot, but it doesn't appear to negatively affect operation in brief testing, and is present in linux-next without this series anyway. Is this message a problem? [0.00] L2C: platform modifies aux control register: 0x0208 - 0x3e480001 [0.00] L2C: DT/platform modifies aux control register: 0x0208 - 0x3e480001 [0.00] L2C-310 errata 727915 769419 enabled [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310: enabling full line of zeros but not enabled in Cortex-A9 ^^ this is logged at error level Correct, it's an error because on Tegra you explicitly set bit 0 in the auxiliary control register, which is pointless unless the feature is also enabled in the Cortex-A9 control register as well. Rather than trying to track down everyone who does this, and then end up in a long discussion about it, I'm just going to make the kernel print an error message as a result, it's just wrong to set random bits in device control registers without first properly understanding what they're doing. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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] ARM: dts: Add peach-pit board support
Tomasz and Arun,
On Sat, Apr 26, 2014 at 4:32 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Arun,
On 24.04.2014 06:17, Arun Kumar K wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes from v1
---
- Addressed review comments from Doug, Sachin Tushar
- Removed adc and lid-switch nodes
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 182
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+ exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..fbb0469
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,182 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include dt-bindings/input/input.h
+#include dt-bindings/gpio/gpio.h
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach,samsung,exynos5420,
+ samsung,exynos5;
Do you really need so many compatible strings here? Furthermore, are all the
newer revisions really fully backwards compatible with older ones?
Also, do you have a way to check the revision in hardware, e.g. by some GPIO
pins? If so, I don't think there would be any need to revision number as a
part of compatible string.
You can send flames mostly my way for this one.
Technically we could replace this with just google,pit for now.
However if we ever actually ship a new / slightly different revision
of pit we might need to introduce these all back in.
I can explain how / why we got to this point if you wish...
Basically:
1. We'd like to support multiple revisions of hardware both during
internal development and post ship. Each unique spin of the board is
assigned a different logical ID even if differences are pretty minor
or they are probe-able. Sometimes we find out much later that
something that was supposed to be a minor change actually necessitates
a device tree change.
I believe we've only shipped rev 13 pit boards. However many people
in-house at Google and Samsung have older revision boards (some even
using as far back as rev 6), so it's very handy to support the old
boards if it's not too difficult.
Examples of types of changes that have happened:
Between rev 8 and rev 9 we switched WiFi chips. That's mostly
probe-able. There's a single GPIO difference in the powerup sequence
but you could use a sequence that's compatible for both. We've had a
unified device tree here since one can work for both, but if we ever
found an issue we could always split it.
On rev 3, 4, and 5 (dts not submitted upstream) we found an issue
where the SoC couldn't handle powering off the INT rail during
suspend.
On rev 3, 4, and 5 we had HDMI's power coming off a different FET.
On rev 4 there was a problem reading the EDID on the panel, so we had
to add special logic to handle this.
On exynos5250-snow there are actually 3 different revisions released
publicly. Right now we only have one device tree but if we want to
fully support audio / touchpad we need at least two. If we want to
enable thermistors on the original rev (optional, really) then we need
a third device tree.
2. As is relatively common, the firmware _doesn't_ ship a device tree.
It picks among devices trees that are part of the kernel.
3. We wanted to avoid hacks in the kernel like if strcmp(compatible,
peach-pit) revision 6 revision 9.
A reasonable solution to the above is to have separate device trees
for separate revisions whenever they are different enough that they
need it. ...and for cases where they're not very different then use
the same device tree.
In the case of peach-pit,
Re: [PATCH 00/16] Another 16 L2C patches
Am Montag, 28. April 2014, 17:56:31 schrieb Russell King - ARM Linux: So, in response to Matt Porter's complaint about breaking prima2, here's another 16 patches which changes the way the L2 cache is initialised on many platforms. This series moves towards a situation where the generic code initialises the L2 cache itself, with as little help as possible from board specific code. Patches 2/16 (ARM: l2c: add platform independent core L2 cache initialisation) and 3/16 (ARM: l2c: convert rockchip to generic l2c initialisation) applied on a linux-next from 20140428, Tested-by: Heiko Stuebner he...@sntech.de -- 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] [media] s5p-mfc: Add IOMMU support
Hi Arun,
On Tuesday 22 April 2014 17:52:08 Arun Kumar K wrote:
On Tue, Apr 22, 2014 at 5:23 PM, Laurent Pinchart wrote:
On Tuesday 22 April 2014 16:32:48 Arun Kumar K wrote:
The patch adds IOMMU support for MFC driver.
I've been working on an IOMMU driver lately, which led me to think about
how drivers should be interfaced with IOMMUs. Runtime IOMMU handling is
performed by the DMA mapping API, but in many cases (including Exynos
platforms) the arm_iommu_create_mapping() and arm_iommu_attach_device()
functions still need to be called explicitly by drivers, which doesn't
seem a very good idea to me. Ideally IOMMU usage should be completely
transparent for bus master drivers, without requiring any driver
modification to use the IOMMU.
What would you think about improving the Exynos IOMMU driver to create the
mapping and attach the device instead of having to modify all bus master
drivers ? See the ipmmu_add_device() function in
http://www.spinics.net/lists/linux-sh/msg30488.html for a possible
implementation.
Yes that would be a better solution. But as far as I know, exynos platforms
has few more complications where multiple IOMMUs are present for single IP.
The exynos iommu work is still under progress and KyonHo Cho will have some
inputs / comments on this. This seems to me a valid usecase which can be
considered for exynos iommu also.
Thank you. Just to be clear, I don't see a reason to delay this patch until
the Exynos IOMMU driver gets support for creating mappings and attaching
devices, but it would be nice to see that happen as a cleanup in the not too
distant future.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
This patch is tested on IOMMU support series [1] posted
by KyonHo Cho.
[1] https://lkml.org/lkml/2014/3/14/9
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 33
+++
1 file changed, 33 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..1f248ba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -32,11 +32,18 @@
#include s5p_mfc_opr.h
#include s5p_mfc_cmd.h
#include s5p_mfc_pm.h
+#ifdef CONFIG_EXYNOS_IOMMU
+#include asm/dma-iommu.h
+#endif
#define S5P_MFC_NAME s5p-mfc
#define S5P_MFC_DEC_NAME s5p-mfc-dec
#define S5P_MFC_ENC_NAME s5p-mfc-enc
+#ifdef CONFIG_EXYNOS_IOMMU
+static struct dma_iommu_mapping *mapping;
+#endif
+
int debug;
module_param(debug, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, Debug level - higher value produces more
verbose
messages); @@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct
platform_device *pdev);
static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
{
+#ifdef CONFIG_EXYNOS_IOMMU
+ struct device *mdev = dev-plat_dev-dev;
+
+ mapping = arm_iommu_create_mapping(platform_bus_type, 0x2000,
+ SZ_256M);
+ if (mapping == NULL) {
+ mfc_err(IOMMU mapping failed\n);
+ return -EFAULT;
+ }
+ mdev-dma_parms = devm_kzalloc(dev-plat_dev-dev,
+ sizeof(*mdev-dma_parms), GFP_KERNEL);
+ dma_set_max_seg_size(mdev, 0xu);
+ arm_iommu_attach_device(mdev, mapping);
+
+ dev-mem_dev_l = dev-mem_dev_r = mdev;
+ return 0;
+#else
unsigned int mem_info[2] = { };
dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
@@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev
*dev) return -ENOMEM;
}
return 0;
+#endif
}
/* MFC probe function */
@@ -1228,6 +1253,10 @@ err_mem_init_ctx_1:
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx[0]);
err_res:
s5p_mfc_final_pm(dev);
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
pr_debug(%s-- with error\n, __func__);
return ret;
@@ -1256,6 +1285,10 @@ static int s5p_mfc_remove(struct platform_device
*pdev) put_device(dev-mem_dev_r);
}
+#ifdef CONFIG_EXYNOS_IOMMU
+ if (mapping)
+ arm_iommu_release_mapping(mapping);
+#endif
s5p_mfc_final_pm(dev);
return 0;
}
--
Regards,
Laurent Pinchart
--
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 1/3] base: power: Add generic OF-based power domain look-up
On 04/23/2014 10:46 AM, Tomasz Figa wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt +==Power domain consumers== + +Required properties: + - power-domain : A phandle and power domain specifier as defined by bindings + of power controller specified by phandle. It seems quite likely that a single logical device could have components in multiple power domains. Consider an HDMI controller with different power domains for the HDMI core, CEC communication, DDC/I2C communication, and the I/O pads, with no clear separation between those two components of the module (no separate register spaces, but the bits/registers are interleaved all together). As such, I think that rather than a power-domain property, we need a pair of power-domains, and power-domain-names properties, and preferably with mandatory usage of name-based lookups, rather than allowing a random mix of name-based and index-based lookups like we have with some existing resource bindings. -- 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 60/97] ARM: l2c: exynos: convert to generic l2c initialisation (and thereby fix it)
exynos was unconditionally calling the L2 cache initialisation from an
early_initcall. This breaks multiplatform kernels. Thankfully,
converting to generic l2c initialisation fixes this.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-exynos/exynos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index fbfc29df3299..a763c0862da9 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -316,12 +316,6 @@ static int __init exynos_core_init(void)
}
core_initcall(exynos_core_init);
-static int __init exynos4_l2x0_cache_init(void)
-{
- return l2x0_of_init(0x3c41, 0xc20f);
-}
-early_initcall(exynos4_l2x0_cache_init);
-
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -387,6 +381,8 @@ static void __init exynos_reserve(void)
DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened Device Tree))
/* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
/* Maintainer: Kukjin Kim kgene@samsung.com */
+ .l2c_aux_val= 0x3c41,
+ .l2c_aux_mask = 0xc20f,
.smp= smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
--
1.8.3.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 59/97] ARM: l2c: exynos: convert to common l2c310 early resume functionality
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-exynos/common.h | 1 -
arch/arm/mach-exynos/exynos.c | 12 +---
arch/arm/mach-exynos/sleep.S | 30 +-
arch/arm/plat-samsung/s5p-sleep.S | 1 -
4 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83efaff..88c619d1e145 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -55,7 +55,6 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
-extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
void __iomem *reg;
unsigned int val[NUM_SYS_POWERDOWN];
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a51bf25e7523..fbfc29df3299 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -318,17 +318,7 @@ core_initcall(exynos_core_init);
static int __init exynos4_l2x0_cache_init(void)
{
- int ret;
-
- ret = l2x0_of_init(0x3c41, 0xc20f);
- if (ret)
- return ret;
-
- if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
- l2x0_regs_phys = virt_to_phys(l2x0_saved_regs);
- clean_dcache_area(l2x0_regs_phys, sizeof(unsigned long));
- }
- return 0;
+ return l2x0_of_init(0x3c41, 0xc20f);
}
early_initcall(exynos4_l2x0_cache_init);
diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S
index 7e0af530511e..108a45f4bb62 100644
--- a/arch/arm/mach-exynos/sleep.S
+++ b/arch/arm/mach-exynos/sleep.S
@@ -16,8 +16,6 @@
*/
#include linux/linkage.h
-#include asm/asm-offsets.h
-#include asm/hardware/cache-l2x0.h
#define CPU_MASK 0xff00
#define CPU_CORTEX_A9 0x410fc090
@@ -53,33 +51,7 @@ ENTRY(exynos_cpu_resume)
and r0, r0, r1
ldr r1, =CPU_CORTEX_A9
cmp r0, r1
- bne skip_l2_resume
- adr r0, l2x0_regs_phys
- ldr r0, [r0]
- cmp r0, #0
- beq skip_l2_resume
- ldr r1, [r0, #L2X0_R_PHY_BASE]
- ldr r2, [r1, #L2X0_CTRL]
- tst r2, #0x1
- bne skip_l2_resume
- ldr r2, [r0, #L2X0_R_AUX_CTRL]
- str r2, [r1, #L2X0_AUX_CTRL]
- ldr r2, [r0, #L2X0_R_TAG_LATENCY]
- str r2, [r1, #L310_TAG_LATENCY_CTRL]
- ldr r2, [r0, #L2X0_R_DATA_LATENCY]
- str r2, [r1, #L310_DATA_LATENCY_CTRL]
- ldr r2, [r0, #L2X0_R_PREFETCH_CTRL]
- str r2, [r1, #L310_PREFETCH_CTRL]
- ldr r2, [r0, #L2X0_R_PWR_CTRL]
- str r2, [r1, #L310_POWER_CTRL]
- mov r2, #1
- str r2, [r1, #L2X0_CTRL]
-skip_l2_resume:
+ bleql2c310_early_resume
#endif
b cpu_resume
ENDPROC(exynos_cpu_resume)
-#ifdef CONFIG_CACHE_L2X0
- .globl l2x0_regs_phys
-l2x0_regs_phys:
- .long 0
-#endif
diff --git a/arch/arm/plat-samsung/s5p-sleep.S
b/arch/arm/plat-samsung/s5p-sleep.S
index c5001659bdf8..25c68ceb9e2b 100644
--- a/arch/arm/plat-samsung/s5p-sleep.S
+++ b/arch/arm/plat-samsung/s5p-sleep.S
@@ -22,7 +22,6 @@
*/
#include linux/linkage.h
-#include asm/asm-offsets.h
.data
.align
--
1.8.3.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: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
On Mon, Apr 28, 2014 at 01:26:46PM +0100, Lee Jones wrote: This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) So I just took a look at the code as zero changes looks suspicious to me. The driver can not simply be copied and pasted into the MFD subsystem in its current state. The fundamental question is; is this chip actually an MFD? What does it do besides Power Management? I looked at the code briefly as well and I don't think it matches the mfd idea. Maybe it could be merged together with arch/arm/mach-exynos/pm.c and moved to drivers/power/ or a more appropriate directory for platform_suspend_ops. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
Since we now automatically enable early BRESP in core L2C-310 code when
we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
explicitly. Instead, they should seek to preserve the value of bit 30
in the auxiliary control register.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-berlin/berlin.c| 2 +-
arch/arm/mach-exynos/exynos.c| 4 ++--
arch/arm/mach-omap2/omap4-common.c | 3 +--
arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 4 ++--
arch/arm/mach-shmobile/board-armadillo800eva.c | 4 ++--
arch/arm/mach-shmobile/board-kzm9g-reference.c | 4 ++--
arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
arch/arm/mach-shmobile/setup-r8a7778.c | 4 ++--
arch/arm/mach-shmobile/setup-r8a7779.c | 4 ++--
arch/arm/mach-spear/spear13xx.c | 2 +-
arch/arm/mach-tegra/tegra.c | 4 ++--
11 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
index 025bcb5473eb..6709d2a6bec8 100644
--- a/arch/arm/mach-berlin/berlin.c
+++ b/arch/arm/mach-berlin/berlin.c
@@ -24,7 +24,7 @@ static void __init berlin_init_machine(void)
* with DT probing for L2CCs, berlin_init_machine can be removed.
* Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
*/
- l2x0_of_init(0x70c0, 0xfeff);
+ l2x0_of_init(0x30c0, 0xfeff);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907d021d..e6828fb46034 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -32,8 +32,8 @@
#include mfc.h
#include regs-pmu.h
-#define L2_AUX_VAL 0x7C470001
-#define L2_AUX_MASK 0xC200
+#define L2_AUX_VAL 0x3c470001
+#define L2_AUX_MASK 0xc200
static struct map_desc exynos4_iodesc[] __initdata = {
{
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index dc9844a55443..9ce52548a484 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -220,8 +220,7 @@ static int __init omap_l2_cache_init(void)
L2C_AUX_CTRL_WAY_SIZE(3) |
L2C_AUX_CTRL_SHARED_OVERRIDE |
L310_AUX_CTRL_DATA_PREFETCH |
- L310_AUX_CTRL_INSTR_PREFETCH |
- L310_AUX_CTRL_EARLY_BRESP;
+ L310_AUX_CTRL_INSTR_PREFETCH;
outer_cache.write_sec = omap4_l2c310_write_sec;
if (of_have_populated_dt())
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 57d1a78367b6..34e7f3c17dd2 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -164,8 +164,8 @@ static void __init eva_init(void)
r8a7740_meram_workaround();
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared attribute override enable, 32K*8way */
- l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
+ /* Shared attribute override enable, 32K*8way */
+ l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
#endif
r8a7740_add_standard_devices_dt();
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..7688990edd3a 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1270,8 +1270,8 @@ static void __init eva_init(void)
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared attribute override enable, 32K*8way */
- l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
+ /* Shared attribute override enable, 32K*8way */
+ l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
#endif
i2c_register_board_info(0, i2c0_devices, ARRAY_SIZE(i2c0_devices));
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c
b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 598e32488410..85873f186d77 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -36,8 +36,8 @@ static void __init kzm_init(void)
sh73a0_add_standard_devices_dt();
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared attribute override enable, 64K*8way */
- l2x0_init(IOMEM(0xf010), 0x4046, 0x82000fff);
+ /* Shared attribute override enable, 64K*8way */
+ l2x0_init(IOMEM(0xf010), 0x0046, 0xc2000fff);
#endif
}
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c
b/arch/arm/mach-shmobile/board-kzm9g.c
index 03dc3ac84502..ea9bf39fdc10 100644
---
[PATCH 58/97] ARM: l2c: exynos: remove cache size override
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-exynos/exynos.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index e6828fb46034..a51bf25e7523 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -32,9 +32,6 @@
#include mfc.h
#include regs-pmu.h
-#define L2_AUX_VAL 0x3c470001
-#define L2_AUX_MASK 0xc200
-
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -323,7 +320,7 @@ static int __init exynos4_l2x0_cache_init(void)
{
int ret;
- ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
+ ret = l2x0_of_init(0x3c41, 0xc20f);
if (ret)
return ret;
--
1.8.3.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 49/97] ARM: l2c: fix register naming
We have a mixture of different devices with different register layouts, but we group all the bits together in an opaque mess. Split them out into those which are L2C-310 specific and ones which refer to earlier devices. Provide full auxiliary control register definitions. Acked-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Shawn Guo shawn@linaro.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/include/asm/hardware/cache-l2x0.h | 73 -- arch/arm/mach-cns3xxx/core.c | 8 ++-- arch/arm/mach-exynos/sleep.S | 8 ++-- arch/arm/mach-imx/system.c | 8 ++-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 2 +- arch/arm/mach-omap2/omap4-common.c | 18 arch/arm/mach-prima2/l2x0.c| 5 +- arch/arm/mach-realview/realview_pbx.c | 4 +- arch/arm/mach-spear/spear13xx.c| 6 +-- arch/arm/mach-sti/board-dt.c | 8 ++-- arch/arm/mach-tegra/sleep.h| 8 ++-- arch/arm/mach-ux500/cache-l2x0.c | 4 +- arch/arm/mach-vexpress/ct-ca9x4.c | 4 +- arch/arm/mm/cache-l2x0.c | 57 +++ 14 files changed, 118 insertions(+), 95 deletions(-) diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h index 3af45734b514..b3ee122c6f24 100644 --- a/arch/arm/include/asm/hardware/cache-l2x0.h +++ b/arch/arm/include/asm/hardware/cache-l2x0.h @@ -26,8 +26,8 @@ #define L2X0_CACHE_TYPE0x004 #define L2X0_CTRL 0x100 #define L2X0_AUX_CTRL 0x104 -#define L2X0_TAG_LATENCY_CTRL 0x108 -#define L2X0_DATA_LATENCY_CTRL 0x10C +#define L310_TAG_LATENCY_CTRL 0x108 +#define L310_DATA_LATENCY_CTRL 0x10C #define L2X0_EVENT_CNT_CTRL0x200 #define L2X0_EVENT_CNT1_CFG0x204 #define L2X0_EVENT_CNT0_CFG0x208 @@ -54,16 +54,16 @@ #define L2X0_LOCKDOWN_WAY_D_BASE 0x900 #define L2X0_LOCKDOWN_WAY_I_BASE 0x904 #define L2X0_LOCKDOWN_STRIDE 0x08 -#define L2X0_ADDR_FILTER_START 0xC00 -#define L2X0_ADDR_FILTER_END 0xC04 +#define L310_ADDR_FILTER_START 0xC00 +#define L310_ADDR_FILTER_END 0xC04 #define L2X0_TEST_OPERATION0xF00 #define L2X0_LINE_DATA 0xF10 #define L2X0_LINE_TAG 0xF30 #define L2X0_DEBUG_CTRL0xF40 -#define L2X0_PREFETCH_CTRL 0xF60 -#define L2X0_POWER_CTRL0xF80 -#define L2X0_DYNAMIC_CLK_GATING_EN (1 1) -#define L2X0_STNDBY_MODE_EN (1 0) +#define L310_PREFETCH_CTRL 0xF60 +#define L310_POWER_CTRL0xF80 +#define L310_DYNAMIC_CLK_GATING_EN (1 1) +#define L310_STNDBY_MODE_EN (1 0) /* Registers shifts and masks */ #define L2X0_CACHE_ID_PART_MASK(0xf 6) @@ -88,29 +88,52 @@ #define L310_CACHE_ID_RTL_R3P3 0x09 #define L2X0_AUX_CTRL_MASK 0xcfff +/* L2C auxiliary control register - bits common to L2C-210/220/310 */ +#define L2C_AUX_CTRL_WAY_SIZE_SHIFT17 +#define L2C_AUX_CTRL_WAY_SIZE_MASK (7 17) +#define L2C_AUX_CTRL_WAY_SIZE(n) ((n) 17) +#define L2C_AUX_CTRL_EVTMON_ENABLE BIT(20) +#define L2C_AUX_CTRL_PARITY_ENABLE BIT(21) +#define L2C_AUX_CTRL_SHARED_OVERRIDE BIT(22) +/* L2C-210/220 common bits */ #define L2X0_AUX_CTRL_DATA_RD_LATENCY_SHIFT0 -#define L2X0_AUX_CTRL_DATA_RD_LATENCY_MASK 0x7 +#define L2X0_AUX_CTRL_DATA_RD_LATENCY_MASK (7 0) #define L2X0_AUX_CTRL_DATA_WR_LATENCY_SHIFT3 -#define L2X0_AUX_CTRL_DATA_WR_LATENCY_MASK (0x7 3) +#define L2X0_AUX_CTRL_DATA_WR_LATENCY_MASK (7 3) #define L2X0_AUX_CTRL_TAG_LATENCY_SHIFT6 -#define L2X0_AUX_CTRL_TAG_LATENCY_MASK (0x7 6) +#define L2X0_AUX_CTRL_TAG_LATENCY_MASK (7 6) #define L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT 9 -#define L2X0_AUX_CTRL_DIRTY_LATENCY_MASK (0x7 9) -#define L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT 16 -#define L2X0_AUX_CTRL_WAY_SIZE_SHIFT 17 -#define L2X0_AUX_CTRL_WAY_SIZE_MASK(0x7 17) -#define L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT 22 -#define L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT26 -#define L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT27 -#define L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT 28 -#define L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT 29 -#define L2X0_AUX_CTRL_EARLY_BRESP_SHIFT30 +#define L2X0_AUX_CTRL_DIRTY_LATENCY_MASK (7 9) +#define L2X0_AUX_CTRL_ASSOC_SHIFT 13 +#define L2X0_AUX_CTRL_ASSOC_MASK (15 13) +/* L2C-210 specific bits */ +#define L210_AUX_CTRL_WRAP_DISABLE BIT(12) +#define L210_AUX_CTRL_WA_OVERRIDE
Re: [PATCH 00/16] Another 16 L2C patches
On 04/28/2014 11:12 AM, Stephen Warren wrote: On 04/28/2014 10:56 AM, Russell King - ARM Linux wrote: So, in response to Matt Porter's complaint about breaking prima2, here's another 16 patches which changes the way the L2 cache is initialised on many platforms. This series moves towards a situation where the generic code initialises the L2 cache itself, with as little help as possible from board specific code. A number of platforms are left alone because they're more complex - these should still eventually be converted. At some point in the near future, I will see about sorting out their ordering wrt the previous patch set. For the time being, they apply on top of the existing l2c changes. Are the existing l2c changes in next-20140428? If not, is there a git branch I can pull to test the whole thing, rather than tracking down and applying the existing l2c changes first? I guess they must be in linux-next, since this series applies cleanly on top of it. So, patches 2/16 (ARM: l2c: add platform independent core L2 cache initialisation) and 7/16 (ARM: l2c: convert tegra to generic l2c initialisation), Tested-by: Stephen Warren swar...@nvidia.com (On an NVIDIA Tegra20 Seaboard/Springbank board, on top of next-20140428) I do see one error in dmesg during boot, but it doesn't appear to negatively affect operation in brief testing, and is present in linux-next without this series anyway. Is this message a problem? [0.00] L2C: platform modifies aux control register: 0x0208 - 0x3e480001 [0.00] L2C: DT/platform modifies aux control register: 0x0208 - 0x3e480001 [0.00] L2C-310 errata 727915 769419 enabled [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310: enabling full line of zeros but not enabled in Cortex-A9 ^^ this is logged at error level [0.00] L2C-310 ID prefetch enabled, offset 1 lines [0.00] L2C-310 dynamic clock gating disabled, standby mode disabled [0.00] L2C-310 cache controller enabled, 8 ways, 1024 kB [0.00] L2C-310: CACHE_ID 0x41c4, AUX_CTRL 0x7e480001 -- 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 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On 04/28/2014 01:30 PM, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Stephen Warren swar...@nvidia.com -- 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 49/97] ARM: l2c: fix register naming
On 04/28/2014 01:30 PM, Russell King wrote: We have a mixture of different devices with different register layouts, but we group all the bits together in an opaque mess. Split them out into those which are L2C-310 specific and ones which refer to earlier devices. Provide full auxiliary control register definitions. Acked-by: Stephen Warren swar...@nvidia.com -- 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 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
Hi YoungJun,
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 ++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
[snip]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
[snip]
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+struct drm_connector *connector = panel-connector;
+struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+struct drm_display_mode *mode;
+
+mode = drm_mode_create(connector-dev);
+if (!mode) {
+DRM_ERROR(failed to create a new display mode\n);
+return 0;
+}
+
+drm_display_mode_from_videomode(ctx-vm, mode);
+mode-width_mm = ctx-width_mm;
+mode-height_mm = ctx-height_mm;
+connector-display_info.width_mm = mode-width_mm;
+connector-display_info.height_mm = mode-height_mm;
+
+mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+mode-private = (void *)ctx-cpu_timings;
Wouldn't it make sense to create a new get_interface_params (or similar)
operation for drm_panel to query interface configuration parameters
instead of shoving it in the mode private field ?
You mean new get_interface_params operation is different from
get_modes() ?
Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.
I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.
Could you explain it in more detail?
The idea is that the interface parameters (RD/WR signals timings in this
case,
but this could also include MIPI DSI lane configuration or any other kind of
physical interface parameters) are distinct from the video modes.
We already have the lanes field in struct mipi_dsi_device. I think in
general I'd prefer to not spread these parameters around too wildly. If
this is a general requirement for DBI devices, perhaps what we need is
struct mipi_dbi_device?
Thierry
pgpaK4xtb2rbz.pgp
Description: PGP signature
Re: [PATCH 2/5 v2] iio: exynos_adc: rearrange clk and regulator enable/disable calls
Naveen,
On Sat, Apr 26, 2014 at 4:37 AM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch maintains the following order in
probe(), remove(), resume() and suspend() calls
regulator enable, clk prepare enable
...
clk disable unprepare, regulator disable
While at it,
1. enable the regulator before the iio_device_register()
2. handle the return values for enable/disable calls
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
---
Changes since v1:
corrected the register/unregister and enabling/disbaling sequences
drivers/iio/adc/exynos_adc.c | 63
+++---
1 file changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index affa93f..0df8916 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -290,32 +290,30 @@ static int exynos_adc_probe(struct platform_device
*pdev)
init_completion(info-completion);
- ret = request_irq(info-irq, exynos_adc_isr,
- 0, dev_name(pdev-dev), info);
- if (ret 0) {
- dev_err(pdev-dev, failed requesting irq, irq = %d\n,
- info-irq);
- return ret;
- }
-
- writel(1, info-enable_reg);
-
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
PTR_ERR(info-clk));
- ret = PTR_ERR(info-clk);
- goto err_irq;
+ return PTR_ERR(info-clk);
}
info-vdd = devm_regulator_get(pdev-dev, vdd);
if (IS_ERR(info-vdd)) {
dev_err(pdev-dev, failed getting regulator, err = %ld\n,
PTR_ERR(info-vdd));
- ret = PTR_ERR(info-vdd);
- goto err_irq;
+ return PTR_ERR(info-vdd);
}
+ ret = regulator_enable(info-vdd);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(info-clk);
+ if (ret)
+ goto err_disable_reg;
+
+ writel(1, info-enable_reg);
+
info-version = exynos_adc_get_version(pdev);
platform_set_drvdata(pdev, indio_dev);
@@ -332,16 +330,18 @@ static int exynos_adc_probe(struct platform_device
*pdev)
else
indio_dev-num_channels = MAX_ADC_V2_CHANNELS;
+ ret = request_irq(info-irq, exynos_adc_isr,
+ 0, dev_name(pdev-dev), info);
+ if (ret 0) {
+ dev_err(pdev-dev, failed requesting irq, irq = %d\n,
+ info-irq);
+ goto err_disable_clk;
+ }
+
ret = iio_device_register(indio_dev);
if (ret)
goto err_irq;
- ret = regulator_enable(info-vdd);
- if (ret)
- goto err_iio_dev;
-
- clk_prepare_enable(info-clk);
-
exynos_adc_hw_init(info);
ret = of_platform_populate(np, exynos_adc_match, NULL,
indio_dev-dev);
@@ -355,12 +355,14 @@ static int exynos_adc_probe(struct platform_device
*pdev)
err_of_populate:
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
-err_iio_dev:
iio_device_unregister(indio_dev);
err_irq:
free_irq(info-irq, info);
+err_disable_clk:
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+err_disable_reg:
+ regulator_disable(info-vdd);
return ret;
}
@@ -371,11 +373,12 @@ static int exynos_adc_remove(struct platform_device
*pdev)
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
- writel(0, info-enable_reg);
iio_device_unregister(indio_dev);
free_irq(info-irq, info);
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+ regulator_disable(info-vdd);
+
nit: one too many blank lines here
return 0;
}
@@ -397,8 +400,8 @@ static int exynos_adc_suspend(struct device *dev)
writel(con, ADC_V1_CON(info-regs));
}
- clk_disable_unprepare(info-clk);
writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
regulator_disable(info-vdd);
return 0;
@@ -414,9 +417,11 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
- writel(1, info-enable_reg);
- clk_prepare_enable(info-clk);
+
Re: [PATCH v12 30/31] ARM: dts: add System MMU nodes of exynos5250
Vikas,
On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan sajjan.li...@gmail.com wrote:
Hi shaik,
+Doug, Abhilash,
On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
From: Cho KyongHo pullip@samsung.com
Signed-off-by: Cho KyongHo pullip@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 270
-
1 file changed, 267 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..eebd397 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -82,6 +82,16 @@
reg = 0x10044040 0x20;
};
+ pd_isp: isp-power-domain@0x10044020 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044020 0x20;
+ };
+
+ pd_disp1: disp1-power-domain@0x100440A0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440A0 0x20;
+ };
+
As per subject add System MMU nodes of exynos5250, it should only
add SysMMU node.
So, I think adding power domain nodes should go in a separate patch.
Adding power domain nodes can break the system, if powering ON/OFF of
the given power domain is NOT taken care well.
I can see ISP is one such case. With this series I can see S2R breaks
[1] on 5250 chromebook with current mainline kernel (same applies for
arndale and smdk5250, but I have tested on these boards yet)
Thanks for catching that! Let's make sure not to break suspend/resume.
Given that these power domains are actually used as the domains for
some of the System MMU nodes I don't totally object to adding them in
the same patch, but if they're breaking things then I agree that we
could leave them out and add them in a later patch (once issues are
sorted out).
-Doug
--
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 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
Since we now automatically enable early BRESP in core L2C-310 code when
we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
explicitly. Instead, they should seek to preserve the value of bit 30
in the auxiliary control register.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
I would prefer if this patch was broken out into individual patches
for each board or SoC file and that they were then picked up
by their respective platform maintainers.
Likewise for patch 66/97. Although it is only for shmobile
I would prefer it broken out.
---
arch/arm/mach-berlin/berlin.c| 2 +-
arch/arm/mach-exynos/exynos.c| 4 ++--
arch/arm/mach-omap2/omap4-common.c | 3 +--
arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 4 ++--
arch/arm/mach-shmobile/board-armadillo800eva.c | 4 ++--
arch/arm/mach-shmobile/board-kzm9g-reference.c | 4 ++--
arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
arch/arm/mach-shmobile/setup-r8a7778.c | 4 ++--
arch/arm/mach-shmobile/setup-r8a7779.c | 4 ++--
arch/arm/mach-spear/spear13xx.c | 2 +-
arch/arm/mach-tegra/tegra.c | 4 ++--
11 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
index 025bcb5473eb..6709d2a6bec8 100644
--- a/arch/arm/mach-berlin/berlin.c
+++ b/arch/arm/mach-berlin/berlin.c
@@ -24,7 +24,7 @@ static void __init berlin_init_machine(void)
* with DT probing for L2CCs, berlin_init_machine can be removed.
* Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
*/
- l2x0_of_init(0x70c0, 0xfeff);
+ l2x0_of_init(0x30c0, 0xfeff);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907d021d..e6828fb46034 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -32,8 +32,8 @@
#include mfc.h
#include regs-pmu.h
-#define L2_AUX_VAL 0x7C470001
-#define L2_AUX_MASK 0xC200
+#define L2_AUX_VAL 0x3c470001
+#define L2_AUX_MASK 0xc200
static struct map_desc exynos4_iodesc[] __initdata = {
{
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index dc9844a55443..9ce52548a484 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -220,8 +220,7 @@ static int __init omap_l2_cache_init(void)
L2C_AUX_CTRL_WAY_SIZE(3) |
L2C_AUX_CTRL_SHARED_OVERRIDE |
L310_AUX_CTRL_DATA_PREFETCH |
-L310_AUX_CTRL_INSTR_PREFETCH |
-L310_AUX_CTRL_EARLY_BRESP;
+L310_AUX_CTRL_INSTR_PREFETCH;
outer_cache.write_sec = omap4_l2c310_write_sec;
if (of_have_populated_dt())
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 57d1a78367b6..34e7f3c17dd2 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -164,8 +164,8 @@ static void __init eva_init(void)
r8a7740_meram_workaround();
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared attribute override enable, 32K*8way */
- l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
+ /* Shared attribute override enable, 32K*8way */
+ l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
#endif
r8a7740_add_standard_devices_dt();
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..7688990edd3a 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1270,8 +1270,8 @@ static void __init eva_init(void)
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared attribute override enable, 32K*8way */
- l2x0_init(IOMEM(0xf0002000), 0x4044, 0x82000fff);
+ /* Shared attribute override enable, 32K*8way */
+ l2x0_init(IOMEM(0xf0002000), 0x0044, 0xc2000fff);
#endif
i2c_register_board_info(0, i2c0_devices, ARRAY_SIZE(i2c0_devices));
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c
b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 598e32488410..85873f186d77 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -36,8 +36,8 @@ static void __init kzm_init(void)
sh73a0_add_standard_devices_dt();
#ifdef CONFIG_CACHE_L2X0
- /* Early BRESP enable, Shared
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Tue, Apr 29, 2014 at 09:02:27AM +0900, Simon Horman wrote: On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I would prefer if this patch was broken out into individual patches for each board or SoC file and that they were then picked up by their respective platform maintainers. Likewise for patch 66/97. Although it is only for shmobile I would prefer it broken out. Oh fuck that. Okay, I'm dropping the whole patch set right now and forgetting the whole damned thing. The L2 cache code can damned well stay as it is and remain an unmaintainable mess. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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
[PATCHv5] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
From: Kyungmin Park kyungmin.p...@samsung.com
This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Changes from v4:
- Post only this patch separated from following patchset[1]
[1] https://lkml.org/lkml/2014/4/24/873
arch/arm/mach-exynos/firmware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
#include mach/map.h
+#include plat/cpu.h
+
#include smc.h
static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+ if (soc_is_exynos4212())
+ cpu = 0;
+
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;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/7] arm64: mm: Implement 4 levels of translation tables
On Monday, April 28, 2014 10:24 PM, Steve Capper wrote: On Sun, Apr 27, 2014 at 12:37:35PM +0900, Jungseok Lee wrote: On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote: On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote: [ ... ] This is overly complicated. For 4 levels we set x0 to be: ttbr1 + 2*PAGE_SIZE. For 4-levels, we set x0 to be ttbr1 + PAGE_SIZE, then inside the create_pgd_entry macro, we check the VA for FIXADDR_TOP then add another PAGE_SIZE. This is presumably done so the same PUD is used for the swapper block map and the FIXADDR map. Is it too complicated to understand the logic? 1) For 4 levels: PAGE_SIZE is added for FIXADDR map and x0 is passed to create pgd entry. 2) For =4 levels: PAGE_SIZE is added in the create_pgd_entry macro since FIXADDR map info is needed to create pud entry. However, I agree that the code should be revised if other people feel like it is a labyrinthine logic. If you assume that the PUD always follows the PGD for 4-levels, then you can remove this #ifdef and the conditional VA logic in set_pgd_entry. To make the logic simpler for 4 levels, you could call create_pud_entry in the middle of create_pgd_entry, then put down the actual pgd after. create_pud_entry should distinguish block map from FIXADDR map although PUD always follows the PGD in case of 4 levels. If we would like to avoid unnecessary #ifdef, the conditional logic should be introduced in create_ pgd_entry macro. I cannot find the best way even though I've tried to figure it out. I would like to find out the most clear and self-descriptive expression. Could you give an idea on how to remove both conditional VA logic and #ifdef? Hello Jungseok, I had the following logic in my head: It compiles and runs on the model, but I've not tried it in anger. Hello Steve, It works well as both host and guest on the model. = .macro create_pud_entry, pgd, tbl, virt, pud, tmp1, tmp2 #ifdef CONFIG_ARM64_4_LEVELS add \tbl, \tbl, #PAGE_SIZE // bump tbl 1 page up. // to make room for pud add \pud, \pgd, #PAGE_SIZE // pgd points to pud which // follows pgd lsr \tmp1, \virt, #PUD_SHIFT and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index orr \tmp2, \tbl, #3 // PUD entry table type str \tmp2, [\pud, \tmp1, lsl #3] #else mov \pud, \tbl // pgd points to section table // directly for 4 levels #endif .endm /* * Macro to populate the PGD for the corresponding block entry in the next * level (tbl) for the given virtual address. * * Preserves: pgd, virt * Corrupts: tmp1, tmp2, tmp3 * Returns: tbl - page where block mappings can be placed *(changed to make room for pud with 4levels, preserved otherwise) */ .macro create_pgd_entry, pgd, tbl, virt, tmp1, tmp2, tmp3 create_pud_entry \pgd, \tbl, \virt, \tmp3, \tmp1, \tmp2 lsr \tmp1, \virt, #PGDIR_SHIFT and \tmp1, \tmp1, #PTRS_PER_PGD - 1 // PGD index orr \tmp2, \tmp3, #3// PGD entry table type str \tmp2, [\pgd, \tmp1, lsl #3] .endm = [Note I've changed the extra argument to create_pgd_entry to be at the end to make it easier to diff callers] So essentially, we bump up tbl if we are running with 4 levels of page table. We put the pgd down after the pud, and this allows us to sneak a pud in after the pgd if we need to, otherwise it points to the target for the section mapping. Does this work for you? (I go cross-eyed with too much assembler, so could have easily missed something). It is a better description compared to my logic. I fully understand your intention now. It would be good to adopt your code instead of mine. How about participating as an author of this part if you are okay? I am posting v4 patches as soon as possible and then figuring out a way to take you as an author of this head.S. + create_pgd_entry x26, x0, x1, x5, x6, x7 So before this patch we have the following created by __create_page_tables: ++ --- TEXT_OFFSET + PHYS_OFFSET | FIXADDR (pmd or pte) | ++ | block map (pmd or pte) | ++ | PGDs for swapper | ++ --- TTBR1 swapper_pg_dir | block map for idmap| ++ | PGDs for idmap | ++ --- TTBR0 idmap_pg_dir After the patch, for 4 levels activated we have:
[PATCH] net: sxgbe: Added set function for interrupt on complete
This patch adds set_rx_int_on_com function for interrupt when
dma is completed.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c |7 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h |3 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |1 +
3 files changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c
index d71691b..2686bb5 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c
@@ -233,6 +233,12 @@ static void sxgbe_set_rx_owner(struct sxgbe_rx_norm_desc
*p)
p-rdes23.rx_rd_des23.own_bit = 1;
}
+/* Set Interrupt on completion bit */
+static void sxgbe_set_rx_int_on_com(struct sxgbe_rx_norm_desc *p)
+{
+ p-rdes23.rx_rd_des23.int_on_com = 1;
+}
+
/* Get the receive frame size */
static int sxgbe_get_rx_frame_len(struct sxgbe_rx_norm_desc *p)
{
@@ -498,6 +504,7 @@ static const struct sxgbe_desc_ops desc_ops = {
.init_rx_desc = sxgbe_init_rx_desc,
.get_rx_owner = sxgbe_get_rx_owner,
.set_rx_owner = sxgbe_set_rx_owner,
+ .set_rx_int_on_com = sxgbe_set_rx_int_on_com,
.get_rx_frame_len = sxgbe_get_rx_frame_len,
.get_rx_fd_status = sxgbe_get_rx_fd_status,
.get_rx_ld_status = sxgbe_get_rx_ld_status,
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
index 0226300..1860932 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
@@ -258,6 +258,9 @@ struct sxgbe_desc_ops {
/* Set own bit */
void (*set_rx_owner)(struct sxgbe_rx_norm_desc *p);
+ /* Set Interrupt on completion bit */
+ void (*set_rx_int_on_com)(struct sxgbe_rx_norm_desc *p);
+
/* Get the receive frame size */
int (*get_rx_frame_len)(struct sxgbe_rx_norm_desc *p);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index fd5c428..82a9a98 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1456,6 +1456,7 @@ static void sxgbe_rx_refill(struct sxgbe_priv_data *priv)
/* Added memory barrier for RX descriptor modification */
wmb();
priv-hw-desc-set_rx_owner(p);
+ priv-hw-desc-set_rx_int_on_com(p);
/* Added memory barrier for RX descriptor modification */
wmb();
}
--
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] net: sxgbe: Added rxqueue enable function
This patch adds rxqueue enable function according to number of rxqueue
and adds rxqueue disable function for removing.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h |2 ++
drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c | 22 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |8
drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h|4
4 files changed, 36 insertions(+)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index 6203c7d..4501964 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -358,6 +358,8 @@ struct sxgbe_core_ops {
/* Enable disable checksum offload operations */
void (*enable_rx_csum)(void __iomem *ioaddr);
void (*disable_rx_csum)(void __iomem *ioaddr);
+ void (*enable_rxqueue)(void __iomem *ioaddr, int queue_num);
+ void (*disable_rxqueue)(void __iomem *ioaddr, int queue_num);
};
const struct sxgbe_core_ops *sxgbe_get_core_ops(void);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
index c4da7a2..58c3569 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
@@ -165,6 +165,26 @@ static void sxgbe_core_set_speed(void __iomem *ioaddr,
unsigned char speed)
writel(tx_cfg, ioaddr + SXGBE_CORE_TX_CONFIG_REG);
}
+static void sxgbe_core_enable_rxqueue(void __iomem *ioaddr, int queue_num)
+{
+ u32 reg_val;
+
+ reg_val = readl(ioaddr + SXGBE_CORE_RX_CTL0_REG);
+ reg_val = ~(SXGBE_CORE_RXQ_ENABLE_MASK queue_num);
+ reg_val |= SXGBE_CORE_RXQ_ENABLE;
+ writel(reg_val, ioaddr + SXGBE_CORE_RX_CTL0_REG);
+}
+
+static void sxgbe_core_disable_rxqueue(void __iomem *ioaddr, int queue_num)
+{
+ u32 reg_val;
+
+ reg_val = readl(ioaddr + SXGBE_CORE_RX_CTL0_REG);
+ reg_val = ~(SXGBE_CORE_RXQ_ENABLE_MASK queue_num);
+ reg_val |= SXGBE_CORE_RXQ_DISABLE;
+ writel(reg_val, ioaddr + SXGBE_CORE_RX_CTL0_REG);
+}
+
static void sxgbe_set_eee_mode(void __iomem *ioaddr)
{
u32 ctrl;
@@ -254,6 +274,8 @@ static const struct sxgbe_core_ops core_ops = {
.set_eee_pls= sxgbe_set_eee_pls,
.enable_rx_csum = sxgbe_enable_rx_csum,
.disable_rx_csum= sxgbe_disable_rx_csum,
+ .enable_rxqueue = sxgbe_core_enable_rxqueue,
+ .disable_rxqueue= sxgbe_core_disable_rxqueue,
};
const struct sxgbe_core_ops *sxgbe_get_core_ops(void)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 6ad7b3a..fd5c428 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1076,6 +1076,9 @@ static int sxgbe_open(struct net_device *dev)
/* Initialize the MAC Core */
priv-hw-mac-core_init(priv-ioaddr);
+ SXGBE_FOR_EACH_QUEUE(SXGBE_RX_QUEUES, queue_num) {
+ priv-hw-mac-enable_rxqueue(priv-ioaddr, queue_num);
+ }
/* Request the IRQ lines */
ret = devm_request_irq(priv-device, priv-irq, sxgbe_common_interrupt,
@@ -2240,9 +2243,14 @@ error_free_netdev:
int sxgbe_drv_remove(struct net_device *ndev)
{
struct sxgbe_priv_data *priv = netdev_priv(ndev);
+ u8 queue_num;
netdev_info(ndev, %s: removing driver\n, __func__);
+ SXGBE_FOR_EACH_QUEUE(SXGBE_RX_QUEUES, queue_num) {
+ priv-hw-mac-disable_rxqueue(priv-ioaddr, queue_num);
+ }
+
priv-hw-dma-stop_rx(priv-ioaddr, SXGBE_RX_QUEUES);
priv-hw-dma-stop_tx(priv-ioaddr, SXGBE_TX_QUEUES);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h
index 5a89acb..56f8bf5 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h
@@ -52,6 +52,10 @@
#define SXGBE_CORE_RX_CTL2_REG 0x00A8
#define SXGBE_CORE_RX_CTL3_REG 0x00AC
+#define SXGBE_CORE_RXQ_ENABLE_MASK 0x0003
+#define SXGBE_CORE_RXQ_ENABLE 0x0002
+#define SXGBE_CORE_RXQ_DISABLE 0x
+
/* Interrupt Registers */
#define SXGBE_CORE_INT_STATUS_REG 0x00B0
#define SXGBE_CORE_INT_ENABLE_REG 0x00B4
--
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 v4 0/7] Support 4 levels of translation tables for ARM64
Hi All, This v4 patchset supports 4 levels of tranlsation tables for ARM64. Firstly, The patchset decouples page size from level of translation tables as taking account into the comment from Catalin Marinas: http://www.spinics.net/linux/lists/arm-kernel/msg319552.html Then, it implements 4 levels of translation tables for native, HYP and stage2 sides. All ARMv8 and ARMv7 related changes are validated with FastModels+kvmtool and A15+QEMU, respectively. Changes since v1: - fixed unmatched data types as per Steve's comment - removed unnecessary #ifdef in arch/arm64/mm/* as per Steve's comment - revised create_pgd_entry to deal with PUD entry as per Steve's comment - introduced a macro for initial memblock limit as per Steve's comment - dropped Fix line length exceeding 80 characters patch as per Marc's comment - removed unnecessary #ifdef in arch/arm/kvm/mmu.c as per Marc's comment - added a macro for a number of objects of as per Marc's comment Changes since v2: - revised some macros in a generic way as per Marc's comment - added a 2 level option for kvm mmu cache allocation as per Marc's comment Changes since v3: - added #ifdef to decide swapper and idmap size as per Steve's comment - introduced Steve's create_pgd_entry Jungseok Lee (7): arm64: Use pr_* instead of printk arm64: Decouple page size from level of translation tables arm64: Introduce a kernel configuration option for VA_BITS arm64: Add a description on 48-bit address space with 4KB pages arm64: Add 4 levels of page tables definition with 4KB pages arm64: mm: Implement 4 levels of translation tables arm64: KVM: Implement 4 levels of translation tables for HYP and stage2 Documentation/arm64/memory.txt| 59 +-- arch/arm/include/asm/kvm_mmu.h| 10 ++ arch/arm/kvm/mmu.c| 88 ++--- arch/arm64/Kconfig| 51 +- arch/arm64/include/asm/kvm_arm.h | 34 +-- arch/arm64/include/asm/kvm_mmu.h | 12 +++ arch/arm64/include/asm/memblock.h |6 ++ arch/arm64/include/asm/memory.h |6 +- arch/arm64/include/asm/page.h |6 +- arch/arm64/include/asm/pgalloc.h | 24 - arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 ++ arch/arm64/include/asm/pgtable-4level-types.h | 71 + arch/arm64/include/asm/pgtable-hwdef.h|8 +- arch/arm64/include/asm/pgtable.h | 53 +- arch/arm64/include/asm/tlb.h | 11 ++- arch/arm64/kernel/head.S | 46 +++-- arch/arm64/kernel/traps.c | 19 ++-- arch/arm64/mm/fault.c |1 + arch/arm64/mm/mmu.c | 16 ++- 19 files changed, 508 insertions(+), 63 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages
This patch adds memory layout and translation lookup information about 48-bit address space with 4K pages. The description is based on 4 levels of translation tables. Cc: Catalin Marinas catalin.mari...@arm.com Cc: Steve Capper steve.cap...@linaro.org Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com --- Documentation/arm64/memory.txt | 59 ++-- 1 file changed, 51 insertions(+), 8 deletions(-) diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index d50fa61..8142709 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables with +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB) +virtual addresses, respectively, for both user and kernel. With 64KB +pages, only 2 levels of translation tables are used but the memory layout +is the same. User addresses have bits 63:39 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the @@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to TTBR0. -AArch64 Linux memory layout with 4KB pages: +AArch64 Linux memory layout with 4KB pages + 3 levels: Start End SizeUse --- @@ -48,7 +49,34 @@ ffbffc00 ffbf 64MB modules ffc0 256GB kernel logical memory map -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +Start End SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc + +7bff 7bff 64KB [guard page] + +7c00 7dff 2TB vmemmap + +7e00 7bbf ~2TB [guard, future vmmemap] + +7a00 7aff 16MB PCI I/O space + +7b00 7bbf 12MB [guard] + +7bc0 7bdf 2MB earlyprintk device + +7be0 7bff 2MB [guard] + +7c00 7fff 64MB modules + +8000 128TB kernel logical memory map + + +AArch64 Linux memory layout with 64KB pages + 2 levels: Start End SizeUse --- @@ -75,7 +103,7 @@ fdfffc00 fdff 64MB modules fe00 2TB kernel logical memory map -Translation table lookup with 4KB pages: +Translation table lookup with 4KB pages + 3 levels: +++++++++ |6356|5548|4740|3932|3124|2316|15 8|7 0| @@ -90,7 +118,22 @@ Translation table lookup with 4KB pages: +- [63] TTBR0/1 -Translation table lookup with 64KB pages: +Translation table lookup with 4KB pages + 4 levels: + ++++++++++ +|6356|5548|4740|3932|3124|2316|15 8|7 0| ++++++++++ + | | | | | | + | | | | | v + | | | | | [11:0] in-page offset + | | | | +- [20:12] L3 index + | | | +--- [29:21] L2 index + | | +- [38:30] L1 index + | +--- [47:39] L0 index + +- [63] TTBR0/1 + + +Translation table lookup with 64KB pages + 2 levels:
[PATCH v4 6/7] arm64: mm: Implement 4 levels of translation tables
This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.
It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.
If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.
References
--
[1]: Principles of ARM Memory Maps, White Paper, Issue C
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig |7 +
arch/arm64/include/asm/memblock.h |6 +
arch/arm64/include/asm/page.h |4 ++-
arch/arm64/include/asm/pgalloc.h | 20 ++
arch/arm64/include/asm/pgtable-hwdef.h |6 +++--
arch/arm64/include/asm/pgtable.h | 45 +++
arch/arm64/include/asm/tlb.h |9 +++
arch/arm64/kernel/head.S | 46 +---
arch/arm64/kernel/traps.c |5
arch/arm64/mm/fault.c |1 +
arch/arm64/mm/mmu.c| 16 ---
11 files changed, 149 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b8d429..6b01025 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -184,12 +184,19 @@ config ARM64_3_LEVELS
help
This feature enables 3 levels of translation tables.
+config ARM64_4_LEVELS
+ bool 4 level
+ depends on ARM64_4K_PAGES
+ help
+ This feature enables 4 levels of translation tables.
+
endchoice
config ARM64_VA_BITS
int Virtual address space size
range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS
range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS
+ range 48 48 if ARM64_4K_PAGES ARM64_4_LEVELS
help
This feature is determined by a combination of page size and
level of translation tables.
diff --git a/arch/arm64/include/asm/memblock.h
b/arch/arm64/include/asm/memblock.h
index 6afeed2..e4ac8bf 100644
--- a/arch/arm64/include/asm/memblock.h
+++ b/arch/arm64/include/asm/memblock.h
@@ -16,6 +16,12 @@
#ifndef __ASM_MEMBLOCK_H
#define __ASM_MEMBLOCK_H
+#ifndef CONFIG_ARM64_4_LEVELS
+#define MEMBLOCK_INITIAL_LIMIT PGDIR_SIZE
+#else
+#define MEMBLOCK_INITIAL_LIMIT PUD_SIZE
+#endif
+
extern void arm64_memblock_init(void);
#endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-types.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include asm/pgtable-3level-types.h
+#else
+#include asm/pgtable-4level-types.h
#endif
extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
#define check_pgt_cache() do { } while (0)
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+ return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+ BUG_ON((unsigned long)pud (PAGE_SIZE-1));
+ free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+ set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif /* CONFIG_ARM64_4_LEVELS */
+
#ifndef CONFIG_ARM64_2_LEVELS
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index 9cd86c6..ba30053 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-hwdef.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include asm/pgtable-3level-hwdef.h
+#else
+#include asm/pgtable-4level-hwdef.h
#endif
/*
@@ -27,7 +29,7 @@
*
* Level 1 descriptor (PUD).
*/
-
[PATCH v4 5/7] arm64: Add 4 levels of page tables definition with 4KB pages
This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 +
arch/arm64/include/asm/pgtable-4level-types.h | 71 +
2 files changed, 121 insertions(+)
create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h
diff --git a/arch/arm64/include/asm/pgtable-4level-hwdef.h
b/arch/arm64/include/asm/pgtable-4level-hwdef.h
new file mode 100644
index 000..0ec84e2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-hwdef.h
@@ -0,0 +1,50 @@
+/*
+ * 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.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_HWDEF_H
+#define __ASM_PGTABLE_4LEVEL_HWDEF_H
+
+#define PTRS_PER_PTE 512
+#define PTRS_PER_PMD 512
+#define PTRS_PER_PUD 512
+#define PTRS_PER_PGD 512
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map.
+ */
+#define PGDIR_SHIFT39
+#define PGDIR_SIZE (_AC(1, UL) PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/*
+ * PUD_SHIFT determines the size the second level page table entry can map.
+ */
+#define PUD_SHIFT 30
+#define PUD_SIZE (_AC(1, UL) PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE-1))
+
+/*
+ * PMD_SHIFT determines the size the third level page table entry can map.
+ */
+#define PMD_SHIFT 21
+#define PMD_SIZE (_AC(1, UL) PMD_SHIFT)
+#define PMD_MASK (~(PMD_SIZE-1))
+
+/*
+ * section address mask and size definitions.
+ */
+#define SECTION_SHIFT 21
+#define SECTION_SIZE (_AC(1, UL) SECTION_SHIFT)
+#define SECTION_MASK (~(SECTION_SIZE-1))
+
+#endif
diff --git a/arch/arm64/include/asm/pgtable-4level-types.h
b/arch/arm64/include/asm/pgtable-4level-types.h
new file mode 100644
index 000..7ad8dd2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-types.h
@@ -0,0 +1,71 @@
+/*
+ * 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.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_TYPES_H
+#define __ASM_PGTABLE_4LEVEL_TYPES_H
+
+#include asm/types.h
+
+typedef u64 pteval_t;
+typedef u64 pmdval_t;
+typedef u64 pudval_t;
+typedef u64 pgdval_t;
+
+#undef STRICT_MM_TYPECHECKS
+
+#ifdef STRICT_MM_TYPECHECKS
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef struct { pteval_t pte; } pte_t;
+typedef struct { pmdval_t pmd; } pmd_t;
+typedef struct { pudval_t pud; } pud_t;
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pteval_t pgprot; } pgprot_t;
+
+#define pte_val(x) ((x).pte)
+#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
+#define pgd_val(x) ((x).pgd)
+#define pgprot_val(x) ((x).pgprot)
+
+#define __pte(x) ((pte_t) { (x) } )
+#define __pmd(x) ((pmd_t) { (x) } )
+#define __pud(x) ((pud_t) { (x) } )
+#define __pgd(x) ((pgd_t) { (x) } )
+#define __pgprot(x)((pgprot_t) { (x) } )
+
+#else /* !STRICT_MM_TYPECHECKS */
+
+typedef pteval_t pte_t;
+typedef pmdval_t pmd_t;
+typedef pudval_t pud_t;
+typedef pgdval_t pgd_t;
+typedef pteval_t pgprot_t;
+
+#define pte_val(x) (x)
+#define pmd_val(x) (x)
+#define pud_val(x) (x)
+#define pgd_val(x) (x)
+#define pgprot_val(x) (x)
+
+#define __pte(x) (x)
+#define __pmd(x) (x)
+#define __pud(x) (x)
+#define __pgd(x) (x)
+#define __pgprot(x)(x)
+
+#endif /* STRICT_MM_TYPECHECKS */
+
+#endif /* __ASM_PGTABLE_4LEVEL_TYPES_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
[PATCH v4 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2
This patch adds 4 levels of translation tables implementation for both
HYP and stage2.
Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:
1) 4KB + 3 levels guest on 4KB + 3 levels host
2) 4KB + 4 levels guest on 4KB + 3 levels host
3) 64KB + 2 levels guest on 4KB + 3 levels host
4) 4KB + 3 levels guest on 4KB + 4 levels host
5) 4KB + 4 levels guest on 4KB + 4 levels host
6) 64KB + 2 levels guest on 4KB + 4 levels host
7) 4KB + 3 levels guest on 64KB + 2 levels host
8) 4KB + 4 levels guest on 64KB + 2 levels host
9) 64KB + 2 levels guest on 64KB + 2 levels host
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm/include/asm/kvm_mmu.h | 10 +
arch/arm/kvm/mmu.c | 88 +-
arch/arm64/include/asm/kvm_arm.h | 34 ---
arch/arm64/include/asm/kvm_mmu.h | 12 ++
4 files changed, 127 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..31eaaa6 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
*/
#define TRAMPOLINE_VA UL(CONFIG_VECTORS_BASE)
+/*
+ * MMU_CACHE_MIN_PAGES is the number of stage2 page table translation levels.
+ */
+#define MMU_CACHE_MIN_PAGES2
+
#ifndef __ASSEMBLY__
#include asm/cacheflush.h
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
}
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+ clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
static inline void kvm_clean_pmd_entry(pmd_t *pmd)
{
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 80bb1e6..3ffbdfb 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned
long start,
return 0;
}
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+ unsigned long end, unsigned long pfn,
+ pgprot_t prot)
+{
+ pud_t *pud;
+ pmd_t *pmd;
+ unsigned long addr, next;
+
+ addr = start;
+ do {
+ pud = pud_offset(pgd, addr);
+
+ if (pud_none_or_clear_bad(pud)) {
+ pmd = pmd_alloc_one(NULL, addr);
+ if (!pmd) {
+ kvm_err(Cannot allocate Hyp pmd\n);
+ return -ENOMEM;
+ }
+ pud_populate(NULL, pud, pmd);
+ get_page(virt_to_page(pud));
+ kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+ }
+
+ next = pud_addr_end(addr, end);
+
+ create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+ pfn += (next - addr) PAGE_SHIFT;
+ } while (addr = next, addr != end);
+
+ return 0;
+}
+
static int __create_hyp_mappings(pgd_t *pgdp,
unsigned long start, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
pgd_t *pgd;
pud_t *pud;
- pmd_t *pmd;
unsigned long addr, next;
int err = 0;
@@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
- pud = pud_offset(pgd, addr);
- if (pud_none_or_clear_bad(pud)) {
- pmd = pmd_alloc_one(NULL, addr);
- if (!pmd) {
- kvm_err(Cannot allocate Hyp pmd\n);
+ if (pgd_none(*pgd)) {
+ pud = pud_alloc_one(NULL, addr);
+ if (!pud) {
+ kvm_err(Cannot allocate Hyp pud\n);
err = -ENOMEM;
goto out;
}
- pud_populate(NULL, pud, pmd);
- get_page(virt_to_page(pud));
- kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+ pgd_populate(NULL, pgd, pud);
+ get_page(virt_to_page(pgd));
+ kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
}
next = pgd_addr_end(addr, end);
- err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+
+ err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
+
if (err)
goto out;
pfn += (next - addr) PAGE_SHIFT;
@@ -563,6 +595,24 @@ void
[PATCH v4 1/7] arm64: Use pr_* instead of printk
This patch fixed the following checkpatch complaint as using pr_*
instead of printk.
WARNING: printk() should include KERN_ facility level
Cc: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/kernel/traps.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..0484e81 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
fs = get_fs();
set_fs(KERNEL_DS);
- printk(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
+ pr_emerg(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
for (first = bottom ~31; first top; first += 32) {
unsigned long p;
@@ -83,7 +83,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
sprintf(str + i * 9, );
}
}
- printk(%s%04lx:%s\n, lvl, first 0x, str);
+ pr_emerg(%s%04lx:%s\n, lvl, first 0x, str);
}
set_fs(fs);
@@ -124,7 +124,7 @@ static void dump_instr(const char *lvl, struct pt_regs
*regs)
break;
}
}
- printk(%sCode: %s\n, lvl, str);
+ pr_emerg(%sCode: %s\n, lvl, str);
set_fs(fs);
}
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
- printk(Call trace:\n);
+ pr_emerg(Call trace:\n);
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -328,17 +328,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int
reason, unsigned int esr)
void __pte_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pte %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pte %016lx.\n, file, line, val);
}
void __pmd_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pmd %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pmd %016lx.\n, file, line, val);
}
void __pgd_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pgd %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pgd %016lx.\n, file, line, val);
}
void __init trap_init(void)
--
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 v4 2/7] arm64: Decouple page size from level of translation tables
This patch separates page size from level of translation tables in
configuration. It facilitates introduction of different options,
such as 4KB + 4 levels, 16KB + 4 levels and 64KB + 3 levels, easily.
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig | 36 +++-
arch/arm64/include/asm/page.h |2 +-
arch/arm64/include/asm/pgalloc.h |4 ++--
arch/arm64/include/asm/pgtable-hwdef.h |2 +-
arch/arm64/include/asm/pgtable.h |8 +++
arch/arm64/include/asm/tlb.h |2 +-
6 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e759af5..c7f5d65 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,48 @@ endmenu
menu Kernel Features
+choice
+ prompt Page size
+ default ARM64_4K_PAGES
+ help
+ Allows page size.
+
+config ARM64_4K_PAGES
+ bool 4KB
+ help
+ This feature enables 4KB pages support.
+
config ARM64_64K_PAGES
- bool Enable 64KB pages support
+ bool 64KB
help
This feature enables 64KB pages support (4KB by default)
allowing only two levels of page tables and faster TLB
look-up. AArch32 emulation is not available when this feature
is enabled.
+endchoice
+
+choice
+ prompt Level of translation tables
+ default ARM64_3_LEVELS if ARM64_4K_PAGES
+ default ARM64_2_LEVELS if ARM64_64K_PAGES
+ help
+ Allows level of translation tables.
+
+config ARM64_2_LEVELS
+ bool 2 level
+ depends on ARM64_64K_PAGES
+ help
+ This feature enables 2 levels of translation tables.
+
+config ARM64_3_LEVELS
+ bool 3 level
+ depends on ARM64_4K_PAGES
+ help
+ This feature enables 3 levels of translation tables.
+
+endchoice
+
config CPU_BIG_ENDIAN
bool Build big-endian kernel
help
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
#ifndef __ASSEMBLY__
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-types.h
#else
#include asm/pgtable-3level-types.h
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
#define check_pgt_cache() do { } while (0)
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
}
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
extern pgd_t *pgd_alloc(struct mm_struct *mm);
extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index 5fc8a66..9cd86c6 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
#ifndef __ASM_PGTABLE_HWDEF_H
#define __ASM_PGTABLE_HWDEF_H
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-hwdef.h
#else
#include asm/pgtable-3level-hwdef.h
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 90c811f..a64ce5e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -47,7 +47,7 @@ extern void __pmd_error(const char *file, int line, unsigned
long val);
extern void __pgd_error(const char *file, int line, unsigned long val);
#define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
#define pmd_ERROR(pmd) __pmd_error(__FILE__, __LINE__, pmd_val(pmd))
#endif
#define pgd_ERROR(pgd) __pgd_error(__FILE__, __LINE__, pgd_val(pgd))
@@ -320,7 +320,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
*/
#define mk_pte(page,prot) pfn_pte(page_to_pfn(page),prot)
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
#define pud_none(pud) (!pud_val(pud))
#define pud_bad(pud) (!(pud_val(pud) 2))
@@ -342,7 +342,7 @@ static inline pmd_t *pud_page_vaddr(pud_t pud)
return __va(pud_val(pud) PHYS_MASK (s32)PAGE_MASK);
}
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
/* to find an entry in a page-table-directory */
#define pgd_index(addr)(((addr) PGDIR_SHIFT)
(PTRS_PER_PGD - 1))
@@
