Re: [PATCH 21/21] thermal: exynos: Make Exynos3250 TMU compatible with Exynos4412
Hi Chanwoo,
On 10/10/2014 01:38 AM, Lukasz Majewski wrote:
Since both SoCs have the same TMU IP block embedded on them, it is
not necessary to maintain separate compatible entry.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index f1e8c9b..7818e2f 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -744,9 +744,6 @@ static irqreturn_t exynos_tmu_irq(int irq, void
*id)
static const struct of_device_id exynos_tmu_match[] = {
{
- .compatible = samsung,exynos3250-tmu,
- },
- {
If you want to remove compatible string for Exynos3250,
you have to modify it on exynos3250.dtsi.
Thanks for pointing this out. I've overlooked this dtsi file.
Thanks,
Chanwoo Choi
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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: Powering down unused PM domains (was: Re: [PATCH 0/4] PM / Domains: Fix race conditions during boot)
Hi! While operation A2 is PM domain-centric (it walks the list of genpd domains), A3 and B3 are device-centric (A3 operates on one specific device, B3 walks the list of devices). Hence B3 never touches PM domains that don't contain any devices[*]. So these PM domains are kept powered-up if CONFIG_PM_RUNTIME=n, even on system suspend. Shouldn't PM domains without devices be powered down at some point? When? In B2, or in B3? I agree with Rafael and Sylwester, that it would be an advantage if PM domains can be initialized in powered off state. Simply because, those may then be left in powered off state all the time, if they are unused. Also... powering up all the domains at the same time is quite harsh at the battery. Even if they are powered down soon, it still causes spike in current which may trip the battery (especially when battery is old and nearly discharged). P.S. Will any of you be at ELC-E next week, for further PM domain discussions? That would have been great, but I won't be there. Unless I schedule a last minute trip. :-) I should be there. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 1/1] ARM: exynos_defconfig: re-enable USB gadget and max77802 options
Hello Kevin, On Fri, Oct 10, 2014 at 1:34 AM, Kevin Hilman khil...@kernel.org wrote: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Commit 43eeaa42e03a (ARM: exynos_defconfig: savedefconfig) removed a set of Kconfig symbols. For most of them there were no functional change since are selected by other Kconfig options or were deprecated but some options are not explicitly selected so they should not had been removed. The options that have to be enabled are USB gadget and the MAX77802 PMIC support which were enabled in commits: 508423bebcda (ARM: exynos_defconfig: enable USB gadget support) 6e80e3d87549 (ARM: exynos_defconfig: Enable MAX77802) Enable those options to leave the config in the state before the change. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org Thanks for testing. This is needed to get RTC wakeup from suspend working on exynos5800-peach-pi. Note that the s3c-rtc works fine, but the max77802-rtc doesn't seem to work be functional for me: [2.408178] max77802-rtc max77802-rtc: rtc core: registered max77802-rtc as rtc0 [3.595485] s3c-rtc 101e.rtc: rtc core: registered s3c as rtc1 root@(none):/# hwclock --rtc /dev/rtc0 hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed: Invalid argument root@(none):/# hwclock --rtc /dev/rtc1 Thu Oct 9 23:33:06 2014 -0.111978 seconds Strange, I don't get that error when testing on my Peach Pit with linux-next + $subject [2.311591] max77802-rtc max77802-rtc: rtc core: registered max77802-rtc as rtc0 [3.594438] s3c-rtc 101e.rtc: rtc core: registered s3c as rtc1 # hwclock --rtc /dev/rtc0 Fri 10 Oct 2014 12:19:23 PM UTC -0.909103 seconds # hwclock --rtc /dev/rtc1 Fri 10 Oct 2014 12:19:26 PM UTC -0.719862 seconds I'll take a look but if you have a test case that makes it fail consistently that would be really helpful. 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
[PATCH 0/4] drm/exynos: misc fixes
Hi Inki, These four independent patches fixes few problems I have encountered recently. 1st patch is a trivial fix. 2nd patch(kms poll init) fixes old issue, which became more visible after my patch 'drm/exynos: init vblank with real number of crtcs' - driver tried to handle HPD events even if it was not fully initialized, it caused WARNs and app locks. Vblank patch is slightly different version of the one proposed in [1]. The only difference is that it enables vblank after dpms on, it is neccessary because drm_crtc_vblank_on can call drm_vblank_enable which can call exynos_drm_crtc_enable_vblank and exynos_drm_crtc_enable_vblank will return error if exynos_crtc-dpms != DRM_MODE_DPMS_ON. DPMS patch was previously sent as a part of other series, but as the series have been dropped I have resend it in this patchset. The patchset is based on exynos-drm-next branch plus following patches: drm/exynos: remove explicit encoder/connector de-initialization drm/exynos: init vblank with real number of crtcs drm/exynos: remove ifdeferry from initialization code It has been tested on trats board. [1]: https://lkml.org/lkml/2014/10/2/154 Regards Andrzej Andrzej Hajda (4): drm/exynos: propagate plane initialization errors drm/exynos: init kms poll at the end of initialization drm/exynos: enable vblank after DPMS on drm/exynos: correct connector-dpms field before resuming drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 27 +-- 2 files changed, 21 insertions(+), 11 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
[PATCH 2/4] drm/exynos: init kms poll at the end of initialization
HPD events can be generated by components even if drm_dev is not fully initialized, to skip such events kms poll initialization should be performed at the end of load callback followed directly by forced connection detection. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 322e7bf..ce6c14c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -94,9 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) goto err_mode_config_cleanup; } - /* init kms poll for handling hpd */ - drm_kms_helper_poll_init(dev); - /* setup possible_clones. */ exynos_drm_encoder_setup(dev); @@ -116,9 +113,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) if (ret) goto err_cleanup_vblank; - /* force connectors detection */ - drm_helper_hpd_irq_event(dev); - /* * enable drm irq mode. * - with irq_enabled = true, we can use the vblank feature. @@ -136,6 +130,12 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) */ dev-vblank_disable_allowed = true; + /* init kms poll for handling hpd */ + drm_kms_helper_poll_init(dev); + + /* force connectors detection */ + drm_helper_hpd_irq_event(dev); + return 0; err_cleanup_vblank: -- 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 4/4] drm/exynos: correct connector-dpms field before resuming
During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ce6c14c..fe250e4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -194,8 +194,12 @@ static int exynos_drm_resume(struct drm_device *dev)
drm_modeset_lock_all(dev);
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- if (connector-funcs-dpms)
- connector-funcs-dpms(connector, connector-dpms);
+ if (connector-funcs-dpms) {
+ int dpms = connector-dpms;
+
+ connector-dpms = DRM_MODE_DPMS_OFF;
+ connector-funcs-dpms(connector, dpms);
+ }
}
drm_modeset_unlock_all(dev);
--
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 1/4] drm/exynos: propagate plane initialization errors
In case of error during plane initialization load callback incorrectly return success, this patch fixes it. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index cf19e60..322e7bf 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -87,8 +87,11 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) plane = exynos_plane_init(dev, possible_crtcs, DRM_PLANE_TYPE_OVERLAY); - if (IS_ERR(plane)) - goto err_mode_config_cleanup; + if (!IS_ERR(plane)) + continue; + + ret = PTR_ERR(plane); + goto err_mode_config_cleanup; } /* init kms poll for handling hpd */ -- 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 3/4] drm/exynos: enable vblank after DPMS on
Before DPMS off driver disables vblank. It should be balanced by vblank enable after DPMS on. The patch fixes issue with page_flip ioctl not being able to acquire vblank counter introduced by patch: drm: Always reject drm_vblank_get() after drm_vblank_off() Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 8e38e9f..45026e6 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -71,13 +71,16 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode) !atomic_read(exynos_crtc-pending_flip), HZ/20)) atomic_set(exynos_crtc-pending_flip, 0); - drm_vblank_off(crtc-dev, exynos_crtc-pipe); + drm_crtc_vblank_off(crtc); } if (manager-ops-dpms) manager-ops-dpms(manager, mode); exynos_crtc-dpms = mode; + + if (mode == DRM_MODE_DPMS_ON) + drm_crtc_vblank_on(crtc); } static void exynos_drm_crtc_prepare(struct drm_crtc *crtc) -- 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] drm/exynos: fix vblank handling during dpms off
On 10/02/2014 12:52 PM, Inki Dae wrote:
On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
Hi Andrzej,
On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagefilp has
not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
It fixes issue with page_flip ioctl not being able to acquire vblank
counter.
This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).
We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .
How about below patch?
Thanks you Joonyoung and Andrzej,
drm_vblank_on/off() are legacy api so it would be better to use
drm_vblank_crtc_on/off functions instead.
And drm_vblank_crtc_off() makes sure that the latest vblank frame count
is stored and restored by drm_vblank_crtc_on() again. So my opinion is,
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
[snip]
if (mode DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc-pending_flip_queue,
!atomic_read(exynos_crtc-pending_flip),
HZ/20))
atomic_set(exynos_crtc-pending_flip, 0);
drm_crtc_vblank_off(crtc); //- store the latest
vblank frame count.
} else {
drm_crtc_vblank_on(crtc); //- restore the vblank
frame count.
}
[snip]
}
Tested and worked well with above patch. How about it?
drm_crtc_vblank_on should be called after dpms on, otherwise it can fail
enabling vblank. I have provided
full explanation in my other email [1].
You can modify your patch or just use the one provided in [1].
[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/116152
Regards
Andrzej
--
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
[RFC PATCH] 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 aksh...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos-decon.txt | 68 ++
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086
drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 +
include/video/samsung_decon.h | 346 +++
7 files changed, 1537 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
create mode 100644 include/video/samsung_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
b/Documentation/devicetree/bindings/video/exynos-decon.txt
new file mode 100644
index 000..e865650
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
@@ -0,0 +1,68 @@
+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, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+
+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_disp SCLK_DSD,
+clock_bus0 ACLK_LH_DISP0,
+clock_disp ACLK_CP_DISP,
+clock_bus0 ACLK_LH_DISP1;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk, sclk_dsd, aclk_lh_disp0,
+ aclk_disp, aclk_lh_disp1;
+ 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 fd1c070..89275ea 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -31,6 +31,13 @@ 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
@@ -41,7 +48,7 @@ config DRM_EXYNOS_DPI
config DRM_EXYNOS_DSI
bool EXYNOS DRM MIPI-DSI driver support
-
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: Hi Ajay, On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: On 20/09/14 14:22, Ajay kumar wrote: Well, I am okay with using video ports to describe the relationship between the encoder, bridge and the panel. But, its just that I need to make use of 2 functions when phandle does it using just one function ;) -panel_node = of_parse_phandle(dev-of_node, panel, 0) + endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); + if (!endpoint) + return -EPROBE_DEFER; + + panel_node = of_graph_get_remote_port_parent(endpoint); + if (!panel_node) + return -EPROBE_DEFER; If nobody else has objections over using of_graph functions instead of phandles, I can respin this patchset by making use of video ports. The discussion did digress somewhat. As a clarification, I'm in no way nack'ing this series because it doesn't use the graphs for video connections. I don't see the simple phandle bindings used here as broken as such. Well, I am okay with any approach you guys decide on. I desperately want this to get this in since it has been floating around for quite sometime. The more we drag this, the more rework for me since the number of platforms using bridge support is increasing daily! I won't nack this patch either. I'm however concerned that we'll run straight into the wall if we don't come up with an agreement on a standard way to describe connections in DT for display devices, which is why I would prefer the ps8622 bindings to use OF graph to describe connections. I think there's not really an easy way out here. It's pretty bold trying to come up with a common way to describe bridges when we have only a single one (and a single use-case at that). The worst that can happen is that we need to change the binding at some point, in which case we may have to special-case early drivers, but I really don't think that's as much of an issue as everybody seems to think. This series has been floating around for months because we're being overly prudent to accept a binding that /may/ turn out to not be generic enough. Right. It would be great if you guys come to agreement ASAP! Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] regulator: of: Add regulator-initial-mode parse support
On Thu, Oct 09, 2014 at 04:19:47PM +0100, Javier Martinez Canillas wrote: Hello Mark, On 10/09/2014 12:27 PM, Mark Rutland wrote: Well, is not fairly obvious to me. One can also say the opposite, why the kernel is documenting a DT binding that is not (currently) implemented? Checkpatch will complain regarding undocumented bindings, so from a pragmatic point of view the binding must come first. Personally, when I read a patch series I do an initial pass in-order, and having the binding first makes things clearer. I might have some questions regarding the binding that the driver answers later, and it makes it easier to spot undocumented properties or conventions used by the driver. Doing so the other way around usually leaves me with more questions at the end. Thanks a lot for the explanation, it certainly makes sense then to have the DT binding before. I'll propose a patch to add that information to Documentation/devicetree/bindings/submitting-patches.txt so people (like me) who didn't find it obvious can know what the convention is. That sounds like a good idea; yes please. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/2] Adds PMU and S2R support for exynos5420
Abhilash Kesavan kesavan.abhil...@gmail.com writes: On Fri, Oct 10, 2014 at 4:29 AM, Kevin Hilman khil...@kernel.org wrote: Kevin Hilman khil...@kernel.org writes: [...] Trying $SUBJECT series on top of kukjin's for-next is working fine, but I'm still not able to make it work on linux-next, with or without the CLK_IGNORE_UNUSED patch. Nevermind, turns out I didn't apply the CLK_IGNORE_UNUSED PATCH. If I actually apply it, I have it working on top of linux-next. However, it seems to have some issues with the nonboot CPUs resuming: [ 11.319833] Enabling non-boot CPUs ... [ 12.319134] CPU1: failed to come online [ 12.319235] Error taking CPU1 up: -5 [ 13.319137] CPU2: failed to come online [ 13.319209] Error taking CPU2 up: -5 [ 14.319133] CPU3: failed to come online [ 14.319224] Error taking CPU3 up: -5 Are you guys seeing all the non-boot CPUs coming up? They fail to come online, but the /sys/devices/.../cpu?/online reports that they are online, which means the next attempt to hotplug them will probably BUG(). Also, If I turn off the switcher (enabled by default exynos_defconfig), resume still has problems bringing all the nonboot CPUs online, and then has a bunch of I2C errors[1]. And one more..., if I try enabling CPUidle[1] with exynos_defconfig, S2R causes a reboot (seems to be on resume.) I tested S2R on my Peach-Pi (Exynos5800) on linux-next-20141009. My tree has: a57db95 TEMP: Use CLK_IGNORE_UNUSED for aclk200_disp1 18158ac ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420 I was missing this one. d86cb2d ARM: exynos5: Add Suspend-to-RAM support for 5420 93f1b7c ARM: exynos5: Add PMU support for 5420 8dcc2db ARM: EXYNOS: Move PMU specific definitions from common.h 493a16a ARM: EXYNOS: Add platform driver support for Exynos PMU 64e73fb mfd: syscon: Decouple syscon interface from platform devices af7b574 Add linux-next specific files for 20141009 4658bc0 Merge branch 'akpm/master' 9784a19 mm: add strictlimit knob I have tested the following scenarios using exynos_defconfig with CONFIG_COMMON_CLK_MAX77802 enabled: 1) CONFIG_BIG_LITTLE enabled (default in exynos_defconfig) 2) CONFIG_BIG_LITTLE disabled 3) CONFIG_ARM_BIG_LITTLE_CPUIDLE enabled In all 3 cases the secondary cores as well as the system resume fine. Can you please confirm if your kernel has a similar configuration ? Adding in the missing dependency above, it's now working for me in all 3 scenarios. Looking back at the cover letter, I see it's clearly listed as a dependency. Sorry, my fault. Feel free to add Tested-by: Kevin Hilman khil...@linaro.org to $SUBJECT series. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] iio: exynos-adc: use syscon instead of ioremap
On 21/09/14 13:17, Jonathan Cameron wrote: On 16/09/14 09:58, Naveen Krishna Chatradhi wrote: Changes since v1: 1. Rebased on top of togreg branch of IIO git. This patch set does the following 1. Use the syscon and Regmap API instead of ioremappaing the ADC_PHY register from PMU. 2. Updates the Documentation in exynos-adc.txt with syscon phandle for the ADC nodes. 3. Updates the Dts files for Exynos3250, Exynos4x12, Exynos5250, Exynos5420 with the syscon phandle. Tested on Exynos5420 based Peach PIT and Exynos5800 based Peach PI by verifying sysfs entries provided by HWMON based NTC thermistors. Tested-By for Exynos3250, Exynos4x12 would be appreciated. Would definitely be good! The main issue I have with this series is that it breaks backward compatibility with old device trees and newer kernels. Now I appreciate that sometimes there are reasons to do it but want this to have deeper consideration (and acks to show it) from the Exynos side of things and preferably from the device tree side of things as well. cc'd Kukjin Kim for the Exynos side of things as the listed Maintainer. Otherwise, the series looks fine to me. Kukjin? Sorry to pester, but this has been sat in my waiting queue for a while now. Naveen Krishna Chatradhi (3): iio: exyno-adc: use syscon for PMU register access Documentation: dt-bindings: update exynos-adc.txt with syscon handle ARM: dts: exynos: Add sysreg phandle to ADC node .../devicetree/bindings/arm/samsung/exynos-adc.txt |9 -- arch/arm/boot/dts/exynos3250.dtsi |3 +- arch/arm/boot/dts/exynos4x12.dtsi |3 +- arch/arm/boot/dts/exynos5250.dtsi |3 +- arch/arm/boot/dts/exynos5420.dtsi |3 +- drivers/iio/adc/exynos_adc.c | 30 ++-- 6 files changed, 36 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/2] Adds PMU and S2R support for exynos5420
Hi Kevin, On Sat, Oct 11, 2014 at 3:47 AM, Kevin Hilman khil...@kernel.org wrote: Abhilash Kesavan kesavan.abhil...@gmail.com writes: On Fri, Oct 10, 2014 at 4:29 AM, Kevin Hilman khil...@kernel.org wrote: Kevin Hilman khil...@kernel.org writes: [...] Trying $SUBJECT series on top of kukjin's for-next is working fine, but I'm still not able to make it work on linux-next, with or without the CLK_IGNORE_UNUSED patch. Nevermind, turns out I didn't apply the CLK_IGNORE_UNUSED PATCH. If I actually apply it, I have it working on top of linux-next. However, it seems to have some issues with the nonboot CPUs resuming: [ 11.319833] Enabling non-boot CPUs ... [ 12.319134] CPU1: failed to come online [ 12.319235] Error taking CPU1 up: -5 [ 13.319137] CPU2: failed to come online [ 13.319209] Error taking CPU2 up: -5 [ 14.319133] CPU3: failed to come online [ 14.319224] Error taking CPU3 up: -5 Are you guys seeing all the non-boot CPUs coming up? They fail to come online, but the /sys/devices/.../cpu?/online reports that they are online, which means the next attempt to hotplug them will probably BUG(). Also, If I turn off the switcher (enabled by default exynos_defconfig), resume still has problems bringing all the nonboot CPUs online, and then has a bunch of I2C errors[1]. And one more..., if I try enabling CPUidle[1] with exynos_defconfig, S2R causes a reboot (seems to be on resume.) I tested S2R on my Peach-Pi (Exynos5800) on linux-next-20141009. My tree has: a57db95 TEMP: Use CLK_IGNORE_UNUSED for aclk200_disp1 18158ac ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420 I was missing this one. d86cb2d ARM: exynos5: Add Suspend-to-RAM support for 5420 93f1b7c ARM: exynos5: Add PMU support for 5420 8dcc2db ARM: EXYNOS: Move PMU specific definitions from common.h 493a16a ARM: EXYNOS: Add platform driver support for Exynos PMU 64e73fb mfd: syscon: Decouple syscon interface from platform devices af7b574 Add linux-next specific files for 20141009 4658bc0 Merge branch 'akpm/master' 9784a19 mm: add strictlimit knob I have tested the following scenarios using exynos_defconfig with CONFIG_COMMON_CLK_MAX77802 enabled: 1) CONFIG_BIG_LITTLE enabled (default in exynos_defconfig) 2) CONFIG_BIG_LITTLE disabled 3) CONFIG_ARM_BIG_LITTLE_CPUIDLE enabled In all 3 cases the secondary cores as well as the system resume fine. Can you please confirm if your kernel has a similar configuration ? Adding in the missing dependency above, it's now working for me in all 3 scenarios. Looking back at the cover letter, I see it's clearly listed as a dependency. Sorry, my fault. Feel free to add Tested-by: Kevin Hilman khil...@linaro.org Thanks a lot for testing. to $SUBJECT series. Kevin -- 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
