[PATCH] ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
There are two PMICs on Cragganmore, currently one dynamically assign
its IRQ base and the other uses a fixed base. It is possible for the
statically assigned PMIC to fail if its IRQ is taken by the dynamically
assigned one. Fix this by statically assigning both the IRQ bases.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
arch/arm/mach-s3c64xx/crag6410.h |1 +
arch/arm/mach-s3c64xx/mach-crag6410.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/crag6410.h b/arch/arm/mach-s3c64xx/crag6410.h
index 7bc6668..dcbe17f 100644
--- a/arch/arm/mach-s3c64xx/crag6410.h
+++ b/arch/arm/mach-s3c64xx/crag6410.h
@@ -14,6 +14,7 @@
#include mach/gpio-samsung.h
#define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START
+#define BANFF_PMIC_IRQ_BASE(IRQ_BOARD_START + 64)
#define PCA935X_GPIO_BASE GPIO_BOARD_START
#define CODEC_GPIO_BASE(GPIO_BOARD_START + 8)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 10b913b..65c426b 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -554,6 +554,7 @@ static struct wm831x_touch_pdata touch_pdata = {
static struct wm831x_pdata crag_pmic_pdata = {
.wm831x_num = 1,
+ .irq_base = BANFF_PMIC_IRQ_BASE,
.gpio_base = BANFF_PMIC_GPIO_BASE,
.soft_shutdown = true,
--
1.7.2.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/5] tests/exynos: add fimg2d performance analysis
Hello Emil, Emil Velikov wrote: Might I suggest that we treat this (and your follow up utility) as a test ? I.e. use if HAVE_INSTALL_TESTS bin_PROGRAMS = \ exynos_fimg2d_perf else noinst_PROGRAMS = \ exynos_fimg2d_perf endif and amend the block below appropriately ? sure, honestly I don't even remember why I didn't add these as tests? *confused* Can you add a licence to this file. Would be nice if it's covered by X/MIT so that *BSD folk and others can use your tool. Will do! Even though I probably won't go with a MIT license. I'm suspecting that having this as a runtime option will be better. Something like ./exynos_fimg2d_perf --output mathematica ? Well, I was thinking about removing the Mathematica specific code for the submission, but I then left it in. I use Mathematica for parts of my thesis, so it's usually my preferred tool to visualize data. I guess a more 'open-source' friendly solution here would be to provide GnuPlot output, but I guess I leave that to another use :) As a general note I would recommend keeping statements on separate lines (none of if (foo) far()) as it makes debugging easier. OK, changing this. With best wishes, 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
Re: [PATCH 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
On 20/03/15 22:25, Tobias Jakobi wrote: This event is specific to Exynos G2D DRM driver. Only process it when Exynos support is enabled. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- exynos/exynos_drm.h | 12 xf86drm.h | 7 ++- xf86drmMode.c | 18 ++ 3 files changed, 36 insertions(+), 1 deletion(-) I fear we are not (yet) allowed to do either of these changes. The exynos/exynos_drm.h header is (supposed to) be in sync/come from the kernel. And changes here are to be reflected only when the corresponding patch lands in drm-next (as per RELEASING). Wrt extending the current drmEventContext, I'm not sure that adding device specific changes to it are allowed. Wish I would give you some better news but... I cannot sorry :-\ -Emil -- 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] tests/exynos: add fimg2d performance analysis
On 20/03/15 22:25, Tobias Jakobi wrote:
Currently only fast solid color clear performance is measured.
A large buffer is allocated and solid color clear operations
are executed on it with randomly chosen properties (position
and size of the region, clear color). Execution time is
measured and output together with the amount of pixels
processed.
The 'simple' variant only executes one G2D command buffer at
a time, while the 'multi' variant executes multiple ones. This
can be used to measure setup/exec overhead.
The test also serves a stability check. If clocks/voltages are
too high or low respectively, the test quickly reveals this.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Hi Tobias,
As most of this series is quite Exynos specific I will cover the misc
bits, and leave the core part to someone familiar with the hardware.
---
tests/exynos/Makefile.am | 8 +-
tests/exynos/exynos_fimg2d_perf.c | 245
++
2 files changed, 252 insertions(+), 1 deletion(-)
create mode 100644 tests/exynos/exynos_fimg2d_perf.c
diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index b21d016..243f957 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -5,9 +5,11 @@ AM_CFLAGS = \
-I $(top_srcdir)/exynos \
-I $(top_srcdir)
+bin_PROGRAMS = exynos_fimg2d_perf
+
Might I suggest that we treat this (and your follow up utility) as a
test ? I.e. use
if HAVE_INSTALL_TESTS
bin_PROGRAMS = \
exynos_fimg2d_perf
else
noinst_PROGRAMS = \
exynos_fimg2d_perf
endif
and amend the block below appropriately ?
if HAVE_LIBKMS
if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
+bin_PROGRAMS += \
exynos_fimg2d_test
else
noinst_PROGRAMS = \
@@ -15,6 +17,10 @@ noinst_PROGRAMS = \
endif
endif
+exynos_fimg2d_perf_LDADD = \
+ $(top_builddir)/libdrm.la \
+ $(top_builddir)/exynos/libdrm_exynos.la
+
exynos_fimg2d_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/libkms/libkms.la \
diff --git a/tests/exynos/exynos_fimg2d_perf.c
b/tests/exynos/exynos_fimg2d_perf.c
new file mode 100644
index 000..f45cacc
--- /dev/null
+++ b/tests/exynos/exynos_fimg2d_perf.c
@@ -0,0 +1,245 @@
Can you add a licence to this file. Would be nice if it's covered by
X/MIT so that *BSD folk and others can use your tool.
+#include stdlib.h
+#include stdio.h
+#include time.h
+
+#include xf86drm.h
+
+#include exynos_drm.h
+#include exynos_drmif.h
+#include exynos_fimg2d.h
+
+/* Enable to format the output so that it can be fed into Mathematica. */
+#define OUTPUT_MATHEMATICA 0
+
+static int fimg2d_perf_simple(struct exynos_bo *bo, struct g2d_context *ctx,
+ unsigned buf_width, unsigned buf_height, unsigned
iterations)
+{
+ struct timespec tspec = { 0 };
+ struct g2d_image img = { 0 };
+
+ unsigned long long g2d_time;
+ unsigned i;
+ int ret = 0;
+
+ img.width = buf_width;
+ img.height = buf_height;
+ img.stride = buf_width * 4;
+ img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+ img.buf_type = G2D_IMGBUF_GEM;
+ img.bo[0] = bo-handle;
+
+ srand(time(NULL));
+
+ printf(starting simple G2D performance test\n);
+ printf(buffer width = %u, buffer height = %u, iterations = %u\n,
+ buf_width, buf_height, iterations);
+
+#if (OUTPUT_MATHEMATICA == 1)
+ putchar('{');
+#endif
+
I'm suspecting that having this as a runtime option will be better.
Something like ./exynos_fimg2d_perf --output mathematica ?
As a general note I would recommend keeping statements on separate lines
(none of if (foo) far()) as it makes debugging easier.
Although all of the above are my take on things, so checks with the
Exynos crew if they feel otherwise :-)
Cheers,
Emil
--
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 2/5] exynos: add EXYNOS_G2D_EVENT to drmHandleEvent
Hello Emil, Emil Velikov wrote: I fear we are not (yet) allowed to do either of these changes. The exynos/exynos_drm.h header is (supposed to) be in sync/come from the kernel. And changes here are to be reflected only when the corresponding patch lands in drm-next (as per RELEASING). the point here is, that the current header in libdrm in _not_ in sync with the one in the kernel. It's hopelessly outdated, but mainly because exynos/libdrm doesn't use any new functionality provided by some update. Here's the current kernel header: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/drm/exynos_drm.h The event stuff has been there since 2012: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/drm/exynos_drm.h?id=d7f1642c90ab5eb2d7c48af0581c993094f97e1a The only reason why I haven't added the IPP things, is because I don't intend to work on this for the moment. Wrt extending the current drmEventContext, I'm not sure that adding device specific changes to it are allowed. Why shouldn't it? Isn't drmHandleEvent supposed to handle all kinds of DRM events that the kernel produces? With best wishes, 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
Re: [PATCH] ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
On Sun, Mar 22, 2015 at 10:40:41AM +, Charles Keepax wrote: There are two PMICs on Cragganmore, currently one dynamically assign its IRQ base and the other uses a fixed base. It is possible for the statically assigned PMIC to fail if its IRQ is taken by the dynamically assigned one. Fix this by statically assigning both the IRQ bases. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com Reviwed-by: Mark Brown broo...@kernel.org This probably wants to go to stable as well. signature.asc Description: Digital signature
