For the Smart PC Solution to fully work, it has to enact to the actions
coming from TA. Add the initial code path for set interface to AMDGPU.
Change amd_pmf_apply_policies() return type, so that it can return
errors when the call to retrieve information from amdgpu fails.
Co-developed-by: Mario
In order to provide GPU inputs to TA for the Smart PC solution to work, we
need to have interface between the PMF driver and the AMDGPU driver.
Add the initial code path for get interface from AMDGPU.
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Signed-off-by: Shyam
Sometimes policy binary retrieved from the BIOS maybe incorrect that can
end up in failing to enable the Smart PC solution feature.
Use print_hex_dump_debug() to dump the policy binary in hex, so that we
debug the issues related to the binary even before sending that to TA.
Signed-off-by: Shyam
A policy binary is OS agnostic, and the same policies are expected to work
across the OSes. At times it becomes difficult to debug when the policies
inside the policy binaries starts to misbehave. Add a way to sideload such
policies independently to debug them via a debugfs entry.
Reviewed-by:
PMF driver sends constant inputs to TA which its gets via the other
subsystems in the kernel. To debug certain TA issues knowing what inputs
being sent to TA becomes critical. Add debug facility to the driver which
can isolate Smart PC and TA related issues.
Also, make source_as_str() as
PMF driver based on the output actions from the TA can request to update
the system states like entering s0i3, lock screen etc. by generating
an uevent. Based on the udev rules set in the userspace the event id
matching the uevent shall get updated accordingly using the systemctl.
Sample udev
P3T (Peak Package Power Limit) is a metric within the SMU controller
that can influence the power limits. Add support from the driver
to update P3T limits accordingly.
Reviewed-by: Mario Limonciello
Signed-off-by: Shyam Sundar S K
---
drivers/platform/x86/amd/pmf/pmf.h| 3 +++
PMF driver sends changing inputs from each subystem to TA for evaluating
the conditions in the policy binary.
Add initial support of plumbing in the PMF driver for Smart PC to get
information from other subsystems in the kernel.
Signed-off-by: Shyam Sundar S K
---
To sideload pmf policy binaries, the Smart PC Solution Builder provides a
debugfs file called "update_policy"; that gets created under a new debugfs
directory called "pb" and this new directory has to be associated with
existing parent directory for PMF driver called "amd_pmf".
In the current
PMF Policy binary is a encrypted and signed binary that will be part
of the BIOS. PMF driver via the ACPI interface checks the existence
of Smart PC bit. If the advertised bit is found, PMF driver walks
the acpi namespace to find out the policy binary size and the address
which has to be passed to
In the current code, the metrics table information was required only
for auto-mode or CnQF at a given time. Hence keeping the return type
of amd_pmf_set_dram_addr() as static made sense.
But with the addition of Smart PC builder feature, the metrics table
information has to be shared by the Smart
PMF TA (Trusted Application) loads via the TEE environment into the
AMD ASP.
PMF-TA supports two commands:
1) Init: Initialize the TA with the PMF Smart PC policy binary and
start the policy engine. A policy is a combination of inputs and
outputs, where;
- the inputs are the changing dynamics of
AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
PMF Trusted Application is a secured firmware placed under
/lib/firmware/amdtee gets loaded only when the TEE environment is
initialized. Add the initial code
Thank you both for the reviews! Some wlroots users have confirmed it
fixes their issues. I've pushed the patch.
Smart PC Solutions Builder allows for OEM to define a large number of
custom system states to dynamically switch to. The system states are
referred to as policies, and multiple policies can be loaded onto the
system at any given time, however only one policy can be active at a
given time.
Policy
On Tue, Oct 10, 2023 at 02:15:47PM +0200, Maxime Ripard wrote:
> On Tue, Oct 10, 2023 at 01:29:52PM +0200, Noralf Trønnes wrote:
> >
> >
> > On 10/10/23 11:25, Maxime Ripard wrote:
> > >
> > >
> > > On Tue, Oct 10, 2023 at 10:55:09AM +0200, Thomas Zimmermann wrote:
> > So if I understand
On Tue, Oct 10, 2023 at 01:48:07PM +0200, Daniel Vetter wrote:
> On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > v3 changelog
> >
> > No real changes, just rebased for context changes, and picked up the Acks.
> >
> > This now conflicts with the
From: Nirmoy Das
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Signed-off-by: Nirmoy Das
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Reviewed-by:
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For DT
From: Nirmoy Das
Add a function for ratelimitted debug print.
Signed-off-by: Nirmoy Das
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Matthew Auld
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Sam
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For device
Hi,
I might have picked up the wrong series and missed some reviews
and the extra patch from Nirmoy with a real use of the
drm_dbg_ratelimited() that John was looking for.
Thanks,
Andi
v2:
pick the right patch with the following changes:
- add more r-b's
- add a patch 2 where the
On Tue, Oct 10, 2023 at 01:29:52PM +0200, Noralf Trønnes wrote:
>
>
> On 10/10/23 11:25, Maxime Ripard wrote:
> >
> >
> > On Tue, Oct 10, 2023 at 10:55:09AM +0200, Thomas Zimmermann wrote:
> So if I understand correctly, drm_panic would pre-allocate a
> plane/commit,
> and use
Enable ILITEK_ILI9882T panel.
Signed-off-by: Cong Yang
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0777bcae9104..c3453dcbad3e 100644
--- a/arch/arm64/configs/defconfig
+++
At present, we have found that there may be a problem of blurred
screen during fast sleep/resume. The direct cause of the blurred
screen is that the IC does not receive 0x28/0x10. Because of the
particularity of the IC, before the panel enters sleep hid must
stop scanning, i2c_hid_core_suspend
The Starry ILI9882t-based panel should never have been part of the boe
tv101wum driver, it is clearly based on the Ilitek ILI9882t display
controller and if you look at the custom command sequences for the
panel these clearly contain the signature Ilitek page switch (0xff)
commands. The hardware
Linus series proposed to break out ili9882t as separate driver,
but he didn't have time for that extensive rework of the driver.
As discussed by Linus and Doug [1], keep macro using the "struct panel_init_cmd"
until we get some resolution about the binary size issue.
[1]:
On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> v3 changelog
>
> No real changes, just rebased for context changes, and picked up the Acks.
>
> This now conflicts with the ia64 removal and introduces one new dependency
> on IA64, but that is harmless
On Fri, Oct 06, 2023 at 04:34:01PM +0200, Ondrej Zary wrote:
> On Friday 06 October 2023, Helge Deller wrote:
> > On 10/5/23 09:01, Zhang Shurong wrote:
> > > Add missing pci_disable_device() in error path in ark_pci_probe().
> >
> > Do you have this hardware and tested your patch?
> > I'm sure
On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:
> Am 09.10.23 um 14:19 schrieb Ville Syrjälä:
> > On Mon, Oct 09, 2023 at 08:42:24AM +0200, Christian König wrote:
> > > Am 06.10.23 um 20:48 schrieb Ray Strode:
> > > > Hi,
> > > >
> > > > On Fri, Oct 6, 2023 at 3:12 AM Christian
On Thu, Oct 05, 2023 at 01:16:27PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 05, 2023 at 11:57:41AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 26, 2023 at 01:05:49PM -0400, Ray Strode wrote:
> > > From: Ray Strode
> > >
> > > A drm atomic commit can be quite slow on some hardware. It can lead
>
Hi,
On Tue, Oct 10, 2023 at 4:44 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Oct 6, 2023 at 11:07 PM Cong Yang
> wrote:
> >
> > At present, we have found that there may be a problem of blurred
> > screen during fast sleep/resume. The direct cause of the blurred
> > screen is that the IC does
On 10/10/23 11:25, Maxime Ripard wrote:
>
>
> On Tue, Oct 10, 2023 at 10:55:09AM +0200, Thomas Zimmermann wrote:
So if I understand correctly, drm_panic would pre-allocate a plane/commit,
and use that when a panic occurs ?
>>>
>>> And have it checked already, yes. We would only wait
Thanks for the review,I will modify these in V2.
On Tue, Oct 10, 2023 at 4:44 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Oct 6, 2023 at 11:07 PM Cong Yang
> wrote:
> >
> > From: Linus Walleij
> >
> > The Starry ILI9882t-based panel should never have been part of the boe
> > tv101wum driver,
Hi Tvrtko,
> > Meteor Lake has demonstrated consistent stability for some time.
> > All user-space API modifications tide to its core platform
> > functions are operational.
> >
> > The necessary firmware components are set up and comprehensive
> > testing has been condused over a period.
> >
>
On Tue, Oct 10, 2023 at 06:20:03PM +0800, Dmitry Osipenko wrote:
> Hi,
>
> On 10/10/23 06:25, Huang Rui wrote:
> > These definitions are used fro qemu, and qemu imports this marco in the
> > headers to enable gfxstream or venus for virtio gpu. So it should add it
> > even kernel doesn't use this.
Maxime Ripard writes:
> On Mon, Oct 09, 2023 at 04:22:29PM +0200, Javier Martinez Canillas wrote:
>> Thomas Zimmermann writes:
>> > Store an instance of struct drm_format_conv_state in the shadow-plane
>> > state struct drm_shadow_plane_state. Many drivers with shadow planes
>> > use DRM's
Hi Arnd,
On Mon, Oct 9, 2023 at 11:19 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The list of dependencies here is phrased as an opt-out, but this is missing
> a lot of architectures that don't actually support VGA consoles, and some
> of the entries are stale:
>
> - powerpc used to
Hi,
On 10/10/23 06:25, Huang Rui wrote:
> These definitions are used fro qemu, and qemu imports this marco in the
> headers to enable gfxstream or venus for virtio gpu. So it should add it
> even kernel doesn't use this.
>
> Signed-off-by: Huang Rui
> ---
>
> Changes V1 -> V2:
> - Add all
Hi Dave, Daniel.
Habanalabs pull request for 6.7.
It's a bit all over the place, a few uapi changes, mostly improvements and
bug fixes.
Notable things are the move to the accel subsystem in the code itself,
meaning we removed the habanalabs class and the code to created device char
and instead
On Mon, Oct 09, 2023 at 10:23:02AM +0200, Thomas Zimmermann wrote:
> Hi Maxime
>
> Am 06.10.23 um 16:49 schrieb Maxime Ripard:
> > Hi,
> >
> > On Thu, Oct 05, 2023 at 11:04:20AM +0200, Thomas Zimmermann wrote:
> > > DRM's format-conversion helpers require temporary memory. Pass the
> > > buffer
On 08/10/2023 17:48, Andi Shyti wrote:
From: Radhakrishna Sripada
Meteor Lake has demonstrated consistent stability for some time.
All user-space API modifications tide to its core platform
functions are operational.
The necessary firmware components are set up and comprehensive
testing has
On Mon, Oct 09, 2023 at 04:22:29PM +0200, Javier Martinez Canillas wrote:
> Thomas Zimmermann writes:
> > Store an instance of struct drm_format_conv_state in the shadow-plane
> > state struct drm_shadow_plane_state. Many drivers with shadow planes
> > use DRM's format helpers to copy or convert
On Mon, Oct 09, 2023 at 11:18:45PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> After the vga console no longer relies on global screen_info, there are
> only two remaining use cases:
>
> - on the x86 architecture, it is used for multiple boot methods
>(bzImage, EFI, Xen, kexec)
On Tue, Oct 10, 2023 at 11:04:33AM +0200, Thomas Zimmermann wrote:
> Am 09.10.23 um 18:07 schrieb Maxime Ripard:
> > On Mon, Oct 09, 2023 at 04:05:19PM +0200, Jocelyn Falempe wrote:
> > > > > - I find it risky to completely reconfigure the hardware in a panic
> > > > > handler.
> > > >
> > > > I
Hi,
thanks for this series!
> Reference to Andrew's previous proposal:
> https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
I do totally agree with Guenter's comment[1], though. This just affects
a few drivers and this patch is way too intrusive for the I2C core. The
later
On Tue, Oct 10, 2023 at 10:55:09AM +0200, Thomas Zimmermann wrote:
> > > So if I understand correctly, drm_panic would pre-allocate a plane/commit,
> > > and use that when a panic occurs ?
> >
> > And have it checked already, yes. We would only wait for a panic to
> > happen to pull the trigger
Hi
Am 03.10.23 um 16:22 schrieb Jocelyn Falempe:
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 24
1 file changed, 24 insertions(+)
Hi
Am 09.10.23 um 18:07 schrieb Maxime Ripard:
On Mon, Oct 09, 2023 at 04:05:19PM +0200, Jocelyn Falempe wrote:
- I find it risky to completely reconfigure the hardware in a panic handler.
I would expect to only change the format and base address of the
framebuffer. I guess it can fail, but
Hi
Am 09.10.23 um 13:33 schrieb Maxime Ripard:
[...]
And you don't need to support all kinds of tiling, YUV or RGB variants.
We should indeed not use YUV at all. For RGB, we already have plenty of
conversion code from XRGB-to-, so we are more flexible there.
So if I understand
Hi,
On Sat, 07 Oct 2023 14:49:49 +0800, Ruihai Zhou wrote:
> The sta_himax83102 panel sometimes shows abnormally flickering
> horizontal lines. The front gate output will precharge the X point of
> the next pole circuit before TP(TouchPanel Enable) term starts, and wait
> until the end of the TP
Maxime Ripard writes:
Hello Maxime,
Thanks for the feedback.
> Hi,
>
> On Mon, Oct 09, 2023 at 08:34:15PM +0200, Javier Martinez Canillas wrote:
>> The driver only supports the SSD130x family of Solomon OLED controllers
>> now, but will be extended to also support the SSD132x (4-bit grayscale)
Hi,
On Mon, 09 Oct 2023 17:04:46 +0800, Ma Ke wrote:
> In tpg110_get_modes(), the return value of drm_mode_duplicate() is
> assigned to mode, which will lead to a NULL pointer dereference on
> failure of drm_mode_duplicate(). Add a check to avoid npd.
>
>
Thanks, Applied to
Hi,
On Sat, 07 Oct 2023 11:31:05 +0800, Ma Ke wrote:
> In versatile_panel_get_modes(), the return value of drm_mode_duplicate()
> is assigned to mode, which will lead to a NULL pointer dereference
> on failure of drm_mode_duplicate(). Add a check to avoid npd.
>
>
Thanks, Applied to
On Tue, Oct 10, 2023 at 09:55:46AM +0200, Jocelyn Falempe wrote:
> On 09/10/2023 18:07, Maxime Ripard wrote:
> > On Mon, Oct 09, 2023 at 04:05:19PM +0200, Jocelyn Falempe wrote:
> > > > > - I find it risky to completely reconfigure the hardware in a panic
> > > > > handler.
> > > >
> > > > I
On 10/10/2023 10:10, Marijn Suijten wrote:
On 2023-10-09 18:36:11, Neil Armstrong wrote:
Starting with the SM8550 platform, the SSPP & WB Clock Controls are
no more in the MDP TOP registers, but in the SSPP & WB register space.
Add the corresponding SSPP & WB ops and use them from the vbif QoS
On 2023-10-09 18:36:11, Neil Armstrong wrote:
> Starting with the SM8550 platform, the SSPP & WB Clock Controls are
> no more in the MDP TOP registers, but in the SSPP & WB register space.
>
> Add the corresponding SSPP & WB ops and use them from the vbif QoS
> and OT limit setup functions.
>
>
Hi,
On Mon, Oct 09, 2023 at 08:34:15PM +0200, Javier Martinez Canillas wrote:
> The driver only supports the SSD130x family of Solomon OLED controllers
> now, but will be extended to also support the SSD132x (4-bit grayscale)
> and SSD133x (16-bit RGB) controller families. Rename driver to
On 09/10/2023 19:10, Dmitry Baryshkov wrote:
On 09/10/2023 19:36, Neil Armstrong wrote:
The SM8550 has the SSPP clk_ctrl in the SSPP registers, move them
out of the MDP top.
Signed-off-by: Neil Armstrong
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 35 ++
1
On 09/10/2023 19:10, Dmitry Baryshkov wrote:
On 09/10/2023 19:36, Neil Armstrong wrote:
The SM8550 has the SSPP clk_ctrl in the SSPP registers, move them
out of the MDP top.
Signed-off-by: Neil Armstrong
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 35 ++
1
On 09/10/2023 19:07, Dmitry Baryshkov wrote:
On 09/10/2023 19:36, Neil Armstrong wrote:
Now clk_ctrl IDs can be optional and the clk_ctrl_reg can be specified
on the SSPP & WB caps directly, pass the SSPP & WB hw struct to the
qos & limit params then call the clk_force_ctrl() op accordingly.
On 09/10/2023 18:07, Maxime Ripard wrote:
On Mon, Oct 09, 2023 at 04:05:19PM +0200, Jocelyn Falempe wrote:
- I find it risky to completely reconfigure the hardware in a panic handler.
I would expect to only change the format and base address of the
framebuffer. I guess it can fail, but it
Hi Helen,
On 09/10/23 06:19, Helen Koike wrote:
Add helper script that given a gitlab pipeline url, analyse which are
the failures and flakes and update the xfails folder accordingly.
Example:
Trigger a pipeline in gitlab infrastructure, than re-try a few jobs more
than once (so we can have
On Tue, 10 Oct 2023 00:35:53 +0200
Danilo Krummrich wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a
> submission limit that corresponds to the number of jobs which can be
> sent to the hardware.
>
Add missing free on an error path.
Signed-off-by: Kunwu.Chan
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
Signed-off-by: Lakshmi Yadlapati
---
drivers/i2c/i2c-core-base.c | 8 +-
drivers/i2c/i2c-core-smbus.c | 143 ---
drivers/i2c/i2c-core.h | 23 ++
include/linux/i2c.h | 2 +
4 files changed, 145 insertions(+), 31 deletions(-)
diff --git
Correct Link to Andrew's previous proposal:
https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
On 10/9/23, 4:21 PM, "Lakshmi Yadlapati" mailto:laksh...@us.ibm.com>> wrote:
Reintroduce per-client throttling of transfers for improved compatibility.
Some devices have
Add missing free on an error path.
Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
Signed-off-by: Kunwu.Chan
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Reintroduce per-client throttling of transfers for improved compatibility.
Some devices have experienced issues with small command turn-around times when
using in-kernel device drivers. While a previous proposal was rejected due to
concerns about error-prone open-coding of delays, recent
The MAX31785 has shown erratic behaviour across multiple system
designs, unexpectedly clock stretching and NAKing transactions.
Inserting a small delay (250us) after register writes makes the
issue go away.
Signed-off-by: Lakshmi Yadlapati
---
drivers/hwmon/pmbus/max31785.c | 8
1 file
Hello Stephen,
On Tue, Oct 10, 2023 at 12:33:45PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the drm-msm tree got conflicts in:
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
>
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design
On Tue, Oct 10, 2023 at 09:07:53AM +0300, Oded Gabbay wrote:
> On Fri, Oct 6, 2023 at 4:57 PM Greg Kroah-Hartman
> wrote:
> >
> > Now that the driver core allows for struct class to be in read-only
> > memory, we should make all 'class' structures declared at build time
> > placing them into
On 10/9/23 16:45, Danilo Krummrich wrote:
On 10/9/23 15:36, Thomas Hellström wrote:
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Kunwu.Chan
Sent: Tuesday, October 10, 2023 2:11 PM
To: Wang, Yang(Kevin)
Cc: Deucher, Alexander ; Kamal, Asad
; Koenig, Christian ; Zhang,
Hawking ; Ma, Le ; Lazar, Lijo
; Pan,
On Fri, Oct 6, 2023 at 4:57 PM Greg Kroah-Hartman
wrote:
>
> Now that the driver core allows for struct class to be in read-only
> memory, we should make all 'class' structures declared at build time
> placing them into read-only memory, instead of having to be dynamically
> allocated at runtime.
101 - 176 of 176 matches
Mail list logo
