On 20-06-24, 18:05, Lee Jones wrote:
> On Thu, 20 Jun 2024, Vinod Koul wrote:
>
> > On 20-06-24, 12:45, Markus Elfring wrote:
> > > …
> > > > All errors (new ones prefixed by >>):
> > > >
> > > >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from
> > > >>> this goto statement to
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3 +++
1 file changed, 3 insertions(+)
d
On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote:
> On 20-06-24, 18:05, Lee Jones wrote:
> > On Thu, 20 Jun 2024, Vinod Koul wrote:
> >
> > > On 20-06-24, 12:45, Markus Elfring wrote:
> > > > …
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > > > > drivers/iio/industrialio-buf
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
Hi
Am 20.06.24 um 16:30 schrieb Hoi Pok Wu:
Dear Thomas,
Thank you for testing my patch. The dev->dev_private is indeed the problem.
However, most of the functions that uses dev->dev_private is passing
drm_device as parameter, and then uses dev->dev_private to retrieve
radeon_device,
contradic
> Sadly, I am yet to see a constructive approach or even better a helpful
> patch which improve something, rather than vague suggestions on the list
Can you get any more constructive impressions from another data representation?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/lo
Am 21.06.24 um 09:16 schrieb Thomas Zimmermann:
Hi
Am 20.06.24 um 16:30 schrieb Hoi Pok Wu:
Dear Thomas,
Thank you for testing my patch. The dev->dev_private is indeed the
problem.
However, most of the functions that uses dev->dev_private is passing
drm_device as parameter, and then uses de
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case while releasing a buffer object. Hence, push a possibl
> Yeah, just look at how many automatic replies he get's from Greg pretty much
> saying to ignore his comments.
Does your feedback just indicate recurring communication difficulties?
Regards,
Markus
On Fri, 21 Jun 2024, Nuno Sá wrote:
> On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote:
> > On 20-06-24, 18:05, Lee Jones wrote:
> > > On Thu, 20 Jun 2024, Vinod Koul wrote:
> > >
> > > > On 20-06-24, 12:45, Markus Elfring wrote:
> > > > > …
> > > > > > All errors (new ones prefixed by >>):
>
On Fri, 21 Jun 2024, Markus Elfring wrote:
> > Sadly, I am yet to see a constructive approach or even better a helpful
> > patch which improve something, rather than vague suggestions on the list
>
> Can you get any more constructive impressions from another data
> representation?
> https://git.
On 09.06.24 23:19, Mikhail Gavrilov wrote:
> On Fri, Jun 7, 2024 at 6:39 PM Alex Deucher wrote:
>>
>> --- a/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c
>> +++ b/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c
>> @@ -944,7 +944,7 @@ void optc1_set_drr(
>>
> The issue is one of communication and the way reviews are conducted.
>
> Reviewing other people's work is challenging and requires a certain
> skill-set, of which _excellent_ communication skills are non-negotiable.
Patch feedback and change tolerance can vary also according to involved
communi
On Fri, 21 Jun 2024, Markus Elfring wrote:
> > The issue is one of communication and the way reviews are conducted.
> >
> > Reviewing other people's work is challenging and requires a certain
> > skill-set, of which _excellent_ communication skills are non-negotiable.
>
> Patch feedback and chang
Am 21.06.24 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case while
On Thu, Jun 20, 2024 at 03:06:11PM GMT, Dave Stevenson wrote:
> On Thu, 20 Jun 2024 at 14:52, Maxime Ripard wrote:
> >
> > On Thu, Jun 20, 2024 at 12:14:00PM GMT, Dave Stevenson wrote:
> > > Add myself and our kernel maintenance list as maintainers for
> > > VC4 alongside Maxime.
> > >
> > > Signe
On Thu, Jun 20, 2024 at 09:00:23AM GMT, Alex Deucher wrote:
> On Thu, Jun 20, 2024 at 3:10 AM Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Wed, Jun 19, 2024 at 09:53:12AM GMT, Alex Deucher wrote:
> > > On Wed, Jun 19, 2024 at 9:50 AM Alex Deucher
> > > wrote:
> > > >
> > > > On Tue, Jun 18, 2024
在 2024/6/21 下午3:10, Chen Ni 写道:
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3 ++
Hi Dave,
Thanks for taking the time to send this.
I've gone through most of the patches and it looks pretty good already,
but I have a few general remarks:
- We merged in drm-misc-next the new HDMI infrastructure recently and
it will heavily conflict with some of these patches, so you need
Hi,
I want to push at least the first patch that is an important fix.
But if there are no objections, I can push the whole series except patch
5 "drm/panic: Convert to drm_fb_clip_offset()" which causes some build
issue.
Best regards,
--
Jocelyn
On 13/06/2024 21:17, Geert Uytterhoeven wrot
Hi,
On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote:
> From: Dom Cobley
>
> Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
> Tested with kmstest and kodi. e.g.
>
> kmstest -r 1920x1080@60 -f 400x300-YU24
>
> Note: without the shift of width, only half the chro
Hi,
On Tue, Jun 11, 2024 at 09:13:03AM GMT, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime,
>
> [snip]
>
> > > > > > ---
> > > > > > TODO:
> > > > > > 1) Drop MTK_DRM_IOCTL_GEM_CREATE and use DMA_HEAP_IOCTL_ALLOC
> > > > > > in
> > > > > > userspace
> > > > > > 2) DRM driver use secure mailbox channel to
On Sat, 15 Jun 2024 20:53:30 +0300, Dmitry Baryshkov wrote:
> Use new HDMI Connector helpers in the Lontium LT9611 bridge driver.
> Program InfoFrames using the helper's callbacks. Also use TMDS char rate
> validation callback to filter out modes, instead of hardcoding 4k@30.
>
> The Audio InfoFra
On LNL because of flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GPU.
Cc: Matthew Auld
Cc: Michal Mrozek
Cc: "Thomas Hellström"
Signed-off-by: Nirmoy Das
---
dri
On 21/06/2024 08:15, Alan Previn wrote:
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file
Hi,
Sorry for taking some time to review this series.
On Sat, Jun 15, 2024 at 08:53:32PM GMT, Dmitry Baryshkov wrote:
> Several DRM drivers implement HDMI codec support (despite its name it
> applies to both HDMI and DisplayPort drivers). Implement generic
> framework to be used by these drivers.
On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> Add necessary glue code to be able to use new HDMI codec framework from
> the DRM bridge drivers. The drm_bridge implements a limited set of the
> hdmi_codec_ops interface, with the functions accepting both
> drm_connector and drm_br
Hi Marek
Am 13.06.24 um 07:59 schrieb Marek Olšák:
Hi Thomas,
Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
breaks (crashes?) lightdm (login screen) such that all I get is the
terminal. It's also reproducible with tag v6.9 where the commit is
present.
I still cannot reprodu
On Fri, 21 Jun 2024 at 09:57, Maxime Ripard wrote:
>
> Hi,
>
> On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote:
> > From: Dom Cobley
> >
> > Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
> > Tested with kmstest and kodi. e.g.
> >
> > kmstest -r 1920x1080@60 -f 4
On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote:
> Here's the v12 of my patchset that introduces DMABUF support to IIO.
>
> Apart from a small documentation fix, it reverts to using
> mutex_lock/mutex_unlock in one particular place, which used cleanup
> GOTOs (which don't play well with
On 20-06-24, 20:11, Jonathan Cameron wrote:
> On Thu, 20 Jun 2024 21:50:41 +0530
> Vinod Koul wrote:
>
> > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > Hi Jonathan,
> >
> > Hey Jonathan,
> >
> > Assuming we are fine with this series, how would you like to proceed.
> > Would you be fine with
On 21-06-24, 15:38, Vinod Koul wrote:
> On 20-06-24, 20:11, Jonathan Cameron wrote:
> > On Thu, 20 Jun 2024 21:50:41 +0530
> > Vinod Koul wrote:
> >
> > > On 20-06-24, 14:27, Paul Cercueil wrote:
> > > > Hi Jonathan,
> > >
> > > Hey Jonathan,
> > >
> > > Assuming we are fine with this series,
Morning Maxime
On Fri, 21 Jun 2024 at 09:55, Maxime Ripard wrote:
>
> Hi Dave,
>
> Thanks for taking the time to send this.
>
> I've gone through most of the patches and it looks pretty good already,
> but I have a few general remarks:
>
> - We merged in drm-misc-next the new HDMI infrastructur
On 6/19/24 21:35, Sunil Kovvuri Goutham wrote:
> [Some people who received this message don't often get email from
> sgout...@marvell.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
>> +
>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_disabl
On 6/19/24 21:41, Sunil Kovvuri Goutham wrote:
> [Some people who received this message don't often get email from
> sgout...@marvell.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
>>
>> Add common support for AI scaling over the network. Initialize the h
>>> +
>>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_disable_decap
>>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_inject_rx_err
>>> +What:
>/sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mac_lane_remap
>>
>> Don't think debugfs is the correct interface for all this con
Hi Marek,
Am Freitag, 21. Juni 2024, 05:30:26 CEST schrieb Marek Vasut:
> On 6/11/24 6:45 PM, Marek Vasut wrote:
> > On 6/6/24 12:10 PM, Alexander Stein wrote:
> >> Hi Marek,
> >
> > Hello Alexander,
> >
> > sorry for the delay.
> >
> >> At least for 148.5MHz (1080p) apparently it is not po
On Wed, Jun 19, 2024 at 09:35:57PM +0200, Uwe Kleine-König wrote:
> These drivers don't use the driver_data member of struct i2c_device_id,
> so don't explicitly initialize this member.
>
> This prepares putting driver_data in an anonymous union which requires
> either no initialization or named de
On Fri, Jun 21, 2024 at 12:56 PM Linux regression tracking (Thorsten
Leemhuis) wrote:
> Hmmm, I might have missed something, but it looks like nothing happened
> here since then. What's the status? Is the issue still happening?
Yes. Tested on e5b3efbe1ab1.
I spotted that the problem disappears a
Hello Krzysztof,
Thank you for your reply!
On Tue, Jun 18, 2024 at 6:17 PM Krzysztof Kozlowski wrote:
>
> On 18/06/2024 10:15, Hironori KIKUCHI wrote:
> > The RG28XX panel is a panel specific to the Anbernic RG28XX.
> > It is 2.8 inches in size (diagonally) with a resolution of 480x640.
> >
> >
In today's drm tree commits
824a450c0d90a ("accel/habanalabs: gradual sleep in polling memory macro")
fb0e9ebb93aa9 ("accel/habanalabs: move heartbeat work initialization to early
init")
ee6350c6c3300 ("accel/habanalabs: print timestamp of last PQ heartbeat on EQ
heartbeat failure")
9948
> On 11 Jun 2024, at 7:50 PM, Jonas Karlman wrote:
>
> This series ensure poweron/poweroff and CEC phys addr invalidation is
> happening under drm mode_config mutex lock, and also ensure EDID is
> updated (when the dw-hdmi connector is used) after a hotplug pulse.
>
> These changes has mainly be
On Fri, 21 Jun 2024 at 12:27, Maxime Ripard wrote:
>
> Hi,
>
> Sorry for taking some time to review this series.
No problem, that's not long.
>
> On Sat, Jun 15, 2024 at 08:53:32PM GMT, Dmitry Baryshkov wrote:
> > Several DRM drivers implement HDMI codec support (despite its name it
> > applies
On Fri, 21 Jun 2024 at 12:30, Maxime Ripard wrote:
>
> On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> > Add necessary glue code to be able to use new HDMI codec framework from
> > the DRM bridge drivers. The drm_bridge implements a limited set of the
> > hdmi_codec_ops interface
On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson wrote:
>
> On Wed, Jun 12, 2024 at 09:28:39PM GMT, Dmitry Baryshkov wrote:
> > On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> > > Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> > > to be added for PD notification
On 20-06-2024 19:16, Nirmoy Das wrote:
On LNL because flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GP
This gives very nice improvement for large buffer:
Withou
On 6/21/2024 2:08 PM, Ghimiray, Himal Prasad wrote:
On 20-06-2024 19:16, Nirmoy Das wrote:
On LNL because flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GP
Thi
On Wed, Jun 19, 2024 at 04:46:48PM +0200, amerg...@baylibre.com wrote:
> + /* gain default values*/
> + regmap_update_bits(priv->regmap, MT6357_AUDENC_ANA_CON0,
> MT6357_AUDPREAMPLGAIN_MASK,
> +UL_GAIN_0DB << MT6357_AUDPREAMPLGAIN_SFT);
> + regmap_update_bits(p
On LNL because of flat CCS, driver creates a migrate job to clear
CCS meta data. Extend that to also clear system pages using GPU.
Inform TTM to allocate pages without __GFP_ZERO to avoid double page
clearing by clearing out TTM_TT_FLAG_ZERO_ALLOC flag.
v2: Handle regression on dgfx(Himal)
Upd
On 21/06/2024 00:22, Javier Martinez Canillas wrote:
Add support for the drm_panic infrastructure, which allows to display
a user friendly message on the screen when a Linux kernel panic occurs.
The display controller doesn't scanout the framebuffer, but instead the
pixels are sent to the dev
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
asus-z00t-tm5p5-n35596 panel.
Signed-off-by: Tejas Vipin
---
.../drm/panel/panel-asus-z00t-tm5p5-
Add myself as maintainer for VC4 alongside Maxime, and
our internal review list as reviewer.
Signed-off-by: Dave Stevenson
---
v1->v2
Changed the internal list from M to R.
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1566c647a50..8dabcb16d
Emma stepped back from VC4 maintenance a while ago, and
all patches are now merged through drm-misc.
Drop Emma's tree from MAINTAINERS.
Signed-off-by: Dave Stevenson
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8dabcb16d29f..3fb03de446c3 100
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
between commit:
c03d770c0b014 ("drm/amd/display: Attempt to avoid empty TUs when endpoint is
DPIA")
from the drm-fixes tree and commits:
47745acc5e8dd ("drm/amd/di
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0
Hi Katya,
thanks for the patch.
Tested-by: Yannick Fertre
BR
Le 19/03/2024 à 14:47, Philippe CORNU - foss a écrit :
zut, déjà un acked-by de RGA...
tu confirmes que je prends?
Philippe
De : Raphael GALLAIS-POU - foss
Envoyé : lundi 26 février 2024 14:
Hi Dave,
On Fri, 21 Jun 2024 at 14:19, Dave Stevenson
wrote:
> Add myself as maintainer for VC4 alongside Maxime, and
> our internal review list as reviewer.
Both patches are:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
From: Yannick Fertre
Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.
Signed
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS().
This means we don't need __maybe_unused on the functions.
Signed-off-by: Raphae
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> These three functions follow the same pattern. To deduplicate the code,
> let's introduce a common help __kstrndup().
>
> Suggested-by: Andrew Morton
> Signed-off-by: Yafang Shao
Hi Yafang Shao,
Some minor nits from my side.
> ---
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> +++ b/mm/internal.h
Why are you putting __kstrndup in a header file when it's only used
in util.c?
Also, I think this function is actually __kmemdup_nul(), not
__kstrndup().
This is "drm/radeon: remove load callback" v2, the only changes
were made are adding "ddev->dev_private = rdev;", right after
the allocation of "struct radeon_device". Patch v2 2-7 mostly
describes simple "rdev->ddev" to "rdev_to_drm(rdev)" to suit
Patch v2 1/7.
Please be aware that these 7 patche
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/atombios_encoders.c | 2 +-
drivers/gpu/drm/radeon/cik.c | 14 ++---
drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 12 +--
d
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/r300.c | 6 +++---
drivers/gpu/drm/radeon/r420.c | 6 +++---
drivers/gpu/drm/radeon/r520.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 12 ++--
drivers/gpu/drm/radeon/r600_cs.c | 2
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
drivers/gpu/drm/radeon/radeon_acpi.c | 10 +-
drivers/gpu/drm/radeon/radeon_agp.c | 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
drivers/gpu/drm/radeo
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/radeon_device.c | 19 +++
drivers/gpu/drm/radeon/radeon_display.c | 74 -
drivers/gpu/drm/radeon/radeon_fbdev.c | 26 -
drivers/gpu/drm/radeon/radeon_fence.c | 8 +-
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/radeon_ib.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c | 12 ++--
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_pm.c | 20 ++--
drive
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/rs400.c | 6 +++---
drivers/gpu/drm/radeon/rs600.c | 14 +++---
drivers/gpu/drm/radeon/rs690.c | 2 +-
drivers/gpu/drm/radeon/rv515.c | 4 ++--
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu
Jocelyn Falempe writes:
Hello Jocelyn, thanks for your feedback!
> On 21/06/2024 00:22, Javier Martinez Canillas wrote:
>> Add support for the drm_panic infrastructure, which allows to display
>> a user friendly message on the screen when a Linux kernel panic occurs.
>>
>> The display controlle
On Fri, Jun 21, 2024 at 12:15:06AM -0700, Alan Previn wrote:
> When calling xe_bo_create_pin_map_at, use the correct
> starting offset provided by caller at xe_ggtt_insert_bo_at.
>
> Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
> Signed-off-by: Alan Previn
> ---
> drivers/gp
Am 20.06.24 um 18:01 schrieb Nirmoy Das:
Currently ttm pool is not honoring TTM_TT_FLAG_ZERO_ALLOC flag and
clearing pages on free. It does help with allocation latency but clearing
happens even if drm driver doesn't passes the flag. If clear on free
is needed then a new flag can be added for tha
Hi Raphaël,
Thanks for your patch, it will not merged due to a new clock management.
Philippe,
this patch will be replaced by another which manages all clocks that the
display controller
will need (pixel clock, bus clock reference clock).
Best regards
Le 26/02/2024 à 11:48, Raphael Gall
On Wed, Jun 19, 2024 at 04:46:48PM +0200, amerg...@baylibre.com wrote:
> From: Nicolas Belin
>
> Add the support of MT6357 PMIC audio codec.
This breaks an x86 allmodconfig build:
/build/stage/linux/sound/soc/codecs/mt6357.c: In function ‘mt_delay_250_event’:
/build/stage/linux/sound/soc/codecs
On 19/06/2024 16:46, Alexandre Mergnat wrote:
> Add the audio codec sub-device. This sub-device is used to set the
> optional voltage values according to the hardware.
> The properties are:
> - Setup of microphone bias voltage.
> - Setup of the speaker pin pull-down.
>
> Also, add the audio po
Hi, Alexandre:
於 2024年5月23日 週四 下午8:49寫道：
>
> From: Fabien Parent
>
> DPI is part of the display / multimedia block in MediaTek SoCs, and
> always have a power-domain (at least in the upstream device-trees).
> Add the power-domains property to the binding documentation.
I've tired to apply this
On 21/06/2024 12:59, Hironori KIKUCHI wrote:
> Hello Krzysztof,
>
> Thank you for your reply!
>
> On Tue, Jun 18, 2024 at 6:17 PM Krzysztof Kozlowski wrote:
>>
>> On 18/06/2024 10:15, Hironori KIKUCHI wrote:
>>> The RG28XX panel is a panel specific to the Anbernic RG28XX.
>>> It is 2.8 inches in
Hi
This set is a number of minor fixes that we've had downstream for a while,
and then lays down the some infrastructure changes to facilitate adding support
of BCM2712. I'm just finalising those patches so they should follow on fairly
soon.
Thanks
Dave
---
v1 -> v2
- Sorted Maxime's email ad
From: Dom Cobley
Fractional source co-ordinates can be used to setup the scaling
filters, so retain the information.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 68 -
2 f
From: Dom Cobley
Apply fractional source co-ordinates into the scaling filters.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c | 87 -
1 file changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v
From: Maxime Ripard
We need to allocate a few additional structures when checking our
atomic_state, especially related to hardware SRAM that will hold the
plane descriptors (DLIST) and the current line context (LBM) during
composition.
Since those allocation can fail, let's add some error messag
When the margins are changed, the dlist needs to be regenerated
with the changed updated dest regions for each of the planes.
Setting the zpos_changed flag is sufficient to trigger that
without doing a full modeset, therefore set it should the
margins be changed.
Signed-off-by: Dave Stevenson
--
From: Maxime Ripard
DLIST generation can get pretty tricky and there's not a lot of debug in
the driver to help. Let's add a few more to track the generated DLIST
size.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 14 --
1 file cha
From: Maxime Ripard
The vc4_plane_atomic_check() directly returns the result of the final
function it calls.
Using the already defined ret variable to check its content on error,
and a separate return 0 on success, makes it easier to extend.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Ste
The HVS can change AXI request mode based on how full the COB
FIFOs are.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.
With HVS channel 2 now being used for live video, change the
panic mode for all channels to be explicitly set by the driver,
and
From: Dom Cobley
Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
Tested with kmstest and kodi. e.g.
kmstest -r 1920x1080@60 -f 400x300-YU24
Note: without the shift of width, only half the chroma is fetched,
resulting in correct left half of image and corrupt colours on right
From: Maxime Ripard
LBM allocations need a different size depending on the line length,
format, etc.
This can get tricky, and fail. Let's add some more prints to ease the
debugging when it does.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c |
When factoring out __vc4_hvs_stop_channel, the logic got inverted from
if (condition)
// stop channel
to
if (condition)
goto out
//stop channel
out:
and also changed the exact register writes used to stop the channel.
Correct the logic so that th
From: Maxime Ripard
The V3D IP has been separate since BCM2711, so let's make sure we issue
a WARN if we're running not only on BCM2711, but also anything newer.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_bo.c | 28 +++-
From: Dom Cobley
Now we wait for write responses and have a burst
size of 4, we can set the fifo threshold much higher.
Set it to 28 (of the 32 entry size) to keep fifo
fuller and reduce chance of underflow.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_
From: Maxime Ripard
Since we'll support BCM2712 soon, let's move the logic behind
vc4_hvs_get_fifo_from_output() to a switch to extend it more easily.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 77 +++
1 file
From: Maxime Ripard
The BCM2712 HVS has registers to report the size of the various SRAM the
driver uses, and their size actually differ depending on the stepping.
The initialisation of the memory pools happen in the __vc4_hvs_alloc()
function that also allocates the main HVS structure, that wil
From: Maxime Ripard
With the introduction of the support for BCM2712, the check of whether
we're running on vc5 or not to compute the LBM alignment requirement
doesn't work anymore.
Moreover, the LBM size will need to be computed in words for the
BCM2712, while we've had sizes in bytes so far.
The offset fields in vc4_plane_state are described as being
the offset for each buffer in the bo, however it is used to
store the complete DMA address that is then written into the
register.
The DMA address including the fb ofset can be retrieved
using drm_fb_dma_get_gem_addr, and the offset adjus
From: Dom Cobley
ABORT_ON_EMPTY chooses whether the HVS abandons the current frame
when it experiences an underflow, or attempts to continue.
In theory the frame should be black from the point of underflow,
compared to a shift of sebsequent pixels to the left.
Unfortunately it seems to put the
From: Maxime Ripard
The HVS register set has been heavily modified in the BCM2712, and we'll
thus need a separate debugfs_reg32 array for it.
The name hvs_regs is thus a bit too generic, so let's rename it to
something more specific.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
From: Tim Gover
Always enable SCALER_CONTROL before attempting other HVS
operations. It's safe to write to some parts of the HVS but
in general it's dangerous to do this because it can cause bus
lockups.
Signed-off-by: Tim Gover
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c
1 - 100 of 174 matches
Mail list logo
