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>
turn off Main-link and power down eDP PHY when enable psr,
turn on Main-link and power up eDP PHY when disable psr.
Signed-off-by: zain wang
---
Changes in v2:
- misc changes
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 124 -
1 file changed, 70 insertions(+), 54
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
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>
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>
Signed-off-by: zain wang
---
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b4ce16a..1bd190e 100644
---
When disabled bridge, analogix_dp_enable_psr() may run due to timer was set
by rockchip_drm_do_flush(), in this case we should return -EBUSY.
Signed-off-by: zain wang
---
Changes in v2:
- add spin_lock to protect dpms_mode
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 43
1. prevent runing enable_psr when disabled bridge
2. get sync PM when init eDP
3. detect Sink PSR state after configuring the PSR
4. switch Main-Link and eDP phy when enable/disable psr
BR,
- Zain
Changes in v2:
- add spin_lock to protect dpms_mode
- misc changes
Yakir Yang (1):
drm/bridge:
sis, I did the following:
- I downgraded my xorg-x11-server installation to the most recent
official F24 packages, that is, "1.18.4-4.fc24",
- I kept the kernel that I built exactly at the regressive commit
(a325725633c2)
- I modified "01-resolution.conf" (see it above in the context) like this:
Section "Device"
Identifier "Default Device"
Driver "modesetting"
BusID "PCI:00:02:0" < new option added
EndSection
where BusID matches the B/D/F of the virtio-vga device from "lspci".
This setup (modulo the kernel of course) was known to work, but now the
X server actually segfaults (apparently in the
xf86PlatformDeviceCheckBusID() function). Please find the logfile attached.
(NB: this is unrelated to upstream commit de9ce6757c2e -- which the
pristine FC24 build lacks -- because I don't set AutoAddGPU to "off" --
it is left at its default "on" value.)
Therefore, you are right. :)
Thanks
Laszlo
> I made the mistake of thinking the kernel change was re-triggering
> the old problem Laszlo fixed, but that does not seem to be the
> case.
>
> Regards,
>
> Hans
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 4610 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/920def26/attachment-0001.bin>
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
On Friday 30 September 2016 06:30 PM, Bartosz Golaszewski wrote:
> 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
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160930/a1a76c82/attachment.html>
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.
>>>
>>>
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
> > >
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]
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
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
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
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:
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/5d7bdf7e/attachment.html>
"modesetting"
EndSection
Section "Monitor"
Identifier "Default Monitor"
Option "PreferredMode" "640x480"
# Option "PreferredMode" "1440x900"
EndSection
I removed these files now, and repeated the test. Again, the X server
wouldn't start, but I think the log file looks a bit different now.
Attached.
> Anyways, Monday is another day we can look at this ...
Sure; many thanks!
Laszlo
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 5691 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/bc32f18d/attachment-0001.bin>
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) <<
This fix allows to play audio while HDMI is disconnected.
When HDMI is disable, audio configuration is stored and samples
are dropped (by HDMI IP).
When HDMI is enabled, audio HDMI configuration is applied and samples
are outputted on HDMI wire.
Signed-off-by: Arnaud Pouliquen
---
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.
ext/x-log
Size: 4117 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/e8754f80/attachment.bin>
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
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
---
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(+)
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
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
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
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
> -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
>
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)
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
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'
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'
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'
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
---
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>
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
>>>
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
>
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
-
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/8a10f495/attachment.html>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/7cdf37e2/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b3541e16/attachment.html>
The series is
Tested-by: Petri Latvala
On 09/30/2016 02:44 PM, Chris Wilson wrote:
> 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
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/11d405d8/attachment.html>
vel/attachments/20160930/e246dcb1/attachment.html>
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,
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:
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
ttachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/235d14d8/attachment-0001.html>
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
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/f078a8a5/attachment.html>
ou 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>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/eb809b0d/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/b2218154/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/861d3034/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/8aa0eb9b/attachment.html>
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
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
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 +-
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'
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
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
---
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(+)
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
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
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
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
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:
>
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
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
> -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
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
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
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:
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:
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
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
h 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:
<https://lists.freedesktop.org/arc
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
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 =
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
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
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
On Thu, Sep 29, 2016 at 11:58 PM, Marek Vasut wrote:
> + /**
> +* @prepare_fb:
> +*
> +* Optional, called by struct _plane_helper_funcs ->prepare_fb .
> +*/
You've lost the hint that people should look there for what this hook
should do. Same with
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 +-
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
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 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
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,
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
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
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
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 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
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160930/3f38563f/attachment.html>
1 - 100 of 112 matches
Mail list logo