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 insertions(
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 (whic
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 (RX
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, Sath
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 requi
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
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 pla
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 ppg
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 Wilson
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
C
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 help
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 gt->vm,
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 do
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
Dat
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
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 YAM
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 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 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
> ---
> .../displa
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 |
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 dr
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 t
101 - 122 of 122 matches
Mail list logo
