Hello Russell,
On 08/24/2016 08:46 AM, Vladimir Zapolskiy wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI moni
Hi Sergei,
Thank you for the patch.
On Thursday 04 Aug 2016 15:01:02 Sergei Shtylyov wrote:
> Add support for the R8A7792 DU; it has 2 DPAD (RGB) outputs.
>
> Signed-off-by: Sergei Shtylyov
Acked-by: Laurent Pinchart
And applied to my tree.
> ---
> This patch is against the 'drm/next/du' br
Hi Sergei,
Thank you for the patch.
On Thursday 01 Sep 2016 22:04:59 Sergei Shtylyov wrote:
> The R-Car DU driver keeps a list of the external encoders which it uses
> to get the encoder type. Renesas Wheat board uses Analog Devices ADV7513
> HDMI encoder, unlike the other Renesas boards which
Am Freitag, 2. September 2016, 06:31:24 schrieb Lin Huang:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
>
> Signed-off-by: Lin Huang
> Signed-off-by: MyngJoo Ham
> Reviewed-by: Chanwoo Choi
> ---
[...]
> diff
On 1 September 2016 at 20:08, Christian Gmeiner
wrote:
> Hi Emil,
>
> thanks a lot for the review.
>
> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>> On 30 August 2016 at 08:14, Christian Gmeiner
>> wrote:
>>> From: The etnaviv authors
>>>
>>> Add the libdrm_etnaviv helper library to encapsulate e
On 1 September 2016 at 20:03, Harry Wentland wrote:
> Bumping this one up again. This patch is fairly contained and is a
> pre-requisite for drivers that want 4k at 60 mode support on HDMI.
>
Afaics Daniel Vetter replied ~4 months ago [1] with a link to a (imho)
more comprehensive series + a reque
Hey
On Mon, Aug 22, 2016 at 10:25 PM, Noralf Trønnes wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into
tch --base= (or --base=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160
ddr-frequency-scaling/20160902-063701
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/
This patch adds the documentation for rockchip rk3399 dmc driver.
Signed-off-by: Lin Huang
---
Changes in v8:
- add ddr timing properties
Changes in v7:
-None
Changes in v6:
-Add more detail in Documentation
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:
kernel
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
---
Changes in v8:
- delete a unuse blank line
Changes in v7:
- None
Changes in v6:
- None
Changes in v5:
- None
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
Changes in v
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Signed-off-by: MyungJoo Ham
Acked-by: Chanwoo Choi
---
Changes in v8:
-None
Changes in v7:
-access need to *4 to get right DDR loading
Changes in v6:
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
Signed-off-by: MyngJoo Ham
Reviewed-by: Chanwoo Choi
---
Changes in v8:
- do not use ddr_timing node, get ddr timing directly
Changes in v7:
- rem
when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not wo
01.09.2016, 23:40, "Maxime Ripard" :
> Hi everyone,
>
> This serie introduces the support in the sun4i-drm driver for the A33.
>
> Beside the new IPs and special cases for the A33 new IPs, there's
> nothing really outstanding, and is now at feature parity with the A13.
How can the driver be modi
Hi,
On Thu, Sep 1, 2016 at 11:32 PM, Maxime Ripard
wrote:
> The LCD output needs to be muxed. Add the proper pinctrl node.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.d
Hi Heiko,
On 2016ë
09ì 02ì¼ 08:17, Heiko Stübner wrote:
> Am Freitag, 2. September 2016, 06:31:24 schrieb Lin Huang:
>> base on dfi result, we do ddr frequency scaling, register
>> dmc driver to devfreq framework, and use simple-ondemand
>> policy.
>>
>> Signed-off-by: Lin Huang
>> Signed-o
On Thu, Sep 1, 2016 at 11:31 PM, Maxime Ripard
wrote:
> Some Allwinner SoCs, such as the A33, have a variation of the TCON that
> doesn't have a second channel (or it is not wired to anything).
>
> Make sure we can handle that case.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
https://bugzilla.kernel.org/show_bug.cgi?id=51381
RussianNeuroMancer changed:
What|Removed |Added
CC||russianneuromancer at ya.ru
--- Comm
Hi Linus,
This is a drm fixes pull for 4.8-rc5. Contains fixes for imx, amdgpu, vc4,
msm and one nouveau ACPI fix.
I've tried using a signed tag, let's see if works.
Dave.
The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:
Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)
On Fri, Sep 2, 2016 at 1:48 AM, David Herrmann wrote:
> So either the drm_simple_kms_helpers are buggy, or the SimpleDRM use
> of it. On DPMS updates, I get:
>
> Sep 02 01:00:39 david-t2 kernel:
> [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
> [CRTC:25:crtc-0] flip_done tim
ns
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/f5ec23fa/attachment-0001.sig>
Hi,
On 9/2/2016 2:13 AM, Sergei Shtylyov wrote:
> The Renesas Wheat board has 2 ADV7513 chips on the same I2C bus, however
> the ADV751x driver only supports 1 chip as it tries to assign the packet/
> EDID/CEC memory I2C devices to the fixed I2C addresses. Assign these I2C
> addresses at the fi
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/94efbcca/attachment.html>
top.org/archives/dri-devel/attachments/20160902/ff061272/attachment-0001.html>
Hey
On request of Noralf, I picked up the patches and prepared v5. Works fine with
Xorg, if configured according to:
https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
If anyone knows how to make Xorg pick it up dynamically without such a static
configuration, please let
The screen_info object was extended to support 64bit lfb_base addresses
in:
commit ae2ee627dc87a70910de91b791b3cd0e9c6facdd
Author: Matt Fleming
Date: Tue Aug 25 16:32:55 2015 +0100
efifb: Add support for 64-bit frame buffer addresses
However, the x86 simple-framebuffer se
The screen_info.lfb_size field is shifted by 16 bits *only* in case of
VBE. This has historical reasons since VBE advertised it similarly.
However, in case of EFI framebuffers, the size is no longer shifted. Fix
the x86 simple-framebuffer setup code to use the correct size in the
non-VBE case.
Whi
We already expose of_platform_device_create(), but give the caller no
chance to revert its effect. Make sure we also provide the counterpart
of_platform_device_destroy().
This requires a small refactoring, since so far the internal destructor
is used as iterator to for_each_device(), but we don't
There are several situations where we want hardware handover from an early
boot GFX driver (e.g., vgacon, vesafb, efifb, simplefb) to a full fletched
GFX driver (e.g., most DRM drivers). So far, we relied on
remove_conflicting_framebuffers() to do this for us, however, this had a
bunch of downsides
Switch over all DRM drivers to use the new sysfb_evict_conflicts()
infrastructure. The only non-trivial conversion is i915, since it does not
make use of the generic PCI resources, but assembles the apertures via
intel ggtt queries.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create dumb-buffers which can be blit into the real
framebuffer similar to UDL. No access to the real framebuffer i
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Makefile | 1 +
drivers/gpu/drm/simpledrm/simpledrm.h | 8 ++
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 13 +++
drive
On 8/31/2016 9:39 PM, Daniel Vetter wrote:
> We don't want to burry the bridge structures kerneldoc in drm_crtc.h.
>
> Cc: Archit Taneja
Reviewed-by: Archit Taneja
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms-helpers.rst | 7 ++
> drivers/gpu/drm/drm_bridge.c
On 8/31/2016 9:39 PM, Daniel Vetter wrote:
> Big thing is untangling and carefully documenting the different uapi
> types of planes. I also sprinkled a few more cross references around
> to make this easier to discover.
>
> As usual, remove the kerneldoc for internal functions which are not
> exp
Could you please help to confirm my question?
Thank you very much.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/7776d58c/attachment.html>
Hi,
On 8/30/2016 5:11 AM, John Stultz wrote:
> From: Andy Green
>
> Set the initial audio packet settings to allow the audio
> driver to work.
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Laurent Pinchart
> Cc: Wolfram Sang
> Cc: Srinivas Kandagatla
> Cc: "Ville Syrjälä"
> Cc: Boris Bre
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/7e91b3a4/attachment.html>
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> The screen_info object was extended to support 64bit lfb_base addresses
> in:
>
> commit ae2ee627dc87a70910de91b791b3cd0e9c6facdd
> Author: Matt Fleming
> Date: Tue Aug 25 16:32:55 2015 +0100
>
> efifb: Add support fo
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/1797ce77/attachment-0001.html>
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> The screen_info.lfb_size field is shifted by 16 bits *only* in case of
> VBE. This has historical reasons since VBE advertised it similarly.
> However, in case of EFI framebuffers, the size is no longer shifted. Fix
> the x86 simple-framebu
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> We already expose of_platform_device_create(), but give the caller no
> chance to revert its effect. Make sure we also provide the counterpart
> of_platform_device_destroy().
>
> This requires a small refactoring, since so far the internal
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> There are several situations where we want hardware handover from an early
> boot GFX driver (e.g., vgacon, vesafb, efifb, simplefb) to a full fletched
> GFX driver (e.g., most DRM drivers). So far, we relied on
> remove_conflicting_framebu
This is MT2701 DRM support PATCH v7, based on 4.8-rc1.
We add DSI interrupt control, transfer function for MIPI DSI panel support.
Most codes are the same, except some register changed.
For example:
- DISP_OVL address offset changed, color format definition changed.
- DISP_RDMA fifo size changed
Add MT8173 prefix for hardware related macros.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 60 +-
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
MIPI_TX pll setting changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT She
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 -
drivers/gpu/drm/mediatek/mtk_drm_ddp.
update connections for OVL, RDMA, BLS, DSI
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 1006
cleaning up unused define and refine function name and variable
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 77 --
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 8 ++--
2 files changed, 41 insertions(+), 44 deletio
From: shaoming chen
add dsi interrupt control
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4efeb38..
From: shaoming chen
add dsi read/write commands for transfer function
Signed-off-by: shaoming chen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 188 +
1 file changed, 188 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/
This patch update enable/disable flow of DSI module and MIPI TX module
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 102 +++--
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 32 ++-
2 files changed, 101 insertion
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +++
On 09/01/16 01:11, Kevin Hilman wrote:
> Hi Jyri,
>
> Jyri Sarha writes:
>
>> On 08/23/16 15:56, Karl Beldan wrote:
>>> Hi,
>>>
>>> I found some missing bits for rev1 of the LCDC and here are some of the
>>> changes I am using to use the DRM driver on an LCDCK (which has a rev1).
>>> 1/3 seems r
On Fri, Aug 26, 2016 at 04:27:41PM +0200, Marek Vasut wrote:
> Add DT bindings for new MXSFB driver using the DRM framework.
> The old MXSFB fbdev driver bindings are preserved in mxsfb.txt .
They should be documented in the same place as they describe the same
h/w. I've not looked how incompatib
Hey
On Fri, Sep 2, 2016 at 2:23 PM, Dmitry Vyukov wrote:
> On Mon, Aug 29, 2016 at 8:05 AM, Daniel Vetter wrote:
>> On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> The following program triggers WARNING in ioremap_wc:
>>
>> Yup, that should also be fixed in linu
On Fri, Sep 2, 2016 at 10:22 AM, David Herrmann
wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into the re
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/61db249e/attachment.html>
.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/168a47fa/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #43 from Alex Deucher ---
Is this still an issue with kernel 3.8? A bunch of PX fixes went into that
kernel.
--
You are receiving this mail because:
You are watching the assignee of the bug.
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/a1bdb6d2/attachment.html>
On Fri, Sep 2, 2016 at 11:31 AM, wrote:
>
> JiangBiao162664/user/zte_ltd Wrote 2016/08/31 10:27:34:
>
>> JiangBiao162664/user/zte_ltd
>> 2016/08/31 10:27
>>
>> From
>> Patrik Jakobsson ,
>> Re: [PATCH] drm/gma500: remove the process of stolen page in page
>> fault handler.
>>
>> Patrik Jakobsson
On Thu, May 26, 2016 at 3:53 AM, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 07:55:23PM +, Yang, Eric wrote:
>> Hi Thierry Reding,
>>
>> enum hdmi_picture_aspect {
>> > HDMI_PICTURE_ASPECT_NONE,
>> > HDMI_PICTURE_ASPECT_4_3,
>> > HDMI_PICTURE_ASPECT_16_9,
>> > + HDMI_P
Hi Tomeu,
On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
> +#ifdef CONFIG_DEBUG_FS
> + spin_lock_init(&crtc->crc.lock);
> + init_waitqueue_head(&crtc->crc.wq);
> + crtc->crc.source = kstrdup("auto", GFP_KERNEL);
Pedantic: kstrdup() can never fail ?
> +#endif
> +
> if (
On Thu, Sep 1, 2016 at 10:59 PM, Dave Airlie wrote:
>
> I've tried using a signed tag, let's see if works.
Worked fine.
But your email was once again marked as spam.
Google hates you, and your email habits.
Linus
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/269bfd9c/attachment.html>
Hi Tomeu,
IMHO it would be better to split out the refactoring into preparatory
patch. It brings a minor change which (not 100% sure on that) should
not cause issues but is worth pointing out.
On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
> +static int do_set_crc_source(struct drm_device *dev,
e of them. Also
can you explain why this needs to be exclusive to Tegra20 and Tegra30?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedeskt
kernel/+/de9295aabdb7f80555c9b77b29ac77bcdac3280b
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/17fd8b43/attachment.sig>
ening after they introduced mandatory Texture Streaming.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/55c93eeb/attachment-0001.html>
case the LLVM version difference between
the two setups?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/a5d8a5e2/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #34 from Kontantin Ivanov ---
Created attachment 231981
--> https://bugzilla.kernel.org/attachment.cgi?id=231981&action=edit
dmesg 4.8.0 rc4 radeon.uvd=0 radeon.dpm=0
--
You are receiving this mail because:
You are watching the as
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #35 from Kontantin Ivanov ---
Created attachment 231991
--> https://bugzilla.kernel.org/attachment.cgi?id=231991&action=edit
Xorg.0.log 4.8.0 rc4
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=153121
--- Comment #36 from Kontantin Ivanov ---
The card doesn't work with and without UVD. I've trying radeon.uvd=0 with
radeon.dpm=0. Firmware from git repository.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 2016-08-31 23:42, Meng Yi wrote:
> Hi Stefan,
>
> Could you test this patch on vf610, I think it will woks fine.
See comment below.
>
> When could you merge this path? And how about the patches for gamma
> correction and multi-layer support by the way?
Still need to look in those patches. I
The intent was to make sure people don't sneak in a small immediate or
something to change the interpretation of the uniform update args, but
these signals are just fine.
Fixes a validation failure in the current X server on some Render
operation.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/
ctrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160902/a1772678/attachment.sig>
Since using clk_register_divider to setup the pixel clock, regmap
is no longer used. Regmap did take care of DCU using different
endianness. Check endianness using the device-tree property
"big-endian" to determine the location of DIV_RATIO.
Cc: stable at vger.kernel.org
Fixes: 2d701449bce1 ("drm/
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #44 from Teofilis Martisius ---
Hi,
Last I tried it was 4.7. I removed my laptop from the quirks list and ATOMBIOS
stuck in loop message still happened.
I'll test this with 4.8-rc4 over the weekend.
Sincerely,
Teofilis
--
You are
Hi Meng, hi Mark,
[added Mark Brown to discuss the endian issue]
On 2016-07-15 01:50, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
>
> Signed-off-by: Meng Yi
> ---
> drivers/gpu/drm/fsl-dcu/Kc
Since this patch has been on hold for a little bit, I did a bit of
thinking of how we could this a little more cleanly. Unfortunately I
couldn't think of a way, however I did think of an alternative
solution:
I'm planning on backporting all of the skl wm fixes already, so I'm
going to use this pat
On Thu, Sep 1, 2016 at 11:32 PM, Maxime Ripard
wrote:
> The SinA33 has an unidentified panel. Add the timings for it under a new
> compatible.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> dif
Chromakey is a simple way of video overlay overlap implementation. This
patch adds 2 new IOCTL's: first - sets color key and is common across of
all Tegra SoC's, second - sets plane blending controls and allows to
utilize the color key, this one is exclusive to Tegra20/30.
Signed-off-by: Dmitry Os
Returning -EINVAL from a bool-returning function
phm_check_smc_update_required_for_display_configuration has an unexpected
effect of returning true, which is probably not what was intended.
Replace -EINVAL by false.
The only place this function is called from is
psm_adjust_power_state_dynamic in
d
Hi,
On Thu, Sep 1, 2016 at 11:31 PM, Maxime Ripard
wrote:
> The A33 has a significantly different pipeline, with components that differ
> too.
>
> Make sure we had compatible for them.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 +++
On 2016ë
09ì 02ì¼ 07:31, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v8:
> - delete a unuse blank line
>
> Changes in v7:
> - None
>
> Changes in v6:
> - None
>
> Changes in v5:
> - None
>
> C
On 2016ë
09ì 02ì¼ 07:31, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v8:
> - add ddr timing properties
>
> Changes in v7:
> -None
>
> Changes in v6:
> -Add more detail in Documentation
>
> Changes in
On Mon, Aug 29, 2016 at 8:05 AM, Daniel Vetter wrote:
> On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers WARNING in ioremap_wc:
>
> Yup, that should also be fixed in linux-next. Probably better to not
> report more for 4.8-rc kernels for
Hi,
On Thu, Sep 1, 2016 at 11:32 PM, Maxime Ripard
wrote:
> Add all the needed blocks to the A33 DTSI.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a33.dtsi | 184
> +++
> 1 file changed, 184 insertions(+)
>
> diff --git a/arch/arm/boot/d
Hi,
On Thu, Sep 1, 2016 at 11:32 PM, Maxime Ripard
wrote:
> The A33 pipeline also has some new components called SAT and DRC. Even
> though their exact features and programming model is not known (or
> documented), they need to be clocked for the pipeline to carry the video
> signal all the way.
On Tue, Aug 23, 2016 at 02:54:48PM +0200, Daniel Vetter wrote:
> Everyone knows them, except all the new folks joining from the ARM
> side haven't lived through all the pain of the past years and are
> entirely surprised when I raise this. Definitely time to document
> this.
Thanks for re-iteratin
92 matches
Mail list logo
