https://bugs.freedesktop.org/show_bug.cgi?id=112038
Andre Klapper changed:
What|Removed |Added
Resolution|--- |INVALID
Group|
https://bugs.freedesktop.org/show_bug.cgi?id=112038
Bug ID: 112038
Summary: [All browsers] The number of countries and regions
text for activities is poorly read on the region pages
Product: DRI
Version: XOrg git
Hardware:
On Wed, Oct 16, 2019 at 04:22:07PM +, Brian Starkey wrote:
> Hi,
>
> On Wed, Oct 16, 2019 at 03:51:39PM +, Mihail Atanassov wrote:
> > Hi James,
> >
> > On Wednesday, 9 October 2019 06:54:15 BST james qian wang (Arm Technology
> > China) wrote:
> > > On Fri, Oct 04, 2019 at 02:34:42PM
Hi Dave, Daniel,
A few fixes for 5.4. Nothing too major.
The following changes since commit 083164dbdb17c5ea4ad92c1782b59c9d75567790:
drm/amdgpu: fix memory leak (2019-10-09 11:45:59 -0500)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
On 2019/10/15 下午10:37, Stefan Hajnoczi wrote:
On Tue, Oct 15, 2019 at 11:37:17AM +0800, Jason Wang wrote:
On 2019/10/15 上午1:49, Stefan Hajnoczi wrote:
On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote:
There are hardware that can do virtio datapath offloading while having
its own
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #99 from Shmerl ---
(In reply to David Biró from comment #98)
>
> Can I help you somehow? (Unfortunately, I've got no idea how can I patch a
> kernel module on Arch.)
On Debian testing, I simply build a whole kernel, applying
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #98 from David Biró ---
Recently, I've just become an RX 5700 xt user, with the same issues, but for me
the keyboard and the mouse also dies after those errors. ( There is a Caps Lock
indicator led, but after the error I can't
On Wed, 16 Oct 2019 20:48:06 +
Parav Pandit wrote:
> > From: Alex Williamson
> > On Wed, 16 Oct 2019 15:31:25 +
> > Parav Pandit wrote:
> > > > From: Cornelia Huck
> > > > Parav Pandit wrote:
> > > > > > From: Alex Williamson
> > > > > > On Tue, 15 Oct 2019 20:17:01 +0800 Jason Wang
On Wed, Oct 16, 2019 at 11:48:22PM +0200, Karol Herbst wrote:
> On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote:
> > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:
> > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
> > > platform means of putting the device
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #35 from Andreas Jackisch (andreas.jacki...@gmail.com) ---
(In reply to Ahzo from comment #34)
> (In reply to Alex Deucher from comment #29)
> > Created attachment 285507 [details]
> > possible fix for uvd6
> >
> > The session info
On Wed, Oct 16, 2019 at 11:30:51PM +0200, Noralf Trønnes wrote:
> As Andy mentioned, ->max_transfer_size is a callback:
> struct spi_controller {
> /*
>* on some hardware transfer / message size may be constrained
>* the limit may depend on device transfer settings
>
On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote:
>
> [+cc linux-acpi]
>
> On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:
> > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
> > platform means of putting the device into D3cold, right? That's
> > actually what
On Thu, 17 Oct 2019 at 03:28, Matt Roper wrote:
>
> On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> > I've kicked this around in my head over the past few weeks but wanted
> > to get some feedback on whether it's a good idea or what impact it
> > might have that I haven't
On Thu, 17 Oct 2019 at 06:00, Alex Deucher wrote:
>
> On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote:
> >
> > I've kicked this around in my head over the past few weeks but wanted
> > to get some feedback on whether it's a good idea or what impact it
> > might have that I haven't considered.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Anusha Srivatsa (1):
intel: sync i915_pciids.h with kernel
Emil Velikov (1):
*-symbols-check: use normal shell over bash
Eric Engestrom (7):
xf86drm: dedupe `#define`s
xf86drm: use max size of drm node name instead of
[+cc linux-acpi]
On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:
> but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
> platform means of putting the device into D3cold, right? That's
> actually what should still happen, just the D3hot step should be
> skipped.
If I
Den 16.10.2019 21.57, skrev Daniel Vetter:
> In DMA mode we have a maximum transfer size, past that the driver
> falls back to PIO (see the check at the top of pxa2xx_spi_transfer_one).
> Falling back to PIO for big transfers defeats the point of a dma engine,
> hence set the max transfer size
On Tue, Sep 10, 2019 at 4:10 AM Wen He wrote:
>
> Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
> This property describe the ARQoS levels of DP500's QoS signaling.
>
> Signed-off-by: Wen He
> Reviewed-by: Rob Herring
Liviu, I see you applied 2/2, but didn't apply this
On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> I've kicked this around in my head over the past few weeks but wanted
> to get some feedback on whether it's a good idea or what impact it
> might have that I haven't considered.
>
> We are getting requests via both amdgpu/amdkfd and
On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote:
>
> I've kicked this around in my head over the past few weeks but wanted
> to get some feedback on whether it's a good idea or what impact it
> might have that I haven't considered.
>
> We are getting requests via both amdgpu/amdkfd and i915 for
On Tue, Oct 15, 2019 at 09:18:15PM +0200, Sebastian Andrzej Siewior wrote:
> The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect
> this change in the comment.
>
> Use `PREEMPTION' in the comment.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David
In DMA mode we have a maximum transfer size, past that the driver
falls back to PIO (see the check at the top of pxa2xx_spi_transfer_one).
Falling back to PIO for big transfers defeats the point of a dma engine,
hence set the max transfer size to inform spi clients that they need
to do something
On Wed, Oct 16, 2019 at 10:28 AM Matt Roper wrote:
>
> On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> > I've kicked this around in my head over the past few weeks but wanted
> > to get some feedback on whether it's a good idea or what impact it
> > might have that I haven't
On Mon, Aug 05, 2019 at 08:33:57AM -0600, Rob Herring wrote:
> Add support to the shmem GEM helpers for tracking madvise state and
> purging pages. This is based on the msm implementation.
>
> The BO provides a list_head, but the list management is handled outside
> of the shmem helpers as there
but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
platform means of putting the device into D3cold, right? That's
actually what should still happen, just the D3hot step should be
skipped.
On Wed, Oct 16, 2019 at 9:14 PM Bjorn Helgaas wrote:
>
> On Wed, Oct 16, 2019 at 04:44:49PM
On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote:
> Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> states.
>
> v2: convert to pci_dev quirk
> put a proper technical explanation of the issue as a in-code comment
> v3: disable it only for certain
Most Kconfig options to enable a driver are in the Kconfig file
inside the relevant directory, move these two to the same.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/Kconfig| 34 --
drivers/gpu/drm/amd/amdgpu/Kconfig | 18
On Wed, Oct 16, 2019 at 07:44:51PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2019 at 6:13 PM Andy Shevchenko
> > On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> > > Something like this, as a test patch.
> > max_transfer_size should be a function. In that case it works.
>
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #97 from Shmerl ---
Unfortunately I just got a random sdma Firefox hang, with that bitmask fix
enabled. I didn't enable other two patches above though. Building the 5.4-rc3
with all three applied now.
--
You are receiving this
On Wed, Oct 16, 2019 at 6:13 PM Andy Shevchenko
wrote:
>
> On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> > > Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > > > On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf
On 10/14/19 5:07 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
>> The CMA driver that registers these nodes will have to be expanded to
>> export them using this framework as needed. We do something similar to
>> export SRAM nodes:
>>
On Wed, Oct 9, 2019 at 10:38 AM Ayan Halder wrote:
>
> On Tue, Sep 24, 2019 at 04:22:18PM +, Ayan Halder wrote:
> > On Thu, Sep 19, 2019 at 10:21:52PM +0530, Sumit Semwal wrote:
> > > Hello Christoph, everyone,
> > >
> > > On Sat, 7 Sep 2019 at 00:17, John Stultz wrote:
> > > >
> > > > Here
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #30 from peter m ---
kernel 5.3.5-200.fc30.x86_64 (mockbu...@bkernel04.phx2.fedoraproject.org)
xfce - 4.14
kernel still crushing
[ cut here ]
WARNING: CPU: 2 PID: 184 at
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #34 from a...@tutanota.com ---
(In reply to Alex Deucher from comment #29)
> Created attachment 285507 [details]
> possible fix for uvd6
>
> The session info is 128K according to mesa.
This version of the patch didn't fail for 100
On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> I've kicked this around in my head over the past few weeks but wanted
> to get some feedback on whether it's a good idea or what impact it
> might have that I haven't considered.
>
> We are getting requests via both amdgpu/amdkfd and
On 10/15/19 8:42 AM, Daniel Vetter wrote:
On Tue, Oct 15, 2019 at 5:14 PM James Jones wrote:
On 10/15/19 7:19 AM, Daniel Vetter wrote:
On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote:
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to
Builds upon the existing NVIDIA 16Bx2 block linear
format modifiers by adding more "fields" to the
existing parameterized
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
macro that allow fully defining a unique-across-
all-NVIDIA-hardware bit layout using a minimal
set of fields and values. The
On Wed, 16 Oct 2019 15:31:25 +
Parav Pandit wrote:
> > -Original Message-
> > From: Cornelia Huck
> > Sent: Wednesday, October 16, 2019 3:53 AM
> > To: Parav Pandit
> > Cc: Alex Williamson ; Jason Wang
> > ; k...@vger.kernel.org; linux-s...@vger.kernel.org;
> >
Hi,
On Wed, Oct 16, 2019 at 03:51:39PM +, Mihail Atanassov wrote:
> Hi James,
>
> On Wednesday, 9 October 2019 06:54:15 BST james qian wang (Arm Technology
> China) wrote:
> > On Fri, Oct 04, 2019 at 02:34:42PM +, Mihail Atanassov wrote:
> > > To support transmitters other than the
On Wed, Oct 16, 2019 at 03:39:16PM +0200, Hans Verkuil wrote:
> From: Dariusz Marcinkiewicz
>
> Fill in the cec_connector_info when calling cec_notifier_conn_register().
>
> Signed-off-by: Dariusz Marcinkiewicz
> Tested-by: Hans Verkuil
> Signed-off-by: Hans Verkuil
> ---
>
Applied. Thanks!
Alex
On Tue, Oct 15, 2019 at 8:22 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.c:23:10: fatal error: drm/drmP.h: No
> such file or
On Wed, Oct 16, 2019 at 8:29 AM YueHaibing wrote:
>
> Fix sparse warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:746:6:
> warning: symbol 'dc_link_detect_helper' was not declared. Should it be
> static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Applied.
On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
> From: Dariusz Marcinkiewicz
>
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
Please explain
On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> > Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > > On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf Trønnes wrote:
> > >> spi-bcm2835 can handle >64kB buffers now so
On Wed, Oct 16, 2019 at 03:23:45PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> > On Wed, 16 Oct 2019 00:35:39 +0200
> > Daniel Vetter wrote:
> >
> >> Yeah I don't think tuning the spam level will ever work. What we need
> >> is some external input
Hi James,
On Wednesday, 9 October 2019 06:54:15 BST james qian wang (Arm Technology
China) wrote:
> On Fri, Oct 04, 2019 at 02:34:42PM +, Mihail Atanassov wrote:
> > To support transmitters other than the tda998x, we need to allow
> > non-component framework bridges to be attached to a dummy
Document the optional properties for describing module resets, to
support resetting display channels on R-Car Gen2 and Gen3.
Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Acked-by: Rob Herring
---
v4:
- Use "All but R8A7779" instead of "R8A779[0123456]", to reduce future
On Wed, Oct 16, 2019 at 01:52:00PM +0200, Gerd Hoffmann wrote:
> Add helper function to mmap ttm bo's using _gem_object_funcs.mmap().
>
> Note that with this code path access verification is done by
> drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
> The _bo_driver.verify_access()
On Wed, Oct 16, 2019 at 9:40 AM Laurent Pinchart
wrote:
>
> Hi Adam,
>
> Thank you for the patch.
>
> On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote:
> > This patch adds documentation of device tree bindings for the WVGA panel
> > Logic PD Type 28 display.
> >
> > Signed-off-by: Adam
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
Signed-off-by: Karol Herbst
Cc:
Hi Adam,
Thank you for the patch.
On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Logic PD Type 28 display.
>
> Signed-off-by: Adam Ford
> ---
> V5: Replace GPIO_ACTIVE_HIGH with 0 to fix make
On Wednesday, 16 October 2019 11:34:30 BST james qian wang (Arm Technology
China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds gamma and color-transform support for DOU-IPS.
> Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
> If color management changed,
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #33 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to me from comment #32)
> @Alex: Didn't have a crash with the old uvd6 patch (attachment 285473
> [details]) so far, but apparently I am just lucky.
>
> Which patch
The switch to per-process address spaces erroneously dropped the check
which validated that the command buffer is mapped through the linear
apperture as required by the hardware. This turned a system
misconfiguration with a helpful error message into a very hard to
debug issue. Reinstate the check
The GPU coredump function violates the locking order by holding the MMU
context lock while trying to acquire the etnaviv_gem_object lock. This
results in a possible ABBA deadlock with other codepaths which follow
the established locking order.
Fortunately this is easy to fix by dropping the MMU
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #32 from m...@cschwarz.com ---
@Alex: Didn't have a crash with the old uvd6 patch (attachment 285473) so far,
but apparently I am just lucky.
Which patch (series?) should I test now?
--
You are receiving this mail because:
You are
On Wed, Oct 16, 2019 at 3:46 PM Koenig, Christian
wrote:
>
> Am 08.10.19 um 10:55 schrieb Daniel Vetter:
> > On Wed, Oct 02, 2019 at 08:37:50AM +, Koenig, Christian wrote:
> >> Hi Daniel,
> >>
> >> once more a ping on this. Any more comments or can we get it comitted?
> > Sorry got a bit
On Wed, Oct 16, 2019 at 8:15 AM Rob Herring wrote:
>
> On Tue, Oct 15, 2019 at 6:04 PM Adam Ford wrote:
> >
> > On Wed, Oct 9, 2019 at 6:31 PM Rob Herring wrote:
> > >
> > > On Tue, Oct 01, 2019 at 06:39:22PM -0500, Adam Ford wrote:
> > > > This patch adds documentation of device tree bindings
This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.
Signed-off-by: Adam Ford
---
V5: Replace GPIO_ACTIVE_HIGH with 0 to fix make dt_binding_check -k
V4: Update per Rob H's suggestions and copy other panel yaml example from
5.4-rc1
V3: Correct
With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Acked-by: Sam Ravnborg
---
V5: No Change
V4:
Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly. This driver was removed so the screen
no longer functions. This patch modifies the panel-simple
file to setup the timings to the same values previously
Hi Jacopo,
Thank you for the patch.
On Wed, Oct 16, 2019 at 10:55:45AM +0200, Jacopo Mondi wrote:
> Implement CMM handling in the crtc begin and enable atomic callbacks,
> and enable CMM unit through the Display Extensional Functions
> register at group setup time.
>
> Reviewed-by: Kieran
This adds initial format modifiers for AMD GFX9 and newer GPUs.
This is particularly useful to determine if we can use DCC, and whether
we need an extra display compatible DCC metadata plane.
Design decisions:
- Always expose a single plane
This way everything works correctly with
Am 08.10.19 um 10:55 schrieb Daniel Vetter:
> On Wed, Oct 02, 2019 at 08:37:50AM +, Koenig, Christian wrote:
>> Hi Daniel,
>>
>> once more a ping on this. Any more comments or can we get it comitted?
> Sorry got a bit smashed past weeks, but should be resurrected now back
> from xdc.
And any
Hi Jacopo,
Thank you for the patch.
On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
This splits the previous v7.2 patch (1) into two parts: one that replaces
cec_notifier_get/put by cec_notifier_conn_(un)register, and one that
sets the connector info.
That second patch moves the CEC notifier code to tda998x_bridge_detach,
but Laurent is making changes in that area and prefers
From: Dariusz Marcinkiewicz
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 21 -
1 file changed, 16
From: Dariusz Marcinkiewicz
Fill in the cec_connector_info when calling cec_notifier_conn_register().
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++-
1 file changed, 18
Hi
Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> On Wed, 16 Oct 2019 00:35:39 +0200
> Daniel Vetter wrote:
>
>> Yeah I don't think tuning the spam level will ever work. What we need
>> is some external input (most likely from the user clicking the "my
>> external screen doesn't work" button,
On Tue, Oct 15, 2019 at 6:04 PM Adam Ford wrote:
>
> On Wed, Oct 9, 2019 at 6:31 PM Rob Herring wrote:
> >
> > On Tue, Oct 01, 2019 at 06:39:22PM -0500, Adam Ford wrote:
> > > This patch adds documentation of device tree bindings for the WVGA panel
> > > Logic PD Type 28 display.
> > >
> > >
On Wed, 16 Oct 2019 00:35:39 +0200
Daniel Vetter wrote:
> Yeah I don't think tuning the spam level will ever work. What we need
> is some external input (most likely from the user clicking the "my
> external screen doesn't work" button, or maybe the compositor
> realizing something that should
Hi, sorry for not having replied earlier
On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote:
> On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote:
>
> > > arch/sh/boards/mach-ecovec24/setup.c | 33 --
> >
> > I guess we're just waiting for the SH Acks now?
>
> The one
On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote:
> > arch/sh/boards/mach-ecovec24/setup.c | 33 --
>
> I guess we're just waiting for the SH Acks now?
The one maintainer with this board is probably overloaded.
I would say just apply it, it can't hold back the entire series.
https://bugs.freedesktop.org/show_bug.cgi?id=111987
--- Comment #12 from Witold Baryluk ---
Hi Alex.
I do understand that, it is a part of power management. That is not the bug is
about.
I did use pp_power_mode_profile too, and it doesn't really help. The issue is
that I would expect the
https://bugs.freedesktop.org/show_bug.cgi?id=111599
--- Comment #5 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111599
--- Comment #4 from Martin Peres ---
(In reply to Chris Wilson from comment #3)
> commit d17a484b3c22706b2b004ef1577f367d79235e43 (upstream/master,
> origin/master, origin/HEAD)
> Author: Chris Wilson
> Date: Wed Oct 2 12:22:29 2019 +0100
>
Fix typo where bits got compared (x < y) instead of shifted (x << y).
Signed-off-by: Patrik Jakobsson
---
include/drm/drm_scdc_helper.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_scdc_helper.h b/include/drm/drm_scdc_helper.h
index
https://bugs.freedesktop.org/show_bug.cgi?id=112033
Martin Peres changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |petri.latv...@intel.com
https://bugs.freedesktop.org/show_bug.cgi?id=112033
Bug ID: 112033
Summary: Store the runner and kernel logs as part of the IGT
results
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
> Factor out ttm vma setup to a new function.
> Reduces code duplication a bit.
>
> v2: don't change vm_flags (moved to separate patch).
> v4: make ttm_bo_mmap_vma_setup static.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König for this
From: Thierry Reding
If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups
From: Thierry Reding
If a client is already attached to an IOMMU domain that is not the
shared domain, don't try to attach it again. This allows using the
IOMMU-backed DMA API.
Since the IOMMU-backed DMA API is now supported and there's no way
to detach from it on 64-bit ARM, don't bother to
From: Thierry Reding
Rename paddr -> iova and vaddr -> virt to make it clearer how these
addresses are used. This is important for a subsequent patch that makes
a distinction between the physical address (physical address of the
system memory from the CPU's point of view) and the IOVA (physical
From: Thierry Reding
Having to provide allocator hooks to the Falcon library is somewhat
cumbersome and it doesn't give the users of the library a lot of
flexibility to deal with allocations. Instead, remove the notion of
Falcon "operations" and let drivers deal with the memory allocations
From: Thierry Reding
Add direction flags to host1x relocations performed during job pinning.
These flags indicate the kinds of accesses that hardware is allowed to
perform on the relocated buffers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 2 ++
include/linux/host1x.h
From: Thierry Reding
If the Tegra DRM clients are backed by an IOMMU, push buffers are likely
to be allocated beyond the 32-bit boundary if sufficient system memory
is available. This is problematic on earlier generations of Tegra where
host1x supports a maximum of 32 address bits for the GATHER
From: Thierry Reding
If host1x_bo_pin() returns an SG table, create a DMA mapping for the
buffer. For buffers that the host1x client has already mapped itself,
host1x_bo_pin() returns NULL and the existing DMA address is used.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 18
From: Thierry Reding
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin
buffers during host1x job submission. Pinning currently returns the SG
table and the DMA address (an IOVA if an IOMMU is used or a physical
address if no IOMMU is used) of the buffer. The DMA address is
Add helper function to mmap ttm bo's using _gem_object_funcs.mmap().
Note that with this code path access verification is done by
drm_gem_mmap() (which calls drm_vma_node_is_allowed(()).
The _bo_driver.verify_access() callback is is not used.
v3: use ttm_bo_mmap_obj instead of
Not needed any more because we don't have vram specific fops
any more. DEFINE_DRM_GEM_FOPS() can be used instead.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
include/drm/drm_gem_vram_helper.h | 18 --
drivers/gpu/drm/ast/ast_drv.c
VM_IO is wrong here, shmem uses normal ram not io memory.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
Add mmap callback to struct drm_gem_object_funcs, which is supposed to
handle the vma setup. It will be used by both normal fops->mmap (via
drm_gem_mmap_obj()) and prime mmap (via drm_gem_prime_mmap()).
For starters the shmem and vram helpers are switched over to the new
workflow, to show things
Not obvious why this is needed. According to Deniel Vetter this is most
likely a historic artefact dating back to the days where drm drivers
exposed hardware registers as mmap'able gem objects, to avoid dumping
touching those registers. shmem gem objects surely don't need that ...
Not needed any more.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj. Move the vm_pgoff sanity
check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree).
The ttm_bo_mmap_obj function can now be used to map any buffer object.
This allows to implement _gem_object_funcs.mmap in gem ttm helpers.
v3: patch added to
DEFINE_DRM_GEM_SHMEM_FOPS is identical
to DEFINE_DRM_GEM_FOPS now, drop it.
Signed-off-by: Gerd Hoffmann
Acked-by: Rob Herring
---
include/drm/drm_gem_shmem_helper.h | 26 -
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c |
Switch gem shmem helper to the new mmap() workflow,
from _driver.fops.mmap to _gem_object_funcs.mmap.
v2: Fix vm_flags and vm_page_prot handling.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Steven Price
---
include/drm/drm_gem_shmem_helper.h | 6 ++
Factor out ttm vma setup to a new function.
Reduces code duplication a bit.
v2: don't change vm_flags (moved to separate patch).
v4: make ttm_bo_mmap_vma_setup static.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 46 +
1 file changed, 24
Wire up the new drm_gem_ttm_mmap() helper function,
use generic drm_gem_mmap for and
delete dead drm_vram_mm_file_operations_mmap().
Signed-off-by: Gerd Hoffmann
Reviewed-by: Thomas Zimmermann
---
include/drm/drm_gem_vram_helper.h | 9 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 34
drm_gem_object_funcs->vm_ops alone can't handle everything which needs
to be done for mmap(), tweaking vm_flags for example. So add a new
mmap() callback to drm_gem_object_funcs where this code can go to.
Note that the vm_ops field is not used in case the mmap callback is
present, it is expected
1 - 100 of 166 matches
Mail list logo
