Re: [PATCH] Input: s3c2410_ts: Move to clk_prepare_enable/clk_disable_unprepare
Hi Vasily, On Wed, Jul 09, 2014 at 12:13:41PM +0300, Vasily Khoruzhick wrote: On 8 July 2014 18:00:49 Dmitry Torokhov wrote: Hi Dmitry, - clk_disable(ts.clock); + clk_disable_unprepare(ts.clock); Do we really need to unprepare on suspend? Why simply disabling is not enough here? You're right, disabling should be enough here. I'll resend a patch after testing on a hardware. I ended up cutting out suspend/resume parts and applying. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: I like the sound of going to the standard ttyS notation and only providing ports for ones that exist, but is this userspace-visible ttyS is 8250 compatible UARTS. If the Samsung is not an 8250 compatible UART then it doesn't belong as ttyS from the kernel perspective. OK, thanks for pointing that out. So we stick with the ttySAC namespace. And by doing that, and sticking to the existing and documented behaviour, it seems like we have already addressed Russells's concern: The problem you're raising is very much the same problem you have when there are multiple USB serial devices connected to the machine - you just get a bunch of /dev/ttyUSB* devices which are unordered (they can change on each boot, or change order if you disconnect and reconnect them.) In this case, we have a dedicated namespace and the path information is already fully encoded in the device name. The order and number of ports are fixed, they can't be disconnected and reconnected. There is no real risk of an additional serial controller driver coming to play in the ttySAC namespace. So I think Tomasz's approach is good - although I haven't looked at the code in detail. Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 4/5] Samsung exynos_mct update for v3.17
On 07/23/2014 01:33 AM, Kukjin Kim wrote: On 07/23/14 02:32, Daniel Lezcano wrote: On 07/22/2014 12:59 PM, Kukjin Kim wrote: Daniel Lezcano wrote: On 07/20/2014 12:06 AM, Olof Johansson wrote: On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote: Note that this is also based on 3.16-rc5 because of dependency with previous samsung fixes including exynos_mct already merged in mainline during -rc. The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab: Linux 3.16-rc5 (2014-07-13 14:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-mct for you to fetch changes up to 1a631118c1d085fe162f3b6d44f710c72206ef2d: clocksource: exynos_mct: Only use 32-bits where possible (2014-07-19 03:07:52 +0900) exynos_mct update for v3.17 - only use 32-bit access for performance benefits on exynos 32-bit system and this means ARCH timer should be supported on exynos 64-bit system instead of current MCT. - use readl_relaxed/writel_relaxed to consistently use the proper functions in exynos_mct. There's no reason for these to go through arm-soc, is there? They should go through the clocksource tree (Daniel Lezcano / Thomas Gleixner). They also lack acks from them if they for some reason need to go through arm-soc. Olof, you're right. The branch has no dependency with arm-soc so I agreed. Yes, that's right. Furthermore I have been discussing with Doug about these patches before. Kukjin, is there any dependency on these patches ? Yeah, Daniel, it should be handled in the clocksource tree so how should I do for it? I can pull your branch v3.17-next/mct-exynos and you drop the merge from this branch in your master ? Yes please and I did drop the merge in my -next just now. Ok, thanks. The patches are applied in my branch for 3.17. -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
On 23 July 2014 13:08, Lukasz Majewski l.majew...@samsung.com wrote: Do you want to say that we have enough tests and we don't need more ? No. We don't have any tests at all :) I always thought that we shall have as much regression tests as possible. Yeah, tests are welcomed but the question is where should they get added. Don't know if its common to add tests directly to kernel. And also if the test is really good, not discouraging your work. On 21 July 2014 12:32, Lukasz Majewski l.majew...@samsung.com wrote: This commit adds first regression test cpufreq_freq_test.sh for the cpufreq subsystem. That's not enough, Tell us why we should continue reading this mail.. Hmm... If regression and test don't catch the attention of a diligent maintainer, then I cannot do much more to encourage him to read the whole e-mail :-) What I meant to say was, your subject and body must be good enough to answer most of the things. You don't have to tell much about the implementation but other things should be pretty clear from logs. Your current logs are quite short for something that's not a normal practice. I can imagine that maintainers are very busy, therefore I've prepared README file with detailed description of the script operation. Yeah, a README is welcomed and would be useful for users as well.. I couldn't make out the purpose of this test and why we need it. How do we ensure that cpufreq attributes exported by sysfs are exposing correct values? First of all the cpufreq attributes are part of the subsystem API. There are systems which actually depend on them, so we would be better off to test if they work as intended. Secondly, the test takes those values and then with use of other attribute enforce the value, which is then read via cat'ing cpufreq_cur_freq. If any of the attributes is wrong then we will spot the error immediately. Shouldn't you use userspace governor then instead of performance? And then we don't need the gzip stuff at all. We can just set it to the right freq and get current freq to see if it matches? And now that we are starting to get tests added into the kernel (will still wait to see what Rafael has to advice), we better think of the way these are going to get added. Probably a single script with parameters like what to test? And actually what do we mean by this statement even? What kind of errors can be there in exposing these values. Errors with cpufreq and CCF cooperation - especially when some parts of cpufreq code uses direct write to MUX, DIV or PLL SoC registers. Also, one can check if permutations of changing all available frequencies are working properly. Yeah, that would be fine. Probably need to think more about scripts name. -- 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] cpufreq: tests: Providing cpufreq regression test
On 23 July 2014 15:40, Lukasz Majewski l.majew...@samsung.com wrote: Shouldn't you use userspace governor then instead of performance? Performance assures that we will have the right frequency set. Why wouldn't userspace assure that? However, there can be a similar patch to use userspace governor and various load to fail if ondemand's frequency flipping is detected. That's why I want to get to the motive behind this patch. AFAIU, we are checking if its fine to switch to available frequencies or not and if yes, do we actually switch to those. Right? For, this testcase we just need a single test and I still don't see why performance is better than userspace? And then we don't need the gzip stuff at all. We can just set it to the right freq and get current freq to see if it matches? Sometimes interresting things show up when you have 100% CPU load and you try to switch frequency. That's a different test then. And that's how it should be presented. So, probably another option to the script, which isn't forced on people. -- 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: [RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue
Sean,
On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul seanp...@google.com wrote:
On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
Move the DP training and video enable from the hotplug handler into
a seperate function and call the same during dpms ON.
With existing code, DP HPD should be generated just few ms before
calling enable_irq in dp_poweron.
This patch removes that stringent time constraint.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
This looks eerily familiar to:
https://chromium-review.googlesource.com/#/c/65782/
In fact, I think it's probably better to do this in commit, rather than
poweron.
Sean
Your are right. This patch contains a subset of changes from the patch
you have mentioned.
But, If I provide commit calback to dp, then it would cause dp to
reinitialize twice
in quick successions - during dpms_on and during commit.
For the user, it would look like a glitch. So, I chose not to provide
a commit callback.
Ajay
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 845d766..a94b114 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void
*arg)
static void exynos_dp_hotplug(struct work_struct *work)
{
struct exynos_dp_device *dp;
- int ret;
dp = container_of(work, struct exynos_dp_device, hotplug_work);
+ if (dp-drm_dev)
+ drm_helper_hpd_irq_event(dp-drm_dev);
+}
+
+static void exynos_dp_setup(void *in_ctx)
+{
+ struct exynos_dp_device *dp = in_ctx;
+ int ret;
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -1059,6 +1067,7 @@ static void exynos_dp_poweron(struct exynos_dp_device
*dp)
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp-irq);
+ exynos_dp_setup(dp);
}
static void exynos_dp_poweroff(struct exynos_dp_device *dp)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
On Wednesday, July 23, 2014 02:19:54 PM Viresh Kumar wrote: On 23 July 2014 13:08, Lukasz Majewski l.majew...@samsung.com wrote: Do you want to say that we have enough tests and we don't need more ? No. We don't have any tests at all :) I always thought that we shall have as much regression tests as possible. Yeah, tests are welcomed but the question is where should they get added. Don't know if its common to add tests directly to kernel. Yes, it is. And also if the test is really good, not discouraging your work. On 21 July 2014 12:32, Lukasz Majewski l.majew...@samsung.com wrote: This commit adds first regression test cpufreq_freq_test.sh for the cpufreq subsystem. That's not enough, Tell us why we should continue reading this mail.. Hmm... If regression and test don't catch the attention of a diligent maintainer, then I cannot do much more to encourage him to read the whole e-mail :-) What I meant to say was, your subject and body must be good enough to answer most of the things. You don't have to tell much about the implementation but other things should be pretty clear from logs. Your current logs are quite short for something that's not a normal practice. I can imagine that maintainers are very busy, therefore I've prepared README file with detailed description of the script operation. Yeah, a README is welcomed and would be useful for users as well.. I couldn't make out the purpose of this test and why we need it. How do we ensure that cpufreq attributes exported by sysfs are exposing correct values? First of all the cpufreq attributes are part of the subsystem API. There are systems which actually depend on them, so we would be better off to test if they work as intended. Secondly, the test takes those values and then with use of other attribute enforce the value, which is then read via cat'ing cpufreq_cur_freq. If any of the attributes is wrong then we will spot the error immediately. Shouldn't you use userspace governor then instead of performance? And then we don't need the gzip stuff at all. We can just set it to the right freq and get current freq to see if it matches? And now that we are starting to get tests added into the kernel (will still wait to see what Rafael has to advice), we better think of the way these are going to get added. Probably a single script with parameters like what to test? I've had a look at the Lukasz' patch in the first iteration and I'm going to look at it again shortly. At this point I can only say that it should be clear to the user of the script what is tested, as well as what success and what failure mean. -- 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 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
Hi Krzysztof, On 18.07.2014 16:36, Krzysztof Kozlowski wrote: Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of ARMCLK will be reduced upon entering idle mode (WFI or WFE). Will apply the whole series to Samsung clock tree. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, leading to a segfault later.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 5fa1bb6..cde8a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1042,8 +1042,19 @@ err:
int exynos_g2d_get_ver_ioctl(struct drm_device *drm_dev, void *data,
struct drm_file *file)
{
+ struct drm_exynos_file_private *file_priv = file-driver_priv;
+ struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
+ struct device *dev = g2d_priv-dev;
+ struct g2d_data *g2d;
struct drm_exynos_g2d_get_ver *ver = data;
+ if (!dev)
+ return -ENODEV;
+
+ g2d = dev_get_drvdata(dev);
+ if (!g2d)
+ return -EFAULT;
+
ver-major = G2D_HW_MAJOR_VER;
ver-minor = G2D_HW_MINOR_VER;
--
1.8.5.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
Aw: [PATCH] drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail
Sorry for the noise! Please disregard the patch for now, it causes more trouble
than it solves!
- Tobias
Gesendet: Mittwoch, 23. Juli 2014 um 15:57 Uhr
Von: Tobias Jakobi tjak...@math.uni-bielefeld.de
An: linux-samsung-soc@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org, t.f...@samsung.com, inki@samsung.com,
Tobias Jakobi tjak...@math.uni-bielefeld.de
Betreff: [PATCH] drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, leading to a segfault later.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 5fa1bb6..cde8a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1042,8 +1042,19 @@ err:
int exynos_g2d_get_ver_ioctl(struct drm_device *drm_dev, void *data,
struct drm_file *file)
{
+ struct drm_exynos_file_private *file_priv = file-driver_priv;
+ struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
+ struct device *dev = g2d_priv-dev;
+ struct g2d_data *g2d;
struct drm_exynos_g2d_get_ver *ver = data;
+ if (!dev)
+ return -ENODEV;
+
+ g2d = dev_get_drvdata(dev);
+ if (!g2d)
+ return -EFAULT;
+
ver-major = G2D_HW_MAJOR_VER;
ver-minor = G2D_HW_MINOR_VER;
--
1.8.5.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
--
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: [RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue
On Wed, Jul 23, 2014 at 7:22 AM, Ajay kumar ajayn...@gmail.com wrote:
Sean,
On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul seanp...@google.com wrote:
On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
Move the DP training and video enable from the hotplug handler into
a seperate function and call the same during dpms ON.
With existing code, DP HPD should be generated just few ms before
calling enable_irq in dp_poweron.
This patch removes that stringent time constraint.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
This looks eerily familiar to:
https://chromium-review.googlesource.com/#/c/65782/
In fact, I think it's probably better to do this in commit, rather than
poweron.
Sean
Your are right. This patch contains a subset of changes from the patch
you have mentioned.
But, If I provide commit calback to dp, then it would cause dp to
reinitialize twice
in quick successions - during dpms_on and during commit.
For the user, it would look like a glitch. So, I chose not to provide
a commit callback.
Interesting. At least in my testing, the absence of the commit
callback causes my simple test app (which just does drmModeSetCrtc) to
fail. In this case, by fail, I mean that the screen just shows black.
Sean
Ajay
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 845d766..a94b114 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq,
void *arg)
static void exynos_dp_hotplug(struct work_struct *work)
{
struct exynos_dp_device *dp;
- int ret;
dp = container_of(work, struct exynos_dp_device, hotplug_work);
+ if (dp-drm_dev)
+ drm_helper_hpd_irq_event(dp-drm_dev);
+}
+
+static void exynos_dp_setup(void *in_ctx)
+{
+ struct exynos_dp_device *dp = in_ctx;
+ int ret;
+
ret = exynos_dp_detect_hpd(dp);
if (ret) {
/* Cable has been disconnected, we're done */
@@ -1059,6 +1067,7 @@ static void exynos_dp_poweron(struct exynos_dp_device
*dp)
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp-irq);
+ exynos_dp_setup(dp);
}
static void exynos_dp_poweroff(struct exynos_dp_device *dp)
--
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: g2d: let exynos_g2d_get_ver_ioctl fail
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, leading to a segfault later.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 8c62423..d662ab6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1042,8 +1042,23 @@ err:
int exynos_g2d_get_ver_ioctl(struct drm_device *drm_dev, void *data,
struct drm_file *file)
{
+ struct drm_exynos_file_private *file_priv = file-driver_priv;
+ struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
+ struct device *dev;
+ struct g2d_data *g2d;
struct drm_exynos_g2d_get_ver *ver = data;
+ if (!g2d_priv)
+ return -ENODEV;
+
+ dev = g2d_priv-dev;
+ if (!dev)
+ return -ENODEV;
+
+ g2d = dev_get_drvdata(dev);
+ if (!g2d)
+ return -EFAULT;
+
ver-major = G2D_HW_MAJOR_VER;
ver-minor = G2D_HW_MINOR_VER;
--
1.8.5.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
[drm/exynos] g2d: error handling and other things
Again, sorry for the noise. These two patches should now really fix what they're supposed to fix. - Tobias -- 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: g2d: make ioctls more robust
Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
if the G2D was succesfully probe. If that is not the case, then g2d_priv
is just NULL and extracting 'dev' from it in the next step is going to
produce a kernel oops.
Add proper checks and return ENODEV if the G2D is not available.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 5fa1bb6..8c62423 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1056,7 +1056,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
*drm_dev, void *data,
{
struct drm_exynos_file_private *file_priv = file-driver_priv;
struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
- struct device *dev = g2d_priv-dev;
+ struct device *dev;
struct g2d_data *g2d;
struct drm_exynos_g2d_set_cmdlist *req = data;
struct drm_exynos_g2d_cmd *cmd;
@@ -1067,6 +1067,10 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
*drm_dev, void *data,
int size;
int ret;
+ if (!g2d_priv)
+ return -ENODEV;
+
+ dev = g2d_priv-dev;
if (!dev)
return -ENODEV;
@@ -1223,13 +1227,17 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev,
void *data,
{
struct drm_exynos_file_private *file_priv = file-driver_priv;
struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
- struct device *dev = g2d_priv-dev;
+ struct device *dev;
struct g2d_data *g2d;
struct drm_exynos_g2d_exec *req = data;
struct g2d_runqueue_node *runqueue_node;
struct list_head *run_cmdlist;
struct list_head *event_list;
+ if (!g2d_priv)
+ return -ENODEV;
+
+ dev = g2d_priv-dev
if (!dev)
return -ENODEV;
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cpufreq: tests: Providing cpufreq regression test
On Wed, Jul 23, 2014 at 02:19:54PM +0530, Viresh Kumar wrote: On 23 July 2014 13:08, Lukasz Majewski l.majew...@samsung.com wrote: Do you want to say that we have enough tests and we don't need more ? No. We don't have any tests at all :) Not really true. I've found bugs triggering opps using cpufreq-bench. http://marc.info/?l=linux-pmm=138165517321579w=2 and i hope you learned from that experience and run this tool when making changes to the core. There is an old writeup of cpufreq-bench here: https://lwn.net/Articles/339862/ and the code itself is in the mainline tree, tools/power/cpupower/bench Andrew -- 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
[v2] [drm/exynos] g2d: error handling and other things
I blame it on the heat... *sigh* - Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2: 1/2] drm/exynos: g2d: make ioctls more robust
Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
if the G2D was succesfully probe. If that is not the case, then g2d_priv
is just NULL and extracting 'dev' from it in the next step is going to
produce a kernel oops.
Add proper checks and return ENODEV if the G2D is not available.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 5fa1bb6..929c6d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1056,7 +1056,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
*drm_dev, void *data,
{
struct drm_exynos_file_private *file_priv = file-driver_priv;
struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
- struct device *dev = g2d_priv-dev;
+ struct device *dev;
struct g2d_data *g2d;
struct drm_exynos_g2d_set_cmdlist *req = data;
struct drm_exynos_g2d_cmd *cmd;
@@ -1067,6 +1067,10 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
*drm_dev, void *data,
int size;
int ret;
+ if (!g2d_priv)
+ return -ENODEV;
+
+ dev = g2d_priv-dev;
if (!dev)
return -ENODEV;
@@ -1223,13 +1227,17 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev,
void *data,
{
struct drm_exynos_file_private *file_priv = file-driver_priv;
struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
- struct device *dev = g2d_priv-dev;
+ struct device *dev;
struct g2d_data *g2d;
struct drm_exynos_g2d_exec *req = data;
struct g2d_runqueue_node *runqueue_node;
struct list_head *run_cmdlist;
struct list_head *event_list;
+ if (!g2d_priv)
+ return -ENODEV;
+
+ dev = g2d_priv-dev;
if (!dev)
return -ENODEV;
--
1.8.5.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 1/3] ARM: exynos: remove unused mach/memory.h
Hello, On Tue, Jul 22, 2014 at 09:14:33AM -0700, Olof Johansson wrote: Patch 2 (v2!) ARM: remove remaining definitions of PLAT_PHYS_OFFSET from mach/memory.h touches several arch/arm/mach-*/include/mach/memory.h and arch/arm/Kconfig. armsoc? Russell? This can go through either, but Russell has already reviewed it once so send it to his patch tracker. Patch 3 fixes a warning regarding nommu and touches the Kconfig entry for Integrator and Renesas (non-multiplatform). armsoc? Don't know without seeing the patch. What's the patch subject so I can find it? I talked to Olof on irc. I sent patches 2 and 3 to the patch tracker as http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8112/1 and http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8113/1 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC
On 22/07/14 03:04, Chanwoo Choi wrote:
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
Acked-by: Arnd Bergmann a...@arndb.de
Applied to the togreg branch of iio.git - initially pushed out as testing.
Thanks
Jonathan
---
arch/arm/boot/dts/exynos3250.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 15c9c87..767189a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -407,10 +407,11 @@
};
adc: adc@126C {
- compatible = samsung,exynos-adc-v3;
+ compatible = samsung,exynos3250-adc,
+samsung,exynos-adc-v2;
reg = 0x126C 0x100, 0x10020718 0x4;
interrupts = 0 137 0;
- clock-names = adc, sclk_tsadc;
+ clock-names = adc, sclk;
clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
#io-channel-cells = 1;
io-channel-ranges;
--
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 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
Quoting Krzysztof Kozlowski (2014-07-18 07:36:32)
Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of
ARMCLK will be reduced upon entering idle mode (WFI or WFE).
The feature behaves like very fast cpufreq ondemand governor. In idle
mode this reduces energy consumption on full frequency chosen by
cpufreq governor by approximately:
- Trats2: 6.5% (153 mA - 143 mA)
- Trats: 33.0% (180 mA - 120 mA)
- Gear1: 27.0% (180 mA - 130 mA)
Nice power savings! Just a quick question on this feature: the clock
frequency is changed in hardware as a result of WFI/WFE? And this only
happens when all CPUs in a cluster (e.g. all 4 CPUs in Exynos 4412) are
in WFI/WFE state?
Thanks,
Mike
The patch uses simillar settings as Exynos5250 (clk-exynos5250.c),
except it disables clock up feature and on Exynos4412 ARMCLK down is
enabled for all 4 cores.
Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and
Samsung Gear 1 (Exynos4212).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
1. Add PWR_CTRL registers to the list of saved clk registers on
Exynos4x12. Suggested by Tomasz Figa.
2. Disable the clock up feature. (sug. Tomasz Figa)
3. Use macros for setting clock down ratio. (sug. Tomasz Figa)
4. Use num_possible_cpus() for exception on Exynos4x12. (sug. Tomasz
Figa)
5. Enable the clock down feature also on Exynos4210 Trats board.
---
drivers/clk/samsung/clk-exynos4.c | 46
+++
1 file changed, 46 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 7f4a473a7ad7..86c7709dc6d6 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -114,11 +114,27 @@
#define DIV_CPU1 0x14504
#define GATE_SCLK_CPU 0x14800
#define GATE_IP_CPU0x14900
+#define PWR_CTRL1 0x15020
+#define E4X12_PWR_CTRL20x15024
#define E4X12_DIV_ISP0 0x18300
#define E4X12_DIV_ISP1 0x18304
#define E4X12_GATE_ISP00x18800
#define E4X12_GATE_ISP10x18804
+/* Below definitions are used for PWR_CTRL settings */
+#define PWR_CTRL1_CORE2_DOWN_RATIO(x) (((x) 0x7) 28)
+#define PWR_CTRL1_CORE1_DOWN_RATIO(x) (((x) 0x7) 16)
+#define PWR_CTRL1_DIV2_DOWN_EN (1 9)
+#define PWR_CTRL1_DIV1_DOWN_EN (1 8)
+#define PWR_CTRL1_USE_CORE3_WFE(1 7)
+#define PWR_CTRL1_USE_CORE2_WFE(1 6)
+#define PWR_CTRL1_USE_CORE1_WFE(1 5)
+#define PWR_CTRL1_USE_CORE0_WFE(1 4)
+#define PWR_CTRL1_USE_CORE3_WFI(1 3)
+#define PWR_CTRL1_USE_CORE2_WFI(1 2)
+#define PWR_CTRL1_USE_CORE1_WFI(1 1)
+#define PWR_CTRL1_USE_CORE0_WFI(1 0)
+
/* the exynos4 soc type */
enum exynos4_soc {
EXYNOS4210,
@@ -155,6 +171,7 @@ static unsigned long exynos4210_clk_save[] __initdata = {
E4210_GATE_IP_LCD1,
E4210_GATE_IP_PERIR,
E4210_MPLL_CON0,
+ PWR_CTRL1,
};
static unsigned long exynos4x12_clk_save[] __initdata = {
@@ -164,6 +181,8 @@ static unsigned long exynos4x12_clk_save[] __initdata = {
E4X12_DIV_ISP,
E4X12_DIV_CAM1,
E4X12_MPLL_CON0,
+ PWR_CTRL1,
+ E4X12_PWR_CTRL2,
};
static unsigned long exynos4_clk_pll_regs[] __initdata = {
@@ -1164,6 +1183,32 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static void __init exynos4_core_down_clock(enum exynos4_soc soc)
+{
+ unsigned int tmp;
+
+ /*
+* Enable arm clock down (in idle) and set arm divider
+* ratios in WFI/WFE state.
+*/
+ tmp = (PWR_CTRL1_CORE2_DOWN_RATIO(7) | PWR_CTRL1_CORE1_DOWN_RATIO(7) |
+ PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
+ PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
+ PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
+ /* On Exynos4412 enable it also on core 2 and 3 */
+ if (num_possible_cpus() == 4)
+ tmp |= PWR_CTRL1_USE_CORE3_WFE | PWR_CTRL1_USE_CORE2_WFE |
+ PWR_CTRL1_USE_CORE3_WFI | PWR_CTRL1_USE_CORE2_WFI;
+ __raw_writel(tmp, reg_base + PWR_CTRL1);
+
+ /*
+* Disable the clock up feature on Exynos4x12, in case it was
+* enabled by bootloader.
+*/
+ if (exynos4_soc == EXYNOS4X12)
+ __raw_writel(0x0, reg_base + E4X12_PWR_CTRL2);
+}
+
/* register exynos4 clocks */
static void __init exynos4_clk_init(struct device_node *np,
enum exynos4_soc soc)
@@ -1250,6 +1295,7 @@ static void
