On Mon, Oct 19, 2020 at 8:38 AM estherbdf <603571...@qq.com> wrote:
>
> [Why] the func bios_parser_get_src_obj () is similar to
> bios_parser_get_dst_obj () which is fixed by the
> commit("drm/amd/display: Banch of smatch error and warning
> fixes in DC").
> the symbol 'id' is uninitialized
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_atomic.c| 17 -
Add the dpu_dbg module which adds supports to dump dpu registers
which can be used in case of error conditions.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c | 316 ++
Register the base address of various dpu sub-modules with the
dpu_dbg module so that it can be dumped out during error scenarios.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_dbg.c | 4 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 6 -
This series adds support to use devcoredump for DPU driver. It introduces
the dpu_dbg module which assists in the capturing of register dumps during
error scenarios. When a display related error happens, the dpu_dbg module
captures all the relevant register dumps along with the snapshot of the drm
Add dpu_dbg points across dpu driver to trigger dumps when critical
errors are hit.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
Hi Guido.
On Tue, Oct 20, 2020 at 01:57:11PM +0200, Guido Günther wrote:
> Hi Daniel, Sam,
> On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > >
> > > On Sat, Oct 17, 2020 at 11:13:07AM +0200,
Applied. Thanks!
Alex
On Mon, Oct 19, 2020 at 11:08 AM Harry Wentland wrote:
>
> On 2020-10-19 10:55 a.m., Christian König wrote:
> > Am 19.10.20 um 16:43 schrieb t...@redhat.com:
> >> From: Tom Rix
> >>
> >> A break is not needed if it is preceded by a return or break
> >>
> >>
Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit 40b99050455b9a6cb8faf15dcd41888312184720:
Merge tag 'drm-intel-next-fixes-2020-10-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-10-19 09:21:59
+1000)
are available in the Git repository at:
From: Dave Airlie
remove the overlapping memcp support as it's never used.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add DDP support for MT8167 SoC.
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 50 ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add support for disp-color on MT8167 SoC.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add binding documentation for the MT8167 SoC
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Fabien Parent
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Hi Thomas,
Thank you for the patch.
On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
> Trying to copy into the string fields with strncpy() gives a warning from
> gcc. Both fields are part of a packed HDMI header and do not require a
> terminating \0 character.
>
>
Hi Daniel, Sam,
On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > Hi Guido.
> >
> > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > Hi Sam,
> > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam
On Wed, Oct 21, 2020 at 10:01:29PM +0200, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 03:07:29PM +0200, Thomas Zimmermann wrote:
> > The drivers gm12u320 and udl operate on USB devices. They leave the
> > PCI device in struct drm_device empty and store the USB device in their
> > own driver
On Wed, Oct 21, 2020 at 03:07:29PM +0200, Thomas Zimmermann wrote:
> The drivers gm12u320 and udl operate on USB devices. They leave the
> PCI device in struct drm_device empty and store the USB device in their
> own driver structure.
>
> Fix this special case and save a few bytes by putting the
On Wed, Oct 21, 2020 at 8:59 PM Dan Williams wrote:
>
> On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
> >
> > We want all iomem mmaps to consistently revoke ptes when the kernel
> > takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> > pci bar mmaps available through
On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
>
> > The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to
> > split that. So ideally ->mmap would never set up any ptes.
>
> /dev/mem makes pgoff == pfn so it
On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
>
> We want all iomem mmaps to consistently revoke ptes when the kernel
> takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
> pci bar mmaps available through procfs and sysfs, which currently do
> not revoke mappings.
>
> To
On Mon, Oct 19, 2020 at 8:53 PM Josh Fuhs wrote:
>
> Thanks. I tried 5.9.1 and I think there's still a problem, or at least
> something different.
>
> Using the same configuration script, I noticed that my cards are running a
> lot hotter. For example, here's total power consumption of a
Applied. Thanks!
Alex
On Wed, Oct 21, 2020 at 8:17 AM Mauro Carvalho Chehab
wrote:
>
> Running "make htmldocs: produce lots of warnings on those files:
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess
> function parameter 'man' description in
Applied. Thanks!
Alex
On Wed, Oct 21, 2020 at 2:29 PM Sumera Priyadarsini
wrote:
>
> Return statements for functions returning bool should use truth
> and false instead of 1 and 0 respectively.
>
> Modify cik_event_interrupt.c to return false instead of 0.
>
> Issue found with Coccinelle.
>
>
On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter wrote:
>
> When we care about pagecache maintenance, we need to make sure that
> both f_mapping and i_mapping point at the right mapping.
>
> But for iomem mappings we only care about the virtual/pte side of
> things, so f_mapping is enough. Also
On Wed, 21 Oct 2020 at 17:34, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
> > It makes sense to me: some modes are annotated with a 'low-power'
> > flag, tucked away behind a client cap which makes clients opt in, and
> > they can switch into the low-power
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> On MT8167, DSI seems to work fine only if we start the clk in HS mode.
> If we don't start the clk in HS but try to switch later to HS, the
> display does not work.
>
> This commit adds a platform data variable to be used to start the
>
Hi, Fabien:
Fabien Parent 於 2020年10月21日 週三 上午1:43寫道：
>
> Add binding documentation for the MT8167 SoC. The SoC needs
> an additional clock compared to the already supported SoC: mipi26m.
>
> Signed-off-by: Fabien Parent
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 7
On Wed, Oct 21, 2020 at 12:24 AM Viresh Kumar wrote:
>
> On 05-10-20, 11:56, Viresh Kumar wrote:
> > On 28-08-20, 11:37, Viresh Kumar wrote:
> > > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> > > find the OPP table with error -ENODEV (i.e. OPP table not present for
>
Ah, good point. It looks like you've already added the drm-misc-next and drm
maintainers to here so as long as they're aware that should be fine
On Wed, 2020-10-21 at 12:11 +0200, Mauro Carvalho Chehab wrote:
> Hi Lyude,
>
> Em Tue, 13 Oct 2020 15:49:11 -0400
> Lyude Paul escreveu:
>
> > wait,
On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
> On Wed, 21 Oct 2020 at 16:58, Daniel Vetter wrote:
> > On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote:
> > > It's useful in Android and other embedded devices to implement Always On
> > > Display (ex. showing clock faces with less
It's the horror and shouldn't be used. Realized we're not clear on
this in a discussion with Rob about what msm is doing to better
support async commits.
v2: Refine existing todo item to include this (Thomas)
Cc: Sean Paul
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc:
With the removal of helper support it doesn't do anything anymore.
Also, we already have async plane update code in vc4.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
Cc: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 --
1 file changed, 6 deletions(-)
diff --git
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed.
>
> On Tue, 20 Oct 2020, Anshuman Gupta wrote:
> > Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
> > It is based upon the actual number of MST streams and size of
> > wired_cmd_repeater_auth_stream_req_in.
> > Excluding the size of hdcp_cmd_header.
> >
> > Cc: Tomas Winkler
On Wed, 21 Oct 2020 at 16:58, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote:
> > It's useful in Android and other embedded devices to implement Always On
> > Display (ex. showing clock faces with less than 15% OPR on screen).
> >
> > OPR (On Pixel Ratio) is the
On Thu, Oct 08, 2020 at 10:38:05AM -0400, Alex Deucher wrote:
> On Thu, Oct 8, 2020 at 10:29 AM Daniel Vetter wrote:
> >
> > It's the only ioctl handler purely for legacy drivers that didn't have
> > this yet.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Alex Deucher
Thanks for
On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote:
>
> Hi All,
>
> It's useful in Android and other embedded devices to implement Always On
> Display (ex. showing clock faces with less than 15% OPR on screen).
>
> OPR (On Pixel Ratio) is the percentage of luminance amount over the display
> area.
On Wed, Oct 21, 2020 at 5:13 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote:
>
> > Uh yes. In drivers/gpu this isn't a problem because we only install
> > ptes from the vm_ops->fault handler. So no races. And I don't think
> > you can fix this
On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> When the next bridge does not specify any bus flags, use the
> bridge->timings->input_bus_flags as fallback when propagating
> bus flags from next bridge to current bridge.
>
> Signed-off-by: Nikhil Devshatwar
> ---
> drivers/gpu/drm/drm_bridge.c
On 2020-10-21 10:35 a.m., Ville Syrjälä wrote:
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020
On Wed, Oct 21, 2020 at 2:50 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 21, 2020 at 10:56:51AM +0200, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_exclusive, proc never did. And
On Tue, Oct 20, 2020 at 09:46:30PM -0400, Vitaly Prosyak wrote:
>
> On 2020-10-20 11:04 a.m., Ville Syrjälä wrote:
> > On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
> >> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> >>> On Fri, 16 Oct 2020 16:50:16 +0300
> >>> Ville Syrjälä
On Wed, Oct 21, 2020 at 11:38 AM Niklas Schnelle wrote:
>
>
>
> On 10/21/20 10:56 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu drivers dynamically manage their memory
Drop the driver's udev field in favor of the one in struct drm_device. No
functional changes made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_connector.c | 8
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 1 -
Drop the driver's udev field in favor of the one in struct drm_device. No
functional changes made.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 52 +++--
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git
We have DRM drivers that operate on USB devices. So far they had
to store a pointer to the USB device structure. Move the reference
into struct drm_device. Putting the USB device into a union with
the PCI data saves a few bytes. Both should mutually exclusive.
Signed-off-by: Thomas Zimmermann
The drivers gm12u320 and udl operate on USB devices. They leave the
PCI device in struct drm_device empty and store the USB device in their
own driver structure.
Fix this special case and save a few bytes by putting the USB device
into an anonymous union with the PCI data. It's expected that DRM
https://bugzilla.kernel.org/show_bug.cgi?id=203339
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to vita.am...@gmail.com from comment #4)
> But what if i need virtual display in order to use it as a second monitor
> via vnc? There is no way...
Patches welcomed.
--
You
any reply or have been acked is on
this branch:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=docs_for_v5.10
There are a couple of warnings that aren't addressed here, because
they don't show at linux-next. I'm keeping a second patch series
against next-20201021 fixing additional
Running "make htmldocs: produce lots of warnings on those files:
./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess
function parameter 'man' description in 'amdgpu_vram_mgr_init'
./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:177: warning: Excess
function
Compiling fbcon.c gives
../drivers/video/fbdev/core/fbcon.c: In function 'fbcon_exit':
../drivers/video/fbdev/core/fbcon.c:3358:7: warning: variable 'pending' set but
not used [-Wunused-but-set-variable]
3358 | int pending = 0;
| ^~~
The variable pending is only used for
Trying to copy into the string fields with strncpy() gives a warning from
gcc. Both fields are part of a packed HDMI header and do not require a
terminating \0 character.
../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified
On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> To be able to support connector operations across multiple
> bridges, it is recommended that the connector should be
> created by the SoC driver instead of the bridges.
>
> Modify the tidss modesetting initialization sequence to
> create the
Am 21.10.20 um 10:33 schrieb Daniel Vetter:
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
From: Dave Airlie
Currently drivers get called to move a buffer, but if they have to
move it temporarily through another space (SYSTEM->VRAM via TT)
then they can end up with a lot of
Hi Lyude,
Em Tue, 13 Oct 2020 15:49:11 -0400
Lyude Paul escreveu:
> wait, I think there's some confusion here. these patches have already been
> pushed
As the patch adding the warning was merged upstream at the 5.10 merge
window, the fixup one should also be added there, instead of waiting
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
Removed unused parameter.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
The move notify callback is only used in one place, this should
be removed in the future, but for now just rename it to the use
case which is to notify the driver that the GPU memory is to be
deleted.
Probably the right thing to do
On Tue, 20 Oct 2020, Pankaj Bharadiya
wrote:
> Kodi patches are reviewed and accepted for merge now.
>
> Here is the userspace patch series link:
> https://github.com/xbmc/xbmc/pull/18567
>
> Background on Integer scaling:
>
> Integer scaling (IS) is a nearest-neighbor upscaling technique that
>
On Mon, Oct 19, 2020 at 05:48:29PM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 07:46:41PM +0800, Shawn Guo wrote:
> > Indeed! Adding drm_crtc_vblank_reset() into driver crtc reset hook
> > removes the WARNING for me. Really appreciate your comments, Daniel!
>
> This should work
https://bugzilla.kernel.org/show_bug.cgi?id=203339
vita.am...@gmail.com (vita.am...@gmail.com) changed:
What|Removed |Added
CC|
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer,
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only
Hi all,
Round 3 of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc:
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc:
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Daniel Vetter
Cc:
On Wed, Oct 21, 2020 at 07:40:48AM +, Simon Ser wrote:
> On Wednesday, October 21, 2020 8:54 AM, Ken Huang
> wrote:
>
> > From: Adrian Salido sali...@google.com
> >
> > Some displays may support Low Power modes, however, these modes may
> > require special handling as they would usually
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently drivers get called to move a buffer, but if they have to
> move it temporarily through another space (SYSTEM->VRAM via TT)
> then they can end up with a lot of ttm->driver->ttm call stacks,
> if the
Hi
On 21.10.20 10:14, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann
> wrote:
>>
>> Hi
>>
>> On 19.10.20 21:43, Kevin Brace wrote:
>>> Hi Sam,
>>>
>>> Thanks for asking the question.
>>> The current OpenChrome DRM code has these two major issues.
>>>
>>> 1) It does
On Tue, Oct 20, 2020 at 01:26:29PM -0700, Rob Clark wrote:
> On Tue, Oct 20, 2020 at 11:14 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Oct 20, 2020 at 5:08 PM Rob Clark
On Wed, Oct 21, 2020 at 10:03 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 19.10.20 21:43, Kevin Brace wrote:
> > Hi Sam,
> >
> > Thanks for asking the question.
> > The current OpenChrome DRM code has these two major issues.
> >
> > 1) It does not support atomic modesetting
> >
> > I do internally
Hi
On 19.10.20 21:43, Kevin Brace wrote:
> Hi Sam,
>
> Thanks for asking the question.
> The current OpenChrome DRM code has these two major issues.
>
> 1) It does not support atomic modesetting
>
> I do internally have working code to support atomic modesetting, but it is
> not ready for
On Wednesday, October 21, 2020 8:54 AM, Ken Huang wrote:
> From: Adrian Salido sali...@google.com
>
> Some displays may support Low Power modes, however, these modes may
> require special handling as they would usually require lower OPR
> content on framebuffers.
I'm not familiar with OPR. Can
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
From: Allen Chen
Signed-off-by: Jitao Shi
Signed-off-by: Pi-Hsun Shih
Signed-off-by: Yilun Lin
Signed-off-by: Hermes Wu
Signed-off-by: Allen Chen
---
drivers/gpu/drm/bridge/Kconfig |7 +
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- Add more information to commit message
Changes in v3:
-- return when dev_pm_opp_set_clkname() failed
Signed-off-by: Kuogee Hsieh
dev_err_probe function simplifies error handling. So use the same in probe
function wherever possible.
Signed-off-by: Biju Das
---
drivers/gpu/drm/bridge/lvds-codec.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
I got a UAF report in do_update_region() when I doing fuzz test.
[ 51.161905] BUG: KASAN: use-after-free in do_update_region+0x579/0x600
[ 51.161918] Read of size 2 at addr 88800010 by task test/295
[ 51.161957] CPU: 2 PID: 295 Comm: test Not tainted 5.7.0+ #975
[ 51.161969]
C reproducer:
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static long syz_open_dev(volatile long a0, volatile long a1, volatile
long a2)
{
if
Hi!
Here's a couple of patches that should be merged in the current merge-window.
Thanks!
Maxime
drm-misc-next-fixes-2020-10-20:
Two patches to prevent out-of-bands accesses on fonts buffers
The following changes since commit d3c8f2784d3266d27956659c78835ee1d1925ad2:
drm/ingenic: Fix bad
Hi sam
This bridge will be used with
mtk_dpi.c(https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_dpi.c).
Thanks for your comments.
-Original Message-
From: Sam Ravnborg [mailto:s...@ravnborg.org]
Sent: Saturday, October 17, 2020 3:27 PM
To: Allen Chen (陳柏宇)
Add binding documentation for the MT8167 SoC. The SoC needs
an additional clock compared to the already supported SoC: mipi26m.
Signed-off-by: Fabien Parent
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Fix the warning message "missing connector type" by adding connector_type
for EDT ETM0700G0DH6 panel.
Signed-off-by: Biju Das
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
Add the main (DSI) drm display path for MT8167.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index
The sii902x chip family requires IO and core voltages to reach the
correct voltage before chip initialization. Add binding for describing
the two supplies.
Signed-off-by: Alexandru Gagniuc
Acked-by: Rob Herring
---
Changes since v1, v2:
* Nothing. version incremented to stay in sync with
> On 19 Oct 2020, at 20:42, Nick Desaulniers wrote:
>
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.
It looks as though the URL mangling has been fixed. If anyone sees that
specific
Hi there,
Could someone please comment on the following hard-lock (*). Staring
at the code, I see `nvkm_rd32` calls are enclosed in a timeout
detection, except one.
drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171
...
nvkm_msec(device, 2000,
if (!(nvkm_rd32(device, 0x100c80) & 0x0001))
Add DDP support for MT8167 SoC.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index
Add binding documentation for the MT8167 SoC
Signed-off-by: Fabien Parent
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
No need to check LINK_STATuS_UPDATED bit before
return 6 bytes of link status during link training.
This patch also fix phy compliance test link rate
conversion error.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
drivers/gpu/drm/msm/dp/dp_link.c |
1 - 100 of 112 matches
Mail list logo
