Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 272 ++
This series replaces the global disable_notify state by command-level bools to
control vq kicks. When command batching is applied to more places, this
prevents one process from affecting another process.
___
dri-devel mailing list
dri-devel@lists.freedes
Call virtqueue_kick_prepare once in virtio_gpu_enable_notify, not
whenever a command is added. This should be more efficient since
the intention is to batch commands.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
drivers/gpu/drm/virtio/virtgpu_vq.c | 28
The global disable_notify state does not scale well when we start
using it in more places and when there are multiple threads. Use
command-level bools to control whether to notify or not.
The naming conventions are
virtio_gpu_cmd_foo -> add foo and commit is implied
virtio_gpu_ctrl_bar -> ad
On Tue, Feb 04, 2020 at 04:41:16PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 03, 2020 at 10:31:13PM +0100, Mauro Rossi wrote:
> > Fixes the following building error:
> >
> > CC [M] drivers/gpu/drm/drm_edid.o
> > ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function
> > 'cea_mode_altern
On Fri, 31 Jan 2020 13:15:52 +0200, Peter Ujfalusi wrote:
> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>
> Signed-off-by: Peter Ujfalusi
> ---
> .../display/bridge/toshiba,tc358768.yaml | 159 ++
> 1 file changed, 159 insertions(+)
> create mode 100644
> Docum
On Tue, Feb 04, 2020 at 07:45:37PM +0530, Harigovindan P wrote:
> Updating bindings of dsi and dpu by adding and removing certain
> properties.
Yes, the diff tells me that. The commit message should say why.
This change breaks compatibility as well.
>
> Signed-off-by: Harigovindan P
> ---
>
>
On Wed, 29 Jan 2020 09:56:13 +0100, Benjamin Gaignard wrote:
> Convert etnaviv bindings to yaml format.
> Move bindings file from display to gpu folder.
>
> Signed-off-by: Benjamin Gaignard
> ---
> version 3:
> - describe clock-names as enum to allow all possible mix
>
> version 2:
> - move bind
On Thu, 6 Feb 2020 14:33:42 +0100, Benjamin Gaignard wrote:
> From: Sam Ravnborg
>
> To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> panel-simple-dsi-yaml are for all simple DSP panels with a single
> power-supply and optional backlight / enable GPIO.
>
> Migrate panasonic,vvx10
On Thu, 6 Feb 2020 14:33:43 +0100, Benjamin Gaignard wrote:
> Convert raydium,rm68200 to json-schema.
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../bindings/display/panel/raydium,rm68200.txt | 25 --
> .../bindings/display/panel/raydium,rm68200.yaml| 56
>
On Thu, 6 Feb 2020 14:33:44 +0100, Benjamin Gaignard wrote:
> Convert orisetech,otm8009a to json-schema.
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../bindings/display/panel/orisetech,otm8009a.txt | 23 --
> .../bindings/display/panel/orisetech,otm8009a.yaml | 53
> +
Hi Ulf,
On Mon, Jan 27, 2020 at 3:55 PM Ulf Hansson wrote:
>
> On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wrote:
> >
> > +Ulf to keep me honest on the power domains
> >
> > On Thu, Jan 9, 2020 at 10:08 PM Steven Price wrote:
> > >
> > > On 08/01/2020 05:23, Nicolas Boichat wrote:
> > > > Whe
On Fri, Feb 7, 2020 at 10:04 AM Nicolas Boichat wrote:
>
> Hi Ulf,
>
> On Mon, Jan 27, 2020 at 3:55 PM Ulf Hansson wrote:
> >
> > On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wrote:
> > >
> > > +Ulf to keep me honest on the power domains
> > >
> > > On Thu, Jan 9, 2020 at 10:08 PM Steven Price
On Mon, Jan 20, 2020 at 10:53 PM Steven Price wrote:
>
> On 14/01/2020 07:16, Nicolas Boichat wrote:
> [snip]
> >
> > + err = panfrost_pm_domain_init(pfdev);
> > + if (err) {
> > + dev_err(pfdev->dev, "pm_domain init failed %d\n", err);
>
> No need for this print - panfrost_pm_
Hi Linus,
Just some fixes on top of the merge windows pull, the tegra changes
fix some regressions in the merge, nouveau has a few modesetting
fixes. The amdgpu fixes are bit bigger, but they contain a couple of
weeks of fixes, and doesn't seem to contain anything that isn't really
a fix.
Regards
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
---
v4:
- Add power domain names.
v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
drivers/gpu/drm/panfrost/panfrost_drv.c | 11
When there is a single power domain per device, the core will
ensure the power domain is switched on (so it is technically
equivalent to having not power domain specified at all).
However, when there are multiple domains, as in MT8183 Bifrost
GPU, we need to handle them in driver code.
Signed-off
Hi!
Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/.
The main purpose of this series is to upstream the dts change and the
binding document, but I wanted to see how far I could probe the GPU, to
check that the binding is indeed correct. The rest of the patches are
RFC/work-in-pr
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
It is useful to know which component cannot be powered on.
Signed-off-by: Nicolas Boichat
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
Was useful when trying to probe Bifrost GPU, to understand what
issue we are facing.
v4:
- No change
v3:
- Rebased on https://patchwork.kern
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.
TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 1
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
We extend the framework in a generic manner so that we could
support more than 2 regulators, if required.
Signed-off-by: Nicolas Boichat
---
v4:
- nits: Run through latest ve
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
v4:
- Add power-domain-names description
(kept Alyssa's reviewed-by as the change is minor)
v3:
- No change
.../bindings/gpu/arm,mali-bif
On 2/7/20 6:26 AM, Nicolas Boichat wrote:
Hi!
Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/.
The main purpose of this series is to upstream the dts change and the
binding document, but I wanted to see how far I could probe the GPU, to
check that the binding is indeed correct
Hi,
> > + indirect = virtio_has_feature(vgdev->vdev,
> > VIRTIO_RING_F_INDIRECT_DESC);
> > + vqcnt = indirect ? 1 : elemcnt;
> Is the feature dynamic and require the lock held? If not, the result
> can be cached and the fixup can happen before grabbing the lock
Not dynamic, so yes
If the virtio device supports indirect ring descriptors we need only one
ring entry for the whole command. Take that into account when checking
whenever the virtqueue has enough free entries for our command.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
driver
On Thu, Feb 6, 2020 at 10:47 PM Gerd Hoffmann wrote:
>
> If the virtio device supports indirect ring descriptors we need only one
> ring entry for the whole command. Take that into account when checking
> whenever the virtqueue has enough free entries for our command.
>
> Signed-off-by: Gerd Hoff
On Fri, Feb 7, 2020 at 2:18 PM Tomeu Vizoso wrote:
>
> On 2/7/20 6:26 AM, Nicolas Boichat wrote:
> > Hi!
> >
> > Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/.
> >
> > The main purpose of this series is to upstream the dts change and the
> > binding document, but I wanted to se
Signed-off-by: Gerd Hoffmann
Gerd Hoffmann (4):
drm/virtio: simplify virtio_gpu_alloc_cmd
drm/virtio: resource teardown tweaks
drm/virtio: move mapping teardown to virtio_gpu_cleanup_object()
drm/virtio: move virtio_gpu_mem_entry initialization to new function
drivers/gpu/drm/virtio/vir
Add new virtio_gpu_cleanup_object() helper function for object cleanup.
Wire up callback function for resource unref, do cleanup from callback
when we know the host stopped using the resource.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 4 +++-
drivers/gpu/drm/vir
Stop sending DETACH_BACKING commands, that will happening anyway when
releasing resources via UNREF. Handle guest-side cleanup in
virtio_gpu_cleanup_object(), called when the host finished processing
the UNREF command.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h|
Just call virtio_gpu_alloc_cmd_resp with some fixed args
instead of duplicating most of the function body.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/virtio/v
Introduce new virtio_gpu_object_shmem_init() helper function which will
create the virtio_gpu_mem_entry array, containing the backing storage
information for the host. For the most path this just moves code from
virtio_gpu_object_attach().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio
On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote:
>
> This patch resolves these compiler errors and warnings --
>
> CC drivers/video/fbdev/g364fb.o
> drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
> drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this
> f
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi,
>
> this contains a couple of fixes for a DMA API performance regression
> that was introduced in v5.5 for older Tegra devices. Patches 1 and 2
> will likely have to be backported to v5.5.
>
> Thierry
>
> Thierry Reding (3)
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> Older Tegra devices only allow addressing 32 bits of memory, so whether
> or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU
> attachment is only needed on devices that can address memory beyond the
> 32-bit bo
Conversion of instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_dp_mst.c.
This also involves extracting the drm_i915_private device pointer from
various intel types to use in the macros.
Signed-off-by: Wambui Karuga
---
drivers/g
Conversion of various instances of the printk based drm logging macros
to the struct drm_device based logging macros in
i915/display/intel_hdmi.c.
This also involves extraction of the drm_i915_private device from
various intel/drm types for use in the logging macros.
Note that this converts DRM_DE
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_dp.c.
This also involves extracting the struct drm_i915_private device pointer
from various intel types to be used in the macros.
Signed-off-by: Wambui Karuga
---
Conversion of the printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_combo_phy.c.
This transformation was achieved using the following coccinelle script
that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
04.02.2020 16:59, Thierry Reding пишет:
> - sgt = host1x_bo_pin(host->dev, g->bo, NULL);
> + /**
^
Although one nit: ^ the second asterisk isn't needed :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:
> On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote:
> >
> > This patch resolves these compiler errors and warnings --
> >
> > CC drivers/video/fbdev/g364fb.o
> > drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
> > drivers/video/fb
This patchset continues the conversion of the printk based drm logging
macros in drm/i915 to use the struct drm_device based logging macros.
This series was done both using coccinelle and manually.
v2: rebase onto drm-tip to fix conflicts with new changes in drm/i915.
Wambui Karuga (12):
drm/i9
This file doesn't need everything provided by .
All it needs are some types, which are provided by .
Note, already includes , but
not relying on implicit includes is indeed a good thing.
Signed-off-by: Andy Shevchenko
---
v2: Update commit message (Geert, Laurent)
include/linux/platform_data/s
Conversion of the printk based drm logging macros to the struct
drm_device based logging macros in display/intel_dp_aux_backlight.c.
This also involves extracting the drm_i915_private device pointer from
various intel types to use in the macros.
Note that this converts DRM_DEBUG_DRIVER to drm_dbg(
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> The DMA direction is only used by the DMA API, so there is no use in
> setting it when a buffer object isn't mapped with the DMA API.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/host1x/job.c | 2 +-
> 1 file changed,
Reviewed-by: Alyssa Rosenzweig
Although it might be nice to
#define TRANSLATION_FAULT_LEVEL1 0xC1
...
#define TRANSLATION_FAULT_LEVEL4 0xC4
and then use semantic names instead of magic values. Minimally maybe add
a comment explaining that.
On Wed, Feb 05, 2020 at 11:07
Replaces various instances of the printk based logging macros with the
struct drm_device based logging macros in i915/display/intel_crt.c using
the following coccinelle script that matches based on the existence of a
drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_p
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> This partially reverts the DMA API support that was recently merged
> because it was causing performance regressions on older Tegra devices.
> Unfortunately, the cache maintenance performed by dma_map_sg() and
> dma_unmap_sg() cau
Adding support for visionox rm69299 panel driver and adding bindings for the
same panel.
Harigovindan P (2):
dt-bindings: display: add visionox rm69299 panel variant
drm/panel: add support for rm69299 visionox panel driver
.../bindings/display/visionox,rm69299.yaml | 109 ++
dri
Conversion of the printk based logging macros to the struct drm_device
based logging macros in i915/display/intel_dpio_phy.c.
This was achieved using the following coccinelle semantic patch that
matches based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@
fn(...,struct drm_
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Split out panel driver patch from dsi config changes(Rob Clark).
- Remove unrelated code(Stephen Boyd).
- Remove static arrays to make regulator setup open coded
in probe(Ste
Document the bindings used for the Cadence MHDP DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,mhdp.yaml| 125 ++
1 file changed, 125 insertions(+)
create mode 100644
Documentation/devicetree/bindings
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in
i915/display/intel_dp_link_training.c.
This also involves extracting the drm_i915_private device pointer from
the intel_dp type to use in the various macros.
Signed-off-by: Wambui Kar
This patch series adds new DRM driver for Cadence Display Port.
The Cadence Display Port is also referred as MHDP (Mobile High
Definition Link, High-Definition Multimedia Interface Display
Port) Cadence Display Port complies with VESA DisplayPort (DP)
and embedded Display Port (eDP) standards. This
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Added a compatible string to support sc7180 panel version.
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob He
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> Older Tegra devices only allow addressing 32 bits of memory, so whether
> or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU
> attachment is only needed on devices that can address memory beyond the
> 32-bit bo
Add j721e wrapper for mhdp, which sets up the clock and data muxes.
Signed-off-by: Yuti Amonkar
---
drivers/gpu/drm/bridge/Kconfig | 12
drivers/gpu/drm/bridge/Makefile | 3 +
drivers/gpu/drm/bridge/cdns-mhdp-core.c | 14 +
drivers/gpu/drm/bridge/cdns-mhdp-core.h |
Conversion of the printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_atomic.c
This change was achieved using the following coccinelle script that
matches based on the existence of a drm_i915_private device pointer:
@@
identifier fn, T;
@@
fn(...,str
This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e SoC.
MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
embedded Display Port (eDP) standards. It integrates uCPU running the
embedded Firmware(FW) interfaced over APB interface.
Basically, it takes a DPI
On 2/5/20 7:02 PM, Philippe Mathieu-Daudé wrote:
> On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote:
>>
>> This patch resolves these compiler errors and warnings --
>>
>> CC drivers/video/fbdev/g364fb.o
>> drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
>> drivers/video/fbdev/g364
Conversion of instances of printk based drm logging macros to the struct
drm_device based logging macros in i915/display/intel_dpll_mgr.c.
This also involves extracting the struct drm_i915_private device pointer
from various intel types to use in the drm_device based macros.
Note that this convert
Initial conversion of the straightforward printk based logging macros to
the struct drm_device based logging macros in
i915/display/intel_color.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_color.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dri
On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:
> Note, you need to rebase your series due to:
>
> commit 8a48ac339398f21282985bff16552447d41dcfb2
> Author: Jani Nikula
> Date: Tue Dec 3 18:38:50 2019 +0200
>
> video: constify fb ops across all drivers
>
OK.
Thanks for your r
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> The DMA direction is only used by the DMA API, so there is no use in
> setting it when a buffer object isn't mapped with the DMA API.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/host1x/job.c | 2 +-
> 1 file changed,
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> This partially reverts the DMA API support that was recently merged
> because it was causing performance regressions on older Tegra devices.
> Unfortunately, the cache maintenance performed by dma_map_sg() and
> dma_unmap_sg() cau
Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_dsi_vbt.c.
This also involves extracting the drm_i915_private device from the
intel_dsi type for use in the logging macros.
This converts DRM_DEBUG/DRM_DEBUG_DRIVER
Hi,
> > virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle,
> > - ents, nents,
> > + obj->ents, obj->nents,
> >fence);
> > + obj->
On Wed, Feb 05, 2020 at 10:19:53AM -0800, Chia-I Wu wrote:
> Make sure elemcnt does not exceed the maximum element count in
> virtio_gpu_queue_ctrl_sgs. We should improve our error handling or
> impose a size limit on execbuffer, which are TODOs.
Hmm, virtio supports indirect ring entries, so lar
After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++
drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++--
driver
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_display.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h
b/drivers/gpu/drm/nouveau/nouveau_display.h
index 6e8e66882e45..e397b3d246e5 100644
--- a/drivers/gpu/drm/nouveau/nouve
The buffer object stored in nvbo is also available GEM object in obj[0]
of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and
replace all references accordingly. This may require an additional cast.
With this change we can already replace nouveau_user_framebuffer_destroy()
and nouve
The vma field of struct nouveau_framebuffer is a special field for the
the accelerated fbdev console. Hence there's at most one single instance
for the active console. Moving it into struct nouveau_fbdev makes struct
nouveau_framebuffer slightly smaller and brings it closer to struct
drm_framebuffe
All fields in struct nouveau_framebuffer appear to be obsolete. The
data structure can be replaced by struct drm_framebuffer entirely.
Patch 1 removes several unused fields from struct nouveau_framebuffer.
Patch 2 moves the field vma to struct nouveau_fbdev. The information
in vma is only relevan
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functiona
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> Hi Andrey,
>
> This commit breaks all drivers, which may bail out of the timeout
> processing as they wish to extend the timeout (etnaviv, v3d).
>
> Those drivers currently just return from the timeout handler before
> calling drm_sc
If the virtio device supports indirect ring descriptors we need only one
ring entry for the whole command. Take that into account when checking
whenever the virtqueue has enough free entries for our command.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 9 ++---
1 f
On Wed, Feb 05, 2020 at 10:19:44AM -0800, Chia-I Wu wrote:
> This series consists of fixes and cleanups for
> virtio_gpu_queue_fenced_ctrl_buffer, except for the last patch. The fixes are
> for corner cases that were overlooked. The cleanups make the last patch
> easier, but they should be good i
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as they wish to extend the timeout (etnaviv, v3d).
Those drivers currently just return from the timeou
On Thu, Feb 06, 2020 at 05:59:51PM +1100, evanb...@google.com wrote:
> From: Sean Paul
>
> Currently the cursor is placed on the first overlay plane, which means
> it will be at the bottom of the stack when the hw does the compositing
> with anything other than primary plane. Since mtk doesn't su
We need to use the AS attached to the opened FD when dumping counters.
Reported-by: Antonio Caggiano
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 ++-
drivers/gpu/drm/panfrost/p
https://bugzilla.kernel.org/show_bug.cgi?id=206441
Bug ID: 206441
Summary: kernel crash when amdgpu reset while very high loading
Product: Drivers
Version: 2.5
Kernel Version: 5.3.15
Hardware: All
OS: Linux
Tr
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
>
> Am 06.02.20 um 12:10 schrieb Lucas Stach:
> > Hi all,
> >
> > On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> >> Hi Andrey,
> >>
> >> This commit breaks all drivers, which may bail out of the timeout
> >> processing as they wish to e
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as
On 06/02/2020 14:13, Boris Brezillon wrote:
> We need to use the AS attached to the opened FD when dumping counters.
Indeed we do!
Reviewed-by: Steven Price
>
> Reported-by: Antonio Caggiano
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc:
> Signed-off-by: Boris
Note I'm adding some fields to nouveau_framebuffer in the series
"drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that
yesterday. It would probably still be possible to avoid them by
re-extracting the relevant data from the format modifier on the fly when
needed, but it is sim
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
> Note I'm adding some fields to nouveau_framebuffer in the series
> "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that
> yesterday. It would probably still be possible to avoid them by
> re-extracting the relevant data from t
On 2/6/20 9:51 AM, Christian König wrote:
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, whic
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
"drm
Hi,
I'd appreciate if you could take a look at this patch. I believe I
have accommodated the earlier review comments.
Thank you,
Bas
On Fri, Jan 24, 2020 at 12:58 AM Bas Nieuwenhuizen
wrote:
>
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/sign
Yes, that's certainly viable. If that's the general preference in
direction, I'll rework that patches to do so.
Thanks,
-James
On 2/6/20 7:49 AM, Thomas Zimmermann wrote:
Hi James
Am 06.02.20 um 16:17 schrieb James Jones:
Note I'm adding some fields to nouveau_framebuffer in the series
"drm
Hi Dave,
The following changes since commit 033ccdb7f6b11701623507339646013b4ce389d3:
gpu: host1x: Remove dev_err() on platform_get_irq() failure (2020-01-10
17:05:12 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.6-rc1-fixes
On Wed, 2020-02-05 at 23:27 +, Eric Engestrom wrote:
> On Wednesday, 2020-02-05 23:10:21 +, Li, Juston wrote:
> > On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote:
> > > On Friday, 2020-01-31 13:41:09 -0800, Juston Li wrote:
> > > > From: Daniel Stone
> > > >
> > > > Add a wrapper
https://bugzilla.kernel.org/show_bug.cgi?id=206225
--- Comment #12 from Christoph Marz (derchiller-fo...@online.de) ---
Follow-up:
After a dist-upgrade, the error returned. I deleted the video acceleration
firmware and it was ok again.
When I installed 5.4.14, there were warnings about possibly
On Sun, Feb 02, 2020 at 05:37:31PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-02-02 13:21:33)
> > There's two references floating around here (for the object reference,
> > not the handle_count reference, that's a different thing):
> >
> > - The temporary reference held by vgem_gem_c
On Thu, Feb 6, 2020 at 1:49 AM Gerd Hoffmann wrote:
>
> On Wed, Feb 05, 2020 at 10:19:53AM -0800, Chia-I Wu wrote:
> > Make sure elemcnt does not exceed the maximum element count in
> > virtio_gpu_queue_ctrl_sgs. We should improve our error handling or
> > impose a size limit on execbuffer, which
On Thu, Feb 6, 2020 at 3:14 AM Gerd Hoffmann wrote:
>
> If the virtio device supports indirect ring descriptors we need only one
> ring entry for the whole command. Take that into account when checking
> whenever the virtqueue has enough free entries for our command.
>
> Signed-off-by: Gerd Hoffm
On Wed, Feb 5, 2020 at 10:43 PM Gerd Hoffmann wrote:
>
> > > -
> > > - drm_gem_shmem_free_object(obj);
> > > + if (bo->created) {
> > > + virtio_gpu_cmd_unref_resource(vgdev, bo);
> > > + /* completion handler calls virtio_gpu_cleanup_object() */
> > nitpick
On Thu, Feb 6, 2020 at 12:55 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle,
> > > - ents, nents,
> > > + obj->ents, obj->nents,
> > >
Hi,
On Wed, Feb 5, 2020 at 1:00 PM Rob Clark wrote:
>
> On Wed, Feb 5, 2020 at 12:48 PM Jordan Crouse wrote:
> >
> > Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed
> > updating the VBIF flush in a6xx_gmu_shutdown and instead
> > inserted the new sequence into a6xx_pm_suspend
1 - 100 of 111 matches
Mail list logo
