Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä wrote: > 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

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

https://bugs.freedesktop.org/show_bug.cgi?id=100745 --- Comment #5 from mr.nuke...@gmail.com --- P2715Q does not have auto-select mode. They're always listening on the same input. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks

On 04/21, Sylwester Nawrocki wrote: > 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

Re: [PATCH v3 4/5] nouveau_hwmon: Add support for auto_point attributes

Hi Oscar, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.11-rc7 next-20170421] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Oscar-Salvador/replace

[Bug 194949] Amdgpu: RX 460 idle temp is 45C

https://bugzilla.kernel.org/show_bug.cgi?id=194949 fin4...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.

Daniel Vetter writes: > On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt wrote: >> Daniel Vetter writes: >>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote: The FBDEV initialization would throw an error in dmesg, when we

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > My personal opinion is that formats in drm_fourcc.h should be > > independent of the CPU byte order and the function > > drm_mode_legacy_fb_format() and drivers depending on that incorrect > > assumption be fixed instead. > > The problem is this isn't a kernel-internal thing any

Re: Pageflip fixes for the amd dal/dc staging tree.

On 2017-04-21 12:23 PM, Mario Kleiner wrote: 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? Yes, I suggest you

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-11 Daniel Vetter : > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > > Gustavo Padovan writes: > > > > > From: Gustavo Padovan > > > > > > In some cases, like cursor updates, it is interesting to update

Applied "ASoC: Add Odroid sound DT bindings documentation" to the asoc tree

The patch ASoC: Add Odroid sound DT bindings documentation 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

Re: [PULL] drm-misc-next-fixes

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

Applied "ASoC: samsung: Add Odroid ASoC machine driver" to the asoc tree

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

Re: Applied "ASoC: Add Odroid sound DT bindings documentation" to the asoc tree

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

[PATCH RFC 7/7] ARM: dts: samsung: Switch to dedicated Odroid sound card binding

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 ---

[PATCH RFC 6/7] ASoC: samsung: Add Odroid ASoC machine driver

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 |

[PATCH RFC 2/7] clk: samsung: Add definitions of some audio related clocks

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 -

[PATCH RFC 3/7] clk: samsung: exynos542x: Add EPLL rate table

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

[PATCH RFC 5/7] ASoC: Add Odroid sound DT bindings documentation

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

[PATCH RFC 0/7] HDMI audio support for Exynos Odroid boards

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

[PATCH RFC 4/7] drm: exynos: Add driver for HDMI audio interface

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

[PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks

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 |

[git pull] vmwgfx-next

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:

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

[PATCH v3 4/5] nouveau_hwmon: Add support for auto_point attributes

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

[PATCH v3 0/5] replace hwmon_device_register for hwmon_device_register_with_info

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

[PATCH v3 3/5] nouveau_hwmon: Remove old code, add .write/.read operations

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

[PATCH v3 5/5] nouveau_hwmon: Change permissions to numeric

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

[PATCH v3 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

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

[PATCH v3 1/5] nouveau_hwmon: Add config for all sensors and their settings

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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,

Pageflip fixes for the amd dal/dc staging tree.

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

[PATCH 2/2] drm/amd/display: Prevent premature pageflip when comitting in vblank.

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(...,

[PATCH 1/2] drm/amd/display: Fix race between vblank irq and pageflip irq.

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

Re: [PATCH] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging

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

Re: [PULL] drm-misc-next-fixes

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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,

[PATCH] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

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

[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio

https://bugzilla.kernel.org/show_bug.cgi?id=195483 Michal Suchánek (msucha...@suse.de) changed: What|Removed |Added Attachment #255949|0 |1 is

[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio

https://bugzilla.kernel.org/show_bug.cgi?id=195483 Michal Suchánek (msucha...@suse.de) changed: What|Removed |Added Attachment #255947|0 |1 is

[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

https://bugs.freedesktop.org/show_bug.cgi?id=100673 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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[] = { >> +

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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. > >

[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio

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=edit radeon card pci id -- You are receiving this mail because: You are watching the assignee of

[Bug 195483] radeon: video modes over 1920x1080 not working with DP audio

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=edit text representation of edid as decoded by edid-decode -- You are receiving this mail because:

[Bug 195483] New: radeon: video modes over 1920x1080 not working with DP audio

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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", > >> +

Re: [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion

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: > >

Re: [PATCH v2] drm/mediatek: fix a timeout loop

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()

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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.

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

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,

[Bug 66963] Rv6xx dpm problems

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion

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

[Bug 99368] Full aspect scaling introduces interlacing on specific resolutions

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

[Bug 100058] amdgpu/dpm: NULL pointer dereference

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=edit dpm patch @Adam, please try applying the attached patch and let me know if it

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH RFC 5/6] drm/omap: csc full range support

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

Re: [PATCH RFC 4/6] drm/omap: cleanup color space conversion

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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: > > > >

[Bug 100058] amdgpu/dpm: NULL pointer dereference

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

Re: [PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic

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

Re: [PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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"

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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: > > > >

Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

[PATCH v2] drm/mediatek: fix a timeout loop

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

[PATCH RFC 4/6] drm/omap: cleanup color space conversion

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 RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration

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

[PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic

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

[PATCH RFC 5/6] drm/omap: csc full range support

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

[PATCH RFC 6/6] drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT

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

[PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties

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

[PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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

[PATCH 11/12] drm: mali-dp: Enable image enhancement when scaling

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

[PATCH 03/12] drm: mali-dp: add atomic_print_state for planes

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(+)

[PATCH 01/12] drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.

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

[PATCH 12/12] drm: mali-dp: Check the mclk rate and allow up/down scaling

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

[PATCH 06/12] drm: mali-dp: add malidp_crtc_state struct

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

[PATCH 04/12] drm: mali-dp: remove unused variable

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

[PATCH 05/12] drm: mali-dp: add custom reset hook for planes

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

[PATCH 09/12] drm/mali-dp: Add core_id file to the sysfs interface

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 ---

[PATCH 02/12] drm: mali-dp: Enable power management for the device.

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

[PATCH 00/12] drm/mali-dp: Collate the pending patches in a series

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.

[PATCH 08/12] drm: mali-dp: Add CTM support

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

[PATCH 07/12] drm: mali-dp: enable gamma support

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

  1   2   >