On Sun, Jun 30, 2019 at 2:58 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> On Sun, Jun 30, 2019 at 02:50:59PM -0700, Rob Clark wrote:
> > On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart wrote:
> > > On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > U
Hi Rob,
On Sun, Jun 30, 2019 at 02:50:59PM -0700, Rob Clark wrote:
> On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart wrote:
> > On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > >
On Sun, Jun 30, 2019 at 2:17 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Use the drm_of_find_panel_id() helper to decide which endpoint to use
> > when looking up panel. This way we
On Sun, Jun 30, 2019 at 2:15 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote:
> > On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote:
> > > On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > N
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 01:36:08PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Use the drm_of_find_panel_id() helper to decide which endpoint to use
> when looking up panel. This way we can support devices that have
> multiple possible panels, such as the aar
Hi Rob,
On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote:
> On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote:
> > On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > Now that we can deal gracefully with bootloader (firmware) initialized
> >
On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Now that we can deal gracefully with bootloader (firmware) initialized
> > display on aarch64 laptops[1], the
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that we can deal gracefully with bootloader (firmware) initialized
> display on aarch64 laptops[1], the next step is to deal with the fact
> that the same model of laptop can ha
From: Rob Clark
Finds the panel-id from chosen, so drivers can use this to pick the
correct endpoint when looking up panel.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_of.c | 21 +
include/drm/drm_of.h | 7 +++
2 files changed, 28 insertions(+)
diff --git a/d
From: Rob Clark
The panel-id property in chosen can be used to communicate which panel,
of multiple possibilities, is installed.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/chosen.txt | 69
1 file changed, 69 insertions(+)
diff --git a/Documentation/dev
From: Rob Clark
On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided
to communicate some information about the display. Crutially it has the
panel-id, so the appropriate panel driver can be selected. Read this
out and stash in /chosen/panel-id so that display driver can use i
From: Rob Clark
Use the drm_of_find_panel_id() helper to decide which endpoint to use
when looking up panel. This way we can support devices that have
multiple possible panels, such as the aarch64 laptops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++--
1 file ch
From: Rob Clark
Now that we can deal gracefully with bootloader (firmware) initialized
display on aarch64 laptops[1], the next step is to deal with the fact
that the same model of laptop can have one of multiple different panels.
(For the yoga c630 that I have, I know of at least two possible pan
On Sun, Jun 30, 2019 at 8:18 AM Linus Walleij wrote:
>
> On Sun, Jun 30, 2019 at 3:26 PM Rob Clark wrote:
>
> > I'm ok with this.. although I wonder if we need to try this hard for
> > backwards compat? At least I don't see any upstream dts
> > using the old names. Maybe it is ok to just look t
On Sun, Jun 30, 2019 at 3:26 PM Rob Clark wrote:
> I'm ok with this.. although I wonder if we need to try this hard for
> backwards compat? At least I don't see any upstream dts
> using the old names. Maybe it is ok to just look the other way and break
> them.
I am usually of the opinion that
From: Rob Clark
Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.
In case they were already enabled, the clk_prepare_enable() has no real
effect, other than getting the enable_count/prepare_count into the right
state so that we ca
From: Rob Clark
Request the enable gpio ASIS to avoid disabling bridge during probe, if
already enabled. And if already enabled, defer enabling runpm until
attach to avoid cutting off the power to the bridge.
Once we get to attach, we know panel and drm driver are probed
successfully, so at thi
From: Rob Clark
Prep work for the following patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 3 +++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 38 ++
4 files ch
From: Rob Clark
The aarch64 laptops which ship with windows, have the display by the
bootloader, and efifb (yah!). But unlike x86 laptops, device power
management isn't handled via ACPI[1]. Currently the CCF and genpd
frameworks will turn off power domains and clocks that they think are
unused.
From: Rob Clark
Mark power domains that may be enabled by bootloader, and which should
not be disabled until a driver takes them over.
This keeps efifb alive until the real driver can be probed. In a distro
kernel, the driver will most likely built as a module, and not probed
until we get to us
From: Rob Clark
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.
Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and which should not be
disabled at late_i
Strange...
git send-email did not send this to all recipients listed as Cc: ?!?!?
Added the following persons missing in the mail:
> Cc: Rob Clark
> Cc: Daniel Vetter
> Cc: Jordan Crouse
> Cc: Jeykumar Sankaran
> Cc: Maarten Lankhorst
After sending out 40 mails I am not too happy to discover
On Sat, Jun 29, 2019 at 6:02 AM Linus Walleij wrote:
>
> Insteaf of the MSM DRM code going around and inspecting the
> device tree nodes by itself to find "qcom,misc" GPIO phandles,
> we add a quirk to the core so that if "qcom,misc-gpios" and
> "qcom,misc-gpio" isn't found, we try to find just
>
From: Rob Clark
If we are going to -EPROBE_DEFER due to panel/bridge not probed yet, we
want to do it before we start touching hardware.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 30 +--
drivers/g
From: Rob Clark
Unused and the extra rpm get/put interferes with handover from
bootloader (ie. happens before we have a chance to check if
things are already enabled).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/
From: Rob Clark
2 and 3 are some early prep-work to deal with bootloader enabled
displays, where we want to avoid runpm get/put cycles until we know
that we won't -EPROBE_DEFER. (Otherwise, it will kill the display,
and it's not terribly nice to kill efifb and leave the user with no
good way to
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 0a4c77fb3d94..e323259a16d3 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/
From: Rob Clark
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg80211 videobuf2_vmalloc videobuf2_memops vide
CPU: 4 PID: 25
Hi
I like the idea, but would prefer a more structured approach.
Setting connector->ddc before calling drm_sysfs_connector_add() seems
error prone. The dependency is not really clear from the code or interfaces.
The other thing is that drivers I mostly work on, ast and mgag200, have
code like th
29 matches
Mail list logo
