On Tue, Sep 04, 2018 at 10:06:06PM +0530, Jagan Teki wrote:
> Allwinner SoC like SUN8I and SUN50I has DE2 CCU so enable them
> as default.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v4, v3:
> - none
> Changes for v2:
> - Enable for MACH_SUN8I
>
> drivers/clk/sunxi-ng/Kconfig | 2 ++
> 1
On Tue, Sep 04, 2018 at 10:06:07PM +0530, Jagan Teki wrote:
> Enable DRM Support for Allwinner Display Engine, built as a module.
>
> Signed-off-by: Jagan Teki
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Descriptio
Hi Stefan,
Thank you for the patch.
On Wednesday, 5 September 2018 08:21:08 EEST Stefan Agner wrote:
> The DRM bus flags convey additional information on pixel data on
> the bus. All current available bus flags might be of interest for
> a bridge. Remove the sampling_edge field and use bus_flags.
Hi Stefan,
Thank you for the patch.
On Wednesday, 5 September 2018 08:21:10 EEST Stefan Agner wrote:
> Allow to specify the data-enable polarity required by a dumb VGA
> DAC converting parallel RGB to VGA.
>
> Signed-off-by: Stefan Agner
> ---
> .../devicetree/bindings/display/bridge/dumb-vga-
On Tue, Sep 04, 2018 at 10:06:08PM +0530, Jagan Teki wrote:
> Allwinner SoC like SUN8I and SUN50I are now using DE2 Mixer
> so enable them as default.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v4, v3:
> - none
> Changes for v2:
> - Enable for SUN8I
>
> drivers/gpu/drm/sun4i/Kconfig | 2
On Tue, Sep 04, 2018 at 10:06:09PM +0530, Jagan Teki wrote:
> Allwinner SUN50I are now using DesignWare HDMI so enable
> them as default. This can build DRM_SUN8I_DW_HDMI as module
> since DRM in arm64 has module.
>
> Making this as defult to SUN8I, may cause an issue while
> loading since arm32 D
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
> By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux
> introduced in R40, although it has two PLL-VIDEOs.
>
> Change the A64 HDMI PHY binding to R40 one.
>
> This binding is introduced in v4.19, which is still in RC sta
On Tue, Sep 04, 2018 at 12:40:44PM +0800, Icenowy Zheng wrote:
> Video PLLs on A64 can be set to higher rate that it is actually
> supported by HW.
>
> Limit maximum rate to 1008 MHz. This is the maximum allowed rate by BSP
> clock driver. Interestengly, user manual specifies maximum frequency to
On Tue, Sep 04, 2018 at 12:40:43PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both A64 video PLLs to
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #5 from Michel Dänzer ---
(In reply to Sylvain BERTRAND from comment #4)
> faulty commit: 019cddc88f9e4ae0de2c76802f7137210c2101aa on
> amd-staging-drm-next
That's a pure merge commit, so it's unlikely to be the one that actually ca
On Tue, Sep 04, 2018 at 12:40:45PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> Allwinner A64 has a DE2 display pipeline. The TCONs are similar to the
> ones in A83T, but the mixers are new (similar to the later R40 SoC).
>
> This patch adds dt-binding documentation for A64 DE2 display pip
On Tue, Sep 04, 2018 at 12:40:46PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> Mixers in Allwinner have similar capabilities as others SoCs with DE2.
>
> Add support for them.
>
> Signed-off-by: Jagan Teki
> [Icenowy: Add mixer1]
> Signed-off-by: Icenowy Zheng
> Reviewed-by: Jernej Skr
On Tue, Sep 04, 2018 at 12:40:47PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> Display Engine(DE2) in Allwinner A64 has two mixers and tcons.
>
> The routing for mixer0 is through tcon0 and connected to
> LVDS/RGB/MIPI-DSI controller.
>
> The routing for mixer1 is through tcon1 and conne
On Tue, Sep 04, 2018 at 12:40:49PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> Allwinner A64 HDMI PHY clock has PLL_VIDEO0 as a parent.
>
> Include the macro on dt-bindings so-that the same can be used
> while defining CCU clock phandles.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Rob
On Tue, Sep 04, 2018 at 12:40:52PM +0800, Icenowy Zheng wrote:
> From: Jernej Skrabec
>
> Some boards have HDMI VCC pin connected to voltage regulator which may
> not be turned on by default.
>
> Add support for such boards by adding voltage regulator handling code to
> HDMI driver.
>
> Signed-
On Tue, Sep 04, 2018 at 12:40:48PM +0800, Icenowy Zheng wrote:
> From: Jagan Teki
>
> The HDMI controller on Allwinner A64 is similar on the one on
> H3/H5/A83T (although the PHY is different with A83T).
>
> Add A64 compatible and append A83T compatible as fallback.
>
> Signed-off-by: Jagan Tek
https://bugs.freedesktop.org/show_bug.cgi?id=105046
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Sep 04, 2018 at 12:40:51PM +0800, Icenowy Zheng wrote:
> Allwiner SoCs with DesignWare HDMI controller all come with a "HVCC"
> pin, which is the VCC of HDMI part.
>
> Add a supply property to specify HVCC's regulator in the device tree.
>
> Signed-off-by: Icenowy Zheng
Applied, thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #10 from Michel Dänzer ---
(In reply to Alan W. Irwin from comment #9)
> So the current lockup could be due to an entirely different bug than in the
> lockups I have encountered for the direct use case.
Yeah, that looks like an RCU
https://bugzilla.kernel.org/show_bug.cgi?id=201015
Michel Dänzer (mic...@daenzer.net) changed:
What|Removed |Added
CC||harry.wentl...@amd.co
Hi Stefan,
On Wednesday, 5 September 2018 10:06:28 EEST Laurent Pinchart wrote:
> On Wednesday, 5 September 2018 08:21:08 EEST Stefan Agner wrote:
> > The DRM bus flags convey additional information on pixel data on
> > the bus. All current available bus flags might be of interest for
> > a bridge
On Tue, Sep 04, 2018 at 12:40:50PM +0800, Icenowy Zheng wrote:
> + hdmi_phy: hdmi-phy@1ef {
> + compatible = "allwinner,sun8i-h3-hdmi-phy";
> + reg = <0x01ef 0x1>;
> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DD
On Wed, Sep 05, 2018 at 12:56:03PM +0530, Jagan Teki wrote:
> On Tue, Sep 4, 2018 at 10:10 AM, Icenowy Zheng wrote:
> > From: Jagan Teki
> >
> > Enable all necessary device tree nodes and add connector node to device
> > trees for all supported A64 boards with HDMI.
> >
> > Signed-off-by: Jagan T
On Tue, Sep 04, 2018 at 01:41:33PM -0700, Rodrigo Vivi wrote:
> Maybe start a new file with SPDX identifier?
>
> I like the idea of this split...
I just checked, none of the other drm files have them. I'm not sure I want
to start this specific bikeshed, so I think I'll leave it as-is.
> Acked-by
On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
>
>
> 于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard 写到:
> >On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
> >> By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux
> >> introduced in R40, although it has
This leaves all the commit/check and state handling in drm_atomic.c,
while pulling all the uapi glue and the huge ioctl itself into a
seprate file.
This seems to almost perfectly split the rather big drm_atomic.c file
into 2 equal sizes.
Also adjust the kerneldoc and type a very terse overview te
- drmP.h is now fully split up.
- vkms is happening (and will gain its own todo and docs under a new
vkms.rst file real soon)
- legacy cruft is completely hidden now, drm_vblank.c is split out
from drm_irq.c now. I've decided to drop the task to split out
drm_legacy.ko, partially because Dave
Allwinner SoC like SUN8I and SUN50I has DE2 CCU so enable them
as default.
Signed-off-by: Jagan Teki
---
Changes for v4, v3:
- none
Changes for v2:
- Enable for MACH_SUN8I
drivers/clk/sunxi-ng/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/c
Enable DRM Support for Allwinner Display Engine, built as a module.
Signed-off-by: Jagan Teki
---
Changes for v4, v3, v2:
- none
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f67e8d5e93ad..4919e
Allwinner SoC like SUN8I and SUN50I are now using DE2 Mixer
so enable them as default.
Signed-off-by: Jagan Teki
---
Changes for v4, v3:
- none
Changes for v2:
- Enable for SUN8I
drivers/gpu/drm/sun4i/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/su
Allwinner SUN50I are now using DesignWare HDMI so enable
them as default. This can build DRM_SUN8I_DW_HDMI as module
since DRM in arm64 has module.
Making this as defult to SUN8I, may cause an issue while
loading since arm32 DRM built as static.
Signed-off-by: Jagan Teki
---
Changes for v4:
- no
Dne torek, 04. september 2018 ob 11:04:21 CEST je Chen-Yu Tsai napisal(a):
> On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec
wrote:
> > Support for mixer0, mixer1, writeback and rotation units is added.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Icenowy Zheng
> > ---
> >
> > driv
Dne torek, 04. september 2018 ob 11:18:47 CEST je Chen-Yu Tsai napisal(a):
> On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec
wrote:
> > Allwinner H6 SoC has multiplier N range between 1 and 254. Since parent
> > rate is 24MHz, intermediate result when calculating final rate easily
> > overflows 32
Original commit causes "plane A assertion failure" on lid close/lid open
with older HP Compaq 6720s laptops (Intel Mobile GME965/GLE960).
Full bug report at "https://bugs.freedesktop.org/show_bug.cgi?id=107827";.
---
drivers/gpu/drm/drm_atomic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletion
On Tue, Sep 04, 2018 at 12:15:23AM +0200, Henrik Austad wrote:
> This is a respin with a wider audience (all that get_maintainer returned)
> and I know this spams a *lot* of people. Not sure what would be the correct
> way, so my apologies for ruining your inbox.
>
> The 00-INDEX files are suppose
On 9/3/18 4:15 PM, Henrik Austad wrote:
> This is a respin with a wider audience (all that get_maintainer returned)
> and I know this spams a *lot* of people. Not sure what would be the correct
> way, so my apologies for ruining your inbox.
>
> The 00-INDEX files are supposed to give a summary of
On Tue, Sep 4, 2018 at 10:10 AM, Icenowy Zheng wrote:
> From: Jagan Teki
>
> Enable all necessary device tree nodes and add connector node to device
> trees for all supported A64 boards with HDMI.
>
> Signed-off-by: Jagan Teki
> [Icenowy: squash all board patches altogether and change supply nam
于 2018年9月4日 GMT+08:00 下午4:40:56, Chen-Yu Tsai 写到:
>On Sun, Sep 2, 2018 at 3:27 PM Jernej Skrabec
>wrote:
>>
>> From: Icenowy Zheng
>>
>> As we have already binding for the H6 system controller, add its node
>> to the device tree.
>>
>> Signed-off-by: Icenowy Zheng
>> [fixed compatible string]
On Tue, Sep 04, 2018 at 12:15:23AM +0200, Henrik Austad wrote:
> This is a respin with a wider audience (all that get_maintainer returned)
> and I know this spams a *lot* of people. Not sure what would be the correct
> way, so my apologies for ruining your inbox.
>
> The 00-INDEX files are suppose
https://bugs.freedesktop.org/show_bug.cgi?id=107793
Simon Geard changed:
What|Removed |Added
Attachment #141424|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107793
--- Comment #5 from Simon Geard ---
Created attachment 141460
--> https://bugs.freedesktop.org/attachment.cgi?id=141460&action=edit
Output of journalctl -k on successful boot
--
You are receiving this mail because:
You are the assignee for t
From: chunhui dai
Different IC has different phy setting of HDMI.
This patch separaes the phy hardware relate part for mt8173.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/Makefile | 15 +--
drivers/gpu/drm/mediatek/mtk_hdmi.c| 30 +++--
drivers/gpu/drm/me
From: chunhui dai
add refcount for DPI power on/off to protect the flow
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi
From: chunhui dai
Using new API for finding bridge.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 3758cfeb58
In order to support HDMI on mt2701,
we have to make some modifications.
1) Add the HDMI driver.
2) Add the DPI driver.
3) Add a mechanism that config output component by dts.
Changes since v1:
- Separate some patches to independent patch.
- add DISP_REG_CONFIG_DSI_SEL and DISP_REG_CONFIG_DPI_SEL
From: chunhui dai
sometimes hdmi reprobe due to encoder probe late,
but audio dai probe earlier than hdmi. it would make
audio dai cannot find the hdmi codec. we need to
register hdmi codec earlier, and the base name which
used in the register should be PLATFORM_DEVID_NONE,
otherwise some audio d
From: chunhui dai
The address of register DPI_H_FRE_CON is different in different IC.
Using of_node data to find this address.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 29 +++--
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 1 -
2 files chan
From: chunhui dai
The default timing of DPI data and clock is not match.
We could adjust this bit to make them match.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 1 +
2 files changed, 9 insertions(+)
diff --git
DRM driver get the comp->clk by of_clk_get(), we only
assign NULL to comp->clk when error happened, but do
not return the error number.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: chunhui dai
This patch adds dpi dirver suppot for both mt2701 and mt7623.
And also support other (existing or future) chips that use
the same binding and driver.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 25 ++---
drivers/gpu/drm/mediatek
We can select output component by decive node port.
Main path default output component is DSI.
External path default output component is DPI.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 37 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4
From: chunhui dai
This patch adds hdmi dirver suppot for both MT2701 and MT7623.
And also support other (existing or future) chips that use
the same binding and driver.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi.h
From: chunhui dai
different IC has different clock designed in HDMI, the factor for
calculate clock should be different. Usinng the data in of_node
to find this factor.
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 28 +++-
1 file changed, 19 inser
Modify display driver to support connection from BLS to DPI.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_dd
From: chunhui dai
add support for SPDIF audio in HDMI
Signed-off-by: chunhui dai
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 2cb33098ec1a..cd8aaeebb436 100644
https://bugs.freedesktop.org/show_bug.cgi?id=107793
--- Comment #6 from Simon Geard ---
Ok, I've added the output of "journalctl -k -b" (the current, successful boot)
and "journalctl -k -b -1" (a failed boot a few minutes previously).
--
You are receiving this mail because:
You are the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=200531
--- Comment #9 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
(In reply to Barry G from comment #8)
> I wasn't having these issues with 4.17 as far as I could tell.
Just re-tested 4.17.0 - no, the issue is present there too.
4.19-rc2 works
Hi,
Here is a set of patches to allow the phy framework consumers to test and
apply runtime configurations.
This is needed to support more phy classes that require tuning based on
parameters depending on the current use case of the device, in addition to
the power state management already provide
The MIPI D-PHY spec defines default values and boundaries for most of the
parameters it defines. Introduce helpers to help drivers get meaningful
values based on their current parameters, and validate the boundaries of
these parameters if needed.
Signed-off-by: Maxime Ripard
---
drivers/phy/Kcon
The crtc_* variants of the timings are initialised at the same value than
their !crtc counterparts, and can later on be tweaked. This means that we
can always use the crtc variants, instead of trying to figure out which of
these two we should use.
Move to always use the crtc_* variants, and remove
Now that we have some infrastructure for it, allow the MIPI D-PHY phy's to
be configured through the generic functions through a custom structure
added to the generic union.
The parameters added here are the one defined in the MIPI D-PHY spec, plus
some parameters that were used by a number of PHY
MIPI D-PHY is a MIPI standard meant mostly for display and cameras in
embedded systems. Add a mode for it.
Signed-off-by: Maxime Ripard
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 9713aebdd348..9cba7fe16c
Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c | 466 +--
Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 11 +-
drivers/gpu/drm/sun4i/Makefile
Cadence has designed a D-PHY that can be used by the, currently in tree,
DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
Only the DSI driver has an ad-hoc driver for that phy at the moment, while
the v4l2 drivers are completely missing any phy support. In order to make
that phy
The phy framework is only allowing to configure the power state of the PHY
using the init and power_on hooks, and their power_off and exit
counterparts.
While it works for most, simple, PHYs supported so far, some more advanced
PHYs need some configuration depending on runtime parameters. These PH
The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c | 87 +
Now that our MIPI D-PHY driver has been converted to the phy framework,
let's move it into the drivers/phy directory.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 10 +-
drivers/gpu/drm/sun4i/Makefile | 1 +-
drivers/gpu/drm/sun4i/sun6i_mipi_dphy
Subject: Revert "drm/atomic: Handling the case when setting old crtc for plane"
On Wed, 05 Sep 2018, Karsten Hohmeier wrote:
> Original commit causes "plane A assertion failure" on lid close/lid open
> with older HP Compaq 6720s laptops (Intel Mobile GME965/GLE960).
> Full bug report at "https:/
Hi, Bibby:
This looks reasonable, but why MT8173 doesn't need this patch? So
describe more about why MT7623 need this patch. If this is caused by
latest DRM core flow change, I think we should treat this patch
independent with MT7623.
Regards,
CK
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wr
On 4 September 2018 at 23:33, Dave Airlie wrote:
> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote:
>>
>> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
>> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
>> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
>> >>> On 08/31/2
On Wed, Sep 05, 2018 at 12:23:52PM +0300, Jani Nikula wrote:
>
> Subject: Revert "drm/atomic: Handling the case when setting old crtc for
> plane"
>
> On Wed, 05 Sep 2018, Karsten Hohmeier wrote:
> > Original commit causes "plane A assertion failure" on lid close/lid open
> > with older HP Comp
Op 05-09-18 om 00:26 schreef Karsten Hohmeier:
> Original commit causes "plane A assertion failure" on lid close/lid open
> with older HP Compaq 6720s laptops (Intel Mobile GME965/GLE960).
> Full bug report at "https://bugs.freedesktop.org/show_bug.cgi?id=107827";.
> ---
> drivers/gpu/drm/drm_atom
https://bugzilla.kernel.org/show_bug.cgi?id=201015
--- Comment #3 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
(In reply to Michel Dänzer from comment #2)
> Is this a regression in 4.19-rc compared to 4.18?
No, happens on 4.18.5 too.
But on 4.18 suspend-resume also triggers
https://bugzi
Hey Karsten, thanks for the patch! I don't know if it's correct or not,
but I'll comment on a few other things.
The title of the commit should be a description of what your commit does;
in this case you should probably keep the title that git gave you when
you did `git revert`, as well as the fir
Hi, Bibby:
One inline comment.
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> The address of register DPI_H_FRE_CON is different in different IC.
> Using of_node data to find this address.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.
Quoting Daniel Vetter (2018-09-04 22:46:33)
> On Tue, Sep 04, 2018 at 09:53:19PM +0100, Chris Wilson wrote:
> > Since this is handling user provided bpp and depth, we need to sanity
> > check and propagate the EINVAL back rather than assume what the insane
> > client intended and fill the logs with
Hi, Emil,
On 09/05/2018 11:33 AM, Emil Velikov wrote:
On 4 September 2018 at 23:33, Dave Airlie wrote:
On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote:
On 09/03/2018 06:33 PM, Daniel Vetter wrote:
On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
On 08/31/2018 05:30 PM,
Since this is handling user provided bpp and depth, we need to sanity
check and propagate the EINVAL back rather than assume what the insane
client intended and fill the logs with DRM_ERROR.
v2: Check both bpp and depth match the builtin pixel format, and
introduce a canonical DRM_FORMAT_INVALID t
https://bugs.freedesktop.org/show_bug.cgi?id=107835
Bug ID: 107835
Summary: DisplayPort audio stopped working in a kernel upgrade
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Sever
Quoting Chris Wilson (2018-09-05 11:22:05)
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
>
> v2: Check both bpp and depth match the builtin pixel f
Hi, Bibby:
One more inline comment.
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> The address of register DPI_H_FRE_CON is different in different IC.
> Using of_node data to find this address.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk
Hi, Bibby:
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> The default timing of DPI data and clock is not match.
> We could adjust this bit to make them match.
>
> Signed-off-by: chunhui dai
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c |
Dear Michał,
Thank you for documenting the function. Do you mean *to* instead of *do*
in the commit message summary?
On 09/01/18 16:08, Michał Mirosław wrote:
> Document remove_conflicting_framebuffers() behaviour.
>
> Signed-off-by: Michał Mirosław
> ---
> drivers/video/fbdev/core/fbmem.c |
Am Donnerstag, 30. August 2018, 23:12:04 CEST schrieb Heiko Stuebner:
> This patches add support rockchip RGB output, Some Rockchip CRTCs, like
> rv1108 and px30 can directly output parallel and serial RGB data to panel
> or to conversion chip.
> So add a feature-bit for vops to mark the ability fo
Am Donnerstag, 30. August 2018, 13:09:37 CEST schrieb Heiko Stuebner:
> The rk3188 has 2 vops not using iommus which only output directly
> to a rgb interface per vop. So all other output modes like hdmi
> are provided by external brige chips.
>
> Signed-off-by: Heiko Stuebner
applied to drm-mis
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #6 from Sylvain BERTRAND ---
I tested several times that:
- this commit is failing.
- the commit right before this one was working.
Then, I can reasonably say, this commit, whatever its type, is the one breaking
di
https://bugzilla.kernel.org/show_bug.cgi?id=201023
Bug ID: 201023
Summary: amdgpu fails compilation
Product: Drivers
Version: 2.5
Kernel Version: 4.18
Hardware: All
OS: Linux
Tree: Mainline
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #7 from Felix Schwarz ---
In reply to Sylvain BERTRAND from comment #6)
> I tested several times that:
>- this commit is failing.
>- the commit right before this one was working.
>
> Then, I can reasonably say, this
Cc: Emil Velikov
Signed-off-by: Eric Engestrom
---
xf86drm.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 7807dce9c7fbba6d74f7..649d400bcbc494ac04e6 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2998,26 +2998,20 @@ static
"real_path" was getting confusing when there are other *paths in the
same functions.
Signed-off-by: Eric Engestrom
---
xf86drm.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 649d400bcbc494ac04e6..b2388194932754dadc99
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #8 from Felix Schwarz ---
Bugzilla: The tool which preserves all my stupid errors for eternity. :-/
Sorry, I just read the previous comments and of course you used git bisect
already... Still you should test both parents of a merge
https://bugs.freedesktop.org/show_bug.cgi?id=107213
--- Comment #13 from Shmerl ---
I have a recent kernel and userland stack with Debian testing, it's still
crashing and falling back into sddm. But with newest kernel I don't see the
segfault message in dmesg anymore.
Linux 4.19.0-rc2-amd64 #1 S
Hi Eric,
On 5 September 2018 at 13:31, Eric Engestrom wrote:
> -static char *
> +static void
> get_real_pci_path(int maj, int min, char *real_path)
> {
> char path[PATH_MAX + 1], *term;
>
> snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
> -if (!realpath(path
https://bugs.freedesktop.org/show_bug.cgi?id=107213
--- Comment #14 from Shmerl ---
Correction, segfault is still happening, it's just not consistent (not every
time).
[ 683.792530] QThread[3520]: segfault at f ip 7f41f9f2ae60 sp
7f41f19d4500 error 4 in libwayland-client.so.0.3.0[7f41f9
On 5 September 2018 at 11:10, Thomas Hellstrom wrote:
> Hi, Emil,
>
>
> On 09/05/2018 11:33 AM, Emil Velikov wrote:
>>
>> On 4 September 2018 at 23:33, Dave Airlie wrote:
>>>
>>> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom
>>> wrote:
On 09/03/2018 06:33 PM, Daniel Vetter wrote:
>
On 09/05/2018 03:07 PM, Emil Velikov wrote:
On 5 September 2018 at 11:10, Thomas Hellstrom wrote:
Hi, Emil,
On 09/05/2018 11:33 AM, Emil Velikov wrote:
On 4 September 2018 at 23:33, Dave Airlie wrote:
On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom
wrote:
On 09/03/2018 06:33 PM, Daniel Vet
On Tue, Sep 04, 2018 at 05:14:01PM -0700, Jeykumar Sankaran wrote:
> On 2018-08-29 10:49, Sean Paul wrote:
> > From: Sean Paul
> >
> > The atomic_check is a bit too aggressive with respect to planes which
> > leave the active area. This caused a bunch of log spew when the cursor
> > got to the ed
On Tue, Sep 04, 2018 at 04:03:25PM -0700, Jeykumar Sankaran wrote:
> On 2018-08-31 09:08, Sean Paul wrote:
> > On Tue, Aug 28, 2018 at 05:40:01PM -0700, Jeykumar Sankaran wrote:
> > > Strip down the support for topology enums. It
> > > can be replaced with simple hw count checks.
> > >
> >
> > Ch
Ok, I got it. Since my git knowledge is quite limited, this "merge" commit is
opening a vast sea of new commits to test.
I'll dive into bisection using bisect (which actually deals with those merge
commits). I am a bit scared of the amount of commits, may take hours/days.
Please, in the foreseab
1 - 100 of 245 matches
Mail list logo
