On Wed, Aug 04, 2021 at 06:34:36AM +0200, Oleksij Rempel wrote:
> changes v4:
> - add vref-supply to adc@0
> - split gpio assignment for the mdio node
>
> changes v3:
> - drop panel bindings patches, it is already in drm-misc-next
> - remove some new lines
> - reorder compatibles at the start of
Thanks for the remind, indeed miss a lock. Patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Fri, Aug 13, 2021 at 3:28 AM Daniel Vetter wrote:
>
> On Thu, Aug 05, 2021 at 12:46:53PM +0200, Daniel Vetter wrote:
> > Nothing special going on here.
> >
> > Aside reviewing the code, it seems like
On Mon, 09 Aug 2021 13:10:07 +0800, Shawn Guo wrote:
> The Sony Tulip Truly NT35521 is a 5.24" 1280x720 DSI panel, which can
> be found on Sony Xperia M4 Aqua phone. The backlight is managed
> through DSI link.
>
> Signed-off-by: Shawn Guo
> ---
> .../panel/sony,tulip-truly-nt35521.yaml
On Mon, 09 Aug 2021 04:34:22 +0300, Laurent Pinchart wrote:
> The DPSUB doesn't live in isolation, but is connected to the
> programmable logic for live inputs and outputs, and also has a
> DisplayPort output. Model all those using OF graph.
>
> Signed-off-by: Laurent Pinchart
> ---
>
On Sun, Aug 08, 2021 at 07:10:39AM +0200, H. Nikolaus Schaller wrote:
> From: Sam Ravnborg
>
> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> Based on .txt binding from Zubair Lutfullah Kakakhel
>
> Signed-off-by: Sam Ravnborg
> Signed-off-by: H. Nikolaus Schaller
> Cc: Rob
On Sat, 07 Aug 2021 16:31:10 +0300, Markuss Broks wrote:
> This adds device-tree bindings for the Samsung S6D27A1 RGB
> DPI display panel.
>
> Signed-off-by: Markuss Broks
>
> v1 -> v2:
> changed additionalProperties to unevaluatedProperties;
> added vci-supply and vccio-supply as required;
>
On Tue, Aug 10, 2021 at 06:10:43PM +0200, Thierry Reding wrote:
> On Tue, Aug 10, 2021 at 06:50:26PM +0300, Mikko Perttunen wrote:
> > On 10.8.2021 18.43, Thierry Reding wrote:
> > > On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote:
> > > > Convert the original Host1x bindings to
It's been invariant since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
this just completes the deed. I've tried to split out prep work for
more
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in ggtt mode, unlike intel_context->vm or
Since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
the gem_ctx->vm can't change anymore. Plus we always set the
intel_context->vm, so might as well use the
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
The comment added in
commit b81dde719439c8f09bb61e742ed95bfc4b33946b
Author: Chris Wilson
Date: Tue May 21 22:11:29 2019 +0100
drm/i915: Allow userspace to clone contexts on creation
and moved in
commit 27dbae8f36c1c25008b7885fc07c57054b7dfba3
Author: Chris
The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.
The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full
Changing the vm from a finalized gem ctx is no longer possible, which
means we don't have to check for that anymore.
I was pondering whether to keep the check as a WARN_ON, but things go
boom real bad real fast if the vm of a vma is wrong. Plus we'd need to
also get the ggtt vm for !full-ppgtt
gem context refcounting is another exercise in least locking design it
seems, where most things get destroyed upon context closure (which can
race with anything really). Only the actual memory allocation and the
locks survive while holding a reference.
This tripped up Jason when reimplementing
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking context.
Unfortunately untangling that
On 8/13/21 12:08 PM, Tom Lendacky wrote:
On 8/12/21 5:07 AM, Kirill A. Shutemov wrote:
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
On 8/10/21 1:45 PM, Kuppuswamy,
https://bugzilla.kernel.org/show_bug.cgi?id=214001
--- Comment #4 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Linux_Chemist from comment #3)
> Thanks for your comment, Duncan!
> Yes, I'm on a customised kernel that has a lot removed (including debugfs as
> you can tell) and also amdgpu
On Fri, 2021-08-13 at 08:49 -0700, Kees Cook wrote:
>
> Ah! Yes, thanks for pointing this out. During earlier development I split
> the "cross-field write" changes from the "cross-field read" changes, and
> it looks like I missed moving lib80211_crypt_ccmp.c into that portion of
> the series
In rare cases the display is flipped or mirrored. This was observed more
often in a low temperature environment. A clean reset on init_display()
should help to get registers in a sane state.
Signed-off-by: Oliver Graute
---
drivers/staging/fbtft/fb_st7789v.c | 2 ++
1 file changed, 2
On 13/08/21, Greg KH wrote:
> On Fri, Aug 13, 2021 at 08:25:10AM +0200, Oliver Graute wrote:
> > staging: fbtft: fb_st7789v: reset display before initialization
>
> What is this line here, and why is this not your subject line instead?
I'll put the line as subject instead.
> > In rare cases the
On Fri, Aug 13, 2021 at 05:11:59PM +0200, Daniel Vetter wrote:
> On Thu, Aug 12, 2021 at 10:38:18PM +, Matthew Brost wrote:
> > On Thu, Aug 12, 2021 at 09:47:23PM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> > > > On Thu, Aug 12, 2021 at
https://bugzilla.kernel.org/show_bug.cgi?id=214001
--- Comment #3 from Linux_Chemist (untaintablean...@hotmail.co.uk) ---
Thanks for your comment, Duncan!
Yes, I'm on a customised kernel that has a lot removed (including debugfs as
you can tell) and also amdgpu (RX 5700).
There's usually a bug
On Fri, 2021-08-13 at 09:08 -0700, Kees Cook wrote:
> >
> > The common helper should also clear ack_signal, but that was broken by
> > commit e3e1a0bcb3f1 ("mac80211: reduce IEEE80211_TX_MAX_RATES"), because
> > that commit changed the order of the fields and updated carl9170 and p54
> > properly
https://bugzilla.kernel.org/show_bug.cgi?id=214001
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
CC||1i5t5.dun...@cox.net
---
On 8/13/21 11:59 AM, Tom Lendacky wrote:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to the
On 8/13/21 9:59 AM, Tom Lendacky wrote:
In prep for other protected virtualization technologies, introduce a
generic helper function, prot_guest_has(), that can be used to check
for specific protection attributes, like memory encryption. This is
intended to eliminate having to add multiple
13.08.2021 20:12, Dmitry Osipenko пишет:
...
> I probably should update compiler or set W=1 to get that warning. These
> variables were used in older versions of the patch and they can be removed
> now.
>
> Please amend the patch with this:
Perhaps too late already. I'll make patch for that
On Fri, Aug 13, 2021 at 9:44 AM Andy Shevchenko
wrote:
>
> On Fri, Aug 13, 2021 at 09:17:10AM -0600, Jim Cromie wrote:
> > Add a const void* data member to the struct, to allow attaching
> > private data that will be used soon by a setter method (via kp->data)
> > to perform more elaborate
13.08.2021 19:36, kernel test robot пишет:
> tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
> head: ad85b0843ee4536593415ca890d7fb52cd7f1fbe
> commit: 04d5d5df9df79f9045e76404775fc8a084aac23d [16/17] drm/tegra: dc:
> Support memory bandwidth management
> config:
Clang warns:
In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable
'err' is uninitialized when used here [-Wuninitialized]
pr_err("[%s] Create context failed: %d!\n", engine->name, err);
On 8/12/21 5:07 AM, Kirill A. Shutemov wrote:
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
...
Looking at code
On Tue, Aug 10, 2021 at 10:43:31AM +0800, sandor...@nxp.com wrote:
> From: Sandor Yu
>
> In function malidp_crtc_mode_valid, mode->crtc_mode = 0 when run
> in drm_helper_probe_single_connector_modes.
> Invalid video modes are not culled
> and all modes move to the connector's modes list.
> It is
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation. Since the default implementation of the
prot_guest_has() matches the s390 implementation of mem_encrypt_active(),
prot_guest_has() does not need to be implemented in s390 (the config
option
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Tom Lendacky
---
arch/powerpc/include/asm/mem_encrypt.h | 5 -
1 file changed, 5 deletions(-)
diff
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Reviewed-by: Joerg Roedel
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h | 5 -
1 file changed, 5
The mem_encrypt_active() function has been replaced by prot_guest_has(),
so remove the implementation.
Reviewed-by: Joerg Roedel
Signed-off-by: Tom Lendacky
---
include/linux/mem_encrypt.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/mem_encrypt.h
Replace occurrences of mem_encrypt_active() with calls to prot_guest_has()
with the PATTR_MEM_ENCRYPT attribute.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc:
Replace occurrences of sev_es_active() with the more generic
prot_guest_has() using PATTR_GUEST_PROT_STATE, except for in
arch/x86/kernel/sev*.c and arch/x86/mm/mem_encrypt*.c where PATTR_SEV_ES
will be used. If future support is added for other memory encyrption
techonologies, the use of
Replace occurrences of sev_active() with the more generic prot_guest_has()
using PATTR_GUEST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c
where PATTR_SEV will be used. If future support is added for other memory
encryption technologies, the use of PATTR_GUEST_MEM_ENCRYPT can be
updated,
Replace occurrences of sme_active() with the more generic prot_guest_has()
using PATTR_HOST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c
where PATTR_SME will be used. If future support is added for other memory
encryption technologies, the use of PATTR_HOST_MEM_ENCRYPT can be
updated, as
Introduce a powerpc version of the prot_guest_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the PATTR_MEM_ENCRYPT
attribute.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Introduce an x86 version of the prot_guest_has() function. This will be
used in the more generic x86 code to replace vendor specific calls like
sev_active(), etc.
While the name suggests this is intended mainly for guests, it will
also be used for host memory encryption checks in place of
In prep for other protected virtualization technologies, introduce a
generic helper function, prot_guest_has(), that can be used to check
for specific protection attributes, like memory encryption. This is
intended to eliminate having to add multiple technology-specific checks
to the code (e.g. if
In prep for other uses of the prot_guest_has() function besides AMD's
memory encryption support, selectively build the AMD memory encryption
architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These
functions are:
- early_memremap_pgprot_adjust()
- arch_memremap_can_ram_remap()
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to the kernel, they can all be covered by a single
Hi Dave, Daniel,
Updates for 5.15. Mostly bug fixes and cleanups.
The following changes since commit a43e2a0e11491b73e2acaa27ee74d6c3b86deac0:
drm/amdkfd: Allow querying SVM attributes that are clear (2021-08-06 16:12:32
-0400)
are available in the Git repository at:
Just a friendly reminder that this fix for a regression needs
review. It should be a quick review.
It would probably be good to ensure this gets in before the final 5.14
release, otherwise this is going to be a very visible regression for
anyone that uses DRM and does not use debugfs.
Thanks!
tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head: ad85b0843ee4536593415ca890d7fb52cd7f1fbe
commit: 04d5d5df9df79f9045e76404775fc8a084aac23d [16/17] drm/tegra: dc: Support
memory bandwidth management
config: arm-defconfig (attached as .config)
compiler:
Hi Dave,
The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3:
Linux 5.14-rc1 (2021-07-11 15:07:40 -0700)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.15-rc1
for you to fetch changes up to
On Fri, Aug 13, 2021 at 06:51:05PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 13, 2021 at 09:17:11AM -0600, Jim Cromie wrote:
> > +int param_set_dyndbg(const char *instr, const struct kernel_param *kp)
> > +{
> > + unsigned long inbits;
> > + int rc, i, chgct = 0, totct = 0;
> > + char
On Fri, Aug 13, 2021 at 09:40:07AM +0200, Johannes Berg wrote:
> On Sat, 2021-07-31 at 08:55 -0700, Kees Cook wrote:
> > On Tue, Jul 27, 2021 at 01:58:30PM -0700, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field bounds checking for memset(),
On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
>
>
> On 8/13/2021 8:10 PM, Michel Dänzer wrote:
>> On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
> On 8/13/2021 3:59 PM, Michel Dänzer wrote:
>>
On Fri, Aug 13, 2021 at 09:17:11AM -0600, Jim Cromie wrote:
> DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
> allows users to define a drm.debug style (bitmap) sysfs interface, and
> to specify the desired mapping from bits[0-N] to the format-prefix'd
> pr_debug()s to be
On Fri, Aug 13, 2021 at 04:54:50PM +0800, Desmond Cheong Zhi Xi wrote:
> Since the last user of drm_ioctl_permit was removed, and it's now only
> used in drm_ioctl.c, unexport the symbol.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
Applied to drm-misc-next for 5.16,
On Fri, Aug 13, 2021 at 04:54:49PM +0800, Desmond Cheong Zhi Xi wrote:
> In drm_client_modeset.c and drm_fb_helper.c,
> drm_master_internal_{acquire,release} are used to avoid races with DRM
> userspace. These functions hold onto drm_device.master_mutex while
> committing, and bail if there's
On Fri, Aug 13, 2021 at 10:04:09AM +0200, Johannes Berg wrote:
> On Tue, 2021-07-27 at 13:58 -0700, Kees Cook wrote:
> >
> > +++ b/include/linux/ieee80211.h
> > @@ -297,9 +297,11 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
> > struct ieee80211_hdr {
> > __le16 frame_control;
> >
Thanks for your review Michel!
@MAINTAINER, could you please strip the Change-Id when applying.
Thanks!
On Fri, Aug 13, 2021 at 3:33 AM Michel Dänzer wrote:
>
> On 2021-08-12 9:49 p.m., Mark Yacoub wrote:
> > From: Mark Yacoub
> >
> > [Why]
> > Userspace should get back a copy of
On Fri, Aug 13, 2021 at 09:17:10AM -0600, Jim Cromie wrote:
> Add a const void* data member to the struct, to allow attaching
> private data that will be used soon by a setter method (via kp->data)
> to perform more elaborate actions.
>
> To attach the data at compile time, add new macros:
>
>
On 8/13/2021 7:42 AM, Daniel Vetter wrote:
On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only
Sean Paul seanp...@chromium.org proposed, in
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
That patchset's goal is to be able to duplicate the debug stream to a
tracing destination, by splitting drm_debug_enabled() into syslog &
trace flavors, and
There are blocks of DRM_DEBUG calls, consolidate their args into
single calls. With dynamic-debug in use, each callsite consumes 56
bytes of ro callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.
no functional changes.
Signed-off-by: Jim Cromie
---
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEBUG*(8 names),
DRM_DEV_DEBUG*(3 names). There are thousands of these callsites, each
categorized by their authors.
These callsites can be enabled at runtime by their category,
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these use DRM debug API, so are controllable using drm.debug,
but others use bare pr_debug("$prefix: .."), each with a different
class-prefix matching "^\[\w+\]:"
Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a /sys
The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM. Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
{
Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the nested quoting needed otherwise:
$> echo "format '^gvt: core:' +p" >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched
DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
allows users to define a drm.debug style (bitmap) sysfs interface, and
to specify the desired mapping from bits[0-N] to the format-prefix'd
pr_debug()s to be controlled.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
Add a const void* data member to the struct, to allow attaching
private data that will be used soon by a setter method (via kp->data)
to perform more elaborate actions.
To attach the data at compile time, add new macros:
module_param_cbd() derives from module_param_cb(), adding data param,
and
s/prink/printk/ - no functional changes
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 9b66be54dd16..15a089a87c22 100644
--- a/include/drm/drm_print.h
+++
On 8/13/2021 7:37 AM, Daniel Vetter wrote:
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution
hi Jason, Greg, Daniel, dri-everyone,
drm_debug_enabled() is called a lot (by drm-debug api) to do unlikely
bit-tests to selectively enable debug printing; this is a good job for
DYNAMIC_DEBUG, IFF it is built with JUMP_LABEL.
This patchset enables the use of dynamic-debug to avoid those
On Thu, Aug 12, 2021 at 10:38:18PM +, Matthew Brost wrote:
> On Thu, Aug 12, 2021 at 09:47:23PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> > > On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug 11, 2021 at
On 8/13/2021 8:10 PM, Michel Dänzer wrote:
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work
On 2021-08-13 10:54 a.m., zhaoxiao wrote:
> This patch fixes the following sparse errors:
> drivers/gpu/drm/radeon/r600_dma.c:247:30: warning: incorrect type in
> assignment (different base types)
> drivers/gpu/drm/radeon/r600_dma.c:247:30:expected unsigned int volatile
> [usertype]
>
On Fri, Aug 13, 2021 at 02:59:27PM +0200, Oliver Graute wrote:
> In rare cases the display is flipped or mirrored. This was observed more
> often in a low temperature environment. A clean reset on init_display()
> should help to get registers in a sane state.
>
> Signed-off-by: Oliver Graute
>
On Fri, Aug 13, 2021 at 02:54:30PM +0200, Oliver Graute wrote:
> On 13/08/21, Greg KH wrote:
> > On Fri, Aug 13, 2021 at 08:25:10AM +0200, Oliver Graute wrote:
> > > staging: fbtft: fb_st7789v: reset display before initialization
> >
> > What is this line here, and why is this not your subject
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
v1:
- Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
v2:
- Use
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
v5:
- Remove panel_in port for dsi node.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml | 88 +++
1
Adds DPU(Display Processor Unit) support for the Unisoc's display
subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
v2:
- Use drm_xxx to replace all DRM_XXX.
- Use kzalloc to replace devm_kzalloc for sprd_dpu structure init.
v3:
- Remove dpu_layer stuff
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internal
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Unisoc's display pipeline have several components as below
description, multi display controllers and corresponding physical
ChangeList:
RFC v1:
1. only upstream modeset and atomic at first commit.
2. remove some unused code;
3. use alpha and blend_mode properties;
3. add yaml support;
4. remove auto-adaptive panel driver;
5. bugfix
RFC v2:
1. add sprd crtc and plane module for KMS, preparing for multi crtc
2. remove
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able to use ttm_move_memcpy() async under
a dma-fence
The ttm_move_memcpy() function was intended to be able to be used async
under a fence.
We are going to utilize that as a fallback if the gpu clearing blit fails
before we set up CPU- or GPU ptes to the memory region.
But to accomplish that the bo argument to ttm_move_memcpy() needs to be
replaced.
In order to make the code a bit more readable and to facilitate
async memcpy moves, reorganize the move code a little. Determine
at an early stage whether to copy or to clear.
v2:
- Don't set up the memcpy iterators unless we are actually going to memcpy.
Signed-off-by: Thomas Hellström
On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > This api allow user mode to create protected buffers and to mark
> > contexts as making use of such objects. Only when using contexts
> > marked in such a
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
>> On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
>
> Contexts can
On Wed, Jul 28, 2021 at 07:01:00PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate
On 8/13/2021 7:04 PM, Michel Dänzer wrote:
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
On 8/13/2021 3:59 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
On 8/13/21 1:36 PM, Dan Carpenter wrote:
If the intel_engine_create_pinned_context() function returns an error
pointer, then dereferencing "ce" will Oops. Use "vm" instead of
"ce->vm".
Fixes: cf586021642d ("drm/i915/gt: Pipelined page migration")
Signed-off-by: Dan Carpenter
---
On Wed, Aug 11, 2021 at 12:51:56PM -0600, Rob Herring wrote:
> On Wed, Aug 04, 2021 at 04:13:51PM +0800, Shawn Guo wrote:
> > The Truly NT35521 is a 5.24" 1280x720 DSI panel, and the backlight is
> > managed through DSI link.
> >
> > Signed-off-by: Shawn Guo
> > ---
> >
On Sat, Aug 7, 2021 at 3:31 PM Markuss Broks wrote:
> This adds a driver for Samsung S6D27A1 display controller and panel.
> This panel is found in the Samsung GT-I8160 mobile phone,
> and possibly some other mobile phones.
>
> This display needs manufacturer commands to configure it;
> the
On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> Atm the EFI FB platform driver gets a runtime PM reference for the
> associated GFX PCI device during probing the EFI FB platform device and
> releases it only when the platform device gets unbound.
>
> When fbcon switches to the FB
On 2021-08-13 1:50 p.m., Lazar, Lijo wrote:
>
>
> On 8/13/2021 3:59 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
>> after the first time GFXOFF was
13.08.2021 13:33, Thierry Reding пишет:
> On Mon, Jun 07, 2021 at 01:40:06AM +0300, Dmitry Osipenko wrote:
>> 01.06.2021 07:21, Dmitry Osipenko пишет:
>>> This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
>>> which is done using interconnect framework. It fixes display
Hi Inki,
On Fri, Aug 13, 2021 at 03:50:56PM +0900, Inki Dae wrote:
> 21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글:
> > On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote:
> >> Exynos DSI driver is actually a Samsung MIPI DSIM bridge
> >> IP which is also used in i.MX8MM platforms.
> >>
> >>
1 - 100 of 141 matches
Mail list logo
