Entering suspend while the display attached to this bridge is still on
makes the resume sequence to resume the bridge first, display last:
when this happens, we get a timeout while resuming the bridge, as its
MCU will get stuck due to the display being unpowered.
On the other hand, on mt8173-elm,
On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. not pin the pages during resource_create ioctl
> 2. pin the pages on the first use during:
> - transfer_*_host ioctl
> - map ioctl
i.e. basically lazy pinning.
Commit a92d083d08b0 created the new flag is_hdmi in drm_display_info
which is set when sink compliant with CEA-861 (EDID) will be treated
as an HDMI sink.
>From that day, this value can be used in some cases instead of
calling drm_detect_hdmi_monitor() and a second parse is avoided
because drm_det
On Mon, Oct 25, 2021 at 12:17:37AM +0200, Claudio Suarez wrote:
[...]
No new comments about this, I suppose everything is fine.
I'm going to send the patch with this changes. Thanks to all and
special thanks to you, Ville. Hope this helps the kernel.
Don't hesitate to ask new changes if necessary
On Mon, Nov 01, 2021 at 07:55:15PM +0100, Hans de Goede wrote:
> Move the setting of the lp->cfg pointer to the chip specific
> lp855x_device_config struct from lp855x_configure() to
> lp855x_probe(), before calling lp855x_parse_dt().
>
> This is a preperation patch for adding ACPI enumeration sup
On Mon, Nov 01, 2021 at 07:55:16PM +0100, Hans de Goede wrote:
> Add a dev local variable to the lp855x_probe(), to replace "&cl->dev"
> and "lp->dev" in various places.
>
> Also switch to dev_err_probe() in one case which takes care of not
> printing -EPROBE_DEFER errors for us.
>
> This is most
On Mon, Nov 01, 2021 at 07:55:17PM +0100, Hans de Goede wrote:
> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 backlight
> controller for its LCD-panel, with a Xiaomi specific ACPI HID of
> "XMCC0001", add support for this.
>
> Note the new "if (id)" check also fixes a NULL pointer der
https://bugzilla.kernel.org/show_bug.cgi?id=214901
--- Comment #6 from t...@siduction.org ---
Looks like the same problem as i stated here:
https://bugzilla.kernel.org/show_bug.cgi?id=214859
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching
From: mwezdeck
The idea behind the commit:
1. not pin the pages during resource_create ioctl
2. pin the pages on the first use during:
- transfer_*_host ioctl
- map ioctl
3. introduce new ioctl for pinning pages on demand
This change has no impact on user space.
Signed-off
Hi Tvrtko,
> > [...]
> >
> > > static int
> > > intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> > > phys_addr)
> >
> > we don't actually need 'id', it's gt->info.id. It's introduced in
> > patch 3 with the value '0' but it's not needed.
>
> I have a suspicion code g
On Tue, Nov 02, 2021 at 11:19:42AM +, Daniel Thompson wrote:
> On Tue, Nov 02, 2021 at 10:04:55AM +, Corentin LABBE wrote:
> > From: Jean-Jacques Hiblot
> >
> > This patch adds support for an "enable GPIO".
>
> Before taking this kind of change is there a good reason why backlight
> shou
On Tue, Nov 02, 2021 at 10:04:55AM +, Corentin LABBE wrote:
> From: Jean-Jacques Hiblot
>
> This patch adds support for an "enable GPIO".
Before taking this kind of change is there a good reason why backlight
should manage the GPIO? I thought that the LED subsystem was a sub
system for LEDs
On Tue, 2 Nov 2021 at 02:56, Xin Ji wrote:
>
> On Mon, Nov 01, 2021 at 11:16:15AM +0800, Jitao Shi wrote:
> > Hi Xin,
> >
> > Please help to review the changes in anx7625.c
> >
> > On Thu, 2021-09-16 at 06:31 +0800, Jitao Shi wrote:
> > > This device requires the packets on lanes aligned at the en
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error capture).
When a vma is
The capture code is typically run entirely in the fence signalling
critical path. Recently added lockdep annotation reveals a lockdep splat
similar to the below one.
Fix the splats and the associated potential deadlocks using
__GFP_KSWAPD_RECLAIM (which is the same as GFP_WAIT, but open-coded for
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
This patch series prepares error capture for asynchronous migration,
where the vma pages may not reflect the pages the GPU is currently
executing from but may be several migrations ahead.
The first patch introduces vma state snapshots that record the vma state
at request submission time.
It also t
https://bugzilla.kernel.org/show_bug.cgi?id=214901
--- Comment #5 from spassw...@web.de ---
This commit leads to a freeze when starting
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/amd/amdgpu?id=714d9e4574d54596973ee3b0624ee4a16264d700
After reverting it
From: Jean-Jacques Hiblot
This patch adds support for an "enable GPIO".
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Corentin LABBE
---
drivers/video/backlight/led_bl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/bac
On 10/30/21 11:24, PGNet Dev wrote:
Is that kernel/modconfig config incorrect?
Not relevant to the problem?
Something else(where) needed?
fwiw,
AMD Global Customer Care's response to question about this 'purple' issue:
"...
Please be informed that Ryzen 5600G APU is supported only on Windows
On 01/11/2021 23:11, Andi Shyti wrote:
Hi Matt and Tvrtko,
[...]
static int
intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
phys_addr)
we don't actually need 'id', it's gt->info.id. It's introduced in
patch 3 with the value '0' but it's not needed.
I have a sus
The eDP sink on sc7280 supports ASSR and dp driver will
enable ASSR in the source hardware. The driver needs to
enable the ASSR field in the DPCD configuration register
to avoid screen corruption. This change will enable ASSR
if supported in the sink device.
Signed-off-by: Sankeerth Billakanti
Re
Add a macro to check for the max_downspread capability in
drm_dp_helper.
Signed-off-by: Sankeerth Billakanti
Reviewed-by: Stephen Boyd
changes in v4:
- Return 1 for DPCD version >= v1.1 (Stephen Boyd)
---
include/drm/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git
The eDP controller on SC7280 is similar to the eDP/DP controllers
supported by the current driver implementation.
SC7280 supports one EDP and one DP controller which can operate
concurrently.
This change adds the support for eDP and DP controller on sc7280.
Signed-off-by: Sankeerth Billakanti
This series will add eDP controller support for Qualcomm SC7280
platform. These patches are baseline changes with which we can enable
eDP display on sc7280. The sc7280 eDP controller driver can also support
additional features such as no_hpd detection, PSR, etc. which will be
enabled in sub
From: Sankeerth Billakanti
The Qualcomm SC7280 platform supports one eDP controller
and a DP controller. This change will add the compatible
string for both eDP and DP to msm dp-controller binding.
Signed-off-by: Sankeerth Billakanti
changes in v3:
- Modify the subject (Doug Anderson)
The sc7280 eDP sink that supports downspread will fail link training
if source does not enable SSC / downspread. This change will set the
downspread bit in the DP sink if supported and indicate SSC support
to the DP PHY driver.
Signed-off-by: Sankeerth Billakanti
Reviewed-by: Stephen Boyd
---
d
In function ps8640_bridge_poweron(), in case of a failure not relative
to the regulators enablement, the code was disabling the regulators but
the gpio changes that happened during the poweron sequence were not
being reverted back to a clean poweroff state.
Since it is expected that, when we enter
In preparation for varying the poweron error handling in function
ps8640_bridge_poweron(), move function ps8640_bridge_poweroff() up
and also move the actual logic to power off the chip to a new
__ps8640_bridge_poweroff() function.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/b
If the bridge cannot get powered on, there's no reason to try to
communicate with it: change the ps8640_bridge_poweron function to
return an error value to the caller, so that we can avoid calling
ps8640_bridge_vdo_control() in ps8640_pre_enable() if the poweron
sequence fails.
Signed-off-by: Ange
Am 25.10.21 um 09:57 schrieb Javier Martinez Canillas:
The logic to remove the conflicting frame buffers for fbdev devices that
use a given memory range is only compiled if CONFIG_FB option is enabled.
But having an ifdefery in drm_aperture_remove_conflicting_framebuffers()
makes the function
Reviewed-by: Simon Ser
On 01/11/2021 18:38, Thomas Hellström wrote:
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move
>From the comments of drm_for_each_connector_iter(), we know
that "connector is only valid within the list body, if you
want to use connector after calling drm_connector_list_iter_end()
then you need to grab your own reference first using
drm_connector_get()". So fix the wrong use of connector
acco
On Tue, 02 Nov 2021, "Yuan, Perry" wrote:
> [AMD Official Use Only]
>
> Hi Jani:
> Thanks for your comments.
>
>> -Original Message-
>> From: Jani Nikula
>> Sent: Monday, November 1, 2021 9:07 PM
>> To: Yuan, Perry ; Maarten Lankhorst
>> ; Maxime Ripard ;
>> Thomas Zimmermann ; David Airl
Hi Maíra,
On Sat, Oct 30, 2021 at 3:35 PM Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
Thanks for your patch!
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/back
On Tue, 02 Nov 2021, He Ying wrote:
> 在 2021/11/1 21:02, Jani Nikula 写道:
>> On Mon, 01 Nov 2021, He Ying wrote:
>>> From the comments of drm_for_each_connector_iter(), we know
>>> that "connector is only valid within the list body, if you
>>> want to use connector after calling drm_connector_lis
From: Ye Guojin
Since the variables named is_end_of_payload and hpd_status are already
bool type, the ?: conditional operator is unnecessary any more.
Clean them up here.
Reported-by: Zeal Robot
Signed-off-by: Ye Guojin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
drivers/g
101 - 138 of 138 matches
Mail list logo
