On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> Unfortunately, the A83t display clocks are not children of the de clock,
> since that clocks doesn't exist at all on the A83t.
>
> For now, they are orphans, so let's move them to their true, existing,
> parent.
>
> Fixes: 763c5bd045b1 ("clk:
Hi All,
I am working for adding the DRM Client cap for the aspect ratio support
as part of the series:
https://patchwork.freedesktop.org/series/10850/ : /Picture aspect ratio
support in DRM layer/ by Shashank Sharma.
I have an open as to how to go about it.
I was going through the existing
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The currently supported planes for DE2 are actually only UI planes, and the
> VI planes will differ both in terms of code and features.
>
> It will make sense to support them in a separate file, so let's make sure
> we don't create a confusin
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The various outputs the TCON can provide have different constraints on the
> dotclock divider. Let's make them configurable by the various mode_set
> functions.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
Make edp display works on chromebook kevin(at least for boot animation).
Also solve some issues i meet during the bringup.
Changes in v4:
Fix compile warning.
Changes in v3:
Assign orphan pwms to dummy pwmchip instead of adding device link in the
customer driver.
Changes in v2:
Use device link
Add missing error handling in rockchip_dp_bind().
Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
Signed-off-by: Jeffy Chen
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 --
1 file cha
Add missing pm_runtime_disable() in bind()'s error handling path.
Also cleanup encoder & connector in unbind().
Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/
Add missing error handling in bind().
Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Jeffy Chen
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/inno_hdmi.c | 20
1 file changed, 16 insertions
From: Tomasz Figa
The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is ba
Add missing clk_disable_unprepare() in bind()'s error handling path.
Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: Jeffy Chen
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 4 +++-
1 file c
Since we are trying to access components' resources in the master's
suspend/resume PM callbacks(e.g. panel), add device links to correct
the suspend/resume and shutdown ordering.
Signed-off-by: Jeffy Chen
---
Changes in v4: None
Changes in v3: None
Changes in v2:
Use device link to correct the s
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
The THS8134A, THS8134B and as it turns out also THS8135 need to
have data clocked out at the negative edge of the clock pulse,
since they clock it into the DAC at the positive ed
This adds device tree bindings for the Texas Instruments
THS8134A and THS8134B VGA DACs by extending and renaming the
existing bindings for THS8135.
These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.
Cc: devicet...@vger.kernel.org
Cc:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> Hi all,
>
> I just sent out a patch that enables FreeSync in Mesa for the somewhat
> hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
> stack's DDX and kernel module. [0]
>
> While this patch isn't meant for upstream, that's as
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> Add support for the A83T display pipeline.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
Am 16.10.2017 21:04, schrieb Christophe JAILLET:
> Rewrite the exit path based on 'au1200fb_drv_remove()'.
> We can safely iterate for all already handled planes. Even if not
> completely initialized, the functions that are called will silently accept
> the 'fb_info' structure that is passed.
>
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The display pipeline on the A83T is mainly composed of the mixers and
> TCONs, plus various encoders.
>
> Let's add the mixers and TCONs to the DTSI.
You are only adding half of them, i.e. only the first pipeline.
Please mention why.
>
> Si
We already have, as a result of upstreaming the gpu bindings,
msm_clk_get() which will try to get the clock both without and with a
"_clk" suffix. Use this in DSI code so we can drop the "_clk" suffix
in bindings while maintaing backwards compatibility.
Signed-off-by: Rob Clark
---
drivers/gpu/
Use our msm_clk_get() helper in more places so "_clk" suffix in
clock names is optional. This was added when upstreaming the GPU
bindings in response to comments that clock names should not have
the "_clk" suffix, and will fall back to looking up the clock
with the suffix for backwards compat with
We already have, as a result of upstreaming the gpu bindings,
msm_clk_get() which will try to get the clock both without and with a
"_clk" suffix. Use this in eDP code so we can drop the "_clk" suffix
in bindings while maintaing backwards compatibility.
Signed-off-by: Rob Clark
---
drivers/gpu/
We already have, as a result of upstreaming the gpu bindings,
msm_clk_get() which will try to get the clock both without and with a
"_clk" suffix. Use this in HDMI code so we can drop the "_clk" suffix
in bindings while maintaing backwards compatibility.
Signed-off-by: Rob Clark
---
drivers/gpu
Now that drm/msm is converted over to use msm_get_clk() everywhere (that
matters), which handles falling back to looking for a clock with the
"_clk" suffix, we can remove "_clk" from the documentation so that new
dts files added do not include "_clk" in the name.
Previously we were doing this for
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The A83T has an LVDS bus that can be connected to a panel or a bridge. Add
> the pinctrl group for it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-de
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The A83T has a PWM that can be output from the SoC. Let's add a pinctrl
> group for it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freed
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
No description?
> Signed-off-by: Maxime Ripard
Changes look good, though unrelated to the rest of the series.
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
On 17.10.2017 12:28, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
Hi all,
I just sent out a patch that enables FreeSync in Mesa for the somewhat
hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
stack's DDX and kernel module. [0]
While this patch isn'
Dear all,
This patchset performs complete rewrite of Exynos DRM IPP subsystem and
its userspace API.
Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
general, but not really extensible on the other side. It is also buggy,
with significant design flaws:
- Userspace API covers m
Some hardware modules, like FIMC in Exynos4 series are shared between
V4L2 (camera support) and DRM (memory-to-memory processing) subsystems.
This patch provides a simple check to let such drivers to be used in the
driver components framework.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/
This patch adds Exynos IPP v2 subsystem and userspace API.
New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback co
Exynos IPP will be rewritten, so remove current IPP core code and mark
existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile |1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 -
drivers/gp
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
Tested-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/Kconfig | 3 +-
d
From: Andrzej Pietrasiewicz
Exynos Scaler is a hardware module, which processes graphic data fetched
from memory and transfers the resultant dato another memory buffer.
Graphics data can be up/down-scaled, rotated, flipped and converted color
space. Scaler hardware modules are a part of Exynos542
From: Andrzej Pietrasiewicz
There are 3 Scaler devices in Exynos5420 SoCs, all are a part of MSCL
power domain. MSCL power domain and SYSMMU controllers (two per each
scaler device) have been already added to exynos5420.dtsi earlier,
so bind them to newly added devices.
Signed-off-by: Andrzej Pi
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/ex
From: Andrzej Pietrasiewicz
There are two Scaler devices in Exynos5433 SoCs. Add nodes for them and
their SYSMMU controllers.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 42 ++
1 file changed
Hi all,
I just sent out a patch that enables FreeSync in Mesa for the somewhat
hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
stack's DDX and kernel module. [0]
While this patch isn't meant for upstream, that's as good a time as any
to raise the issue of how a prope
https://bugs.freedesktop.org/show_bug.cgi?id=103130
--- Comment #6 from Jan Vesely ---
(In reply to Adam from comment #5)
> I upgraded to the offending repo. I attempted again with wine log -all. I
> get:
>
> mesa: for the -simplifycfg-sink-common option: may only occur zero or one
> times!
> /
On Mon, Oct 16, 2017 at 09:04:52PM +0200, Christophe JAILLET wrote:
> There is no need to shut gcc up. It should not complain.
> Axe 'fbdev', it is never used in this function.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/video/fbdev/au1200fb.c | 6 --
> 1 file changed, 6 deletions(
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/Makefile | 1 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 183
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The A83T has the same PWM block than the H3. Add it to our DT.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On Tue, Oct 17, 2017 at 01:03:46PM +1100, Daniel Axtens wrote:
> Bjorn Helgaas writes:
>
> > The default VGA device is normally set in vga_arbiter_add_pci_device() when
> > we call it for the first enabled device that can be accessed with the
> > legacy VGA resources ([mem 0xa-0xb], etc.)
On Mon, Oct 16, 2017 at 07:35:24AM -0700, Tony Lindgren wrote:
> * Daniel Vetter [171016 02:18]:
> > On Mon, Oct 16, 2017 at 05:15:50PM +1000, Dave Airlie wrote:
> > > On 16 October 2017 at 16:53, Tomi Valkeinen wrote:
> > > >
> > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki
On Wed, Oct 11, 2017 at 01:23:33PM +0200, Lothar Waßmann wrote:
> Create a macro that eases the definition of display mode parameters by
> accecpting the parameters:
> freq, hactive, hfront-porch, hsynclen, hback-porch,
> vactive, vfront-porch, vsynclen, vback-porch, vrefresh
> that can be usually
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
No description?
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 163 +--
> 1 file changed, 154 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
On Wed, Oct 11, 2017 at 01:23:34PM +0200, Lothar Waßmann wrote:
> Use the newly defined macro to generate the display_mode data entries
> for all panels. This reduces the code size significantly and makes the
> code more readable.
>
> Signed-off-by: Lothar Waßmann
> ---
> drivers/gpu/drm/panel/p
On Tue, Oct 17, 2017 at 07:20:47AM +0200, Maarten Lankhorst wrote:
> Commit 669c9215afea ("drm/atomic: Make async plane update checks work as
> intended, v2.") forced planes to always be tracked, but forgot to
> explicitly get the crtc commit from the new crtc when available.
>
> This broke plane
On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote:
> The baseboards for the Ka-Ro electronics series of i.MX modules
> use a 24bit LCD interface, no matter what LCD bus width the SoC on the
> module provides and what the LCD panel expects. LCDs with 6bit per color
> will ignore the 2 L
On Wed, Oct 11, 2017 at 01:23:36PM +0200, Lothar Waßmann wrote:
> The Ka-Ro electronics MB7 baseboard has an on-board LCD->LVDS
> converter that requires a fixed pixelclk polarity, no matter what the
> panel's display_mode specifies. Add an option to override the pixelclk
> polarity defined in the
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> The A711 has 1024x600 LVDS panel, with a PWM-based backlight. Add it to our
> DT.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
Though I think tcon0 could be enabled by default all the time.
__
On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
wrote:
> Hi,
>
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modifications.
From: Jonathan Liu
The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.
The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI contr
The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.
The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI controller, or
CVBS/YPbPr/
From: Jonathan Liu
The video PLLs are used directly by the HDMI controller. Export them so
that we can use them in our DT node.
Signed-off-by: Jonathan Liu
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.h | 4 ++--
include/dt-bindings/clock/sun4i-a10-ccu.h | 2 ++
2 f
From: Jonathan Liu
The A10 has two TCONs that are similar to the ones found on other SoCs.
Like the A31, TCON0 has a register used to mux the TCON outputs to the
downstream encoders. The bit fields are slightly different.
Signed-off-by: Jonathan Liu
[w...@csie.org: Reworked for A10 and fixed up
The backend has a mux to select the destination of the data to output
to. It can select the TCON or the frontends. On the A20, it includes
an option to output to the second TCON. This is not documented in the
user manual, but the vendor kernel uses it nevertheless, so the second
backend outputs to
All the A20 devices I own have standard HDMI connectors wired
to the dedicated HDMI pins on the SoC:
- Bananapi M1+
- Cubieboard 2
- Cubietruck
- Lamobo R1 (or Bananapi R1)
Development boards from Olimex also have standard HDMI connectors.
Schematics for them are publicly available. Enabl
Hi everyone,
This series adds display support for Allwinner A10/A20 SoCs to the
sun4i-drm driver. The core display pipeline components and HDMI are
covered. LCD panel RGB output should also be available, but I do not
have devices to test this on.
Jonathan had HDMI working on the A20, along with L
From: Jonathan Liu
The A20 has two interconnected display pipelines, mirroring the A10.
Add all the device nodes for them, including the downstream HDMI
controller that we already support.
Signed-off-by: Jonathan Liu
[w...@csie.org: Squashed in HDMI and provided commit message]
Signed-off-by:
The HDMI controller in the A10 SoC is the same as the one currently
supported in the A10s. It has slightly different setup parameters.
Since these parameters are not thoroughly understood, we add support
for this variant by copying these parameters verbatim.
Signed-off-by: Chen-Yu Tsai
---
.../b
Various A10-based development boards have standard HDMI connectors
wired to the dedicated HDMI pins on the SoC.
Enable the display pipeline and HDMI output on boards I have or have
access to schematics:
- Cubieboard
- Olimex A10-OLinuXino-LIME
Signed-off-by: Chen-Yu Tsai
---
Can someone co
The A10 has two interconnected display pipelines, much like the A31,
but without the DRCs between the backend and TCONs.
Add all the device nodes for them, including the downstream HDMI
controller that we already support.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun4i-a10.dtsi | 306 ++
On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> > Hi all,
> >
> > I just sent out a patch that enables FreeSync in Mesa for the somewhat
> > hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
> > stack's DDX and k
On Tue, Oct 17, 2017 at 01:07:43PM +0200, Marek Szyprowski wrote:
> Dear all,
>
> This patchset performs complete rewrite of Exynos DRM IPP subsystem and
> its userspace API.
>
> Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
> general, but not really extensible on the other
Op 17-10-17 om 14:11 schreef Daniel Vetter:
> On Tue, Oct 17, 2017 at 07:20:47AM +0200, Maarten Lankhorst wrote:
>> Commit 669c9215afea ("drm/atomic: Make async plane update checks work as
>> intended, v2.") forced planes to always be tracked, but forgot to
>> explicitly get the crtc commit from th
2017-10-17 0:09 GMT+02:00 Laura Abbott :
> On 10/10/2017 02:11 AM, Mark Brown wrote:
>> On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
>>> On 10/09/2017 03:08 PM, Mark Brown wrote:
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>>
> Anyway, to move this forwar
On Sun, Oct 15, 2017 at 06:30:35PM +0200, Noralf Trønnes wrote:
> Make functions tolerate that the drm_fb_helper argument is NULL.
> This is useful for drivers that continue probing when fbdev emulation
> fails and not having to do this check themselves.
> Update docs for functions that already han
On Sun, Oct 15, 2017 at 06:30:38PM +0200, Noralf Trønnes wrote:
> This adds helpers for the drm_driver->last_close and the
> drm_mode_config_funcs->output_poll_changed callbacks.
>
> Signed-off-by: Noralf Trønnes
Definitely want a todo entry to roll these out to all drivers, but maybe
do a separ
On Sun, Oct 15, 2017 at 06:30:36PM +0200, Noralf Trønnes wrote:
> drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
> struct drm_device. This makes it possible to add callback helpers for
> .last_close and .output_poll_changed further reducing fbdev emulation
> footprint in dr
On Tue, Oct 17, 2017 at 02:25:07PM +0200, Lothar Waßmann wrote:
> Hi,
>
> On Tue, 17 Oct 2017 14:14:22 +0200 Thierry Reding wrote:
> > On Wed, Oct 11, 2017 at 01:23:36PM +0200, Lothar Waßmann wrote:
> > > The Ka-Ro electronics MB7 baseboard has an on-board LCD->LVDS
> > > converter that requires a
On Sun, Oct 15, 2017 at 06:30:37PM +0200, Noralf Trønnes wrote:
> This adds some simple init/fini helpers for drivers that don't need
> anything special in their fbdev emulation setup.
>
> Signed-off-by: Noralf Trønnes
So I know the saying goes that any design problem in IT can be solved by
addi
On Tue, Oct 17, 2017 at 02:13:37PM +0200, Lothar Waßmann wrote:
> Hi,
>
> On Tue, 17 Oct 2017 14:08:18 +0200 Thierry Reding wrote:
> > On Wed, Oct 11, 2017 at 01:23:33PM +0200, Lothar Waßmann wrote:
> > > Create a macro that eases the definition of display mode parameters by
> > > accecpting the p
On Sun, Oct 15, 2017 at 06:30:40PM +0200, Noralf Trønnes wrote:
> Add vmalloc buffer object helper that can be useful for modesetting
> drivers, particularly the framebuffer flushing kind.
>
> Signed-off-by: Noralf Trønnes
Why can't we extend the shmem stuff to provide a simple vmalloc helper?
D
On Tue, Oct 17, 2017 at 02:44:23PM +0200, Lothar Waßmann wrote:
> Hi,
>
> On Tue, 17 Oct 2017 14:12:40 +0200 Thierry Reding wrote:
> > On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote:
> > > The baseboards for the Ka-Ro electronics series of i.MX modules
> > > use a 24bit LCD interfa
On Sun, Oct 15, 2017 at 06:30:39PM +0200, Noralf Trønnes wrote:
> Add drm_gem_fb_debugfs_show() function to provide a debugfs
> representation of the framebuffer and GEM object(s).
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 45
>
On Tue, Oct 17, 2017 at 03:05:16PM +0200, Lothar Waßmann wrote:
> Hi,
>
> On Tue, 17 Oct 2017 14:09:37 +0200 Thierry Reding wrote:
> > On Wed, Oct 11, 2017 at 01:23:34PM +0200, Lothar Waßmann wrote:
> > > Use the newly defined macro to generate the display_mode data entries
> > > for all panels. T
https://bugs.freedesktop.org/show_bug.cgi?id=102820
--- Comment #13 from Alex Deucher ---
(In reply to dwagner from comment #11)
>
> This is the manufacturers page advertising my graphics board:
>
> http://www.xfxforce.com/en-us/products/amd-radeon-rx-400-series/rx-460-4gb-
> heatsink-rx-460p4h
On 17/10/17 01:04 PM, Nicolai Hähnle wrote:
> On 17.10.2017 12:28, Michel Dänzer wrote:
>> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
>>>
>>> Common sense suggests that there need to be two side to FreeSync / VESA
>>> Adaptive Sync support:
>>>
>>> 1. Query the display capabilities. This means que
On 17/10/17 02:22 PM, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
>> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
>
>>> Common sense suggests that there need to be two side to FreeSync / VESA
>>> Adaptive Sync support:
>>>
>>> 1. Query the display capabilit
Am 17.10.2017 um 15:46 schrieb Michel Dänzer:
On 17/10/17 02:22 PM, Daniel Vetter wrote:
[SNIP]
Finally I'm not sure we want to insist on a target time for freesync. At
least as far as I understand things you just want "as soon as possible".
This might change with some of the VK/EGL/GLX extensio
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> > On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> >
> >>> Common sense suggests that there need to be two side to FreeSync
On Tue, Oct 17, 2017 at 12:23:47PM +0800, Chen-Yu Tsai wrote:
> The display backend, as well as other peripherals that have a DRAM
> clock gate and access DRAM directly, bypassing the system bus,
> address the DRAM starting from 0x0, while physical addresses the
> system uses starts from 0x4000
On Tue, Oct 17, 2017 at 05:19:04PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > The commit da82b8785eeb ("drm/sun4i: add components in breadth first
> > traversal order") implemented a breadth first traversal of our device tree
> > nodes graph. However,
On Tue, Oct 17, 2017 at 05:14:47PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > Some options were not padded as they should, and the order in the Makefile
> > was chaotic. Fix that.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i
On Tue, Oct 17, 2017 at 05:21:09PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > The drm_display_mode pointer can be mark const, so let's do it.
> >
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Rip
On Tue, Oct 17, 2017 at 05:22:03PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > The drm_display_mode pointer can be mark const, so let's do it.
> >
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Rip
On Tue, Oct 17, 2017 at 05:28:42PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > So far, we've required all the TCON-connected encoders to call the TCON
> > enable and disable functions.
> >
> > This was made this way because in the RGB/LVDS case, the TCO
On Mon, Oct 16, 2017 at 8:17 PM, wrote:
> From: Frank Rowand
>
> This patch is aimed primarily at drivers/of/overlay.c, but those
> changes also have a small impact in a few other files.
>
> overlay.c is difficult to read and maintain. Improve readability:
> - Rename functions, types and vari
On Tue, Oct 17, 2017 at 05:56:47PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 17, 2017 at 5:06 PM, Maxime Ripard
> wrote:
> > Just like we did for the TCON enable and disable, for historical reasons we
> > used to rely on the encoders calling the TCON mode_set function, while the
> > CRTC has a call
Bootloader enabled display, when the driver is built-in (rather than a
module loaded after CCF/genpd disable "unused" clocks/powerdomains)
causes problems since the driver thinks the clocks are off, but in fact
they are on. This causes (for example) clk_set_rate() to fail.
A better solution would
On Tue, Oct 17, 2017 at 8:18 PM, Chen-Yu Tsai wrote:
> Various A10-based development boards have standard HDMI connectors
> wired to the dedicated HDMI pins on the SoC.
>
> Enable the display pipeline and HDMI output on boards I have or have
> access to schematics:
>
> - Cubieboard
> - Olimex
At least when they have vblank support they need to call this, or the
vblank core will happily call into their crtc->enable_vblank callback
even when the crtc is off. Which leads to a boom when the clocks are
off on most hardware (besides the inevitable confusion in the
book-keeping).
The consiste
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
> On 17/10/17 02:22 PM, Daniel Vetter wrote:
> > On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> >
> >>> Common sense suggests that there need to be two side to FreeSync
On Tue, Oct 17, 2017 at 04:59:39PM +0200, Daniel Vetter wrote:
> At least when they have vblank support they need to call this, or the
> vblank core will happily call into their crtc->enable_vblank callback
> even when the crtc is off. Which leads to a boom when the clocks are
> off on most hardwar
At least when they have vblank support they need to call this, or the
vblank core will happily call into their crtc->enable_vblank callback
even when the crtc is off. Which leads to a boom when the clocks are
off on most hardware (besides the inevitable confusion in the
book-keeping).
The consiste
On Tue, Oct 17, 2017 at 05:27:14PM +0200, Daniel Vetter wrote:
> At least when they have vblank support they need to call this, or the
> vblank core will happily call into their crtc->enable_vblank callback
> even when the crtc is off. Which leads to a boom when the clocks are
> off on most hardwar
On 17/10/17 05:04 PM, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
>>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
>>>
> Common sense sugges
On Mon, Oct 09, 2017 at 04:06:53PM +0800, Sandy Huang wrote:
> Some Rockchip CRTCs, like rv1108, can directly output parallel and
> serial RGB data to panel or conversion chip, so we add this driver to
> probe encoder and connector.
>
> Signed-off-by: Sandy Huang
> ---
> Changes in v3:
> update
On Mon, Oct 09, 2017 at 04:07:04PM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
>
> Documentation/devicetree/bindings/display/panel/panel-rgb.txt
>
> Signed-off-by: San
On Tue, Oct 17, 2017 at 12:33:09PM +0200, Matthias Brugger wrote:
> Hi Ulrich,
>
> On 10/16/2017 05:31 PM, Ulrich Hecht wrote:
> > Hi!
> >
> > This is a new revision of the Acer Chromebook R13 support series. It does
> > not offer anything new in terms of functionality, but eliminates three out
>
101 - 200 of 298 matches
Mail list logo
