Can you rebase this onto rc1? since I'm getting conflicts when I pull
it, and I really shouldn't be.
Dave.
On 31 March 2016 at 00:19, Liviu Dudau wrote:
> Hi David,
>
> There is one patch that Alexey Brodkin has submitted a while ago
> for cleanup up the maintainance of pixel clock for HDLCD tha
Hi Linus,
Nothing too crazy in here, a bunch of AMD fixes/quirks,
two msm, some rockchip fixes, and a udl warning fix,
along with one locking fix for displayport that seems
to fix some dodgy monitors.
Thanks,
Dave.
The following changes since commit c05c2ec96bb8b7310da1055c7b9d786a3ec6dc0c:
Hi,
My setup is an embedded GM45 based board with a screen connected via 24
bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the
screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS
versions of the kernel worked fine.
I'm hoping that a resident Intel DRM guru
o a few tests with that.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/728be174/attachment.sig>
On Fri, 01 Apr 2016, "Zanoni, Paulo R" wrote:
> Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
> escreveu:
>> From: Ville Syrjälä
>>
>> DP dual mode type 1 DVI adaptors aren't required to implement any
>> registers, so it's a bit hard to detect them. The best way would
>>
On 01/04/16 10:03, Tomi Valkeinen wrote:
> So probably we could just fix hdmi_core_powerdown_disable(), so that it
> sets PD to 1, which is what it was meant to do. This assumes that there
> are no bad side effects having PD 1 even if the HDMI is blanked, which
> is something we need to verify. I
_release(struct hdmi_core_data *core)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/85298677/attachment.sig>
On Fri, 01 Apr 2016, Rob Kramer wrote:
> My setup is an embedded GM45 based board with a screen connected via 24
> bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the
> screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS
> versions of the kernel worked fine.
Hi Dave,
here are some updates and fixes for the imx-drm plane setup and
dw_hdmi-imx binding.
The unimplemented gamma support is no longer advertised and plane
parameters are checked for hardware constraints. YUV 4:2:0 support and
the display FIFO setup are fixed.
best regards
Philipp
The follow
From: Michel Dänzer
Prevents the
if (WARN_ON(pipe >= dev->num_crtcs))
in drm_vblank_on/off from triggering if acceleration fails to
initialize, in which case we call drm_vblank_cleanup.
Reported-and-Tested-by: Julian Margetson
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeo
On 31.03.2016 19:00, Julian Margetson wrote:
> On 3/31/2016 2:50 AM, Michel Dänzer wrote:
>> On 30.03.2016 19:36, Julian Margetson wrote:
>>> On 3/29/2016 11:49 PM, Michel Dänzer wrote:
On 29.03.2016 18:55, Julian Margetson wrote:
> On 3/28/2016 11:15 PM, Michel Dänzer wrote:
>> On
On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> Only really needed for fbdev emulation at 8bpp. And bochs doesn't do
> that. And either way bochs only does 32bit rgb, so this is all pretty
> much wasted dead code.
Pointless leftover when I copyed things over from cirrus.
Reviewed-by: Ger
On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> No need to confuse userspace like this.
Reviewed-by: Gerd Hoffmann
Am Donnerstag, den 31.03.2016, 16:26 -0400 schrieb Rob Clark:
> A bit overkill since, for example, the rcu_dereference_protected() in
> reservation_object_get_list() will WARN. But this is much less subtle
> for folks reading the code.
>
> Signed-off-by: Rob Clark
> ---
> drivers/dma-buf/reserv
On 04/01/2016 04:01 PM, Jani Nikula wrote:
> On Fri, 01 Apr 2016, Rob Kramer wrote:
>> My setup is an embedded GM45 based board with a screen connected via 24
>> bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the
>> screen stays blank. I'm only testing KMS so far, no X. Older, p
9483a3d
- gtk 2.24.20
- mate 1.6.1
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/61182242/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/233cd82d/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/ced76d18/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/9ba42dba/attachment.html>
;https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/551e2e0d/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/f0ee2f7c/attachment-0001.html>
From: Michel Dänzer
When this flag is set, we program the hardware to execute the flip
during horizontal blank (i.e. for the next scanline) instead of during
vertical blank (i.e. for the next frame).
Currently this is only supported on ASICs which have a page flip
completion interrupt (>= R600)
On Fri, Apr 01, 2016 at 01:13:02PM +1000, Dave Airlie wrote:
> Can you rebase this onto rc1? since I'm getting conflicts when I pull
> it, and I really shouldn't be.
I've now rebased the tree on top of rc1. Here is the updated pull
request.
Many thanks,
Liviu
The following changes since commit f
Here's the same issue on a more reasonable kernel. The log looks quite
different, but the end result is still a blank screen. Uploaded here:
http://pastebin.com/WLpT5mPc
This section looks promising:
[4.763951] [drm:intel_dump_pipe_config] requested mode:
[4.763953] [drm:drm_mode_debug_
On 4/1/2016 4:31 AM, Michel Dänzer wrote:
> On 31.03.2016 19:00, Julian Margetson wrote:
>> On 3/31/2016 2:50 AM, Michel Dänzer wrote:
>>> On 30.03.2016 19:36, Julian Margetson wrote:
On 3/29/2016 11:49 PM, Michel Dänzer wrote:
> On 29.03.2016 18:55, Julian Margetson wrote:
>> On 3/
the one
used by Ubuntu for fglrx.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/b8ffec8e/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/eccc80a3/attachment.html>
.org/archives/dri-devel/attachments/20160401/348976de/attachment.html>
The static checker checker is warning that we could hit the first
continue; on every iteration through the loop and never initialize
"ret". It seems unlikely but we may as well silence the warning.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/dr
On Fri, 01 Apr 2016, Rob Kramer wrote:
> Here's the same issue on a more reasonable kernel. The log looks quite
> different, but the end result is still a blank screen. Uploaded here:
> http://pastebin.com/WLpT5mPc
>
> This section looks promising:
>
> [4.763951] [drm:intel_dump_pipe_config]
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/d8a309d0/attachment.html>
On 04/01/2016 01:26 PM, Mark yao wrote:
> On 2016å¹´03æ31æ¥ 16:08, Tomeu Vizoso wrote:
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> v2: Use the status of the workqueue instead of vop->event, and
On 2016å¹´04æ01æ¥ 19:47, Tomeu Vizoso wrote:
> On 04/01/2016 01:26 PM, Mark yao wrote:
>> On 2016å¹´03æ31æ¥ 16:08, Tomeu Vizoso wrote:
>>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>>> updated is requested and there is an earlier updated pending".
>>>
>>> v2: Use
Hello,
On 2016-03-30 13:34, Benjamin Gaignard wrote:
> The original patches have been done by Marek:
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html
>
> I have just adapt them to make zpos depend on plane and no more on drm core.
>
> Since zpos range can be define per p
Am 01.04.2016 um 11:51 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> When this flag is set, we program the hardware to execute the flip
> during horizontal blank (i.e. for the next scanline) instead of during
> vertical blank (i.e. for the next frame).
>
> Currently this is only supported on
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plan
Hi Dave,
I figured it's time to open 4.7, also because we need the DCS patches from
this pull in i915:
- First patch of uapi header alignment with libdrm.
- random small stuff all over.
There's a small trivial conflict in amdgpu with the dummy
vgacon_text_force patch.
Cheers, Daniel
The follow
Hello,
This patch series simplifies the code by replacing custom code with
generic helper.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (7):
drm/exynos: exynos5433_decon: use generic of_device_get_match_data
helper
drm/exynos: dsi: use gene
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_d
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fim
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_d
There are no non-devicetree based Exynos platforms in mainline, so there
no point keeping old platform driver data for them.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_mixer.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exyno
Simplify code by replacing custom code by generic helper.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 06105feb
Hi Benjamin,
On 30 March 2016 at 12:34, Benjamin Gaignard
wrote:
> The original patches have been done by Marek:
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html
>
> I have just adapt them to make zpos depend on plane and no more on drm core.
>
> Since zpos range can be
On 1 April 2016 at 14:35, Emil Velikov wrote:
> Hi Benjamin,
>
> On 30 March 2016 at 12:34, Benjamin Gaignard
> wrote:
>> The original patches have been done by Marek:
>> https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html
>>
>> I have just adapt them to make zpos depend on
Hi Dave,
drm-intel-next-2016-03-30:
- VBT code refactor for a clean split between parsing&using of firmware
information (Jani)
- untangle the pll computation code, and splitting up the monster
i9xx_crtc_compute_clocks (Ander)
- dsi support for bxt (Jani, Shashank Sharma and others)
- color man
Am 31.03.2016 um 22:26 schrieb Rob Clark:
> A bit overkill since, for example, the rcu_dereference_protected() in
> reservation_object_get_list() will WARN. But this is much less subtle
> for folks reading the code.
>
> Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
One i
On Thu, Mar 31, 2016 at 4:26 PM, Rob Clark wrote:
> Some dma-buf headerdoc fixes (turns out dma-buf.h wasn't getting pulled
> into doc build), add reservation headerdoc, and fixup a bit the section
> in device-drivers.tmpl.
>
> Rob Clark (4):
> reservation: sprinkle some WARN_ON()s
> dma-buf:
On Fri, Apr 1, 2016 at 4:28 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Prevents the
>
> if (WARN_ON(pipe >= dev->num_crtcs))
>
> in drm_vblank_on/off from triggering if acceleration fails to
> initialize, in which case we call drm_vblank_cleanup.
>
> Reported-and-Tested-by: Juli
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/b4632e3c/attachment.html>
On Thu, Mar 31, 2016 at 10:06:37PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > DP dual mode type 1 DVI adaptors aren't required to implement any
> > registers, so it's a bit hard to detect them.
On Thu, Mar 31, 2016 at 05:55:03PM -0300, Ezequiel Garcia wrote:
> Currently, our implementation of drm_connector_funcs.detect is
> based on getting a valid EDID.
>
> This requirement makes the driver fail to detect connected
> connectors in case of EDID corruption, which prevents from falling
> b
On Fri, Apr 1, 2016 at 4:48 AM, Lucas Stach wrote:
> Am Donnerstag, den 31.03.2016, 16:26 -0400 schrieb Rob Clark:
>> A bit overkill since, for example, the rcu_dereference_protected() in
>> reservation_object_get_list() will WARN. But this is much less subtle
>> for folks reading the code.
>>
>>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/808a9f79/attachment.html>
Fixes ttm on platforms like PPC460 where the CPU
is in 32-bit mode, but the physical addresses are
>32 bits.
Extracted from a patch by Hans.
Cc: Thomas Hellstrom
Cc: Julian Margetson
Cc: Hans Verkuil
Signed-off-by: Alex Deucher
---
include/drm/ttm/ttm_bo_api.h | 2 +-
1 file changed, 1 inser
On Fri, Apr 1, 2016 at 8:39 AM, Christian König
wrote:
> Am 01.04.2016 um 11:51 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>>
>> When this flag is set, we program the hardware to execute the flip
>> during horizontal blank (i.e. for the next scanline) instead of during
>> vertical blank
Hi Rob,
On 1 April 2016 at 19:37, Alex Deucher wrote:
> On Thu, Mar 31, 2016 at 4:26 PM, Rob Clark wrote:
>> Some dma-buf headerdoc fixes (turns out dma-buf.h wasn't getting pulled
>> into doc build), add reservation headerdoc, and fixup a bit the section
>> in device-drivers.tmpl.
>>
Thanks for
From: Ville Syrjälä
Eliminate the duplicate code for pipe timing readout in
intel_crtc_mode_get() by using the functions we use for the normal state
readout.
Cc: dri-devel at lists.freedesktop.org
Cc: Rob Kramer
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/inte
From: Ville Syrjälä
intel_crtc->config->cpu_transcoder isn't yet filled out when
intel_crtc_mode_get() gets called during output probing, so we should
not use it there. Instead intel_crtc_mode_get() figures out the correct
transcoder on its own, and that's what we should use.
If the BIOS boots
AIN_GMBUS);
> >
> > return status;
> > --
> > 2.7.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/bcebab55/attachment.html>
On Fri, Apr 01, 2016 at 12:38:11PM -0300, Ezequiel Garcia wrote:
> El abr. 1, 2016 11:47 AM, "Ville Syrjälä"
> escribió:
> >
> > On Thu, Mar 31, 2016 at 05:55:03PM -0300, Ezequiel Garcia wrote:
> > > Currently, our implementation of drm_connector_funcs.detect is
> > > based on getting a valid E
7;t verify this in-game.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/c2964845/attachment-0001.html>
On 4/1/2016 11:02 AM, Alex Deucher wrote:
> Fixes ttm on platforms like PPC460 where the CPU
> is in 32-bit mode, but the physical addresses are
>> 32 bits.
> Extracted from a patch by Hans.
>
> Cc: Thomas Hellstrom
> Cc: Julian Margetson
> Cc: Hans Verkuil
> Signed-off-by: Alex Deucher
> ---
>
Acked-by: Thomas Hellstrom
On 04/01/2016 06:31 PM, Julian Margetson wrote:
> On 4/1/2016 11:02 AM, Alex Deucher wrote:
>> Fixes ttm on platforms like PPC460 where the CPU
>> is in 32-bit mode, but the physical addresses are
>>> 32 bits.
>> Extracted from a patch by Hans.
>>
>> Cc: Thomas Hellstro
On 04/01/2016 12:03 AM, Tomi Valkeinen wrote:
> On 01/04/16 03:46, Hans Verkuil wrote:
>
>>> Apparently we set it always to 0 in
>>> hdmi4_core.c:hdmi_core_powerdown_disable(), but never enable it. I guess
>>> it only affects core irqs, so there have been no side effects.
>>>
>>> But it would mak
Hi Tomi,
On 04/01/2016 12:35 AM, Tomi Valkeinen wrote:
>
> On 01/04/16 10:03, Tomi Valkeinen wrote:
>
>> So probably we could just fix hdmi_core_powerdown_disable(), so that it
>> sets PD to 1, which is what it was meant to do. This assumes that there
>> are no bad side effects having PD 1 even if
ut
the HDMI IP is different than on OMAP4, so I presume CEC is different too.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160401/10445e52/attachment.sig>
Hello,
Here is the public first version of the driver for the Mali Display Processors.
Currently, the driver supports the Display Engine found in Mali DP500, DP550
and DP650, with up to 3 planes that can be rotated by the hardware. There are
features that the hardware supports that are not current
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/display/arm,ma
On Wed, Mar 30, 2016 at 06:22:23PM +0200, Enric Balletbo i Serra wrote:
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> Cc: Rob Herring
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes since v1:
> - Rob Herring:
>- Re
Hi Jose,
Thank you for the patch.
On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
> This patch adds audio support for the ADV7511 HDMI transmitter
> using ALSA SoC.
>
> The code was ported from Analog Devices linux tree from
> commit 1770c4a1e32b ("Merge remote-tracking branch
> 'xilinx/master'
Am 01.04.2016 um 17:02 schrieb Alex Deucher:
> Fixes ttm on platforms like PPC460 where the CPU
> is in 32-bit mode, but the physical addresses are
>> 32 bits.
> Extracted from a patch by Hans.
>
> Cc: Thomas Hellstrom
> Cc: Julian Margetson
> Cc: Hans Verkuil
> Signed-off-by: Alex Deucher
Rev
On Thu, Mar 31, 2016 at 04:36:03PM +0300, Jyri Sarha wrote:
> Register ASoC HDMI codec for audio functionality and adds device tree
> binding for audio configuration.
>
> With the registered HDMI codec the tda998x node can be used like a
> regular codec node in ASoC card configurations. HDMI audio
From: Ville Syrjälä
Eliminate the duplicate code for pipe timing readout in
intel_crtc_mode_get() by using the functions we use for the normal state
readout.
v2: Store dotclock in adjusted_mode instead of the final mode
Cc: dri-devel at lists.freedesktop.org
Cc: Rob Kramer
Cc: Daniel Vetter
Den 29.03.2016 09:27, skrev Daniel Vetter:
> On Fri, Mar 25, 2016 at 11:41:44AM +0100, Noralf Trønnes wrote:
>> Den 23.03.2016 18:28, skrev Daniel Vetter:
>>> On Wed, Mar 23, 2016 at 06:07:56PM +0100, Noralf Trønnes wrote:
Den 18.03.2016 18:47, skrev Daniel Vetter:
> On Thu, Mar 17, 201
On 01 Apr 06:46 PM, Ville Syrjälä wrote:
> On Fri, Apr 01, 2016 at 12:38:11PM -0300, Ezequiel Garcia wrote:
> > El abr. 1, 2016 11:47 AM, "Ville Syrjälä" > linux.intel.com>
> > escribió:
> > >
> > > On Thu, Mar 31, 2016 at 05:55:03PM -0300, Ezequiel Garcia wrote:
> > > > Currently, our implem
On Tue, Mar 22, 2016 at 04:08:39PM +0100, Maarten Lankhorst wrote:
> Op 22-03-16 om 15:58 schreef Ville Syrjälä:
> > On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
> >> __drm_atomic_helper_plane_destroy_state calls
> >> drm_framebuffer_unreference, which means that if drm_fram
Might have been better as a separate migration patch and then a compaction
patch. It's prefixed mm/compaction, but most changed are in mm/migrate.c
On 03/30/2016 09:12 AM, Minchan Kim wrote:
> We have allowed migration for only LRU pages until now and it was
> enough to make high-order pages. But
On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote:
> Add DT bindings documentation for the Mali Display Processor. The bindings
> describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar G
82 matches
Mail list logo
