Hi Tetsuo,
Thanks for your patch!
On Mon, Aug 30, 2021 at 6:05 PM Tetsuo Handa
wrote:
> syzbot is reporting page fault at vga16fb_fillrect() [1], for
> vga16fb_check_var() is failing to detect multiplication overflow.
>
> if (vxres * vyres > maxmem) {
> vyres = maxmem / vxres;
> if (vy
Am 31.08.21 um 05:44 schrieb guangming@mediatek.com:
From: Guangming Cao
Am 30.08.21 um 12:01 schrieb guangming@mediatek.com:
From: Guangming Cao
Current flow, one dmabuf maybe call cache sync many times if
it has beed mapped more than one time.
Well I'm not an expert on DMA heaps,
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_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
Hi,
I updated the patch set with some suggestions by Daniel Vetter, and
dropped the patches after patch 4 so that we can stick the landing for
avoiding races with modesetting rights before dealing with the tricky
spinlock.
Overall, this series fixes races with modesetting rights, and converts
drm
On 26/8/21 9:21 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote:
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
The zte zx platform was removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform") and the zxdrm driver is going to be removed in v5.15 via
drm tree. Let's remove the now obsolete binding doc.
Cc: Arnd Bergmann
Cc: Jun Nie
Cc: Shawn Guo
Signed-off-by: Zenghui Yu
---
.../devicetree/binding
From: Guangming Cao
> Am 30.08.21 um 12:01 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > Current flow, one dmabuf maybe call cache sync many times if
> > it has beed mapped more than one time.
>
> Well I'm not an expert on DMA heaps, but this will most likely not work
> co
Hi Umesh,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210830]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.14]
[If your
On 2021/8/31 0:12, Rob Herring wrote:
On Thu, Aug 26, 2021 at 4:22 AM Daniel Vetter wrote:
I just merged another patch to delete the zte driver.
Unfortunately, that one missed the binding doc, so please send me a
patch removing the binding doc.
Okay I'll send it out today.
I've searched t
On 2021-08-30 15:53:10, Stephen Boyd wrote:
> Quoting Marijn Suijten (2021-08-30 15:45:42)
> > Hi Stephen,
> >
> > On 2021-08-30 15:16:13, Stephen Boyd wrote:
> > > Quoting Marijn Suijten (2021-08-30 11:24:44)
> > > > All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> > > > glo
Quoting Lyude Paul (2021-08-30 09:58:01)
> On Mon, 2021-08-30 at 08:56 -0700, khs...@codeaurora.org wrote:
> > On 2021-08-25 09:26, Lyude Paul wrote:
> > > The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems
> > > like it
> > > just hasn't trickled down to linus's branch quite ye
Quoting Marijn Suijten (2021-08-30 15:45:42)
> Hi Stephen,
>
> On 2021-08-30 15:16:13, Stephen Boyd wrote:
> > Quoting Marijn Suijten (2021-08-30 11:24:44)
> > > All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> > > global name, most of which don't exist or have been renamed.
Hi Stephen,
On 2021-08-30 15:16:13, Stephen Boyd wrote:
> Quoting Marijn Suijten (2021-08-30 11:24:44)
> > All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> > global name, most of which don't exist or have been renamed. These
> > clock drivers seem to function fine without th
Quoting Marijn Suijten (2021-08-30 11:24:44)
> All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> global name, most of which don't exist or have been renamed. These
> clock drivers seem to function fine without that except the 14nm driver
> for the sdm6xx [1].
>
> At the same
On Mon, Aug 30, 2021 at 01:09:24PM -0400, Lyude Paul wrote:
oops-except for "drm/nouveau: block a bunch of classes from userspace" of
course. the rest are fine though
Yup, that one is gone :)
--
Thanks,
Sasha
On 26/8/21 8:59 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:19AM +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_rwsem while
c
On 26/8/21 5:58 pm, Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 10:01:18AM +0800, Desmond Cheong Zhi Xi wrote:
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mu
On 8/27/2021 6:27 PM, Daniele Ceraolo Spurio wrote:
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkle
https://bugzilla.kernel.org/show_bug.cgi?id=214199
--- Comment #2 from Zeljko (ker...@zeljko.anonaddy.com) ---
At first, I've got both monitors to work correctly with amdgpu.dc=0 kernel
parameter.
After analyzing the dmesg outputs without the above kernel parameter I've
noticed that, on boot, my
On Fri, 2021-08-27 at 19:43 -0400, Fangzhi Zuo wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63 slots available.
>
> In 128b/132b encoding format, metadata is transmitted
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggere
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
v4: Use intel_uncore_rm
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
en
From: Chris Wilson
The OA subsystem would like to enable its privileged clients access to
the OA registers from execbuf. This requires temporarily removing the
HW validation from those registers for the duration of the OA client,
for which we need to allow OA to dynamically adjust the set of
RING
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.
v2:
-
From: Chris Wilson
Strip the encoded bits from the register offset so that we only use the
address for looking up the RING_NONPRIV entry.
Signed-off-by: Chris Wilson
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +
1 file changed,
From: Chris Wilson
Switch the search and grow code of the _wa_add to use _wa_index and
_wa_list_grow.
Signed-off-by: Chris Wilson
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 124 +++-
1 file changed, 71 insertions(+), 53 deletions(-)
d
This is a revival of the patch series to support triggered perf query reports
from here - https://patchwork.freedesktop.org/series/83831/
The patches were not pushed earlier because corresponding UMD changes were
missing. This revival addresses UMD changes in GPUvis for this series. GPUvis
uses th
Refactor intel_engine_apply_whitelist into locked and unlocked versions
so that a caller who already has the lock can apply whitelist.
v2: Fix sparse warning
v3: (Chris)
- Drop prefix and suffix for static function
- Use longest to shortest line ordering for variable declaration
Signed-off-by: Um
On Thu, Aug 05, 2021 at 12:47:05PM +0200, Daniel Vetter wrote:
> Specifically document the new/clarified rules around how the shared
> fences do not have any ordering requirements against the exclusive
> fence.
>
> But also document all the things a bit better, given how central
> struct dma_resv
The DSI PHY/PLL was relying on a global "xo" clock to be found, but the
real clock is named "xo_board" in the DT. The standard nowadays is to
never use global clock names anymore but require the firmware (DT) to
provide every clock binding explicitly with .fw_name. The DSI PLLs have
since been co
All DSI PHY/PLL drivers were referencing their VCO parent clock by a
global name, most of which don't exist or have been renamed. These
clock drivers seem to function fine without that except the 14nm driver
for the sdm6xx [1].
At the same time all DTs provide a "ref" clock as per the requirement
All DSI PHY/PLL drivers were referencing their VCO parent clock by a
global name, most of which don't exist or have been renamed. These
clock drivers seem to function fine without that except the 14nm driver
for the sdm6xx [1].
At the same time all DTs provide a "ref" clock as per the requirement
On 2021-08-30 1:05 p.m., Christian König wrote:
Am 30.08.21 um 19:02 schrieb Andrey Grodzovsky:
On 2021-08-30 12:51 p.m., Christian König wrote:
Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky:
On 2021-08-30 4:58 a.m., Christian König wrote:
Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky
Am 2021-08-30 um 4:28 a.m. schrieb Christoph Hellwig:
> On Thu, Aug 26, 2021 at 06:27:31PM -0400, Felix Kuehling wrote:
>> I think we're missing something here. As far as I can tell, all the work
>> we did first with DEVICE_GENERIC and now DEVICE_PUBLIC always used
>> normal pages. Are we missing s
On 2021-08-30 12:51 p.m., Christian König wrote:
Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky:
On 2021-08-30 4:58 a.m., Christian König wrote:
Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky:
This list will be used to capture all non VRAM BOs not
on LRU so when device is hot unplugged we c
oops-except for "drm/nouveau: block a bunch of classes from userspace" of
course. the rest are fine though
On Mon, 2021-08-30 at 13:08 -0400, Lyude Paul wrote:
> ahhh-ok, that makes these patchs make a bit more sense then. If Ben doesn't
> have any objections I'd say these are fine to backport the
ahhh-ok, that makes these patchs make a bit more sense then. If Ben doesn't
have any objections I'd say these are fine to backport then
On Mon, 2021-08-30 at 08:17 -0400, Sasha Levin wrote:
> On Tue, Aug 24, 2021 at 01:08:28PM -0400, Lyude Paul wrote:
> > This is more hardware enablement, I'm not
Am 30.08.21 um 19:02 schrieb Andrey Grodzovsky:
On 2021-08-30 12:51 p.m., Christian König wrote:
Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky:
On 2021-08-30 4:58 a.m., Christian König wrote:
Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky:
This list will be used to capture all non VRAM
Am 30.08.21 um 19:00 schrieb Andrey Grodzovsky:
On 2021-08-30 12:55 p.m., Christian König wrote:
Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky:
On 2021-08-30 4:57 a.m., Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able after allocati
On 2021-08-30 12:55 p.m., Christian König wrote:
Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky:
On 2021-08-30 4:57 a.m., Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including
On Mon, 2021-08-30 at 08:56 -0700, khs...@codeaurora.org wrote:
> On 2021-08-25 09:26, Lyude Paul wrote:
> > The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems
> > like it
> > just hasn't trickled down to linus's branch quite yet.
>
> Hi Stephen B,
>
> Would you mind back por
Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky:
On 2021-08-30 4:57 a.m., Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including OOM on GDS handling
and not being able to use TTM a
On 2021-08-30 4:57 a.m., Christian König wrote:
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including OOM on GDS handling
and not being able to use TTM as general resource manager.
Signed-off-by: Chri
Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky:
On 2021-08-30 4:58 a.m., Christian König wrote:
Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky:
This list will be used to capture all non VRAM BOs not
on LRU so when device is hot unplugged we can iterate
the list and unmap DMA mappings before de
On Thu, Aug 26, 2021 at 01:37:34PM -0400, Rodrigo Vivi wrote:
> On Fri, Aug 20, 2021 at 08:26:14PM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote:
> > > Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> > > fast+narrow link on eDP
Hi,
On Sun, Aug 29, 2021 at 7:39 PM yangcong
wrote:
>
> Support for these two panels fits in nicely with the existing
> panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. The main things
> we needed to handle were:
> a) These panels need slightly longer delays in two places. Since these
> new
On Thu, Aug 26, 2021 at 4:22 AM Daniel Vetter wrote:
>
> On Mon, Aug 23, 2021 at 01:51:30PM -0500, Rob Herring wrote:
> > On Sat, 21 Aug 2021 11:13:57 +0800, Zenghui Yu wrote:
> > > The zte zx platform had been removed in commit 89d4f98ae90d ("ARM: remove
> > > zte zx platform"), so this driver is
Applied. Thanks!
Alex
On Sun, Aug 29, 2021 at 12:46 PM Colin King wrote:
>
> From: Colin Ian King
>
> Pointer sink is being inintialized with a value that is never read,
> it is later being re-assigned a new value. Remove the redundant
> initialization.
>
> Addresses-Coverity: ("Unused value")
Applied. Thanks!
Alex
On Fri, Aug 27, 2021 at 2:59 PM Colin King wrote:
>
> From: Colin Ian King
>
> There are three identical spelling mistakes in dev_err messages.
> Fix these.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
> drivers/
Maybe the commit message can be improved a bit? Add a prefix to make it
clear this is about the udl driver, make it clear this is about the
udl_get_edid_block function. The new `return ret` statement may return
something different from ENOMEM.
This would give something among these lines:
drm/
syzbot is reporting page fault at vga16fb_fillrect() [1], for
vga16fb_check_var() is failing to detect multiplication overflow.
if (vxres * vyres > maxmem) {
vyres = maxmem / vxres;
if (vyres < yres)
return -ENOMEM;
}
Since no module would accept too huge resolutions where multi
check the return value and pass the proper error code.
Signed-off-by: F.A. SULAIMAN
---
drivers/gpu/drm/udl/udl_connector.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index cdc1c42e166
Hi,
On Sat, Aug 28, 2021 at 7:40 AM Bjorn Andersson
wrote:
>
> On Fri 27 Aug 15:52 CDT 2021, Doug Anderson wrote:
>
> > Hi,
> >
> > On Mon, Jul 26, 2021 at 4:15 PM Bjorn Andersson
> > wrote:
> > >
> > > +static int dp_parser_find_panel(struct dp_parser *parser)
> > > +{
> > > + struct devi
On 2021-08-25 09:26, Lyude Paul wrote:
The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems
like it
just hasn't trickled down to linus's branch quite yet.
Hi Stephen B,
Would you mind back porting this patch to V5.10 branch?
It will have lots of helps for us to support displ
On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote:
> The VESA Organization Vendor-Specific Data Block, defined in VESA
> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
> stream count and segment pixel overlap.
>
> DisplayID v1.3 has Appendix B: DisplayID as an EDID
Hi Tetsuo,
On Mon, Aug 30, 2021 at 4:53 PM Geert Uytterhoeven wrote:
> On Mon, Aug 30, 2021 at 4:38 PM Tetsuo Handa
> wrote:
> > On 2021/08/30 23:30, Geert Uytterhoeven wrote:
> > > The highest possible value of maxmem inside vga16fb_check_var()
> > > is 65536.
> >
> > Yes.
> >
> > >
> > > So I
Hi Tetsuo,
On Mon, Aug 30, 2021 at 12:25 PM Tetsuo Handa
wrote:
> On 2021/08/30 17:16, Daniel Vetter wrote:
> > On Mon, Aug 30, 2021 at 11:30:23AM +0800, tcs.ker...@gmail.com wrote:
> >> From: Haimin Zhang
> >>
> >> yres and vyres can be controlled by user mode parameters, and cause
> >> p->vrow
Hi Tetsuo,
On Mon, Aug 30, 2021 at 4:38 PM Tetsuo Handa
wrote:
> On 2021/08/30 23:30, Geert Uytterhoeven wrote:
> > The highest possible value of maxmem inside vga16fb_check_var()
> > is 65536.
>
> Yes.
>
> >
> > So I believe
> >
> > if (array_size(vxres, vyres) > maxmem)
> >
> > should work
On 2021/08/30 23:30, Geert Uytterhoeven wrote:
> The highest possible value of maxmem inside vga16fb_check_var()
> is 65536.
Yes.
>
> So I believe
>
> if (array_size(vxres, vyres) > maxmem)
>
> should work fine.
My intent is to check at common path than individual module so that we don't
Hi Cai,
On Sat, Aug 28, 2021 at 04:52:52PM +0800, Cai Huoqing wrote:
> Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
> operators ".runtime_suspend/.runtime_resume", because the
> SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought
> in to make code a little clearer
Hi Tetsuo,
On Mon, Aug 30, 2021 at 4:26 PM Tetsuo Handa
wrote:
> On 2021/08/30 22:47, Dan Carpenter wrote:
> > On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
> >> On 2021/08/30 22:00, Dan Carpenter wrote:
> > diff --git a/drivers/video/fbdev/vga16fb.c
> > b/drivers/video/f
On Mon, Aug 30, 2021 at 11:25:51PM +0900, Tetsuo Handa wrote:
> On 2021/08/30 22:47, Dan Carpenter wrote:
> > On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
> >> On 2021/08/30 22:00, Dan Carpenter wrote:
> > diff --git a/drivers/video/fbdev/vga16fb.c
> > b/drivers/video/fbde
On 2021/08/30 22:47, Dan Carpenter wrote:
> On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
>> On 2021/08/30 22:00, Dan Carpenter wrote:
> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
> index e2757ff1c23d..e483a3f5fd47 100644
> --- a/drivers/v
Hi Dmitry,
On Mon, Aug 30, 2021 at 04:17:32AM +0300, Dmitry Baryshkov wrote:
> On Mon, 30 Aug 2021 at 00:53, Marijn Suijten
> wrote:
> >
> > Hi Dmitry,
> >
> > On 8/29/21 10:39 PM, Dmitry Baryshkov wrote:
> > > Hi,
> > >
> > > On Sun, 29 Aug 2021 at 23:30, Marijn Suijten
> > > wrote:
> > >>
> >
On 2021-08-30 4:58 a.m., Christian König wrote:
Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky:
This list will be used to capture all non VRAM BOs not
on LRU so when device is hot unplugged we can iterate
the list and unmap DMA mappings before device is removed.
v2: Reanme function to ttm_bo_
On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> From: Maor Gottlieb
>
> Changelog:
> v4:
> * Unify sg_free_table_entries with __sg_free_table
> v3: https://lore.kernel.org/lkml/cover.1627551226.git.leo...@nvidia.com/
> * Rewrote to new API suggestion
> * Split for more patches
On Mon, Aug 30, 2021 at 10:31:28AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> > On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > > From: Maor Gottlieb
> > >
> > > Changelog:
> > > v4:
> > > * Unify sg_free_table_entries wi
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #298267|0 |1
is obsolete|
Hi,
On Tue, Aug 17, 2021 at 10:43 PM Anisse Astier wrote:
>
> This patch series is for making the GPD Win Max display usable with
> Linux.
>
> The GPD Win Max is a small laptop, and its eDP panel does not send an
> EDID over DPCD; the EDID is instead available in the intel opregion, in
> mailbox
On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
> On 2021/08/30 22:00, Dan Carpenter wrote:
> >>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
> >>> index e2757ff1c23d..e483a3f5fd47 100644
> >>> --- a/drivers/video/fbdev/vga16fb.c
> >>> +++ b/drivers/vide
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #298265|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #298269|0 |1
is obsolete|
On 2021/08/30 22:00, Dan Carpenter wrote:
>>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
>>> index e2757ff1c23d..e483a3f5fd47 100644
>>> --- a/drivers/video/fbdev/vga16fb.c
>>> +++ b/drivers/video/fbdev/vga16fb.c
>>> @@ -403,7 +403,7 @@ static int vga16fb_check_var(s
On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote:
> On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote:
> > From: Maor Gottlieb
> >
> > Changelog:
> > v4:
> > * Unify sg_free_table_entries with __sg_free_table
> > v3: https://lore.kernel.org/lkml/cover.1627551226.git.le
On Sat, Aug 28, 2021 at 4:41 AM Cai Huoqing wrote:
>
> Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
> operators ".runtime_suspend/.runtime_resume/.runtime_idle", because
> the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought
> in to make code a little clearer,
On Mon, Aug 30, 2021 at 02:00:21PM +0200, Geert Uytterhoeven wrote:
> Hi Testsuo,
>
> On Mon, Aug 30, 2021 at 4:27 AM Tetsuo Handa
> wrote:
> > On 2021/08/30 9:24, Randy Dunlap wrote:
> > > Note that yres_virtual is set to 0x1000. Is there no practical limit
> > > (hence limit check) that can
Am 28.08.21 um 10:50 schrieb Cai Huoqing:
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
operators ".runtime_suspend/.runtime_resume/.runtime_idle", because
the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought
in to make code a little clearer, a little more conc
Am 30.08.21 um 12:01 schrieb guangming@mediatek.com:
From: Guangming Cao
Current flow, one dmabuf maybe call cache sync many times if
it has beed mapped more than one time.
Well I'm not an expert on DMA heaps, but this will most likely not work
correctly.
Is there any case that attach
On 30 Aug 21 08:21:52, Alex Deucher wrote:
> On Sat, Aug 28, 2021 at 4:51 AM Cai Huoqing wrote:
> >
> > Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
> > operators ".runtime_suspend/.runtime_resume/.runtime_idle", because
> > the SET_RUNTIME_PM_OPS() is a nice helper macro that
On Mon, Aug 23, 2021 at 3:11 PM Sam Ravnborg wrote:
>
> On Thu, Aug 19, 2021 at 12:10:19PM +0200, Krzysztof Kozlowski wrote:
> > Correct indentation warning:
> > ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> > found 8 (indentation)
> >
> > Signed-off-by: Krzysztof Koz
On Sat, Aug 28, 2021 at 4:51 AM Cai Huoqing wrote:
>
> Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose
> operators ".runtime_suspend/.runtime_resume/.runtime_idle", because
> the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought
> in to make code a little clearer,
On Tue, Aug 24, 2021 at 01:05:32PM -0400, Lyude Paul wrote:
This isn't at all intended to be a fix to be backported, so I don't think this
should be included. I don't know about 5/7, but I'll let Benjamin comment on
that one
I'll drop it, thanks!
--
Thanks,
Sasha
On Tue, Aug 24, 2021 at 01:08:28PM -0400, Lyude Paul wrote:
This is more hardware enablement, I'm not sure this should be going into
stable either. Ben?
We take this sort of hardware enablement patches (where the platform
code is already there, and we just add quirks/ids/etc.
--
Thanks,
Sasha
Den 17.08.2021 15.56, skrev Daniel Vetter:
> On Tue, Aug 17, 2021 at 02:29:12PM +0200, Noralf Trønnes wrote:
>> Add XRGB emulation support for devices that can only do RGB332.
>>
>> Cc: Thomas Zimmermann
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/drm_format_helper.c | 47 +
From: Krzysztof Hałasa
[ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ]
Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
bytes) is invalid. Fix it.
Signed-off-by: Krzysztof Halasa
Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl
[p.za...@pengutronix.
Hi Testsuo,
On Mon, Aug 30, 2021 at 4:27 AM Tetsuo Handa
wrote:
> On 2021/08/30 9:24, Randy Dunlap wrote:
> > Note that yres_virtual is set to 0x1000. Is there no practical limit
> > (hence limit check) that can be used here?
> >
> > Also, in vga16fb_check_var(), beginning at line 404:
> >
>
From: Krzysztof Hałasa
[ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ]
Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
bytes) is invalid. Fix it.
Signed-off-by: Krzysztof Halasa
Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl
[p.za...@pengutronix.
From: Krzysztof Hałasa
[ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ]
Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
bytes) is invalid. Fix it.
Signed-off-by: Krzysztof Halasa
Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl
[p.za...@pengutronix.
From: Krzysztof Hałasa
[ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ]
Video captured in 1400x1050 resolution (bytesperline aka stride = 1408
bytes) is invalid. Fix it.
Signed-off-by: Krzysztof Halasa
Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl
[p.za...@pengutronix.
On Mon, 30 Aug 2021, Jani Nikula wrote:
> The VESA Organization Vendor-Specific Data Block, defined in VESA
> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
> stream count and segment pixel overlap.
>
> DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
> describi
DisplayID v2.0 changes the data block identifiers and product types (now
called primary use cases).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayi
Now that we have MSO pixel overlap in display info, use it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index
MSO will require segment pixel overlap information from the
EDID. Postpone MSO init until after we've read and cached the EDID.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/dis
The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.
DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID ex
Make the values easier to read. Also add DisplayID Structure version and
revision information (this is different from the spec version).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 57 +++--
1 file changed, 29 insertions(+), 28 deletions(-)
diff
We need the DisplayID VESA vendor block data for properly configuring
eDP MSO (Multi-SST Operation) pixel overlap.
I haven't actually tested this on a panel that requires the overlap, but
this is all pretty straightforward to prepare for that use case.
BR,
Jani.
Jani Nikula (5):
drm/displayid:
1 - 100 of 131 matches
Mail list logo
