On 18.04.2023 01:53, Andi Shyti wrote:
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc:
Hi Vinay,
On Mon, Apr 17, 2023 at 11:04:31PM -0700, Belgaumkar, Vinay wrote:
>
> On 4/17/2023 6:39 PM, Andi Shyti wrote:
> > Hi Vinay,
> >
> > Looks good, just few minor comments below,
> >
> > [...]
> >
> > > @@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int
> > > test_type)
Sorry, I found that the latest code function has become amdgpu_cs_pass1,
and radeon_cs_parser_init has the same problem.And i will send the patch.
whitehat002 whitehat002 于2023年4月18日周二 11:39写道:
> Hello,
>
> I am going to file a security bug.
>
> VULNERABILITY DETAILS
>
> ioctl$AMDGPU_CS will cal
We have some machines with ASPEED SATA controllers, and are seeing the same NCQ
issues that ATI controllers (I am not sure if it's a rebranded ATI controller,
or they both have some faulty implementation). This NCQ breakage is consistent
across a few different types of drives.
Instead of maintaini
Hello,
I am going to file a security bug.
VULNERABILITY DETAILS
ioctl$AMDGPU_CS will call amdgpu_cs_ioctl which will call
amdgpu_cs_parser_init. The type of size is unsigned(4 bytes)[1]. And size
is assigned from p->chunks[i].length_dw[2] which is assigned from
user_chunk.length_dw[3], which typ
Currently the ASPEED PCI vendor ID is defined in drivers/gpu/drm/ast/ast_drv.c,
move that to include/linux/pci_ids.h with all the rest of the PCI vendor ID
definitions. Rename the definition to follow the format that the other
definitions follow.
Signed-off-by: Patrick McLean
---
drivers/gpu/drm
On 17/04/2023 17:30, Konrad Dybcio wrote:
> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
> another path that needs to be handled to ensure MDSS functions properly,
> namely the "reg bus", a.k.a the CPU-MDSS interconnect.
>
> Gating that path may have a variety of effects.. f
Hi
Am 18.04.23 um 03:23 schrieb Jammy Huang:
Hi Thomas,
The Intel(x86) CPUs have a separate address space for "IO", but the ARM
architecture only has "memory", so all IO devices are accessed as if
they were memory. Which means ARM does not support isolated IO. Here is
a related discussion on
Hi
Am 17.04.23 um 16:12 schrieb Arnd Bergmann:
On Mon, Apr 17, 2023, at 14:56, Thomas Zimmermann wrote:
Various architectures provide with helpers for fbdev
framebuffer devices. Share the contained code where possible. There
is already , which implements generic (as in
'empty') functions of th
Hi Geert,
Thank you for the patch.
On Mon, Apr 17, 2023 at 03:40:21PM +0200, Geert Uytterhoeven wrote:
> Replace the printing of hexadecimal fourcc format codes by
> pretty-printed format names, using the "%p4cc" format specifier.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Thomas Zimm
Hi Geert,
On Mon, Apr 17, 2023 at 03:40:20PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> Currently, there are two drivers for the LCD controller on Renesas
> SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
> 1. sh_mobile_lcdcfb, using the fbdev framework,
> 2. shmob_drm, usin
On 2023-04-17 18:54:18, Abhinav Kumar wrote:
>
> On 4/17/2023 4:14 PM, Marijn Suijten wrote:
> > Some of these members were initialized while never read, while others
> > were not even assigned any value at all. Drop them to save some space,
> > and above all confusion when looking at these membe
Hi Thomas,
Thanks for you reminder. The comment you mentioned is added in 2014 for
AST2400 rev 0x20, which means MMIO is not enable by default before that
revision. I will send another patch to handle it.
On 2023/4/18 下午 03:24, Thomas Zimmermann wrote:
Hi
Am 18.04.23 um 03:23 schrieb Jammy
On 4/18/23 14:24, Christoph Hellwig wrote:
> On Mon, Apr 17, 2023 at 06:17:20PM -0700, Patrick McLean wrote:
>> We have some machines with ASPEED SATA controllers, and are seeing the same
>> NCQ
>> issues that ATI controllers (I am not sure if it's a rebranded ATI
>> controller,
>> or they both h
Hi Laurent,
On Tue, Apr 18, 2023 at 9:49 AM Laurent Pinchart
wrote:
> On Mon, Apr 17, 2023 at 03:40:20PM +0200, Geert Uytterhoeven wrote:
> > Currently, there are two drivers for the LCD controller on Renesas
> > SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
> > 1. sh_mobile_lcdcfb, u
New in v6: a oneliner fix to patch 14 for an unlock imbalance in MIPI CSI
calibration (Tegra210 only). Many thanks to Hans for testing and spotting
this!
Full details follow.
Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
receive from either MIPI CSI-2 or parallel video
VIP is the parallel video capture component within the video input
subsystem of Tegra20 (and other Tegra chips, apparently).
Signed-off-by: Luca Ceresoli
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
-
The Tegra20 VI peripheral can receive parallel input from the VIP parallel
input module. Add it to the allowed properties and augment the existing
nvidia,tegra20-vi example to show a 'vip' property.
Signed-off-by: Luca Ceresoli
Reviewed-by: Rob Herring
---
No changes in v6
No changes in v5
Ch
Clarify what this function does.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 3 +++
1 file changed, 3 insertions(+)
diff --
Some fields are irrelevant for Tegra20/VIP. Add a note to clarify that.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 6 +++---
tegra_vi_channels_alloc() can primarily fail for two reasons:
1. "ports" node not found
2. port_num > vi->soc->vi_max_channels
Case 1 prints nothing, case 2 has a dev_err(). The caller [tegra_vi_init()]
has a generic dev_err() on any failure. This mean that in case 2 we print
two messages, and
of_node_put(node) does nothing if node == NULL, so it can be moved to the
cleanup section at the bottom.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/
Add "skip" in "so we can *skip* the current channel" or it doesn't make
sense.
Also add articles where appropriate to fix English grammar.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No
This declaration is used only in csi.c, no need to export it elsewhere.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
This patch was added in v3.
---
drivers/staging/media/tegra-video/csi.c | 4
drive
struct tegra_vi_graph_entity is an internal implementation detail of the VI
module. Move its declaration from vi.h to vi.c.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
--
We are about to add support for the Tegra20 parallel video capture, which
has no TPG. In preparation for that, limit the VIDEO_TEGRA_TPG option to
Tegra210 which is the only implementation currently provided by this
driver.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No chang
tegra_channel_fmt_align() takes care of the size constraints, alignment and
rounding requirements of the Tegra210 VI peripheral. Tegra20 has different
constraints.
In preparation for adding Tegra20 support, move this function to a new op
in the soc-specific `struct tegra_vi_ops` .
Also move to te
There is only a pointer reference to struct tegra_vi in video.h, thus vi.h
is not needed.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-vid
The tegra_default_format in vi.c is specific to Tegra210 CSI.
In preparation for adding Tegra20 VIP support, move the default format to a
new field in the soc-specific `struct tegra_vi_soc`. Instead of an entire
format struct, only store a pointer to an item in the existing format
array.
No funct
The CSI module does not handle all the MIPI lane calibration procedure,
leaving a small part of it to the VI module. In doing this,
tegra_channel_enable_stream() (vi.c) manipulates the private data of the
upstream subdev casting it to struct 'tegra_csi_channel', which will be
wrong after introducin
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-vid
tegra_channel_host1x_syncpt_init() gets the host1x syncpts needed for the
Tegra210 implementation, and tegra_channel_host1x_syncpts_free() puts
them.
Tegra20 needs to get and put a different syncpt. In preparation for adding
Tegra20 support, move these functions to new ops in the soc-specific
`str
In preparation to implement Tegra20 parallel video capture, add a variable
to hold the required syncpt and document all the syncpt variables.
Signed-off-by: Luca Ceresoli
Reviewed-by: Dmitry Osipenko
---
No changes in v6
No changes in v5
Changed in v4:
- Added review tags
Changed in v3:
-
Tegra20 supports planar YUV422 capture, which can be implemented by writing
U and V base address registers in addition to the "main" base buffer
address register.
It also supports H and V flip, which among others requires to write the
start address (i.e. the 1st offset to write, at the end of the
Tegra20 can do horizontal and vertical image flip, but Tegra210 cannot
(either the hardware, or this driver).
In preparation to adding Tegra20 support, add a flag in struct tegra_vi_soc
so the generic vi.c code knows whether the flip controls should be added or
not.
Also provide a generic impleme
The VI peripheral of Tegra supports capturing from MIPI CSI-2 or parallel
video (called VIP in the docs).
The staging tegra-video driver currently implements MIPI CSI-2 video
capture for Tegra210. Add support for parallel video capture (VIP) on
Tegra20. With the generalizations added to the VI dri
Il 17/04/23 17:41, Konrad Dybcio ha scritto:
Commit 5dd45b66742a ("drm/panel: novatek-nt35950: Improve error handling")
introduced logic to unregister DSI1 on any sort of probe failure, as
that's not done automatically by kernel APIs.
It did not however account for cases where only one DSI host
Hi Hans,
On Fri, 14 Apr 2023 17:51:34 +0200
Hans Verkuil wrote:
> Hi Luca,
>
> I just encountered an error in this patch, so I have rejected the PR I made.
>
> See below for the details:
>
> On 07/04/2023 15:38, Luca Ceresoli wrote:
> > The CSI module does not handle all the MIPI lane calibra
Hi Jonathan,
Le dimanche 16 avril 2023 à 15:24 +0100, Jonathan Cameron a écrit :
> On Mon, 3 Apr 2023 17:47:52 +0200
> Paul Cercueil wrote:
>
> > The buffer-dma code was using two queues, incoming and outgoing, to
> > manage the state of the blocks in use.
> >
> > While this totally works, it
Hi Geert,
On Tue, Apr 18, 2023 at 10:00:35AM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 18, 2023 at 9:49 AM Laurent Pinchart wrote:
> > On Mon, Apr 17, 2023 at 03:40:20PM +0200, Geert Uytterhoeven wrote:
> > > Currently, there are two drivers for the LCD controller on Renesas
> > > SuperH-base
On 18/04/2023 10:07, Luca Ceresoli wrote:
> Hi Hans,
>
> On Fri, 14 Apr 2023 17:51:34 +0200
> Hans Verkuil wrote:
>
>> Hi Luca,
>>
>> I just encountered an error in this patch, so I have rejected the PR I made.
>>
>> See below for the details:
>>
>> On 07/04/2023 15:38, Luca Ceresoli wrote:
>>>
On Thu, Apr 13, 2023 at 11:34:17AM +0100, Sarah Walker wrote:
> This patch adds the initial DRM driver for Imagination Technologies PowerVR
> GPUs, starting with those based on our Rogue architecture. It's worth pointing
> out that this is a new driver, written from the ground up, rather than a
> r
On 17/04/2023 21:12, Rob Clark wrote:
From: Rob Clark
The restriction about no whitespace, etc, really only applies to the
usage of strings in keys. Values can contain anything (other than
newline).
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 29 ++---
Hi,
On Mon, 17 Apr 2023 17:41:08 +0200, Konrad Dybcio wrote:
> Commit 5dd45b66742a ("drm/panel: novatek-nt35950: Improve error handling")
> introduced logic to unregister DSI1 on any sort of probe failure, as
> that's not done automatically by kernel APIs.
>
> It did not however account for cases
On 17/04/2023 21:12, Rob Clark wrote:
From: Rob Clark
Make it work in terms of ctx so that it can be re-used for fdinfo.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c
On 4/18/23 04:29, Adam Ford wrote:
On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut wrote:
On 4/15/23 12:41, Adam Ford wrote:
Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
having an entry in the device tree for samsung,pll-clock-frequency.
Signed-off-by: Adam Ford
---
drivers/
On Mon, Apr 17, 2023 at 07:32:19PM +0800, Sui Jingfeng wrote:
> The fbdev test of IGT may write after EOF, which lead to out-of-bound
> access for the drm drivers using fbdev-generic. For example, on a x86
> + aspeed bmc card platform, with a 1680x1050 resolution display, running
> fbdev test if IG
On Tue, Apr 18, 2023 at 09:27:49AM +0100, Tvrtko Ursulin wrote:
>
> On 17/04/2023 21:12, Rob Clark wrote:
> > From: Rob Clark
> >
> > Make it work in terms of ctx so that it can be re-used for fdinfo.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +
On Mon, Apr 17, 2023 at 06:17:19PM -0700, Patrick McLean wrote:
> Currently the ASPEED PCI vendor ID is defined in
> drivers/gpu/drm/ast/ast_drv.c,
> move that to include/linux/pci_ids.h with all the rest of the PCI vendor ID
> definitions. Rename the definition to follow the format that the other
Hello!
On 4/18/23 4:17 AM, Patrick McLean wrote:
> We have some machines with ASPEED SATA controllers, and are seeing the same
> NCQ
> issues that ATI controllers (I am not sure if it's a rebranded ATI controller,
> or they both have some faulty implementation). This NCQ breakage is consistent
>
On Wed, Apr 05, 2023 at 09:29:02PM +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2023 at 05:43:01PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> > > +/// An armed DRM scheduler job (not yet submitted)
> > > +pub struct ArmedJob<'a, T: JobImpl>(Box>,
Am Dienstag, dem 18.04.2023 um 10:30 +0200 schrieb Marek Vasut:
> On 4/18/23 04:29, Adam Ford wrote:
> > On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut wrote:
> > >
> > > On 4/15/23 12:41, Adam Ford wrote:
> > > > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > > > having an entry
On 4/18/23 4:17 AM, Patrick McLean wrote:
> Currently the ASPEED PCI vendor ID is defined in
> drivers/gpu/drm/ast/ast_drv.c,
> move that to include/linux/pci_ids.h with all the rest of the PCI vendor ID
> definitions. Rename the definition to follow the format that the other
> definitions follow
On Tue, 18 Apr 2023, Wayne Lin wrote:
> [Why & How]
> The sequence for collecting down_reply/up_request from source
> perspective should be:
>
> Request_n->repeat (get partial reply of Request_n->clear message ready
> flag to ack DPRX that the message is received) till all partial
> replies for Re
On 17/04/2023 21:12, Rob Clark wrote:
From: Rob Clark
Normally this would be the same information that can be obtained in
other ways. But in some cases the process opening the drm fd is merely
a sort of proxy for the actual process using the GPU. This is the case
for guest VM processes usin
On 17/04/2023 20:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 ++
Hi
Am 18.04.23 um 10:32 schrieb Daniel Vetter:
On Mon, Apr 17, 2023 at 07:32:19PM +0800, Sui Jingfeng wrote:
The fbdev test of IGT may write after EOF, which lead to out-of-bound
access for the drm drivers using fbdev-generic. For example, on a x86
+ aspeed bmc card platform, with a 1680x1050 r
https://bugzilla.kernel.org/show_bug.cgi?id=217348
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
Looks like the 'PATCH' part of your subject was cut off!
Konrad
On 17.04.2023 22:12, Rob Clark wrote:
> From: Rob Clark
>
> When many of the things using the GPU are processes in a VM guest, the
> actual client process is just a proxy. The msm driver has a way to let
> the proxy tell the kerne
On 4/17/23 22:42, Arthur Grillo Queiroz Cabral wrote:
On 17/04/23 13:19, Maíra Canal wrote:
On 4/6/23 08:53, Arthur Grillo wrote:
Insert parameterized test for the drm_rect_calc_vscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the excep
From: Dafna Hirschfeld
the helper is extract_u32_until_given_char and can later be used to
also get the major/minor of the sw version.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/firmware_if.c | 69 --
From: Dafna Hirschfeld
The fw inner version is less trustable, instead use the fw general
sw release version.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 10 --
drivers/accel/habanalabs/gaudi2/
From: Ofir Bitton
User needs to be able to perform downcast / upcast of fp8_143 dtype.
Hence bias register needs to be accessed by the user.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2_security.c | 1 +
1 file chan
From: Dafna Hirschfeld
This is done depending on the FW version. The cpucp method is
preferable and saves scratchpads resource.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/firmware_if.c | 14 ++
drivers/accel
From: Dafna Hirschfeld
We later want to add fields for Firmware SW version. The current
extracted FW version is the inner FW versioning so the new name
is better and also better differentiate from the FW's SW version.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded
From: Dafna Hirschfeld
It is not always possible to know the FW's SW version from the inner FW
version. Therefore we should extract the general SW version in addition
to the FW version and use it in functions like
'hl_is_fw_ver_below_1_9' etc.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded G
From: farah kassabri
Add uapi to allow user to unregister timestamp record.
This is needed when the user wishes to re-use the same record with
different interrupt id. For that, the user must first unregister it
from the current interrupt id and then register it with the new id.
Signed-off-by: fa
From: Koby Elbaz
Sync Stream Encapsulated Signal Handlers can be managed from different
contexts, and as such they are protected via a spin_lock.
However, spin_lock was unnecessarily protecting a larger code section
than really needed, covering a sleepable code section as well.
Since spin_lock di
From: Koby Elbaz
Aborting CS completions should be in command_submission.c but aborting
waiting for user interrupts should be in device.c.
This separation is also for adding more abort operations in the future.
Signed-off-by: Koby Elbaz
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
From: Moti Haimovski
This commit modifies the call to retrieve HW or FW error events to
return success when no events are pending, as done in the calls to
other events.
Signed-off-by: Moti Haimovski
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
.../habanalabs/common/habanalabs_ioct
[Public]
Hi Jani Nikula,
Appreciate your time and feedback! Will adjust the patch.
Some comments inline.
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, April 18, 2023 4:53 PM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: ly...@redha
It already happend a few times that patches slipped through which
implemented access to an entity through a job that was already removed
from the entities queue. Since jobs and entities might have different
lifecycles, this can potentially cause UAF bugs.
In order to make it obvious that a jobs en
From: Frieder Schrempf
This patchset contains a proposal to fix the initialization flow for
the display pipeline used on our i.MX8MM Kontron boards:
i.MX8MM LCDIF -> i.MX8MM DSIM -> TI SN65DSI84 -> 7" LVDS Panel
Without these changes the display works most of the time, but fails
to come up oc
From: Frieder Schrempf
According to the documentation [1] the proper enable flow is:
1. Enable DSI link and keep data lanes in LP-11 (stop state)
2. Disable stop state to bring data lanes into HS mode
Currently we do this all at once within enable(), which doesn't
allow to meet the requirements
From: Frieder Schrempf
The datasheet describes the following initialization flow including
minimum delay times between each step:
1. DSI data lanes need to be in LP-11 and the clock lane in HS mode
2. toggle EN signal
3. initialize registers
4. enable PLL
5. soft reset
6. enable DSI stream
7. ch
From: Frieder Schrempf
Assuming that with the init flow fixed to meet the documentation at
[1] and the pre_enable_prev_first flag set in downstream bridge/panel
drivers which require it, we can use the default flow for Exynos as
already done for i.MX8M.
[1] https://docs.kernel.org/gpu/drm-kms-he
On 17/04/2023 17:20, Christian König wrote:
Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c | 52 +++
On Mon, Apr 17, 2023 at 2:00 AM Alexander Stein
wrote:
>
> Hi,
>
> Am Montag, 17. April 2023, 00:31:24 CEST schrieb Adam Ford:
> > On Sun, Apr 16, 2023 at 5:07 PM Marek Vasut wrote:
> > > On 4/15/23 12:40, Adam Ford wrote:
> > > > According to Table 13-45 of the i.MX8M Mini Reference Manual, the
On 14/04/2023 07:43, Uwe Kleine-König wrote:
Hello,
On Wed, Apr 12, 2023 at 01:27:13PM +0200, AngeloGioacchino Del Regno wrote:
Add a compatible string for MediaTek Helio X10 MT6795's display PWM
block: this is the same as MT8173.
Signed-off-by: AngeloGioacchino Del Regno
Acked-by: Uwe
On Tue, 18 Apr 2023, "Lin, Wayne" wrote:
> [Public]
>
> Hi Jani Nikula,
>
> Appreciate your time and feedback! Will adjust the patch.
> Some comments inline.
>
>> -Original Message-
>> From: Jani Nikula
>> Sent: Tuesday, April 18, 2023 4:53 PM
>> To: Lin, Wayne ; dri-devel@lists.freedeskt
v1 -> v2:
- Fix "Mbps" -> "MBps" [5/5]
- Add an interconnects: entry in dt-bindings (and not only -names..) [1/5]
v1:
https://lore.kernel.org/r/20230417-topic-dpu_regbus-v1-0-06fbdc164...@linaro.org
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
D
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
O
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
O
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DISPLAY_CFG path, rename
the path-related struc
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DISPLAY_CFG path, rename
the path-related struc
On 17.04.2023 22:21, Marijn Suijten wrote:
> No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
> offset downstream. Even though neither downstream nor upstream utilizes
> these registers in any way, remove the erroneous specification for
> SC8280XP, SM8350 and SM8450 to preven
On 17.04.2023 22:21, Marijn Suijten wrote:
> These offsets do not fall under the MDP TOP block and do not fit the
> comment right above. Move them to dpu_hw_interrupts.c next to the
> repsective MDP_INTF_x_OFF interrupt block offsets.
>
> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
On 17.04.2023 22:21, Marijn Suijten wrote:
> SM8550 only comes with a DITHER subblock inside the PINGPONG block,
> hence the name and a block length of zero. However, the PP_BLK macro
> name was typo'd to DIPHER rather than DITHER.
>
> Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550"
On 17.04.2023 22:21, Marijn Suijten wrote:
> The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
> registers are already defined higher up, in the right place when sorted
> numerically.
>
> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
> Signed-off-by: Marijn Suijten
>
On 17.04.2023 22:21, Marijn Suijten wrote:
> A bunch of registers are indented with two extra spaces, looking as if
> these are values corresponding to the previous register which is not the
> case, rather these are simply also register offsets and should only have
> a single space separating th
On 17.04.2023 22:21, Marijn Suijten wrote:
> A bunch of registers were appended at the end in e.g. 91143873a05d
> ("drm/msm/dpu: Add MISR register support for interface") rather than
> being inserted in a place that maintains numerical sorting. Restore
> that.
>
> Signed-off-by: Marijn Suijten
On 17.04.2023 22:21, Marijn Suijten wrote:
> This callback was migrated from downstream when DPU1 was first
> introduced to mainline, but never used by any component. Drop it to
> save some lines and unnecessary confusion.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Marijn Suijten
>
From: Daniel Vetter
commit 6fd33ac7916689b8f051a185defe4dd515b0 upstream.
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but sin
From: Daniel Vetter
commit 6fd33ac7916689b8f051a185defe4dd515b0 upstream.
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but sin
From: Daniel Vetter
commit 6fd33ac7916689b8f051a185defe4dd515b0 upstream.
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but sin
From: Daniel Vetter
commit 6fd33ac7916689b8f051a185defe4dd515b0 upstream.
This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt
restore") - I failed to realize that nasty userspace could set this.
It's not pretty to mix up kernel-internal and userspace uapi flags
like this, but sin
On 17.04.2023 22:21, Marijn Suijten wrote:
> Since hardware revision 5.0.0 the TE configuration moved out of the
> PINGPONG block into the INTF block. Writing these registers has no
> effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
> flag. This flag is only added to PINGP
On 17.04.2023 22:21, Marijn Suijten wrote:
> As the INTF block is going to attain more interrupts that don't share
> the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
> the caller to construct the right interrupt index (register and bit
> index) to not make the interrupt bit
On 17.04.2023 22:21, Marijn Suijten wrote:
> All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
> the PINGPONG block and into the INTF block. Wire up these interrupts
> and IRQ masks on all supported hardware.
>
> Signed-off-by: Marijn Suijten
> ---
Acked-by: Konrad Dybci
1 - 100 of 208 matches
Mail list logo