As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
diff --git
The name we are given is the first part of the command line, the part
before any option.
The most trivial case is thus that we're parsing a mode. However, the
connection status uses a single character to encode what status we want
to force on a connector.
It's thus fairly easy to confuse that
The name we are given is the first part of the command line split at a
comma.
We can thus be called in two cases, either we are parsing a (named?)
mode, before the optional part separated by a comma, or we never had a
mode specified but only options.
Options use the equal sign as separator
If the name we want to parse has a length of zero, there's no need to
compare it to the list of all the named modes we support, we can return
straight away.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index b1e800e4ed60..8d629fbb1047
If the name we want to parse starts with a digit, it's not a named mode.
Thus, there's no need to compare it to the list of all the named modes
we support, we can return straight away.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display
Some video= options might have a value that contains a dash. However, the
command line parsing mode considers all dashes as the separator between the
mode and the bpp count.
Let's rework the parsing code a bit to only consider a dash as the bpp
separator if it before a comma, the options
From: Geert Uytterhoeven
It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and bpp.
Fix this by skipping any dashes that are
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 generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
diff --git
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
The subconnector property was created by drm_mode_create_tv_properties(),
but wasn't exposed to the userspace through the generic
atomic_get/set_property implementation, and wasn't stored in any generic
state structure.
Let's solve this.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.
While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.
Worse, the
We currently have two sets of TV properties.
The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.
The second one is there to deal with
Since we've recently added a ton of tests, the list starts to be a bit
of a mess and creates unneeded conflicts.
Let's order it alphabetically.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index 91b70f7d2769..2d9f49b62ecb 100644
---
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Signed-off-by:
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
*
Hi Nirmoy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Nirmoy-Das/drm-i915-Improve-debug-print-in-vm_fault_ttm/20220922-201041
base: git://anongit.freedesktop.org/drm/drm-tip drm
Hi Simon,
On 8/30/22 14:29, Simon Ser wrote:
This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
commits, aka. "immediate flip" (which might result in tearing).
The feature was only available via the legacy uAPI, however for
gaming use-cases it may be desirable to enable it via the
On Thu, Sep 22, 2022 at 10:05:34AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 19:17, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Two things:
1)
Is there enough commonality to
Hi Dave and Daniel,
this is the drm-misc-fixes PR for this week.
Best regards
Thomas
drm-misc-fixes-2022-09-22:
Short summary of fixes pull
* drm/hisilicon: Depend on MMU
* drm/mgag200: Fix console on G200ER
* drm/panel: Fix innolux_g121i1_l01 bus format
The following changes since commit
Add support for the Sony TD4353 JDI 2160x1080 display panel used in
some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
of smartphone manufacturing, it is impossible to retrieve a better name
for this panel.
This revision adds support for the default 60 Hz configuration,
Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
Compact smartphones.
Signed-off-by: Konrad Dybcio
---
Changes since v1:
- remove device-specific compatibles in favour of panel-common
height/width-mm properties
- fix indentation in the example
On Wed, Sep 21, 2022 at 12:00:38PM +0530, Iddamsetty, Aravind wrote:
replying here for earlier comments too.
On 21-09-2022 01:35, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver tpo-tpg110-panel has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver s6d27a1-panel has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver abt-y030xx067a has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver nt39016 has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver ws2401-panel has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree.
Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT
compatible") added a test to check that every SPI driver has a
spi_device_id for each DT compatiable string defined
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver panel-ilitek-ili9322 has
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver panel-samsung-s6e63m0 has
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver nv3052c has no
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver panel-innolux-ej030na has
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver db7430-panel has no
On 9/21/22 10:10 PM, Kees Cook wrote:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing
On Wed, Sep 21, 2022 at 08:10:05PM -0700, Kees Cook wrote:
> Instead of discovering the kmalloc bucket size _after_ allocation, round
> up proactively so the allocation is explicitly made for the full size,
> allowing the compiler to correctly reason about the resulting size of
> the buffer
On 25/08/2022 12:40 pm, Sascha Hauer wrote:
On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote:
On 2022-08-22 16:20, Sascha Hauer wrote:
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a
Iterate over all damage clips and updated them one by one. Replaces
the merging of damage areas, which can result in significant overhead
if damage areas are not close to each other.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 24 +---
1 file
The primary plane implements atomic_disable, so atomic_update will
not be called without a framebuffer set. Remove the test for !fb.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c
Synchronize CPU access to GEM BOs with other drivers when updating the
screen buffer. Imported buffers might otherwise contain stale data.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
This patchset contains various improvements to simpledrm that have
piled up over time.
Thomas Zimmermann (5):
drm/simpledrm: Compute linestride with drm_format_info_min_pitch()
drm/simpledrm: Use drm_atomic_get_new_plane_state()
drm/simpledrm: Remove !fb check from atomic_update
Lookup the plane's state in atomic_update with the helper
drm_atomic_get_new_plane_state(). Also rename the helpers'
state arguments. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
If not given, compute the stride with drm_format_info_min_pitch(). It's
the standard helper for this purpose.
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Zimmermann
Fixes: fd9e3169e42b ("drm/simpledrm: Compute framebuffer stride if not set")
Cc: Javier Martinez Canillas
Cc:
On 19/09/2022 18:56, Guillaume Ranquet wrote:
> Add a compatible for the HDMI PHY on MT8195
>
> Signed-off-by: Guillaume Ranquet
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 19/09/2022 18:55, Guillaume Ranquet wrote:
> From: Pablo Sun
>
> Expand dt-bindings slot for VDOSYS1 of MT8195.
> This clock is required by the DPI1 hardware
> and is a downstream of the HDMI pixel clock.
>
> Signed-off-by: Pablo Sun
> Signed-off-by: Guillaume Ranquet
> Reviewed-by:
On 22/09/2022 14:45, Guillaume Ranquet wrote:
> On Thu, 22 Sep 2022 09:11, Krzysztof Kozlowski
> wrote:
>> On 19/09/2022 18:55, Guillaume Ranquet wrote:
>>> From: Pablo Sun
>>>
>>> Expand dt-bindings slot for VDOSYS1 of MT8195.
>>> This clock is required by the DPI1 hardware
>>> and is a
On Thu, 22 Sep 2022 09:11, Krzysztof Kozlowski
wrote:
>On 19/09/2022 18:55, Guillaume Ranquet wrote:
>> From: Pablo Sun
>>
>> Expand dt-bindings slot for VDOSYS1 of MT8195.
>> This clock is required by the DPI1 hardware
>> and is a downstream of the HDMI pixel clock.
>>
>> Signed-off-by: Pablo
From: Xinlei Lee
Due to the mt8186 hardware changes, we need to modify the dpi output
format corresponding to the mmsys register(mmsys_base+0x400).
Because different sink ICs may support other output formats.
The current DRM architecture supports retrieving the output format of
all bridges
From: Xinlei Lee
Add the compatible because use edge_cfg_in_mmsys in mt8186.
Signed-off-by: Xinlei Lee
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
2 files changed, 23 insertions(+)
diff --git
From: Xinlei Lee
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect.
So when setting the dpi output format, we need to call mmsys_func to set
it to MT8186 synchronously.
Adding mmsys all the
From: Xinlei Lee
Base on the branch of ck-linux-next/mediatek-drm-fixes.
Changes since v7:
1. This series is based on the following patch:
[1] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
On 22/09/2022 13:46, Dmitry Baryshkov wrote:
>>> - ranges: true
>>> +maxItems: 2
>>>
>>> interconnects:
>>> -items:
>>> - - description: Interconnect path from mdp0 port to the data bus
>>> - - description: Interconnect path from mdp1 port to the data bus
>>> +
On 22/09/2022 13:47, Dmitry Baryshkov wrote:
missing allOf
>>>
>>> Rob asked to remove this while reviewing v6 ([1]). And indeed the
>>> allOf's around a single $ref do not seem to be necessary
>>
>> He commented on one of properties, not top-level, maybe it is different
>> case for
On 22/09/2022 12:30, Dmitry Baryshkov wrote:
>>> +display-subsystem@ae0 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +compatible = "qcom,sc7180-mdss";
>>> +reg = <0xae0 0x1000>;
>>> +reg-names = "mdss";
>>> +power-domains = <
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, 2022-09-22 at 10:16 +0200, AngeloGioacchino Del Regno wrote:
> Il 22/09/22 09:29, xinlei@mediatek.com ha scritto:
> > From: Xinlei Lee
> >
> > The difference between MT8186 and other ICs is that when modifying
> > the
> > output format, we need to modify the mmsys_base+0x400 register
On 22/09/2022 10:04, Krzysztof Kozlowski wrote:
On 15/09/2022 15:37, Dmitry Baryshkov wrote:
Move properties common to all MDSS DT nodes to the mdss-common.yaml.
This extends qcom,msm8998-mdss schema to allow interconnect nodes, which
will be added later, once msm8998 gains interconnect
On 22/09/2022 14:43, Krzysztof Kozlowski wrote:
On 22/09/2022 09:53, Dmitry Baryshkov wrote:
On Thu, 22 Sept 2022 at 10:05, Krzysztof Kozlowski
wrote:
On 15/09/2022 15:37, Dmitry Baryshkov wrote:
Move properties common to all MDSS DT nodes to the mdss-common.yaml.
This extends
On 22-09-22, 14:30, Dmitry Baryshkov wrote:
> This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform.
Tested this on DM8450-HDK with HDMI and it works for me.
For whole series:
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
>
> Dmitry Baryshkov (5):
> drm/msm/dsi: add
On 22/09/2022 09:53, Dmitry Baryshkov wrote:
> On Thu, 22 Sept 2022 at 10:05, Krzysztof Kozlowski
> wrote:
>>
>> On 15/09/2022 15:37, Dmitry Baryshkov wrote:
>>> Move properties common to all MDSS DT nodes to the mdss-common.yaml.
>>>
>>> This extends qcom,msm8998-mdss schema to allow
On 22/09/2022 09:50, Dmitry Baryshkov wrote:
> On Thu, 22 Sept 2022 at 10:02, Krzysztof Kozlowski
> wrote:
>>
>> On 15/09/2022 15:37, Dmitry Baryshkov wrote:
>>> Move properties common to all DPU DT nodes to the dpu-common.yaml.
>>>
>>> Note, this removes description of individual DPU port@
Support the CRTC's color-management property and implement each model's
palette support.
The OF hardware has different methods of setting the palette. The
respective code has been taken from fbdev's offb and refactored into
per-model device functions. The device functions integrate this
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the system's firmware. Runtime
modesetting via DRM is not
Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.
v3:
* define constants for PCI ids (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
PowerPC's Open Firmware offers a simple display buffer for graphics
output. Add ofdrm, a DRM driver for the device. As with the existing
simpledrm driver, the graphics hardware is pre-initialized by the
firmware. The driver only provides blitting, no actual DRM modesetting
is possible.
For
Add a dedicated CRTC state to ofdrm to later store information for
palette updates.
v3:
* rework CRTC state helpers (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 59 ++--
1 file
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 +
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
Co-developed-by: Robert Foss
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 6 +-
Add support for the MDSS block on SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index e13c5c12b775..9e011762396b 100644
---
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform.
Dmitry Baryshkov (5):
drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450
drm/msm/dsi: add support for DSI 2.6.0
drm/msm/dpu: add support for MDP_TOP blackhole
drm/msm/dpu: add support for SM8450
drm/msm: mdss
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
Add support for DSI 2.6.0 (block used on sm8450).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index
On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote:
> In the effort to help the compiler reason about buffer sizes, the
> __alloc_size attribute was added to allocators. This improves the scope
> of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near
> future)
On 2022-09-21 17:54, Sasha Levin wrote:
> From: Hamza Mahfooz
>
> [ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
>
> Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
> drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
> struct.
>
>
On Thu, 22 Sept 2022 at 10:08, Krzysztof Kozlowski
wrote:
>
> On 15/09/2022 15:37, Dmitry Baryshkov wrote:
> > In order to make the schema more readable, split dpu-sc7180 into the DPU
> > and MDSS parts, each one describing just a single device binding.
> >
> > Signed-off-by: Dmitry Baryshkov
>
Each of the user contexts has two command queues, one for compute engine
and one for the copy engine. Command queues are allocated and registered
in the device when the first job (command buffer) is submitted from
the user space to the VPU device. The userspace provides a list of
GEM buffer object
The IPC driver is used to send and receive messages to/from firmware
running on the VPU.
The only supported IPC message format is Job Submission Model (JSM)
defined in vpu_jsm_api.h header.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
- Implement cold and warm firmware boot flows
- Add hang recovery support
- Add runtime power management support
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 3 +-
drivers/gpu/drm/ivpu/ivpu_drv.c| 34 ++-
Read, parse and boot VPU firmware image.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 122 +++-
drivers/gpu/drm/ivpu/ivpu_drv.h | 10 +
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to
VPU Memory Management Unit is based on ARM MMU-600.
It allows to create multiple virtual address spaces for the device and
map noncontinuous host memory (there is no dedicated memory on the VPU).
Address space is implemented as a struct ivpu_mmu_context, it has an ID,
drm_mm allocator for VPU
VPU stands for Versatile Processing Unit and it's a CPU-integrated
inference accelerator for Computer Vision and Deep Learning
applications.
The VPU device consist of following componensts:
- Buttress - provides CPU to VPU integration, interrupt, frequency and
power management.
- Memory
Hi,
This patchset contains a new Linux* Kernel Driver for Intel® VPUs.
VPU stands for Versatile Processing Unit and it is an AI inference accelerator
integrated with Intel non-server CPUs starting from 14th generation.
VPU enables efficient execution of Deep Learning applications
like object
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
> new file mode 100644
> index ..725febfd6a53
> --- /dev/null
> +++
I just correct the subject line and resend the patch mail.
Please refer to:
[PATCH resend v2] drm/amdgpu: fix enum conversion in display_mode_vba
On 2022/9/19 15:44, Christian König wrote:
Am 19.09.22 um 03:41 schrieb Zeng Heng:
Fix below compile warning when open enum-conversion
option
On Wed, Sep 21, 2022 at 02:50:49PM -0700, Li Zhong wrote:
> Subject: [PATCH v1] drivers:adp8870_bl: check the return value of
> adp8870_write
Should be backlight: adp8870_bl.
> Check and propagate the return value of adp8870_write() when it fails,
>
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add support for handling out fence for vm_bind call.
>
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
> .../drm/i915/gem/i915_gem_vm_bind_object.c|
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add uapi and implement support for bind and unbind of an
> object at the specified GPU virtual addresses.
>
> The vm_bind mode is not supported in legacy execbuf2 ioctl.
> It will be supported only in the newer execbuf3 ioctl.
>
>
On 22/09/2022 05:43, Niranjana Vishwanathapura wrote:
The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 ++---
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add function __i915_sw_fence_await_reservation() for
> asynchronous wait on a dma-resv object with specified
> dma_resv_usage. This is required for async vma unbind
> with vm_bind.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
>
On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote:
>
> -#ifdef __alloc_size__
> -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
> -#else
> -# define __alloc_size(x, ...) __malloc
> -#endif
> +#define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc
>
Fix below compile warning when open enum-conversion
option check (compiled with -Wenum-conversion):
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:
In function ‘dml20_ModeSupportAndSystemConfigurationFull’:
On 21/09/2022 19:17, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between
101 - 200 of 242 matches
Mail list logo
