Re: [PATCHv2] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
On 31.05.2015 23:34, Chanho Park wrote:
The odroid-xu3 board which is based on exynos5422 not exynos5800 is
booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order
is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are
cortex-a15 cores. To correct this mis-odering, I added exynos5422.dtsi
and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and
cpu4-7 are cortex-a15.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
Changes from v1:
- rename exynos5422.dtsi to exynos5422-cpus.dtsi
- include the dtsi file top of the exynos5422-odroidxu3.dts
arch/arm/boot/dts/exynos5422-cpus.dtsi | 88
++
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 +-
2 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
new file mode 100644
index 000..d39db49
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -0,0 +1,88 @@
+/*
+ * SAMSUNG EXYNOS5422 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * The only difference between EXYNOS5422 and EXYNOS5800 is cpu ordering. The
+ * EXYNOS5422 is booting from Cortex-A7 core while the EXYNOS5800 is booting
+ * from Cortex-A15 core.
+ *
+ * EXYNOS5422 based board files can include this file to provide cpu ordering
+ * which could boot a cortex-a7 from cpu0.
+ *
+ * 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 exynos5420.dtsi
+
+/ {
+ compatible = samsung,exynos5800, samsung,exynos5422,
+ samsung,exynos5;
+};
Drop the include and compatible.
The goal of the file is to override only cpus, not to introduce whole
Exynos5420 node tree.
The exynos5420.dtsi is already included by board file through
exynos5800.dtsi.
Rest looks fine.
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] drm/exynos/ipp: Replace struct timeval usage
'struct timeval' uses a 32-bit seconds representation which
will overflow in the year 2038 and beyond. This patch
replaces the use of struct timeval with struct timespec64
which uses a 64-bit seconds representation and is y2038 safe.
The patch is part of a larger effort to remove all 32-bit
timekeeping variables (timeval, time_t and timespec) from the
kernel.
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b7f1cbc..7cd4a97 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -16,6 +16,7 @@
#include linux/types.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/time64.h
#include drm/drmP.h
#include drm/exynos_drm.h
@@ -1414,7 +1415,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
struct drm_exynos_ipp_queue_buf qbuf;
struct drm_exynos_ipp_send_event *e;
struct list_head *head;
- struct timeval now;
+ struct timespec64 now;
unsigned long flags;
u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
int ret, i;
@@ -1518,10 +1519,11 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
e = list_first_entry(c_node-event_list,
struct drm_exynos_ipp_send_event, base.link);
- do_gettimeofday(now);
- DRM_DEBUG_KMS(tv_sec[%ld]tv_usec[%ld]\n, now.tv_sec, now.tv_usec);
+ getnstimeofday64(now);
+ DRM_DEBUG_KMS(tv_sec[%lld]tv_usec[%lld]\n, now.tv_sec, (now.tv_nsec /
+ NSEC_PER_SEC));
e-event.tv_sec = now.tv_sec;
- e-event.tv_usec = now.tv_usec;
+ e-event.tv_usec = now.tv_nsec / NSEC_PER_SEC;
e-event.prop_id = property-prop_id;
/* set buffer id about source destination */
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos/ipp: Replace struct timeval usage
'struct timeval' uses a 32-bit seconds representation which
will overflow in the year 2038 and beyond. This patch
replaces the use of struct timeval with struct timespec64
which uses a 64-bit seconds representation and is y2038 safe.
The patch is part of a larger effort to remove all 32-bit
timekeeping variables (timeval, time_t and timespec) from the
kernel.
Signed-off-by: Tina Ruchandani ruchandani.t...@gmail.com
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b7f1cbc..7cd4a97 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -16,6 +16,7 @@
#include linux/types.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/time64.h
#include drm/drmP.h
#include drm/exynos_drm.h
@@ -1414,7 +1415,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
struct drm_exynos_ipp_queue_buf qbuf;
struct drm_exynos_ipp_send_event *e;
struct list_head *head;
- struct timeval now;
+ struct timespec64 now;
unsigned long flags;
u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
int ret, i;
@@ -1518,10 +1519,11 @@ static int ipp_send_event(struct exynos_drm_ippdrv
*ippdrv,
e = list_first_entry(c_node-event_list,
struct drm_exynos_ipp_send_event, base.link);
- do_gettimeofday(now);
- DRM_DEBUG_KMS(tv_sec[%ld]tv_usec[%ld]\n, now.tv_sec, now.tv_usec);
+ getnstimeofday64(now);
+ DRM_DEBUG_KMS(tv_sec[%lld]tv_usec[%lld]\n, now.tv_sec, (now.tv_nsec /
+ NSEC_PER_SEC));
e-event.tv_sec = now.tv_sec;
- e-event.tv_usec = now.tv_usec;
+ e-event.tv_usec = now.tv_nsec / NSEC_PER_SEC;
e-event.prop_id = property-prop_id;
/* set buffer id about source destination */
--
2.2.0.rc0.207.ga3a616c
--
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
[GIT PULL] ARM: EXYNOS: Fix for 4.1, 4th
Dear Arnd and Olof, This is fix from April which should be applied before [0]. Apparently it was missed. I am sending it to you guys because Kukjin seems to be busy. Best regards, Krzysztof [0] http://www.spinics.net/lists/linux-samsung-soc/msg44937.html The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736: Linux 4.1-rc3 (2015-05-10 15:12:29 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-fixes-4.1-4 for you to fetch changes up to fe931229c61c04e0a7906c4ebef9623a4538a5ab: ARM: exynos: Fix wake-up interrupts for Exynos3250 (2015-06-01 09:08:34 +0900) Fix for Exynos3250 RTC wake-up interrupts after converting PMU wakeup to stacked domains. This allows waking up the device from suspend to RAM using S3C RTC driver (the RTC on SoC). The patch should be applied some time ago, unfortunately it seems it slipped through fingers. Marc Zyngier (1): ARM: exynos: Fix wake-up interrupts for Exynos3250 arch/arm/mach-exynos/suspend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 12/13] drm/exynos: atomic dpms support
On 05/30/2015 06:33 AM, Gustavo Padovan wrote:
2015-05-29 Joonyoung Shim jy0922.s...@samsung.com:
On 05/29/2015 06:36 AM, Gustavo Padovan wrote:
2015-05-28 Joonyoung Shim jy0922.s...@samsung.com:
On 05/28/2015 05:24 PM, Joonyoung Shim wrote:
On 05/28/2015 02:39 PM, Inki Dae wrote:
Hi Gustavo,
On 2015년 05월 28일 05:27, Gustavo Padovan wrote:
Hi Inki,
2015-05-27 Inki Dae inki@samsung.com:
Hi Gustavo,
On 2015년 05월 23일 00:40, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Run dpms operations through the atomic intefaces. This basically
removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call -disable() instead of -dpms()
- do not use WARN_ON on crtc enable/disable
v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com
Tested-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/bridge/ps8622.c | 2 +-
drivers/gpu/drm/bridge/ptn3460.c| 2 +-
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 95
-
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c| 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c| 6 +-
10 files changed, 69 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c
b/drivers/gpu/drm/bridge/ps8622.c
index b604326..d686235 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -499,7 +499,7 @@ static void ps8622_connector_destroy(struct
drm_connector *connector)
}
static const struct drm_connector_funcs ps8622_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index 8ed3617..260bc9f 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs ptn3460_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 195fe60..c9995b1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -954,7 +954,7 @@ static void exynos_dp_connector_destroy(struct
drm_connector *connector)
}
[--snip--]
static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
- .dpms = exynos_drm_crtc_dpms,
- .prepare= exynos_drm_crtc_prepare,
- .commit = exynos_drm_crtc_commit,
+ .enable = exynos_drm_crtc_enable,
+ .disable= exynos_drm_crtc_disable,
.mode_fixup = exynos_drm_crtc_mode_fixup,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = exynos_drm_crtc_mode_set_nofb,
I think it'd be better to use atomic_flush callback to enable global
dma
like commit callback did. Is there any reason that you don't use
atomic_begin and atomic_flush callbacks?
atomic relevant codes I looked into do as follows,
atomic_begin();
atomic_update(); /* this will call win_commit callback to set a
overlay
relevant registers and enable its dma channel. */
atomic_flush();
So atomic overlay updating between atomic_begin() ~ atomic_flush() will
be guaranteed.
I think we can go down that road, but I'd suggest we push the atomic
patches v8 (with the lastest comments from Joonyoung fixed) and then
work on the change you are proposing as a follow-up together with the
other improvements for atomic I already have queued here. This way
we don't take the risk of missing one more merge window.
We(I and Joonyoung) will have discussion about this patch series. For
this, we have already started to analyze entire atomic features
including your patch set so I'd merge it at end of next week according
to the discussion. I'm not kind of sure yet but I will merge it as long
as there is no big problem.
Actually i agree to opinion of Gustavo and will repost the patchset of
Gustavo with some
[PATCH] drm/exynos: g2d: Replace struct timeval usage
'struct timeval' uses a 32-bit seconds representation which will overflow in the year 2038 and beyond. This patch replaces the use of struct timeval with struct timespec64 which uses a 64-bit seconds representation and is y2038 safe. The patch is part of a larger effort to remove all 32-bit timekeeping variables (timeval, time_t and timespec) from the kernel. Signed-off-by: Tina Ruchandani ruchandani.t...@gmail.com --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index 81a2508..69e236f 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/pm_runtime.h #include linux/slab.h +#include linux/time64.h #include linux/workqueue.h #include linux/dma-mapping.h #include linux/dma-attrs.h @@ -889,7 +890,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 cmdlist_no) struct drm_device *drm_dev = g2d-subdrv.drm_dev; struct g2d_runqueue_node *runqueue_node = g2d-runqueue_node; struct drm_exynos_pending_g2d_event *e; - struct timeval now; + struct timespec64 now; unsigned long flags; if (list_empty(runqueue_node-event_list)) @@ -898,9 +899,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 cmdlist_no) e = list_first_entry(runqueue_node-event_list, struct drm_exynos_pending_g2d_event, base.link); - do_gettimeofday(now); + getnstimeofday64(now); e-event.tv_sec = now.tv_sec; - e-event.tv_usec = now.tv_usec; + e-event.tv_usec = (now.tv_nsec / NSEC_PER_USEC); e-event.cmdlist_no = cmdlist_no; spin_lock_irqsave(drm_dev-event_lock, flags); -- 2.2.0.rc0.207.ga3a616c -- 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/ipp: Replace struct timeval usage
Hi Tina,
On Mon, Jun 01, 2015 at 08:43:08AM +0530, Tina Ruchandani wrote:
'struct timeval' uses a 32-bit seconds representation which
will overflow in the year 2038 and beyond. This patch
replaces the use of struct timeval with struct timespec64
which uses a 64-bit seconds representation and is y2038 safe.
The patch is part of a larger effort to remove all 32-bit
timekeeping variables (timeval, time_t and timespec) from the
kernel.
Your sing-off is missing.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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 1/2] usb: ehci-exynos: Make provision for vdd regulators
2014-06-25 21:42 GMT+09:00 Vivek Gautam gautam.vi...@samsung.com: Facilitate getting required 3.3V and 1.0V VDD supply for EHCI controller on Exynos. With the patches for regulators' nodes merged in 3.15: c8c253f ARM: dts: Add regulator entries to smdk5420 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, the exynos systems turn on only minimal number of regulators. Until now, the VDD regulator supplies were either turned on by the bootloader, or the regulators were enabled by default in the kernel, so that the controller drivers did not need to care about turning on these regulators on their own. This was rather bad about these controller drivers. So ensuring now that the controller driver requests the necessary VDD regulators (if available, unless there are direct VDD rails), and enable them so as to make them working. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Jingoo Han jg1@samsung.com Cc: Alan Stern st...@rowland.harvard.edu --- Changes from v2: - replaced devm_regulator_get() with devm_regulator_get_optional(). - Added Documentation for the vdd supplies for the controller. - Re-did the commit message. The patch looks useful but it seems it was forgotten. Do you have any plans to resend it? 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: exynos4412: Audio dies after one day on kernel 4.0
2015-05-31 2:32 GMT+09:00 gabr...@unseen.is:
Hello,
I've been successfully using a self compiled linux kernel until version
3.19 together with Debian Stretch.
After upgrading the kernel to version 4.0 I see strange messages in the
logs i.e.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: ALSA woke us up to write new data to the device, but there
was actually nothing to write!
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: Most likely this is a bug in the ALSA driver
'snd_soc_simple_card'. Please report this issue to the ALSA developers.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
snd_pcm_avail() returned 0 or another value min_avail.
I can easily play sound in perfect quality for approx the first 24h.
After that time the sound becomes distorted and is choppy/crackling.
After rebooting then the sound is optimal again.
I have tried to use kernel 4.0 with almost exactly the same
configuration than for 3.19 to no avail.
Then somebody on
http://forum.odroid.com/viewtopic.php?f=82t=13281p=91186 gave me the
hint that the followin patch might solve the issue:
https://github.com/prahal/linux/commit/5e60cfc9fa5101a346e29ef5f944fbbad300c72d
The patch did help something. I can now still play music after 2 days
but what happens is that each time I turn on music I get a choppy sound
for some time. That means the sound comes clear but every 2 seconds the
sound pauses for a fraction of a second. Which is somewhat comparable to
the issue earlier but without the heavy crackling - and that this goes
away after a couple of minutes.
But furthermore the sound has now simple cracklings. One in two second
approx. and they do not disappear.
Does anybody have an idea what could be the matter here?
Thanks in advance.
+Cc Robert, dmaengine list.
Bisecting would be helpful. You could also try reverting following commits:
88987d2c75
aee4d1fac8
Other possible test case would be disabling runtime PM for pl330 DMA driver:
for i in /sys/bus/amba/drivers/dma-pl330/*.[amp]dma/power ; do
echo on ${i}/control
done
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] ARM: dts: odroidxu3: Enable USB3 regulators
2015-05-30 22:53 GMT+09:00 Anand Moon linux.am...@gmail.com: On 28 May 2015 at 14:49, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 28.05.2015 17:58, Anand Moon wrote: Enable regulator for usbdrd3_0 and usbdrd3_1 From the schematic pin diagram USB3_0 and USB3_1 is regulated by LDO9 and LD011. Please reformat statement above to proper sentence(s) without before From. Fix the boot message of failed. [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device tree [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in node /usb@1200 failed [3.503568] usb@1200 supply vdd33 not found, using dummy regulator [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device tree [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in node /usb@1200 failed [3.509181] usb@1200 supply vdd10 not found, using dummy regulator [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device tree [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in node /usb@1240 failed [3.917578] usb@1240 supply vdd33 not found, using dummy regulator [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device tree [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in node /usb@1240 failed --- This patch is based on Krzysztof github branch work-next/odroid-xu3-s2mps11-irq --- I mentioned this already on previous postings. Let's make an exercise. Please: 1. Save your email as mbox format (from mailer). 2. Go to a GIT repo with kernel and checkout base branch. 3. git am 0001-the-name-of-file.mbox 4. git show Do you see the signed-off-by in commit? The patch itself looks good, thanks for fixing this. Just please fix the issues with commit message. By the way: 1. The always-on from LDO9 could be probably removed if the ehci-exynos driver had regulator consumer implemented. 2. The Documentation/devicetree/bindings/usb/exynos-usb.txt (or dwc.txt) should proably mention the vdd-supply property. Hi Krzysztof, https://patchwork.kernel.org/patch/4420061/ https://patchwork.kernel.org/patch/4420071/ These patch are missing for this changes to make it work correctly. Can you share you thought on this. They look quite old, it is a pity that they were not merged. 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] ARM: dts: add exynos5422.dtsi to correct cpu order
2015-05-28 17:43 GMT+09:00 Chanho Park chanho61.p...@samsung.com: Hi, When adding new 5422 board we can split out CPU configuration to separate DTSI file. I already posted patches for Odroid XU3-family common DTSI file for XU3 Lite board: http://www.spinics.net/lists/linux-samsung-soc/msg44868.html IMHO, all of the exynos5422 boards will be same cpu configurations. That's why I added new exynos5422.dtsi. Maybe all of boards will have same configuration... maybe not. You cannot predict the future, right? It is however strictly related to the board configuration. The SoC supports both boot modes depending on the GPIO pin. I do not oppose against the idea of correcting order of CPUs. It is nice to have them ordered in a more natural way. However I think this should be a DTSI related to the CPU-nodes, not a DTSI for SoC. Especially that inclusion order gets quite complicated: 1. Odroid includes 5422.dtsi. 2. 5422 includes 5800. 3. 5800 includes 5420. Can you make it as a DTSI specific for CPU nodes configuration and then include it only in boards DTS? BTW, booting of secondary cpus are still broken. Is there any progress of the patch[1]? This patch is also generated top of the patch with some fixes. [1]. http://www.spinics.net/lists/linux-samsung-soc/msg39523.html No progress so far. Apparently nobody knows why this works and what to do with it. I would suspect booted CPUs stuck somewhere in BL1 or BL2 and writing to PMU_SPARE2 kicks them. However this is just a guess. Kukjin which could be the closest person to the real knowledge (LSI) did not gave his feedback. We have a lot of such hacks and undocumented interfaces between kernel and bootloaders. IMHO it would be good to start documenting them. Good. But, who can do it? Anyone can do it! The information is there (spread in arch/arm/mach-exynos and in u-boot code) so we just need a volunteer! :) BR, 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
[PATCHv2] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
The odroid-xu3 board which is based on exynos5422 not exynos5800 is
booted from cortex-a7 core unlike exynos5800. The odroid-xu3's cpu order
is quite strange. cpu0 and cpu5-7 are cortex-a7 cores and cpu1-4 are
cortex-a15 cores. To correct this mis-odering, I added exynos5422.dtsi
and reversing cpu orders from exynos5420. Now, cpu0-3 are cortex-a7 and
cpu4-7 are cortex-a15.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
Changes from v1:
- rename exynos5422.dtsi to exynos5422-cpus.dtsi
- include the dtsi file top of the exynos5422-odroidxu3.dts
arch/arm/boot/dts/exynos5422-cpus.dtsi | 88 ++
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 +-
2 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos5422-cpus.dtsi
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
new file mode 100644
index 000..d39db49
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -0,0 +1,88 @@
+/*
+ * SAMSUNG EXYNOS5422 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * The only difference between EXYNOS5422 and EXYNOS5800 is cpu ordering. The
+ * EXYNOS5422 is booting from Cortex-A7 core while the EXYNOS5800 is booting
+ * from Cortex-A15 core.
+ *
+ * EXYNOS5422 based board files can include this file to provide cpu ordering
+ * which could boot a cortex-a7 from cpu0.
+ *
+ * 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 exynos5420.dtsi
+
+/ {
+ compatible = samsung,exynos5800, samsung,exynos5422,
+samsung,exynos5;
+};
+
+cpu0 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x100;
+ clock-frequency = 10;
+ cci-control-port = cci_control0;
+};
+
+cpu1 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x101;
+ clock-frequency = 10;
+ cci-control-port = cci_control0;
+};
+
+cpu2 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x102;
+ clock-frequency = 10;
+ cci-control-port = cci_control0;
+};
+
+cpu3 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x103;
+ clock-frequency = 10;
+ cci-control-port = cci_control0;
+};
+
+cpu4 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0x0;
+ clock-frequency = 18;
+ cci-control-port = cci_control1;
+};
+
+cpu5 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0x1;
+ clock-frequency = 18;
+ cci-control-port = cci_control1;
+};
+
+cpu6 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0x2;
+ clock-frequency = 18;
+ cci-control-port = cci_control1;
+};
+
+cpu7 {
+ device_type = cpu;
+ compatible = arm,cortex-a15;
+ reg = 0x3;
+ clock-frequency = 18;
+ cci-control-port = cci_control1;
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index edc25cf..00f45c9 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -12,10 +12,12 @@
/dts-v1/;
#include exynos5800.dtsi
+#include exynos5422-cpus.dtsi
/ {
model = Hardkernel Odroid XU3;
- compatible = hardkernel,odroid-xu3, samsung,exynos5800,
samsung,exynos5;
+ compatible = hardkernel,odroid-xu3, samsung,exynos5800,
+samsung,exynos5422, samsung,exynos5;
memory {
reg = 0x4000 0x7EA0;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
