On Tue, 28 May 2024, Dmitry Baryshkov wrote:
> On Tue, May 28, 2024 at 12:04:49PM +0200, Ricard Wanderlof wrote:
> >
> > Even though data is truncated to 24 bits, the I2S interface does
> > accept 32 bit data (the slot widths according to the data sheet
> > can be 16 or 32 bits) so let the hw_p
Hi Gurchetan,
>
> On Fri, May 24, 2024 at 11:33 AM Kasireddy, Vivek
> mailto:vivek.kasire...@intel.com> > wrote:
>
>
> Hi,
>
> Sorry, my previous reply got messed up as a result of HTML
> formatting. This is
> a plain text version of the same reply.
>
> >
> >
>
Hi Dave & Sima -
drm-intel-fixes-2024-05-30:
drm/i915 fixes for v6.10-rc2:
- Fix a race in audio component by registering it later
- Make DPT object unshrinkable to avoid shrinking when framebuffer has
not shrunk
- Fix CCS id calculation to fix a perf regression
- Fix selftest caching mode
- F
On Wed, 29 May 2024, John Harrison wrote:
> On 5/28/2024 06:06, Michal Wajdeczko wrote:
>> This drm printer wrapper can be used to increase the robustness of
>> the captured output generated by any other drm_printer to make sure
>> we didn't lost any intermediate lines of the output by adding line
Please ignore this patch, V2 will be send out soon
Thanks
Zhu Lingshan
On 5/30/2024 12:02 PM, Huang Rui wrote:
> On Thu, May 30, 2024 at 11:41:04AM +0800, Zhu, Lingshan wrote:
>> ttm page fault handler ttm_bo_vm_fault_reserved() maps
>> TTM_BO_VM_NUM_PREFAULT more pages beforehand
>> due to the p
On Thu, 30 May 2024 at 04:59, Baolu Lu wrote:
>
> On 5/29/24 4:21 PM, Dmitry Baryshkov wrote:
> > On Wed, May 29, 2024 at 01:32:36PM +0800, Lu Baolu wrote:
> >> The domain allocated in msm_iommu_new() is for the @dev. Replace
> >> iommu_domain_alloc() with iommu_paging_domain_alloc() to make it ex
On Thu, 30 May 2024 at 07:41, Limonciello, Mario
wrote:
>
>
> >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
> >> someone needs this to work on non-ACPI system they get to figure out
> >> how to abstract it better. acpi_lid_open() does seem to return != 0
> >> when ACPI is
On 29/05/2024 15:33, Laurent Pinchart wrote:
On Wed, May 29, 2024 at 04:28:44PM +0300, Dmitry Baryshkov wrote:
On Wed, May 29, 2024 at 12:55:06PM +0300, Laurent Pinchart wrote:
On Wed, May 29, 2024 at 12:25:56PM +0300, Dmitry Baryshkov wrote:
On Wed, May 29, 2024 at 12:10:18PM +0300, Lauren
On Wed, May 29, 2024 at 04:44:59PM -0700, Abhinav Kumar wrote:
>
>
> On 5/24/2024 1:22 PM, Dmitry Baryshkov wrote:
> > On Fri, May 24, 2024 at 12:58:53PM -0700, Abhinav Kumar wrote:
> > >
> > >
> > > On 5/22/2024 3:24 AM, Dmitry Baryshkov wrote:
> > > > In the DPU driver blank IRQ handling is c
On Thu, May 30, 2024 at 09:17:03AM +0200, Ricard Wanderlof wrote:
>
> On Tue, 28 May 2024, Dmitry Baryshkov wrote:
>
> > On Tue, May 28, 2024 at 12:04:49PM +0200, Ricard Wanderlof wrote:
> > >
> > > Even though data is truncated to 24 bits, the I2S interface does
> > > accept 32 bit data (the sl
Hello,
V2 of this patch with discussed and recommended compatible string fixes and
updates to DT binding example code.
Original cover below.
--
The WL_355608_A8 panel is a VGA LCD display with an NV3052C-compatible driver
IC, used in a number of Anbernic handheld gaming devices. This patch add
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a
number of handheld gaming devices made by Anbernic. By consensus a
vendor prefix is not provided as the panel OEM is unknown.
Add a device tree binding for the panel.
Signed-off-by: Ryan Walklin
---
Changelog v1..v2:
- Correct c
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM used in a number of handheld gaming devices made by Anbernic.
Limited information is available online however the panel timing values
(below) have been obtained from the vendor BSP. The panel appears to
integrate a NV3052C
On Thu, 30 May 2024 at 11:16, Jocelyn Falempe wrote:
>
>
>
> On 29/05/2024 15:33, Laurent Pinchart wrote:
> > On Wed, May 29, 2024 at 04:28:44PM +0300, Dmitry Baryshkov wrote:
> >> On Wed, May 29, 2024 at 12:55:06PM +0300, Laurent Pinchart wrote:
> >>> On Wed, May 29, 2024 at 12:25:56PM +0300, Dmi
Hi everyone,
This series enables the PowerVR GPU found in the MT8173 SoC, found in
some Chromebooks.
This version is different from the initial powervr driver submission [1]
in that it splits out the GPU glue layer support out of the powervr
driver and into a separate clock and power domain drive
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.
The clock gates are exposed as clocks provided by a clock controller,
whi
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/imagination/pvr_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/imagination/pvr_drv.c
b
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.
The clock gates are exposed as clocks provided by a clock controller,
whi
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.
On top of the GPU is a glue layer that handles some clock and power
signals.
Add device nodes for both.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/medi
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
of the Series6XT GPUs, another sub-family of the Rogue family.
This was part of the very first few versions of the PowerVR submission,
but was later dropped. The compatible string has been updated to follow
the new naming scheme a
The MFG_ASYNC domain, which is likely associated to the whole MFG block,
currently specifies clk26m as its domain clock. This is bogus, since the
clock is an external crystal with no controls. Also, the MFG block has
a independent CLK_TOP_AXI_MFG_IN_SEL clock, which according to the block
diagram,
Hi,
On Thu, May 30, 2024 at 02:12:24AM GMT, Dmitry Baryshkov wrote:
> Allow passing NULL as audio infoframe as a way to disable Audio
> Infoframe generation.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++
> 1 file changed, 10 ins
On Thu, 30 May 2024 02:12:25 +0300, Dmitry Baryshkov wrote:
> Turn drm_bridge_connector to using drmm_kzalloc() and
> drmm_connector_init() and drop the custom destroy function. The
> drm_connector_unregister() and fwnode_handle_put() are already handled
> by the drm_connector_cleanup() and so are
Hi,
On Thu, May 30, 2024 at 02:12:26AM GMT, Dmitry Baryshkov wrote:
> In order to let bridge chains implement HDMI connector infrastructure,
> add necessary glue code to the drm_bridge_connector. In case there is a
> bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
> itself
On Thu, 30 May 2024 02:12:27 +0300, Dmitry Baryshkov wrote:
> Change MSM HDMI bridge to use atomic_* callbacks in preparation to
> enablign the HDMI connector support.
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
On Thu, May 30, 2024 at 02:12:28AM GMT, Dmitry Baryshkov wrote:
> Setup the HDMI connector on the MSM HDMI outputs. Make use of
> atomic_check hook and of the provided Infoframe infrastructure.
>
> Signed-off-by: Dmitry Baryshkov
As a general comment: I really like it, it looks super tidy.
With the support for the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR' case,
the connector_helper funcs are not initialized if the encoder has this
flag in its bridge_attach call. Till now we had mode_valid hook only in
the drm_connector_helper_funcs. Move this hook to drm_bridge_funcs to
validate the modes.
S
Currently, mode_valid hook returns all mode as valid and it is
defined only in drm_connector_helper_funcs. With the introduction of
'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
bridge_attach call for cases when the encoder has this flag enabled.
So move the mode_valid hook to d
Move the mode_valid hook to drm_bridge_funcs structure to take care
of the case when the encoder attaches the bridge chain with the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag in which case, the connector is not
initialized in the bridge's attach call and mode_valid is not called.
Also add this check to t
Check the pixel clock for the mode in atomic_check and ensure that
it is within the range supported by the bridge.
Signed-off-by: Jayesh Choudhary
---
drivers/gpu/drm/bridge/sii902x.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bri
On Thu, 30 May 2024 14:47:57 +0530, Jayesh Choudhary wrote:
> With the support for the 'DRM_BRIDGE_ATTACH_NO_CONNECTOR' case,
> the connector_helper funcs are not initialized if the encoder has this
> flag in its bridge_attach call. Till now we had mode_valid hook only in
> the drm_connector_helper
On 30.05.2024 09:49, Jani Nikula wrote:
> On Wed, 29 May 2024, John Harrison wrote:
>> On 5/28/2024 06:06, Michal Wajdeczko wrote:
>>> This drm printer wrapper can be used to increase the robustness of
>>> the captured output generated by any other drm_printer to make sure
>>> we didn't lost an
Hi,
On Thu, May 30, 2024 at 02:59:30PM GMT, Jayesh Choudhary wrote:
> Check the pixel clock for the mode in atomic_check and ensure that
> it is within the range supported by the bridge.
>
> Signed-off-by: Jayesh Choudhary
> ---
> drivers/gpu/drm/bridge/sii902x.c | 6 ++
> 1 file changed, 6
Update the Phy initialized state to "not initialized" when the driver
(and the hardware by extension) gets suspended. This will allow the Phy
to get initialized again after resume.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge
The order of init of DSI link and DSI phy is wrong. The DSI link needs
to be configured before the DSI phy is getting configured. Otherwise,
the D-Phy is unable to lock in on the incoming PLL Reference clock[0].
Fix the order of inits.
[0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC
Hello all,
This series provides some crucial fixes and improvements for the Cadence's DSI
TX (cdns-dsi) controller found commonly in Texas Instruments' J7 family of SoCs
as well as in AM62P.
Along with that, this series aims to fix the color-shift issue that has been
going on with the DSI control
Fix the OF node pointer passed to the of_drm_find_bridge() call to find
the next bridge in the display chain.
Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Once the DSI Link and DSI Phy are initialized, the code needs to wait
for Clk and Data Lanes to be ready, before continuing configuration.
This is in accordance with the DSI Start-up procedure, found in the
Technical Reference Manual of Texas Instrument's J721E SoC[0] which
houses this DSI TX contr
Allow the D-Phy config checks to use mode->clock instead of
mode->crtc_clock during mode_valid checks, like everywhere else in the
driver.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 2 +-
1
Move the bridge pre_enable call before crtc enable, and the bridge
post_disable call after the crtc disable.
The sequence of enable after this patch will look like:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_enable
bridge[1]
Change the existing (and deprecated) bridge hooks, to the bridge
atomic APIs.
Add drm helpers for duplicate_state, destroy_state, and bridge_reset
bridge hooks.
Further add support for the input format negotiation hook.
Signed-off-by: Aradhya Bhatia
---
.../gpu/drm/bridge/cadence/cdns-dsi-core
The cdns-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming[0]. Not having that, allows
for a small window before cdns-dsi enable and after cdns-dsi disable
where the previous entity (in this case tidss's videoport) to continue
streaming DPI vi
Allow the DCS Write FIFO in the cdns-dsi controller to reset before any
DCS packet is transmitted to the DSI sink device.
The DCS FIFO reset is optional. Not all panels require it. But at
least one of the DSI based panel that uses Ilitek ILI9881C (DSI to DPI
bridge) doesn't work with without this
Hi Maxime,
On 21/05/24 18:48, Maxime Ripard wrote:
> On Thu, May 16, 2024 at 04:33:40PM GMT, Aradhya Bhatia wrote:
>> Hi Maxime,
>>
>> Thank you for reviewing the patches.
>>
>> On 16/05/24 13:40, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
Hi Maxime,
On 28/05/24 17:13, Maxime Ripard wrote:
> On Fri, May 24, 2024 at 04:38:13PM GMT, Aradhya Bhatia wrote:
>> Hi Maxime,
>>
>> On 21/05/24 18:45, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Thu, May 16, 2024 at 03:10:15PM GMT, Aradhya Bhatia wrote:
>> /**
>> * @pre_e
Hello Maxime,
On 30/05/24 15:04, Maxime Ripard wrote:
Hi,
On Thu, May 30, 2024 at 02:59:30PM GMT, Jayesh Choudhary wrote:
Check the pixel clock for the mode in atomic_check and ensure that
it is within the range supported by the bridge.
Signed-off-by: Jayesh Choudhary
---
drivers/gpu/drm/b
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.
The clock gates are exposed
The duplicated EDID is never freed. Fix it.
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_v
Don't open code drm_edid_duplicate(). While at it, drop the error
message on allocation failure.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers
Avoid assigning fake_edid_info to ctx->raw_edid. Always keep
ctx->raw_edid either an allocated pointer or NULL. Defer fake_edid_info
handling to .get_modes().
This should be functionally equivalent but slightly easier to follow.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_drm_v
Prefer the struct drm_edid based functions for storing the EDID and
updating the connector.
It would be better if the vidi connection ioctl passed in the EDID size
separately instead of relying on the extension count specified in the
EDID, but that's what we have to rely on.
Signed-off-by: Jani N
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
of the Series6XT GPUs, another sub-family of the Rogue family.
This was part of the very first few versions of the PowerVR submission,
but was later dropped. The compatible string has
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MFG_ASYNC domain, which is likely associated to the whole MFG block,
currently specifies clk26m as its domain clock. This is bogus, since the
clock is an external crystal with no controls. Also, the MFG block has
a independent CLK_TOP_AXI_MFG_IN_SEL
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.
On top of the GPU is a glue layer that handles some clock and power
signals.
Add device nodes for both.
Signed-off-b
On Thu, May 30, 2024 at 5:59 PM AngeloGioacchino Del Regno
wrote:
>
> Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
> > The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
> > in the datasheet, that contains clock gates, some power sequence signal
> > delays, and other unknown re
Hi,
On 16/05/2024 13:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reduced re-spin of my previous series after Christian corrected a few
misconceptions that I had. So lets see if what remains makes sense or is still
misguided.
To summarise, the series address the following two issues:
*
Hi,
On 20/05/2024 12:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert fdinfo memory stats to use the common drm_print_memory_stats
helper.
This achieves alignment with the common keys as documented in
drm-usage-stats.rst, adding specifically drm-total- key the driver was
missing until
Hi,
Here's the first drm-misc-next PR for 6.11
Maxime
drm-misc-next-2024-05-30:
drm-misc-next for 6.11:
UAPI Changes:
- Deprecate DRM date and return a 0 date in DRM_IOCTL_VERSION
Core Changes:
- connector: Create a set of helpers to help with HDMI support
- fbdev: Create memory manager
On Thu, May 30, 2024 at 10:49:26AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 30, 2024 at 02:12:24AM GMT, Dmitry Baryshkov wrote:
> > Allow passing NULL as audio infoframe as a way to disable Audio
> > Infoframe generation.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/
On Thu, May 30, 2024 at 11:01:26AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 30, 2024 at 02:12:26AM GMT, Dmitry Baryshkov wrote:
> > In order to let bridge chains implement HDMI connector infrastructure,
> > add necessary glue code to the drm_bridge_connector. In case there is a
> > bridge
On Thu, May 30, 2024 at 11:16:08AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, May 30, 2024 at 02:12:28AM GMT, Dmitry Baryshkov wrote:
> > Setup the HDMI connector on the MSM HDMI outputs. Make use of
> > atomic_check hook and of the provided Infoframe infrastructure.
> >
> > Signed-off-by: Dmi
We'll want to stop drm_edid_block_valid() usage. KVMGT is the last
user. Replace with drm_edid_valid(), which unfortunately requires an
allocated drm_edid. However, on the plus side, this would be required to
handle the TODO comment about EDID extension block support.
Signed-off-by: Jani Nikula
drm_edid_block_valid() is no longer used outside of drm_edid.c. Make it
static.
Signed-off-by: Jani Nikula
---
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: intel-gvt-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 17
On Mon, 20 May 2024, Doug Anderson wrote:
> Hi,
>
> On Sun, May 19, 2024 at 2:01 AM Dmitry Baryshkov
> wrote:
>>
>> On Tue, May 14, 2024 at 03:55:14PM +0300, Jani Nikula wrote:
>> > Prefer the struct drm_edid based functions for reading the EDID and
>> > updating the connector.
>> >
>> > Simplify
Il 30/05/24 12:16, Chen-Yu Tsai ha scritto:
On Thu, May 30, 2024 at 5:59 PM AngeloGioacchino Del Regno
wrote:
Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence si
On Thu, 30 May 2024 at 15:45, Jani Nikula wrote:
>
> On Mon, 20 May 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, May 19, 2024 at 2:01 AM Dmitry Baryshkov
> > wrote:
> >>
> >> On Tue, May 14, 2024 at 03:55:14PM +0300, Jani Nikula wrote:
> >> > Prefer the struct drm_edid based functions for
Hi,
On Wed, 29 May 2024 16:42:44 +0200, Gerald Loacker wrote:
> At the jt240mhqs_hwt_ek_e3 panel, noticeable flickering occurs. This is
> addressed by patch 1, which adjusts the vertical timing. Patch 2 and 3 are
> two more minor fixes for timing and dimension.
>
>
Thanks, Applied to https://gi
We've accumulated enough Intel specific header files under include/drm
that they warrant a subdirectory of their own. Clean up the top drm
header directory by moving the Intel files under include/drm/intel.
Since i915 is most impacted, I suggest merging the lot via
drm-intel-next. Please ack if th
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Reviewed-by: Andi Shyti
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/char/agp/
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Tomas Winkler
Reviewed-by: Andi Shyti
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
v2: Also change Documentation/gpu/i915.rst (Andi)
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Tomas Winkler
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Lucas D
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Reviewed-by: Andi Shyti
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
v2: Also fix comment in intel_pci_config.h (Ilpo)
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Bjorn Helgaas
Cc: Hans de Goede
Cc: Ilpo Järvinen
Acked-by: Lucas De
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Tomas Winkler
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/px
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/xe/xe_pci.c | 2 +-
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Bjorn Helgaas
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
arch/x86/kernel/early-q
Clean up the top level include/drm directory by grouping all the Intel
specific files under a common subdirectory.
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Lucas De Marchi
Cc: Tomas Winkler
Acked-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/di
With all the Intel specific drm files under include/drm/intel, update
the i915, xe, and the shared display entries. Do not discriminate based
on file name pattern, just add the entire directory for all three
entries.
Cc: Joonas Lahtinen
Cc: Lucas De Marchi
Cc: Oded Gabbay
Cc: Rodrigo Vivi
Cc:
Abhinav,
On 08/05/2024 21:52, Jon Hunter wrote:
On 08/05/2024 17:46, Abhinav Kumar wrote:
On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails
with ...
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_head
On Thu, 30 May 2024, Mitul Golani wrote:
> Move VRR related register definitions to a separate file called
> intel_vrr_regs.h.
But this is not just movement... there's a bunch of other (mostly
unwanted?) changes there too.
'git show --color-moved' is a powerful tool for reviewing code
movement.
On Thu, May 30, 2024 at 03:06:13PM +0530, Aradhya Bhatia wrote:
> Fix the OF node pointer passed to the of_drm_find_bridge() call to find
> the next bridge in the display chain.
Please describe why, not what. In other words, please describe why you
have to pass np, no device's of_node.
>
> Fixes
Hi,
On Tue, May 28, 2024 at 4:52 PM Dmitry Baryshkov
wrote:
>
> Add a fat warning against adding new panel compatibles to the panel-edp
> driver. All new users of the eDP panels are supposed to use the generic
> "edp-panel" compatible device on the AUX bus. The remaining compatibles
> are either
Hi,
On Tue, May 28, 2024 at 4:53 PM Dmitry Baryshkov
wrote:
>
> The panel-edp driver supports legacy compatible strings for several eDP
> panels which were never used in DT files present in Linux tree and most
> likely have never been used with the upstream kernel. Drop compatibles
> for these pa
Hi,
On Tue, May 28, 2024 at 4:53 PM Dmitry Baryshkov
wrote:
>
> The panel-simple.yaml includes legacy bindings for several eDP panels
> which were never used in DT files present in Linux tree and most likely
> have never been used with the upstream kernel. Drop compatibles for
> these panels in f
Applied. Thanks!
On Wed, May 29, 2024 at 5:54 PM Nathan Chancellor wrote:
>
> From: Bill Wendling
>
> Work for __counted_by on generic pointers in structures (not just
> flexible array members) has started landing in Clang 19 (current tip of
> tree). During the development of this feature, a re
From: Palmer Dabbelt
I get a handful of build errors along the lines of
linux/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13:
error: stack frame size (2352) exceeds limit (2048) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalcu
On Tue, May 28, 2024 at 01:39:52PM GMT, Arnaud Vrac wrote:
> On 28/05/2024 11:17, Maxime Ripard wrote:
> > On Tue, May 28, 2024 at 10:05:50AM GMT, Arnaud Vrac wrote:
> > > On 28/05/2024 09:43, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Mon, May 27, 2024 at 06:03:56PM GMT, Marc Gonzalez wr
On Tue, May 28, 2024 at 07:15:34AM GMT, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime,
>
> On Mon, 2024-05-27 at 16:06 +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Sun, May 26, 2024 at 07:29:21AM GMT, Jason-JH.Lin wrote:
> > > From: Jason-jh Lin
> > >
> > > Memory Definitions:
> > > secure memory - M
Since the default number 256 can't handle large modern systems
with large numbers of GPUs, specify a more reasonable default.
Signed-off-by: James Zhu
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm
On Thu, May 30, 2024 at 04:35:02PM +0800, Chen-Yu Tsai wrote:
> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
> of the Series6XT GPUs, another sub-family of the Rogue family.
>
> This was part of the very first few versions of the PowerVR submission,
> but was later dropped.
On Thu, May 30, 2024 at 04:35:00PM +0800, Chen-Yu Tsai wrote:
> The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
> in the datasheet, that contains clock gates, some power sequence signal
> delays, and other unknown registers that get toggled when the GPU is
> powered on.
>
>
On Thu, May 30, 2024 at 08:22:22PM +1200, Ryan Walklin wrote:
> The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a
> number of handheld gaming devices made by Anbernic.
> By consensus a
> vendor prefix is not provided as the panel OEM is unknown.
Reviewed-by: Conor Dooley
> +exam
On Thu, May 30, 2024 at 08:22:22PM +1200, Ryan Walklin wrote:
> +port {
> + endpoint {
^
You accidentally added a tab here:
/stuff/linux/.git/worktrees/linux-dt/rebase-apply/patch:71: space before tab in
indent.
endpoint {
warning: 1 line add
Hi Chen-Yu,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Chen-Yu-Tsai/dt-bindings-clock-mediatek-Add-mt8173-mfgtop/20240530-163739
base
Hi Chen-Yu,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Chen-Yu-Tsai/dt-bindings-clock-mediatek-Add-mt8173-mfgtop/20240530-163739
base
Hi Dave, Sima
The drm-xe-fixes for -rc2
Only three fixes so far. I'm holding back one additional
fix to be able to sort out whether it's correct or need more work.
drm-xe-fixes-2024-05-30:
Driver Changes:
- One pcode polling timeout change
- One fix for deadlocks for faulting VMs
- One error-pat
On Wed May 8, 2024 at 1:04 AM CEST, Abhinav Kumar wrote:
> Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
> compilation is broken on machines having python versions older than 3.9
> due to dependency on argparse.BooleanOptionalAction.
>
> Switch to use simple bool for
On Fri, May 24, 2024 at 12:57:58PM -0700, Abhinav Kumar wrote:
> Hello
>
> On 5/24/2024 12:55 PM, Paul E. McKenney wrote:
> > Hello!
> >
> > I get the following allmodconfig build error on x86 in next-20240523:
> >
> > Traceback (most recent call last):
> > File "drivers/gpu/drm/msm/registers
1 - 100 of 182 matches
Mail list logo
