Hi,
On 02/03/2015 12:58 PM, Kukjin Kim wrote:
> Marek Szyprowski wrote:
>>
>> Hi all,
>>
>> This is yet another update on patchset, which enables HDMI support for
>> Exynos based platforms.
>>
>> Beside DTS changes, this patchset adds parent domain support for Exynos
>> PM domains and add support
On Tue, Feb 03, 2015 at 10:42:26PM +0100, Arnd Bergmann wrote:
> Right, if you have a private iommu, there is no problem. The tricky part
> is using a single driver for the system-level translation and the gpu
> private mappings when there is only one type of iommu in the system.
You've got a prob
re receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/7b8f0de9/attachment.html>
From: Michel Dänzer
Doing so can cause things to become slow.
Print a warning at compile time and an informative message at runtime in
that case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeo
Hi,
On 02/03/2015 10:28 PM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-01-29 Joonyoung Shim :
>
>> The exynos_update_plane functions can be called from set_plane as well
>> as set_crtc and pageflip. Currently the plane displayed by set_plane
>> isn't called exynos_plane_on function and if p
Hi,
On 02/03/2015 10:41 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This issue was caused by the latest exynos_update_plane() clean up
> that unified plane operations. After those changes the plane failed
> to go the On state. This patch fix this problem by doing correct account
> of
Hi,
On 02/03/2015 11:16 PM, Gustavo Padovan wrote:
> 2015-02-02 Joonyoung Shim :
>
>> Hi,
>>
>> On 01/30/2015 11:44 PM, Gustavo Padovan wrote:
>>> Hi Joonyoung,
>>>
>>> 2015-01-30 Joonyoung Shim :
>>>
Hi,
On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
> From: Daniel Kurtz
+Cc Inki,
Hi,
On 02/04/2015 12:48 AM, Daniel Vetter wrote:
> So this has been merged originally in
>
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim
> Date: Thu Dec 15 15:40:55 2011 +0900
>
> drm: Add multi buffer plane pixel formats
>
> which hasn't seen a lot
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/e1797559/attachment.html>
On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
>> On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:
>>> Hi Mark, Heiko,
>>>
>>> On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao
>>> wrote:
Vop standby will take effect end of current frame,
Vop standby will take effect at end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.
we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.
Reviewed-by: Heiko Stuebner
Reviewed-by: Daniel Kurtz
Signed-off-by: Mark Yao
---
Change
On Feb 4, 2015 11:38 AM, "Mark yao" wrote:
>
> On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
>>
>> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
>>>
>>> On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:
Hi Mark, Heiko,
On Sat, Jan 31, 2015 at 4:41 PM, Mark Yao
>>
On 2015å¹´02æ04æ¥ 11:48, Daniel Kurtz wrote:
> On Feb 4, 2015 11:38 AM, "Mark yao" wrote:
>> On 2015å¹´02æ02æ¥ 15:53, Daniel Vetter wrote:
>>> On Mon, Feb 02, 2015 at 10:30:09AM +0800, Mark yao wrote:
On 2015å¹´02æ02æ¥ 10:07, Daniel Kurtz wrote:
> Hi Mark, Heiko,
>
> On S
Hello Daniel,
On 2015ë
02ì 04ì¼ 00:48, Daniel Vetter wrote:
> So this has been merged originally in
>
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim
> Date: Thu Dec 15 15:40:55 2011 +0900
>
> drm: Add multi buffer plane pixel formats
>
> which hasn't seen
Vop standby will take effect at end of current frame,
if dsp_hold_valid_irq happen, it means vop standby complete.
we must wait standby complete when we want to disable aclk,
if not, memory bus maybe dead.
Reviewed-by: Heiko Stuebner
Reviewed-by: Daniel Kurtz
Signed-off-by: Mark Yao
---
Change
Hi Marek,
On 2015ë
02ì 02ì¼ 22:20, Marek Szyprowski wrote:
> Mixed need to have hdmi clock enabled to properly perform power on/off
> sequences, so add handling of this clock directly to the mixer driver.
> Dependency between hdmi clock and mixer module has been observed on
> Exynos4 based bo
On 2015ë
01ì 20ì¼ 23:31, Marek Szyprowski wrote:
> If system provides IOMMU feature, Exynos DRM should use it by default,
> because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
> driver has been enabled and no IOMMU support has been compiled into Exynos
> DRM driver.
Appli
On 2015ë
01ì 27ì¼ 20:40, Joonyoung Shim wrote:
> The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
> to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
> prevent that user selects the option unnecessarily.
Applied two patches, 1 and 2.
Thanks,
Inki D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2015 06:35 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:11PM +0530, Shobhit Kumar wrote:
>> On BYT-T configuration, panel enable/disable signals are routed
>> through PMIC. Add a cell device for the same.
>>
>> Signed-off-by: Sho
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/44c3252d/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2015 06:46 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
>> This driver provides support for the "crystal_cove_panel" cell
>> device. On BYT-T pmic has to be used to enable/disable panel.
>>
>> v2:
ri-devel/attachments/20150204/5101fb49/attachment.html>
On 2015ë
01ì 30ì¼ 16:43, Joonyoung Shim wrote:
> We get wrong pipe value for crtc since commit 93bca243ec96 ("drm/exynos:
> remove struct exynos_drm_manager"). We should should increase pipe value
> before call exynos_drm_crtc_create.
Right, applied.
Thanks,
Inki Dae
>
> Signed-off-by: Joo
On 2015ë
01ì 30ì¼ 16:43, Joonyoung Shim wrote:
> Use driver internal struct as argument instead of struct exynos_drm_crtc
> except functions of exynos_drm_crtc_ops and instead of struct
> exynos_drm_display except functions of exynos_drm_display_ops.
Agree. Reasonable to use a driver context
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This series clean ups a few more paths from exynos-drm with the most important
> being the removal of the global page flip queue and the removal in driver
> internal data (struct *_win_data) that was replicat
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> from the underlying layer. However neither one of these layers implement
> win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpm
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
>
> It changes how planes are created and remove .win_mode_set()
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The atomic helper to disable planes also uses the optional
> .atomic_disable() helper. The unique operation it does is calling
> .win_disable()
>
Is there any reason to split this patch from patch 06/14?
> exynos_d
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> unprotect the windows before the commit and protects it after based on
> a plane mask tha store which plane will be updated.
>
I don't think they
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The new atomic infrastructure needs the .mode_set_nofb() callback to
> update CRTC timings before setting any plane.
>
> Signed-off-by: Gustavo Padovan
>
> Conflicts:
> drivers/gpu/drm/exynos/exynos_drm_crtc.
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
> track of the framebuffer pointer and reference.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
>
On 2015ë
01ì 30ì¼ 17:30, Seung-Woo Kim wrote:
> For default graphic window, mixer_win_commit() sets display size
> register as fb size. Calling setplane with smaller fb size than
> mode size to default window causes distorted display result. So
> this patch replaces fb size with mode size for
Le vendredi 30 janvier 2015 à 16:29 +0900, Joonyoung Shim a écrit :
> Hi,
>
> OK, i also get blank screen from hdmi after enable vidi.
>
> The pipe value for crtc is increased in mixer_initialize so it should be
> called before exynos_drm_crtc_create because the pipe value is used in
> exyno
Hello Benjamin Gaignard,
The patch f32c4c506f9b: "drm: sti: add DVO output connector" from Dec
30, 2014, leads to the following static checker warning:
drivers/gpu/drm/sti/sti_awg_utils.c:63 awg_generate_instr()
warn: no-op. '(arg << 24) >> 24'
drivers/gpu/drm/sti/sti_awg_utils.c
On Wed, Feb 04, 2015 at 11:30:23AM +0900, Joonyoung Shim wrote:
> +Cc Inki,
>
> Hi,
>
> On 02/04/2015 12:48 AM, Daniel Vetter wrote:
> > So this has been merged originally in
> >
> > commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> > Author: Seung-Woo Kim
> > Date: Thu Dec 15 15:40:55 2011 +
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/bf3e6e6d/attachment.html>
On Mon, 02 Feb 2015, Sakari Kapanen wrote:
> Dear maintainers,
>
> On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000
> graphics, I'm experiencing the following with the latest 3.19rc6
> mainline kernel (built from the Arch Linux AUR package:
> https://aur.archlinux.org/pack
On Tue, Feb 03, 2015 at 11:30:11AM +0100, Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
>
> Thus far i915 used drm_vblank_off, but one of the side-effects of i
Am 04.02.2015 um 02:19 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> Doing so can cause things to become slow.
>
> Print a warning at compile time and an informative message at runtime in
> that case.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
> Cc: stable at vger.kernel
This patch removes the trailing tabs and whitespaces.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4b9cf2f..6ce8717 100644
--- a/tests/modetest/modet
When setting a plane is turned on without setting a mode, modetest
terminates with segmentation fault like below. So this patch adds
null check for the variable storing the buffer object in set_mode()
which is null in this case.
[ 4759.016695] modetest[619]: unhandled level 2 translation fault (11
Instead of manual calls of device_create_file() and
device_remove_file(), assign the static attribute groups to the device
with device_create_with_groups(). The conditionally built sysfs
entries are handled via is_visible callback.
This simplifies the code and also avoids the possible races.
Sig
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/276f965e/attachment.html>
Hi Dave,
As discussed on irc one more pull for a bit of atomic goodies. Otherwise
just random all over. Plus one fixup on top of the tag because we've
accidentally broken thread-safety for the hangcheck.
drm-intel-next-2015-01-30:
- chv rps improvements from Ville
- atomic state handling prep wor
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/a4020ea8/attachment.html>
Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> I have two machines with integrated Intel graphics and the problem
> happens only on the old o
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/afe9b603/attachment-0001.html>
On Mon, 02 Feb 2015, Gergely Nógrádi wrote:
> I can't configure the 2nd or 3rd display on my Dell Latitude e5540
> notebook and Dell NB Port Replicator.
> I tried to connect DVI, DP and VGA to Port Replicator and it is
> working only in mirror mode.
> The only way to use 2 external display if I
Hi Inki,
On Mon, Dec 8, 2014 at 7:09 PM, Inki Dae wrote:
>
>
> On 2014ë
12ì 07ì¼ 21:04, Ajay Kumar wrote:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> DECON(Display and Enhancement Contr
On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote:
> Hi,
>
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
> > from the underlying layer. However neither one of these layers impl
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
> Hi,
>
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > struct {fimd,mixer,vidi}_win_data was just keeping the same data
> > as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote:
> Hi,
>
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> > unprotect the windows before the commit and protects it after based on
On Wed, Feb 04, 2015 at 04:53:12PM +0900, Joonyoung Shim wrote:
> Hi,
>
> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
> > track of the framebuffer pointer and reference.
> >
> > Signed-of
Hi all,
I've gone through some of the contentions point in this patch review. With
my community guy hat on I really want to make drm atomic a success, exynos
atomic is important for that.
On Wed, Feb 04, 2015 at 04:37:04PM +0900, Joonyoung Shim wrote:
> Hi,
>
> On 02/04/2015 04:14 AM, Gustavo Pa
a 5670.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/7c80d93a/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/de368210/attachment-0001.html>
On 32-bit platforms using asm-generic/div64.h:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
'gk20a_pllg_calc_rate':
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:147:79: warning: comparison of
distinct pointer types lacks a cast
do_div(rate, divider);
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/19754f32/attachment.html>
On Wed, Feb 04, 2015 at 11:58:53AM +0100, Takashi Iwai wrote:
> Instead of manual calls of device_create_file() and
> device_remove_file(), assign the static attribute groups to the device
> with device_create_with_groups(). The conditionally built sysfs
> entries are handled via is_visible callba
Hello,
I'm currently adding support for atomic operations (or atomic
modesetting) in the Atmel HLCDC driver.
Everything is pretty much in place, and all the features provided by the
current driver are working as expected.
However, there's one feature I'd like to add (actually I was hoping
atomic s
On Wed, Feb 4, 2015 at 12:23 PM, Boris Brezillon
wrote:
> Hello,
>
> I'm currently adding support for atomic operations (or atomic
> modesetting) in the Atmel HLCDC driver.
> Everything is pretty much in place, and all the features provided by the
> current driver are working as expected.
> Howeve
On Wed, Feb 04, 2015 at 06:23:15PM +0100, Boris Brezillon wrote:
> Hello,
>
> I'm currently adding support for atomic operations (or atomic
> modesetting) in the Atmel HLCDC driver.
> Everything is pretty much in place, and all the features provided by the
> current driver are working as expected.
On Wed, Feb 04, 2015 at 09:26:27PM +0300, Andrey Skvortsov wrote:
> On Tue, Feb 03, 2015 at 08:21:52PM +, Chris Wilson wrote:
> > On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> > > Hi,
> > >
> > > tested next-20150202. System boots, but graphic output is broken (empty
> >
On Wed, 4 Feb 2015 12:49:19 -0500
Rob Clark wrote:
> On Wed, Feb 4, 2015 at 12:23 PM, Boris Brezillon
> wrote:
> > Hello,
> >
> > I'm currently adding support for atomic operations (or atomic
> > modesetting) in the Atmel HLCDC driver.
> > Everything is pretty much in place, and all the features
Hi Ville,
On Wed, 4 Feb 2015 20:02:27 +0200
Ville Syrjälä wrote:
> On Wed, Feb 04, 2015 at 06:23:15PM +0100, Boris Brezillon wrote:
> > Hello,
> >
> > I'm currently adding support for atomic operations (or atomic
> > modesetting) in the Atmel HLCDC driver.
> > Everything is pretty much in pla
Convert the HLCDC driver to atomic mode-setting.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 142 ++
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 5 +-
drivers/gpu/drm/atmel-hlcdc/atme
0-255 seems to be the preferred range for the pwm interface.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 91e1bd2..9f75
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/9ad854b7/attachment.html>
On Wed, Feb 4, 2015 at 4:49 AM, Christian König
wrote:
> Am 04.02.2015 um 02:19 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>>
>> Doing so can cause things to become slow.
>>
>> Print a warning at compile time and an informative message at runtime in
>> that case.
>>
>> Bugzilla: https:/
For scenarios where OF is not available, we can use panel identification by
name.
v2: Use const char *name instead of name[NAME_MAX] (Thierry)
CC: Thierry Reding
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/drm_panel.c | 18 ++
include/drm/drm_panel.h | 3 +++
2 files
This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.
Signed-off-by: Marek Szyprowski
---
Resend reason: rebased onto latest kgene/v3.20-next/dt-samsung-4 branch
---
arch/arm/boot/dts/exynos4.dtsi| 40 +++
Hi Philipp,
Could you add linux-media next time you send the set, please? I think
that's the most relevant list for the format related patches.
Philipp Zabel wrote:
> Commit 9e74d2926a28 ("staging: imx-drm: add LVDS666 support for parallel
> display") describes a 24-bit bus format where three 6-
On 02/04/15 09:09, Joonyoung Shim wrote:
> Hi,
>
Hi,
> On 02/03/2015 12:58 PM, Kukjin Kim wrote:
>> Marek Szyprowski wrote:
>>>
>>> Hi all,
>>>
>>> This is yet another update on patchset, which enables HDMI support for
>>> Exynos based platforms.
>>>
>>> Beside DTS changes, this patchset adds par
On Tue, Jan 20, 2015 at 10:38 AM, Ajay Kumar
wrote:
> ps8622 eDP-LVDS converter bridge chip is from parade technologies
>
> Signed-off-by: Ajay Kumar
> Acked-by: Inki Dae
> Tested-by: Rahul Sharma
> Tested-by: Javier Martinez Canillas
> Tested-by: Gustavo Padovan
> Tested-by: Sjoerd Simons
zable_should_stop+0x36/0x36
> > [ 31.781326] [] ? ret_from_fork+0x7c/0xb0
> > [ 31.781329] [] ?
> > kthread_freezable_should_stop+0x36/0x36
> > [ 31.782726] ---[ end trace e2b78017f1a10054 ]---
> >
--
Best regards,
Andrey Skvortsov
PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150204/0a69cdc4/attachment-0001.sig>
On Tue, Feb 03, 2015 at 08:21:52PM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> > Hi,
> >
> > tested next-20150202. System boots, but graphic output is broken (empty
> > black screen).
> > Booted five times the same kernel, always got the same r
From: Markus Elfring
Date: Wed, 4 Feb 2015 21:54:45 +0100
The functions phy_power_on() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/
From: Markus Elfring
Date: Wed, 4 Feb 2015 22:22:36 +0100
The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drive
On Wed, Dec 31, 2014 at 2:23 AM, Liu Ying wrote:
> Signed-off-by: Liu Ying
I don't know what the status is for the rest of the series, but I'm
applying this and patch 3 so you don't have to keep sending them.
Rob
> ---
> v7->v8:
> * None.
>
> v6->v7:
> * None.
>
> v5->v6:
> * None.
>
> v4->
79 matches
Mail list logo
