Hi Emil,
On Fri, Sep 30, 2016 at 01:34:14PM +0100, Emil Velikov wrote:
> Hi Shawn,
>
> A couple of fly-by suggestions, which I hope you'll find useful :-)
Thanks for the suggestions.
> On 24 September 2016 at 15:26, Shawn Guo wrote:
>
> > +
> > + val = ((vm.hsync_len - 1) << SYNC_WIDE_
Hi Linus,
One big regression fix for udl, along with two amdgpu fixes and two
nouveau fixes.
All seems pretty safe and useful.
Dave.
The following changes since commit 08895a8b6b06ed2323cd97a36ee40a116b3db8ed:
Linux 4.8-rc8 (2016-09-25 18:47:13 -0700)
are available in the git repository at:
On Thu, 2016-09-29 at 10:46 +0200, Matthias Brugger wrote:
>
> On 29/09/16 06:01, CK Hu wrote:
> > Acked-by: CK Hu
> >
> > On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
> >> Fix the typo: OD_RELAYMODE->OD_CFG
> >>
>
Hi, Matthias
Thanks for your reply.
> Although it is quite clear what
Hi Andrezj,
On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> f
using drm_vblank_no_hw_counter() to eliminate kernel warning.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index eebb7d8..e286
Hi Daniel,
Thanks for very descriptive comment.
Few comments/questions below.
On 29.09.2016 17:50, Daniel Vetter wrote:
> It's not that obvious how a driver can all race the atomic commit with
> handling the completion event. And there's unfortunately a pile of
> drivers with rather bad event han
next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55095 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/af802c1a/attachment-0001.gz>
Hi,
On 30-09-16 05:09, Laszlo Ersek wrote:
> Hello Daniel,
>
> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>> We already have a fallback in place to fill out the unique from
>> dev->unique, which is set to something reasonable in drm_dev_alloc.
>>
>> Which means we only nee
Hi Stefan,
2016-09-29 Stefan Christ :
> Hi,
>
> this series is refactoring work suggested by Daniel Vetter in the email:
>
>https://lists.freedesktop.org/archives/dri-devel/2016-July/113237.html
>
> The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> implementations f
On Fri, Sep 30, 2016 at 9:56 AM, Andrzej Hajda wrote:
> Hi Daniel,
>
> Thanks for very descriptive comment.
> Few comments/questions below.
>
> On 29.09.2016 17:50, Daniel Vetter wrote:
>> It's not that obvious how a driver can all race the atomic commit with
>> handling the completion event. And
On Thu, Sep 29, 2016 at 11:04 PM, Marek Vasut wrote:
> On 09/29/2016 11:28 AM, Daniel Vetter wrote:
>> On Tue, Sep 27, 2016 at 02:20:49PM +0200, Marek Vasut wrote:
>>> On 09/27/2016 02:16 PM, Noralf Trønnes wrote:
Den 27.09.2016 12:29, skrev Marek Vasut:
> On 09/27/2016 09:49 AM, Da
On Thu, Sep 29, 2016 at 11:44 PM, Marek Vasut wrote:
> I have the following right now, I think that's more descriptive as this
> function is not preparing the FB in any way.
>
> /**
> * drm_fb_cma_extract_and_attach_fence() - Extract fence from plane and
> attach to planestate
> * @plane: Which
Hi all
On 30 September 2016 at 04:09, Laszlo Ersek wrote:
> Hello Daniel,
>
> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>> We already have a fallback in place to fill out the unique from
>> dev->unique, which is set to something reasonable in drm_dev_alloc.
>>
>> Which m
On Thu, Sep 29, 2016 at 11:58 PM, Marek Vasut wrote:
> + /**
> +* @prepare_fb:
> +*
> +* Optional, called by struct &drm_plane_helper_funcs ->prepare_fb .
> +*/
You've lost the hint that people should look there for what this hook
should do. Same with cleanu
Add stub for intel_crtc_set_crc_source() and fix arguments of stub for
intel_display_crc_init().
Signed-off-by: Tomeu Vizoso
Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
Fixes: 13fa0253d97a ("drm/i915: Use new CRC debugfs API")
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
dri
It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.
Try to remedy this by documenting everything better.
v2: Type fixes Ale
On Fri, Sep 30, 2016 at 09:30:16AM +0530, Archit Taneja wrote:
> Hi Andrezj,
>
> On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
> > SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> > It is controlled via I2C bus. Its interaction with other
> > devices in video pipeline is performed mainl
On Thu, Sep 29, 2016 at 10:48:37PM +0200, Stefan Christ wrote:
> The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> implementations for functions in struct fb_ops. A drm driver can use it
> like:
>
> static struct fb_ops drm_fbdev_cma_ops = {
> .owner =
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/si.c:7850:5: warning: no previous prototype for
'si_vce_send_vcepll_ctlreq' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_dp_mst.c:226:21: warning: no previous prototype
for 'radeon_mst_best_encoder' [-Wmissing-prototy
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_clocks.c:35:10: warning: no previous prototype
for 'radeon_legacy_get_engine_clock' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/atombios_encoders.c:75:1: warning: no previous prototype
for 'atombios_get_backlight
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning: no
previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.c:2052:5: warning: no
previous prototyp
Hello Daniel,
On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
> We already have a fallback in place to fill out the unique from
> dev->unique, which is set to something reasonable in drm_dev_alloc.
>
> Which means we only need to have a special set_busid for pci devices,
> to
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/si.c:7850:5: warning: no previous prototype for
'si_vce_send_vcepll_ctlreq' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_dp_mst.c:226:21: warning: no previous prototype
for 'radeon_mst_best_encoder' [-Wmissing-prototy
We get 10 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:65:6:
warning: no previous prototype for 'cz_phm_is_safe_for_asic_block'
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:71:5:
warning:
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/si.c:908:5: warning: no previous prototype for
'si_pciep_rreg' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/si.c:921:6: warning: no previous prototype for
'si_pciep_wreg' [-Wmissing-prototypes]
In fact, these functi
On 09/30/16 10:28, Hans de Goede wrote:
> Hi,
>
> On 30-09-16 05:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out the unique from
>>> dev->unique, which is set to something reasona
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_device.c:642:6: warning: no previous prototype
for 'radeon_device_is_virtual' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:56:5: warning: no previous prototype for
'radeon_driver_unload_kms' [-Wmissin
On 30.09.2016 12:07, Daniel Vetter wrote:
> On Fri, Sep 30, 2016 at 09:30:16AM +0530, Archit Taneja wrote:
>> Hi Andrezj,
>>
>> On 09/26/2016 07:10 PM, Andrzej Hajda wrote:
>>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
>>> It is controlled via I2C bus. Its interaction with other
>>
2 patches against the xserver which should fix this,
please give them a try.
Regards,
Hans
-- next part --
A non-text attachment was scrubbed...
Name: 0001-xfree86-Make-adding-unclaimed-devices-as-GPU-devices.patch
Type: text/x-patch
Size: 2991 bytes
Desc: not available
URL:
&l
On 30 September 2016 at 10:55, Emil Velikov wrote:
> Hi all
>
> On 30 September 2016 at 04:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out the unique from
>>> dev->unique, which
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Expand the interface
so that driver
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/ea00ccd1/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/3f38563f/attachment.html>
Hi,
On 29 September 2016 at 16:20, Daniel Vetter wrote:
> + * 1. Driver commits new hardware state into vblank-synchronized registes.
> + * 2. A vblank happes, committing the hardware state. Also the corresponding
> + *vblank interrupt is fired off and fully processed by the interrupt
> + *
On 30 September 2016 at 11:55, Daniel Stone wrote:
> Hi,
>
> [...]
... and with that, Reviewed-by: Daniel Stone
Cheers,
Daniel, off to find more coffee
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Expand the interface
so that driver
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.
Suggested-by: Dan
Ah! Here is patch #2. I'm indeed not deeply into the atombios stuff, so
it probably was correct to not CC me :)
Anyway patch is Acked-by: Christian König .
Cheers,
Christian.
Am 30.09.2016 um 10:14 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/rad
On Fri, Sep 30, 2016 at 11:58:42AM +0200, Tomeu Vizoso wrote:
> Add stub for intel_crtc_set_crc_source() and fix arguments of stub for
> intel_display_crc_init().
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
> Fixes: 13fa0253d97a ("drm/i915: U
This one and patch #3 are Reviewed-by: Christian König
.
Where is patch #2? That never made it into my inbox.
Regards,
Christian.
Am 30.09.2016 um 10:13 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/radeon/radeon_clocks.c:35:10: warning: no previo
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the scree
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either ba
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++
1 file changed, 54 insertions(+)
di
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
--- a/a
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59 100644
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/dr
Both patches are Acked-by: Christian König .
Regards,
Christian.
Am 30.09.2016 um 11:58 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning:
> no previous prototype for 'fiji_setup_pwr_virus' [-
Add stub for intel_crtc_set_crc_source() and fix arguments of
intel_display_crc_init().
Signed-off-by: Tomeu Vizoso
Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
Fixes: 13fa0253d97a ("drm/i915: Use new CRC debugfs API")
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers
Hi Shawn,
A couple of fly-by suggestions, which I hope you'll find useful :-)
On 24 September 2016 at 15:26, Shawn Guo wrote:
> +
> + val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
To save some writing/minimise the chances to typos getting, in you can
have single/collect
commit
:: c5454461cd2d25ebddf0a2a2e7360bb3ad5d6eea drm/amd/dal: Register offset
cleanup on Link and Stream Encoder
:: TO: Chris Park
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55095 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/20cde162/attachment-0001.gz>
Why not just use dev->fops->owner instead of changing the interface
everywhere?
Regards,
Christian.
Am 30.09.2016 um 13:44 schrieb Chris Wilson:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
>
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori
Signed-off-by: Bartosz Golaszewski
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
1 file changed,
On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
> Add stub for intel_crtc_set_crc_source() and fix arguments of
> intel_display_crc_init().
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC code")
> Fixes: 13fa0253d97a ("drm/i915: Use new CR
On Fri, 30 Sep 2016, Chris Wilson wrote:
> On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
>> Add stub for intel_crtc_set_crc_source() and fix arguments of
>> intel_display_crc_init().
>>
>> Signed-off-by: Tomeu Vizoso
>> Fixes: 21165bd933ac ("drm/i915/debugfs: Move out pipe CRC co
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- added the new compatible to the bindings documen
2016-09-30 15:00 GMT+02:00 Bartosz Golaszewski :
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
>
> Suggested-by: Sekhar Nori
> Signed-off-by: Bartosz Golaszewski
> --
On Fri, Sep 30, 2016 at 3:19 PM, Jani Nikula
wrote:
> On Fri, 30 Sep 2016, Chris Wilson wrote:
>> On Fri, Sep 30, 2016 at 02:20:30PM +0200, Tomeu Vizoso wrote:
>>> Add stub for intel_crtc_set_crc_source() and fix arguments of
>>> intel_display_crc_init().
>>>
>>> Signed-off-by: Tomeu Vizoso
>>>
dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the de
In order to keep the dmabuf alive whilst the mmap is, we need to hold a
reference to the dmabuf and not the backing object. This is important as
the dmabuf not only keeps the object alive, but also the device so that
dmabuf = vgem_create_dmabuf();
ptr = mmap(... dmabuf ...);
dma_buf may live a long time, longer than the last direct user of the
driver. We already hold a reference to the owner module (that prevents
the object code from disappearing), but there is no reference to the
drm_dev - so the pointers to the driver backend themselves may vanish.
Testcase: igt/vge
> -Original Message-
> From: Baoyou Xie [mailto:baoyou.xie at linaro.org]
> Sent: Friday, September 30, 2016 4:15 AM
> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> arnd at arndb.de; baoyou.xie at
Am 30.09.2016 um 15:59 schrieb Chris Wilson:
> dma_buf_export() adds a reference to the owning module to the dmabuf (to
> prevent the driver from being unloaded whilst a third party still refers
> to the dmabuf). However, drm_gem_prime_export() was passing its own
> THIS_MODULE (i.e. drm.ko) rather
https://bugs.freedesktop.org/show_bug.cgi?id=97986
Bug ID: 97986
Summary: sony vaio with ati graphics flashing flikering
Product: Mesa
Version: 12.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
Our planes cannot be set at negative coordinates. Make sure we reject such
configuration.
Reported-by: Boris Brezillon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/d
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/8aa0eb9b/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/861d3034/attachment.html>
Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any i
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/dr
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either ba
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
--- a/a
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59 100644
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++
1 file changed, 54 insertions(+)
di
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b2218154/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/eb809b0d/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/20160930/332fc9f8/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/f078a8a5/attachment.html>
ttachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/235d14d8/attachment-0001.html>
Hi,
On 30-09-16 16:51, Laszlo Ersek wrote:
> On 09/30/16 12:35, Hans de Goede wrote:
>
>> Attached are 2 patches against the xserver which should fix this,
>> please give them a try.
>
> Sorry about the delay.
>
> The patches don't seem to fix the issue for me. Please see the Xorg log
> attached.
d...
Name: .config.gz
Type: application/gzip
Size: 6406 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/e102f731/attachment.gz>
vel/attachments/20160930/e246dcb1/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/11d405d8/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b3541e16/attachment.html>
RL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/7cdf37e2/attachment.html>
ng 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/20160930/8a10f495/attachment.html>
On Fri, 30 Sep 2016 16:33:20 +0200
Maxime Ripard wrote:
> Our planes cannot be set at negative coordinates. Make sure we reject such
> configuration.
>
> Reported-by: Boris Brezillon
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +++
> 1 file changed, 3 insert
On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> On Fri, 30 Sep 2016 16:33:20 +0200
> Maxime Ripard wrote:
>
> > Our planes cannot be set at negative coordinates. Make sure we reject such
> > configuration.
> >
> > Reported-by: Boris Brezillon
> > Signed-off-by: Maxime Ripard
> -Original Message-
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, September 30, 2016 12:21 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: Arnd Bergmann; David Airlie; Zhou, Jammy; Zhu, Rex; dri-
> devel at lists.freedesktop.org; linux-kernel at vger.kernel.org
> Sub
Using the newly exported amd_set_clockgating_by_smu function in the main amdgpu
driver
means that we can no longer build the driver without also enabling the powerplay
component, otherwise we get this link error:
ERROR: "amd_set_clockgating_by_smu" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefine
On 2016-09-28 01:24, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
>
> Split the DCU regs into "regs", "palette", "gamma" and "cursor".
> Create a second regmap for gamma memory space using little
On Fri, 30 Sep 2016 19:22:11 +0300
Ville Syrjälä wrote:
> On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> > On Fri, 30 Sep 2016 16:33:20 +0200
> > Maxime Ripard wrote:
> >
> > > Our planes cannot be set at negative coordinates. Make sure we reject such
> > > configuration
Hi,
On 30-09-16 17:33, Laszlo Ersek wrote:
> On 09/30/16 16:59, Hans de Goede wrote:
>> Hi,
>>
>> On 30-09-16 16:51, Laszlo Ersek wrote:
>>> On 09/30/16 12:35, Hans de Goede wrote:
>>>
Attached are 2 patches against the xserver which should fix this,
please give them a try.
>>>
>>> Sorry
On Fri, Sep 30, 2016 at 7:52 AM, Christian König
wrote:
> This one and patch #3 are Reviewed-by: Christian König
> .
>
Applied 1 and 3, thanks!
Alex
> Where is patch #2? That never made it into my inbox.
>
> Regards,
> Christian.
>
>
> Am 30.09.2016 um 10:13 schrieb Baoyou Xie:
>>
>> We get a
On Fri, Sep 30, 2016 at 8:16 AM, Christian König
wrote:
> Both patches are Acked-by: Christian König .
Applied patch 1. I'd like to get Rex's ack on patch 2 before applying it.
Alex
>
> Regards,
> Christian.
>
>
> Am 30.09.2016 um 11:58 schrieb Baoyou Xie:
>>
>> We get a few warnings when bu
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/5d7bdf7e/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160930/a1a76c82/attachment.html>
On Fri, Sep 30, 2016 at 06:33:48PM +0200, Boris Brezillon wrote:
> On Fri, 30 Sep 2016 19:22:11 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Sep 30, 2016 at 06:08:26PM +0200, Boris Brezillon wrote:
> > > On Fri, 30 Sep 2016 16:33:20 +0200
> > > Maxime Ripard wrote:
> > >
> > > > Our planes ca
)
v2: merge codepaths where possible
--
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/20160930/166fe652/attachment.html>
ectly.
--
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/20160930/27751e54/attachment.html>
ll keep looking.
--
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/20160930/525894d9/attachment-0001.html>
From: Yakir Yang
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.
Signed-off-by: Yakir Yang
Signed-off-by: Zain Wang
---
Changes in v2: None
drivers/gpu/drm/bridge/analogi
1 - 100 of 110 matches
Mail list logo
