From: ye xingchen
Return the value ci_load_smc_ucode() directly instead of storing it in
another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: ye xingchen
---
drivers/gpu/drm/radeon/ci_dpm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
From: ye xingchen
Return the value radeon_drm_ioctl() directly instead of storing it in
another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: ye xingchen
---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
Hi Rob,
On Jul 12 11:45, Rob Herring wrote:
>
> That's not the right interpretation. There should not be some Type-C
> specific child mux/switch node because the device has no such h/w within
> it. Assuming all the possibilities Stephen outlined are valid, it's
> clear this lane selection has
Hi Mateusz,
On Fri, Sep 2, 2022 at 12:00 AM Mateusz Kwiatkowski wrote:
> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> > The TV mode property has been around for a while now to select and get the
> > current TV mode output on an analog TV connector.
> >
> > Despite that property name being ge
Hi, Bo-Chen:
On Thu, 2022-09-01 at 12:41 +0800, Bo-Chen Chen wrote:
> It's not necessary to have a next_bridge for DP device, so we add
> this
> patch to judge this.
Reviewed-by: CK Hu
>
> Signed-off-by: Bo-Chen Chen
> ---
> drivers/gpu/drm/mediatek/mtk_dp.c | 5 -
> 1 file changed, 4 in
From: zhang songyi
Return the enable_link_dp() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/g
From: zhang songyi
Return the sdma_v6_0_start() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/
On Thu, 01 Sep 2022, Maíra Canal wrote:
> Hi Maxime,
>
> On 9/1/22 09:55, Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
>>> With the introduction of KUnit, IGT is no longer the only option to run
>>> the DRM unit tests, as the tests can be run thro
On Thu, Sep 01, 2022 at 07:33:18PM -0300, Maíra Canal wrote:
> Hi Maxime,
>
> On 9/1/22 09:55, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
> >> With the introduction of KUnit, IGT is no longer the only option to run
> >> the DRM unit tests, as
From: zhang songyi
Return the drm_dp_dpcd_writeb() directly instead of storing it in another
redundant variable.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/display/drm_dp_helper.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/
On Fri, 02 Sep 2022, cgel@gmail.com wrote:
> From: zhang songyi
>
> Return the drm_dp_dpcd_writeb() directly instead of storing it in another
> redundant variable.
Please just *stop* sending changes like this. See for example [1].
What's most offending to me is that I've replied to a lot of
On Fri, 02 Sep 2022, Maxime Ripard wrote:
> On Thu, Sep 01, 2022 at 07:33:18PM -0300, Maíra Canal wrote:
>> Hi Maxime,
>>
>> On 9/1/22 09:55, Maxime Ripard wrote:
>> > Hi,
>> >
>> > On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
>> >> With the introduction of KUnit, IGT is no longe
From: zhang songyi
Return the mul_u32_fixed16() and div_fixed16() directly instead of
redundant variables.
Reported-by: Zeal Robot
Signed-off-by: zhang songyi
---
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandaga
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandaga
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Friday, August 26, 2022 5:02 PM
>To: Kalyan Thota ; Kalyan Thota (QUIC)
>; diand...@chromium.org
>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>k
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nit
01.09.2022 17:02, Ruhl, Michael J пишет:
...
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>> drm_i915_private *i915,
>> continue;
>> }
>>
>
02.09.2022 13:31, Dmitry Osipenko пишет:
> 01.09.2022 17:02, Ruhl, Michael J пишет:
> ...
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>>> drm_i915_private *i915,
>>>
On 29.08.2022 20:40, Jagan Teki wrote:
> Samsung MIPI DSIM controller is common DSI IP that can be used in various
> SoCs like Exynos, i.MX8M Mini/Nano.
>
> In order to access this DSI controller between various platform SoCs,
> the ideal way to incorporate this in the drm stack is via the drm brid
> -Original Message-
> From: dri-devel On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH v2 1/4] drm: Use original src rect while initializing damage
> itera
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 2/4] drm/i915/display: Use original src in
> psr2 sel
> fetch area calculat
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Use drm helper instead
> of
> own loop for damage cl
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Tuesday, August 23, 2022 2:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 4/4] drm/tests: Set also mock plane src_x,
> src_y,
> src_w and src_h
>
>
On Fri, 2 Sept 2022 at 12:38, Kalyan Thota wrote:
>
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This change adds
On Fri, 2 Sept 2022 at 12:35, Kalyan Thota wrote:
>
>
>
> >-Original Message-
> >From: Dmitry Baryshkov
> >Sent: Friday, August 26, 2022 5:02 PM
> >To: Kalyan Thota ; Kalyan Thota (QUIC)
> >; diand...@chromium.org
> >Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> >f
On Fri, Aug 26, 2022 at 04:19:27PM +0200, Andrzej Hajda wrote:
> i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
> called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
> Since dp_mst is suspended after irq handler uninstall, a cleaner approach
> is to cancel hp
Den 01.09.2022 21.35, skrev Noralf Trønnes:
>
>
> I have finally found a workaround for my kernel hangs.
>
> Dom had a look at my kernel and found that the VideoCore was fine, and
> he said this:
>
>> That suggests cause of lockup was on arm side rather than VC side.
>>
>> But it's hard to d
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For some resaon we only use the secondary GTF curve for the
> standard timings. Use it for inferred modes as well.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 35 ++-
>
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For EDID 1.4 the first detailed timing is always preferred,
> for older EDIDs there was a feature flag to indicate the same.
> While correct, the code setting that up is rather confusing.
> Restate it in a slightly more straightf
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of the confusing version_greater() stuff and
> simply compare edid->revision directly everwhere. Half
> the places already did it this way, and since we actually
> reject any EDID with edid->version!=1 it's a perfectly
>
On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote:
> On Thu, 01 Sep 2022, Maíra Canal wrote:
> > Hi Maxime,
> >
> > On 9/1/22 09:55, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
> >>> With the introduction of KUnit, IGT is no longe
On Fri, Sep 02, 2022 at 03:25:39PM +0300, Jani Nikula wrote:
> On Sat, 27 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > For some resaon we only use the secondary GTF curve for the
> > standard timings. Use it for inferred modes as well.
> >
> > Signed-off-by: Ville Syrjälä
> > -
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. Fix this up by properly
calling dput().
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel
On Fri, 02 Sep 2022, Maxime Ripard wrote:
> On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote:
>> On Thu, 01 Sep 2022, Maíra Canal wrote:
>> > Hi Maxime,
>> >
>> > On 9/1/22 09:55, Maxime Ripard wrote:
>> >> Hi,
>> >>
>> >> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
>
On Fri, Sep 02, 2022 at 03:01:05PM +0200, Greg Kroah-Hartman wrote:
> When calling debugfs_lookup() the result must have dput() called on it,
> otherwise the memory will leak over time. Fix this up by properly
> calling dput().
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: A
On Thu, 25 Aug 2022, Hans de Goede wrote:
> On machins without an i915 opregion the acpi_video driver immediately
> probes the ACPI video bus and used to also immediately register
> acpi_video# backlight devices when supported.
>
> Once the drm/kms driver then loaded later and possibly registered
On Thu, Sep 01, 2022 at 09:26:27PM +0200, Daniel Vetter wrote:
> On Thu, 1 Sept 2022 at 13:35, Petr Mladek wrote:
> >
> > On Tue 2022-08-30 16:50:04, Daniel Vetter wrote:
> > > console_unblank() does this too (called in both places right after),
> > > and with a lot more confidence inspiring appro
On Fri, Sep 02, 2022 at 04:03:20PM +0300, Jani Nikula wrote:
> On Fri, 02 Sep 2022, Maxime Ripard wrote:
> > On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote:
> >> On Thu, 01 Sep 2022, Maíra Canal wrote:
> >> > Hi Maxime,
> >> >
> >> > On 9/1/22 09:55, Maxime Ripard wrote:
> >> >> Hi,
On Sat, 27 Aug 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prefer the timing formula indicated by the range
> descriptor for generating the non-DMT standard timings.
>
> Previously we just used CVT for all EDID 1.4 continuous
> frequency displays without even checking if the range
> desc
On Fri, Aug 26, 2022 at 06:40:12PM -0700, Navare, Manasi wrote:
> On Sat, Aug 27, 2022 at 12:34:51AM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > EDID 1.4 introduced some extra flags in the range
> > descriptor to support min/max h/vfreq >= 255. Consult them
> > to correctly parse
On Fri, 02 Sep 2022, Michał Winiarski wrote:
> Having said that - I do believe that igt_* prefix don't belong here
> (which is why I'm progressively trying to get rid of in the patches
> that refactor some of the tests).
Just clarifying that I'm not trying to defend igt_ prefix at all, and I
agre
On Fri, Sep 02, 2022 at 04:41:36PM +0300, Jani Nikula wrote:
> On Sat, 27 Aug 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Prefer the timing formula indicated by the range
> > descriptor for generating the non-DMT standard timings.
> >
> > Previously we just used CVT for all EDID 1.
On Wed, Aug 31, 2022 at 07:15:11PM -0300, Maíra Canal wrote:
> Hi Michał
>
> Some very minor nits inline, but either way:
>
> Reviewed-by: Maíra Canal
>
> On 8/31/22 18:56, Michał Winiarski wrote:
> > While we have multiple test cases, most of them check multiple
> > conditions, calling the fun
On 30.08.22 г. 21:23 ч., Tomi Valkeinen wrote:
On 30/08/2022 21:08, Ivaylo Dimitrov wrote:
flags &= ~OMAP_BO_TILED_MASK;
flags |= 0x0008;
flags |= OMAP_BO_WC;
bo = omap_bo_new(dev, size, flags);
As you can see we use 0x0008 (OMAP_BO_MEM_CONTIG) u
On 9/2/22 11:06, Michał Winiarski wrote:
On Wed, Aug 31, 2022 at 07:15:11PM -0300, Maíra Canal wrote:
Hi Michał
Some very minor nits inline, but either way:
Reviewed-by: Maíra Canal
On 8/31/22 18:56, Michał Winiarski wrote:
While we have multiple test cases, most of them check multiple
cond
The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
will register a device matching the HDMI codec driver, and then register
an ASoC card using that codec.
However, if vc4 is compiled as a module, chances ar
On Thu, Sep 01, 2022 at 09:20:55AM -0300, Maíra Canal wrote:
> Hi Michał
>
> On 8/31/22 17:45, Michał Winiarski wrote:
> > The test was constructed as a single function (test case) which checks
> > multiple conditions, calling the function that is tested multiple times
> > with different arguments
On Fri, 02 Sep 2022, cgel@gmail.com wrote:
> From: zhang songyi
>
> Return the mul_u32_fixed16() and div_fixed16() directly instead of
> redundant variables.
>
> Reported-by: Zeal Robot
> Signed-off-by: zhang songyi
NAK.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_pm.c | 9 +++--
On Fri, 02 Sep 2022, Jani Nikula wrote:
> On Fri, 02 Sep 2022, cgel@gmail.com wrote:
>> From: zhang songyi
>>
>> Return the mul_u32_fixed16() and div_fixed16() directly instead of
>> redundant variables.
>>
>> Reported-by: Zeal Robot
>> Signed-off-by: zhang songyi
>
> NAK.
And to explain
On 9/2/22 11:53, Michał Winiarski wrote:
> On Thu, Sep 01, 2022 at 09:20:55AM -0300, Maíra Canal wrote:
>> Hi Michał
>>
>> On 8/31/22 17:45, Michał Winiarski wrote:
>>> The test was constructed as a single function (test case) which checks
>>> multiple conditions, calling the function that is teste
From: Chris Morgan
This series adds the ability to set the byteswap order in the chrontel
ch7033 driver via an optional devicetree node. This is necessary
because the HDMI DIP of the NTC CHIP requires a byteswap order that
differs from the default value of the driver.
Changes from V1:
- Update
From: Chris Morgan
Update dt-binding documentation to add support for setting byteswap of
chrontel ch7033.
New property name of chrontel,byteswap added to set the byteswap order.
This property is optional.
Signed-off-by: Chris Morgan
Reviewed-by: Robert Foss
---
.../bindings/display/bridge/c
From: Chris Morgan
Add the option to set the byteswap order in the devicetree. For the
official HDMI DIP for the NTC CHIP the byteswap order needs to be
RGB, however the driver sets it as BGR. With this patch the driver
will remain at BGR unless manually specified via devicetree.
Signed-off-by:
On Fri, 2 Sept 2022 at 17:39, Chris Morgan wrote:
>
> From: Chris Morgan
>
> This series adds the ability to set the byteswap order in the chrontel
> ch7033 driver via an optional devicetree node. This is necessary
> because the HDMI DIP of the NTC CHIP requires a byteswap order that
> differs fr
>-Original Message-
>From: Dmitry Osipenko
>Sent: Friday, September 2, 2022 6:39 AM
>To: Ruhl, Michael J ; Dmitry Osipenko
>; Jani Nikula ;
>Joonas Lahtinen ; Vivi, Rodrigo
>; Tvrtko Ursulin ;
>Thomas Hellström ; Christian König
>; Chris Wilson
>Cc: dri-devel@lists.freedesktop.org; linux-
tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Radhakrishna-Sripada/Initial-Meteorlake-Support/20220902-140730
b
Both RZ/G2L and RCar display system uses similar hardware pipeline for
display ie, it uses FCPV, VSPD and DU. Both FCPV and VSPD are almost
similar, but DU there are some differences like it does not have
plane/group registers.
Since the pipeline and software architecture are similar, we can reuse
Add RZ/G2L reset and clocks to struct rcar_du_crtc, so that
we can share and optimize the common code between RCar and
RZ/G2L driver using RCar DU library.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 ++
1 f
Add RCar DU encoder lib support by moving rcar_du_encoder_count_ports()
and rcar_du_encoder_funcs to the lib file and added
rcar_du_encoder_funcs() to share the common code between RCar and
RZ/G2L DU encoder drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
*
Add RCar DU kms lib support by moving rcar_du_format_infos table and
rcar_du_format_infos() to the lib file to share the common code between
RCar and RZ/G2L DU KMS drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/Makefile
Add RCar DU vsp lib support by moving rcar_du_vsp_disable()
to the lib file so that same function can be used by both
RCar and RZ/G2L DU VSP drivers.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/Kconfig | 5 +
drivers/gpu
Move rcar_du_vsp_atomic_begin() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 5 +
drivers
Move rcar_du_vsp_atomic_flush() to RCar DU vsp lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 13 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp_lib.c | 14 +++
Move vsp rcar_du_vsp_{map,unmap}_fb() to RCar DU VSP lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 78 -
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 18 -
drivers/gpu/drm/rcar-du/rcar_du_v
Move rcar_du_dumb_create() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 5
drivers/gpu/drm/rcar-du/rcar_du_kms_lib.c | 28 ++
Move rcar_du_gem_prime_import_sg_table() to RCar DU KMS lib.
Signed-off-by: Biju Das
---
v1->v2:
* Rebased on drm-misc-next and DU-next.
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 47 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 8
drivers/gpu/drm/rcar-du/rcar_
RZ/G2L does not have plane registers as well as it uses different
CRTC. The below functions are SoC specific
* rcar_du_crtc_finish_page_flip()
* __rcar_du_plane_setup
* __rcar_du_plane_atomic_check
All other function can be handled in common code. This patch introduces
rcar_du_lib_vsp_init() to
On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
wrote:
On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
On Fri, 2 Sept 2022 at 21:07, Abhinav Kumar wrote:
>
>
>
> On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
> >
> >
> > On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
> > wrote:
> >>
> >>
> >> On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
> >>> To let the probe function bail early if any of
On 9/2/2022 12:05 PM, Dmitry Baryshkov wrote:
On Fri, 2 Sept 2022 at 21:07, Abhinav Kumar wrote:
On 9/1/2022 11:06 PM, Dmitry Baryshkov wrote:
On 2 September 2022 03:24:17 GMT+03:00, Abhinav Kumar
wrote:
On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:
To let the probe function bail
On Tue, Aug 16, 2022 at 06:28:04PM +0100, Robin Murphy wrote:
> The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with
> only a couple more public interfaces left pertaining to MSI integration.
> Since these depend on the main IOMMU API header anyway, move their
> declarations there,
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote:
> Although iommu-dma is a per-architecture chonce, that is currently
> implemented in a rather haphazard way. Selecting from the arch Kconfig
> was the original logical approach, but is complicated by having to
> manage dependencies; con
Reviewed-by: Lyude Paul
On Wed, 2022-08-31 at 18:13 -0400, Fangzhi Zuo wrote:
> The attempt to read DPCD_REV before any native aux read breaks
> majority of DP2 compliance.
>
> The spec. requires DP_SINK_STATUS to be polled for the reset status
> DP_INTRA_HOP_AUX_REPLY_INDICATION during the clea
The pull request you sent on Fri, 2 Sep 2022 11:48:36 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-02
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1e8e515edd6dbe15b86003d846fee005c12c0685
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Future platforms can read the IP version from a register and the
IP version numbers need not be hard coded in device info. Move the
ip version for media and display to runtime info.
On platforms where hard coding of IP version is required, update
the IP version in __runtime under device_info.
v2:
On 9/2/22 10:38, Michał Winiarski wrote:
> On Fri, Sep 02, 2022 at 04:03:20PM +0300, Jani Nikula wrote:
>> On Fri, 02 Sep 2022, Maxime Ripard wrote:
>>> On Fri, Sep 02, 2022 at 11:04:14AM +0300, Jani Nikula wrote:
On Thu, 01 Sep 2022, Maíra Canal wrote:
> Hi Maxime,
>
> On 9/1/22
As we start supporting multiple uncore structures in future patches, the
MMIO cleanup (which make also get called mid-init if there's a failure)
will become more complicated. Moving to DRM-managed actions will help
keep things simple.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driv
Starting with MTL, media functionality has moved into a new, second GT
at the hardware level. This new GT, referred to as "standalone media"
in the spec, has its own GuC, power management/forcewake, etc. The
general non-engine GT registers for standalone media start at 0x38,
but otherwise use
We're slowly transitioning the init-time kzalloc's of the driver over to
DRM-managed allocations; let's make sure the uncore objects allocated
for non-root GTs are thus allocated.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++
1 fi
The original intent of intel_uncore_mmio_debug as described in commit
0a9b26306d6a ("drm/i915: split out uncore_mmio_debug") was to be a
singleton structure that could be shared between multiple GTs' uncore
objects in a multi-tile system. Somehow we went off track and
started allocating separate i
Moving the locking for MMIO debug (and the final check for unclaimed
accesses when resuming debug after a userspace-initiated forcewake) will
make it simpler to completely skip MMIO debug handling on uncores that
don't support it in future patches.
Signed-off-by: Matt Roper
Reviewed-by: Radhakris
The common early GT init is needed for initialization of all GT types
(root/primary, remote tile, standalone media). Since standalone media
(coming in the next patch) will be implemented in a separate file,
rename and expose the function for use.
Signed-off-by: Matt Roper
Reviewed-by: Radhakrish
GT non-engine registers (referred to as "GSI" registers by the spec)
have the same relative offsets on standalone media as they do on the
primary GT, just with an additional "GSI offset" added to their MMIO
address. If we store this GSI offset in the standalone media's
intel_uncore structure, it c
Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups). When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS e
We're going to introduce an additional intel_gt for MTL's media unit
soon. Let's provide a bit more multi-GT initialization framework in
preparation for that. The initialization will pull the list of GTs for
a platform from the device info structure. Although necessary for the
immediate MTL medi
Xe_LPM+ platforms have "standalone media." I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc. Let's allow platforms to include media GTs in their device info.
v2:
- Simplify GSI register handling and split it out to a separate patch
for ease o
When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow. As
such, we should share the same IRQ lock with the primary GT. Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same
In a multi-GT system we need to initialize MMIO access for each GT, not
just the primary GT.
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 27 ++-
drivers/gpu/drm/i915/intel_uncore.c | 5 -
drivers/gpu/drm/i915/intel_
In preparation for enabling a second GT, there are a number of GT/uncore
operations that happen during initialization or suspend flows that need
to be performed on each GT, not just the primary,
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_driver.c | 59 +++
Hi Chris,
Thank you for the patch.
On Fri, Sep 02, 2022 at 10:39:06AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add the option to set the byteswap order in the devicetree. For the
> official HDMI DIP for the NTC CHIP the byteswap order needs to be
> RGB, however the driver sets it as
Hi Chris,
Thank you for the patch.
On Fri, Sep 02, 2022 at 10:39:05AM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Update dt-binding documentation to add support for setting byteswap of
> chrontel ch7033.
>
> New property name of chrontel,byteswap added to set the byteswap order.
> This
Hi Rob,
On Fri, Sep 02, 2022 at 06:21:50PM +0200, Robert Foss wrote:
> On Fri, 2 Sept 2022 at 17:39, Chris Morgan wrote:
> >
> > From: Chris Morgan
> >
> > This series adds the ability to set the byteswap order in the chrontel
> > ch7033 driver via an optional devicetree node. This is necessary
Poblem: Given many entities competing for same rq on
same scheduler an uncceptabliy long wait time for some
jobs waiting stuck in rq before being picked up are
observed (seen using GPUVis).
The issue is due to Round Robin policy used by scheduler
to pick up the next entity for execution. Under str
94 matches
Mail list logo
