On 2020.06.03 14:33:21 +0200, Julian Stecklina wrote:
> When a user tries to allocate too many or too big vGPUs and runs out
> of graphics memory, the resulting error message is not actionable and
> looks like an internal error.
>
> Change the error message to clearly point out what actions a user
From: "Ahmed S. Darwish"
Date: Wed, 3 Jun 2020 16:49:43 +0200
> Since patch #7 and #8 from the series:
>
>[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks
>
> https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de
>
> are now pending on the lock
On Thu, 04 Jun 2020 15:56:36 +0800, Xin Ji wrote:
> anx7625: MIPI to DP transmitter DT schema
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 95
> ++
> 1 file changed, 95 insertions(+)
> create mode 100644
> Documentation/devicetree/
On Thu, Jun 04, 2020 at 08:01:03PM +, Almahallawy, Khaled wrote:
> On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > > Signed-off-by: Khaled Almahallawy
> > > Signed-off-by: Vidya Srinivas
> > > ---
> > > drivers/g
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/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
drivers/gpu/drm/ms
Another iteration of the split-pagetable support for arm-smmu and the Adreno GPU
SMMU. After email discussions [1] we opted to make a arm-smmu implementation for
specifically for the Adreno GPU and use that to enable split pagetable support
and later other implementation specific bits that we need.
On Thu, Jun 04, 2020 at 12:41:33PM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> >
> > sparc32 smp images in next-20200603 still crash for me with a spinlock
> > recursion. s390 images hang early in boot. Several others (alpha, arm64,
> > various pp
Hi,
On Thu, Jun 4, 2020 at 6:20 AM Kalyan Thota wrote:
>
> -#ifdef CONFIG_PM
> -static int msm_runtime_suspend(struct device *dev)
> +#ifdef CONFIG_PM_SLEEP
> +static int msm_pm_suspend(struct device *dev)
> {
> - struct drm_device *ddev = dev_get_drvdata(dev);
> - struct msm_drm_pri
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent Pincha
On Wed, Jun 03, 2020 at 10:16:17AM +0200, Daniel Vetter wrote:
> On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote:
> > > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
> > > > O
On Thu, 2020-06-04 at 22:06 +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> > Signed-off-by: Khaled Almahallawy
> > Signed-off-by: Vidya Srinivas
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 40
> > ++---
> > 1
Hi Harigovindan
On Thu, Jun 04, 2020 at 04:04:38PM +0530, Harigovindan P wrote:
> ti-sn65dsi86 bridge is enumerated as a runtime device.
>
> Adding sleep ops to force runtime_suspend when PM suspend is
> requested on the device.
Patch looks correct - but could you please explain why it is needed.
On Thu, Jun 04, 2020 at 10:33:48AM +0530, Vidya Srinivas wrote:
> Signed-off-by: Khaled Almahallawy
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 40
> ++---
> 1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/driv
On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> This change adds a new flavor of dma-bufs that can be used by virtio
> drivers to share exported objects. A virtio dma-buf can be queried by
> virtio drivers to obtain the UUID which identifies the underlying
> exported object.
>
> S
I've tested your change and one issue gone.
However I still see kernel crash (due to invalid read in kernel mode by 0x0
address) on weston stop:
--->8---
Oops
Path: (null)
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted
5.7.0-r
On Thu, Jun 04, 2020 at 09:45:00PM +0300, Imre Deak wrote:
> Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
> incorrectly filter out HPD short pulses with a duration less than
> ~540 usec, leading to MST probe failures.
>
> According to the DP Standard 2.0 section 5.1.4:
Applied. thanks!
Alex
On Thu, Jun 4, 2020 at 6:35 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dml_print message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 2 +-
> 1 file changed, 1
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than
~540 usec, leading to MST probe failures.
According to the DP Standard 2.0 section 5.1.4:
- DP sinks should generate short pulses in the 500 usec -> 1 msec ran
Currently MST on a port can get enabled/disabled from the hotplug work
and get disabled from the short pulse work in a racy way. Fix this by
relying on the MST state checking in the hotplug work and just schedule
a hotplug work from the short pulse handler if some problem happened
during the MST in
Hi Dave, Daniel,
Fixes for 5.8.
The following changes since commit 9ca1f474cea0edc14a1d7ec933e5472c0ff115d3:
Merge tag 'amd-drm-next-5.8-2020-05-27' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-05-28 16:10:17
+1000)
are available in the Git repository at:
git://people
This patch is i915-specific. It should be sent to
intel-...@lists.freedesktop.org instead of dri-devel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Ramalingam C
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_region_lmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
index d5ffef3bf5f6..d85da31f98c9 100644
--- a/
On Thu, Jun 04, 2020 at 06:12:27PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 01:18:59AM +0300, Imre Deak wrote:
> > Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
> > incorrectly filter out HPD short pulses with a duration less than ~540
> > usec, leading to MST p
On Thu, Jun 04, 2020 at 01:18:59AM +0300, Imre Deak wrote:
> Some TypeC -> native DP adapters, at least the Club CAC-1557 adapter,
> incorrectly filter out HPD short pulses with a duration less than ~540
> usec, leading to MST probe failures.
>
> According to the DP alt mode specification adapters
On Thu, Jun 04, 2020 at 05:55:30PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 04, 2020 at 12:10:38AM +0300, Imre Deak wrote:
> > Currently MST on a port can get enabled/disabled from the hotplug work
> > and get disabled from the short pulse work in a racy way. Fix this by
> > relying on the MST sta
Hi Dave & Daniel,
Fixes use-after free on display global state tracking.
Then the removal of write bits from sysfs files
where changed value is not reflected anywhere.
Two scheduler fixes with deps that are Cc: stable.
Includes the GVT pull which has two build warning fixes
at this time.
CI_DI
On Thu, Jun 04, 2020 at 12:10:38AM +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from
On Thu, Jun 04, 2020 at 09:48:49AM -0400, Jim Quinlan wrote:
> > > + r = devm_kcalloc(dev, 1, sizeof(struct dma_pfn_offset_region),
> > > + GFP_KERNEL);
> >
> > Use:r = devm_kzalloc(dev, sizeof(*r), GFP_KERNEL);
> Will fix.
>
> >
> >
> > > + if (!r)
> > > +
On 04/06/2020 11:02, Tomi Valkeinen wrote:
> The connector type for DISPC's DPI videoport was set the LVDS instead of
> DPI. This causes any DPI panel setup to fail with tidss, making all DPI
> panels unusable.
>
> Fix this by using correct connector type.
>
> Signed-off-by: Tomi Valkeinen
> Fix
The connector type for DISPC's DPI videoport was set the LVDS instead of
DPI. This causes any DPI panel setup to fail with tidss, making all DPI
panels unusable.
Fix this by using correct connector type.
Signed-off-by: Tomi Valkeinen
Fixes: 32a1795f57eecc39749017 ("drm/tidss: New driver for TI K
Hi Eugeniy,
Apologies, somehow I missed your mail. I looked at the code again, and I
think I fumbled something. Does the below diff help to prevent the issues?
Thanks, Daniel
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 857812f25bec..33d812a5ad7f 100644
--- a
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of multiple pfn offsets between cpu addrs and dma addrs. It
subsumes the role of dev->dma_pfn_offset -- a uniform offset -- and
designates the single offset a special case.
of_dma_configure() is the typical manner t
On Wed, Jun 03, 2020 at 03:20:41PM -0400, Jim Quinlan wrote:
> @@ -786,7 +787,7 @@ static int sun4i_backend_bind(struct device *dev, struct
> device *master,
> const struct sun4i_backend_quirks *quirks;
> struct resource *res;
> void __iomem *regs;
> - int i, ret;
> + int
Hi Daniel,
I've already tested it (and found several issues), so please check my reply
here:
https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg07403.html
Not sure why you didn't receive my reply (probably the reason is because it was
sent to your @ffwll.ch mail instead of @inte
From: Colin Ian King
There is a spelling mistake in a dml_print message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display
On Thu, Jun 4, 2020 at 11:20 AM Simon Ser wrote:
>
> Describe what a "BAD" link-status means for user-space and how it should
> handle it. The logic described has been implemented in igt [1].
>
> v2:
>
> - Change wording to avoid "enabled" (Daniel)
> - Add paragraph about multiple connectors shari
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> sparc32 smp images in next-20200603 still crash for me with a spinlock
> recursion. s390 images hang early in boot. Several others (alpha, arm64,
> various ppc) don't even compile. I can run some more bisects over time,
> but this
On Thu, Jun 4, 2020 at 11:27 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-06-04 10:21:46)
> > On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel)
> > wrote:
> > >
> > >
> > > On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > > ...
> > > > Thread A:
> > > >
> > > > mutex_lock(A);
>
Hi Laurent,
Thanks your review comments.
> -Original Message-
> From: Laurent Pinchart
> Sent: Wednesday, June 3, 2020 7:44 AM
> To: Sandor Yu
> Cc: a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se;
> jernej.skra...@siol.net; he...@sntech.de; h...@rock-chips.com;
> d...@cad
> -Original Message-
> From: Laurent Pinchart
> Sent: Wednesday, June 3, 2020 7:35 AM
> To: Sandor Yu
> Cc: a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se;
> jernej.skra...@siol.net; he...@sntech.de; h...@rock-chips.com;
> d...@cadence.com; dri-devel@lists.freedesktop.or
> -Original Message-
> From: Laurent Pinchart
> Sent: Wednesday, June 3, 2020 7:29 AM
> To: Emil Velikov
> Cc: Sandor Yu ; Andrzej Hajda ;
> Neil Armstrong ; Jonas Karlman
> ; Jernej Skrabec ; Heiko Stübner
> ; Sandy Huang ;
> d...@cadence.com; ML dri-devel ;
> linux-rockchip ; Linux-Ke
Quoting Daniel Vetter (2020-06-04 10:21:46)
> On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel)
> wrote:
> >
> >
> > On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > ...
> > > Thread A:
> > >
> > > mutex_lock(A);
> > > mutex_unlock(A);
> > >
> > > dma_fence_signal();
> > >
> >
On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel)
wrote:
>
>
> On 6/4/20 10:12 AM, Daniel Vetter wrote:
> ...
> > Thread A:
> >
> > mutex_lock(A);
> > mutex_unlock(A);
> >
> > dma_fence_signal();
> >
> > Thread B:
> >
> > mutex_lock(A);
> > dma_fence_wait();
>
Describe what a "BAD" link-status means for user-space and how it should
handle it. The logic described has been implemented in igt [1].
v2:
- Change wording to avoid "enabled" (Daniel)
- Add paragraph about multiple connectors sharing the same CRTC (Pekka)
- Add paragraph about performing an ato
On Wed, 3 Jun 2020 at 19:53, Marek Olšák wrote:
> TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
> then all other used buffers must also be TMZ or read only. If no TMZ buffers
> are used by a command buffer, then TMZ is disabled. If a context is not
> secure, TMZ is
On 6/4/20 10:12 AM, Daniel Vetter wrote:
...
Thread A:
mutex_lock(A);
mutex_unlock(A);
dma_fence_signal();
Thread B:
mutex_lock(A);
dma_fence_wait();
mutex_unlock(A);
Thread B is blocked on A signalling the fence, but A never gets around
to th
On Wed, Jun 03, 2020 at 04:49:49PM +0200, Ahmed S. Darwish wrote:
> Commit 3c3b177a9369 ("reservation: add support for read-only access
> using rcu") introduced a sequence counter to manage updates to
> reservations. Back then, the reservation object initializer
> reservation_object_init() was alwa
On Wed, 3 Jun 2020 17:25:47 +0800
Chuhong Yuan wrote:
> Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory()
> partly, it does not call pci_disable_device() as gx1fb_map_video_memory()
> calls pci_enable_device().
> Add the missed function call to fix the bug.
>
> Fixes: 5
i915 does tons of allocations from this worker, which lockdep catches.
Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic c
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] ---
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vge
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
Hi all,
Still very much early stuff, still very much looking for initial thoughts
and maybe some ideas how this could all be rolled out across drivers.
Full intro probably best from the RFC cover letter:
https://lore.kernel.org/amd-gfx/20200512085944.222637-1-daniel.vet...@ffwll.ch/
Changes sin
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
i
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: l
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this is
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched
Just some tiny edits:
- fix link to struct dma_fence
- give slightly more meaningful title - the polling here is about
implicit fences, explicit fences (in sync_file or drm_syncobj) also
have their own polling
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file chan
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no exper
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
fs_reclaim_acquire/release nicely catch recursion issues when
allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
to use to keep the excessive caches in check). For mmu notifier
recursions we do have lockdep annotations since 23b68395c7c7
("mm/mmu_notifiers: add a lockdep map for
Am 03.06.20 um 22:13 schrieb Jason Gunthorpe:
On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote:
Hi Linus,
This is the main drm pull request for 5.8-rc1.
Highlights:
Core DRM had a lot of refactoring around managed drm resources to make
drivers simpler.
Intel Tigerlake support is on
Hello Xin,
Thank you for the patch.
On Thu, Jun 04, 2020 at 03:58:05PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/anal
On Fri, May 08, 2020 at 08:07:41PM +0200, Daniel Vetter wrote:
> On Fri, May 8, 2020 at 3:56 PM Alexey Brodkin
> wrote:
> >
> > Hi Daniel,
> >
> > > > Looking at this patch series, feels a bit like hand-rolling of bridge
> > > > code, badly. We should get away from that.
> > > >
> > > > Once you h
On 03/06/2020 10:31, Thomas Zimmermann wrote:
> The meson driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
> macro now sets these defaults and .dumb_create in struct drm_driver.
>
> By using DRM_GEM_CMA_
Hi Vinod,
On Thu, Jun 04, 2020 at 12:55:48PM +0530, Vinod Koul wrote:
> On 28-05-20, 04:52, Laurent Pinchart wrote:
>
> > > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611 *lt9611 = brid
On Wed, Jun 03, 2020 at 06:04:34PM +0100, Emil Velikov wrote:
> Add some information about pre-atomic modeset properties alongside a
> list of suggestions how to handle the different instances.
>
> Signed-off-by: Emil Velikov
> ---
> Documentation/gpu/todo.rst | 32 ++
Hi Vinod,
On Thu, Jun 04, 2020 at 12:48:59PM +0530, Vinod Koul wrote:
> Hi Laurent,
>
> Sorry for late reply, I was out last week.
No worries.
> On 28-05-20, 04:48, Laurent Pinchart wrote:
> > > +
> > > + interrupts:
> > > +maxItems: 1
> > > +description: interrupt line for the chip
>
On Wed, Jun 03, 2020 at 04:49:43PM +0200, Ahmed S. Darwish wrote:
> Hi,
>
> Since patch #7 and #8 from the series:
>
>[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks
>
> https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de
>
> are now pending o
Hi Laurent,
On 28-05-20, 04:52, Laurent Pinchart wrote:
> > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > + enum drm_bridge_attach_flags flags)
> > +{
> > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > + int ret;
> > +
> > + dev_dbg(lt961
Hi Laurent,
Sorry for late reply, I was out last week.
On 28-05-20, 04:48, Laurent Pinchart wrote:
> > +
> > + interrupts:
> > +maxItems: 1
> > +description: interrupt line for the chip
>
> I think you could drop the descriptions for the reg and interrupt
> properties, they don't add mu
Hi,
Le 03/06/2020 à 10:10, Michal Simek a écrit :
Hi Michael,
On 26. 05. 20 15:44, Michael Ellerman wrote:
Michal Simek writes:
Hi Michael,
On 01. 04. 20 13:30, Michal Simek wrote:
On 01. 04. 20 12:38, Takashi Iwai wrote:
On Wed, 01 Apr 2020 12:35:16 +0200,
Michael Ellerman wrote:
Micha
On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote:
> Hi Linus,
>
> This is the main drm pull request for 5.8-rc1.
>
> Highlights:
> Core DRM had a lot of refactoring around managed drm resources to make
> drivers simpler.
> Intel Tigerlake support is on by default
> amdgpu now support p
When a user tries to allocate too many or too big vGPUs and runs out
of graphics memory, the resulting error message is not actionable and
looks like an internal error.
Change the error message to clearly point out what actions a user can
take to resolve this situation.
Cc: Thomas Prescher
Cc: Z
Hi Michael,
On 26. 05. 20 15:44, Michael Ellerman wrote:
> Michal Simek writes:
>> Hi Michael,
>>
>> On 01. 04. 20 13:30, Michal Simek wrote:
>>> On 01. 04. 20 12:38, Takashi Iwai wrote:
On Wed, 01 Apr 2020 12:35:16 +0200,
Michael Ellerman wrote:
>
> Michal Simek writes:
>>
On 6/3/20 2:14 PM, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
>> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote:
>>
>
> Actually it occurs to me that the patch consolidating kmap_prot is odd for
> sparc 32 bit...
>
> Its a long shot bu
On 2020-06-03 5:45 a.m., Piotr Stankiewicz wrote:
> There are several places in the kernel which check/ask for MSI or MSI-X
> interrupts. It would make sense to have a shorthand constant, similar to
> PCI_IRQ_ALL_TYPES, to use in these situations. So add PCI_IRQ_MSI_TYPES,
> for this purpose.
>
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if the time taken by 20k insertions takes more than
4 times of 10k insertions as we know that insertions should at
most scale quadratically.
v2:
introduce fragmentation b
On 6/3/20 5:22 PM, Rafael J. Wysocki wrote:
On Wed, Jun 3, 2020 at 6:12 PM Lukasz Luba wrote:
On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
On 03. 06. 20 10:13, Christophe Leroy wrote:
> Hi,
>
> Le 03/06/2020 à 10:10, Michal Simek a écrit :
>> Hi Michael,
>>
>> On 26. 05. 20 15:44, Michael Ellerman wrote:
>>> Michal Simek writes:
Hi Michael,
On 01. 04. 20 13:30, Michal Simek wrote:
> On 01. 04. 20 12:38, Takashi Iw
On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
Hi Daniel,
On 6/1/20 10:44 PM, Daniel Lezcano wrote:
On 27/05/2020 11:58, Lukasz Luba wrote:
Add support for other devices than CPUs. The registration function
does not require a valid cpumask p
On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
Hi Daniel,
On 6/1/20 10:44 PM, Daniel Lezcano wrote:
On 27/05/2020 11:58, Lukasz Luba wrote:
A
Christophe Leroy writes:
> Hi,
>
> Le 03/06/2020 à 10:10, Michal Simek a écrit :
>> Hi Michael,
>>
>> On 26. 05. 20 15:44, Michael Ellerman wrote:
>>> Michal Simek writes:
Hi Michael,
On 01. 04. 20 13:30, Michal Simek wrote:
> On 01. 04. 20 12:38, Takashi Iwai wrote:
>> On
> Add the missed function call to fix the bug.
…
> +++ b/drivers/video/fbdev/geode/gx1fb_core.c
> @@ -208,29 +208,44 @@ static int gx1fb_map_video_memory(struct fb_info
> *info, struct pci_dev *dev)
…
> return 0;
> +
> +err:
> + pci_disable_device(dev);
> + return ret;
> }
…
I su
* Tomi Valkeinen [200603 12:34]:
> Hi Tony,
>
> On 31/05/2020 22:39, Tony Lindgren wrote:
> > When booting without legacy platform data, we no longer have omap_device
> > calling PM runtime suspend for us on suspend. This causes the driver
> > context not be saved as we have no suspend and resume
Hi Eric,
On Wed, May 27, 2020 at 12:40:02PM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
> >
> > At boot time, if we detect that a pixelvalve has been enabled, we need to
> > be able to retrieve the HVS channel it has been assigned to so that we can
> > disable
Hi Stefan,
On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote:
> Am 02.06.20 um 21:31 schrieb Eric Anholt:
> > On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
> > wrote:
> >> Hi Maxime and Eric
> >>
> >> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote:
> >>> Hi Eric
> >>>
> >>> On Wed,
Hi,
Since patch #7 and #8 from the series:
[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks
https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de
are now pending on the lockdep/x86 IRQ state tracking patch series:
[PATCH 00/14] x86/entry: disal
Commit 3c3b177a9369 ("reservation: add support for read-only access
using rcu") introduced a sequence counter to manage updates to
reservations. Back then, the reservation object initializer
reservation_object_init() was always inlined.
Having the sequence counter initialization inlined meant that
Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory()
partly, it does not call pci_disable_device() as gx1fb_map_video_memory()
calls pci_enable_device().
Add the missed function call to fix the bug.
Fixes: 53eed4ec8bcd ("[PATCH] fbdev: geode updates]")
Signed-off-by: Chuhong
97 matches
Mail list logo
