On 2020/6/25 上午7:21, Michael S. Tsirkin wrote:
Now that the corresponding feature bit has been renamed,
rename the quirk too - it's about special ways to
do DMA, not necessarily about the IOMMU.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gp
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #30 from mn...@protonmail.com ---
I've been looking at this bug for a while now and I'll try to share what I've
found about it.
In some conditions, when amdgpu_dm_atomic_commit_tail calls
dm_atomic_get_new_state, dm_atomic_get_new_sta
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c-Removing-that-prohibited-space-before/20200627-125315
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: x86_64
Finalize he conversion of GMA500 to use only GPIO descriptors.
The GPIO look-up-table is associated with the device directly
in the GMA500 Medfield chip driver since no explicit platform
type device (such as in x86/platform/intel-mid) exists: the
GMA500 probes directly from the PCI device. Apparent
https://bugzilla.kernel.org/show_bug.cgi?id=207383
zzyx...@gmail.com changed:
What|Removed |Added
CC||zzyx...@gmail.com
--- Comment #29 fro
On Sat, Jun 27, 2020 at 10:07 PM Patrik Jakobsson
wrote:
> On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij
> wrote:
> >
> > This file includes but does not use any
> > symbols from it, drop the include.
>
> Hi Linus,
> Seems the include should be moved to mdfld_dsi_output.c instead.
Yeah we are
Hi Dmitry,
Thank you for the patch.
On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> This patch adds missing BUS fields to the display panel descriptions of
> the panels which are found on NVIDIA Tegra devices:
>
> 1. AUO B101AW03
> 2. Chunghwa CLAA070WP03XG
> 3. Chunghwa
On Mon, Jun 22, 2020 at 01:27:40AM +0300, Dmitry Osipenko wrote:
> Hello,
>
> This is a follow up to [1], which was already applied to drm-misc and then
> Laurent Pinchart spotted some problems. This series addresses those problems.
>
> [1]
> https://patchwork.ozlabs.org/project/linux-tegra/patc
On Sat, Jun 27, 2020 at 12:56 PM Rob Clark wrote:
>
> On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse wrote:
> >
> > Add support for using per-instance pagetables if all the dependencies are
> > available.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c
On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij wrote:
>
> This file includes but does not use any
> symbols from it, drop the include.
Hi Linus,
Seems the include should be moved to mdfld_dsi_output.c instead.
Thanks
Patrik
>
> Cc: Patrik Jakobsson
> Signed-off-by: Linus Walleij
> ---
> dri
On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse wrote:
>
> Add support for using per-instance pagetables if all the dependencies are
> available.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
> drivers/gpu/drm/msm/msm_ringbuffer.
Hi Liu,
thanks for the notice.
Laurent, I trust you will take a look and resolve this.
Sam
On Thu, Jun 25, 2020 at 04:48:01PM +0800, Liu Ying wrote:
> Hi Sam,
>
> On Tue, 2020-06-23 at 20:55 +0200, Sam Ravnborg wrote:
> > Hi Laurent.
> >
> > On Tue, May 26, 2020 at 04:14:38AM +0300, L
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" so
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just g
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouve
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushi
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).
First - we add some new functionality to kt
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by
This got me confused for a bit while looking over this code: I had been
planning on adding some blocking function calls into this function, but
seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it
very clear whether or not that would actually be safe.
So I went ahead and review
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to in
On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/
On Wed, May 20, 2020 at 03:39:31PM +0200, Erwan Le Ray wrote:
> Add support of generic DT binding for annoucing RTS/CTS lines. The initial
> binding 'st,hw-flow-control' is not needed anymore since generic binding
> is available, but is kept for backward compatibility.
>
> Signed-off-by: Erwan Le
On 26/06/2020 13:01, Andrzej Hajda wrote:
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is probe_err function introduced recently,
ie. if
https://bugzilla.kernel.org/show_bug.cgi?id=207673
--- Comment #5 from phileimer (p...@jpmr.org) ---
Created attachment 289897
--> https://bugzilla.kernel.org/attachment.cgi?id=289897&action=edit
amdgpu: kernel log when over temperature crash
--
You are receiving this mail because:
You are wat
From: Shawn Guo
The msm/mdp5 driver uses state of drm_private_obj as its global atomic
state, which keeps the assignment of hwpipe to plane. With
drm_private_obj missing from duplicate state call in context of atomic
suspend/resume helpers, mdp5 suspend works with no problem only for the
very fi
On Fri, Jun 26, 2020 at 02:11:31PM +0200, Maxime Ripard wrote:
> The example used in the DPI binding before the conversion to YAML had a
> simple-panel example that got carried over to the YAML binding.
>
> However, that example doesn't match the simple-panel binding and results in
> validation er
The example used in the DPI binding before the conversion to YAML had a
simple-panel example that got carried over to the YAML binding.
However, that example doesn't match the simple-panel binding and results in
validation errors. Since it's only marginally helpful, let's remove that
part of the e
26.06.2020 10:34, Thierry Reding пишет:
> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> ### DRM_TEGRA_CHANNEL_MAP
>>>
>>> Make memory accessible by the engine while executing work on the channel.
>>>
>>> ```
>>> #define DRM_TEGRA_CH
On Fri, Jun 26, 2020 at 05:06:00PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 03:40:20PM +0200, Daniel Vetter wrote:
> > Adding Lyude, she's been revamping all the lifetime refcouting in the
> > dp code last few kernel releases. At a glance I don't even have an
> > idea what's going wron
Some of these comments are part of the Linux GPU Driver Developer's
Guide.
Fix some minor typo in the comments and remove a repeated 'the'.
Signed-off-by: Antonio Borneo
---
drivers/gpu/drm/drm_connector.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
26.06.2020 16:38, Daniel Vetter пишет:
> On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote:
>> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote:
>>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote:
# Host1x/TegraDRM UAPI proposal
This is a proposa
Den 22.06.2020 16.05, skrev Pekka Paalanen:
> From: Pekka Paalanen
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC
> and
> from https://lists.freedesktop.org/archive
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: i386-randconfig-a005-20200624 (attached as
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: m68k-randconfig-r016-20200624 (attached as
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #28 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #27)
> and another crash, chrome's good at causing them (watching youtube). Used -s
> "" for the setting which I think should set it to 'auto', and wh
trace_printk should not be used in production code. Since
tracing interrupts is presumably latency sensitive, pr_dbg is
not appropriate, so guard the call with a preprocessor symbol
that can be defined for debugging purpose.
Signed-off-by: Nicolas Boichat
---
drivers/media/platform/qcom/camss/c
trace_printk should not be used in production code, replace it
call with dev_dbg.
Signed-off-by: Nicolas Boichat
---
Unclear why a trace_printk was used in the first place, it's
possible that some rate-limiting is necessary here.
drivers/usb/cdns3/gadget.c | 2 +-
1 file changed, 1 insertion(
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled, or source code changes, as indicated by the
warning that shows up on boot if any trace_printk is called:
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
trace_printk should not be used in production code, replace it
call with pr_info.
Signed-off-by: Nicolas Boichat
---
drivers/staging/media/atomisp/pci/hmm/hmm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm.c
b/drivers/
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled or source code changes.
Patches 1 to 3 remove/disable trace_printk that should not
be enabled by default.
Patch 4 adds a config option that can be used to dete
42 matches
Mail list logo
