Hi, Nancy:
On Sat, 2021-07-17 at 17:04 +0800, Nancy.Lin wrote:
> Add pseudo ovl module files:
> Pseudo ovl is an encapsulated module and designed for simplified
> DRM control flow. This module is composed of 8 RDMAs and 4 MERGEs.
> Two RDMAs merge into one layer, so this module support 4
>
dither 6 setting is missed in a6b7c98afdca
bit 1 is lfsr_en( "Enables LFSR-type dithering"), need enable
bit 2 is rdither_en(Enables running order dithering), need disable
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
1 file changed, 2 insertions(+)
diff
Change since v2:
- add fixes tag and modify commit message
Yongqiang Niu (1):
Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common()
function)
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
1 file changed, 2 insertions(+)
--
1.8.1.1.dirty
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size)
And no header file define a prototype for
On Mon, Jul 19, 2021 at 4:24 PM Yongqiang Niu
wrote:
>
> in the first version dither patch
> https://patchwork.kernel.org/project/linux-mediatek/patch/1553667561-25447-13-git-send-email-yongqiang@mediatek.com/
> dither 6 setting is included in that patch
I think you don't need to link the
On Mon, Jul 19, 2021 at 05:51:46PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 7/16/2021 1:16 PM, Matthew Brost wrote:
> > Implement GuC context operations which includes GuC specific operations
> > alloc, pin, unpin, and destroy.
> >
> > v2:
> > (Daniel Vetter)
> >- Use
On Mon, Jul 19, 2021 at 07:48:17PM -0700, Matthew Brost wrote:
> On Mon, Jul 19, 2021 at 04:46:57PM -0700, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 7/16/2021 1:16 PM, Matthew Brost wrote:
> > > If two requests are on the same ring, they are explicitly ordered by the
> > > HW. So, a
On Mon, Jul 19, 2021 at 04:46:57PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 7/16/2021 1:16 PM, Matthew Brost wrote:
> > If two requests are on the same ring, they are explicitly ordered by the
> > HW. So, a submission fence is sufficient to ensure ordering when using
> > the new GuC
On Mon, Jul 19, 2021 at 05:23:55PM -0700, John Harrison wrote:
> On 7/16/2021 13:16, Matthew Brost wrote:
> > Implement GuC context operations which includes GuC specific operations
> > alloc, pin, unpin, and destroy.
> >
> > v2:
> > (Daniel Vetter)
> >- Use msleep_interruptible rather than
On Mon, Jul 19, 2021 at 06:27:06PM -0700, John Harrison wrote:
> On 7/16/2021 13:16, Matthew Brost wrote:
> > Add trace points for request dependencies and GuC submit. Extended
> > existing request trace points to include submit fence value,, guc_id,
> Still has misplaced commas.
>
> Also, Tvrtko
On Tue, Jul 13, 2021 at 10:06:17AM +0100, Tvrtko Ursulin wrote:
>
> On 24/06/2021 08:04, Matthew Brost wrote:
> > Add trace points for request dependencies and GuC submit. Extended
> > existing request trace points to include submit fence value,, guc_id,
> > and ring tail value.
> >
> > Cc: John
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 submission and was expecting to only be given physical
> > engines. However, in
On Mon, Jul 19, 2021 at 06:03:05PM -0700, John Harrison wrote:
> On 7/16/2021 13:16, Matthew Brost wrote:
> > When running the GuC the GPU can't be considered idle if the GuC still
> > has contexts pinned. As such, a call has been added in
> > intel_gt_wait_for_idle to idle the UC and in turn the
On 7/16/2021 13:16, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen
On 7/16/2021 13:16, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
Still has misplaced commas.
Also, Tvrtko has a bunch of comments/questions on the previous version
that need to be
On Tue, Jul 20, 2021 at 12:03 AM Madhurkiran Harikrishnan
wrote:
>
> Hi,
>
> I had created a patch sometimes ago to test on our platform. That is correct,
> we have three clocks going to gp,pp0 and pp1 (Although all are at same rate).
> DVFS is not supported primarily because at zynqmp clocks
On 7/16/2021 13:16, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
v2:
(John Harrison)
- Remove intel_lrc_reg.h include from i915_debugfs.c
(Michal)
- Rename GuC debugfs functions
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by:
On 7/16/2021 13:16, Matthew Brost wrote:
When running the GuC the GPU can't be considered idle if the GuC still
has contexts pinned. As such, a call has been added in
intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for
the number of unpinned contexts to go to zero.
v2:
On 7/16/2021 1:16 PM, Matthew Brost wrote:
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched in busy loop
(Michal)
- Remove C++ style comment
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 since V2:
- Make sure that we compile FPU operation
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 fpu_operations that intends to
centralize all
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 from other files, the compiler
might enable the use
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 access to
kernel_fpu_begin/end.
Change since
Hi,
In the display core, we utilize floats and doubles units for calculating
modesetting parameters. One side effect of our approach to use double-precision
is the fact that we spread multiple FPU access across our driver, which means
that we can accidentally clobber user space FPU state.
#
On 7/16/2021 13:16, Matthew Brost wrote:
Semaphores are an optimization and not required for basic GuC submission
to work properly. Disable until we have time to do the implementation to
enable semaphores and tune them for performance. Also long direction is
just to delete semaphores from the
On 7/19/2021 15:55, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote:
On 7/16/2021 13:16, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a
On 7/16/2021 13:16, Matthew Brost wrote:
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched in busy loop
(Michal)
- Remove C++ style comment
Signed-off-by:
On 7/16/2021 1:16 PM, Matthew Brost wrote:
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same
On Mon, Jul 19, 2021 at 04:42:50PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 7/19/2021 4:27 PM, Matthew Brost wrote:
> > On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote:
> > >
> > > On 7/16/2021 1:16 PM, Matthew Brost wrote:
> > > > Implement GuC virtual engines.
On 7/19/2021 4:27 PM, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote:
On 7/16/2021 1:16 PM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function
On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 7/16/2021 1:16 PM, Matthew Brost wrote:
> > Implement GuC virtual engines. Rather simple implementation, basically
> > just allocate an engine, setup context enter / exit function to virtual
> > engine specific
On 7/16/2021 1:16 PM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to
On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote:
> On 7/16/2021 13:16, Matthew Brost wrote:
> > Implement GuC submission tasklet for new interface. The new GuC
> > interface uses H2G to submit contexts to the GuC. Since H2G use a single
> > channel, a single tasklet submits is used
On 7/16/2021 13:16, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet submits is used for the submission path.
This still needs fixing - 'a single tasklet submits
Regards,
Oak
On 2021-07-17, 3:22 PM, "amd-gfx on behalf of Alex Sierra"
wrote:
Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 8
Hi Xiyu, Xin,
On Mon, Jul 19, 2021 at 01:59:45PM +0800, Xiyu Yang wrote:
> refcount_t type and corresponding API can protect refcounters from
> accidental underflow and overflow and further use-after-free situations.
>
> Signed-off-by: Xiyu Yang
> Signed-off-by: Xin Tan
Looks like a nice
On 7/19/21 1:06 AM, Geert Uytterhoeven wrote:
> Hi Randy,
>
> On Mon, Jul 19, 2021 at 4:34 AM Randy Dunlap wrote:
>> When DRM_SIMPLEDRM=m, all of FB_CFB_{FILLRECT,COPYAREA,IMAGEBLIT} are =m,
>
> Why does that happen?
> FB_SIMPLE does select FB_CFB_*, so all of the latter should be builtin?
> Do
Hi Rob,
On Mon, Jul 19, 2021 at 01:50:01PM -0600, Rob Herring wrote:
> The graph schema doesn't allow custom properties on endpoint nodes for
> '#/properties/port' and '#/$defs/port-base' should be used instead. This
> doesn't matter until 'unevaluatedProperties' support is implemented.
>
> Cc:
On Mon, Jul 19, 2021 at 4:10 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:23, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 9:52 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 15/07/2021 11:15, Matthew Auld wrote:
> > > > The CPU domain should be static for discrete, and on
The graph schema doesn't allow custom properties on endpoint nodes for
'#/properties/port' and '#/$defs/port-base' should be used instead. This
doesn't matter until 'unevaluatedProperties' support is implemented.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: Marek Vasut
Hi Geert,
On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series optimizes console operations on ssd1307fb, after the
> customary fixes and cleanups.
>
> Currently, each screen update triggers an I2C transfer of all screen
> data, up to 1 KiB
Am 19.07.21 um 20:30 schrieb Jason Ekstrand:
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
everything is all set up.
Signed-off-by: Jason Ekstrand
Fixes: 62b53b37e4b1 ("drm/ttm: use a static
Hi Geert,
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 mode.
>
> Reduce the amount of transferred data by only
Hi Geert,
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/ssd1307fb.c | 61 +++--
> 1 file changed,
Hi Geert,
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 "m" is the
> same inside a page,
> 2. array->data[]
On Thu, Jul 15, 2021 at 09:10:29PM -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
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 it:
>
> divide error: [#1] PREEMPT SMP KASAN PTI
> RIP:
On Mon, Jul 19, 2021 at 11:25:55AM -0700, John Harrison wrote:
> On 7/19/2021 10:24, Matthew Brost wrote:
> > On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote:
> > > From: John Harrison
> > >
> > > The media watchdog mechanism involves GuC doing a silent reset and
> > > continue of
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 reference count ever goes to zero and then
ttm_global_init() is called again,
There's no reason that I can tell why this should be per-i915_buddy_mm
and doing so causes KMEM_CACHE to throw dmesg warnings because it tries
to create a debugfs entry with the name i915_buddy_block multiple times.
We could handle this by carefully giving each slab its own name but that
brings
If we have a failure, decrement the reference count so that the next
call to ttm_global_init() will actually do something instead of assume
everything is all set up.
Signed-off-by: Jason Ekstrand
Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance")
Cc: Christian König
---
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 have an early exit from
i915_init which
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c
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: Make request allocation caches global")
Cc: Daniel Vetter
---
This patch series fixes a miscellaneous collection of bugs that all add up
to all our mock selftests throwing dmesg warnings in CI. As can be seen
from "drm/i915: Always call i915_globals_exit() from i915_exit()", it's
especially fun since those warnings don't always show up in the selftests
but
On 7/19/2021 10:24, Matthew Brost wrote:
On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote:
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the
On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman
wrote:
>
> From: Thomas Zimmermann
>
> commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
>
> Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
> from struct drm_device.dev to get the PCI device structure.
>
> v9:
>
The cursor plane should use the current plane state in atomic_async_update
because it would not be the new plane state in the global atomic state
since _swap_state happened when those hook are run.
Fix cursor plane issue by below modification:
1. Remove plane_helper_funcs->atomic_update(plane,
Change in v2:
Fix typo in patch message.
jason-jh.lin (1):
Fix cursor plane didn't update
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 -
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 60 ++--
2 files changed, 34 insertions(+), 27 deletions(-)
--
2.18.0
The cursor plane should use the current plane state in atomic_async_update
because it would not be the new plane state in the global atomic state
since _swap_state happened when those hook are run.
Fix cursor plane issue by below modification:
1. Remove plane_helper_funcs->atomic_update(plane,
Add Mads.
Thanks,
Jason
> -Original Message-
> From: Michal Simek
> Sent: Monday, July 19, 2021 12:53 AM
> To: Qiang Yu ; Marek Vasut ;
> Jianqiang Chen
> Cc: dri-devel ; l...@lists.freedesktop.org;
> Michal Simek ; Michal Simek
> Subject: Re: [PATCH] drm/lima: Convert to clk_bulk API
On Mon, Jul 19, 2021 at 7:23 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote:
> > On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > From: Thomas Zimmermann
> > >
> > > commit 0ecb51824e838372e01330752503ddf9c0430ef7
Hi,
I had created a patch sometimes ago to test on our platform. That is correct,
we have three clocks going to gp,pp0 and pp1 (Although all are at same rate).
DVFS is not supported primarily because at zynqmp clocks are shared, for
example it could come from VPLL or IOPLL.
All zynqmp
On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> The media watchdog mechanism involves GuC doing a silent reset and
> continue of the hung context. This requires the i915 driver provide a
> golden context to GuC in the ADS.
>
> Signed-off-by: John
From: José Roberto de Souza
commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream.
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes:
From: Wayne Lin
commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream.
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In
From: José Roberto de Souza
commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream.
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes:
From: Wayne Lin
commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream.
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In
From: Greg Kroah-Hartman
This reverts commit fcb041ca5c7787b096aafc899e45f93583e66cbd which is
commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
Turns out this was incomplete, as it is missing a dependancy, so drop it
from the tree.
Link:
From: José Roberto de Souza
commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream.
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes:
From: Wayne Lin
commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream.
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In
https://bugzilla.kernel.org/show_bug.cgi?id=213779
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> The user can open multiple device FDs if it likes, however the open
> function calls vfio_register_notifier() on device global state. Calling
> vfio_register_notifier() twice will trigger a WARN_ON from
> notifier_chain_register() and the first close
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> mbochs_close() iterates over global device state and frees it. Currently
> this is done every time a device FD is closed, but if multiple device FDs
> are open this could corrupt other still active FDs.
>
> Change this to use close_device() so it
Am 19.07.21 um 16:21 schrieb Rob Clark:
On Mon, Jul 19, 2021 at 1:40 AM 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
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> The user can open multiple device FDs if it likes, however these open()
> functions call vfio_register_notifier() on some device global
> state. Calling vfio_register_notifier() twice in will trigger a WARN_ON
> from notifier_chain_register() and the
hi
Am 19.07.21 um 13:23 schrieb Greg Kroah-Hartman:
On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote:
On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman
wrote:
From: Thomas Zimmermann
commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
Using struct drm_device.pdev is
On Mon, Jul 19, 2021 at 1:40 AM 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 piece
On 7/13/21 6:47 PM, Philippe CORNU wrote:
Hi Antonio,
On 7/13/21 4:49 PM, Antonio Borneo wrote:
The driver uses a conservative set of hardcoded values for the
maximum time delay of the transitions between LP and HS, either
for data and clock lanes.
By using the info in STM32MP157
On 7/13/21 6:43 PM, Philippe CORNU wrote:
Hi Jagan,
On 7/4/21 3:59 PM, Jagan Teki wrote:
As dw-mipi-dsi supported all possible ways to find the DSI
devices. It can take multiple iterations for ltdc to find
all components attached to the DSI bridge.
The current ltdc driver failed to find
On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
>
> On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> > > wrote:
> > > >
> > > > On Fri, 16 Jul 2021 at 16:52, Matthew
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297925
--> https://bugzilla.kernel.org/attachment.cgi?id=297925=edit
kernel .config (5.14-rc2, AMD A10-8750)
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297923
--> https://bugzilla.kernel.org/attachment.cgi?id=297923=edit
kernel dmesg (5.14-rc2, AMD A10-8750)
--
You may reply to this email to add a comment.
You are
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297921
--> https://bugzilla.kernel.org/attachment.cgi?id=297921=edit
output of /sys/kernel/debug/kmemleak (kernel 5.14-rc2)
Looking slightly different on kernel
On Thu, Jul 15, 2021 at 09:58:07AM +0800, lichenyang wrote:
> +int loongson_crtc_init(struct loongson_device *ldev, int index)
> +{
> + struct loongson_crtc *lcrtc;
> + u32 ret;
This should be "int ret;"
> +
> + lcrtc = kzalloc(sizeof(struct loongson_crtc), GFP_KERNEL);
> + if
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Add missing drm parameters to recently added call to
drm_dbg_kms()
to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Add missing drm parameters to recently added call to
drm_dbg_kms()
to the 5.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
Revert "drm/ast: Remove reference to struct drm_device.pdev"
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Add missing drm parameters to recently added call to
drm_dbg_kms()
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The
On Mon, Jul 19, 2021 at 07:43:39PM +0800, Xiaotian Feng wrote:
> On Mon, Jul 19, 2021 at 7:23 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote:
> > > On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > From: Thomas
On Mon, Jul 19, 2021 at 10:01:31AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 19, 2021 at 02:58:58PM +0200, Cornelia Huck wrote:
> > > - ret = device->ops->open(device);
> > > - if (ret) {
> > > - module_put(device->dev->driver->owner);
> > > - vfio_device_put(device);
> > > -
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> The core code no longer requires these ops to be defined, so delete these
> empty functions and leave the op as NULL. mtty's functions only log a
> pointless message, delete that entirely.
>
> Signed-off-by: Yishai Hadas
> Signed-off-by: Jason
On Mon, Jul 19, 2021 at 02:58:58PM +0200, Cornelia Huck wrote:
> > - ret = device->ops->open(device);
> > - if (ret) {
> > - module_put(device->dev->driver->owner);
> > - vfio_device_put(device);
> > - return ret;
> > + mutex_lock(>dev_set->lock);
> > +
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> Currently the driver ops have an open/release pair that is called once
> each time a device FD is opened or closed. Add an additional set of
> open/close_device() ops which are called when the device FD is opened for
> the first time and closed for
On Mon, Jul 19 2021, Jason Gunthorpe wrote:
> On Mon, Jul 19, 2021 at 02:11:38PM +0200, Cornelia Huck wrote:
>> On Wed, Jul 14 2021, Jason Gunthorpe wrote:
>>
>> > From: Max Gurtovoy
>> >
>> > This pairs with vfio_init_group_dev() and allows undoing any state that is
>> > stored in the
On Mon, Jul 19, 2021 at 02:11:38PM +0200, Cornelia Huck wrote:
> On Wed, Jul 14 2021, Jason Gunthorpe wrote:
>
> > From: Max Gurtovoy
> >
> > This pairs with vfio_init_group_dev() and allows undoing any state that is
> > stored in the vfio_device unrelated to registration. Add appropriately
> >
On Wed, Jul 14 2021, Jason Gunthorpe wrote:
> From: Max Gurtovoy
>
> This pairs with vfio_init_group_dev() and allows undoing any state that is
> stored in the vfio_device unrelated to registration. Add appropriately
> placed calls to all the drivers.
>
> The following patch will use this to
1 - 100 of 146 matches
Mail list logo