On 2021-05-19 11:29 p.m., Felix Kuehling wrote:
Am 2021-05-19 um 11:20 p.m. schrieb Andrey Grodzovsky:
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
v5:
Move HW finilization into this callback to prevent MMIO accesses
post cpi remove.
v7:
Hi Dave,
Just one fixup to kerneldoc and two cleanups to drop redundant error
messages.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:
Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)
are
I think this works for KFD userptr BOs. But this problem is probably not
specific to KFD. It's only most obvious with KFD because we rely so
heavily for userptrs.
I don't really understand why we're messing with TTM_PAGE_FLAG_SG in
amdgpu_ttm_tt_populate and amdgpu_ttm_tt_unpopulate. And why are
Am 2021-05-19 um 11:20 p.m. schrieb Andrey Grodzovsky:
> Use it to call disply code dependent on device->drv_data
> before it's set to NULL on device unplug
>
> v5:
> Move HW finilization into this callback to prevent MMIO accesses
> post cpi remove.
>
> v7:
> Split kfd suspend from device exit to
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
v5:
Move HW finilization into this callback to prevent MMIO accesses
post cpi remove.
v7:
Split kfd suspend from device exit to expdite HW related
stuff to amdgpu_pci_remove
v8:
Squash previous KFD
We have met memory corruption due to unexcepted swapout/swapin.
swapout function create one swap storage which is filled with zero. And
set ttm->page_flags as TTM_PAGE_FLAG_SWAPPED. But because userptr BO ttm
has no backend page at that time, no real data is swapout to swap
storage.
swapin
Hi Dave, Daniel,
New stuff for 5.14, same as last week, but with fixed up fixes tag.
The following changes since commit af8352f1ff54c4fecf84e36315fd1928809a580b:
Merge tag 'drm-msm-next-2021-04-11' of https://gitlab.freedesktop.org/drm/msm
into drm-next (2021-04-13 23:35:54 +0200)
are
[AMD Official Use Only]
I am not sure if we can create a ttm_bo_type_sg bo for userptr. But I have
another idea now. we can use flag AMDGPU_AMDKFD_CREATE_USERPTR_BO to create the
userptr bo.
发件人: Kuehling, Felix
发送时间: 2021年5月19日 23:11
收件人: Christian
[AMD Official Use Only]
swapout function create one swap storage which is filled with zero. And set
ttm->page_flags as TTM_PAGE_FLAG_SWAPPED. Just because ttm has no backend page
this time, no real data is swapout to this swap storage.
swapin function is called during populate as
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:
Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.13-2021-05-19
for you to
Quoting Saravana Kannan (2021-05-19 18:27:50)
> On Wed, May 19, 2021 at 5:25 PM Stephen Boyd wrote:
> >
> > This series is from discussion we had on reordering the device lists for
> > drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
> > the aggregate device onto and then we
The device lists are poorly ordered when the component device code is
used. This is because component_master_add_with_match() returns 0
regardless of component devices calling component_add() first. It can
really only fail if an allocation fails, in which case everything is
going bad and we're out
Replace 'struct master' with 'struct aggregate_device' and then rename
'master' to 'adev' everywhere in the code. While we're here, put a
struct device inside the aggregate device so that we can register it
with a bus_type in the next patch.
The diff is large but that's because this is mostly a
Let's rename this struct member to 'parent' to better reflect the
reality that it's the parent device of this psuedo-device. In the next
patch we'll put a 'struct device' inside of this struct so moving this
away simplifies that patch by reducing the number of places that 'dev'
is modified.
Cc:
This allows aggregate driver writers to use the device passed to their
probe/remove/shutdown functions properly instead of treating it as an
opaque pointer.
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
We left this in place to ease the code diff, but now we can remove it
because the aggregate device parent pointer is the same.
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 37
The component driver only provides 'bind' and 'unbind' callbacks to tell
the host driver that it is time to assemble the aggregate driver now
that all the components have probed. The component driver model doesn't
attempt to resolve runtime PM or suspend/resume ordering, and explicitly
mentions
This argument isn't used. Drop it.
Cc: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/component.c
This series is from discussion we had on reordering the device lists for
drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
the aggregate device onto and then we probe the device once all the
components are probed and call component_add(). The probe/remove hooks
are where the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_mm.c
between commit:
293837b9ac8d ("Revert "i915: fix remap_io_sg to verify the pgprot"")
from Linus' tree and commit:
ec279384c6a0 ("drm/i915: Initialize err in remap_io_sg()")
from
[AMD Official Use Only]
Parsing over 550 processes for fdinfo is taking between 40-100ms single
threaded in a 2GHz skylake IBRS within a VM using simple string comparisons and
DIRent parsing. And that is pretty much the worst case scenario with some more
optimized implementations.
David
On Tue, May 18, 2021 at 03:33:45PM +0530, Krishna Manikandan wrote:
> Add bindings for Snapdragon DisplayPort controller driver.
>
> Signed-off-by: Chandan Uddaraju
> Signed-off-by: Vara Reddy
> Signed-off-by: Tanmay Shah
> Signed-off-by: Kuogee Hsieh
> Signed-off-by: Krishna Manikandan
>
>
On Tue, 18 May 2021 15:33:44 +0530, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI PHY.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
>- Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd)
>- Remove qcom,dsi-phy-regulator-ldo-mode
On Tue, 18 May 2021 15:33:42 +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsystem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for DPU device tree bindings.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> - Changed dpu to DPU
On Tue, May 18, 2021 at 03:33:43PM +0530, Krishna Manikandan wrote:
> Add YAML schema for the device tree bindings for DSI
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v1:
> - Separate dsi controller bindings to a separate patch (Stephen Boyd)
> - Merge
JFYI I haven't had a chance yet but I'm hoping to look at this this week
On Mon, 2021-05-17 at 13:08 -0700, Douglas Anderson wrote:
> The primary goal of this series is to try to properly fix EDID reading
> for eDP panels using the ti-sn65dsi86 bridge.
>
> Previously we had a patch that added
On Tue, 18 May 2021 09:51:31 +0200, Geert Uytterhoeven wrote:
> Convert the Solomon SSD1307 Framebuffer Device Tree binding
> documentation to json-schema.
>
> Fix the spelling of the "pwms" property.
> Document default values.
> Make properties with default values not required.
>
>
Hi,
On Wed, May 19, 2021 at 1:02 PM Rob Herring wrote:
>
> On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
> > We want to be able to list an eDP panel as a child of a ti-sn65dsi86
> > node to represent the fact that the panel is connected to the bridge's
> > DP AUX bus. Though
If 'platform_get_irq()' fails, it is spurious to call
'of_reserved_mem_device_release()' in the error handling path, because
'of_reserved_mem_device_init() has not been called yet.
Moreover, a previous 'kmb_initialize_clocks()' is unbalanced by a
corresponding 'kmb_display_clk_disable()' call,
Converts display/faraday,tve200.txt to yaml.
Signed-off-by: Corentin Labbe
---
Changes since v1:
- added two subsequent patchs fixing issue found when converting
- fixed all issues reported by Rob Herring
.../bindings/display/faraday,tve200.txt | 54 ---
dtb_check complains about #address-cells and #size-cells, so lets
remove them.
Signed-off-by: Corentin Labbe
---
arch/arm/boot/dts/gemini.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index fa708f5d0c72..34961e5bc7b2
The address and reg adds no value to the port node, remove them.
Signed-off-by: Corentin Labbe
---
arch/arm/boot/dts/gemini-dlink-dir-685.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
On Tue, 18 May 2021 09:15:53 +0200, Oleksij Rempel wrote:
> Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480)
> TFT LCD panel with TTL interface and a backlight unit.
>
> Signed-off-by: Oleksij Rempel
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml |
On Tue, 18 May 2021 00:43:36 +0200, Marek Vasut wrote:
> Add missing spaces to make the diagrams readable, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
>
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #29 from James Zhu (jam...@amd.com) ---
Hi Jeromec,I think debug turn-on changes a little bit timing. log without debug
info can't give me any help. The amdgpu_fence_info looks good for all cases.
this issue is possible device
On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
> We want to be able to list an eDP panel as a child of a ti-sn65dsi86
> node to represent the fact that the panel is connected to the bridge's
> DP AUX bus. Though the panel and the bridge chip are connected in
> several ways, the
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #28 from Jerome C (m...@jeromec.com) ---
Created attachment 296877
--> https://bugzilla.kernel.org/attachment.cgi?id=296877=edit
AMDGPU fence info
(In reply to James Zhu from comment #27)
> Hi Jeromec, thanks for your feedback, can
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Split the debugfs creation to make the code reusable for supporting
> different bounce buffer pools, e.g. restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct.
> The restricted DMA pool is preferred if available.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
Hi Dave and Daniel,
Here goes the first pull request targeting 5.14.
Main highlight goes to the ADL-P platform and display XeLPD IP
enabling patches. Also with a refactor on how we handle the graphics
and display IP versions.
drm-intel-next-2021-05-19-1:
Core Changes:
- drm: Rename
On May 19, 2021 12:16:15 Daniel Vetter wrote:
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote:
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
I honestly did not find that much ... what did you uncover?
When I was digging through this earlier
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new wrapper __dma_direct_free_pages() that will be useful later
> for swiotlb_free().
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Signed-off-by: Claire Chang
> ---
> include/linux/device.h | 4 +++
> include/linux/swiotlb.h | 3 +-
> kernel/dma/swiotlb.c| 76
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
>
> Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
>
> Signed-off-by: Claire Chang
> ---
>
From: Rob Clark
Note, at this point I haven't given a lot of consideration into how much
we should boost, and for how long. And perhaps we should only boost at
less than 50% utilization? At this point, this is only an example of
dma_fence_boost() implementation.
Signed-off-by: Rob Clark
---
From: Rob Clark
In some cases, like double-buffered rendering, missing vblanks can
trick the GPU into running at a lower frequence, when really we
want to be running at a higher frequency to not miss the vblanks
in the first place.
This is partially inspired by a trick i915 does, but
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 560aaecba31b..fe10fc2e7f86 100644
---
From: Rob Clark
Add a way to hint to the fence signaler that a fence waiter has missed a
deadline waiting on the fence.
In some cases, missing a vblank can result in lower gpu utilization,
when really we want to go in the opposite direction and boost gpu freq.
The boost callback gives some
On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin
wrote:
>
>
> On 18/05/2021 10:40, Tvrtko Ursulin wrote:
> >
> > On 18/05/2021 10:16, Daniel Stone wrote:
> >> Hi,
> >>
> >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
> >> wrote:
> >>> I was just wondering if stat(2) and a chrdev major check would
> Sorry for the noise.
Not at all, it is good that more people understand things!
Jason
On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > Add entry fpr i915 new parallel submission uAPI plan.
> >
> > v2:
> > (Daniel Vetter):
> > - Expand logical order explaination
> > - Add dummy header
> > -
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote:
>
> Once we no longer rely on error propagation, I think there's a lot we
> can rip out.
I honestly did not find that much ... what did you uncover?
-Daniel
>
> --Jason
>
> On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote:
> >
> > From:
On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:
> Oh, yeah we call that gang submit on the AMD side.
>
> Had already some internal discussions how to implement this, but so far
> couldn't figure out how to cleanly introduce that into the DRM scheduler.
>
> Can you briefly
On Wed, May 19, 2021 at 9:57 AM Kai-Heng Feng
wrote:
>
> Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
> the first device is an integrated GPU. However, on AMD platforms an
> integrated GPU can have higher PCI device number than a discrete GPU.
>
> Integrated GPU on ACPI
Pushed out to drm-misc-next. Also fixed up Michel's name.
Alex
On Wed, May 19, 2021 at 11:56 AM Randy Dunlap wrote:
>
> On 5/19/21 1:15 AM, Mauro Carvalho Chehab wrote:
> > There are some places at drm that ended receiving a
> > REPLACEMENT CHARACTER U+fffd ('�'), probably because of
> > some
After calling clk_prepare_enable(), clk_disable_unprepare() need
be called when calling regmap_write() failed.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Reported-by: Hulk Robot
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 1 +
1
Signed-off-by: songqiang
---
drivers/video/fbdev/core/fbmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 072780b0e570..6036ab849475 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++
Another Samsung OLED panel needs DPCD to get control of backlight.
Kernel 5.12+ support the backlight via:
commit: <4a8d79901d5b> ("drm/i915/dp: Enable Intel's HDR backlight interface
(only SDR for now)")
Only make backlight work on lower versions of kernel.
Closes:
Maintainer for hyperv synthetic video device.
Signed-off-by: Deepak Rawat
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 41f2b2b85b6d..dbe4ed540e11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6084,6 +6084,14 @@ T: git
Virtual device inform if screen update is needed or not with
SYNTHVID_FEATURE_CHANGE message. Handle this message to set dirt_needed
flag.
Suggested-by: Dexuan Cui
Signed-off-by: Deepak Rawat
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/hyperv/hyperv_drm.h | 1 +
DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.
v2:
- Add support for gen2 VM
- Fixed review comments
v3:
- Split into multiple files as suggested by Thomas Zimmermann
- Fixed hibernation issue as
On Wed, 2021-05-19 at 13:51 +1000, Sam McNally wrote:
> On Wed, 19 May 2021 at 08:01, Lyude Paul wrote:
> >
> > Looks like these tests might still need to be fixed up a bit:
> >
> > [ 34.785042] (null): [drm:drm_dp_sideband_parse_req [drm_kms_helper]]
> > connection status reply parse length
Seems reasonable to me:
Reviewed-by: Lyude Paul
On Wed, 2021-05-19 at 17:53 +0800, Aaron Ma wrote:
> Another Samsung OLED panel needs DPCD to get control of backlight.
> Kernel 5.12+ support the backlight via:
> commit: <4a8d79901d5b> ("drm/i915/dp: Enable Intel's HDR backlight interface
>
On 18/05/2021 10:40, Tvrtko Ursulin wrote:
On 18/05/2021 10:16, Daniel Stone wrote:
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
I was just wondering if stat(2) and a chrdev major check would be a
solid criteria to more efficiently (compared to parsing the text
content) detect
On 5/19/21 1:15 AM, Mauro Carvalho Chehab wrote:
> There are some places at drm that ended receiving a
> REPLACEMENT CHARACTER U+fffd ('�'), probably because of
> some bad charset conversion.
>
> Fix them by using what it seems to be the proper
> character.
>
> Signed-off-by: Mauro
On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
>>
>> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
>>> On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
On Tue, May 18, 2021 at 7:40 PM Christian König
wrote:
>
>
On Wed, May 19, 2021 at 01:03:00PM +0200, Juerg Haefliger wrote:
> Remove leading whitespaces, replace multi spaces with tabs, and fix help
> text indentation.
>
> Signed-off-by: Juerg Haefliger
Reviewed-by: Daniel Thompson
Daniel.
> ---
> drivers/video/backlight/Kconfig | 22
On Wed, May 19, 2021 at 6:43 AM Christian König
wrote:
>
> Am 19.05.21 um 00:06 schrieb Jason Ekstrand:
> > [SNIP]
> >>> E.g. we can't add a fence which doesn't wait for the exclusive one as
> >>> shared.
> >> Ok I think that's a real problem, and guess it's also related to all
> >> the ttm
On 19/05/2021 12:10, Daniel Vetter wrote:
On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
Add entry fpr i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
-
On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
>
> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> > On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
> >>
> >> On Tue, May 18, 2021 at 7:40 PM Christian König
> >> wrote:
> >>>
> >>> Am 18.05.21 um 18:48 schrieb Daniel Vetter:
>
Looks like we're creating the userptr BO as ttm_bo_type_device. I guess
we should be using ttm_bo_type_sg? BTW, amdgpu_gem_userptr_ioctl also
uses ttm_bo_type_device.
Regards,
Felix
Am 2021-05-19 um 6:01 a.m. schrieb Christian König:
> I'm scratching my head how that is even possible.
>
> See
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
--Jason
On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote:
>
> From: Jason Ekstrand
>
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a
On Wed, May 19, 2021 at 2:43 AM Daniel Vetter wrote:
>
> On gen9 for blt cmd parser we relied on the magic fence error
> propagation which:
> - doesn't work on gen7, because there's no scheduler with ringbuffers
> there yet
> - fence error propagation can be weaponized to attack other things,
On Tue 18 May 22:41 CDT 2021, abhin...@codeaurora.org wrote:
> Hi Bjorn
>
> I had a quick glance on the series and before getting to other things wanted
> to know how you are initializing two different connectors for
> DP & EDP resp.
>
> The connector type for DP should be
On Mon, 17 May 2021, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds support for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
> Reviewed-by: Daniel Thompson
> ---
> since v7
> - Fix typo 'common' to 'commonly' in Kconfig description.
> ---
> drivers/video/backlight/Kconfig
On Mon, 17 May 2021, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831.
>
> Signed-off-by: ChiYuan Huang
> Reviewed-by: Rob Herring
> ---
> .../devicetree/bindings/mfd/richtek,rt4831.yaml| 90
> ++
> 1 file changed, 90
On Mon, 17 May 2021, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
> Reviewed-by: Daniel Thompson
> ---
> since v7
> - Add allOf property refer to common.yaml.
> - Remove default-brightness/max-brightness
On Mon, 17 May 2021, cy_huang wrote:
> From: ChiYuan Huang
>
> This adds support Richtek RT4831 core. It includes four channel WLED driver
> and Display Bias Voltage outputs.
>
> Signed-off-by: ChiYuan Huang
> ---
> - Send the patch series for the wrong mail subject.
>
> The RT4831 regulator
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #2 from Tomas Gayoso (tgay...@gmail.com) ---
Created attachment 296871
--> https://bugzilla.kernel.org/attachment.cgi?id=296871=edit
kernel configuration
--
You may reply to this email to add a comment.
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #1 from Tomas Gayoso (tgay...@gmail.com) ---
Created attachment 296869
--> https://bugzilla.kernel.org/attachment.cgi?id=296869=edit
lsmod output
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=213145
Bug ID: 213145
Summary: AMDGPU resets, timesout and crashes after "*ERROR*
Waiting for fences timed out!"
Product: Drivers
Version: 2.5
Kernel Version: 5.10.37 and 5.10.38
On Mon, 10 May 2021, Andy Shevchenko wrote:
> device_for_each_child_node() bumps a reference counting of a returned
> variable.
> We have to balance it whenever we return to the caller.
>
> Fixes: 8fbce8efe15cd ("backlight: lm3630a: Add firmware node support")
> Cc: Brian Masney
> Cc: Dan
Am 19.05.21 um 16:14 schrieb Andrey Grodzovsky:
Wait for all dependencies of a job to complete before
killing it to avoid data corruptions.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 5 +
1 file changed, 5
Wait for all dependencies of a job to complete before
killing it to avoid data corruptions.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_entity.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
On Wed, May 19, 2021 at 10:28:42AM -0300, Jason Gunthorpe wrote:
> On Tue, May 18, 2021 at 07:45:05PM -0400, Peter Xu wrote:
> > On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote:
> > > Logically during fork all these device exclusive pages should be
> > > reverted back to their CPU
On Wed, May 19, 2021 at 11:11:55PM +1000, Alistair Popple wrote:
> On Wednesday, 19 May 2021 10:15:41 PM AEST Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> > On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote:
> > > Failing fork() because we
Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
the first device is an integrated GPU. However, on AMD platforms an
integrated GPU can have higher PCI device number than a discrete GPU.
Integrated GPU on ACPI platform generally has _DOD and _DOS method, so
use that as
śr., 19 maj 2021 o 01:41 Matthew Brost napisał(a):
>
> Add entry fpr i915 new parallel submission uAPI plan.
s/fpr/for/
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure parallel submission per slot
On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä wrote:
>
> > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
> > > Hello,
> > >
> > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm
>
Hi,
On 5/3/21 5:46 PM, Hans de Goede wrote:
> The Type-C connector on these devices is connected to DP-2 not DP-1,
> so the reference must be to the DD04 child-node of the GPU, rather
> then the DD02 child-node.
>
> Signed-off-by: Hans de Goede
Since this is pretty much independent from the
On 5/6/21 6:10 AM, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 18:36:51 -0300
> Leandro Ribeiro wrote:
>
>> Add a small description and document struct fields of
>> drm_mode_get_plane.
>>
>> Signed-off-by: Leandro Ribeiro
>
> Hi,
>
> thanks a lot for revising these.
>
>> ---
>>
On Tue, May 18, 2021 at 07:45:05PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote:
> > Logically during fork all these device exclusive pages should be
> > reverted back to their CPU pages, write protected and the CPU page PTE
> > copied to the fork.
> >
[AMD Public Use]
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, May 19, 2021 4:50 AM
> To: dim-to...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> jani.nik...@intel.com; Deucher, Alexander
> ; Koenig, Christian
> ; Pan; Pan,
On Wednesday, 19 May 2021 10:15:41 PM AEST Peter Xu wrote:
> External email: Use caution opening links or attachments
>
> On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote:
> > Failing fork() because we couldn't take a lock doesn't seem like the right
> > approach though, especially
On Wednesday, 19 May 2021 10:21:08 PM AEST Peter Xu wrote:
> External email: Use caution opening links or attachments
>
> On Wed, May 19, 2021 at 09:35:10PM +1000, Alistair Popple wrote:
> > I think the approach you are describing is similar to what
> > migrate_vma_collect()/migrate_vma_unamp()
On Wednesday, 19 May 2021 10:24:27 PM AEST Peter Xu wrote:
> External email: Use caution opening links or attachments
>
> On Wed, May 19, 2021 at 08:49:01PM +1000, Alistair Popple wrote:
> > On Wednesday, 19 May 2021 7:16:38 AM AEST Peter Xu wrote:
> > > External email: Use caution opening links
On Wednesday, 19 May 2021 6:04:51 AM AEST Liam Howlett wrote:
> External email: Use caution opening links or attachments
>
> * Alistair Popple [210407 04:43]:
> > The behaviour of try_to_unmap_one() is difficult to follow because it
> > performs different operations based on a fairly large set
1 - 100 of 149 matches
Mail list logo
