https://bugs.freedesktop.org/show_bug.cgi?id=108015
Bug ID: 108015
Summary: Enabling pp_od_clk_voltage causes the gpu to be locked
to lowest power level until some value is written to
pp_od_clk_voltage and then the pp_od_clk_voltage
Goal: simplify multiseat support.
A new parameter was added to the Xorg server to make it use a passed file
descriptor instead of /dev/dri/card*.
This enables one to start the Xorg server with leased FD.
Although it is possible to organize multiseat using this approach, it does not
integrate
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #12 from michael.mans...@gmail.com ---
This fixes the issue for me as well. Its great to finally have a work-around!
--
You are receiving this mail because:
You are the assignee for the
Currently we return NOTIFY_DONE for any event which we don't think is
ours. However, many laptops will send more then just an ATIF event and
will also send an ACPI_VIDEO_NOTIFY_PROBE event as well. Since we don't
check for this, we return NOTIFY_DONE which causes a keypress for the
ACPI event to
https://bugzilla.kernel.org/show_bug.cgi?id=201201
Bug ID: 201201
Summary: [amdgpu] Can't raise power limit on Vega
Product: Drivers
Version: 2.5
Kernel Version: 4.19-rc4
Hardware: x86-64
OS: Linux
Tree:
https://bugs.freedesktop.org/show_bug.cgi?id=108014
Bug ID: 108014
Summary: AMD WX4150 - MST is entirely nonfunctional, spams
dmesg with errors
Product: DRI
Version: DRI git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=108014
Lyude Paul changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this mail
On Thu, Sep 20, 2018 at 01:16:09PM +0100, Emil Velikov wrote:
> On 14 September 2018 at 00:57, Lucas De Marchi
> wrote:
> > Rely on -fvisibility=hidden to hide the symbols. Previous version of
> > this series applying only to drm_intel.so is
> >
> > Reviewed-by: Eric Engestrom
> >
> >
On Fri, 2018-09-21 at 11:27 +0200, Daniel Vetter wrote:
> On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote:
> > Currently we set intel_connector->mst_port to NULL to signify that the
> > MST port has been removed from the system so that we can prevent further
> > action on the port such
Hi Dave,
one fix to get a proper DMA configuration in place for the etnaviv
virtual device. I'm sending this as a fix, as a dma-mapping change at
the ARC architecture side during the 4.19 cycle broke etnaviv on this
platform, which gets remedied with this patch, but it also enables
ARM64.
If you
Reviewed-by: Karol Herbst
On Fri, Sep 14, 2018 at 10:44 PM, Lyude Paul wrote:
> While we currently grab a runtime PM ref in nouveau's normal connector
> detection code, we apparently don't do this for MST. This means if we're
> in a scenario where the GPU is suspended and userspace attempts to
Both patches are Reviewed-by: Karol Herbst
On Wed, Sep 19, 2018 at 7:13 PM, Lyude Paul wrote:
> This is a small patch series that adds a strap_peek file into our
> debugfs, and sets the size of the vbios.rom debugfs file so that nvbios
> can easily be used to parse the vbios even on systems
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #6 from Jerry Zuo ---
I got it. Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
v2: the first element of the ring mirror list is the currently
executing job so we don't need a additional variable for it
Signed-off-by: Nayan Deshmukh
On 09/20/2018 11:53 PM, Jiandi An wrote:
>
>
> On 09/20/2018 01:29 AM, Gerd Hoffmann wrote:
>> Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and
>> virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just
>> the virtio resource handle.
>>
>> This is needed to
Hi Ayan,
On 21 September 2018 at 17:00, Ayan Kumar Halder wrote:
> radeon:
> - Removed RADEON_TILING_R600_NO_SCANOUT
>
> sis:
> - Changed the data type of some structure members from 'int' to 'long'.
>
> via:
> - Removed inclusion of 'via_drmclient.h'.
These three need to be
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the
Hi,
I've found it odd that the GEM object has its callbacks on drm_driver
and not a vtable of its own. But something being odd isn't enough to
make a change (me thinks).
After working on the GEM shmem helper I saw that a few drivers have
runtime support for 2 memory types for their buffers
This is just a showcase for the drm/gem patch, not to be applied.
vc4 has it's own mmap function so I just bundled it in for a quick hack.
The drivers that use the CMA helper should in theory be able to drop it's
drm_driver GEM callbacks (not dumb_create and import) and use the GEM
attached
The majority of drivers use drm_gem_prime_export() and
drm_gem_prime_import() for these callbacks so let's make them the
default.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 7 +++
drivers/gpu/drm/drm_prime.c | 10 --
include/drm/drm_drv.h | 4
3
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #5 from Jerry Zuo ---
Thank you. You connect both HDMI and DP to UP3214 with DP1.2 enabled, switch
back and forth, and the warning is showing up. When the warning is observed, a
delay is also observed. Am I right?
--
You are
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and
From: Ayan Kumar Halder
Add support for compressed framebuffers that are described using
the framebuffer's modifier field. Mali DP uses the rotation memory for
the decompressor of the format, so we need to check for space when
the modifiers are present.
Signed-off-by: Ayan Kumar Halder
We support that value so it should work as expected. This does not make
'auto' the default since the API is still marked as experimental.
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 75c7bdff..8001a9cc 100644
---
On Wed, Sep 19, 2018 at 7:55 PM Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v7:
> -
From: Ville Syrjälä
Add the code to deal with the NTSC VBI infoframe.
I decided against parsing the PES_data_field and just leave
it as an opaque blob, just dumping it out as hex in the log.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
From: Ville Syrjälä
Add the code to deal with the MPEG source infoframe.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 229
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #4 from Paul Menzel ---
(In reply to Jerry Zuo from comment #3)
> Hi Paul, can you please explain what you did by "when switching the inputs
> of the monitor (two systems are connected)"?
The monitor has several inputs. Over the
On Fri, Sep 21, 2018 at 04:12:36PM +0200, Hans Verkuil wrote:
> On 09/21/18 16:01, Ville Syrjälä wrote:
> > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> >> On 09/20/18 20:51, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> We'll be wanting to send more than just
On Fri, Sep 21, 2018 at 03:59:06PM +0200, Daniel Vetter wrote:
> On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life simpler by passing around intel_encoder instead of
> > drm_encoder.
> >
> > @r1@
> > identifier F =~ "infoframe";
> >
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #3 from Jerry Zuo ---
Hi Paul, can you please explain what you did by "when switching the inputs of
the monitor (two systems are connected)"?
--
You are receiving this mail because:
You are the assignee for the
From: Ville Syrjälä
Let's make the infoframe pack functions usable with a const infoframe
structure. This allows us to precompute the infoframe earlier, and still
pack it later when we're no longer allowed to modify the structure.
So now we end up with a _check()+_pack_only() or _pack()
On Fri, Sep 21, 2018 at 10:24:25AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make the infoframe pack functions usable with a const infoframe
> > structure. This allows us to precompute the infoframe earlier, and still
> > pack it
Quoting John Garry (2018-09-21 09:11:19)
> On 21/09/2018 06:49, Liuxinliang (Matthew Liu) wrote:
> > Hi John,
> > Thank you for reporting bug.
> > I am now using 4.18.7. I haven't found this issue yet.
> > I will try linux-next and figure out what's wrong with it.
> >
> > Thanks,
> > Xinliang
> >
This reverts commit 3510e7a7f91088159bfc67e8abdc9f9e77d28870.
During the 4.19 merge window for drm-misc, two patches critical to
supporting the display pipeline on the Allwinner R40 SoC were missed.
They were applied later but missed the merge window deadline. As a
result 4.19-rc1 kernel would
On Wed, Sep 19, 2018 at 02:14:36PM +0200, Maxime Ripard wrote:
> > I'm sorry but I'm not convinced a consumer driver should have all the
> > details
> > that are added in phy_configure_opts_mipi_dphy.
>
> If it can convince you, here is the parameters that are needed by all
> the MIPI-DSI
On Thu, Sep 20, 2018 at 09:51:37PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have definitions and low level code for everything except the gamut
> metadata HDMI packet. Add the missing bits.
>
> Signed-off-by: Ville Syrjälä
Online Bspec seems to have dropped pre-cpt/snb stuff,
On 09/21/18 16:01, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
>> On 09/20/18 20:51, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> We'll be wanting to send more than just infoframes over HDMI. So add an
>>> enum for other packet types.
>>>
>>> TODO:
Hi,
On Thu, Sep 20, 2018 at 03:04:12PM +0200, Neil Armstrong wrote:
> Since "drm/fb: Stop leaking physical address", the default behaviour of
> the DRM fbdev emulation is to set the smem_base to 0 and pass the new
> FBINFO_HIDE_SMEM_START flag.
>
> The main reason is to avoid leaking physical
On Thu, Sep 20, 2018 at 03:54:40PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> This adds basic support for Cadence MHDP DPI to DP bridge.
>
> Basically, it takes a DPI stream as input and output it encoded in DP
> format. It's missing proper HPD, HDCP and currently supports only
> SST
On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll be wanting to send more than just infoframes over HDMI. So add an
> > enum for other packet types.
> >
> > TODO: Maybe just include the infoframe types
On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life simpler by passing around intel_encoder instead of
> drm_encoder.
>
> @r1@
> identifier F =~ "infoframe";
> identifier I, M;
> @@
> F(
> - struct drm_encoder *I
> + struct intel_encoder *I
> ,
On Fri, Sep 21, 2018 at 10:30:16AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the NTSC VBI infoframe.
> >
> > I decided against parsing the PES_data_field and just leave
> > it as an opaque blob, just dumping it
On Fri, Sep 21, 2018 at 10:28:09AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the MPEG source infoframe.
> >
> > Blindly typed from the spec, and totally untested.
>
> I'm not sure this patch should be added at
On Thu, Sep 20, 2018 at 09:51:35PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled memmove() with the real thing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 4 +---
> 1 file changed, 1 insertion(+),
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the
Creating framebuffers for fbdev emulation should use the correct format
code too, so switch drm_gem_fbdev_fb_create() over to use the new
drm_driver_legacy_fb_format() function.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++--
1
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_fourcc.c | 5 +
drivers/gpu/drm/drm_framebuffer.c | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 7c6d3922ed..90a1c846fc 100644
---
On Fri, Sep 21, 2018 at 01:34:00AM -0700, Manasi Navare wrote:
> On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 18, 2018 at
Fix fbdev emulation.
Fix bochs-drm and virtio-gpu drivers.
Gerd Hoffmann (6):
drm: move native byte order quirk to new drm_driver_legacy_fb_format
function
drm: use drm_driver_legacy_fb_format in drm_gem_fbdev_fb_create
drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
https://bugs.freedesktop.org/show_bug.cgi?id=107956
--- Comment #4 from Martin Peres ---
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_114/fi-ilk-650/igt@kms_b...@extended-pageflip-hang-newfb-render-b.html
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v8:
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
JFYI, this is going to munge your Author name. This can be fixed up when the
patch is applied, so probably not worth a v9.
Reviewed-by: Sean Paul
>
> Add the device tree bindings for Truly
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #11 from Jason Playne ---
(In reply to Jason Playne from comment #10)
> (In reply to Timothy Arceri from comment #9)
> > I'm not sure why yet but both the black triangles and the incorrect
> > rendering behind the chinese emperor on
Hi Dave,
I have managed to push the fixes to the public tree without sending the
pull request until today when I did a clean checkout of drm-fixes and
realised my mistake. I've now rebased the tree on your latest drm-fixes
branch.
At your convenience, please pull these two patches.
Many thanks,
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
v2: take care of configurations without IOMMU
Signed-off-by: Andrzej Hajda
---
Hi Inki,
In the 2nd version I took care of non-iommu case, thanks to Marek.
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #10 from Jason Playne ---
(In reply to Timothy Arceri from comment #9)
> I'm not sure why yet but both the black triangles and the incorrect
> rendering behind the chinese emperor on the loading screen go away when I
> run the trace
From: Thierry Reding
Tegra194 contains a fourth display controller that does not own any
windows. Therefore, we cannot currently assign a primary plane to it
which causes KMS to eventually crash. Do not register the display
controller if it owns no windows to work around this.
Note that we
From: Thierry Reding
The DPAUX controller found on Tegra194 is almost identical to its
predecessor from Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dpaux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
From: Thierry Reding
The display controllers found on Tegra194 are almost identical to those
found on Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 51 +
drivers/gpu/drm/tegra/dc.h | 2 +-
drivers/gpu/drm/tegra/drm.c | 1 +
3
From: Thierry Reding
The SOR implemented in Tegra194 is subtly different from its predecessor
found in Tegra186. Most notably some registers have been moved around so
it is no longer compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/sor.c
From: Thierry Reding
The display hub integrated into Tegra194 is almost identical to the one
found on Tegra186. However, it doesn't support DSC (display stream
compression) so it isn't fully compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds hdmi dirver suppot for both MT2701 and MT7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai
> ---
>
Hi Andrzej,
On 2018-09-21 10:58, Andrzej Hajda wrote:
> Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
> looping through all components and maintaining DMA device flags.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 50
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds dpi dirver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> Convert dpi driver to use drm_of_find_panel_or_bridge.
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
>
On Wed, Sep 19, 2018 at 01:12:47PM +0200, Gerd Hoffmann wrote:
> Fix fbdev emulation.
> Fix bochs-drm and virtio-gpu drivers.
>
> Gerd Hoffmann (5):
> drm: move native byte order quirk to new drm_mode_legacy_fb_format2
> function
> drm: use drm_mode_legacy_fb_format2 in
On Wed, Sep 19, 2018 at 01:12:48PM +0200, Gerd Hoffmann wrote:
> Turns out we need the pixel format fixup not only for the addfb ioctl,
> but also for fbdev emulation code.
>
> Ideally we would place it in drm_mode_legacy_fb_format(). That would
> create alot of churn though, and most drivers
Quoting Daniel Vetter (2018-09-21 10:15:41)
> On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote:
> > After schedule() returns 0, we must do one last check of COND to
> > determine the reason for the wakeup with 0 jiffies remaining before
> > reporting the timeout -- otherwise we may
On Wed, Sep 19, 2018 at 03:37:12PM +0800, ning.a.zh...@intel.com wrote:
> From: Zhang Ning
>
> when i915 is built in module, and system has built-in display, eg. eDP,
> i915 will detect and active it during driver probe. it will take long
> time.
>
> set i915 driver probe to asynchrous can save
On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote:
> Currently we set intel_connector->mst_port to NULL to signify that the
> MST port has been removed from the system so that we can prevent further
> action on the port such as connector probes, mode probing, etc.
> However, we're going
On Tue, Sep 18, 2018 at 09:02:04PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> > All DRM_CLIENT capabilities are tied to KMS support, so returning
> > -EOPNOTSUPP when KMS is not supported.
> >
> > v2: returning -EOPNOTSUPP(same value as
On Tue, Sep 18, 2018 at 06:21:59PM +0100, Eric Engestrom wrote:
> All the other vendors use the format
> DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
> modifiers, except Intel.
>
> Suggested-by: Gerd Hoffmann
> Signed-off-by: Eric Engestrom
I think it'd be good to add
On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote:
> After schedule() returns 0, we must do one last check of COND to
> determine the reason for the wakeup with 0 jiffies remaining before
> reporting the timeout -- otherwise we may lose the signal due to
> scheduler delays.
Ah classic!
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> different IC has different clock designed in HDMI, the factor for
> calculate clock should be different. Usinng the data in of_node
> to find this factor.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui
On Tue, Sep 18, 2018 at 11:07:19AM +0100, Chris Wilson wrote:
> Both the .enable_signaling and .release of the null syncobj fence
> can be replaced by the default callbacks for a small reduction in code
> size.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
> ---
>
On Mon, Sep 17, 2018 at 05:12:04PM -0400, Lyude Paul wrote:
> On Mon, 2018-09-17 at 21:16 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> > > On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 17, 2018 at 01:43:44PM -0400,
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +++
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 13 +-
On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote:
> drm_mode_setcrtc() retries modesetting in case one of the functions it
> calls returns -EDEADLK. connector_set, mode and fb are freed before
> retrying, but they are not set to NULL. This can cause
> drm_mode_setcrtc() to use those
On Sat, Sep 15, 2018 at 01:53:19AM +, Wei Yongjun wrote:
> 'vaddr_out' is malloced in _vkms_get_crc() and should be freed before
> leaving from the error handling cases, otherwise it will cause memory
> leak.
>
> Fixes: db7f419c06d7 ("drm/vkms: Compute CRC with Cursor Plane")
> Signed-off-by:
On Mon, Sep 17, 2018 at 01:25:49PM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Kieran,
>
> On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> > Hi Alexandru,
> >
> > On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > > Hi Kieran,
> > >
> > > Sorry for that and thanks for
Hi Damian,
Am Donnerstag, 20. September 2018, 16:54:40 CEST schrieb Damian Kos:
> From: Quentin Schulz
>
> This adds basic support for Cadence MHDP DPI to DP bridge.
>
> Basically, it takes a DPI stream as input and output it encoded in DP
> format. It's missing proper HPD, HDCP and currently
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting to send more than just infoframes over HDMI. So add an
> enum for other packet types.
>
> TODO: Maybe just include the infoframe types in the packet type enum
> and get rid of the infoframe type enum?
I
Hi Simon,
On Friday, 21 September 2018 10:16:44 EEST Simon Horman wrote:
> On Wed, Sep 19, 2018 at 04:11:36PM +0300, Laurent Pinchart wrote:
> > On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote:
> >>> On
On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > On Tue, Sep 18, 2018 at
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the NTSC VBI infoframe.
>
> I decided against parsing the PES_data_field and just leave
> it as an opaque blob, just dumping it out as hex in the log.
>
> Blindly typed from the spec, and totally
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the MPEG source infoframe.
>
> Blindly typed from the spec, and totally untested.
I'm not sure this patch should be added at all. The CTA-861-G spec (section 6.7)
says that the implementation of this
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make the infoframe pack functions usable with a const infoframe
> structure. This allows us to precompute the infoframe earlier, and still
> pack it later when we're no longer allowed to modify the structure.
> So now we end
Hi Inki,
On 2018-09-21 05:20, Inki Dae wrote:
> There are several warnings,
> WARNING: line over 80 characters
> #276: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:182:
> + struct drm_exynos_ipp_task_rect *src_pos, const struct scaler_format
> *fmt)
>
> WARNING: line over 80 characters
>
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The unpack functions just read from the passed in buffer,
> so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> v2: Convert tda1997x.c as well (kbuild test robot)
>
> Cc: Thierry Reding
> Cc: Hans
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The log functions don't modify the passed in infoframe so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville
Thanks for the patch. Verified with the DP 1.4 spec and looks good to me.
Also look at the related patch that makes use of the correct extended
capabilities:
https://patchwork.freedesktop.org/patch/249400/
Reviewed-by: Manasi Navare
Manasi
On Thu, Sep 20, 2018 at 03:54:37PM +0100, Damian
On 2018-09-20 8:31 p.m., Eric Engestrom wrote:
> On Thursday, 2018-09-20 18:21:41 +0100, Eric Engestrom wrote:
>> On Thursday, 2018-09-20 18:09:41 +0200, Michel Dänzer wrote:
>>> On 2018-09-20 5:58 p.m., Eric Engestrom wrote:
Fixes: 9f45264815eff6ebeba3 "radeon: annotate public functions"
On Fri, Sep 21, 2018 at 10:06:58AM +1000, Dave Airlie wrote:
> Hey Greg,
>
> Looks like a pretty run of the mill set of fixes for this stage,
>
> core: fix debugfs for atomic, fix the check for atomic for
> non-modesetting drivers
> amdgpu: adds a new PCI id, some kfd fixes and a sdma fix
>
1 - 100 of 124 matches
Mail list logo
