Re: [PATCH v10 00/17] drm/exynos: atomic modesetting support
Hello, On 2015-06-01 17:04, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. Thanks for this patchses, however I've noticed a problem after applying them. The issue gets revealed when support for IOMMU is enabled. I've did my tests with Exynos HDMI driver on Odroid U3 board. To demonstrated the issue I've added following additional debug in the exynos mixer driver in mixer_graph_buffer() function: pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n, plane-dma_addr[0], plane-src_width, plane-src_height); Before applying patches setting 640x480 mode and getting back to 1920x1080 console generates following log: # modetest -M exynos -s 23:640x480 setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21 [ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 After applying atomic modesetting patchset: # modetest -M exynos -s 24:640x480 [ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22 [ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height 1080 [ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 As you can see from the above log, mixer_graph_buffer function is called several times. 0xbbd0 is the DMA address of the 1920x1080 framebuffer and 0xbc50 is the DMA address of the allocated 640x480 buffer. mixer_graph_buffer() is first called with the new DMA address of the framebuffer, but with the old mode parameters (1920x1080 size) and then in the next call it updates the plane parameters to the correct values (size changed to 640x480). When IOMMU is not used, this can be easily missed, but after enabling IOMMU support, any DMA access to unallocated address causes IOMMU PAGE FAULT. Here it will happen after changing DMA address of the buffer without changing the size. A quick workaround to resolve this multiple calls to mixer_graph_buffer() with partially updated mode values is to remove calls to mixer_window_suspend/mixer_window_resume from mixer_disable and mixer_disable functions, but I expect that this is not the right approach. Probably the same problem can be observed with Exynos FIMD driver. Gustavo: could you check if mixer_enable functions should really call mixer_window_resume function, which in turn calls mixer_win_commit, which calls mixer_graph_buffer with partially updated display buffer data? (...) Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/17] drm/exynos: atomic modesetting support
Hi Marek,
On 2015년 06월 10일 19:03, Marek Szyprowski wrote:
Hello,
On 2015-06-01 17:04, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
Thanks for this patchses, however I've noticed a problem after applying
them.
The issue gets revealed when support for IOMMU is enabled. I've did my
tests
with Exynos HDMI driver on Odroid U3 board.
To demonstrated the issue I've added following additional debug in the
exynos
mixer driver in mixer_graph_buffer() function:
pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n,
plane-dma_addr[0], plane-src_width, plane-src_height);
Before applying patches setting 640x480 mode and getting back to 1920x1080
console generates following log:
# modetest -M exynos -s 23:640x480
setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21
[ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
[ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
After applying atomic modesetting patchset:
# modetest -M exynos -s 24:640x480
[ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
[ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22
[ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height 1080
[ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
As you can see from the above log, mixer_graph_buffer function is called
several times. 0xbbd0 is the DMA address of the 1920x1080 framebuffer
and 0xbc50 is the DMA address of the allocated 640x480 buffer.
mixer_graph_buffer() is first called with the new DMA address of the
framebuffer, but with the old mode parameters (1920x1080 size) and then
in the next call it updates the plane parameters to the correct values
(size changed to 640x480). When IOMMU is not used, this can be easily
missed, but after enabling IOMMU support, any DMA access to unallocated
address causes IOMMU PAGE FAULT. Here it will happen after changing DMA
address of the buffer without changing the size.
A quick workaround to resolve this multiple calls to mixer_graph_buffer()
with partially updated mode values is to remove calls to
mixer_window_suspend/mixer_window_resume from mixer_disable and
mixer_disable functions, but I expect that this is not the right
approach.
Probably the same problem can be observed with Exynos FIMD driver.
Gustavo: could you check if mixer_enable functions should really
call mixer_window_resume function, which in turn calls mixer_win_commit,
which calls mixer_graph_buffer with partially updated display buffer
data?
Marek, can you share how other people can test the atomic feature with
iommu?
I should have merged below several patches and added device tree
relevant codes to test iommu.
1. Merged iommu support patches for Exynos SoC below iommu exynos tree,
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/exynos
2. Merged below patch,
[PATCH v7 24/25] ARM: DMA-mapping: add
support for creating reserved mappings in iova space
3. Added device node relevant codes - I tested Exynos drm on trats2
board based on Exynos4412 SoC - like below,
in exynos4.dtsi file:
fimd: fimd@11c0 {
...
iommus = sysmmu_fimd0;
...
sysmmu_fimd0: sysmmu@11E2 {
compatible = samsung,exynos-sysmmu;
reg = 0x11E2 0x1000;
interrupt-parent = combiner;
interrupts = 5 2;
clock-names = sysmmu, master;
clocks = clock CLK_SMMU_FIMD0, clock CLK_FIMD0;
power-domains = pd_lcd0;
#iommu-cells = 0;
};
in exynos4412-trats2.dts file:
fimd@11c0 {
status = okay;
iommu-reserved-mapping = 0x4000 0x4000 0x4000;
};
Is that all? You would need to share exact guide about iommu enabling to
other people so that they can test atomic feature with iommu.
Thanks,
Inki Dae
(...)
Best regards
--
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 v10 00/17] drm/exynos: atomic modesetting support
Hello,
On 2015-06-10 12:59, Inki Dae wrote:
Hi Marek,
On 2015년 06월 10일 19:03, Marek Szyprowski wrote:
Hello,
On 2015-06-01 17:04, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
Thanks for this patchses, however I've noticed a problem after applying
them.
The issue gets revealed when support for IOMMU is enabled. I've did my
tests
with Exynos HDMI driver on Odroid U3 board.
To demonstrated the issue I've added following additional debug in the
exynos
mixer driver in mixer_graph_buffer() function:
pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n,
plane-dma_addr[0], plane-src_width, plane-src_height);
Before applying patches setting 640x480 mode and getting back to 1920x1080
console generates following log:
# modetest -M exynos -s 23:640x480
setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21
[ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
[ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
After applying atomic modesetting patchset:
# modetest -M exynos -s 24:640x480
[ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
[ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22
[ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height 1080
[ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080
As you can see from the above log, mixer_graph_buffer function is called
several times. 0xbbd0 is the DMA address of the 1920x1080 framebuffer
and 0xbc50 is the DMA address of the allocated 640x480 buffer.
mixer_graph_buffer() is first called with the new DMA address of the
framebuffer, but with the old mode parameters (1920x1080 size) and then
in the next call it updates the plane parameters to the correct values
(size changed to 640x480). When IOMMU is not used, this can be easily
missed, but after enabling IOMMU support, any DMA access to unallocated
address causes IOMMU PAGE FAULT. Here it will happen after changing DMA
address of the buffer without changing the size.
A quick workaround to resolve this multiple calls to mixer_graph_buffer()
with partially updated mode values is to remove calls to
mixer_window_suspend/mixer_window_resume from mixer_disable and
mixer_disable functions, but I expect that this is not the right
approach.
Probably the same problem can be observed with Exynos FIMD driver.
Gustavo: could you check if mixer_enable functions should really
call mixer_window_resume function, which in turn calls mixer_win_commit,
which calls mixer_graph_buffer with partially updated display buffer
data?
Marek, can you share how other people can test the atomic feature with
iommu?
I should have merged below several patches and added device tree
relevant codes to test iommu.
1. Merged iommu support patches for Exynos SoC below iommu exynos tree,
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/exynos
2. Merged below patch,
[PATCH v7 24/25] ARM: DMA-mapping: add
support for creating reserved mappings in iova space
3. Added device node relevant codes - I tested Exynos drm on trats2
board based on Exynos4412 SoC - like below,
in exynos4.dtsi file:
fimd: fimd@11c0 {
...
iommus = sysmmu_fimd0;
...
sysmmu_fimd0: sysmmu@11E2 {
compatible = samsung,exynos-sysmmu;
reg = 0x11E2 0x1000;
interrupt-parent = combiner;
interrupts = 5 2;
clock-names = sysmmu, master;
clocks = clock CLK_SMMU_FIMD0, clock CLK_FIMD0;
power-domains = pd_lcd0;
#iommu-cells = 0;
};
in exynos4412-trats2.dts file:
fimd@11c0 {
status = okay;
iommu-reserved-mapping = 0x4000 0x4000 0x4000;
};
Is that all? You would need to share exact guide about iommu enabling to
other people so that they can test atomic feature with iommu.
Right, the above should be enough. For convenience I've prepared a
branch with all needed patches:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git
v4.1-exynos-drm-iommu
I've included following branches:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm/for-next
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=v4.2-next/dt-samsung-4th
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=v4.2-next/mach-samsung
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/exynos
Then I've applied my Exynos DRM patches
(http://www.spinics.net/lists/linux-samsung-soc/msg45114.html)
as well as
Re: [PATCH 00/21] On-demand device registration
On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote: This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get - of_platform_device_ensure - probe() on the platform device that encloses the requested device node (i2c host) - i2c slave gets probed and the regulator registered - regulator_get returns the requested resource The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. Deepest respect for your efforts! Thanks! Tomeu Yours, Linus Walleij ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: [RFT v2 06/48] pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
2015-06-04 6:13 GMT+02:00 Jiang Liu jiang@linux.intel.com: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org --- [...] drivers/pinctrl/mediatek/pinctrl-mtk-common.c |4 ++-- For the changes in pinctrl-mtk-common.c: Acked-by: Matthias Brugger matthias.brug...@gmail.com -- 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 9/9] drm/exynos: unify exynos_drm_plane names with drm core
Hi Gustavo,
On 2015년 06월 09일 23:27, Gustavo Padovan wrote:
Hi Inki and Joonyoung,
Any comments on this series?
As you may know, I'm reviewing and testing iommu support patch series
posted by Marek. With the patch series, I faced with page fault issue
while booting like below,
[1.161282] [drm] Initialized drm 1.1.0 20060810
[1.168972] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
vidi_component_ops)
[1.178462] [ cut here ]
[1.181610] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1718
drm_handle_vblank+0x2a0/0x308()
[1.190710] Modules linked in:
[1.193754] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-00564-g9acf8e2-dirty #1385
[1.201995] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.208094] [c0015388] (unwind_backtrace) from [c0012440]
(show_stack+0x10/0x14)
[1.215810] [c0012440] (show_stack) from [c04a35b8]
(dump_stack+0x84/0xc4)
[1.223014] [c04a35b8] (dump_stack) from [c00245cc]
(warn_slowpath_common+0x80/0xb0)
[1.223059] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.223403] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.223408] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.223411] [drm] No driver support for vblank timestamp query.
[1.223455] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[1.264427] [c00245cc] (warn_slowpath_common) from [c0024698]
(warn_slowpath_null+0x1c/0x24)
[1.273184] [c0024698] (warn_slowpath_null) from [c027c394]
(drm_handle_vblank+0x2a0/0x308)
[1.281872] [c027c394] (drm_handle_vblank) from [c0298964]
(fimd_irq_handler+0x78/0xcc)
[1.290201] [c0298964] (fimd_irq_handler) from [c0060708]
(handle_irq_event_percpu+0x78/0x134)
[1.299134] [c0060708] (handle_irq_event_percpu) from [c0060800]
(handle_irq_event+0x3c/0x5c)
[1.307994] [c0060800] (handle_irq_event) from [c00634a8]
(handle_level_irq+0xc4/0x13c)
[1.308007] [c00634a8] (handle_level_irq) from [c005fd8c]
(generic_handle_irq+0x2c/0x3c)
[1.308021] [c005fd8c] (generic_handle_irq) from [c02010cc]
(combiner_handle_cascade_irq+0x94/0x100)
[1.308032] [c02010cc] (combiner_handle_cascade_irq) from
[c005fd8c] (generic_handle_irq+0x2c/0x3c)
[1.308042] [c005fd8c] (generic_handle_irq) from [c0060058]
(__handle_domain_irq+0x7c/0xec)
[1.308052] [c0060058] (__handle_domain_irq) from [c0009434]
(gic_handle_irq+0x30/0x68)
[1.308060] [c0009434] (gic_handle_irq) from [c0012f40]
(__irq_svc+0x40/0x74)
[1.308065] Exception stack(0xc06dbf68 to 0xc06dbfb0)
[1.308072] bf60: 1298
c001cc80 c06da000 c06dc4f8
[1.308080] bf80: c04abf50 c06d62c4 c06dbfb8 c070c121 0001
0100 c06dbfb0
[1.308085] bfa0: c0010064 c0010068 6113
[1.308099] [c0012f40] (__irq_svc) from [c0010068]
(arch_cpu_idle+0x38/0x3c)
[1.308113] [c0010068] (arch_cpu_idle) from [c0054358]
(cpu_startup_entry+0x12c/0x1c4)
[1.308129] [c0054358] (cpu_startup_entry) from [c0688c54]
(start_kernel+0x398/0x3a4)
[1.308140] [c0688c54] (start_kernel) from [4000807c] (0x4000807c)
[1.308157] ---[ end trace 489a69b2a98f6c1d ]---
[1.341264] random: nonblocking pool is initialized
[4.235177] panel_s6e8aa0 11c8.dsi.0: ID: 0xa2, 0x60, 0x90
[4.436180] Console: switching to colour frame buffer device 102x91
[4.592094] exynos-drm exynos-drm: fb0: frame buffer device
[4.597734] exynos-drm exynos-drm: registered panic notifier
Enabling IOMMU makes DMA device more sensitive so it seems that hided
issues happen with iommu support. In this time, let's have more reviews.
Look like that now atomic features aren't safe yet.
Thanks,
Inki Dae
2015-06-03 Gustavo Padovan gust...@padovan.org:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 16
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +++---
5 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7a99237..4e63a9c 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -442,25 +442,25 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
DRM_DEBUG_KMS(start addr = 0x%lx\n,
(unsigned long)val);
DRM_DEBUG_KMS(ovl_width = %d, ovl_height = %d\n,
-plane-crtc_width, plane-crtc_height);
+
Re: [PATCH 9/9] drm/exynos: unify exynos_drm_plane names with drm core
On 2015년 06월 10일 19:42, Inki Dae wrote: Hi Gustavo, On 2015년 06월 09일 23:27, Gustavo Padovan wrote: Hi Inki and Joonyoung, Any comments on this series? As you may know, I'm reviewing and testing iommu support patch series posted by Marek. With the patch series, I faced with page fault issue while booting like below, [1.161282] [drm] Initialized drm 1.1.0 20060810 [1.168972] exynos-drm exynos-drm: bound exynos-drm-vidi (ops vidi_component_ops) [1.178462] [ cut here ] [1.181610] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1718 drm_handle_vblank+0x2a0/0x308() [1.190710] Modules linked in: [1.193754] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-00564-g9acf8e2-dirty #1385 [1.201995] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [1.208094] [c0015388] (unwind_backtrace) from [c0012440] (show_stack+0x10/0x14) [1.215810] [c0012440] (show_stack) from [c04a35b8] (dump_stack+0x84/0xc4) [1.223014] [c04a35b8] (dump_stack) from [c00245cc] (warn_slowpath_common+0x80/0xb0) [1.223059] exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) [1.223403] exynos-drm exynos-drm: bound 11c8.dsi (ops exynos_dsi_component_ops) [1.223408] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.223411] [drm] No driver support for vblank timestamp query. [1.223455] [drm] Initialized exynos 1.0.0 20110530 on minor 0 [1.264427] [c00245cc] (warn_slowpath_common) from [c0024698] (warn_slowpath_null+0x1c/0x24) [1.273184] [c0024698] (warn_slowpath_null) from [c027c394] (drm_handle_vblank+0x2a0/0x308) [1.281872] [c027c394] (drm_handle_vblank) from [c0298964] (fimd_irq_handler+0x78/0xcc) [1.290201] [c0298964] (fimd_irq_handler) from [c0060708] (handle_irq_event_percpu+0x78/0x134) [1.299134] [c0060708] (handle_irq_event_percpu) from [c0060800] (handle_irq_event+0x3c/0x5c) [1.307994] [c0060800] (handle_irq_event) from [c00634a8] (handle_level_irq+0xc4/0x13c) [1.308007] [c00634a8] (handle_level_irq) from [c005fd8c] (generic_handle_irq+0x2c/0x3c) [1.308021] [c005fd8c] (generic_handle_irq) from [c02010cc] (combiner_handle_cascade_irq+0x94/0x100) [1.308032] [c02010cc] (combiner_handle_cascade_irq) from [c005fd8c] (generic_handle_irq+0x2c/0x3c) [1.308042] [c005fd8c] (generic_handle_irq) from [c0060058] (__handle_domain_irq+0x7c/0xec) [1.308052] [c0060058] (__handle_domain_irq) from [c0009434] (gic_handle_irq+0x30/0x68) [1.308060] [c0009434] (gic_handle_irq) from [c0012f40] (__irq_svc+0x40/0x74) [1.308065] Exception stack(0xc06dbf68 to 0xc06dbfb0) [1.308072] bf60: 1298 c001cc80 c06da000 c06dc4f8 [1.308080] bf80: c04abf50 c06d62c4 c06dbfb8 c070c121 0001 0100 c06dbfb0 [1.308085] bfa0: c0010064 c0010068 6113 [1.308099] [c0012f40] (__irq_svc) from [c0010068] (arch_cpu_idle+0x38/0x3c) [1.308113] [c0010068] (arch_cpu_idle) from [c0054358] (cpu_startup_entry+0x12c/0x1c4) [1.308129] [c0054358] (cpu_startup_entry) from [c0688c54] (start_kernel+0x398/0x3a4) [1.308140] [c0688c54] (start_kernel) from [4000807c] (0x4000807c) [1.308157] ---[ end trace 489a69b2a98f6c1d ]--- [1.341264] random: nonblocking pool is initialized [4.235177] panel_s6e8aa0 11c8.dsi.0: ID: 0xa2, 0x60, 0x90 [4.436180] Console: switching to colour frame buffer device 102x91 [4.592094] exynos-drm exynos-drm: fb0: frame buffer device [4.597734] exynos-drm exynos-drm: registered panic notifier Oops, sorry. My mistake. Above log is warning message happened while booting. See the below log, page fault issue which happened when modetest is released. # modetest -s 31@29:720x1280 trying to open device 'i915'...failed. trying to open device 'radeon'...failed. trying to open device 'nouveau'...failed. trying to open device 'vmwgfx'...failed. trying to open device 'omapdrm'...failed. trying to open device 'exynos'...success. setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29 [ 37.782766] PAGE FAULT occurred at 0x2055d200 by 11e2.sysmmu(Page table base: 0x6ebe) [ 37.789807] Lv1 entry: 0x6e92dc01 [ 37.793225] [ cut here ] [ 37.797793] kernel BUG at drivers/iommu/exynos-iommu.c:364! [ 37.803349] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 37.809163] Modules linked in: [ 37.812207] CPU: 0 PID: 1475 Comm: modetest Tainted: GW 4.1.0-rc4-00564-g9acf8e2-dirty #1385 [ 37.821836] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 37.827914] task: ee3c9100 ti: ee342000 task.ti: ee342000 [ 37.833304] PC is at exynos_sysmmu_irq+0x184/0x208 [ 37.838070] LR is at exynos_sysmmu_irq+0xd4/0x208 [ 37.842758] pc : [c0267bcc]lr : [c0267b1c]psr: 6193 [ 37.842758] sp : ee343cc8 ip : fp : [ 37.854214] r10: c070c123 r9 :
Re: [PATCH 00/21] On-demand device registration
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote: This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Deepest respect for your efforts! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] [media] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
From: Jan Kara j...@suse.cz
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..810e1ee7c07d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct page **pages;
- unsigned intnpages;
+ struct frame_vector *vec;
struct sg_table *sgt;
- struct vm_area_struct *vma;
atomic_trefcount;
boolin_pool;
boolout_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct page **pages;
if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr-sgt,
DMA_BIDIRECTIONAL);
- exynos_gem_put_pages_to_userptr(g2d_userptr-pages,
- g2d_userptr-npages,
- g2d_userptr-vma);
+ pages = frame_vector_pages(g2d_userptr-vec);
+ if (!IS_ERR(pages)) {
+ int i;
- exynos_gem_put_vma(g2d_userptr-vma);
+ for (i = 0; i frame_vector_count(g2d_userptr-vec); i++)
+ set_page_dirty_lock(pages[i]);
+ }
+ put_vaddr_frames(g2d_userptr-vec);
+ frame_vector_destroy(g2d_userptr-vec);
if (!g2d_userptr-out_of_list)
list_del_init(g2d_userptr-list);
sg_free_table(g2d_userptr-sgt);
kfree(g2d_userptr-sgt);
-
- drm_free_large(g2d_userptr-pages);
kfree(g2d_userptr);
}
@@ -408,9 +409,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
struct exynos_drm_g2d_private *g2d_priv = file_priv-g2d_priv;
struct g2d_cmdlist_userptr *g2d_userptr;
struct g2d_data *g2d;
- struct page **pages;
struct sg_table *sgt;
- struct vm_area_struct *vma;
unsigned long start, end;
unsigned int npages, offset;
int ret;
@@ -456,65 +455,38 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
atomic_set(g2d_userptr-refcount, 1);
+ g2d_userptr-size = size;
start = userptr PAGE_MASK;
offset = userptr ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) PAGE_SHIFT;
- g2d_userptr-npages = npages;
-
- pages = drm_calloc_large(npages, sizeof(struct page *));
- if (!pages) {
- DRM_ERROR(failed to allocate pages.\n);
- ret = -ENOMEM;
+ g2d_userptr-vec = frame_vector_create(npages);
+ if (!vec)
goto err_free;
- }
- down_read(current-mm-mmap_sem);
- vma = find_vma(current-mm, userptr);
- if (!vma) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(failed to get vm region.\n);
- ret = -EFAULT;
- goto err_free_pages;
- }
-
- if (vma-vm_end userptr + size) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(vma is too small.\n);
- ret = -EFAULT;
- goto err_free_pages;
- }
-
- g2d_userptr-vma = exynos_gem_get_vma(vma);
- if (!g2d_userptr-vma) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(failed to copy vma.\n);
- ret = -ENOMEM;
- goto err_free_pages;
- }
-
- g2d_userptr-size = size;
-
- ret = exynos_gem_get_pages_from_userptr(start PAGE_MASK,
- npages, pages, vma);
- if (ret 0) {
- up_read(current-mm-mmap_sem);
+ ret = get_vaddr_frames(start, npages, true, true, g2d_userptr-vec);
+ if (ret != npages) {
DRM_ERROR(failed to get user pages from userptr.\n);
- goto err_put_vma;
+ if (ret 0)
+ goto err_destroy_framevec;
+ ret = -EFAULT;
+ goto err_put_framevec;
+ }
+ if (frame_vector_to_pages(g2d_userptr-vec) 0) {
+ ret = -EFAULT;
+
[PATCH 9/9] [media] mm: Move get_vaddr_frames() behind a config option
From: Jan Kara j...@suse.cz
get_vaddr_frames() is used by relatively rare drivers so hide it and the
related functions behind a config option that is selected only by
drivers that need the infrastructure.
Suggested-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
create mode 100644 mm/frame_vector.c
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0a6780367d28..fc678289cf79 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI
config DRM_EXYNOS_G2D
bool Exynos DRM G2D
depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D
+ select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index dc2aaab54aef..217d613b0fe7 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT
select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB
+ select FRAME_VECTOR
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index f7a01a72eb9e..f38f6e387f04 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -73,6 +73,7 @@ config VIDEOBUF2_CORE
config VIDEOBUF2_MEMOPS
tristate
+ select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/mm/Kconfig b/mm/Kconfig
index 390214da4546..2ca52e9986f0 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB
changed to a smaller value in which case that is used.
A sane initial value is 80 MB.
+
+config FRAME_VECTOR
+ bool
diff --git a/mm/Makefile b/mm/Makefile
index 98c4eaeabdcb..be5d5c866305 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
new file mode 100644
index ..31a2bd5f41d5
--- /dev/null
+++ b/mm/frame_vector.c
@@ -0,0 +1,232 @@
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/sched.h
+
+/*
+ * get_vaddr_frames() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_frames: number of pages / pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. See description of the same argument of
+ get_user_pages().
+ * @vec: structure which receives pages / pfns of the addresses mapped.
+ * It should have space for at least nr_frames entries.
+ *
+ * This function maps virtual addresses from @start and fills @vec structure
+ * with page frame numbers or page pointers to corresponding pages (choice
+ * depends on the type of the vma underlying the virtual address). If @start
+ * belongs to a normal vma, the function grabs reference to each of the pages
+ * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't
+ * touch page structures and the caller must make sure pfns aren't reused for
+ * anything else while he is using them.
+ *
+ * The function returns number of pages mapped which may be less than
+ * @nr_frames. In particular we stop mapping if there are more vmas of
+ * different type underlying the specified range of virtual addresses.
+ * When the function isn't able to map a single page, it returns error.
+ *
+ * This function takes care of grabbing mmap_sem as necessary.
+ */
+int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
+bool write, bool force, struct frame_vector *vec)
+{
+ struct mm_struct *mm = current-mm;
+ struct vm_area_struct *vma;
+ int ret = 0;
+ int err;
+ int locked;
+
+ if (nr_frames == 0)
+ return 0;
+
+ if (WARN_ON_ONCE(nr_frames vec-nr_allocated))
+ nr_frames = vec-nr_allocated;
+
+ down_read(mm-mmap_sem);
+ locked = 1;
+ vma = find_vma_intersection(mm, start, start + 1);
+ if (!vma) {
+ ret = -EFAULT;
+ goto out;
+ }
+ if (!(vma-vm_flags (VM_IO | VM_PFNMAP))) {
+ vec-got_ref = true;
+ vec-is_pfns = false;
+ ret =
Re: [PATCH 9/9] drm/exynos: unify exynos_drm_plane names with drm core
On 06/09/2015 11:27 PM, Gustavo Padovan wrote:
Hi Inki and Joonyoung,
Any comments on this series?
I saw this series in brief and good mostly. I feel it can be better to
split a atomic patch and cleanup patches, it can make to merge easier.
It's problem to give late any feedback about patches posted, i will try
to review them but i have no time. Sorry about that again.
Thanks.
2015-06-03 Gustavo Padovan gust...@padovan.org:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 16
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +++---
5 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7a99237..4e63a9c 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -442,25 +442,25 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
DRM_DEBUG_KMS(start addr = 0x%lx\n,
(unsigned long)val);
DRM_DEBUG_KMS(ovl_width = %d, ovl_height = %d\n,
-plane-crtc_width, plane-crtc_height);
+plane-crtc_w, plane-crtc_h);
/*
* OSD position.
* In case the window layout goes of LCD layout, DECON fails.
*/
-if ((plane-crtc_x + plane-crtc_width) mode-hdisplay)
-plane-crtc_x = mode-hdisplay - plane-crtc_width;
-if ((plane-crtc_y + plane-crtc_height) mode-vdisplay)
-plane-crtc_y = mode-vdisplay - plane-crtc_height;
+if ((plane-crtc_x + plane-crtc_w) mode-hdisplay)
+plane-crtc_x = mode-hdisplay - plane-crtc_w;
+if ((plane-crtc_y + plane-crtc_h) mode-vdisplay)
+plane-crtc_y = mode-vdisplay - plane-crtc_h;
val = VIDOSDxA_TOPLEFT_X(plane-crtc_x) |
VIDOSDxA_TOPLEFT_Y(plane-crtc_y);
writel(val, ctx-regs + VIDOSD_A(win));
-last_x = plane-crtc_x + plane-crtc_width;
+last_x = plane-crtc_x + plane-crtc_w;
if (last_x)
last_x--;
-last_y = plane-crtc_y + plane-crtc_height;
+last_y = plane-crtc_y + plane-crtc_h;
if (last_y)
last_y--;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b83d487..7c6196e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -51,12 +51,12 @@ enum exynos_drm_output_type {
* - the unit is screen coordinates.
* @src_y: offset y on a framebuffer to be displayed.
* - the unit is screen coordinates.
- * @src_width: width of a partial image to be displayed from framebuffer.
- * @src_height: height of a partial image to be displayed from framebuffer.
+ * @src_w: width of a partial image to be displayed from framebuffer.
+ * @src_h: height of a partial image to be displayed from framebuffer.
* @crtc_x: offset x on hardware screen.
* @crtc_y: offset y on hardware screen.
- * @crtc_width: window width to be displayed (hardware screen).
- * @crtc_height: window height to be displayed (hardware screen).
+ * @crtc_w: window width to be displayed (hardware screen).
+ * @crtc_h: window height to be displayed (hardware screen).
* @h_ratio: horizontal scaling ratio, 16.16 fixed point
* @v_ratio: vertical scaling ratio, 16.16 fixed point
* @dma_addr: array of bus(accessed by dma) address to the memory region
@@ -73,12 +73,12 @@ struct exynos_drm_plane {
struct drm_plane base;
unsigned int src_x;
unsigned int src_y;
-unsigned int src_width;
-unsigned int src_height;
+unsigned int src_w;
+unsigned int src_h;
unsigned int crtc_x;
unsigned int crtc_y;
-unsigned int crtc_width;
-unsigned int crtc_height;
+unsigned int crtc_w;
+unsigned int crtc_h;
unsigned int h_ratio;
unsigned int v_ratio;
dma_addr_t dma_addr[MAX_FB_BUFFER];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2ece83b..920727b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -659,18 +659,18 @@ static void fimd_update_plane(struct exynos_drm_crtc
*crtc,
writel(val, ctx-regs + VIDWx_BUF_START(win, 0));
/* buffer end address */
-size = pitch * plane-crtc_height;
+size = pitch * plane-crtc_h;
val = (unsigned long)(dma_addr + size);
writel(val, ctx-regs + VIDWx_BUF_END(win, 0));
Re: [PATCH 00/21] On-demand device registration
On 06/10/2015 12:19 PM, Tomeu Vizoso wrote: On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote: This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get - of_platform_device_ensure - probe() on the platform device that encloses the requested device node (i2c host) - i2c slave gets probed and the regulator registered - regulator_get returns the requested resource The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree. The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, As I understand Greg you cannot prevent unbinding by design, see [1]. [1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus=1154648 or to automatically unbind the devices that depend on it, What about devices that have weak dependency? They should not be unbound but they should be somehow noticed about unbinding. In general many kernel frameworks are broken in handling hot-unbinding of drivers, consumers are not noticed about unbinding of their resource providers and usually they stay with broken handles or handles to dummy resources. I suspect the only proper solution for handling resources that can dynamically appear/disappear is to provide notification to their consumers about appearance change of the resource. I have proposed some times ago solution for above problems based on the statement above, cover letter explains it in more detail [2]. In short it solves following issues: - consumer receives resource as soon as it becomes available, - consumer is notified just before resource removal, - it can properly handle provider unbind/re-bind, - it avoids late init due to deferred probing, - it allows to track optional resources. [2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201 Regards Andrzej or to print a warning if a device is hotplugged off and other devices depend on it. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. Deepest respect for your efforts! Thanks! Tomeu Yours, Linus Walleij ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-gpio 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
[PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
The Exynos interrupt combiner IP looses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
I noticed this issue because after a S2R, IRQs for some devices didn't
trigger anymore but others continued working and all of them had lines
from a GPIO chip as their interrupt source.
The only difference was that the GPIO pins that were not working after
a resume, were the ones that had the interrupt combiner as interrupt
parent.
With this patch now all perhiperals are working correctly after a resume.
Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
Chromebooks.
Best regards,
Javier
drivers/irqchip/exynos-combiner.c | 61 +++
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..69c710641bfa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/slab.h
+#include linux/syscore_ops.h
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/interrupt.h
@@ -34,9 +35,14 @@ struct combiner_chip_data {
unsigned int irq_mask;
void __iomem *base;
unsigned int parent_irq;
+#ifdef CONFIG_PM
+ u32 pm_save;
+#endif
};
+static struct combiner_chip_data *combiner_data;
static struct irq_domain *combiner_irq_domain;
+static unsigned int max_nr = 20;
static inline void __iomem *combiner_base(struct irq_data *data)
{
@@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
};
static void __init combiner_init(void __iomem *combiner_base,
-struct device_node *np,
-unsigned int max_nr)
+struct device_node *np)
{
int i, irq;
unsigned int nr_irq;
- struct combiner_chip_data *combiner_data;
nr_irq = max_nr * IRQ_IN_COMBINER;
@@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
}
+#ifdef CONFIG_PM
+
+/**
+ * combiner_suspend - save interrupt combiner state before suspend
+ *
+ * Save the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state.
+ *
+ */
+static int combiner_suspend(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ combiner_data[i].pm_save =
+ __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET);
+
+ return 0;
+}
+
+/**
+ * combiner_resume - restore interrupt combiner state after resume
+ *
+ * Restore the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state on suspend.
+ *
+ */
+static void combiner_resume(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ __raw_writel(combiner_data[i].pm_save,
+combiner_data[i].base + COMBINER_ENABLE_SET);
+}
+
+#else
+#define combiner_suspend NULL
+#define combiner_resumeNULL
+#endif
+
+static struct syscore_ops combiner_syscore_ops = {
+ .suspend= combiner_suspend,
+ .resume = combiner_resume,
+};
+
static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
{
void __iomem *combiner_base;
- unsigned int max_nr = 20;
combiner_base = of_iomap(np, 0);
if (!combiner_base) {
@@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node *np,
__func__, max_nr);
}
- combiner_init(combiner_base, np, max_nr);
+ combiner_init(combiner_base, np);
+
+ register_syscore_ops(combiner_syscore_ops);
return 0;
}
--
2.1.4
--
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 v10 00/17] drm/exynos: atomic modesetting support
On 2015년 06월 10일 20:38, Marek Szyprowski wrote:
Hello,
On 2015-06-10 12:59, Inki Dae wrote:
Hi Marek,
On 2015년 06월 10일 19:03, Marek Szyprowski wrote:
Hello,
On 2015-06-01 17:04, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
Thanks for this patchses, however I've noticed a problem after applying
them.
The issue gets revealed when support for IOMMU is enabled. I've did my
tests
with Exynos HDMI driver on Odroid U3 board.
To demonstrated the issue I've added following additional debug in the
exynos
mixer driver in mixer_graph_buffer() function:
pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n,
plane-dma_addr[0], plane-src_width, plane-src_height);
Before applying patches setting 640x480 mode and getting back to
1920x1080
console generates following log:
# modetest -M exynos -s 23:640x480
setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21
[ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height
1080
[ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height
1080
After applying atomic modesetting patchset:
# modetest -M exynos -s 24:640x480
[ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height
1080
[ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height
1080
setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22
[ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height
1080
[ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480
^C
[ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height
1080
As you can see from the above log, mixer_graph_buffer function is called
several times. 0xbbd0 is the DMA address of the 1920x1080
framebuffer
and 0xbc50 is the DMA address of the allocated 640x480 buffer.
mixer_graph_buffer() is first called with the new DMA address of the
framebuffer, but with the old mode parameters (1920x1080 size) and then
in the next call it updates the plane parameters to the correct values
(size changed to 640x480). When IOMMU is not used, this can be easily
missed, but after enabling IOMMU support, any DMA access to unallocated
address causes IOMMU PAGE FAULT. Here it will happen after changing DMA
address of the buffer without changing the size.
A quick workaround to resolve this multiple calls to
mixer_graph_buffer()
with partially updated mode values is to remove calls to
mixer_window_suspend/mixer_window_resume from mixer_disable and
mixer_disable functions, but I expect that this is not the right
approach.
Probably the same problem can be observed with Exynos FIMD driver.
Gustavo: could you check if mixer_enable functions should really
call mixer_window_resume function, which in turn calls mixer_win_commit,
which calls mixer_graph_buffer with partially updated display buffer
data?
Marek, can you share how other people can test the atomic feature with
iommu?
I should have merged below several patches and added device tree
relevant codes to test iommu.
1. Merged iommu support patches for Exynos SoC below iommu exynos tree,
https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/exynos
2. Merged below patch,
[PATCH v7 24/25] ARM: DMA-mapping: add
support for creating reserved mappings in iova space
3. Added device node relevant codes - I tested Exynos drm on trats2
board based on Exynos4412 SoC - like below,
in exynos4.dtsi file:
fimd: fimd@11c0 {
...
iommus = sysmmu_fimd0;
...
sysmmu_fimd0: sysmmu@11E2 {
compatible = samsung,exynos-sysmmu;
reg = 0x11E2 0x1000;
interrupt-parent = combiner;
interrupts = 5 2;
clock-names = sysmmu, master;
clocks = clock CLK_SMMU_FIMD0, clock CLK_FIMD0;
power-domains = pd_lcd0;
#iommu-cells = 0;
};
in exynos4412-trats2.dts file:
fimd@11c0 {
status = okay;
iommu-reserved-mapping = 0x4000 0x4000
0x4000;
};
Is that all? You would need to share exact guide about iommu enabling to
other people so that they can test atomic feature with iommu.
Right, the above should be enough. For convenience I've prepared a
branch with all needed patches:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git
v4.1-exynos-drm-iommu
I've included following branches:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm/for-next
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=v4.2-next/dt-samsung-4th
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=v4.2-next/mach-samsung
Re: [PATCH 11/15] pinctrl: kill off set_irq_flags usage
On Tue, Jun 9, 2015 at 8:26 PM, Rob Herring r...@kernel.org wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also set IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring r...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Lee Jones l...@kernel.org Cc: Matthias Brugger matthias@gmail.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux-g...@vger.kernel.org Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT v2 44/48] genirq, pinctrl: Kill the first parameter 'irq' of irq_flow_handler_t
Am Donnerstag, 4. Juni 2015, 12:13:54 schrieb Jiang Liu: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/pinctrl/pinctrl-rockchip.c|2 +- For Rockchip Acked-by: Heiko Stuebner he...@sntech.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: [RFT v2 06/48] pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
Am Donnerstag, 4. Juni 2015, 12:13:16 schrieb Jiang Liu: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org --- drivers/pinctrl/pinctrl-rockchip.c|4 ++-- For Rockchip Acked-by: Heiko Stuebner he...@sntech.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: exynos4412: Audio dies after one day on kernel 4.0
2015-06-09 20:25 GMT+09:00 gabr...@unseen.is:
On 06/03/2015 02:05 AM, Krzysztof Kozlowski wrote:
On 03.06.2015 04:51, gabr...@unseen.is wrote:
On 05/31/2015 08:47 AM, Krzysztof Kozlowski wrote:
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
Thanks a lot Krzysztof,
I have reverted 88987d2c75 and aee4d1fac8 from 4.0.4 and I have still
audio working after 1 and 1/2 day. Unluckily the alsa error message
occured still once but they don't seem to be the issue here.
+CC Marek,
Robert, Marek, do you have any idea for the cause?
I can now say for sure that the commits 88987d2c75 and aee4d1fac8 are
the cause for the problem. Audio was working now for 7 days.
+CC Vinod
Gabriel,
I sent a patch which should fix the issue. Could you give it a try? Of
course don't revert the other patches and don't use other workarounds.
Just apply the patch on clean (vanilla would be the best) kernel.
[RFT PATCH] dmaengine: Fix choppy sound because of unimplemented resume
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 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
For unclear reasons my SoB was missing in my pull request. So add it now:
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
On 05/13/15 15:08, Jan Kara wrote:
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Signed-off-by: Jan Kara j...@suse.cz
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 89 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 97
-
2 files changed, 29 insertions(+), 157 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..265519c0fe2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct page **pages;
- unsigned intnpages;
+ struct frame_vector *vec;
struct sg_table *sgt;
- struct vm_area_struct *vma;
atomic_trefcount;
boolin_pool;
boolout_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct page **pages;
if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr-sgt,
DMA_BIDIRECTIONAL);
- exynos_gem_put_pages_to_userptr(g2d_userptr-pages,
- g2d_userptr-npages,
- g2d_userptr-vma);
+ pages = frame_vector_pages(g2d_userptr-vec);
+ if (!IS_ERR(pages)) {
+ int i;
- exynos_gem_put_vma(g2d_userptr-vma);
+ for (i = 0; i frame_vector_count(g2d_userptr-vec); i++)
+ set_page_dirty_lock(pages[i]);
+ }
+ put_vaddr_frames(g2d_userptr-vec);
+ frame_vector_destroy(g2d_userptr-vec);
if (!g2d_userptr-out_of_list)
list_del_init(g2d_userptr-list);
sg_free_table(g2d_userptr-sgt);
kfree(g2d_userptr-sgt);
-
- drm_free_large(g2d_userptr-pages);
kfree(g2d_userptr);
}
@@ -413,6 +414,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
struct vm_area_struct *vma;
unsigned long start, end;
unsigned int npages, offset;
+ struct frame_vector *vec;
int ret;
if (!size) {
@@ -456,65 +458,37 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
atomic_set(g2d_userptr-refcount, 1);
+ g2d_userptr-size = size;
start = userptr PAGE_MASK;
offset = userptr ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) PAGE_SHIFT;
- g2d_userptr-npages = npages;
-
- pages = drm_calloc_large(npages, sizeof(struct page *));
- if (!pages) {
- DRM_ERROR(failed to allocate pages.\n);
- ret = -ENOMEM;
+ vec = g2d_userptr-vec = frame_vector_create(npages);
+ if (!vec)
goto err_free;
- }
- down_read(current-mm-mmap_sem);
- vma = find_vma(current-mm, userptr);
- if (!vma) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(failed to get vm region.\n);
+ ret = get_vaddr_frames(start, npages, 1, 1, vec);
+ if (ret != npages) {
+ DRM_ERROR(failed to get user pages from userptr.\n);
+ if (ret 0)
+ goto err_destroy_framevec;
ret = -EFAULT;
- goto err_free_pages;
+ goto err_put_framevec;
}
-
- if (vma-vm_end userptr + size) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(vma is too small.\n);
+ if (frame_vector_to_pages(vec) 0) {
ret = -EFAULT;
- goto err_free_pages;
+ goto err_put_framevec;
}
- g2d_userptr-vma = exynos_gem_get_vma(vma);
- if (!g2d_userptr-vma) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(failed to copy vma.\n);
- ret = -ENOMEM;
- goto err_free_pages;
- }
-
- g2d_userptr-size = size;
-
- ret = exynos_gem_get_pages_from_userptr(start PAGE_MASK,
- npages, pages, vma);
- if (ret 0) {
- up_read(current-mm-mmap_sem);
- DRM_ERROR(failed to get
[PATCH v2 2/3] drm/exynos: fix broken component binding in case of multiple pipelines
In case there are multiple pipelines and deferred probe occurs, only components
of the first pipeline were bound. As a result only one pipeline was available.
The main cause of this issue was dynamic generation of component match table -
every component driver during probe registered itself on helper list, if there
was at least one pipeline present on this list component match table were
created without deferred components.
This patch removes this helper list, instead it creates match table from
existing devices requiring exynos_drm KMS drivers. This way match table do not
depend on probe/deferral order and contains all KMS components.
As a side effect patch makes the code cleaner and significantly smaller.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
v2:
- removed unused types (as pointed out by Gustavo) and variables,
- fixed two gotos to removed label in dsi driver.
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +-
drivers/gpu/drm/exynos/exynos_dp_core.c| 14 +-
drivers/gpu/drm/exynos/exynos_drm_dpi.c| 20 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c| 283 -
drivers/gpu/drm/exynos/exynos_drm_drv.h| 14 --
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 35 +---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 28 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 18 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 22 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
10 files changed, 101 insertions(+), 361 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..22cb067 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -769,11 +769,6 @@ static int decon_probe(struct platform_device *pdev)
if (!ctx)
return -ENOMEM;
- ret = exynos_drm_component_add(dev, EXYNOS_DEVICE_TYPE_CRTC,
- EXYNOS_DISPLAY_TYPE_LCD);
- if (ret)
- return ret;
-
ctx-dev = dev;
ctx-suspended = true;
@@ -783,10 +778,8 @@ static int decon_probe(struct platform_device *pdev)
of_node_put(i80_if_timings);
ctx-regs = of_iomap(dev-of_node, 0);
- if (!ctx-regs) {
- ret = -ENOMEM;
- goto err_del_component;
- }
+ if (!ctx-regs)
+ return -ENOMEM;
ctx-pclk = devm_clk_get(dev, pclk_decon0);
if (IS_ERR(ctx-pclk)) {
@@ -856,8 +849,6 @@ err_disable_pm_runtime:
err_iounmap:
iounmap(ctx-regs);
-err_del_component:
- exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CRTC);
return ret;
}
@@ -870,7 +861,6 @@ static int decon_remove(struct platform_device *pdev)
iounmap(ctx-regs);
component_del(pdev-dev, decon_component_ops);
- exynos_drm_component_del(pdev-dev, EXYNOS_DEVICE_TYPE_CRTC);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index c9995b1..1057cc2 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1333,7 +1333,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct device_node *panel_node, *bridge_node, *endpoint;
struct exynos_dp_device *dp;
- int ret;
dp = devm_kzalloc(pdev-dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -1344,11 +1343,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp-display.ops = exynos_dp_display_ops;
platform_set_drvdata(pdev, dp);
- ret = exynos_drm_component_add(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
- dp-display.type);
- if (ret)
- return ret;
-
panel_node = of_parse_phandle(dev-of_node, panel, 0);
if (panel_node) {
dp-panel = of_drm_find_panel(panel_node);
@@ -1369,18 +1363,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- ret = component_add(pdev-dev, exynos_dp_ops);
- if (ret)
- exynos_drm_component_del(pdev-dev,
- EXYNOS_DEVICE_TYPE_CONNECTOR);
-
- return ret;
+ return component_add(pdev-dev, exynos_dp_ops);
}
static int exynos_dp_remove(struct platform_device *pdev)
{
component_del(pdev-dev, exynos_dp_ops);
- exynos_drm_component_del(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 6dc328e..7cb6595 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -313,33 +313,19 @@ struct exynos_drm_display *exynos_dpi_probe(struct device
*dev)
ctx-dev = dev;
Re: [PATCH 2/9] drm/exynos: add atomic asynchronous commit
On 06/03/2015 11:30 PM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will schedule a work task to run the update later.
It also waits to an update to finishes to schedule a new one.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6
drivers/gpu/drm/exynos/exynos_drm_fb.c | 51
++---
3 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 08b9a8c..8ccff36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -60,6 +60,9 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
if (!private)
return -ENOMEM;
+ INIT_WORK(private-work, exynos_drm_atomic_work);
+ private-dev = dev;
+
dev_set_drvdata(dev-dev, dev);
dev-dev_private = (void *)private;
@@ -140,6 +143,8 @@ err_free_private:
static int exynos_drm_unload(struct drm_device *dev)
{
+ struct exynos_drm_private *private = dev-dev_private;
+
exynos_drm_device_subdrv_remove(dev);
exynos_drm_fbdev_fini(dev);
@@ -150,6 +155,7 @@ static int exynos_drm_unload(struct drm_device *dev)
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);
+ flush_work(private-work);
kfree(dev-dev_private);
dev-dev_private = NULL;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 1c66f65..552ca4a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -255,6 +255,10 @@ struct exynos_drm_private {
unsigned long da_space_size;
unsigned int pipe;
+
+ struct drm_device *dev;
+ struct work_struct work;
+ struct drm_atomic_state *state;
};
/*
@@ -324,6 +328,8 @@ static inline int exynos_drm_probe_vidi(void) { return 0;
}
static inline void exynos_drm_remove_vidi(void) {}
#endif
+void exynos_drm_atomic_work(struct work_struct *work);
+
/* This function creates a encoder and a connector, and initializes them. */
int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 789db6f..28626db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -267,20 +267,18 @@ static void exynos_drm_output_poll_changed(struct
drm_device *dev)
exynos_drm_fbdev_init(dev);
}
-static int exynos_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
+static void exynos_atomic_commit_schedule(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* This is the point of no return */
+ struct exynos_drm_private *private = dev-dev_private;
- drm_atomic_helper_swap_state(dev, state);
+ private-state = state;
+ schedule_work(private-work);
+}
+static void exynos_atomic_commit_complete(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
drm_atomic_helper_commit_modeset_disables(dev, state);
drm_atomic_helper_commit_modeset_enables(dev, state);
@@ -300,6 +298,37 @@ static int exynos_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_state_free(state);
+}
+
+void exynos_drm_atomic_work(struct work_struct *work)
+{
+ struct exynos_drm_private *private = container_of(work,
+ struct exynos_drm_private, work);
+
+ exynos_atomic_commit_complete(private-dev, private-state);
+}
+
+static int exynos_atomic_commit(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool async)
+{
+ struct exynos_drm_private *private = dev-dev_private;
+ int ret;
+
+ ret = drm_atomic_helper_prepare_planes(dev, state);
+ if (ret)
+ return ret;
+
+ /* This is the point of no return */
+
+ drm_atomic_helper_swap_state(dev, state);
+
+ flush_work(private-work);
It seems be wrong to swap state before flush work.
I'm not sure whether need locking but other drivers changed to atomic
modeset feature use locking here.
+
+ if (async)
+
[PATCH 5/9] tests/exynos: remove unused define
It doesn't make sense to limit the number of test cases anyway. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index 6af9277..080d178 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -34,7 +34,6 @@ #include exynos_fimg2d.h #define DRM_MODULE_NAMEexynos -#define MAX_TEST_CASE 8 static unsigned int screen_width, screen_height; -- 2.0.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] drm/exynos: cleanups and small fixes for libdrm
Hello, I've split off the Exynos specific bits, so this is just some cleanups and small fixes. Everything can be reviewed without knowledge about the Exynos platform. My hope is that I can get at least some of the patches from my last series upstream. With best wishes, Tobias Tobias Jakobi (9): exynos: fimg2d: fix return codes tests/exynos: replace return by break exynos/fimg2d: simplify g2d_fini() tests/exynos: clean struct connector tests/exynos: remove unused define tests/exynos: remove struct fimg2d_test_case tests/exynos: simplify drm_set_crtc tests/exynos: remove connector_find_plane tests/exynos: handle G2D_IMGBUF_COLOR in switch statements exynos/exynos_fimg2d.c| 23 ++-- tests/exynos/exynos_fimg2d_test.c | 112 +++--- 2 files changed, 26 insertions(+), 109 deletions(-) -- 2.0.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 1/9] exynos: fimg2d: fix return codes
Even if flushing the command buffer doesn't succeed, the G2D calls would still return zero. Fix this by just passing the flush return code. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- exynos/exynos_fimg2d.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 86ae898..5ea42e6 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -330,9 +330,7 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, bitblt.data.fast_solid_color_fill_en = 1; g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -415,9 +413,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src, rop4.data.unmasked_rop3 = G2D_ROP3_SRC; g2d_add_cmd(ctx, ROP4_REG, rop4.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -527,9 +523,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -636,9 +630,7 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -766,7 +758,5 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } -- 2.0.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 6/9] tests/exynos: remove struct fimg2d_test_case
It doesn't make sense to keep this structure, since we
can just call all tests directly.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 42 +--
1 file changed, 5 insertions(+), 37 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 080d178..de6a2b7 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -37,30 +37,6 @@
static unsigned int screen_width, screen_height;
-/*
- * A structure to test fimg2d hw.
- *
- * @solid_fill: fill given color data to source buffer.
- * @copy: copy source to destination buffer.
- * @copy_with_scale: copy source to destination buffer scaling up or
- * down properly.
- * @blend: blend source to destination buffer.
- */
-struct fimg2d_test_case {
- int (*solid_fill)(struct exynos_device *dev, struct exynos_bo *dst);
- int (*copy)(struct exynos_device *dev, struct exynos_bo *src,
- struct exynos_bo *dst, enum e_g2d_buf_type);
- int (*copy_with_scale)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
- int (*blend)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
- int (*checkerboard)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
-};
-
struct connector {
uint32_t id;
char mode_str[64];
@@ -630,14 +606,6 @@ fail:
return ret;
}
-static struct fimg2d_test_case test_case = {
- .solid_fill = g2d_solid_fill_test,
- .copy = g2d_copy_test,
- .copy_with_scale = g2d_copy_with_scale_test,
- .blend = g2d_blend_test,
- .checkerboard = g2d_checkerboard_test,
-};
-
static void usage(char *name)
{
fprintf(stderr, usage: %s [-s]\n, name);
@@ -747,7 +715,7 @@ int main(int argc, char **argv)
if (ret 0)
goto err_rm_fb;
- ret = test_case.solid_fill(dev, bo);
+ ret = g2d_solid_fill_test(dev, bo);
if (ret 0) {
fprintf(stderr, failed to solid fill operation.\n);
goto err_rm_fb;
@@ -761,7 +729,7 @@ int main(int argc, char **argv)
goto err_rm_fb;
}
- ret = test_case.copy(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_copy_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to test copy operation.\n);
goto err_free_src;
@@ -769,7 +737,7 @@ int main(int argc, char **argv)
wait_for_user_input(0);
- ret = test_case.copy_with_scale(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_copy_with_scale_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to test copy and scale operation.\n);
goto err_free_src;
@@ -777,7 +745,7 @@ int main(int argc, char **argv)
wait_for_user_input(0);
- ret = test_case.checkerboard(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_checkerboard_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to issue checkerboard test.\n);
goto err_free_src;
@@ -794,7 +762,7 @@ int main(int argc, char **argv)
* Disable the test for now, until the kernel code has been sanitized.
*/
#if 0
- ret = test_case.blend(dev, src, bo, G2D_IMGBUF_USERPTR);
+ ret = g2d_blend_test(dev, src, bo, G2D_IMGBUF_USERPTR);
if (ret 0)
fprintf(stderr, failed to test blend operation.\n);
--
2.0.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 7/9] tests/exynos: simplify drm_set_crtc
We can just return 'ret' here, the goto serves no purpose.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index de6a2b7..1ec7340 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -150,14 +150,9 @@ static int drm_set_crtc(struct exynos_device *dev, struct
connector *c,
ret = drmModeSetCrtc(dev-fd, c-crtc,
fb_id, 0, 0, c-id, 1, c-mode);
- if (ret) {
+ if (ret)
drmMsg(failed to set mode: %s\n, strerror(errno));
- goto err;
- }
-
- return 0;
-err:
return ret;
}
--
2.0.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 8/9] tests/exynos: remove connector_find_plane
No test uses DRM planes at the moment so this function
is never called.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 1ec7340..59de4ba 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -112,37 +112,6 @@ static void connector_find_mode(int fd, struct connector
*c,
c-crtc = c-encoder-crtc_id;
}
-static int connector_find_plane(int fd, unsigned int *plane_id)
-{
- drmModePlaneRes *plane_resources;
- drmModePlane *ovr;
- int i;
-
- plane_resources = drmModeGetPlaneResources(fd);
- if (!plane_resources) {
- fprintf(stderr, drmModeGetPlaneResources failed: %s\n,
- strerror(errno));
- return -1;
- }
-
- for (i = 0; i plane_resources-count_planes; i++) {
- plane_id[i] = 0;
-
- ovr = drmModeGetPlane(fd, plane_resources-planes[i]);
- if (!ovr) {
- fprintf(stderr, drmModeGetPlane failed: %s\n,
- strerror(errno));
- continue;
- }
-
- if (ovr-possible_crtcs (1 0))
- plane_id[i] = ovr-plane_id;
- drmModeFreePlane(ovr);
- }
-
- return 0;
-}
-
static int drm_set_crtc(struct exynos_device *dev, struct connector *c,
unsigned int fb_id)
{
--
2.0.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] drm/exynos: mixer: remove chained calls to enable/disable planes
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
With atomic modesetting all the control for CRTC, Planes, Encoders and
Connectors should come from DRM core, so the driver is not allowed to
disable planes from inside the crtc_disable() call. This patch
removes this chainned calls from mixer code letting only DRM core touch
planes.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_mixer.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6bab717..0e4d083 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -937,8 +937,6 @@ static void mixer_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
vp_video_buffer(mixer_ctx, win);
else
mixer_graph_buffer(mixer_ctx, win);
-
- mixer_ctx-planes[win].enabled = true;
}
static void mixer_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
@@ -952,7 +950,6 @@ static void mixer_win_disable(struct exynos_drm_crtc *crtc,
unsigned int win)
mutex_lock(mixer_ctx-mixer_mutex);
if (!mixer_ctx-powered) {
mutex_unlock(mixer_ctx-mixer_mutex);
- mixer_ctx-planes[win].resume = false;
return;
}
mutex_unlock(mixer_ctx-mixer_mutex);
@@ -964,8 +961,6 @@ static void mixer_win_disable(struct exynos_drm_crtc *crtc,
unsigned int win)
mixer_vsync_set_update(mixer_ctx, true);
spin_unlock_irqrestore(res-reg_slock, flags);
-
- mixer_ctx-planes[win].enabled = false;
}
static void mixer_wait_for_vblank(struct exynos_drm_crtc *crtc)
@@ -1000,33 +995,6 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc
*crtc)
drm_vblank_put(mixer_ctx-drm_dev, mixer_ctx-pipe);
}
-static void mixer_window_suspend(struct mixer_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i MIXER_WIN_NR; i++) {
- plane = ctx-planes[i];
- plane-resume = plane-enabled;
- mixer_win_disable(ctx-crtc, i);
- }
- mixer_wait_for_vblank(ctx-crtc);
-}
-
-static void mixer_window_resume(struct mixer_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i MIXER_WIN_NR; i++) {
- plane = ctx-planes[i];
- plane-enabled = plane-resume;
- plane-resume = false;
- if (plane-enabled)
- mixer_win_commit(ctx-crtc, i);
- }
-}
-
static void mixer_enable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc-ctx;
@@ -1058,8 +1026,6 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
mixer_reg_write(res, MXR_INT_EN, ctx-int_en);
mixer_win_reset(ctx);
-
- mixer_window_resume(ctx);
}
static void mixer_disable(struct exynos_drm_crtc *crtc)
@@ -1076,7 +1042,6 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
mixer_stop(ctx);
mixer_regs_dump(ctx);
- mixer_window_suspend(ctx);
ctx-int_en = mixer_reg_read(res, MXR_INT_EN);
--
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
Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hello Shuah,
Thanks a lot for your feedback.
On 06/10/2015 03:30 PM, Shuah Khan wrote:
On Wed, Jun 10, 2015 at 7:10 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The Exynos interrupt combiner IP looses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
I noticed this issue because after a S2R, IRQs for some devices didn't
trigger anymore but others continued working and all of them had lines
from a GPIO chip as their interrupt source.
The only difference was that the GPIO pins that were not working after
a resume, were the ones that had the interrupt combiner as interrupt
parent.
With this patch now all perhiperals are working correctly after a resume.
Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
Chromebooks.
Best regards,
Javier
drivers/irqchip/exynos-combiner.c | 61
+++
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..69c710641bfa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/slab.h
+#include linux/syscore_ops.h
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/interrupt.h
@@ -34,9 +35,14 @@ struct combiner_chip_data {
unsigned int irq_mask;
void __iomem *base;
unsigned int parent_irq;
+#ifdef CONFIG_PM
+ u32 pm_save;
+#endif
};
+static struct combiner_chip_data *combiner_data;
static struct irq_domain *combiner_irq_domain;
+static unsigned int max_nr = 20;
static inline void __iomem *combiner_base(struct irq_data *data)
{
@@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops =
{
};
static void __init combiner_init(void __iomem *combiner_base,
-struct device_node *np,
-unsigned int max_nr)
+struct device_node *np)
{
int i, irq;
unsigned int nr_irq;
- struct combiner_chip_data *combiner_data;
nr_irq = max_nr * IRQ_IN_COMBINER;
@@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
}
+#ifdef CONFIG_PM
+
+/**
+ * combiner_suspend - save interrupt combiner state before suspend
+ *
+ * Save the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state.
+ *
+ */
+static int combiner_suspend(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ combiner_data[i].pm_save =
+ __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET);
+
+ return 0;
+}
+
+/**
+ * combiner_resume - restore interrupt combiner state after resume
+ *
+ * Restore the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state on suspend.
+ *
+ */
+static void combiner_resume(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ __raw_writel(combiner_data[i].pm_save,
+combiner_data[i].base + COMBINER_ENABLE_SET);
+}
+
+#else
+#define combiner_suspend NULL
+#define combiner_resumeNULL
+#endif
+
+static struct syscore_ops combiner_syscore_ops = {
+ .suspend= combiner_suspend,
+ .resume = combiner_resume,
+};
+
Should this be static const struct syscore_ops?
That would cause a compile warning since register_syscore_ops() expects a
struct syscore_ops * as its argument and not a const struct syscore_ops *
static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
{
void __iomem *combiner_base;
- unsigned int max_nr = 20;
combiner_base = of_iomap(np, 0);
if (!combiner_base) {
@@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node
*np,
__func__, max_nr);
}
- combiner_init(combiner_base, np, max_nr);
+ combiner_init(combiner_base, np);
+
+ register_syscore_ops(combiner_syscore_ops);
return 0;
}
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
Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
On Wed, Jun 10, 2015 at 7:10 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The Exynos interrupt combiner IP looses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
I noticed this issue because after a S2R, IRQs for some devices didn't
trigger anymore but others continued working and all of them had lines
from a GPIO chip as their interrupt source.
The only difference was that the GPIO pins that were not working after
a resume, were the ones that had the interrupt combiner as interrupt
parent.
With this patch now all perhiperals are working correctly after a resume.
Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
Chromebooks.
Best regards,
Javier
drivers/irqchip/exynos-combiner.c | 61
+++
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..69c710641bfa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/slab.h
+#include linux/syscore_ops.h
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/interrupt.h
@@ -34,9 +35,14 @@ struct combiner_chip_data {
unsigned int irq_mask;
void __iomem *base;
unsigned int parent_irq;
+#ifdef CONFIG_PM
+ u32 pm_save;
+#endif
};
+static struct combiner_chip_data *combiner_data;
static struct irq_domain *combiner_irq_domain;
+static unsigned int max_nr = 20;
static inline void __iomem *combiner_base(struct irq_data *data)
{
@@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
};
static void __init combiner_init(void __iomem *combiner_base,
-struct device_node *np,
-unsigned int max_nr)
+struct device_node *np)
{
int i, irq;
unsigned int nr_irq;
- struct combiner_chip_data *combiner_data;
nr_irq = max_nr * IRQ_IN_COMBINER;
@@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
}
+#ifdef CONFIG_PM
+
+/**
+ * combiner_suspend - save interrupt combiner state before suspend
+ *
+ * Save the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state.
+ *
+ */
+static int combiner_suspend(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ combiner_data[i].pm_save =
+ __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET);
+
+ return 0;
+}
+
+/**
+ * combiner_resume - restore interrupt combiner state after resume
+ *
+ * Restore the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state on suspend.
+ *
+ */
+static void combiner_resume(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ __raw_writel(combiner_data[i].pm_save,
+combiner_data[i].base + COMBINER_ENABLE_SET);
+}
+
+#else
+#define combiner_suspend NULL
+#define combiner_resumeNULL
+#endif
+
+static struct syscore_ops combiner_syscore_ops = {
+ .suspend= combiner_suspend,
+ .resume = combiner_resume,
+};
+
Should this be static const struct syscore_ops?
static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
{
void __iomem *combiner_base;
- unsigned int max_nr = 20;
combiner_base = of_iomap(np, 0);
if (!combiner_base) {
@@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node *np,
__func__, max_nr);
}
- combiner_init(combiner_base, np, max_nr);
+ combiner_init(combiner_base, np);
+
+ register_syscore_ops(combiner_syscore_ops);
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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
Re: [PATCH v10 00/17] drm/exynos: atomic modesetting support
Hi Marek, 2015-06-10 Marek Szyprowski m.szyprow...@samsung.com: Hello, On 2015-06-01 17:04, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. Thanks for this patchses, however I've noticed a problem after applying them. The issue gets revealed when support for IOMMU is enabled. I've did my tests with Exynos HDMI driver on Odroid U3 board. To demonstrated the issue I've added following additional debug in the exynos mixer driver in mixer_graph_buffer() function: pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n, plane-dma_addr[0], plane-src_width, plane-src_height); Before applying patches setting 640x480 mode and getting back to 1920x1080 console generates following log: # modetest -M exynos -s 23:640x480 setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21 [ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 After applying atomic modesetting patchset: # modetest -M exynos -s 24:640x480 [ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22 [ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height 1080 [ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 As you can see from the above log, mixer_graph_buffer function is called several times. 0xbbd0 is the DMA address of the 1920x1080 framebuffer and 0xbc50 is the DMA address of the allocated 640x480 buffer. mixer_graph_buffer() is first called with the new DMA address of the framebuffer, but with the old mode parameters (1920x1080 size) and then in the next call it updates the plane parameters to the correct values (size changed to 640x480). When IOMMU is not used, this can be easily missed, but after enabling IOMMU support, any DMA access to unallocated address causes IOMMU PAGE FAULT. Here it will happen after changing DMA address of the buffer without changing the size. A quick workaround to resolve this multiple calls to mixer_graph_buffer() with partially updated mode values is to remove calls to mixer_window_suspend/mixer_window_resume from mixer_disable and mixer_disable functions, but I expect that this is not the right approach. Probably the same problem can be observed with Exynos FIMD driver. Gustavo: could you check if mixer_enable functions should really call mixer_window_resume function, which in turn calls mixer_win_commit, which calls mixer_graph_buffer with partially updated display buffer data? It should not, you are right. This is actually the correct fix. Atomic modesetting should not do chained calls, e.g., crtc_disable calling plane_disable. This change was already in my plan actually, but as I had IOMMU disabled I didn't see it here, and I didn't create this patch yet. Gustavo -- 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] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hi,
On Wed, Jun 10, 2015 at 10:10 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The Exynos interrupt combiner IP looses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
I noticed this issue because after a S2R, IRQs for some devices didn't
trigger anymore but others continued working and all of them had lines
from a GPIO chip as their interrupt source.
The only difference was that the GPIO pins that were not working after
a resume, were the ones that had the interrupt combiner as interrupt
parent.
With this patch now all perhiperals are working correctly after a resume.
Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
Chromebooks.
Best regards,
Javier
drivers/irqchip/exynos-combiner.c | 61
+++
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..69c710641bfa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/slab.h
+#include linux/syscore_ops.h
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/interrupt.h
@@ -34,9 +35,14 @@ struct combiner_chip_data {
unsigned int irq_mask;
void __iomem *base;
unsigned int parent_irq;
+#ifdef CONFIG_PM
+ u32 pm_save;
+#endif
};
+static struct combiner_chip_data *combiner_data;
static struct irq_domain *combiner_irq_domain;
+static unsigned int max_nr = 20;
static inline void __iomem *combiner_base(struct irq_data *data)
{
@@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
};
static void __init combiner_init(void __iomem *combiner_base,
-struct device_node *np,
-unsigned int max_nr)
+struct device_node *np)
{
int i, irq;
unsigned int nr_irq;
- struct combiner_chip_data *combiner_data;
nr_irq = max_nr * IRQ_IN_COMBINER;
@@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
}
+#ifdef CONFIG_PM
+
+/**
+ * combiner_suspend - save interrupt combiner state before suspend
+ *
+ * Save the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state.
+ *
+ */
+static int combiner_suspend(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ combiner_data[i].pm_save =
+ __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET);
+
+ return 0;
+}
+
+/**
+ * combiner_resume - restore interrupt combiner state after resume
+ *
+ * Restore the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state on suspend.
+ *
+ */
+static void combiner_resume(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
Don't you need to clear masking bits of the COMBINER_ENABLE_CLEAR
before enabling the bits?
+ __raw_writel(combiner_data[i].pm_save,
+combiner_data[i].base + COMBINER_ENABLE_SET);
+}
+
+#else
+#define combiner_suspend NULL
+#define combiner_resumeNULL
+#endif
+
+static struct syscore_ops combiner_syscore_ops = {
+ .suspend= combiner_suspend,
+ .resume = combiner_resume,
+};
+
static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
{
void __iomem *combiner_base;
- unsigned int max_nr = 20;
combiner_base = of_iomap(np, 0);
if (!combiner_base) {
@@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node *np,
__func__, max_nr);
}
- combiner_init(combiner_base, np, max_nr);
+ combiner_init(combiner_base, np);
+
+ register_syscore_ops(combiner_syscore_ops);
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards,
Chanho Park
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a
[PATCH 2/9] tests/exynos: replace return by break
The 'usage' function already does exit(0), so that this 'return -EINVAL' is never called. Just put a break there to avoid confusion. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index e64bb32..64dacfa 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -689,7 +689,7 @@ int main(int argc, char **argv) break; default: usage(argv[0]); - return -EINVAL; + break; } } -- 2.0.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 9/9] tests/exynos: handle G2D_IMGBUF_COLOR in switch statements
This fixes a compiler warning about missing handling of enum values in the switch statements. Also remove the silent mapping to G2D_IMGBUF_GEM when an unknown buffer type is encountered. We have full control about the type here, and if it's unknown then we obviously have a bug in the code. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index 59de4ba..8794dac 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -270,9 +270,10 @@ static int g2d_copy_test(struct exynos_device *dev, struct exynos_bo *src, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(copy test with %s.\n, @@ -306,6 +307,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return ret; @@ -349,9 +351,10 @@ static int g2d_copy_with_scale_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(copy and scale test with %s.\n, @@ -390,6 +393,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return 0; @@ -435,9 +439,10 @@ static int g2d_blend_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(blend test with %s.\n, @@ -487,6 +492,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return 0; @@ -532,6 +538,7 @@ static int g2d_checkerboard_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = (unsigned long)checkerboard; src_img.user_ptr[0].size = img_w * img_h * 4; break; + case G2D_IMGBUF_COLOR: default: ret = -EFAULT; goto fail; -- 2.0.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 3/9] exynos/fimg2d: simplify g2d_fini()
free()ing a nullptr is a noop, so remove the check.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
exynos/exynos_fimg2d.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 5ea42e6..24a06d0 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -254,8 +254,7 @@ struct g2d_context *g2d_init(int fd)
void g2d_fini(struct g2d_context *ctx)
{
- if (ctx)
- free(ctx);
+ free(ctx);
}
/**
--
2.0.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 4/9] tests/exynos: clean struct connector
Remove all unused struct members.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 64dacfa..6af9277 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -65,17 +65,9 @@ struct fimg2d_test_case {
struct connector {
uint32_t id;
char mode_str[64];
- char format_str[5];
- unsigned int fourcc;
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
- int pipe;
- int plane_zpos;
- unsigned int fb_id[2], current_fb_id;
- struct timeval start;
-
- int swap_count;
};
static void connector_find_mode(int fd, struct connector *c,
@@ -750,8 +742,6 @@ int main(int argc, char **argv)
if (ret 0)
goto err_destroy_buffer;
- con.plane_zpos = -1;
-
memset(bo-vaddr, 0xff, screen_width * screen_height * 4);
ret = drm_set_crtc(dev, con, fb_id);
--
2.0.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/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hello Chanho,
Thanks a lot for your feedback.
On 06/10/2015 03:40 PM, Chanho Park wrote:
Hi,
On Wed, Jun 10, 2015 at 10:10 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The Exynos interrupt combiner IP looses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
I noticed this issue because after a S2R, IRQs for some devices didn't
trigger anymore but others continued working and all of them had lines
from a GPIO chip as their interrupt source.
The only difference was that the GPIO pins that were not working after
a resume, were the ones that had the interrupt combiner as interrupt
parent.
With this patch now all perhiperals are working correctly after a resume.
Tested on an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi
Chromebooks.
Best regards,
Javier
drivers/irqchip/exynos-combiner.c | 61
+++
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..69c710641bfa 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/slab.h
+#include linux/syscore_ops.h
#include linux/irqdomain.h
#include linux/irqchip/chained_irq.h
#include linux/interrupt.h
@@ -34,9 +35,14 @@ struct combiner_chip_data {
unsigned int irq_mask;
void __iomem *base;
unsigned int parent_irq;
+#ifdef CONFIG_PM
+ u32 pm_save;
+#endif
};
+static struct combiner_chip_data *combiner_data;
static struct irq_domain *combiner_irq_domain;
+static unsigned int max_nr = 20;
static inline void __iomem *combiner_base(struct irq_data *data)
{
@@ -170,12 +176,10 @@ static struct irq_domain_ops combiner_irq_domain_ops =
{
};
static void __init combiner_init(void __iomem *combiner_base,
-struct device_node *np,
-unsigned int max_nr)
+struct device_node *np)
{
int i, irq;
unsigned int nr_irq;
- struct combiner_chip_data *combiner_data;
nr_irq = max_nr * IRQ_IN_COMBINER;
@@ -201,11 +205,56 @@ static void __init combiner_init(void __iomem
*combiner_base,
}
}
+#ifdef CONFIG_PM
+
+/**
+ * combiner_suspend - save interrupt combiner state before suspend
+ *
+ * Save the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state.
+ *
+ */
+static int combiner_suspend(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
+ combiner_data[i].pm_save =
+ __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET);
+
+ return 0;
+}
+
+/**
+ * combiner_resume - restore interrupt combiner state after resume
+ *
+ * Restore the interrupt enable set register for all combiner groups since
+ * the state is lost when the system enters into a sleep state on suspend.
+ *
+ */
+static void combiner_resume(void)
+{
+ int i;
+
+ for (i = 0; i max_nr; i++)
Don't you need to clear masking bits of the COMBINER_ENABLE_CLEAR
before enabling the bits?
I thought that was not needed since the enable bits are all cleared to 0
(default reset value) after a suspend.
But I can add the following if you think that it is needed or more safe:
/* Disable all interrupts */
__raw_writel(combiner_data[i].irq_mask,
combiner_data[i].base + COMBINER_ENABLE_CLEAR);
+ __raw_writel(combiner_data[i].pm_save,
+combiner_data[i].base + COMBINER_ENABLE_SET);
+}
+
+#else
+#define combiner_suspend NULL
+#define combiner_resumeNULL
+#endif
+
+static struct syscore_ops combiner_syscore_ops = {
+ .suspend= combiner_suspend,
+ .resume = combiner_resume,
+};
+
static int __init combiner_of_init(struct device_node *np,
struct device_node *parent)
{
void __iomem *combiner_base;
- unsigned int max_nr = 20;
combiner_base = of_iomap(np, 0);
if (!combiner_base) {
@@ -219,7 +268,9 @@ static int __init combiner_of_init(struct device_node
*np,
__func__, max_nr);
}
- combiner_init(combiner_base, np, max_nr);
+ combiner_init(combiner_base, np);
Re: [PATCH 1/2] power_supply: max17042: Add OF support for setting thresholds
Hi, On Mon, Jun 08, 2015 at 10:11:38AM +0900, Krzysztof Kozlowski wrote: The commit edd4ab055931 (power: max17042_battery: add HEALTH and TEMP_* properties support) added support for setting voltage and temperature thresholds with platform data. For DeviceTree default of 0 was always used. This caused reporting battery health always as over voltage or over heated. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Fixes: edd4ab055931 (power: max17042_battery: add HEALTH and TEMP_* properties support) Thanks, queued. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 9/9] [media] mm: Move get_vaddr_frames() behind a config option
On Wed, Jun 10, 2015 at 06:20:52AM -0300, Mauro Carvalho Chehab wrote:
From: Jan Kara j...@suse.cz
get_vaddr_frames() is used by relatively rare drivers so hide it and the
related functions behind a config option that is selected only by
drivers that need the infrastructure.
Suggested-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Seems sensible to me.
Since this patch makes the kernel smaller, can you include the delta
from bloat-o-meter between allnoconfig with and without this patch?
Also, I assume you've compile-tested the kernel with allyesconfig minus
the three options that now have select FRAME_VECTOR, to make sure it
builds?
create mode 100644 mm/frame_vector.c
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0a6780367d28..fc678289cf79 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI
config DRM_EXYNOS_G2D
bool Exynos DRM G2D
depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D
+ select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index dc2aaab54aef..217d613b0fe7 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT
select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB
+ select FRAME_VECTOR
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index f7a01a72eb9e..f38f6e387f04 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -73,6 +73,7 @@ config VIDEOBUF2_CORE
config VIDEOBUF2_MEMOPS
tristate
+ select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/mm/Kconfig b/mm/Kconfig
index 390214da4546..2ca52e9986f0 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB
changed to a smaller value in which case that is used.
A sane initial value is 80 MB.
+
+config FRAME_VECTOR
+ bool
diff --git a/mm/Makefile b/mm/Makefile
index 98c4eaeabdcb..be5d5c866305 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
new file mode 100644
index ..31a2bd5f41d5
--- /dev/null
+++ b/mm/frame_vector.c
@@ -0,0 +1,232 @@
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/sched.h
+
+/*
+ * get_vaddr_frames() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_frames: number of pages / pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. See description of the same argument of
+ get_user_pages().
+ * @vec: structure which receives pages / pfns of the addresses mapped.
+ * It should have space for at least nr_frames entries.
+ *
+ * This function maps virtual addresses from @start and fills @vec structure
+ * with page frame numbers or page pointers to corresponding pages (choice
+ * depends on the type of the vma underlying the virtual address). If @start
+ * belongs to a normal vma, the function grabs reference to each of the pages
+ * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we
don't
+ * touch page structures and the caller must make sure pfns aren't reused for
+ * anything else while he is using them.
+ *
+ * The function returns number of pages mapped which may be less than
+ * @nr_frames. In particular we stop mapping if there are more vmas of
+ * different type underlying the specified range of virtual addresses.
+ * When the function isn't able to map a single page, it returns error.
+ *
+ * This function takes care of grabbing mmap_sem as necessary.
+ */
+int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
+ bool write, bool force, struct frame_vector *vec)
+{
+ struct mm_struct *mm = current-mm;
+ struct vm_area_struct *vma;
+ int ret = 0;
+ int err;
+ int locked;
+
+ if (nr_frames == 0)
+ return 0;
+
+ if
Re: [PATCH 07/15] irqchip: kill off set_irq_flags usage
On Tue, Jun 9, 2015 at 1:26 PM, Rob Herring r...@kernel.org wrote:
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.
[...]
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33127f1..e3609ae 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct
irq_domain *h, unsigned int virq,
irq_hw_number_t hw)
{
irq_flow_handler_t handler = handle_level_irq;
- unsigned int flags = IRQF_VALID | IRQF_PROBE;
+ unsigned int flags = 0;
if (!clps711x_irqs[hw].flags)
return 0;
if (clps711x_irqs[hw].flags CLPS711X_FLAG_FIQ) {
handler = handle_bad_irq;
- flags |= IRQF_NOAUTOEN;
+ flags |= IRQ_NOAUTOEN;
} else if (clps711x_irqs[hw].eoi) {
handler = handle_fasteoi_irq;
}
@@ -150,7 +150,7 @@ static int __init clps711x_intc_irq_map(struct irq_domain
*h, unsigned int virq,
writel_relaxed(0, clps711x_intc-base +
clps711x_irqs[hw].eoi);
irq_set_chip_and_handler(virq, clps711x_intc_chip, handler);
- set_irq_flags(virq, flags);
+ irq_modify_status_flags(irq, IRQ_NOPROBE, flags);
One fix needed here:
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index e3609ae..2e74e81 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -150,7 +150,7 @@ static int __init clps711x_intc_irq_map(struct
irq_domain *h, unsigned int virq,
writel_relaxed(0, clps711x_intc-base + clps711x_irqs[hw].eoi);
irq_set_chip_and_handler(virq, clps711x_intc_chip, handler);
- irq_modify_status_flags(irq, IRQ_NOPROBE, flags);
+ irq_modify_status(virq, IRQ_NOPROBE, flags);
return 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
Re: [PATCH 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Javier == Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Javier The Exynos interrupt combiner IP looses its state when the SoC s/looses/loses/ Peter C -- Dr Peter Chubb peter.chubb AT nicta.com.au http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA -- 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
