From: Chen-Yu Tsai
In commit 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK
to 1.") it was assumed that all TCON variants support a minimum divider
of 1 if only DCLK was used.
However, the oldest generation of hardware only supports minimum divider
of 4 if only DCLK is used. If a
On 27/12/2019 13:54, Maxime Ripard wrote:
On Wed, Dec 25, 2019 at 09:20:42PM +0800, yu kuai wrote:
no functional change, just to make the code simpler
Signed-off-by: yu kuai
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c| 6 ++
d
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f75fc37b5e70b75f21550410f88e2379648120e2
commit: f75fc37b5e70b75f21550410f88e2379648120e2 [20/20] drm/i915/gt: Mark up
virtual engine uabi_instance
If you fix the issue, kindly add following tag
Reported-by: kbuild test
Hi, Dave, Daniel, Matthias:
In mediatek-drm-next-5.6 [1], I've cherry-pick 3 patches from
v5.5-next/soc [2] because some drm patches depend on these cmdq patches.
So these cmdq patches exist in both tree now. I want to know how to
process this case. I think we could choose one of below way:
1. Be
On 2020.01.06 16:06:20 +0200, Julian Stecklina wrote:
> The documentation had some stale paths to i915 graphics virtualization
> code. Fix them to point to existing files.
>
> Cc: Zhenyu Wang
> Cc: zhiyuan...@intel.com
> Cc: hang.y...@intel.com
>
> Signed-off-by: Julian Stecklina
> ---
> Docum
On 1/6/20 1:01 AM, Jan Kara wrote:
...
Also, looking ahead:
a) if the problem disappears with the latest above test, then we likely have
a huge page refcount overflow, and there are a couple of different ways to
fix it.
b) if it still reproduces with the above, then it's some other rand
On 1/7/20 6:43 AM, Doug Anderson wrote:
Dear Robot,
On Sat, Dec 21, 2019 at 5:57 AM kbuild test robot wrote:
Hi Douglas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.5-rc2 next-20191220]
[if your patch is applied
On Tue, 7 Jan 2020 at 05:17, James Jones wrote:
>
> On 1/5/20 5:30 PM, Ben Skeggs wrote:
> > On Tue, 17 Dec 2019 at 10:44, James Jones wrote:
> >>
> >> This series modifies the NV5x+ nouveau display backends to advertise
> >> appropriate format modifiers on their display planes in atomic mode
> >
On Thu, Jan 2, 2020 at 10:14 AM Harry Wentland wrote:
>
> On 2019-12-02 4:47 p.m., Thomas Anderson wrote:
> > For high-res (8K) or HFR (4K120) displays, using uncompressed pixel
> > formats like YCbCr444 would exceed the bandwidth of HDMI 2.0, so the
> > "interesting" modes would be disabled, leav
On Fri, Jan 3, 2020 at 6:53 PM Manasi Navare wrote:
>
> Harry, Jani - Since this also updates the AMD driver file, should this be
> merged through
> AMD tree and then backmerged to drm-misc ?
Take it through whatever tree is easiest for you.
Alex
>
> Manasi
>
> On Mon, Dec 30, 2019 at 09:45:15
On Fri, Jan 3, 2020 at 2:34 PM Wambui Karuga wrote:
>
> list_for_each() can be replaced by the more concise
> list_for_each_entry() here for iteration over the lists.
> This change was reported by coccinelle.
>
> Signed-off-by: Wambui Karuga
Applied. Thanks!
Alex
> ---
> .../drm/amd/display/
On Fri, Jan 3, 2020 at 2:34 PM Wambui Karuga wrote:
>
> As single statement conditionals do not need to be wrapped around
> braces, the unnecessary braces can be removed.
>
> Signed-off-by: Wambui Karuga
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 3 +--
> driv
On Fri, Jan 3, 2020 at 2:34 PM Wambui Karuga wrote:
>
> Remove unnecessary variable comparisions to true/false in if statements
> and check the value of the variable directly.
>
> Signed-off-by: Wambui Karuga
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik_sdma.c | 2
Hi,
On Wed, Dec 18, 2019 at 2:36 PM Douglas Anderson wrote:
>
> This series contains a pile of patches that was created to support
> hooking up the AUO B116XAK01 panel to the eDP side of the bridge. In
> general it should be useful for hooking up a wider variety of DP
> panels to the bridge, esp
Dear Robot,
On Sat, Dec 21, 2019 at 5:57 AM kbuild test robot wrote:
>
> Hi Douglas,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v5.5-rc2 next-20191220]
> [if your patch is applied to the wrong git tree, please d
FW property).
I have tested this series on a Rockchip RK3328 Rock64 device along with early
work
on rockchip dw-hdmi bus format negotiation at [1]. All output modes supported
on RK3328 works (RGB444, YUV420/444, 8/10-bit).
So for this entire series:
Tested-by: Jonas Karlman
[1] https:/
Hi,
On Mon, Dec 23, 2019 at 12:49 AM Jonas Karlman wrote:
>
> Commit 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock
> framework")
> changed what rate clk_round_rate() is called with, an additional 999 Hz
> added to the requsted mode clock. This has caused a regression on RK33
On Mon, Dec 16, 2019 at 09:37:50AM -0700, Jordan Crouse wrote:
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU stru
On Tue, Dec 24, 2019 at 08:27:28AM +0530, smase...@codeaurora.org wrote:
> On 2019-12-16 22:07, Jordan Crouse wrote:
> >Attempt to enable split pagetables if the arm-smmu driver supports it.
> >This will move the default address space from the default region to
> >the address range assigned to TTBR
at [4].
[1] https://patchwork.kernel.org/cover/11320061/
[2] https://patchwork.freedesktop.org/series/71675/
[3] https://github.com/Kwiboo/linux-rockchip/commits/next-20200106-inno-hdmi-phy
[4] https://github.com/Kwiboo/linux-rockchip/commits/next-20200106-bus-format
>
> Hence I can also just po
Am Montag, 6. Januar 2020, 21:50:02 CET schrieb Jonas Karlman:
> From: Algea Cao
>
> Adding the following freq cfg in 8-bit and 10-bit color depth:
>
> {
> 4000, 6500, 7100, 8350, 8575,
> 8875, 10800, 11900, 16200
> }
>
> New freq has been validated by
Hi Jonas,
Am Montag, 6. Januar 2020, 21:48:25 CET schrieb Jonas Karlman:
> Using a destination width that is more then 3840 pixels
> is not supported in scl_vop_cal_scl_fac().
>
> Work around this limitation by filtering all modes with
> a width above 3840 pixels.
could you try to send the whole
mpll_cfg/cur_ctr/phy_config is not used when phy_force_vendor is true,
lets remove them.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/d
RK3228/RK3328 does not provide a stable hdmi signal at TMDS rates
above 371.25MHz (340MHz pixel clock).
Limit the pixel clock rate to 340MHz to provide a stable signal.
Also limit the pixel clock to the display reported max tmds clock.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/d
From: Algea Cao
Adding the following freq cfg in 8-bit and 10-bit color depth:
{
4000, 6500, 7100, 8350, 8575,
8875, 10800, 11900, 16200
}
New freq has been validated by quantumdata 980.
For some freq which can't be got by only using integer freq div,
The VOP on RK3328 needs to run at higher rate in order to
produce a proper 3840x2160 signal.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/bo
Add the hdmiphy clock as the vpll in hdmi node.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index ee4b6170a9e6..987c04abb387 10
Add the hdmiphy clock as the vpll in hdmi node.
Signed-off-by: Jonas Karlman
---
arch/arm/boot/dts/rk322x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 340ed6ccb08f..16ad240d5f7f 100644
--- a/arch/
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3228.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
index d17cfb7a3ff4..25f79af22cb8 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drive
RK3228/RK3328 can only support clock rates defined in the pre pll table.
Lets validate the mode clock rate against the pre pll config and filter
out any mode with a clock rate returning error from clk_round_rate().
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17
Prepare support for High TMDS Bit Rates used by HDMI2.0 display modes.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
ind
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
Using a destination width that is more then 3840 pixels
is not supported in scl_vop_cal_scl_fac().
Work around this limitation by filtering all modes with
a width above 3840 pixels.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++
1 file changed, 10
From: Huicong Xu
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-b
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consist
From: Zheng Yang
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a r
This series make it possible to use more HDMI modes on RK3328,
and presumably also on RK3228. It also prepares for a future YUV420 and
10-bit output series.
Part of this has been reworked from vendor BSP 4.4 kernel commits.
Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver.
Pat
>
> Claudiu Beznea (5):
> drm: atmel-hlcdc: use double rate for pixel clock only if supported
> drm: atmel-hlcdc: enable clock before configuring timing engine
> mfd: atmel-hlcdc: add struct device member to struct
> atmel_hlcdc_regmap
> mfd: atmel-hlcdc: return in case of error
>
On 1/5/20 5:30 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:44, James Jones wrote:
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are avail
On 1/5/20 5:25 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:45, James Jones wrote:
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_displa
Hi Claudiu.
On Mon, Jan 06, 2020 at 09:25:40AM +, claudiu.bez...@microchip.com wrote:
>
>
> On 04.01.2020 19:12, Sam Ravnborg wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi Claudiu
> >
> > On Thu, Jan 02, 2020 at 10:08:4
Hi Heiko.
On Mon, Jan 06, 2020 at 07:37:53PM +0100, Heiko Stuebner wrote:
> Am Montag, 6. Januar 2020, 19:17:31 CET schrieb Sam Ravnborg:
> > The reg property in the example caused following warnings:
> >
> > xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format):
> > /example-0/dsi@ff450
The reg property in the example caused following warnings:
xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format):
/example-0/dsi@ff45/panel@0:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
xinpeng,xpp055c272.example.dt.yaml: Warning (pci_device_bu
Device specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific dev_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatical
We will need struct device pointer to pass it to dev_WARN* calls.
Add helper functions to exract device pointer from various structs.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
drivers/gpu/drm/i915/gvt/gvt.h |
dev_WARN does not support conditional warning unlike WARN.
Add condition support to dev_WARN (file: include/linux/device.h)
to make it work like WARN and modify all existing callers to use it.
This is quite useful where we want to replace existing WARN with
dev_WARN.
Following cocci script is us
It's quite useful to print the device name on the stack dump caused
by WARN_ON*.
Introduce dev_WARN_ON and dev_WARN_ON_ONCE macros for the same.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_utils.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915
Device specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific dev_WARN*
variants in functions where any one of intel_pm, intel_encoder,
i915_perf_stream or intel_crtc_state struct poin
Device specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific dev_WARN*
variants in functions where first function argument is a
struct pointer and has drm_i915_private struct pointer
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Knowing the device specific information in the backtrace would be
helpful in development all around.
This patch series aims to con
On Sun, Jan 05, 2020 at 04:51:20PM +0100, Hans de Goede wrote:
> If the new video=... panel_orientation option is set for a connector, honor
> it and setup a matching "panel orientation" property on the connector.
>
> Changes in v2:
> -Improve DRM_INFO message to make it clear that the panel_orien
On 1/6/20 3:28 AM, Geert Uytterhoeven wrote:
Hi Sam,
On Sun, Jan 5, 2020 at 10:13 AM Sam Ravnborg wrote:
Good to see we add more functionality to the smallest driver in DRM.
The patch triggered a few comments - see below.
Some comments relates to the original driver - and not your changes.
T
Hi Geert.
> Thanks for your comments!
>
> > On Thu, Jan 02, 2020 at 03:12:46PM +0100, Geert Uytterhoeven wrote:
> > > Add support for the Okaya RH128128T display to the st7735r driver.
> > >
> > > The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix
> > > ST7715R TFT Controller/Drive
On 1/2/20 8:46 AM, Sam Ravnborg wrote:
Hi Geert.
On Thu, Jan 02, 2020 at 03:12:44PM +0100, Geert Uytterhoeven wrote:
Document support for the Okaya RH128128T display, which is a 128x128
1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver.
ST7715R and ST7735R are very similar.
Hi Christian.
> To be honest.. I forgot the change log thing this time - sorry.
It was small changes - so no worries.
> So the rule
> is to have the change log in the normal commit message?
This is what Danial Vetter tell people - but it is not documented as
far as I can tell.
> Funny - Lucas to
Hi Sam,
> For future patches can you please incldue a small changelog
> within each patch.
>
> Something like
>
> v2:
> - Drop redundant newlines (Lucas)
>
> This serves several purposes:
> - It explains what was changed since last version
> - It allow the reader to focus on changed parts
> - It
Hi Christian
On Mon, Jan 06, 2020 at 04:16:45PM +0100, Christian Gmeiner wrote:
> This patch series extends the hwdb for an entry for the gc400 found
> in the ST STM32 SoC. With this patches we report the same limits and
> features for this GPU as the galcore kernel driver does.
For future patche
The information was taken from STM32 glacore driver hw database.
The entry is named as gc7000nano_0x4652.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hw
This patch series extends the hwdb for an entry for the gc400 found
in the ST STM32 SoC. With this patches we report the same limits and
features for this GPU as the galcore kernel driver does.
Christian Gmeiner (6):
drm/etnaviv: update hardware headers from rnndb
drm/etnaviv: determine produc
Update the state HI header from rnndb commit
7f1ce75 ("rnndb: document some GPU identity register")
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/state_hi.xml.h | 29 --
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv
Use ~0U as marker for 'I do not care'. I am not sure what
GC7000 based devices are in the wild and I do not want to
break them. In the near future we should extend the hwdb.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 3 +++
1 file changed, 3 insertions(+)
diff
They will be used for extended HWDB support.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/dr
Take product id, customer id and eco id into account. If that
delivers no match try a search for model and revision.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etna
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 7ee67e12141d..151033d58bfb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
On Mon, Jan 6, 2020 at 9:10 AM Thomas Zimmermann wrote:
>
> The udl driver for DisplayLink devices depends on support for host-side
> USB controllers, which is enabled with CONFIG_USB. Plain USB support as
> given by CONFIG_USB_SUPPORT not sufficient.
>
> This patch changes dependencies for udl to
On 26/12/2019 13:12, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/bridge/cdns-dsi.c: In function
> ‘cdns_dsi_bridge_enable’:
> drivers/gpu/drm/bridge/cdns-dsi.c:788:6: warning: variable ‘bpp’
> set but not used [-Wunused-but-set-variable]
>
> It is never use
On 26/12/2019 13:14, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_mode2cfg’:
> drivers/gpu/drm/bridge/cdns-dsi.c:515:11: warning: variable ‘nlanes’
> set but not used [-Wunused-but-set-variable]
>
> It is never used,
Hi,
On 30/12/2019 10:04, Enric Balletbo i Serra wrote:
> Hi all,
>
> This is another version of the driver. Note that the driver changed
> significally and is a more simply because now is using the panel_bridge
> helpers. Apart from this, I addressed the comments from Maxime, Laurent
> and Ezequi
On 16/12/2019 04:58, zhengbin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/meson/meson_crtc.c:360:3-4: Unneeded semicolon
> drivers/gpu/drm/meson/meson_plane.c:181:2-3: Unneeded semicolon
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/meson/meson_crtc.c
On 06/01/2020 15:40, Boris Brezillon wrote:
> On Mon, 6 Jan 2020 15:34:07 +0100
> Neil Armstrong wrote:
>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> index 8ffa4fbbdeb3..b8b22dc55bdb 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> +++ b
Hi Laurent,
On 19/12/2019 11:44, Laurent Pinchart wrote:
> Hello,
>
> This patch series is the fourth attempt to (nearly, see [1]) complete the
> rework of the omapdrm driver to move to drm_bridge and drm_panel.
>
> Versions, available at [2], explains in its long cover letter the
> rationale fo
On 01/01/2020 15:52, Laurent Pinchart wrote:
> Hi Julia,
>
> Thank you for the patch.
>
> On Wed, Jan 01, 2020 at 08:43:33AM +0100, Julia Lawall wrote:
>> The dw_hdmi_hw structure is only copied into another structure,
>> so make it const.
>>
>> The opportunity for this change was found using Coc
On Mon, 6 Jan 2020 15:34:07 +0100
Neil Armstrong wrote:
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 8ffa4fbbdeb3..b8b22dc55bdb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -590,8 +590,9
On Mon, 6 Jan 2020 15:34:05 +0100
Neil Armstrong wrote:
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
>
> In order to support that, we need drm bridges to fully tak
From: Boris Brezillon
This way the drm_bridge_funcs interface is consistent with the rest of
the subsystem.
The only driver implementing those hooks (analogix DP) is patched too.
Signed-off-by: Boris Brezillon
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
Changes in v6:
* A
From: Boris Brezillon
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls
This patch series aims at adding support for runtime bus-format
negotiation between all elements of the
'encoder -> bridges -> connector/display' section of the pipeline.
In order to support that, we need drm bridges to fully take part in the
atomic state validation process, which requires adding
From: Boris Brezillon
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges,
From: Boris Brezillon
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object i
This variable is used nowhere, so remove it.
Cc: Zhenyu Wang
Cc: zhiyuan...@intel.com
Cc: hang.y...@intel.com
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediato
The documentation had some stale paths to i915 graphics virtualization
code. Fix them to point to existing files.
Cc: Zhenyu Wang
Cc: zhiyuan...@intel.com
Cc: hang.y...@intel.com
Signed-off-by: Julian Stecklina
---
Documentation/gpu/i915.rst | 8
1 file changed, 4 insertions(+), 4 del
The udl driver for DisplayLink devices depends on support for host-side
USB controllers, which is enabled with CONFIG_USB. Plain USB support as
given by CONFIG_USB_SUPPORT not sufficient.
This patch changes dependencies for udl to depend on CONFIG_USB, instead
of CONFIG_USB_SUPPORT. Users will hav
On Sun, 2019-12-29 at 16:22 +, Eric Engestrom wrote:
> On Monday, 2019-12-16 16:51:28 +, Souza, Jose wrote:
> > Hello
> >
> > I have being contributing to i915 for the past 2 years and part of
> > my
> > work is update the PCI ids of Intel devices in libdrm.
> > Being able to push my revie
Hi Feng,
do you still have the test setup that produced the performance penalty?
If so, could you give a try to the patchset at [1]? I think I've fixed
the remaining issues in earlier versions and I'd like to see if it
actually improves performance.
Best regards
Thomas
[1]
https://lists.freedes
Hi
Am 31.12.19 um 07:50 schrieb Tian Tao:
> since we can get the BO from drm_fb rather than hibmc_fb,do not need
> the hibmc_fb.so we delete the local variable hibmc_fb.
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 +---
>
A number of cleanups that I wanted to apply for some time. The first
two patches simplify the public interface. The third patch adds support
for struct drm_driver.gem_create_object. All tested by running fbdev,
X11 and Weston on ast HW.
v4:
* rebased onto recent drm-tip
v3:
* drm_g
The flag 'interruptible', which is passed to various functions,
is always set to be false. Remove it and hard-code the value.
Signed-off-by: Thomas Zimmermann
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
There's nothing special about hibmc's fbdev emulation that is not
provided by the generic implementation. Switch over and remove the
driver's code.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
...
The hibmc driver aligns scanlines to 16 bytes. By using the new pitch_align
argument of drm_gem_vram_fill_create_dumb(), convert hibmc over.
v2:
* move changes to VRAM helpers into separate patch
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
..
This change makes information about VRAM consumption available on
debugfs. See
/sys/kernel/debug/dri/0/vram-mm
for an overview of how VRAM is being used.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |
The hibmc driver's struct hibmc_framebuffer stores a DRM framebuffer
with an associated GEM object. This functionality is also provided by
generic code. Switch hibmc over.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
.../gpu/drm/hisilicon/hibmc/hibmc_d
Adding the pitch alignment as an argument to drm_gem_vram_fill_create_dumb()
allows to align scanlines to certain offsets. A value of 0 disables scanline
pitches.
v3:
* only do power-of-2 test if pitch_align given; fails otherwise
* mgag200: call drm_gem_vram_fill_create_dumb() wit
Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.
v3:
* separately check allocation failure in if/else branches
before upcast to gbo
v2:
* only cast to gbo within if branch; set gbo d
TTM is an implementation detail of the VRAM helpers and therefore
shouldn't be exposed to the callers. There's only one correct value
for the BO device anyway, which is the one stored in the DRM device.
So remove struct ttm_bo_device from the VRAM-helper interface and
use the device's VRAM manager
Hi
Am 23.12.19 um 04:08 schrieb Zhihui Chen:
> without the obj[0] set, we can see the following panic:
>
> [ 29.236764] pstate: 2049 (nzCv daif +PAN -UAO)
> [ 29.241532] pc : drm_gem_vram_offset+0x10/0x28 [drm_vram_helper]
> [ 29.247511] lr : hibmc_plane_atomic_update+0x30/0xe0 [hibmc_d
https://bugzilla.kernel.org/show_bug.cgi?id=206017
--- Comment #10 from udo (udo...@xs4all.nl) ---
More like 6 hours or less.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugzilla.kernel.org/show_bug.cgi?id=206017
--- Comment #9 from udo (udo...@xs4all.nl) ---
5.4.8 runs less than 12 hours until hard crash when used.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
On Mon, Jan 06, 2020 at 11:03:54AM +0100, Boris Brezillon wrote:
> On Thu, 19 Dec 2019 11:11:48 +0100 Neil Armstrong wrote:
>
> > +/**
> > + * drm_atomic_helper_duplicate_bridge_state() - Default duplicate state
> > helper
> > + * @bridge: bridge containing the state to duplicate
> > + *
> > + *
1 - 100 of 140 matches
Mail list logo
