[PATCH V3 2/3] ARM: shmobile: Convert to genpd flags for PM clocks for r8a7779
Instead of using the dev_ops -stop|start() callbacks for genpd, let's
convert to use genpd's flag field and set it to GENPD_PM_CLK.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v3:
Convert to renamed define.
Changes in v2:
None.
---
arch/arm/mach-shmobile/pm-r8a7779.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c
b/arch/arm/mach-shmobile/pm-r8a7779.c
index 82fe3d7..3a09ae7 100644
--- a/arch/arm/mach-shmobile/pm-r8a7779.c
+++ b/arch/arm/mach-shmobile/pm-r8a7779.c
@@ -83,9 +83,8 @@ static void r8a7779_init_pm_domain(struct r8a7779_pm_domain
*r8a7779_pd)
{
struct generic_pm_domain *genpd = r8a7779_pd-genpd;
+ genpd-flags = GENPD_PM_CLK;
pm_genpd_init(genpd, NULL, false);
- genpd-dev_ops.stop = pm_clk_suspend;
- genpd-dev_ops.start = pm_clk_resume;
genpd-dev_ops.active_wakeup = pd_active_wakeup;
genpd-power_off = pd_power_down;
genpd-power_on = pd_power_up;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 3/3] ARM: shmobile: Convert to genpd flags for PM clocks for R-mobile
Instead of using the dev_ops -stop|start() callbacks for genpd, let's convert to use genpd's flag field and set it to GENPD_PM_CLK. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- Changes in v3: Convert to renamed define. Changes in v2: None. --- arch/arm/mach-shmobile/pm-rmobile.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/arch/arm/mach-shmobile/pm-rmobile.c index 717e641..5aa277d 100644 --- a/arch/arm/mach-shmobile/pm-rmobile.c +++ b/arch/arm/mach-shmobile/pm-rmobile.c @@ -106,9 +106,8 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd) struct generic_pm_domain *genpd = rmobile_pd-genpd; struct dev_power_governor *gov = rmobile_pd-gov; + genpd-flags = GENPD_PM_CLK; pm_genpd_init(genpd, gov ? : simple_qos_governor, false); - genpd-dev_ops.stop = pm_clk_suspend; - genpd-dev_ops.start= pm_clk_resume; genpd-dev_ops.active_wakeup= rmobile_pd_active_wakeup; genpd-power_off= rmobile_pd_power_down; genpd-power_on = rmobile_pd_power_up; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/3] PM / Domains: Initial PM clock support for genpd
It's quite common for PM domains to use PM clocks. Typically from SOC
specific code, the per device PM clock list is created and
pm_clk_suspend|resume() are invoked to handle clock gating/ungating.
A step towards consolidation is to integrate PM clock support into
genpd, which is what this patch does.
In this initial step, the calls to the pm_clk_suspend|resume() are
handled within genpd, but the per device PM clock list still needs to
be created from SOC specific code. It seems reasonable to have gendp to
handle that as well, but that left to future patches to address.
It's not every users of genpd that are keen on using PM clocks, thus we
need to provide this a configuration option for genpd. Therefore let's
add flag field in the genpd struct to keep this information and define
a new GENDP_PM_CLK bit for it.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v3:
Moved define out of struct definition.
Don't use bitops.h
Rename define to GENDP_PM_CLK.
Changes in v2:
Set -start() callback to pm_clk_resume() and fixed comment.
---
drivers/base/power/domain.c | 7 +++
include/linux/pm_domain.h | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..a2424a7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -12,6 +12,7 @@
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
+#include linux/pm_clock.h
#include linux/slab.h
#include linux/err.h
#include linux/sched.h
@@ -1928,6 +1929,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
genpd-domain.ops.complete = pm_genpd_complete;
genpd-dev_ops.save_state = pm_genpd_default_save_state;
genpd-dev_ops.restore_state = pm_genpd_default_restore_state;
+
+ if (genpd-flags GENPD_PM_CLK) {
+ genpd-dev_ops.stop = pm_clk_suspend;
+ genpd-dev_ops.start = pm_clk_resume;
+ }
+
mutex_lock(gpd_list_lock);
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..173cc67 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -17,6 +17,9 @@
#include linux/notifier.h
#include linux/cpuidle.h
+/* Defines used for the flags field in the struct generic_pm_domain */
+#define GENPD_PM_CLK (1U 0) /* PM domain uses PM clk */
+
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
GPD_STATE_WAIT_MASTER, /* PM domain's master is being waited for */
@@ -76,6 +79,7 @@ struct generic_pm_domain {
struct device *dev);
void (*detach_dev)(struct generic_pm_domain *domain,
struct device *dev);
+ unsigned int flags; /* Bit field of configs for genpd */
};
static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/3] PM / Domains: Add initial PM clock support to genpd
Changes in v3: -Fixed comments from Rafael for patch 1. -Change name of define, affects all patches. Changes in v2: -Small fixes in patch 1. It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. In patch 2 and patch 3, we convert some of the SH-MOBILE SOCs to start using the new PM clock support in genpd. Ulf Hansson (3): PM / Domains: Initial PM clock support for genpd ARM: shmobile: Convert to genpd flags for PM clocks for r8a7779 ARM: shmobile: Convert to genpd flags for PM clocks for R-mobile arch/arm/mach-shmobile/pm-r8a7779.c | 3 +-- arch/arm/mach-shmobile/pm-rmobile.c | 3 +-- drivers/base/power/domain.c | 7 +++ include/linux/pm_domain.h | 4 4 files changed, 13 insertions(+), 4 deletions(-) -- 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 RFC v2 07/12] PM / Domains: export pm_genpd_lookup_name
On Thu, Nov 27, 2014 at 7:50 PM, Ulf Hansson ulf.hans...@linaro.org wrote: On 25 November 2014 at 09:48, amit daniel kachhap amit.dan...@samsung.com wrote: On Tue, Nov 25, 2014 at 1:05 PM, Ulf Hansson ulf.hans...@linaro.org wrote: On 24 November 2014 at 14:04, Amit Daniel Kachhap amit.dan...@samsung.com wrote: This API may be needed to set the power domain parent/child relationship in the power domain platform driver. The parent relationship is generally set after the child power domain is registered with the power domain subsystem. In this case, pm_genpd_lookup_name API might be useful. I think this is a step in the wrong direction. Instead we should be working on removing the name based APIs from genpd. The proper way should be to pass the PM domain as a parameter to the APIs instead. Yes i understand but i had a special requirement for using this API during pd probe. I cannot use hierarchy to represent parent/child pd nodes as it will break the existing SoC's. In my case all the PD nodes are linear. The parent/child relationship are established in the second pass after all the PD entries are registered with the help of this API. Although there a way that i can always keep parent PD's before the child PD's in DT in linear order. Will check this approach. I had some thinking around this, could the below approach work? I just posted a patch[1] adding a new pm_genpd_lookup() API, which is using a DT device node to fetch the genpd. The idea is to use that API to get the genpd handle which is needed to configure a subdomain through pm_genpd_add_subdomain() API. I looked at your patch. I seems fine. i will test them and post the new version of my series. Regards, Amit D In principle you will have to walk through the DT a couple of times, initialize those domains (and subdomains) which either don't have a parent domain or which parent domain already has been initialized. I guess you need a somewhat clever loop to do that, but I think it's doable. Obviously we also need to have a generic binding for a parent domain. I like Geert's proposal from the other patch, which means using power-domains = pd_xyz. Kind regards Uffe [1] http://marc.info/?l=linux-pmm=141709766008458w=2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hello,
On 2014-11-27 23:51, Russell King - ARM Linux wrote:
On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote:
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
So, I applied this series, and now I get a conflicts between my tree and
arm-soc for:
arch/arm/mach-exynos/firmware.c
arch/arm/mach-exynos/sleep.S
So, I'm going to un-stage the exynos bits, and we'll have to work out
some way to handle those.
I've already pointed that those patches depend on other previously merged to
exynos and arm-soc trees, but both Arnd and Kukjin said that those patch
series
should go via your kernel tree:
https://lkml.org/lkml/2014/11/15/158
That's why in v9 I rebased patches once again onto vanilla v3.18-rc4 and
uploaded
to your patch tracker. I see the following two possibilities to get them
merged:
1. Merge patches to rmk tree and resolve the merge conflict. The
conflict IS quite
easy to resolve - both trees, arm-soc and rmk only adds some code and
the goal is
simply to have both chunks added.
2. Merge the previous version (v8 from the above link) to arm-soc tree,
where it
applies cleanly on for-next, preferably with Russell's Acked-by.
Arnd, Russell: which approach do you prefer? How can I help to get it
merged?
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property
On czw, 2014-11-27 at 18:30 +, Mark Brown wrote:
On Thu, Nov 27, 2014 at 12:20:48PM +0100, Krzysztof Kozlowski wrote:
+- ena-gpios: GPIO to use for enable control. Actual implementation depends
+ on regulator driver. The bindings documentation for given driver
describes
+ which regulator actually supports it.
+- ena-gpio-open-drain: GPIO is open drain type.
I'm relly not a big fan of adding a fixed name property here with no
override capability, it means that the naming won't reflect the specific
regulator design so closely and in practice for many of the PMICs the
GPIO control can do rather more than just control enables and supports
reprogramming. The latter case where we've got a signal which can
sometimes be simply and enable but sometimes more makes it especially
worrying to have the property always be there, it's something that might
work in some configurations but could easily be broken if we try to
exploit more advanced functionality (things also triggering other
configuration changes at the same time).
I understand your concerns here however I didn't want to overengineer
this. Is the same GPIO (on more complex PMICs) used in different
contexts? Like enable control and something more in the same time?
For example the S5M8767 uses different GPIOs for:
1. enable control - one GPIO per regulator,
2. voltage selection (DVS) - 3 GPIOs total,
so there is no benefit in merging this into one common regulator code.
Factoring out the code is good but it seems better to have it be
something which drivers can control, for example by having them
explicitly specify a property name to use or perhaps a flag to enable
the default name.
Something like:
struct regulator_desc desc {
.name = LDO1
.of_match = of_match_ptr(LDO1),
.regulators_node = of_match_ptr(voltage-regulators),
.ops= max77686_ldo_ops,
+ .of_ena_gpio= of_match_ptr(ena-gpios),
...
}
?
We also need an invert option.
This is parsed from gpio specifier in DTS: the flags from
include/dt-bindings/gpio/gpio.h.
Thank you for feedback,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/7] regulator: of: Parse ena-gpios property from DTS
On czw, 2014-11-27 at 18:45 +, Mark Brown wrote:
On Thu, Nov 27, 2014 at 12:20:49PM +0100, Krzysztof Kozlowski wrote:
+ constraints-ena_gpio = of_get_named_gpio_flags(np, ena-gpios, 0,
+ gpio_flags);
+ if (gpio_is_valid(constraints-ena_gpio)) {
No, this isn't sensible - in what way would an enable control GPIO be a
constraint? The whole reason we have separate constraint and config
structures is that these are different things. Keep the GPIO setup in
the configuration.
OK, I'll change it to config.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
On czw, 2014-11-27 at 18:43 +, Mark Brown wrote:
On Thu, Nov 27, 2014 at 12:20:50PM +0100, Krzysztof Kozlowski wrote:
Use ena_gpio from regulator constraints (filled by parsing generic
bindings) to initialize the GPIO enable control. Support also the old
way: ena_gpio supplied in regulator_config structure.
This also adds a new set_ena_gpio() callback in regulator_ops structure
which driver may provide to actually enable the GPIO control in
hardware.
This seems really confused like it's trying to work around some other
problem - this all feels like it's at the wrong abstraction level. As
far as I can tell this is trying to fix bugs in the previous patch and
do some other refactorings (the also add this other random op bit
especially) but I'm really not clear what the goal is.
Please try to think if the code you're writing makes sense at the big
picture level rather than just band aiding specific problems you see.
It's also a good idea to keep random code motion separate from
functional changes since it makes it much easier to follow what each is
supposed to do.
@@ -1044,6 +1045,14 @@ static int set_machine_constraints(struct
regulator_dev *rdev,
}
}
+ if (rdev-constraints-use_ena_gpio ops-set_ena_gpio) {
+ ret = ops-set_ena_gpio(rdev);
+ if (ret 0) {
+ rdev_err(rdev, failed to set enable GPIO control\n);
+ goto out;
+ }
+ }
Why do we need some special magic operation for GPIO based enables
that's separate to any other enable operation? This seems really
confusing, if the constraint setting doesn't work somehow for GPIO based
enables we should fix that. Though since this operation takes no
parameters it's hard to see how it's supposed to apply constraints
unless it reparses them which doesn't seem like a good idea...
The regulator driver no longer parses GPIO control from DTS. So somehow
it should be notified that regulator core parsed this and GPIO should be
enabled.
That is the purpose of ops-set_ena_gpio() call.
static int regulator_ena_gpio_request(struct regulator_dev *rdev,
- const struct regulator_config *config)
- ret = gpio_request_one(config-ena_gpio,
- GPIOF_DIR_OUT | config-ena_gpio_flags,
+ ret = gpio_request_one(gpio, GPIOF_DIR_OUT | gpio_flags,
rdev_get_name(rdev));
+/*
+ * Request GPIO for enable control from regulator_config
+ * or init_data-constraints.
+ */
+static int regulator_ena_gpio_setup(struct regulator_dev *rdev,
+ const struct regulator_config *config,
+ const struct regulator_init_data *init_data)
Why is setting up the GPIO different to requesting it, especially given
that we have an existing function called _request() which still exists?
Maybe the name was not a best choice. The setup calls request.
My patchset here tried to retain the compatibility with
config.ena_gpio way so the core would accept GPIOs passed in one of
two ways:
1. old: config.ena_gpio,
2. new: parsed by core from DTS.
The request function previously worked only on config.ena_gpio and I
changed it here to accept any GPIO. The setup uses one of GPIO methods
(old or new) and calls request with appropriate GPIO.
Anyway this will change after your comments about not using constraints
(patch 3/7). I'll keep your comments about big picture level in mind and
start working on next version.
Thanks for feedback!
Best regards,
Krzysztof
--
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] PM / Domains: Add pm_genpd_lookup() API to lookup domain by firmware node
In a step to move away from using genpd's name based APIs, such as the
pm_genpd_add_subdomain_names(), provide an API to lookup an already
initialized generic PM domain by its firmware node.
This API would typically be a called from SOC specific code, to fetch a
handle to the domain. Especially convenient to configure subdomains and
when the hierarchy of the domains are described in DT.
Do note, before pm_genpd_init() is invoked to initialize a generic PM
domain, it's the callers responsibility to assign the new -fwnode
pointer in the struct generic_pm_domain, to enable pm_genpd_lookup() to
find the domain.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v2:
Change from using struct device_node to struct fwnode_handle.
Updated commit header accordingly.
---
drivers/base/power/domain.c | 27 +++
include/linux/pm_domain.h | 4
2 files changed, 31 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..2d881d5 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -75,6 +75,33 @@ struct generic_pm_domain *dev_to_genpd(struct device *dev)
return pd_to_genpd(dev-pm_domain);
}
+/**
+ * pm_genpd_lookup - Fetch a generic PM domain object by firmware node.
+ * @node: Firmware node to a corresponding genpd.
+ *
+ * Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
+ * on failure.
+ */
+struct generic_pm_domain *pm_genpd_lookup(struct fwnode_handle *node)
+{
+ struct generic_pm_domain *genpd = ERR_PTR(-ENOENT), *gpd;
+
+ if (IS_ERR_OR_NULL(node))
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(gpd_list_lock);
+ list_for_each_entry(gpd, gpd_list, gpd_list_node) {
+ if (gpd-fwnode == node) {
+ genpd = gpd;
+ break;
+ }
+ }
+ mutex_unlock(gpd_list_lock);
+
+ return genpd;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_lookup);
+
static int genpd_stop_dev(struct generic_pm_domain *genpd, struct device *dev)
{
return GENPD_DEV_TIMED_CALLBACK(genpd, int, stop, dev,
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..aa01050 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -43,6 +43,8 @@ struct gpd_cpuidle_data {
struct cpuidle_state *idle_state;
};
+struct fwnode_handle;
+
struct generic_pm_domain {
struct dev_pm_domain domain;/* PM domain operations */
struct list_head gpd_list_node; /* Node in the global PM domains list */
@@ -53,6 +55,7 @@ struct generic_pm_domain {
struct dev_power_governor *gov;
struct work_struct power_off_work;
const char *name;
+ struct fwnode_handle *fwnode; /* Firware node for the PM domain */
unsigned int in_progress; /* Number of devices being suspended
now */
atomic_t sd_count; /* Number of subdomains with power on */
enum gpd_status status; /* Current state of the domain */
@@ -126,6 +129,7 @@ static inline struct generic_pm_domain_data
*dev_gpd_data(struct device *dev)
}
extern struct generic_pm_domain *dev_to_genpd(struct device *dev);
+extern struct generic_pm_domain *pm_genpd_lookup(struct fwnode_handle *node);
extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,
struct device *dev,
struct gpd_timing_data *td);
--
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 v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
On Friday 28 November 2014 09:55:53 Marek Szyprowski wrote: On 2014-11-27 23:51, Russell King - ARM Linux wrote: On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote: Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+ boards (both with secure firmware). There should be no functional change for Exynos boards running without secure firmware. I do not have access to affected non-Exynos boards, so I could not test on them. So, I applied this series, and now I get a conflicts between my tree and arm-soc for: arch/arm/mach-exynos/firmware.c arch/arm/mach-exynos/sleep.S So, I'm going to un-stage the exynos bits, and we'll have to work out some way to handle those. Ok I've already pointed that those patches depend on other previously merged to exynos and arm-soc trees, but both Arnd and Kukjin said that those patch series should go via your kernel tree: https://lkml.org/lkml/2014/11/15/158 That's why in v9 I rebased patches once again onto vanilla v3.18-rc4 and uploaded to your patch tracker. I see the following two possibilities to get them merged: 1. Merge patches to rmk tree and resolve the merge conflict. The conflict IS quite easy to resolve - both trees, arm-soc and rmk only adds some code and the goal is simply to have both chunks added. 2. Merge the previous version (v8 from the above link) to arm-soc tree, where it applies cleanly on for-next, preferably with Russell's Acked-by. Arnd, Russell: which approach do you prefer? How can I help to get it merged? I'm fine with it either way. Russell, if you like you can merge http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung v3.19-next/pm-samsung-2 into your tree and resolve the conflict on your end, we have a stable copy of that branch queued in next/soc. If you prefer v8 to go through arm-soc, that's fine with me too, or we could share a branch with v9 of Marek's series and have that merged into arm-soc/next/soc to resolve the conflict. arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/exynos: fimd: Remove drm_dev pointer from fimd_context
ctx-drm_dev is unnecessary since it can be easily
accessed via ctx-manager-drm_dev, cleaning it up.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..122c851 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -159,7 +159,6 @@ struct fimd_win_data {
struct fimd_context {
struct exynos_drm_manager manager;
struct device *dev;
- struct drm_device *drm_dev;
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
@@ -298,17 +297,17 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
struct exynos_drm_private *priv;
priv = drm_dev-dev_private;
- mgr-drm_dev = ctx-drm_dev = drm_dev;
+ mgr-drm_dev = drm_dev;
mgr-pipe = ctx-pipe = priv-pipe++;
/* attach this sub driver to iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev)) {
+ if (is_drm_iommu_supported(mgr-drm_dev)) {
/*
* If any channel is already active, iommu will throw
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(ctx-drm_dev, ctx-dev);
+ drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
}
return 0;
@@ -319,8 +318,8 @@ static void fimd_mgr_remove(struct exynos_drm_manager *mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* detach this sub driver from iommu mapping if supported. */
- if (is_drm_iommu_supported(ctx-drm_dev))
- drm_iommu_detach_device(ctx-drm_dev, ctx-dev);
+ if (is_drm_iommu_supported(mgr-drm_dev))
+ drm_iommu_detach_device(mgr-drm_dev, ctx-dev);
}
static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
@@ -1001,7 +1000,7 @@ static void fimd_te_handler(struct exynos_drm_manager
*mgr)
struct fimd_context *ctx = mgr_to_fimd(mgr);
/* Checks the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (ctx-pipe 0 || !mgr-drm_dev)
return;
/*
@@ -1018,7 +1017,7 @@ static void fimd_te_handler(struct exynos_drm_manager
*mgr)
}
if (test_bit(0, ctx-irq_flags))
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(mgr-drm_dev, ctx-pipe);
}
static struct exynos_drm_manager_ops fimd_manager_ops = {
@@ -1047,17 +1046,19 @@ static irqreturn_t fimd_irq_handler(int irq, void
*dev_id)
writel(clear_bit, ctx-regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx-pipe 0 || !ctx-drm_dev)
+ if (ctx-pipe 0 || !ctx-manager.drm_dev)
goto out;
if (ctx-i80_if) {
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-pipe);
/* Exits triggering mode */
atomic_set(ctx-triggering, 0);
} else {
- drm_handle_vblank(ctx-drm_dev, ctx-pipe);
- exynos_drm_crtc_finish_pageflip(ctx-drm_dev, ctx-pipe);
+ drm_handle_vblank(ctx-manager.drm_dev, ctx-pipe);
+ exynos_drm_crtc_finish_pageflip(ctx-manager.drm_dev,
+ ctx-pipe);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(ctx-wait_vsync_event)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: fimd: check error status for drm_iommu_attach_device
check error status for drm_iommu_attach_device() and make sure
it propagates till the caller.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 122c851..528420c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -295,6 +295,8 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
{
struct fimd_context *ctx = mgr_to_fimd(mgr);
struct exynos_drm_private *priv;
+ int ret;
+
priv = drm_dev-dev_private;
mgr-drm_dev = drm_dev;
@@ -307,7 +309,12 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
* a PAGE FAULT when enabled. So clear any channel if enabled.
*/
fimd_clear_channel(mgr);
- drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+
+ ret = drm_iommu_attach_device(mgr-drm_dev, ctx-dev);
+ if (ret) {
+ DRM_ERROR(drm_iommu_attach failed.\n);
+ return ret;
+ }
}
return 0;
@@ -1075,8 +1082,14 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ int ret;
+
+ ret = fimd_mgr_initialize(ctx-manager, drm_dev);
+ if (ret) {
+ DRM_ERROR(fimd_mgr_initialize failed.\n);
+ return ret;
+ }
- fimd_mgr_initialize(ctx-manager, drm_dev);
exynos_drm_crtc_create(ctx-manager);
if (ctx-display)
exynos_drm_create_enc_conn(drm_dev, ctx-display);
--
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 v4 2/7] regulator: dt-bindings: Document the ena-gpios property
On Fri, Nov 28, 2014 at 10:09:44AM +0100, Krzysztof Kozlowski wrote:
I understand your concerns here however I didn't want to overengineer
this. Is the same GPIO (on more complex PMICs) used in different
contexts? Like enable control and something more in the same time?
Yes, and it's often reprogrammable at runtime.
Something like:
struct regulator_desc desc {
.name = LDO1
.of_match = of_match_ptr(LDO1),
.regulators_node = of_match_ptr(voltage-regulators),
.ops= max77686_ldo_ops,
+ .of_ena_gpio= of_match_ptr(ena-gpios),
...
}
Yes, and note that this also means existing bindings can use the core
code.
signature.asc
Description: Digital signature
[PATCH V2] drm/exynos: Add DECON driver
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1037
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1466 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool Exynos DRM DECON
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool EXYNOS DRM parallel output support
- depends on DRM_EXYNOS_FIMD
+ depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS_DECON)
select DRM_PANEL
default n
help
@@
Re: [PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On Fri, 28 Nov 2014 13:35:49 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 November 2014 at 19:42, Eduardo Valentin edubez...@gmail.com
wrote:
(I'm sorry VireshK, I am still using my normal practice) :-)
That's fine :)
diff --git a/drivers/thermal/cpu_cooling.c
b/drivers/thermal/cpu_cooling.c index 1ab0018..bed3fa2 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node
*np, int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_frequency_get_table(0)) {
+ pr_err(cpu_cooling: cpufreq layer not ready!
Deferring.\n);
Throwing an error here doesn't look to be the right thing. Ultimately
we will register the cooling dev when probed again after some time.
So, a pr_debug() suits more here.
Also, this breaks existing exynos thermal drivers as they don't handle
-EPROBE_DEFER well right now.
Unfortunately Viresh is correct here. Current (before rework) Exynos
TMU driver expects that cpu_cooling device will succeed.
I reached here, because one of my patches had something similar to
what you wrote. Just for this file though, haven't updated any other
drivers though.
Will be sending you my small patchset by end of day today, please see
if they make any sense at all..
Best regards,
Łukasz Majewski
signature.asc
Description: PGP signature
Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
On Fri, Nov 28, 2014 at 11:30:55AM +0100, Krzysztof Kozlowski wrote: On czw, 2014-11-27 at 18:43 +, Mark Brown wrote: Why do we need some special magic operation for GPIO based enables that's separate to any other enable operation? This seems really confusing, if the constraint setting doesn't work somehow for GPIO based enables we should fix that. Though since this operation takes no parameters it's hard to see how it's supposed to apply constraints unless it reparses them which doesn't seem like a good idea... The regulator driver no longer parses GPIO control from DTS. So somehow it should be notified that regulator core parsed this and GPIO should be enabled. That is the purpose of ops-set_ena_gpio() call. This sort of thing is a sign that we're not saving much by moving the parsing to the core and perhaps there's more flexiblity here... It's also not something that should be in the constraints handling, it's not something that constrains the regulator. +static int regulator_ena_gpio_setup(struct regulator_dev *rdev, + const struct regulator_config *config, + const struct regulator_init_data *init_data) Why is setting up the GPIO different to requesting it, especially given that we have an existing function called _request() which still exists? Maybe the name was not a best choice. The setup calls request. My patchset here tried to retain the compatibility with config.ena_gpio way so the core would accept GPIOs passed in one of two ways: 1. old: config.ena_gpio, 2. new: parsed by core from DTS. The request function previously worked only on config.ena_gpio and I changed it here to accept any GPIO. The setup uses one of GPIO methods (old or new) and calls request with appropriate GPIO. We need to support both methods since not all the world is DT. What I can't tell is how this code achieves these objectives - it seems to be an awfully big patch if that's all it's supposed to be doing, I'd expect just a conditional where we try the two methods in turn. It may be that there's a good reason for all this but that needs to be made clear. signature.asc Description: Digital signature
[PATCH 1/3] ARM: dts: add fimd device support for exynos3250-rinato
This patch adds fimd device node which is a display controller
for Exynos3250 Rinato board.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 80aa8b4..79aa916 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,17 @@
};
};
+fimd {
+ status = okay;
+
+ i80-if-timings {
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-act = 1;
+ wr-hold = 0;
+ };
+};
+
i2c_0 {
#address-cells = 1;
#size-cells = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] add Display support for exynos3250 Rinato board
This patch series adds Display support for exynos3250 Rinato board. For this, it adds fimd, MIPI-DSI and Panel device nodes to exynos3250-rinato dts file, and adds a s6e63j0x03 Amoled panel device driver which is based on MIPI-DSI bus. Inki Dae (3): ARM: dts: add fimd device support for exynos3250-rinato drm/panel: add s6e63j0x03 LCD Panel driver ARM: dts: add Panel device support for exynos3250-rinato arch/arm/boot/dts/exynos3250-rinato.dts | 70 +++ drivers/gpu/drm/panel/Kconfig|6 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e63j0x03.c | 693 ++ 4 files changed, 770 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] drm/panel: add s6e63j0x03 LCD Panel driver
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD Panel driver
which uses mipi_dsi bus to communicate with Panel.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig|6 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-s6e63j0x03.c | 693 ++
3 files changed, 700 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bee9f72..bc133e2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -27,4 +27,10 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E63J0X03
+ tristate S6E63J0X03 DSI video mode panel
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..7f36dc2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E63J0X03) += panel-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
new file mode 100644
index 000..7b8d8ca
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
@@ -0,0 +1,693 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, inki@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 drm/drmP.h
+#include drm/drm_mipi_dsi.h
+#include drm/drm_panel.h
+
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
+#include linux/backlight.h
+
+#include video/mipi_display.h
+#include video/of_videomode.h
+#include video/videomode.h
+
+#define GAMMA_LEVEL_NUM30
+#define MTP_ID_LEN 6
+/* Manufacturer Command Set */
+#define MCS_MTP_ID 0xD3
+
+#define MCS_MTP_SET3 0xd4
+#define MCS_MTP_KEY0xf1
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define GAMMA_CMD_CNT 28
+#define MAX_GAMMA_CNT 11
+
+struct s6e63j0x03 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct backlight_device *bl_dev;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ u32 power_on_delay;
+ u32 power_off_delay;
+ u32 reset_delay;
+ u32 init_delay;
+ bool flip_horizontal;
+ bool flip_vertical;
+ struct videomode vm;
+ u32 width_mm;
+ u32 height_mm;
+
+ int power;
+
+ /* This field is tested by functions directly accessing DSI bus before
+* transfer, transfer is skipped if it is set. In case of transfer
+* failure or unexpected response the field is set to error value.
+* Such construct allows to eliminate many checks in higher level
+* functions.
+*/
+ int error;
+};
+
+static const unsigned char GAMMA_10[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26, 0x28, 0x2d,
+ 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36, 0x35, 0x00, 0xab, 0x00,
+ 0xae, 0x00, 0xbf
+};
+
+static const unsigned char GAMMA_30[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26, 0x27, 0x2a,
+ 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34, 0x35, 0x00, 0xc4, 0x00,
+ 0xca, 0x00, 0xdc
+};
+
+static const unsigned char GAMMA_60[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a, 0x28, 0x29,
+ 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33, 0x34, 0x00, 0xd9, 0x00,
+ 0xe4, 0x00, 0xf5
+};
+
+static const unsigned char GAMMA_90[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29, 0x28, 0x28,
+ 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31, 0x31, 0x00, 0xea, 0x00,
+ 0xf6, 0x01, 0x09
+};
+
+static const unsigned char GAMMA_120[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28, 0x28, 0x27,
+ 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31, 0x30, 0x00, 0xf9, 0x01,
+ 0x05, 0x01, 0x1b
+};
+
+static const unsigned char GAMMA_150[] = {
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x31, 0x51, 0x53, 0x66, 0x66, 0x67, 0x28, 0x29, 0x27,
+ 0x28, 0x27, 0x27, 0x2e, 0x2d, 0x2e, 0x31, 0x31, 0x30, 0x01, 0x04, 0x01,
+ 0x11, 0x01, 0x29
+};
+
+static
[PATCH 3/3] ARM: dts: add Panel device support for exynos3250-rinato
This patch adds MIPI-DSI and MIPI-DSI based S6E63J0X03 AMOLED panel
device nodes for Exynos3250 Rinato board.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 59 +++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 79aa916..6e0e90d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,65 @@
};
};
+dsi_0 {
+ vddcore-supply = ldo6_reg;
+ vddio-supply = ldo6_reg;
+ samsung,pll-clock-frequency = 2400;
+ status = okay;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@1 {
+ reg = 1;
+
+ dsi_out: endpoint {
+ remote-endpoint = dsi_in;
+ samsung,burst-clock-frequency = 25000;
+ samsung,esc-clock-frequency = 2000;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = samsung,s6e63j0x03;
+ reg = 0;
+ vdd3-supply = ldo16_reg;
+ vci-supply = ldo20_reg;
+ reset-gpios = gpe0 1 0;
+ te-gpios = gpx0 6 0;
+ power-on-delay= 30;
+ power-off-delay= 120;
+ reset-delay = 5;
+ init-delay = 100;
+ flip-horizontal;
+ flip-vertical;
+ panel-width-mm = 29;
+ panel-height-mm = 29;
+
+ display-timings {
+ timing-0 {
+ clock-frequency = 0;
+ hactive = 320;
+ vactive = 320;
+ hfront-porch = 1;
+ hback-porch = 1;
+ hsync-len = 1;
+ vfront-porch = 150;
+ vback-porch = 1;
+ vsync-len = 2;
+ };
+ };
+
+ port {
+ dsi_in: endpoint {
+ remote-endpoint = dsi_out;
+ };
+ };
+ };
+};
+
fimd {
status = okay;
--
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 v4 2/7] regulator: dt-bindings: Document the ena-gpios property
On pią, 2014-11-28 at 11:21 +, Mark Brown wrote:
On Fri, Nov 28, 2014 at 10:09:44AM +0100, Krzysztof Kozlowski wrote:
I understand your concerns here however I didn't want to overengineer
this. Is the same GPIO (on more complex PMICs) used in different
contexts? Like enable control and something more in the same time?
Yes, and it's often reprogrammable at runtime.
I have doubts if generalized code could support such configuration...
Something like:
struct regulator_desc desc {
.name = LDO1
.of_match = of_match_ptr(LDO1),
.regulators_node = of_match_ptr(voltage-regulators),
.ops= max77686_ldo_ops,
+ .of_ena_gpio= of_match_ptr(ena-gpios),
...
}
Yes, and note that this also means existing bindings can use the core
code.
Thanks for idea,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] pinctrl: exynos: add exynos5410 SoC specific data
On Sat, Nov 22, 2014 at 11:26 PM, Andreas Färber afaer...@suse.de wrote:
From: Hakjoo Kim ruppi@hardkernel.com
Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.
Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased onto Exynos5260 and irq_chip consolidation]
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)
v1 - v2:
* Filled in Sob from Hakjoo Kim
Is this based on the pinctrl devel branch so I can apply it?
I'd like Tomasz ACK on it first though.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] pinctrl: exynos: add exynos5410 SoC specific data
Am 28.11.2014 um 12:59 schrieb Linus Walleij:
On Sat, Nov 22, 2014 at 11:26 PM, Andreas Färber afaer...@suse.de wrote:
From: Hakjoo Kim ruppi@hardkernel.com
Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.
Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased onto Exynos5260 and irq_chip consolidation]
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)
v1 - v2:
* Filled in Sob from Hakjoo Kim
Is this based on the pinctrl devel branch so I can apply it?
It was based on the Samsung for-next tree. I can rebase if needed.
I'd like Tomasz ACK on it first though.
Thanks,
Andreas
--
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: exynos_defconfig: Enable CONFIG_FHANDLE
CONFIG_FHANDLE is required by systemd, which is the default init system in more and more distributions. So lets enable it for Exynos as well (it's already enabled in multi_v7_defconfig) Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e419fac..d4751ef 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -1,4 +1,5 @@ CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_CGROUPS=y -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable CONFIG_FHANDLE
Am 28.11.2014 um 13:06 schrieb Sjoerd Simons: CONFIG_FHANDLE is required by systemd, which is the default init system in more and more distributions. So lets enable it for Exynos as well (it's already enabled in multi_v7_defconfig) Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Reviewed-by: Andreas Färber afaer...@suse.de Thanks, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg -- 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: [GIT PULL 1/5] Samsung non-critical fixes for v3.19
On Friday 21 November 2014, Kukjin Kim wrote: Samsung non-critical-fixes for v3.19 - fix typo in static struct name exynos5_list_diable_wfi_wfe : it should be exynos5_list_disable_wfi_wfe Pulled into next/fixes-non-critical, thanks! 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: [GIT PULL 2/5] Samsung 2nd round of cleanup for v3.19
On Friday 21 November 2014, Kukjin Kim wrote: The following changes since commit 13cfa6c4f7facfc690ba9e99ec382c151fddaced: ARM: EXYNOS: Fix CPU idle clock down after CPU off (2014-10-21 00:06:22 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cleanup-2 for you to fetch changes up to 9c50b2a98cf0ca70480b70a4490a87177519094c: ARM: EXYNOS: Remove unused static iomapping (2014-11-13 11:42:59 +0900) Samsung 2nd cleanup for v3.19 - remove unused static iomapping for exynos SoCs : remove unused static iomapping from exynos4/5_iodesc table, and related macros from mach/map.h and plat/map-s5p.h. Nice cleanup! Applied to next/cleanup, thanks! 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: [GIT PULL 3/5] Samsung defconfig update for v3.19
On Friday 21 November 2014, Kukjin Kim wrote: The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig-v3.19 for you to fetch changes up to 26048def56ac2f901d4245d2935c797984e96d68: ARM: exynos_defconfig: Use 16 minors per MMC block device (2014-11-21 22:04:05 +0900) Samsung defconfig update for v3.19 - Use 16 minors per MMC block device for exynos_defconfig : 16 minors per MMC block device are required for Rinato (Gear 2) The defconfig branch didn't have v3.18-rc3 yet, so I cherry-picked the one patch from this branch to avoid a back-merge from upstream. Please make sure to base patches on older -rc releases if you can, it makes our lives easier. Thanks! 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: [GIT PULL 4/5] Samsung 2nd round of DT updates for v3.19
On Friday 21 November 2014, Kukjin Kim wrote: Samsung 2nd DT updates for v3.19 - add micro SD card SDHCI node for exynos4412-trats - add exynos4415 DT - add exynos3250-rinato DT and sleep mode support Note: based on previous tags/samsung-dt for v3.19 Pulled into next/dt, thanks! 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: [GIT PULL 5/5] Samsung exynos updates for v3.19
On Friday 21 November 2014, Kukjin Kim wrote: Samsung exynos updates in arch/arm/mach-exynos/ for v3.19 - add SOC_EXYNOS4415 config to be used in audio driver - add support platform driver for exynos PMU - move PMU specific definitions from common.h to exynos-pmu.h - for exynos5420, add support PMU and Suspend-to-RAM use MCPM call backs and call regulator core suspend prepare and finish functions Pulled into next/soc, thanks! 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: [GIT PULL 1/4] Samsung 3rd round of PM updates for v3.19
On Thursday 27 November 2014, Kukjin Kim wrote: The following changes since commit c645a598f99768e6cc82129081458dfdd0c273b7: ARM: EXYNOS: Call regulator core suspend prepare and finish functions (2014-11-21 22:49:47 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-pm-3 for you to fetch changes up to b04fa9f704aa818b87509ff4149bba810ef8bbd8: ARM: EXYNOS: use u8 for val[] in struct exynos_pmu_conf (2014-11-27 02:47:05 +0900) Samsung PM 3rd updates for v3.19 - exynos3250 : add PMU support - PMU refactoring : move restart code into PMU driver : move restart code for exynos440 into clk driver - use u8 for val[] in struct exynos_pmu_conf Note that this branch is based on tags/samsung-exynos-v3.19 Pulled into next/soc, thanks! 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: [GIT PULL 2/4] Samsung serial updates for v3.19
On Thursday 27 November 2014, Kukjin Kim wrote: Hi Arnd, Olof, Kevin Please pull this branch for exynos7 SoC into arm-soc. Note Greg agreed to upstream via arm-soc tree. I don't really see any dependency on anything else here, so I wonder why you are sending it to me, but I assume there is some reason and it's trivial enough. Pulled into next/drivers. 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: [GIT PULL 3/4] Samsung 3rd round of DT updates for v3.19
On Thursday 27 November 2014, Kukjin Kim wrote: Samsung 3rd DT updates for v3.19 - exynos3250 : remove unused bootargs on exynos3250-rinato : add new board dt file for exynos3250-monk - exynos4 : add missing clock for MFC : specify default clocks for camera - exynos4x12 : add TMU related DT nodes - exynos4412-trats2 : add max77693-haptic and pwm nodes, enable TMU support - exynos4412-odroid : specify audio clock parents and rates - exynos5250 and exynos5420 : add syscon based phandle to i2c device nodes - exynos5250-spring : add trackpad, temperature sensor and usb3505 pinctrl Note: based on previous tags/samsung-dt-2 for v3.19 Pulled into next/dt, thanks! 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] ARM: exynos_defconfig: Enable CONFIG_FHANDLE
Hello Sjoerd, On 11/28/2014 01:06 PM, Sjoerd Simons wrote: CONFIG_FHANDLE is required by systemd, which is the default init system in more and more distributions. So lets enable it for Exynos as well (it's already enabled in multi_v7_defconfig) Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e419fac..d4751ef 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -1,4 +1,5 @@ CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y This is certainly required for newer systemd and has to be enabled. But it would also be great to have enabled all the config symbols that are listed as requirements in the systemd README file: http://cgit.freedesktop.org/systemd/systemd/tree/README. Tony added that support to OMAP2+ defconfig in commit 673ce00c (ARM: omap2plus_defconfig: Add support for distros with systemd) so the same should be done in exynos_defconfig. That can of course be a follow-up patch though, so for $subject: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk 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: [GIT PULL 4/4] Samsung exynos7 updates for v3.19
On Thursday 27 November 2014, Kukjin Kim wrote: Samsung arch/arm64 DT updates for v3.19 - to support ARMv8 based exynos7 SoC : add initial device tree and add pinctrl, PMU, mmc, i2c, rtc, watchdog, and adc nodes for exynos7 SoC and exynos7 based espresso board. NOTE that this is including following dependencies : cleanup/dts-subdirs in arm-soc for arm64 vendor support : tags/samsung-driver for samsung serial : for-v3.19/exynos-clk in samsung-clk tree for exynos7 clk One more NOTE, for support exynos7 we need Liviu's arm64: Create link to include/dt-bindings to enable C preprocessor use in arm-soc tree and arm64 defconfig update should be handled directly. I'm confused by the dependencies. I don't see a for-v3.19/exynos-clk in arm-soc, you haven't put the clk maintainer on Cc and I see no indication that he has this in his tree already, so I'm not pulling this until further clarification. 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: [PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
Hello Folks,
On Fri, Nov 28, 2014 at 11:18:24AM +0100, Lukasz Majewski wrote:
On Fri, 28 Nov 2014 13:35:49 +0530
Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 November 2014 at 19:42, Eduardo Valentin edubez...@gmail.com
wrote:
(I'm sorry VireshK, I am still using my normal practice) :-)
That's fine :)
diff --git a/drivers/thermal/cpu_cooling.c
b/drivers/thermal/cpu_cooling.c index 1ab0018..bed3fa2 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node
*np, int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_frequency_get_table(0)) {
+ pr_err(cpu_cooling: cpufreq layer not ready!
Deferring.\n);
Throwing an error here doesn't look to be the right thing. Ultimately
we will register the cooling dev when probed again after some time.
So, a pr_debug() suits more here.
Yeah, I agree here.
Also, this breaks existing exynos thermal drivers as they don't handle
-EPROBE_DEFER well right now.
Unfortunately Viresh is correct here. Current (before rework) Exynos
TMU driver expects that cpu_cooling device will succeed.
Well, I wouldn't say unfortunately, but fortunately! :-)
Ok. But I believe it is a matter of propagating the error code. As I
included in this patch:
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..f84975e 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -373,7 +373,7 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
dev_err(sensor_conf-dev,
Failed to register cpufreq cooling device\n);
- ret = -EINVAL;
+ ret =
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
goto err_unregister;
}
th_zone-cool_dev_size++;
I reached here, because one of my patches had something similar to
what you wrote. Just for this file though, haven't updated any other
drivers though.
Will be sending you my small patchset by end of day today, please see
if they make any sense at all..
The version you sent (for exynos) is better because there is a check for
not print error messages in case of deferring.
However, I would prefer, at least to what comes to deferring, to update
the drivers altogether with the inclusion of the check in cpu cooling.
This way the change in behavior is atomic, in terms of commit changes.
Viresh, if you don't mind, I will merge your patch 04/26 into this one.
Best regards,
Łukasz Majewski
BR, Eduardo Valentin
signature.asc
Description: Digital signature
Re: [PATCH 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Dear Mark,
On 11/27/2014 08:18 PM, Mark Rutland wrote:
On Thu, Nov 27, 2014 at 07:35:13AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
Cc: Kukjin Kim kgene@samsung.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Geunsik Lim geunsik@samsung.com
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
+
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
2 files changed, 1221 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
new file mode 100644
index 000..3d8b576
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -0,0 +1,523 @@
+/*
+ * Samsung's Exynos5433 SoC device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC device nodes are listed in this file. Exynos5433
+ * based board files can include this file and provide values for board
specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * Exynos5433 SoC. As device tree coverage for Exynos5433 increases,
additional
+ * nodes can be added to this file.
+ *
+ * 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 skeleton.dtsi
+#include dt-bindings/clock/exynos5433.h
+
Just to check: no memory reservations required for any reason?
There also don't appear to be any memory nodes. Typically if that's
filled in by the bootloader/FW we'd have an empty node (or one with a
zero size entry) and a comment regarding the FW.
I add the memory node to board dtsi file because memory information
is more dependent on on h/w target than SoC.
+/ {
+ compatible = samsung,exynos5433;
+ #address-cells = 1;
+ #size-cells = 1;
Not two, on both counts? The CPUs can address more than 32 bits.
You're right. I'll fix it as two and then retry to test it.
Is there nothing in the physical address space above 0x?
[...]
+ cpus {
+ #address-cells = 2;
+ #size-cells = 0;
+
+ cpu0: cpu@100 {
+ device_type = cpu;
+ compatible = arm,cortex-a53, arm,armv8;
+ enable-method = psci;
While the CPU nodes have enable-methods, I didn't spot a PSCI node
anywhere, so this dts cannot possibly have been used to bring up an SMP
system.
How has this dts been tested?
What PSCI revision have you implemented? Have have you tested it?
My mistake,
Exynos5433 supports PSCI v0.1. I'll add following PSCI nodes:
I tested the boot of secondary cpu.
psci {
compatible = arm,psci;
method = smc;
cpu_off = 0x8402;
cpu_on = 0xC403;
};
I take it from the presence of GICH/GICV in the gic node that CPUs enter
the kernel at EL2?
+ reg = 0x0 0x100;
+ clock-frequency = 105000;
What uses this?
It is un-used. I'll drop it.
+ };
[...]
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ fixed-rate-clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ xusbxti: clock@0 {
+ compatible = fixed-clock;
+ clock-output-names = xusbxti;
+ #clock-cells = 0;
+ };
+ };
Get rid of the fixed-rate-clocks container node. It's pointless and
messy. Given you only have one there's no need for the bogus
unit-address either.
OK, I'll remove unneeded code and will add following dt node for fin_pll.
fin_pll: xxti {
compatible = fixed-clock;
clock-output-names = fin_pll;
#clock-cells = 0;
};
+
+ cmu_top: clock-controller@0x1003{
s/@0x/@/ -- a unit-address should not have the leading '0x'. Please
apply that to the rest of the file.
I'll remove '0x'.
+ compatible =
Re: [PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On 28 November 2014 at 18:44, Eduardo Valentin edubez...@gmail.com wrote: Well, I wouldn't say unfortunately, but fortunately! :-) +1 :) However, I would prefer, at least to what comes to deferring, to update the drivers altogether with the inclusion of the check in cpu cooling. This way the change in behavior is atomic, in terms of commit changes. Viresh, if you don't mind, I will merge your patch 04/26 into this one. Sure, go ahead. -- 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 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Dear Marc,
On 11/27/2014 07:26 PM, Marc Zyngier wrote:
On 27/11/14 07:35, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
Cc: Kukjin Kim kgene@samsung.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Geunsik Lim geunsik@samsung.com
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
+
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
2 files changed, 1221 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
new file mode 100644
index 000..3d8b576
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
This is wrong. Timer interrupts for both A53 and A57 are level triggered.
I'll fix it level triggering instead of edge triggering.
If possible, could you give the document url to check the correct type of level
trigger?
whether irq is high level trigger or low level trigger.
+ clock-frequency = 2400;
Please go and fix your firmware. Really...
+ use-clocksource-only;
+ use-physical-timer;
+ };
Well, that's a total NAK. Neither of these properties are part of the
binding, and we've already established that none of that would never be
valid on arm64.
I suggest you finally do what we've been asking for years, which is to
fix your boot ROM by adding the 5 lines of assembly code that are needed
instead of repeatedly post the same bogus DT files.
I'll remove last three properties.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Fri, Nov 28, 2014 at 01:18:25PM +, Chanwoo Choi wrote:
Dear Mark,
On 11/27/2014 08:18 PM, Mark Rutland wrote:
On Thu, Nov 27, 2014 at 07:35:13AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
Cc: Kukjin Kim kgene@samsung.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Geunsik Lim geunsik@samsung.com
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
+
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
2 files changed, 1221 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
+ cpus {
+ #address-cells = 2;
+ #size-cells = 0;
+
+ cpu0: cpu@100 {
+ device_type = cpu;
+ compatible = arm,cortex-a53, arm,armv8;
+ enable-method = psci;
While the CPU nodes have enable-methods, I didn't spot a PSCI node
anywhere, so this dts cannot possibly have been used to bring up an SMP
system.
How has this dts been tested?
What PSCI revision have you implemented? Have have you tested it?
My mistake,
Exynos5433 supports PSCI v0.1. I'll add following PSCI nodes:
I tested the boot of secondary cpu.
psci {
compatible = arm,psci;
method = smc;
cpu_off = 0x8402;
cpu_on = 0xC403;
};
Ok. I take it _any_ CPU may be hotplugged (including CPU0), given that
you don't have MIGRATE_INFO_TYPE from PSCI 0.2 to tell you that this is
not possible? If not, attempting to hotplug CPU0 will result in a BUG()
and the kernel will explode.
Has that been tested?
Do all CPUs enter the kernel at EL2?
+ soc: soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ fixed-rate-clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ xusbxti: clock@0 {
+ compatible = fixed-clock;
+ clock-output-names = xusbxti;
+ #clock-cells = 0;
+ };
+ };
Get rid of the fixed-rate-clocks container node. It's pointless and
messy. Given you only have one there's no need for the bogus
unit-address either.
OK, I'll remove unneeded code and will add following dt node for fin_pll.
fin_pll: xxti {
compatible = fixed-clock;
clock-output-names = fin_pll;
#clock-cells = 0;
};
That looks fine to me.
[...]
+ mct@101c {
+ compatible = samsung,exynos4210-mct;
+ reg = 0x101c 0x800;
+ interrupts = 0 102 0, 0 103 0, 0 104 0, 0
105 0,
+ 0 106 0, 0 107 0, 0 108 0, 0 109,
+ 0 110 0, 0 111 0, 0 112 0, 0 113 0;
+ clocks = cmu_top CLK_FIN_PLL, cmu_peris
CLK_PCLK_MCT;
+ clock-names = fin_pll, mct;
+ };
Hase this block had no changes whatsoever since its use in Exynos4210?
Do we not need a samsung,exynos5433-mct comaptible string too?
The type of Exynos5433's MCT(Multi-Core Timer) IP is the same with the type
of Exynos4210 MCT.
Just Exynos5433 have eight local timer for Octa cores.
So samsung,exynos4210-mct should appear in the list. I'm just
wondering if it's worth having:
compatible = samsung,exynos5433-mct, samsung,exynos4210-mct;
Just in case we need to special-case the 5433 MCT for some reason later.
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
134: 0 0 0 0 0 0
0 0 GIC 134 mct_comp_irq
138: 3189 0 0 0 0 0
0 0 GIC 138 mct_tick0
139: 0 2670 0 0 0 0
0 0 GIC 139 mct_tick1
140: 0 0 2763 0 0 0
0 0 GIC 140 mct_tick2
141: 0 0 0 2732 0 0
0 0 GIC 141 mct_tick3
142: 0 0
Re: [PATCH v2 3/5] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated
On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The audio subsystem on Exynos 5420 has separate clocks and GPIO. To operate properly on GPIOs the main block clock 'mau_epll' must be enabled. This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0) after introducing runtime PM to pl330 DMA driver. After that commit the 'mau_epll' was gated, because the amba clock was disabled and there were no more users of mau_epll. The system hang just before probing i2s0 because samsung_pinmux_setup() tried to access memory from audss block which was gated. Add a clock property to the pinctrl driver and enable the clock during GPIO setup. During normal GPIO operations (set, get, set_direction) the clock is not enabled. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Waiting for Tomasz to review this. Can this patch be applied in separation from the others? Yours, Linus Walleij -- 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 3/5] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated
On pią, 2014-11-28 at 15:04 +0100, Linus Walleij wrote: On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The audio subsystem on Exynos 5420 has separate clocks and GPIO. To operate properly on GPIOs the main block clock 'mau_epll' must be enabled. This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0) after introducing runtime PM to pl330 DMA driver. After that commit the 'mau_epll' was gated, because the amba clock was disabled and there were no more users of mau_epll. The system hang just before probing i2s0 because samsung_pinmux_setup() tried to access memory from audss block which was gated. Add a clock property to the pinctrl driver and enable the clock during GPIO setup. During normal GPIO operations (set, get, set_direction) the clock is not enabled. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Waiting for Tomasz to review this. Can this patch be applied in separation from the others? Yes, it can be picked independently. The commit message is somehow misleading because issue is actually fixed by enabling this in DTS. So the next patch (4/5: ARM: dts: exynos5420: Add clock for audss pinctrl) actually fixes the issue on Arndale Octa board from pinctrl perspective. Unfortunately I spot that mistake (in commit msg) later... Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
On pią, 2014-11-28 at 11:38 +, Mark Brown wrote: On Fri, Nov 28, 2014 at 11:30:55AM +0100, Krzysztof Kozlowski wrote: On czw, 2014-11-27 at 18:43 +, Mark Brown wrote: Why do we need some special magic operation for GPIO based enables that's separate to any other enable operation? This seems really confusing, if the constraint setting doesn't work somehow for GPIO based enables we should fix that. Though since this operation takes no parameters it's hard to see how it's supposed to apply constraints unless it reparses them which doesn't seem like a good idea... The regulator driver no longer parses GPIO control from DTS. So somehow it should be notified that regulator core parsed this and GPIO should be enabled. That is the purpose of ops-set_ena_gpio() call. This sort of thing is a sign that we're not saving much by moving the parsing to the core and perhaps there's more flexiblity here... The driver receive callbacks (or exposes other kind of interface) for other core-generalized code. Recent example is parsing regulator mode (added by Javier) and .of_map_mode() callback. I thought how to do this without this additional set_ena_gpio() call. One way would be to extend the regulator modes (FAST/IDLE/STANDBY/ and GPIO) but this would look somehow unnatural. It's also not something that should be in the constraints handling, it's not something that constrains the regulator. Got it. +static int regulator_ena_gpio_setup(struct regulator_dev *rdev, + const struct regulator_config *config, + const struct regulator_init_data *init_data) Why is setting up the GPIO different to requesting it, especially given that we have an existing function called _request() which still exists? Maybe the name was not a best choice. The setup calls request. My patchset here tried to retain the compatibility with config.ena_gpio way so the core would accept GPIOs passed in one of two ways: 1. old: config.ena_gpio, 2. new: parsed by core from DTS. The request function previously worked only on config.ena_gpio and I changed it here to accept any GPIO. The setup uses one of GPIO methods (old or new) and calls request with appropriate GPIO. We need to support both methods since not all the world is DT. What I can't tell is how this code achieves these objectives - it seems to be an awfully big patch if that's all it's supposed to be doing, I'd expect just a conditional where we try the two methods in turn. It may be that there's a good reason for all this but that needs to be made clear. OK, I'll try to better describe the reason behind and to split the patches (if possible). Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property
On Fri, Nov 28, 2014 at 12:54:27PM +0100, Krzysztof Kozlowski wrote: On pią, 2014-11-28 at 11:21 +, Mark Brown wrote: On Fri, Nov 28, 2014 at 10:09:44AM +0100, Krzysztof Kozlowski wrote: I understand your concerns here however I didn't want to overengineer this. Is the same GPIO (on more complex PMICs) used in different contexts? Like enable control and something more in the same time? Yes, and it's often reprogrammable at runtime. I have doubts if generalized code could support such configuration... That's pretty much my point. signature.asc Description: Digital signature
[PATCH RFT 1/2] drivers: bus: check cci device tree node status
The arm-cci driver completes the probe sequence even if the cci node is marked as disabled. Add a check in the driver to honour the cci status in the device tree. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- drivers/bus/arm-cci.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c index 860da40..0ce5e2d 100644 --- a/drivers/bus/arm-cci.c +++ b/drivers/bus/arm-cci.c @@ -1312,6 +1312,9 @@ static int cci_probe(void) if (!np) return -ENODEV; + if (!of_device_is_available(np)) + return -ENODEV; + cci_config = of_match_node(arm_cci_matches, np)-data; if (!cci_config) return -ENODEV; -- 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 RFT 2/2] arm: dts: disable CCI on exynos420 based arndale-octa
The arndale-octa board was giving imprecise external aborts during
boot-up with MCPM enabled. CCI enablement of the boot cluster was found
to be the cause of these aborts (possibly because the secure f/w was not
allowing it). Hence, disable CCI for the arndale-octa board.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts |4
arch/arm/boot/dts/exynos5420.dtsi |2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index aa7a7d7..db2c1c4 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -372,3 +372,7 @@
usbdrd_dwc3_1 {
dr_mode = host;
};
+
+cci {
+ status = disabled;
+};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..0a82ae7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -120,7 +120,7 @@
};
};
- cci@10d2 {
+ cci: cci@10d2 {
compatible = arm,cci-400;
#address-cells = 1;
#size-cells = 1;
--
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 v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
On Fri, Nov 28, 2014 at 03:14:04PM +0100, Krzysztof Kozlowski wrote: On pią, 2014-11-28 at 11:38 +, Mark Brown wrote: This sort of thing is a sign that we're not saving much by moving the parsing to the core and perhaps there's more flexiblity here... The driver receive callbacks (or exposes other kind of interface) for other core-generalized code. Recent example is parsing regulator mode (added by Javier) and .of_map_mode() callback. Right, but that's actually doing some device specific translation and successfully factoring out the bulk of the code - the fact that it's taking parameters and returning data is a good sign. This is a callback placed randomly away from any other related code (adding to the confusion - it's not integrated into the rest of the flow around this at all) without a clear purpose. I thought how to do this without this additional set_ena_gpio() call. One way would be to extend the regulator modes (FAST/IDLE/STANDBY/ and GPIO) but this would look somehow unnatural. Yes, that's absolutely hideous. signature.asc Description: Digital signature
Re: [PATCH RFT 2/2] arm: dts: disable CCI on exynos420 based arndale-octa
On pią, 2014-11-28 at 20:20 +0530, Abhilash Kesavan wrote: The arndale-octa board was giving imprecise external aborts during boot-up with MCPM enabled. CCI enablement of the boot cluster was found to be the cause of these aborts (possibly because the secure f/w was not allowing it). Hence, disable CCI for the arndale-octa board. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- arch/arm/boot/dts/exynos5420-arndale-octa.dts |4 arch/arm/boot/dts/exynos5420.dtsi |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) I tested these 2 patches on Arndale Octa but there are no improvements. I still got imprecise aborts (some not fatal and sometimes killing init with full backtrace). Tested on next-20141128. System booted from microSD (bootloader from Linaro Ubuntu Saucy server image): == U-Boot 2012.07 (Feb 15 2014 - 17:29:55) for ARNDALE OCTA CPU: Exynos5420 Rev2.0 [Samsung SOC on SMP Platform Base on ARM CortexA15] APLL = 800MHz, KPLL = 600MHz MPLL = 532MHz, BPLL = 800MHz Board: ARNDALE OCTA DRAM: 2 GiB WARNING: Caches not enabled TrustZone Enabled BSP BL1 version: Checking Boot Mode ... SDMMC MMC: S5P_MSHC2: 0, S5P_MSHC0: 1 MMC Device 0: 29.3 GiB MMC Device 1: 7.3 GiB MMC Device 2: MMC Device 2 not found there are pending interrupts 0x0001 In:serial Out: serial Err: serial Net: No ethernet found. (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... The request port(2) is not configured The request port(2) is not configured 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 ARNDALE # uTTY Unknown command 'uTTY' - try 'help' ARNDALE # run nn reading uImage 3674704 bytes read reading uInitrd 2330480 bytes read reading board.dtb 33680 bytes read ## Booting kernel from Legacy Image at 20007000 ... Image Name: Linux-exynos5420-arndale-octa Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3674640 Bytes = 3.5 MiB Load Address: 41008000 Entry Point: 41008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 2200 ... Image Name: initramfs Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:2330416 Bytes = 2.2 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 21f0 Booting using the fdt blob at 0x21f0 Loading Kernel Image ... OK OK Using Device Tree in place at 21f0, end 21f0b38f Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.18.0-rc6-next-20141128-7-g33b7bf7da133 (k.kozlowski@AMDC1943) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #24 SMP PREEMPT Fri Nov 28 16:13:43 CET 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d ... [ 12.874514] VFS: Mounted root (ext4 filesystem) readonly on device 179:67. [ 12.887392] devtmpfs: mounted [ 12.889321] Freeing unused kernel memory: 324K (c0669000 - c06ba000) [ 12.951241] Unhandled fault: imprecise external abort (0x406) at 0x [ 12.966312] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 [ 12.966312] [ 12.973980] CPU: 0 PID: 1 Comm: bash Tainted: GW 3.18.0-rc6-next-20141128-7-g33b7bf7da133 #24 [ 12.983938] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 12.990014] [c0014d44] (unwind_backtrace) from [c0011c88] (show_stack+0x10/0x14) [ 12.997723] [c0011c88] (show_stack) from [c048e82c] (dump_stack+0x70/0xbc) [ 13.004911] [c048e82c] (dump_stack) from [c048a8c0] (panic+0x94/0x20c) [ 13.011753] [c048a8c0] (panic) from [c0026500] (do_exit+0x944/0x988) [ 13.018424] [c0026500] (do_exit) from [c00265f4] (do_group_exit+0x3c/0xbc) [ 13.025621] [c00265f4] (do_group_exit) from [c0030d60] (get_signal+0x218/0x8c4) [ 13.033247] [c0030d60] (get_signal) from [c048a39c] (do_signal+0x84/0x350) [ 13.040438] [c048a39c] (do_signal) from [c00115ec] (do_work_pending+0xbc/0xcc) [ 13.047979] [c00115ec] (do_work_pending) from [c000f1f8] (work_pending+0xc/0x20) [ 13.055693] CPU1: stopping [ 13.058385] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.18.0-rc6-next-20141128-7-g33b7bf7da133 #24 [ 13.068790] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 13.074858] [c0014d44] (unwind_backtrace) from [c0011c88] (show_stack+0x10/0x14) [ 13.082573] [c0011c88] (show_stack) from [c048e82c] (dump_stack+0x70/0xbc) [ 13.089762] [c048e82c] (dump_stack) from [c0013e14] (handle_IPI+0x158/0x18c) [ 13.097128] [c0013e14] (handle_IPI) from [c00086f4] (gic_handle_irq+0x60/0x68) [ 13.104669] [c00086f4] (gic_handle_irq) from [c00127c4] (__irq_svc+0x44/0x7c) [ 13.112112] Exception stack(0xee4c3fa0 to 0xee4c3fe8) [ 13.117135] 3fa0
Re: [PATCH RFT 2/2] arm: dts: disable CCI on exynos420 based arndale-octa
Hello Krzysztof, On Fri, Nov 28, 2014 at 8:49 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On pią, 2014-11-28 at 20:20 +0530, Abhilash Kesavan wrote: The arndale-octa board was giving imprecise external aborts during boot-up with MCPM enabled. CCI enablement of the boot cluster was found to be the cause of these aborts (possibly because the secure f/w was not allowing it). Hence, disable CCI for the arndale-octa board. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com --- arch/arm/boot/dts/exynos5420-arndale-octa.dts |4 arch/arm/boot/dts/exynos5420.dtsi |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) I tested these 2 patches on Arndale Octa but there are no improvements. I still got imprecise aborts (some not fatal and sometimes killing init with full backtrace). Thanks for testing. Are you testing this with exynos_defconfig with no other changes ? Can you please confirm from the bootlog that MCPM and CCI are not being initialized. Can you remove these 2 patches and on linux-next check if you are getting aborts even with 5420_MCPM disabled. Regards, Abhilash Tested on next-20141128. System booted from microSD (bootloader from Linaro Ubuntu Saucy server image): == U-Boot 2012.07 (Feb 15 2014 - 17:29:55) for ARNDALE OCTA CPU: Exynos5420 Rev2.0 [Samsung SOC on SMP Platform Base on ARM CortexA15] APLL = 800MHz, KPLL = 600MHz MPLL = 532MHz, BPLL = 800MHz Board: ARNDALE OCTA DRAM: 2 GiB WARNING: Caches not enabled TrustZone Enabled BSP BL1 version: Checking Boot Mode ... SDMMC MMC: S5P_MSHC2: 0, S5P_MSHC0: 1 MMC Device 0: 29.3 GiB MMC Device 1: 7.3 GiB MMC Device 2: MMC Device 2 not found there are pending interrupts 0x0001 In:serial Out: serial Err: serial Net: No ethernet found. (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... The request port(2) is not configured The request port(2) is not configured 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Hit any key to stop autoboot: 0 ARNDALE # uTTY Unknown command 'uTTY' - try 'help' ARNDALE # run nn reading uImage 3674704 bytes read reading uInitrd 2330480 bytes read reading board.dtb 33680 bytes read ## Booting kernel from Legacy Image at 20007000 ... Image Name: Linux-exynos5420-arndale-octa Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3674640 Bytes = 3.5 MiB Load Address: 41008000 Entry Point: 41008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 2200 ... Image Name: initramfs Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:2330416 Bytes = 2.2 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 21f0 Booting using the fdt blob at 0x21f0 Loading Kernel Image ... OK OK Using Device Tree in place at 21f0, end 21f0b38f Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.18.0-rc6-next-20141128-7-g33b7bf7da133 (k.kozlowski@AMDC1943) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #24 SMP PREEMPT Fri Nov 28 16:13:43 CET 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d ... [ 12.874514] VFS: Mounted root (ext4 filesystem) readonly on device 179:67. [ 12.887392] devtmpfs: mounted [ 12.889321] Freeing unused kernel memory: 324K (c0669000 - c06ba000) [ 12.951241] Unhandled fault: imprecise external abort (0x406) at 0x [ 12.966312] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 [ 12.966312] [ 12.973980] CPU: 0 PID: 1 Comm: bash Tainted: GW 3.18.0-rc6-next-20141128-7-g33b7bf7da133 #24 [ 12.983938] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 12.990014] [c0014d44] (unwind_backtrace) from [c0011c88] (show_stack+0x10/0x14) [ 12.997723] [c0011c88] (show_stack) from [c048e82c] (dump_stack+0x70/0xbc) [ 13.004911] [c048e82c] (dump_stack) from [c048a8c0] (panic+0x94/0x20c) [ 13.011753] [c048a8c0] (panic) from [c0026500] (do_exit+0x944/0x988) [ 13.018424] [c0026500] (do_exit) from [c00265f4] (do_group_exit+0x3c/0xbc) [ 13.025621] [c00265f4] (do_group_exit) from [c0030d60] (get_signal+0x218/0x8c4) [ 13.033247] [c0030d60] (get_signal) from [c048a39c] (do_signal+0x84/0x350) [ 13.040438] [c048a39c] (do_signal) from [c00115ec] (do_work_pending+0xbc/0xcc) [ 13.047979] [c00115ec] (do_work_pending) from [c000f1f8] (work_pending+0xc/0x20) [ 13.055693] CPU1: stopping [ 13.058385] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.18.0-rc6-next-20141128-7-g33b7bf7da133 #24 [ 13.068790] Hardware name: SAMSUNG EXYNOS
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam gautam.vi...@samsung.com wrote: USB and Power regulator on Exynos7 require gpios available in BUS1 pin controller block. So adding the BUS1 pinctrl support. Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org If the change looks good, will it be possible to pick it fo 3.19-rc1 ? That will really help enabling USB IP on exynos7. As you know the Exynos driver has a maintainer, Tomasz Figa, I will not merge patches without his ACK. Apart from that, there are *again* a lot of Exynos patches flying around and I start to loose track of them. If they do not apply together and start to conflict I will just ask Tomasz to stack them and provide a pull request again. Yours, Linus Walleij -- 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
[PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.
Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.
Cc: devicet...@vger.kernel.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Eduardo Valentin edubez...@gmail.com
---
drivers/thermal/cpu_cooling.c | 3 +++
drivers/thermal/db8500_cpufreq_cooling.c | 5 -
drivers/thermal/imx_thermal.c | 5 -
drivers/thermal/samsung/exynos_thermal_common.c| 7 ---
drivers/thermal/samsung/exynos_tmu.c | 4 +++-
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
6 files changed, 10 insertions(+), 20 deletions(-)
---
Changes from V2:
- Removed logging message when returning EPROBE_DEFER. Majority
of the existing code simply do not log. Following the pattern
- Merges Viresh's patch in Exynos driver. Reasoning, the change
in the API behavior goes together with the needed changes in the API
users.
Changes from V1:
- As per Viresh K. suggestion's, the check for cpufreq layer readiness is now
only a simple fetch for cpufreq table.
This patch depends on:
(0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
https://patchwork.kernel.org/patch/5390731/
https://patchwork.kernel.org/patch/5390741/
https://patchwork.kernel.org/patch/5390751/
https://patchwork.kernel.org/patch/5390761/
(1) - fix of thermal core:
https://patchwork.kernel.org/patch/5326991/
BR,
Eduardo Valentin
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..88d2775 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,9 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_frequency_get_table(0))
+ return ERR_PTR(-EPROBE_DEFER);
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
*/
#include linux/cpu_cooling.h
-#include linux/cpufreq.h
#include linux/err.h
#include linux/module.h
#include linux/of.h
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
- /* make sure cpufreq driver has been initialized */
- if (!cpufreq_frequency_get_table(0))
- return -EPROBE_DEFER;
-
cpumask_set_cpu(0, mask_val);
cdev = cpufreq_cooling_register(mask_val);
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
#include linux/clk.h
#include linux/cpu_cooling.h
-#include linux/cpufreq.h
#include linux/delay.h
#include linux/device.h
#include linux/init.h
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
- if (!cpufreq_get_current_driver()) {
- dev_dbg(pdev-dev, no cpufreq driver!);
- return -EPROBE_DEFER;
- }
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..d4eaa1b 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -371,9 +371,10 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
th_zone-cool_dev[th_zone-cool_dev_size] =
cpufreq_cooling_register(mask_val);
if
Re: [PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On Fri, Nov 28, 2014 at 10:53:30AM -0400, Eduardo Valentin wrote:
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..d4eaa1b 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -371,9 +371,10 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
th_zone-cool_dev[th_zone-cool_dev_size] =
cpufreq_cooling_register(mask_val);
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
- dev_err(sensor_conf-dev,
- Failed to register cpufreq cooling device\n);
- ret = -EINVAL;
+ ret =
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
+ if (ret != -EPROBE_DEFER)
+ dev_err(sensor_conf-dev,
+ Failed to register cpufreq cooling
device\n);
Something which bugs me quite a lot is when there is an error code (which
tells you why something didn't work) and you have an error message, and
the error message doesn't bother printing the error code.
You might as well just print Failed\n and leave it at that, or md5sum
the error message and print the sum instead. :)
Knowing why something failed allows you to read the source, and find
possible reasons for the failure (which could come down to one reason)
and allows faster resolution of the problem.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
Russel,
On Fri, Nov 28, 2014 at 05:10:24PM +, Russell King - ARM Linux wrote:
On Fri, Nov 28, 2014 at 10:53:30AM -0400, Eduardo Valentin wrote:
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..d4eaa1b 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -371,9 +371,10 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
th_zone-cool_dev[th_zone-cool_dev_size] =
cpufreq_cooling_register(mask_val);
if (IS_ERR(th_zone-cool_dev[th_zone-cool_dev_size])) {
- dev_err(sensor_conf-dev,
- Failed to register cpufreq cooling device\n);
- ret = -EINVAL;
+ ret =
PTR_ERR(th_zone-cool_dev[th_zone-cool_dev_size]);
+ if (ret != -EPROBE_DEFER)
+ dev_err(sensor_conf-dev,
+ Failed to register cpufreq cooling
device\n);
Something which bugs me quite a lot is when there is an error code (which
tells you why something didn't work) and you have an error message, and
the error message doesn't bother printing the error code.
You might as well just print Failed\n and leave it at that, or md5sum
the error message and print the sum instead. :)
I like the md5sum better! :-)
Knowing why something failed allows you to read the source, and find
possible reasons for the failure (which could come down to one reason)
and allows faster resolution of the problem.
Sure. I will resend with the error codes in the error messages. Makes
completely sense.
Thanks for taking the time and reviewing.
Eduardo Valentin
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
signature.asc
Description: Digital signature
Re: [PATCH 03/12] PM / Domains: Add notifier support for power domain transitions
On 07/11/14 19:45, Kevin Hilman wrote:
Sylwester Nawrocki s.nawro...@samsung.com writes:
On 04/11/14 07:44, amit daniel kachhap wrote:
On Mon, Nov 3, 2014 at 11:53 PM, Kevin Hilman khil...@kernel.org wrote:
Rafael J. Wysocki r...@rjwysocki.net writes:
On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote:
[...]
Indeed, the somehow complicated power domain power on/off sequences
are SoC specific. They involve not only groups of clocks (usually
gate, mux clock registers of all devices in a power domain) but also
SoC-specific PMU (Power Management Unit) registers.
I assume it would be inappropriate to push such details to device
drivers. Moreover, a device driver could not be even loaded.
Since the clocks' state is already maintained by clk driver we came
up with an idea of having generic calls from power domain driver back
to the clock controller driver.
For the clock tree, it still seems to me that this is better handled in
the SoC clock driver. For example, when a power domain is about to be
gated, all the devices in that domain are runtime suspended, and
presumably all of their gate clocks are disabled. Now, doesn't the
clock driver know the clock tree parent-child hierarchy and shouldn't it
be capable of saving the state of parent clocks (like mux clocks) etc?
Stated diffrently, it still seems to me like we're pushing functionality
in PM core notifiers that should be the responsibility of subsystem
drivers.
My apologies for not replying earlier, I got distracted by other
activities.
I'd prefer not adding anything new to the PM core, however there are
dependencies between the power domain and clock controller driver
which are hard to model in the current APIs. I assume resorting to
inter-exynos-driver API is not a good idea either.
Saving/restoring the clock hierarchy in the clock controller driver
during the power domain state transitions has a caveat that the clock
turn off/on sequences are IP/SoC subsystem specific. So simply
restoring saved registers from memory is not going to work.
The other detail I might have forgotten to mention is that the whole
clock controller may be in same power domain as the consumer devices.
That means the clock controller's registers must not be touched when
a related power domain is turned off. Naturally when a power domain
gets switched off all the clock controller's registers reset to their
default values. If we decided to use pm_runtime_{get_sync, put} in
the clock controller driver I'm not sure how it would need to interact
with the clk API.
In current mainline there is an issue with exynos4x12 that the system
may hang if clk_summary is attempted to read as the clock controller
driver doesn't take the ISP power domain into account.
[...]
Personally, I'm uncomfortable with notifiers like this because it
suggests that underlying frameworks are not doing the right thing, or
are not being used. (I also don't like the implementation here where a
single global notifier list is maintained by the core, but the notifiers
are actually triggered by SoC specific code.)
Yes right the global notifier block can be moved to per genpd structure.
Also SoC trigger can be moved to core files.
IIUC, the usage in this series seems to be that certain clock related
registers need to be saved/restored across a power domain transition.
Wouldn't an alternative solution be to add a feature to the clock driver
such that the state of each clock is saved when the clock is disabled,
and restored when the clock is enabled? That would allow any clock
context to survive any power domain transtion also, correct?
I also thought about same. But the trigger point for this would be
driver calling clk disable/enable and not the power domain. so this
will lead to lot of save/restore for each power domain child.
Even though we would have saved/restored at that points still the power
domain driver would need to enforce some specific clock/PMU registers
state before/after a power domain state transition. And this is what I
found difficult with the existing APIs.
This is what I'm not understanding.
Why can't the power domain driver's power_on/power_off callback just
call the PMU APIs and/or the clk_enable/_disable calls it needs?
I was concerned that it would not have been reliable by using the clk
API due to the clk enable refcounting. But that might not be a valid
argument, since as you pointed out when a power domain is about to
be gated related the clocks should be already disabled.
The other concern was atomicity in enabling/disabling groups of clocks,
i.e. setting group of bits in a clock gate register at once, rather
than a bit for each clock one by one. But I'm not 100% sure about
such a hardware requirement myself, would need to do some more testing
and/or find a hardware engineer who could explain this.
Additionally specifying clocks in device tree would be a bit messy and
there would very
Re: [PATCH V3 1/3] PM / Domains: Initial PM clock support for genpd
On Friday, November 28, 2014 09:30:01 AM Ulf Hansson wrote:
It's quite common for PM domains to use PM clocks. Typically from SOC
specific code, the per device PM clock list is created and
pm_clk_suspend|resume() are invoked to handle clock gating/ungating.
A step towards consolidation is to integrate PM clock support into
genpd, which is what this patch does.
In this initial step, the calls to the pm_clk_suspend|resume() are
handled within genpd, but the per device PM clock list still needs to
be created from SOC specific code. It seems reasonable to have gendp to
handle that as well, but that left to future patches to address.
It's not every users of genpd that are keen on using PM clocks, thus we
need to provide this a configuration option for genpd. Therefore let's
add flag field in the genpd struct to keep this information and define
a new GENDP_PM_CLK bit for it.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v3:
Moved define out of struct definition.
Don't use bitops.h
Rename define to GENDP_PM_CLK.
Changes in v2:
Set -start() callback to pm_clk_resume() and fixed comment.
---
drivers/base/power/domain.c | 7 +++
include/linux/pm_domain.h | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..a2424a7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -12,6 +12,7 @@
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
+#include linux/pm_clock.h
#include linux/slab.h
#include linux/err.h
#include linux/sched.h
@@ -1928,6 +1929,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
genpd-domain.ops.complete = pm_genpd_complete;
genpd-dev_ops.save_state = pm_genpd_default_save_state;
genpd-dev_ops.restore_state = pm_genpd_default_restore_state;
+
+ if (genpd-flags GENPD_PM_CLK) {
+ genpd-dev_ops.stop = pm_clk_suspend;
+ genpd-dev_ops.start = pm_clk_resume;
+ }
+
mutex_lock(gpd_list_lock);
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..173cc67 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -17,6 +17,9 @@
#include linux/notifier.h
#include linux/cpuidle.h
+/* Defines used for the flags field in the struct generic_pm_domain */
+#define GENPD_PM_CLK (1U 0) /* PM domain uses PM clk */
I'd prefer GENPD_FLAG_PM_CLK to indicate in the name that this is, well, a flag.
Otherwise it looks OK to me.
If you want me to apply [2-3/3] too, ACKs from the ARM/shmobile maintainers
are needed.
+
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
GPD_STATE_WAIT_MASTER, /* PM domain's master is being waited for */
@@ -76,6 +79,7 @@ struct generic_pm_domain {
struct device *dev);
void (*detach_dev)(struct generic_pm_domain *domain,
struct device *dev);
+ unsigned int flags; /* Bit field of configs for genpd */
};
static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] PM / Domains: Add pm_genpd_lookup() API to lookup domain by firmware node
On Friday, November 28, 2014 11:38:35 AM Ulf Hansson wrote:
In a step to move away from using genpd's name based APIs, such as the
pm_genpd_add_subdomain_names(), provide an API to lookup an already
initialized generic PM domain by its firmware node.
This API would typically be a called from SOC specific code, to fetch a
handle to the domain. Especially convenient to configure subdomains and
when the hierarchy of the domains are described in DT.
Do note, before pm_genpd_init() is invoked to initialize a generic PM
domain, it's the callers responsibility to assign the new -fwnode
pointer in the struct generic_pm_domain, to enable pm_genpd_lookup() to
find the domain.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
I have no problems with that, but do you have a user for it?
---
Changes in v2:
Change from using struct device_node to struct fwnode_handle.
Updated commit header accordingly.
---
drivers/base/power/domain.c | 27 +++
include/linux/pm_domain.h | 4
2 files changed, 31 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..2d881d5 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -75,6 +75,33 @@ struct generic_pm_domain *dev_to_genpd(struct device *dev)
return pd_to_genpd(dev-pm_domain);
}
+/**
+ * pm_genpd_lookup - Fetch a generic PM domain object by firmware node.
+ * @node: Firmware node to a corresponding genpd.
+ *
+ * Returns a valid pointer to struct generic_pm_domain on success or
ERR_PTR()
+ * on failure.
+ */
+struct generic_pm_domain *pm_genpd_lookup(struct fwnode_handle *node)
+{
+ struct generic_pm_domain *genpd = ERR_PTR(-ENOENT), *gpd;
+
+ if (IS_ERR_OR_NULL(node))
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(gpd_list_lock);
+ list_for_each_entry(gpd, gpd_list, gpd_list_node) {
+ if (gpd-fwnode == node) {
+ genpd = gpd;
+ break;
+ }
+ }
+ mutex_unlock(gpd_list_lock);
+
+ return genpd;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_lookup);
+
static int genpd_stop_dev(struct generic_pm_domain *genpd, struct device
*dev)
{
return GENPD_DEV_TIMED_CALLBACK(genpd, int, stop, dev,
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..aa01050 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -43,6 +43,8 @@ struct gpd_cpuidle_data {
struct cpuidle_state *idle_state;
};
+struct fwnode_handle;
+
struct generic_pm_domain {
struct dev_pm_domain domain;/* PM domain operations */
struct list_head gpd_list_node; /* Node in the global PM domains list */
@@ -53,6 +55,7 @@ struct generic_pm_domain {
struct dev_power_governor *gov;
struct work_struct power_off_work;
const char *name;
+ struct fwnode_handle *fwnode; /* Firware node for the PM domain */
unsigned int in_progress; /* Number of devices being suspended
now */
atomic_t sd_count; /* Number of subdomains with power on */
enum gpd_status status; /* Current state of the domain */
@@ -126,6 +129,7 @@ static inline struct generic_pm_domain_data
*dev_gpd_data(struct device *dev)
}
extern struct generic_pm_domain *dev_to_genpd(struct device *dev);
+extern struct generic_pm_domain *pm_genpd_lookup(struct fwnode_handle *node);
extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,
struct device *dev,
struct gpd_timing_data *td);
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: [GIT PULL 4/4] Samsung exynos7 updates for v3.19
Arnd Bergmann wrote: On Thursday 27 November 2014, Kukjin Kim wrote: Samsung arch/arm64 DT updates for v3.19 - to support ARMv8 based exynos7 SoC : add initial device tree and add pinctrl, PMU, mmc, i2c, rtc, watchdog, and adc nodes for exynos7 SoC and exynos7 based espresso board. NOTE that this is including following dependencies : cleanup/dts-subdirs in arm-soc for arm64 vendor support : tags/samsung-driver for samsung serial : for-v3.19/exynos-clk in samsung-clk tree for exynos7 clk One more NOTE, for support exynos7 we need Liviu's arm64: Create link to include/dt-bindings to enable C preprocessor use in arm-soc tree and arm64 defconfig update should be handled directly. I'm confused by the dependencies. I don't see a for-v3.19/exynos-clk in arm-soc, you haven't put the clk maintainer on Cc and I see no indication that he has this in his tree already, so I'm not pulling this until further clarification. Hi, Sorry for insufficient description. Since the exynos7 stuff requires regarding clk stuff for kernel build, I talked to Mike, Sylwester and Mike suggested pulling the branch into Samsung tree. http://www.spinics.net/lists/linux-samsung-soc/msg39368.html If any problems, please let me know. Thanks, Kukjin -- 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: [GIT PULL 2/4] Samsung serial updates for v3.19
Arnd Bergmann wrote: On Thursday 27 November 2014, Kukjin Kim wrote: Hi Arnd, Olof, Kevin Please pull this branch for exynos7 SoC into arm-soc. Note Greg agreed to upstream via arm-soc tree. I don't really see any dependency on anything else here, so I wonder why you are sending it to me, but I assume there is some reason and it's trivial enough. Yes, actually there is no dependency for build the kernel but I wanted to provide a topic branch for test and implement further features on exynos7. Pulled into next/drivers. Thanks a lot. - Kukjin -- 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: [GIT PULL 3/5] Samsung defconfig update for v3.19
Arnd Bergmann wrote: On Friday 21 November 2014, Kukjin Kim wrote: The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig-v3.19 for you to fetch changes up to 26048def56ac2f901d4245d2935c797984e96d68: ARM: exynos_defconfig: Use 16 minors per MMC block device (2014-11-21 22:04:05 +0900) Samsung defconfig update for v3.19 - Use 16 minors per MMC block device for exynos_defconfig : 16 minors per MMC block device are required for Rinato (Gear 2) The defconfig branch didn't have v3.18-rc3 yet, so I cherry-picked the one patch from this branch to avoid a back-merge from upstream. OK, I'm fine. Please make sure to base patches on older -rc releases if you can, it makes our lives easier. OK, I will :) Thanks, Kukjin -- 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
