Hi!
This series is truncated .. I only got first patches. Similary, 5.10
series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add
checking to s5p_mfc_probe... is last one I got.
I got all the patches before that, so I believe it is not problem on
my side, but I'd not mind someone con
Hi Pavel,
Am 09.11.21 um 08:54 schrieb Pavel Machek:
Hi!
This series is truncated .. I only got first patches. Similary, 5.10
series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add
checking to s5p_mfc_probe... is last one I got.
I got all the patches before that, so I believe it
Hi,
21. 11. 2. 오전 11:20에 Maíra Canal 이(가) 쓴 글:
> Considering the current transition of the GPIO subsystem, remove all
> dependencies of the legacy GPIO interface (linux/gpio.h and linux
> /of_gpio.h) and replace it with the descriptor-based GPIO approach.
>
Applied.
Thanks,
Inki Dae
> Signed-o
There are a few details specific to the GETFB2 IOCTL.
It's not immediately clear how user-space should check for the
number of planes. Suggest using the pitches field.
The modifier array is filled with zeroes, ie. DRM_FORMAT_MOD_LINEAR.
So explicitly tell user-space to not look at it unless the f
Hi
Am 15.10.21 um 01:28 schrieb bugzilla-dae...@bugzilla.kernel.org:
https://bugzilla.kernel.org/show_bug.cgi?id=214725
Bug ID: 214725
Summary: simpledrm and i915 both active after boot
Product: Drivers
Version: 2.5
Kernel Version: 5.14.11
Hi
Am 08.11.21 um 22:01 schrieb Noralf Trønnes:
Den 01.11.2021 15.15, skrev Thomas Zimmermann:
Add constants for the maximum size of the shadow-plane surface
size. Useful for shadow planes with virtual screen sizes. The
current sizes are 4096 scanlines with 4096 pixels each. This
seems reason
On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote:
> I stumbled across this thread when I ran into the same issue, while
> working out how to move drm/msm to use scheduler's retire +
> timeout/recovery (and get rid of our own mirror list of in-flight
> jobs). We already have hw error detec
On Mon, Nov 08, 2021 at 04:21:04PM -0800, James Jones wrote:
> On 9/8/21 2:44 AM, Simon Ser wrote:
> > > stride
> > >
> >
> > I think what's clear is:
> >
> > - Per-plane property
> > - In bytes
> > - Offset between two consecutive rows
> >
> > How that applies to weird YUV formats is the
On Mon, Nov 08, 2021 at 04:18:22PM -0800, James Jones wrote:
> On 9/6/21 5:28 AM, Simon Ser wrote:
> > > Since there's a lot of confusion around this, document both the rules
> > > and the best practice around negotiating, allocating, importing, and
> > > using buffers when crossing context/process
On Tue, Nov 09, 2021 at 09:40:08AM +0200, Jani Nikula wrote:
> On Sat, 06 Nov 2021, Stephen Rothwell wrote:
> > Hi Jani,
> >
> > On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula
> > wrote:
> >>
> >> I probably should have pushed c4f08d7246a5 ("drm/locking: fix
> >> __stack_depot_* name conflict")
On Mon, Nov 08, 2021 at 09:16:07PM +0300, Dmitry Osipenko wrote:
> 08.11.2021 18:17, Daniel Vetter пишет:
> > On Mon, Nov 08, 2021 at 02:08:21AM +0300, Dmitry Osipenko wrote:
> >> Use drm_dp_aux_register_ddc/chardev() helpers that allow to register I2C
> >> adapter separately from the character dev
On Tuesday, November 9th, 2021 at 10:13, Daniel Vetter wrote:
> On Mon, Nov 08, 2021 at 04:18:22PM -0800, James Jones wrote:
> > On 9/6/21 5:28 AM, Simon Ser wrote:
> > > > Since there's a lot of confusion around this, document both the rules
> > > > and the best practice around negotiating, allo
Hi Thomas and Daniel,
21. 11. 9. 오전 12:29에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Nov 08, 2021 at 11:28:44AM +0100, Thomas Zimmermann wrote:
>> Moving the driver-specific mmap code into a GEM object function allows
>> for using DRM helpers for various mmap callbacks.
>>
>> The respective exynos functio
On Tue, Nov 09, 2021 at 08:56:10AM +, Simon Ser wrote:
> There are a few details specific to the GETFB2 IOCTL.
>
> It's not immediately clear how user-space should check for the
> number of planes. Suggest using the pitches field.
>
> The modifier array is filled with zeroes, ie. DRM_FORMAT_M
On Tuesday, November 9th, 2021 at 10:24, Daniel Vetter wrote:
> On Tue, Nov 09, 2021 at 08:56:10AM +, Simon Ser wrote:
> > There are a few details specific to the GETFB2 IOCTL.
> >
> > It's not immediately clear how user-space should check for the
> > number of planes. Suggest using the pitch
On Tue, 26 Oct 2021 08:34:00 -0300
Igor Torrente wrote:
> Summary
> ===
> This series of patches refactor some vkms components in order to introduce
> new formats to the planes and writeback connector.
>
> Now in the blend function, the plane's pixels are converted to ARGB16161616
> and then
Hi
Am 08.11.21 um 19:57 schrieb Noralf Trønnes:
Den 01.11.2021 15.15, skrev Thomas Zimmermann:
Enable the FB_DAMAGE_CLIPS property to reduce display-update
overhead. Also fixes a warning in the kernel log.
simple-framebuffer simple-framebuffer.0: [drm]
drm_plane_enable_fb_damage_clips()
Hi
Am 09.11.21 um 10:34 schrieb Inki Dae:
Hi Thomas and Daniel,
21. 11. 9. 오전 12:29에 Daniel Vetter 이(가) 쓴 글:
On Mon, Nov 08, 2021 at 11:28:44AM +0100, Thomas Zimmermann wrote:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbac
On Tue, Nov 09, 2021 at 09:29:54AM +, Simon Ser wrote:
> On Tuesday, November 9th, 2021 at 10:24, Daniel Vetter
> wrote:
>
> > On Tue, Nov 09, 2021 at 08:56:10AM +, Simon Ser wrote:
> > > There are a few details specific to the GETFB2 IOCTL.
> > >
> > > It's not immediately clear how use
In the current implementation, substring comparison
using device node name is used to find mdp node
during driver probe. Use compatible string list instead
of node name to get mdp node from the parent mdss node.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Use compatible lists instead of
Hi Dafna,
Thanks for your suggestion,
On Fri, 2021-10-29 at 13:49 +0200, Dafna Hirschfeld wrote:
>
> On 29.10.21 05:55, Yunfei Dong wrote:
> > Decoder will use component framework to manage hardware, it is big
> > difference with encoder.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Yunfe
Hi dafna,
Thanks for your suggestion.
On Fri, 2021-10-29 at 13:42 +0200, Dafna Hirschfeld wrote:
>
> On 29.10.21 05:55, Yunfei Dong wrote:
> > Need to build decoder pm file as module for master and comp
> > use the same pm interface.
>
> Do you still use the component framework in this patchset?
On Tue, 09 Nov 2021, "Wang, Zhi A" wrote:
> On 11/9/2021 9:00 AM, Jani Nikula wrote:
>> On Mon, 08 Nov 2021, Zhi Wang wrote:
>>> From: Zhi Wang
>>>
>>> To support the new mdev interfaces and the re-factor patches from
>>> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
>
Hi dafna,
Thanks for your suggestion.
On Fri, 2021-10-29 at 13:35 +0200, Dafna Hirschfeld wrote:
>
> On 29.10.21 05:55, Yunfei Dong wrote:
> > Using the needed param for pm init/release function and remove
> > unused
> > param mtkdev in 'struct mtk_vcodec_pm'.
> >
> > Reviewed-by: Tzung-Bi Shih
On 11/9/2021 12:58 PM, h...@lst.de wrote:
> On Tue, Nov 09, 2021 at 10:51:27AM +, Wang, Zhi A wrote:
>> Can you elaborate more about this? We need the hash query from the table
>> ASAP when the hypervisor trapped a mmio access. It's a critical path and
>> we tried different data structure in th
On Tue, 09 Nov 2021, Daniel Vetter wrote:
> On Tue, Nov 09, 2021 at 09:40:08AM +0200, Jani Nikula wrote:
>> On Sat, 06 Nov 2021, Stephen Rothwell wrote:
>> > Hi Jani,
>> >
>> > On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula
>> > wrote:
>> >>
>> >> I probably should have pushed c4f08d7246a5 ("dr
After we move BO to a new memory region, we should put it to
the new memory manager's lru list regardless we unlock the resv or not.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
Hi Igor,
again, that is a really nice speed-up. Unfortunately, I find the code
rather messy and hard to follow. I hope my comments below help with
re-designing it to be easier to understand.
On Tue, 26 Oct 2021 08:34:06 -0300
Igor Torrente wrote:
> Currently the blend function only accepts XRG
The "ret" variable is checked on the previous line so we know it's
zero. No need to check again.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pi
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect its
status.
Signed-off-by: Tvrtko Ursulin
Cc: Lu Baolu
---
Bao
From: Tvrtko Ursulin
Trying to capture uninitialised engines when we wedged on init ends in
tears. Skip that together with uC capture, since failure to initialise the
latter can actually be one of the reasons for wedging on init.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_
Am 09.11.21 um 12:19 schrieb xinhui pan:
After we move BO to a new memory region, we should put it to
the new memory manager's lru list regardless we unlock the resv or not.
Signed-off-by: xinhui pan
Interesting find, did you trigger that somehow or did you just stumbled
over it by reading t
[AMD Official Use Only]
I hit vulkan cts test hang with navi23.
dmesg says gmc page fault with address 0x0, 0x1000, 0x2000
And some debug log also says amdgu copy one BO from system Domain to system
Domain which is really weird.
发件人: Koenig, Christian
Mhm, I'm not sure what the rational behind that is.
Not moving the BO would make things less efficient, but should never
cause a crash.
Maybe we should add a CC: stable tag and push it to -fixes instead?
Christian.
Am 09.11.21 um 13:28 schrieb Pan, Xinhui:
[AMD Official Use Only]
I hit vul
Am 08.11.21 um 21:55 schrieb Noralf Trønnes:
Den 01.11.2021 15.15, skrev Thomas Zimmermann:
Enable the FB_DAMAGE_CLIPS property to reduce display-update
overhead. Also fixes a warning in the kernel log.
simple-framebuffer simple-framebuffer.0: [drm]
drm_plane_enable_fb_damage_clips() no
Different platform may has different numbers of register bases. Gets the
numbers of register bases from DT (sizeof(u32) * 4 bytes for each).
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 37 ++-
1 file changed, 28 insert
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
Reviewed-by: Tzung-Bi Shih
Reviewed-By: AngeloGioacchino Del Regno
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk
Manage each hardware information which includes irq/power/clk.
The hardware includes LAT0, LAT1 and CORE.
Signed-off-by: Yunfei Dong
Reported-by: kernel test robot
---
drivers/media/platform/mtk-vcodec/Makefile| 5 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 119 +
.../
Need to build decoder pm file as module for main device
and subdev use the same pm interface.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 6 --
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 9 +
2 files changed, 13 insertions(+), 2
This series adds support for multi hardware decode into mtk-vcodec, by first
adding use
of_platform_populate to manage each hardware information: interrupt, clock,
register
bases and power. Secondly add core work queue to deal with core hardware
message,
at the same time, add msg queue for diffe
Separate decoder and encoder document for the dts are big difference.
Reviewed-by: Rob Herring
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-decoder.yaml| 176 +
.../media/mediatek,vcodec-encoder.yaml| 187 ++
.../bindings/media/mediatek
Adds irq interface for multi hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33 +--
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 25 ++
.../platform/mtk-vcodec/mtk_vcod
Separates different architecture for hardware: pure_sin_core
and lat_sin_core. MT8183 is pure single core. Uses .hw_arch to
distinguish.
Signed-off-by: Yunfei Dong
Reviewed-By: AngeloGioacchino Del Regno
---
.../platform/mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
.../platform/mtk-vcodec
For add new hardware, not only need to lock lat hardware, also
need to lock core hardware in case of different instance start
to decoder at the same time.
Signed-off-by: Yunfei Dong
Reviewed-By: AngeloGioacchino Del Regno
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++--
dri
From: Yunfei Dong
Adds MT8192's compatible "mediatek,mt8192-vcodec-dec".
Adds MT8192's device private data mtk_lat_sig_core_pdata.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4
.../mtk-vcodec/
Use the dma_set_mask_and_coherent helper to set vdec
DMA bit mask to support 34bits iova space(16GB) that
the mt8192 iommu HW support.
Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G,
regarding which iova range VDEC actually locate, it
depends on the dma-ranges property of vdec dtsi nod
For lat and core architecture, lat thread will send message to core
thread when lat decode done. Core hardware will use the message
from lat to decode, then free message to lat thread when decode done.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../plat
Adds decoder dt-bindings for mt8192.
Signed-off-by: Yunfei Dong
---
fix comments and rename yaml file.
---
.../media/mediatek,vcodec-subdev-decoder.yaml | 261 ++
1 file changed, 261 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,vcodec-subdev
Add work queue to process core hardware information.
First, get lat_buf from message queue, then call core
hardware of each codec(H264/VP9/AV1) to decode, finally
puts lat_buf back to the message.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 16 +++-
.../pla
Generalizes power and clock on/off interfaces to support different hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 4 +
.../platform/mtk-vcodec/
Add core dec and dec end ipi msg: AP_IPIMSG_DEC_CORE/AP_IPIMSG_DEC_CORE_END.
Signed-off-by: Yunfei Dong
Reviewed-By: AngeloGioacchino Del Regno
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 4
.../media/platform/mtk-vcodec/vdec_vpu_if.c| 12
.../media/platform/mtk
There are only two lines in mtk_vcodec_release_enc_pm, using
pm_runtime_disable and put_device instead directly.
Move pm_runtime_enable outside mtk_vcodec_release_enc_pm to symmetry with
pm_runtime_disable, after that, rename mtk_vcodec_init_enc_pm to *_clk since
it only has clock operations now.
There are only two lines in mtk_vcodec_release_dec_pm, using
pm_runtime_disable and put_device instead directly.
Move pm_runtime_enable outside mtk_vcodec_init_dec_pm to symmetry with
pm_runtime_disable, after that, rename mtk_vcodec_init_dec_pm to *_clk since
it only has clock operations now.
Si
Vdec and venc can use the same function to wake up interrupt event.
Reviewed-by: Tzung-Bi Shih
Reviewed-By: AngeloGioacchino Del Regno
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 9 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |
There is just one core thread, in order to separate different
hardware, using codec type to separeate it in scp driver.
Signed-off-by: Yunfei Dong
Reviewed-By: AngeloGioacchino Del Regno
---
fix spelling mistakes.
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platfo
Den 09.11.2021 13.38, skrev Thomas Zimmermann:
>
>
> Am 08.11.21 um 21:55 schrieb Noralf Trønnes:
>>
>>
>> Den 01.11.2021 15.15, skrev Thomas Zimmermann:
>>> Enable the FB_DAMAGE_CLIPS property to reduce display-update
>>> overhead. Also fixes a warning in the kernel log.
>>>
>>> simple-fra
[AMD Official Use Only]
Yes, a stable tag is needed. vulkan guys say 5.14 hit this issue too.
I think that amdgpu_bo_move() does support copy from sysMem to sysMem correctly.
maybe something below is needed.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu
Den 09.11.2021 10.06, skrev Thomas Zimmermann:
> Hi
>
> Am 08.11.21 um 22:01 schrieb Noralf Trønnes:
>>
>>
>> Den 01.11.2021 15.15, skrev Thomas Zimmermann:
>>> Add constants for the maximum size of the shadow-plane surface
>>> size. Useful for shadow planes with virtual screen sizes. The
>>> c
On 27/10/2021 10:30, Tomi Valkeinen wrote:
> On 27/10/2021 11:29, Tomi Valkeinen wrote:
>> On 18/10/2021 17:28, Neil Armstrong wrote:
>>> Call drm_atomic_helper_check_plane_state() from the plane
>>> atomic_check() callback in order to add plane state sanity
>>> checking.
>>>
>>> It will permit fil
[AMD Official Use Only]
Actually this patch does not totally fix the mismatch of lru list with mem_type
as mem_type is changed in ->move() and lru list is changed after that.
During this small period, another eviction could still happed and evict this
mismatched BO from sMam(say, its lru list i
Yeah, but that should never happen in the first place.
Even when the BO is on the wrong LRU TTM should check that beforehand.
In other words when we pick a BO from the LRU we should still double
check bo->resource->mem_type to make sure it is what we are searching for.
Christian.
Am 09.11.21
Exactly that's the reason why we should have the double check in TTM
I've mentioned in the other mail.
Christian.
Am 09.11.21 um 14:16 schrieb Pan, Xinhui:
[AMD Official Use Only]
Actually this patch does not totally fix the mismatch of lru list with mem_type as
mem_type is changed in ->move
On Tue, 9 Nov 2021 at 12:47, Krishna Manikandan
wrote:
>
> In the current implementation, substring comparison
> using device node name is used to find mdp node
> during driver probe. Use compatible string list instead
> of node name to get mdp node from the parent mdss node.
>
> Signed-off-by: Kr
Hi,
On 27/10/2021 14:50, Tomi Valkeinen wrote:
> On 18/10/2021 17:28, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> If the drm_plane has a source width that's greater than the max width
>> supported by a single hw overlay, then we assign a 'r_overlay' to it in
>> omap_plane_atomic_check().
>
Hi Tomi,
On 12/10/2021 15:39, Neil Armstrong wrote:
> From: Tomi Valkeinen
>
> DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes
> from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To
> support DRA76's wide screen HDMI feature, we need to increase this
> max
Hi drm/bridge maintainers,
On 29/10/2021 15:59, Neil Armstrong wrote:
> The current ELD handling takes the internal connector ELD buffer and
> shares it to the I2S and AHB sub-driver.
>
> But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created
> elsewhere (not not), and an eventual conn
[AMD Official Use Only]
yes, a double check is needed.
how about change below.
As long as we detect such mismatch, it indicates another eviction is on going.
return false here is reasonable.
@@ -1335,6 +1336,8 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
09.11.2021 12:19, Daniel Vetter пишет:
> On Mon, Nov 08, 2021 at 09:16:07PM +0300, Dmitry Osipenko wrote:
>> 08.11.2021 18:17, Daniel Vetter пишет:
>>> On Mon, Nov 08, 2021 at 02:08:21AM +0300, Dmitry Osipenko wrote:
Use drm_dp_aux_register_ddc/chardev() helpers that allow to register I2C
On 04/11/21 12:46 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> On contiguous allocation, we round up the size
>> to the *next* power of 2, implement a function
>> to free the unused pages after the newly allocate block.
>>
>> Signed-off-by: Arunpravin
>
> Ideally this ge
In general the correct idea, but the wrong place to check that.
Calling amdgpu_ttm_bo_eviction_valuable() is only optional, but that
check must be mandatory for correct operation.
This needs to be inside ttm_bo_evict_swapout_allowable().
Christian.
Am 09.11.21 um 14:41 schrieb Pan, Xinhui:
09.11.2021 16:52, Dmitry Osipenko пишет:
> 09.11.2021 12:19, Daniel Vetter пишет:
>> On Mon, Nov 08, 2021 at 09:16:07PM +0300, Dmitry Osipenko wrote:
>>> 08.11.2021 18:17, Daniel Vetter пишет:
On Mon, Nov 08, 2021 at 02:08:21AM +0300, Dmitry Osipenko wrote:
> Use drm_dp_aux_register_ddc/ch
09.11.2021 17:08, Dmitry Osipenko пишет:
>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
>> +{
>> +struct drm_device *drm = dev_get_drvdata(&dev->dev);
> And platform_unregister_drivers() should be moved here.
>
Nah, that should cause deadlock. This ad-hoc is too lame.
Anoth
09.11.2021 17:17, Dmitry Osipenko пишет:
> 09.11.2021 17:08, Dmitry Osipenko пишет:
>>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
>>> +{
>>> + struct drm_device *drm = dev_get_drvdata(&dev->dev);
>> And platform_unregister_drivers() should be moved here.
>>
>
> Nah, that shou
Hi,
thanks for looking through all this code.
Am 09.11.21 um 14:04 schrieb Noralf Trønnes:
Den 09.11.2021 13.38, skrev Thomas Zimmermann:
Am 08.11.21 um 21:55 schrieb Noralf Trønnes:
Den 01.11.2021 15.15, skrev Thomas Zimmermann:
Enable the FB_DAMAGE_CLIPS property to reduce display-up
Den 09.11.2021 15.56, skrev Thomas Zimmermann:
> Hi,
>
> thanks for looking through all this code.
>
> Am 09.11.21 um 14:04 schrieb Noralf Trønnes:
>>
>>
>> Den 09.11.2021 13.38, skrev Thomas Zimmermann:
>>>
>>>
>>> Am 08.11.21 um 21:55 schrieb Noralf Trønnes:
Den 01.11.2021 15.
On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote:
>
> On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote:
> > I stumbled across this thread when I ran into the same issue, while
> > working out how to move drm/msm to use scheduler's retire +
> > timeout/recovery (and get rid of our own mi
On 11/8/2021 4:29 PM, Bjorn Andersson wrote:
On Mon 08 Nov 15:42 PST 2021, Kuogee Hsieh wrote:
From: Kuogee Hsieh
Combo phy supports both USB and DP simultaneously. There may has a
possible conflict during phy initialization phase between USB and
DP driver which may cause USB phy timeout wh
On 9/27/21 7:26 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
The meaning of the 'imply' keyword has changed recently, and neither the
old meaning (select the symbol if its dependencies are met) nor the new
meaning (enable it by default, but let the user set any other setting)
is what we want he
On 11/8/21 11:54 PM, Pavel Machek wrote:
Hi!
This series is truncated .. I only got first patches. Similary, 5.10
series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add
checking to s5p_mfc_probe... is last one I got.
I got all the patches before that, so I believe it is not probl
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence of iommu domain per device to accurately reflect
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that intel_iommu=igfx_off option only
disables the igfx iommu. Stop relying on global intel_iommu_gfx_mapped
and probe presence o
On Tue, Nov 9, 2021 at 11:04 PM Tim Harvey wrote:
>
> Add nodes for MIPI DSI and LCDIF on IMX8MM
>
> I'm currently working with a set of patches to convert drm/exynos
> to a bridge [1] and add IMX8MM support [2] in order to get IMX8MM DSI
> working for display with a Raspberry Pi DSI touchscreen c
On Tue, Nov 9, 2021 at 11:38 AM Jagan Teki wrote:
>
> On Tue, Nov 9, 2021 at 11:04 PM Tim Harvey wrote:
> >
> > Add nodes for MIPI DSI and LCDIF on IMX8MM
> >
> > I'm currently working with a set of patches to convert drm/exynos
> > to a bridge [1] and add IMX8MM support [2] in order to get IMX8M
If you happened to try to access `/dev/drm_dp_aux` devices provided by
the MSM DP AUX driver too early at bootup you could go boom. Let's
avoid that by only allowing AUX transfers when the controller is
powered up.
Specifically the crash that was seen (on Chrome OS 5.4 tree with
relevant backports
From: Rob Clark
This started out as conversion to using drm/sched to handle job timeout,
recovery, and retire (and delete a bunch of code), but the latter part
is on hold until drm/sched is fixed to properly handle job retire/
cleanup before deciding which job triggered the fault/timeout[1]. But
From: Rob Clark
The struct_mutex locking is a remnant from the days before per-obj locks,
and no longer needed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_debugfs.c | 37 ++-
drivers/gpu/drm/msm/msm_fbdev.c | 13 ---
2 files changed, 16 insertion
From: Rob Clark
cur_ctx_seqno already does the same thing, but handles the edge cases
where a refcnt'd context can live after lastclose. So let's not have
two ways to do the same thing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/a3x
From: Rob Clark
The remaining struct_mutex usage is just to serialize various gpu
related things (submit/retire/recover/fault/etc), so replace
struct_mutex with gpu->lock.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 ++--
drivers/gpu/drm/msm/adreno/adreno_devic
From: Rob Clark
Add some helpers for fence comparision, which handle rollover properly,
and stop open coding fence seqno comparisions.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.h | 12
drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
drivers/gpu/drm/msm/msm_gpu.h |
From: Rob Clark
Add a debugfs interface to ignore hw error irqs, in order to force
fallback to sw hangcheck mechanism. Because the hw error detection is
pretty good on newer gens, we need this for igt tests to test the sw
hang detection.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno
Add nodes for MIPI DSI and LCDIF on IMX8MM
I'm currently working with a set of patches to convert drm/exynos
to a bridge [1] and add IMX8MM support [2] in order to get IMX8MM DSI
working for display with a Raspberry Pi DSI touchscreen compatible with
a Toshiba TC358762 DSI bridge and Powertip PH8
On Tue, Nov 9, 2021 at 11:34 AM Tim Harvey wrote:
>
> Add nodes for MIPI DSI and LCDIF on IMX8MM
>
> I'm currently working with a set of patches to convert drm/exynos
> to a bridge [1] and add IMX8MM support [2] in order to get IMX8MM DSI
> working for display with a Raspberry Pi DSI touchscreen c
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
As we are going to add virtual planes, add the list of supported
formats
to the hw catalog entry. It will be used to setup universal planes,
with
later selecting a pipe depending on whether the YUV format is used for
the framebuffer.
Signed-off-by:
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Add DPU_SSPP_CSC_ANY denoting any CSC block. As we are at it, rewrite
DPU_SSPP_SCALER (any scaler) to use BIT(x) instead of hand-coded
bitshifts.
This can go independent of the multi-rect series, so can you please take
this with the
first half of th
On 2021-07-04 18:21, Dmitry Baryshkov wrote:
Stop limiting zpos property values, we use normalized_zpos anyway. And
nothing stops userspace from assigning several planes to a single zpos
(it is a userspace bug, but the kernel is forgiving about it).
Userspace assigning several planes to a singl
Hi Paul,
> Am 07.11.2021 um 20:05 schrieb Paul Cercueil :
>
>> 6. Therefore I think it *may* work overclocked with 48MHz
>> but is not guaranteed or reliable above 27 MHz.
>> So everything is ok here.
>
> One thing though - the "assigned-clocks" and "assigned-clock-rates", while it
> works here
On 2021-11-05 08:59, Ville Syrjälä wrote:
> On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>> planes have different capabilities, implemented respective
>>> struct
On Tue, 9 Nov 2021 at 23:15, wrote:
>
> On 2021-07-04 18:21, Dmitry Baryshkov wrote:
> > Stop limiting zpos property values, we use normalized_zpos anyway. And
> > nothing stops userspace from assigning several planes to a single zpos
> > (it is a userspace bug, but the kernel is forgiving about i
On 2021-11-05 07:49, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>> Harry Wentland wrote:
>>>
On 2021-09-06 17:38, Uma Shankar wrote:
> Existing LUT pre
Hi Nikolaus,
Le mar., nov. 9 2021 at 21:19:17 +0100, H. Nikolaus Schaller
a écrit :
Hi Paul,
Am 07.11.2021 um 20:05 schrieb Paul Cercueil :
6. Therefore I think it *may* work overclocked with 48MHz
but is not guaranteed or reliable above 27 MHz.
So everything is ok here.
One thing t
1 - 100 of 137 matches
Mail list logo
