https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #36 from Christian Zigotzky ---
(In reply to Ilia Mirkin from comment #35)
> If I had to put money on one of the left-over commits, I'd go with
>
> commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
> Author: Aaron Ma
> Date: Sat Se
https://bugs.freedesktop.org/show_bug.cgi?id=110641
Bug ID: 110641
Summary: lm_sensors reports "ERROR: Can't get value of
subfeature in0_input: Can't read"
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110636
Samuel Pitoiset changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
This was caused by a silent merge conflict, and is now fixed.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 13:53:48)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
> commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Mer
This too was caused by a merge conflict and one missing Fixes:.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 14:08:25)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
> commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Me
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --g
The data structure |struct drm_vram_mm| and its helpers replace mgag200's
TTM-based memory manager. It's the same implementation; except for the type
names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based
There's now a pointer to struct drm_vram_mm stored in struct drm_device.
DRM drivers that use VRAM MM should use this field to refer to their
instance of the data structure. Appropriate helpers are now provided as
well.
Adding struct drm_vram_mm to struct drm_device further avoids wrappers
and boi
The type |struct drm_gem_vram_object| implements a GEM object for simple
framebuffer devices with dedicated video memory. The BO is either located
in VRAM or system memory.
The implementation has been created from the respective code in ast,
bochs and mgag200. These drivers copy their implementati
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct bochs_bo|. It's the same implementation; except for the type
names.
v5:
* use PRIME helpers from GEM VRAM
v4:
* cleanups from checkpatch.pl
* select config option DRM_VRAM_HELPER
Signed-off-by:
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct ast_bo|. It's the same implementation; except for the type names.
v4:
* cleanups from checkpatch.pl
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Kconfig| 2 +-
drivers/gpu/drm/ast/ast_drv.c
This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_vram_object|. The only change in
semantics is that &ttm_bo_driver.verify_access() now does the actual
verification.
v4:
* select config option DRM_VRAM_HELPER
v3:
* remove forwar
The helper function drm_gem_vram_fill_create_dumb() implements most of
struct drm_driver.dumb_create() for GEM-VRAM buffer objects. It's not a
full implementation of the callback, as several driver-specific parameters
are still required.
v4:
* cleanups from checkpatch.pl
v2:
* docu
The provided helpers can be used for the respective callback functions
in |struct ttm_bo_driver|.
v2:
* drm_is_gem_vram() is now a private function
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 50 +++
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct hibmc_bo|. It's the same implementation; except for the type
names.
v4:
* select config option DRM_VRAM_HELPER
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
.../
The data structure |struct drm_vram_mm| and its helpers replace hibmc's
TTM-based memory manager. It's the same implementation; except for the
type names.
v5:
* set .llseek via DRM_VRAM_MM_FILE_OPERATIONS
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vr
The data structure |struct drm_vram_mm| and its helpers replace ast's
TTM-based memory manager. It's the same implementation; except for the
type names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based ins
Several simple framebuffer drivers copy most of the TTM code from each
other. The implementation is always the same; except for the name of
some data structures.
As recently discussed, this patch set provides generic memory-management
code for simple framebuffers with dedicated video memory. It fu
The VRAM MM memory manager is a helper library that manages dedicated video
memory of simple framebuffer devices. It is supported to be used with
struct drm_gem_vram_object, but does not depend on it.
The implementation is based on the respective code from ast, bochs, and
mgag200. These drivers sh
These basic helper functions for GEM VRAM allow for pinning and mapping
GEM VRAM objects via the PRIME interfaces. It's not a full implementation,
but complete enough for generic fbcon.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 98 +++
i
The data structure |struct drm_gem_vram_object| and its helpers replace
|struct mgag200_bo|. It's the same implementation; except for the type
names.
v4:
* cleanups from checkpatch.pl
* select config option DRM_VRAM_HELPER
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mga
The data structure |struct drm_vram_mm| and its helpers replace bochs'
TTM-based memory manager. It's the same implementation; except for the
type names.
v5:
* set .llseek via DRM_VRAM_MM_FILE_OPERATIONS
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vra
The AST driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h |
VRAM MM is most likely be used with GEM VRAM. The latter now provides the
required instance of struct drm_vram_mm_funcs for drivers to use.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 14 ++
include/drm/drm_gem_vram_helper.h | 3 +++
2 files chan
The data structure |struct drm_vram_mm| and its helpers replace vboxvideo's
TTM-based memory manager. It's the same implementation; except for the type
names.
v4:
* don't select DRM_TTM or DRM_VRAM_MM_HELPER
v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-bas
The provided helpers can be used for the respective callback functions
in |struct drm_driver|.
v4:
* cleanups from checkpatch.pl
v2:
* documentation fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 49 +++
include/drm/drm
The mgag200 driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.
v4:
* cleanups from checkpatch.pl
Signed-off-by: Thomas Zimm
On Tue, May 07, 2019 at 06:19:50PM +0200, Sam Ravnborg wrote:
> Hi Fabio
>
> On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote:
> > [Adding Sam, who is helping to review/collect panel-simple patches]
> >
> > On Tue, May 7, 2019 at 12:27 PM Sébastien Szymanski
> > wrote:
> > >
> > > T
On 5/7/19 1:42 PM, Koenig, Christian wrote:
Am 07.05.19 um 13:37 schrieb Thomas Hellstrom:
[CAUTION: External Email]
On 5/7/19 1:24 PM, Christian König wrote:
Am 07.05.19 um 13:22 schrieb zhoucm1:
On 2019年05月07日 19:13, Koenig, Christian wrote:
Am 07.05.19 um 13:08 schrieb zhoucm1:
On 2019年
On Tue, May 07, 2019 at 01:14:11PM -0600, Jordan Crouse wrote:
> An error while initializing the msm driver ends up calling
> drm_atomic_helper_shutdown() without first initializing the funcs
> in mode_config. While I'm not 100% sure this isn't a ordering
> problem in msm adding a check to drm_mode
Hi,
On Tue, May 07, 2019 at 08:12:23PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> Looks good now, stumbled upon a few details I missed in last round.
> With these considered / fixed you can add my
> Reviewed-by: Sam Ravnborg
>
> Sam
>
> > +#define CM(x) (
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 434
This patch adds support for the Armadeus ST0700 Adapt. It comes with a
Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
that it can be connected on the TFT header of Armadeus Dev boards.
Cc: sta...@vger.kernel.org # v4.19
Reviewed-by: Rob Herring
Signed-off-by: Sébastien Szy
From: Allen Chen
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.txt | 30 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 31 insertions(+)
create mode 100644
Documenta
Hello there,
[linux-5.1/drivers/video/fbdev/via/viafbdev.c:233]: (style) Assignment
'depth=30' is redundant with condition 'depth==30'.
Source code is
else if (depth == 30)
depth = 30;
Suggest code rework.
Regards
David Binderman
__
Here is a bit of inline commentary on the TAP13/TAP14 discussion.
> -Original Message-
> From: Brendan Higgins
>
> > On 5/3/19 4:14 PM, Brendan Higgins wrote:
> > >> On 5/2/19 10:36 PM, Brendan Higgins wrote:
> > > In any case, it sounds like you and Greg are in agreement on the core
> >
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
drive
From: Alastair D'Silva
This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.
This allows structs that are not 16/32 bytes to display on
a single line.
This patch also expands the self-tests to test row sizes
up to 64 bytes
To make use of the new eLCDIF DRM driver OF graph description is
required. Describe the display using OF graph nodes.
Cc: sta...@vger.kernel.org # v4.19
Signed-off-by: Sébastien Szymanski
---
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 37 +++--
1 file changed, 16 insertions(+)
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
---
drivers/gpu/drm/bridge/Kconfig | 22 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/
From: Alastair D'Silva
The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.
This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting the orde
From: Alastair D'Silva
The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.
This patch renames the cryptic variables and accounts for the
above case.
The selftests now pass.
Signed-off-by: Alastair D'Silva
---
lib/test_hexdump.c | 47 ++
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces a flag to allow the supression of lines of repeated
bytes, which are replaced with '** Skipped %u bytes of value 0x%x **'
An inline wr
From: Alastair D'Silva
Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.
eg.
buf:: 454d414e 43415053 4e495f45 00584544 NAMESPAC E_INDEX.
buf:0010: 0002
Sign
From: Allen Chen
This add can let us find it6505 char device in the /dev file and use read/write
function to let the driver be hold.
Signed-off-by: Allen Chen
---
drivers/gpu/drm/bridge/ite-it6505.c | 131
1 file changed, 131 insertions(+)
diff --git a/d
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg. wi
On Wed, 08 May 2019, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
For i915
Am 08.05.19 um 10:34 schrieb Thomas Hellstrom:
> [SNIP]
No, what I mean is to add the acquire_ctx as separate parameter to
ttm_mem_evict_first().
E.g. we only need it in this function and it is actually not related
to the ttm operation context filled in by the driver.
>>>
>
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 5:40 PM
>To: Shankar, Uma
>Cc: Jonas Karlman ; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; emil.l.veli...@gmail.com;
>dcasta...@chrom
On Wed, May 08, 2019 at 10:33:03AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2019 at 06:19:50PM +0200, Sam Ravnborg wrote:
> > Hi Fabio
> >
> > On Tue, May 07, 2019 at 12:33:39PM -0300, Fabio Estevam wrote:
> > > [Adding Sam, who is helping to review/collect panel-simple patches]
> > >
> > >
On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
> To allow a smooth transition from pinning buffer objects to dynamic
> invalidation we first start to cache the sg_table for an attachment.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 24
On Wed, May 08, 2019 at 05:01:44PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c
On Tue, May 07, 2019 at 10:13:31AM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 5:32 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; emil.l.veli...@gmail
On Tue, May 07, 2019 at 10:13:32AM +0200, Christian König wrote:
> That is now done by the DMA-buf helpers instead.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_prime.c | 76 -
> 1 file changed, 16 insertions(+), 60 deletions(-)
>
> diff --g
On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
> > To allow a smooth transition from pinning buffer objects to dynamic
> > invalidation we first start to cache the sg_table for an attachment.
> >
> > Signed-off-by:
https://bugzilla.kernel.org/show_bug.cgi?id=202873
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
CC||haxk...@gmail.com
--- Commen
https://bugzilla.kernel.org/show_bug.cgi?id=202873
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
Ah sorry this is the old bug where clocks cause flickering. But still try 5.1.
Maybe it will help.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #6 from Erik (erikjohans...@flashbox.5july.org) ---
The bisect was working i only didn't trust it.
What causes the change in behavior wasn't caused by resent fixes, well it was
but it wasn't.
What makes it work is bumping SUBLEVEL abov
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #37 from Christian Zigotzky ---
Hi All,
Allan has tested the ninth test kernel.
He wrote:
Christian
DRM9 boots to SI card.
ace
--
This step has been marked as bad because the ninth test kernel doesn't boot to
the FirePro.
Am 08.05.19 um 11:57 schrieb Daniel Vetter:
On Tue, May 07, 2019 at 10:13:32AM +0200, Christian König wrote:
That is now done by the DMA-buf helpers instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 76 -
1 file changed, 16 inserti
Am 08.05.19 um 11:15 schrieb Daniel Vetter:
On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment.
Signed-off-by: Christian König
---
drivers/dma
Am 08.05.19 um 12:11 schrieb Daniel Vetter:
On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for a
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/Makefile
In order to fix a bug in i915, I would like to opencode the dma fence
signal processing (to close a race condition with preemption and signal
enabling). Tvrtko quite rightly objected to the opencoding and suggested
that dma-fence should provide the helpers, so here's my suggestion wrt
the interface
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no long
Quoting Chris Wilson (2019-05-08 13:05:42)
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris Wilson
> Reviewed-b
On 08/05/2019 13:05, Chris Wilson wrote:
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko U
On Wed, May 8, 2019 at 2:00 PM Christian König
wrote:
> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
> > On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
> >> On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
> >>> To allow a smooth transition from pinning buffer object
On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> -static const char * const phy_types[] = {
> - "emmc 5.0 phy",
> - "emmc 5.1 phy"
> -};
> -
> enum xenon_phy_type_enum {
> EMMC_5_0_PHY,
> EMMC_5_1_PHY,
> NR_PHY_TYPES
There is no need for NR_PHY_TYPES
Am 08.05.19 um 14:15 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Wed, May 8, 2019 at 2:00 PM Christian König
> wrote:
>> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
>>> On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
On Tue, May 07, 2019 at 10:13:30AM +0200, Chris
On Wed, May 8, 2019 at 2:05 PM Chris Wilson wrote:
>
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris Wilson
>
On Wed, May 8, 2019 at 2:23 PM Koenig, Christian
wrote:
>
> Am 08.05.19 um 14:15 schrieb Daniel Vetter:
> > [CAUTION: External Email]
> >
> > On Wed, May 8, 2019 at 2:00 PM Christian König
> > wrote:
> >> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
> >>> On Wed, May 08, 2019 at 11:15:33AM +0200,
On Wed, May 8, 2019 at 2:06 PM Chris Wilson wrote:
>
> Currently there is an underlying assumption that i915_request_unsubmit()
> is synchronous wrt the GPU -- that is the request is no longer in flight
> as we remove it. In the near future that may change, and this may upset
> our signaling as we
From: Rob Clark
Depending on platform firmware, a zap shader may not be required to take
the GPU out of secure mode on boot, in which case we can just write
RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
clearing 'ret' resulting that hw_init() returned an error on these
d
On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> > This change re-introduces `match_string()` as a macro that uses
> > ARRAY_SIZE() to compute the size of the array.
> > The macro is added in all the places that
https://bugs.freedesktop.org/show_bug.cgi?id=110645
Michel Dänzer changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Total membership 84; total votes 65; which makes for a 77.4% voter
turnout. Here are the results:
Board Members:
Name 1 2 3 4 5 6 Score
Daniel Vetter 27 10 14 6 2 6 296
Samuel Iglesias Gonsálvez 11 10 13 15 10 6 239
Lyude
Den 08.05.2019 08.33, skrev Oleksandr Andrushchenko:
> On 5/7/19 7:04 PM, Noralf Trønnes wrote:
>> Hi,
>>
>> Could someone please have a look at this one?
>>
>> Noralf.
>>
>> Den 26.04.2019 14.47, skrev Noralf Trønnes:
>>> The logic for freeing an imported buffer with a virtual address is
>>> bro
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #7 from Erik (erikjohans...@flashbox.5july.org) ---
Is there anything more i can do to find out what's going on?
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
On Wed, May 8, 2019 at 10:06 AM Harry Wentland wrote:
>Trevor Woerner 4 14 10 10 8 19 199
>
I'd like to truly thank the other 3 people who chose me as their 1st pick,
and the 14 (:-O !!) who chose me as their first 2nd-place pick!
Considering I'm not an active contributor
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> It should also be noted that even though our election process as
> outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows
> denying candidates any points our website didn't take this into account
> and forced vot
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> In the interest of transparency I should mention that one person
> accidentally signed up twice and voted twice. Luckily this doesn't
> change the results of the election since there is more than a 6-point
> gap between 4th and
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> Due to the lack of
> controversy about the candidates [...]
Such a statement, when talking about election results, very much sounds
like "the election committees favourite candidates won anyway, so..."
p.
Luc Verhaegen.
__
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #1 from Alex Deucher ---
That commit just exposes the temperature via an ioctl interface. It doesn't
affect the hwmon sysfs API. How did you determine that that was the
problematic one?
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=110472
--- Comment #2 from gpiza...@javaman.net ---
I really hope someone sees this. Bump x2?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
From: Sean Paul
Another version of the SR helpers for your consumption.
Pretty minor differences between v4 and v3:
- lots of documentation changes
- Use connector to get at crtc state in encoders
- Use the damage helpers in rockchip to fix fbdev
Note that the rockchip patches require
e9abc611a
From: Sean Paul
This patch adds atomic_enable and atomic_disable callbacks to the
encoder helpers. This will allow encoders to make informed decisions in
their start-up/shutdown based on the committed state.
Aside from the new hooks, this patch also introduces the new signature
for .atomic_* fun
From: Laurent Pinchart
Add functions to the atomic core to retrieve the old and new connectors
associated with an encoder in a drm_atomic_state. This is useful for
encoders and bridges that need to access the connector, for instance for
the drm_display_info.
The CRTC associated with the encoder
From: Sean Paul
This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implem
From: Sean Paul
Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the new self refresh helpers to do the heavy lifting.
Changes in v2:
- updated to reflect changes made in the helpers
Changes in v3:
- use the new atomic hooks to inspect crtc state instead
From: Sean Paul
Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid
1 - 100 of 163 matches
Mail list logo
