Re: [PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
Hello Chanwoo,
On 18 June 2014 07:51, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Changes look good to me.
Reviewed-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..3a5af82 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+ Must be samsung,exynos3250-adc-v2 for
+ for exynos3250 controllers.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
+ From common clock binding: handle to sclk_tsadc clock
+ if using Exynos3250.
- clock-names From common clock binding: Shall be adc.
+ From common clock binding: Shall be sclk_tsadc
+ if using Exynos3250.
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +47,20 @@ adc: adc@12D1 {
vdd-supply = buck5_reg;
};
+Example: adding device info in dtsi file for Exynos3250 with additional sclk
+
+adc: adc@126C {
+ compatible = samsung,exynos3250-adc-v2;
+ reg = 0x126C 0x100, 0x10020718 0x4;
+ interrupts = 0 137 0;
+ #io-channel-cells = 1;
+ io-channel-ranges;
+
+ clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
+ clock-names = adc, sclk_adc;
+
+ vdd-supply = buck5_reg;
+};
Example: Adding child nodes in dts file
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-iio in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: remove display power domain for exynos5420
On 06/17/2014 07:49 AM, Rahul Sharma wrote:
Hi All,
Please review this patch.
Regards,
Rahul Sharma
On 9 June 2014 16:58, Rahul Sharma rahul.sha...@samsung.com wrote:
Display domain is removed due to instability issues. Explaining
the problem below:
exynos_init_late triggers the pm_genpd_poweroff_unused which
powers off the unused power domains. This call hits before
the trigger to deferred probes.
DRM DP Panel defers the probe due to supply get failure. By the
time, deferred probe is scheduled again, Display Power Domain is
powered off by pm_genpd_poweroff_unused.
FIMD and DP drivers are accessing registers during Probe and Bind
callbacks. If display domain is enabled/disabled around register
accesses, display domain gets unstable and we are getting Power
Domain Disable fail notification. Increasing the Timeout also
didn't help.
As I understand the problem is that fimd and dp drivers access hw
registers without enabling power domain. So the proper solution is to
fix these drivers.
Btw. there are already patches removing hw access from probe/bind of
fimd. I guess removing also hw access from dp probe/bind could be a good
solution.
Regards
Andrzej
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
based on Kukjin's for-next branch.
arch/arm/boot/dts/exynos5420.dtsi |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..3d528cf 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -262,11 +262,6 @@
reg = 0x10044060 0x20;
};
- disp_pd: power-domain@100440C0 {
- compatible = samsung,exynos4210-pd;
- reg = 0x100440C0 0x20;
- };
-
msc_pd: power-domain@10044120 {
compatible = samsung,exynos4210-pd;
reg = 0x10044120 0x20;
@@ -518,7 +513,6 @@
};
fimd: fimd@1440 {
- samsung,power-domain = disp_pd;
clocks = clock CLK_SCLK_FIMD1, clock CLK_FIMD1;
clock-names = sclk_fimd, fimd;
};
--
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: [PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
Hi Naveen,
On 06/18/2014 03:12 PM, Naveen Krishna Ch wrote:
Hello Chanwoo,
On 18 June 2014 07:51, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Changes look good to me.
Reviewed-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Thanks for your review.
Best Regards,
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] ARM: dts: remove display power domain for exynos5420
Hi Andrej,
On 18 June 2014 11:46, Andrzej Hajda a.ha...@samsung.com wrote:
On 06/17/2014 07:49 AM, Rahul Sharma wrote:
Hi All,
Please review this patch.
Regards,
Rahul Sharma
On 9 June 2014 16:58, Rahul Sharma rahul.sha...@samsung.com wrote:
Display domain is removed due to instability issues. Explaining
the problem below:
exynos_init_late triggers the pm_genpd_poweroff_unused which
powers off the unused power domains. This call hits before
the trigger to deferred probes.
DRM DP Panel defers the probe due to supply get failure. By the
time, deferred probe is scheduled again, Display Power Domain is
powered off by pm_genpd_poweroff_unused.
FIMD and DP drivers are accessing registers during Probe and Bind
callbacks. If display domain is enabled/disabled around register
accesses, display domain gets unstable and we are getting Power
Domain Disable fail notification. Increasing the Timeout also
didn't help.
As I understand the problem is that fimd and dp drivers access hw
registers without enabling power domain. So the proper solution is to
fix these drivers.
That is also a problem but I fixed those accesses in my local kernel before
hitting this issue. If we do register accesses in FIMD/DP probe/bind we
observes Prefetch abort exception. But here the problem is that 'DP
domain disable' starts failing if we enable/disable multiple times.
Btw. there are already patches removing hw access from probe/bind of
fimd. I guess removing also hw access from dp probe/bind could be a good
solution.
Please let me know the links for posted patches. I will test with those patches.
Regards,
Rahul Sharma
Regards
Andrzej
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
based on Kukjin's for-next branch.
arch/arm/boot/dts/exynos5420.dtsi |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..3d528cf 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -262,11 +262,6 @@
reg = 0x10044060 0x20;
};
- disp_pd: power-domain@100440C0 {
- compatible = samsung,exynos4210-pd;
- reg = 0x100440C0 0x20;
- };
-
msc_pd: power-domain@10044120 {
compatible = samsung,exynos4210-pd;
reg = 0x10044120 0x20;
@@ -518,7 +513,6 @@
};
fimd: fimd@1440 {
- samsung,power-domain = disp_pd;
clocks = clock CLK_SCLK_FIMD1, clock CLK_FIMD1;
clock-names = sclk_fimd, fimd;
};
--
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 10/10] mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
When communicating with the EC, the cmd_xfer() function should return the
number of bytes it received from the EC, or negative on error.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 2 +-
drivers/mfd/cros_ec_spi.c | 2 +-
include/linux/mfd/cros_ec.h | 8
4 files changed, 7 insertions(+), 7 deletions(-)
For the re-spin:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index dd07818..05e033c 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -228,7 +228,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
msg.insize = response_len;
result = bus-ec-cmd_xfer(bus-ec, msg);
- if (result)
+ if (result 0)
goto exit;
result = ec_i2c_parse_response(response, i2c_msgs, num);
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 2276096..dc0ba29 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -120,7 +120,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
goto done;
}
- ret = 0;
+ ret = i2c_msg[1].buf[1];
done:
kfree(in_buf);
kfree(out_buf);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 4d34f1c..beba1bc 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -333,7 +333,7 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
goto exit;
}
- ret = 0;
+ ret = len;
exit:
mutex_unlock(ec_spi-lock);
return ret;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 60c0880..7b65a75 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -41,7 +41,7 @@ enum {
* @outdata: Outgoing data to EC
* @outsize: Outgoing length in bytes
* @indata: Where to put the incoming data from EC
- * @insize: Incoming length in bytes (filled in by EC)
+ * @insize: Max number of bytes to accept from EC
* @result: EC's response to the command (separate from communication
failure)
*/
struct cros_ec_command {
@@ -64,9 +64,9 @@ struct cros_ec_command {
* sleep at the last suspend
* @event_notifier: interrupt event notifier for transport devices
* @cmd_xfer: send command to EC and get response
- * Returns 0 if the communication succeeded, but that doesn't mean the EC
- * was happy with the command it got. Caller should check msg.result for
- * the EC's result code.
+ * 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
--
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 09/10] mfd: cros_ec: Check result code from EC messages
On Tue, 17 Jun 2014, Doug Anderson wrote:
Simon,
On Tue, Jun 17, 2014 at 8:43 PM, Simon Glass s...@chromium.org wrote:
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 09ca789..4d34f1c 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -289,21 +289,23 @@ static int cros_ec_cmd_xfer_spi(struct
cros_ec_device *ec_dev,
goto exit;
}
- /* check response error code */
ptr = ec_dev-din;
- if (ptr[0]) {
- if (ptr[0] == EC_RES_IN_PROGRESS) {
- dev_dbg(ec_dev-dev, command 0x%02x in
progress\n,
- ec_msg-command);
- ret = -EAGAIN;
- goto exit;
- }
- dev_warn(ec_dev-dev, command 0x%02x returned an error
%d\n,
-ec_msg-command, ptr[0]);
- debug_packet(ec_dev-dev, in_err, ptr, len);
- ret = -EINVAL;
+
+ /* check response error code */
+ ec_msg-result = ptr[0];
+ switch (ec_msg-result) {
+ case EC_RES_SUCCESS:
+ break;
+ case EC_RES_IN_PROGRESS:
+ ret = -EAGAIN;
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ ec_msg-command);
goto exit;
+ default:
+ dev_warn(ec_dev-dev, command 0x%02x returned %d\n,
+ec_msg-command, ec_msg-result);
}
Since this code is the same as the above, should it go in a common
function in cros_ec?
So you are thinking it should be written like:
ec_msg-result = ptr[0];
ret = cros_ec_check_result(ec_dev, ec_msg);
if (ret)
goto exit;
---
int cros_ec_check_result(struct cros_ec_device *ec_dev, struct
cros_ec_command *ec_msg)
{
switch (ec_msg-result) {
case EC_RES_SUCCESS:
return 0;
case EC_RES_IN_PROGRESS:
dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
ec_msg-command);
return -EAGAIN;
default:
dev_warn(ec_dev-dev, command 0x%02x returned %d\n,
ec_msg-command, ec_msg-result);
return 0;
}
OK, that seems reasonable. I'll plan to spin tomorrow with that.
+1
I'll do a proper review when you re-spin the patch.
--
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 07/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
struct cros_ec_device has a superfluous name field. We can get all the
debugging info we need from the existing ec_name and phys_name fields, so
let's take out the extra field.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
include/linux/mfd/cros_ec.h | 2 --
4 files changed, 1 insertion(+), 5 deletions(-)
For the re-spin:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 9304056..d242714 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -138,7 +138,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
goto fail_mfd;
}
- dev_info(dev, Chrome EC (%s)\n, ec_dev-name);
+ dev_info(dev, Chrome EC device registered\n);
return 0;
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 37ed12f..5bb32f5 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -132,7 +132,6 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
return -ENOMEM;
i2c_set_clientdata(client, ec_dev);
- ec_dev-name = I2C;
ec_dev-dev = dev;
ec_dev-priv = client;
ec_dev-irq = client-irq;
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 2d713fe..09ca789 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -374,7 +374,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
cros_ec_spi_dt_probe(ec_spi, dev);
spi_set_drvdata(spi, ec_dev);
- ec_dev-name = SPI;
ec_dev-dev = dev;
ec_dev-priv = ec_spi;
ec_dev-irq = spi-irq;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f27c037..2b0c598 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -67,7 +67,6 @@ struct cros_ec_command {
* @command_recv: receive a response
* @command_sendrecv: send a command and receive a response
*
- * @name: Name of this EC interface
* @priv: Private data
* @irq: Interrupt to use
* @din: input buffer (for data from EC)
@@ -104,7 +103,6 @@ struct cros_ec_device {
void *in_buf, int in_len);
/* These are used to implement the platform-specific interface */
- const char *name;
void *priv;
int irq;
uint8_t *din;
--
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 06/10] mfd: cros_ec: Use struct cros_ec_command to communicate with the EC
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
This is some internal structure reorganization / renaming to prepare
for future patches that will add a userspace API to cros_ec. There
should be no visible changes.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 28 ++--
drivers/mfd/cros_ec_i2c.c | 24
drivers/mfd/cros_ec_spi.c | 16
include/linux/mfd/cros_ec.h | 35 ++-
4 files changed, 52 insertions(+), 51 deletions(-)
*/
-struct cros_ec_msg {
- u8 version;
- u8 cmd;
- uint8_t *out_buf;
- int out_len;
- uint8_t *in_buf;
- int in_len;
+struct cros_ec_command {
+ uint32_t version;
+ uint32_t command;
+ uint8_t *outdata;
+ uint32_t outsize;
+ uint8_t *indata;
+ uint32_t insize;
+ uint32_t result;
If you're sure these type changed do not cause you any bother:
Acked-by: Lee Jones lee.jo...@linaro.org
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] mdf: cros_ec: Detect in-progress commands
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Simon Glass s...@chromium.org
Some commands take a while to execute. Use -EAGAIN to signal this to the
caller.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec_spi.c | 6 ++
1 file changed, 6 insertions(+)
For the re-spin:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 52d4d7b..c29a2d7 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -292,6 +292,12 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
/* check response error code */
ptr = ec_dev-din;
if (ptr[0]) {
+ if (ptr[0] == EC_RES_IN_PROGRESS) {
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ ec_msg-cmd);
+ ret = -EAGAIN;
+ goto exit;
+ }
dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
ec_msg-cmd, ptr[0]);
debug_packet(ec_dev-dev, in_err, ptr, len);
--
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 04/10] mfd: cros_ec: Tweak struct cros_ec_device for clarity
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
The members of struct cros_ec_device were improperly commented, and
intermixed the private and public sections. This is just cleanup to make it
more obvious what goes with what.
[dianders: left lock in the structure but gave it the name that will
eventually be used.]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 4 +--
drivers/mfd/cros_ec_spi.c | 10 +++
include/linux/mfd/cros_ec.h | 65
-
4 files changed, 43 insertions(+), 38 deletions(-)
For the re-spin:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index bd6f936..a9eede5 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -57,7 +57,7 @@ static int cros_ec_command_sendrecv(struct cros_ec_device
*ec_dev,
msg.in_buf = in_buf;
msg.in_len = in_len;
- return ec_dev-command_xfer(ec_dev, msg);
+ return ec_dev-cmd_xfer(ec_dev, msg);
}
static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 4f71be9..777e529 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -29,7 +29,7 @@ static inline struct cros_ec_device *to_ec_dev(struct
device *dev)
return i2c_get_clientdata(client);
}
-static int cros_ec_command_xfer(struct cros_ec_device *ec_dev,
+static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
struct cros_ec_msg *msg)
{
struct i2c_client *client = ec_dev-priv;
@@ -136,7 +136,7 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev-dev = dev;
ec_dev-priv = client;
ec_dev-irq = client-irq;
- ec_dev-command_xfer = cros_ec_command_xfer;
+ ec_dev-cmd_xfer = cros_ec_cmd_xfer_i2c;
ec_dev-ec_name = client-name;
ec_dev-phys_name = client-adapter-name;
ec_dev-parent = client-dev;
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 0b8d328..52d4d7b 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -73,7 +73,7 @@
* 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_command_spi_xfer at a time
+ * @lock: mutex to ensure only one user of cros_ec_cmd_xfer_spi at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
@@ -210,13 +210,13 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
}
/**
- * cros_ec_command_spi_xfer - Transfer a message over SPI and receive the
reply
+ * cros_ec_cmd_xfer_spi - Transfer a message over SPI and receive the reply
*
* @ec_dev: ChromeOS EC device
* @ec_msg: Message to transfer
*/
-static int cros_ec_command_spi_xfer(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *ec_msg)
+static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
+ struct cros_ec_msg *ec_msg)
{
struct cros_ec_spi *ec_spi = ec_dev-priv;
struct spi_transfer trans;
@@ -372,7 +372,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev-dev = dev;
ec_dev-priv = ec_spi;
ec_dev-irq = spi-irq;
- ec_dev-command_xfer = cros_ec_command_spi_xfer;
+ ec_dev-cmd_xfer = cros_ec_cmd_xfer_spi;
ec_dev-ec_name = ec_spi-spi-modalias;
ec_dev-phys_name = dev_name(ec_spi-spi-dev);
ec_dev-parent = ec_spi-spi-dev;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2ee3190..79a3585 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -16,7 +16,9 @@
#ifndef __LINUX_MFD_CROS_EC_H
#define __LINUX_MFD_CROS_EC_H
+#include linux/notifier.h
#include linux/mfd/cros_ec_commands.h
+#include linux/mutex.h
/*
* Command interface between EC and AP, for LPC, I2C and SPI interfaces.
@@ -55,34 +57,53 @@ struct cros_ec_msg {
/**
* struct cros_ec_device - Information about a ChromeOS EC device
*
+ * @ec_name: name of EC device (e.g. 'chromeos-ec')
+ * @phys_name: name of physical comms layer (e.g. 'i2c-4')
+ * @dev: Device pointer
+ * @was_wake_device: true if this device was set to wake the system from
+ * sleep at the last suspend
+ * @event_notifier: interrupt event notifier for transport devices
+ * @command_send: send a command
+ * @command_recv: receive a response
+ * @command_sendrecv: send a command and receive a response
+ *
* @name: Name of this EC interface
* @priv: Private data
* @irq: Interrupt to use
- * @din: input buffer (from EC)
- * @dout: output buffer
Re: [PATCH v6 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
On 17 June 2014 20:55, Thomas Abraham thomas...@samsung.com wrote: Changes since v5: - Configuration data for cpu clock block is embedded with the code. The cpu clock logic can later to extended to obtain this data from DT. - Excluded the support for Exynos4x12 SoC since the work on boost OPP bindings is still incomplete. - Included cpufreq support for Exynos5420 SoC. - Many other minor changes (and so dropped Ack's for some of the patches in v5) This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-cpu0 driver for these platforms. This series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq driver. cpuf...@vger.kernel.org list is deprecated now: dec102a, use linux-pm instead. For patch 5 and 6: Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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 03/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
The lower-level driver may want to provide its own buffers. If so,
there's no need to allocate new ones. This already happens to work
just fine (since we check for size of 0 and use devm allocation), but
it's good to document it.
[dianders: Resolved conflicts; documented that no code changes needed
on mainline]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
include/linux/mfd/cros_ec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 7e9fe6e..2ee3190 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -68,8 +68,8 @@ struct cros_ec_msg {
* We use this alignment to keep ARM and x86 happy. Probably word
* alignment would be OK, there might be a small performance advantage
* to using dword.
- * @din_size: size of din buffer
- * @dout_size: size of dout buffer
+ * @din_size: size of din buffer to allocate (zero to use static din)
+ * @dout_size: size of dout buffer to allocate (zero to use static dout)
Why don't these use your new format i.e. doutsize, etc?
* @command_send: send a command
* @command_recv: receive a command
* @ec_name: name of EC device (e.g. 'chromeos-ec')
--
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 02/10] mfd: cros_ec: IRQs for cros_ec should be optional
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
Preparing the way for the LPC device, which is just a plaform_device without
interrupts.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 38fe9bf..bd6f936 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -119,17 +119,15 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
- if (!ec_dev-irq) {
- dev_dbg(dev, no valid IRQ: %d\n, ec_dev-irq);
- return err;
- }
-
- err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-chromeos-ec, ec_dev);
- if (err) {
- dev_err(dev, request irq %d: error %d\n, ec_dev-irq, err);
- return err;
+ if (ec_dev-irq) {
+ err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ chromeos-ec, ec_dev);
Is there anything stopping you using the devm_* version?
+ if (err) {
+ dev_err(dev, request irq %d: error %d\n,
+ ec_dev-irq, err);
+ return err;
+ }
}
err = mfd_add_devices(dev, 0, cros_devs,
@@ -145,7 +143,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return 0;
fail_mfd:
- free_irq(ec_dev-irq, ec_dev);
+ if (ec_dev-irq)
+ free_irq(ec_dev-irq, ec_dev);
return err;
}
@@ -154,7 +153,8 @@ EXPORT_SYMBOL(cros_ec_register);
int cros_ec_remove(struct cros_ec_device *ec_dev)
{
mfd_remove_devices(ec_dev-dev);
- free_irq(ec_dev-irq, ec_dev);
+ if (ec_dev-irq)
+ free_irq(ec_dev-irq, ec_dev);
return 0;
}
--
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: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
Hi Chanwoo,
On 18.06.2014 04:20, Chanwoo Choi wrote:
This patchset add 'exynos_adc_ops' structure which includes some functions
to control ADC operation according to ADC version (v1 or v2).
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 174
+--
1 file changed, 120 insertions(+), 54 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 010578f..c30def6 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -90,6 +90,7 @@ struct exynos_adc {
struct clk *clk;
unsigned intirq;
struct regulator*vdd;
+ struct exynos_adc_ops *ops;
struct completion completion;
@@ -97,6 +98,13 @@ struct exynos_adc {
unsigned intversion;
};
+struct exynos_adc_ops {
+ void (*init_hw)(struct exynos_adc *info);
+ void (*clear_irq)(struct exynos_adc *info);
+ void (*start_conv)(struct exynos_adc *info, unsigned long addr);
+ void (*stop_conv)(struct exynos_adc *info);
+};
+
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
@@ -112,30 +120,98 @@ static inline unsigned int
exynos_adc_get_version(struct platform_device *pdev)
return (unsigned int)match-data;
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
+static void exynos_adc_v1_init_hw(struct exynos_adc *info)
+{
+ u32 con1;
+
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info-regs));
+}
+
+static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long
addr)
+{
+ u32 con1;
+
+ writel(addr, ADC_V1_MUX(info-regs));
+
+ con1 = readl(ADC_V1_CON(info-regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info-regs));
+}
+
+static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
+{
+ writel(1, ADC_V1_INTCLR(info-regs));
+}
+
+static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
+{
+ u32 con;
+
+ con = readl(ADC_V1_CON(info-regs));
+ con |= ADC_V1_CON_STANDBY;
+ writel(con, ADC_V1_CON(info-regs));
+}
+
+static struct exynos_adc_ops exynos_adc_v1_ops = {
+ .init_hw= exynos_adc_v1_init_hw,
+ .clear_irq = exynos_adc_v1_clear_irq,
+ .start_conv = exynos_adc_v1_start_conv,
+ .stop_conv = exynos_adc_v1_stop_conv,
+};
+
+static void exynos_adc_v2_init_hw(struct exynos_adc *info)
{
u32 con1, con2;
- if (info-version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info-regs));
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info-regs));
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info-regs));
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info-regs));
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info-regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info-regs));
+}
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info-regs));
- }
+static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long
addr)
+{
+ u32 con1, con2;
+
+ con2 = readl(ADC_V2_CON2(info-regs));
+ con2 = ~ADC_V2_CON2_ACH_MASK;
+ con2 |= ADC_V2_CON2_ACH_SEL(addr);
+ writel(con2, ADC_V2_CON2(info-regs));
+
+ con1 = readl(ADC_V2_CON1(info-regs));
+ writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info-regs));
+}
+
+static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
+{
+ writel(1, ADC_V2_INT_ST(info-regs));
+}
+
+static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
+{
+ u32 con;
+
+ con = readl(ADC_V2_CON1(info-regs));
+ con = ~ADC_CON_EN_START;
+ writel(con, ADC_V2_CON1(info-regs));
}
+static struct exynos_adc_ops exynos_adc_v2_ops = {
+ .init_hw= exynos_adc_v2_init_hw,
+ .start_conv = exynos_adc_v2_start_conv,
+ .clear_irq = exynos_adc_v2_clear_irq,
+ .stop_conv = exynos_adc_v2_stop_conv,
+};
+
static int exynos_read_raw(struct iio_dev *indio_dev,
Re: [PATCH 01/10] mfd: cros_ec: Fix the comment on cros_ec_remove()
On Mon, 16 Jun 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org This comment was incorrect, so update it. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Simon Glass s...@chromium.org How many people did it take to write this patch? ;) Acked-by: Lee Jones lee.jo...@linaro.org Signed-off-by: Doug Anderson diand...@chromium.org --- include/linux/mfd/cros_ec.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h index 887ef4f..7e9fe6e 100644 --- a/include/linux/mfd/cros_ec.h +++ b/include/linux/mfd/cros_ec.h @@ -148,8 +148,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev, /** * cros_ec_remove - Remove a ChromeOS EC * - * Call this to deregister a ChromeOS EC. After this you should call - * cros_ec_free(). + * Call this to deregister a ChromeOS EC, then clean up any private data. * * @ec_dev: Device to register * @return 0 if ok, -ve on error -- 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 RFC] mfd: syscon: Decouple syscon interface from syscon devices
On Tue, 17 Jun 2014, Tomasz Figa wrote: On 17.06.2014 17:42, Arnd Bergmann wrote: On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote: Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated 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. This patch decouples syscon object from syscon driver, so that it can be registered from any driver in addition to the original syscon platform driver. +1 for this approach. Michal, Pankay, Does it also suit your needs? Signed-off-by: Tomasz Figa t.f...@samsung.com Hi Tomasz, This seems like a reasonable way of solving the problem, but I think there is an even better one that we have about in the past: if we promote syscon from a platform driver into a a drivers/base/ helper that is independent of the platform device matching, we can use call syscon_regmap_lookup_* for any device node, whether it's already bound to a driver or not, which do what you need. It would also make it easier to call the syscon code before the platform_device infrastructure gets initialized, which is something a number of people have asked for, e.g. for using regmap to do SMP bringup or for clock registration. Basically, unless I'm missing your point, this is what my patch does, except that I don't move it to drivers/base/ and the registration function I added require a pointer to struct device. Indeed, decoupling it further from the driver model, by adding of_syscon_register() should be useful for early users. If agreed by Arnd, I think this work can be completed as a subsequent patch. Should I move this to drivers/base/, even though from current location it can be used outside the platform driver anyway? If I'm being honest with myself, I'd say that Syscon wasn't really an MFD driver. I'm happy to keep it in there any continue maintaining it, but wouldn't block a move either. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/10] mfd: Add driver for Maxim 77802 Power Management IC
+config MFD_MAX77802 + tristate Maxim Integrated MAX77802 PMIC Support + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + select IRQ_DOMAIN + help +Say yes here to support for Maxim Integrated MAX77802. +This is a Power Management IC with RTC on chip. +This driver provides common support for accessing the device; +additional drivers must be enabled in order to use the functionality +of the device. + It is a bit unorthodox to put the build infrastructure in the same patch as the DT binding... I thought it was the opposite. That a DT binding document has to be added along with the first user of the binding but I'll separate the DT doc in another patch then if that is the right thing to do. This was the 'old' method, but changed a little over a year ago. Thanks a lot for all your suggestions, I'll wait a little to see if there is more feedback and repost a v3 addressing all the issues you pointed out. Just re-post it. I'll review the next version. -- 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: [PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
Hi Chanwoo,
On 18.06.2014 04:21, Chanwoo Choi wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..3a5af82 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+ Must be samsung,exynos3250-adc-v2 for
+ for exynos3250 controllers.
You might change the last line for:
for controllers compatible with ADC of Exynos3250.
This is to make it also account for possible future SoCs which need
exactly the same handling.
- reg: Contains ADC register address range (base
address and
length) and the address of the phy enable register.
- interrupts:Contains the interrupt information for the
timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
+ From common clock binding: handle to sclk_tsadc clock
+ if using Exynos3250.
This is not clear. It might sound like the sclk_tsadc clock is used on
Exynos3250 and adc on remaining SoCs. I'd write this simply as:
From common clock bindings: handles to clocks specified in clock-names
property, in the same order.
- clock-namesFrom common clock binding: Shall be adc.
+ From common clock binding: Shall be sclk_tsadc
+ if using Exynos3250.
This is also not clear. I'd recommend something like:
From common clock bindings: list of clock input names used by ADC block:
- adc : ADC bus clock,
- sclk_tsadc : ADC special clock (only for Exynos3250 and
compatible ADC blocks).
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: [PATCHv4 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
Hi Chanwoo,
On 18.06.2014 04:21, Chanwoo Choi wrote:
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 6c1fb67..107dc44 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -414,10 +414,10 @@
};
adc: adc@126C {
- compatible = samsung,exynos-adc-v3;
+ compatible = samsung,exynos3250-adc-v2;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
- clock-names = adc, sclk_tsadc;
+ clock-names = adc, sclk_adc;
So, is it sclk_adc or sclk_tsadc? The code uses the former, while
the documentation mentions the latter. Please fix this.
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
[PATCHv2 1/3] clk: samsung: cpu: Add support for cpu clocks of Exynos3250
This patch add support for a new clock type for Exynos3250 CPU clock provider
and modify little difference of DIV_CPU0 between Exynos4 and Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/clk/samsung/clk-cpu.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index c40f7b5..0d5a4d6 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -31,6 +31,10 @@
#define E4210_DIV0_ATB_SHIFT 16
#define E4210_DIV0_ATB_MASK(DIV_MASK E4210_DIV0_ATB_SHIFT)
+#define E3250_CPU_DIV0(apll, pclk_dbg, atb, corem) \
+ (((apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \
+ ((corem) 4))
+
#define E4210_CPU_DIV0(apll, pclk_dbg, atb, periph, corem1, corem0)\
(((apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \
((periph) 12) | ((corem1) 8) | ((corem0) 4))
@@ -50,6 +54,7 @@
(((kpll 24) | (pclk 20) | (aclk 4)))
enum cpuclk_type {
+ EXYNOS3250,
EXYNOS4210,
EXYNOS5250,
EXYNOS5420,
@@ -426,6 +431,20 @@ static int exynos4210_cpuclk_post_rate_change(struct
clk_notifier_data *ndata,
return 0;
}
+static const struct exynos4210_cpuclk_data e3250_armclk_d[] __initconst = {
+ { 100, E3250_CPU_DIV0(1, 7, 4, 1), E4210_CPU_DIV1(7, 7), },
+ { 90, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 80, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 70, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 60, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 50, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 40, E3250_CPU_DIV0(1, 7, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 30, E3250_CPU_DIV0(1, 5, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 20, E3250_CPU_DIV0(1, 3, 3, 1), E4210_CPU_DIV1(7, 7), },
+ { 10, E3250_CPU_DIV0(1, 1, 1, 1), E4210_CPU_DIV1(7, 7), },
+ { 0 },
+};
+
static const struct exynos4210_cpuclk_data e4210_armclk_d[] __initconst = {
{ 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
{ 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
@@ -493,6 +512,16 @@ static const struct exynos4210_cpuclk_data
e5420_kfcclk_d[] __initconst = {
{ 0 },
};
+static const struct exynos_cpuclk_soc_data e3250_clk_soc_data __initconst = {
+ .ops = exynos_cpuclk_clk_ops,
+ .offset = 0x14200,
+ .data = e3250_armclk_d,
+ .data_size = sizeof(e3250_armclk_d),
+ .type = EXYNOS3250,
+ .pre_rate_cb = exynos4210_cpuclk_pre_rate_change,
+ .post_rate_cb = exynos4210_cpuclk_post_rate_change,
+};
+
static const struct exynos_cpuclk_soc_data e4210_clk_soc_data __initconst = {
.ops = exynos_cpuclk_clk_ops,
.offset = 0x14200,
@@ -536,6 +565,8 @@ static const struct exynos_cpuclk_soc_data
e5420_clk_soc_data[] __initconst = {
};
static const struct of_device_id exynos_cpuclk_ids[] __initconst = {
+ { .compatible = samsung,exynos3250-cmu,
+ .data = e3250_clk_soc_data, },
{ .compatible = samsung,exynos4210-clock,
.data = e4210_clk_soc_data, },
{ .compatible = samsung,exynos5250-clock,
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] ARM: dts: Exynos: Add cpu clock table for Exynos3250
This patch add cpu clock table (CPU clock and voltage) to support generic
cpufreq-cpu0 driver for Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index d3777d2..3d3c45b 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -53,6 +53,21 @@
compatible = arm,cortex-a7;
reg = 0;
clock-frequency = 10;
+ clocks = cmu CLK_DIV_CORE2;
+ clock-names = cpu;
+
+ operating-points =
+ 100 115
+ 90 1112500
+ 80 1075000
+ 70 1037500
+ 60 100
+ 50 962500
+ 40 925000
+ 30 887500
+ 20 85
+ 10 85
+ ;
};
cpu1: cpu@1 {
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] cpufreq: Use cpufreq-cpu0 driver for Exynos3250
This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this patchset is based on following patchset[1] by Thomas Abraham. [1] http://www.spinics.net/lists/arm-kernel/msg339392.html Changes from v1: - Rebased on new patchset[1] by Thomas Abraham - Modify clk-cpu.c to support Exynos3250 - Drop documentation patch on previous patchset[2] [2] http://www.spinics.net/lists/cpufreq/msg10265.html - Add only operating-points for Exynos3250 without armclk-divider-table Chanwoo Choi (3): clk: samsung: cpu: Add support for cpu clocks of Exynos3250 clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq ARM: dts: Exynos: Add cpu clock table for Exynos3250 arch/arm/boot/dts/exynos3250.dtsi| 15 +++ drivers/clk/samsung/clk-cpu.c| 31 +++ drivers/clk/samsung/clk-exynos3250.c | 14 ++ 3 files changed, 56 insertions(+), 4 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
Hi Tomasz,
On 06/18/2014 05:37 PM, Tomasz Figa wrote:
Hi Chanwoo,
On 18.06.2014 04:21, Chanwoo Choi wrote:
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 6c1fb67..107dc44 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -414,10 +414,10 @@
};
adc: adc@126C {
-compatible = samsung,exynos-adc-v3;
+compatible = samsung,exynos3250-adc-v2;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
-clock-names = adc, sclk_tsadc;
+clock-names = adc, sclk_adc;
So, is it sclk_adc or sclk_tsadc? The code uses the former, while
the documentation mentions the latter. Please fix this.
OK, I'll fix it by using 'sclk_adc' clock name.
Best Regards,
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: [PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
Hi Tomasz,
On 06/18/2014 05:35 PM, Tomasz Figa wrote:
Hi Chanwoo,
On 18.06.2014 04:21, Chanwoo Choi wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..3a5af82 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+Must be samsung,exynos3250-adc-v2 for
+for exynos3250 controllers.
You might change the last line for:
for controllers compatible with ADC of Exynos3250.
This is to make it also account for possible future SoCs which need
exactly the same handling.
OK, I'll modify it as folloiwng according to your comment:
+Must be samsung,exynos3250-adc-v2 for
+for controllers compatible with ADC of
Exynos3250.
- reg: Contains ADC register address range (base
address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the
timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
- clocksFrom common clock binding: handle to adc clock.
+From common clock binding: handle to sclk_tsadc clock
+if using Exynos3250.
This is not clear. It might sound like the sclk_tsadc clock is used on
Exynos3250 and adc on remaining SoCs. I'd write this simply as:
From common clock bindings: handles to clocks specified in clock-names
property, in the same order.
I'll modify it.
- clock-names From common clock binding: Shall be adc.
+From common clock binding: Shall be sclk_tsadc
+if using Exynos3250.
This is also not clear. I'd recommend something like:
From common clock bindings: list of clock input names used by ADC block:
- adc : ADC bus clock,
- sclk_tsadc : ADC special clock (only for Exynos3250 and
compatible ADC blocks).
I'll modify it.
Best Regards,
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] mfd: cros_ec_spi: set wakeup capability
From: Prathyush K prathyus...@samsung.com Set the device as wakeup capable and register the wakeup source. Note: Though it makes more sense to have the SPI framework do this, (either via device tree or by board_info) this change is as per an existing mail chain: https://lkml.org/lkml/2009/8/27/291 Signed-off-by: Prathyush K prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@chromium.org --- Note that I don't have suspend/resume actually working upstream, but I see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists with this patch and doesn't exist without it. Very well. Applied, thanks. drivers/mfd/cros_ec_spi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 0b8d328..ef22dd5 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -385,6 +385,8 @@ static int cros_ec_spi_probe(struct spi_device *spi) return err; } + device_init_wakeup(spi-dev, true); + return 0; } -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/10] mfd: max77686: Convert to use regmap_irq
Hello Doug,
On 06/17/2014 10:57 PM, Doug Anderson wrote:
Javier,
On Mon, Jun 16, 2014 at 11:02 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
@@ -127,15 +175,48 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
}
i2c_set_clientdata(max77686-rtc, max77686);
- max77686_irq_init(max77686);
+ max77686-rtc_regmap = devm_regmap_init_i2c(max77686-rtc,
+
max77686_rtc_regmap_config);
+ if (IS_ERR(max77686-rtc_regmap)) {
+ ret = PTR_ERR(max77686-rtc_regmap);
+ dev_err(max77686-dev, failed to allocate RTC regmap: %d\n,
+ ret);
+ goto err_unregister_i2c;
+ }
+
+ ret = regmap_add_irq_chip(max77686-regmap, max77686-irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT |
+ IRQF_SHARED, 0, max77686_irq_chip,
+ max77686-irq_data);
+ if (ret != 0) {
+ dev_err(i2c-dev, failed to add PMIC irq chip: %d\n, ret);
+ goto err_unregister_i2c;
+ }
+ ret = regmap_add_irq_chip(max77686-rtc_regmap, max77686-irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT |
+ IRQF_SHARED, 0, max77686_rtc_irq_chip,
+ max77686-rtc_irq_data);
+ if (ret != 0) {
+ dev_err(i2c-dev, failed to add RTC irq chip: %d\n, ret);
+ goto err_del_irqc;
+ }
ret = mfd_add_devices(max77686-dev, -1, max77686_devs,
ARRAY_SIZE(max77686_devs), NULL, 0, NULL);
if (ret 0) {
- mfd_remove_devices(max77686-dev);
- i2c_unregister_device(max77686-rtc);
+ dev_err(i2c-dev, failed to add MFD devices: %d\n, ret);
+ goto err_del_rtc_irqc;
}
+ return 0;
+
+err_del_rtc_irqc:
+ regmap_del_irq_chip(max77686-irq, max77686-rtc_irq_data);
+err_del_irqc:
+ regmap_del_irq_chip(max77686-irq, max77686-irq_data);
I would imagine you either don't need these regmap_del_irq_chip() here
or that you _do_ need them in max77686_i2c_remove().
...from looking at other drivers I think the answer is to add them to
max77686_i2c_remove().
Yes, I forgot to do the regmap irqchip cleanup in the driver .remove function.
The same issue is in the max77802 driver btw so I'll fix both on v3.
Thanks a lot for pointing this out.
diff --git a/include/linux/mfd/max77686-private.h
b/include/linux/mfd/max77686-private.h
index 8c75a9c..3a810b1 100644
--- a/include/linux/mfd/max77686-private.h
+++ b/include/linux/mfd/max77686-private.h
@@ -205,7 +205,7 @@ enum max77686_irq {
MAX77686_PMICIRQ_140C,
MAX77686_PMICIRQ_120C,
- MAX77686_RTCIRQ_RTC60S,
+ MAX77686_RTCIRQ_RTC60S = 0,
MAX77686_RTCIRQ_RTCA1,
MAX77686_RTCIRQ_RTCA2,
MAX77686_RTCIRQ_SMPL,
@@ -215,6 +215,25 @@ enum max77686_irq {
MAX77686_IRQ_NR,
Maybe remove MAX77686_IRQ_NR which no longer makes any sense now that
you start over at 0 partway through.
Right, it is not needed anymore. I'll remove it when re-spin.
Overall this looks good to me, so once nits above are fixed feel to
add my Reviewed-by. I've also built and booted this patch on
exynos5250-snow and tested that the RTC wakealarm fires and can even
wake the system up (with some additional work that I'll email you
about).
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
Great! thanks a lot for testing.
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] devicetree: Add generic IOMMU device tree bindings
On Tue, Jun 17, 2014 at 03:50:25PM +0100, Stuart Yoder wrote: I think for simple masters (i.e. those that have all their StreamIDs under control of one driver), then setting something during attach (or add?) based on the DT could work pretty well. The other case is when we have masters behind a bridge (such as a PCI RC). In this case, it might actually be better to ask the bridge for the IDs and let it sort out the allocation itself. That would also move the RequesterID - StreamID mapping out of the SMMU code. What do you think? The PCI bus iommu group creation code would be part of the SMMU driver (it is handled by other IOMMU drivers as well). My understanding is that there would be one is to one correspondence between the requestor ID and the iommu group. May be, we can have an API provided by the PCI bridge (architecture specific) for setting the stream ID. I think Will is suggesting something along those lines-- I think it's a question of where the streamID allocation happens. You could either do something like the following in the SMMU driver when attaching a PCI device: id = alloc_stream_id(...); pci_set_streamid(pci-dev, id); or id = pci_get_streamid(pci-dev); ...i.e the PCI RC could allocate (from some TBD allocator) and set the stream ID itself. Not sure how big a deal it is to extend PCI RC interfaces for something like that. I think both interfaces have their place; the latter for hotpluggable buses and the former for static allocation (i.e. set once). The only way to see how well it works is to try implementing it, I guess. Will -- 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] clk: s3c64xx: Hookup SPI clocks correctly
In the move to this clock driver the hookups for the SPI clocks were
dropped, which causes my system Cragganmore (s3c6410 based) to be unable
to locate any spibus clocks. This patch adds them back in.
When taking the clock from the epll clock (SCLK) the rates on the SPI
bus are incorrect, this needs further debugging but the hookup here
should be correct and the problem should be else where.
The USBCLK case has been dropped because this requires the USB PHY to be
enabled.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/clk/samsung/clk-s3c64xx.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
index efa16ee..8889ff1c 100644
--- a/drivers/clk/samsung/clk-s3c64xx.c
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -418,8 +418,10 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[]
= {
ALIAS(SCLK_MMC2, s3c-sdhci.2, mmc_busclk.2),
ALIAS(SCLK_MMC1, s3c-sdhci.1, mmc_busclk.2),
ALIAS(SCLK_MMC0, s3c-sdhci.0, mmc_busclk.2),
- ALIAS(SCLK_SPI1, s3c6410-spi.1, spi-bus),
- ALIAS(SCLK_SPI0, s3c6410-spi.0, spi-bus),
+ ALIAS(PCLK_SPI1, s3c6410-spi.1, spi_busclk0),
+ ALIAS(SCLK_SPI1, s3c6410-spi.1, spi_busclk2),
+ ALIAS(PCLK_SPI0, s3c6410-spi.0, spi_busclk0),
+ ALIAS(SCLK_SPI0, s3c6410-spi.0, spi_busclk2),
ALIAS(SCLK_AUDIO1, samsung-pcm.1, audio-bus),
ALIAS(SCLK_AUDIO1, samsung-i2s.1, audio-bus),
ALIAS(SCLK_AUDIO0, samsung-pcm.0, audio-bus),
--
1.7.2.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
MMC regression with linux-next on Exynos5250
Hi Jaehoon,
I get the below crash on Exyos5250 based Arndale board with linux-next
(20140618) kernel.
Looks like the following patch is causing it
Commit da118915cc72 mmc: dw_mmc: replace disable-wp from slot's
quirk to host's quirk
Reverting the above patch fixes the issue.
The below changes in dts file also did not help.
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f50d15b..617fc5fe50f7 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -422,6 +422,7 @@
num-slots = 1;
supports-highspeed;
card-detect-delay = 200;
+ disable-wp;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
@@ -432,7 +433,6 @@
slot@0 {
reg = 0;
bus-width = 4;
- disable-wp;
};
};
Please check.
-- [2.043665] mmc_host mmc0: Bus speed (slot 0) = 1Hz
(slot req 5200Hz, actual 5000HZ div = 1)
[2.044300] Waiting for root device /dev/mmcblk1p3...
[2.058350] mmc0: new DDR MMC card at address 0001
[2.063256] mmcblk0: mmc0:0001 M4G1FA 3.72 GiB
[2.067633] mmcblk0boot0: mmc0:0001 M4G1FA partition 1 1.00 MiB
[2.073531] mmcblk0boot1: mmc0:0001 M4G1FA partition 2 1.00 MiB
[2.079433] mmcblk0rpmb: mmc0:0001 M4G1FA partition 3 128 KiB
[2.086554] mmcblk0: p1 p2 p3 p4
[2.089706] mmcblk0boot1: unknown partition table
[2.093953] mmcblk0boot0: unknown partition table
[2.098345] platform 122f.sata: Driver ahci requests probe deferral
[2.172280] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[2.180563] mmc1: new high speed SDHC card at address
[2.186220] mmcblk1: mmc1: SU04G 3.69 GiB (ro)
[2.192336] mmcblk1: p1 p2 p3
[2.194654] platform 122f.sata: Driver ahci requests probe deferral
[2.250761] VFS: Cannot open root device mmcblk1p3 or
unknown-block(179,67): error -30
[2.257452] Please append a correct root= boot option; here are
the available partitions:
[2.265787] b300 3907584 mmcblk0 driver: mmcblk
[2.271059] b301 2352800 mmcblk0p1 -01
[2.276312] b302 507872 mmcblk0p2 -02
[2.281606] b303 507840 mmcblk0p3 -03
[2.286899] b304 507840 mmcblk0p4 -04
[2.292206] b330 128 mmcblk0rpmb (driver?)
[2.297406] b3201024 mmcblk0boot1 (driver?)
[2.302700] b3101024 mmcblk0boot0 (driver?)
[2.307994] b340 3872256 mmcblk1 driver: mmcblk
[2.313289] b3414095 mmcblk1p1 0005ac11-01
[2.318582] b342 53248 mmcblk1p2 0005ac11-02
[2.323876] b343 3814912 mmcblk1p3 0005ac11-03
[2.329174] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(179,67)
[2.337696] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.16.0-rc1-next-20140618-00048-g868c90fe6c88 #2106
[2.347186] [c0216130] (unwind_backtrace) from [c0211ccc]
(show_stack+0x10/0x14)
[2.354895] [c0211ccc] (show_stack) from [c0822420]
(dump_stack+0x8c/0x9c)
[2.362090] [c0822420] (dump_stack) from [c0821b80] (panic+0xa4/0x21c)
[2.368950] [c0821b80] (panic) from [c0ae50d4]
(mount_block_root+0x1a0/0x230)
[2.376415] [c0ae50d4] (mount_block_root) from [c0ae526c]
(mount_root+0x108/0x110)
[2.384313] [c0ae526c] (mount_root) from [c0ae53cc]
(prepare_namespace+0x158/0x19c)
[2.392301] [c0ae53cc] (prepare_namespace) from [c0ae4d90]
(kernel_init_freeable+0x1cc/0x1dc)
[2.401159] [c0ae4d90] (kernel_init_freeable) from [c081fed4]
(kernel_init+0xc/0xe8)
[2.409229] [c081fed4] (kernel_init) from [c020e838]
(ret_from_fork+0x14/0x3c)
[2.416770] CPU1: stopping
[2.419453] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.16.0-rc1-next-20140618-00048-g868c90fe6c88 #2106
[2.428948] [c0216130] (unwind_backtrace) from [c0211ccc]
(show_stack+0x10/0x14)
[2.436660] [c0211ccc] (show_stack) from [c0822420]
(dump_stack+0x8c/0x9c)
[2.443856] [c0822420] (dump_stack) from [c02149ac]
(handle_IPI+0x150/0x170)
[2.451233] [c02149ac] (handle_IPI) from [c0208910]
(gic_handle_irq+0x64/0x68)
[2.458781] [c0208910] (gic_handle_irq) from [c0212840]
(__irq_svc+0x40/0x50)
[2.466239] Exception stack(0xe989ff90 to 0xe989ffd8)
[2.471268] ff80: ffed
ffed c021f6c0
[2.479438] ffa0: e989e020 c0b94458 c0b944c4
e989e000 c082ef44 c0b88da8
[2.487594] ffc0: c0b95858 e989ffd8 c020f374 c020f378 6113
[2.494195] [c0212840] (__irq_svc) from [c020f378]
(arch_cpu_idle+0x38/0x3c)
[2.501587] [c020f378] (arch_cpu_idle) from [c027d7e4]
(cpu_startup_entry+0x1e8/0x23c
Re: [PATCH 1/4] clk: propagate parent change up one level
Hi Mike,
Do you have any comments about this patch?
The patch is needed to provide a clean fix for recently
broken support for HDMI on Exynos4210 SoC in mainline.
Regards,
Tomasz Stanislawski
On 05/01/2014 12:19 AM, Tomasz Figa wrote:
Mike,
On 08.04.2014 17:45, Tomasz Figa wrote:
Hi,
On 04.04.2014 16:53, Tomasz Stanislawski wrote:
This patch adds support for propagation of setup of clock's parent one
level
up.
This feature is helpful when a driver changes topology of its clocks
using
clk_set_parent(). The problem occurs when on one platform/SoC
driver's clock
is located at MUX output but on the other platform/SoC there is a
gated proxy
clock between the MUX and driver's clock. In such a case, driver's
code has to
be modified to use one clock for enabling and the other clock for
setup of a
parent.
The code updates are avoided by propagating setup of a parent up one
level.
Additionally, this patch adds CLK_SET_PARENT_PARENT (sorry for naming)
flag to
inform clk-core that clk_set_parent() should be propagated.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/clk/clk.c|6 ++
include/linux/clk-provider.h |1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373..53bbfda 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1737,6 +1737,12 @@ int clk_set_parent(struct clk *clk, struct clk
*parent)
/* try finding the new parent index */
if (parent) {
+if ((clk-flags CLK_SET_PARENT_PARENT)
+ clk-num_parents == 1) {
+ret = clk_set_parent(clk-parent, parent);
+goto out;
+}
+
p_index = clk_fetch_parent_index(clk, parent);
p_rate = parent-rate;
if (p_index 0) {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5119174..daa0b03 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -30,6 +30,7 @@
#define CLK_GET_RATE_NOCACHEBIT(6) /* do not use the cached clk
rate */
#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate
change */
#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk
accuracy */
+#define CLK_SET_PARENT_PARENTBIT(9) /* propagate parent change up
one level */
struct clk_hw;
struct dentry;
This would be very useful, at least on Exynos platforms, with
mux-div-gate clock paths. PARENT_PARENT sounds a bit funny, though.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Your opinion on this would be greatly appreciated.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote: On Tue, Jun 17, 2014 at 01:18:11PM +0100, Will Deacon wrote: On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote: On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote: On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote: It can easily be argued that if the algorithm used to remap the ID varies, the compatibility of the device changes. Therefore I would expect any variant of the GICv3 that deviates from the standard mapping (if there is such a thing) to have its own compatible string. There is no standard mapping; it's a property defined at system integration time. I fully expect different SoCs to do different things here. My point was that the mapping itself seems to be fundamental enough to make devices with different mappings incompatible. Therefore I think this could probably be handled by using different compatible values, something along the lines of this: compatible = vendor,soc-gicv3, arm,gicv3; Then the mapping can be described in code, which should be a whole lot easier and more flexible than a more or less generic notation in device tree. I don't think that scales well beyond a handful of unique mappings, and I really anticipate everybody doing something different based on their integration constraints. You'd very quickly end up with sets of tables for each SoC, describing the topology and associated IDs in the kernel source, which feels like a giant step backwards from where we are today with device tree. Well, today we don't have a generic binding at all, so anything will really be a giant step forward in my opinion. Oh, I'm not disputing that at all. I just think it's worth considering how we can extend the binding in future to describe some of the ID routing and remapping that we've discussed. But seriously, from what you said earlier I got the impression that some of the mappings may not be easy or possible to represent in DT, which is why I proposed to encode it into the compatible property so that it can be handled in code instead. For any old arbitrary mappings, we're going to have a rough time, but that doesn't mean we need to support that until we're forced to (and then we can consider our options). What I *do* think we need to describe is: - Each master has a set of fixed StreamIDs - StreamIDs can be remastered by adding a constant offset (this could also be used to describe RequesterID - StreamID mapping) I'd hope this would be sufficient for most people. Dynamic ID assignment can be worked out later (I'm not even sure it belongs in this binding) and any mappings other than `add a constant offset' can be treated on a case-by-case basis. We don't want to throw the kitchen sink at a language for describing arbitrary transformations! We've had similar discussions before (power sequences anyone?) where we tried to come up with a generic way to describe something in device tree that just didn't work out too well. Some things are better done in code, so I think we should at least consider that possibility rather than blindly try and force everything into device tree. If we can support 90% of SoCs with a simple DT-based description, we can address the corner cases as they arise. I'm not ruling our hardcoding topology if we have no choice, but I don't think that's a healthy place to start from. Will -- 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: MMC regression with linux-next on Exynos5250
Hi Jaehoon, On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Sachin. Did you check the below patch? https://patchwork.kernel.org/patch/4346781/ Thanks for the patch. But even with this patch, I continue to get the aforementioned crash. I will resend the patch after including the ARM soc mailing. dw-mmc controller used the mmc_of_parse(), but it can't parse the sub-node. After checking it, let me know your result, plz. Regards, Sachin. -- 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: MMC regression with linux-next on Exynos5250
On 18 June 2014 13:10, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Jaehoon, On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Sachin. Did you check the below patch? https://patchwork.kernel.org/patch/4346781/ Thanks for the patch. But even with this patch, I continue to get the aforementioned crash. Hi Sachin / Jaehoon, Until we sorted out the problem, I will drop the related patch from my mmc tree. Kind regards Uffe -- 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: MMC regression with linux-next on Exynos5250
Hi Ulf, On Wed, Jun 18, 2014 at 4:43 PM, Ulf Hansson ulf.hans...@linaro.org wrote: On 18 June 2014 13:10, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Jaehoon, On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Sachin. Did you check the below patch? https://patchwork.kernel.org/patch/4346781/ Thanks for the patch. But even with this patch, I continue to get the aforementioned crash. Hi Sachin / Jaehoon, Until we sorted out the problem, I will drop the related patch from my mmc tree. OK. Also, I feel the mmc patch and the corresponding DT changes should go through single tree to avoid dependency issues. Regards, Sachin. -- 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] clocksource: exynos-mct: Register the timer for stable udelay
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This change
have been tested on exynos5420 based board.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 8d64200..57cb3dc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+ return exynos4_frc_read(mct_frc);
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
+ exynos4_delay_timer.read_current_timer = exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(exynos4_delay_timer);
+
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
--
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
MMC error on Exynos4210 board
Hi Tim, I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 mmc: sdhci: Use mmc core regulator infrastucture Any ideas? *** -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.180281] Synopsys Designware Multimedia Card Interface Driver [2.188131] usbcore: registered new interface driver usbhid [2.192287] usbhid: USB HID core driver [2.196329] TCP: cubic registered [2.199362] NET: Registered protocol family 17 [2.203917] NET: Registered protocol family 15 [2.208404] Registering SWP/SWPB emulation handler [2.214357] of_get_named_gpiod_flags exited with status 0 [2.218430] of_get_named_gpiod_flags exited with status 0 [2.223803] of_get_named_gpiod_flags exited with status 0 [2.229170] of_get_named_gpiod_flags exited with status 0 [2.234560] of_get_named_gpiod_flags exited with status 0 [2.239953] gpio-229: gpiod_set_debounce: missing set() or set_debounce() operations [2.247773] gpio-230: gpiod_set_debounce: missing set() or set_debounce() operations [2.255473] gpio-228: gpiod_set_debounce: missing set() or set_debounce() operations [2.263221] gpio-227: gpiod_set_debounce: missing set() or set_debounce() operations [2.270918] gpio-226: gpiod_set_debounce: missing set() or set_debounce() operations [2.278899] input: gpio_keys as /devices/gpio_keys/input/input0 [2.285196] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.295072] VDD_G3D_1.1V: disabling [2.304744] VADC_3.3V: disabling [2.312095] VDD_AUD_1.8V: disabling [2.319714] VMIPI_1.1V: disabling [2.327193] VDD_ABB_3.3V: disabling [2.332779] VMEM_VDD_2.8V: disabling [2.336148] Waiting for root device /dev/mmcblk0p1... * Regards, Sachin. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] drm/exynos: fix for misc issues related to exynos mixer
Fixes for various issues which are to Power On/Off sequence, Layer update, waiting for vblank in exynos mixer driver. This series is based on exynos-drm-fixes branch in Inki dae's tree. Rahul Sharma (5): drm/exynos: set power state variable after enabling clocks and power drm/exynos: stop mixer before gating clocks during poweroff drm/exynos: allow mulitple layer updates per vsync for mixer drm/exynos: soft reset mixer before reconfigure after power-on drm/exynos: enable vsync interrupt while waiting for vblank drivers/gpu/drm/exynos/exynos_mixer.c | 50 +++-- drivers/gpu/drm/exynos/regs-mixer.h |1 + 2 files changed, 36 insertions(+), 15 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
[PATCH 1/5] drm/exynos: set power state variable after enabling clocks and power
Power state variable holds the state of the mixer device.
Power on and power off functions are toggling these variable
at wrong place.
State variable should be changed to true only after Runtime
PM and clocks are enabled. Else it may result to a situation
where mixer registers are accessed with device power enabled.
Similar logic for poweroff sequence.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c5aed7..c00abbe 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1061,7 +1061,7 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
mutex_unlock(ctx-mixer_mutex);
return;
}
- ctx-powered = true;
+
mutex_unlock(ctx-mixer_mutex);
pm_runtime_get_sync(ctx-dev);
@@ -1072,6 +1072,10 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
clk_prepare_enable(res-sclk_mixer);
}
+ mutex_lock(ctx-mixer_mutex);
+ ctx-powered = true;
+ mutex_unlock(ctx-mixer_mutex);
+
mixer_reg_write(res, MXR_INT_EN, ctx-int_en);
mixer_win_reset(ctx);
@@ -1084,14 +1088,20 @@ static void mixer_poweroff(struct exynos_drm_manager
*mgr)
struct mixer_resources *res = ctx-mixer_res;
mutex_lock(ctx-mixer_mutex);
- if (!ctx-powered)
- goto out;
+ if (!ctx-powered) {
+ mutex_unlock(ctx-mixer_mutex);
+ return;
+ }
mutex_unlock(ctx-mixer_mutex);
mixer_window_suspend(mgr);
ctx-int_en = mixer_reg_read(res, MXR_INT_EN);
+ mutex_lock(ctx-mixer_mutex);
+ ctx-powered = false;
+ mutex_unlock(ctx-mixer_mutex);
+
clk_disable_unprepare(res-mixer);
if (ctx-vp_enabled) {
clk_disable_unprepare(res-vp);
@@ -1099,12 +1109,6 @@ static void mixer_poweroff(struct exynos_drm_manager
*mgr)
}
pm_runtime_put_sync(ctx-dev);
-
- mutex_lock(ctx-mixer_mutex);
- ctx-powered = false;
-
-out:
- mutex_unlock(ctx-mixer_mutex);
}
static void mixer_dpms(struct exynos_drm_manager *mgr, int mode)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] drm/exynos: stop mixer before gating clocks during poweroff
Mixer should be power gated only after it is gracefully stopped.
The recommended sequence is to Stop the mixer and wait till
it enters to IDLE state before gating the clocks and power to
the mixer.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 15 +++
drivers/gpu/drm/exynos/regs-mixer.h |1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c00abbe..d359501 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -377,6 +377,20 @@ static void mixer_run(struct mixer_context *ctx)
mixer_regs_dump(ctx);
}
+static void mixer_stop(struct mixer_context *ctx)
+{
+ struct mixer_resources *res = ctx-mixer_res;
+ int timeout = 20;
+
+ mixer_reg_writemask(res, MXR_STATUS, 0, MXR_STATUS_REG_RUN);
+
+ while (!(mixer_reg_read(res, MXR_STATUS) MXR_STATUS_REG_IDLE)
+ --timeout)
+ usleep_range(1, 12000);
+
+ mixer_regs_dump(ctx);
+}
+
static void vp_video_buffer(struct mixer_context *ctx, int win)
{
struct mixer_resources *res = ctx-mixer_res;
@@ -1094,6 +1108,7 @@ static void mixer_poweroff(struct exynos_drm_manager *mgr)
}
mutex_unlock(ctx-mixer_mutex);
+ mixer_stop(ctx);
mixer_window_suspend(mgr);
ctx-int_en = mixer_reg_read(res, MXR_INT_EN);
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index 4537026..5f32e1a 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -78,6 +78,7 @@
#define MXR_STATUS_BIG_ENDIAN (1 3)
#define MXR_STATUS_ENDIAN_MASK (1 3)
#define MXR_STATUS_SYNC_ENABLE (1 2)
+#define MXR_STATUS_REG_IDLE(1 1)
#define MXR_STATUS_REG_RUN (1 0)
/* bits for MXR_CFG */
--
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 3/5] drm/exynos: allow mulitple layer updates per vsync for mixer
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, int
win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = ctx-mixer_res;
- u32 val;
-
- val = mixer_reg_read(res, MXR_CFG);
- /* allow one update per vsync only */
- if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
- mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+ mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
}
static void mixer_graph_buffer(struct mixer_context *ctx, int win)
--
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 4/5] drm/exynos: soft reset mixer before reconfigure after power-on
Mixer soft reset is a recommended step before reconfiguring the mixer after power on. Mixer looses the previous state of DMAs if soft reset. This is the recommendation from the hardware team. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- drivers/gpu/drm/exynos/exynos_mixer.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 6773b03..6f18581 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1085,6 +1085,8 @@ static void mixer_poweron(struct exynos_drm_manager *mgr) ctx-powered = true; mutex_unlock(ctx-mixer_mutex); + mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET); + mixer_reg_write(res, MXR_INT_EN, ctx-int_en); mixer_win_reset(ctx); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] drm/exynos: enable vsync interrupt while waiting for vblank
mixer_wait_for_vblank function expects that the upcoming vsync interrupt handler routine will clear the wait_vsync_event atomic variable. For this to happen, interrupts should be enabled and disabled properly. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- drivers/gpu/drm/exynos/exynos_mixer.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 6f18581..7927f2e 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1019,6 +1019,8 @@ static void mixer_wait_for_vblank(struct exynos_drm_manager *mgr) } mutex_unlock(mixer_ctx-mixer_mutex); + mixer_enable_vblank(mgr); + atomic_set(mixer_ctx-wait_vsync_event, 1); /* @@ -1029,6 +1031,8 @@ static void mixer_wait_for_vblank(struct exynos_drm_manager *mgr) !atomic_read(mixer_ctx-wait_vsync_event), HZ/20)) DRM_DEBUG_KMS(vblank wait timed out.\n); + + mixer_disable_vblank(mgr); } static void mixer_window_suspend(struct exynos_drm_manager *mgr) -- 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 RFC] mfd: syscon: Decouple syscon interface from syscon devices
On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote: On 17.06.2014 17:42, Arnd Bergmann wrote: This seems like a reasonable way of solving the problem, but I think there is an even better one that we have about in the past: if we promote syscon from a platform driver into a a drivers/base/ helper that is independent of the platform device matching, we can use call syscon_regmap_lookup_* for any device node, whether it's already bound to a driver or not, which do what you need. It would also make it easier to call the syscon code before the platform_device infrastructure gets initialized, which is something a number of people have asked for, e.g. for using regmap to do SMP bringup or for clock registration. Basically, unless I'm missing your point, this is what my patch does, except that I don't move it to drivers/base/ and the registration function I added require a pointer to struct device. Indeed, decoupling it further from the driver model, by adding of_syscon_register() should be useful for early users. I believe the part you are missing is that with the approach I suggested, there would be no registration function at all. You can easily do the lookup from the client drivers using the DT data structures, with no need for the device at all. The only exception today is the clps711x platform using syscon_regmap_lookup_by_pdevname(), but that should be solved in 3.17 when clps711x becomes DT-only. Should I move this to drivers/base/, even though from current location it can be used outside the platform driver anyway? Thinking about it some more, drivers/of might be better than drivers/base. It depends a bit where we are heading with this, in particular if we expect to see non-DT users in the future. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: defer hdmi probe when fail to get regulators
HDMI probe proceeds with dummy regulators when the regulators
are not provided in DT node or regulator provider has not get
probed or failed to register the regulators.
This patch modify hdmi driver to defer the probe in case the
regulators are not available.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on exynos-drm-fixes branch in Inki dae's tree.
drivers/gpu/drm/exynos/exynos_hdmi.c | 69 --
1 file changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0..3f24c49 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -83,7 +83,7 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
- struct regulator_bulk_data *regul_bulk;
+ struct regulator**regulators;
int regul_count;
};
@@ -2022,6 +2022,36 @@ static void hdmi_commit(struct exynos_drm_display
*display)
hdmi_conf_apply(hdata);
}
+int hdmi_regulator_enable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_enable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to enable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+int hdmi_regulator_disable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_disable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to disable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
static void hdmi_poweron(struct exynos_drm_display *display)
{
struct hdmi_context *hdata = display-ctx;
@@ -2039,8 +2069,8 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
pm_runtime_get_sync(hdata-dev);
- if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
- DRM_DEBUG_KMS(failed to enable regulator bulk\n);
+ if (hdmi_regulator_enable(hdata))
+ DRM_DEBUG_KMS(failed to enable regulators\n);
/* set pmu hdmiphy control bit to enable hdmiphy */
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
@@ -2077,7 +2107,8 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
- regulator_bulk_disable(res-regul_count, res-regul_bulk);
+ if (hdmi_regulator_disable(hdata))
+ DRM_DEBUG_KMS(failed to disable regulators\n);
pm_runtime_put_sync(hdata-dev);
@@ -2211,24 +2242,24 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
clk_set_parent(res-mout_hdmi, res-sclk_pixel);
- res-regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
- sizeof(res-regul_bulk[0]), GFP_KERNEL);
- if (!res-regul_bulk) {
- ret = -ENOMEM;
- goto fail;
- }
+ res-regul_count = ARRAY_SIZE(supply);
+
+ res-regulators = devm_kzalloc(dev, res-regul_count *
+ sizeof(res-regulators[0]), GFP_KERNEL);
+ if (!res-regulators)
+ return -ENOMEM;
+
for (i = 0; i ARRAY_SIZE(supply); ++i) {
- res-regul_bulk[i].supply = supply[i];
- res-regul_bulk[i].consumer = NULL;
- }
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), res-regul_bulk);
- if (ret) {
- DRM_ERROR(failed to get regulators\n);
- return ret;
+ res-regulators[i] =
+ devm_regulator_get_optional(dev, supply[i]);
+ if (IS_ERR(res-regulators[i])) {
+ DRM_ERROR(fail to get regulator: %s.\n,
+ supply[i]);
+ return -EPROBE_DEFER;
+ }
}
- res-regul_count = ARRAY_SIZE(supply);
- return ret;
+ return 0;
fail:
DRM_ERROR(HDMI resource init - failed\n);
return ret;
--
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] ARM: dts: add hdmi regulators for exynos5420 based peach-pit board
Adding regulators for hdmi for peach-pit board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on for-next branch in Kukjin's tree.
Dependent on:
1) PMIC DT patch at http://www.gossamer-threads.com/lists/linux/kernel/1945703
2) tps65090 DT patch at https://lkml.org/lkml/2014/6/13/483
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9..0a6a1cb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -229,6 +229,11 @@
pinctrl-names = default;
pinctrl-0 = hdmi_hpd_irq;
ddc = i2c_2;
+
+ hdmi-en-supply = tps65090_fet7;
+ vdd-supply = ldo8_reg;
+ vdd_osc-supply = ldo10_reg;
+ vdd_pll-supply = ldo8_reg;
};
usbdrd_phy0 {
--
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 v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators
On Wed, 18 Jun 2014, Javier Martinez Canillas wrote: Hello Lee, Thanks a lot for your feedback. On 06/17/2014 11:17 PM, Lee Jones wrote: The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout (LDO) regulators. This patch adds support for all these regulators found on the MAX77802 PMIC and is based on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Remove unneeded check if num_regulators != MAX77802_MAX_REGULATORS. - Fix .set_suspend_mode handler comment and split regulators ops for regulators that behave differently. Suggested by Mark Brown. - Use module_platform_driver() instead of having init/exit functions. Suggested by Mark Brown. - Use the new descriptor-based GPIO interface instead of the deprecated integer based GPIO one. Suggested by Mark Brown. - Look for regulators child node instead of voltage-regulators to be consistent with other PMIC drivers. Suggested by Mark Brown. drivers/mfd/max77802.c | 1 + Can you remove all of the MFD changes from patches 7, 8 and 9 and create new one. That way there's no requirement for any cross subsystem messiness. Sure, Mark already suggested the same and I'll do it on the next version. But there still be some cross-subsystem dependency/messiness since the regulator, clk and rtc drivers include the mfd max77802 headers that are added in Patch 6. What I should have said was _avoidable_ or _unnecessary_ messiness. So I guess you should either a) take the whole patch-set through your mfd tree or b) merge the mfd patches and create an immutable branch that can be pulled by Mark, Mike and Alessandro. I don't know what's the preferred workflow in these cases... That's fine. I'm happy to create shared branches when required. drivers/regulator/Kconfig| 9 + drivers/regulator/Makefile | 1 + drivers/regulator/max77802.c | 701 +++ 4 files changed, 712 insertions(+) create mode 100644 drivers/regulator/max77802.c Best regards, Javier -- 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: MMC error on Exynos4210 board
On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat spk.li...@gmail.com wrote: Hi Tim, I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 mmc: sdhci: Use mmc core regulator infrastucture Any ideas? *** -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.180281] Synopsys Designware Multimedia Card Interface Driver [2.188131] usbcore: registered new interface driver usbhid [2.192287] usbhid: USB HID core driver [2.196329] TCP: cubic registered [2.199362] NET: Registered protocol family 17 [2.203917] NET: Registered protocol family 15 [2.208404] Registering SWP/SWPB emulation handler [2.214357] of_get_named_gpiod_flags exited with status 0 [2.218430] of_get_named_gpiod_flags exited with status 0 [2.223803] of_get_named_gpiod_flags exited with status 0 [2.229170] of_get_named_gpiod_flags exited with status 0 [2.234560] of_get_named_gpiod_flags exited with status 0 [2.239953] gpio-229: gpiod_set_debounce: missing set() or set_debounce() operations [2.247773] gpio-230: gpiod_set_debounce: missing set() or set_debounce() operations [2.255473] gpio-228: gpiod_set_debounce: missing set() or set_debounce() operations [2.263221] gpio-227: gpiod_set_debounce: missing set() or set_debounce() operations [2.270918] gpio-226: gpiod_set_debounce: missing set() or set_debounce() operations [2.278899] input: gpio_keys as /devices/gpio_keys/input/input0 [2.285196] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.295072] VDD_G3D_1.1V: disabling [2.304744] VADC_3.3V: disabling [2.312095] VDD_AUD_1.8V: disabling [2.319714] VMIPI_1.1V: disabling [2.327193] VDD_ABB_3.3V: disabling [2.332779] VMEM_VDD_2.8V: disabling [2.336148] Waiting for root device /dev/mmcblk0p1... * Regards, Sachin. Would you mind reverting just this part of the commit to see if it clears up your trouble? if (host-ocr_mask) - ocr_avail = host-ocr_mask; + ocr_avail = host-ocr_mask; mmc-ocr_avail = ocr_avail; mmc-ocr_avail_sdio = ocr_avail; Thanks, Tim Kryger -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: exynos: Support cluster power off on exynos5420/5800
Turning off a cluster when all 4 cores of the cluster are powered off
saves power significantly. Powering off the A15 L2 alone gives around
100mW in savings. Add support for powering off the A15/A7 clusters on
exynos5420/5800.
The patch enables specific register bits which ensure that:
- cluster L2 will be turned on before the first man is powered up.
- last man will be turned off before the cluster L2 is turned off.
- core is powered down before powering it up.
Remove the exynos_cluster_power_control function completely as we can
rely on the above mentioned bits rather than polling the cluster power
status register.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
The patch is based on Linux-next 20140618. It has been tested on an
exynos5420-based chromebook using the /dev/bL_switcher interface as
well as the script provided by Nicolas Pitre and Dave Martin [1].
Patch depends on:
[v2] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
[1] http://www.spinics.net/lists/linux-samsung-soc/msg31257.html
arch/arm/mach-exynos/mcpm-exynos.c | 66 ++
1 file changed, 31 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index ace0ed6..95b5acf 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -26,6 +26,10 @@
#define EXYNOS5420_CPUS_PER_CLUSTER4
#define EXYNOS5420_NR_CLUSTERS 2
+#define EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN BIT(9)
+#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
+#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -73,36 +77,9 @@
cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
-static int exynos_cluster_power_control(unsigned int cluster, int enable)
-{
- unsigned int tries = 100;
- unsigned int val;
-
- if (enable) {
- exynos_cluster_power_up(cluster);
- val = S5P_CORE_LOCAL_PWR_EN;
- } else {
- exynos_cluster_power_down(cluster);
- val = 0;
- }
-
- /* Wait until cluster power control is applied */
- while (tries--) {
- if (exynos_cluster_power_state(cluster) == val)
- return 0;
-
- cpu_relax();
- }
- pr_debug(timed out waiting for cluster %u to power %s\n, cluster,
- enable ? on : off);
-
- return -ETIMEDOUT;
-}
-
static int exynos_power_up(unsigned int cpu, unsigned int cluster)
{
unsigned int cpunr = cpu + (cluster * EXYNOS5420_CPUS_PER_CLUSTER);
- int err = 0;
pr_debug(%s: cpu %u cluster %u\n, __func__, cpu, cluster);
if (cpu = EXYNOS5420_CPUS_PER_CLUSTER ||
@@ -126,12 +103,9 @@ static int exynos_power_up(unsigned int cpu, unsigned int
cluster)
* cores.
*/
if (was_cluster_down)
- err = exynos_cluster_power_control(cluster, 1);
+ exynos_cluster_power_up(cluster);
- if (!err)
- exynos_cpu_power_up(cpunr);
- else
- exynos_cluster_power_control(cluster, 0);
+ exynos_cpu_power_up(cpunr);
} else if (cpu_use_count[cpu][cluster] != 2) {
/*
* The only possible values are:
@@ -147,7 +121,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int
cluster)
arch_spin_unlock(exynos_mcpm_lock);
local_irq_enable();
- return err;
+ return 0;
}
/*
@@ -178,9 +152,10 @@ static void exynos_power_down(void)
if (cpu_use_count[cpu][cluster] == 0) {
exynos_cpu_power_down(cpunr);
- if (exynos_cluster_unused(cluster))
- /* TODO: Turn off the cluster here to save power. */
+ if (exynos_cluster_unused(cluster)) {
+ exynos_cluster_power_down(cluster);
last_man = true;
+ }
} else if (cpu_use_count[cpu][cluster] == 1) {
/*
* A power_up request went ahead of us.
@@ -299,6 +274,7 @@ static int __init exynos_mcpm_init(void)
{
struct device_node *node;
void __iomem *ns_sram_base_addr;
+ unsigned int value, i;
int ret;
node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
@@ -342,6 +318,26 @@ static int __init exynos_mcpm_init(void)
pr_info(Exynos MCPM support installed\n);
/*
+* On Exynos5420/5800 for the A15 and A7 clusters:
+*
+* EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN ensures that all the cores
+* in a cluster are turned off before
Re: [PATCH] arm: exynos: Support cluster power off on exynos5420/5800
On Wed, 18 Jun 2014, Abhilash Kesavan wrote:
Turning off a cluster when all 4 cores of the cluster are powered off
saves power significantly. Powering off the A15 L2 alone gives around
100mW in savings. Add support for powering off the A15/A7 clusters on
exynos5420/5800.
The patch enables specific register bits which ensure that:
- cluster L2 will be turned on before the first man is powered up.
- last man will be turned off before the cluster L2 is turned off.
- core is powered down before powering it up.
Remove the exynos_cluster_power_control function completely as we can
rely on the above mentioned bits rather than polling the cluster power
status register.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Minor nit below:
@@ -342,6 +318,26 @@ static int __init exynos_mcpm_init(void)
pr_info(Exynos MCPM support installed\n);
/*
+ * On Exynos5420/5800 for the A15 and A7 clusters:
+ *
+ * EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN ensures that all the cores
+ * in a cluster are turned off before turning off the cluster L2.
+ *
+ * EXYNOS5420_USE_ARM_CORE_DOWN_STATE ensures that a cores is powered
+ * off before waking it up.
+ *
+ * EXYNOS5420_USE_L2_COMMON_UP_STATE ensures that cluster L2 will be
+ * turned on before the first man is powered up.
+ */
+ for (i = 0; i EXYNOS5420_NR_CLUSTERS; i++) {
+ value = __raw_readl(EXYNOS_COMMON_CONFIGURATION(i) + 0x8);
+ value |= EXYNOS5420_ENABLE_AUTOMATIC_CORE_DOWN |
+ EXYNOS5420_USE_ARM_CORE_DOWN_STATE|
+ EXYNOS5420_USE_L2_COMMON_UP_STATE;
+ __raw_writel(value, EXYNOS_COMMON_CONFIGURATION(i) + 0x8);
Surely you can add another define in mach-exynos/regs-pmu.h to better
identify this register instead of EXYNOS_COMMON_CONFIGURATION()+8 ?
After that, you may add:
Acked-by: Nicolas Pitre n...@linaro.org
Nicolas
--
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] clk: samsung: Register clk provider only after registering its all clocks
Ensure the clock provider is not registered until after all its related clocks were created and are ready to use. Currently there are races possible and any (of_)clk_get() call right after a clock provider's clk_init_cb callback call may fail. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- NOTE: Tested only on Exynos4412. drivers/clk/samsung/clk-exynos3250.c |2 ++ drivers/clk/samsung/clk-exynos4.c|2 ++ drivers/clk/samsung/clk-exynos5250.c |2 ++ drivers/clk/samsung/clk-exynos5260.c |2 ++ drivers/clk/samsung/clk-exynos5410.c |2 ++ drivers/clk/samsung/clk-exynos5420.c |2 ++ drivers/clk/samsung/clk-exynos5440.c |2 ++ drivers/clk/samsung/clk-s3c2410.c|2 ++ drivers/clk/samsung/clk-s3c2412.c|2 ++ drivers/clk/samsung/clk-s3c2443.c|2 ++ drivers/clk/samsung/clk-s3c64xx.c|2 ++ drivers/clk/samsung/clk.c| 19 ++- drivers/clk/samsung/clk.h|2 ++ 13 files changed, 34 insertions(+), 9 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c index 7a17bd4..9a43cc3 100644 --- a/drivers/clk/samsung/clk-exynos3250.c +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -776,5 +776,7 @@ static void __init exynos3250_cmu_init(struct device_node *np) samsung_clk_register_gate(ctx, gate_clks, ARRAY_SIZE(gate_clks)); exynos3250_clk_sleep_init(); + + samsung_clk_of_add_provider(np, ctx); } CLK_OF_DECLARE(exynos3250_cmu, samsung,exynos3250-cmu, exynos3250_cmu_init); diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c index 4f150c9..fc73bb4 100644 --- a/drivers/clk/samsung/clk-exynos4.c +++ b/drivers/clk/samsung/clk-exynos4.c @@ -1260,6 +1260,8 @@ static void __init exynos4_clk_init(struct device_node *np, exynos4_clk_sleep_init(); + samsung_clk_of_add_provider(np, ctx); + pr_info(%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n \tsclk_epll = %ld, sclk_vpll = %ld, arm_clk = %ld\n, exynos4_soc == EXYNOS4210 ? Exynos4210 : Exynos4x12, diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c index 1fad4c5..3a544a8 100644 --- a/drivers/clk/samsung/clk-exynos5250.c +++ b/drivers/clk/samsung/clk-exynos5250.c @@ -820,6 +820,8 @@ static void __init exynos5250_clk_init(struct device_node *np) exynos5250_clk_sleep_init(); + samsung_clk_of_add_provider(np, ctx); + pr_info(Exynos5250: clock setup completed, armclk=%ld\n, _get_rate(div_arm2)); } diff --git a/drivers/clk/samsung/clk-exynos5260.c b/drivers/clk/samsung/clk-exynos5260.c index 64596ba..ce3de97 100644 --- a/drivers/clk/samsung/clk-exynos5260.c +++ b/drivers/clk/samsung/clk-exynos5260.c @@ -206,6 +206,8 @@ void __init exynos5260_cmu_register_one(struct device_node *np, if (cmu-clk_regs) exynos5260_clk_sleep_init(reg_base, cmu-clk_regs, cmu-nr_clk_regs); + + samsung_clk_of_add_provider(np, ctx); } diff --git a/drivers/clk/samsung/clk-exynos5410.c b/drivers/clk/samsung/clk-exynos5410.c index c9505ab..231475b 100644 --- a/drivers/clk/samsung/clk-exynos5410.c +++ b/drivers/clk/samsung/clk-exynos5410.c @@ -204,6 +204,8 @@ static void __init exynos5410_clk_init(struct device_node *np) samsung_clk_register_gate(ctx, exynos5410_gate_clks, ARRAY_SIZE(exynos5410_gate_clks)); + samsung_clk_of_add_provider(np, ctx); + pr_debug(Exynos5410: clock setup completed.\n); } CLK_OF_DECLARE(exynos5410_clk, samsung,exynos5410-clock, exynos5410_clk_init); diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c index 9d7d7ee..ef48f34 100644 --- a/drivers/clk/samsung/clk-exynos5420.c +++ b/drivers/clk/samsung/clk-exynos5420.c @@ -1226,6 +1226,8 @@ static void __init exynos5x_clk_init(struct device_node *np, } exynos5420_clk_sleep_init(); + + samsung_clk_of_add_provider(np, ctx); } static void __init exynos5420_clk_init(struct device_node *np) diff --git a/drivers/clk/samsung/clk-exynos5440.c b/drivers/clk/samsung/clk-exynos5440.c index 647f144..2f182f2 100644 --- a/drivers/clk/samsung/clk-exynos5440.c +++ b/drivers/clk/samsung/clk-exynos5440.c @@ -123,6 +123,8 @@ static void __init exynos5440_clk_init(struct device_node *np) samsung_clk_register_gate(ctx, exynos5440_gate_clks, ARRAY_SIZE(exynos5440_gate_clks)); + samsung_clk_of_add_provider(np, ctx); + pr_info(Exynos5440: arm_clk = %ldHz\n, _get_rate(arm_clk)); pr_info(exynos5440 clock initialization complete\n); } diff --git a/drivers/clk/samsung/clk-s3c2410.c b/drivers/clk/samsung/clk-s3c2410.c index ba07168..2e688c3 100644 --- a/drivers/clk/samsung/clk-s3c2410.c +++ b/drivers/clk/samsung/clk-s3c2410.c @@ -461,6 +461,8 @@ void __init s3c2410_common_clk_init(struct
Re: [PATCH 0/4] Add support for Exynos clock output configuration
Hi Tomasz, On Tue, May 20, 2014 at 5:43 PM, Tomasz Figa t.f...@samsung.com wrote: Since the block responsible for handling the pin is PMU, not CMU, a separate driver, that binds to PMU node is required and acquires all input clocks by standard DT clock look-up. This way we don't need any cross-IP block drivers and cross-driver register sharing or nodes for fake devices. To represent the PMU mux/gate clock, generic composite clock is registered. Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. Depends on: [PATCHv5 0/4] Enable usbphy and hsotg for exynos4 (No link, sorry, I could not find it in any archive yet...) for Exynos4210/4x12 PMU binding and DT nodes. This isn't working for me. Testing linus master e99cfa2d0634881b8a41d56c48b5956b9a3ba162 plus: ARM: dts: exynos4: add port sub-nodes to exynos usb host modules ARM: dts: exynos4412-odroidx: enable common hardware blocks ARM: dts: exynos4412-odroidx: add support for USB (phy, host, device) ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3 Testing on ODROID-U2. I apply the first patch here (clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy) and things continue to work. Now when I add the second patch clk: samsung: exynos4: Add CLKOUT clock hierarchy boot hangs at: [4.753740] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 02:43:30 UTC (946694610) [4.753809] ### dt-test ### No testcase data in device tree; not running tests [4.791155] gps-power-domain: Power-off latency e Any ideas? Thanks Daniel -- 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/2] Sound support for Exynos4412 Odroid X2, U3 board
This series adds basic sound support for the Odroid X2/U3 boards. It relies on specific Exynos Audio Subsystem clock parent and frequencies being pre-configured. My full testing git branch has been pushed to: git://linuxtv.org/snawrocki/samsung.git v3.16-rc1-odroid-sound-clk It can be browsed at: http://git.linuxtv.org/cgit.cgi/snawrocki/samsung.git/log/?h=v3.16-rc1-odroid-sound-clk I didn't use the simple-card since there is going to be added one more CPU interface using the secondary I2S and IDMA. Sylwester Nawrocki (2): ASoC: samsung: Add machine driver for Odroid X2/U3 doc: dt bindings: Document Odroid X2/U3 audio subsystem bindings .../bindings/sound/samsung,odroidx2-max98090.txt | 35 sound/soc/samsung/Kconfig |8 + sound/soc/samsung/Makefile |2 + sound/soc/samsung/odroidx2_max98090.c | 191 4 files changed, 236 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt create mode 100644 sound/soc/samsung/odroidx2_max98090.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] ASoC: samsung: Add machine driver for Odroid X2/U3
This patch adds the sound subsystem driver for Odroid-X2 and
Odroid-U3 boards. The codec works in I2S master mode; there are
2 separate audio routing paths defined as there are differences
in the signal routing between the X2 and U3 boards, i.e. U3 uses
single jack for headphones and microphone.
Signed-off-by: Chen Zhen zhen1.c...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
sound/soc/samsung/Kconfig |8 ++
sound/soc/samsung/Makefile|2 +
sound/soc/samsung/odroidx2_max98090.c | 191 +
3 files changed, 201 insertions(+)
create mode 100644 sound/soc/samsung/odroidx2_max98090.c
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7745629..bd2645c 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -243,3 +243,11 @@ config SND_SOC_SNOW
help
Say Y if you want to add audio support for various Snow
boards based on Exynos5 series of SoCs.
+
+config SND_SOC_ODROIDX2
+ tristate Audio support for Odroid-X2 and Odroid-U3
+ depends on SND_SOC_SAMSUNG
+ select SND_SOC_MAX98090
+ select SND_SAMSUNG_I2S
+ help
+ Say Y here to enable audio support for the Odroid-X2/U3.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 6d0212b..8b1cfbd 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -46,6 +46,7 @@ snd-soc-tobermory-objs := tobermory.o
snd-soc-lowland-objs := lowland.o
snd-soc-littlemill-objs := littlemill.o
snd-soc-bells-objs := bells.o
+snd-soc-odroidx2-max98090-objs := odroidx2_max98090.o
obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
@@ -71,3 +72,4 @@ obj-$(CONFIG_SND_SOC_TOBERMORY) += snd-soc-tobermory.o
obj-$(CONFIG_SND_SOC_LOWLAND) += snd-soc-lowland.o
obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
+obj-$(CONFIG_SND_SOC_ODROIDX2) += snd-soc-odroidx2-max98090.o
diff --git a/sound/soc/samsung/odroidx2_max98090.c
b/sound/soc/samsung/odroidx2_max98090.c
new file mode 100644
index 000..11c0952
--- /dev/null
+++ b/sound/soc/samsung/odroidx2_max98090.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/of.h
+#include linux/module.h
+#include sound/soc.h
+#include sound/pcm_params.h
+#include i2s.h
+
+struct odroidx2_drv_data {
+ const struct snd_soc_dapm_widget *dapm_widgets;
+ unsigned int num_dapm_widgets;
+};
+
+/* The I2S CDCLK output clock frequency to the MAX98090 codec. */
+#define MAX98090_MCLK 1920
+
+static int odroidx2_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_dai *codec_dai = rtd-codec_dai;
+ int ret;
+
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
+ SND_SOC_CLOCK_IN);
+ if (ret 0) {
+ dev_err(codec_dai-dev,
+ Unable to switch to FLL1: %d\n, ret);
+ return ret;
+ }
+
+ /* Set the cpu DAI configuration in order to use CDCLK */
+ ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_OUT);
+ if (ret 0)
+ return ret;
+
+ dev_dbg(codec_dai-dev, HiFi DAI %s params: channels: %d, rate: %d\n,
+ snd_pcm_stream_str(substream), params_channels(params),
+ params_rate(params));
+
+ return 0;
+}
+
+static struct snd_soc_ops odroidx2_ops = {
+ .hw_params = odroidx2_hw_params,
+};
+
+static const struct snd_soc_dapm_widget odroidx2_dapm_widgets[] = {
+ SND_SOC_DAPM_HP(Headphone Jack, NULL),
+ SND_SOC_DAPM_MIC(Mic Jack, NULL),
+ SND_SOC_DAPM_MIC(DMIC, NULL),
+};
+
+static const struct snd_soc_dapm_widget odroidu3_dapm_widgets[] = {
+ SND_SOC_DAPM_HP(Headphone Jack, NULL),
+ SND_SOC_DAPM_SPK(Speakers, NULL),
+};
+
+static struct snd_soc_dai_link odroidx2_dai[] = {
+ {
+ .name = MAX98090,
+ .stream_name= MAX98090 PCM,
+ .codec_dai_name = HiFi,
+ .dai_fmt= SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM,
+ .ops= odroidx2_ops,
+ }
+};
+
+static struct snd_soc_card odroidx2 = {
+ .owner = THIS_MODULE,
+ .dai_link =
Re: [PATCH 02/10] mfd: cros_ec: IRQs for cros_ec should be optional
Lee,
On Wed, Jun 18, 2014 at 12:55 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
Preparing the way for the LPC device, which is just a plaform_device without
interrupts.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 38fe9bf..bd6f936 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -119,17 +119,15 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
- if (!ec_dev-irq) {
- dev_dbg(dev, no valid IRQ: %d\n, ec_dev-irq);
- return err;
- }
-
- err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-chromeos-ec, ec_dev);
- if (err) {
- dev_err(dev, request irq %d: error %d\n, ec_dev-irq, err);
- return err;
+ if (ec_dev-irq) {
+ err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ chromeos-ec, ec_dev);
Is there anything stopping you using the devm_* version?
I'm generally quite hesitant about using the devm_ IRQ functions.
Requesting an IRQ enables the IRQ at the time of request and freeing
it disables it, right? Leaving it up to the the devm subsystem to
disable your IRQ tends to be a race waiting to happen if an IRQ
happens after you've freed all your memory / cleaned up all your
state.
Looking at cros_ec in particular though:
* Right now the last thing done in cros_ec_remove() (which is the last
thing in both cros_ec_i2c_remove and cros_ec_spi_remove) is to free
the IRQ. That means that you're right: we could switch to devm_ in
this case and it wouldn't introduce any new bugs.
* ...but I'm not convinced that the location of the free_irq() today
is quite right. I couldn't actually get it to crash or hang, but
there is a time period where we've called mfd_remove_devices() and the
IRQ is still active. That doesn't seem like a super great situation
to be in. I'll add a move of the irq_free to the patch series.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] doc: dt bindings: Document Odroid X2/U3 audio subsystem bindings
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../bindings/sound/samsung,odroidx2-max98090.txt | 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt
diff --git
a/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt
b/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt
new file mode 100644
index 000..9148f72
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt
@@ -0,0 +1,35 @@
+Samsung Exynos Odroid X2/U3 audio complex with MAX98090 codec
+
+Required properties:
+ - compatible : samsung,odroidx2-audio - for Odroid X2 board,
+ samsung,odroidu3-audio - for Odroid U3 board
+ - samsung,model : the user-visible name of this sound complex
+ - samsung,i2s-controller : the phandle of the I2S controller
+ - samsung,audio-codec : the phandle of the MAX98090 audio codec
+ - samsung,audio-routing : a list of the connections between audio
+ components; each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's source;
+ valid names for sources and sinks are the MAX98090's pins (as
+ documented in its binding), and the jacks on the board
+ For Odroid X2:
+ * Headphone Jack
+ * Mic Jack
+ * DMIC
+
+ For Odroid U3:
+ * Headphone Jack
+ * Speakers
+
+Example:
+
+sound {
+ compatible = samsung,odroidu3-audio;
+ samsung,i2s-controller = i2s0;
+ samsung,audio-codec = max98090;
+ samsung,model = Odroid-X2;
+ samsung,audio-routing =
+ Headphone Jack, HPL,
+ Headphone Jack, HPR,
+ IN1, Mic Jack,
+ Mic Jack, MICBIAS;
+};
--
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 01/10] mfd: cros_ec: Fix the comment on cros_ec_remove()
Lee, On Wed, Jun 18, 2014 at 12:57 AM, Lee Jones lee.jo...@linaro.org wrote: On Mon, 16 Jun 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org This comment was incorrect, so update it. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Simon Glass s...@chromium.org How many people did it take to write this patch? ;) Acked-by: Lee Jones lee.jo...@linaro.org There's gotta be a joke here about how many Google engineers it takes to fix a comment. In this case I think the answer is 3: one to fix the comment, one to clean it up, and one to send it upstream. ;) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()
Lee,
On Wed, Jun 18, 2014 at 12:53 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
The lower-level driver may want to provide its own buffers. If so,
there's no need to allocate new ones. This already happens to work
just fine (since we check for size of 0 and use devm allocation), but
it's good to document it.
[dianders: Resolved conflicts; documented that no code changes needed
on mainline]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
include/linux/mfd/cros_ec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 7e9fe6e..2ee3190 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -68,8 +68,8 @@ struct cros_ec_msg {
* We use this alignment to keep ARM and x86 happy. Probably word
* alignment would be OK, there might be a small performance advantage
* to using dword.
- * @din_size: size of din buffer
- * @dout_size: size of dout buffer
+ * @din_size: size of din buffer to allocate (zero to use static din)
+ * @dout_size: size of dout buffer to allocate (zero to use static dout)
Why don't these use your new format i.e. doutsize, etc?
Ah, you mean like the new struct cros_ec_command that's switched to
in (mfd: cros_ec: Use struct cros_ec_command to communicate with the
EC)? I don't know--it seems rather arbitrary. Personally I like
having the underscore (thus if we have to change I'd advocate changing
struct cros_ec_command).
The inconsistency doesn't bother me terribly and it will be more work
to cherry-pick future patches. Since it didn't sound like you are
insisting then I won't change this, but if you say that you want me to
change it I'm more than happy to.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] mfd: cros_ec: Fix the comment on cros_ec_remove()
On Wed, 18 Jun 2014, Doug Anderson wrote: Lee, On Wed, Jun 18, 2014 at 12:57 AM, Lee Jones lee.jo...@linaro.org wrote: On Mon, 16 Jun 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org This comment was incorrect, so update it. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Simon Glass s...@chromium.org How many people did it take to write this patch? ;) Acked-by: Lee Jones lee.jo...@linaro.org There's gotta be a joke here about how many Google engineers it takes to fix a comment. In this case I think the answer is 3: one to fix the comment, one to clean it up, and one to send it upstream. ;) ... and one to hold the ladder. No, wait! ;) -- 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 02/10] mfd: cros_ec: IRQs for cros_ec should be optional
On Wed, 18 Jun 2014, Doug Anderson wrote:
Lee,
On Wed, Jun 18, 2014 at 12:55 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
Preparing the way for the LPC device, which is just a plaform_device
without
interrupts.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 38fe9bf..bd6f936 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -119,17 +119,15 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
- if (!ec_dev-irq) {
- dev_dbg(dev, no valid IRQ: %d\n, ec_dev-irq);
- return err;
- }
-
- err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-chromeos-ec, ec_dev);
- if (err) {
- dev_err(dev, request irq %d: error %d\n, ec_dev-irq, err);
- return err;
+ if (ec_dev-irq) {
+ err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ chromeos-ec, ec_dev);
Is there anything stopping you using the devm_* version?
I'm generally quite hesitant about using the devm_ IRQ functions.
Requesting an IRQ enables the IRQ at the time of request and freeing
it disables it, right? Leaving it up to the the devm subsystem to
disable your IRQ tends to be a race waiting to happen if an IRQ
happens after you've freed all your memory / cleaned up all your
state.
Looking at cros_ec in particular though:
* Right now the last thing done in cros_ec_remove() (which is the last
thing in both cros_ec_i2c_remove and cros_ec_spi_remove) is to free
the IRQ. That means that you're right: we could switch to devm_ in
this case and it wouldn't introduce any new bugs.
* ...but I'm not convinced that the location of the free_irq() today
is quite right. I couldn't actually get it to crash or hang, but
there is a time period where we've called mfd_remove_devices() and the
IRQ is still active. That doesn't seem like a super great situation
to be in. I'll add a move of the irq_free to the patch series.
I guess if you're concerned about ordering you could always use
devm_free_irq() in the places where you think it should be freed
earlier than release. I'm pretty sure that discludes the failure
patch in probe() though, so we'd still be able to rid a few lines.
--
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 02/10] mfd: cros_ec: IRQs for cros_ec should be optional
Lee,
On Wed, Jun 18, 2014 at 9:46 AM, Lee Jones lee.jo...@linaro.org wrote:
On Wed, 18 Jun 2014, Doug Anderson wrote:
Lee,
On Wed, Jun 18, 2014 at 12:55 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, 16 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
Preparing the way for the LPC device, which is just a plaform_device
without
interrupts.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/cros_ec.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 38fe9bf..bd6f936 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -119,17 +119,15 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
- if (!ec_dev-irq) {
- dev_dbg(dev, no valid IRQ: %d\n, ec_dev-irq);
- return err;
- }
-
- err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-chromeos-ec, ec_dev);
- if (err) {
- dev_err(dev, request irq %d: error %d\n, ec_dev-irq,
err);
- return err;
+ if (ec_dev-irq) {
+ err = request_threaded_irq(ec_dev-irq, NULL, ec_irq_thread,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ chromeos-ec, ec_dev);
Is there anything stopping you using the devm_* version?
I'm generally quite hesitant about using the devm_ IRQ functions.
Requesting an IRQ enables the IRQ at the time of request and freeing
it disables it, right? Leaving it up to the the devm subsystem to
disable your IRQ tends to be a race waiting to happen if an IRQ
happens after you've freed all your memory / cleaned up all your
state.
Looking at cros_ec in particular though:
* Right now the last thing done in cros_ec_remove() (which is the last
thing in both cros_ec_i2c_remove and cros_ec_spi_remove) is to free
the IRQ. That means that you're right: we could switch to devm_ in
this case and it wouldn't introduce any new bugs.
* ...but I'm not convinced that the location of the free_irq() today
is quite right. I couldn't actually get it to crash or hang, but
there is a time period where we've called mfd_remove_devices() and the
IRQ is still active. That doesn't seem like a super great situation
to be in. I'll add a move of the irq_free to the patch series.
I guess if you're concerned about ordering you could always use
devm_free_irq() in the places where you think it should be freed
earlier than release. I'm pretty sure that discludes the failure
patch in probe() though, so we'd still be able to rid a few lines.
Hmmm, I'd even vote to move the IRQ request to be the last thing in
probe (which would also mean that the devm wouldn't be used but would
then require us to call mfd_remove_devices()). ...but I can't find
any good reason that we need to do that.
Oh, dang. I just looked at the next local patch in the list of local
ones. ...it totally rips this code out and moves the IRQ to
cros_ec_keyboard where it belongs (the infrastructure didn't really
allow more than one person to use this anyway). I'll just squash this
patch there and we're done. Sorry for the noise! :(
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] mfd: cros_ec: Tweak struct cros_ec_device for clarity
From: Bill Richardson wfric...@chromium.org
The members of struct cros_ec_device were improperly commented, and
intermixed the private and public sections. This is just cleanup to make it
more obvious what goes with what.
[dianders: left lock in the structure but gave it the name that will
eventually be used.]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v2: None
drivers/mfd/cros_ec.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 4 +--
drivers/mfd/cros_ec_spi.c | 10 +++
include/linux/mfd/cros_ec.h | 65 -
4 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 38fe9bf..04e053c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -57,7 +57,7 @@ static int cros_ec_command_sendrecv(struct cros_ec_device
*ec_dev,
msg.in_buf = in_buf;
msg.in_len = in_len;
- return ec_dev-command_xfer(ec_dev, msg);
+ return ec_dev-cmd_xfer(ec_dev, msg);
}
static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 4f71be9..777e529 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -29,7 +29,7 @@ static inline struct cros_ec_device *to_ec_dev(struct device
*dev)
return i2c_get_clientdata(client);
}
-static int cros_ec_command_xfer(struct cros_ec_device *ec_dev,
+static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
struct cros_ec_msg *msg)
{
struct i2c_client *client = ec_dev-priv;
@@ -136,7 +136,7 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev-dev = dev;
ec_dev-priv = client;
ec_dev-irq = client-irq;
- ec_dev-command_xfer = cros_ec_command_xfer;
+ ec_dev-cmd_xfer = cros_ec_cmd_xfer_i2c;
ec_dev-ec_name = client-name;
ec_dev-phys_name = client-adapter-name;
ec_dev-parent = client-dev;
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 0b8d328..52d4d7b 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -73,7 +73,7 @@
* 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_command_spi_xfer at a time
+ * @lock: mutex to ensure only one user of cros_ec_cmd_xfer_spi at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
@@ -210,13 +210,13 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
}
/**
- * cros_ec_command_spi_xfer - Transfer a message over SPI and receive the reply
+ * cros_ec_cmd_xfer_spi - Transfer a message over SPI and receive the reply
*
* @ec_dev: ChromeOS EC device
* @ec_msg: Message to transfer
*/
-static int cros_ec_command_spi_xfer(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *ec_msg)
+static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
+ struct cros_ec_msg *ec_msg)
{
struct cros_ec_spi *ec_spi = ec_dev-priv;
struct spi_transfer trans;
@@ -372,7 +372,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev-dev = dev;
ec_dev-priv = ec_spi;
ec_dev-irq = spi-irq;
- ec_dev-command_xfer = cros_ec_command_spi_xfer;
+ ec_dev-cmd_xfer = cros_ec_cmd_xfer_spi;
ec_dev-ec_name = ec_spi-spi-modalias;
ec_dev-phys_name = dev_name(ec_spi-spi-dev);
ec_dev-parent = ec_spi-spi-dev;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2ee3190..79a3585 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -16,7 +16,9 @@
#ifndef __LINUX_MFD_CROS_EC_H
#define __LINUX_MFD_CROS_EC_H
+#include linux/notifier.h
#include linux/mfd/cros_ec_commands.h
+#include linux/mutex.h
/*
* Command interface between EC and AP, for LPC, I2C and SPI interfaces.
@@ -55,34 +57,53 @@ struct cros_ec_msg {
/**
* struct cros_ec_device - Information about a ChromeOS EC device
*
+ * @ec_name: name of EC device (e.g. 'chromeos-ec')
+ * @phys_name: name of physical comms layer (e.g. 'i2c-4')
+ * @dev: Device pointer
+ * @was_wake_device: true if this device was set to wake the system from
+ * sleep at the last suspend
+ * @event_notifier: interrupt event notifier for transport devices
+ * @command_send: send a command
+ * @command_recv: receive a response
+ * @command_sendrecv: send a command and receive a response
+ *
* @name: Name of this EC interface
* @priv: Private data
* @irq: Interrupt to use
- * @din: input buffer (from EC)
- * @dout: output buffer (to EC)
+ * @din: input buffer (for data from EC)
+ * @dout: output buffer (for data to EC)
* \note
* These
[PATCH v2 0/10] Batch of cleanup patches for cros_ec
This is a batch of cleanup patches picked from the ChromeOS 3.8 kernel tree and applied to ToT. Most of these patches were authored by Bill Richardson (CCed). Where appropriate I've squashed patches together, though I have erred on the side of keeping patches logically distinct rather than squashing into one big cleanup patch. There is very little functionality added by this series, but this gets us closer to how things look in the ChromeOS tree so we can add more patches atop it. In general I took the oldest patches from our tree and stopped picking when I got to a reasonable patch size (10 patches). There are about 5 more cleanup patches still in the ChromeOS tree, then some more major functionality patches. Note that I didn't take the cros_ec_dev userspace inteface, the LPC implementation, the vboot context implementation, and patches relating to exynos5250-spring when picking patches. These bits are very separate (and big!) and can be added and debated separately after we've got cleanup in. Whenever patches touched those pieces of the code I ignored that part of the patch. In general I did take cleanup code that was intended to make it easier to later add these bits. I have tested basic functionality of these patches on exynos5250-snow and exynos5420-peach-pit. Changes in v2: - Include example printouts before/after in commit message. - Removed unneeded ret variable. - Added common function to cros_ec.c - Changed to dev_dbg() as per http://crosreview.com/66726 - IRQs should be optional = move EC interrupt to keyboard. Andrew Bresticker (1): mfd: cros_ec: move EC interrupt to cros_ec_keyb Bill Richardson (8): mfd: cros_ec: Fix the comment on cros_ec_remove() mfd: cros_ec: Allow static din/dout buffers with cros_ec_register() mfd: cros_ec: Tweak struct cros_ec_device for clarity mfd: cros_ec: Use struct cros_ec_command to communicate with the EC mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device mfd: cros_ec: cleanup: Remove EC wrapper functions mfd: cros_ec: Check result code from EC messages mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC Simon Glass (1): mdf: cros_ec: Detect in-progress commands drivers/i2c/busses/i2c-cros-ec-tunnel.c | 17 +++-- drivers/input/keyboard/cros_ec_keyb.c | 70 drivers/mfd/cros_ec.c | 97 drivers/mfd/cros_ec_i2c.c | 37 +-- drivers/mfd/cros_ec_spi.c | 36 +-- include/linux/mfd/cros_ec.h | 110 +--- 6 files changed, 172 insertions(+), 195 deletions(-) -- 2.0.0.526.g5318336 -- 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 09/10] mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC
From: Bill Richardson wfric...@chromium.org
When communicating with the EC, the cmd_xfer() function should return the
number of bytes it received from the EC, or negative on error.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v2: None
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 2 +-
drivers/mfd/cros_ec_spi.c | 2 +-
include/linux/mfd/cros_ec.h | 8
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index dd07818..05e033c 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -228,7 +228,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
msg.insize = response_len;
result = bus-ec-cmd_xfer(bus-ec, msg);
- if (result)
+ if (result 0)
goto exit;
result = ec_i2c_parse_response(response, i2c_msgs, num);
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 189e7d1..fd7a546 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -111,7 +111,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
goto done;
}
- ret = 0;
+ ret = i2c_msg[1].buf[1];
done:
kfree(in_buf);
kfree(out_buf);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c975087..2ad6815 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -324,7 +324,7 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
goto exit;
}
- ret = 0;
+ ret = len;
exit:
mutex_unlock(ec_spi-lock);
return ret;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 1f79f16..0ebf26f 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -41,7 +41,7 @@ enum {
* @outdata: Outgoing data to EC
* @outsize: Outgoing length in bytes
* @indata: Where to put the incoming data from EC
- * @insize: Incoming length in bytes (filled in by EC)
+ * @insize: Max number of bytes to accept from EC
* @result: EC's response to the command (separate from communication failure)
*/
struct cros_ec_command {
@@ -64,9 +64,9 @@ struct cros_ec_command {
* sleep at the last suspend
* @event_notifier: interrupt event notifier for transport devices
* @cmd_xfer: send command to EC and get response
- * Returns 0 if the communication succeeded, but that doesn't mean the EC
- * was happy with the command it got. Caller should check msg.result for
- * the EC's result code.
+ * 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
--
2.0.0.526.g5318336
--
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 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb
From: Andrew Bresticker abres...@chromium.org
If we receive EC interrupts after the cros_ec driver has probed, but
before the cros_ec_keyb driver has probed, the cros_ec IRQ handler
will not run the cros_ec_keyb notifier and the EC will leave the IRQ
line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and
the resulting flood of interrupts causes the machine to hang.
Since the EC interrupt is currently only used for the keyboard, move
the setup and handling of the EC interrupt to the cros_ec_keyb driver.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- IRQs should be optional = move EC interrupt to keyboard.
drivers/input/keyboard/cros_ec_keyb.c | 58 ---
drivers/mfd/cros_ec.c | 35 +
include/linux/mfd/cros_ec.h | 2 --
3 files changed, 34 insertions(+), 61 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index b8341ab..791781a 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -24,8 +24,8 @@
#include linux/module.h
#include linux/i2c.h
#include linux/input.h
+#include linux/interrupt.h
#include linux/kernel.h
-#include linux/notifier.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/input/matrix_keypad.h
@@ -42,7 +42,6 @@
* @dev: Device pointer
* @idev: Input device
* @ec: Top level ChromeOS device to use to talk to EC
- * @event_notifier: interrupt event notifier for transport devices
*/
struct cros_ec_keyb {
unsigned int rows;
@@ -55,7 +54,6 @@ struct cros_ec_keyb {
struct device *dev;
struct input_dev *idev;
struct cros_ec_device *ec;
- struct notifier_block notifier;
};
@@ -173,22 +171,6 @@ static void cros_ec_keyb_process(struct cros_ec_keyb
*ckdev,
input_sync(ckdev-idev);
}
-static int cros_ec_keyb_open(struct input_dev *dev)
-{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
-
- return blocking_notifier_chain_register(ckdev-ec-event_notifier,
- ckdev-notifier);
-}
-
-static void cros_ec_keyb_close(struct input_dev *dev)
-{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
-
- blocking_notifier_chain_unregister(ckdev-ec-event_notifier,
- ckdev-notifier);
-}
-
static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
*kb_state)
{
struct cros_ec_command msg = {
@@ -203,19 +185,41 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb
*ckdev, uint8_t *kb_state)
return ckdev-ec-cmd_xfer(ckdev-ec, msg);
}
-static int cros_ec_keyb_work(struct notifier_block *nb,
-unsigned long state, void *_notify)
+static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
{
+ struct cros_ec_keyb *ckdev = data;
+ struct cros_ec_device *ec = ckdev-ec;
int ret;
- struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
- notifier);
uint8_t kb_state[ckdev-cols];
+ if (device_may_wakeup(ec-dev))
+ pm_wakeup_event(ec-dev, 0);
+
ret = cros_ec_keyb_get_state(ckdev, kb_state);
if (ret = 0)
cros_ec_keyb_process(ckdev, kb_state, ret);
+ else
+ dev_err(ec-dev, failed to get keyboard state: %d\n, ret);
- return NOTIFY_DONE;
+ return IRQ_HANDLED;
+}
+
+static int cros_ec_keyb_open(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ struct cros_ec_device *ec = ckdev-ec;
+
+ return request_threaded_irq(ec-irq, NULL, cros_ec_keyb_irq,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ cros_ec_keyb, ckdev);
+}
+
+static void cros_ec_keyb_close(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ struct cros_ec_device *ec = ckdev-ec;
+
+ free_irq(ec-irq, ckdev);
}
static int cros_ec_keyb_probe(struct platform_device *pdev)
@@ -246,8 +250,12 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
if (!idev)
return -ENOMEM;
+ if (!ec-irq) {
+ dev_err(dev, no EC IRQ specified\n);
+ return -EINVAL;
+ }
+
ckdev-ec = ec;
- ckdev-notifier.notifier_call = cros_ec_keyb_work;
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 83e30c6..4873f9c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -62,18 +62,6 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_check_result);
-static irqreturn_t ec_irq_thread(int irq, void *data)
-{
- struct
[PATCH v2 08/10] mfd: cros_ec: Check result code from EC messages
From: Bill Richardson wfric...@chromium.org
Just because the host was able to talk to the EC doesn't mean that the EC
was happy with what it was told. Errors in communincation are not the same
as error messages from the EC itself.
This change lets the EC report its errors separately.
[dianders: Added common function to cros_ec.c]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Added common function to cros_ec.c
- Changed to dev_dbg() as per http://crosreview.com/66726
drivers/mfd/cros_ec.c | 18 ++
drivers/mfd/cros_ec_i2c.c | 8 +++-
drivers/mfd/cros_ec_spi.c | 19 ++-
include/linux/mfd/cros_ec.h | 12
4 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4851ed2..83e30c6 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -44,6 +44,24 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
+int cros_ec_check_result(struct cros_ec_device *ec_dev,
+struct cros_ec_command *msg)
+{
+ switch (msg-result) {
+ case EC_RES_SUCCESS:
+ return 0;
+ case EC_RES_IN_PROGRESS:
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ msg-command);
+ return -EAGAIN;
+ default:
+ dev_dbg(ec_dev-dev, command 0x%02x returned %d\n,
+ msg-command, msg-result);
+ return 0;
+ }
+}
+EXPORT_SYMBOL(cros_ec_check_result);
+
static irqreturn_t ec_irq_thread(int irq, void *data)
{
struct cros_ec_device *ec_dev = data;
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 5bb32f5..189e7d1 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -92,12 +92,10 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
}
/* check response error code */
- if (i2c_msg[1].buf[0]) {
- dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
-msg-command, i2c_msg[1].buf[0]);
- ret = -EINVAL;
+ msg-result = i2c_msg[1].buf[0];
+ ret = cros_ec_check_result(ec_dev, msg);
+ if (ret)
goto done;
- }
/* copy response packet payload and compute checksum */
sum = in_buf[0] + in_buf[1];
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 09ca789..c975087 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -289,21 +289,14 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
goto exit;
}
- /* check response error code */
ptr = ec_dev-din;
- if (ptr[0]) {
- if (ptr[0] == EC_RES_IN_PROGRESS) {
- dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
- ec_msg-command);
- ret = -EAGAIN;
- goto exit;
- }
- dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
-ec_msg-command, ptr[0]);
- debug_packet(ec_dev-dev, in_err, ptr, len);
- ret = -EINVAL;
+
+ /* check response error code */
+ ec_msg-result = ptr[0];
+ ret = cros_ec_check_result(ec_dev, ec_msg);
+ if (ret)
goto exit;
- }
+
len = ptr[1];
sum = ptr[0] + ptr[1];
if (len ec_msg-insize) {
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 60c0880..1f79f16 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -143,6 +143,18 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg);
/**
+ * cros_ec_check_result - Check ec_msg-result
+ *
+ * This is used by ChromeOS EC drivers to check the ec_msg-result for
+ * errors and to warn about them.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to check
+ */
+int cros_ec_check_result(struct cros_ec_device *ec_dev,
+struct cros_ec_command *msg);
+
+/**
* cros_ec_remove - Remove a ChromeOS EC
*
* Call this to deregister a ChromeOS EC, then clean up any private data.
--
2.0.0.526.g5318336
--
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 04/10] mdf: cros_ec: Detect in-progress commands
From: Simon Glass s...@chromium.org
Some commands take a while to execute. Use -EAGAIN to signal this to the
caller.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v2: None
drivers/mfd/cros_ec_spi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 52d4d7b..c29a2d7 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -292,6 +292,12 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
/* check response error code */
ptr = ec_dev-din;
if (ptr[0]) {
+ if (ptr[0] == EC_RES_IN_PROGRESS) {
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ ec_msg-cmd);
+ ret = -EAGAIN;
+ goto exit;
+ }
dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
ec_msg-cmd, ptr[0]);
debug_packet(ec_dev-dev, in_err, ptr, len);
--
2.0.0.526.g5318336
--
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 02/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()
From: Bill Richardson wfric...@chromium.org
The lower-level driver may want to provide its own buffers. If so,
there's no need to allocate new ones. This already happens to work
just fine (since we check for size of 0 and use devm allocation), but
it's good to document it.
[dianders: Resolved conflicts; documented that no code changes needed
on mainline]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v2: None
include/linux/mfd/cros_ec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 7e9fe6e..2ee3190 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -68,8 +68,8 @@ struct cros_ec_msg {
* We use this alignment to keep ARM and x86 happy. Probably word
* alignment would be OK, there might be a small performance advantage
* to using dword.
- * @din_size: size of din buffer
- * @dout_size: size of dout buffer
+ * @din_size: size of din buffer to allocate (zero to use static din)
+ * @dout_size: size of dout buffer to allocate (zero to use static dout)
* @command_send: send a command
* @command_recv: receive a command
* @ec_name: name of EC device (e.g. 'chromeos-ec')
--
2.0.0.526.g5318336
--
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 05/10] mfd: cros_ec: Use struct cros_ec_command to communicate with the EC
From: Bill Richardson wfric...@chromium.org
This is some internal structure reorganization / renaming to prepare
for future patches that will add a userspace API to cros_ec. There
should be no visible changes.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v2: None
drivers/mfd/cros_ec.c | 28 ++--
drivers/mfd/cros_ec_i2c.c | 24
drivers/mfd/cros_ec_spi.c | 16
include/linux/mfd/cros_ec.h | 35 ++-
4 files changed, 52 insertions(+), 51 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 04e053c..2e86c28 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -25,22 +25,22 @@
#include linux/mfd/cros_ec_commands.h
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *msg)
+ struct cros_ec_command *msg)
{
uint8_t *out;
int csum, i;
- BUG_ON(msg-out_len EC_PROTO2_MAX_PARAM_SIZE);
+ BUG_ON(msg-outsize EC_PROTO2_MAX_PARAM_SIZE);
out = ec_dev-dout;
out[0] = EC_CMD_VERSION0 + msg-version;
- out[1] = msg-cmd;
- out[2] = msg-out_len;
+ out[1] = msg-command;
+ out[2] = msg-outsize;
csum = out[0] + out[1] + out[2];
- for (i = 0; i msg-out_len; i++)
- csum += out[EC_MSG_TX_HEADER_BYTES + i] = msg-out_buf[i];
- out[EC_MSG_TX_HEADER_BYTES + msg-out_len] = (uint8_t)(csum 0xff);
+ for (i = 0; i msg-outsize; i++)
+ csum += out[EC_MSG_TX_HEADER_BYTES + i] = msg-outdata[i];
+ out[EC_MSG_TX_HEADER_BYTES + msg-outsize] = (uint8_t)(csum 0xff);
- return EC_MSG_TX_PROTO_BYTES + msg-out_len;
+ return EC_MSG_TX_PROTO_BYTES + msg-outsize;
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
@@ -48,14 +48,14 @@ static int cros_ec_command_sendrecv(struct cros_ec_device
*ec_dev,
uint16_t cmd, void *out_buf, int out_len,
void *in_buf, int in_len)
{
- struct cros_ec_msg msg;
+ struct cros_ec_command msg;
msg.version = cmd 8;
- msg.cmd = cmd 0xff;
- msg.out_buf = out_buf;
- msg.out_len = out_len;
- msg.in_buf = in_buf;
- msg.in_len = in_len;
+ msg.command = cmd 0xff;
+ msg.outdata = out_buf;
+ msg.outsize = out_len;
+ msg.indata = in_buf;
+ msg.insize = in_len;
return ec_dev-cmd_xfer(ec_dev, msg);
}
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 777e529..37ed12f 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -30,7 +30,7 @@ static inline struct cros_ec_device *to_ec_dev(struct device
*dev)
}
static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
- struct cros_ec_msg *msg)
+ struct cros_ec_command *msg)
{
struct i2c_client *client = ec_dev-priv;
int ret = -ENOMEM;
@@ -50,7 +50,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
* allocate larger packet (one byte for checksum, one byte for
* length, and one for result code)
*/
- packet_len = msg-in_len + 3;
+ packet_len = msg-insize + 3;
in_buf = kzalloc(packet_len, GFP_KERNEL);
if (!in_buf)
goto done;
@@ -61,7 +61,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device *ec_dev,
* allocate larger packet (one byte for checksum, one for
* command code, one for length, and one for command version)
*/
- packet_len = msg-out_len + 4;
+ packet_len = msg-outsize + 4;
out_buf = kzalloc(packet_len, GFP_KERNEL);
if (!out_buf)
goto done;
@@ -69,16 +69,16 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
i2c_msg[0].buf = (char *)out_buf;
out_buf[0] = EC_CMD_VERSION0 + msg-version;
- out_buf[1] = msg-cmd;
- out_buf[2] = msg-out_len;
+ out_buf[1] = msg-command;
+ out_buf[2] = msg-outsize;
/* copy message payload and compute checksum */
sum = out_buf[0] + out_buf[1] + out_buf[2];
- for (i = 0; i msg-out_len; i++) {
- out_buf[3 + i] = msg-out_buf[i];
+ for (i = 0; i msg-outsize; i++) {
+ out_buf[3 + i] = msg-outdata[i];
sum += out_buf[3 + i];
}
- out_buf[3 + msg-out_len] = sum;
+ out_buf[3 + msg-outsize] = sum;
/* send command to EC and read answer */
ret = i2c_transfer(client-adapter, i2c_msg, 2);
@@ -94,20 +94,20 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
/* check response error code */
if (i2c_msg[1].buf[0]) {
dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
-
[PATCH v2 07/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
From: Bill Richardson wfric...@chromium.org
Remove the three wrapper functions that talk to the EC without passing all
the desired arguments and just use the underlying communication function
that passes everything in a struct intead.
This is internal code refactoring only. Nothing should change.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Removed unneeded ret variable.
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 15 +++
drivers/input/keyboard/cros_ec_keyb.c | 12 ++--
drivers/mfd/cros_ec.c | 32
include/linux/mfd/cros_ec.h | 19 ++-
4 files changed, 27 insertions(+), 51 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 8e7a714..dd07818 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -183,6 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
u8 *request = NULL;
u8 *response = NULL;
int result;
+ struct cros_ec_command msg;
request_len = ec_i2c_count_message(i2c_msgs, num);
if (request_len 0) {
@@ -218,9 +219,15 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
}
ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
- result = bus-ec-command_sendrecv(bus-ec, EC_CMD_I2C_PASSTHRU,
- request, request_len,
- response, response_len);
+
+ msg.version = 0;
+ msg.command = EC_CMD_I2C_PASSTHRU;
+ msg.outdata = request;
+ msg.outsize = request_len;
+ msg.indata = response;
+ msg.insize = response_len;
+
+ result = bus-ec-cmd_xfer(bus-ec, msg);
if (result)
goto exit;
@@ -258,7 +265,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
u32 remote_bus;
int err;
- if (!ec-command_sendrecv) {
+ if (!ec-cmd_xfer) {
dev_err(dev, Missing sendrecv\n);
return -EINVAL;
}
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 4083796..b8341ab 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -191,8 +191,16 @@ static void cros_ec_keyb_close(struct input_dev *dev)
static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
*kb_state)
{
- return ckdev-ec-command_recv(ckdev-ec, EC_CMD_MKBP_STATE,
- kb_state, ckdev-cols);
+ struct cros_ec_command msg = {
+ .version = 0,
+ .command = EC_CMD_MKBP_STATE,
+ .outdata = NULL,
+ .outsize = 0,
+ .indata = kb_state,
+ .insize = ckdev-cols,
+ };
+
+ return ckdev-ec-cmd_xfer(ckdev-ec, msg);
}
static int cros_ec_keyb_work(struct notifier_block *nb,
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 49ed8c3..4851ed2 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -44,34 +44,6 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
-static int cros_ec_command_sendrecv(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *out_buf, int out_len,
- void *in_buf, int in_len)
-{
- struct cros_ec_command msg;
-
- msg.version = cmd 8;
- msg.command = cmd 0xff;
- msg.outdata = out_buf;
- msg.outsize = out_len;
- msg.indata = in_buf;
- msg.insize = in_len;
-
- return ec_dev-cmd_xfer(ec_dev, msg);
-}
-
-static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *buf, int buf_len)
-{
- return cros_ec_command_sendrecv(ec_dev, cmd, NULL, 0, buf, buf_len);
-}
-
-static int cros_ec_command_send(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *buf, int buf_len)
-{
- return cros_ec_command_sendrecv(ec_dev, cmd, buf, buf_len, NULL, 0);
-}
-
static irqreturn_t ec_irq_thread(int irq, void *data)
{
struct cros_ec_device *ec_dev = data;
@@ -104,10 +76,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
BLOCKING_INIT_NOTIFIER_HEAD(ec_dev-event_notifier);
- ec_dev-command_send = cros_ec_command_send;
- ec_dev-command_recv = cros_ec_command_recv;
- ec_dev-command_sendrecv = cros_ec_command_sendrecv;
-
if (ec_dev-din_size) {
ec_dev-din = devm_kzalloc(dev, ec_dev-din_size, GFP_KERNEL);
if (!ec_dev-din)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2b0c598..60c0880 100644
---
[PATCH v2 01/10] mfd: cros_ec: Fix the comment on cros_ec_remove()
From: Bill Richardson wfric...@chromium.org This comment was incorrect, so update it. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Lee Jones lee.jo...@linaro.org --- Changes in v2: None include/linux/mfd/cros_ec.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h index 887ef4f..7e9fe6e 100644 --- a/include/linux/mfd/cros_ec.h +++ b/include/linux/mfd/cros_ec.h @@ -148,8 +148,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev, /** * cros_ec_remove - Remove a ChromeOS EC * - * Call this to deregister a ChromeOS EC. After this you should call - * cros_ec_free(). + * Call this to deregister a ChromeOS EC, then clean up any private data. * * @ec_dev: Device to register * @return 0 if ok, -ve on error -- 2.0.0.526.g5318336 -- 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 06/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device
From: Bill Richardson wfric...@chromium.org
struct cros_ec_device has a superfluous name field. We can get all the
debugging info we need from the existing ec_name and phys_name fields, so
let's take out the extra field.
The printout also has sufficient info in it without explicitly adding
the transport. Before this change:
cros-ec-spi spi2.0: Chrome EC (SPI)
After this change:
cros-ec-spi spi2.0: Chrome EC device registered
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Include example printouts before/after in commit message.
drivers/mfd/cros_ec.c | 2 +-
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
include/linux/mfd/cros_ec.h | 2 --
4 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 2e86c28..49ed8c3 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -140,7 +140,7 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
goto fail_mfd;
}
- dev_info(dev, Chrome EC (%s)\n, ec_dev-name);
+ dev_info(dev, Chrome EC device registered\n);
return 0;
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 37ed12f..5bb32f5 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -132,7 +132,6 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
return -ENOMEM;
i2c_set_clientdata(client, ec_dev);
- ec_dev-name = I2C;
ec_dev-dev = dev;
ec_dev-priv = client;
ec_dev-irq = client-irq;
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 2d713fe..09ca789 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -374,7 +374,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
cros_ec_spi_dt_probe(ec_spi, dev);
spi_set_drvdata(spi, ec_dev);
- ec_dev-name = SPI;
ec_dev-dev = dev;
ec_dev-priv = ec_spi;
ec_dev-irq = spi-irq;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f27c037..2b0c598 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -67,7 +67,6 @@ struct cros_ec_command {
* @command_recv: receive a response
* @command_sendrecv: send a command and receive a response
*
- * @name: Name of this EC interface
* @priv: Private data
* @irq: Interrupt to use
* @din: input buffer (for data from EC)
@@ -104,7 +103,6 @@ struct cros_ec_device {
void *in_buf, int in_len);
/* These are used to implement the platform-specific interface */
- const char *name;
void *priv;
int irq;
uint8_t *din;
--
2.0.0.526.g5318336
--
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] clocksource: exynos-mct: Register the timer for stable udelay
Amit,
Thanks for posting!
On Wed, Jun 18, 2014 at 4:31 AM, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch register the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for the
exynos platform and avoid using unnecessary calibrated jiffies. This change
have been tested on exynos5420 based board.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
Patches from David Riley confirmed that udelay is broken in exynos5420.
Link to those patches are,
1) https://patchwork.kernel.org/patch/4344911/
2) https://patchwork.kernel.org/patch/4344881/
drivers/clocksource/exynos_mct.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 8d64200..57cb3dc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -198,10 +198,21 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_frc_read(mct_frc);
}
+static struct delay_timer exynos4_delay_timer;
+
+static unsigned long exynos4_read_current_timer(void)
+{
+ return exynos4_frc_read(mct_frc);
This is terribly inefficient to read all 64-bits and then cast back to
a 32-bit value. Replace with:
return __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
+}
+
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start(0, 0);
Please rebase atop (1d80415 clocksource: exynos_mct: Don't reset the
counter during boot and resume), which is in linuxnext among other
places.
+ exynos4_delay_timer.read_current_timer = exynos4_read_current_timer;
+ exynos4_delay_timer.freq = clk_rate;
+ register_current_timer_delay(exynos4_delay_timer);
+
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
It does seem to work for me though. :)
--
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 RFC] mfd: syscon: Decouple syscon interface from syscon devices
Hi, On 06/18/2014 02:57 PM, Arnd Bergmann wrote: On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote: On 17.06.2014 17:42, Arnd Bergmann wrote: This seems like a reasonable way of solving the problem, but I think there is an even better one that we have about in the past: if we promote syscon from a platform driver into a a drivers/base/ helper that is independent of the platform device matching, we can use call syscon_regmap_lookup_* for any device node, whether it's already bound to a driver or not, which do what you need. It would also make it easier to call the syscon code before the platform_device infrastructure gets initialized, which is something a number of people have asked for, e.g. for using regmap to do SMP bringup or for clock registration. Basically, unless I'm missing your point, this is what my patch does, except that I don't move it to drivers/base/ and the registration function I added require a pointer to struct device. Indeed, decoupling it further from the driver model, by adding of_syscon_register() should be useful for early users. I believe the part you are missing is that with the approach I suggested, there would be no registration function at all. You can easily do the lookup from the client drivers using the DT data structures, with no need for the device at all. The only exception today is the clps711x platform using syscon_regmap_lookup_by_pdevname(), but that should be solved in 3.17 when clps711x becomes DT-only. I agree with Arnd. This patch is doing the part of what we wanted to do with it. It means create a list of registered devices. But you are working with struct device which you can't use in early phase which is the feature we wanted to use. But currently we have workaround in the kernel and clk subsystem is not able to work with regmap anyway. Moving to proper location is just the last step. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
[PATCH v2] ARM: dts: exynos4: fix pwm-cells in pwm node
pwm-cells should be 3. Third cell is optional PWM flags. And This flag supported by this binding is PWM_POLARITY_INVERTED. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- Changes in v2: - Remove unnecessary handle. arch/arm/boot/dts/exynos4.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index b8ece4b..e118356 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -554,7 +554,7 @@ interrupts = 0 37 0, 0 38 0, 0 39 0, 0 40 0, 0 41 0; clocks = clock CLK_PWM; clock-names = timers; - #pwm-cells = 2; + #pwm-cells = 3; status = disabled; }; -- 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: MMC regression with linux-next on Exynos5250
Hi, all. On 06/18/2014 08:22 PM, Sachin Kamat wrote: Hi Ulf, On Wed, Jun 18, 2014 at 4:43 PM, Ulf Hansson ulf.hans...@linaro.org wrote: On 18 June 2014 13:10, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Jaehoon, On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Sachin. Did you check the below patch? https://patchwork.kernel.org/patch/4346781/ Thanks for the patch. But even with this patch, I continue to get the aforementioned crash. Hi Sachin / Jaehoon, Until we sorted out the problem, I will drop the related patch from my mmc tree. OK. Also, I feel the mmc patch and the corresponding DT changes should go through single tree to avoid dependency issues. Thanks, I will send the patch on today. Sorry for late. Best Regards, Jaehoon Chung Regards, Sachin. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC error on Exynos4210 board
On Wed, Jun 18, 2014 at 7:41 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat spk.li...@gmail.com wrote: Hi Tim, I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 mmc: sdhci: Use mmc core regulator infrastucture Any ideas? *** -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.180281] Synopsys Designware Multimedia Card Interface Driver [2.188131] usbcore: registered new interface driver usbhid [2.192287] usbhid: USB HID core driver [2.196329] TCP: cubic registered [2.199362] NET: Registered protocol family 17 [2.203917] NET: Registered protocol family 15 [2.208404] Registering SWP/SWPB emulation handler [2.214357] of_get_named_gpiod_flags exited with status 0 [2.218430] of_get_named_gpiod_flags exited with status 0 [2.223803] of_get_named_gpiod_flags exited with status 0 [2.229170] of_get_named_gpiod_flags exited with status 0 [2.234560] of_get_named_gpiod_flags exited with status 0 [2.239953] gpio-229: gpiod_set_debounce: missing set() or set_debounce() operations [2.247773] gpio-230: gpiod_set_debounce: missing set() or set_debounce() operations [2.255473] gpio-228: gpiod_set_debounce: missing set() or set_debounce() operations [2.263221] gpio-227: gpiod_set_debounce: missing set() or set_debounce() operations [2.270918] gpio-226: gpiod_set_debounce: missing set() or set_debounce() operations [2.278899] input: gpio_keys as /devices/gpio_keys/input/input0 [2.285196] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.295072] VDD_G3D_1.1V: disabling [2.304744] VADC_3.3V: disabling [2.312095] VDD_AUD_1.8V: disabling [2.319714] VMIPI_1.1V: disabling [2.327193] VDD_ABB_3.3V: disabling [2.332779] VMEM_VDD_2.8V: disabling [2.336148] Waiting for root device /dev/mmcblk0p1... * Regards, Sachin. Would you mind reverting just this part of the commit to see if it clears up your trouble? if (host-ocr_mask) - ocr_avail = host-ocr_mask; + ocr_avail = host-ocr_mask; Reverting this did not help. I still get the above error. My diff: diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index c23a87285a95..f4135094320d 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3096,7 +3096,7 @@ int sdhci_add_host(struct sdhci_host *host) ocr_avail = mmc-ocr_avail; if (host-ocr_mask) - ocr_avail = host-ocr_mask; + ocr_avail = host-ocr_mask; mmc-ocr_avail = ocr_avail; mmc-ocr_avail_sdio = ocr_avail; FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. -- Regards, Sachin. -- 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] drm/exynos: defer hdmi probe when fail to get regulators
On 2014년 06월 18일 22:42, Rahul Sharma wrote:
HDMI probe proceeds with dummy regulators when the regulators
are not provided in DT node or regulator provider has not get
probed or failed to register the regulators.
This patch modify hdmi driver to defer the probe in case the
regulators are not available.
No, already available. See the below comments.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on exynos-drm-fixes branch in Inki dae's tree.
drivers/gpu/drm/exynos/exynos_hdmi.c | 69
--
1 file changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0..3f24c49 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -83,7 +83,7 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
- struct regulator_bulk_data *regul_bulk;
+ struct regulator**regulators;
int regul_count;
};
@@ -2022,6 +2022,36 @@ static void hdmi_commit(struct exynos_drm_display
*display)
hdmi_conf_apply(hdata);
}
+int hdmi_regulator_enable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_enable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to enable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+int hdmi_regulator_disable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_disable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to disable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
static void hdmi_poweron(struct exynos_drm_display *display)
{
struct hdmi_context *hdata = display-ctx;
@@ -2039,8 +2069,8 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
pm_runtime_get_sync(hdata-dev);
- if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
- DRM_DEBUG_KMS(failed to enable regulator bulk\n);
+ if (hdmi_regulator_enable(hdata))
+ DRM_DEBUG_KMS(failed to enable regulators\n);
/* set pmu hdmiphy control bit to enable hdmiphy */
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
@@ -2077,7 +2107,8 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
- regulator_bulk_disable(res-regul_count, res-regul_bulk);
+ if (hdmi_regulator_disable(hdata))
+ DRM_DEBUG_KMS(failed to disable regulators\n);
pm_runtime_put_sync(hdata-dev);
@@ -2211,24 +2242,24 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
clk_set_parent(res-mout_hdmi, res-sclk_pixel);
- res-regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
- sizeof(res-regul_bulk[0]), GFP_KERNEL);
- if (!res-regul_bulk) {
- ret = -ENOMEM;
- goto fail;
- }
+ res-regul_count = ARRAY_SIZE(supply);
+
+ res-regulators = devm_kzalloc(dev, res-regul_count *
+ sizeof(res-regulators[0]), GFP_KERNEL);
+ if (!res-regulators)
+ return -ENOMEM;
+
for (i = 0; i ARRAY_SIZE(supply); ++i) {
- res-regul_bulk[i].supply = supply[i];
- res-regul_bulk[i].consumer = NULL;
- }
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), res-regul_bulk);
- if (ret) {
- DRM_ERROR(failed to get regulators\n);
- return ret;
+ res-regulators[i] =
+ devm_regulator_get_optional(dev, supply[i]);
+ if (IS_ERR(res-regulators[i])) {
+ DRM_ERROR(fail to get regulator: %s.\n,
+ supply[i]);
+ return -EPROBE_DEFER;
devm_regulator_get_optional function would return -EPROBE_DEFER if
needed. So it's not good to force returning -EPROBE_DEFER in case of all
errors.
Thanks,
Inki Dae
+ }
}
- res-regul_count = ARRAY_SIZE(supply);
- return ret;
+ return 0;
fail:
DRM_ERROR(HDMI resource init - failed\n);
return ret;
--
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 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
On Wed, Jun 18, 2014 at 1:21 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On 17 June 2014 20:55, Thomas Abraham thomas...@samsung.com wrote: Changes since v5: - Configuration data for cpu clock block is embedded with the code. The cpu clock logic can later to extended to obtain this data from DT. - Excluded the support for Exynos4x12 SoC since the work on boost OPP bindings is still incomplete. - Included cpufreq support for Exynos5420 SoC. - Many other minor changes (and so dropped Ack's for some of the patches in v5) This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-cpu0 driver for these platforms. This series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq driver. cpuf...@vger.kernel.org list is deprecated now: dec102a, use linux-pm instead. Ok. Will take care next time. For patch 5 and 6: Acked-by: Viresh Kumar viresh.ku...@linaro.org Thanks Viresh. Regards, Thomas. -- To unsubscribe from this list: send the line unsubscribe cpufreq in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/3] cpufreq: Use cpufreq-cpu0 driver for Exynos3250
On Wed, Jun 18, 2014 at 2:09 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this patchset is based on following patchset[1] by Thomas Abraham. [1] http://www.spinics.net/lists/arm-kernel/msg339392.html Changes from v1: - Rebased on new patchset[1] by Thomas Abraham - Modify clk-cpu.c to support Exynos3250 - Drop documentation patch on previous patchset[2] [2] http://www.spinics.net/lists/cpufreq/msg10265.html - Add only operating-points for Exynos3250 without armclk-divider-table Chanwoo Choi (3): clk: samsung: cpu: Add support for cpu clocks of Exynos3250 clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq ARM: dts: Exynos: Add cpu clock table for Exynos3250 arch/arm/boot/dts/exynos3250.dtsi| 15 +++ drivers/clk/samsung/clk-cpu.c| 31 +++ drivers/clk/samsung/clk-exynos3250.c | 14 ++ 3 files changed, 56 insertions(+), 4 deletions(-) Hi Chanwoo, I have reviewed this series and it looks fine. If the cpu clock type is merged without any further changes, please add Reviewed-by: Thomas Abraham thomas...@samsung.com Thanks, Thomas. -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [PATCHv2 0/3] cpufreq: Use cpufreq-cpu0 driver for Exynos3250
Hi Thomas, On 06/19/2014 01:21 PM, Thomas Abraham wrote: On Wed, Jun 18, 2014 at 2:09 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this patchset is based on following patchset[1] by Thomas Abraham. [1] http://www.spinics.net/lists/arm-kernel/msg339392.html Changes from v1: - Rebased on new patchset[1] by Thomas Abraham - Modify clk-cpu.c to support Exynos3250 - Drop documentation patch on previous patchset[2] [2] http://www.spinics.net/lists/cpufreq/msg10265.html - Add only operating-points for Exynos3250 without armclk-divider-table Chanwoo Choi (3): clk: samsung: cpu: Add support for cpu clocks of Exynos3250 clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq ARM: dts: Exynos: Add cpu clock table for Exynos3250 arch/arm/boot/dts/exynos3250.dtsi| 15 +++ drivers/clk/samsung/clk-cpu.c| 31 +++ drivers/clk/samsung/clk-exynos3250.c | 14 ++ 3 files changed, 56 insertions(+), 4 deletions(-) Hi Chanwoo, I have reviewed this series and it looks fine. If the cpu clock type is merged without any further changes, please add Reviewed-by: Thomas Abraham thomas...@samsung.com Thanks for your review. Best Regards, 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] drm/exynos: defer hdmi probe when fail to get regulators
Thanks Inki,
On 19 June 2014 09:34, Inki Dae inki@samsung.com wrote:
On 2014년 06월 18일 22:42, Rahul Sharma wrote:
HDMI probe proceeds with dummy regulators when the regulators
are not provided in DT node or regulator provider has not get
probed or failed to register the regulators.
This patch modify hdmi driver to defer the probe in case the
regulators are not available.
No, already available. See the below comments.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on exynos-drm-fixes branch in Inki dae's tree.
drivers/gpu/drm/exynos/exynos_hdmi.c | 69
--
1 file changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0..3f24c49 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -83,7 +83,7 @@ struct hdmi_resources {
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
struct clk *mout_hdmi;
- struct regulator_bulk_data *regul_bulk;
+ struct regulator**regulators;
int regul_count;
};
@@ -2022,6 +2022,36 @@ static void hdmi_commit(struct exynos_drm_display
*display)
hdmi_conf_apply(hdata);
}
+int hdmi_regulator_enable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_enable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to enable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
+int hdmi_regulator_disable(struct hdmi_context *hdata)
+{
+ struct hdmi_resources *res = hdata-res;
+ int i, ret;
+
+ for (i = 0; i res-regul_count; ++i) {
+ ret = regulator_disable(res-regulators[i]);
+ if (ret 0) {
+ DRM_ERROR(fail to disable regulators.\n);
+ return ret;
+ }
+ }
+ return 0;
+}
+
static void hdmi_poweron(struct exynos_drm_display *display)
{
struct hdmi_context *hdata = display-ctx;
@@ -2039,8 +2069,8 @@ static void hdmi_poweron(struct exynos_drm_display
*display)
pm_runtime_get_sync(hdata-dev);
- if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
- DRM_DEBUG_KMS(failed to enable regulator bulk\n);
+ if (hdmi_regulator_enable(hdata))
+ DRM_DEBUG_KMS(failed to enable regulators\n);
/* set pmu hdmiphy control bit to enable hdmiphy */
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
@@ -2077,7 +2107,8 @@ static void hdmi_poweroff(struct exynos_drm_display
*display)
regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
- regulator_bulk_disable(res-regul_count, res-regul_bulk);
+ if (hdmi_regulator_disable(hdata))
+ DRM_DEBUG_KMS(failed to disable regulators\n);
pm_runtime_put_sync(hdata-dev);
@@ -2211,24 +2242,24 @@ static int hdmi_resources_init(struct hdmi_context
*hdata)
clk_set_parent(res-mout_hdmi, res-sclk_pixel);
- res-regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
- sizeof(res-regul_bulk[0]), GFP_KERNEL);
- if (!res-regul_bulk) {
- ret = -ENOMEM;
- goto fail;
- }
+ res-regul_count = ARRAY_SIZE(supply);
+
+ res-regulators = devm_kzalloc(dev, res-regul_count *
+ sizeof(res-regulators[0]), GFP_KERNEL);
+ if (!res-regulators)
+ return -ENOMEM;
+
for (i = 0; i ARRAY_SIZE(supply); ++i) {
- res-regul_bulk[i].supply = supply[i];
- res-regul_bulk[i].consumer = NULL;
- }
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply),
res-regul_bulk);
- if (ret) {
- DRM_ERROR(failed to get regulators\n);
- return ret;
+ res-regulators[i] =
+ devm_regulator_get_optional(dev, supply[i]);
+ if (IS_ERR(res-regulators[i])) {
+ DRM_ERROR(fail to get regulator: %s.\n,
+ supply[i]);
+ return -EPROBE_DEFER;
devm_regulator_get_optional function would return -EPROBE_DEFER if
needed. So it's not good to force returning -EPROBE_DEFER in case of all
errors.
Yea you are right. Its returning -EPROBE_DEFER. I will change this in next
version.
Regards,
Rahul Sharma.
Thanks,
Inki Dae
+ }
}
- res-regul_count = ARRAY_SIZE(supply);
- return ret;
+ return 0;
fail:
DRM_ERROR(HDMI resource init - failed\n);
return ret;
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body
[PATCH] i2c: s3c2410: resume the I2C controller earlier
From: Vincent Palatin vpala...@chromium.org
When the wake-up is triggered by the PMIC RTC, the RTC driver is trying
to read the PMIC interrupt status over I2C and fails because the I2C
controller is not resumed yet.
Let's resume the I2C controller earlier in the _noirq phase
(as other hardwares are doing), so we can properly get the wake-up
condition.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index e828a1d..b904132 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1267,7 +1267,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
return 0;
}
-static int s3c24xx_i2c_resume(struct device *dev)
+static int s3c24xx_i2c_resume_noirq(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
@@ -1285,7 +1285,7 @@ static int s3c24xx_i2c_resume(struct device *dev)
static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
#ifdef CONFIG_PM_SLEEP
.suspend_noirq = s3c24xx_i2c_suspend_noirq,
- .resume = s3c24xx_i2c_resume,
+ .resume_noirq = s3c24xx_i2c_resume_noirq,
#endif
};
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume
The original code for the exynos i2c controller registered for the
noirq variants. However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually noirq (despite functions named
exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq).
i2c controllers that might have wakeup sources on them seem to need to
resume at noirq time so that the individual drivers can actually read
the i2c bus to handle their wakeup.
NOTE: I took the original review feedback from Wolfram and added
poweroff, thaw, freeze, restore.
This patch has only been compile-tested since I don't have all the
patches needed to make my machine using this i2c driver actually
suspend/resume.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-exynos5.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..cba740c 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -789,8 +789,14 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
}
#endif
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
-exynos5_i2c_resume_noirq);
+const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
+ .suspend_noirq = exynos5_i2c_suspend_noirq,
+ .resume_noirq = exynos5_i2c_resume_noirq,
+ .freeze_noirq = exynos5_i2c_suspend_noirq,
+ .thaw_noirq = exynos5_i2c_resume_noirq,
+ .poweroff_noirq = exynos5_i2c_suspend_noirq,
+ .restore_noirq = exynos5_i2c_resume_noirq,
+};
static struct platform_driver exynos5_i2c_driver = {
.probe = exynos5_i2c_probe,
--
2.0.0.526.g5318336
--
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] i2c: s3c2410: resume the I2C controller earlier
Hi,
On Wed, Jun 18, 2014 at 9:54 PM, Doug Anderson diand...@chromium.org wrote:
From: Vincent Palatin vpala...@chromium.org
When the wake-up is triggered by the PMIC RTC, the RTC driver is trying
to read the PMIC interrupt status over I2C and fails because the I2C
controller is not resumed yet.
Let's resume the I2C controller earlier in the _noirq phase
(as other hardwares are doing), so we can properly get the wake-up
condition.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e828a1d..b904132 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1267,7 +1267,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
return 0;
}
-static int s3c24xx_i2c_resume(struct device *dev)
+static int s3c24xx_i2c_resume_noirq(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
@@ -1285,7 +1285,7 @@ static int s3c24xx_i2c_resume(struct device *dev)
static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
#ifdef CONFIG_PM_SLEEP
.suspend_noirq = s3c24xx_i2c_suspend_noirq,
- .resume = s3c24xx_i2c_resume,
+ .resume_noirq = s3c24xx_i2c_resume_noirq,
I looked at applying this to another i2c controller and stumbled upon
feedback from Wolfram suggesting that I should add poweroff, thaw,
freeze, restore. I'm happy to squash that into this patch or send a
separate patch if people would like it. Just let me know.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk/exynos5250: fix bit number for tv sysmmu clock
Change bit from 2 to 9 for tv (mixer) sysmmu clock.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Based on Kukjin's for-next branch.
drivers/clk/samsung/clk-exynos5250.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 1fad4c5..184f642 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -661,7 +661,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
GATE(CLK_RTC, rtc, div_aclk66, GATE_IP_PERIS, 20, 0, 0),
GATE(CLK_TMU, tmu, div_aclk66, GATE_IP_PERIS, 21, 0, 0),
GATE(CLK_SMMU_TV, smmu_tv, mout_aclk200_disp1_sub,
- GATE_IP_DISP1, 2, 0, 0),
+ GATE_IP_DISP1, 9, 0, 0),
GATE(CLK_SMMU_FIMD1, smmu_fimd1, mout_aclk200_disp1_sub,
GATE_IP_DISP1, 8, 0, 0),
GATE(CLK_SMMU_2D, smmu_2d, div_aclk200, GATE_IP_ACP, 7, 0, 0),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
