https://bugzilla.kernel.org/show_bug.cgi?id=209457
dark_syl...@yahoo.com.ar changed:
What|Removed |Added
CC||dark_syl...@yahoo.com.ar
---
Hi,
On Thu, Oct 15, 2020 at 12:07:01AM +0530, man...@codeaurora.org wrote:
> On 2020-10-14 18:59, Akhil P Oommen wrote:
> > On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
> > > On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Thu, Oct 8, 2020 at
The dma-buf API have been used under the assumption that the sg lists
returned from dma_buf_map_attachment() are fully page aligned. Lots of
stuff can break otherwise all over the place. Clarify this in the
documentation and add a check when DMA API debug is enabled.
Signed-off-by: Jianxin Xiong
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 112
This is the fifth version of the patch set. Changelog:
v5:
* Fix a few warnings reported by kernel test robot:
- no previous prototype for function 'ib_umem_dmabuf_release'
- no previous prototype for function 'ib_umem_dmabuf_map_pages'
- comparison of distinct pointer types in
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian
On Mon, Oct 12, 2020 at 09:59:22AM -0300, Melissa Wen wrote:
> On 10/10, Daniel Vetter wrote:
> > The only thing we support is xrgb.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Melissa Wen
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > ---
> >
Hi all,
On Mon, 12 Oct 2020 15:19:48 +1100 Stephen Rothwell
wrote:
>
> On Tue, 6 Oct 2020 13:41:20 -0300 Jason Gunthorpe wrote:
> >
> > On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the hmm tree, today's linux-next build (arm
> > >
On 2020-10-15 3:40 p.m., Eryk Brol wrote:
[Why]
Missed removing a '!' which results in incorrect behavior
[How]
Remove the offending '!'
Signed-off-by: Eryk Brol
Reviewed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed,
[Why]
Missed removing a '!' which results in incorrect behavior
[How]
Remove the offending '!'
Signed-off-by: Eryk Brol
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #6 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 292999
--> https://bugzilla.kernel.org/attachment.cgi?id=292999=edit
crashing dmesg #3
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #5 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 292997
--> https://bugzilla.kernel.org/attachment.cgi?id=292997=edit
crashing dmesg #2
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #3 from cornelius.riemenschnei...@googlemail.com ---
Kernel is 5.8.14-arch1-1.
I attached three dmesg outputs of the last two days, where each time the amdgpu
driver seemed to cause a divide_error, and the screen froze.
Audio
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #4 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 292995
--> https://bugzilla.kernel.org/attachment.cgi?id=292995=edit
crashing dmesg #1
--
You are receiving this mail because:
You are watching the assignee
On Fri, 16 Oct 2020 at 04:42, Linus Torvalds
wrote:
>
> On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
> wrote:
> >
> > Thanks, looks good to me [..]
>
> Uhhuh. I already pushed things out, but my clang build (which I don't
> do between each merge) shows a problem:
>
>
On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
wrote:
>
> Thanks, looks good to me [..]
Uhhuh. I already pushed things out, but my clang build (which I don't
do between each merge) shows a problem:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8:
warning:
On Wed, Sep 16, 2020 at 01:18:51PM -0400, Lyude Paul wrote:
> Since we're about to add support for a second type of backlight control
> interface over DP AUX (specifically, Intel's proprietary HDR backlight
> controls) let's rename all of the current backlight hooks we have for
> vesa to make it
On Wed, Sep 16, 2020 at 01:18:50PM -0400, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for
On Wed, Sep 16, 2020 at 01:18:48PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will
Hi Dave and Daniel,
here goes couple display fixes for this last round of fixes before -rc1
drm-intel-next-fixes-2020-10-15:
- Set all unused color plane offsets to ~0xfff again (Ville)
- Fix TGL DKL PHY DP vswing handling (Ville)
The following changes since commit
The pull request you sent on Thu, 15 Oct 2020 11:33:08 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/93b694d096cc10994c817730d4d50288f9ae3d66
Thank you!
--
Deet-doot-dot, I am a bot.
Hi
On Thu, 15 Oct 2020 16:08:13 +0200 Christian König
wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a
Reviewed-by: Lyude Paul
JFYI - since the commit this fixes has been in the kernel for a while, we should
definitely Cc this to sta...@vger.kernel.org so that it gets backported. In the
future, the dim tools have a command called "fixes" that can figure this out for
you:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
> On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
> > > kernel address space. The mapping's
On Wed, Oct 14, 2020 at 6:33 PM Dave Airlie wrote:
>
> There are a bunch of conflicts but none of them seemed overly scary,
> and sfr has provided resolutions for them all. I've put a tree up with
> my merge results, so you can tell me I did it wrong here:
>
On Thu, Oct 15, 2020 at 6:32 PM Karol Herbst wrote:
>
> Ben, I think this is like the 5th patch tackling this issue, I think
> we should merge one of those.
>
maybe I just confused that with reports, but it seems to turn up quite
a bit and maybe I should have pushed more of it as well...
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a
On 10/3/20 12:59 AM, Rob Herring wrote:
> Some DSI controllers are missing a reference to the recently added
> dsi-controller.yaml schema. Add it and we can drop the duplicate parts.
>
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Eric Anholt
> Cc: Nicolas Saenz Julienne
> Cc: Florian
Ben, I think this is like the 5th patch tackling this issue, I think
we should merge one of those.
On Thu, Oct 15, 2020 at 6:23 AM Keita Suzuki
wrote:
>
> struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
> and stored to a struct member of local variable. However, the
Am 15.10.20 um 18:03 schrieb Daniel Vetter:
On Wed, Oct 14, 2020 at 09:16:01AM -0700, Jianxin Xiong wrote:
The dma-buf API have been used under the assumption that the sg lists
returned from dma_buf_map_attachment() are fully page aligned. Lots of
stuff can break otherwise all over the place.
Em Thu, 15 Oct 2020 17:49:23 +0200
Daniel Vetter escreveu:
> On Tue, Oct 13, 2020 at 01:53:15PM +0200, Mauro Carvalho Chehab wrote:
> > This series actually folds the previous Sphinx 3.x patch series
> > with the other patches I sent fixing warnings with Sphinx
> > 2.x and with kernel-doc and
On Wed, Oct 14, 2020 at 09:15:16AM -0700, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the
On Wed, Oct 14, 2020 at 09:16:01AM -0700, Jianxin Xiong wrote:
> The dma-buf API have been used under the assumption that the sg lists
> returned from dma_buf_map_attachment() are fully page aligned. Lots of
> stuff can break otherwise all over the place. Clarify this in the
> documentation and
https://bugzilla.kernel.org/show_bug.cgi?id=209673
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Thu, Oct 15, 2020 at 07:55:32AM +0100, Christoph Hellwig wrote:
> On Tue, Oct 13, 2020 at 02:42:38PM +0100, Robin Murphy wrote:
> > I still think this situation would be best handled with a variant of
> > dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set
> > automatically
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 9, 2020 at 2:31 PM
On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:
> Hi Maintainers,
>
> Does this patch ready to merge?
Would maybe be good to get some acks from other drivers using this, then
Sandy can push to drm-misc-next.
-Daniel
>
> On 2020/7/7 下午7:25, Sandy Huang wrote:
> > don't mask
On Thu, Oct 15, 2020 at 2:15 AM Krishna Manikandan
wrote:
>
> When there are back to back commits with async cursor update,
> there is a case where second commit can program the DPU hw
> blocks while first didn't complete flushing config to HW.
>
> Synchronize the compositions such that second
On Thu, Oct 15, 2020 at 10:53:28AM -0400, Alex Deucher wrote:
> On Thu, Oct 15, 2020 at 9:59 AM Peilin Ye wrote:
> > It has been applied to linux-next twice, for unknown reasons. Thank you!
>
> The patch was already in drm-next, but since it was a bug fix it was
> applied it to 5.9 as well.
Ah,
On Thu, Oct 15, 2020 at 9:59 AM Peilin Ye wrote:
>
> Hi all,
>
> On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> > Peilin Ye (1):
> > drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
>
> This patch is already in mainline:
>
> commit
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by:
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
Hi all,
On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> Peilin Ye (1):
> drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
This patch is already in mainline:
commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31
Author: Peilin Ye
Date: Tue Jul 28 15:29:24 2020 -0400
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
On 10/13/20 9:56 AM, Yannick Fertre wrote:
> Standardize on the dev_ based logging.
>
> Signed-off-by: Yannick Fertre
> ---
> Changes in v2:
> - restore function dsi_color_from_mipi.
> - reword commit.
>
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 55 ++-
>
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions.
For
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
Signed-off-by: Thomas Zimmermann
---
include/linux/dma-buf-map.h | 72 +++--
1 file changed, 62 insertions(+), 10 deletions(-)
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
---
This patch adds a helper function to read the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new structure to store these caps,
which can then be used to get the PPS parameters for PCON-HDMI2.1 sink
pair. Which inturn will be used to take a call to override the existing
PPS-metadata,
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
Signed-off-by: Ankit Nautiyal
---
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 93 +++
include/drm/drm_dp_helper.h
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
Signed-off-by: Ankit Nautiyal
---
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
Signed-off-by: Ankit Nautiyal
---
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Minor changes:
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
The details are mentioned in DP to HDMI2.1 PCON Enum/Config
Hi
On Thu, 15 Oct 2020 17:00:17 +0800 Tian Tao wrote:
> Consistently Use the same style of variable type in hibmc_drm_drv.c and
> hibmc_drm_drv.h.
>
> Signed-off-by: Tian Tao
> Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
>
Hi Maxime
On Thu, 8 Oct 2020 at 13:44, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
Something appears to be slightly off with this one. Running the
monitor (Dell U2718Q 4k monitor) at 1080p60.
Use modetest to switch "max bpc"
Removing force probe protection from JSL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.
Signed-off-by: Kamati Srinivas
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed,
Hi Hariom,
With Sunil's help was able to see EHL achieving rc6 state.
Verified from sys entries, under no load to gpu rc6_residency_ms counter is
changing.
Also ran all the Rodrigo mention tests and I see them passing. But with
i915_selftest dmesg warnings are still seen.
Thanks,
Srinivas
Hi
On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen"
wrote:
> On Wed, 14 Oct 2020, Thomas Zimmermann wrote:
> > On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
> > wrote:
> >
> > > The high-res mode works, however, I wasn't expecting it to be this slow
> > > though as I can
On Tue, Oct 13, 2020 at 6:15 PM Rob Clark wrote:
>
> On Tue, Oct 13, 2020 at 4:08 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> > > On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> > > >
> > > > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob
On Wed, 14 Oct 2020 08:57:22 + Xu Wang wrote:
> Because clk_prepare_enable() and clk_disable_unprepare() already checked
> NULL clock parameter, so the additional checks are unnecessary, just
> remove them.
>
> Signed-off-by: Xu Wang
Reviewed-by: Thomas Zimmermann
> ---
>
On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
> Because clk_prepare_enable() and clk_disable_unprepare() already checked
> NULL clock parameter, so the additional checks are unnecessary, just
> remove them.
>
> Signed-off-by: Xu Wang
Reviewed-by: Thomas Zimmermann
> ---
>
Hi
On Wed, 14 Oct 2020 08:21:37 + Xu Wang wrote:
> Because clk_enable, clk_disable, clk_prepare, and clk_unprepare already
> checked NULL clock parameter, so the additional checks are unnecessary,
> just remove them.
All clk_*() functions seem to handle NULL pointers gracefully, so you can
On Thu, Oct 15, 2020 at 9:52 AM Daniel Vetter wrote:
>
> On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > > >
> > > > On Fri, Oct 09, 2020 at 04:24:45PM
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 9, 2020 at 2:31 PM
Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.
Synchronize the compositions such that second commit waits
until first commit flushes the composition.
This change
In functions vegam_is_dpm_running & vegam_populate_avfs_parameters,
maybe there is no need to conver bool condition to bool variable
or bool return value.
This change is to make the code a bit more readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 7
Hi Chun-Kuang,
On Wed, Oct 14, 2020 at 6:25 PM Fabien Parent wrote:
>
> Hi Chun-Kuang,
>
> On Wed, Oct 14, 2020 at 3:00 PM Chun-Kuang Hu wrote:
> >
> > Hi, Fabien:
> >
> > Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
> > >
> > > Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> > >
Because clk_enable, clk_disable, clk_prepare, and clk_unprepare already
checked NULL clock parameter, so the additional checks are unnecessary,
just remove them.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/au1100fb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
On 2020-10-14 18:59, Akhil P Oommen wrote:
On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
Hi,
On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen
wrote:
Add cooling-cells property and the cooling maps for the gpu tzones
to support
On 21/09/2020 14:20, Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
>
> Devfreq framework can change the device status in the
On Wed, 2020-10-14 at 12:44 +0800, CK Hu wrote:
> Hi, Chunfeng:
>
> On Tue, 2020-10-13 at 16:52 +0800, Chunfeng Yun wrote:
> > Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2: fix binding check warning of reg in example
> > ---
>
struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
and stored to a struct member of local variable. However, the array is not
freed when the local variable becomes invalid, and the reference is not
passed on, leading to a memory leak.
Fix this by freeing struct pw_rail_t
Connection state is not set correctly happen when either failure of link
train due to cable unplugged in the middle of aux channel reading or
cable plugged in while in suspended state. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.
Changes in V2:
Hi Alexandre,
On Wed, Sep 30, 2020 at 01:53:47PM +0200, Alexandre Bailon wrote:
> This adds a driver to communicate with the APU available
> in the mt8183. The driver is generic and could be used for other APU.
> It mostly provides a userspace interface to send messages and
> and share big
On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > > >
> > > > On Fri, Oct 09, 2020 at
Hi Chun-Kuang,
On Wed, Oct 14, 2020 at 3:00 PM Chun-Kuang Hu wrote:
>
> Hi, Fabien:
>
> Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
> >
> > Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> > MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
>
> I think you should
1 - 100 of 102 matches
Mail list logo
