Hi Jyri,
On Tue, Mar 19, 2019 at 04:38:45PM +0200, Jyri Sarha wrote:
> On 17/03/2019 18:16, Laurent Pinchart wrote:
> > On Thu, Mar 14, 2019 at 01:27:51PM +0200, Jyri Sarha wrote:
> >> The sii902x chip family supports also HDMI audio. Add binding for
> >> describing the necessary i2s and mclk wiri
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #85 from Diego Viola ---
Created attachment 144054
--> https://bugs.freedesktop.org/attachment.cgi?id=144054&action=edit
xterm exhibiting the bug
xterm exhibiting the bug after running "dmesg" and hitting Shift+PgUp.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #84 from Diego Viola ---
(In reply to Michel Dänzer from comment #83)
> (In reply to Diego Viola from comment #82)
> > I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but
> > it still happens with -glamor.
>
Hi Jyri,
Thank you for the patch.
On Fri, Mar 22, 2019 at 10:06:14AM +0200, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x.txt
Hi Maxime,
On Thu, Apr 18, 2019 at 10:56:30PM +0200, Maxime Ripard wrote:
> On Thu, Apr 18, 2019 at 02:32:14PM +0200, Daniel Vetter wrote:
> > Unifying the formats themselves, and all the associated metadata is
> > imo a no-go, and was a pretty conscious decision when we implemented
>
Hi Daniel,
On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote:
> > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 18, 2019 at 8:22 AM Maxime Ripard wrote:
> > > > On Wed, Apr 17, 2019 at 05:41:21PM
Hi Paul,
On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote:
> >> And a lot of people pushed for the "fourcc is a standard", when
> >> really it's totally not
Hi Andrzej,
On Mon, Apr 15, 2019 at 02:12:46PM +0200, Andrzej Hajda wrote:
> On 15.04.2019 13:19, Tomi Valkeinen wrote:
> > On 15/04/2019 13:09, Andrzej Hajda wrote:
> >> On 26.03.2019 11:31, Tomi Valkeinen wrote:
> >>> In tc_bridge_mode_set callback, we store the pointer to the given
> >>> drm_di
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:42PM +0200, Tomi Valkeinen wrote:
> As far as I know, drm_connector_helper_funcs.best_encoder is not needed
> in a trivial case as we have here. So remove tc_connector_best_encoder.
I would add that the operation is only needed when
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:41PM +0200, Tomi Valkeinen wrote:
> We have tc_connector_mode_valid() to filter out videomdoes that the
> tc358767 cannot support. As it is a bridge limitation, change the code
> to use drm_bridge_funcs's mode_valid instead.
>
> Sig
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:40PM +0200, Tomi Valkeinen wrote:
> tc_main_link_enable() checks if videomode has been set, and fails if
> there's no videomode. As tc_main_link_enable() no longer depends on the
> videomode, we can drop the check.
Shouldn't you mov
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:39PM +0200, Tomi Valkeinen wrote:
> The current link training code does unnecessary retry-loops, and does
> extra writes to the registers. It is easier to follow the flow and
> ensure it's similar to Toshiba's documentation if we dea
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:38PM +0200, Tomi Valkeinen wrote:
> The driver has a loop after ending link training, where it reads the
> DPCD link status and prints an error if that status is not ok.
>
> The loop is unnecessary, as far as I can understand from D
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:37PM +0200, Tomi Valkeinen wrote:
> At the end of the link training, two steps have to be taken: 1)
> tc358767's LT mode is disabled by a write to DP0_SRCCTRL, and 2) Remove
> LT flag in DPCD 0x102.
>
> Toshiba's documentation tells
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:36PM +0200, Tomi Valkeinen wrote:
> For some reason the driver has a msleep(100) after writing to
> DP_PHY_CTRL. Toshiba's documentation doesn't suggest any delay is
> needed, and I have not seen any issues with the sleep removed.
I
Hi Tomi,
On Mon, Apr 15, 2019 at 02:26:20PM +0300, Tomi Valkeinen wrote:
> On 15/04/2019 11:49, Andrzej Hajda wrote:
> > On 26.03.2019 11:31, Tomi Valkeinen wrote:
> >> Link training will sometimes fail if the DP link is, for some whatever
> >> reason, enabled when tc_main_link_enable() is called.
Hi Tomi,
Thank you for the patch.
On Mon, Apr 15, 2019 at 02:39:21PM +0300, Tomi Valkeinen wrote:
> On 15/04/2019 11:36, Andrzej Hajda wrote:
>
> >> +static int tc_main_link_disable(struct tc_data *tc)
> >> +{
> >> + int ret;
> >> +
> >> + dev_dbg(tc->dev, "link disable\n");
> >> +
> >> + tc_
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:33PM +0200, Tomi Valkeinen wrote:
> We set up the PXL PLL inside tc_main_link_setup. This is unnecessary,
> and makes tc_main_link_setup depend on the video-mode, which should not
> be the case. As PXL PLL is used only for the video
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:32PM +0200, Tomi Valkeinen wrote:
> It is nicer to have enable/disable functions instead of set(bool enable)
> style function.
When the two functions have nothing in common, yes.
> Split tc_main_link_stream into tc_stream_enable an
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:31PM +0200, Tomi Valkeinen wrote:
> The driver currently sets the video stream registers in
> tc_main_link_setup. One should be able to establish the DP link without
> any video stream, so a more logical place is to configure the str
Hi Tomi,
Thank you for the patch.
On Mon, Apr 15, 2019 at 10:52:38AM +0300, Tomi Valkeinen wrote:
> On 15/04/2019 10:38, Andrzej Hajda wrote:
> > On 26.03.2019 11:31, Tomi Valkeinen wrote:
> >> Modify aux_link_setup so that it does not use tc->link, and thus makes
> >> aux setup independent of th
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:29PM +0200, Tomi Valkeinen wrote:
> swing and preemp fields are not used. Remove them.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358767.c | 2 --
> 1 file changed, 2 deleti
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:28PM +0200, Tomi Valkeinen wrote:
> Minor cleanups:
> - Use bool for boolean fields
> - Use DP_MAX_DOWNSPREAD_0_5 instead of BIT(0)
> - debug print down-spread and scrambler status
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: La
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> the ANSI 8B10B bit set in DPCD, even if it should always be set.
Makes you wonder why the bit is present :-) I've checked th
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:26PM +0200, Tomi Valkeinen wrote:
> We need to reset DPCD voltage-swing & pre-emphasis before starting the
> link training, as otherwise tc358767 will use the previous values as
> minimums.
>
> Signed-off-by: Tomi Valkeinen
> ---
>
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:25PM +0200, Tomi Valkeinen wrote:
> tc_aux_get_status() does not report AUX_TIMEOUT correctly, as it only
> checks the AUX_TIMEOUT if aux is still busy. Fix this by always checking
> for AUX_TIMEOUT.
>
> Signed-off-by: Tomi Valkeine
https://bugs.freedesktop.org/show_bug.cgi?id=107623
taij...@posteo.de changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110477
taij...@posteo.de changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110477
Bug ID: 110477
Summary: [5.0.7] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]]
*ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!
Product: DRI
Version: unspecified
Hardware:
Den 20.04.2019 12.45, skrev Noralf Trønnes:
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
>
> Changes this time:
> - Use full drm_client_init/release for the modesets (Daniel Vetter)
> - drm_client_for_each_modeset: use lockdep_
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: c5fdcd8bd5c596bfc70b6be93e6f04d910c51308
commit: c5fdcd8bd5c596bfc70b6be93e6f04d910c51308 [9/9] drm-tip:
2019y-04m-19d-20h-56m-16s UTC integration manifest
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GC
The hotplug detection routine of drm_helper_hpd_irq_event() can detect
changing of status of connector, but it can not detect changing of
properties of the connector.
e.g. changing of edid while suspend/resume, changing of dp lanes in dp aux.
Following scenario explains one of them; A detection of
On Thu, Apr 18, 2019 at 7:33 PM Jani Nikula wrote:
>
> On Thu, 18 Apr 2019, Gwan-gyeong Mun wrote:
> > The hotplug detection routine of drm_helper_hpd_irq_event() can detect
> > changing of status of connector, but it can not detect changing of
> > properties of the connector.
> > e.g. changing o
Hi Dave,
On Thu, Mar 28, 2019 at 09:07:14AM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds support for 16 missing RGB formats to the DU
> driver. To do is, the formats are first added to the VSP1 driver.
> Patches 1/9 to 3/9 define those formats in the V4L2 API, patches 4/9 to
On Wed, 17 Apr 2019 at 10:48, Rob Herring wrote:
>
> On Sun, Apr 14, 2019 at 3:08 PM Paul Cercueil wrote:
> >
> > Add macros that can be used with the ingenic,lcd-mode property in the
> > devicetree node that corresponds to the ingenic-drm driver.
>
> DRM is a Linuxism.
>
> >
> > Signed-off-by: P
An example to showcase the client API.
TODO:
A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be reversed for
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_client_modeset.c | 706 ++-
drivers/gpu/drm/drm_fb_helper.c | 691 --
include/drm/drm_client.h
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282
It now only contains the modeset so use that directly instead and attach
a modeset array to drm_client_dev. drm_fb_helper will use this array.
Code will later be moved to drm_client, so add code there in a new file
drm_client_modeset.c with MIT license to match drm_fb_helper.c.
The modeset connect
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Use full drm_client_init/release for the modesets (Daniel Vetter)
- drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
- Hook up to Documentation/gpu
drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.
Avoid this race by holding the drm_device->master_mutex lock while
committin
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files changed
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 131 ---
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */ o
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
d
The values are already present in the modeset.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 12
include/drm/drm_fb_helper.h |
All drivers add all their connectors so there's no need to keep around an
array of available connectors.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 3 +
drivers/gpu/dr
On 2019/4/20 2:00, John Stultz wrote:
From: Da Lv
The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the off
Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
> > It would be cool if both could be used concurrently and not just return
> > -EBUSY when the device is used with the other subsystem.
>
> We live in this world already :-) I think there's even patches (or merged
> already) to add fen
This is required to bring Mali450 gpu out of reset. Also
we now use CLK_OF_DECLARE_DRIVER to probe in both the
clock and reset drivers. The clock and reset parts have
been done as one atomic commit to avoid a bisection hole.
Signed-off-by: Peter Griffin
Cc: Stephen Boyd
---
arch/arm64/boot/dts/
This is required to bring Mali450 gpu out of reset.
Signed-off-by: Peter Griffin
Reviewed-by: Rob Herring
---
include/dt-bindings/reset/hisi,hi6220-resets.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/dt-bindings/reset/hisi,hi6220-resets.h
b/include/dt-bindings/reset/his
Hi folks,
This series adds support for the Mali450 MP4 GPU found on the
hi6220 SoC from HiSilicon. It has been tested with the
lima drm/mesa driver hosted on freedesktop.org gitlab,
and validated using Weston and kmscube.
As lima drm driver has now been merged this v2 series includes
one extra pa
This changeset adds a driver for the SPI keyboard and trackpad on recent
MacBook's and MacBook Pro's. The driver has seen a fair amount of use
over the last 2 years (basically anybody running linux on these
machines), with only relatively small changes in the last year or so.
For those interested,
On Hikey board all lima ip blocks are shared with one irq.
This patch avoids a NULL ptr deref crash on this platform
on startup. Tested with Weston and kmscube.
Signed-off-by: Peter Griffin
Cc: Rob Herring
Cc: Daniel Vetter
Cc: Qiang Yu
---
drivers/gpu/drm/lima/lima_pp.c | 8 +++-
1 file
commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
of RC_CORE) changed the driver to select both RC_CORE and INPUT.
However, this causes problems with other drivers, in particular an input
driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
commit):
drivers/c
The reset driver now supports the ao reset controller, so update the
documentation to match.
Signed-off-by: Peter Griffin
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/
hi6220 has a Mali450 MP4 so lets add it into the DT.
Signed-off-by: Peter Griffin
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.d
The Hisilicon hi6220 uses a Mali-450MP4 with 4 PPs, so add
a compatible for it.
Signed-off-by: Peter Griffin
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,
The keyboard and trackpad on recent MacBook's (since 8,1) and
MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
of USB, as previously. The higher level protocol is not publicly
documented and hence has been reverse engineered. As a consequence there
are still a number of unknow
Le vendredi 19 avril 2019 à 13:27 +0900, Tomasz Figa a écrit :
> On Fri, Apr 19, 2019 at 9:30 AM Nicolas Dufresne wrote:
> > Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
> > > > It would be cool if both could be used concurrently and not just return
> > > > -EBUSY when the device
Pushed to drm-misc-next.
Thanks,
Qiang
On Fri, Apr 19, 2019 at 4:35 PM Peter Griffin wrote:
>
> On Hikey board all lima ip blocks are shared with one irq.
> This patch avoids a NULL ptr deref crash on this platform
> on startup. Tested with Weston and kmscube.
>
> Signed-off-by: Peter Griffin
>
61 matches
Mail list logo
