Hi
On Fri, Oct 15, 2021 at 9:15 PM Sam Ravnborg wrote:
>
> Hi Michael,
>
> > Add this panel's initialzation sequence and timing to ILI9881D driver.
> > Tested on px30-evb v11
> Patch looks good, but we need the vendor and the compatible documented.
>
> >
> > Signed-off-by: Michael Trimarchi
> >
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > > According to the document
On Sat, Oct 16, 2021 at 10:25:03AM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 15, 2021 at 0
Hi Maxime,
> drm/bridge: adv7533: Switch to devm MIPI-DSI helpers
> drm/bridge: adv7511: Register and attach our DSI device at probe
> drm/bridge: anx7625: Switch to devm MIPI-DSI helpers
> drm/bridge: anx7625: Register and attach our DSI device at probe
> drm/bridge: lt8912b: Switch to
On Fri, Oct 15, 2021 at 11:14:54AM -0400, Harry Wentland wrote:
>
>
> On 2021-10-15 07:37, Claudio Suarez wrote:
> > a) Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. The amdgpu driver still calls
> > drm_detect_hdmi_monitor() to retri
This patch series add support for W552946ABA panel. This panel is used
in px30-evb v11. All the patches can be applied on top of drm-fixes
branch. The last patch is suppose to fix a race when the panel is built
in. Tested on px30 evb
Michael Trimarchi (5):
dt-bindings: vendor-prefix: add Wanchan
Wanchanglong Electronics Technology is a company to provide LCD
modules.
Signed-off-by: Michael Trimarchi
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devic
W552946ABA is a panel by Wanchanglong. This panel utilizes the Ilitek ILI9881D
controller.
Add this panel's initialzation sequence and timing to ILI9881D driver.
Tested on px30-evb v11
Signed-off-by: Michael Trimarchi
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 238 +-
1
Depends in how logic is connected to the board the gpio is
not stricly required.
Signed-off-by: Michael Trimarchi
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 -
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 2 +-
2 files changed, 1 insertion(+), 2
It utilizes an Ilitek ILI9881D controller chip, but its
compatible with ili9881c so should be added to ilitek,ili9881c file.
Add the compatible string for it.
Signed-off-by: Michael Trimarchi
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 +
1 file changed, 1 insertion
The dsi registration is implemented in rockchip platform driver.
The attach can be called before the probe is terminated and therefore
we need to be sure that corresponding entry during attach is valid
Signed-off-by: Michael Trimarchi
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8
Hi Daniel and Jani,
On Wed, Oct 13, 2021 at 01:51:30PM +0200, Daniel Vetter wrote:
> On Wed, Oct 13, 2021 at 02:24:05PM +0300, Jani Nikula wrote:
> > On Mon, 11 Oct 2021, Len Baker wrote:
> > > Hi,
> > >
> > > On Sun, Oct 03, 2021 at 12:42:58PM +0200, Len Baker wrote:
> > >> As noted in the "Depr
Hi Michael,
I fail to follow the logic in this patch.
On Sat, Oct 16, 2021 at 10:22:32AM +, Michael Trimarchi wrote:
> The dsi registration is implemented in rockchip platform driver.
> The attach can be called before the probe is terminated and therefore
> we need to be sure that correspond
Hi Michael,
On Sat, Oct 16, 2021 at 10:22:27AM +, Michael Trimarchi wrote:
> This patch series add support for W552946ABA panel. This panel is used
> in px30-evb v11. All the patches can be applied on top of drm-fixes
> branch. The last patch is suppose to fix a race when the panel is built
>
Hi Sam
On Sat, Oct 16, 2021 at 2:25 PM Sam Ravnborg wrote:
>
> Hi Michael,
>
> I fail to follow the logic in this patch.
>
>
> On Sat, Oct 16, 2021 at 10:22:32AM +, Michael Trimarchi wrote:
> > The dsi registration is implemented in rockchip platform driver.
> > The attach can be called befor
Hi Simon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on f6632721cd6231e1bf28b5317dcc7543e43359f7]
url:
https://github.com/0day-ci/linux/commits/Simon-Ser/drm-add-per-connector-hotplug-events/20211016-003611
base: f6632721cd6231e1bf28b5317dcc7543e43359f7
On Sat, 16 Oct 2021 at 01:25, wrote:
>
> Hi Dmitry
>
> On 2021-10-14 17:11, Dmitry Baryshkov wrote:
> > Merge old hdmi_bridge and hdmi_connector implementations. Use
> > drm_bridge_connector instead.
> >
> Can you please comment on the validation done on this change?
> Has basic bootup been verifi
Hi
Forget this one I can not replicate. We have another problem
9862.010474] Hardware name: Rockchip PX30 EVB (DT)
[ 9862.015738] Call trace:
[ 9862.018471] dump_backtrace+0x0/0x19c
[ 9862.022586] show_stack+0x1c/0x70
[ 9862.026305] dump_stack_lvl+0x68/0x84
[ 9862.030408] dump_stack+0x1c/0x3
All the panel driver check the fact that their prepare/unprepare
call was already called. It's not an ideal solution but fix
for now the problem on ili9881c
[ 9862.283296] [ cut here ]
[ 9862.288490] unbalanced disables for vcc3v3_lcd
[ 9862.293555] WARNING: CPU: 0 PID: 1 a
01.10.2021 16:27, Ulf Hansson пишет:
> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>>
>> Add OPP and SoC core voltage scaling support to the display controller
>> driver. This is required for enabling system-wide DVFS on pre-Tegra186
>> SoCs.
>>
>> Tested-by: Peter Geis # Ouya T30
>> Te
On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote:
> On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote:
> >
> > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > > > > Does anyone know why devmap is pte_special anyhow?
> > >
> > > It does not need to be special as me
On 28/09/2021 00:04, Rob Clark wrote:
From: Rob Clark
Add a short delay before clamping to idle frequency on active->idle
transition. It takes ~0.5ms to increase the freq again on the next
idle->active transition, so this helps avoid extra freq transitions
on workloads that bounce between CP
On Sat, Oct 16, 2021 at 12:44:50PM -0300, Jason Gunthorpe wrote:
> Assuming changing FSDAX is hard.. How would DAX people feel about just
> deleting the PUD/PMD support until it can be done with compound pages?
I think there are customers who would find that an unacceptable answer :-)
Fit ps8640 driver into runtime power management framework:
First, break _poweron() to 3 parts: (1) turn on power and wait for
ps8640's internal MCU to finish init (2) check panel HPD (which is
proxy by GPIO9) (3) the other configs. Runtime _resume() can be called
before panel is powered, so we onl
Conventionally, panel is listed under the root in the device tree.
When userland asks for display mode, ps8640 bridge is responsible
for returning EDID when ps8640_bridge_get_edid() is called.
Now enable a new option of listing the panel under "aux-bus" of ps8640
bridge node in the device tree. In
Hi Maxime,
> drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers
> drm/bridge: sn65dsi83: Register and attach our DSI device at probe
> drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers
> drm/bridge: sn65dsi86: Register and attach our DSI device at probe
> drm/bridge: tc358775: S
According to the documentation, drm_add_edid_modes
"... Also fills out the &drm_display_info structure and ELD in @connector
with any information which can be derived from the edid."
drm_add_edid_modes accepts a struct edid *edid parameter which may have a
value or may be null. When it is not null
Changelog:
v2:
- no helper function
- A separate patch is made for amdgpu
- zte patch is removed because that driver no longer exists
[Why]
Copy&paste from Documentation/gpu/todo.rst
===
Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
--
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Use this value instead of calling
drm_detect_hdmi_monitor() to avoid a second parse.
This is a TODO task in Documentation/gpu/todo.rst
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/vc4/v
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information is less
efficient. Change to drm_display_info.is_hdmi
This is a TODO task in Documentation/gpu/todo.rst
Also, correct an inacurracy or bug in
radeon_connector_ge
Hi Yassine,
Sorry for the late response - have been away from kernel stuff for some
months.
A few comments in the following - mostly backlight related.
Please fix and resend.
Note: bindings comes before the panel driver - as we cannot apply a
panel driver for an unknown binding.
Sam
On
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/tegra/hdmi.c | 6 +-
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/bridge/adv
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/rockchip/inno_hdmi.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/msm/hdmi/hdmi_connector.c
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi where possible.
This is a TODO task in Documentation/gpu/todo.rst
Signed-off
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/nouveau/dispnv50/disp.c |
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |
On Fri, Oct 15, 2021 at 12:34:20PM -0700, Jessica Zhang wrote:
> Hey Dmitry,
>
> On 10/15/2021 11:24 AM, Dmitry Baryshkov wrote:
> > On Fri, 15 Oct 2021 at 04:43, Jessica Zhang wrote:
> > > Hey Dan,
> > >
> > > On 10/1/2021 5:31 AM, Dan Carpenter wrote:
> > > > Hello Sean Paul,
> > > >
> > > >
Current code always sets reset line low in .pre_enable callback and
holds it low for 10ms. This is sub-optimal and increases the time
between enablement of the DSI83 and valid LVDS clock.
Rework the reset handling such that the reset line is held low for 10ms
both in probe() of the driver and .dis
The mxsfb->crtc.funcs may already be NULL when unloading the driver,
in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
mxsfb_unload() leads to NULL pointer dereference.
Since all we care about is masking the IRQ and mxsfb->base is still
valid, just use that to clear and mask t
On Sat, Oct 16, 2021 at 11:04 PM Marek Vasut wrote:
> Current code always sets reset line low in .pre_enable callback and
> holds it low for 10ms. This is sub-optimal and increases the time
> between enablement of the DSI83 and valid LVDS clock.
>
> Rework the reset handling such that the reset l
The current implementation supports a single DP instance and the DPU code will
only match it against INTF_DP instance 0. These patches extends this to allow
multiple DP instances and support for matching against DP instances beyond 0.
With that in place add SC8180x DP and eDP controllers.
Bjorn A
As the Qualcomm DisplayPort driver only supports a single instance of
the driver the commonly used struct dp_display is kept in a global
variable. As we introduce additional instances this obviously doesn't
work.
Replace this with a combination of existing references to adjacent
objects and drvdat
Functions in the DisplayPort code that relates to individual instances
(encoders) are passed both the struct msm_dp and the struct drm_encoder.
But in a situation where multiple DP instances would exist this means
that the caller need to resolve which struct msm_dp relates to the
struct drm_encoder
As the following patches introduced support for multiple DP blocks in a
platform and some of those block might be eDP it becomes useful to be
able to specify the connector type per block.
Although there's only a single block at this point, the array of descs
and the search in dp_display_get_desc()
The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
DP driver.
Link:
https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- Use the MSM_DP_CONTROLLER_n enums
- const the msm_dp_desc a
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM driver, introduce a
per-compatible list of base addresses which is used to resolve the
"instance id" for
eDP panels might need some power sequencing and backlight management,
so make it possible to associate a drm_panel with an eDP instance and
prepare and enable the panel accordingly.
Now that we know which hardware instance is DP and which is eDP,
parser->parse() is passed the connector_type and th
The Qualcomm SC8180x has 2 DP controllers and 1 eDP controller, add
compatibles for these to the msm/dp binding.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- None
.../devicetree/bindings/display/msm/dp-controller.yaml |
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pclk-sample", not
the same as the one used by display timings but rather the same as used by
media, to define the pixel data sampling edge.
Signed-off-by: Marek Vasut
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pclk-sample", not
the same as the one used by display timings but rather the same as used by
media, and configure bus flags based on this DT property.
Signed-off-by: Ma
Quoting Bjorn Andersson (2021-10-16 15:18:39)
> As the following patches introduced support for multiple DP blocks in a
> platform and some of those block might be eDP it becomes useful to be
> able to specify the connector type per block.
>
> Although there's only a single block at this point, the
Quoting Bjorn Andersson (2021-10-16 15:18:40)
> eDP panels might need some power sequencing and backlight management,
> so make it possible to associate a drm_panel with an eDP instance and
> prepare and enable the panel accordingly.
>
> Now that we know which hardware instance is DP and which is e
Quoting Bjorn Andersson (2021-10-16 15:18:41)
> Based on the removal of the g_dp_display and the movement of the
> priv->dp lookup into the DP code it's now possible to have multiple
> DP instances.
>
> In line with the other controllers in the MSM driver, introduce a
> per-compatible list of base
Quoting Bjorn Andersson (2021-10-16 15:18:43)
> The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
> DP driver.
>
> Link:
> https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/
> Signed-off-by: Bjorn Andersson
> ---
Reviewed-by: Stephen
Quoting Bjorn Andersson (2021-10-16 15:18:43)
> The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
> DP driver.
>
> Link:
> https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/
BTW, was the link intentional?
60 matches
Mail list logo
