On Tue, Jul 20, 2021 at 2:50 AM Sam Ravnborg wrote:
>
> Hi Zheyu,
> On Wed, Jul 14, 2021 at 04:09:22AM +, Zheyu Ma wrote:
> > The user can pass in any value to the driver through the 'ioctl'
> > interface. The driver dost not check, which may cause DoS bugs.
> >
> > The following log reveals i
Hi Sam,
On Mon, Jul 19, 2021 at 9:23 PM Sam Ravnborg wrote:
> On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote:
> > This patch series optimizes console operations on ssd1307fb, after the
> > customary fixes and cleanups.
> >
> > Currently, each screen update triggers an I2C tran
Hi Sam,
On Mon, Jul 19, 2021 at 9:05 PM Sam Ravnborg wrote:
> On Wed, Jul 14, 2021 at 04:58:01PM +0200, Geert Uytterhoeven wrote:
> > Simplify the nested loops to handle conversion from linear frame buffer
> > to ssd1307 page layout:
> > 1. Move last page handling one level up, as the value of
The cursor plane should use the current plane state hook in
atomic_async_update because it would not be the new plane state in
the global atomic state, since drm_atomic_helper_swap_state happened
when those plane state hook are run.
Fix cursor plane didn't update issue by below modification:
1. Re
Change in v3:
- Fix patch title and drop new line after Fixes tag.
- Add more detail information to commit message.
Change in v2:
- Fix typo in patch message.
jason-jh.lin (1):
drm/mediatek: Fix cursor plane didn't update
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 -
drivers/gpu/drm/media
Hi Sam,
On Mon, Jul 19, 2021 at 9:07 PM Sam Ravnborg wrote:
> On Wed, Jul 14, 2021 at 04:58:02PM +0200, Geert Uytterhoeven wrote:
> > Extract the code to set the column and page ranges into a helper
> > function.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > drivers/video/fbdev/ssd1307f
Hi Sam,
On Mon, Jul 19, 2021 at 9:21 PM Sam Ravnborg wrote:
> On Wed, Jul 14, 2021 at 04:58:03PM +0200, Geert Uytterhoeven wrote:
> > Currently, each screen update triggers an I2C transfer of all screen
> > data, up to 1 KiB of data for a 128x64 display, which takes at least 20
> > ms in Fast mod
Am 20.07.21 um 02:49 schrieb Rodrigo Siqueira:
The display core files rely on FPU, which requires to be compiled with
special flags. Ideally, we don't want these FPU operations spread around
the DC code; nevertheless, it happens in the current source. This commit
introduces a new directory named
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
v3:
* return error if (ret < 0) (Geert)
* remove duplicate error message (Geert)
v2:
* handle errors in platform_
Am 20.07.21 um 02:49 schrieb Rodrigo Siqueira:
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mechanism inside our DC_FP_START/END macros for
trying to alleviate this problem.
Changes si
Am 20.07.21 um 02:49 schrieb Rodrigo Siqueira:
To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface fro
Am 20.07.21 um 02:49 schrieb Rodrigo Siqueira:
DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the
On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don't tear those down in i915_exit(), we'll leak a bunch
of memory slabs. This can happen two ways: use_kms = false and if we've
run mock selftests. In either case, we
Hi
Am 09.07.21 um 10:09 schrieb KuoHsiang Chou:
[Bug][AST2500]
V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset
Hi
Am 16.07.21 um 03:56 schrieb ainux.w...@gmail.com:
From: "Ainux.Wang"
The function ast_get_modes() will also return 0, when it try to get the
edid, but it also do not get the edid.
Signed-off-by: Ainux.Wang
Acked-by: Thomas Zimmermann
after the issue has been discussed a bit. I'll mer
Hi
Am 15.07.21 um 15:28 schrieb Yang Yingliang:
Replace pci_enable_device() with pcim_enable_device(),
pci_disable_device() will be called in release automatically.
v2:
use pcim_enable_device()
Signed-off-by: Yang Yingliang
Reported-by: Hulk Robot
Acked-by: Thomas Zimmermann
Thanks, I'
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> From: Thomas Hellström
>
> If our exported dma-bufs are imported by another instance of our driver,
> that instance will typically have the imported dma-bufs locked during
> dma_buf_map_attachment(). But the exporter also locks the same rese
Am 17.07.21 um 03:14 schrieb Ainux Wang:
Thomas Zimmermann 于2021年7月16日周五 下午8:00写道：
Hi
Am 16.07.21 um 11:55 schrieb ainux.w...@gmail.com:
From: "Ainux.Wang"
There is should a status when do not get edid.
Well, not really.
So, the problem is that VGA is not hotplug-able. It's supposed t
Am 13.07.21 um 06:07 schrieb Hridya Valsaraju:
The DMA-BUF attachment statistics form a subset of the DMA-BUF
sysfs statistics that recently merged to the drm-misc tree. They are not
UABI yet since they have not merged to the upstream Linux kernel.
Since there has been a reported a performance r
Hi Sam,
On Tue, Jul 20, 2021 at 9:56 AM Geert Uytterhoeven wrote:
> On Mon, Jul 19, 2021 at 9:21 PM Sam Ravnborg wrote:
> > On Wed, Jul 14, 2021 at 04:58:03PM +0200, Geert Uytterhoeven wrote:
> > > Currently, each screen update triggers an I2C transfer of all screen
> > > data, up to 1 KiB of da
Am 19.07.21 um 07:19 schrieb guangming@mediatek.com:
From: Guangming Cao
Dmabuf sysfs stat is used for dmabuf info track.
but these file maybe still use after buffer release/detach,
should clear it before buffer release/detach.
Please rebase on current drm-misc-next. The attachment sysfs
On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
>
> Instead of hand-rolling the same three calls in each function, pull them
> into an i915_gem_object_create_user helper. Apart from re-ordering of
> the placements array ENOMEM check, the only functional change here
> should be that i915_gem_d
Use pm_runtime_force_{suspend,resume} as system suspend/resume hook, to
ensure that anx7625 is always powered off on suspend.
Also add a device link between anx7625 driver and the encoder, to ensure
that bridge_disable will be called before suspend.
Signed-off-by: Pi-Hsun Shih
---
Changes from
On 2021-07-09 2:07 p.m., Christian König wrote:
> Daniel pointed me towards this function and there are multiple obvious
> problems
> in the implementation.
>
> First of all the retry loop is not working as intended. In general the retry
> makes only sense if you grab the reference first and then
From: Guangming Cao
On Tue, 2021-07-20 at 11:31 +0200, Christian König wrote:
> Am 19.07.21 um 07:19 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > Dmabuf sysfs stat is used for dmabuf info track.
> > but these file maybe still use after buffer release/detach,
> > should cl
From: Guangming Cao
Dmabuf sysfs stat is used for dmabuf info track.
But these file maybe still in use after buffer released,
should clear it before buffer release.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> From: Thomas Hellström
>
> Until we support p2p dma or as a complement to that, migrate data
> to system memory at dma-buf attach time if possible.
>
> v2:
> - Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
> selftest
Am 20.07.21 um 12:31 schrieb guangming@mediatek.com:
From: Guangming Cao
Dmabuf sysfs stat is used for dmabuf info track.
But these file maybe still in use after buffer released,
should clear it before buffer release.
Signed-off-by: Guangming Cao
Reviewed and pushed to drm-misc-next.
T
On Wed, Jul 14, 2021 at 3:21 PM Christian König
wrote:
> Just a gentle ping. Or have I missed your reply?
Nah just got overwhelmed with dma-resv discussion and took a break. I
still think some igt (or reviewing what we have) would be good. We
could also just merge Jason's import/export series, si
https://bugzilla.kernel.org/show_bug.cgi?id=211807
pavol.ha...@gmail.com changed:
What|Removed |Added
CC||pavol.ha...@gmail.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=213779
alex14...@yahoo.com changed:
What|Removed |Added
Regression|No |Yes
--- Comment #3 from alex14...@y
On Thu, Jul 15, 2021 at 03:16:08PM -0700, John Harrison wrote:
> On 6/16/2021 03:25, Daniel Vetter wrote:
> > On Thu, Jun 10, 2021 at 10:46 PM wrote:
> > > From: John Harrison
> > >
> > > Various UMDs need to know the L3 bank count. So add a query API for it.
> > Please link to both the igt test
On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote:
> On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote:
> >
> > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann wrote:
> > >
> > > Hi
> > >
> > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas:
> > > > On 6/25/21 3:09 PM, Javier Ma
On Wed, Jul 14, 2021 at 11:51:34AM -0600, Jim Cromie wrote:
> s/prink/printk/ - no functional changes
>
> Signed-off-by: Jim Cromie
Applied to drm-misc-next, thanks for your patch.
-Daniel
> ---
> include/drm/drm_print.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.
Then we should always also wait
On Wed, Jul 14, 2021 at 11:51:36AM -0600, Jim Cromie wrote:
> drm's debug system uses distinct categories of debug messages, encoded
> in an enum (DRM_UT_), which are mapped to bits in drm.debug.
> drm_debug_enabled() does a lot of unlikely bit-mask checks on
> drm.debug; we can use dynamic debug i
On 7/20/21 3:01 PM, Daniel Vetter wrote:
> On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote:
>> On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote:
[snip]
>>>
>>> Can we just merge via drm-misc and make sure the acks are present and
>>> I'll deal with the fallout if any.
>>>
>>
>> Fin
On Thu, Jul 15, 2021 at 09:49:51PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Quite a few places are hand rolling the modeset lock backoff dance.
> Let's suck that into a helper macro that is easier to use without
> forgetting some steps.
>
> The main downside is probably that the imp
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel i
This reverts commit 7213246a803f9b8da0677adb9ae06a3d8b806d02.
The commit 7213246a803f ("drm/vc4: dsi: Only register our component once
a DSI device is attached") aimed at preventing an endless probe loop
between the DSI host driver and its panel/bridge where both would wait
for each other to probe
Display drivers so far need to have a lot of boilerplate to first
retrieve either the panel or bridge that they are connected to using
drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
functions or create a drm panel bridge through drm_panel_bridge_add.
In order to reduce t
The bridge documentation overview is quite packed already, and we'll add
some more documentation that isn't part of an overview at all.
Let's add some sections to the documentation to separare each bits.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/drm-kms-helpers.rst | 6 ++
drivers
Interactions between bridges, panels, MIPI-DSI host and the component
framework are not trivial and can lead to probing issues when
implementing a display driver. Let's document the various cases we need
too consider, and the solution to support all the cases.
Signed-off-by: Maxime Ripard
---
Do
In order to make the probe order expectation more consistent between
bridges, let's create attach and detach hooks for the panels as well to
match what is there for bridges.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_panel.c | 20
include/drm/drm_panel.h | 6 +
Now that we have additional attach and detach hooks for panels, make
sure that the panel bridge driver calls them when relevant.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/dr
The new drm_of_get_next removes most of the boilerplate we have to deal
with. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 ++
drivers/gpu/drm/vc4/vc4_dsi.c | 28
2 files changed, 6 insertions(+), 24 deletions(-)
diff --git
The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
already free'd on release.
Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
Touchscreen.")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -
1 file changed, 1 dele
Now that we have an attach hook available for panels as well, let's use
it for the RaspberryPi 7" DSI panel.
This now mimics what all the other bridges in a similar situation are
doing, and we avoid our probe order issue entirely.
Signed-off-by: Maxime Ripard
---
.../drm/panel/panel-raspberrypi
The driver was using a two-steps initialisation when probing with the
i2c probe first registering the MIPI-DSI device, and then when that
device was probed the driver would attach the device to its host. This
resulted in a fairly non-standard probe logic.
The previous commit changed that logic ent
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote:
> Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
> > The define is entirely unused.
> >
> > Signed-off-by: Christoph Hellwig
>
> I'm not an expert for this particular code, but at least of hand everything
> you do here makes total
On Fri, Jul 16, 2021 at 09:14:31AM -0400, Alex Deucher wrote:
> On Fri, Jul 16, 2021 at 3:06 AM Christian König
> wrote:
> >
> > This reverts commit 85fd4a8a84316166640102676a356755ddec80e0.
> >
> > Daniel pointed out that even PROT_READ can cause a BUG_ON() with this.
> >
> > Signed-off-by: Chris
On Fri, Jul 16, 2021 at 05:43:12PM +0100, Charles Baylis wrote:
>
> Hi
>
> The attached patch fixes a problem where non-drm ioctls are incorrectly
> handled by drm drivers.
>
> This causes problems when isatty() is called on a file descriptor which
> was opened on a drm device node. Glibc imple
On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote:
> On 7/20/21 3:01 PM, Daniel Vetter wrote:
> > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote:
> >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie wrote:
>
> [snip]
>
> >>>
> >>> Can we just merge via drm-misc a
On Fri, Jul 16, 2021 at 04:07:57PM +0200, Thomas Zimmermann wrote:
> Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
> same for _end_cpu_access(). Remove some boiler-plate code. No functional
> changes.
>
> There's one left-over reference to the imported attachment that we
>
On Fri, Jul 16, 2021 at 04:07:55PM +0200, Thomas Zimmermann wrote:
> Implement helpers drm_gem_fb_begin_cpu_access() and _end_cpu_access(),
> which call the rsp dma-buf functions for all GEM BOs of the given
> framebuffer.
>
> Calls to dma_buf_end_cpu_access() can return an error code on failure,
On Mon, Jul 19, 2021 at 10:40:57AM +0200, Christian König wrote:
> Am 17.07.21 um 22:29 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Conversion to gpu_scheduler, and bonus removal of
> > drm_gem_object_put_locked()
>
> Oh yes please!
>
> If I'm not completely mistaken that was the last puzzle
On Sat, Jul 17, 2021 at 01:29:06PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that no one is using it, remove it.
>
> Signed-off-by: Rob Clark
Yay!
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem.c | 22 --
> include/drm/drm_gem.h | 2 --
> 2 file
On Mon, Jul 19, 2021 at 01:30:43PM -0500, Jason Ekstrand wrote:
> In the unlikely event that pci_register_device() fails, we were tearing
> down our PMU setup but not globals. This leaves a bunch of memory slabs
> lying around.
>
> Signed-off-by: Jason Ekstrand
> Fixes: 32eb6bcfdda9 ("drm/i915:
Am 20.07.21 um 15:50 schrieb Daniel Vetter:
On Fri, Jul 16, 2021 at 09:14:02AM +0200, Christian König wrote:
Am 16.07.21 um 08:16 schrieb Christoph Hellwig:
The define is entirely unused.
Signed-off-by: Christoph Hellwig
I'm not an expert for this particular code, but at least of hand everyt
Am 20.07.21 um 16:07 schrieb Daniel Vetter:
On Mon, Jul 19, 2021 at 10:40:57AM +0200, Christian König wrote:
Am 17.07.21 um 22:29 schrieb Rob Clark:
From: Rob Clark
Conversion to gpu_scheduler, and bonus removal of
drm_gem_object_put_locked()
Oh yes please!
If I'm not completely mistaken th
On Mon, Jul 19, 2021 at 01:30:44PM -0500, Jason Ekstrand wrote:
> If the driver was not fully loaded, we may still have globals lying
> around. If we don't tear those down in i915_exit(), we'll leak a bunch
> of memory slabs. This can happen two ways: use_kms = false and if we've
> run mock selft
On Mon, Jul 19, 2021 at 01:30:46PM -0500, Jason Ekstrand wrote:
> We create a bunch of debugfs entries as a side-effect of
> ttm_global_init() and then never clean them up. This isn't usually a
> problem because we free the whole debugfs directory on module unload.
> However, if the global referen
On Tue, Jul 20, 2021 at 04:16:56PM +0200, Christian König wrote:
> Am 20.07.21 um 16:07 schrieb Daniel Vetter:
> > On Mon, Jul 19, 2021 at 10:40:57AM +0200, Christian König wrote:
> > > Am 17.07.21 um 22:29 schrieb Rob Clark:
> > > > From: Rob Clark
> > > >
> > > > Conversion to gpu_scheduler, an
New KMS properties come with a bunch of requirements to avoid each
driver from running their own, inconsistent, set of properties,
eventually leading to issues like property conflicts, inconsistencies
between drivers and semantics, etc.
Let's document what we expect.
Cc: Alexandre Belloni
Cc: Al
On Tue, Jul 20, 2021 at 11:16:27AM +0200, Geert Uytterhoeven wrote:
> Hi Sam,
>
> On Tue, Jul 20, 2021 at 9:56 AM Geert Uytterhoeven
> wrote:
> > On Mon, Jul 19, 2021 at 9:21 PM Sam Ravnborg wrote:
> > > On Wed, Jul 14, 2021 at 04:58:03PM +0200, Geert Uytterhoeven wrote:
> > > > Currently, each
Hi Geert,
On Tue, Jul 20, 2021 at 09:43:22AM +0200, Geert Uytterhoeven wrote:
> Hi Sam,
>
> On Mon, Jul 19, 2021 at 9:05 PM Sam Ravnborg wrote:
> > On Wed, Jul 14, 2021 at 04:58:01PM +0200, Geert Uytterhoeven wrote:
> > > Simplify the nested loops to handle conversion from linear frame buffer
>
In preparation to convert OPP bindings to DT schema, clean-up a few OPP
binding node names in the binding examples.
Cc: Georgi Djakov
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Leonard Crestez
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@vger.kernel.org
Acked-by: Viresh Kumar
Signed-off-by: Rob H
Hi Geert,
On Tue, Jul 20, 2021 at 09:33:11AM +0200, Geert Uytterhoeven wrote:
> Hi Sam,
>
> On Mon, Jul 19, 2021 at 9:23 PM Sam Ravnborg wrote:
> > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote:
> > > This patch series optimizes console operations on ssd1307fb, after the
> >
On Thu, Jul 15, 2021 at 8:54 AM Geert Uytterhoeven wrote:
>
> Hi Sam,
>
> On Wed, Jul 14, 2021 at 5:27 PM Sam Ravnborg wrote:
> > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote:
> > > This patch series optimizes console operations on ssd1307fb, after the
> > > customary fixes
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
>
>
> On 19/07/2021 19:30, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a bunch
> > of memory slabs. This can happen two ways:
On Tue, Jul 20, 2021 at 9:18 AM Daniel Vetter wrote:
>
> On Mon, Jul 19, 2021 at 01:30:44PM -0500, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a bunch
> > of memory slabs. This ca
From: Rob Clark
Somehow we had neither ->wait() nor dma_fence_signal() calls, and no
one noticed. Oops.
Note that this removes the !timeout case, which has not been used in
a long time.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 59 +++--
1 fil
Sorry... didn't reply to everything the first time
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
>
>
> On 19/07/2021 19:30, Jason Ekstrand wrote:
> > If the driver was not fully loaded, we may still have globals lying
> > around. If we don't tear those down in i915_exit(), we'll leak a b
On 20/07/2021 15:53, Jason Ekstrand wrote:
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don't tear those down in i915_exit(), we'll leak a bunch
of memory
On 20/07/2021 16:05, Jason Ekstrand wrote:
Sorry... didn't reply to everything the first time
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don't tear thos
Now you confused me with two replies I forgot to reply to all... :))
On 20/07/2021 15:53, Jason Ekstrand wrote:
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
[snip]
+
static int __init i915_init(void)
{
bool use_kms = true;
int err;
+ i915_fully_loaded = f
Fix the upper guard and the "removed_region", this fixes the random
crashes which used to occur in memory intensive loads. I'm not sure WHY
the upper guard being 0x2000 instead of 0x1000 doesn't fix this, but it
HAS to be 0x1000.
Signed-off-by: Caleb Connolly
Fixes: e60fd5ac1f68 ("arm64: dts: qco
The OnePlus 6T panel fails to initialise if it has been reset,
workaround this by allowing panels to not specify a reset GPIO.
Signed-off-by: Caleb Connolly
---
drivers/gpu/drm/panel/panel-samsung-sofef00.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
Don't specify the reset GPIO for the OnePlus 6T, the panel in the 6T
will refuse to initialise if it has been reset so use this as a
workaround.
Signed-off-by: Caleb Connolly
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 4 +---
arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dts
This series is another collection of small fixes for the OnePlus 6 and 6T.
Notably we finally have finally tracked down and fixed the reserved memory
related crashes!
We also enable UART as well as take Bjorns approach to working around the panel
reset GPIO issue making the reset GPIO optional in t
A labelled diagram showing the location of the Rx and Tx testpoints for
the OnePlus 6 is available on the postmarketOS wiki:
https://wiki.postmarketos.org/wiki/Serial_debugging:Cable_schematics
The device uses 1.8v UART at a baud rate of 115200, bootloader output is
also available here.
Signed-o
Add the correct patch to the ipa firmware now that custom paths are
supported.
Signed-off-by: Caleb Connolly
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
b/arch/arm64/boot/dts/qcom
On Mon, Jul 19, 2021 at 3:35 AM Daniel Vetter wrote:
>
> Jason is trying to sort out the unwinding in i915_init and i915_exit,
> while reviewing those patches I noticed that we also have the
> nomodeset handling now in the middle of things.
>
> Pull that out for simplisity in unwinding - if you ru
From: Colin Ian King
The subtraction of fw->size - offset is operating on two unsigned
integers and the result is unsigned and hence the less than zero
comparison will always to be false. Fix this by casting fw->size
from a size_t to a ssize_t to ensure the result can be signed to
allow a less th
On Tue 20 Jul 10:33 CDT 2021, Caleb Connolly wrote:
> The OnePlus 6T panel fails to initialise if it has been reset,
> workaround this by allowing panels to not specify a reset GPIO.
>
> Signed-off-by: Caleb Connolly
> ---
> drivers/gpu/drm/panel/panel-samsung-sofef00.c | 7 +--
> 1 file ch
[Why]
We directlly clean up proposed_vcpis[] but forget to put malloc_kref of
ports which the proposed_vcpis[] are pointing to.
[How]
Iterate over proposed_vcpis[] and put malloc_kref of ports which used to
have allocated payloads.
Fixes: 8732fe46b20c ("drm/dp_mst: Fix clearing payload state on t
[why]
When resume, we will reprobe the topology to detect any changes during
suspend. If we unplug a branch device during suspend and then resume, we
can eventually unregister child connectors of this branch device because
we call drm_dp_mst_topology_put_mstb() in drm_dp_port_set_pdt().
However, we
[Why]
Now, after receiving CSN notifying that a port is disconnected, we can
unregister child connectors under a branch device via
drm_dp_mst_topology_put_mstb() in drm_dp_port_set_pdt(). However, if
this reported disconnected port is used to connect to an end
device(sst/dp_to_legace converter), we
[Why]
Currently, we will create connectors for all output ports no matter
it's connected or not. However, in MST, we can only determine
whether an output port really stands for a "connector" till it is
connected and check its peer device type as an end device.
In current code, we have chance to cr
By patches below, we change to clean up resources of a mst connector
and put port's malloc_kref when we start to destroy a connector.
* 09b974e8983 drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback
* 72dc0f51591 drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector
However, find
https://bugzilla.kernel.org/show_bug.cgi?id=213715
mario.limoncie...@amd.com changed:
What|Removed |Added
CC||mario.limoncie...@amd.com
---
On Tue, Jul 20, 2021 at 07:12:26PM +0300, Diana Craciun OSS wrote:
> On 7/15/2021 3:20 AM, Jason Gunthorpe wrote:
> > FSL uses the internal reflck to implement the open_device() functionality,
> > conversion to the core code is straightforward.
> >
> > The decision on which set to be part of is tr
Hi Bjorn,
On 20/07/2021 17:03, Bjorn Andersson wrote:
> On Tue 20 Jul 10:33 CDT 2021, Caleb Connolly wrote:
>
>> The OnePlus 6T panel fails to initialise if it has been reset,
>> workaround this by allowing panels to not specify a reset GPIO.
>>
>> Signed-off-by: Caleb Connolly
>> ---
>> driver
On Tue, Jul 20, 2021 at 07:23:35PM +0300, Diana Craciun OSS wrote:
> I have tested the changes and everything works as expected.
Great, thanks, I added a Tested-by for you
Jason
On Mon, Jul 19, 2021 at 06:54:00PM -0700, Matthew Brost wrote:
> On Mon, Jul 19, 2021 at 06:28:47PM -0700, John Harrison wrote:
> > On 7/16/2021 13:16, Matthew Brost wrote:
> > > From: John Harrison
> > >
> > > The serial number tracking of engines happens at the backend of
> > > request submissi
Hi Maxime,
On Tue, Jul 20, 2021 at 03:45:23PM +0200, Maxime Ripard wrote:
> The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
> already free'd on release.
>
> Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
> Touchscreen.")
> Signed-off-by: Maxime Ripard
Re
There's no reason to have "status" properties in examples. "okay" is the
default, and "disabled" turns off some schema checks ('required'
specifically).
Enabling qca,ar71xx causes a warning, so let's fix the node names:
Documentation/devicetree/bindings/net/qca,ar71xx.example.dt.yaml: phy@3:
'#p
On Tue, Jul 20, 2021 at 04:57:26PM +0100, Colin King wrote:
From: Colin Ian King
The subtraction of fw->size - offset is operating on two unsigned
integers and the result is unsigned and hence the less than zero
comparison will always to be false. Fix this by casting fw->size
from a size_t to a
On 20.07.21 17:41, Rob Herring wrote:
In preparation to convert OPP bindings to DT schema, clean-up a few OPP
binding node names in the binding examples.
Cc: Georgi Djakov
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Leonard Crestez
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@vger.kernel.org
Acke
On Fri, Jul 16, 2021 at 01:17:18PM -0700, Matthew Brost wrote:
> From: Rahul Kumar Singh
>
> When GuC submission is enabled, the GuC controls engine resets. Rather
> than explicitly triggering a reset, the driver must submit a hanging
> context to GuC and wait for the reset to occur.
>
> Signed-
1 - 100 of 246 matches
Mail list logo
