Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
Right, it does provide the ability to have syscon before devices
are registered, I missed that part.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when someone
calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
and then return a reference to that new syscon. When another driver
looks up the same device node, we just pass a reference to the existing
syscon.
Doesn't sound too unreasonable. So how about instead of exporting
these new of_syscon_{un,}register() calls, we make them static and
call them from syscon_regmap_lookup_by_{phandle,compatible}?
--
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] mfd: syscon: Decouple syscon interface from syscon devices
On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
Right, it does provide the ability to have syscon before devices
are registered, I missed that part.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when someone
calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
and then return a reference to that new syscon. When another driver
looks up the same device node, we just pass a reference to the existing
syscon.
Doesn't sound too unreasonable. So how about instead of exporting
these new of_syscon_{un,}register() calls, we make them static and
call them from syscon_regmap_lookup_by_{phandle,compatible}?
Yes, that would be a good start. We should think about whether we want
to remove the existing DT probing at the same time, since it becomes
unused, and we might want to move the code to drivers/base/regmap_*.c
at some point.
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] mfd: syscon: Decouple syscon interface from syscon devices
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: Tuesday, September 02, 2014 1:45 PM
To: linux-arm-ker...@lists.infradead.org
Cc: Lee Jones; kgene@samsung.com; li...@arm.linux.org.uk;
naus...@samsung.com; Pankaj Dubey; Tomasz Figa;
linux-ker...@vger.kernel.org;
jo...@samsung.com; vikas.saj...@samsung.com; linux-samsung-
s...@vger.kernel.org; broo...@kernel.org; thomas...@samsung.com;
chow@samsung.com
Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon
devices
On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure
that lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a
syscon device to bind to this driver, which was fine for the first
use-cases of syscon as it wasn't required too early during boot.
However, now there are use-cases where systems require access to
syscon registers eariler in boot we require a means to obtain
access prior to device probing. I thought this patch not only
provides that possibilty, but also leaves in the ability to register
direct from
DT.
Right, it does provide the ability to have syscon before devices are
registered, I missed that part.
In contrast, this patch introduces a new
of_syscon_{un,}register() interface that would get removed after
the the above has been implemented, causing extra churn for any
driver that also wants to provide a regmap-like interface.
When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when
someone calls syscon_regmap_lookup_by_compatible or
syscon_regmap_lookup_by_phandle and then return a reference to that
new syscon. When another driver looks up the same device node, we
just pass a reference to the existing syscon.
Doesn't sound too unreasonable. So how about instead of exporting
these new of_syscon_{un,}register() calls, we make them static and
call them from syscon_regmap_lookup_by_{phandle,compatible}?
Yes, that would be a good start. We should think about whether we want to
remove
the existing DT probing at the same time, since it becomes unused, and we
might
want to move the code to drivers/base/regmap_*.c at some point.
OK, I am working on these two parts. Once code is in proper form and tested
on
our setup I will post here.
Thanks,
Pankaj
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] mfd: syscon: Decouple syscon interface from syscon devices
On Tue, 02 Sep 2014, Arnd Bergmann wrote:
On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
Right, it does provide the ability to have syscon before devices
are registered, I missed that part.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when someone
calls syscon_regmap_lookup_by_compatible or
syscon_regmap_lookup_by_phandle
and then return a reference to that new syscon. When another driver
looks up the same device node, we just pass a reference to the existing
syscon.
Doesn't sound too unreasonable. So how about instead of exporting
these new of_syscon_{un,}register() calls, we make them static and
call them from syscon_regmap_lookup_by_{phandle,compatible}?
Yes, that would be a good start. We should think about whether we want
to remove the existing DT probing at the same time, since it becomes
unused, and we might want to move the code to drivers/base/regmap_*.c
at some point
I'd support that move - and can even draft the patch if required.
--
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 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
+
exynos-dev = dev;
exynos-clk = clk;
clk_prepare_enable(exynos-clk);
+ if (!IS_ERR(exynos-sclk))
+ clk_prepare_enable(exynos-sclk);
If you replaced the returned err value with NULL you could avoid these
IS_ERR cases.
Right, point taken.
[snip]
--
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
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 11:39:08AM +0100, Vivek Gautam wrote:
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c
b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but
that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
Perhaps. I don't know what your future hardware will look like.
Is the usbdrd30_sclk input unique to Exynos7, or was it previously there
but just without an input?
If the latter you could just reduce this to:
dev_info(dev, no sclk specified);
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/4] phy: Add provision for calibrating phy.
Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-core.c | 36
include/linux/phy/phy.h |8
2 files changed, 44 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 834b337..c8cb3de 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -393,6 +393,42 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ * example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ * phy which needs calibration after the host controller reset
+ * has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ if (!phy)
+ return 0;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-calibrate) {
+ ret = phy-ops-calibrate(phy);
+ if (ret 0) {
+ dev_err(phy-dev,
+ phy calibration failed -- %d\n, ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
+/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index d983051..c70a311 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @calibrate: calibrate the phy post init
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -35,6 +36,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*calibrate)(struct phy *phy);
struct module *owner;
};
@@ -126,6 +128,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy-attrs.bus_width;
@@ -231,6 +234,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_calibrate(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK (0x3f 1) #define LINKSYSTEM_FLADJ(_x) ((_x) 1) #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) #define EXYNOS5_DRD_PHYUTMI0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE0x0c #define EXYNOS5_DRD_PHYCLKRST 0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 21) #define PHYCLKRST_SSC_RANGE(_x)((_x) 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2 BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 8) #define PHYCLKRST_FSEL(_x) ((_x) 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - #define PHYCLKRST_PORTRESETBIT(1) #define PHYCLKRST_COMMONONNBIT(0) #define EXYNOS5_DRD_PHYREG00x14 +#define PHYREG0_SSC_REF_CLK_SELBIT(21) +#define PHYREG0_SSC_RANGE BIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READBIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) 2) +#define PHYREG0_CR_CAP_DATABIT(1) +#define PHYREG0_CR_CAP_ADDRBIT(0) + #define EXYNOS5_DRD_PHYREG10x18 +#define PHYREG1_CR_DATA_OUT(_x)((_x) 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM0 0x1c - #define PHYPARAM0_REF_USE_PAD BIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 26) #define EXYNOS5_DRD_PHYPARAM1 0x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM0x24 #define EXYNOS5_DRD_PHYTEST0x28 - #define PHYTEST_POWERDOWN_SSP BIT(3) #define PHYTEST_POWERDOWN_HSP BIT(2) #define EXYNOS5_DRD_PHYADP 0x2c #define EXYNOS5_DRD_PHYUTMICLKSEL 0x30 - #define PHYUTMICLKSEL_UTMI_CLKSEL BIT(2) #define
[PATCH v6 3/4] usb: hcd: Calibrate PHY post hcd reset
Some quirky PHYs may require to be calibrated post the
hcd initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along
with Synopsys's DWC3 controller, is one such PHY which needs
to be calibrated post xhci's reset at initialization time and
at resume time, to get the controller work at SuperSpeed.
So facilitating the HCDs to calibrate the PHY.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/core/hcd.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index c4ed66c..6e01d09 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2202,6 +2202,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t
msg)
struct usb_hcd *hcd = container_of(rhdev-bus, struct usb_hcd, self);
int status;
int old_state = hcd-state;
+ int ret;
dev_dbg(rhdev-dev, usb %sresume\n,
(PMSG_IS_AUTO(msg) ? auto- : ));
@@ -2216,6 +2217,15 @@ int hcd_bus_resume(struct usb_device *rhdev,
pm_message_t msg)
hcd-state = HC_STATE_RESUMING;
status = hcd-driver-bus_resume(hcd);
+
+ /* calibrate the phy here */
+ ret = phy_calibrate(hcd-gen_phy);
+ if (ret 0 ret != -ENOTSUPP) {
+ dev_err(hcd-self.controller,
+ failed to calibrate USB PHY\n);
+ return ret;
+ }
+
clear_bit(HCD_FLAG_WAKEUP_PENDING, hcd-flags);
if (status == 0) {
struct usb_device *udev;
@@ -2738,6 +2748,14 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
hcd-rh_pollable = 1;
+ /* calibrate the phy here */
+ retval = phy_calibrate(hcd-gen_phy);
+ if (retval 0 retval != -ENOTSUPP) {
+ dev_err(hcd-self.controller,
+ failed to calibrate USB PHY\n);
+ return retval;
+ }
+
/* NOTE: root hub and controller capabilities may not be the same */
if (device_can_wakeup(hcd-self.controller)
device_can_wakeup(hcd-self.root_hub-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 v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/xhci-plat.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..6afd508 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -180,6 +181,19 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd-gen_phy = devm_phy_get(pdev-dev, usb2-phy);
+ if (IS_ERR(hcd-gen_phy)) {
+ ret = PTR_ERR(hcd-gen_phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ hcd-gen_phy = NULL;
+ dev_warn(pdev-dev,
+Error retrieving usb2 phy: %d\n, ret);
+ }
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
@@ -209,6 +223,19 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+ xhci-shared_hcd-gen_phy = devm_phy_get(pdev-dev, usb3-phy);
+ if (IS_ERR(xhci-shared_hcd-gen_phy)) {
+ ret = PTR_ERR(xhci-shared_hcd-gen_phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ xhci-shared_hcd-gen_phy = NULL;
+ dev_warn(pdev-dev,
+Error retrieving usb3 phy: %d\n, ret);
+ }
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
--
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 v6 0/4] Fine tune USB 3.0 PHY on exynos5420
This series is based on Heikki's patches for simpliefied phy lookup table: [PATCHv3 0/6] phy: simplified phy lookup [1], applied against 'usb-next' branch alongwith Sergei's patch for adding generic phy support to usb hcd [2]. NOTE: We need to get above dependencies merged first in order to merge this series. As of now patches @ [1] are posted with all the comments addressed and we are waiting for an ACK on them, but patch @ [2] needs to be re-spined as Sergie says in [3]: Yes, I'm planning this since Greg has lost v4. Changes since v5: - Assigned NULL to hcd-gen_phy in error path in xhci-plat.c, so that we don't need to check for IS_ERR() while calibrating the PHYs in core/hcd.c - Removed extra empty lines in register definitions in exynos5-usbdrd phy driver. - Added write access for EXYNOS5_DRD_PHYREG0 register before any crport_handshake() call as suggested by Jingoo Han. - Renamed member 'calibrate' to 'phy_exynos_calibrate' of struct exynos5_usbdrd_phy_drvdata. Changes since v4: - Rebased on latest patches by Heikki. - Took care of handling -EPROBE_DEFER error number while getting PHY in xhci plat. Changes from v3: - Modified error message as per review comments from Julius. Changes since v2: - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy, in order to make it more generic. - Moved the phy_calibration calls to core/hcd.c to enable a more generic solution for issues of calibrating the PHYs. Changes since v1: - Using 'gen_phy' member of 'hcd' instead of declaring more variables to hold phys. - Added a check for compatible match for 'Synopsys-dwc3' controller, since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that, instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs (main hcd and shared hcd). - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()' to use hcd-gen_phy directly. Also added the check for Synopsys's DWC3 controller while trying to calibrate the PHY. Explanation for the need of this patch-series: The DWC3-exynos eXtensible host controller present on Exynos5420/5800 SoCs is quirky. The PHY serving this controller operates at High-Speed by default, so it detects even Super-speed devices as high-speed ones. Certain PHY parameters like Tx LOS levels and Boost levels need to be calibrated further post initialization of xHCI controller, to get SuperSpeed operations working. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html [2] http://comments.gmane.org/gmane.linux.ports.sh.devel/35932 [3] http://www.spinics.net/lists/linux-usb/msg112300.html Vivek Gautam (4): phy: Add provision for calibrating phy. usb: host: xhci-plat: Get PHYs for xhci's hcds usb: hcd: Calibrate PHY post hcd reset phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 drivers/phy/phy-core.c | 36 drivers/phy/phy-exynos5-usbdrd.c | 185 ++ drivers/usb/core/hcd.c | 18 drivers/usb/host/xhci-plat.c | 27 ++ include/linux/phy/phy.h |8 ++ 5 files changed, 259 insertions(+), 15 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 17/17] drm/exynos/ipp: add file checks for ioctls
Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.
It also simplifies lookup for command node.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
v3:
- added file check from previous commit
- simplified c_node lookup
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 69 +++--
1 file changed, 22 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 9e9714a..4f36a9d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -318,44 +318,6 @@ static void ipp_print_property(struct
drm_exynos_ipp_property *property,
sz-hsize, sz-vsize, config-flip, config-degree);
}
-static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property)
-{
- struct exynos_drm_ippdrv *ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node;
- u32 prop_id = property-prop_id;
-
- DRM_DEBUG_KMS(prop_id[%d]\n, prop_id);
-
- ippdrv = ipp_find_drv_by_handle(prop_id);
- if (IS_ERR(ippdrv)) {
- DRM_ERROR(failed to get ipp driver.\n);
- return -EINVAL;
- }
-
- /*
-* Find command node using command list in ippdrv.
-* when we find this command no using prop_id.
-* return property information set in this command node.
-*/
- mutex_lock(ippdrv-cmd_lock);
- list_for_each_entry(c_node, ippdrv-cmd_list, list) {
- if ((c_node-property.prop_id == prop_id)
- (c_node-state == IPP_STATE_STOP)) {
- mutex_unlock(ippdrv-cmd_lock);
- DRM_DEBUG_KMS(found cmd[%d]ippdrv[0x%x]\n,
- property-cmd, (int)ippdrv);
-
- c_node-property = *property;
- return 0;
- }
- }
- mutex_unlock(ippdrv-cmd_lock);
-
- DRM_ERROR(failed to search property.\n);
-
- return -EINVAL;
-}
-
static struct drm_exynos_ipp_cmd_work *ipp_create_cmd_work(void)
{
struct drm_exynos_ipp_cmd_work *cmd_work;
@@ -391,6 +353,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
struct drm_exynos_ipp_property *property = data;
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
+ u32 prop_id;
int ret, i;
if (!ctx) {
@@ -403,6 +366,8 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
return -EINVAL;
}
+ prop_id = property-prop_id;
+
/*
* This is log print for user application property.
* user application set various property.
@@ -411,14 +376,24 @@ int exynos_drm_ipp_set_property(struct drm_device
*drm_dev, void *data,
ipp_print_property(property, i);
/*
-* set property ioctl generated new prop_id.
-* but in this case already asigned prop_id using old set property.
-* e.g PAUSE state. this case supports find current prop_id and use it
-* instead of allocation.
+* In case prop_id is not zero try to set existing property.
*/
- if (property-prop_id) {
- DRM_DEBUG_KMS(prop_id[%d]\n, property-prop_id);
- return ipp_find_and_set_property(property);
+ if (prop_id) {
+ c_node = ipp_find_obj(ctx-prop_idr, ctx-prop_lock, prop_id);
+
+ if (!c_node || c_node-filp != file) {
+ DRM_DEBUG_KMS(prop_id[%d] not found\n, prop_id);
+ return -EINVAL;
+ }
+
+ if (c_node-state != IPP_STATE_STOP) {
+ DRM_DEBUG_KMS(prop_id[%d] not stopped\n, prop_id);
+ return -EINVAL;
+ }
+
+ c_node-property = *property;
+
+ return 0;
}
/* find ipp driver using ipp id */
@@ -897,7 +872,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
/* find command node */
c_node = ipp_find_obj(ctx-prop_idr, ctx-prop_lock,
qbuf-prop_id);
- if (!c_node) {
+ if (!c_node || c_node-filp != file) {
DRM_ERROR(failed to get command node.\n);
return -ENODEV;
}
@@ -1032,7 +1007,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
void *data,
c_node = ipp_find_obj(ctx-prop_idr, ctx-prop_lock,
cmd_ctrl-prop_id);
- if (!c_node) {
+ if (!c_node || c_node-filp != file) {
DRM_ERROR(invalid command node list.\n);
return -ENODEV;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 11/19] irqchip: vic: Add support for FIQ management
This patch introduces callbacks to route interrupts to or away
from the FIQ signal. It also causes these callbacks to be registered
with the FIQ infrastructure.
This patch enable FIQ support for mach-versatile whilst mach-ep93xx,
mach-netx, mach-s3c64xx and plat-samsung are unmodified (and can therefore
continue to use init_FIQ() as before).
Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
Cc: Hartley Sweeten hswee...@visionengravers.com
Cc: Ryan Mallon rmal...@gmail.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: linux-samsung-soc@vger.kernel.org
---
arch/arm/mach-versatile/core.c | 2 +-
drivers/irqchip/irq-gic.c | 21 --
drivers/irqchip/irq-vic.c | 92 -
include/linux/irqchip/arm-gic.h | 3 ++
include/linux/irqchip/arm-vic.h | 6 ++-
5 files changed, 88 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 08fb8c8..bad1d30 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -108,7 +108,7 @@ void __init versatile_init_irq(void)
np = of_find_matching_node_by_address(NULL, vic_of_match,
VERSATILE_VIC_BASE);
- __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
+ __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np ? false : true, np);
writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index bda5a91..8821160 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data *gic,
/*
* Fully acknowledge (both ack and eoi) a FIQ-based IPI
*/
-static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs,
- void *data)
+void gic_handle_fiq_ipi(void)
{
struct gic_chip_data *gic = gic_data[0];
- void __iomem *cpu_base = gic_data_cpu_base(gic);
+ void __iomem *cpu_base;
unsigned long irqstat, irqnr;
+ if (!gic || !gic-fiq_enable)
+ return;
+
+ cpu_base = gic_data_cpu_base(gic);
+
if (WARN_ON(!in_nmi()))
return NOTIFY_BAD;
@@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb,
unsigned long regs,
return NOTIFY_OK;
}
-
-/*
- * Notifier to ensure IPI FIQ is acknowledged correctly.
- */
-static struct notifier_block gic_fiq_ipi_notifier = {
- .notifier_call = gic_handle_fiq_ipi,
-};
#else /* CONFIG_FIQ */
static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
int group) {}
@@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
#ifdef CONFIG_SMP
set_smp_cross_call(gic_raise_softirq);
register_cpu_notifier(gic_cpu_notifier);
-#ifdef CONFIG_FIQ
- if (gic_data_fiq_enable(gic))
- register_fiq_nmi_notifier(gic_fiq_ipi_notifier);
-#endif
#endif
set_handle_irq(gic_handle_irq);
}
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 7d35287..22aa126 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -36,6 +36,9 @@
#include asm/exception.h
#include asm/irq.h
+#ifdef CONFIG_FIQ
+#include asm/fiq.h
+#endif
#include irqchip.h
@@ -261,11 +264,53 @@ static struct irq_domain_ops vic_irqdomain_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+#ifdef CONFIG_FIQ
+static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+
+static void vic_set_fiq(struct irq_data *d, bool enable)
+{
+ void __iomem *base = irq_data_get_irq_chip_data(d);
+ unsigned int irq = d-hwirq;
+ u32 val;
+
+ raw_spin_lock(irq_controller_lock);
+ val = readl(base + VIC_INT_SELECT);
+ if (enable)
+ val |= 1 irq;
+ else
+ val = ~(1 irq);
+ writel(val, base + VIC_INT_SELECT);
+ raw_spin_unlock(irq_controller_lock);
+}
+
+static void vic_enable_fiq(struct irq_data *d)
+{
+ vic_set_fiq(d, true);
+}
+
+static void vic_disable_fiq(struct irq_data *d)
+{
+ vic_set_fiq(d, false);
+}
+
+struct fiq_chip vic_fiq = {
+ .fiq_enable = vic_enable_fiq,
+ .fiq_disable = vic_disable_fiq,
+};
+
+static void vic_register_fiq(int irq)
+{
+ fiq_register_mapping(irq, vic_fiq);
+}
+#else /* CONFIG_FIQ */
+static inline void vic_register_fiq(int irq) {}
+#endif /* CONFIG_FIQ */
+
/**
* vic_register() - Register a VIC.
* @base: The base address of the VIC.
* @parent_irq: The parent IRQ if cascaded, else 0.
- * @irq: The base IRQ for the VIC.
+ * @irq_start: The base IRQ for the VIC.
* @valid_sources: bitmask of valid interrupts
*
[PATCH v2 3/3] dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU
Document the new compatible for clock in DMC (Dynamic Memory
Controller) domain of Exynos3250 Clock Management Unit (CMU).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos3250-clock.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
index aadc9c59e2d1..f57d9dd9ea85 100644
--- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -7,6 +7,8 @@ Required Properties:
- compatible: should be one of the following.
- samsung,exynos3250-cmu - controller compatible with Exynos3250 SoC.
+ - samsung,exynos3250-cmu-dmc - controller compatible with
+Exynos3250 SoC for Dynamic Memory Controller domain.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos3250.h header and can be used in device
tree sources.
-Example 1: An example of a clock controller node is listed below.
+Example 1: Examples of clock controller nodes are listed below.
cmu: clock-controller@1003 {
compatible = samsung,exynos3250-cmu;
@@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed
below.
#clock-cells = 1;
};
+ cmu_dmc: clock-controller@105C {
+ compatible = samsung,exynos3250-cmu-dmc;
+ reg = 0x105C 0x2000;
+ #clock-cells = 1;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] clk: samsung: exynos3250: Register DMC clk provider
Add clock provider for clocks in DMC domain including EPLL and BPLL. The
DMC clocks are necessary for Exynos3 devfreq driver.
The DMC clock domain uses different address space (0x105C) than
standard clock domain (0x1003 - 0x1005). The difference is huge
enough to add new DT node for the clock provider, rather than extending
existing address space.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
=
1. Fix overwritteing main clock provider reg_base with DMC clock domain
reg_basr. This leads to OOPS in suspend.
---
drivers/clk/samsung/clk-exynos3250.c | 195 +
include/dt-bindings/clock/exynos3250.h | 27 +
2 files changed, 222 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e7a2d7..6840dc71c72b 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -110,7 +110,14 @@ enum exynos3250_plls {
nr_plls
};
+/* list of PLLs in DMC block to be registered */
+enum exynos3250_dmc_plls {
+ bpll, epll,
+ nr_dmc_plls
+};
+
static void __iomem *reg_base;
+static void __iomem *dmc_reg_base;
/*
* Support for CMU save/restore across system suspends
@@ -724,6 +731,25 @@ static struct samsung_pll_rate_table
exynos3250_pll_rates[] = {
{ /* sentinel */ }
};
+/* EPLL */
+static struct samsung_pll_rate_table exynos3250_epll_rates[] = {
+ PLL_36XX_RATE(8, 200, 3, 1, 0),
+ PLL_36XX_RATE(28800, 96, 2, 2, 0),
+ PLL_36XX_RATE(19200, 128, 2, 3, 0),
+ PLL_36XX_RATE(14400, 96, 2, 3, 0),
+ PLL_36XX_RATE( 9600, 128, 2, 4, 0),
+ PLL_36XX_RATE( 8400, 112, 2, 4, 0),
+ PLL_36XX_RATE( 8004, 106, 2, 4, 43691),
+ PLL_36XX_RATE( 73728000, 98, 2, 4, 19923),
+ PLL_36XX_RATE( 67737598, 270, 3, 5, 62285),
+ PLL_36XX_RATE( 65535999, 174, 2, 5, 49982),
+ PLL_36XX_RATE( 5000, 200, 3, 5, 0),
+ PLL_36XX_RATE( 49152002, 131, 2, 5, 4719),
+ PLL_36XX_RATE( 4800, 128, 2, 5, 0),
+ PLL_36XX_RATE( 45158401, 180, 3, 5, 41524),
+ { /* sentinel */ }
+};
+
/* VPLL */
static struct samsung_pll_rate_table exynos3250_vpll_rates[] = {
PLL_36XX_RATE(6, 100, 2, 1, 0),
@@ -821,3 +847,172 @@ static void __init exynos3250_cmu_init(struct device_node
*np)
samsung_clk_of_add_provider(np, ctx);
}
CLK_OF_DECLARE(exynos3250_cmu, samsung,exynos3250-cmu, exynos3250_cmu_init);
+
+/*
+ * CMU DMC
+ */
+
+#define BPLL_LOCK 0x0118
+#define BPLL_CON0 0x0218
+#define BPLL_CON1 0x021c
+#define BPLL_CON2 0x0220
+#define SRC_DMC0x0300
+#define DIV_DMC1 0x0504
+#define GATE_BUS_DMC0 0x0700
+#define GATE_BUS_DMC1 0x0704
+#define GATE_BUS_DMC2 0x0708
+#define GATE_BUS_DMC3 0x070c
+#define GATE_SCLK_DMC 0x0800
+#define GATE_IP_DMC0 0x0900
+#define GATE_IP_DMC1 0x0904
+#define EPLL_LOCK 0x1110
+#define EPLL_CON0 0x1114
+#define EPLL_CON1 0x1118
+#define EPLL_CON2 0x111c
+#define SRC_EPLL 0x1120
+
+/*
+ * Support for CMU save/restore across system suspends
+ */
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *exynos3250_dmc_clk_regs;
+
+static unsigned long exynos3250_cmu_dmc_clk_regs[] __initdata = {
+ BPLL_LOCK,
+ BPLL_CON0,
+ BPLL_CON1,
+ BPLL_CON2,
+ SRC_DMC,
+ DIV_DMC1,
+ GATE_BUS_DMC0,
+ GATE_BUS_DMC1,
+ GATE_BUS_DMC2,
+ GATE_BUS_DMC3,
+ GATE_SCLK_DMC,
+ GATE_IP_DMC0,
+ GATE_IP_DMC1,
+ EPLL_LOCK,
+ EPLL_CON0,
+ EPLL_CON1,
+ EPLL_CON2,
+ SRC_EPLL,
+};
+
+static int exynos3250_dmc_clk_suspend(void)
+{
+ samsung_clk_save(dmc_reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ return 0;
+}
+
+static void exynos3250_dmc_clk_resume(void)
+{
+ samsung_clk_restore(dmc_reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+}
+
+static struct syscore_ops exynos3250_dmc_clk_syscore_ops = {
+ .suspend = exynos3250_dmc_clk_suspend,
+ .resume = exynos3250_dmc_clk_resume,
+};
+
+static void exynos3250_dmc_clk_sleep_init(void)
+{
+ exynos3250_dmc_clk_regs =
+ samsung_clk_alloc_reg_dump(exynos3250_cmu_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ if (!exynos3250_dmc_clk_regs) {
+ pr_warn(%s: Failed to allocate sleep save data\n, __func__);
+ goto err;
+ }
+
+ register_syscore_ops(exynos3250_dmc_clk_syscore_ops);
+ return;
+err:
+ kfree(exynos3250_dmc_clk_regs);
+}
[PATCH v2 2/3] ARM: dts: exynos3250: Add CMU node for DMC domain clocks
Add CMU (Clock Management Unit) node for DMC (Dynamic Memory Controller)
domain clocks on Exynos3250.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 429a6c6cfcf9..8c3a9cc0a4d1 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -163,6 +163,12 @@
#clock-cells = 1;
};
+ cmu_dmc: clock-controller@105C {
+ compatible = samsung,exynos3250-cmu-dmc;
+ reg = 0x105C 0x2000;
+ #clock-cells = 1;
+ };
+
rtc: rtc@1007 {
compatible = samsung,exynos3250-rtc;
reg = 0x1007 0x100;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad
On 27/08/14 15:22, Javier Martinez Canillas wrote: If there was a BTN_NONE or KEY_UNUSED it would had been better but I think that making a distinction between these two cases (reserved pin vs GPIO available but not used) is useful. Maybe Nick can comment here. Yes, this is probably useful to document. However, I fear that it's not going to be obvious what the distinction is to someone who doesn't have the Atmel docs. Perhaps it would be clearer to just do something like: linux,gpio-keymap = KEY_RESERVED KEY_RESERVED KEY_RESERVED /* GPIO0 */ KEY_RESERVED /* GPIO1 */ KEY_RESERVED /* GPIO2 */ BTN_LEFT; /* GPIO3 */ If you omit any trailing KEY_RESERVED values it doesn't affect anything. I was also going to suggest that you put something like /* Atmel mXT224SL */ in your .dts file so it's clear what version of the maXTouch device you are configuring. -- 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 v9 1/6] clk: samsung: add infrastructure to register cpu clocks
On Tue, Sep 2, 2014 at 3:59 AM, Mike Turquette mturque...@linaro.org wrote:
Quoting Thomas Abraham (2014-07-30 01:07:38)
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Mike Turquette mturque...@linaro.org
Thank you Mike.
Regards,
Thomas.
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 335
+
drivers/clk/samsung/clk-cpu.h | 91 +++
3 files changed, 427 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
create mode 100644 drivers/clk/samsung/clk-cpu.h
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..8909c93 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..009a21b
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham thomas...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility function to register CPU clock for Samsung
+ * Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or
a
+ * group of CPUs. The CPU clock is typically derived from a hierarchy of
clock
+ * blocks which includes mux and divider blocks. There are a number of other
+ * auxiliary clocks supplied to the CPU domain such as the debug blocks and
AXI
+ * clock for CPU domain. The rates of these auxiliary clocks are related to
the
+ * CPU clock rate and this relation is usually specified in the hardware
manual
+ * of the SoC or supplied after the SoC characterization.
+ *
+ * The below implementation of the CPU clock allows the rate changes of the
CPU
+ * clock and the corresponding rate changes of the auxillary clocks of the
CPU
+ * domain. The platform clock driver provides a clock register configuration
+ * for each configurable rate which is then used to program the clock
hardware
+ * registers to acheive a fast co-oridinated rate change for all the CPU
domain
+ * clocks.
+ *
+ * On a rate change request for the CPU clock, the rate change is propagated
+ * upto the PLL supplying the clock to the CPU domain clock blocks. While
the
+ * CPU domain PLL is reconfigured, the CPU domain clocks are driven using an
+ * alternate clock source. If required, the alternate clock source is
divided
+ * down in order to keep the output clock rate within the previous OPP
limits.
+*/
+
+#include linux/errno.h
+#include clk-cpu.h
+
+#define E4210_SRC_CPU 0x0
+#define E4210_STAT_CPU 0x200
+#define E4210_DIV_CPU0 0x300
+#define E4210_DIV_CPU1 0x304
+#define E4210_DIV_STAT_CPU00x400
+#define E4210_DIV_STAT_CPU10x404
+
+#define E4210_DIV0_RATIO0_MASK 0x7
+#define E4210_DIV1_HPM_MASK(0x7 4)
+#define E4210_DIV1_COPY_MASK (0x7 0)
+#define E4210_MUX_HPM_MASK (1 20)
+#define E4210_DIV0_ATB_SHIFT 16
+#define E4210_DIV0_ATB_MASK(DIV_MASK E4210_DIV0_ATB_SHIFT)
+
+#define MAX_DIV8
+#define DIV_MASK 7
+#define DIV_MASK_ALL 0x
+#define MUX_MASK 7
+
+/*
+ * Helper function to wait until divider(s) have stabilized after the
divider
+ * value has changed.
+ */
+static void wait_until_divider_stable(void __iomem *div_reg, unsigned long
mask)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(10);
+
+ do {
+ if (!(readl(div_reg) mask))
+ return;
+ } while (time_before(jiffies, timeout));
+
+ pr_err(%s: timeout in divider stablization\n, __func__);
+}
+
+/*
+ * Helper function to wait until mux has stabilized after the mux selection
+ * value was changed.
+ */
+static void wait_until_mux_stable(void __iomem *mux_reg, u32 mux_pos,
+ unsigned long mux_value)
+{
+ unsigned long
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK(0x3f 1) #define LINKSYSTEM_FLADJ(_x) ((_x) 1) #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) #define EXYNOS5_DRD_PHYUTMI 0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE 0x0c #define EXYNOS5_DRD_PHYCLKRST0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 21) #define PHYCLKRST_SSC_RANGE(_x) ((_x) 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 8) #define PHYCLKRST_FSEL(_x) ((_x) 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - #define PHYCLKRST_PORTRESET BIT(1) #define PHYCLKRST_COMMONONN BIT(0) #define EXYNOS5_DRD_PHYREG0 0x14 +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) +#define PHYREG0_SSC_RANGEBIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READ BIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) 2) +#define PHYREG0_CR_CAP_DATA BIT(1) +#define PHYREG0_CR_CAP_ADDR BIT(0) + #define EXYNOS5_DRD_PHYREG1 0x18 +#define PHYREG1_CR_DATA_OUT(_x) ((_x) 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM00x1c - #define PHYPARAM0_REF_USE_PADBIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 26) #define EXYNOS5_DRD_PHYPARAM10x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM 0x24 #define EXYNOS5_DRD_PHYTEST 0x28 - #define PHYTEST_POWERDOWN_SSPBIT(3) #define PHYTEST_POWERDOWN_HSP
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 04:09:08PM +0530, Vivek Gautam wrote:
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c
b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
+ if (IS_ERR(exynos-sclk))
+ dev_warn(dev, couldn't get sclk\n);
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but
that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
maybe dev_dbg() is what you want ? :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 0/8] thermal: exynos: various cleanups
On Mon, Sep 01, 2014 at 07:05:27AM -0400, edubez...@gmail.com wrote: Amit On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap amit.dan...@samsung.com wrote: On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin edubez...@gmail.com wrote: Amit, On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 9%. It is based on next-20140731 kernel. It should not cause any functionality changes. Did you have the time to test this series? Hi Eduardo/Bartlomiej, For the whole series tested on exynos5250 based arndale board. Tested-by: Amit Daniel Kachhap amit.dan...@samsung.com Thanks! I will pull the series on my tree. Pulled into my next branch. Thanks. Sorry for the delay as I was busy in some internal work. Thanks, Amit D Changes since v2 (https://lkml.org/lkml/2014/6/17/436): - synced patches against next-20140731 - dropped patch thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration (newly added Exynos3250 SoC support uses TYPE_TWO_POINT_TRIMMING calibration) - updated patch description for patch #2 - dropped Reviewed-by from Amit from patch #8 (due to changed scope of the patch) Changes since v1 (https://lkml.org/lkml/2014/5/5/194): - synced patches against next-20140617 - merged patch thermal: exynos: remove unused defines into thermal: exynos: remove unused struct exynos_tmu_registers entries one (per request from Eduardo) - improved patch descriptions for patches #1-5 - fixed documentation for pdata-gain and pdata-reference_voltage - added Reviewed-by from Amit to patches #6, #7 and #10 - added missing Acked-by from Kyungmin Park Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (8): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 126 +--- drivers/thermal/samsung/exynos_tmu.h| 74 +- drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- drivers/thermal/samsung/exynos_tmu_data.h | 31 +- 5 files changed, 35 insertions(+), 253 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -- Eduardo Bezerra Valentin -- 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 v2] mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can only be registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain cases it is required to bind a device with it's dedicated
driver rather than binding with syscon driver.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
This patch decouples syscon object from syscon platform driver, and
allows to create syscon objects first time when it is required by
calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon
objects along with syscon provider device_nodes and regmap handles.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
V1 of this patchset [1] and related discussion can be found here [1].
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname and
will be broken after this patch. As per discussion over here [1], patches
for making these drivers DT based are ready and once that is done they can use
syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
[1]: https://lkml.org/lkml/2014/8/22/81
drivers/mfd/syscon.c | 143 +---
include/linux/mfd/syscon.h |1 +
2 files changed, 44 insertions(+), 100 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..8247e93 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -14,41 +14,45 @@
#include linux/err.h
#include linux/io.h
-#include linux/module.h
+#include linux/list.h
#include linux/of.h
#include linux/of_address.h
-#include linux/of_platform.h
-#include linux/platform_data/syscon.h
-#include linux/platform_device.h
#include linux/regmap.h
#include linux/mfd/syscon.h
+#include linux/slab.h
-static struct platform_driver syscon_driver;
+static DEFINE_SPINLOCK(syscon_list_slock);
+static LIST_HEAD(syscon_list);
struct syscon {
+ struct device_node *np;
struct regmap *regmap;
+ struct list_head list;
};
-static int syscon_match_node(struct device *dev, void *data)
-{
- struct device_node *dn = data;
-
- return (dev-of_node == dn) ? 1 : 0;
-}
+static struct syscon *of_syscon_register(struct device_node *np);
struct regmap *syscon_node_to_regmap(struct device_node *np)
{
- struct syscon *syscon;
- struct device *dev;
+ struct syscon *entry, *syscon = NULL;
+
+ spin_lock(syscon_list_slock);
- dev = driver_find_device(syscon_driver.driver, NULL, np,
-syscon_match_node);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
+ list_for_each_entry(entry, syscon_list, list)
+ if (entry-np == np) {
+ syscon = entry;
+ break;
+ }
- syscon = dev_get_drvdata(dev);
+ spin_unlock(syscon_list_slock);
- return syscon-regmap;
+ if (!syscon)
+ syscon = of_syscon_register(np);
+
+ if (!IS_ERR(syscon))
+ return syscon-regmap;
+ else
+ return ERR_CAST(syscon);
}
EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
@@ -68,27 +72,6 @@ struct regmap *syscon_regmap_lookup_by_compatible(const char
*s)
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
-static int syscon_match_pdevname(struct device *dev, void *data)
-{
- return !strcmp(dev_name(dev), (const char *)data);
-}
-
-struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
-{
- struct device *dev;
- struct syscon *syscon;
-
- dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
-syscon_match_pdevname);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- syscon = dev_get_drvdata(dev);
-
- return syscon-regmap;
-}
-EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
-
struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
const char *property)
{
@@ -110,81 +93,41 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct
device_node *np,
}
Re: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
Chanwoo,
On Fri, Aug 29, 2014 at 08:50:41AM +0900, Chanwoo Choi wrote:
Dear Eduardo,
On 08/28/2014 11:53 PM, Eduardo Valentin wrote:
On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote:
Dear Eduardo,
This patch is wrong. It is my mistake.
Please ignore only this patch because
the offset calculation of 'case 0' is different from 'case 2'.
Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be
a common agreement.
Yes, patches 1 - 3 are correct.
OK. I pulled patch 01 into my next branch.
Can you please update patches 02 and 03 based on my next brach? They are
conflicting with the massive cleanups done by Bartlomiej (Thanks
Bartlomiej). So, please, resend patches 02 and 03 only, refreshed onto
my next branch.
Cheers.
Best Regards,
Chanwoo Choi
Best Regards,
Chanwoo Choi
On 08/26/2014 10:31 AM, Chanwoo Choi wrote:
This patch remove simply duplicate code when reading triminfo register of
Exynos5440.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 64c702a..5888467 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
*/
switch (data-id) {
case 0:
+ case 2:
trim_info = readl(data-base +
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
break;
case 1:
trim_info = readl(data-base + reg-triminfo_data);
break;
- case 2:
- trim_info = readl(data-base -
- EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
/* On exynos5420 the triminfo register is in the shared space */
--
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] mfd: syscon: Decouple syscon interface from platform devices
On 02.09.2014 16:42, Pankaj Dubey wrote: Currently a syscon entity can only be registered directly through a platform device that binds to a dedicated syscon driver. However in certain cases it is required to bind a device with it's dedicated driver rather than binding with syscon driver. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon platform driver, and allows to create syscon objects first time when it is required by calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon objects along with syscon provider device_nodes and regmap handles. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com --- V1 of this patchset [1] and related discussion can be found here [1]. Changes since v1: - Removed of_syscon_unregister function. - Modified of_syscon_register function and it will be used by syscon.c to create syscon objects whenever required. - Removed platform device support from syscon. - Removed syscon_regmap_lookup_by_pdevname API support. - As there are significant changes w.r.t patchset v1, I am taking over author for this patchset from Tomasz Figa. I guess you should also drop my Signed-off-by too. I think the best thing would replacing it with my Suggested-by and adding Arnd's Suggested-by too. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote:
Currently a syscon entity can only be registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain cases it is required to bind a device with it's dedicated
driver rather than binding with syscon driver.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
This patch decouples syscon object from syscon platform driver, and
allows to create syscon objects first time when it is required by
calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon
objects along with syscon provider device_nodes and regmap handles.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
V1 of this patchset [1] and related discussion can be found here [1].
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
Note that you got the Signed-off-by: list wrong, you should never have
any people listed as Signed-off-by after your own name, and they should
be listed before your name only when you are forwarding their patches.
Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname
and
will be broken after this patch. As per discussion over here [1], patches
for making these drivers DT based are ready and once that is done they can use
syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
[1]: https://lkml.org/lkml/2014/8/22/81
Adding Alexander Shiyan to Cc here, so we can make sure this is well
coordinated.
I'm also adding Michal Simek, since here was involved in earlier discussions
about doing this.
drivers/mfd/syscon.c | 143
+---
include/linux/mfd/syscon.h |1 +
2 files changed, 44 insertions(+), 100 deletions(-)
I certainly like the diffstat ;-)
struct syscon {
+ struct device_node *np;
struct regmap *regmap;
+ struct list_head list;
};
Right
@@ -68,27 +72,6 @@ struct regmap *syscon_regmap_lookup_by_compatible(const
char *s)
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
-static int syscon_match_pdevname(struct device *dev, void *data)
-{
- return !strcmp(dev_name(dev), (const char *)data);
-}
-
-struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
-{
- struct device *dev;
- struct syscon *syscon;
-
- dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
- syscon_match_pdevname);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- syscon = dev_get_drvdata(dev);
-
- return syscon-regmap;
-}
-EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
I think this can actually be left intact if that helps with clps71xx.
It could be done in a hacky way using bus_find_device_by_name()
to keep it simple, or in a somewhat nicer way by keeping the
syscon platform_driver around for the non-DT case.
+ regmap = regmap_init_mmio(NULL, base, syscon_regmap_config);
+ if (IS_ERR(regmap)) {
+ pr_err(regmap init failed\n);
+ return ERR_CAST(regmap);
+ }
The last time I looked over this code, I think it was not safe to
call regmap_init_mmio() with a NULL device pointer, and we decided
that should be fixed. Have you checked whether it is ok now?
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] tty/serial: fix config dependencies for samsung serial
From: Pankaj Dubey pankaj.du...@samsung.com Make the config symbols SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than PLAT_SAMSUNG. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/tty/serial/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 26cec64..4f27f0c 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -230,14 +230,14 @@ config SERIAL_SAMSUNG config SERIAL_SAMSUNG_UARTS_4 bool - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || CPU_S3C2442) help Internal node for the common case of 4 Samsung compatible UARTs config SERIAL_SAMSUNG_UARTS int - depends on PLAT_SAMSUNG + depends on SERIAL_SAMSUNG default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 default 3 help -- 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] irqchip: exynos-combiner: Fix compilation error on ARM64
The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including asm/hardirq.h. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Thomas Gleixner t...@linutronix.de --- drivers/irqchip/exynos-combiner.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index f8636a6..7fbedcc 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -18,6 +18,8 @@ #include linux/of_address.h #include linux/of_irq.h +#include asm/hardirq.h + #include irqchip.h #define COMBINER_ENABLE_SET0x0 -- 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 v2 0/7] arch: arm64: enable support for Samsung Exynos7 SoC
Changes since v1: - Reduced the number of features targetted for the initial platform support. This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC processor. NOTE: We tested these patches with the arm64: dts: add dt-bindings/ symlink change posted @ https://lkml.org/lkml/2014/9/1/688 The following patches are tested based on Kgene's for-next tree. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next The following patches are required for this series. 1- irqchip: exynos-combiner: Fix compilation error on ARM64 https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36209.html 2- tty/serial: fix config dependencies for samsung serial https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html Alim Akhtar (1): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support Naveen Krishna Chatradhi (6): clk: samsung: add support for 145xx and 1460x PLLs clk: samsung: Factor out the common code to clk.c clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info clk: samsung: add initial clock support for Exynos7 SoC tty/serial: samsung: enable usage for 64-bit Exynos platforms arm64: dts: Add initial device tree support for EXYNOS7 .../devicetree/bindings/clock/exynos7-clock.txt| 37 ++ arch/arm64/Kconfig | 12 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/exynos/exynos7-espresso.dts| 31 ++ arch/arm64/boot/dts/exynos/exynos7.dtsi| 168 drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5260.c | 183 ++-- drivers/clk/samsung/clk-exynos7.c | 438 drivers/clk/samsung/clk-pll.c | 25 +- drivers/clk/samsung/clk-pll.h |4 + drivers/clk/samsung/clk.c | 98 + drivers/clk/samsung/clk.h | 37 ++ drivers/tty/serial/Kconfig |2 +- include/dt-bindings/clock/exynos7-clk.h| 55 +++ 14 files changed, 929 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h -- 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 v2 1/7] clk: samsung: add support for 145xx and 1460x PLLs
PLL145xx is similar to PLL35xx and PLL1460x is almost similar
to PLL46xx with minor differences in bit positions. Hence,
reuse the functions defined for pll_35xx and pll_46xx to
support 145xx and 1460x PLLs respectively.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-pll.c | 25 -
drivers/clk/samsung/clk-pll.h |4
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index b07fad2..9d70e5c 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -482,6 +482,8 @@ static const struct clk_ops samsung_pll45xx_clk_min_ops = {
#define PLL46XX_VSEL_MASK (1)
#define PLL46XX_MDIV_MASK (0x1FF)
+#define PLL1460X_MDIV_MASK (0x3FF)
+
#define PLL46XX_PDIV_MASK (0x3F)
#define PLL46XX_SDIV_MASK (0x7)
#define PLL46XX_VSEL_SHIFT (27)
@@ -511,13 +513,15 @@ static unsigned long samsung_pll46xx_recalc_rate(struct
clk_hw *hw,
pll_con0 = __raw_readl(pll-con_reg);
pll_con1 = __raw_readl(pll-con_reg + 4);
- mdiv = (pll_con0 PLL46XX_MDIV_SHIFT) PLL46XX_MDIV_MASK;
+ mdiv = (pll_con0 PLL46XX_MDIV_SHIFT) ((pll-type == pll_1460x) ?
+ PLL1460X_MDIV_MASK : PLL46XX_MDIV_MASK);
pdiv = (pll_con0 PLL46XX_PDIV_SHIFT) PLL46XX_PDIV_MASK;
sdiv = (pll_con0 PLL46XX_SDIV_SHIFT) PLL46XX_SDIV_MASK;
kdiv = pll-type == pll_4650c ? pll_con1 PLL4650C_KDIV_MASK :
pll_con1 PLL46XX_KDIV_MASK;
- shift = pll-type == pll_4600 ? 16 : 10;
+ shift = ((pll-type == pll_4600) || (pll-type == pll_1460x)) ? 16 : 10;
+
fvco *= (mdiv shift) + kdiv;
do_div(fvco, (pdiv sdiv));
fvco = shift;
@@ -573,14 +577,21 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw,
unsigned long drate,
lock = 0x;
/* Set PLL PMS and VSEL values. */
- con0 = ~((PLL46XX_MDIV_MASK PLL46XX_MDIV_SHIFT) |
+ if (pll-type == pll_1460x) {
+ con0 = ~((PLL1460X_MDIV_MASK PLL46XX_MDIV_SHIFT) |
+ (PLL46XX_PDIV_MASK PLL46XX_PDIV_SHIFT) |
+ (PLL46XX_SDIV_MASK PLL46XX_SDIV_SHIFT));
+ } else {
+ con0 = ~((PLL46XX_MDIV_MASK PLL46XX_MDIV_SHIFT) |
(PLL46XX_PDIV_MASK PLL46XX_PDIV_SHIFT) |
(PLL46XX_SDIV_MASK PLL46XX_SDIV_SHIFT) |
(PLL46XX_VSEL_MASK PLL46XX_VSEL_SHIFT));
+ con0 |= rate-vsel PLL46XX_VSEL_SHIFT;
+ }
+
con0 |= (rate-mdiv PLL46XX_MDIV_SHIFT) |
(rate-pdiv PLL46XX_PDIV_SHIFT) |
- (rate-sdiv PLL46XX_SDIV_SHIFT) |
- (rate-vsel PLL46XX_VSEL_SHIFT);
+ (rate-sdiv PLL46XX_SDIV_SHIFT);
/* Set PLL K, MFR and MRR values. */
con1 = __raw_readl(pll-con_reg + 0x4);
@@ -1190,6 +1201,9 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
/* clk_ops for 35xx and 2550 are similar */
case pll_35xx:
case pll_2550:
+ case pll_1450x:
+ case pll_1451x:
+ case pll_1452x:
if (!pll-rate_table)
init.ops = samsung_pll35xx_clk_min_ops;
else
@@ -1223,6 +1237,7 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
case pll_4600:
case pll_4650:
case pll_4650c:
+ case pll_1460x:
if (!pll-rate_table)
init.ops = samsung_pll46xx_clk_min_ops;
else
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index c0ed4d4..213de9a 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -33,6 +33,10 @@ enum samsung_pll_type {
pll_s3c2440_mpll,
pll_2550xx,
pll_2650xx,
+ pll_1450x,
+ pll_1451x,
+ pll_1452x,
+ pll_1460x,
};
#define PLL_35XX_RATE(_rate, _m, _p, _s) \
--
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 v2 3/7] clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info
Add the fields fixed_factor_clks and nr_fixed_factor_clks to
struct exynos_cmu_info to allow registering of fixed factor
clocks as well with exynos_cmu_register_one().
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk.c |3 +++
drivers/clk/samsung/clk.h |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index a043654..4b31267 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -402,6 +402,9 @@ void __init exynos_cmu_register_one(struct device_node *np,
if (cmu-fixed_clks)
samsung_clk_register_fixed_rate(ctx, cmu-fixed_clks,
cmu-nr_fixed_clks);
+ if (cmu-fixed_factor_clks)
+ samsung_clk_register_fixed_factor(ctx, cmu-fixed_factor_clks,
+ cmu-nr_fixed_factor_clks);
if (cmu-clk_regs)
exynos_clk_sleep_init(reg_base, cmu-clk_regs,
cmu-nr_clk_regs);
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 552d155..993b51c 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -347,6 +347,9 @@ struct exynos_cmu_info {
/* list of fixed clocks and respective count */
struct samsung_fixed_rate_clock *fixed_clks;
unsigned int nr_fixed_clks;
+ /* list of fixed factor clocks and respective count */
+ struct samsung_fixed_factor_clock *fixed_factor_clks;
+ unsigned int nr_fixed_factor_clks;
/* total number of clocks with IDs assigned*/
unsigned int nr_clk_ids;
--
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 v2 2/7] clk: samsung: Factor out the common code to clk.c
While adding clock support for Exynos5260, the infrastructure to
register multiple clock controllers was introduced. Factor out the
support for registering multiple clock controller from Exynos5260
clock code to common samsung clock code so that it can be used by
other Exynos SoC which have multiple clock controllers.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-exynos5260.c | 183 +-
drivers/clk/samsung/clk.c| 95 ++
drivers/clk/samsung/clk.h| 34 +++
3 files changed, 155 insertions(+), 157 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5260.c
b/drivers/clk/samsung/clk-exynos5260.c
index ce3de97..d72c982 100644
--- a/drivers/clk/samsung/clk-exynos5260.c
+++ b/drivers/clk/samsung/clk-exynos5260.c
@@ -11,10 +11,8 @@
#include linux/clk.h
#include linux/clkdev.h
-#include linux/clk-provider.h
#include linux/of.h
#include linux/of_address.h
-#include linux/syscore_ops.h
#include clk-exynos5260.h
#include clk.h
@@ -22,39 +20,6 @@
#include dt-bindings/clock/exynos5260-clk.h
-static LIST_HEAD(clock_reg_cache_list);
-
-struct exynos5260_clock_reg_cache {
- struct list_head node;
- void __iomem *reg_base;
- struct samsung_clk_reg_dump *rdump;
- unsigned int rd_num;
-};
-
-struct exynos5260_cmu_info {
- /* list of pll clocks and respective count */
- struct samsung_pll_clock *pll_clks;
- unsigned int nr_pll_clks;
- /* list of mux clocks and respective count */
- struct samsung_mux_clock *mux_clks;
- unsigned int nr_mux_clks;
- /* list of div clocks and respective count */
- struct samsung_div_clock *div_clks;
- unsigned int nr_div_clks;
- /* list of gate clocks and respective count */
- struct samsung_gate_clock *gate_clks;
- unsigned int nr_gate_clks;
- /* list of fixed clocks and respective count */
- struct samsung_fixed_rate_clock *fixed_clks;
- unsigned int nr_fixed_clks;
- /* total number of clocks with IDs assigned*/
- unsigned int nr_clk_ids;
-
- /* list and number of clocks registers */
- unsigned long *clk_regs;
- unsigned int nr_clk_regs;
-};
-
/*
* Applicable for all 2550 Type PLLS for Exynos5260, listed below
* DISP_PLL, EGL_PLL, KFC_PLL, MEM_PLL, BUS_PLL, MEDIA_PLL, G3D_PLL.
@@ -115,102 +80,6 @@ static struct samsung_pll_rate_table pll2650_24mhz_tbl[]
__initdata = {
#ifdef CONFIG_PM_SLEEP
-static int exynos5260_clk_suspend(void)
-{
- struct exynos5260_clock_reg_cache *cache;
-
- list_for_each_entry(cache, clock_reg_cache_list, node)
- samsung_clk_save(cache-reg_base, cache-rdump,
- cache-rd_num);
-
- return 0;
-}
-
-static void exynos5260_clk_resume(void)
-{
- struct exynos5260_clock_reg_cache *cache;
-
- list_for_each_entry(cache, clock_reg_cache_list, node)
- samsung_clk_restore(cache-reg_base, cache-rdump,
- cache-rd_num);
-}
-
-static struct syscore_ops exynos5260_clk_syscore_ops = {
- .suspend = exynos5260_clk_suspend,
- .resume = exynos5260_clk_resume,
-};
-
-static void exynos5260_clk_sleep_init(void __iomem *reg_base,
- unsigned long *rdump,
- unsigned long nr_rdump)
-{
- struct exynos5260_clock_reg_cache *reg_cache;
-
- reg_cache = kzalloc(sizeof(struct exynos5260_clock_reg_cache),
- GFP_KERNEL);
- if (!reg_cache)
- panic(could not allocate register cache.\n);
-
- reg_cache-rdump = samsung_clk_alloc_reg_dump(rdump, nr_rdump);
-
- if (!reg_cache-rdump)
- panic(could not allocate register dump storage.\n);
-
- if (list_empty(clock_reg_cache_list))
- register_syscore_ops(exynos5260_clk_syscore_ops);
-
- reg_cache-rd_num = nr_rdump;
- reg_cache-reg_base = reg_base;
- list_add_tail(reg_cache-node, clock_reg_cache_list);
-}
-
-#else
-static void exynos5260_clk_sleep_init(void __iomem *reg_base,
- unsigned long *rdump,
- unsigned long nr_rdump){}
-#endif
-
-/*
- * Common function which registers plls, muxes, dividers and gates
- * for each CMU. It also add CMU register list to register cache.
- */
-
-void __init exynos5260_cmu_register_one(struct device_node *np,
- struct exynos5260_cmu_info *cmu)
-{
- void __iomem *reg_base;
- struct samsung_clk_provider *ctx;
-
- reg_base = of_iomap(np, 0);
- if (!reg_base)
- panic(%s: failed to map registers\n, __func__);
-
- ctx = samsung_clk_init(np, reg_base, cmu-nr_clk_ids);
- if (!ctx)
- panic(%s: unable to alllocate ctx\n, __func__);
-
- if (cmu-pll_clks)
-
[PATCH v2 5/7] arm64: dts: Add initial device tree support for EXYNOS7
Add initial device tree nodes for EXYNOS7 SoC and board dts file
to support Espresso board based on Exynos7 SoC.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm64/boot/dts/Makefile|1 +
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 31 +
arch/arm64/boot/dts/exynos/exynos7.dtsi | 168 +++
3 files changed, 200 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c52bdb0..a3bc18a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_EXYNOS7) += exynos/exynos7-espresso.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
new file mode 100644
index 000..f6a8879
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -0,0 +1,31 @@
+/*
+ * SAMSUNG Exynos7 Espresso board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos7.dtsi
+
+/ {
+ model = Samsung Exynos7 Espresso board based on EXYNOS7;
+ compatible = samsung,exynos7-espresso, samsung,exynos7;
+
+ chosen {
+ linux,stdout-path = serial_2;
+ };
+
+ memory@4000 {
+ device_type = memory;
+ reg = 0x0 0x4000 0x0 0xC000;
+ };
+};
+
+serial_2 {
+ status = okay;
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
new file mode 100644
index 000..e593af55
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -0,0 +1,168 @@
+/*
+ * SAMSUNG EXYNOS7 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clock/exynos7-clk.h
+
+/ {
+ compatible = samsung,exynos7;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ serial0 = serial_0;
+ serial1 = serial_1;
+ serial2 = serial_2;
+ serial3 = serial_3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x1;
+ };
+
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x2;
+ };
+
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x3;
+ };
+ };
+
+ psci {
+ compatible = arm,psci-0.2;
+ method = smc;
+ };
+
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0 0 0x1800;
+
+ chipid@1000 {
+ compatible = samsung,exynos4210-chipid;
+ reg = 0x1000 0x100;
+ };
+
+ fin_pll: xxti {
+ compatible = fixed-clock;
+ clock-frequency = 2400;
+ clock-output-names = fin_pll;
+ #clock-cells = 0;
+ };
+
+ gic: interrupt-controller@11001000 {
+ compatible = arm,gic-400;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x11001000 0x1000,
+ 0x11002000 0x1000,
+
[PATCH v2 7/7] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
From: Alim Akhtar alim.akh...@samsung.com This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Rob Herring r...@kernel.org Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm64/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fd4e81a..b4d1dc2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,18 @@ source kernel/Kconfig.freezer menu Platform selection +config ARCH_EXYNOS + bool + help + This enables support for Samsung Exynos SoC family + +config ARCH_EXYNOS7 + bool ARMv8 based Samsung Exynos7 + select ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + help + This enables support for Samsung Exynos7 SoC family + config ARCH_VEXPRESS bool ARMv8 software model (Versatile Express) select ARCH_REQUIRE_GPIOLIB -- 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 v2 4/7] clk: samsung: add initial clock support for Exynos7 SoC
Add initial clock support for Exynos7 SoC which is required
to bring up platforms based on Exynos7.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
---
.../devicetree/bindings/clock/exynos7-clock.txt| 37 ++
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos7.c | 438
include/dt-bindings/clock/exynos7-clk.h| 55 +++
4 files changed, 531 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos7.c
create mode 100644 include/dt-bindings/clock/exynos7-clk.h
diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
new file mode 100644
index 000..798eb10
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -0,0 +1,37 @@
+* Samsung Exynos7 Clock Controller
+
+Exynos7 clock controller has various blocks which are instantiated
+independently from the device-tree. These clock controllers
+generate and supply clocks to various hardware blocks within
+the SoC.
+
+Each clock is assigned an identifier and client nodes can use
+this identifier to specify the clock which they consume. All
+available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos7-clk.h header and can be used in
+device tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It
+is expected that they are defined using standard clock bindings
+with following clock-output-names:
+
+ - fin_pll - PLL input clock from XXTI
+
+Required Properties for Clock Controller:
+
+ - compatible: clock controllers will use one of the following
+ compatible strings to indicate the clock controller
+ functionality.
+
+ - samsung,exynos7-clock-topc
+ - samsung,exynos7-clock-top0
+ - samsung,exynos7-clock-peric0
+ - samsung,exynos7-clock-peric1
+ - samsung,exynos7-clock-peris
+
+ - reg: physical base address of the controller and the length of
+ memory mapped region.
+
+ - #clock-cells: should be 1.
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..5da0ba9 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o
obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
obj-$(CONFIG_ARCH_S5PV210) += clk-s5pv210.o clk-s5pv210-audss.o
+obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
new file mode 100644
index 000..25e12b3
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -0,0 +1,438 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Naveen Krishna Chatradhi ch.nav...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+*/
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+
+#include clk.h
+#include dt-bindings/clock/exynos7-clk.h
+
+/* Register Offset definitions for CMU_TOPC (0x1057) */
+#define CC_PLL_LOCK0x
+#define BUS0_PLL_LOCK 0x0004
+#define BUS1_DPLL_LOCK 0x0008
+#define MFC_PLL_LOCK 0x000C
+#define AUD_PLL_LOCK 0x0010
+#define CC_PLL_CON00x0100
+#define BUS0_PLL_CON0 0x0110
+#define BUS1_DPLL_CON0 0x0120
+#define MFC_PLL_CON0 0x0130
+#define AUD_PLL_CON0 0x0140
+#define AUD_PLL_CON1 0x0144
+#define AUD_PLL_CON2 0x0148
+#define MIF_PLL_CON0 0x0150
+#define MIF_PLL_CON1 0x0154
+#define MIF_PLL_CON2 0x0158
+#define MUX_SEL_TOPC0 0x0200
+#define MUX_SEL_TOPC1 0x0204
+#define MUX_SEL_TOPC3 0x020C
+#define DIV_TOPC1 0x0604
+#define DIV_TOPC3 0x060C
+#define ENABLE_ACLK_TOPC1 0x0804
+#define ENABLE_SCLK_TOPC1 0x0A04
+
+static struct samsung_fixed_factor_clock topc_fixed_factor_clks[] __initdata =
{
+ FFACTOR(0, ffac_topc_bus0_pll_div2, mout_bus0_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_bus0_pll_div4,
+ ffac_topc_bus0_pll_div2, 1, 2, 0),
+ FFACTOR(0, ffac_topc_bus1_pll_div2, mout_bus1_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_cc_pll_div2, mout_cc_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_mfc_pll_div2, mout_mfc_pll_ctrl, 1, 2, 0),
+};
+
+/* List of parent clocks for Muxes in CMU_TOPC */
+PNAME(mout_bus0_pll_ctrl_p)= { fin_pll, fout_bus0_pll };
+PNAME(mout_bus1_pll_ctrl_p)= { fin_pll, fout_bus1_pll };
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
Tue, 02 Sep 2014 17:20:03 +0200 от Arnd Bergmann a...@arndb.de:
On Tuesday 02 September 2014 20:12:15 Pankaj Dubey wrote:
Currently a syscon entity can only be registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain cases it is required to bind a device with it's dedicated
driver rather than binding with syscon driver.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
This patch decouples syscon object from syscon platform driver, and
allows to create syscon objects first time when it is required by
calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon
objects along with syscon provider device_nodes and regmap handles.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
V1 of this patchset [1] and related discussion can be found here [1].
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
Note that you got the Signed-off-by: list wrong, you should never have
any people listed as Signed-off-by after your own name, and they should
be listed before your name only when you are forwarding their patches.
Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname
and
will be broken after this patch. As per discussion over here [1], patches
for making these drivers DT based are ready and once that is done they can
use
syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible.
[1]: https://lkml.org/lkml/2014/8/22/81
...
-struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
-{
- struct device *dev;
- struct syscon *syscon;
-
- dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
-syscon_match_pdevname);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- syscon = dev_get_drvdata(dev);
-
- return syscon-regmap;
-}
-EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
I think this can actually be left intact if that helps with clps71xx.
It could be done in a hacky way using bus_find_device_by_name()
to keep it simple, or in a somewhat nicer way by keeping the
syscon platform_driver around for the non-DT case.
It will not work anyway because the patch involves the use of
of_device_is_compatible(), of_iomap() etc...
---
N�r��yb�X��ǧv�^�){.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH] irqchip: exynos-combiner: Fix compilation error on ARM64
On 02/09/14 16:24, Naveen Krishna Chatradhi wrote: The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including asm/hardirq.h. You should avoid using asm headers whenever possible esp. in driver code. linux/hardirq.h or much better linux/interrupt.h should fix this error. Regards, Sudeep -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] arch: arm64: enable support for Samsung Exynos7 SoC
Hi Naveen, On 02.09.2014 17:35, Naveen Krishna Chatradhi wrote: Changes since v1: - Reduced the number of features targetted for the initial platform support. Are you going to reply to my comments to previous version? Btw. My @samsung.com e-mail is no longer valid. Please use my private one for patches related to Samsung clocks and pin control drivers. Respective patch for MAINTAINERS file has been applied already. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mfd: syscon: Decouple syscon interface from platform devices
On Tuesday 02 September 2014 19:42:52 Alexander Shiyan wrote:
-struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
-{
- struct device *dev;
- struct syscon *syscon;
-
- dev = driver_find_device(syscon_driver.driver, NULL, (void *)s,
-syscon_match_pdevname);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- syscon = dev_get_drvdata(dev);
-
- return syscon-regmap;
-}
-EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
I think this can actually be left intact if that helps with clps71xx.
It could be done in a hacky way using bus_find_device_by_name()
to keep it simple, or in a somewhat nicer way by keeping the
syscon platform_driver around for the non-DT case.
It will not work anyway because the patch involves the use of
of_device_is_compatible(), of_iomap() etc...
What I meant was to have the pdevname stuff keep working the way
it does today. At that point, you essentially have two completely
independent drivers, one that registers a platform driver and
provides syscon_regmap_lookup_by_pdevname, and one that provides
the other interfaces using DT lookup.
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] irqchip: exynos-combiner: Fix compilation error on ARM64
Naveen, On Tue, Sep 02, 2014 at 08:54:52PM +0530, Naveen Krishna Chatradhi wrote: The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including asm/hardirq.h. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Thomas Gleixner t...@linutronix.de --- drivers/irqchip/exynos-combiner.c |2 ++ 1 file changed, 2 insertions(+) Please include me in the Cc on future irqchip fixes, I almost missed this one. thx, Jason. -- 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 v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
HI Thomas, Thomas Abraham ta.oma...@gmail.com writes: On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. I also noticed that the force vdd_arm and vdd_kfc to max voltage patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) Are there any plans to update the main referece branch and include cpufreq? Kevin [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a -- 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 v11 11/19] irqchip: vic: Add support for FIQ management
On Tue, Sep 02, 2014 at 02:00:45PM +0100, Daniel Thompson wrote:
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index bda5a91..8821160 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data
*gic,
/*
* Fully acknowledge (both ack and eoi) a FIQ-based IPI
*/
-static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs,
-void *data)
+void gic_handle_fiq_ipi(void)
{
struct gic_chip_data *gic = gic_data[0];
- void __iomem *cpu_base = gic_data_cpu_base(gic);
+ void __iomem *cpu_base;
unsigned long irqstat, irqnr;
+ if (!gic || !gic-fiq_enable)
+ return;
+
+ cpu_base = gic_data_cpu_base(gic);
+
if (WARN_ON(!in_nmi()))
return NOTIFY_BAD;
@@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb,
unsigned long regs,
return NOTIFY_OK;
}
-
-/*
- * Notifier to ensure IPI FIQ is acknowledged correctly.
- */
-static struct notifier_block gic_fiq_ipi_notifier = {
- .notifier_call = gic_handle_fiq_ipi,
-};
#else /* CONFIG_FIQ */
static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
int group) {}
@@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
#ifdef CONFIG_SMP
set_smp_cross_call(gic_raise_softirq);
register_cpu_notifier(gic_cpu_notifier);
-#ifdef CONFIG_FIQ
- if (gic_data_fiq_enable(gic))
- register_fiq_nmi_notifier(gic_fiq_ipi_notifier);
-#endif
#endif
set_handle_irq(gic_handle_irq);
}
Shouldn't this be merged into some other patch?
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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 16/17] drm/exynos/ipp: remove file argument from node related functions
On 09/02/2014 09:55 PM, Andrzej Hajda wrote:
Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
v3:
- file check moved to next patch
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
About both patch 16 and 17
Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com
Thanks.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f0f4e..9e9714a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
dma_addr_t *addr;
addr = exynos_drm_gem_get_dma_addr(drm_dev,
- qbuf-handle[i], file);
+ qbuf-handle[i], c_node-filp);
if (IS_ERR(addr)) {
DRM_ERROR(failed to get addr.\n);
ipp_put_mem_node(drm_dev, c_node, m_node);
@@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event
*event)
}
static int ipp_get_event(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
spin_lock_irqsave(drm_dev-event_lock, flags);
- file-event_space += sizeof(e-event);
+ c_node-filp-event_space += sizeof(e-event);
spin_unlock_irqrestore(drm_dev-event_lock, flags);
return -ENOMEM;
}
@@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e-event.prop_id = qbuf-prop_id;
e-event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf-buf_id;
e-base.event = e-event.base;
- e-base.file_priv = file;
+ e-base.file_priv = c_node-filp;
e-base.destroy = ipp_free_event;
mutex_lock(c_node-event_lock);
list_add_tail(e-base.link, c_node-event_list);
@@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
switch (qbuf-buf_type) {
case IPP_BUF_ENQUEUE:
/* get memory node */
- m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
+ m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
if (IS_ERR(m_node)) {
DRM_ERROR(failed to get m_node.\n);
return PTR_ERR(m_node);
@@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
*/
if (qbuf-ops_id == EXYNOS_DRM_OPS_DST) {
/* get event for destination buffer */
- ret = ipp_get_event(drm_dev, file, c_node, qbuf);
+ ret = ipp_get_event(drm_dev, c_node, qbuf);
if (ret) {
DRM_ERROR(failed to get event.\n);
goto err_clean_node;
--
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: [PATCHv5 4/4] thermal: exynos: Remove duplicate code when reading triminfo register of Exynos5440
Dear Eduardo,
On 08/30/2014 04:28 AM, Eduardo Valentin wrote:
Chanwoo,
On Fri, Aug 29, 2014 at 08:50:41AM +0900, Chanwoo Choi wrote:
Dear Eduardo,
On 08/28/2014 11:53 PM, Eduardo Valentin wrote:
On Thu, Aug 28, 2014 at 01:25:14PM +0900, Chanwoo Choi wrote:
Dear Eduardo,
This patch is wrong. It is my mistake.
Please ignore only this patch because
the offset calculation of 'case 0' is different from 'case 2'.
Do patches 1 - 3 are still correct? Patch 1, from Barlomiej, seams to be
a common agreement.
Yes, patches 1 - 3 are correct.
OK. I pulled patch 01 into my next branch.
Can you please update patches 02 and 03 based on my next brach? They are
conflicting with the massive cleanups done by Bartlomiej (Thanks
Bartlomiej). So, please, resend patches 02 and 03 only, refreshed onto
my next branch.
OK, I'll send new patchset after rebase it.
Best Regards,
Chanwoo Choi
Cheers.
Best Regards,
Chanwoo Choi
Best Regards,
Chanwoo Choi
On 08/26/2014 10:31 AM, Chanwoo Choi wrote:
This patch remove simply duplicate code when reading triminfo register of
Exynos5440.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 64c702a..5888467 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -187,15 +187,13 @@ static int exynos_tmu_initialize(struct
platform_device *pdev)
*/
switch (data-id) {
case 0:
+ case 2:
trim_info = readl(data-base +
EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
break;
case 1:
trim_info = readl(data-base + reg-triminfo_data);
break;
- case 2:
- trim_info = readl(data-base -
- EXYNOS5440_EFUSE_SWAP_OFFSET + reg-triminfo_data);
}
} else {
/* On exynos5420 the triminfo register is in the shared space */
--
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
[PATCHv6 0/2] thermal: exynos: Add support for TRIMINFO feature of Exynos3250
This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250.
But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only one
TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which
has more than one TRIMINF_CTRL.
Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove
duplicate code when reading triminfo register of Exynos5440.
Changes from v5:
- Rebase this patchset on next branch of linux-soc-thermal.git
Changes from v4:
- Remove un-necessary triminfo_ctrl_{shift, mask} field
- Includes Bartlomiej's patch[1] that Exynos5260 / Exynos5420 should not use
TRIM_RELOAD flag
[2] https://lkml.org/lkml/2014/8/20/481
Changes from v3:
- Add reviewed message of Amit Daniel Kachhap amit.dan...@samsung.com
- Split RELOAD patch as two patch
- Fix 'TRIMINFO_RELOAD_SHIFT' value
- This series includes separate patch[1]
[1] https://lkml.org/lkml/2014/8/20/5
- Drop ACTIME bit setting because TRM includes not enough information of ACTIME
bit.
Changes from v2:
- Fix build break because of missing 'or' operation.
Changes from v1:
- Add missing 'TMU_SUPPORT_TRIM_RELOAD' features
Chanwoo Choi (2):
thermal: exynos: Add support for many TRIMINFO_CTRL registers
thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
drivers/thermal/samsung/exynos_thermal_common.h | 1 +
drivers/thermal/samsung/exynos_tmu.c| 15 ---
drivers/thermal/samsung/exynos_tmu.h| 7 +--
drivers/thermal/samsung/exynos_tmu_data.c | 11 +--
drivers/thermal/samsung/exynos_tmu_data.h | 8 ++--
5 files changed, 33 insertions(+), 9 deletions(-)
--
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
[PATCHv6 2/2] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
This patch add support for TRIM_RELOAD feature at Exynos3250. The TMu of
Exynos3250 has two TRIMINFO_CON register and must need to set RELOAD bit
before reading TRIMINFO register.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Reviewed-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/thermal/samsung/exynos_tmu_data.c | 9 +++--
drivers/thermal/samsung/exynos_tmu_data.h | 7 +--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 362a1e1..8bae170 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -87,6 +87,9 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data
= {
#if defined(CONFIG_SOC_EXYNOS3250)
static const struct exynos_tmu_registers exynos3250_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+ .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
+ .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
+ .triminfo_ctrl_count = 2,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
.test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
.therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
@@ -147,8 +150,10 @@ static const struct exynos_tmu_registers
exynos3250_tmu_registers = {
.temp_level = 95, \
}, \
.freq_tab_count = 2, \
+ .triminfo_reload[0] = EXYNOS_TRIMINFO_RELOAD_ENABLE, \
+ .triminfo_reload[1] = EXYNOS_TRIMINFO_RELOAD_ENABLE, \
.registers = exynos3250_tmu_registers, \
- .features = (TMU_SUPPORT_EMULATION | \
+ .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
TMU_SUPPORT_EMUL_TIME)
#endif
@@ -169,7 +174,7 @@ struct exynos_tmu_init_data const
exynos3250_default_tmu_data = {
#if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
static const struct exynos_tmu_registers exynos4412_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
- .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON,
+ .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON2,
.triminfo_ctrl_count = 1,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
.test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index 6b47a17..4b8f33c 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -39,14 +39,17 @@
#define EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT 8
#define EXYNOS_TMU_CORE_EN_SHIFT 0
+/* Exynos3250 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON1 0x10
+
/* Exynos4210 specific registers */
#define EXYNOS4210_TMU_REG_THRESHOLD_TEMP 0x44
#define EXYNOS4210_TMU_REG_TRIG_LEVEL0 0x50
#define EXYNOS4210_TMU_TRIG_LEVEL_MASK 0x
-/* Exynos5250 and Exynos4412 specific registers */
-#define EXYNOS_TMU_TRIMINFO_CON0x14
+/* Exynos5250, Exynos4412, Exynos3250 specific registers */
+#define EXYNOS_TMU_TRIMINFO_CON2 0x14
#define EXYNOS_THD_TEMP_RISE 0x50
#define EXYNOS_THD_TEMP_FALL 0x54
#define EXYNOS_EMUL_CON0x80
--
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 v2] mfd: syscon: Decouple syscon interface from platform devices
On Tue, Sep 2, 2014 at 8:12 PM, Pankaj Dubey pankaj.du...@samsung.com wrote: Currently a syscon entity can only be registered directly through a platform device that binds to a dedicated syscon driver. However in certain cases it is required to bind a device with it's dedicated driver rather than binding with syscon driver. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon platform driver, and allows to create syscon objects first time when it is required by calling of syscon_regmap_lookup_by APIs and keeps a list of such syscon objects along with syscon provider device_nodes and regmap handles. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com --- V1 of this patchset [1] and related discussion can be found here [1]. Changes since v1: - Removed of_syscon_unregister function. - Modified of_syscon_register function and it will be used by syscon.c to create syscon objects whenever required. - Removed platform device support from syscon. - Removed syscon_regmap_lookup_by_pdevname API support. - As there are significant changes w.r.t patchset v1, I am taking over author for this patchset from Tomasz Figa. Note: Current kernel has clps711x user of syscon_regmap_lookup_by_pdevname and will be broken after this patch. As per discussion over here [1], patches for making these drivers DT based are ready and once that is done they can use syscon_regmap_lookup_by_phandle or syscon_regmap_lookup_by_compatible. [1]: https://lkml.org/lkml/2014/8/22/81 [snip] Tested on smdk5250 board with 3.17-rc3 for USB 2.0 and USB 3.0, since USB takes syscon phandle for handling some of the pmu registers. Things work fine with all the dt side changes in this patch. Tested-by: Vivek Gautam gautam.vi...@samsung.com -- 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
Re: [PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
On Fri, Aug 29, 2014 at 12:58 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 28, 2014 at 01:31:59PM +0530, Vivek Gautam wrote: The Exynos-DWC3 USB 3.0 DRD controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 785510a..e235894 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate Samsung Exynos Platform - depends on ARCH_EXYNOS || COMPILE_TEST + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST wait when building for ARCH_EXYNOS7 you don't get ARCH_EXYNOS ? Right, we do get it now in V2 patch series for Exynos7 [1], but it wasn't available in the first series [2]. Will drop this patch now. [1] http://www.spinics.net/lists/linux-samsung-soc/msg36378.html [2] http://www.spinics.net/lists/arm-kernel/msg357382.html -- 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
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi dfo...@gmail.com wrote: 2014-08-28 10:02 GMT+02:00 Vivek Gautam: This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver - depends on ARCH_EXYNOS5 OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) OF shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like that idea. The thing is that this will likely need to be patches for exynos8, 9, 10, 11... Yes, after we have the 2nd version of Exynos7 support patches, it makes more sense to keep dependency on ARCH_EXYNOS. -- 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
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman khil...@kernel.org wrote: HI Thomas, Thomas Abraham ta.oma...@gmail.com writes: On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman khil...@kernel.org wrote: Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman khil...@linaro.org wrote: On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote: [...] Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. I mis-stated this. Actually my tree is based on the v3.17-rc1 branch of the exynos-reference tree[1] + the above mentioned patches for cpuidle and cpufreq. Also, I've narrowed down the instability a bit, and it's not related to CPUidle. I can now trigger a boot hang even without CPUidle enabled. Here's a quick way to cause a boot lockup. With the switcher disabled, I enable CPUfreq and set the default governor to performance. As soon as cpufreq driver loads, it tries to use the top frequences for both clusters, and it hangs. Selectively disabling frequencies, I narrowed it down to the 1.3GHz and 1.2GHz frequencies of the little cluster. With these commented out in the DT, it will fully boot with the performance governor enabled. So that leads to the question. Are all of the operating points in exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Yes, your branch works fine, but it's because of the last (unposted) patch on your branch[1]: ARM: dts: remove all supplies sourced from tps65090 PMIC I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary. That patch had not been posted, so I hadn't seen it before, but based on the changelog, it's pretty clear you had the same problems that I had without it, so I'm not sure why it wasn't mentioned earlier in this thread. At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier. I also noticed that the force vdd_arm and vdd_kfc to max voltage patch is not actually using the max voltage, which appears to be 1.5V from the DT, but actually using 1.35 V, however the changelog has no explanation for this. This also is a temporary patch and by max voltage I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply. One other thing, your temp-cpufreq branch has conflicts with max77802 stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm using for CPUidle dependencies, on the PMU series IIRC.) I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch. Are there any plans to update the main referece branch and include cpufreq? Yes, a new branch with all the latest patches (cpufreq +
[PATCH v2] irqchip: exynos-combiner: Fix compilation error on ARM64
The following compilation error occurs on 64-bit Exynos7 SoC: drivers/irqchip/exynos-combiner.c: In function ‘combiner_irq_domain_map’: drivers/irqchip/exynos-combiner.c:162:2: error: implicit declaration of function ‘set_irq_flags’ [-Werror=implicit-function-declaration] set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: error: ‘IRQF_VALID’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); ^ drivers/irqchip/exynos-combiner.c:162:21: note: each undeclared identifier is reported only once for each function it appears in drivers/irqchip/exynos-combiner.c:162:34: error: ‘IRQF_PROBE’ undeclared (first use in this function) set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); Fix the build error by including linux/interrupt.h. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Thomas Gleixner t...@linutronix.de Cc: Jason Cooper ja...@lakedaemon.net Cc: Sudeep Holla sudeep.ho...@arm.com --- Changes since v1: Used linux/interrupt.h instead of asm/hardirq.h drivers/irqchip/exynos-combiner.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index f8636a6..5945223 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -15,6 +15,7 @@ #include linux/slab.h #include linux/irqdomain.h #include linux/irqchip/chained_irq.h +#include linux/interrupt.h #include linux/of_address.h #include linux/of_irq.h -- 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
