https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #294 from Kyle K ---
Hello,
I have been having problem with my HD6870 for some time. I experienced it on
4.7/4.8/4.9 kernels (haven't tested earlier). My HD6870 works great out of the
box with DPM enabled, I do not have any issues fo
It's unused.
Suggested-by: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/drm/drm_fourcc.h | 2 --
drivers/gpu/drm/drm_fourcc.c | 3 +--
drivers/gpu/drm/drm_framebuffer.c | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b
While working on graphics support for virtual machines on ppc64 (which
exists in both little and big endian variants) I've figured the comments
for various drm fourcc formats in the header file don't match reality.
Comments says the RGB formats are little endian, but in practice they
are native en
On Fri, 21 Apr 2017 09:58:24 +0200
Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says t
https://bugs.freedesktop.org/show_bug.cgi?id=100375
--- Comment #5 from Michel Dänzer ---
(In reply to Edward O'Callaghan from comment #4)
> The actual root causes is that if a page flip is in progress something races
> on that fd and causes the null ptr deref:
How did you determine that it's re
On Thu, 20 Apr 2017, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Adding DPCD register definitions from the DP 1.3 specification for CEC
> over AUX support.
>
> V2: Add DP_ prefix to all defines.
> V3: missed prefixes from the ESI1 defines
>
> Cc: Jani Nikula
>
> Reviewed-by: Jani N
Hi Chris,
On Friday 21 Apr 2017 00:08:21 Chris Wilson wrote:
> On Fri, Apr 21, 2017 at 12:33:59AM +0300, Laurent Pinchart wrote:
> > To ensure that neither the GEM object nor the DRM device goes away while
> > a GEM object exported through dma-buf is still accessible, take a
> > reference to both
On 20/04/17 06:56 PM, Masahiro Yamada wrote:
> Include instead of relative path from include/drm, then
> remove the -Iinclude/drm compiler flag.
>
> The fixes of include/drm/ttm/*.h will help driver Makefiles drop
> -Iinclude/drm flag.
>
> Signed-off-by: Masahiro Yamada
[...]
> diff --git a/i
On 20/04/17 06:56 PM, Masahiro Yamada wrote:
> Include instead of relative path from include/drm, then
> remove the -Iinclude/drm compiler flag.
>
> Signed-off-by: Masahiro Yamada
This patch and patch 12 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
From: Mihail Atanassov
All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/ar
From: Mihail Atanassov
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simpl
From: Mihail Atanassov
Enable the scaling engine for upscaling a single plane using the polyphase
scaler. No image enhancement support or downscaling yet*, and composition
result scaling is not implemented.
* Downscaling a plane requires mclk > pxlclk.
Signed-off-by: Mihail Atanassov
Signed-of
From: Mihail Atanassov
Now that we are using a custom plane state in mali-dp, we need a
bespoke reset that takes into account the larger structure.
Signed-off-by: Mihail Atanassov
[Updated commit message]
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 23
Add a core_id file in the driver's sysfs directory,
exposing the hardware CORE ID. This is useful to allow
userspace to discover the hardware version used.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 35 +++
d
Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 14 -
drivers/gpu/drm/arm/malidp_drv.c | 128
From: Arnd Bergmann
The newly introduced function causes a harmless build warning:
drivers/gpu/drm/arm/malidp_planes.c: In function
'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp'
[-Werror=unused-variable]
The variable serves no purpos
Hello,
This is not a topic series, but a collection of patches that I have acked
previously on the dri-devel list and I now plan to push to drm-next. I have
rebased on the latest drm-next from 20/04 and also cleaned up some comments
compared to what has been already pushed into the mailing list.
From: Mihail Atanassov
Add a custom CRTC state struct to enable storing driver's private
state. This patch only adds the base drm_crtc_state struct and
the atomic functions that handle it.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 52 ++
Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 12
1 file changed, 8 in
From: Mihail Atanassov
When downscaling, mclk needs to be sufficiently higher than pxlclk in
order to be able to fetch the higher-resolution data and produce output
pixels. When not scaling, or when upscaling, mclk can be equal to
pxlclk. Since the driver doesn't control mclk, just ensure that th
From: Mihail Atanassov
Add function to dump the state of the plane.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/
From: Mihail Atanassov
Apply image enhacement when we are upscaling by a factor of 2
or more in either direction.
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 7 ++-
drivers/gpu/drm/arm/malidp_drv.c | 3 +++
drivers/gpu/drm/arm/mali
On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments s
Hi,
> > Leaving the yuv formats as-is. I have no idea if and how those are used
> > on bigendian machines.
> just an idea - since we are not sure how the remaining formats are being
> used, should those be marked somehow uncertain whether they are little
> or native endian?
ATM the yuv don't
On Fri, Apr 21, 2017 at 11:38:28AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Leaving the yuv formats as-is. I have no idea if and how those are used
> > > on bigendian machines.
>
> > just an idea - since we are not sure how the remaining formats are being
> > used, should those be marked some
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> > for various drm fourcc
Add standard properties to control YCbCr to RGB conversion in DRM
planes. The created properties are stored to drm_plane object to allow
different set of supported conversion modes for different planes on
the device. For simplicity the related property blobs for CSC matrix
and YCbCr preoffsets are
The series adds plane specific atomic properties to control YCbCr to
RGB conversions. My intention was to try to implement the plane
specific (before DEGAMMA) part of the suggestion in this dri-devel
post:
https://lists.freedesktop.org/archives/dri-devel/2017-March/135870.html
This series may not
Adds support for YCBCR_TO_RGB_MODE and YCBCR_TO_RGB_CSC properties to
omap_plane.c and dispc.c. The supported CSC presets are:
- YCbCt BT.601 limited range to RGB BT.601 full range
- YCbCt BT.601 full range to RGB BT.601 full range
- YCbCt BT.709 limited range to RGB BT.709 full range
Custom CSC
Change drm_atomic_replace_property_blob_from_id()'s first parameter
from drm_crtc to drm_device, so that the function can be used for other
drm_mode_objects too.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_atomic.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --gi
From: Tomi Valkeinen
At the moment the driver always uses limited range when doing YUV-RGB
conversions. This patch adds full-range tables, and makes the code to
always use full-range tables.
In the future we should allow the user to select the color range instead
of hardcoding it.
Signed-off-by
Signed-off-by: Jyri Sarha
---
include/drm/drm_color_mgmt.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index bce4a53..03a59cb 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#in
From: Tomi Valkeinen
The setup code for color space conversion is a bit messy. This patch
cleans it up.
For some reason the TRM uses values in YCrCb order, which is also used
in the current driver, whereas everywhere else it's YCbCr (which also
matches YUV order). This patch changes the tables t
This code causes a static checker warning because it treats "i == 0" as
a timeout but, because it's a post-op, the loop actually ends with "i"
set to -1. Philipp Zabel points out that it would be cleaner to use
readl_poll_timeout() instead.
Fixes: 21898816831f ("drm/mediatek: add dsi transfer fun
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > While working on graphics support for virtual machines on ppc64 (which
> > > exists in both little and big
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > While working on graphics support for virtual machines on ppc64 (which
> > > exists in both little and big
On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> Add standard properties to control YCbCr to RGB conversion in DRM
> planes. The created properties are stored to drm_plane object to allow
> different set of supported conversion modes for different planes on
> the device. For simplicity
On Fri, 21 Apr 2017 14:08:04 +0300
Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > > While working on graphics support fo
Hi,
> > I personally find "native" more intuitive, but at the end of the day I
> > don't mind much. If people prefer "host" over "native" I'll change it.
>
> "native" to me feels more like "native to the GPU" since these things
> really are tied to the GPU not the CPU.
Ok, then maybe "host" i
Hi Jyri,
Thank you for the patch
On Friday 21 Apr 2017 12:51:12 Jyri Sarha wrote:
No commit message ?
> Signed-off-by: Jyri Sarha
Apart from that,
Reviewed-by: Laurent Pinchart
> ---
> include/drm/drm_color_mgmt.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/drm/drm
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:13 Jyri Sarha wrote:
> Change drm_atomic_replace_property_blob_from_id()'s first parameter
> from drm_crtc to drm_device, so that the function can be used for other
> drm_mode_objects too.
>
> Signed-off-by: Jyri Sarha
Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=100058
--- Comment #12 from Edward O'Callaghan ---
@Alex Deucher I confirmed with Adam that, even with c10c8f7 he still has the
null pointer issue.
--
You are receiving this mail because:
You are the assignee for the bug._
On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote:
> On Fri, 21 Apr 2017 14:08:04 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 21, 2017 at 09:58:24A
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:15 Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> The setup code for color space conversion is a bit messy. This patch
> cleans it up.
>
> For some reason the TRM uses values in YCrCb order, which is also used
> in the current driver,
Hi Jyri,
Thank you for the patch.
On Friday 21 Apr 2017 12:51:16 Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> At the moment the driver always uses limited range when doing YUV-RGB
> conversions. This patch adds full-range tables, and makes the code to
> always use full-range tables.
>
> In the
Am 21.04.2017 um 13:08 schrieb Ville Syrjälä:
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
While working on graphics support for virtual machines on ppc64 (wh
Hello,
CC'ing Hans Verkuil for his knowledge on colorspace.
On Friday 21 Apr 2017 14:17:56 Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> > Add standard properties to control YCbCr to RGB conversion in DRM
> > planes. The created properties are stored to drm_
Am 21.04.2017 um 13:49 schrieb Ville Syrjälä:
On Fri, Apr 21, 2017 at 02:40:18PM +0300, Pekka Paalanen wrote:
On Fri, 21 Apr 2017 14:08:04 +0300
Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
On Fri,
https://bugs.freedesktop.org/show_bug.cgi?id=100058
--- Comment #13 from Edward O'Callaghan ---
Created attachment 130967
--> https://bugs.freedesktop.org/attachment.cgi?id=130967&action=edit
dpm patch
@Adam, please try applying the attached patch and let me know if it helps with
your issue?
https://bugs.freedesktop.org/show_bug.cgi?id=99368
--- Comment #6 from Adam Bolte ---
I'm seeing this too. Running a BenQ XL2730Z (2560x1440@144Hz) gaming monitor,
but some games (eg. Prototype 2 under Wine, Saints Row 2) only accept
resolutions up to 1920x1080. They cause GPU scaling to automati
Regards
Shashank
On 4/21/2017 3:21 PM, Jyri Sarha wrote:
The series adds plane specific atomic properties to control YCbCr to
RGB conversions. My intention was to try to implement the plane
specific (before DEGAMMA) part of the suggestion in this dri-devel
post:
I would probably extend this se
Regards
Shashank
On 4/21/2017 4:47 PM, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
Add standard properties to control YCbCr to RGB conversion in DRM
planes. The created properties are stored to drm_plane object to allow
different set of supported conversio
On Fri, Apr 21, 2017 at 03:10:31PM +0300, Laurent Pinchart wrote:
> Hello,
>
> CC'ing Hans Verkuil for his knowledge on colorspace.
>
> On Friday 21 Apr 2017 14:17:56 Ville Syrjälä wrote:
> > On Fri, Apr 21, 2017 at 12:51:14PM +0300, Jyri Sarha wrote:
> > > Add standard properties to control YCbC
Hi,
> > "native" to me feels more like "native to the GPU" since these things
> > really are tied to the GPU not the CPU. That's also why I went with the
> > explicit endianness originally so that the driver could properly declare
> > what the GPU supports.
> And to be honest I would really pref
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #295 from Alex Deucher ---
(In reply to Kyle K from comment #294)
> Hello,
>
> I have been having problem with my HD6870 for some time. I experienced it on
> 4.7/4.8/4.9 kernels (haven't tested earlier). My HD6870 works great out of
https://bugs.freedesktop.org/show_bug.cgi?id=100745
--- Comment #4 from Harry Wentland ---
Are the monitors set to DP input or to auto-select? If they are in auto-select
will setting input to DP help?
I've seen auto-select mode have problems with DP many times, especially with
scenarios like com
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
"native" to me feels more like "native to the GPU" since these things
really are tied to the GPU not the CPU. That's also why I went with the
explicit endianness originally so that the driver could properly declare
what the GPU supports.
And
Adding Harry to this mail thread as well, cause is one of the people
really affected by this.
Christian.
Am 21.04.2017 um 15:21 schrieb Christian König:
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
"native" to me feels more like "native to the GPU" since these things
really are tied
On 04/21/17 14:17, Ville Syrjälä wrote:
>> +static char *ycbcr_to_rgb_mode_name[] = {
>> +[DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
>> +"YCbCr BT.601 limited range TO RGB BT.601 full range",
>> +[DRM_PLANE_YCBCR_BT601_FULL_TO_RGB_BT601_FULL] =
>> +"YCbCr BT.601
On Fri, 2017-04-21 at 13:51 +0300, Dan Carpenter wrote:
> This code causes a static checker warning because it treats "i == 0" as
> a timeout but, because it's a post-op, the loop actually ends with "i"
> set to -1. Philipp Zabel points out that it would be cleaner to use
> readl_poll_timeout() in
Hi Jyri,
On Fri, Apr 21, 2017 at 12:51:11PM +0300, Jyri Sarha wrote:
> The series adds plane specific atomic properties to control YCbCr to
> RGB conversions. My intention was to try to implement the plane
> specific (before DEGAMMA) part of the suggestion in this dri-devel
> post:
>
> https://li
On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
> On 04/21/17 14:17, Ville Syrjälä wrote:
> >> +static char *ycbcr_to_rgb_mode_name[] = {
> >> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT601_FULL] =
> >> + "YCbCr BT.601 limited range TO RGB BT.601 full range",
> >> + [DRM_PLANE_YCB
https://bugzilla.kernel.org/show_bug.cgi?id=195483
Bug ID: 195483
Summary: radeon: video modes over 1920x1080 not working with DP
audio
Product: Drivers
Version: 2.5
Kernel Version: 4.0
Hardware: All
OS:
https://bugzilla.kernel.org/show_bug.cgi?id=195483
--- Comment #1 from Michal Suchánek (msucha...@suse.de) ---
Created attachment 255949
--> https://bugzilla.kernel.org/attachment.cgi?id=255949&action=edit
text representation of edid as decoded by edid-decode
--
You are receiving this mail bec
https://bugzilla.kernel.org/show_bug.cgi?id=195483
--- Comment #2 from Michal Suchánek (msucha...@suse.de) ---
Created attachment 255951
--> https://bugzilla.kernel.org/attachment.cgi?id=255951&action=edit
radeon card pci id
--
You are receiving this mail because:
You are watching the assignee
On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says the R
Hi,
Thanks for picking this up Jyri.
On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
On 04/21/17 14:17, Ville Syrjälä wrote:
>> +static char *ycbcr_to_rgb_mode_name[] = {
>> + [DRM_PLANE_YCBCR_BT601_LIM_TO_RGB_BT60
https://bugs.freedesktop.org/show_bug.cgi?id=100673
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.kernel.org/show_bug.cgi?id=195483
Michal Suchánek (msucha...@suse.de) changed:
What|Removed |Added
Attachment #255947|0 |1
is obsolet
https://bugzilla.kernel.org/show_bug.cgi?id=195483
Michal Suchánek (msucha...@suse.de) changed:
What|Removed |Added
Attachment #255949|0 |1
is obsolet
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.
Add a quirk to get the full 10 bpc.
Cc: sta...@vger.kernel.org
Thanks, Christian for adding me.
On 2017-04-21 09:27 AM, Christian König wrote:
Adding Harry to this mail thread as well, cause is one of the people
really affected by this.
Christian.
Am 21.04.2017 um 15:21 schrieb Christian König:
Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann:
Hi,
"nat
On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
> Hi,
>
> Thanks for picking this up Jyri.
>
> On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
> >On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
> >> On 04/21/17 14:17, Ville Syrjälä wrote:
> >> >> +static
On 21 April 2017 at 03:20, Daniel Vetter wrote:
>> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan)
>
> This one touches v4l and ion and is acked by the corresponding
> maintainers (but Sumit forgot to record that when applying the patch,
> and Sean didn't highlight it in the summar
Hi Laura,
Thanks much for this series!
On 18 April 2017 at 23:57, Laura Abbott wrote:
> Hi,
>
> This is v4 of the series to cleanup to Ion. Greg took some of the patches
> that weren't CMA related already. There was a minor bisectability problem
> with the CMA APIs so this is a new version to ad
On Fri, Apr 21, 2017 at 06:21:48PM +0300, Ville Syrjälä wrote:
On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
Hi,
Thanks for picking this up Jyri.
On Fri, Apr 21, 2017 at 04:52:03PM +0300, Ville Syrjälä wrote:
>On Fri, Apr 21, 2017 at 04:39:16PM +0300, Jyri Sarha wrote:
>> On 0
On 2017-04-21 11:05 AM, Mario Kleiner wrote:
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.
Add a quirk to
Since DC now uses CRTC_VERTICAL_INTERRUPT0 as VBLANK irq trigger
and vblank interrupts actually happen earliest at start of vblank,
instead of a bit before vblank, we no longer need some of the
fudging logic to deal with too early vblank irq handling (grep for
lb_vblank_lead_lines). This itself fix
Make sure we do not program a hw pageflip inside vblank 'n' iff the
atomic flip is comitted while inside the same vblank 'n'. We must
defer such a flip by one refresh cycle to vblank 'n+1'.
Without this, pageflips programmed via X11 GLX_OML_sync_control extensions
glXSwapBuffersMscOML(..., target_
Hi
These two patches were written and tested against Harry's
hwentland amd-staging-dc-drm-next branch from a few days ago.
Not sure if that is the right one to base dal/dc patches against,
but it looks recent and active enough?
They fix pageflip scheduling to always flip at the right target vblan
On Fri, Apr 21, 2017 at 04:34:00PM +0100, Brian Starkey wrote:
> On Fri, Apr 21, 2017 at 06:21:48PM +0300, Ville Syrjälä wrote:
> >On Fri, Apr 21, 2017 at 03:53:42PM +0100, Brian Starkey wrote:
> >> Hi,
> >>
> >> Thanks for picking this up Jyri.
> >>
> >> On Fri, Apr 21, 2017 at 04:52:03PM +0300, V
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to
Hi, this is version v3 with some fix-ups:
Versions:
v1 -> v2:
* Keep temp attrs as read only
v2 -> v3:
* Code fix-ups: struct and string as const and add return within switch
due to fallthrough
* Add Signed-off-by to all commits
This patchseries replaces the de
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 722 +++-
1 file changed, 249 insertions(+), 473
This patch replaces the symbolic permissions with the numeric ones,
and adds me to the authors too.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info.
Signed-off-by: Oscar Salvador
-
On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
> > While working on graphics support for virtual machines on ppc64 (which
> > exists in both little and big endian variants) I've figured the comments
> > for various drm fourcc fo
Hi Dave,
The following changes since commit 6b1462700b4a6a1244c018cdd2fa97ded43090a0:
Merge tag 'drm-misc-next-fixes-2017-04-20' of
git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-04-21 13:51:59
+1000)
are available in the git repository at:
git://people.freedesktop.org/~sy
The existing enable/disable ops for PLL35XX are made more generic
and used also for PLL36XX. This fixes issues in the kernel with
PLL36XX PLLs when the PLL has not been already enabled by bootloader.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-pll.c | 85 +++
The hdmi-codec interface added in this patch is required to properly
support HDMI audio. Currently the audio part of the SoC internal
HDMI transmitter is configured with fixed values, which makes HDMI
audio working by chance, only on boards equipped with external audio
codec connected in parallel w
In this series I gathered patches touching various subsystems to make
the overall review easier, finally I'm going to post independently
patches for each subsystem and the dts patch(es) will be postponed
to subsequent merge window.
The main purpose of this series is to add audio codec interface t
This patch adds missing definitions of mux clocks required for using
EPLL as the audio subsystem root clock on exynos5420/exynos5422 SoCs.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-exynos5420.c | 13 -
include/dt-bindings/clock/exynos5420.h | 3 +++
2 files cha
A specific clock rate table is added for EPLL so it is possible
to set frequency of the EPLL output clock as multiple of various
audio sampling rates.
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/samsung/clk-exynos5420.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletio
This patch adds DT binding documentation for Odroid XU3/4
sound subsystem.
Signed-off-by: Sylwester Nawrocki
---
.../devicetree/bindings/sound/samsung,odroid.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/samsung,od
This dedicated driver allows to support SoC specific clock
settings and helps to ensure proper number of channels gets
negotiated in multicodec system configurations.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/Kconfig | 8 ++
sound/soc/samsung/Makefile | 2 +
sound/soc/samsung/
The new sound card DT binding is used for Odroid XU3 in order
to properly support the HDMI audio path.
Clocks configuration is changed so the I2S controller is now the bit
and the frame clock master with EPLL as the root clock source.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exyno
On Fri, Apr 21, 2017 at 07:31:42PM +0200, Krzysztof Kozlowski wrote:
> Although Sylwester is known of writing good quality code and can be
> trusted but he posted it just 9 minutes ago. Isn't it a little bit too
> fast to apply? I just finished reading cover letter but didn't manage
> to start loo
The patch
ASoC: samsung: Add Odroid ASoC machine driver
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to L
On Thu, Apr 20, 2017 at 11:50:02PM +0200, Daniel Vetter wrote:
> On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul wrote:
> > Hi Dave,
> > A few fixes for you to pick up. The driver changes are trivial, and the
> > maintainer change was necessitated by the sti fix. The headliner here is the
> > dma_buf_
1 - 100 of 138 matches
Mail list logo
