Now that include/linux/bits.h implements fixed-width GENMASK_*, use them
to implement the i915/xe specific macros. Converting each driver to use
the generic macros are left for later, when/if other driver-specific
macros are also generalized.
Signed-off-by: Lucas De Marchi
Acked-by: Jani Nikula
From: Yury Norov
Generalize __GENMASK() to support different types, and implement
fixed-types versions of GENMASK() based on it. The fixed-type version
allows more strict checks to the min/max values accepted, which is
useful for defining registers like implemented by i915 and xe drivers
with
ove the implementation of REG_GENMASK/REG_BIT to a more appropriate
place to be shared by i915, xe and possibly other parts of the kernel.
For now this re-defines the old macros. In future we may start using the
new macros directly, but that's a more intrusive search-and-replace.
Changes from
Implement fixed-type BIT() to help drivers add stricter checks, like was
done for GENMASK.
Signed-off-by: Lucas De Marchi
Acked-by: Jani Nikula
---
include/linux/bits.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/bits.h b/include/linux/bits.h
index
Am 07.02.24 um 18:44 schrieb Arunpravin Paneer Selvam:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in
Am 08.02.24 um 01:36 schrieb Dave Airlie:
Just cc'ing some folks. I've also added another question.
On Wed, 7 Feb 2024 at 21:08, Maíra Canal wrote:
Adding another point to this discussion, would it make sense to somehow
create a generic structure that all drivers, including shmem drivers,
Hi,
On 2024/1/29 18:29, Daniel Stone wrote:
Hi Lucas,
On Fri, 26 Jan 2024 at 17:00, Lucas Stach wrote:
The dma sync operation needs to be done with DMA_BIDIRECTIONAL when
the BO is prepared for both read and write operations. With the
current inverted if ladder it would only be synced for
On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" wrote:
> On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote:
> > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"
> > > wrote:
> > >
> > > > > > Fixing
On 8/2/24 04:21, Mario Limonciello wrote:
> On 2/7/2024 03:51, Daniel Vetter wrote:
>> On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
>>> On 6/2/24 23:41, Mario Limonciello wrote:
On 2/6/2024 08:21, Daniel Vetter wrote:
> On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel
Just cc'ing some folks. I've also added another question.
On Wed, 7 Feb 2024 at 21:08, Maíra Canal wrote:
>
> Adding another point to this discussion, would it make sense to somehow
> create a generic structure that all drivers, including shmem drivers,
> could use it?
>
> Best Regards,
> -
All of the selects on ACPI_VIDEO are unnecessary when DRM does the
select for ACPI_VIDEO as it provides a helper for acpi based EDID.
Reviewed-by: Pranjal Ramajor Asha Kanojiya
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/Kconfig | 7 ---
drivers/gpu/drm/gma500/Kconfig
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers can call this
helper to attempt to fetch the EDID from the BIOS's ACPI _DDC method.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/Kconfig| 5 +++
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Convert the usage in nouveau_connector_detect_lvds() to use
struct
The drm_get_acpi_edid() helper is for drivers that would prefer
to get the EDID from ACPI instead of from the panel.
Earlier versions of this series were aimed at using this in amdgpu
and nouveau.
This version does NOT update amdgpu as the change will require a
larger overhaul to use struct
On Wed, Feb 07, 2024 at 10:48:43PM +0200, Imre Deak wrote:
> On Wed, Feb 07, 2024 at 10:02:18PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > + [...]
> > > +static int group_allocated_bw(struct drm_dp_tunnel_group *group)
> > > +{
> > > + struct
From: Sohaib Nadeem
[ Upstream commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a ]
[why]
Originally, PMFW said min FCLK is 300Mhz, but min DCFCLK can be increased
to 400Mhz because min FCLK is now 600Mhz so FCLK >= 1.5 * DCFCLK hardware
requirement will still be satisfied. Increasing min DCFCLK
From: Sohaib Nadeem
[ Upstream commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a ]
[why]
Originally, PMFW said min FCLK is 300Mhz, but min DCFCLK can be increased
to 400Mhz because min FCLK is now 600Mhz so FCLK >= 1.5 * DCFCLK hardware
requirement will still be satisfied. Increasing min DCFCLK
From: Mukul Joshi
[ Upstream commit 4119734e06a7f30e7e8eb92a58b85dca0269 ]
On GFX 9.4.3, for a given KFD node, fetch the correct drm device from
XCP manager when checking for cgroup permissions.
Signed-off-by: Mukul Joshi
Reviewed-by: Harish Kasiviswanathan
Signed-off-by: Alex Deucher
On 2/7/2024 12:47, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
On 2/7/2024 11:43, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56,
From: Dmytro Laktyushkin
[ Upstream commit 31c2bf25eaf51c2d45f092284a28e97f43b54c15 ]
[Why]
Secondary DP2 display fails to light up in some instances
[How]
Clock needs to be on when DPSTREAMCLK*_EN =1. This change
moves dtbclk_p enable/disable point to make sure this is
the case
Reviewed-by:
From: Sohaib Nadeem
[ Upstream commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a ]
[why]
Originally, PMFW said min FCLK is 300Mhz, but min DCFCLK can be increased
to 400Mhz because min FCLK is now 600Mhz so FCLK >= 1.5 * DCFCLK hardware
requirement will still be satisfied. Increasing min DCFCLK
From: Mukul Joshi
[ Upstream commit 4119734e06a7f30e7e8eb92a58b85dca0269 ]
On GFX 9.4.3, for a given KFD node, fetch the correct drm device from
XCP manager when checking for cgroup permissions.
Signed-off-by: Mukul Joshi
Reviewed-by: Harish Kasiviswanathan
Signed-off-by: Alex Deucher
From: Charlene Liu
[ Upstream commit b5abd7f983e14054593dc91d6df2aa5f8cc67652 ]
[why]
BIOS's integration info table not following the original order
which is phy instance is ext_displaypath's array index.
[how]
Move them to follow the original order.
Reviewed-by: Muhammad Ahmed
Acked-by: Tom
On Wed, Feb 07, 2024 at 10:48:53PM +0200, Imre Deak wrote:
> On Wed, Feb 07, 2024 at 10:02:18PM +0200, Ville Syrjälä wrote:
> > > [...]
> > > +static int
> > > +drm_dp_tunnel_atomic_check_group_bw(struct drm_dp_tunnel_group_state
> > > *new_group_state,
> > > + u32
Hi Dmitry,
On 2/7/24 12:00, Dmitry Baryshkov wrote:
On Tue, 6 Feb 2024 at 01:57, wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
As you don't seem to be the
On Wed, Feb 07, 2024 at 10:02:18PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > +static char yes_no_chr(int val)
> > +{
> > + return val ? 'Y' : 'N';
> > +}
>
> We have str_yes_no() already.
Ok, will use this.
> v> +
> > +#define
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
> On 2/7/2024 11:43, Souza, Jose wrote:
> > On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> > > On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > > > On 07/02/2024 18:12, John Harrison wrote:
> > > > > On 2/7/2024 03:56, Tvrtko Ursulin
Hi Dave,
A few fixes for v6.8, description below
The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:
drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)
are available in the Git repository at:
y-pixel is the culprit, but I don't see why it wouldn't be.
>>>
>>> I just need to do some final touches on the benchmark code and it
>>> will be ready for revision.
>>
>> Awesome, thank you very much for doing that!
>> pq
>
> I also think it's a good benchmarks for classic configurations. The odd
> size is a very nice idea to verify the corner cases of line-by-line
> algorithms.
>
> When this is ready, please share the test, so I can check if my patch is
> as performant as before.
>
> Thank you for this work.
>
> Have a nice day,
> Louis Chauvet
>
Just sent the benchmark for revision:
https://lore.kernel.org/r/20240207-bench-v1-1-7135ad426...@riseup.net
On 2/7/2024 03:51, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 10:03:10AM +0800, Daniel van Vugt wrote:
On 6/2/24 23:41, Mario Limonciello wrote:
On 2/6/2024 08:21, Daniel Vetter wrote:
On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote:
Until now, deferred console takeover
);
+
+ igt_output_set_writeback_fb(data.wb_output,
[fb_index]);
+
+ igt_display_commit2(, COMMIT_ATOMIC);
+ }
+
+ igt_display_fini();
+ drm_close_driver(data.fd);
+}
---
base-commit: c58c5fb6aa1cb7d3627a15e364816a7a2add9edc
change-id: 20240207-bench-393789eaba47
Best regards,
--
Arthur Grillo
On 2/7/2024 11:56 AM, Dmitry Baryshkov wrote:
On Wed, 7 Feb 2024 at 20:48, Abhinav Kumar wrote:
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions
On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> +static char yes_no_chr(int val)
> +{
> + return val ? 'Y' : 'N';
> +}
We have str_yes_no() already.
v> +
> +#define SKIP_DPRX_CAPS_CHECK BIT(0)
> +#define ALLOW_ALLOCATED_BW_CHANGEBIT(1)
> +
> +static bool
On Wed, 7 Feb 2024 at 20:25, Abhinav Kumar wrote:
>
>
>
> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> > Older (mdp5) platforms do not use per-SoC compatible strings. Instead
> > they use a single compat entry 'qcom,mdss'. To facilitate migrating
> > these platforms to the DPU driver provide a
On Wed, 7 Feb 2024 at 20:48, Abhinav Kumar wrote:
>
>
>
> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> > Existing MDP5 devices have slightly different bindings. The main
> > register region is called `mdp_phys' instead of `mdp'. Also vbif
> > register regions are a part of the parent, MDSS
Hi Dave,
A few fixes for v6.8, description below
The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b:
drm/msm/dp: call dp_display_get_next_bridge() during probe
(2023-12-14 09:27:46 +0200)
are available in the Git repository at:
On 2/7/2024 11:43, Souza, Jose wrote:
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > On 07/02/2024 18:12, John Harrison wrote:
> > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Add a new query to the GuC submission interface version.
>
On Wed, 7 Feb 2024 at 19:52, Abhinav Kumar wrote:
>
>
>
> On 10/5/2023 3:06 PM, Dmitry Baryshkov wrote:
> > The frame event callback is always set to dpu_crtc_frame_event_cb() (or
> > to NULL) and the data is always either the CRTC itself or NULL
> > (correpondingly). Thus drop the event callback
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
Changes since v2
(https://lore.kernel.org/linux-spi/cover.1705944943.git.u.kleine-koe...@pengutronix.de):
- Drop patch "mtd: rawnand: fsl_elbc: Let .probe retry if local bus is
missing" which doesn't belong into this series.
- Fix a build failure noticed by the kernel build bot in
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Greg Kroah-Hartman
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Acked-by: Jonathan Cameron
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU
syzbot has bisected this issue to:
commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
Author: Daniel Vetter
Date: Fri Oct 9 23:21:56 2020 +
drm/vkms: fbdev emulation support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1282dbffe8
start commit: 6764c317b6bb Merge
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute command streamers
simultaneously can cause GPU
On Tue, Feb 6, 2024 at 4:30 PM Ian Forbes wrote:
>
> So the issue is that SVGA_3D_CMD_DX_PRED_COPY_REGION between 2
> surfaces that are the size of the mode fails. Technically for this to
> work the filter will have to be 1/2 of graphics mem. I was just lucky
> that the next mode in the list was
They rather fundamentally break the entire concept of zero copy, so if
an exporter manages to hand these out things will break all over.
Luckily there's not too many case that use
swiotlb_sync_single_for_device/cpu():
- The generic iommu dma-api code in drivers/iommu/dma-iommu.c. We can
catch
On 10/5/2023 3:06 PM, Dmitry Baryshkov wrote:
The frame event callback is always set to dpu_crtc_frame_event_cb() (or
to NULL) and the data is always either the CRTC itself or NULL
(correpondingly). Thus drop the event callback registration, call the
dpu_crtc_frame_event_cb() directly and
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if
On Fri, Jan 19, 2024 at 03:13:58PM +0100, Paul Cercueil wrote:
> Implement .begin_access() and .end_access() callbacks.
>
> For now these functions will simply sync/flush the CPU cache when
> needed.
>
> Signed-off-by: Paul Cercueil
>
> ---
> v5: New patch
> ---
> drivers/dma-buf/udmabuf.c |
The 2024 X.Org Foundation elections are rapidly approaching. We will be
forwarding the election schedule and nominating process to the
membership shortly.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in
Am 07.02.24 um 17:13 schrieb Randy Dunlap:
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes: dae7fbf43fd0 ("driver/ps3: Include for mode parsing")
Fixes: a3b6792e990d
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes: dae7fbf43fd0 ("driver/ps3: Include for mode parsing")
Fixes: a3b6792e990d ("video/cmdline: Introduce CONFIG_VIDEO for
Hello Pekka, Arthur,
[...]
> > > Would it be possible to have a standardised benchmark specifically
> > > for performance rather than correctness, in IGT or where-ever it
> > > would make sense? Then it would be simple to tell contributors to
> > > run this and report the numbers before and
$subject: dt-bindings: display: bridge: add sam9x75-lvds compatible
If there's a respin for some reason, please update the subject to match
what the commit is actually doing (adding a whole binding).
Cheers,
Conor.
signature.asc
Description: PGP signature
Hello Pekka, Arthur, Maxime,
> > > >> Change the composition algorithm to iterate over pixels instead of
> > > >> lines.
> > > >> It allows a simpler management of rotation and pixel access for
> > > >> complex formats.
> > > >>
> > > >> This new algorithm allows
Hi,
On 2024/2/5 16:24, Thomas Zimmermann wrote:
Hi
Am 02.02.24 um 16:23 schrieb Sui Jingfeng:
Hi,
On 2024/2/2 19:58, Thomas Zimmermann wrote:
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux
Hello.
On Tue, Oct 24, 2023 at 05:07:20PM +0100, Tvrtko Ursulin
wrote:
> +struct drm_cgroup_state {
> + struct cgroup_subsys_state css;
> +};
> +
> +struct drm_root_cgroup_state {
> + struct drm_cgroup_state drmcs;
> +};
> +
> +static struct drm_root_cgroup_state root_drmcs;
Special
Hello.
(I hope I'm replying to the latest iteration and it has some validitiy
still. Sorry for my late reply. Few points caught my attention.)
On Tue, Oct 24, 2023 at 05:07:25PM +0100, Tvrtko Ursulin
wrote:
> @@ -15,10 +17,28 @@ struct drm_cgroup_state {
> struct cgroup_subsys_state css;
Hi,
On 2024/2/7 17:35, Daniel Vetter wrote:
On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
The component helper functions are the glue, which is used to bind multiple
GPU cores to a virtual master platform device. Which is fine and works well
for the SoCs who contains multiple
Quoting Tvrtko Ursulin (2024-02-07 13:56:12)
> From: Tvrtko Ursulin
>
> Add a new query to the GuC submission interface version.
>
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
> simultaneously
All entries fit in 82 columns, which is acceptable: compress all of
the mtk_dsi_of_match[] entries to a single line for each.
While at it, also add the usual sentinel comment to the last entry.
Reviewed-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
Registering the dsi host with its ops before getting dsi->regs is
simply wrong: even though there's nothing (for now) asynchronously
calling those ops before the end of the probe function, installing
ops that are using iospace(s) and clocks before even initializing
those is too fragile.
Register
In mtk_dsi_phy_timconfig(), we're dividing the `data_rate` variable,
expressed in Hz to retrieve a value in MHz: instead of open-coding,
use the HZ_PER_MHZ definition, available in linux/units.h.
Reviewed-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
Instead of open coding, use the mipi_dsi_pixel_format_to_bpp() helper
function from drm_mipi_dsi.h in mtk_dsi_poweron() and for validation
in mtk_dsi_bridge_mode_valid().
Note that this function changes the behavior of this driver: previously,
in case of unknown formats, it would (wrongly) assume
Most of the functions that are called in the probe callback are
devm managed, or all but mipi_dsi_host_register(): simplify the probe
function's error paths with dev_err_probe() and remove the lonely
instance of `goto err_unregister_host` by just directly calling the
mipi_dsi_host_unregister()
Instead of open coding bitshifting for various register fields,
use the bitfield macro FIELD_PREP(): this allows to enhance the
human readability, decrease likeliness of mistakes (and register
field overflowing) and also to simplify the code.
The latter is especially seen in
Change magic numerical masks with usage of the GENMASK() macro
to improve readability.
This commit brings no functional changes.
Reviewed-by: Alexandre Mergnat
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 45 +++---
1 file
Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
merge the two in one mtk_dsi_ps_control() function by adding one
function parameter `config_vact` which, when true, writes the VACT
related registers.
Reviewed-by: Fei Shao
Reviewed-by: Alexandre Mergnat
Signed-off-by:
The register bits definitions for RGB666 formats are wrong in multiple
ways: first, in the DSI_PS_SEL bits region, the Packed 18-bits RGB666
format is selected with bit 1, while the Loosely Packed one is bit 2,
and second - the definition name "LOOSELY_PS_18BIT_RGB666" is wrong
because the loosely
Changes in v5:
- Changed patch 1 to not fix the DSI_PS_SEL mask for newer SoCs
Changes in v4:
- Added a fix for RGB666 formats setting and for wrong register
definitions for packed vs loosely packed formats
- Added a commit to make use of mipi_dsi_pixel_format_to_bpp() helper
instead of
On Wed, Nov 22, 2023 at 1:49 PM Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional
For vfio_ap_ops.c
Reviewed-by: Anthony Krowiak
On 2/6/24 2:44 PM, Stefan Hajnoczi wrote:
vhost and VIRTIO-related parts:
Reviewed-by: Stefan Hajnoczi
On Wed, 22 Nov 2023 at 07:50, Christian Brauner wrote:
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d
On Wed, Feb 07, 2024 at 01:25:19AM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2024 at 12:28:45PM +0200, Imre Deak wrote:
> > Compute the BW required through a DP tunnel on links with such tunnels
> > detected and add the corresponding atomic state during a modeset.
> >
> > Signed-off-by: Imre
On Wed, Feb 07, 2024 at 05:17:19PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
> nonexisting document 'gpu/rfc/xe'
>
>
On Thu, 11 Jan 2024 11:17:30 +0100, Julien Stephan wrote:
> This is a new driver that supports the MIPI CSI CD-PHY version 0.5
>
> The number of PHYs depend on the SoC.
> Each PHY can support D-PHY only or CD-PHY configuration.
> The driver supports only D-PHY mode, so CD-PHY
> compatible PHY
On Tue, Feb 06, 2024 at 11:45:58PM +, Kuninori Morimoto wrote:
>
> Hi Laurent
>
> Thank you for your review
>
> > > diff --git a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
> > > b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
> > > index 686ca8753ba2..3f8bea2e3934 100644
On Wed, Feb 07, 2024 at 02:13:05PM +0100, Krzysztof Hałasa wrote:
> Laurent,
>
> Laurent Pinchart writes:
>
> >> +++ b/drivers/media/i2c/adv7604.c
> >> @@ -3205,7 +3205,7 @@ static int adv76xx_parse_dt(struct adv76xx_state
> >> *state)
> >> np =
On 07/02/2024 14:51, Laurent Pinchart wrote:
> On Wed, Feb 07, 2024 at 02:14:33PM +0100, Krzysztof Hałasa wrote:
>> Hans,
>>
>> Hans Verkuil writes:
>>
>>> Ideally someone would have to actually test this, perhaps with one of those
>>> Renesas boards. While I do have one, it got bricked after I
On Wed, Feb 07, 2024 at 02:14:33PM +0100, Krzysztof Hałasa wrote:
> Hans,
>
> Hans Verkuil writes:
>
> > Ideally someone would have to actually test this, perhaps with one of those
> > Renesas boards. While I do have one, it got bricked after I attempted a
> > u-boot update :-(
>
> May be
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is
There will be no EFI framebuffer device for disabled parent devices
and thus we never probe efifb in that case. Hence remove the tracking
code from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/efifb.c | 5 +
1 file changed, 1
Detect the firmware framebuffer's parent device from the global
screen_info state and set up the framebuffer's device accordingly.
Remove the equivalent functionality from efifb. Other drivers for
firmware framebuffers, such as simpledrm or vesafb, now add these
new features.
Patches 1 and 2
If the firmware framebuffer has been reloacted, the sysfb code
fixes the screen_info state before it creates the framebuffer's
platform device. Efifb will automatically receive a screen_info
with updated values. Hence remove the tracking from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.
So far, efifb tracked the status of the PCI parent device internally
and
Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.
v3:
* search PCI device with pci_get_base_class() (Sui)
v2:
* remove ret from screen_info_pci_dev() (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by:
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.
Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the
The EFI device has the correct parent device set. This allows Linux
to handle the power management internally. Hence, remove the manual
PM management for the parent device from efifb.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/efifb.c | 16
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in
On 24/01/2024 04:53, Anatoliy Klymenko wrote:
Add few missing pieces to support ZynqMP DPSUB live video in mode.
ZynqMP DPSUB supports 2 modes of operations in regard to video data
input.
In the first mode, DPSUB uses DMA engine to pull video data from memory
buffers. To support this the
Laurent,
Laurent Pinchart writes:
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -3205,7 +3205,7 @@ static int adv76xx_parse_dt(struct adv76xx_state
>> *state)
>> np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node;
>>
>> /* Parse the endpoint. */
>> - endpoint =
Hans,
Hans Verkuil writes:
> Ideally someone would have to actually test this, perhaps with one of those
> Renesas boards. While I do have one, it got bricked after I attempted a
> u-boot update :-(
May be reversible, though.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy
On Fri, Feb 02, 2024 at 12:15:40PM -0400, Jason Gunthorpe wrote:
> > Yes looks like a race of some sort. Adding a bit of debug also makes the
> > issue go away so difficult to see what is happening.
>
> I'm wondering if it is racing with iommu driver probing? I looked but
> didn't notice
On Wed, Feb 07, 2024 at 01:08:43AM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2024 at 12:28:42PM +0200, Imre Deak wrote:
> > Add support to enable the DP tunnel BW allocation mode. Follow-up
> > patches will call the required helpers added here to prepare for a
> > modeset on a link with DP
On Wed, Feb 7, 2024 at 3:24 AM Neil Armstrong wrote:
>
> On 07/02/2024 10:22, Fabio Estevam wrote:
> > Hi Adam,
> >
> > On Tue, Feb 6, 2024 at 9:23 PM Adam Ford wrote:
> >>
> >> Two separate build warnings were reported. One from an
> >> uninitialized variable, and the other from returning 0
>
1 - 100 of 133 matches
Mail list logo
