On 20/02/2024 22:23, Konrad Dybcio wrote:
> On 20.02.2024 18:31, Dmitry Baryshkov wrote:
>> The patch adding Type-C support for sm6115 was misapplied. All the
>> orientation switch configuration ended up at the UFS PHY node instead of
>> the USB PHY node. Move the data bits to the correct place.
Hi Alexander,
Thanks for your comments,
>
> Hi,
>
> thanks for the update.
>
> Am Dienstag, 20. Februar 2024, 04:23:55 CET schrieb Sandor Yu:
> > Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.
> >
> > Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base
> on
> > the configuration
Hi Alexander,
Thanks for your comments,
>
>
> Hi,
>
> thanks for the update.
>
> Am Dienstag, 20. Februar 2024, 04:23:53 CET schrieb Sandor Yu:
> > Add bindings for Freescale iMX8MQ DP and HDMI PHY.
> >
> > Signed-off-by: Sandor Yu
> > Reviewed-by: Rob Herring
> > ---
> > v9->v14:
> > *No
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages
Hi Lucas,
On Tue, 20 Feb 2024 23:29:54 -0600 Lucas De Marchi
wrote:
>
> Looking at
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e
> it seems we still don't have drm-xe-next branch in linux-next.
>
> Stephen, could you
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e Add linux-next specific
files for 20240220
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402210011.c42qmsp5-...@intel.com
Error
Add the LCD controller layer definition and descriptor structure for
sam9x75 for the following layers:
- Base Layer
- Overlay1 Layer
- Overlay2 Layer
- High End Overlay
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 100 +++
1 file
Add support for the following DPI mode if the encoder type
is DSI as per the XLCDC IP datasheet:
- 16BPPCFG1
- 16BPPCFG2
- 16BPPCFG3
- 18BPPCFG1
- 18BPPCFG2
- 24BPP
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update output format using is_xlcdc flag]
Signed-off-by:
Update the vertical and horizontal scaler registers of XLCDC IP
with Bilinear and Bicubic co-efficients taps for Chroma and
Luma componenets of the Pixel.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4
Add support for Display Pixel Interface (DPI) Compatible Mode
support in atmel-hlcdc driver for XLCDC IP along with legacy
pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register.
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update DPI mode bit using is_xlcdc
Add XLCDC specific driver ops and is_xlcdc flag to separate the
functionality and to access the controller registers.
HEO scaling, window resampling, Alpha blending, YUV-to-RGB
conversion in XLCDC is derived and handled using additional
configuration bits and registers. Writing one to the Enable
From: Durai Manickam KR
The register address of the XLCDC IP used in SAM9X7 SoC family
are different from the previous HLCDC. Defining those address
space with valid macros.
Signed-off-by: Durai Manickam KR
[manikanda...@microchip.com: Remove unused macro definitions]
Signed-off-by: Manikandan
Add LCD IP specific ops in driver data to differentiate
HLCDC and XLCDC code within the atmel-hlcdc driver files.
XLCDC in SAM9X7 has different sets of registers and additional
configuration bits when compared to previous HLCDC IP. Read/write
operation on the controller register and functionality
This patch series aims to add support for XLCDC IP of sam9x7 SoC family
to the DRM subsystem.XLCDC IP has additional registers and new
configuration bits compared to the existing register set of HLCDC IP.
The new compatible string "microchip,sam9x75-xlcdc" is defined for sam9x75
variant of the
+Stephen
On Tue, Feb 13, 2024 at 03:58:54PM +0100, Arnd Bergmann wrote:
On Tue, Feb 13, 2024, at 15:55, Jani Nikula wrote:
On Tue, 13 Feb 2024, Arnd Bergmann wrote:
From: Arnd Bergmann
Some of the debugfs functions are stubbed out in these configurations,
so trying to build the .c file
Hi Stephen,
On Tue, 20 Feb 2024 at 22:46, Stephen Rothwell wrote:
> On Tue, 20 Feb 2024 11:25:05 + Daniel Stone wrote:
> > cc sfr - once we move the DRM repos to a different location, what's
> > the best way to update linux-next?
>
> These are (I think) all the drm trees/branches that I
Hi Tvrtko,
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
> On 20/02/2024 14:35, Andi Shyti wrote:
> > Enable only one CCS engine by default with all the compute sices
>
> slices
Thanks!
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> >
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq
Hi Matt,
thanks a lot for looking into this.
On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
[...]
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index
On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
>
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
>
> This
On Tue, Feb 20, 2024 at 03:35:25PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi
On Wed, 21 Feb 2024 at 01:04, Abhinav Kumar wrote:
>
>
>
> On 2/20/2024 2:42 PM, Dmitry Baryshkov wrote:
> > On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar
> >>> wrote:
On 2/20/2024 2:42 PM, Dmitry Baryshkov wrote:
On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar wrote:
On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar wrote:
On 2/14/2024 11:20 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:02, Abhinav
On Wed, 21 Feb 2024 at 00:50, Abel Vesa wrote:
>
> Add the X1E80100 DP descs and compatible. This platform will be using
> a single compatible for both eDP and DP mode. The actual mode will
> be set in devicetree via is-edp flag.
>
> Signed-off-by: Abel Vesa
> ---
>
On Wed, 21 Feb 2024 at 00:50, Abel Vesa wrote:
>
> Instead of relying on different compatibles for eDP and DP, use
> the is-edp property from DT to figure out the connector type and
> then pass on that information to the PHY.
>
> Signed-off-by: Abel Vesa
> ---
> drivers/gpu/drm/msm/dp/dp_ctrl.c
Add the X1E80100 to the list of compatibles and docoment the is-edp
flag. This new flag will be used from now on to dictate the mode from
devicetree, instead of having separate compatibles for eDP and DP.
Signed-off-by: Abel Vesa
---
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set in devicetree via is-edp flag.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9 insertions(+)
diff
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
drivers/gpu/drm/msm/dp/dp_ctrl.h| 1
the PHY know which mode it should configure itself.
The PHY counterpart patchset is here:
https://lore.kernel.org/all/20240220-x1e80100-phy-edp-compatible-refactor-v5-0-e8658adf5...@linaro.org/
Signed-off-by: Abel Vesa
---
Abel Vesa (3):
dt-bindings: display: msm: dp-controller: document
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When debugging GPU hangs Mesa developers are finding it useful to replay
> the captured error state against the simulator. But due various simulator
> limitations which prevent replicating all hangs, one
Hi Daniel,
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 transparent to current committers and users: we'll
> > > still use dim, in the
On Wed, 21 Feb 2024 at 00:40, Abhinav Kumar wrote:
>
>
>
> On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/14/2024 11:20 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar
> >>> wrote:
On 2/19/2024 3:52 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:36, Abhinav Kumar wrote:
On 2/14/2024 11:20 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:02, Abhinav Kumar wrote:
On 2/8/2024 6:50 AM, Dmitry Baryshkov wrote:
We have several reports of vblank timeout
Hi all,
Today's linux-next merge of the drm-misc-fixes tree got a conflict in:
drivers/gpu/drm/tests/drm_buddy_test.c
between commit:
fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
from Linus' tree and commit:
335126937753 ("drm/tests/drm_buddy: fix 32b
On Tue, Feb 20, 2024 at 11:52:04AM -0800, John Harrison wrote:
> On 2/19/2024 12:28, Rodrigo Vivi wrote:
> > On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The above w/a is required for every platform that the i915 driver
> > >
On 20.02.2024 18:31, Dmitry Baryshkov wrote:
> The patch adding Type-C support for sm6115 was misapplied. All the
> orientation switch configuration ended up at the UFS PHY node instead of
> the USB PHY node. Move the data bits to the correct place.
>
> Fixes: a06a2f12f9e2 ("arm64: dts: qcom:
Hi Johan
On 2/19/2024 2:41 AM, Johan Hovold wrote:
On Sat, Feb 17, 2024 at 04:14:58PM +0100, Johan Hovold wrote:
On Wed, Feb 14, 2024 at 02:52:06PM +0100, Johan Hovold wrote:
On Tue, Feb 13, 2024 at 10:00:13AM -0800, Abhinav Kumar wrote:
Since Dmitry had trouble reproducing this issue I
The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
depends on the GFX driver reading out the sink's DPRX capabilities in
response to a long HPD pulse. Since in i915 this read-out can be blocked
by another connector's/encoder's hotplug event handling (which is
serialized by
Suspend and resume DP tunnels during system suspend/resume, disabling
the BW allocation mode during suspend, re-enabling it after resume. This
reflects the link's BW management component (Thunderbolt CM) disabling
BWA during suspend. Before any BW requests the driver must read the
sink's DPRX
Detect DP tunnels and enable the BW allocation mode on them. Send a
hotplug notification to userspace in response to a BW change.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_driver.c | 20 +++
drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
A follow-up change will need to resume DP tunnels during system resume,
so call intel_dp_sync_state() always for DDI encoders, so this function
can resume the tunnels for all DP connectors.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
1
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.
v2:
- Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville)
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch.
(Ville)
- Move
Handle DP tunnel IRQs a sink (or rather a BW management component like
the Thunderbolt Connection Manager) raises to signal the completion of a
BW request by the driver, or to signal any state change related to the
link BW.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c |
Allocate and free the DP tunnel BW required by a stream while
enabling/disabling the stream during a modeset.
v2:
- Move the allocation up from encoder hooks to
intel_atomic_commit_tail().
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar (v1)
---
drivers/gpu/drm/i915/display/intel_ddi.c
Take any link BW limitation into account in
intel_dp_max_link_data_rate(). Such a limitation can be due to multiple
displays on (Thunderbolt) links with DP tunnels sharing the link BW.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 32
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 tunnels, the last change in the patchset
actually enabling BWA.
With BWA enabled, the driver will expose the full mode list a display
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX
BW used by a follow-up patch enabling the DP tunnel BW allocation mode.
The link BW can be below the DPRX BW due to a BW limitation on a link
shared by multiple sinks.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
Add a way to get the active pipes through a given DP port by syncing
against a related pending non-blocking commit. Atm
intel_dp_get_active_pipes() will only try to sync a given pipe and if
that would block ignore the pipe. A follow-up change enabling the DP
tunnel BW allocation mode will need to
Add the atomic state during a modeset required to enable the DP tunnel
BW allocation mode on links where such a tunnel was detected. This state
applies to an already enabled output, the state added for a newly
enabled output will be computed and added/cleared to/from the atomic
state in a
Factor out a function updating the sink's link rate and lane count
capabilities, used by a follow-up patch enabling the DP tunnel BW
allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
Factor out a function to read the sink's DPRX capabilities used by a
follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_dp_link_training.c | 30 +++
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by
a follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files
On shared (Thunderbolt) links with DP tunnels, the modeset may need to
be retried on all connectors on the link due to a link BW limitation
arising only after the atomic check phase. To support this add a helper
function queuing a work to retry the modeset on a given port's connector
and at the
Factor out intel_dp_config_required_rate() used by a follow-up patch
enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files
Instead of intel_dp_max_data_rate() use the equivalent
drm_dp_max_dprx_data_rate() which was copied from the former one in a
previous patch.
Signed-off-by: Imre Deak
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c
The system resume display mode restoration should happen with an output
configuration matching that of the suspend time saved mode. Since the
restored mode configuration is subject to the bpp fallback logic,
starting out with an unlimited bpp and reducing the bpp as required by
any (MST) link BW
Add support for Display Port tunneling. For now this includes the
support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay
support for later.
BWA allows using displays that share the same (Thunderbolt) link with
their maximum resolution. Atm, this may not be possible due to the
This is v2 of [1], with the following changes:
- Several functional/typo/formatting fixes, detailed in the patches.
- Move the BW allocation from encoder hooks to
intel_atomic_commit_tail() fixing the allocation for MST streams
enabled/disabled w/o a full modeset (i.e. w/o re-enabling the
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
clarity. This patchset will also switch calling the new DRM function
in i915 instead of
On Tue, 20 Feb 2024 at 21:54, Abhinav Kumar wrote:
>
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
> ---
>
On Tue, Feb 20, 2024 at 02:34:53PM -0600, Lucas De Marchi wrote:
On Sun, Jan 14, 2024 at 04:09:16PM +0100, Christophe JAILLET wrote:
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is
On Sun, Jan 14, 2024 at 04:09:16PM +0100, Christophe JAILLET wrote:
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_max() is inclusive. So a -1 has
On 2/20/24 20:45, Timur Tabi wrote:
On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote:
Looks like I spoke too soon, I just hit the problem with the drm-next tree.
Did you apply the patch to drm-next?
Ugh, you're right. I don't how I got confused, but I could have sworn that I
saw
Currently the size parameter of drm_dp_vsc_sdp_pack() is always
the size of struct dp_sdp. Hence lets drop this parameter and
use sizeof() directly.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c |
On 2/19/2024 12:28, Rodrigo Vivi wrote:
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of
On 2/20/2024 11:41 AM, Ville Syrjälä wrote:
On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote:
On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:
On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
wrote:
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote:
On 2/20/2024 10:49 AM,
On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote:
Looks like I spoke too soon, I just hit the problem with the drm-next tree.
Did you apply the patch to drm-next?
Ugh, you're right. I don't how I got confused, but I could have sworn that I
saw your two patches in drm-next, but they
On Tue, Feb 20, 2024 at 11:27:18AM -0800, Abhinav Kumar wrote:
>
>
> On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:
> > On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
> > wrote:
> >>
> >> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 2/20/2024 10:49 AM,
On 2/20/2024 11:20 AM, Dmitry Baryshkov wrote:
On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
wrote:
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote:
On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be
On Tue, Feb 20, 2024 at 08:06:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > > Commit 1fd4a5a36f9f
On Tue, 20 Feb 2024 at 21:05, Dmitry Baryshkov
wrote:
>
> On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote:
> >
> >
> >
> > On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> > > On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar
> > > wrote:
> > >>
> > >> intel_dp_vsc_sdp_pack() can be re-used by
On Tue, 20 Feb 2024 at 21:09, Abhinav Kumar wrote:
>
>
>
> On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote:
> > On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> >>> On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar
> >>>
On 2/20/2024 10:09 AM, Dmitry Baryshkov wrote:
On Tue, 20 Feb 2024 at 19:55, Paloma Arellano wrote:
On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
On Sat, 17 Feb 2024 at 01:03, Paloma Arellano wrote:
+ }
+
+ panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
+
On 2/20/2024 11:05 AM, Dmitry Baryshkov wrote:
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote:
On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to
On Tue, 20 Feb 2024 at 20:53, Abhinav Kumar wrote:
>
>
>
> On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
> > On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar
> > wrote:
> >>
> >> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> >> Lets move this to drm_dp_helper to achieve
_simple API have been sent.
And Matthew Wilcox seems happy with the on going work. (see [1])
Based on next-20240220
$git grep ida_simple_get | wc -l
36
https://elixir.bootlin.com/linux/v6.8-rc3/A/ident/ida_simple_get
50
https://elixir.bootlin.com/linux/v6.7.4/A/ident/ida_simple_get
81
Than
On 2/20/2024 10:49 AM, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar wrote:
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry
On Thu, 15 Feb 2024 at 21:08, Abhinav Kumar wrote:
>
> intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
> Lets move this to drm_dp_helper to achieve this.
>
> changes in v2:
> - rebased on top of drm-tip
>
> Acked-by: Dmitry Baryshkov
v1 had an explicit comment
On 11/22/2023 5:47 AM, Pratyush Brahma wrote:
> From: Vijayanand Jitta
>
> Add secure system for Pixel and Non pixel video usecases, this
> allocates from system heap and secures using qcom_scm_aasign_mem.
^^
On Tue, 20 Feb 2024 at 19:55, Paloma Arellano wrote:
>
>
> On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
> > On Sat, 17 Feb 2024 at 01:03, Paloma Arellano
> > wrote:
> >> + }
> >> +
> >> + panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
> >> + catalog =
On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > to update all the
On Tue, 20 Feb 2024 19:31:04 +0200, Dmitry Baryshkov wrote:
> The patch adding Type-C support for sm6115 was misapplied. All the
> orientation switch configuration ended up at the UFS PHY node instead of
> the USB PHY node. Move the data bits to the correct place.
>
>
Applied, thanks!
[1/1]
On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > to update all the users of the struct drm_tv_connector_state mode field,
> > which
On 2/17/2024 12:56 AM, Dmitry Baryshkov wrote:
On Sat, 17 Feb 2024 at 01:03, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v4:
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the
Hi Maxime
On Tue, 20 Feb 2024 at 16:10, Maxime Ripard wrote:
>
> The EDID firmware loading mechanism introduced a few built-in EDIDs that
> could be forced on any connector, bypassing the EDIDs it exposes.
>
> While convenient, this limited set of EDIDs doesn't take into account
> the connector
The patch adding Type-C support for sm6115 was misapplied. All the
orientation switch configuration ended up at the UFS PHY node instead of
the USB PHY node. Move the data bits to the correct place.
Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port
handling")
Signed-off-by:
(gpu))
gpu->ubwc_config.highest_bank_bit = 13;
---
base-commit: 41c177cf354126a22443b5c80cec9fdd313e67e1
change-id: 20240220-fd-sc7180-explicit-ubwc-40953fa55947
Best regards,
--
Dmitry Baryshkov
On Tue, Feb 20, 2024 at 05:45:32PM +0100, Luca Weiss wrote:
> On Dienstag, 20. Februar 2024 15:12:10 CET Daniel Thompson wrote:
> > On Tue, Feb 20, 2024 at 12:11:22AM +0100, Luca Weiss wrote:
> > > Connect the panel with the backlight nodes so that the backlight can be
> > > turned off when the
On Dienstag, 20. Februar 2024 16:35:23 CET Daniel Thompson wrote:
> [Sorry for the RESEND so soon... embarrassingly I got Lee's e-mail
> address wrong the first time!]
>
> Luca Weiss recently shared a patch to zero the properties structure for
> lm3630a... and shortly afterwards I realized I
On Dienstag, 20. Februar 2024 15:12:10 CET Daniel Thompson wrote:
> On Tue, Feb 20, 2024 at 12:11:22AM +0100, Luca Weiss wrote:
> > Connect the panel with the backlight nodes so that the backlight can be
> > turned off when the display is blanked.
> >
> > Signed-off-by: Luca Weiss
>
>
Am 20.02.24 um 17:10 schrieb Maxime Ripard:
The EDID firmware loading mechanism introduced a few built-in EDIDs that
could be forced on any connector, bypassing the EDIDs it exposes.
While convenient, this limited set of EDIDs doesn't take into account
the connector type, and we can end up
On Dienstag, 20. Februar 2024 15:11:07 CET Daniel Thompson wrote:
> On Tue, Feb 20, 2024 at 12:11:21AM +0100, Luca Weiss wrote:
> > As per documentation "drivers are expected to use this function in their
> > update_status() operation to get the brightness value.".
> >
> > With this we can also
Applied to drm-misc-fixes
On 20.02.2024 14:16, Jacek Lawrynowicz wrote:
> From: Andrzej Kacprowski
>
> There is no point in requesting 1 tile on VPU40xx as the FW will
> probably need more tiles to run workloads, so it will have to
> reconfigure PLL anyway. Don't enable any tiles and allow the
The EDID firmware loading mechanism introduced a few built-in EDIDs that
could be forced on any connector, bypassing the EDIDs it exposes.
While convenient, this limited set of EDIDs doesn't take into account
the connector type, and we can end up with an EDID that is completely
invalid for a
From: Tomer Tayar
The reserved memory for FW is currently saved in an ASIC property in
units of MB, just like the value that comes from FW.
Except the fact that it is not clear from the property's name, it means
also that a calculation to actual size is required everywhere that it is
used.
From: Ofir Bitton
Fetching sensor data can fail due to various reasons. In order
not to pollute the kernel log, those error prints must be
rate limited.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/hwmon.c | 29
From: Ofir Bitton
Due to a H/W issue, AXI drain event does not include a read/write
indication, hence we remove this print.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 14 +++---
1 file changed, 3
1 - 100 of 217 matches
Mail list logo
