This patch add regulator_set_load() before enable regulator at
DP phy driver.
Changes in v2:
-- no regulator_set_load() before disable regulator
Changes in v3:
-- split into two patches
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 12
1 file changed, 12 i
Should subject be "phy: qcom:" prefix?
Quoting Kuogee Hsieh (2022-05-18 13:24:02)
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Changes in v3:
> -- no regulator_set_load before disable regulator
> -- no supply name string change at probe
> -- split into two
Quoting Kuogee Hsieh (2022-05-18 13:24:03)
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Changes in v2:
> -- no regulator_set_load() before disable regulator
>
> Changes in v3:
> -- split into two patches
Same changelog comment
>
> Signed-off-by: Kuogee Hs
On Tue, May 17, 2022 at 10:42 AM Adrián Larumbe
wrote:
>
> In the event of a job timeout, debug dump information will be written into
> /sys/class/devcoredump.
>
> Inspired by etnaviv's similar feature.
>
> Signed-off-by: Adrián Larumbe
> ---
> drivers/gpu/drm/panfrost/Kconfig | 1 +
>
Hi Dave, Daniel,
Stuff for 5.19. A bit late for new stuff, but it's just additional enablement
for new IPs so they shouldn't affect existing parts. The rest is just the usual
fixes.
The following changes since commit 81c5495910e81c2cadcb9118ca0c8803ab3bde61:
drm/amdgpu: Remove duplicated arg
Quoting Kuogee Hsieh (2022-05-18 13:24:04)
> Vdda regulators are related to both eDP and DP phy so that it should be
> managed at eDP and DP phy driver instead of controller. This patch removes
> vdda regulators related functions out of eDP/DP controller.
>
> Signed-off-by: Kuogee Hsieh
> ---
Rev
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy/qualcomm: add regulator_set_load to edp phy
phy/qualcomm: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related fun
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-ed
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualco
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_pars
On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 12
> 1 file changed, 12 insertions(+)
>
>
On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote:
>
> Vdda regulators are related to both eDP and DP phy so that it should be
> managed at eDP and DP phy driver instead of controller. This patch removes
> vdda regulators related functions out of eDP/DP controller.
>
> Signed-off-by: Kuogee Hsieh
On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dr
If there are errors while trying to enable the pm in the
bind path, it will lead to unclocked access of hw revision
register thereby crashing the device.
This will not address why the pm_runtime_get_sync() fails
but at the very least we should be able to prevent the
crash by handling the error and
On 18.05.2022 16:05, Marek Szyprowski wrote:
Hi Dave,
On 11.05.2022 17:47, Dave Stevenson wrote:
On Wed, 11 May 2022 at 15:58, Marek Szyprowski wrote:
On 05.04.2022 13:43, Dave Stevenson wrote:
On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
wrote:
On Fri, 4 Mar 2022 at 15:18, Dave Steven
Handle empty data-lanes = < >; property, which translates to
dsi_lanes = 0 as invalid.
Fixes: bbfd3190b6562 ("drm/bridge: tc358767: Add DSI-to-DPI mode support")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ripard
Cc: Neil Armst
The Refclk may be supplied by SoC clock output instead of crystal
oscillator, make sure the clock are enabled before any other action
is performed with the bridge chip, otherwise it may either fail to
operate at all, or miss reset GPIO toggle.
Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI t
The DSI-to-e(DP) mode is now supported, update the driver comment
to reflect this. No functional change.
Fixes: 3080c21a043ab ("drm/bridge: tc358767: Add DSI-to-(e)DP mode support")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ri
Handle empty data-lanes = < >; property, which translates to
dsi_lanes = 0 as invalid.
Fixes: ceb515ba29ba6 ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84
driver")
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Marek Vasut
Cc: Maxime Ripard
On Wed, May 18, 2022 at 3:34 PM Abhinav Kumar wrote:
>
> If there are errors while trying to enable the pm in the
> bind path, it will lead to unclocked access of hw revision
> register thereby crashing the device.
>
> This will not address why the pm_runtime_get_sync() fails
> but at the very lea
https://bugzilla.kernel.org/show_bug.cgi?id=201497
Rev (r...@pop.ms) changed:
What|Removed |Added
CC||r...@pop.ms
--- Comment #24 from Rev
Quoting Abhinav Kumar (2022-05-18 15:34:07)
> If there are errors while trying to enable the pm in the
> bind path, it will lead to unclocked access of hw revision
> register thereby crashing the device.
>
> This will not address why the pm_runtime_get_sync() fails
> but at the very least we should
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3
and is completely different from the LCDIFv3 found in i.MX23 in that it
has a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space. However,
except for
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which i
On 5/9/22 11:44, Alexander Stein wrote:
Hi Lucas,
Am Freitag, 6. Mai 2022, 20:10:25 CEST schrieb Lucas Stach:
second round of the i.MX8MP HDMI work. Still not split up into proper
parts for merging through the various trees this needs to go into, but
should make it easy for people to test.
I'v
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific
files for 20220518
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com
https
On 5/18/2022 5:40 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2022-05-18 15:34:07)
If there are errors while trying to enable the pm in the
bind path, it will lead to unclocked access of hw revision
register thereby crashing the device.
This will not address why the pm_runtime_get_sync()
On 5/18/22 17:55, kernel test robot wrote:
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific
files for 20220518
Error/Warning reports:
https://lore.kernel.org/linux-mm
On 18-05-22, 14:36, Kuogee Hsieh wrote:
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
sigh! still wrong tags!
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 12
> 1 file changed, 12 ins
Hi Dave & Daniel,
Two final -fixes for v5.18.
One is to reject DMC with out-of-spec MMIO (Cc: stable) and another
to correctly mark guilty contexts on GuC reset.
Regards, Joonas
***
drm-intel-fixes-2022-05-19:
- Reject DMC firmware with out-of-spec MMIO addresses.
- Correctly mark guilty cont
On Wed, May 18, 2022 at 10:11:03PM +0100, Mark Cave-Ayland wrote:
> On 18/05/2022 19:30, Thomas Zimmermann wrote:
>
> > 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 fo
101 - 131 of 131 matches
Mail list logo
