On Thu, May 16, 2024 at 8:21 PM Yunfei Dong wrote:
>
> Need secure buffer size to convert secure handle to secure
> pa in optee-os, re-construct the vsi struct to store each
> secure buffer size.
>
> Separate svp and normal wait interrupt condition for svp mode
> waiting hardware interrupt in
On Mon, May 27, 2024 at 12:54 PM Fei Shao wrote:
>
> On Mon, May 27, 2024 at 12:38 PM Chen-Yu Tsai wrote:
> >
> > On Mon, May 27, 2024 at 12:34 PM Fei Shao wrote:
> > >
> > > Hi Shawn,
> > >
> > > On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote:
> > > >
> > > > From: Hsiao Chien Sung
> > > >
On Mon, May 27, 2024 at 12:38 PM Chen-Yu Tsai wrote:
>
> On Mon, May 27, 2024 at 12:34 PM Fei Shao wrote:
> >
> > Hi Shawn,
> >
> > On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote:
> > >
> > > From: Hsiao Chien Sung
> > >
> > > Set DRM mode configs limitation according to the hardware
On Mon, May 27, 2024 at 12:34 PM Fei Shao wrote:
>
> Hi Shawn,
>
> On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote:
> >
> > From: Hsiao Chien Sung
> >
> > Set DRM mode configs limitation according to the hardware capabilities
> > and pass the IGT checks as below:
> >
> > - The test
Hi Shawn,
On Thu, May 2, 2024 at 6:39 PM Shawn Sung wrote:
>
> From: Hsiao Chien Sung
>
> Set DRM mode configs limitation according to the hardware capabilities
> and pass the IGT checks as below:
>
> - The test "graphics.IgtKms.kms_plane" requires a frame buffer with
> width of 4512 pixels
Hello:
This patch was applied to chrome-platform/linux.git (for-next)
by Chun-Kuang Hu :
On Wed, 17 Apr 2024 10:38:19 + you wrote:
> In case there is no DP device attached to the port the
> transfer function should return IO error, similar to what
> other drivers do.
> In case EAGAIN is
Hello:
This patch was applied to chrome-platform/linux.git (for-kernelci)
by Chun-Kuang Hu :
On Wed, 17 Apr 2024 10:38:19 + you wrote:
> In case there is no DP device attached to the port the
> transfer function should return IO error, similar to what
> other drivers do.
> In case EAGAIN is
Hi,
On 5/27/24 07:33, kernel test robot wrote:
Hi Sui,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.10-rc1 next-20240523]
[cannot apply to shawnguo/for-next]
[If your patch is applied to
Hi,
On 5/27/24 05:19, Dmitry Baryshkov wrote:
On Mon, May 27, 2024 at 04:21:07AM +0800, Sui Jingfeng wrote:
Normally, the drm_bridge::of_node won't be used by bridge driver instances
themselves. Rather, it is mainly used by other modules to find associated
drm bridge drvier. Therefore, adding
In r100_cp_init_microcode, if rdev->family don't match any of
if statement, fw_name will be NULL, which will cause
gcc (11.4.0 powerpc64le-linux-gnu) complain:
In function ‘r100_cp_init_microcode’,
inlined from ‘r100_cp_init’ at drivers/gpu/drm/radeon/r100.c:1136:7:
Hi Sui,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.10-rc1 next-20240523]
[cannot apply to shawnguo/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Mon, May 27, 2024 at 04:21:07AM +0800, Sui Jingfeng wrote:
> Normally, the drm_bridge::of_node won't be used by bridge driver instances
> themselves. Rather, it is mainly used by other modules to find associated
> drm bridge drvier. Therefore, adding a drm bridge to the global bridge list
> and
On Mon, May 27, 2024 at 03:58:24AM +0800, Sui Jingfeng wrote:
> In some display subsystems, the functionality of a PCIe device may too
> complex to be managed by a single driver. A split of the functionality
> into child devices can helpful to achieve better modularity.
>
> Another benefit is
https://bugzilla.kernel.org/show_bug.cgi?id=218891
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Use the freshly created helper to replace the use of DT-dependent APIs,
also print error log if the fwnode graph is not complete which is benefit
to debug.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/chrontel-ch7033.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Make this driver less DT-dependent by calling the newly created helpers,
also switch to use fwnode APIs to acquire additional device properties.
No functional changes for DT-based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ti-tfp410.c | 39 +++---
1
Switch to use the freshly created drm_bridge_set_node() helper, no
functional changes. The reason behind of this introduction is that
the name 'of_node' itself has a smell of DT dependent, and it is a
internal memeber, when there has helper function, we should use the
revelant helper and avoid
Make this driver less DT-dependent by calling the newly created helpers,
also switch to use fwnode APIs to acquire additional device properties.
A side benifit is that boilerplates get reduced, no functional changes
for DT-based systems.
Signed-off-by: Sui Jingfeng
---
Make this driver less DT-dependent by calling the freshly created helpers,
also switch to use fwnode APIs to acquire additional device properties.
One side benifit is that boilerplates get reduced, no functional changes
for DT-based systems.
Signed-off-by: Sui Jingfeng
---
Switch to use the fwnode APIs, which is a fundamental step to make this
driver OF-independent possible. No functional changes for DT-based systems.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/display-connector.c | 23 +++---
1 file changed, 11 insertions(+), 12
Normally, the drm_bridge::of_node won't be used by bridge driver instances
themselves. Rather, it is mainly used by other modules to find associated
drm bridge drvier. Therefore, adding a drm bridge to the global bridge list
and setting 'of_node' field of a drm bridge share the same goal. Both are
Make this driver less DT-dependent by calling the newly created helpers,
also switch to use fwnode APIs to acquire additional device properties.
A side benifit is that boilerplates get reduced, no functional changes
for DT-based systems.
Signed-off-by: Sui Jingfeng
---
Before applying this patch, people may worry about the OF and non-OF API
will have a risk to diverge. Eliminate the risk by reimplement the
of_drm_find_bridge() on the top of drm_bridge_find_by_fwnode(). As for now
the fundamental searching method is unique.
Signed-off-by: Sui Jingfeng
---
The various display bridge drivers rely on 'OF' infrastructures to
works very well, yet there are some platforms and/or devices lack of
'OF' support. Such as virtual display drivers, USB display apapters
and ACPI based systems etc.
Add fwnode based helpers to fill the niche, this allows part of
Currently, the various display bridge drivers rely on OF infrastructures
to works very well, yet there are platforms and/or devices absence of 'OF'
support. Such as virtual display drivers, USB display apapters and ACPI
based systems etc.
Add fwnode based helpers to fill the niche, this allows
Loongson Graphics are PCIe multi-functional devices, the GPU device and
the display controller are two distinct devices. Drivers of them should
loose coupling, but still be able to works togather to provide a unified
service to userspace.
Add a dummy driver for the GPU, it functional as a
Hardware units come with PCIe are actually all ready to be driven, but
there has some board specific modules could return '-EPROBE_DEFER'.
However, the driver needs all of the subcompoments ready to use before
it can register the drm service to userspace.
Introduce the component framework to
In some display subsystems, the functionality of a PCIe device may too
complex to be managed by a single driver. A split of the functionality
into child devices can helpful to achieve better modularity.
Another benefit is that we could migrate the dependency on exterinal
modules to a submodule
Introduce component framework to bind child and sibling devices, for better
modularity and offload the deferral probe issue to submodule if it need to
attach exterinal module someday. Also for better reflect the hardware
layout.
Hardware units that come with PCIe are all ready to drive, but there
Use generic macro round_closest_up() for rounding closest to specified
value instead of using local macro round_closest().
There is no change from functionality point of view as round_closest_up()
is functionally same as the previously used local macro round_closest().
Signed-off-by: Devarsh
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest
Add tests for round_closest_up/down and roundclosest macros which round
to nearest multiple of specified argument. These are tested with kunit
tool as shared here [1].
[1]: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876
Signed-off-by: Devarsh Thakkar
---
V1->V9 (No change,
From: Daniel Latypov
Add basic test coverage for files that don't require any config options:
* part of math.h (what seem to be the most commonly used macros)
* gcd.c
* lcm.c
* int_sqrt.c
* reciprocal_div.c
(Ignored int_pow.c since it's a simple textbook algorithm.)
These tests aren't
Add below rounding related macros:
round_closest_up(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to round up in case two nearest values are
possible.
round_closest_down(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to
This adds support for V4L2 M2M based driver for E5010 JPEG Encoder
which is a stateful JPEG encoder from Imagination technologies
and is present in TI AM62A SoC.
While adding support for it, following additional framework changes were
made:
- Moved reference quantization and huffman tables
On Sun, 26 May 2024 22:44:37 +0800, Jason-JH.Lin wrote:
> 1. Add mboxes property to define a GCE loopping thread as a secure IRQ
> handler.
> The CMDQ secure driver requests a mbox channel and sends a looping
> command to the GCE thread. The looping command will wait for a secure
> packet done
1. Add a loop flag for CMDQ packet struct.
CMDQ helper will use a loop flag to mark CMDQ packet as lopping command
and make current command buffer jumps to the beginning when GCE executes
to the end of command buffer.
2. Add a looping task handle flow in irq handler.
GCE irq occurs when GCE
Open secure cmdq_pkt APIs to support executing commands in secure world.
1. Add cmdq_sec_pkt_alloc_sec_data(), cmdq_sec_pkt_free_sec_data() and
cmdq_sec_pkt_set_data() to prepare the sec_data in cmdq_pkt that will
be referenced in the secure world.
2. Add cmdq_sec_insert_backup_cookie()
CMDQ driver will probe a secure CMDQ driver when has_sec flag
in platform data is true and its device node in dts has defined a
event id of CMDQ_SYNC_TOKEN_SEC_EOF.
Secure CMDQ driver support on mt8188 and mt8195 currently.
So add a has_secure flag to their driver data to probe it.
1. Add mboxes property to define a GCE loopping thread as a secure IRQ
handler.
The CMDQ secure driver requests a mbox channel and sends a looping
command to the GCE thread. The looping command will wait for a secure
packet done event signal from secure world and then jump back to the
first
To support secure video path feature, GCE have to read/write registgers
in the secure world. GCE will enable the secure access permission to the
HW who wants to access the secure content buffer.
Add CMDQ secure mailbox driver to make CMDQ client user is able to
sending their HW settings to the
To support CMDQ secure driver, move some reuseable definition to header.
- define: e.g. CMDQ_GCE_NUM_MAX, CMDQ_THR_BASE, CMDQ_THR_SIZE.
- struct: e.g. cmdq_thread, cmdq, cmdq_task.
- include: e.g. .
Add "#include " for the function that takes
"struct mbox_chan * chan" as a parameter. That may
There are 2 kind of GCE event signal:
- The SW token means: a GCE event signal triggered by SW drivers.
e.g. SW driver append a GCE command to set a GCE event after a specific
GCE command. Or SW driver use CPU to write a event id to GCE register to
trigger the GCE event corresponding to that event
Add cmdq_pkt_logic_command to support math operation.
cmdq_pkt_logic_command can append logic command to the CMDQ packet,
ask GCE to execute a arithmetic calculate instruction,
such as add, subtract, multiply, AND, OR and NOT, etc.
Note that all arithmetic instructions are unsigned calculations.
From: Jason-jh Lin
For the Secure Video Path (SVP) feature, inculding the memory stored
secure video content, the registers of display HW pipeline and the
HW configure operations are required to execute in the secure world.
So using a CMDQ secure driver to make all display HW registers
Hi,
Day before yesterday I replaced 7900XTX to 6900XT for got clear in
which kernel first time appeared warning message "DMA-API: amdgpu
:0f:00.0: cacheline tracking EEXIST, overlapping mappings aren't
supported".
The kernel 6.3 and older won't boot on a computer with Radeon 7900XTX.
When I
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at
Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays
Signed-off-by: Patrick Gansterer
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Daniel Thompson
---
.../bindings/leds/backlight/ti,lm3509.yaml| 136 ++
1
On Thu, May 23 2024 at 12:32:18 +01:00:00, Adrián Larumbe
wrote:
Commit a78027847226 ("drm/gem: Acquire reservation lock in
drm_gem_{pin/unpin}()") moved locking the DRM object's dma
reservation to
drm_gem_pin(), but Lima's pin callback kept calling drm_gem_shmem_pin,
which also tries to
54 matches
Mail list logo
