Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sparc/master]
[also build test ERROR on stm32/stm32-next linus/master v5.7-rc2 next-20200422]
[cannot apply to sparc-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
Hi Joe.
> >
> > > I would also be great if you or someone else could:
> > > - teach get_maintainers about .yaml file listed maintainers
> >
> > It already does to some extent. IIRC, there's a mode to extract email
> > addresses from files.
>
> --file-emails
>
> > I was hoping that the MAINTAIN
https://bugzilla.kernel.org/show_bug.cgi?id=206987
Cyrax (ev...@hotmail.com) changed:
What|Removed |Added
Kernel Version|5.6.4 |5.6.5
--
You are receiving t
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #9 from Cyrax (ev...@hotmail.com) ---
Created attachment 288679
--> https://bugzilla.kernel.org/attachment.cgi?id=288679&action=edit
dmesg output
And again.
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #3 from Duncan (1i5t5.dun...@cox.net) ---
CCed the two from MAINTAINERS bugzi would let me add. It wouldn't let me add
amd-gfx@ or david1.zhou@, and Alex's gmail address according to bugzi isn't
what's in MAINTAINERS.
--
You are rec
Hi all,
On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen wrote:
>
> On 21/04/2020 04:52, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc
> > tree with the drm-misc-fixes tree
> >
> >drivers/gpu/drm/tidss/tidss_encoder.c
> >
> >
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
between commit:
09b974e8983a ("drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback")
from the drm tree and commit:
c33f212c0c92 ("drm/amdgpu/displa
On Wed, 2020-04-22 at 15:02 -0500, Rob Herring wrote:
> On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg wrote:
> > Hi Adrian
> >
> > On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> > > Hello,
> > >
> > > I got confused while doing the txt -> yaml conversion at [1] and it's
> > > s
Hi Dave, Daniel,
Fixes for 5.7.
The following changes since commit 4da858c086433cd012c0bb16b5921f6fafe3f803:
Merge branch 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes
(2020-04-16 15:40:02 +1000)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/li
With the addition of device memory (lmem) for the i915 driver, the
dma-buf interface needs a little polishing.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The i915 GEM dmabuf mmap interface assumes all BOs are SHMEM. When
the BO is backed by LMEM, this assumption doesn't work so well.
Introduce the dmabuf mmap interface to LMEM by adding the appropriate
VMA faulting mechanism.
Update dmabuf to allow for LMEM backed BOs by leveraging the gem_mman
pa
LMEM backed buffer objects do not have struct page information, and
are not WB compatible. Currently the cpu access and vmap interfaces
only support struct page backed objects.
Update the dma-buf interfaces begin/end_cpu_access and vmap/vunmap
to be LMEM aware.
Signed-off-by: Michael J. Ruhl
--
Update open coded for loop to use the standard scatterlist
for_each_sg API.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/ge
LMEM backed buffer objects do not have struct page information.
Instead the dma_address of the struct sg is used to store the
LMEM address information (relative to the device, this is not
the CPU physical address).
The dmabuf map handler requires pages to do a dma_map_xx.
Add new mapping/unmappin
Some minor cleanup of some variables to make upcoming patches
a little easier.
Normalize struct sg_table to sgt.
Normalize struct dma_buf_attachment to attach.
checkpatch issues sizeof(), !NULL updates.
Signed-off-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 +
On Sat, Apr 18, 2020 at 1:11 PM Rafael J. Wysocki wrote:
>
> From: "Rafael J. Wysocki"
>
> Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
> matches its purpose more closely.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> Acked-by: Bjorn Helgaas # for PCI parts
On Wed, Apr 22, 2020 at 12:59 PM Adrian Ratiu
wrote:
>
> This converts the Synopsis MIPI DSI binding documentation to yaml and
> should be quite straightforward. I've added a missing ref clk and also
> added Philippe as maintainer b/c he's the original txt author following
> the algorithm provided
On Tue, Apr 21, 2020 at 10:34 AM Christian König
wrote:
>
> Am 21.04.20 um 16:33 schrieb Christian König:
> > Am 20.04.20 um 03:50 schrieb Randy Dunlap:
> >> Fix a kernel-doc warning of missing struct field desription:
> >>
> >> ../drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:92: warning: Function
> >>
On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg wrote:
>
> Hi Adrian
>
> On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> > Hello,
> >
> > I got confused while doing the txt -> yaml conversion at [1] and it's still
> > not clear to me who should be added in the "maintainers" field. C
On Wed, Apr 22, 2020 at 10:00 AM Harry Wentland wrote:
>
> On 2020-04-21 7:34 p.m., Randy Dunlap wrote:
> > From: Randy Dunlap
> >
> > Fix help text: indent one tab + 2 spaces; end a sentence with a
> > period; and collapse short lines of text to one line.
> >
> > Fixes: 23c61b4599c4 ("drm/amd: F
On Tue, 21 Apr 2020 19:16:07 +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host controller
> present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
>
> Cc: Rob Herring
> Cc: Neil Armstrong
> Cc: Fabio Estevam
> Cc: Laurent Pinchart
> Cc: devicet...@
On Tue, 21 Apr 2020 10:25:08 +0530, Harigovindan P wrote:
> Documenting compatible string vendor "visionox" in vendor-prefix yaml file.
>
> Signed-off-by: Harigovindan P
> ---
> Changes in v11:
> - Added visionox compatible string in vendor-prefixes.yaml
> - Added as a part of checkpa
On 4/21/20 5:21 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
The API is a bit complicated for the uses we actually have, and
disucssions for simplifying have come up a number of times.
This small series removes the customizable pfn format and simplifies the
return code of hmm_range_fault
Am 22.04.20 um 17:51 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Bernard Zhao
Sent: Tuesday, April 21, 2020 7:17 AM
To: Alex Deucher ; Christian König
; David (ChunMing) Zhou
; David Airlie ; Daniel Vetter
; Tom St Denis ; Ori Messinger
; Sam Ravnborg ; Berna
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Thank you for the patch.
On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
This provides an example DT binding for the MIPI DSI host
controller present on the i.MX6 SoC based on Synopsis
DesignWare v1.01 IP. Cc: Rob Herr
This converts the Synopsis MIPI DSI binding documentation to yaml and
should be quite straightforward. I've added a missing ref clk and also
added Philippe as maintainer b/c he's the original txt author following
the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org.
Cc: Rob Herr
This converts the Synopsis MIPI DSI binding documentation to yaml and
should be quite straightforward. I've added a missing ref clk and also
added Philippe as maintainer b/c he's the original txt author following
the algorithm provided in Message-ID 20200420175909.ga5...@ravnborg.org.
Cc: Rob Herr
[+Philip Yang]
Am 2020-04-21 um 8:21 p.m. schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> Presumably the intent here was that hmm_range_fault() could put the data
> into some HW specific format and thus avoid some work. However, nothing
> actually does that, and it isn't clear how anything a
Hello,
On Tue, Apr 21, 2020 at 02:34:59PM +0200, Daniel Vetter wrote:
> > > Also, of course, let me know if yu're not happy with the
> > > __kthread_queue_work() changes/kthread_worker usage in drm_vblank_work as
> > > well
> >
> > Just glanced over it and I still wonder whether it needs to be t
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote:
On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart
> wrote:
>> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu
Hi,
On Wed, Apr 22, 2020 at 3:23 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-04-20 22:06:17)
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> > be used as GPIOs in a system. Each pin can be configured as input,
> > output, or a special function for the b
>-Original Message-
>From: dri-devel On Behalf Of
>Bernard Zhao
>Sent: Tuesday, April 21, 2020 7:17 AM
>To: Alex Deucher ; Christian König
>; David (ChunMing) Zhou
>; David Airlie ; Daniel Vetter
>; Tom St Denis ; Ori Messinger
>; Sam Ravnborg ; Bernard
>Zhao ; amd-...@lists.freedesktop.or
Hi Adrian,
On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote:
> On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> > On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart wrote:
> >> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> >>> This provides an example DT bindi
On Wed, Apr 22, 2020 at 12:15 AM Thierry Reding
wrote:
> On Wed, Apr 15, 2020 at 02:24:27PM +0200, Linus Walleij wrote:
> > The Tegra DRM drivers includes the legacy GPIO headers
> > and but what it really
> > uses is since only gpio_desc
> > structs are ever referenced.
> >
> > Include the rig
Hi Adrian,
On Wed, Apr 22, 2020 at 12:33:10PM +0300, Adrian Ratiu wrote:
> On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> > On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
> >> This adds support for the Synopsis DesignWare MIPI DSI v1.01
> >> host controller which is embedded in i
Most drivers that use VRAM helpers have only a few MiB of framebuffer
memory available. To reduce fragmentation, new BOs are now put into
system memory by default. Only pin operations are allowed to move BOs
into VRAM.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c |
With limited VRAM available, fragmentation can lead to OOM errors.
Alternating between bottom-up and top-down placement keeps BOs near the
ends of the VRAM and the available pages consecutively near the middle.
A real-world example with 16 MiB of VRAM is shown below.
> cat /sys/kernel/debug/dri
VRAM memory can easily fragment, which leads to OOM errors on devices
with little VRAM available (i.e., all of them). This patchset addresses
the problem by placing BOs near the bottom and top ends of the VRAM and
keeping available areas near the middle.
Thomas Zimmermann (2):
drm/vram-helper: D
On Wed, Apr 22, 2020 at 4:52 PM Dejin Zheng wrote:
>
> On Tue, Apr 21, 2020 at 08:24:24PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng wrote:
> > >
> > > It forgot to call bochs_hw_fini() to release related resources when
> > > bochs_pci_probe() fail. eg: io virtu
On 2020-04-21 7:34 p.m., Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix help text: indent one tab + 2 spaces; end a sentence with a
> period; and collapse short lines of text to one line.
>
> Fixes: 23c61b4599c4 ("drm/amd: Fix Kconfig indentation")
> Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc di
On Mon, Apr 20, 2020 at 06:04:29PM +0300, Hadar Gat wrote:
> Both of_platform.h and of_device.h were included each other.
> In of_device.h, removed unneeded #include to of_platform.h
> and added include to of_platform.h in the files that needs it.
>
> Signed-off-by: Hadar Gat
> Reported-by: kbuil
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #10 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Looks like I need to recompile with CONFIG_PM_ADVANCED_DEBUG, I suspect.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #9 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Well, it'll take time to patch and recompile the kernel, but in the meantime
here is all the contents of the power directories:
AMD Radeon GPU
cat /sys/bus/pci/devices/\:01\:00.0
From: Binu R S
a) Adds new format modifiers for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Generated from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h | 54 ++
Explicitly check if the imported buffer has been mapped as contiguous in
the DMA address space, what is required by all Exynos DRM CRTC drivers.
While touching this, set buffer flags depending on the availability of
the IOMMU.
Signed-off-by: Marek Szyprowski
---
v2:
- reworked a check for sgt->ne
From: Aditya Swarup
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs,
From: Manasi Navare
From: Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v4:
* Rebase (Bhanu)
* Remove "Vrr_capa
AFBC has a mode that allows use of AFBC with an uncompressed buffer,
we add a new modifier to support this mode.
Signed-off-by: Ben Davis
---
include/uapi/drm/drm_fourcc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
inde
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts. The format is similar to P010 with 4:2:0
sub-sampling but has no padding between components. Instead, luminance
and chrominance samples are grouped into 4s so that each group is packed
into an integer num
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in de
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in de
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart
wrote:
On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host
> controller present on the i.MX
From: Binu R S
a) Adds new format modifiers for Format modifier for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Taken from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h | 5
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
This adds support for the Synopsis DesignWare MIPI DSI v1.01
host controller which is embedded in i.MX 6 SoCs. Based on
following patches, but updated/exten
On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
>
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new
On Wed, Apr 22, 2020 at 09:51:14AM +0300, Tomi Valkeinen wrote:
> The code that maps the LED default brightness to backlight levels has
> two issues: 1) if the default brightness is the first backlight level
> (usually 0), the code fails to find it, and 2) when the code fails to
> find a backlight
Hi Inki,
On 22.04.2020 06:36, Inki Dae wrote:
> 20. 4. 22. 오후 12:37에 Inki Dae 이(가) 쓴 글:
>> 20. 4. 21. 오후 5:09에 Marek Szyprowski 이(가) 쓴 글:
>>> On 21.04.2020 09:38, Inki Dae wrote:
20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
> Explicitly check if the imported buffer has been mapped as co
On 22/04/2020 10:19, Jason Yan wrote:
Fix the following coccicheck warning:
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING:
Comparison to bool
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: Jason Yan
---
driv
Am 22.04.20 um 02:56 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 22:53:47
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel
On 4/21/20 14:51, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
>
On 4/21/20 13:45, Dan Carpenter wrote:
> Hi Kernel Janitors,
Hi
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the followin
The code that maps the LED default brightness to backlight levels has
two issues: 1) if the default brightness is the first backlight level
(usually 0), the code fails to find it, and 2) when the code fails to
find a backlight level, it ends up using max_brightness + 1 as the
default brightness.
F
led_bl does not lock 'led_access' when calling led_sysfs_disable and
led_sysfs_enable, causing the below WARN. Add the locking.
WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
led_sysfs_disable+0x4c/0x5c
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/back
There's no need to set 'levels' to NULL.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366..c4
Hi,
Changes in v3:
- "backlight: led_bl: fix led -> backlight brightness mapping": Simplify
the for loop as suggested by Daniel
Changes in v2:
- Drop "backlight: led_bl: rewrite led_bl_parse_levels()". The patch
changed the behavior, and the new behavior may not be wanted. So lets
drop th
Fix issues reported by checkpatch. No functional changes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight
67 matches
Mail list logo
