On 10.03.2023 10:23, Andrzej Hajda wrote:
This patch tries to diminish plague of DMAR read errors present
in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
CI is usually tolerant for these errors, so the scale of the problem
is not really visible.
To show it I have counted
On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote:
>
> On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> >
> > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote:
> > > >
> > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark
On 3/16/2023 9:36 AM, Abhinav Kumar wrote:
On 3/16/2023 9:23 AM, Dmitry Baryshkov wrote:
On 16/03/2023 18:13, Abhinav Kumar wrote:
On 3/16/2023 9:03 AM, Dmitry Baryshkov wrote:
Hi,
[removed previous conversation]
Hi Dmitry and Abhinav,
Just wanted to follow up on this thread. I've
Arthur Grillo Queiroz Cabral writes:
> Hello Javier,
>
> On 14/03/23 16:08, Javier Martinez Canillas wrote:
>> Arthur Grillo writes:
>>
>> Hello Arthur,
>>
>>> Extend the existing test cases to test the conversion from XRGB to
>>> monochromatic.
>>>
>>> Signed-off-by: Arthur Grillo
>>>
From: John Harrison
A failure to load the GuC is occasionally observed where the GuC log
actually showed that the GuC had loaded just fine. The implication
being that the load just took ever so slightly longer than the 200ms
timeout. Given that the actual time should be tens of milliseconds at
From: John Harrison
There are multiple ways in which the GuC load can fail. The driver was
reporting the status register as is, but not everyone can read the
matrix unfiltered. So add decoding of the common error cases.
Also, remove the comment about interrupt based load completion
checking
There's a nice macro to calculate the destination pitch that already takes
into account sub-byte pixel formats. Use that instead of open coding it.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 7 ++-
1 file
From: John Harrison
Add more decoding of the GuC load failures. Also include information
about GT frequency to see if timeouts are due to a failure to boost
the clocks. Finally, increase the timeout to accommodate situations
where the clock boost does fail.
v2: Reduce timeout in release builds,
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes linus/master v6.3-rc2 next-20230316]
[cannot apply to drm-tip/drm-tip tegra/for-next]
[If your patch
On Thu, 16 Mar 2023, Juergen Gross wrote:
> On 16.03.23 14:53, Alex Deucher wrote:
> > On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote:
> > >
> > > On 16.03.23 14:45, Alex Deucher wrote:
> > > > On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote:
> > > > >
> > > > > On 16.03.2023 00:25,
Hi,
On Tue, Mar 14, 2023 at 4:55 PM Jianhua Lu wrote:
>
> On Tue, Mar 14, 2023 at 10:12:02AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Mar 14, 2023 at 4:45 AM Jianhua Lu wrote:
> > >
> > > Some panels set mode type to DRM_MODE_TYPE_PREFERRED by the number
> > > of modes. It isn't
On 3/15/2023 11:54 AM, Nirmoy Das wrote:
Add a comment why there is a obj refcount inc before installing
the vm_ops for the mmap call. Also remove the invalid older comment
as drm API(drm_gem_prime_mmap()) will hold an obj reference before
calling this driver mmap callback so we can't have
On Wed, Mar 8, 2023 at 7:53 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This series adds a deadline hint to fences, so realtime deadlines
> such as vblank can be communicated to the fence signaller for power/
> frequency management decisions.
>
> This is partially inspired by a trick i915 does,
On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick
wrote:
>
> On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote:
> >
> > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> > >
> > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl
://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-tegra-allow-compile-test-on-ARM/20230316-172205
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r
On 2023/3/16 17:53, kernel test robot wrote:
Hi Sui,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.3-rc2 next-20230316]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote:
> The sitronix-st7789v driver now considers the panel-timing property.
I read the patch for that and still don't know 'why'. Commit messages
should answer why.
> Add the property to the documentation.
We generally don't put
On Wed, Mar 15, 2023 at 11:08:00AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> On MTL, objects allocated through i915_gem_object_create_internal() are
> mapped as uncached in GPU by default because HAS_LLC is false. However
> in the live_hwsp_read selftest these watcher objects are
Hi Rob,
On 3/16/23 22:57, Rob Herring wrote:
> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote:
>> The sitronix-st7789v driver now considers the panel-timing property.
>
> I read the patch for that and still don't know 'why'. Commit messages
> should answer why.
>
>> Add the
Geert Uytterhoeven writes:
Hello Geert,
[...]
>> + if (!dst_pitch) {
>> + bpp = drm_format_info_bpp(dst_fi, 0);
>> + dst_pitch = DIV_ROUND_UP(drm_rect_width(clip) * bpp, 8);
>
> I know I'm a bit late to the party, but here's actually a helper for that:
>
>
On Thu, Mar 16, 2023 at 10:13:54PM +0100, Sebastian Wick wrote:
> On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
> wrote:
> >
> > On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 12:47:51 +0200
> > > Ville Syrjälä wrote:
> > >
> > > > On Thu, Mar 16, 2023
On Thu, Mar 16, 2023 at 1:35 PM Ville Syrjälä
wrote:
>
> On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> > On Thu, 16 Mar 2023 12:47:51 +0200
> > Ville Syrjälä wrote:
> >
> > > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > > On Thu, 16 Mar 2023 11:50:27
On Thu, 16 Mar 2023 at 19:27, Matthew Auld
wrote:
>
> On Thu, 16 Mar 2023 at 07:26, Christian König
> wrote:
> >
> > That was accidentially left over when we switched to the delayed delete
> > worker.
> >
> > Suggested-by: Matthew Auld
> > Signed-off-by: Christian König
> > Fixes:
>> From: Fei Yang
>>
>> On MTL, objects allocated through i915_gem_object_create_internal() are
>> mapped as uncached in GPU by default because HAS_LLC is false. However
>> in the live_hwsp_read selftest these watcher objects are mapped as WB
>> on CPU side. The conseqence is that the updates
On 14/03/2023 13:13, Konrad Dybcio wrote:
> The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
> alone. This however didn't quite work out and the property became
> undocumented instead of deprecated. Fix that.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main:
On 14/03/2023 16:28, Konrad Dybcio wrote:
> The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
> we'd normally assign to the GMU as if they were a part of the GMU, even
> though they are not". It's a (good) software representation of the GMU_CX
> and GMU_GX register spaces within
That was accidentially left over when we switched to the delayed delete
worker.
Suggested-by: Matthew Auld
Signed-off-by: Christian König
Fixes: ("9bff18d13473") drm/ttm: use per BO cleanup workers
Reported-by: Steven Rostedt (Google)
Tested-by: Steven Rostedt (Google)
---
Am 15.03.23 um 22:15 schrieb Sui Jingfeng:
From: suijingfeng
Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.
This display
On 16/03/2023 07:19, Nancy Lin (林欣螢) wrote:
> On Wed, 2023-03-15 at 08:16 +0100, Krzysztof Kozlowski wrote:
>> On 15/03/2023 04:45, Nancy Lin (林欣螢) wrote:
>>
>> Trim the replies and remove unneeded context. You want to get the
>> attention of other people, not force them to read entire email.
>>
On 14/03/2023 16:28, Konrad Dybcio wrote:
> The "GMU Wrapper" is Qualcomm's name for "let's treat the GPU blocks
> we'd normally assign to the GMU as if they were a part of the GMU, even
> though they are not". It's a (good) software representation of the GMU_CX
> and GMU_GX register spaces within
On 16.03.2023 00:25, Stefano Stabellini wrote:
> On Wed, 15 Mar 2023, Jan Beulich wrote:
>> On 15.03.2023 01:52, Stefano Stabellini wrote:
>>> On Mon, 13 Mar 2023, Jan Beulich wrote:
On 12.03.2023 13:01, Huang Rui wrote:
> Xen PVH is the paravirtualized mode and takes advantage of
Making sure a bug tracker is up to date is not an easy task. For
example, a first version of a patch fixing a tracked issue can be sent a
long time after having created the issue. But also, it can take some
time to have this patch accepted upstream in its final form. When it is
done, someone --
Hi Konstantin,
On 15/03/2023 19:12, Konstantin Ryabitsev wrote:
> On Wed, Mar 15, 2023 at 06:44:56PM +0100, Matthieu Baerts wrote:
>> Note that thanks to this "Closes" tag, the mentioned bug trackers can
>> also locate where a patch has been applied in different branches and
>> repositories. If
Hi Jon,
On 15/03/2023 19:19, Jonathan Corbet wrote:
> Matthieu Baerts writes:
>
>> +In the same category as linking web pages, a special tag is also used to
>> close
>> +issues but only when the mentioned ticketing system can do this operation
>> +automatically::
>> +
>> +Closes:
Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags
followed by a link [1]. It also complains if a "Reported-by:" tag is
followed by a "Closes:" one [2].
As detailed in the first patch, this "Closes:" tag is used for a bit of
time, mainly by DRM and MPTCP subsystems. It is
On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>
> Now that i915 is the last flush_scheduled_work() user, for now let's
> start with blind
As a follow-up of the previous patch modifying the documentation to
allow using the "Closes:" tag, checkpatch.pl is updated accordingly.
checkpatch.pl now mentions the "Closes:" tag between brackets to express
the fact it should be used only if it makes sense.
While at it, checkpatch.pl will not
From: Koby Elbaz
Engines idle state can't always be verified between changes of
engine modes (e.g., stall/halt).
For example, if a CS is inflight when altering engine's mode,
idle state will return NOT idle, always.
Signed-off-by: Koby Elbaz
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
From: Dafna Hirschfeld
In hw_fini callback, we use either the cpucp packet method or polling a
register. Currently we return error only in the case of cpucp packet
failure. In this patch we also return error if polling timed out.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
From: Tomer Tayar
Remove all '\n' from strings which are passed as arguments to
gaudi2_print_event(), because the newline character is added internally
in this function.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
On 16/03/2023 10:53, AngeloGioacchino Del Regno wrote:
> Hello Krzysztof, Nancy,
>
> Since this series has reached v29, can we please reach an agreement on the
> bindings
> to use here, so that we can get this finally upstreamed?
>
> I will put some examples to try to get this issue resolved.
From: Koby Elbaz
Now that CQ-completion based jobs do not trigger a reset upon failure,
failure of such jobs (e.g., MMU cache invalidation) should be handled
by the caller itself depending on the error code returned to it.
Signed-off-by: Koby Elbaz
Reviewed-by: Oded Gabbay
Signed-off-by: Oded
From: Dafna Hirschfeld
- remove reset_sleep_ms arg from functions that don't use it.
- move the call msleep(reset_sleep_ms) from btm poll to gaudi2_hw_fini
as it is called from there already for other flow.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
From: Dafna Hirschfeld
Since the err_cause register is unprivileged, we should read it from
the driver instead of using the param that came from the FW.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 40
Copy the most up-to-date interface files to the firmware.
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 +-
.../habanalabs/include/common/cpucp_if.h | 51 ++-
.../habanalabs/include/common/hl_boot_if.h| 47 +
From: Ofir Bitton
Due to a firmware bug we need to increase reset poll timeout
or else we will timeout in secured environments.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 3 ++-
1 file changed, 2
Don't use padX for actual reservedX fields.
Signed-off-by: Oded Gabbay
---
include/uapi/drm/habanalabs_accel.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/uapi/drm/habanalabs_accel.h
b/include/uapi/drm/habanalabs_accel.h
index
From: Ofir Bitton
We expose this in order for user applications to know how much dram
is reserved for internal use.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs_ioctl.c | 1 +
On Thu, Mar 16, 2023 at 01:34:49PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 12:47:51 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > > On Thu, 16 Mar 2023 11:50:27 +0200
> > > Ville Syrjälä wrote:
> > >
> > > > On Thu, Mar 16,
On 2023/3/16 15:18, Christian König wrote:
Am 15.03.23 um 22:15 schrieb Sui Jingfeng:
From: suijingfeng
Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included
On Mon, Mar 13, 2023 at 4:16 PM Thomas Zimmermann wrote:
>
> Convert gma500's fbdev code to drm_client. Replace to the current
> ad-hoc integration. The conversion includes a number of cleanups.
> Only build fbdev support if the config option has been set.
>
> Tested on Cedarview HW.
>
> v2:
>
v4 -> v5:
- Drop superfluous items: level in [8/10]
- Remove the header define for the qcm2290 config in [6/10] instead of
[7/10]
- Pick up tags
v4:
https://lore.kernel.org/r/20230307-topic-dsi_qcm-v4-0-54b489818...@linaro.org
v3 -> v4:
- Use the shiny new compatible in the 6115 bindings
The qcom, prefix was missed previously. Fix it.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Acked-by: Rob Herring
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
The configs are identical, other than the number of *maximum* DSI
hosts allowed. This isn't an issue, unless somebody deliberately
tries to access the inexistent host by adding a dt node for it.
Remove the SC7180 struct and point the hw revision match to the
SDM845's one. On a note, this could
Some structs were defined multiple times for no apparent reason.
Deduplicate them.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 93 +--
1 file changed, 30 insertions(+), 63
Now that the only user is handled by common code, remove the option to
specify custom handlers through match data.
This is effectively a revert of commit:
5ae15e76271 ("drm/msm/dsi: Allow to specify dsi config as pdata")
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by:
The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
alone. This however didn't quite work out and the property became
undocumented instead of deprecated. Fix that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
strings for every current SoC")
Add a compatible for the DSI on SM6115.
Acked-by: Rob Herring
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
.../devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml | 10 --
2 files changed,
Use the non-deprecated, SoC-specific DSI compatible.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi
Now that the logic can handle multiple sets of registers, move
the QCM2290 to the common logic and mark it deprecated. This allows us
to remove a couple of structs, saving some memory.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
In preparation for supporting multiple sets of possible base registers,
remove the num_dsi variable. We're comparing the io_start array contents
with the reg value from the DTS, so it will either match one of the
expected values or don't match against a zero (which we get from partial
array
Currently, we allow for MAX_DSI entries in io_start to facilitate for
MAX_DSI number of DSI hosts at different addresses. The configuration
is matched against the DSI CTRL hardware revision read back from the
component. We need a way to resolve situations where multiple SoCs
with different
Il 16/03/23 07:31, Krzysztof Kozlowski ha scritto:
On 16/03/2023 07:19, Nancy Lin (林欣螢) wrote:
On Wed, 2023-03-15 at 08:16 +0100, Krzysztof Kozlowski wrote:
On 15/03/2023 04:45, Nancy Lin (林欣螢) wrote:
..snip..
[1].
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.e
xamp
On 15.03.23 18:44, Matthieu Baerts wrote:
> Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags
> followed by a link [1]. It also complains if a "Reported-by:" tag is
> followed by a "Closes:" one [2].
>
> As detailed in the first patch, this "Closes:" tag is used for a bit of
MediaTek MT8186 has a Mali-G52 MC2 2EE (Bifrost): add a new compatible
and platform data using the same supplies list as "mt8183_b" (only one
regulator), and a new pm_domains list with only two power domains.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Steven Price
Reviewed-by:
From: Alyssa Rosenzweig
MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID,
but treat it as otherwise identical to a standard Mali-G57.
We do _not_ fix up the GPU ID here -- userspace needs to be aware of the
special GPU ID, in case we find functional differences between
MT8186 has a Mali-G52 MC2 2EE GPU (two cores): add a binding with
two power domains (one per core) for it.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
Reviewed-by: Rob Herring
---
.../bindings/gpu/arm,mali-bifrost.yaml | 18
The MediaTek MT8195 SoC has a Mali G57 MC5 (Valhall-JM) and has the
same number of power domains and requirements as MT8192 in terms of
bindings.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
---
From: Alyssa Rosenzweig
Required for Mali-G57 on the Mediatek MT8192 and MT8195, which
uses even more power domains than the MT8183 before it.
Signed-off-by: Alyssa Rosenzweig
[Angelo: Removed unneeded "sram" supply, added mt8195 to commit description]
Co-developed-by: AngeloGioacchino Del
Changes in v5:
- Changed minItems for power-domain-names in base schema as
suggested by Rob
Changes in v4:
- Refactored power-domains and power-domain-names exclusions as
suggested by Krzysztof
- Small changes in MT8192 bindings addition
Changes in v3:
- Changed MT8186 bindings to
Commit ("dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183")
incorrectly introduced power domain names for MT8183, causing
validation issues.
Add power-domain-names to the base schema, allowing a maximum of
five elements; since platforms having a single power domain don't
need any actual domain
MediaTek MT8192 (and similar) needs five power domains for the
Mali GPU and no sram-supply: change the binding to allow so by
also introducing power-domain-names in the generic binding;
while at it, also disallow the newly introduced power-domain-names
for all non-MediaTek bindings.
Fixes:
From: Alyssa Rosenzweig
Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the
extra power domains required by the Mali-G57 on the MT8192.
Signed-off-by: Alyssa Rosenzweig
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Steven Price
Reviewed-by: Chen-Yu Tsai
Tested-by:
In preparation for adding (and fixing) power-domain-names and MediaTek
MT8192 bindings, allow up to five items for power-domains.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
Reviewed-by: Rob Herring
---
In preparation for adding new bindings for new MediaTek SoCs, split out
the power-domains variation from the `else` in the current
mediatek,mt8183-mali conditional.
The sram-supply part is left in place to be disallowed for anything
that is not compatible with "mediatek,mt8183-mali" as this
Hi Thorsten, Linus,
@Linus: in short, we would like to continue using the "Closes:" tag (or
similar, see below) with a URL in commit messages. They are useful to
have public bug trackers doing automated actions like closing a specific
ticket. Any objection from your side?
The full thread is
On Thu, 16 Mar 2023 12:47:51 +0200
Ville Syrjälä wrote:
> On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> > On Thu, 16 Mar 2023 11:50:27 +0200
> > Ville Syrjälä wrote:
> >
> > > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > > On Tue, Mar 7, 2023 at
Hi Dave & Daniel,
Here's the first batch of drm-intel-gt-next towards v6.4.
There is an important performance monitoring fix (#6333), more
resiliency to pcode load delay and avoiding caching problems on LLC
systems for ring buffers. Stolen memory probing fix and a
missing register whitelisting
clang reportes this error
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error:
variable 'possible_crtcs' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]
if (vp) {
^~
On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote:
> >
> > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote:
> > > >
> > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800,
On Thu, 16 Mar 2023 at 07:26, Christian König
wrote:
>
> That was accidentially left over when we switched to the delayed delete
> worker.
>
> Suggested-by: Matthew Auld
> Signed-off-by: Christian König
> Fixes: ("9bff18d13473") drm/ttm: use per BO cleanup workers
> Reported-by: Steven Rostedt
Hi Sui,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.3-rc2 next-20230316]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Thu, 16 Mar 2023 11:50:27 +0200
Ville Syrjälä wrote:
> On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland
> > wrote:
> > >
> > > We want compositors to be able to set the output
> > > colorspace on DP and HDMI outputs, based
On 2023/3/16 17:53, kernel test robot wrote:
Hi Sui,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.3-rc2 next-20230316]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Thu, Mar 16, 2023 at 12:07:01PM +0200, Pekka Paalanen wrote:
> On Thu, 16 Mar 2023 11:50:27 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Mar 16, 2023 at 01:37:24AM +0100, Sebastian Wick wrote:
> > > On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland
> > > wrote:
> > > >
> > > > We want
Make the description of @dev_priv to @i915 to silence the warnings:
drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Function parameter or
member 'i915' not described in 'intel_update_watermarks'
drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Excess function parameter
'dev_priv'
On 2023/3/16 16:46, Sui jingfeng wrote:
On 2023/3/16 15:18, Christian König wrote:
Am 15.03.23 um 22:15 schrieb Sui Jingfeng:
From: suijingfeng
Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and
On 15/03/2023 00:17, Adam Skladowski wrote:
Downstream driver appears to not support preemption on A510 target,
trying to use one make device slow and fill log with rings related errors.
Set num_rings to 1 to disable preemption.
Suggested-by: Dmitry Baryshkov
Fixes: e20c9284c8f2
We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c
We only keept that around for API compatibility with drivers. Clean all
this up and use the per device debugfs directory.
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c| 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
This compile tests on x86 just perfectly fine.
Signed-off-by: Christian König
CC: Thierry Reding
CC: Jonathan Hunter
CC: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/Kconfig | 2 +-
drivers/gpu/host1x/Kconfig| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Use managed memory allocation for this. That allows us to not keep
track of all the files any more.
Signed-off-by: Christian König
---
drivers/accel/drm_accel.c | 2 -
drivers/gpu/drm/drm_debugfs.c | 75 +-
drivers/gpu/drm/drm_drv.c | 2 -
Instead of the per minor directories only create a single debugfs
directory for the whole device directly when the device is initialized.
For DRM devices each minor gets a symlink to the per device directory
for now until we can be sure that this isn't useful any more in any way.
Accel devices
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
Completely drop that approach and just create the files directly but
return -ENODEV while opening the file
Hi guys,
I've messed up the last send out. Cleanup up some issues reported by people
with the accel drivers (duplicated files) and rebased the result.
Apart from that the same approach we already discussed previously.
Please review and comment,
Christian.
Not used by any drivers any more, the only use case in drm_dev_init()
can be inlined now.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_drv.c | 26 --
include/drm/drm_drv.h | 2 --
2 files changed, 4 insertions(+), 24 deletions(-)
diff --git
On 15/03/2023 09:16, Eero Tamminen wrote:
Hi,
Tested the patch with Ubuntu 22.04 desktop + Linux 6.2-rc3 (drm-tip)
kernel, on TGL-H HW.
With it, this log spam has disappeared:
[ 8691.608933] i915 :00:02.0: [drm] PXP firmware failed
Il 06/03/23 09:06, Jason-JH.Lin ha scritto:
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2
Hi,
this series is uncommented for some time now. Any feedback?
Thanks,
Alexander
Am Montag, 13. Februar 2023, 09:24:33 CET schrieb Alexander Stein:
> Hi,
>
> any feedback on this series?
>
> Best regards,
> Alexander
>
> Am Dienstag, 17. Januar 2023, 12:08:00 CET schrieb Alexander Stein:
>
1 - 100 of 221 matches
Mail list logo
