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
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=edit
dmesg output
And again.
--
You are receiving this mail because:
You are watching the assignee of the
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
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
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
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
> > >
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:
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
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
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
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
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
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.
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:
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:
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
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
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 ;
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
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
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
[+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
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
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
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
>-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 ;
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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
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
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
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
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
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 |
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
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
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
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
---
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
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
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.
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
---
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
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
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
Add Adreno 640 and 650 GPU info to the gpulist.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +
3 files changed, 35
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam
From: Jason Gunthorpe
There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.
Currently all drivers provide a feature kconfig that will disable use of
DEVICE_PRIVATE in that
Sure, this seems to be a lot more professional than my previous modification.
My original intention is to make the code easier to read, and I learned a lot
from
submitting these patches. Thank you very much for all your guidance!
Regards,
Bernard
发件人：Felix Kuehling
发送日期：2020-04-22 10:27:16
On Tue, 21 Apr 2020, Dan Carpenter wrote:
> Hi Kernel Janitors,
>
> 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
Update the gmu_pdc registers for A640 and A650.
Some of the RSCC registers on A650 are in a separate region.
Note this also changes the address of these registers:
RSCC_TCS1_DRV0_STATUS
RSCC_TCS2_DRV0_STATUS
RSCC_TCS3_DRV0_STATUS
Based on the values in msm-4.14 and msm-4.19 kernels.
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19
Add HFI v2 code paths required by Adreno 640 and 650 GPUs.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 66 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 117
On 4/21/20 12:30 PM, Jordan Crouse wrote:
On Mon, Apr 20, 2020 at 10:03:08AM -0400, Jonathan Marek wrote:
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 68 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c |
This function allows pinning iova to a specific page range (for a6xx GMU).
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.h | 6 +-
drivers/gpu/drm/msm/msm_gem.c | 28 +---
drivers/gpu/drm/msm/msm_gem_vma.c | 6 --
3 files changed, 30
Fixes coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity
for kmemdup
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity
for kmemdup
Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure
boot"")
Adreno 640 and 650 GPUs need some registers set differently.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 14 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 ++-
2 files changed, 61 insertions(+), 9 deletions(-)
diff --git
> There is no need to if check again,
Thanks for this information.
* Should the function name be mentioned in this commit message?
* Would you like to adjust the patch subject another bit?
> maybe we could merge into the above else branch.
I suggest to reconsider this wording.
Are you still
From: Michał Winiarski
Control nodes are no longer with us.
While we still need to preserve render nodes numbering, there's no need
to reserve the range formerly used for control. Let's repurpose it to be
used by primary and remove control remains from the code entirely.
References:
Newer GPUs have different GMU firmware path.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 135 +++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 11 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 6 +
3 files changed, 136 insertions(+), 16
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_svm.c | 1 -
> But i have to say there are so many code not follow the kernel code-style in
> amdgpu module.
> And also the ./scripts/checkpatch.pl did not throw any warning or error.
Will such information become more interesting for further evolution
in the affected software areas?
Regards,
Markus
This flag sets IOMMU_PRIV, which is required for some a6xx GMU objects.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 3 +++
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
* Tony Lindgren [200421 10:39]:
> See for example the standard 8250 uart for am335x with:
>
> $ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
>
> The 8250 device configuration is described in the standard 8250
> dts binding, and the am335x module in the ti-sysc binding.
> The are
发件人："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.org,opensource.ker...@vivo.com
It forgot to call bochs_hw_fini() to release related resources when
bochs_pci_probe() fail. eg: io virtual address get by ioremap().
Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.")
CC: Andy Shevchenko
Signed-off-by: Dejin Zheng
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 +
* H. Nikolaus Schaller [200421 17:31]:
> > Am 21.04.2020 um 16:15 schrieb Tony Lindgren :
> > Note that on omaps there are actually SoC module specific registers.
>
> Ah, I see. This is of course a difference that the TI glue logic has
> its own registers in the same address range as the sgx and
From: Jason Gunthorpe
Since amdgpu does not use the snapshot mode of hmm_range_fault() a
successful return already proves that all entries in the pfns are
HMM_PFN_VALID, there is no need to check the return result of
hmm_device_entry_to_page().
Signed-off-by: Jason Gunthorpe
---
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 display driver (v2)")
Signed-off-by: Randy Dunlap
Cc: Harry
[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 change that came in
after I rebased to tip. I wasn't sure earlier about
On Tue, Apr 21, 2020 at 09:51:37AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 19:15:14)
> > On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
> > > So it seems that the patch got pulled into v5.6 and has been backported
> > > to v5.5 but not v5.4.
> >
> >
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault() for anything other than error.
More
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()
All the drivers are adjusted to process in
This is required for a650 to work.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 4
3 files changed, 20 insertions(+)
diff --git
>> But i have to say there are so many code not follow the kernel code-style in
>> amdgpu module.
>> And also the ./scripts/checkpatch.pl did not throw any warning or error.
>
> That is unfortunately true, yes. But we try to push new code through the
> usual code review and improve things as we
>>> There is no need to if check again, maybe we could merge
>>> into the above else branch.
I find also this commit message still improvable (besides the mentioned
implementation details around coding style concerns).
How will corresponding review comments be taken better into account?
Regards,
> Am 21.04.2020 um 16:15 schrieb Tony Lindgren :
>
> * Maxime Ripard [200421 11:22]:
>> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
>>> I had a look on genpd and I'm not really sure if that fits.
>>>
>>> It is basically some bit that verify that the clocks should be
1 - 100 of 126 matches
Mail list logo
