Re: [PATCH] drm/exynos: update to use component match support
On 2014년 09월 10일 19:24, Andrzej Hajda wrote:
Hi Inki,
To test it properly I have to fix init/remove bugs [1].
Of course these bugs were not introduced by this patch,
but they prevented some basic tests.
I had tested my patch with trats2 board, and works well without below
patch set. hm.. it seems that there is other corner cases I missed. Can
you give me more details about basic tests?
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
I have tested successfully your patch with trats and universal_c210 boards.
Thanks for testing and above fixup patch set. Will look into them soon. :)
Thanks,
Inki Dae
Few additional comments below.
On 09/01/2014 02:19 PM, Inki Dae wrote:
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40
++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
Nitpick.
This is not a part of this patch but compare_of suggests it compares OF
nodes but this function compares devices, maybe compare_dev would be better.
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(drm_component_lock);
list_for_each_entry(cdev, drm_component_list, list) {
-int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device
*dev, struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
- *
- * TODO. if dpi module follows driver-model driver then
- * below codes can be removed.
*/
if (cdev-crtc_dev == cdev-conn_dev) {
-ret = component_master_add_child(m, compare_of,
-cdev-crtc_dev);
-if (ret 0)
-return ret;
-
+component_match_add(dev, match, compare_of,
+cdev-crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device
*dev, struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
-ret = component_master_add_child(m, compare_of, cdev-crtc_dev);
-ret |= component_master_add_child(m, compare_of,
-cdev-conn_dev);
-if (ret 0)
-return ret;
+component_match_add(dev, match, compare_of, cdev-crtc_dev);
+component_match_add(dev, match, compare_of, cdev-conn_dev);
out_lock:
mutex_lock(drm_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(drm_component_lock);
-return attach_cnt ? 0 : -ENODEV;
+return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
-.add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+struct component_match *match;
int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
-ret = component_master_add(pdev-dev, exynos_drm_ops);
-if (ret 0)
-DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
+match = exynos_drm_match_add(pdev-dev);
+if (IS_ERR(match)) {
+ret = PTR_ERR(match);
+goto err_unregister_ipp_dev;
+}
-return 0;
+return component_master_add_with_match(pdev-dev, exynos_drm_ops,
+match);
In case component_master_add_with_match fails there will be no cleanup -
platform devices and drivers will not be
Re: [PATCH] drm/exynos: update to use component match support
On 09/11/2014 08:37 AM, Inki Dae wrote:
On 2014년 09월 10일 19:24, Andrzej Hajda wrote:
Hi Inki,
To test it properly I have to fix init/remove bugs [1].
Of course these bugs were not introduced by this patch,
but they prevented some basic tests.
I had tested my patch with trats2 board, and works well without below
patch set. hm.. it seems that there is other corner cases I missed. Can
you give me more details about basic tests?
As the component framework is about bringing up/down the master when
all/some components becomes available/unavailable I have tested
what happens when I change availability of components using bind/unbind
sysfs properties, for example:
echo 11c8.dsi /sys/bus/platform/drivers/exynos-dsi/unbind
echo 11c8.dsi /sys/bus/platform/drivers/exynos-dsi/bind
Regards
Andrzej
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
I have tested successfully your patch with trats and universal_c210 boards.
Thanks for testing and above fixup patch set. Will look into them soon. :)
Thanks,
Inki Dae
Few additional comments below.
On 09/01/2014 02:19 PM, Inki Dae wrote:
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40
++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
Nitpick.
This is not a part of this patch but compare_of suggests it compares OF
nodes but this function compares devices, maybe compare_dev would be better.
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(drm_component_lock);
list_for_each_entry(cdev, drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device
*dev, struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev-crtc_dev == cdev-conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev-crtc_dev);
- if (ret 0)
- return ret;
-
+ component_match_add(dev, match, compare_of,
+ cdev-crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device
*dev, struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev-crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev-conn_dev);
- if (ret 0)
- return ret;
+ component_match_add(dev, match, compare_of, cdev-crtc_dev);
+ component_match_add(dev, match, compare_of, cdev-conn_dev);
out_lock:
mutex_lock(drm_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(pdev-dev, exynos_drm_ops);
- if (ret 0)
- DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
+ match = exynos_drm_match_add(pdev-dev);
+ if
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Hey Lee,
On Wed, 2014-09-10 at 10:28 +0100, Lee Jones wrote:
On Tue, 09 Sep 2014, Javier Martinez Canillas wrote:
[adding Lee Jones to cc list since I'm referring on a series he posted]
Hello Sjoerd,
On 09/09/2014 09:52 AM, Sjoerd Simons wrote:
For i2c devices in OF the modalias exposed to userspace is i2c:node
type, for the Maxtouch driver this is i2c:maxtouch.
Add maxtouch to the i2c id table such that userspace can correctly
load the module for the device and drop the OF table as it's not
needed for i2c devices.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index db178ed..57ff26d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2267,16 +2267,11 @@ static int mxt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mxt_pm_ops, mxt_suspend, mxt_resume);
-static const struct of_device_id mxt_of_match[] = {
- { .compatible = atmel,maxtouch, },
- {},
-};
-MODULE_DEVICE_TABLE(of, mxt_of_match);
-
static const struct i2c_device_id mxt_id[] = {
{ qt602240_ts, 0 },
{ atmel_mxt_ts, 0 },
{ atmel_mxt_tp, 0 },
+ { maxtouch, 0 },
{ mXT224, 0 },
{ }
};
@@ -2286,7 +2281,6 @@ static struct i2c_driver mxt_driver = {
.driver = {
.name = atmel_mxt_ts,
.owner = THIS_MODULE,
- .of_match_table = of_match_ptr(mxt_of_match),
.pm = mxt_pm_ops,
},
.probe = mxt_probe,
I see that Lee is working to allow the I2C subsystem to not need an I2C ID
table to match [0]. I'll let Lee to comment what the future plans are and if
his series are going to solve your issue since I'm not that familiar with
the
I2C core.
It's wrong to expect DT to probe these devices without a compatible
string. It does so at the moment, but this is a bi-product and not
the correct method.
Ok, which means removing the mxt_of_match table in this patch is wrong..
I'll fix that for for a V2.
However that makes adding the maxtouch string to the i2c device table
somewhat cumbersome as it only gets added in this case to ensure
module-autoloading can happen as the modalias presented to userspace is
going still going to be i2c:maxtouch.
Tbh, the bigger problem this is pointing out is that for I2C devices
with only an OF compability tring module auto-loading is broken...
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Hello Lee,
On 09/11/2014 10:00 AM, Sjoerd Simons wrote:
-static const struct of_device_id mxt_of_match[] = {
-{ .compatible = atmel,maxtouch, },
-{},
-};
-MODULE_DEVICE_TABLE(of, mxt_of_match);
-
static const struct i2c_device_id mxt_id[] = {
{ qt602240_ts, 0 },
{ atmel_mxt_ts, 0 },
{ atmel_mxt_tp, 0 },
+{ maxtouch, 0 },
{ mXT224, 0 },
{ }
};
@@ -2286,7 +2281,6 @@ static struct i2c_driver mxt_driver = {
.driver = {
.name = atmel_mxt_ts,
.owner = THIS_MODULE,
-.of_match_table = of_match_ptr(mxt_of_match),
.pm = mxt_pm_ops,
},
.probe = mxt_probe,
I see that Lee is working to allow the I2C subsystem to not need an I2C ID
table to match [0]. I'll let Lee to comment what the future plans are and
if
his series are going to solve your issue since I'm not that familiar with
the
I2C core.
It's wrong to expect DT to probe these devices without a compatible
string. It does so at the moment, but this is a bi-product and not
the correct method.
Ok, which means removing the mxt_of_match table in this patch is wrong..
I'll fix that for for a V2.
However that makes adding the maxtouch string to the i2c device table
somewhat cumbersome as it only gets added in this case to ensure
module-autoloading can happen as the modalias presented to userspace is
going still going to be i2c:maxtouch.
Tbh, the bigger problem this is pointing out is that for I2C devices
with only an OF compability tring module auto-loading is broken...
To expand on what Sjoerd already said and just to be sure everyone is on the
same page.
The problem is that right now the driver reports the following modalias:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
but if you look at the module information, that is not a valid alias:
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
alias: of:N*T*Catmel,maxtouch*
which means that udev/kmod can't load the module automatically based on the
alias information.
The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:maxtouch
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
which matches the reported uevent so the module will be auto-loaded.
This is because the I2C subsystem hardcodes i2c:client-name, if you look at
drivers/i2c/i2c-core.c:
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
...
if (add_uevent_var(env, MODALIAS=%s%s,
I2C_MODULE_PREFIX, client-name))
...
}
I've looked at Lee's series and AFAICT that remains the same so I second
Sjoerd that module auto-loading will continue to be broken.
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 5/7] arm64: dts: Add initial device tree support for EXYNOS7
On 9 September 2014 08:58, kg...@kernel.org wrote:
Naveen Krishna Chatradhi wrote:
Add initial device tree nodes for EXYNOS7 SoC and board dts file
to support Espresso board based on Exynos7 SoC.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm64/boot/dts/Makefile|1 +
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 31 +
arch/arm64/boot/dts/exynos/exynos7.dtsi | 168
+++
3 files changed, 200 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
[...]
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
new file mode 100644
index 000..e593af55
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -0,0 +1,168 @@
+/*
+ * SAMSUNG EXYNOS7 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clock/exynos7-clk.h
+
+/ {
+ compatible = samsung,exynos7;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #address-cells = 1; ?
Hmm...I can't see any 64-bit address here.
All the SoC peripherals have been put into the soc node and ranges
property in that node is used to convert 64-bit to 32-bit addresses.
But since this is a 64-bit SoC, we use #address-cells as 2.
+ #size-cells = 2;
+
[...]
+
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0 0 0x1800;
+
+ chipid@1000 {
+ compatible = samsung,exynos4210-chipid;
+ reg = 0x1000 0x100;
+ };
Maybe this is not required? There is no check chipid in arm/arm64.
This is only describing the hardware and it does not depend on linux
using this information. And support for chip id can be used later for
64-bit Exynos platforms as well.
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+ 1 14 0xff01,
+ 1 11 0xff01,
+ 1 10 0xff01;
clock-frequency ?
That is programmed by the bootloader / firmware.
[...]
- Kukjin
Thanks,
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
On Wed, 10 Sep 2014 15:31:44 +0100, Mark Brown broo...@kernel.org wrote:
On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote:
On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
Well, lets see... We've got a real user complaining about a platform
that used to work on mainline, and no longer does. The only loophole
for ignoring breakage is if there nobody cares that it is broken. That
currently isn't the case. So even though it's based on a patch that
has DO NOT SUBMIT in large friendly letters on the front cover, it
doesn't change the situation that mainline has a regression.
Yeah, I'm with you on this Grant, it doesn't matter what the patch is
labelled as.
One way to deal with this could be to add a quirk at boot time --
looking for the simplefb and if found, modifies the regulators to keep
them on. That'd go in the kernel, not in firmware.
Well, we should also be fixing simplefb to manage the resources it uses
though that doesn't clean up after the broken DTs that are currently
deployed.
As well as the regulators we'll also need to fix the clocks. If we're
going to start adding these fixups perhaps we want to consider having a
wrapper stage that deals with rewriting DTs prior to trying to use them?
I'm not sure if it makes much difference but there's overlap with other
tools like the ATAGs conversion wrapper and building separately would
let the fixup code run early without directly going into the early init
code (which seems a bit scary).
We've already got a dt fixup hook in the machine struct, created for
exactly this reason. Fixing an incorrect DT provided by firmware:
arch/arm/include/asm/mach/arch.h:
struct machine_desc {
...
void (*dt_fixup)(void);
...
g.
--
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] Input: atmel_mxt_ts: Add of node type to the i2c table
On 11/09/14 09:38, Javier Martinez Canillas wrote:
To expand on what Sjoerd already said and just to be sure everyone is on the
same page.
The problem is that right now the driver reports the following modalias:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
but if you look at the module information, that is not a valid alias:
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
alias: of:N*T*Catmel,maxtouch*
which means that udev/kmod can't load the module automatically based on the
alias information.
The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:maxtouch
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
which matches the reported uevent so the module will be auto-loaded.
This is because the I2C subsystem hardcodes i2c:client-name, if you look at
drivers/i2c/i2c-core.c:
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
...
if (add_uevent_var(env, MODALIAS=%s%s,
I2C_MODULE_PREFIX, client-name))
...
}
I've looked at Lee's series and AFAICT that remains the same so I second
Sjoerd that module auto-loading will continue to be broken.
Thanks for the clear explanation.
The i2c aliases are a bit confusing. The original device the driver was
written for was called qt602240, which was renamed by Atmel to mXT224 when
the chip series was called maXTouch. The driver now actually supports
many other chips which aren't listed (more than 20 devices that I've
personally tested). I could add them all, but it would be an extremely long
list. It may be preferable to use the generic name maXTouch.
So I think the sensible thing to do here would be to add maxtouch to the
i2c list to fix the module autoload issue.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 05:29:32PM +0100, Grant Likely wrote: What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit. It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency. I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints. g. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/6] mfd: cros_ec: stop calling -cmd_xfer() directly
From: Andrew Bresticker abres...@chromium.org
Instead of having users of the ChromeOS EC call the interface-specific
cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
to use instead. This will allow us to put all the locking and retry
logic in one place instead of duplicating it across the different
drivers.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 7 +++
include/linux/mfd/cros_ec.h | 24 ++--
4 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 97e6369..ec5c38d 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -229,7 +229,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
msg.indata = response;
msg.insize = response_len;
- result = bus-ec-cmd_xfer(bus-ec, msg);
+ result = cros_ec_cmd_xfer(bus-ec, msg);
if (result 0)
goto exit;
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 8c09b3e..462bfcb 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -157,7 +157,7 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb
*ckdev, uint8_t *kb_state)
.insize = ckdev-cols,
};
- return ckdev-ec-cmd_xfer(ckdev-ec, msg);
+ return cros_ec_cmd_xfer(ckdev-ec, msg);
}
static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4873f9c..a9faebd 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -62,6 +62,13 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_check_result);
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+struct cros_ec_command *msg)
+{
+ return ec_dev-cmd_xfer(ec_dev, msg);
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
static const struct mfd_cell cros_devs[] = {
{
.name = cros-ec-keyb,
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index fcbe9d1..0e166b9 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -62,10 +62,6 @@ struct cros_ec_command {
* @dev: Device pointer
* @was_wake_device: true if this device was set to wake the system from
* sleep at the last suspend
- * @cmd_xfer: send command to EC and get response
- * Returns the number of bytes received if the communication succeeded, but
- * that doesn't mean the EC was happy with the command. The caller
- * should check msg.result for the EC's result code.
*
* @priv: Private data
* @irq: Interrupt to use
@@ -82,6 +78,10 @@ struct cros_ec_command {
* @dout_size: size of dout buffer to allocate (zero to use static dout)
* @parent: pointer to parent device (e.g. i2c or spi device)
* @wake_enabled: true if this device can wake the system from sleep
+ * @cmd_xfer: send command to EC and get response
+ * Returns the number of bytes received if the communication succeeded, but
+ * that doesn't mean the EC was happy with the command. The caller
+ * should check msg.result for the EC's result code.
* @lock: one transaction at a time
*/
struct cros_ec_device {
@@ -92,8 +92,6 @@ struct cros_ec_device {
struct device *dev;
bool was_wake_device;
struct class *cros_class;
- int (*cmd_xfer)(struct cros_ec_device *ec,
- struct cros_ec_command *msg);
/* These are used to implement the platform-specific interface */
void *priv;
@@ -104,6 +102,8 @@ struct cros_ec_device {
int dout_size;
struct device *parent;
bool wake_enabled;
+ int (*cmd_xfer)(struct cros_ec_device *ec,
+ struct cros_ec_command *msg);
struct mutex lock;
};
@@ -153,6 +153,18 @@ int cros_ec_check_result(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg);
/**
+ * cros_ec_cmd_xfer - Send a command to the ChromeOS EC
+ *
+ * Call this to send a command to the ChromeOS EC. This should be used
+ * instead of calling the EC's cmd_xfer() callback directly.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ */
+int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
+struct cros_ec_command *msg);
+
+/**
* cros_ec_remove - Remove a ChromeOS EC
*
* Call this to deregister a ChromeOS EC, then clean up any private data.
--
2.1.0
--
To unsubscribe from this list: send the line
[PATCH v3 5/6] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Andrew Bresticker abres...@chromium.org
When an EC command returns EC_RES_IN_PROGRESS, we need to query
the state of the EC until it indicates that it is no longer busy.
Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
it is working on the in-progress command.
The delay in milliseconds and the number of retries are the values
that were used by the flashrom tool when retrying commands.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- Explain in the commit message from where the delay and retry values come
from.
Commented by Andrew Bresticker.
- Move the needed definitions inside the if block. Suggested by Lee Jones.
- Only check if result is EC_RES_IN_PROGRESS instead of checking also if ret is
-EAGAIN since the former implies the later. Suggested by Lee Jones.
- Use usleep_range() instead of msleep() since doesn't handle values between
1~20.
Suggested by Lee Jones.
Changes since v1:
- The *xfer() calls don't modify the passed cros_ec_command so there is
no need to populate it inside the for loop. Suggested by Lee Jones.
drivers/mfd/cros_ec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c53804a..af2fadf 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -23,6 +23,10 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
#include linux/mfd/cros_ec_commands.h
+#include linux/delay.h
+
+#define EC_COMMAND_RETRIES 50
+#define EC_RETRY_DELAY_MS 10
int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
@@ -69,6 +73,36 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
mutex_lock(ec_dev-lock);
ret = ec_dev-cmd_xfer(ec_dev, msg);
+ if (msg-result == EC_RES_IN_PROGRESS) {
+ int i;
+ struct cros_ec_command status_msg;
+ struct ec_response_get_comms_status status;
+
+ status_msg.version = 0;
+ status_msg.command = EC_CMD_GET_COMMS_STATUS;
+ status_msg.outdata = NULL;
+ status_msg.outsize = 0;
+ status_msg.indata = (uint8_t *)status;
+ status_msg.insize = sizeof(status);
+
+ /*
+* Query the EC's status until it's no longer busy or
+* we encounter an error.
+*/
+ for (i = 0; i EC_COMMAND_RETRIES; i++) {
+ usleep_range(EC_RETRY_DELAY_MS, EC_RETRY_DELAY_MS + 1);
+
+ ret = ec_dev-cmd_xfer(ec_dev, status_msg);
+ if (ret 0)
+ break;
+
+ msg-result = status_msg.result;
+ if (status_msg.result != EC_RES_SUCCESS)
+ break;
+ if (!(status.flags EC_COMMS_STATUS_PROCESSING))
+ break;
+ }
+ }
mutex_unlock(ec_dev-lock);
return ret;
--
2.1.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
[PATCH v3 6/6] mfd: cros_ec: Instantiate sub-devices from device tree
From: Todd Broch tbr...@chromium.org
If the EC device tree node has sub-nodes, try to instantiate them as
MFD sub-devices. We can configure the EC features provided by the board.
Signed-off-by: Todd Broch tbr...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- Drop if guards since of_node is unconditionally built. Suggested by Lee Jones
- Drop unneeded comment about of_platform_populate(). Suggested by Lee Jones.
- Fix error message if of_platform_populate() fails. Suggested by Lee Jones.
Changes since v1:
- Don't leave an empty struct mfd_cell array. Suggested by Lee Jones.
- Just use of_platform_populate() instead of manually iterating through
sub-devices and calling mfd_add_devices. Suggested by Lee Jones.
---
drivers/mfd/cros_ec.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 751af0b..7c533d2 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/mfd/core.h
+#include linux/of_platform.h
#include linux/mfd/cros_ec.h
#include linux/mfd/cros_ec_commands.h
#include linux/delay.h
@@ -109,22 +110,10 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_cmd_xfer);
-static const struct mfd_cell cros_devs[] = {
- {
- .name = cros-ec-keyb,
- .id = 1,
- .of_compatible = google,cros-ec-keyb,
- },
- {
- .name = cros-ec-i2c-tunnel,
- .id = 2,
- .of_compatible = google,cros-ec-i2c-tunnel,
- },
-};
-
int cros_ec_register(struct cros_ec_device *ec_dev)
{
struct device *dev = ec_dev-dev;
+ struct device_node *node = dev-of_node;
int err = 0;
if (ec_dev-din_size) {
@@ -140,12 +129,12 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
mutex_init(ec_dev-lock);
- err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
- NULL, ec_dev-irq, NULL);
- if (err) {
- dev_err(dev, failed to add mfd devices\n);
- return err;
+ if (node) {
+ err = of_platform_populate(node, NULL, NULL, dev);
+ if (err) {
+ dev_err(dev, Failed to register subordinate devices);
+ return err;
+ }
}
dev_info(dev, Chrome EC device registered\n);
--
2.1.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
[PATCH v3 0/6] Second batch of cleanups for cros_ec
Hello, This is a second batch of cleanups patches for the mfd cros_ec driver and its subdevices drivers. The first batch of cleanups was posted by Doug Anderson [0] and have already been merged. The patches were picked from the ChromeOS 3.8 kernel and after these no cleanups patches for cros_ec are left, only commits that add cros ec support not yet available in mainline. This is a third version of the patch series that addresses issues pointed out by Lee Jones on v2 [1]. There is almost no functionality added on this series but the idea is to reduce the delta between the mainline drivers and the ones in the downstream Chrome OS 3.8 kernel so the missing functionality can be added on top once these cleanups patches are merged. The missing functionlity currently in mainline is: - Chrome OS Embedded Controller userspace device interface - Chrome OS Embedded Controller Low Pin Count (LPC) inteface - Access to vboot context stored on a block device - Access to vboot context stored on EC's nvram The patches in this series are authored by different people (all on cc) and consist of the following: Andrew Bresticker (3): mfd: cros_ec: stop calling -cmd_xfer() directly mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: wait for completion of commands that return IN_PROGRESS Derek Basehore (1): i2c: i2c-cros-ec-tunnel: Set retries to 3 Doug Anderson (1): mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC Todd Broch (1): mfd: cros_ec: Instantiate sub-devices from device tree drivers/i2c/busses/i2c-cros-ec-tunnel.c | 5 ++- drivers/input/keyboard/cros_ec_keyb.c | 2 +- drivers/mfd/cros_ec.c | 74 + drivers/mfd/cros_ec_spi.c | 20 - include/linux/mfd/cros_ec.h | 24 --- 5 files changed, 88 insertions(+), 37 deletions(-) Patches #1, #2 and #6 can be applied independently but patches #3, #4 and #5 rely on the previous one so they should be applied together and in that order. Best regards, Javier [0]: https://www.mail-archive.com/linux-input@vger.kernel.org/msg11385.html [1]: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35858.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
[PATCH v3 2/6] i2c: i2c-cros-ec-tunnel: Set retries to 3
From: Derek Basehore dbaseh...@chromium.org
Since the i2c bus can get wedged on the EC sometimes, set the number of retries
to 3. Since we un-wedge the bus immediately after the wedge happens, this is the
correct fix since only one transfer will fail.
Signed-off-by: Derek Basehore dbaseh...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Wolfram Sang w...@the-dreams.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 3c15dcc..97e6369 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
+#define I2C_MAX_RETRIES 3
+
/**
* struct ec_i2c_device - Driver data for I2C tunnel
*
@@ -290,6 +292,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
bus-adap.algo_data = bus;
bus-adap.dev.parent = pdev-dev;
bus-adap.dev.of_node = np;
+ bus-adap.retries = I2C_MAX_RETRIES;
err = i2c_add_adapter(bus-adap);
if (err) {
--
2.1.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
[PATCH v3 4/6] mfd: cros_ec: move locking into cros_ec_cmd_xfer
From: Andrew Bresticker abres...@chromium.org
Now that there's a central cros_ec_cmd_xfer(), move the locking
out of the SPI driver.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v2: None
Changes since v1:
- Remove mention of LPC driver in the commit message since it does not
exist in mainline yet. Suggested by Doug Anderson.
drivers/mfd/cros_ec.c | 10 +-
drivers/mfd/cros_ec_spi.c | 11 ---
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index a9faebd..c53804a 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -65,7 +65,13 @@ EXPORT_SYMBOL(cros_ec_check_result);
int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg)
{
- return ec_dev-cmd_xfer(ec_dev, msg);
+ int ret;
+
+ mutex_lock(ec_dev-lock);
+ ret = ec_dev-cmd_xfer(ec_dev, msg);
+ mutex_unlock(ec_dev-lock);
+
+ return ret;
}
EXPORT_SYMBOL(cros_ec_cmd_xfer);
@@ -98,6 +104,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
return -ENOMEM;
}
+ mutex_init(ec_dev-lock);
+
err = mfd_add_devices(dev, 0, cros_devs,
ARRAY_SIZE(cros_devs),
NULL, ec_dev-irq, NULL);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index b396705..bf6e08e 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -79,13 +79,11 @@
* if no record
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
- * @lock: mutex to ensure only one user of cros_ec_cmd_xfer_spi at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
- struct mutex lock;
};
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -232,13 +230,6 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
int sum;
int ret = 0, final_ret;
- /*
-* We have the shared ec_dev buffer plus we do lots of separate spi_sync
-* calls, so we need to make sure only one person is using this at a
-* time.
-*/
- mutex_lock(ec_spi-lock);
-
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev-dev, prepared, len=%d\n, len);
@@ -327,7 +318,6 @@ exit:
if (ec_msg-command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
- mutex_unlock(ec_spi-lock);
return ret;
}
@@ -359,7 +349,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi-spi = spi;
- mutex_init(ec_spi-lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
--
2.1.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
[PATCH v3 1/6] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC
From: Doug Anderson diand...@chromium.org If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be unresponsive for quite a while. Add a delay to the end of the command to prevent random failures of future commands. NOTES: * This could be optimized a bit by simply delaying the next command sent, but EC_CMD_REBOOT_EC is such a rare command that the extra complexity doesn't seem worth it. * This is a bit of an ugly hack since the SPI driver is effectively snooping on the communication and making a lot of assumptions. It would be nice to architect in some better solution long term. * This same logic probably needs to be applied to the i2c driver. Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Randall Spangler rspang...@chromium.org Reviewed-by: Vadim Bendebury vben...@chromium.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/cros_ec_spi.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 588c700..b396705 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -65,6 +65,12 @@ */ #define EC_SPI_RECOVERY_TIME_NS(200 * 1000) +/* + * The EC is unresponsive for a time after a reboot command. Add a + * simple delay to make sure that the bus stays locked. + */ +#define EC_REBOOT_DELAY_MS 50 + /** * struct cros_ec_spi - information about a SPI-connected EC * @@ -318,6 +324,9 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev, ret = len; exit: + if (ec_msg-command == EC_CMD_REBOOT_EC) + msleep(EC_REBOOT_DELAY_MS); + mutex_unlock(ec_spi-lock); return ret; } -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad
Hello Dmitry,
On 09/11/2014 12:25 AM, Dmitry Torokhov wrote:
+hsi2c_8 {
+status = okay;
+clock-frequency = 333000;
+
+/* Atmel mXT336S */
+trackpad@4b {
+compatible = atmel,maxtouch;
+reg = 0x4b;
+interrupt-parent = gpx1;
+interrupts = 1 IRQ_TYPE_EDGE_FALLING;
+wakeup-source;
+pinctrl-names = default;
+pinctrl-0 = trackpad_irq;
+linux,gpio-keymap = KEY_RESERVED
+ KEY_RESERVED
+ KEY_RESERVED /* GPIO0 */
+ KEY_RESERVED /* GPIO1 */
+ KEY_RESERVED /* GPIO2 */
+ BTN_LEFT; /* GPIO3 */
Seems like a single space sneaked between the semicolon and the tab.
Maybe whoever applies could squash it.
Right, I set c-default-style to linux on Emacs but seems it gets confused
sometimes when editing Device Tree source files. Sorry about that.
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] Input: atmel_mxt_ts: Add of node type to the i2c table
Hello Nick, On 09/11/2014 11:19 AM, Nick Dyer wrote: Thanks for the clear explanation. The i2c aliases are a bit confusing. The original device the driver was written for was called qt602240, which was renamed by Atmel to mXT224 when the chip series was called maXTouch. The driver now actually supports many other chips which aren't listed (more than 20 devices that I've personally tested). I could add them all, but it would be an extremely long list. It may be preferable to use the generic name maXTouch. So I think the sensible thing to do here would be to add maxtouch to the i2c list to fix the module autoload issue. While this will actually fix the module auto-load issue on the atmel driver, I'm concerned that the I2C core is not reporting the correct module 'of:N*T*Catmel,maxtouch*' alias when probing using DT. Since as Lee said on his cover letter for the mentioned series [0], an I2C ID table shouldn't be mandatory for drivers that only support DT based platforms (e.g: a driver that depends on OF) but in that case I2C module auto-loading would not work AFAICT. Best regards, Javier [0]: https://lkml.org/lkml/2014/6/20/199 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/8] arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support
From: Alim Akhtar alim.akh...@samsung.com This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos7 SoC. Signed-off-by: Alim Akhtar alim.akh...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Rob Herring r...@kernel.org Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm64/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index fd4e81a..b4d1dc2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -134,6 +134,18 @@ source kernel/Kconfig.freezer menu Platform selection +config ARCH_EXYNOS + bool + help + This enables support for Samsung Exynos SoC family + +config ARCH_EXYNOS7 + bool ARMv8 based Samsung Exynos7 + select ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + help + This enables support for Samsung Exynos7 SoC family + config ARCH_VEXPRESS bool ARMv8 software model (Versatile Express) select ARCH_REQUIRE_GPIOLIB -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] clk: samsung: Factor out the common code to clk.c
While adding clock support for Exynos5260, the infrastructure to
register multiple clock controllers was introduced. Factor out the
support for registering multiple clock controller from Exynos5260
clock code to common samsung clock code so that it can be used by
other Exynos SoC which have multiple clock controllers.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-exynos5260.c | 185 +-
drivers/clk/samsung/clk.c| 95 +
drivers/clk/samsung/clk.h| 34 +++
3 files changed, 155 insertions(+), 159 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5260.c
b/drivers/clk/samsung/clk-exynos5260.c
index ce3de97..b08ac19 100644
--- a/drivers/clk/samsung/clk-exynos5260.c
+++ b/drivers/clk/samsung/clk-exynos5260.c
@@ -11,10 +11,8 @@
#include linux/clk.h
#include linux/clkdev.h
-#include linux/clk-provider.h
#include linux/of.h
#include linux/of_address.h
-#include linux/syscore_ops.h
#include clk-exynos5260.h
#include clk.h
@@ -22,39 +20,6 @@
#include dt-bindings/clock/exynos5260-clk.h
-static LIST_HEAD(clock_reg_cache_list);
-
-struct exynos5260_clock_reg_cache {
- struct list_head node;
- void __iomem *reg_base;
- struct samsung_clk_reg_dump *rdump;
- unsigned int rd_num;
-};
-
-struct exynos5260_cmu_info {
- /* list of pll clocks and respective count */
- struct samsung_pll_clock *pll_clks;
- unsigned int nr_pll_clks;
- /* list of mux clocks and respective count */
- struct samsung_mux_clock *mux_clks;
- unsigned int nr_mux_clks;
- /* list of div clocks and respective count */
- struct samsung_div_clock *div_clks;
- unsigned int nr_div_clks;
- /* list of gate clocks and respective count */
- struct samsung_gate_clock *gate_clks;
- unsigned int nr_gate_clks;
- /* list of fixed clocks and respective count */
- struct samsung_fixed_rate_clock *fixed_clks;
- unsigned int nr_fixed_clks;
- /* total number of clocks with IDs assigned*/
- unsigned int nr_clk_ids;
-
- /* list and number of clocks registers */
- unsigned long *clk_regs;
- unsigned int nr_clk_regs;
-};
-
/*
* Applicable for all 2550 Type PLLS for Exynos5260, listed below
* DISP_PLL, EGL_PLL, KFC_PLL, MEM_PLL, BUS_PLL, MEDIA_PLL, G3D_PLL.
@@ -113,104 +78,6 @@ static struct samsung_pll_rate_table pll2650_24mhz_tbl[]
__initdata = {
PLL_36XX_RATE(6600, 176, 2, 5, 0),
};
-#ifdef CONFIG_PM_SLEEP
-
-static int exynos5260_clk_suspend(void)
-{
- struct exynos5260_clock_reg_cache *cache;
-
- list_for_each_entry(cache, clock_reg_cache_list, node)
- samsung_clk_save(cache-reg_base, cache-rdump,
- cache-rd_num);
-
- return 0;
-}
-
-static void exynos5260_clk_resume(void)
-{
- struct exynos5260_clock_reg_cache *cache;
-
- list_for_each_entry(cache, clock_reg_cache_list, node)
- samsung_clk_restore(cache-reg_base, cache-rdump,
- cache-rd_num);
-}
-
-static struct syscore_ops exynos5260_clk_syscore_ops = {
- .suspend = exynos5260_clk_suspend,
- .resume = exynos5260_clk_resume,
-};
-
-static void exynos5260_clk_sleep_init(void __iomem *reg_base,
- unsigned long *rdump,
- unsigned long nr_rdump)
-{
- struct exynos5260_clock_reg_cache *reg_cache;
-
- reg_cache = kzalloc(sizeof(struct exynos5260_clock_reg_cache),
- GFP_KERNEL);
- if (!reg_cache)
- panic(could not allocate register cache.\n);
-
- reg_cache-rdump = samsung_clk_alloc_reg_dump(rdump, nr_rdump);
-
- if (!reg_cache-rdump)
- panic(could not allocate register dump storage.\n);
-
- if (list_empty(clock_reg_cache_list))
- register_syscore_ops(exynos5260_clk_syscore_ops);
-
- reg_cache-rd_num = nr_rdump;
- reg_cache-reg_base = reg_base;
- list_add_tail(reg_cache-node, clock_reg_cache_list);
-}
-
-#else
-static void exynos5260_clk_sleep_init(void __iomem *reg_base,
- unsigned long *rdump,
- unsigned long nr_rdump){}
-#endif
-
-/*
- * Common function which registers plls, muxes, dividers and gates
- * for each CMU. It also add CMU register list to register cache.
- */
-
-void __init exynos5260_cmu_register_one(struct device_node *np,
- struct exynos5260_cmu_info *cmu)
-{
- void __iomem *reg_base;
- struct samsung_clk_provider *ctx;
-
- reg_base = of_iomap(np, 0);
- if (!reg_base)
- panic(%s: failed to map registers\n, __func__);
-
- ctx = samsung_clk_init(np, reg_base, cmu-nr_clk_ids);
- if (!ctx)
- panic(%s: unable to
[PATCH v3 0/8] arch: arm64: enable support for Samsung Exynos7 SoC
This patchset supports new Exynos7 Samsung SoC based on Cortex-A57. Exynos7 is a System-On-Chip (SoC) that is based on 64-bit ARMv8 RISC processor. The following patches are tested based on Kgene's for-next tree. https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next The following patches are required for this series. 1- tty/serial: fix config dependencies for samsung serial https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg36208.html Alim Akhtar (1): arm64: exynos7: Enable ARMv8 based Exynos7 (SoC) support Naveen Krishna Chatradhi (6): clk: samsung: add support for 145xx and 1460x PLLs clk: samsung: Factor out the common code to clk.c clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info clk: samsung: add initial clock support for Exynos7 SoC arm64: dts: Add initial device tree support for EXYNOS7 tty/serial: samsung: enable usage for 64-bit Exynos platforms Pankaj Dubey (1): arm64: dts: add dt-bindings/ symlink .../devicetree/bindings/clock/exynos7-clock.txt| 37 ++ arch/arm64/Kconfig | 12 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/exynos/exynos7-espresso.dts| 35 ++ arch/arm64/boot/dts/exynos/exynos7.dtsi| 167 arch/arm64/boot/dts/include/dt-bindings|1 + drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5260.c | 185 ++--- drivers/clk/samsung/clk-exynos7.c | 438 drivers/clk/samsung/clk-pll.c | 25 +- drivers/clk/samsung/clk-pll.h |4 + drivers/clk/samsung/clk.c | 98 + drivers/clk/samsung/clk.h | 37 ++ drivers/tty/serial/Kconfig |2 +- include/dt-bindings/clock/exynos7-clk.h| 55 +++ 15 files changed, 933 insertions(+), 165 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi create mode 12 arch/arm64/boot/dts/include/dt-bindings create mode 100644 drivers/clk/samsung/clk-exynos7.c create mode 100644 include/dt-bindings/clock/exynos7-clk.h -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/8] clk: samsung: add initial clock support for Exynos7 SoC
Add initial clock support for Exynos7 SoC which is required
to bring up platforms based on Exynos7.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
---
.../devicetree/bindings/clock/exynos7-clock.txt| 37 ++
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos7.c | 438
include/dt-bindings/clock/exynos7-clk.h| 55 +++
4 files changed, 531 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos7-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos7.c
create mode 100644 include/dt-bindings/clock/exynos7-clk.h
diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
new file mode 100644
index 000..798eb10
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
@@ -0,0 +1,37 @@
+* Samsung Exynos7 Clock Controller
+
+Exynos7 clock controller has various blocks which are instantiated
+independently from the device-tree. These clock controllers
+generate and supply clocks to various hardware blocks within
+the SoC.
+
+Each clock is assigned an identifier and client nodes can use
+this identifier to specify the clock which they consume. All
+available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos7-clk.h header and can be used in
+device tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It
+is expected that they are defined using standard clock bindings
+with following clock-output-names:
+
+ - fin_pll - PLL input clock from XXTI
+
+Required Properties for Clock Controller:
+
+ - compatible: clock controllers will use one of the following
+ compatible strings to indicate the clock controller
+ functionality.
+
+ - samsung,exynos7-clock-topc
+ - samsung,exynos7-clock-top0
+ - samsung,exynos7-clock-peric0
+ - samsung,exynos7-clock-peric1
+ - samsung,exynos7-clock-peris
+
+ - reg: physical base address of the controller and the length of
+ memory mapped region.
+
+ - #clock-cells: should be 1.
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..5da0ba9 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
obj-$(CONFIG_S3C2443_COMMON_CLK)+= clk-s3c2443.o
obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
obj-$(CONFIG_ARCH_S5PV210) += clk-s5pv210.o clk-s5pv210-audss.o
+obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
new file mode 100644
index 000..25e12b3
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -0,0 +1,438 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Naveen Krishna Chatradhi ch.nav...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+*/
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+
+#include clk.h
+#include dt-bindings/clock/exynos7-clk.h
+
+/* Register Offset definitions for CMU_TOPC (0x1057) */
+#define CC_PLL_LOCK0x
+#define BUS0_PLL_LOCK 0x0004
+#define BUS1_DPLL_LOCK 0x0008
+#define MFC_PLL_LOCK 0x000C
+#define AUD_PLL_LOCK 0x0010
+#define CC_PLL_CON00x0100
+#define BUS0_PLL_CON0 0x0110
+#define BUS1_DPLL_CON0 0x0120
+#define MFC_PLL_CON0 0x0130
+#define AUD_PLL_CON0 0x0140
+#define AUD_PLL_CON1 0x0144
+#define AUD_PLL_CON2 0x0148
+#define MIF_PLL_CON0 0x0150
+#define MIF_PLL_CON1 0x0154
+#define MIF_PLL_CON2 0x0158
+#define MUX_SEL_TOPC0 0x0200
+#define MUX_SEL_TOPC1 0x0204
+#define MUX_SEL_TOPC3 0x020C
+#define DIV_TOPC1 0x0604
+#define DIV_TOPC3 0x060C
+#define ENABLE_ACLK_TOPC1 0x0804
+#define ENABLE_SCLK_TOPC1 0x0A04
+
+static struct samsung_fixed_factor_clock topc_fixed_factor_clks[] __initdata =
{
+ FFACTOR(0, ffac_topc_bus0_pll_div2, mout_bus0_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_bus0_pll_div4,
+ ffac_topc_bus0_pll_div2, 1, 2, 0),
+ FFACTOR(0, ffac_topc_bus1_pll_div2, mout_bus1_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_cc_pll_div2, mout_cc_pll_ctrl, 1, 2, 0),
+ FFACTOR(0, ffac_topc_mfc_pll_div2, mout_mfc_pll_ctrl, 1, 2, 0),
+};
+
+/* List of parent clocks for Muxes in CMU_TOPC */
+PNAME(mout_bus0_pll_ctrl_p)= { fin_pll, fout_bus0_pll };
+PNAME(mout_bus1_pll_ctrl_p)= { fin_pll, fout_bus1_pll };
[PATCH v3 5/8] arm64: dts: Add initial device tree support for EXYNOS7
Add initial device tree nodes for EXYNOS7 SoC and board dts file
to support Espresso board based on Exynos7 SoC.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring r...@kernel.org
Cc: Catalin Marinas catalin.mari...@arm.com
---
arch/arm64/boot/dts/Makefile|1 +
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 35 +
arch/arm64/boot/dts/exynos/exynos7.dtsi | 167 +++
3 files changed, 203 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos7-espresso.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos7.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c52bdb0..a3bc18a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_EXYNOS7) += exynos/exynos7-espresso.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
new file mode 100644
index 000..4f69991
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -0,0 +1,35 @@
+/*
+ * SAMSUNG Exynos7 Espresso board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos7.dtsi
+
+/ {
+ model = Samsung Exynos7 Espresso board based on EXYNOS7;
+ compatible = samsung,exynos7-espresso, samsung,exynos7;
+
+ chosen {
+ linux,stdout-path = serial_2;
+ };
+
+ memory@4000 {
+ device_type = memory;
+ reg = 0x0 0x4000 0x0 0xC000;
+ };
+};
+
+fin_pll {
+ clock-frequency = 2400;
+};
+
+serial_2 {
+ status = okay;
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
new file mode 100644
index 000..56ec5f4
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -0,0 +1,167 @@
+/*
+ * SAMSUNG EXYNOS7 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clock/exynos7-clk.h
+
+/ {
+ compatible = samsung,exynos7;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ serial0 = serial_0;
+ serial1 = serial_1;
+ serial2 = serial_2;
+ serial3 = serial_3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x1;
+ };
+
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x2;
+ };
+
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,cortex-a57, arm,armv8;
+ enable-method = psci;
+ reg = 0x3;
+ };
+ };
+
+ psci {
+ compatible = arm,psci-0.2;
+ method = smc;
+ };
+
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0 0 0x1800;
+
+ chipid@1000 {
+ compatible = samsung,exynos4210-chipid;
+ reg = 0x1000 0x100;
+ };
+
+ fin_pll: xxti {
+ compatible = fixed-clock;
+ clock-output-names = fin_pll;
+ #clock-cells = 0;
+ };
+
+ gic: interrupt-controller@11001000 {
+ compatible = arm,gic-400;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x11001000 0x1000,
+ 0x11002000 0x1000,
+
[PATCH v3 8/8] arm64: dts: add dt-bindings/ symlink
From: Pankaj Dubey pankaj.du...@samsung.com Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/ to match the ones in ARM architectures so that preprocessed device tree files can include various useful constant definitions. See commit c58299aa8754 (kbuild: create an include chroot for DT bindings) merged in v3.10-rc1 for details. CC: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm64/boot/dts/include/dt-bindings |1 + 1 file changed, 1 insertion(+) create mode 12 arch/arm64/boot/dts/include/dt-bindings diff --git a/arch/arm64/boot/dts/include/dt-bindings b/arch/arm64/boot/dts/include/dt-bindings new file mode 12 index 000..08c00e4 --- /dev/null +++ b/arch/arm64/boot/dts/include/dt-bindings @@ -0,0 +1 @@ +../../../../../include/dt-bindings \ No newline at end of file -- 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 v3 3/8] clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info
Add the fields fixed_factor_clks and nr_fixed_factor_clks to
struct exynos_cmu_info to allow registering of fixed factor
clocks as well with exynos_cmu_register_one().
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk.c |3 +++
drivers/clk/samsung/clk.h |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index a043654..4b31267 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -402,6 +402,9 @@ void __init exynos_cmu_register_one(struct device_node *np,
if (cmu-fixed_clks)
samsung_clk_register_fixed_rate(ctx, cmu-fixed_clks,
cmu-nr_fixed_clks);
+ if (cmu-fixed_factor_clks)
+ samsung_clk_register_fixed_factor(ctx, cmu-fixed_factor_clks,
+ cmu-nr_fixed_factor_clks);
if (cmu-clk_regs)
exynos_clk_sleep_init(reg_base, cmu-clk_regs,
cmu-nr_clk_regs);
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 552d155..993b51c 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -347,6 +347,9 @@ struct exynos_cmu_info {
/* list of fixed clocks and respective count */
struct samsung_fixed_rate_clock *fixed_clks;
unsigned int nr_fixed_clks;
+ /* list of fixed factor clocks and respective count */
+ struct samsung_fixed_factor_clock *fixed_factor_clks;
+ unsigned int nr_fixed_factor_clks;
/* total number of clocks with IDs assigned*/
unsigned int nr_clk_ids;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/8] clk: samsung: add support for 145xx and 1460x PLLs
PLL145xx is similar to PLL35xx and PLL1460x is almost similar
to PLL46xx with minor differences in bit positions. Hence,
reuse the functions defined for pll_35xx and pll_46xx to
support 145xx and 1460x PLLs respectively.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-pll.c | 25 -
drivers/clk/samsung/clk-pll.h |4
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index b07fad2..9d70e5c 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -482,6 +482,8 @@ static const struct clk_ops samsung_pll45xx_clk_min_ops = {
#define PLL46XX_VSEL_MASK (1)
#define PLL46XX_MDIV_MASK (0x1FF)
+#define PLL1460X_MDIV_MASK (0x3FF)
+
#define PLL46XX_PDIV_MASK (0x3F)
#define PLL46XX_SDIV_MASK (0x7)
#define PLL46XX_VSEL_SHIFT (27)
@@ -511,13 +513,15 @@ static unsigned long samsung_pll46xx_recalc_rate(struct
clk_hw *hw,
pll_con0 = __raw_readl(pll-con_reg);
pll_con1 = __raw_readl(pll-con_reg + 4);
- mdiv = (pll_con0 PLL46XX_MDIV_SHIFT) PLL46XX_MDIV_MASK;
+ mdiv = (pll_con0 PLL46XX_MDIV_SHIFT) ((pll-type == pll_1460x) ?
+ PLL1460X_MDIV_MASK : PLL46XX_MDIV_MASK);
pdiv = (pll_con0 PLL46XX_PDIV_SHIFT) PLL46XX_PDIV_MASK;
sdiv = (pll_con0 PLL46XX_SDIV_SHIFT) PLL46XX_SDIV_MASK;
kdiv = pll-type == pll_4650c ? pll_con1 PLL4650C_KDIV_MASK :
pll_con1 PLL46XX_KDIV_MASK;
- shift = pll-type == pll_4600 ? 16 : 10;
+ shift = ((pll-type == pll_4600) || (pll-type == pll_1460x)) ? 16 : 10;
+
fvco *= (mdiv shift) + kdiv;
do_div(fvco, (pdiv sdiv));
fvco = shift;
@@ -573,14 +577,21 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw,
unsigned long drate,
lock = 0x;
/* Set PLL PMS and VSEL values. */
- con0 = ~((PLL46XX_MDIV_MASK PLL46XX_MDIV_SHIFT) |
+ if (pll-type == pll_1460x) {
+ con0 = ~((PLL1460X_MDIV_MASK PLL46XX_MDIV_SHIFT) |
+ (PLL46XX_PDIV_MASK PLL46XX_PDIV_SHIFT) |
+ (PLL46XX_SDIV_MASK PLL46XX_SDIV_SHIFT));
+ } else {
+ con0 = ~((PLL46XX_MDIV_MASK PLL46XX_MDIV_SHIFT) |
(PLL46XX_PDIV_MASK PLL46XX_PDIV_SHIFT) |
(PLL46XX_SDIV_MASK PLL46XX_SDIV_SHIFT) |
(PLL46XX_VSEL_MASK PLL46XX_VSEL_SHIFT));
+ con0 |= rate-vsel PLL46XX_VSEL_SHIFT;
+ }
+
con0 |= (rate-mdiv PLL46XX_MDIV_SHIFT) |
(rate-pdiv PLL46XX_PDIV_SHIFT) |
- (rate-sdiv PLL46XX_SDIV_SHIFT) |
- (rate-vsel PLL46XX_VSEL_SHIFT);
+ (rate-sdiv PLL46XX_SDIV_SHIFT);
/* Set PLL K, MFR and MRR values. */
con1 = __raw_readl(pll-con_reg + 0x4);
@@ -1190,6 +1201,9 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
/* clk_ops for 35xx and 2550 are similar */
case pll_35xx:
case pll_2550:
+ case pll_1450x:
+ case pll_1451x:
+ case pll_1452x:
if (!pll-rate_table)
init.ops = samsung_pll35xx_clk_min_ops;
else
@@ -1223,6 +1237,7 @@ static void __init _samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
case pll_4600:
case pll_4650:
case pll_4650c:
+ case pll_1460x:
if (!pll-rate_table)
init.ops = samsung_pll46xx_clk_min_ops;
else
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index c0ed4d4..213de9a 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -33,6 +33,10 @@ enum samsung_pll_type {
pll_s3c2440_mpll,
pll_2550xx,
pll_2650xx,
+ pll_1450x,
+ pll_1451x,
+ pll_1452x,
+ pll_1460x,
};
#define PLL_35XX_RATE(_rate, _m, _p, _s) \
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/8] tty/serial: samsung: enable usage for 64-bit Exynos platforms
Allow Samsung serial driver to be usable on Exynos 64-bit SoC based platforms. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/tty/serial/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 26cec64..3383744 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -220,7 +220,7 @@ config SERIAL_CLPS711X_CONSOLE config SERIAL_SAMSUNG tristate Samsung SoC serial support - depends on PLAT_SAMSUNG + depends on PLAT_SAMSUNG || ARCH_EXYNOS select SERIAL_CORE help Support for the on-chip UARTs on the Samsung S3C24XX series CPUs, -- 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 v3 5/8] arm64: dts: Add initial device tree support for EXYNOS7
On Thursday 11 September 2014 15:50:49 Naveen Krishna Chatradhi wrote:
+ aliases {
+ serial0 = serial_0;
+ serial1 = serial_1;
+ serial2 = serial_2;
+ serial3 = serial_3;
+ };
+
Please move the aliases from the exynos7.dtsi file into the
exynos7-espresso.dts file, and only list the ones that are
present, starting with alias 0, like
aliases {
serial0 = serial_2;
};
If the machine has only one serial port, it should be the first
alias.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Funny timing. I am just reviewing the series from Lee and also stumbled
over modaliases, too...
On Thu, Sep 11, 2014 at 10:19:54AM +0100, Nick Dyer wrote:
On 11/09/14 09:38, Javier Martinez Canillas wrote:
To expand on what Sjoerd already said and just to be sure everyone is on the
same page.
The problem is that right now the driver reports the following modalias:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
but if you look at the module information, that is not a valid alias:
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
alias: of:N*T*Catmel,maxtouch*
which means that udev/kmod can't load the module automatically based on the
alias information.
The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:maxtouch
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
which matches the reported uevent so the module will be auto-loaded.
This is because the I2C subsystem hardcodes i2c:client-name, if you look
at
drivers/i2c/i2c-core.c:
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env
*env)
{
...
if (add_uevent_var(env, MODALIAS=%s%s,
I2C_MODULE_PREFIX, client-name))
...
}
I've looked at Lee's series and AFAICT that remains the same so I second
Sjoerd that module auto-loading will continue to be broken.
I think the above code in the i2c core needs a fix. Will have a closer
look after lunch.
The i2c aliases are a bit confusing. The original device the driver was
written for was called qt602240, which was renamed by Atmel to mXT224 when
the chip series was called maXTouch. The driver now actually supports
many other chips which aren't listed (more than 20 devices that I've
personally tested). I could add them all, but it would be an extremely long
list. It may be preferable to use the generic name maXTouch.
This is probably true for some more I2C devices. Like RTCs being
compatible or, most prominent, EEPROMS. I don't want to have a list of
all vendors producing 24c02s if they are all compatible. If generic
entries are frowned upon, I'd agree on a first come, first served policy:
Somebody provides one compatible-property with the vendor which happens
to be on that board, and the others have to reuse that
compatible-property since they are, well, compatible.
So I think the sensible thing to do here would be to add maxtouch to the
i2c list to fix the module autoload issue.
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
Regards,
Wolfram
signature.asc
Description: Digital signature
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Hello Wolfram,
On 09/11/2014 01:08 PM, Wolfram Sang wrote:
Funny timing. I am just reviewing the series from Lee and also stumbled
over modaliases, too...
On Thu, Sep 11, 2014 at 10:19:54AM +0100, Nick Dyer wrote:
On 11/09/14 09:38, Javier Martinez Canillas wrote:
To expand on what Sjoerd already said and just to be sure everyone is on
the
same page.
The problem is that right now the driver reports the following modalias:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
but if you look at the module information, that is not a valid alias:
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
alias: of:N*T*Catmel,maxtouch*
which means that udev/kmod can't load the module automatically based on the
alias information.
The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
# modinfo atmel_mxt_ts | grep alias
alias: i2c:mXT224
alias: i2c:maxtouch
alias: i2c:atmel_mxt_tp
alias: i2c:atmel_mxt_ts
alias: i2c:qt602240_ts
which matches the reported uevent so the module will be auto-loaded.
This is because the I2C subsystem hardcodes i2c:client-name, if you
look at
drivers/i2c/i2c-core.c:
/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env
*env)
{
...
if (add_uevent_var(env, MODALIAS=%s%s,
I2C_MODULE_PREFIX, client-name))
...
}
I've looked at Lee's series and AFAICT that remains the same so I second
Sjoerd that module auto-loading will continue to be broken.
I think the above code in the i2c core needs a fix. Will have a closer
look after lunch.
Agreed, I just posted an RFC patch [0] with the fix but as Sjoerd pointed out
on an internal review, changing that will regress all the drivers that were
relying on the old behavior.
The i2c aliases are a bit confusing. The original device the driver was
written for was called qt602240, which was renamed by Atmel to mXT224 when
the chip series was called maXTouch. The driver now actually supports
many other chips which aren't listed (more than 20 devices that I've
personally tested). I could add them all, but it would be an extremely long
list. It may be preferable to use the generic name maXTouch.
This is probably true for some more I2C devices. Like RTCs being
compatible or, most prominent, EEPROMS. I don't want to have a list of
all vendors producing 24c02s if they are all compatible. If generic
entries are frowned upon, I'd agree on a first come, first served policy:
Somebody provides one compatible-property with the vendor which happens
to be on that board, and the others have to reuse that
compatible-property since they are, well, compatible.
Agreed.
So I think the sensible thing to do here would be to add maxtouch to the
i2c list to fix the module autoload issue.
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
I think it really depends if an IP block can be used on non-DT platforms
(which I think is true for this trackpad) but if a driver is for an IP block
that can only be used on a DT-only platform (e.g: a PMIC that is controlled
over I2C and is only compatible with a DT-only SoC) then I don't think we need
to support the i2c_board_info structure and can get rid of the I2C ID table on
these drivers once Lee series land.
Regards,
Wolfram
Best regards,
Javier
[0]: https://patchwork.ozlabs.org/patch/388200/
--
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] Input: atmel_mxt_ts: Add of node type to the i2c table
This is a workaround. It would make sense, however, to add it because we want to support i2c_board_info structures. I think it really depends if an IP block can be used on non-DT platforms (which I think is true for this trackpad) but if a driver is for an IP block that can only be used on a DT-only platform (e.g: a PMIC that is controlled over I2C and is only compatible with a DT-only SoC) then I don't think we need to support the i2c_board_info structure and can get rid of the I2C ID table on these drivers once Lee series land. That is exactly what I meant. It should be only added if there is a reason other than workaround. If you say, it doesn't make sense on non-DT, then it should not be added. signature.asc Description: Digital signature
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
Hello Wolfram, On 09/11/2014 01:35 PM, Wolfram Sang wrote: This is a workaround. It would make sense, however, to add it because we want to support i2c_board_info structures. I think it really depends if an IP block can be used on non-DT platforms (which I think is true for this trackpad) but if a driver is for an IP block that can only be used on a DT-only platform (e.g: a PMIC that is controlled over I2C and is only compatible with a DT-only SoC) then I don't think we need to support the i2c_board_info structure and can get rid of the I2C ID table on these drivers once Lee series land. That is exactly what I meant. It should be only added if there is a reason other than workaround. If you say, it doesn't make sense on non-DT, then it should not be added. Sorry for explaining myself badly. I just tried to say that this is a decision that has to be made on a per-driver basis but I don't really know if makes sense or not in this case since I don't know if this device is (or could be) shipped on non-DT platforms. Nick is in a much better position to answer that question. 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 v3 5/8] arm64: dts: Add initial device tree support for EXYNOS7
On 11 September 2014 16:11, Arnd Bergmann a...@arndb.de wrote:
On Thursday 11 September 2014 15:50:49 Naveen Krishna Chatradhi wrote:
+ aliases {
+ serial0 = serial_0;
+ serial1 = serial_1;
+ serial2 = serial_2;
+ serial3 = serial_3;
+ };
+
Please move the aliases from the exynos7.dtsi file into the
exynos7-espresso.dts file, and only list the ones that are
present, starting with alias 0, like
aliases {
serial0 = serial_2;
};
If the machine has only one serial port, it should be the first
alias.
Okay, will fix this in the next version.
Arnd
Thanks,
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
On 11/09/14 12:41, Javier Martinez Canillas wrote: On 09/11/2014 01:35 PM, Wolfram Sang wrote: This is a workaround. It would make sense, however, to add it because we want to support i2c_board_info structures. I think it really depends if an IP block can be used on non-DT platforms (which I think is true for this trackpad) but if a driver is for an IP block that can only be used on a DT-only platform (e.g: a PMIC that is controlled over I2C and is only compatible with a DT-only SoC) then I don't think we need to support the i2c_board_info structure and can get rid of the I2C ID table on these drivers once Lee series land. That is exactly what I meant. It should be only added if there is a reason other than workaround. If you say, it doesn't make sense on non-DT, then it should not be added. Sorry for explaining myself badly. I just tried to say that this is a decision that has to be made on a per-driver basis but I don't really know if makes sense or not in this case since I don't know if this device is (or could be) shipped on non-DT platforms. Nick is in a much better position to answer that question. There are plenty of out-of-tree users of this driver which don't use DT. The most significant use I'm aware of is on Chromium OS systems. -- 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 00/17] drm/exynos/ipp: image post processing fixes and improvements, part four
On 2014년 08월 28일 18:07, Andrzej Hajda wrote: This set of patches contains various improvement and fixes for exynos_drm ipp framework. The patchset is based on exynos-drm-next branch. IPP framework was tested for regressions on exynos4210-trats target. In the 2nd version of the series I have included changes proposed by Joonyoung Shim. I have decided to resend whole series because the changes caused merge conflicts and two separate patches have been added to the series. Changes are described in comit messages. Applied. Thanks, Inki Dae Regards Andrzej Andrzej Hajda (17): drm/exynos/ipp: remove fake pm callbacks drm/exynos/ipp: cancel works before command node clean drm/exynos/ipp: move file reference from memory to command node drm/exynos/ipp: remove only related commands on file close drm/exynos/ipp: remove unused field in command node drm/exynos/ipp: free partially allocated resources on error drm/exynos/ipp: move nodes cleaning to separate function drm/exynos/ipp: clean memory nodes on command node cleaning drm/exynos/ipp: replace work_struct casting with better constructs drm/exynos/ipp: stop hardware before freeing memory drm/exynos/ipp: remove events during command cleaning drm/exynos/fimc: avoid clearing overflow bits drm/exynos/fimc: do not enable fimc twice drm/exynos/fimc: simplify buffer queuing drm/exynos/fimc: fix source buffer registers drm/exynos/ipp: remove file argument from node related functions drm/exynos/ipp: add file checks for ioctls drivers/gpu/drm/exynos/exynos_drm_fimc.c| 90 ++- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 397 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 3 +- 5 files changed, 195 insertions(+), 302 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Changelog v2:
- release devices and drivers if failed.
- change compare_of to compare_dev.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 44 +++
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5aae95c..3f6ec96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -486,21 +486,20 @@ void exynos_drm_component_del(struct device *dev,
mutex_unlock(drm_component_lock);
}
-static int compare_of(struct device *dev, void *data)
+static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(drm_component_lock);
list_for_each_entry(cdev, drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -515,16 +514,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev-crtc_dev == cdev-conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev-crtc_dev);
- if (ret 0)
- return ret;
-
+ component_match_add(dev, match, compare_dev,
+ cdev-crtc_dev);
goto out_lock;
}
@@ -534,11 +527,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev-crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev-conn_dev);
- if (ret 0)
- return ret;
+ component_match_add(dev, match, compare_dev, cdev-crtc_dev);
+ component_match_add(dev, match, compare_dev, cdev-conn_dev);
out_lock:
mutex_lock(drm_component_lock);
@@ -546,7 +536,7 @@ out_lock:
mutex_unlock(drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -560,13 +550,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -633,13 +623,23 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(pdev-dev, exynos_drm_ops);
+ match = exynos_drm_match_add(pdev-dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_resources;
+ }
+
+ ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
+ match);
if (ret 0)
- DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
+ goto err_unregister_resources;
- return 0;
+ return ret;
+
+err_unregister_resources:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(ipp_driver);
err_unregister_gsc_drv:
--
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] thermal: exynos: use correct offset for TMU_CONTROL register on Exynos5260
In exynos5260_tmu_registers tmu_ctrl entry is erroneously
assigned twice. The second assignment (to EXYNOS_TMU_REG_CONTROL1
define which represents 0x24 value) overrides the first one
(to EXYNOS_TMU_REG_CONTROL define which represents 0x20 value)
which results in the wrong (according to the Exynos5260 SoC
documentation that I have) offset being used for TMU_CONTROL
register. Fix it by removing the wrong assignment and then
remove no longer used EXYNOS_TMU_REG_CONTROL1 define.
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Amit Daniel Kachhap amit.dan...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/samsung/exynos_tmu_data.c |1 -
drivers/thermal/samsung/exynos_tmu_data.h |1 -
2 files changed, 2 deletions(-)
Index: b/drivers/thermal/samsung/exynos_tmu_data.c
===
--- a/drivers/thermal/samsung/exynos_tmu_data.c 2014-09-11 14:41:12.567347442
+0200
+++ b/drivers/thermal/samsung/exynos_tmu_data.c 2014-09-11 14:43:00.211350284
+0200
@@ -273,7 +273,6 @@ struct exynos_tmu_init_data const exynos
static const struct exynos_tmu_registers exynos5260_tmu_registers = {
.triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
.tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
- .tmu_ctrl = EXYNOS_TMU_REG_CONTROL1,
.therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
.therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
.therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
Index: b/drivers/thermal/samsung/exynos_tmu_data.h
===
--- a/drivers/thermal/samsung/exynos_tmu_data.h 2014-09-11 14:41:12.243347433
+0200
+++ b/drivers/thermal/samsung/exynos_tmu_data.h 2014-09-11 14:43:36.167351233
+0200
@@ -83,7 +83,6 @@
#define EXYNOS_MAX_TRIGGER_PER_REG 4
/* Exynos5260 specific */
-#define EXYNOS_TMU_REG_CONTROL10x24
#define EXYNOS5260_TMU_REG_INTEN 0xC0
#define EXYNOS5260_TMU_REG_INTSTAT 0xC4
#define EXYNOS5260_TMU_REG_INTCLEAR0xC8
--
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] Input: atmel_mxt_ts - fix merge in DT documentation
On 15/08/14 17:13, Stephen Warren wrote: Any comments on this? I would really appreciate if you can expand on how this DT property is supposed to be used so I can re-spin the atmel support patch for Peach boards. The below patch improves the documentation for the gpio-property. That patch makes sense, and is a nice description, Acked-by: Stephen Warren swar...@nvidia.com Hi Dmitry- Something went a bit wrong in merging f5940231a - there's a bit of repeated text that's been introduced. Signed-off-by: Nick Dyer nick.d...@itdev.co.uk --- Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt index 0ac23f2..1852906 100644 --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt @@ -11,10 +11,6 @@ Required properties: Optional properties for main touchpad device: -- linux,gpio-keymap: An array of up to 4 entries indicating the Linux -keycode generated by each GPIO. Linux keycodes are defined in -dt-bindings/input/input.h. - - linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages on GPIO bit changes. An array of up to 8 entries can be provided indicating the Linux keycode mapped to each bit of the status byte, -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] drm/exynos: update to use component match support
On 09/11/2014 02:57 PM, Inki Dae wrote:
Update Exynos's DRM driver to use component match support rater than
add_components.
Changelog v2:
- release devices and drivers if failed.
- change compare_of to compare_dev.
Signed-off-by: Inki Dae inki@samsung.com
Modulo fixes I have posted earlier.
Tested-by: Andrzej Hajda a.ha...@samsung.com
--
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 44
+++
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5aae95c..3f6ec96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -486,21 +486,20 @@ void exynos_drm_component_del(struct device *dev,
mutex_unlock(drm_component_lock);
}
-static int compare_of(struct device *dev, void *data)
+static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(drm_component_lock);
list_for_each_entry(cdev, drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -515,16 +514,10 @@ static int exynos_drm_add_components(struct device
*dev, struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
- *
- * TODO. if dpi module follows driver-model driver then
- * below codes can be removed.
*/
if (cdev-crtc_dev == cdev-conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev-crtc_dev);
- if (ret 0)
- return ret;
-
+ component_match_add(dev, match, compare_dev,
+ cdev-crtc_dev);
goto out_lock;
}
@@ -534,11 +527,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev-crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev-conn_dev);
- if (ret 0)
- return ret;
+ component_match_add(dev, match, compare_dev, cdev-crtc_dev);
+ component_match_add(dev, match, compare_dev, cdev-conn_dev);
out_lock:
mutex_lock(drm_component_lock);
@@ -546,7 +536,7 @@ out_lock:
mutex_unlock(drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -560,13 +550,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -633,13 +623,23 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(pdev-dev, exynos_drm_ops);
+ match = exynos_drm_match_add(pdev-dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_resources;
+ }
+
+ ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
+ match);
if (ret 0)
- DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
+ goto err_unregister_resources;
- return 0;
+ return ret;
+
+err_unregister_resources:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(ipp_driver);
err_unregister_gsc_drv:
--
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 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Wednesday 10 September 2014 01:26 PM, Vivek Gautam wrote: On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam gautam.vi...@samsung.com wrote: On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam gautam.vi...@samsung.com wrote: adding Julius here, i think i had missed adding Julius for this entire series :-( I should be more careful with the CC list in future. Added his chromium id, since that seems to be more active. On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: Hi, On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? No, unfortunately keeping these calibration settings in phy_power_on() doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new -calibrate() method which, likely, will only be used by you ;-) so you mean, the xhci should itself call phy_init() at a time suitable, so that -calibrate() is not required at all ? but wait, dwc3 does a phy_init() already, then how xhci will be able to do that again. We can't do phy_init() multiple times right ? right. I think we should split and do phy ops separately for dwc3 host and gadget? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
On Thu, Sep 11, 2014 at 10:06:08AM +0100, Grant Likely wrote:
On Wed, 10 Sep 2014 15:31:44 +0100, Mark Brown broo...@kernel.org wrote:
As well as the regulators we'll also need to fix the clocks. If we're
going to start adding these fixups perhaps we want to consider having a
wrapper stage that deals with rewriting DTs prior to trying to use them?
I'm not sure if it makes much difference but there's overlap with other
tools like the ATAGs conversion wrapper and building separately would
let the fixup code run early without directly going into the early init
code (which seems a bit scary).
We've already got a dt fixup hook in the machine struct, created for
exactly this reason. Fixing an incorrect DT provided by firmware:
arch/arm/include/asm/mach/arch.h:
struct machine_desc {
...
void (*dt_fixup)(void);
...
Hrm, that's in the machine descriptor which doesn't seem the ideal
place - something keying off machine ID would be nicer. But that's
relatively speaking just detail.
signature.asc
Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Thu, Sep 11, 2014 at 09:10:21PM +0530, Kishon Vijay Abraham I wrote: Hi, On Wednesday 10 September 2014 01:26 PM, Vivek Gautam wrote: On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam gautam.vi...@samsung.com wrote: On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam gautam.vi...@samsung.com wrote: adding Julius here, i think i had missed adding Julius for this entire series :-( I should be more careful with the CC list in future. Added his chromium id, since that seems to be more active. On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: Hi, On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? No, unfortunately keeping these calibration settings in phy_power_on() doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new -calibrate() method which, likely, will only be used by you ;-) so you mean, the xhci should itself call phy_init() at a time suitable, so that -calibrate() is not required at all ? but wait, dwc3 does a phy_init() already, then how xhci will be able to do that again. We can't do phy_init() multiple times right ? right. I think we should split and do phy ops separately for dwc3 host and gadget? no, don't do that. We need a better way of handling this. As of now we don't support dual-role, so we can just reinitialize the PHY once we reach xhci. Once we start supporting dual-role, we will need more inteligence in the algorithm. -- balbi signature.asc Description: Digital signature
Re: [PATCH] Input: atmel_mxt_ts - fix merge in DT documentation
On Thu, Sep 11, 2014 at 03:52:46PM +0100, Nick Dyer wrote: On 15/08/14 17:13, Stephen Warren wrote: Any comments on this? I would really appreciate if you can expand on how this DT property is supposed to be used so I can re-spin the atmel support patch for Peach boards. The below patch improves the documentation for the gpio-property. That patch makes sense, and is a nice description, Acked-by: Stephen Warren swar...@nvidia.com Hi Dmitry- Something went a bit wrong in merging f5940231a - there's a bit of repeated text that's been introduced. Signed-off-by: Nick Dyer nick.d...@itdev.co.uk Hmm, not sure how I messed this up, but I will queue the patch for the next push. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote: On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org wrote: It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency. I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints. When things break I'm not sure that users are going to understand that something that used to work for them was only provided on a best effort basis, I think they will expect things to carry on working. It's not going to be great if enabling some driver for a device that happens to be in the same power domain as a component used in a framebuffer causes the display to vanish, or if better power management in an existing driver causes breakage. It's relatively OK to have a brief hiccup during boot but usage seems to have expanded beyond that point and I think we need to take robustness more seriously. Given that we have straightforward ways to communicate resource usage it seems sensible to add robustness to the system by making use of them. signature.asc Description: Digital signature
[PATCH] clk: don't use __initconst for non-const arrays
The statement
static const char *name[];
defines a modifiable array of pointers to constant chars. That is
*name[0] = 'f';
is forbidden, but
name[0] = f;
is not. So marking an array that is defined as above with __initconst is
wrong. Either an additional const must be added such that the whole
definition reads:
static const char *const name[] __initconst;
or where this is not possible __initdata must be used.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
drivers/clk/hisilicon/clk-hix5hd2.c | 6 ++--
drivers/clk/mxs/clk-imx23.c | 12
drivers/clk/mxs/clk-imx28.c | 18 ++--
drivers/clk/rockchip/clk.h | 2 +-
drivers/clk/samsung/clk-s5pv210.c | 56 ++---
drivers/clk/ti/composite.c | 2 +-
6 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hix5hd2.c
b/drivers/clk/hisilicon/clk-hix5hd2.c
index e5fcfb4e32ef..7acae2eeb490 100644
--- a/drivers/clk/hisilicon/clk-hix5hd2.c
+++ b/drivers/clk/hisilicon/clk-hix5hd2.c
@@ -44,15 +44,15 @@ static struct hisi_fixed_rate_clock
hix5hd2_fixed_rate_clks[] __initdata = {
{ HIX5HD2_FIXED_83M, 83m, NULL, CLK_IS_ROOT, 8333, },
};
-static const char *sfc_mux_p[] __initconst = {
+static const char *sfc_mux_p[] __initdata = {
24m, 150m, 200m, 100m, 75m, };
static u32 sfc_mux_table[] = {0, 4, 5, 6, 7};
-static const char *sdio1_mux_p[] __initconst = {
+static const char *sdio1_mux_p[] __initdata = {
75m, 100m, 50m, 15m, };
static u32 sdio1_mux_table[] = {0, 1, 2, 3};
-static const char *fephy_mux_p[] __initconst = { 25m, 125m};
+static const char *fephy_mux_p[] __initdata = { 25m, 125m};
static u32 fephy_mux_table[] = {0, 1};
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index 9fc9359f5133..22d136aa699f 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -77,12 +77,12 @@ static void __init clk_misc_init(void)
writel_relaxed(30 BP_FRAC_IOFRAC, FRAC + SET);
}
-static const char *sel_pll[] __initconst = { pll, ref_xtal, };
-static const char *sel_cpu[] __initconst = { ref_cpu, ref_xtal, };
-static const char *sel_pix[] __initconst = { ref_pix, ref_xtal, };
-static const char *sel_io[] __initconst = { ref_io, ref_xtal, };
-static const char *cpu_sels[] __initconst = { cpu_pll, cpu_xtal, };
-static const char *emi_sels[] __initconst = { emi_pll, emi_xtal, };
+static const char *sel_pll[] __initdata = { pll, ref_xtal, };
+static const char *sel_cpu[] __initdata = { ref_cpu, ref_xtal, };
+static const char *sel_pix[] __initdata = { ref_pix, ref_xtal, };
+static const char *sel_io[] __initdata = { ref_io, ref_xtal, };
+static const char *cpu_sels[] __initdata = { cpu_pll, cpu_xtal, };
+static const char *emi_sels[] __initdata = { emi_pll, emi_xtal, };
enum imx23_clk {
ref_xtal, pll, ref_cpu, ref_emi, ref_pix, ref_io, saif_sel,
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index a6c35010e4e5..b1be3746ce95 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -125,15 +125,15 @@ static void __init clk_misc_init(void)
writel_relaxed(val, FRAC0);
}
-static const char *sel_cpu[] __initconst = { ref_cpu, ref_xtal, };
-static const char *sel_io0[] __initconst = { ref_io0, ref_xtal, };
-static const char *sel_io1[] __initconst = { ref_io1, ref_xtal, };
-static const char *sel_pix[] __initconst = { ref_pix, ref_xtal, };
-static const char *sel_gpmi[] __initconst = { ref_gpmi, ref_xtal, };
-static const char *sel_pll0[] __initconst = { pll0, ref_xtal, };
-static const char *cpu_sels[] __initconst = { cpu_pll, cpu_xtal, };
-static const char *emi_sels[] __initconst = { emi_pll, emi_xtal, };
-static const char *ptp_sels[] __initconst = { ref_xtal, pll0, };
+static const char *sel_cpu[] __initdata = { ref_cpu, ref_xtal, };
+static const char *sel_io0[] __initdata = { ref_io0, ref_xtal, };
+static const char *sel_io1[] __initdata = { ref_io1, ref_xtal, };
+static const char *sel_pix[] __initdata = { ref_pix, ref_xtal, };
+static const char *sel_gpmi[] __initdata = { ref_gpmi, ref_xtal, };
+static const char *sel_pll0[] __initdata = { pll0, ref_xtal, };
+static const char *cpu_sels[] __initdata = { cpu_pll, cpu_xtal, };
+static const char *emi_sels[] __initdata = { emi_pll, emi_xtal, };
+static const char *ptp_sels[] __initdata = { ref_xtal, pll0, };
enum imx28_clk {
ref_xtal, pll0, pll1, pll2, ref_cpu, ref_emi, ref_io0, ref_io1,
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 887cbdeca2aa..74fbb9c4b6de 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -120,7 +120,7 @@ struct clk *rockchip_clk_register_pll(enum
rockchip_pll_type pll_type,
struct rockchip_pll_rate_table *rate_table,
spinlock_t *lock);
-#define
Re: [PATCH] clk: don't use __initconst for non-const arrays
[adding Sylwester and removing my samsung.com e-mail which is no longer valid] On 11.09.2014 23:04, Uwe Kleine-König wrote: The statement static const char *name[]; defines a modifiable array of pointers to constant chars. That is *name[0] = 'f'; is forbidden, but name[0] = f; is not. So marking an array that is defined as above with __initconst is wrong. Either an additional const must be added such that the whole definition reads: static const char *const name[] __initconst; or where this is not possible __initdata must be used. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- drivers/clk/hisilicon/clk-hix5hd2.c | 6 ++-- drivers/clk/mxs/clk-imx23.c | 12 drivers/clk/mxs/clk-imx28.c | 18 ++-- drivers/clk/rockchip/clk.h | 2 +- drivers/clk/samsung/clk-s5pv210.c | 56 ++--- For drivers/clk/samsung/* Acked-by: Tomasz Figa tomasz.f...@gmail.com 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] clk: don't use __initconst for non-const arrays
Hello,
On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
/* Mux parent lists. */
-static const char *fin_pll_p[] __initconst = {
+static const char *fin_pll_p[] __initdata = {
xxti,
xusbxti
};
As discussed with Tomasz on irc: The sad thing here is that for this
array only 8 bytes are freed when .init.rodata is thrown away (that is
two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
freed though.
We wondered if there is a nice and easy way to throw away the
characters, too.
The only way I currently see is:
const char xxti[] __initconst = xxti;
...
static const char *fin_pll_p[] __initdata = {
xxti,
...
};
but this definitively doesn't qualify as nice and easy. Is there an
alternative?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
Hi, On Thu, Sep 11, 2014 at 11:03 AM, Mark Brown broo...@kernel.org wrote: On Thu, Sep 11, 2014 at 10:22:32AM +0100, Grant Likely wrote: On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org wrote: It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency. I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints. When things break I'm not sure that users are going to understand that something that used to work for them was only provided on a best effort basis, I think they will expect things to carry on working. Right. This is exactly what happened at the start of this thread. SimpleFB was working only on a best effort basis and then it stopped working. I agree that's pretty non-ideal. -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] clk: samsung: exynos5260: fix typo in clock name
Hi Pankaj, On 10.09.2014 07:56, Pankaj Dubey wrote: From: Chander Kashyap k.chan...@samsung.com The parent name added in parent list as mout_phyclk_mipi_dphy_4l_m_txbyte_clkhs_p, is different than the defined parent due to typo. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Signed-off-by: Chander Kashyap k.chan...@samsung.com Missed your sign-off? You can reply with it inline and I will add it when applying this weekend. P.S. Please keep me on CC when sending patches for Samsung clock drivers. 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
DTS for exynos5422 odroid-xu3: anyone working on it?
Just curious if anyone is working on upstream DTS for the odroid-xu3?
It's booting fine with mainline using exynos5420-smdk5420.dts, but would
like to see more devices added.
I found the DTS files in the hardkernel v3.10.y branch which can be used
as a starting point, but wanted to know if anyone else is working on it
before duplicating effort.
In particular, one of the first bits I'm trying to add are the nodes for
the on-board INA231 voltage/current sensors that are hanging of i2c_0.
I just stole the driver and DTS snippet[1] from the hardkernel tree and
tried it with mainline, and can get the driver to probe, but it fails
the first I2C write, suggesting that I'm missing something else in the
DTS, which leads me to this posting.
Kevin
[1]
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index d789a2361612..9d629377869e 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -31,6 +31,62 @@
};
};
+/* i2c0 INA231 Sensors */
+/*
+- include/linux/platform_data/ina231.h
+
+config = INA231_CONFIG(VSH_CT(eVSH_CT_8244uS) | \
+VBUS_CT(eVBUS_CT_8244uS) | \
+AVG_BIT(eAVG_16) | \
+eSHUNT_BUS_VOLT_CONTINUOUS),
+update_period = CONVERSION_DELAY(eVSH_CON_8244uS, eVBUS_CON_8244uS,
eAVG_CON_16), // unit = usec
+*/
+
+ i2c@12C6 {
+ status = okay;
+clock-frequency = 40;
+ina231@40 {
+ compatible = hardkernel,INA231;
+ reg = 0x40;
+ sensor-name = sensor_arm;
+ enable = 1;
+ max_A = 9;
+ shunt_R_mohm = 10;
+ config = 0x45FF;
+ update_period = 263808;
+};
+ina231@41 {
+ compatible = hardkernel,INA231;
+ reg = 0x41;
+ sensor-name = sensor_mem;
+ enable = 0;
+ max_A = 3;
+ shunt_R_mohm = 10;
+ config = 0x45FF;
+ update_period = 263808;
+};
+ina231@44 {
+ compatible = hardkernel,INA231;
+ reg = 0x44;
+ sensor-name = sensor_g3d;
+ enable = 0;
+ max_A = 5;
+ shunt_R_mohm = 10;
+ config = 0x45FF;
+ update_period = 263808;
+};
+ina231@45 {
+ compatible = hardkernel,INA231;
+ reg = 0x45;
+ sensor-name = sensor_kfc;
+ enable = 0;
+ max_A = 2;
+ shunt_R_mohm = 10;
+ config = 0x45FF;
+ update_period = 263808;
+};
+ };
+
regulators {
compatible = simple-bus;
#address-cells = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] clk: samsung: exynos5260: fix typo in clock name
Hi Tomasz, On Friday, September 12, 2014, Tomasz Figa wrote, To: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux-samsung- s...@vger.kernel.org; linux-ker...@vger.kernel.org Cc: kgene@samsung.com; s.nawro...@samsung.com; mturque...@linaro.org; Chander Kashyap; Abhilash Kesavan Subject: Re: [PATCH] clk: samsung: exynos5260: fix typo in clock name Hi Pankaj, On 10.09.2014 07:56, Pankaj Dubey wrote: From: Chander Kashyap k.chan...@samsung.com The parent name added in parent list as mout_phyclk_mipi_dphy_4l_m_txbyte_clkhs_p, is different than the defined parent due to typo. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Signed-off-by: Chander Kashyap k.chan...@samsung.com Missed your sign-off? You can reply with it inline and I will add it when applying this weekend. OK. P.S. Please keep me on CC when sending patches for Samsung clock drivers. Sure. Thanks, Pankaj Dubey Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
