Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
phy comprises of CMU and TRSV blocks which are of I2C register Map.
So this patch also adds a i2c client driver, which is used configure
the CMU and TRSV block of exynos5250 SATA PHY.
Why not make the Exynos5250 sata phy as a i2c client driver instead?
This patch incorporates the generic phy framework to deal with sata
phy.
This patch depends on the below patch
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Signed-off-by: Girish K S ks.g...@samsung.com
Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
drivers/phy/Kconfig |6 +
drivers/phy/Makefile |1 +
drivers/phy/exynos/Kconfig |5 +
drivers/phy/exynos/Makefile |5 +
drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
drivers/phy/exynos/sata_phy_exynos5250.c | 248
++
drivers/phy/exynos/sata_phy_exynos5250.h | 33
7 files changed, 351 insertions(+)
create mode 100644 drivers/phy/exynos/Kconfig
create mode 100644 drivers/phy/exynos/Makefile
create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..ab3d1c6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework
and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
NAK. Just select GENERIC_PHY from your driver Kconfig.
+
+source drivers/phy/exynos/Kconfig
+
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..e0223d7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
simply have phy-exynos5250 in drivers/phy.
ok.
diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
new file mode 100644
index 000..fa125fb
--- /dev/null
+++ b/drivers/phy/exynos/Kconfig
@@ -0,0 +1,5 @@
+config PHY_SAMSUNG_SATA
+ tristate Samsung Sata SerDes/PHY driver
+ help
+ Support for Samsung sata SerDes/Phy found on Samsung
+ SoCs.
diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
new file mode 100644
index 000..50dc7eb
--- /dev/null
+++ b/drivers/phy/exynos/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the exynos phy drivers.
+#
+ccflags-y := -Idrivers/phy/exynos
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
exynos5250_phy_i2c.o
diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
b/drivers/phy/exynos/exynos5250_phy_i2c.c
new file mode 100644
index 000..9c75d3b
--- /dev/null
+++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Author:
+ * Yuvaraj C D yuvaraj...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/module.h
+#include sata_phy_exynos5250.h
+
+static int exynos_sata_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
+{
+ sataphy_attach_i2c_client(client);
+
+ dev_info(client-adapter-dev,
+ attached %s into i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static int exynos_sata_i2c_remove(struct i2c_client *client)
+{
+ dev_info(client-adapter-dev,
+ detached %s from i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static const struct i2c_device_id phy_i2c_device_match[] = {
+ { sata-phy-i2c, 0 },
+};
+MODULE_DEVICE_TABLE(of, phy_i2c_device_match);
+
+struct i2c_driver sataphy_i2c_driver = {
+ .probe= exynos_sata_i2c_probe,
+ .id_table = phy_i2c_device_match,
+ .remove = exynos_sata_i2c_remove,
+ .driver = {
+ .name = sata-phy-i2c,
+ .owner = THIS_MODULE,
+
Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Tue, Nov 19, 2013 at 3:22 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
phy comprises of CMU and TRSV blocks which are of I2C register Map.
So this patch also adds a i2c client driver, which is used configure
the CMU and TRSV block of exynos5250 SATA PHY.
Why not make the Exynos5250 sata phy as a i2c client driver instead?
This patch incorporates the generic phy framework to deal with sata
phy.
This patch depends on the below patch
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Signed-off-by: Girish K S ks.g...@samsung.com
Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
drivers/phy/Kconfig |6 +
drivers/phy/Makefile |1 +
drivers/phy/exynos/Kconfig |5 +
drivers/phy/exynos/Makefile |5 +
drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
drivers/phy/exynos/sata_phy_exynos5250.c | 248
++
drivers/phy/exynos/sata_phy_exynos5250.h | 33
7 files changed, 351 insertions(+)
create mode 100644 drivers/phy/exynos/Kconfig
create mode 100644 drivers/phy/exynos/Makefile
create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..ab3d1c6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework
and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
NAK. Just select GENERIC_PHY from your driver Kconfig.
+
+source drivers/phy/exynos/Kconfig
+
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..e0223d7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
simply have phy-exynos5250 in drivers/phy.
ok.
diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
new file mode 100644
index 000..fa125fb
--- /dev/null
+++ b/drivers/phy/exynos/Kconfig
@@ -0,0 +1,5 @@
+config PHY_SAMSUNG_SATA
+ tristate Samsung Sata SerDes/PHY driver
+ help
+ Support for Samsung sata SerDes/Phy found on Samsung
+ SoCs.
diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
new file mode 100644
index 000..50dc7eb
--- /dev/null
+++ b/drivers/phy/exynos/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the exynos phy drivers.
+#
+ccflags-y := -Idrivers/phy/exynos
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
exynos5250_phy_i2c.o
diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
b/drivers/phy/exynos/exynos5250_phy_i2c.c
new file mode 100644
index 000..9c75d3b
--- /dev/null
+++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Author:
+ * Yuvaraj C D yuvaraj...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/module.h
+#include sata_phy_exynos5250.h
+
+static int exynos_sata_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
+{
+ sataphy_attach_i2c_client(client);
+
+ dev_info(client-adapter-dev,
+ attached %s into i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static int exynos_sata_i2c_remove(struct i2c_client *client)
+{
+ dev_info(client-adapter-dev,
+ detached %s from i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static const struct i2c_device_id phy_i2c_device_match[] = {
+ { sata-phy-i2c, 0 },
+};
+MODULE_DEVICE_TABLE(of, phy_i2c_device_match);
+
+struct i2c_driver sataphy_i2c_driver = {
+ .probe= exynos_sata_i2c_probe,
+ .id_table = phy_i2c_device_match,
+ .remove = exynos_sata_i2c_remove,
+ .driver = {
Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Tuesday 19 November 2013 03:42 PM, Yuvaraj Kumar wrote:
On Tue, Nov 19, 2013 at 3:22 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
phy comprises of CMU and TRSV blocks which are of I2C register Map.
So this patch also adds a i2c client driver, which is used configure
the CMU and TRSV block of exynos5250 SATA PHY.
Why not make the Exynos5250 sata phy as a i2c client driver instead?
This patch incorporates the generic phy framework to deal with sata
phy.
This patch depends on the below patch
[1].drivers: phy: add generic PHY framework
by Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Signed-off-by: Girish K S ks.g...@samsung.com
Signed-off-by: Vasanth Ananthan vasant...@samsung.com
---
drivers/phy/Kconfig |6 +
drivers/phy/Makefile |1 +
drivers/phy/exynos/Kconfig |5 +
drivers/phy/exynos/Makefile |5 +
drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
drivers/phy/exynos/sata_phy_exynos5250.c | 248
++
drivers/phy/exynos/sata_phy_exynos5250.h | 33
7 files changed, 351 insertions(+)
create mode 100644 drivers/phy/exynos/Kconfig
create mode 100644 drivers/phy/exynos/Makefile
create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..ab3d1c6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework
and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
NAK. Just select GENERIC_PHY from your driver Kconfig.
+
+source drivers/phy/exynos/Kconfig
+
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..e0223d7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
simply have phy-exynos5250 in drivers/phy.
ok.
diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
new file mode 100644
index 000..fa125fb
--- /dev/null
+++ b/drivers/phy/exynos/Kconfig
@@ -0,0 +1,5 @@
+config PHY_SAMSUNG_SATA
+ tristate Samsung Sata SerDes/PHY driver
+ help
+ Support for Samsung sata SerDes/Phy found on Samsung
+ SoCs.
diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
new file mode 100644
index 000..50dc7eb
--- /dev/null
+++ b/drivers/phy/exynos/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the exynos phy drivers.
+#
+ccflags-y := -Idrivers/phy/exynos
+obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
exynos5250_phy_i2c.o
diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
b/drivers/phy/exynos/exynos5250_phy_i2c.c
new file mode 100644
index 000..9c75d3b
--- /dev/null
+++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Author:
+ * Yuvaraj C D yuvaraj...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published
by the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/module.h
+#include sata_phy_exynos5250.h
+
+static int exynos_sata_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
+{
+ sataphy_attach_i2c_client(client);
+
+ dev_info(client-adapter-dev,
+ attached %s into i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static int exynos_sata_i2c_remove(struct i2c_client *client)
+{
+ dev_info(client-adapter-dev,
+ detached %s from i2c adapter successfully\n,
+ client-name);
+
+ return 0;
+}
+
+static const struct i2c_device_id phy_i2c_device_match[] = {
+ { sata-phy-i2c, 0 },
+};
+MODULE_DEVICE_TABLE(of, phy_i2c_device_match);
+
+struct i2c_driver sataphy_i2c_driver = {
+ .probe= exynos_sata_i2c_probe,
+ .id_table = phy_i2c_device_match,
+
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Mon, Nov 18, 2013 at 07:04:50PM +, Christopher Covington wrote: On 11/18/2013 12:30 PM, Catalin Marinas wrote: [...] You can't run legacy AArch32 code at EL3 and have lower levels in AArch64 mode (architectural constraint). What prevents AArch32 code from running at EL3 and then requesting a reset to AArch64 by writing to the Reset Management Register before sliding down to lower exception levels? You can do this for some initial code but the firmware still needs to switch to AArch64 before dropping to lower exception levels. What this thread is about is run-time calls to firmware for booting secondary CPUs, idle, l2x0. At this point, the code at EL3 must run in AArch64 mode. There is no way you can bounce between AArch32 and AArch64 modes using reset just to handle some SMCs. -- 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
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Mon, Nov 18, 2013 at 05:52:36PM +, Stephen Warren wrote: On 11/18/2013 10:30 AM, Catalin Marinas wrote: On Mon, Nov 18, 2013 at 05:03:37PM +, Stephen Warren wrote: On 11/18/2013 04:58 AM, Catalin Marinas wrote: ... Of course, trusted foundations interface could be plugged into cpu_ops on arm64 but I will NAK it on the grounds of not using the PSCI API, nor the SMC calling convention (and it's easy to fix when porting to ARMv8). If a supported standard API is used, then there is no need for additional code in the kernel. What happens when someone takes an existing working secure-mode SW stack and simply re-uses it on some new ARMv8 SoC. Are you going to force people working on upstream to re-write the secure mode firmware in shipped hardware before allowing upstream kernel support? Don't confuse the secure stack with the secure monitor running at EL3. If you want AArch64 support for lower levels (EL2, EL1, EL0), your monitor _must_ be AArch64. You can't run legacy AArch32 code at EL3 and have lower levels in AArch64 mode (architectural constraint). I was assuming that vendors would take the existing source code and simply rebuild it to create the AArch64 secure world. Some C code can probably be reused but not the EL3 entry/exit code, world switching and AArch64 initialisation. The main differences in ARMv8 EL3 is that it has its own MMU and it can only be entered via SMC and exit via ERET (you can no longer switch from/to secure SVC by writing to CPSR). So apart from a different instruction set, the new exception model requires a rewrite of the secure monitor logic used to handle SMCs, switch worlds, pass arguments between worlds. As such, the same SMC IDs, same structures, etc. would be used. The only source difference would be to perhaps change some 32-bit registers/struct-fields up to 64-bit. Naively that sounds like the lowest-effort way to get an AArch64 secure world, so I'm purely guessing that that's what vendors will do. It looks simpler in theory until you hit the new exception model and realise the clear separation between EL3 (previously secure monitor) and secure EL1 (previously secure SVC). I'm not referring to the whole secure stack here, just the things I mentioned above. You can still keep the secure services at S-EL1 in AArch32, only that the SMCs are handled by EL3 (and that's another aspect the SMC calling convention spec is trying to address, mixed register-width secure/non-secure OSes). I'm not sure of the implications of that statement. Since you mention SMCs being handled by EL3, I think the quick-and-dirty conversion I mention above is still likely to be used. What I meant is that a secure OS (providing cryptography, banking etc. services) can run in secure EL1 in AArch32 mode, it does not need to be converted (though it helps from a performance perspective, new instructions). But the world switching (which is pretty tightly coupled with secure SVC on ARMv7) and SMC handling need to be rewritten. And it's usually EL3 where you would place power management firmware on ARMv8 (cache/TLB maintenance, power controller access). This is usually done by the SoC vendor and not the secure OS provider (the latter may do the final link). -- 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
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote:
On 11/18/2013 08:58 PM, Catalin Marinas wrote:
On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot acour...@nvidia.com wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support for simple, TrustZone-based firmwares but could
also cover other use-cases. It has been suggested that this
interface might be useful to other architectures (e.g. arm64) and
that it should be moved out of arch/arm.
NAK. I'm for code sharing with arm via common locations but this API
goes against the ARMv8 firmware standardisation efforts like PSCI,
encouraging each platform to define there own non-standard interface.
I have to say, I pretty much agree with your NAK.
The reason for this patch is that the suggestion to move firmware_ops
out of arch/arm is the last (I hope) thing that prevents my Trusted
Foundation support series from being merged.
Moving it into drivers shouldn't be a workaround. Nice try ;).
Hehe. I thought that just sending a patch would settle the issue one way
or the other and avoid a huge discussion. Woke up this morning to see
how wrong I was.
It's a sensitive topic ;).
BTW, is legacy code the reason for not converting the SMC # to PSCI?
It's already supported on ARMv7, so you may not have much code left to
merge in the kernel ;).
The problem here is twofold:
1) we are just consumers of the TrustZone secure monitor who receive a
binary and do not have any control over its calling conventions. I agree
that it would be trivial to make it compatible with PSCI, but it's just
not something we can make by ourselves (TF does not even follow the SMC
calling convention). If this problem is to be addressed, it should be
done by forcing the TrustZone secure monitors providers to follow PSCI.
I agree and such discussions do happen ('forcing' is a bit harder, more
like 'strongly recommending'). On my side, I voice this message via the
Linux channels, so SoC vendors can also encourage their secure provider
in this direction. The benefit is that the Linux changes are minimal
afterwards, single image is easier.
But as I replied to Stephen, make sure you separate the secure OS (EL1)
from the secure firmware (EL3). The latter (or parts of it) are provided
by the SoC vendor (e.g. NVidia) and may be eventually linked into a big
blob by the secure OS provider. ARM is encouraging separation here and a
multi-stage firmware loading approach (and ARM started a public generic
firmware project, it's in the early days now).
2) devices have already shipped with this firmware. Are we going to just
renounce supporting them, even though the necessary support is
lightweight and fits within already existing interfaces?
I'm talking only about ARMv8 here. Please see my reply to Stephen for
the details of (not) reusing existing firmware.
I certainly do hope that for ARMv8 things will be different and more
standardized. But that's not something that can be guaranteed unless ARM
strongly enforces it to firmware vendors. In case such a non-standard
firmware gets used again, I *do* hope that using cpu_ops will be
preferred over saying this device cannot be supported in mainline, ever.
cpu_ops or firmware_ops is just a name and can be unified (TBD what
common functionality it contains). What I don't want to encourage is
each SoC registering its own firmware interface.
The kernel already supports non-standard hardware, BIOS, ACPI through
hacks that are *way* more horrible than that. This should certainly not
be encouraged, but that's not a valid reason to forbid otherwise
perfectly fine devices to run mainline IMHO.
So you say we should just stop trying to standardise anything because
people don't care anyway. Why do we even bother with DT (or ACPI) since
board files were fine in the past (with a bit more code)?
* that should a need to move it (for whatever reason) occur later, it
will be easy to do (as this patch hopefully demonstrates).
I agree, it's not hard to unify this but so far I haven't seen a good
reason.
Same here. arm64 has its own cpu_operations. Other archs have different
needs and if we move this to a common place it will just become a messy
placeholder for function pointers from which each arch will only use a
subset.
That was my initial point but it turned into a thread against PSCI
(again ;)).
--
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 2/4 v10] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the reg property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
Changes since v9:
Just respinning
Changes since v8:
None
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index c493245..bbd0fc3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg-tmu_pmin !data-id)
- writel(0, data-base_common + reg-tmu_pmin);
+ writel(0, data-base_second + reg-tmu_pmin);
out:
clk_disable(data-clk);
mutex_unlock(data-lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg-tmu_irqstatus) {
- val_type = readl(data-base_common + reg-tmu_irqstatus);
+ val_type = readl(data-base_second + reg-tmu_irqstatus);
if (!((val_type data-id) 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev-dev.of_node, 1, res)) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data-base_common = devm_ioremap(pdev-dev, res.start,
+ data-base_second = devm_ioremap(pdev-dev, res.start,
resource_size(res));
- if (!data-base_common) {
+ if (!data-base_second) {
dev_err(pdev-dev, Failed to ioremap memory\n);
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
*
[PATCH 3/4 v10] thermal: samsung: Add TMU support for Exynos5420 SoCs
Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
Changes since v9:
Just respinning
Changes since v8:
1. rewrote the Documentation for device tree bindings
2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix)
3. introduces samsung,exynos5420-tmu-triminfo and
samsung,exynos5420-tmu-triminfo-clk to handle the TMU channels on
Exynos5420 more appropriately
.../devicetree/bindings/thermal/exynos-thermal.txt | 45 +
drivers/thermal/samsung/exynos_tmu.c | 58 ++-
drivers/thermal/samsung/exynos_tmu.h |2 +
drivers/thermal/samsung/exynos_tmu_data.c | 106
drivers/thermal/samsung/exynos_tmu_data.h |8 ++
5 files changed, 215 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..5055b31 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,11 @@
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
+ samsung,exynos5420-tmu for TMU channel 0, 1 on Exynos5420
+ samsung,exynos5420-tmu-triminfo for TMU channel 2 Exynos5420
+ (Must pass triminfo base)
+ samsung,exynos5420-tmu-triminfo-clk for TMU channel 3 and 4
+ Exynos5420 (Must pass triminfo base and triminfo clock)
samsung,exynos5440-tmu
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +18,18 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+ Use samsung,exynos5420-tmu-triminfo in cases, there is a misplaced
+ register but no need of another clock to access that base.
+ Use samsung,exynos5420-tmu-triminfo-clk in cases where there is a
misplaced
+ register and we need another clock to access that base.
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +60,34 @@ Example 2):
clock-names = tmu_apbif;
};
+Example 3): (In case of Exynos5420 with misplaced TRIMINFO register)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu-triminfo;
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu-triminfo-clk;
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif, tmu_triminfo_apbif;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu-triminfo-clk;
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif, tmu_triminfo_apbif;
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in aliases node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index bbd0fc3..826647c 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,6 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
+ * @clk_sec: pointer to the clock structure for accessing the
[PATCH 4/4 v4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
---
Changes since v3:
None, Just respinning
Changes since v2:
3. uses the new compatible strings introduced along with adding
support for Exynso5420.
Changes since v1:
1. Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
2. Correct the clock number for the TMU4
arch/arm/boot/dts/exynos5420.dtsi | 48 +
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6ffefd1..d736b40 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -369,4 +369,52 @@
clock-names = gscl;
samsung,power-domain = gsc_pd;
};
+
+ /* tmu for CPU0 */
+ tmu@1006 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x1006 0x100;
+ interrupts = 0 65 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU1 */
+ tmu@10064000 {
+ compatible = samsung,exynos5420-tmu;
+ reg = 0x10064000 0x100;
+ interrupts = 0 183 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = samsung,exynos5420-tmu-triminfo;
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = 0x10068000 0x100, 0x1006c000 0x4;
+ interrupts = 0 184 0;
+ clocks = clock 318;
+ clock-names = tmu_apbif;
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = samsung,exynos5420-tmu-triminfo-clk;
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = 0x1006c000 0x100, 0x100a 0x4;
+ interrupts = 0 185 0;
+ clocks = clock 318, clock 319;
+ clock-names = tmu_apbif, tmu_apbif_triminfo;
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = samsung,exynos5420-tmu-triminfo-clk;
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = 0x100a 0x100, 0x10068000 0x4;
+ interrupts = 0 215 0;
+ clocks = clock 319, clock 318;
+ clock-names = tmu_apbif, tmu_apbif_triminfo;
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] cpufreq: exynos: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(cpufreq_lock);
frequency_locked = false;
--
1.8.1.2
--
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 4/4] PM / devfreq: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/devfreq/exynos/exynos5_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index a60da3c..bd672de0 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(data-lock);
@@ -300,6 +301,7 @@ unlock:
if (err)
return NOTIFY_BAD;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
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: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote:
On 11/18/2013 08:58 PM, Catalin Marinas wrote:
On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
On 11/18/2013 12:59 AM, Catalin Marinas wrote:
On 17 November 2013 08:49, Alexandre Courbot acour...@nvidia.com wrote:
The ARM tree includes a firmware_ops interface that is designed to
implement support for simple, TrustZone-based firmwares but could
also cover other use-cases. It has been suggested that this
interface might be useful to other architectures (e.g. arm64) and
that it should be moved out of arch/arm.
NAK. I'm for code sharing with arm via common locations but this API
goes against the ARMv8 firmware standardisation efforts like PSCI,
encouraging each platform to define there own non-standard interface.
I have to say, I pretty much agree with your NAK.
The reason for this patch is that the suggestion to move firmware_ops
out of arch/arm is the last (I hope) thing that prevents my Trusted
Foundation support series from being merged.
Moving it into drivers shouldn't be a workaround. Nice try ;).
Hehe. I thought that just sending a patch would settle the issue one way
or the other and avoid a huge discussion. Woke up this morning to see
how wrong I was.
It's a sensitive topic ;).
BTW, is legacy code the reason for not converting the SMC # to PSCI?
It's already supported on ARMv7, so you may not have much code left to
merge in the kernel ;).
The problem here is twofold:
1) we are just consumers of the TrustZone secure monitor who receive a
binary and do not have any control over its calling conventions. I agree
that it would be trivial to make it compatible with PSCI, but it's just
not something we can make by ourselves (TF does not even follow the SMC
calling convention). If this problem is to be addressed, it should be
done by forcing the TrustZone secure monitors providers to follow PSCI.
I agree and such discussions do happen ('forcing' is a bit harder, more
like 'strongly recommending'). On my side, I voice this message via the
Linux channels, so SoC vendors can also encourage their secure provider
in this direction. The benefit is that the Linux changes are minimal
afterwards, single image is easier.
But as I replied to Stephen, make sure you separate the secure OS (EL1)
from the secure firmware (EL3). The latter (or parts of it) are provided
by the SoC vendor (e.g. NVidia) and may be eventually linked into a big
blob by the secure OS provider. ARM is encouraging separation here and a
multi-stage firmware loading approach (and ARM started a public generic
firmware project, it's in the early days now).
Will keep that in mind and check whether that could apply to future
devices, thanks.
2) devices have already shipped with this firmware. Are we going to just
renounce supporting them, even though the necessary support is
lightweight and fits within already existing interfaces?
I'm talking only about ARMv8 here. Please see my reply to Stephen for
the details of (not) reusing existing firmware.
I certainly do hope that for ARMv8 things will be different and more
standardized. But that's not something that can be guaranteed unless ARM
strongly enforces it to firmware vendors. In case such a non-standard
firmware gets used again, I *do* hope that using cpu_ops will be
preferred over saying this device cannot be supported in mainline, ever.
cpu_ops or firmware_ops is just a name and can be unified (TBD what
common functionality it contains). What I don't want to encourage is
each SoC registering its own firmware interface.
Sorry, are you talking about interface as in SMC interface, or as in
cpu_operations/firmware_ops?
The kernel already supports non-standard hardware, BIOS, ACPI through
hacks that are *way* more horrible than that. This should certainly not
be encouraged, but that's not a valid reason to forbid otherwise
perfectly fine devices to run mainline IMHO.
So you say we should just stop trying to standardise anything because
people don't care anyway. Why do we even bother with DT (or ACPI) since
board files were fine in the past (with a bit more code)?
Oh no, that's not what I am saying at all. Standardization is good.
PSCI is good. Of course I would prefer that the secure monitor we use
follow established conventions - that'd be less work to support it and
less hassle to get my patches merged.
I may have misunderstood you, but I felt your mail sounded a bit like
we won't merge support for firmwares that do not follow PSCI. I
agree that whenever it is possible to support a firmware through a
standard interface, this should be done - no discussion. But right now
I have two devices that are good representatives of Tegra 4 and
available in stores, which I would like to see supported in mainline
to satisfy requests from the community for
Re: [PATCH 2/4] cpufreq: exynos: Consider hibernation in pm notifier
On 19 November 2013 18:59, Jonghwan Choi jhbird.c...@gmail.com wrote:
Frequency lock should be considered in suspend/hibernation.
These could turn out to be important logs for future. Please write
with more effort..
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct
notifier_block *notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct
notifier_block *notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(cpufreq_lock);
frequency_locked = false;
@Rafael: So we have few more drivers which are already doing such
stuff (even tegra as well)..
--
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 4/4] PM / devfreq: Consider hibernation in pm notifier
Hi,
Are you planning to add hibernation support to ARM?
If so then this should be stated somewhere in the patch description.
OTOH if you are not going to add hibernation support to ARM I see
a little sense in adding hibernation support to ARM-only drivers..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Tuesday, November 19, 2013 10:30:31 PM Jonghwan Choi wrote:
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/devfreq/exynos/exynos5_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index a60da3c..bd672de0 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(data-lock);
@@ -300,6 +301,7 @@ unlock:
if (err)
return NOTIFY_BAD;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
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: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 02:29:39PM +, Alexandre Courbot wrote: On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote: 2) devices have already shipped with this firmware. Are we going to just renounce supporting them, even though the necessary support is lightweight and fits within already existing interfaces? I'm talking only about ARMv8 here. Please see my reply to Stephen for the details of (not) reusing existing firmware. I certainly do hope that for ARMv8 things will be different and more standardized. But that's not something that can be guaranteed unless ARM strongly enforces it to firmware vendors. In case such a non-standard firmware gets used again, I *do* hope that using cpu_ops will be preferred over saying this device cannot be supported in mainline, ever. cpu_ops or firmware_ops is just a name and can be unified (TBD what common functionality it contains). What I don't want to encourage is each SoC registering its own firmware interface. Sorry, are you talking about interface as in SMC interface, or as in cpu_operations/firmware_ops? Both. I don't want to see platforms defining their own SMC interface for no good reason. The cpu_ops/firmware_ops handling in the kernel is just some naming but the key is having standard SMC interfaces for CPU operations. The kernel already supports non-standard hardware, BIOS, ACPI through hacks that are *way* more horrible than that. This should certainly not be encouraged, but that's not a valid reason to forbid otherwise perfectly fine devices to run mainline IMHO. So you say we should just stop trying to standardise anything because people don't care anyway. Why do we even bother with DT (or ACPI) since board files were fine in the past (with a bit more code)? Oh no, that's not what I am saying at all. Standardization is good. PSCI is good. Of course I would prefer that the secure monitor we use follow established conventions - that'd be less work to support it and less hassle to get my patches merged. I may have misunderstood you, but I felt your mail sounded a bit like we won't merge support for firmwares that do not follow PSCI. Just to clarify it: I won't merge support for _ARMv8_ firmware that does not follow a standard CPU booting/power protocol supported by Linux. Currently we only support PSCI. If there is a need for another protocol and a good proposal, I'm open for discussions. The above is all related to having no SoC code under arch/arm64 (or board files, whatever you want to call them). I agree that whenever it is possible to support a firmware through a standard interface, this should be done - no discussion. But right now I have two devices that are good representatives of Tegra 4 and available in stores, which I would like to see supported in mainline to satisfy requests from the community for Tegra development platforms, and also initiate the habit to support future NVIDIA-branded devices in mainline. Their secure monitor unfortunately does not follow PSCI or the SMC convention and needs a custom firmware_ops. Are they unworthy of mainline? Are they ARMv8? Since we didn't have any such rules on ARMv7 and earlier, standard secure interface is nice to have but should not prevent upstreaming. I made this clear already that it is ARMv8 only, please don't try to generalise it. And if, by sheer misfortune, the same thing happened on an ARMv8 device (despite the EL1/EL3 separation), what would be the outcome? If some people get it wrong and they have to work around firmware bugs for devices already in the field, we may need to bend the rules (bugs do happen, both in software and hardware). But definitely _not_ when people don't even bother. IMHO, more devices in mainline is beneficial to everybody, and actually *encourages* SoC vendors/firmware providers to follow conventions. Banning devices is what triggers the kind of screw it reactions mentioned earlier, By following some rules and doing things in a standard way (firmware interface in this case), it is more likely that their SoC support requires minimal kernel code and it's easier to upstream and maintain. and on the contrary once a device is in, you tend to make sure the next ones follow the kernel trends because you know you will need to support them in mainline as well and it will make your life easier. Not really. The next device won't follow the kernel trends but just the same non-standard way of doing things that were accepted in the first place. -- 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
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Wed, Nov 20, 2013 at 12:07 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Nov 19, 2013 at 02:29:39PM +, Alexandre Courbot wrote: On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote: 2) devices have already shipped with this firmware. Are we going to just renounce supporting them, even though the necessary support is lightweight and fits within already existing interfaces? I'm talking only about ARMv8 here. Please see my reply to Stephen for the details of (not) reusing existing firmware. I certainly do hope that for ARMv8 things will be different and more standardized. But that's not something that can be guaranteed unless ARM strongly enforces it to firmware vendors. In case such a non-standard firmware gets used again, I *do* hope that using cpu_ops will be preferred over saying this device cannot be supported in mainline, ever. cpu_ops or firmware_ops is just a name and can be unified (TBD what common functionality it contains). What I don't want to encourage is each SoC registering its own firmware interface. Sorry, are you talking about interface as in SMC interface, or as in cpu_operations/firmware_ops? Both. I don't want to see platforms defining their own SMC interface for no good reason. The cpu_ops/firmware_ops handling in the kernel is just some naming but the key is having standard SMC interfaces for CPU operations. Fair enough. The kernel already supports non-standard hardware, BIOS, ACPI through hacks that are *way* more horrible than that. This should certainly not be encouraged, but that's not a valid reason to forbid otherwise perfectly fine devices to run mainline IMHO. So you say we should just stop trying to standardise anything because people don't care anyway. Why do we even bother with DT (or ACPI) since board files were fine in the past (with a bit more code)? Oh no, that's not what I am saying at all. Standardization is good. PSCI is good. Of course I would prefer that the secure monitor we use follow established conventions - that'd be less work to support it and less hassle to get my patches merged. I may have misunderstood you, but I felt your mail sounded a bit like we won't merge support for firmwares that do not follow PSCI. Just to clarify it: I won't merge support for _ARMv8_ firmware that does not follow a standard CPU booting/power protocol supported by Linux. Currently we only support PSCI. If there is a need for another protocol and a good proposal, I'm open for discussions. The above is all related to having no SoC code under arch/arm64 (or board files, whatever you want to call them). I agree that whenever it is possible to support a firmware through a standard interface, this should be done - no discussion. But right now I have two devices that are good representatives of Tegra 4 and available in stores, which I would like to see supported in mainline to satisfy requests from the community for Tegra development platforms, and also initiate the habit to support future NVIDIA-branded devices in mainline. Their secure monitor unfortunately does not follow PSCI or the SMC convention and needs a custom firmware_ops. Are they unworthy of mainline? Are they ARMv8? Since we didn't have any such rules on ARMv7 and earlier, standard secure interface is nice to have but should not prevent upstreaming. I made this clear already that it is ARMv8 only, please don't try to generalise it. Sorry, that was not my intention at all - I just misunderstood what you meant. Thanks for clarifying it. And if, by sheer misfortune, the same thing happened on an ARMv8 device (despite the EL1/EL3 separation), what would be the outcome? If some people get it wrong and they have to work around firmware bugs for devices already in the field, we may need to bend the rules (bugs do happen, both in software and hardware). But definitely _not_ when people don't even bother. Ok, I guess for ARMv8 there is absolutely no excuse not to follow PSCI anyways. We'll need to be careful about this one. IMHO, more devices in mainline is beneficial to everybody, and actually *encourages* SoC vendors/firmware providers to follow conventions. Banning devices is what triggers the kind of screw it reactions mentioned earlier, By following some rules and doing things in a standard way (firmware interface in this case), it is more likely that their SoC support requires minimal kernel code and it's easier to upstream and maintain. and on the contrary once a device is in, you tend to make sure the next ones follow the kernel trends because you know you will need to support them in mainline as well and it will make your life easier. Not really. The next device won't follow the kernel trends but just the same non-standard way of doing things that were accepted in the first place. I guess that
[PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
One of remaining limitations of current pinctrl-samsung driver was
the inability to parse multiple pinmux/pinconf group nodes grouped
inside a single device tree node. It made defining groups of pins for
single purpose, but with different parameters very inconvenient.
This patch implements Tegra-like support for grouping multiple pinctrl
groups inside one device tree node, by completely changing the way
pin groups and functions are parsed from device tree. The code creating
pinctrl maps from DT nodes has been borrowed from pinctrl-tegra, while
the initial creation of groups and functions has been completely
rewritten with following assumptions:
- each group consists of just one pin and does not depend on data
from device tree,
- each function is represented by a device tree child node of the
pin controller, which in turn can contain multiple child nodes
for pins that need to have different configuration values.
Device Tree bindings are fully backwards compatible. New functionality
can be used by defining a new pinctrl group consisting of several child
nodes, as on following example:
sd4_bus8: sd4-bus-width8 {
part-1 {
samsung,pins = gpk0-3, gpk0-4,
gpk0-5, gpk0-6;
samsung,pin-function = 3;
samsung,pin-pud = 3;
samsung,pin-drv = 3;
};
part-2 {
samsung,pins = gpk1-3, gpk1-4,
gpk1-5, gpk1-6;
samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
};
Tested on Exynos4210-Trats board and a custom Exynos4212-based one.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/pinctrl/samsung-pinctrl.txt | 23 +-
drivers/pinctrl/pinctrl-samsung.c | 619 -
drivers/pinctrl/pinctrl-samsung.h | 1 +
3 files changed, 392 insertions(+), 251 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 257677d..fe34cbb 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -43,7 +43,11 @@ Required Properties:
- Pin mux/config groups as child nodes: The pin mux (selecting pin function
mode) and pin config (pull up/down, driver strength) settings are represented
as child nodes of the pin-controller node. There should be atleast one
- child node and there is no limit on the count of these child nodes.
+ child node and there is no limit on the count of these child nodes. It is
+ also possible for a child node to consist of several further child nodes
+ to allow grouping multiple pinctrl groups into one. The format of second
+ level child nodes is exactly the same as for first level ones and is
+ described below.
The child node should contain a list of pin(s) on which a particular pin
function selection or pin configuration (or both) have to applied. This
@@ -248,6 +252,23 @@ Example 1: A pin-controller node with pin groups.
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
+
+ sd4_bus8: sd4-bus-width8 {
+ part-1 {
+ samsung,pins = gpk0-3, gpk0-4,
+ gpk0-5, gpk0-6;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 3;
+ };
+ part-2 {
+ samsung,pins = gpk1-3, gpk1-4,
+ gpk1-5, gpk1-6;
+ samsung,pin-function = 4;
+ samsung,pin-pud = 4;
+ samsung,pin-drv = 3;
+ };
+ };
};
Example 2: A pin-controller node with external wakeup interrupt controller
node.
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 47ec2e8..c752de4 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -40,9 +40,9 @@
/* list of all possible config options supported */
static struct pin_config {
- char*prop_cfg;
- unsigned intcfg_type;
-} pcfgs[] = {
+ const char *property;
+ enum pincfg_type param;
+} cfg_params[] = {
{ samsung,pin-pud, PINCFG_TYPE_PUD },
{ samsung,pin-drv, PINCFG_TYPE_DRV },
{ samsung,pin-con-pdn, PINCFG_TYPE_CON_PDN },
@@ -59,163 +59,242 @@ static inline struct
[PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-samsung.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index fe34cbb..ed4cc9c 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -74,6 +74,7 @@ Required Properties:
samsung,pins property of the child node. The following pin configuration
properties are supported.
+ - samsung,pin-val: Initial value of pin output buffer.
- samsung,pin-pud: Pull up/down configuration.
- samsung,pin-drv: Drive strength configuration.
- samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index c752de4..6b2194a 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -47,6 +47,7 @@ static struct pin_config {
{ samsung,pin-drv, PINCFG_TYPE_DRV },
{ samsung,pin-con-pdn, PINCFG_TYPE_CON_PDN },
{ samsung,pin-pud-pdn, PINCFG_TYPE_PUD_PDN },
+ { samsung,pin-val, PINCFG_TYPE_DAT },
};
/* Global list of devices (struct samsung_pinctrl_drv_data) */
--
1.8.4.2
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. Does that sound like the same scenario you're trying to solve Tomasz? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On 11/19/2013 10:10 AM, Tomasz Figa wrote:
One of remaining limitations of current pinctrl-samsung driver was
the inability to parse multiple pinmux/pinconf group nodes grouped
inside a single device tree node. It made defining groups of pins for
single purpose, but with different parameters very inconvenient.
This patch implements Tegra-like support for grouping multiple pinctrl
groups inside one device tree node, by completely changing the way
pin groups and functions are parsed from device tree.
The code creating
pinctrl maps from DT nodes has been borrowed from pinctrl-tegra,
A lot of the Tegra code has been slightly generalized and put into
pinconf-generic.c. Can the Samsung driver be converted to use that core
code rather than adding another copy of it? Perhaps this isn't possible
given the backwards-compatibility requirements that allow either 1- or
2-level nodes though, although I imagine that could be added to the core
code. One thing you'd certainly need to do is enhance the code in
pinconf-generic.c so that you could substitute your own
pinconf_generic_parse_dt_config() function or dt_params[] table, to
allow for the SoC-specific property names, but I doubt that's too hard.
Tegra could be converted then too:-)
while
the initial creation of groups and functions has been completely
rewritten with following assumptions:
- each group consists of just one pin and does not depend on data
from device tree,
- each function is represented by a device tree child node of the
pin controller, which in turn can contain multiple child nodes
for pins that need to have different configuration values.
OK, I think that sounds reasonable.
Device Tree bindings are fully backwards compatible. New functionality
can be used by defining a new pinctrl group consisting of several child
nodes, as on following example:
sd4_bus8: sd4-bus-width8 {
part-1 {
samsung,pins = gpk0-3, gpk0-4,
gpk0-5, gpk0-6;
samsung,pin-function = 3;
samsung,pin-pud = 3;
samsung,pin-drv = 3;
};
part-2 {
samsung,pins = gpk1-3, gpk1-4,
gpk1-5, gpk1-6;
samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
};
OK, that all looks great!
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
The DT changes fully, and the code a little briefly,
Reviewed-by: Stephen Warren swar...@nvidia.com
Just a minor comment below,
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
+static int samsung_pinctrl_create_function(struct device *dev,
+ struct samsung_pinctrl_drv_data *drvdata,
+ struct device_node *func_np,
+ struct samsung_pmx_func *func)
...
+ for (i = 0; i npins; ++i) {
+ const char *gname;
+ char *gname_copy;
+
+ ret = of_property_read_string_index(func_np, samsung,pins,
+ i, gname);
+ if (ret) {
+ dev_err(dev,
+ failed to read pin name %d from %s node\n,
+ i, func_np-name);
+ return ret;
}
+
+ gname_copy = devm_kzalloc(dev, strlen(gname) + 1, GFP_KERNEL);
+ if (!gname_copy)
+ return -ENOMEM;
+ strcpy(gname_copy, gname);
Is the lifetime of the string returned by
of_property_read_string_index() really so short that you must copy the
string? I'd be tempted just to store the pointer, although perhaps you
need to get() the node so that's safe.
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 11:59 AM, Doug Anderson wrote: On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of the SoC's GPIO driver communicate with the pinctrl driver (which might be the same driver; not sure here) so that gpio_direction_output() causes the pinctrl HW to be programmed as output only after the GPIO HW is programmed as output and with the correct output value. In this scenario, the pinctrl default state wouldn't touch the pin's input/output setting; that operation would be deferred until the driver set up the GPIO as an output. -- 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 4/4] PM / devfreq: Consider hibernation in pm notifier
Quoting Bartlomiej Zolnierkiewicz (2013-11-19 06:50:05) Hi, Are you planning to add hibernation support to ARM? If so then this should be stated somewhere in the patch description. OTOH if you are not going to add hibernation support to ARM I see a little sense in adding hibernation support to ARM-only drivers.. FYI, we at Linaro and a few others have been working on adding hibernation support for ARM. I have not coordinated with Jonghwan however. Apoligies for the earlier toppost. Thanks, Sebastian Capella -- 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] Exynos 5410 Dual cluster support
Hi, On Thursday 07 of November 2013 12:12:45 Vyacheslav Tyrtov wrote: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12. Has been tested on Exynos 5410 reference board (exynos_defconfig). I've applied the patches on top of today's linux-next and tried to boot my ODROID-XU using exynos5410-smdk5410.dts and exynos_defconfig, but all I can get is an imprecise external abort, when the kernel tries to jump to init. Full boot log below. Any ideas? Best regards, Tomasz 8 U-Boot 2012.07-g2bcb371 (Nov 19 2013 - 20:17:37) for Exynos5410 CPU: Exynos5410 Rev2.3 [Samsung SOC on SMP Platform Base on ARM CortexA15] APLL = 900MHz, KPLL = 600MHz MPLL = 532MHz, BPLL = 800MHz DRAM: 2 GiB WARNING: Caches not enabled TrustZone Enabled BSP BL1 version: PMIC VER : 0, CHIP REV : 6 VDD MIF : 1.0V VDD ARM : 1.0V VDD INT : 1.0V VDD G3D : 1.0V VDD KFC : 1.0V Checking Boot Mode ... SDMMC MMC: S5P_MSHC2: 0, S5P_MSHC0: 1 MMC Device 0: 14.8 GiB MMC Device 1: [ERROR] response error : 0006 cmd 8 [ERROR] response error : 0006 cmd 55 [ERROR] response error : 0006 cmd 2 In:serial Out: serial Err: serial Net: No ethernet found. Press 'Enter' or 'Space' to stop autoboot: 0 ODROID-XU # ODROID-XU # ODROID-XU # pri baudrate=115200 bootargs=console=ttySAC2,115200n8 earlyprintk ignore_loglevel mem=1G root=/dev/mmcblk0p1 rootwait bootcmd=run netboot bootdelay=1 bootfile=uImage.xu bootscript=source 40008000 copy_uboot_emmc2sd=emmc open 0;movi r z f 0 4000;emmc close 0;movi w f 1 4000;emmc open 0;movi r z b 0 4000;emmc close 0;movi w b 1 4000;emmc open 0;movi r z u 0 4000;emmc close 0;movi w u 1 4000;emmc open 0;movi r z t 0 4000;emmc close 0;movi w t 1 4000;mmc write 1 0x40008000 0x4CF 0x20; copy_uboot_sd2emmc=movi r f 0 4000;emmc open 1;movi w z f 1 4000;emmc close 1;movi r b 0 4000;emmc open 1;movi w z b 1 4000;emmc close 1;movi r u 0 4000;emmc open 1;movi w z u 1 4000;emmc close 1;movi r t 0 4000;emmc open 1;movi w z t 1 4000;emmc close 1;mmc write 1 0x40008000 0x4CF 0x20; default_bootcmd=echo Run Default Bootcmd ;movi read kernel 0 40008000;bootz 40008000 ethact=sms0 ipaddr=192.168.1.20 loadbootscript_1=echo Load Boot Script from mmc 0:1 ;fatload mmc 0:1 40008000 boot.scr loadbootscript_2=echo Load Boot Script from mmc 0:2 ;fatload mmc 0:2 40008000 boot.scr loadbootscript_3=echo Load Boot Script from mmc 1:1 ;fatload mmc 1:1 40008000 boot.scr loadbootscript_4=echo Load Boot Script from mmc 1:2 ;fatload mmc 1:2 40008000 boot.scr netboot=usb start tftpboot 40008000 bootm 40008000 rootfslen=10 serverip=192.168.1.2 stderr=serial stdin=serial stdout=serial usbethaddr=00:11:22:33:44:55 Environment size: 1546/16380 bytes ODROID-XU # run netboot (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.20 Filename 'uImage.xu'. Load address: 0x40008000 Loading: # # # # done Bytes transferred = 2980232 (2d7988 hex) ## Booting kernel from Legacy Image at 40008000 ... Image Name: Linux-exynos5410-odroidxu Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2980168 Bytes = 2.8 MiB Load Address: 50008000 Entry Point: 50008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.0-next-20131119-4-g27f3f5f-dirty (tom3q@flatron) (gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) ) #11 SMP PREEMPT Wed Nov 20 00:08:02 CET 2013 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Hardkernel ODROID-XU board based on EXYNOS5410 [0.00] bootconsole [earlycon0] enabled [0.00] debug: ignoring loglevel setting. [0.00] Memory policy: Data cache writealloc [0.00] CPU EXYNOS5410 (id
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 11:59 AM, Doug Anderson wrote: On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Thank you, Kyungmin Park the SoC's GPIO driver communicate with the pinctrl driver (which might be the same driver; not sure here) so that gpio_direction_output() causes the pinctrl HW to be programmed as output only after the GPIO HW is programmed as output and with the correct output value. In this scenario, the pinctrl default state wouldn't touch the pin's input/output setting; that operation would be deferred until the driver set up the GPIO as an output. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 05:02 PM, Kyungmin Park wrote: On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 11:59 AM, Doug Anderson wrote: On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Hmm. Shouldn't board firmware configure that kind of thing? (Of course, some firmware is starting to use DT to configure itself, so that just shifts the DT discussion, but anyway). -- 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
