On 07/09/16 18:03, Dave Gordon wrote:
> On 06/09/16 21:36, Nicolas Iooss wrote:
>> On 06/09/16 12:21, Dave Gordon wrote:
>>> On 04/09/16 19:58, Nicolas Iooss wrote:
When building the kernel with clang and some warning flags, the
compiler
reports that the return value of dcs_get_backl
amdgpu-kms uses shared fences for its prime exported dmabufs,
instead of an exclusive fence. Therefore we need to wait for
all fences of the dmabuf reservation object to prevent
unsynchronized rendering and flipping.
This patch was tested to behave properly with intel-kms +
radeon/amdgpu/nouveau-k
On Wed, 2016-09-07 at 15:37 +0300, Jani Nikula wrote:
> On Sun, 04 Sep 2016, Dominik Brodowski wrote:
> > Hi!
> >
> > Since commit 1c80c25fb6 (determined by git bisect, and confirmed by
> > reverting this patch on top of 9ca581b50d), the sceen on my DELL XPS 13
> > is flickering every once in a wh
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
9909113cc48a ("drm/i915/gen9: Only copy WM results for changed pipes to
skl_hw")
from Linus' tree and commits:
2722efb90b34 ("drm/i915/gen9: Only copy WM results fo
On 08/09/16 02:23 AM, Imre Deak wrote:
> This fixes the error path for platforms that don't define the new
> page_flip_target() hook.
>
> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
> Testcase: igt/kms_flip/basic-flip-vs-dpms
> CC: Michel Dänzer
> Signed-off-by: Imre Deak
> --
From: Tomeu Vizoso
Remove code for reading the EDID and DPCD fields and use the helpers
instead.
Besides the obvious code reduction, other helpers are being added to the
core that could be used in this driver and will be good to be able to
use them instead of duplicating them.
Signed-off-by: To
Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
function, or printing the error Sink PSR state if we failed to effect
the request PSR setting.
Signed-off-by: Yakir Yang
---
Changes in v2:
- A bunch of good fixes from Sean
drivers/gpu/drm/bridge/analogix/analogix_dp_co
Hi Jani,
2016-09-07 17:34 GMT+09:00 Jani Nikula :
> On Wed, 07 Sep 2016, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>>
>> Signed-off-by: Masahiro Yamada
>
> ...
>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 95ddd56..59
On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
> amdgpu-kms uses shared fences for its prime exported dmabufs,
> instead of an exclusive fence. Therefore we need to wait for
> all fences of the dmabuf reservation object to prevent
> unsynchronized rendering and flipping.
No. Fix th
sa or even lower in the stack. Reassigning to
Mesa for now.
--
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/20160908/2a5eb1
On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote:
> In previous drm_global_item_ref, there are two times of writing
> ref->object if item->refcount is 0. So this patch does a minor update
> to put alloc and init ref firstly, and then to modify the item of glob
> array. Use "else" to avoid
Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
>
> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
> Oops because Connector 0 (LCD Panel interface) does not have DDC.
I'm not an expert on this, but that is really odd cause even LCD Panels
should have a DDC interface.
>
> Ubun
|--- |FIXED
--
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/20160908/d43fb769/attachment-0001.html>
>
> > diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> > b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> > index 63ec2a6..1b1321a 100644
> > --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> > +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> >
On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
> On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote:
> > In previous drm_global_item_ref, there are two times of writing
> > ref->object if item->refcount is 0. So this patch does a minor update
> > to put alloc and init ref firs
Am 08.09.2016 um 04:07 schrieb Huang Rui:
> In previous drm_global_item_ref, there are two times of writing
> ref->object if item->refcount is 0. So this patch does a minor update
> to put alloc and init ref firstly, and then to modify the item of glob
> array. Use "else" to avoid two times of writ
after fixing it.
I did while applying, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/eeaaa040/attachment.sig>
On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote:
> On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
> > On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote:
> > > In previous drm_global_item_ref, there are two times of writing
> > > ref->object if item->refcount is 0. S
Am 08.09.2016 um 09:35 schrieb Chris Wilson:
> On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote:
>> On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
>>> On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote:
In previous drm_global_item_ref, there are two times of writ
On Thu, Sep 08, 2016 at 09:43:52AM +0200, Christian König wrote:
> Am 08.09.2016 um 09:35 schrieb Chris Wilson:
> >On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote:
> >>On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
> >>>On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui w
Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/a
On Thu, 08 Sep 2016, Michel Dänzer wrote:
> On 08/09/16 02:23 AM, Imre Deak wrote:
>> This fixes the error path for platforms that don't define the new
>> page_flip_target() hook.
>>
>> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
>> Testcase: igt/kms_flip/basic-flip-vs-dpms
>>
Hi Dave, some i915 fixes for v4.8.
BR,
Jani.
The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:
Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-09-08
for you to f
k at all.
--
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/20160908/b2e1ad29/attachment.html>
Hi Dave -
Here's a drm-misc pull request mainly to get some fixes moving forward.
BR,
Jani.
The following changes since commit 2b2fd56d7e92f134ecaae5c89e20f64dd0f95aa2:
Revert "drm: make DRI1 drivers depend on BROKEN" (2016-09-01 06:16:12 +1000)
are available in the git repository at:
gi
[Trimming down the CC list]
Hi Baoyou,
On 7 September 2016 at 12:05, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
As you're going through DRM I was wondering if you have a rough number
of warnings we get at the various W levels 1,2,...
Hope you'll have the time/interest
l of this though.
I'm very happy to hear the idea has support!
Thanks,
pq
> I'd like to add that the X11 Present extension specification already
> includes support for specifying a target time instead of a target
> refresh cycle. This isn't implemented yet though, but it should be
> relatively straightforward to implement using the kind of kernel API you
> describe.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/060525fe/attachment.sig>
--- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/d7268678/attachment-0001.sig>
ePAPR clearly
documents the underscore as being a valid character for the node
names.
I'll change the few inconsistencies though.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/aae07d1e/attachment.sig>
On Thursday, September 8, 2016 10:35:17 AM CEST Emil Velikov wrote:
> On 7 September 2016 at 12:05, Baoyou Xie wrote:
> > We get 2 warnings when building kernel with W=1:
> As you're going through DRM I was wondering if you have a rough number
> of warnings we get at the various W levels 1,2,...
Acked-by: Benjamin Gaignard
2016-09-07 13:05 GMT+02:00 Baoyou Xie :
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/sti/sti_mixer.c:361:6: warning: no previous prototype for
> 'sti_mixer_set_matrix' [-Wmissing-prototypes]
> drivers/gpu/drm/sti/sti_dvo.c:109:5: warning: no pr
On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote:
> On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote:
> > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote:
> > > Actually I just cooked up another branch [2]. It just throws in some
> > > memory barriers to
Am 08.09.2016 um 11:09 schrieb Mark Fortescue:
> Hi Christian,
>
> Thank you for the feedback.
>
> On 08/09/16 08:14, Christian König wrote:
>> Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
>>>
>>> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
>>> Oops because Connector 0 (LC
Property lifetimes are equal to the device lifetime, so the separate
drm_property_find is not needed. The pointer can be retrieved from
the properties member, which saves us some locking and a extra lookup.
The lifetime for properties is until the device is destroyed, which
happens late in the devi
nning the script as well so you will also see files prefixed with
just screens-0-5-good in such a case.
Let me know what else I can do to help.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed..
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/6f5680a0/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/bbef4d4e/attachment.html>
> -Original Message-
> From: Jim Bride [mailto:jim.bride at linux.intel.com]
> Sent: Thursday, September 8, 2016 12:20 AM
> To: Kahola, Mika
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> ville.syrjala at linux.intel.com; daniel.vetter at ffwll.ch
> Subje
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
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot
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
Thanks for the review. I'll fix those indentations.
> -Original Message-
> From: Jim Bride [mailto:jim.bride at linux.intel.com]
> Sent: Thursday, September 8, 2016 12:27 AM
> To: Kahola, Mika
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> ville.syrjala at
On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> Respect max TMDS clock frequency from DPCD for active
> DP to HDMI adapters.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
> 2
Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/1db356f3/attachment.sig>
On 09/08/16 14:08, Baoyou Xie wrote:
> We get 4 warnings when building kernel with W=1:
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:393:12: warning: no previous prototype
> for 'tilcdc_tfp410_init' [-Wmissing-prototypes]
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:398:13: warning: no previous prototype
On 09/08/16 14:29, Baoyou Xie wrote:
> We get 3 warnings when building kernel with W=1:
> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:142:29: warning: no previous
> prototype for 'tilcdc_get_overlay' [-Wmissing-prototypes]
> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:198:13: warning: no previou
On Wed, Aug 17, 2016 at 01:49:39PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported pixel rate
> for DisplayPort legay VGA converter or TMDS clock rate
> for other digital legacy converters. The helper returns
> clock rate in kHz.
>
> v2: Return early if detailed port cap i
On Wed, Aug 17, 2016 at 01:49:40PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported bits per
> component for DisplayPort legay converters.
>
> v2: Return early if detailed port cap info is not available.
> Replace if-else ladder with switch-case (Ville)
>
> Reviewed-by
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Thursday, September 8, 2016 4:02 PM
> To: Kahola, Mika
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> jim.bride at linux.intel.com; daniel.vetter at ffwll.ch
> S
Hi Tomeu,
A couple of small nitpicks and a rather nasty looking bug, related to
your earlier question.
On 7 September 2016 at 11:27, Tomeu Vizoso
wrote:
> +static ssize_t crc_control_write(struct file *file, const char __user *ubuf,
> +size_t len, loff_t *offp)
Hi Tomeu,
Just a couple of nitpicks. Nothing that has to be fixed or (if you
agree) cannot be done on top/later on.
On 7 September 2016 at 11:27, Tomeu Vizoso
wrote:
> The core provides now an ABI to userspace for generation of frame CRCs,
> so implement the ->set_crc_source() callback and reus
On 7 September 2016 at 11:27, Tomeu Vizoso
wrote:
> Hi,
>
> this series basically takes the facility for continuously capturing CRCs
> of frames from the i915 driver and into the DRM core.
>
> The idea is that test suites such as IGT use this information to check
> that frames that are exected to
ivers v1.17
xserver v1.17.4
KDE Plasma 5 (kwin)
If you need any further info please ask.
--
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-deve
From: Christian König
Makes more sense to keep that together.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h| 32 +---
include/drm/ttm/ttm_placement.h | 35 +++
2 files changed, 36 insertions(+), 31 deletions(-)
From: Christian König
Either never used or not used in quite a while.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
include/drm/ttm/ttm_placement.h | 19 ---
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_b
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/0e0363fb/attachment.html>
Hello Daniel and Ville,
On Thursday 09 Jun 2016 17:13:15 Ville Syrjälä wrote:
> On Thu, Jun 09, 2016 at 03:29:10PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 04:05:11PM +0300, Ville Syrjälä wrote:
> >> On Thu, Jun 09, 2016 at 02:40:28PM +0200, Daniel Vetter wrote:
> >>> On Thu, Ju
On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang wrote:
> From: Tomeu Vizoso
>
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
> Besides the obvious code reduction, other helpers are being added to the
> core that could be used in this driver and will be good to be
On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang wrote:
> Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
> function, or printing the error Sink PSR state if we failed to effect
> the request PSR setting.
>
Let's change to:
Make sure the request PSR state takes effect in a
On 08/09/16 00:02, Nicolas Iooss wrote:
> On 07/09/16 18:03, Dave Gordon wrote:
>> On 06/09/16 21:36, Nicolas Iooss wrote:
>>> On 06/09/16 12:21, Dave Gordon wrote:
On 04/09/16 19:58, Nicolas Iooss wrote:
> When building the kernel with clang and some warning flags, the
> compiler
Hello,
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to access
more than a single parameter of the format, leading to inefficiencies due
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to mult
Turn the drm_format_*() helpers into wrappers around the drm_format_info
lookup function to centralize all format information in a single place.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fourcc.c | 186 +--
1 file changed, 37 insertions(+), 1
The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.
The
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
Acked-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_gdp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Cc: Benjamin Gaign
Replace calls to the drm_format_*() helper functions with direct use of
the drm_format_info structure. This improves efficiency by removing
duplicate lookups.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fb_cma_helper.c | 23
drivers/gpu/drm/drm_framebuffer.c | 102 +--
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Cc: Liviu Dudau
d
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
In the tilcdc_crtc_mode_set() function compute the hardware register
value directly from the pixel format instead of computing the number of
bits per pixels first.
Signed-o
The driver doesn't need the color depth, only the number of bits per
pixel. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +++---
drivers/gpu/drm/cirrus/cirrus_main.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
Cc: Dave Airlie
The driver uses drm_fb_get_bpp_depth() to check whether it can support
the format requested by userspace when creating a framebuffer. This
isn't the right API, as it doesn't differentiate between RGB formats
other than on a depth and bpp basis.
Fixing this requires non trivial changes to the drive
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Renamed bpp to cpp
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 14 +++---
drivers/gpu/drm/amd/amdgpu/amd
The driver needs the number of bytes per pixel, not the bpp and depth
info meant for fbdev compatibility. Use the right API.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Renamed bpp to cpp
---
drivers/gpu/drm/radeon/radeon_fb.c | 20 ++--
drivers/gpu/drm/radeon/radeo
The driver doesn't need the color depth, only the number of bits per
pixel. Use the right API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arm/malidp_hw.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malid
The function is only used by the drm_helper_mode_fill_fb_struct() core
function to fill the drm_framebuffer bpp and depth fields, used by
drivers that haven't been converted to use pixel formats directly yet.
It should not be used by new drivers, so inline it in its only caller.
Signed-off-by: Lau
The driver is the last users of the drm_fb_get_bpp_depth() function. It
should ideally be converted to use struct drm_mode_fb_cmd2 instead of
the legacy struct drm_mode_fb_cmd internally, but that will require
broad changes across the code base. As a first step, replace
drm_fb_get_bpp_depth() with
Hi Liviu,
On Monday 25 Jul 2016 12:10:24 Liviu Dudau wrote:
> On Thu, Jun 09, 2016 at 10:01:40AM +0100, Liviu Dudau wrote:
> > On Thu, Jun 09, 2016 at 02:32:12AM +0300, Laurent Pinchart wrote:
> > > The driver needs the number of bytes per pixel, not the bpp and depth
> > > info meant for fbdev co
Hi,
this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.
The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.
Other drivers fo
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
Signed-off-by: Tomeu Vizo
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
b
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong v
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+
On 8 September 2016 at 15:35, Emil Velikov wrote:
> Hi Tomeu,
>
> Just a couple of nitpicks. Nothing that has to be fixed or (if you
> agree) cannot be done on top/later on.
>
> On 7 September 2016 at 11:27, Tomeu Vizoso
> wrote:
>> The core provides now an ABI to userspace for generation of fra
On 8 September 2016 at 15:24, Emil Velikov wrote:
> Hi Tomeu,
>
> A couple of small nitpicks and a rather nasty looking bug, related to
> your earlier question.
>
> On 7 September 2016 at 11:27, Tomeu Vizoso
> wrote:
>
>> +static ssize_t crc_control_write(struct file *file, const char __user *ub
On 8 September 2016 at 15:49, Tomeu Vizoso
wrote:
> On 8 September 2016 at 15:24, Emil Velikov
> wrote:
>> Hi Tomeu,
>>
>> A couple of small nitpicks and a rather nasty looking bug, related to
>> your earlier question.
>>
>> On 7 September 2016 at 11:27, Tomeu Vizoso
>> wrote:
>>
>>> +static
On 09/08/2016 08:30 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
>> amdgpu-kms uses shared fences for its prime exported dmabufs,
>> instead of an exclusive fence. Therefore we need to wait for
>> all fences of the dmabuf reservation object to prevent
>>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/502e205c/attachment-0001.html>
On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> On 09/08/2016 08:30 AM, Chris Wilson wrote:
> >On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
> >>amdgpu-kms uses shared fences for its prime exported dmabufs,
> >>instead of an exclusive fence. Therefore we need to wa
that will help.
--
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/20160908/6e3dd999/attachment.html>
On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner
wrote:
> Hi Emil,
>
> thanks a lot for the review.
>
> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>> On 30 August 2016 at 08:14, Christian Gmeiner
>> wrote:
>>> From: The etnaviv authors
>>>
>>> Add the libdrm_etnaviv helper library to encapsulate
On Thu, Sep 8, 2016 at 1:52 PM, Rob Herring wrote:
> On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner
> wrote:
>> Hi Emil,
>>
>> thanks a lot for the review.
>>
>> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>>> On 30 August 2016 at 08:14, Christian Gmeiner
>>> wrote:
From: The etnaviv autho
;https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/3317dcfb/attachment.sig>
Hi Rob,
2016-09-08 20:52 GMT+02:00 Rob Herring :
> On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner
> wrote:
>> Hi Emil,
>>
>> thanks a lot for the review.
>>
>> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>>> On 30 August 2016 at 08:14, Christian Gmeiner
>>> wrote:
From: The etnaviv authors
On Wed, 07 Sep 2016 15:26:14 -0700 Dan Williams
wrote:
> track_pfn_insert() in vmf_insert_pfn_pmd() is marking dax mappings as
> uncacheable rendering them impractical for application usage. DAX-pte
> mappings are cached and the goal of establishing DAX-pmd mappings is to
> attain more performa
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/0ec6fe45/attachment.html>
Component|DRM/amdkfd |/dev/null
--
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/20160908/5f117cf4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #46 from Teofilis Martisius ---
Created attachment 232761
--> https://bugzilla.kernel.org/attachment.cgi?id=232761&action=edit
dmesg output from 4.8-rc4 when turning OFF dGPU via vgaswitcheroo
--
You are receiving this mail because
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #47 from Teofilis Martisius ---
Created attachment 232771
--> https://bugzilla.kernel.org/attachment.cgi?id=232771&action=edit
dmesg output from 4.8-rc4 with RADEON_PX_QUIRK_DISABLE_PX quirks removed
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #48 from Teofilis Martisius ---
Hi,
I ran two tests over the weekend.
First, I tried booting up stock 4.8-rc4. glxgears runs fine both on APU and
dGPU. But it fails when I try to turn OFF my dGPU by doing:
echo OFF >/sys/kernel/deb
1 - 100 of 115 matches
Mail list logo
