On Thu, Feb 29, 2024 at 12:26:49AM +0100, Konrad Dybcio wrote:
>
>
> On 2/28/24 19:05, Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Wed, 28 Feb 2024 18:45:13 +0100
> >
> > Add a jump target so that a bit of exception handling can be better reused
> > at the end of this function
On Wed, Feb 28, 2024 at 10:10:10AM -0800, Abhinav Kumar wrote:
> On 2/28/2024 5:28 AM, Johan Hovold wrote:
> > This is a fix for a user-visible regression that was reported formally
> > two weeks ago and informally (e.g. to you) soon after rc1 came out, and
> > which now also has an identified
On 28.02.24 22:34, Matthias Kaehlcke wrote:
> On Wed, Feb 28, 2024 at 09:50:22PM +0100, Javier Carrasco wrote:
>> On 28.02.24 21:41, Matthias Kaehlcke wrote:
>>> On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote:
On 28.02.24 19:10, Matthias Kaehlcke wrote:
> On Wed, Feb 28,
On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 28/02/2024 11:18, dharm...@microchip.com wrote:
>> On 28/02/24 12:43 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open
> Subject: Re: [PATCH v12 0/8] Enable Adaptive Sync SDP Support for DP
>
> On Wed, 28 Feb 2024, Mitul Golani
> wrote:
> > -v12:
> > - Update cover letter
>
> Did you just send the entire series again within 30 minutes just to update the
> cover letter? You could've just replied to the cover
Hi all,
After merging the kunit-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/tests/drm_buddy_test.c:7:
drivers/gpu/drm/tests/drm_buddy_test.c: In function
'drm_test_buddy_alloc_range_bias':
On Wed, Feb 28, 2024 at 7:24 AM Maxime Ripard wrote:
>
> I'm currently working on a platform that seems to have togglable RAM ECC
> support. Enabling ECC reduces the memory capacity and memory bandwidth,
> so while it's a good idea to protect most of the system, it's not worth
> it for things
Since MT8195 gamma has multiple bank for 12 bits LUT and it is
different from any other SoC LUT setting.
So we move MT8195 compatible from the one of items to the
single enum group.
Signed-off-by: Jason-JH.Lin
---
.../devicetree/bindings/display/mediatek/mediatek,gamma.yaml| 2 +-
1 file
The gamma LUT setting of MT8188 and MT8195 are the same, so we create
a one of items for MT8188 to reuse the driver data settings of MT8195.
Signed-off-by: Jason-JH.Lin
---
.../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 4
1 file changed, 4 insertions(+)
diff --git
Since MT8195 compatible is in the single enum group, we have to add its
compatible into mediatek-drm component binding table to ensure that
it can be bound as a ddp_comp.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Jason-jh Lin
Since MT8195 supports GAMMA 12-bit LUT after the landing of [1] series,
we can now add support for MT8188.
[1] MediaTek DDP GAMMA - 12-bit LUT support
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=792516
Jason-JH.Lin (3):
dt-bindings: display:
在 2024/2/28 18:47, Matt Coster 写道:
Hi, thanks for the patch!
On 28/02/2024 01:23, Lu Yao wrote:
When 'PAGE_SIZE=64K',the following compilation error occurs:
"
../drivers/gpu/drm/imagination/pvr_fw_mips.c: In function
‘pvr_mips_fw_process’:
On 27/02/24 17:01, Arthur Grillo wrote:
>
>
> On 27/02/24 12:02, Louis Chauvet wrote:
>> Hi Pekka,
>>
>> For all the comment related to the conversion part, maybe Arthur have an
>> opinion on it, I took his patch as a "black box" (I did not want to
>> break (and debug) it).
>>
>> Le
On Wed, Feb 28, 2024 at 5:13 PM Dmitry Baryshkov
wrote:
>
> On Thu, 29 Feb 2024 at 03:05, Hsin-Yi Wang wrote:
> >
> > On Wed, Feb 28, 2024 at 4:22 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
> > > >
> > > > There are 2 different AUO
On Thu, 29 Feb 2024 at 03:05, Hsin-Yi Wang wrote:
>
> On Wed, Feb 28, 2024 at 4:22 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
> > >
> > > There are 2 different AUO panels using the same panel id. One of the
> > > variants requires using
On Wed, Feb 28, 2024 at 4:22 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
> >
> > There are 2 different AUO panels using the same panel id. One of the
> > variants requires using overridden modes to resolve glitching issue as
> > described in commit
On Wed, Feb 28, 2024 at 4:21 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
> >
> > Some panels are interested in the EDID during early probe when connector
> > is still unknown.
> >
> > Add a function drm_get_edid_no_connector() to get edid without
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> There are 2 different AUO panels using the same panel id. One of the
> variants requires using overridden modes to resolve glitching issue as
> described in commit 70e0d5550f5c ("drm/panel-edp: Add auo_b116xa3_mode").
> Other variants
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> @@ -2107,13 +2113,41 @@ static const struct edp_panel_entry edp_panels[] = {
> { /* sentinal */ }
> };
>
> -static const struct edp_panel_entry *find_edp_panel(u32 panel_id)
> +static bool edid_has_name(struct edid *edid, const
Hi,
On Tue, Feb 27, 2024 at 5:11 PM Hsin-Yi Wang wrote:
>
> Some panels are interested in the EDID during early probe when connector
> is still unknown.
>
> Add a function drm_get_edid_no_connector() to get edid without connector.
> No functional change for existing usage.
>
> Signed-off-by:
Hi,
On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang wrote:
>
> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula
> wrote:
> >
> > On Fri, 23 Feb 2024, Hsin-Yi Wang wrote:
> > > It's found that some panels have variants that they share the same panel
> > > id
> > > although their EDID and names are
On 15/01/24 12:06, Sebastian Wick wrote:
> On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote:
>> This patchset aims to add support for additional buffer YUV formats.
>> More specifically, it adds support to:
>>
>> Semi-planar formats:
>>
>> - NV12
>> - NV16
>> - NV24
>> - NV21
>> -
On Thu, Feb 22, 2024 at 06:49:59AM -0800, Yury Norov wrote:
On Wed, Feb 21, 2024 at 03:59:06PM -0600, Lucas De Marchi wrote:
On Wed, Feb 21, 2024 at 11:04:22PM +0200, Andy Shevchenko wrote:
> On Wed, Feb 21, 2024 at 10:30:02PM +0200, Dmitry Baryshkov wrote:
> > On Thu, 8 Feb 2024 at 09:45,
On 2/28/24 19:05, Markus Elfring wrote:
From: Markus Elfring
Date: Wed, 28 Feb 2024 18:45:13 +0100
Add a jump target so that a bit of exception handling can be better reused
at the end of this function implementation.
This issue was transformed by using the Coccinelle software.
Hello Andrew,
Many thanks for proposing this.
On Wed, Feb 28, 2024 at 11:02 PM Javier Martinez Canillas
wrote:
>
> Andrew Halaney writes:
>
> Hello Andrew,
>
> > This gets logged out to /sys/kernel/debug/devices_deferred in the
> > -EPROBE_DEFER case and as an error otherwise. The message here
Hi Helen,
I appreciate the amount of work you've put into this, to improve testing
of the kernel as a whole. I'll need more time to answer, but please see
below for a quick comment already.
On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote:
> Dear Kernel Community,
>
> This patch
Add documentation of kci-gitlab.
Signed-off-by: Helen Koike
---
Documentation/ci/gitlab-ci/gitlab-ci.rst | 404 +++
Documentation/index.rst | 7 +
MAINTAINERS | 1 +
3 files changed, 412 insertions(+)
create mode 100644
This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
defininga basic test pipeline triggered by code pushes to a GitLab-CI
instance. This initial version includes static checks (checkpatch and
smatch for now) and build tests across various architectures and
configurations. It
Dear Kernel Community,
This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a
basic test pipeline triggered by code pushes to a GitLab-CI instance. This
initial version includes static checks (checkpatch and smatch for now) and build
tests across various architectures and
Quoting Dmitry Baryshkov (2024-02-26 14:34:45)
> The function dp_wait_hpd_asserted() uses pm_runtime_get_sync() and
> doesn't care about the return value. Potentially this can lead to
> unclocked access if for some reason resuming of the DP controller fails.
>
> Change the function to use
Hi Laurent,
Thanks a lot for the review.
> -Original Message-
> From: Laurent Pinchart
> Sent: Wednesday, February 28, 2024 8:08 AM
> To: Klymenko, Anatoliy
> Cc: Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ; David
> Airlie ; Daniel Vetter ; Simek, Michal
> ; Andrzej Hajda
On 2/9/2024 3:17 PM, Richard Acayan wrote:
On Thu, Feb 08, 2024 at 05:34:57PM -0800, Jessica Zhang wrote:
On 2/8/2024 4:16 PM, Richard Acayan wrote:
The S6E3FA7 display controller is enabled in every Pixel 3a (non-XL)
variant. Add the driver for it, generated by
On Thu, Feb 29, 2024 at 01:31:53AM +0800, kernel test robot wrote:
drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant
4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is
always false [-Werror,-Wtautological-constant-out-of-range-compare]
Andrew Halaney writes:
Hello Andrew,
> This gets logged out to /sys/kernel/debug/devices_deferred in the
> -EPROBE_DEFER case and as an error otherwise. The message here provides
> useful information to the user when troubleshooting why their display is
> not working in either case, so let's
Hi Maxime,
Thanks for the review.
> -Original Message-
> From: Maxime Ripard
> Sent: Wednesday, February 28, 2024 7:30 AM
> To: Klymenko, Anatoliy
> Cc: Laurent Pinchart ; Maarten Lankhorst
> ; Thomas Zimmermann
> ; David Airlie ; Daniel Vetter
> ; Simek, Michal ; Andrzej Hajda
> ;
Hi Daniel,
On Wed, 28 Feb 2024 17:33:28 +0100 Daniel Vetter wrote:
>
> > git://git.freedesktop.org/git/drm/drm.git#drm-fixes
> > git://git.freedesktop.org/git/drm/drm.git#drm-next
>
> To test out the process we've moved drm.git first. It's now here:
>
>
On 2/2/2024 2:15 AM, Maxime Ripard wrote:
On Tue, Jan 30, 2024 at 09:53:13AM +0100, Daniel Vetter wrote:
Wouldn't it be simpler if we had a vkms-like panel that we could either
configure from DT or from debugfs that would just be registered the
usual way and would be the only panel we
On Wed, Feb 28, 2024 at 09:50:22PM +0100, Javier Carrasco wrote:
> On 28.02.24 21:41, Matthias Kaehlcke wrote:
> > On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote:
> >> On 28.02.24 19:10, Matthias Kaehlcke wrote:
> >>> On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco
Hi,
On Wed, Feb 28, 2024 at 8:52 AM wrote:
>
> On 28/02/2024 17:40, Doug Anderson wrote:
> > Neil,
> >
> > On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
> > wrote:
> >>
> >> Hi Doug,
> >>
> >> On 15/02/2024 16:08, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Thu, Feb 15, 2024 at 2:24 AM Jani
On 28.02.24 21:41, Matthias Kaehlcke wrote:
> On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote:
>> On 28.02.24 19:10, Matthias Kaehlcke wrote:
>>> On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote:
Most of the functionality this driver provides can be used by
On Wed, Feb 28, 2024 at 09:21:00PM +0100, Javier Carrasco wrote:
> On 28.02.24 19:10, Matthias Kaehlcke wrote:
> > On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote:
> >> Most of the functionality this driver provides can be used by non-hub
> >> devices as well.
> >>
> >> To account
On 28.02.24 19:10, Matthias Kaehlcke wrote:
> On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote:
>> Most of the functionality this driver provides can be used by non-hub
>> devices as well.
>>
>> To account for the hub-specific code, add a flag to the device data
>> structure and
return dev_err_probe(dev, ret, "port %d probe
failed\n", i);
}
if (panel) {
---
base-commit: 22ba90670a51a18c6b36d285fddf92b9887c0bc3
change-id: 20240228-tidss-dev-err-probe-fa61fb057029
Best regards,
--
Andrew Halaney
On 28.02.24 19:18, Matthias Kaehlcke wrote:
> On Wed, Feb 28, 2024 at 02:51:29PM +0100, Javier Carrasco wrote:
>> This patch prepares onboad_hub to support non-hub devices by renaming
>> the driver files and their content, the headers and their references.
>>
>> The comments and descriptions have
On 2/28/2024 4:54 AM, Tvrtko Ursulin wrote:
On 27/02/2024 23:51, Vinay Belgaumkar wrote:
Allow user to provide a low latency context hint. When set, KMD
sends a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches
The mail wasn’t indent/preface correctly. Manually format it.
From: Christian König
mailto:christian.koe...@amd.com>>
Sent: Tuesday, February 27, 2024 1:54 AM
To: Zeng, Oak mailto:oak.z...@intel.com>>; Danilo Krummrich
mailto:d...@redhat.com>>; Dave Airlie
mailto:airl...@redhat.com>>; Daniel
Following the pattern of other interfaces, lets align writeback
as well by dropping the dpu_kms parameter in its _dpu_kms_initialize_*
function.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
dpu_kms seems unused while initializing DSI, HDMI and DP through
their respective _dpu_kms_initialize_* functions.
Hence lets drop the parameter altogether.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ++-
1 file changed, 6 insertions(+), 9
On Mon, 26 Feb 2024 13:46:36 +0100, Arnd Bergmann wrote:
> When the driver is built-in but the tests are in loadable modules,
> the helpers don't actually get put into the driver:
>
> ERROR: modpost: "xe_kunit_helper_alloc_xe_device"
> [drivers/gpu/drm/xe/tests/xe_test.ko] undefined!
>
>
On Wed, Feb 28, 2024 at 02:51:35PM +0100, Javier Carrasco wrote:
> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
> multicore controller for voice processing.
>
> This device requires a specific power sequence, which consists of
> enabling the regulators that control the
Hi Dave,
A late revert to address a displayport hpd regression.
The following changes since commit 8c7bfd8262319fd3f127a5380f593ea76f1b88a2:
drm/msm: Wire up tlb ops (2024-02-15 08:51:31 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git
On Wed, Feb 28, 2024 at 02:51:29PM +0100, Javier Carrasco wrote:
> This patch prepares onboad_hub to support non-hub devices by renaming
> the driver files and their content, the headers and their references.
>
> The comments and descriptions have been slightly modified to keep
> coherence and
On Sun, 18 Feb 2024 22:41:21 +0100
Boris Brezillon wrote:
> +int panthor_vm_active(struct panthor_vm *vm)
> +{
> + struct panthor_device *ptdev = vm->ptdev;
> + struct io_pgtable_cfg *cfg =
> _pgtable_ops_to_pgtable(vm->pgtbl_ops)->cfg;
> + int ret = 0, as, cookie;
> + u64
On Sun, 18 Feb 2024 22:41:24 +0100
Boris Brezillon wrote:
> +static void panthor_sched_immediate_tick(struct panthor_device *ptdev)
> +{
> + struct panthor_scheduler *sched = ptdev->scheduler;
> +
> + sched_queue_delayed_work(sched, tick, 0);
> +}
> +
> +/**
> + *
On Wed, Feb 28, 2024 at 02:51:33PM +0100, Javier Carrasco wrote:
> Most of the functionality this driver provides can be used by non-hub
> devices as well.
>
> To account for the hub-specific code, add a flag to the device data
> structure and check its value for hub-specific code.
>
> The
On 2/28/2024 5:28 AM, Johan Hovold wrote:
On Wed, Feb 28, 2024 at 01:08:04PM +0200, Dmitry Baryshkov wrote:
On Wed, 28 Feb 2024 at 11:50, Johan Hovold wrote:
On Tue, Feb 27, 2024 at 02:11:56PM -0800, Abhinav Kumar wrote:
On 2/27/2024 2:08 PM, Dmitry Baryshkov wrote:
This reverts commit
On Wed, Feb 28, 2024 at 02:09:33PM +0100, Paweł Anikiel wrote:
> On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski
> wrote:
> >
> > On 28/02/2024 12:05, Paweł Anikiel wrote:
> > > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring wrote:
> > >>
> > >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł
On 2/28/2024 05:54, Hans de Goede wrote:
Hi Daniel,
On 2/28/24 03:00, Daniel van Vugt wrote:
On 27/2/24 21:47, Hans de Goede wrote:
I think some boot failures also take you to the grub menu automatically next
time?
In Fedora all boot failures will unhide the grub menu on
the next boot.
From: Markus Elfring
Date: Wed, 28 Feb 2024 18:45:13 +0100
Add a jump target so that a bit of exception handling can be better reused
at the end of this function implementation.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 20af1ca418d2c0b11bc2a1fe8c0c88f67bcc2a7e Add linux-next specific
files for 20240228
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402281921.gr4yw253-...@intel.com
https
On 28/02/2024 17:40, Doug Anderson wrote:
Neil,
On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
wrote:
Hi Doug,
On 15/02/2024 16:08, Doug Anderson wrote:
Hi,
On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
On Wed, 14 Feb 2024, Doug Anderson wrote:
Hi,
On Tue, Feb 13, 2024 at 10:25
Fix the documentation issues below, also reported by 'make htmldocs':
drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or
struct member 'tunnel' not described in 'drm_dp_tunnel_put'
drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or
struct member
Neil,
On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
wrote:
>
> Hi Doug,
>
> On 15/02/2024 16:08, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
> >>
> >> On Wed, 14 Feb 2024, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Tue, Feb 13, 2024 at 10:25 PM
Hi Stephen!
On Wed, Feb 21, 2024 at 09:46:43AM +1100, Stephen Rothwell wrote:
> On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote:
> >
> > On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote:
> > > On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote:
> > > > This will be mostly
Hi Adam,
Thank you for the patch.
On Wed, Feb 28, 2024 at 05:37:36AM -0600, Adam Ford wrote:
> The DSI to HDMI bridge supports hot-plut-detect, but the
> driver didn't previously support a shared IRQ GPIO. With
> the driver updated, the interrupt can be added to the bridge.
You can reflow the
Hi Adam,
Thank you for the patch.
On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> The IRQ registration currently assumes that the GPIO is
> dedicated to it, but that may not necessarily be the case.
> If the board has another device sharing the IRQ, it won't be
> registered and the
On Wednesday, February 28th, 2024 at 17:14, Maxime Ripard
wrote:
> > I don't know what the rules were 8 years ago, but the current uAPI rules
> > are what they are, and a new enum entry is new uAPI.
>
> TBF, and even if the wayland compositors support is missing, this
> property is perfectly
Hello Rohit,
Thank you for the patch.
On Fri, Feb 16, 2024 at 04:40:43AM -0800, Rohit Visavalia wrote:
> Assert DisplayPort reset signal before deasserting,
> it is to clear out any registers programmed before booting kernel.
>
> Signed-off-by: Rohit Visavalia
> ---
>
Hi,
On Tue, Feb 27, 2024 at 09:51:06AM +, Simon Ser wrote:
> On Monday, February 26th, 2024 at 18:23, Dave Stevenson
> wrote:
> > > and I've also completely missed any kernel command line
> > > arguments manipulating KMS properties.
> >
> > "tv_mode" on the command line is handled in
> >
On Wed, Feb 28, 2024 at 05:02:10PM +0100, Javier Carrasco wrote:
> On 28.02.24 16:37, Matthias Kaehlcke wrote:
> > Hi Javier,
> >
> > Thanks for moving this patch to the front of the series!
> >
> > A few more comments inline.
> >
> > On Wed, Feb 28, 2024 at 02:51:28PM +0100, Javier Carrasco
On Wed, Feb 28, 2024 at 04:29:33PM +0100, Maxime Ripard wrote:
> On Mon, Feb 26, 2024 at 08:44:45PM -0800, Anatoliy Klymenko wrote:
> > Add select_output_bus_format to CRTC atomic helpers callbacks. This
> > callback Will allow CRTC to participate in media bus format negotiation
> > over connected
Hi Anatoliy,
Thank you for the patch.
On Mon, Feb 26, 2024 at 08:44:44PM -0800, Anatoliy Klymenko wrote:
> Program live video input format according to selected media bus format.
>
> In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
> almost certainly supports a single
On 28.02.24 16:37, Matthias Kaehlcke wrote:
> Hi Javier,
>
> Thanks for moving this patch to the front of the series!
>
> A few more comments inline.
>
> On Wed, Feb 28, 2024 at 02:51:28PM +0100, Javier Carrasco wrote:
>> The current implementation uses generic names for the power supplies,
>>
Hi Anatoliy,
Thank you for the patch.
On Mon, Feb 26, 2024 at 08:44:43PM -0800, Anatoliy Klymenko wrote:
> DPSUB in bridge mode supports multiple input media bus formats.
>
> Announce the list of supported input media bus formats via
> drm_bridge.atomic_get_input_bus_fmts callback.
>
>
On 2/27/24 13:18, Rodrigo Siqueira wrote:
From: Ivan Lipski
[WHY]
Some eDP panels's ext caps don't write initial value cause the value of
dpcd_addr(0x317) is random. It means that sometimes the eDP will
clarify it is OLED, miniLED...etc cause the backlight control interface
is incorrect.
On Thu, 22 Feb 2024 19:13:50 +0100, Maxime Ripard wrote:
> We're going to need a full-blown, functional, KMS device to test more
> components of the atomic modesetting infrastructure.
>
> Let's add a new helper to create a dumb, mocked, CRTC. By default it
> will create a CRTC relying only on the
On Thu, 22 Feb 2024 19:13:51 +0100, Maxime Ripard wrote:
> drmm_connector_init is the preferred function to initialize a
> drm_connector structure. Let's add a bunch of unit tests for it.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 22 Feb 2024 19:13:49 +0100, Maxime Ripard wrote:
> We're going to need a full-blown, functional, KMS device to test more
> components of the atomic modesetting infrastructure.
>
> Let's add a new helper to create a dumb, mocked, primary plane. By
> default, it will create a linear
On Thu, 22 Feb 2024 19:13:48 +0100, Maxime Ripard wrote:
> The mock device we were creating was missing any of the driver-wide
> helpers. That was fine before since we weren't testing the atomic state
> path, but we're going to start, so let's use the default
> implementations.
>
>
Applied to
On Thu, 22 Feb 2024 19:13:47 +0100, Maxime Ripard wrote:
> We have a few functions declared in our kunit helpers header, some of
> them dereferencing the struct drm_driver.
>
> However, we don't include the drm_drv.h header file defining that
> structure, leading to compilation errors if we don't
Hi Javier,
Thanks for moving this patch to the front of the series!
A few more comments inline.
On Wed, Feb 28, 2024 at 02:51:28PM +0100, Javier Carrasco wrote:
> The current implementation uses generic names for the power supplies,
> which conflicts with proper name definitions in the device
On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil wrote:
>
> Hi Paweł,
>
> On 21/02/2024 17:02, Paweł Anikiel wrote:
> > Currently, .query_dv_timings() is defined as a video callback without
> > a pad argument. This is a problem if the subdevice can have different
> > dv timings for each pad (e.g. a
On Mon, Feb 26, 2024 at 01:46:36PM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
When the driver is built-in but the tests are in loadable modules,
the helpers don't actually get put into the driver:
ERROR: modpost: "xe_kunit_helper_alloc_xe_device"
[drivers/gpu/drm/xe/tests/xe_test.ko]
On Mon, Feb 26, 2024 at 01:46:37PM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
clang complains about a nonsensical test on builds with a 32-bit phys_addr_t,
which means resizing will always fail:
drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant
4294967296 with
On Wed, Feb 28, 2024 at 01:26:29PM +0100, Arnd Bergmann wrote:
On Mon, Feb 26, 2024, at 17:40, Lucas De Marchi wrote:
On Mon, Feb 26, 2024 at 01:46:38PM +0100, Arnd Bergmann wrote:
Fixes: 237412e45390 ("drm/xe: Enable 32bits build")
Signed-off-by: Arnd Bergmann
---
v2: use correct Fixes tag
While trying to reproduce some other issues reported by CI for i915
hangcheck live selftest, I found them hidden behind timeout failures
reported by igt_hang_sanitycheck -- the very first hangcheck test case
executed.
Feb 22 19:49:06 DUT1394ACMR kernel: calling mei_gsc_driver_init+0x0/0xff0
Hi,
I'm currently working on a platform that seems to have togglable RAM ECC
support. Enabling ECC reduces the memory capacity and memory bandwidth,
so while it's a good idea to protect most of the system, it's not worth
it for things like framebuffers that won't really be affected by a
bitflip.
On Wed, 28 Feb 2024, Mitul Golani wrote:
> -v12:
> - Update cover letter
Did you just send the entire series again within 30 minutes just to
update the cover letter? You could've just replied to the cover
letter...
BR,
Jani.
--
Jani Nikula, Intel
On 28/02/2024 16:08, Paweł Anikiel wrote:
> Hi Hans, thanks for the review!
>
> On Wed, Feb 28, 2024 at 12:24 PM Hans Verkuil
> wrote:
>>
>> Hi Paweł,
>>
>> On 21/02/2024 17:02, Paweł Anikiel wrote:
>>> Add v4l2 driver for the Google Chameleon v3 framebuffer device.
>>
>> This is just a video
Hi Hans, thanks for the review!
On Wed, Feb 28, 2024 at 12:24 PM Hans Verkuil wrote:
>
> Hi Paweł,
>
> On 21/02/2024 17:02, Paweł Anikiel wrote:
> > Add v4l2 driver for the Google Chameleon v3 framebuffer device.
>
> This is just a video capture device, right? A framebuffer device is something
>
Hi Anatoliy,
Thank you for the patch.
On Mon, Feb 26, 2024 at 08:44:42PM -0800, Anatoliy Klymenko wrote:
> Set layer mode of operation (live or dma-based) during layer creation.
>
> Each DPSUB layer mode of operation is defined by corresponding DT node port
> connection, so it is possible to
On Wed, 28 Feb 2024, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> I will lose access to my @.*intel.com e-mail addresses soon so let me
> adjust the maintainers entry and update the mailmap too.
>
> While at it consolidate a few other of my old emails to point to the
> main one.
>
>
On Wed, Feb 21, 2024 at 04:55:58PM +0800, Kunwu Chan wrote:
> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> to simplify the creation of SLAB caches.
>
> Signed-off-by: Kunwu Chan
Applied to drm-misc-next, thanks for your patch!
-Sima
> ---
>
Write/Read Adaptive sync SDP only when Sink and Source is enabled
for the same. Also along with write TRANS_VRR_VSYNC values.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
drivers/gpu/drm/i915/display/intel_dp.c | 4
Enable infoframe and add state checker for Adaptive Sync
SDP enablement.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display.c | 46
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
2 files changed, 48 insertions(+)
diff --git
Compute vrr_vsync_start/end, which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Updated VSYNC_START/END macros to VRR_VSYNC_START/END. (Ankit)
- Updated bit fields of VRR_VSYNC_START/END. (Ankit)
--v3:
- Add
Add necessary function definitions to compute AS SDP data.
The new intel_dp_compute_as_sdp function computes AS SDP
values based on the display configuration, ensuring proper
handling of Variable Refresh Rate (VRR).
--v2:
- Added DP_SDP_ADAPTIVE_SYNC to infoframe_type_to_idx(). [Ankit]
-
Add a wrapper function to check if both the source and
sink support Adaptive Sync SDP.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 8
drivers/gpu/drm/i915/display/intel_dp.h
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
1 - 100 of 174 matches
Mail list logo
