Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Thu, Sep 25, 2014 at 10:50:22AM +0530, Vivek Gautam wrote: Hi Greg, On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Now that we have completely moved from older USB-PHY drivers to newer GENERIC-PHY drivers for PHYs available with USB controllers on Exynos series of SoCs, we can remove the support for the same in our host drivers too. We also defer the probe for our host in case we end up getting EPROBE_DEFER error when getting PHYs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Alan Stern st...@rowland.harvard.edu --- Did this one got missed for usb-next ? I can only see usb: host: ohci-exynos: Remove unnecessary usb-phy support in the next branch. Ignore me if you have already taken care of this, and plan to queue it up. If it's not in my tree already, please resend as I don't have this in my queue anymore. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Mon, Sep 29, 2014 at 7:21 AM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Sep 25, 2014 at 10:50:22AM +0530, Vivek Gautam wrote: Hi Greg, On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Now that we have completely moved from older USB-PHY drivers to newer GENERIC-PHY drivers for PHYs available with USB controllers on Exynos series of SoCs, we can remove the support for the same in our host drivers too. We also defer the probe for our host in case we end up getting EPROBE_DEFER error when getting PHYs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Alan Stern st...@rowland.harvard.edu --- Did this one got missed for usb-next ? I can only see usb: host: ohci-exynos: Remove unnecessary usb-phy support in the next branch. Ignore me if you have already taken care of this, and plan to queue it up. If it's not in my tree already, please resend as I don't have this in my queue anymore. yea, i don't see it in usb-next. I will resend it then. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 RESEND 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes since v4:
- returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ehci-exynos.c | 74 +++-
1 file changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..7189f2e 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
-#include linux/usb/phy.h
-#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
#include linux/usb/hcd.h
-#include linux/usb/otg.h
#include ehci.h
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)-priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci-phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ehci-phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ehci-phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci-phy)) {
- ret = PTR_ERR(exynos_ehci-phy);
- if (ret != -ENXIO ret != -ENODEV) {
- dev_err(dev, no usb2 phy configured\n);
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ dev_err(dev,
+ Error retrieving usb2 phy: %d\n, ret);
+ return ret;
+ }
}
- dev_dbg(dev, Failed to get usb2 phy\n);
- } else {
- exynos_ehci-otg = exynos_ehci-phy-otg;
}
- return ret;
+ return 0;
}
static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci-phy))
- return usb_phy_init(exynos_ehci-phy);
-
for (i = 0; ret == 0 i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- ret = phy_power_on(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ ret = phy_power_on(exynos_ehci-phy[i]);
if (ret)
for (i--; i = 0; i--)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if (!IS_ERR(exynos_ehci-phy[i]))
+ phy_power_off(exynos_ehci-phy[i]);
return ret;
}
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci-phy)) {
- usb_phy_shutdown(exynos_ehci-phy);
- return;
- }
-
for (i = 0; i PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci-phy_g[i]))
- phy_power_off(exynos_ehci-phy_g[i]);
+ if
RE: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related clocks
Hi,
On Monday, September 29, 2014 9:07 AM, Kyungmin Park wrote,
To: Pankaj Dubey
Cc: Chanwoo Choi; Kukjin Kim; Russell King - ARM Linux;
naus...@samsung.com;
Tomasz Figa; linux-samsung-soc; robh...@kernel.org; Sylwester Nawrocki;
Mike
Turquette; arm-linux
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
clocks
On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com
wrote:
Hi Chanwoo,
On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
To: Pankaj Dubey
Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org;
kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette;
Sylwester Nawrocki
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3
related
clocks
Hi Pankaj,
On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
missing clock entries for UART2 and UART3.
CC: Mike Turquette mturque...@linaro.org
CC: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 11 +++
include/dt-bindings/clock/exynos3250.h | 10 +-
2 files changed, 20 insertions(+), 1 deletion(-)
Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART
2,3.
As per Exynos3250 user manual that I have with me it supports
UART(0,1,2,3).
It has been mentioned
which UM do you use? There are two UARTs at rev0.01
I am using Rev 2.0.
Thanks,
Pankaj Dubey
in UART Chapter as well as CMU IP details also mentioned about the
clock entries. We have tested it also on Espresso3250 board which is
based on Exynos3250 SoC.
I can't find it at my UM.
Kyungmin Park
Thanks,
Pankaj Dubey
Thanks,
Chanwoo Choi
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e..0722fef 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
__initdata =
{
MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0,
3),
/* SRC_PERIL0 */
+ MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
12, 4),
+ MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0,
8,
4),
MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0,
4,
4),
MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0,
0,
4),
@@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
__initdata = {
DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
/* DIV_PERIL0 */
+ DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12,
4),
+ DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8,
+ 4),
DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0,
4),
@@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
+ GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
+ GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6
+687,7
@@
static struct samsung_gate_clock gate_clks[] __initdata = {
GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13,
0,
0),
GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
0, 0),
GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0,
0),
+ GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7,
0,
0),
GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6,
0,
0),
GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5,
0,
0),
GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0,
0),
@@
-698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
+ GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0,
0),
+ GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0,
+ 0),
GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
GATE(CLK_UART0, uart0, div_aclk_100, GATE_IP_PERIL, 0, 0,
0), }; diff --git a/include/dt-bindings/clock/exynos3250.h
b/include/dt-bindings/clock/exynos3250.h
index
RE: [PATCH 2/3] clk: samsung: remove unnecessary CONFIG_OF from clk.c
Hi Tomasz, On Saturday, September 27, 2014 6:51 PM, Tomasz Figa wrote, Hi Pankaj, On 27.09.2014 07:41, Pankaj Dubey wrote: Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Missing patch description. OK, will add it. --- drivers/clk/samsung/clk.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c index deab84d..31bf391 100644 --- a/drivers/clk/samsung/clk.c +++ b/drivers/clk/samsung/clk.c @@ -281,7 +281,6 @@ void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx, * obtain the clock speed of all external fixed clock sources from device * tree and register it */ -#ifdef CONFIG_OF We still have non-DT platforms which use this code, i.e. s3c24xx and s3c64xx. Have you checked if this compiles fine on them with CONFIG_OF disabled? Compile tested with s3c2410_defconfig and s3c6400_defconfig, and its compiled fine. In both cases CONFIG_OF was disabled. Thanks, Pankaj Dubey 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 v3 6/6] mfd: cros_ec: Instantiate sub-devices from device tree
Hello Lee, On 09/25/2014 04:48 PM, Lee Jones wrote: On Thu, 25 Sep 2014, Javier Martinez Canillas wrote: Understood, that's why I dropped this since as explained earlier, it makes more sense to include this change once the cros_ec_dev driver is pushed to upstream. The last version of the series (v4) I posted a week ago [0], does not include this patch so I hope the series can be picked for 3.18 since most of the patches were already acked by you. Unfortunately this is going to have to wait until v3.19 now, as Linus is closing the -rcs early. I have subsequently applied my last patch to the MFD tree for v3.18. It will be good for these patches to get some soak testing in -next anyway, rather than rush them in. I don't want to be annoying but I was just wondering if now that Linus has delayed the 3.18 merge window for two weeks [1], you will consider picking this series. Most of the patches have been acked by you a couple of weeks ago anyways and I dropped $subject from the last version of the series [2], which was the patch you had issues with. It would be awesome if this can make it to 3.18 so we can start adding the missing functionality and target it to 3.19. Thanks a lot and best regards, Javier [1]: http://thread.gmane.org/gmane.linux.kernel/1797057 [2]: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36770.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
Re: [PATCH v4 2/5] i2c: i2c-cros-ec-tunnel: Set retries to 3
On Thu, 18 Sep 2014, Javier Martinez Canillas wrote:
From: Derek Basehore dbaseh...@chromium.org
Since the i2c bus can get wedged on the EC sometimes, set the number of
retries
to 3. Since we un-wedge the bus immediately after the wedge happens, this is
the
correct fix since only one transfer will fail.
Signed-off-by: Derek Basehore dbaseh...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Wolfram Sang w...@the-dreams.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 3 +++
1 file changed, 3 insertions(+)
Applied, thanks.
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 3c15dcc..97e6369 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
+#define I2C_MAX_RETRIES 3
+
/**
* struct ec_i2c_device - Driver data for I2C tunnel
*
@@ -290,6 +292,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
bus-adap.algo_data = bus;
bus-adap.dev.parent = pdev-dev;
bus-adap.dev.of_node = np;
+ bus-adap.retries = I2C_MAX_RETRIES;
err = i2c_add_adapter(bus-adap);
if (err) {
--
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 v4 2/5] i2c: i2c-cros-ec-tunnel: Set retries to 3
On Mon, 29 Sep 2014, Lee Jones wrote:
On Thu, 18 Sep 2014, Javier Martinez Canillas wrote:
From: Derek Basehore dbaseh...@chromium.org
Since the i2c bus can get wedged on the EC sometimes, set the number of
retries
to 3. Since we un-wedge the bus immediately after the wedge happens, this
is the
correct fix since only one transfer will fail.
Signed-off-by: Derek Basehore dbaseh...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Wolfram Sang w...@the-dreams.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 3 +++
1 file changed, 3 insertions(+)
Applied, thanks.
Wolfram,
Do you want a pull-request?
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 3c15dcc..97e6369 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
+#define I2C_MAX_RETRIES 3
+
/**
* struct ec_i2c_device - Driver data for I2C tunnel
*
@@ -290,6 +292,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
bus-adap.algo_data = bus;
bus-adap.dev.parent = pdev-dev;
bus-adap.dev.of_node = np;
+ bus-adap.retries = I2C_MAX_RETRIES;
err = i2c_add_adapter(bus-adap);
if (err) {
--
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 v4 4/5] mfd: cros_ec: move locking into cros_ec_cmd_xfer
On Thu, 18 Sep 2014, Javier Martinez Canillas wrote:
From: Andrew Bresticker abres...@chromium.org
Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI driver.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v1:
- Remove mention of LPC driver in the commit message since it does not
exist in mainline yet. Suggested by Doug Anderson.
drivers/mfd/cros_ec.c | 10 +-
drivers/mfd/cros_ec_spi.c | 11 ---
2 files changed, 9 insertions(+), 12 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index a9faebd..c53804a 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -65,7 +65,13 @@ EXPORT_SYMBOL(cros_ec_check_result);
int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
- return ec_dev-cmd_xfer(ec_dev, msg);
+ int ret;
+
+ mutex_lock(ec_dev-lock);
+ ret = ec_dev-cmd_xfer(ec_dev, msg);
+ mutex_unlock(ec_dev-lock);
+
+ return ret;
}
EXPORT_SYMBOL(cros_ec_cmd_xfer);
@@ -98,6 +104,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
+ mutex_init(ec_dev-lock);
+
err = mfd_add_devices(dev, 0, cros_devs,
ARRAY_SIZE(cros_devs),
NULL, ec_dev-irq, NULL);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index b396705..bf6e08e 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -79,13 +79,11 @@
* if no record
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
- * @lock: mutex to ensure only one user of cros_ec_cmd_xfer_spi at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
- struct mutex lock;
};
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -232,13 +230,6 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
int sum;
int ret = 0, final_ret;
- /*
- * We have the shared ec_dev buffer plus we do lots of separate spi_sync
- * calls, so we need to make sure only one person is using this at a
- * time.
- */
- mutex_lock(ec_spi-lock);
-
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev-dev, prepared, len=%d\n, len);
@@ -327,7 +318,6 @@ exit:
if (ec_msg-command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
- mutex_unlock(ec_spi-lock);
return ret;
}
@@ -359,7 +349,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi-spi = spi;
- mutex_init(ec_spi-lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
--
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 v4 3/5] mfd: cros_ec: stop calling -cmd_xfer() directly
On Thu, 18 Sep 2014, Javier Martinez Canillas wrote:
From: Andrew Bresticker abres...@chromium.org
Instead of having users of the ChromeOS EC call the interface-specific
cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
to use instead. This will allow us to put all the locking and retry
logic in one place instead of duplicating it across the different
drivers.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 7 +++
include/linux/mfd/cros_ec.h | 24 ++--
4 files changed, 27 insertions(+), 8 deletions(-)
Applied, thanks.
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 97e6369..ec5c38d 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -229,7 +229,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
msg.indata = response;
msg.insize = response_len;
- result = bus-ec-cmd_xfer(bus-ec, msg);
+ result = cros_ec_cmd_xfer(bus-ec, msg);
if (result 0)
goto exit;
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 8c09b3e..462bfcb 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -157,7 +157,7 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb
*ckdev, uint8_t *kb_state)
.insize = ckdev-cols,
};
- return ckdev-ec-cmd_xfer(ckdev-ec, msg);
+ return cros_ec_cmd_xfer(ckdev-ec, msg);
}
static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4873f9c..a9faebd 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -62,6 +62,13 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_check_result);
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ return ec_dev-cmd_xfer(ec_dev, msg);
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
static const struct mfd_cell cros_devs[] = {
{
.name = cros-ec-keyb,
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index fcbe9d1..0e166b9 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -62,10 +62,6 @@ struct cros_ec_command {
* @dev: Device pointer
* @was_wake_device: true if this device was set to wake the system from
* sleep at the last suspend
- * @cmd_xfer: send command to EC and get response
- * Returns the number of bytes received if the communication succeeded,
but
- * that doesn't mean the EC was happy with the command. The caller
- * should check msg.result for the EC's result code.
*
* @priv: Private data
* @irq: Interrupt to use
@@ -82,6 +78,10 @@ struct cros_ec_command {
* @dout_size: size of dout buffer to allocate (zero to use static dout)
* @parent: pointer to parent device (e.g. i2c or spi device)
* @wake_enabled: true if this device can wake the system from sleep
+ * @cmd_xfer: send command to EC and get response
+ * Returns the number of bytes received if the communication succeeded,
but
+ * that doesn't mean the EC was happy with the command. The caller
+ * should check msg.result for the EC's result code.
* @lock: one transaction at a time
*/
struct cros_ec_device {
@@ -92,8 +92,6 @@ struct cros_ec_device {
struct device *dev;
bool was_wake_device;
struct class *cros_class;
- int (*cmd_xfer)(struct cros_ec_device *ec,
- struct cros_ec_command *msg);
/* These are used to implement the platform-specific interface */
void *priv;
@@ -104,6 +102,8 @@ struct cros_ec_device {
int dout_size;
struct device *parent;
bool wake_enabled;
+ int (*cmd_xfer)(struct cros_ec_device *ec,
+ struct cros_ec_command *msg);
struct mutex lock;
};
@@ -153,6 +153,18 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg);
/**
+ * cros_ec_cmd_xfer - Send a command to the ChromeOS EC
+ *
+ * Call this to send a command to the ChromeOS EC. This should be used
+ * instead of calling the EC's cmd_xfer() callback directly.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ */
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg);
+
+/**
* cros_ec_remove - Remove a ChromeOS
[PATCH v2 2/3] clk: samsung: remove unnecessary CONFIG_OF from clk.c
Remove unnecessary CONFIG_OF from samsung/clk.c. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- drivers/clk/samsung/clk.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c index deab84d..31bf391 100644 --- a/drivers/clk/samsung/clk.c +++ b/drivers/clk/samsung/clk.c @@ -281,7 +281,6 @@ void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx, * obtain the clock speed of all external fixed clock sources from device * tree and register it */ -#ifdef CONFIG_OF void __init samsung_clk_of_register_fixed_ext(struct samsung_clk_provider *ctx, struct samsung_fixed_rate_clock *fixed_rate_clk, unsigned int nr_fixed_rate_clk, @@ -298,7 +297,6 @@ void __init samsung_clk_of_register_fixed_ext(struct samsung_clk_provider *ctx, } samsung_clk_register_fixed_rate(ctx, fixed_rate_clk, nr_fixed_rate_clk); } -#endif /* utility function to get the rate of a specified clock */ unsigned long _get_rate(const char *clk_name) -- 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/3] clk: samsung: remove unnecessary inclusion of header files from clk.h
Let's remove unnecessary include of header files from clk.h and add required one in clk.c Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- drivers/clk/samsung/clk.c |3 ++- drivers/clk/samsung/clk.h |4 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c index 31bf391..952f9ec 100644 --- a/drivers/clk/samsung/clk.c +++ b/drivers/clk/samsung/clk.c @@ -11,7 +11,8 @@ * clock framework for Samsung platforms. */ -#include linux/syscore_ops.h +#include linux/of_address.h + #include clk.h void samsung_clk_save(void __iomem *base, diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h index a1ece4a..29a5779 100644 --- a/drivers/clk/samsung/clk.h +++ b/drivers/clk/samsung/clk.h @@ -13,12 +13,8 @@ #ifndef __SAMSUNG_CLK_H #define __SAMSUNG_CLK_H -#include linux/clk.h #include linux/clkdev.h -#include linux/io.h #include linux/clk-provider.h -#include linux/of.h -#include linux/of_address.h #include clk-pll.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 0/3] Some cleanup for samsung clock
This patch series does some cleanup of samsung clock files and fixes one typo in clk.h Changes since v1: - Added patch commit message description to patch 1/3 and 2/3. Pankaj Dubey (3): clk: samsung: Spelling s/bwtween/between/ clk: samsung: remove unnecessary CONFIG_OF from clk.c clk: samsung: remove unnecessary inclusion of header files from clk.h drivers/clk/samsung/clk.c |5 ++--- drivers/clk/samsung/clk.h |6 +- 2 files changed, 3 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related clocks
On Mon, Sep 29, 2014 at 4:22 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi,
On Monday, September 29, 2014 9:07 AM, Kyungmin Park wrote,
To: Pankaj Dubey
Cc: Chanwoo Choi; Kukjin Kim; Russell King - ARM Linux;
naus...@samsung.com;
Tomasz Figa; linux-samsung-soc; robh...@kernel.org; Sylwester Nawrocki;
Mike
Turquette; arm-linux
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
clocks
On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com
wrote:
Hi Chanwoo,
On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
To: Pankaj Dubey
Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org;
kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette;
Sylwester Nawrocki
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3
related
clocks
Hi Pankaj,
On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
missing clock entries for UART2 and UART3.
CC: Mike Turquette mturque...@linaro.org
CC: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 11 +++
include/dt-bindings/clock/exynos3250.h | 10 +-
2 files changed, 20 insertions(+), 1 deletion(-)
Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART
2,3.
As per Exynos3250 user manual that I have with me it supports
UART(0,1,2,3).
It has been mentioned
which UM do you use? There are two UARTs at rev0.01
I am using Rev 2.0.
I received the latest manual from LSI. but it's still v1.40.
Thanks,
Pankaj Dubey
in UART Chapter as well as CMU IP details also mentioned about the
clock entries. We have tested it also on Espresso3250 board which is
based on Exynos3250 SoC.
I can't find it at my UM.
Kyungmin Park
Thanks,
Pankaj Dubey
Thanks,
Chanwoo Choi
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e..0722fef 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
__initdata =
{
MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0,
3),
/* SRC_PERIL0 */
+ MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
12, 4),
+ MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0,
8,
4),
MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0,
4,
4),
MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0,
0,
4),
@@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
__initdata = {
DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
/* DIV_PERIL0 */
+ DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12,
4),
+ DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8,
+ 4),
DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0,
4),
@@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
+ GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
+ GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6
+687,7
@@
static struct samsung_gate_clock gate_clks[] __initdata = {
GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13,
0,
0),
GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
0, 0),
GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0,
0),
+ GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7,
0,
0),
GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6,
0,
0),
GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5,
0,
0),
GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0,
0),
@@
-698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
+ GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0,
0),
+ GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0,
+ 0),
GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
GATE(CLK_UART0, uart0,
[PATCH v6] mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
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.
In case of DT based platforms, 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 keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann a...@arndb.de
Suggested-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
Patch v5 and related discussions can be found here [1].
Change since v5:
- Dropping creation of dummy platform device in of_syscon_register.
- As we are changing syscon to decouple from platform_device, creation of
dummy platform_device does not look good option, and as suggested by Arnd,
I made another attempt so that regmap_mmio_init API should work with NULL
dev pointer itself. Since regmap needs to know about Syscon device node
properties so let's parse device node of syscon in syscon itself for any
such properties and using regmap_config parameter pass all such information
to regmap. Other concern of crashes due to NULL dev pointer in regmap already
addressed in separate patches of regmap. Please see [2] and [3].
Changes since v4:
- Addressed Tomasz Figa's comments for v4.
- Added error handing in of_syscon_register function.
- Using devm_regmap_init_mmio instead of regmap_init_mmio.
Changes since v3:
- Addressed Arnd's comment for v2.
- Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
- For early users created dummy platform device.
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
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.
[1]: https://lkml.org/lkml/2014/9/22/12
[2]: https://lkml.org/lkml/2014/9/18/130
[3]: https://lkml.org/lkml/2014/9/27/2
drivers/mfd/syscon.c | 106 +++---
1 file changed, 84 insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..00a8410 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -15,6 +15,7 @@
#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
@@ -22,31 +23,104 @@
#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 struct regmap_config syscon_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
};
-static int syscon_match_node(struct device *dev, void *data)
+static struct syscon *of_syscon_register(struct device_node *np)
{
- struct device_node *dn = data;
+ struct syscon *syscon;
+ struct regmap *regmap;
+ void __iomem *base;
+
Re: [PATCH v4 2/5] i2c: i2c-cros-ec-tunnel: Set retries to 3
On Mon, Sep 29, 2014 at 08:50:14AM +0100, Lee Jones wrote: On Mon, 29 Sep 2014, Lee Jones wrote: On Thu, 18 Sep 2014, Javier Martinez Canillas wrote: From: Derek Basehore dbaseh...@chromium.org Since the i2c bus can get wedged on the EC sometimes, set the number of retries to 3. Since we un-wedge the bus immediately after the wedge happens, this is the correct fix since only one transfer will fail. Signed-off-by: Derek Basehore dbaseh...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Acked-by: Wolfram Sang w...@the-dreams.de Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/i2c/busses/i2c-cros-ec-tunnel.c | 3 +++ 1 file changed, 3 insertions(+) Applied, thanks. Wolfram, Do you want a pull-request? Nope. All fine, there shouldn't be any conflict. signature.asc Description: Digital signature
Re: [PATCH v6] mfd: syscon: Decouple syscon interface from platform devices
On Monday 29 September 2014 14:17:38 Pankaj Dubey wrote: Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated syscon driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. 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. In case of DT based platforms, 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 keep a list of such syscon objects along with syscon provider device_nodes and regmap handles. For non-DT based platforms, this patch keeps syscon platform driver structure where is can be probed and such non-DT based drivers can use syscon_regmap_lookup_by_pdev API and get access to regmap handles. Once all users of syscon_regmap_lookup_by_pdev migrated to DT based, we can completely remove platform driver of syscon, and keep only helper functions to get regmap handles. Suggested-by: Arnd Bergmann a...@arndb.de Suggested-by: Tomasz Figa tomasz.f...@gmail.com Tested-by: Vivek Gautam gautam.vi...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- Patch v5 and related discussions can be found here [1]. Change since v5: - Dropping creation of dummy platform device in of_syscon_register. - As we are changing syscon to decouple from platform_device, creation of dummy platform_device does not look good option, and as suggested by Arnd, I made another attempt so that regmap_mmio_init API should work with NULL dev pointer itself. Since regmap needs to know about Syscon device node properties so let's parse device node of syscon in syscon itself for any such properties and using regmap_config parameter pass all such information to regmap. Other concern of crashes due to NULL dev pointer in regmap already addressed in separate patches of regmap. Please see [2] and [3]. Reviewed-by: Arnd Bergmann a...@arndb.de Looks good to me, thanks a lot! 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: [PATCHv3 3/4] ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
On 25 September 2014 00:05, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch add exynos3250 compatible string to exynos_cpufreq_matches
for supporting generic cpufreq driver on Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8923d37..1318d69 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -285,6 +285,7 @@ static const struct of_device_id exynos_cpufreq_matches[]
= {
{ .compatible = samsung,exynos5420, .data = arm-bL-cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-cpu0 },
{ .compatible = samsung,exynos4210, .data = cpufreq-cpu0 },
+ { .compatible = samsung,exynos3250, .data = cpufreq-cpu0 },
cpufreq-cpu0 is renamed to cpufreq-dt now.
--
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: [PATCHv3 3/4] ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
On 09/29/2014 06:58 PM, Viresh Kumar wrote:
On 25 September 2014 00:05, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch add exynos3250 compatible string to exynos_cpufreq_matches
for supporting generic cpufreq driver on Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8923d37..1318d69 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -285,6 +285,7 @@ static const struct of_device_id
exynos_cpufreq_matches[] = {
{ .compatible = samsung,exynos5420, .data = arm-bL-cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-cpu0 },
{ .compatible = samsung,exynos4210, .data = cpufreq-cpu0 },
+ { .compatible = samsung,exynos3250, .data = cpufreq-cpu0 },
cpufreq-cpu0 is renamed to cpufreq-dt now.
As you comment, I checked it on following patch. I'll change it.
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/drivers/cpufreq/cpufreq-dt.c?h=linux-nextid=978027e170fbf428ccb1dedcdaa8f1eb7ced97f4
Thanks,
Chanwoo Choi
--
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] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Hi,
On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote:
On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Thanks! Applied for next.
Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC)
detection on Exynos5420 Arndale Octa for me:
[ 10.797979] dwmmc_exynos 1222.mmc: no support for card's volts
[ 10.797998] mmc1: error -22 whilst initialising SD card
Without the patch:
[ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
5000Hz, actual 5000HZ div = 0)
[ 10.866977] mmc1: new high speed SDHC card at address 1234
[ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB
[ 10.915054] mmcblk1: p1 p2 p3
The config is attached (exynos_defconfig doesn't work correctly for
this board yet).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
Kind regards
Uffe
---
changes from v1:
1.Used mmc_regulator_set_ocr() instead of regulator_enable() for
vmmc.
2.Turned on vmmc and vqmmc during MMC_POWER_UP.
3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which
added during the initial version of this patch.
4. Added error message, if it failed to turn on regulator's.
drivers/mmc/host/dw_mmc.c | 72
+---
include/linux/mmc/dw_mmc.h |2 +-
2 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 7f227e9..aadb0d6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -936,6 +936,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -974,12 +975,38 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if (!IS_ERR(mmc-supply.vmmc)) {
+ ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
+ ios-vdd);
+ if (ret) {
+ dev_err(slot-host-dev,
+ failed to enable vmmc
regulator\n);
+ /*return, if failed turn on vmmc*/
+ return;
+ }
+ }
+ if (!IS_ERR(mmc-supply.vqmmc)
!slot-host-vqmmc_enabled) {
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (ret 0)
+ dev_err(slot-host-dev,
+ failed to enable vqmmc
regulator\n);
+ else
+ slot-host-vqmmc_enabled = true;
+ }
set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
regs = mci_readl(slot-host, PWREN);
regs |= (1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, 0);
+
+ if (!IS_ERR(mmc-supply.vqmmc)
slot-host-vqmmc_enabled) {
+ regulator_disable(mmc-supply.vqmmc);
+ slot-host-vqmmc_enabled = false;
+ }
+
regs = mci_readl(slot-host, PWREN);
regs = ~(1 slot-id);
mci_writel(slot-host, PWREN, regs);
@@ -2110,7 +2137,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-f_max = freq[1];
}
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ /*if there are external regulators, get them*/
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret == -EPROBE_DEFER)
+ goto err_setup_bus;
+
+ if (!mmc-ocr_avail)
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
if (host-pdata-caps)
mmc-caps = host-pdata-caps;
@@ -2176,7 +2209,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
err_setup_bus:
mmc_free_host(mmc);
- return -EINVAL;
+ return ret;
}
static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned
Re: [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes
Hi,
On Friday, August 29, 2014 01:43:16 PM Ulf Hansson wrote:
On 25 August 2014 22:59, Doug Anderson diand...@google.com wrote:
Ulf,
On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 22 August 2014 22:38, Doug Anderson diand...@google.com wrote:
Ulf,
On Fri, Aug 22, 2014 at 8:35 AM, Ulf Hansson ulf.hans...@linaro.org
wrote:
On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
From: Doug Anderson diand...@chromium.org
For UHS cards we need the ability to switch voltages from 3.3V to
1.8V. Add support to the dw_mmc driver to handle this. Note that
dw_mmc needs a little bit of extra code since the interface needs a
special bit programmed to the CMD register while CMD11 is progressing.
This means adding a few extra states to the state machine to track.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
changes since v1:
1. Added error message and return error in case of
regulator_set_voltage() fail.
2. changed dw_mci_cmd_interrupt(host,pending |
SDMMC_INT_CMD_DONE)
to dw_mci_cmd_interrupt(host,pending).
3. Removed unnecessary comments.
drivers/mmc/host/dw_mmc.c | 134
+---
drivers/mmc/host/dw_mmc.h |5 +-
include/linux/mmc/dw_mmc.h |2 +
3 files changed, 131 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index aadb0d6..f20b4b8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -29,6 +29,7 @@
#include linux/irq.h
#include linux/mmc/host.h
#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
#include linux/mmc/sdio.h
#include linux/mmc/dw_mmc.h
#include linux/bitops.h
@@ -234,10 +235,13 @@ err:
}
#endif /* defined(CONFIG_DEBUG_FS) */
+static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
+
static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct
mmc_command *cmd)
{
struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci *host = slot-host;
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 cmdr;
cmd-error = -EINPROGRESS;
@@ -253,6 +257,31 @@ static u32 dw_mci_prepare_command(struct mmc_host
*mmc, struct mmc_command *cmd)
else if (cmd-opcode != MMC_SEND_STATUS cmd-data)
cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
+ if (cmd-opcode == SD_SWITCH_VOLTAGE) {
+ u32 clk_en_a;
+
+ /* Special bit makes CMD11 not die */
+ cmdr |= SDMMC_CMD_VOLT_SWITCH;
+
+ /* Change state to continue to handle CMD11 weirdness */
+ WARN_ON(slot-host-state != STATE_SENDING_CMD);
+ slot-host-state = STATE_SENDING_CMD11;
+
+ /*
+* We need to disable clock stop while doing voltage
switch
+* according to Voltage Switch Normal Scenario.
+* It's assumed that by the next time the CLKENA is
updated
+* (when we set the clock next) that the voltage change
will
+* be over, so we don't bother setting any bits to
synchronize
+* with dw_mci_setup_bus().
+*/
I don't know the details about the dw_mmc controller, but normally a
host driver is expected to gate the clock from it's -set_ios
callback, when the clk frequency are set to 0.
Could you elaborate on why dw_mmc can't do that, but need to handle
this from here?
Let's see, it's been a while since I wrote this...
So dw_mmc has a special feature where the controller itself will
automatically stop the MMC Card clock when nothing is going on. This
is called low power mode. I'm not super familiar with other MMC
drivers, I get the impression that this is a special dw_mmc feature
and not common to other controllers. I think other drivers have
aggressive runtime PM to get similar power savings.
I see.
I am familiar with such low power mode features, there are certainly
other controllers supporting such as well. My experience tells me,
it's hard to get things right for all corner cases. The voltage switch
behaviour is just one of these, then you have SDIO irq etc.
Instead of using the controller HW, yes you may implement clock gating
through runtime PM in the host driver.
The dw_mmc auto clock gating can wreck total havoc on the voltage
change procedure, since part of the way that the host and card
communicate is that the host is supposed to stop its clock when it
gets to a certain phase of the voltage switch sequence. If the
controller is stopping the clock for us then it can confuse the card.
The dw_mmc manual says that before starting a voltage
Re: Unable to boot mainline on snow chromebook since 3.15
On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote: On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as. One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware. Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed. As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary). Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :( As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. I posted a patch[0] earlier to do this for the clock framework in that other thread. The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver. Something similar could be done other frameworks. One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about. Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available. Thierry [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/291295.html pgpCIkL4sbREV.pgp
Re: [PATCH v7 0/2] Adds PMU and S2R support for exynos5420
Hi Javier, On Thu, Sep 25, 2014 at 10:45 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: [adding Pankaj Dubey to cc list] Hello Vikas, On Sun, Sep 14, 2014 at 4:57 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Hi All, On Thu, Aug 21, 2014 at 6:29 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Rebased on 1] Kukjin Kim's tree, master branch http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/ 2] Pankaj Dubey's v7 PMU patchset https://lkml.org/lkml/2014/7/9/2 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270655.html The mentioned patches from the PMU series depend on the patch to decouple the syscon interface from syscon drivers. The latest version of that patch is Pankaj's [PATCH v5] mfd: syscon: Decouple syscon interface from platform devices [0]. Since Arnd has given Reviewed-by to Pankaj's MFD syscon patch now, Pankaj can rebase his PMU patchset [1], so that I can re-spin my 5420 S2R patchset on top his PMU patchset. [1] https://lkml.org/lkml/2014/7/9/2 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270655.html There is still an ongoing discussion about the implementation details since errors were reported (debugfs regmap dir failing to be created due a NULL device name) so this won't be a definite version. But I tested that patch on an Exynos5420 Peach Pit and it works so maybe Pankaj can re-spin his PMU series on top of his latest syscon patch so at least the dependencies for your series are sorted and people can try it? Best regards, Javier [0]: https://patchwork.kernel.org/patch/4945481/ Regards Vikas Sajjan -- 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote: On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as. One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware. Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed. As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary). Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :( As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. I posted a patch[0] earlier to do this for the clock framework in that other thread. The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver. Something similar could be done other frameworks. One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about. Agreed Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available. When simplefb is
Re: [PATCH v7 0/2] Adds PMU and S2R support for exynos5420
Hello Vikas, On Mon, Sep 29, 2014 at 2:59 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Hi Javier, On Thu, Sep 25, 2014 at 10:45 PM, Javier Martinez Canillas The mentioned patches from the PMU series depend on the patch to decouple the syscon interface from syscon drivers. The latest version of that patch is Pankaj's [PATCH v5] mfd: syscon: Decouple syscon interface from platform devices [0]. Since Arnd has given Reviewed-by to Pankaj's MFD syscon patch now, Pankaj can rebase his PMU patchset [1], so that I can re-spin my 5420 S2R patchset on top his PMU patchset. Indeed, that would be great. Thanks a lot! Regards Vikas Sajjan Best regards, Javier -- 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 v6] mfd: syscon: Decouple syscon interface from platform devices
Am Montag, 29. September 2014, 14:17:38 schrieb Pankaj Dubey:
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
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.
In case of DT based platforms, 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 keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
we can completely remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann a...@arndb.de
Suggested-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
On Rockchip boards during core clock init (aka before timers)
Tested-by: Heiko Stuebner he...@sntech.de
Except one issue described inline below
Reviewed-by: Heiko Stuebner he...@sntech.de
And I'm really looking forward to having this in the kernel :-)
Thanks for working on this
Heiko
Patch v5 and related discussions can be found here [1].
Change since v5:
- Dropping creation of dummy platform device in of_syscon_register.
- As we are changing syscon to decouple from platform_device, creation of
dummy platform_device does not look good option, and as suggested by
Arnd, I made another attempt so that regmap_mmio_init API should work with
NULL dev pointer itself. Since regmap needs to know about Syscon device
node properties so let's parse device node of syscon in syscon itself for
any such properties and using regmap_config parameter pass all such
information to regmap. Other concern of crashes due to NULL dev pointer in
regmap already addressed in separate patches of regmap. Please see [2] and
[3].
Changes since v4:
- Addressed Tomasz Figa's comments for v4.
- Added error handing in of_syscon_register function.
- Using devm_regmap_init_mmio instead of regmap_init_mmio.
Changes since v3:
- Addressed Arnd's comment for v2.
- Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
- For early users created dummy platform device.
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
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.
[1]: https://lkml.org/lkml/2014/9/22/12
[2]: https://lkml.org/lkml/2014/9/18/130
[3]: https://lkml.org/lkml/2014/9/27/2
drivers/mfd/syscon.c | 106
+++--- 1 file changed, 84
insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..00a8410 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -15,6 +15,7 @@
#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
@@ -22,31 +23,104 @@
#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;
+
Re: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 29, 2014 at 02:12:43PM +0100, Grant Likely wrote: On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available. When simplefb is the only framebuffer to get a platform working, it is reasonable to have a placeholder driver that grabs the resources and nothing else. When a real driver is implemented, and merged, the placeholder driver should drop compatibility with the device node at the same time. I'd thought there was some objection to doing this? It does seem like a sensible approach. signature.asc Description: Digital signature
[GIT PULL] Samsung clock changes for v3.18
The following changes since commit a52ae5a755d980e9ff812c6f45a415ba27bfd33b: Merge branch 'clk-fixes' into clk-next (2014-09-17 11:47:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.18/samsung-clk for you to fetch changes up to fa0111be4ff30150720db3c3e5ee8d7823921639: clk: samsung: exynos4: remove duplicate div_core2 divider clock instantiation (2014-09-24 12:41:33 +0200) Samsung clock patches for v3.18 1) non-critical fixes (without the need to push to stable) fa0111be4ff3 clk: samsung: exynos4: remove duplicate div_core2 divider clock instantiation b511593d7165 clk: samsung: exynos4: fix g3d clocks c14254300131 clk: samsung: exynos4: add missing smmu_g2d clock and update comments 22842d244af3 clk: samsung: exynos5260: fix typo in clock name e82ba578ccde clk: samsung: exynos3250: fix width field of mout_mmc0/1 59037b92f440 clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock 5ce37f266650 clk: samsung: exynos3250: fix mout_cam_blk parent list 2) Clock driver extensions 07ccf02ba5c3 dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU d0e73eaf1925 ARM: dts: exynos3250: Add CMU node for DMC domain clocks e3c3f19bc618 clk: samsung: exynos3250: Register DMC clk provider 4676f0aab9dc clk: samsung: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks Chander Kashyap (1): clk: samsung: exynos5260: fix typo in clock name Krzysztof Kozlowski (3): clk: samsung: exynos3250: Register DMC clk provider ARM: dts: exynos3250: Add CMU node for DMC domain clocks dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU Marek Szyprowski (3): clk: samsung: exynos4: add missing smmu_g2d clock and update comments clk: samsung: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks clk: samsung: exynos4: fix g3d clocks Pankaj Dubey (3): clk: samsung: exynos3250: fix mout_cam_blk parent list clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock clk: samsung: exynos3250: fix width field of mout_mmc0/1 Thomas Abraham (1): clk: samsung: exynos4: remove duplicate div_core2 divider clock instantiation .../devicetree/bindings/clock/exynos3250-clock.txt | 10 +- arch/arm/boot/dts/exynos3250.dtsi | 6 + drivers/clk/samsung/clk-exynos3250.c | 202 - drivers/clk/samsung/clk-exynos4.c | 18 +- drivers/clk/samsung/clk-exynos5260.c | 2 +- include/dt-bindings/clock/exynos3250.h | 27 +++ include/dt-bindings/clock/exynos4.h| 12 +- 7 files changed, 257 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 29, 2014 at 02:57:19PM +0200, Thierry Reding wrote: On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote: On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as. One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware. Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed. As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary). Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :( As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. I posted a patch[0] earlier to do this for the clock framework in that other thread. The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver. Something similar could be done other frameworks. One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about. That's not what has been said. What might happen is this. parent (gate) | +-- clock A (sound) | +-- clock B (display) So. Let's say that at boot, we have parent enabled, and display enabled, and that the display have been setup. We have a sound driver that is going to probe. If at *any* point in time, the sound driver is to disable its clock, the clock framework, since there's no registered user left of the parent clock, will disable the parent clock as well,
Re: [PATCH 1/2 v2] i2c: cros-ec-tunnel: Add of match table
On Fri, Sep 19, 2014 at 10:08:12AM +0200, Sjoerd Simons wrote: To enable the cros-ec-tunnel driver to be auto-loaded when build as a module add an of match table (and export it) to match the modalias information passed on to userspace as the Cros EC MFD driver registers the MFD subdevices with an of_compatibility string. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Applied to for-next, thanks! However, since you are working on this driver: sparse rightfully complains about: drivers/i2c/busses/i2c-cros-ec-tunnel.c:97:44: warning: cast truncates bits from constant value (1 becomes 0) I don't know the EC protocol, can you check? signature.asc Description: Digital signature
[PATCH] ARM: dts: Enable temperature sensor on exynos4412 ODROID
The Exynos4412 has a Thermal Management Unit (TMU) which provides
a temperature sensor and related functionality.
This must be enabled on a per-board basis, as it requires a 100k
resistance to ground on the XtsRES_EXT pin, as well as a 1.8V input on
VDD18_TS pin. If that voltage is not supplied, the machine immediately
reports a maximum temperature of 255C and triggers the thermal subsystem
to shut down the system.
This patch also enables the TMU on the ODROID boards via the appropriate
power supply.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
arch/arm/boot/dts/exynos4412.dtsi | 10 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3d8c623..9994a44 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -400,3 +400,8 @@
samsung,pin-drv = 0;
};
};
+
+tmu {
+ status = okay;
+ vtmu-supply = ldo10_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 0f6ec93..ee58e7f 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -66,4 +66,14 @@
pmu_system_controller: system-controller@1002 {
compatible = samsung,exynos4412-pmu, syscon;
};
+
+ tmu: tmu@100C {
+ compatible = samsung,exynos4412-tmu;
+ interrupt-parent = combiner;
+ reg = 0x100C 0x100;
+ interrupts = 2 4;
+ clocks = clock CLK_TMU_APBIF;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
};
--
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] serial: samsung: Fix serial config dependencies for exynos7
Hi Abhilash, The patch itself seems fine, but I wonder if those config options aren't really just leftovers from the past and couldn't be completely removed. On 29.09.2014 07:16, Abhilash Kesavan wrote: From: Pankaj Dubey pankaj.du...@samsung.com Exynos7 has a similar serial controller to that present in older Samsung SoCs. To re-use the existing serial driver on Exynos7 we need to have SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS selected. This is not possible because these symbols are dependent on PLAT_SAMSUNG which is not present for the ARMv8 based exynos7. Change the dependency of these symbols from PLAT_SAMSUNG to the serial driver thus making it available on exynos7. As the existing platform specific code making use of these symbols is related to uart driver this change in dependency should not cause any issues. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- Build tested with s3c6400_defconfig, exynos_defconfig and arm64's defconfig with and without the serial driver enabled. 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 81f6ee7..e6c0bcb 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -249,14 +249,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 The only place where this symbol is used is below. 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 With this symbol the situation isn't that easy, but still should be manageable. Looking at the serial-samsung driver, all occurrences of CONFIG_SERIAL_SAMSUNG_UARTS could be simply replaced with a locally defined number equal to the maximum value - in this case 4. There are also two places in arch/arm where this symbol is used: 1) In arch/arm/mach-s3c64xx/irq-pm.c it's used as the number of serial ports which need suspend/resume handling. Since on s3c64xx the number is always 4, it can be simply defined locally as a constant. 2) In arch/arm/plat-samsung/init.c it is used to determine size of a static array of UART ports and to check whether the UART driver is enabled. In former case I believe it should be safe to hardcode it to 4 as well, in latter CONFIG_SERIAL_SAMSUNG can be used. 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 v3 3/6] pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts
Hi Abhilash,
Just two minor issues inline. I leave them up to Linus to decide.
Linus, if you don't mind them, feel free to apply this patch with my Ack.
On 29.09.2014 07:15, Abhilash Kesavan wrote:
Exynos7 uses different offsets for wakeup interrupt configuration registers.
So a new irq_chip instance for Exynos7 wakeup interrupts is added. The
irq_chip
selection is now based on the wakeup interrupt controller compatible string.
[snip]
@@ -469,12 +488,18 @@ static int exynos_eint_wkup_init(struct
samsung_pinctrl_drv_data *d)
struct samsung_pin_bank *bank;
struct exynos_weint_data *weint_data;
struct exynos_muxed_weint_data *muxed_data;
+ struct exynos_irq_chip *exynos_wkup_irq_chip;
Quite an awful name for a local variable. irq_chip alone would be enough.
unsigned int muxed_banks = 0;
unsigned int i;
int idx, irq;
for_each_child_of_node(dev-of_node, np) {
- if (of_match_node(exynos_wkup_irq_ids, np)) {
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos_wkup_irq_ids, np);
+ if (match) {
+ exynos_wkup_irq_chip = kmemdup(match-data,
+ sizeof(struct exynos_irq_chip), GFP_KERNEL);
sizeof(*exynos_wkup_irq_chip) (or irq_chip considering my comment above)
could be used instead.
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 v3 0/6] Add initial support for pinctrl on Exynos7
On 29.09.2014 07:15, Abhilash Kesavan wrote: Changes since v1: - Marked the newly created irq_chip instances as __initdata - Used kmemdup to keep a copy of the irq_chip - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM - Moved the pinctrl enablement for exynos7 into a separate patch - Added tested-by and reviewed-by tags from Thomas Abraham Following patches have been tested on linux-next (20140926). https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/ Following patches are required for this series: 1) tty/serial: fix config dependencies for samsung serial https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html 2) dts, kbuild: Implement support for dtb vendor subdirs patchset http://comments.gmane.org/gmane.linux.kbuild.devel/12131 3) arch: arm64: enable support for Samsung Exynos7 SoC patchset (v5) http://www.spinics.net/lists/arm-kernel/msg364014.html Abhilash Kesavan (3): pinctrl: exynos: Generalize the eint16_31 demux code pinctrl: exynos: Consolidate irq domain callbacks pinctrl: exynos: Add irq_chip instance for Exynos7 wakeup interrupts Naveen Krishna Ch (3): pinctrl: exynos: Add initial driver data for Exynos7 arm64: dts: Add initial pinctrl support to EXYNOS7 arm64: exynos: Enable pinctrl support for Exynos7 .../bindings/pinctrl/samsung-pinctrl.txt |3 + arch/arm64/Kconfig |2 + arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi| 560 arch/arm64/boot/dts/exynos/exynos7.dtsi| 66 +++ drivers/pinctrl/samsung/pinctrl-exynos.c | 196 +-- drivers/pinctrl/samsung/pinctrl-exynos.h |3 + drivers/pinctrl/samsung/pinctrl-samsung.c |2 + drivers/pinctrl/samsung/pinctrl-samsung.h |3 + 8 files changed, 799 insertions(+), 36 deletions(-) create mode 100644 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi For patches 1-2, 4-6: Acked-by: Tomasz Figa tomasz.f...@gmail.com Linus, I have replied for patch 3 with 2 minor issues with coding style. If you don't mind them, feel free to take the whole series with my Ack. 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 1/2 v2] i2c: cros-ec-tunnel: Add of match table
Hello Wolfram, On 09/29/2014 10:59 PM, Wolfram Sang wrote: On Fri, Sep 19, 2014 at 10:08:12AM +0200, Sjoerd Simons wrote: To enable the cros-ec-tunnel driver to be auto-loaded when build as a module add an of match table (and export it) to match the modalias information passed on to userspace as the Cros EC MFD driver registers the MFD subdevices with an of_compatibility string. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Applied to for-next, thanks! However, since you are working on this driver: sparse rightfully complains about: drivers/i2c/busses/i2c-cros-ec-tunnel.c:97:44: warning: cast truncates bits from constant value (1 becomes 0) I don't know the EC protocol, can you check? Doug posted a patch [0] to fix the issue you are reporting but it was not picked. I tested that the patch applies on top of linux-next + the latest cros_ec cleanups (that includes a patch for this i2c driver and was taken by Lee. So I think is safe for you take Doug's patch through your tree since it seems to not cause any conflict with the mfd tree. Or if you prefer, I can re-post that patch for 3.19. Best regards, Javier [0]: https://lkml.org/lkml/2014/6/23/830 -- 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 v6] mfd: syscon: Decouple syscon interface from platform devices
Hi,
On Monday, September 29, 2014 9:38 PM, Heiko Stübner wrote,
Am Montag, 29. September 2014, 14:17:38 schrieb Pankaj Dubey:
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
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.
In case of DT based platforms, 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
keep a list of such syscon objects along with syscon provider
device_nodes and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of syscon_regmap_lookup_by_pdev migrated to DT based,
we can completely remove platform driver of syscon, and keep only
helper functions to get regmap handles.
Suggested-by: Arnd Bergmann a...@arndb.de
Suggested-by: Tomasz Figa tomasz.f...@gmail.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
On Rockchip boards during core clock init (aka before timers)
Tested-by: Heiko Stuebner he...@sntech.de
Thanks for testing.
Except one issue described inline below
Reviewed-by: Heiko Stuebner he...@sntech.de
And I'm really looking forward to having this in the kernel :-)
Thanks for working on this
Heiko
[snip]
drivers/mfd/syscon.c | 106
+++--- 1 file
changed, 84
insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index
ca15878..00a8410 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -15,6 +15,7 @@
#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
@@ -22,31 +23,104 @@
#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 struct regmap_config syscon_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
};
-static int syscon_match_node(struct device *dev, void *data)
+static struct syscon *of_syscon_register(struct device_node *np)
{
- struct device_node *dn = data;
+ struct syscon *syscon;
+ struct regmap *regmap;
+ void __iomem *base;
+ int ret;
+ enum regmap_endian endian = REGMAP_ENDIAN_DEFAULT;
+
+ if (!of_device_is_compatible(np, syscon))
+ return ERR_PTR(-EINVAL);
+
+ syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
+ if (!syscon)
+ return ERR_PTR(-ENOMEM);
+
+ base = of_iomap(np, 0);
+ if (!base) {
+ ret = -ENOMEM;
+ goto err_map;
+ }
+
+ /* Parse the device's DT node for an endianness specification */
+ if (of_property_read_bool(np, big-endian))
+ endian = REGMAP_ENDIAN_BIG;
+else if (of_property_read_bool(np, little-endian))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ syscon_regmap_config.val_format_endian = endian;
+
+ regmap = regmap_init_mmio(NULL, base, syscon_regmap_config);
+ if (IS_ERR(regmap)) {
+ pr_err(regmap init failed\n);
+ ret = PTR_ERR(regmap);
+ goto err_regmap;
+ }
+
+ syscon-regmap = regmap;
+ syscon-np = np;
+
+ spin_lock(syscon_list_slock);
+ list_add_tail(syscon-list, syscon_list);
+ spin_unlock(syscon_list_slock);
- return (dev-of_node == dn) ? 1 : 0;
+ /* Change back endianness of syscon_regmap_config.
+* As this is static config in this file and in one system we may
+* have more than one syscon
+*/
+ syscon_regmap_config.val_format_endian =
RE: [PATCH v7 0/2] Adds PMU and S2R support for exynos5420
Hi Javier and Vikas, Hello Vikas, On Mon, Sep 29, 2014 at 2:59 PM, Vikas Sajjan vikas.saj...@samsung.com wrote: Hi Javier, On Thu, Sep 25, 2014 at 10:45 PM, Javier Martinez Canillas The mentioned patches from the PMU series depend on the patch to decouple the syscon interface from syscon drivers. The latest version of that patch is Pankaj's [PATCH v5] mfd: syscon: Decouple syscon interface from platform devices [0]. Since Arnd has given Reviewed-by to Pankaj's MFD syscon patch now, Pankaj can rebase his PMU patchset [1], so that I can re-spin my 5420 S2R patchset on top his PMU patchset. Indeed, that would be great. Thanks a lot! I was waiting for syscon patch to be finalized, now I will rebase my the PMU patches as almost all issues of syscon has been addressed, and I hope it's now ready to be taken in. Thanks, Pankaj Dubey Regards Vikas Sajjan Best regards, Javier -- 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] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Hi
On 09/29/2014 09:31 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Friday, August 29, 2014 01:34:44 PM Ulf Hansson wrote:
On 22 August 2014 15:47, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Thanks! Applied for next.
Unfortunately this patch breaks mmc1 card (Kingston 32GB micro SDHC)
detection on Exynos5420 Arndale Octa for me:
[ 10.797979] dwmmc_exynos 1222.mmc: no support for card's volts
[ 10.797998] mmc1: error -22 whilst initialising SD card
OCR value is not matched. Which values are supported about the mmc_host's value
and card's value?
Could you share the value?
Best Regards,
Jaehoon Chung
Without the patch:
[ 10.866926] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req
5000Hz, actual 5000HZ div = 0)
[ 10.866977] mmc1: new high speed SDHC card at address 1234
[ 10.868730] mmcblk1: mmc1:1234 SA32G 29.3 GiB
[ 10.915054] mmcblk1: p1 p2 p3
The config is attached (exynos_defconfig doesn't work correctly for
this board yet).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
Kind regards
Uffe
---
changes from v1:
1.Used mmc_regulator_set_ocr() instead of regulator_enable() for
vmmc.
2.Turned on vmmc and vqmmc during MMC_POWER_UP.
3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which
added during the initial version of this patch.
4. Added error message, if it failed to turn on regulator's.
drivers/mmc/host/dw_mmc.c | 72
+---
include/linux/mmc/dw_mmc.h |2 +-
2 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 7f227e9..aadb0d6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -936,6 +936,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -974,12 +975,38 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if (!IS_ERR(mmc-supply.vmmc)) {
+ ret = mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
+ ios-vdd);
+ if (ret) {
+ dev_err(slot-host-dev,
+ failed to enable vmmc
regulator\n);
+ /*return, if failed turn on vmmc*/
+ return;
+ }
+ }
+ if (!IS_ERR(mmc-supply.vqmmc)
!slot-host-vqmmc_enabled) {
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (ret 0)
+ dev_err(slot-host-dev,
+ failed to enable vqmmc
regulator\n);
+ else
+ slot-host-vqmmc_enabled = true;
+ }
set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
regs = mci_readl(slot-host, PWREN);
regs |= (1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, 0);
+
+ if (!IS_ERR(mmc-supply.vqmmc)
slot-host-vqmmc_enabled) {
+ regulator_disable(mmc-supply.vqmmc);
+ slot-host-vqmmc_enabled = false;
+ }
+
regs = mci_readl(slot-host, PWREN);
regs = ~(1 slot-id);
mci_writel(slot-host, PWREN, regs);
@@ -2110,7 +2137,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-f_max = freq[1];
}
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ /*if there are external regulators, get them*/
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret == -EPROBE_DEFER)
+ goto err_setup_bus;
+
+ if (!mmc-ocr_avail)
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
if (host-pdata-caps)
mmc-caps = host-pdata-caps;
@@ -2176,7 +2209,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
err_setup_bus:
