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 fixed offsets (derived from the programming guide) from
the
Hi Dave,
Please pull these collected fixes from various sources.
Thanks,
Jyri
The following changes since commit 2b2fd56d7e92f134ecaae5c89e20f64dd0f95aa2:
Revert "drm: make DRI1 drivers depend on BROKEN" (2016-09-01 06:16:12
+1000)
are available in the git repository at:
https://github.com
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 all use ADV7511W --
add it to the encoder list.
Signed-off-by: Sergei Shtylyov
---
This patch is
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 etnaviv-specific
>> interfaces to the DRM.
>>
>> Signed-off-by: Chris
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/8eccfcc2/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/58d1d1d5/attachment.html>
e of
> getting this patch into the kernel?
>
> If anyone is willing to write a fix, as opposed to a workaround, for this
> issue, I would be happy to test it on my device.
Yeah, no, that didn't help a bit.
--
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/20160901/f53debc3/attachment.html>
Add HDMI support on IFC6410. Populate the regulators required by HDMI-TX
and PHY. Establish the link between the MDP4 DTV encoder and HDMI. Create
a generic micro HDMI connector DT node. The msm drm driver doesn't parse
for HDMI connectors in DT, but it will do so later.
Cc: Rob Herring
Cc: devic
APQ8064 contains a MDP4 based display controller. It contains a HDMI, LVDS
and 2 DSI outputs.
Add display DT nodes for MDP4, HDMI TX and HDMI PHY. MDP4 based display
blocks have a flat device hierarchy.
Nodes for other outputs will be added later.
Cc: Rob Herring
Cc: devicetree at vger.kernel.o
Make the following changes in the HDMI gpio bindings:
- Use "-gpios" as the suffix for all the gpio names
- Move all the gpios to optional, since there are platforms that use none
of them.
- The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
it.
- Add a missing lpm gpio use
The LVDS port is the first in the list of the output ports in MDP4.
The driver assumed that if the port and its corresponding endpoint
is defined, then there should be a panel node too. This isn't
necessary since boards may not really use a LVDS panel. Don't fail
if there isn't a panel node availab
This set adds the display DT parts for the APQ8064 based IFC6410 board.
There were a couple of small fixes/cleanups required in the driver to
use the correct bindings. Those are a part of this patchset too.
Changes in v2:
- Incorporated comments on HDMI gpio bindings as suggested by Rob H.
Archit
pe: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/50fb977c/attachment-0001.sig>
Enable the display pipeline with the associated 7" panel sold with the
SinA33.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
b/arch/ar
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.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 5f9dbd17eb50..d5f93c05846f 10
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/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index deb0cd613e97..5f9d
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(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel
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.
Add minimal drivers for those that just claim the needed resources
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 ++-
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
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
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 34 +-
drivers/gpu/drm
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.
This serie is based on my A33 CCU patches posted earlier today here:
http:/
Fix property handling for mode object without mode object type.
drm_property_change_valid_get() crashes if atomic ioctl for mode
object does not specify the mode object type. This patch makes
drm_property_change_valid_get() to tolerate such requests.
Signed-off-by: Jyri Sarha
---
This used to wo
å¾æç iPad å³é
Thank you
> Andrzej Hajda æ¼ 2016å¹´9æ1æ¥ ä¸å3:04
> 寫éï¼
>
>> On 08/31/2016 07:55 PM, ayaka wrote:
>>
>>> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>>> Hi,
>>>
>>>
On 08/30/2016 12:50 AM, Randy Li wrote:
It is actually a lvds panel connected th
On 1 September 2016 at 02:48, Nicolas Boichat wrote:
> From: Daniel Kurtz
>
> There is a mediatek drm kms driver: Add "mediatek" to the static
> lists of driver names.
>
Pushed as well as the modetest patch. Thanks !
Can I interest you in adding support for platform devices in the DRM
device API
On 09/01/2016 02:00 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Wednesday 31 Aug 2016 22:24:30 Archit Taneja wrote:
>> On 8/31/2016 9:23 PM, Laurent Pinchart wrote:
>>> On Wednesday 31 Aug 2016 16:22:09 Archit Taneja wrote:
ADV7533 requires supply to the AVDD, V1P2 and V3P3 pins for prop
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.
-Harry
On 2016-05-13 06:44 PM, Eric Yang wrote:
> This patch expand the cea861 mode timing table to include vic 65
> to 107. This allows more modes to be reported
s are picked and why
things are failing. It's worth adding some of that in the report.
--
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/a
Various cleanups to the DRM core initialization and exit handlers:
- Register chrdev last: Once register_chrdev() returns, open() will
succeed on the given chrdevs. This is usually not an issue, as no
chardevs are registered, yet. However, nodes can be created by
user-space via mknod(2),
The drm_core.h header contains a set of constants meant to be used
throughout DRM. However, as it turns out, they're each used just once and
don't bring any benefit. They're also grossly mis-named and lack
name-spacing. This patch inlines them, or moves them into drm_internal.h
as appropriate:
-
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of
We don't want anyone but legacy DRM1 code to use drm_file.filp. Especially
for in-kernel contexts, this might be set to NULL, so lets make sure
no-one accesses it, ever.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_bufs.c | 7 ---
drivers/gpu/drm/drm_fops.c | 2 +-
include/drm/drmP.
Rather than using "struct file*", use "struct drm_file*" as tag VM tag for
BOs. This will pave the way for "struct drm_file*" without any "struct
file*" back-pointer.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/ast/ast_ttm.c | 3
Each DRM file-context caches the EUID of the process that opened the file.
It is used exclusively for debugging purposes in /proc/dri/ and friends.
Note, however, that we can already fetch the EUID from
priv->pid->task->creds. The pointer-chasing will not hurt us, since it is
only about debugging,
Hey
The remaining cleanup patches pending on dri-devel in one batch. Random cleanups
all over the place. Should all be straightforward.
Thanks
David
David Herrmann (6):
drm: remove redundant drm_file->uid
drm: use drm_file to tag vm-bos
drm: rename drm_file.filp to drm_file.legacy_filp
d
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
The DE is active low according to the documentation.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 5 +
1 fi
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/d
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.
The code will be easier to follow if we use consistent names.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/connector-dv
omap_video_timings can be replaced with the generic videomode in omapdrm
and the omap_video_timings can be removed.
This patch will replace the omap_video_timings with videomode.
With the change we no longer need the functions to convert to/from
videomode and drm_display_mode to omap_video_timings
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: Peter Ujfalusi
---
driv
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 5 ++---
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 5 +++--
.../drm/omapdrm/displays/pan
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 3 +--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 3 +--
.../gpu/drm/omapdrm/displays
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 6 +++---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
drivers/gpu
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 ++--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 +-
.../drm/omapdrm/displays/panel-lgp
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 +--
drivers/gpu/drm/omapdrm/displays/connecto
Instead of passing the omap_video_timings structure's members individually,
use the pointer to the struct.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 38 ++---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu
Remove the interlace member and add display_flags to omap_video_timings to
configure the interlace mode.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 --
drivers/gpu/drm/omapdrm/dss/dis
By using a pointer to the omap_vode_timings struct we can unwrap lines to
make the code easier to follow.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 47 ++--
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/disp
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/disp
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 2 +-
drivers/gpu/drm/omapdrm/
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays/con
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/di
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays/conne
Configure the DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE flags according to the
binding document.
If the syncclk-active is present in DT, configure the flags accordingly, if
it is omitted it means that the SYNC edge is following the pixdata
configuration.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC
The sync can be - and for some panels it must be - driven on different edge
then the data.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC: Mark Rutland
CC: devicetree at vger.kernel.org
---
include/video/display_timing.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/video/d
There are display panels which demands that the sync signal is driven on
different edge than the pixel data.
With the syncclk-active property we can specify the clk edge to be used to
drive the sync signal. When the property is missing it indicates that the
sync is driven on the same edge as the pi
Hi,
The following series will convert the omapdrm stack to use the generic videmode
instead of the private omap_video_timings struct for the panel information.
Since we have several panels under omapdrm/displays/ where the data drive edge
is set to be different then the sync drive edge, the first
enGL version
--
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/20160901/7e5536f8/attachment-0001.html>
The KMS helpers (drm_atomic_helper_check_modeset/mode_fixup) pass
encoder->bridge directly to drm_bridge_mode_fixup, which expects a
valid pointer, or NULL (in which case it just returns).
Clear encoder->bridge if a bridge is not found, instead of keeping
the ERR_PTR value.
Since other drm_bridge
Am Montag, 22. August 2016, 11:36:19 schrieb Lin Huang:
> add ddrc clock setting, so we can do ddr frequency
> scaling on rk3399 platform in future.
>
> Signed-off-by: Lin Huang
applied to my clk-branch for 4.9
Thanks
Heiko
Hi Maarten,
2016-09-01 Maarten Lankhorst :
> Op 31-08-16 om 21:07 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > There is now a new property called FENCE_FD attached to every plane
> > state that receives the sync_file fd from userspace via the atomic commit
> > IOCTL.
> >
> > The fd
Add blue-and-red-wiring -property to lcdc node. The am335x-evmsk has
blue and red wires crossed to get 24-bit RGB (and 16-bit BGR)
support. After this patch am335x-evmsk supports BGR565, RGB888, and
XRGB color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
Whitespace cleanup of lcdc related nodes. Do all indentation and
alignment with tabs instead of spaces.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-evmsk.dts | 40 +++---
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/
Add blue-and-red-wiring -property to lcdc node. The am335x-evm has
blue and red wires crossed to get 24-bit RGB (and 16-bit BGR)
support. After this patch am335x-evm supports BGR565, RGB888, and
XRGB color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
Sig
Add blue-and-red-wiring -property to LCDC node. Also adds comments on
how to get support 24 bit RGB mode. After this patch am335x-boneblack
support RGB565, BGR888, and XBGR color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
The BBB has straight color wir
Choose console BPP that supports RGB and remove the old fbdev bpp
selection code. LCDC on AM335x has red and blue wires switched between
24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16
bit format is wired for BGR. drm_fbdev_cma_init() does not currently
like anything else but
Add "blue-and-red-wiring"-device tree property and update devicetree
binding document.
The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the red and blue
wires has to be crossed and this in turn causes 16 colors output to be
in BG
Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC
drm_helper_disable_unused_functions() should not be called by atomic
drivers.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3404d24..e45c268 1
Changes since v3:
- "drm/tilcdc: Write DMA base and ceiling address with single instruction"
- Adjust comments, no functional changes
- "drm/tilcdc: Add blue-and-red-crossed devicetree property"
- Remove "default" from recognized property values
- Clean up commit description
- "ARM: dts: am33
Hi,
On 29 August 2016 at 15:49, Daniel Vetter wrote:
> It's deprecated and only should be used by drivers which still use
> drm_platform_init, not by anyone else.
>
> And indeed it's entirely unused and can be nuked.
>
> This required a bit more fudging, but I guess kirin_dc_ops really
> wants to
Hi,
Am Montag, 22. August 2016, 11:36:23 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
> Reviewed-by: Chanwoo Choi
> ---
[...]
> diff --git a/drivers/devfreq/rk33
Am Montag, 22. August 2016, 11:36:17 schrieb Lin Huang:
> On new rockchip platform(rk3399 etc), there have dcf controller to
> do ddr frequency scaling, and this controller will implement in
> arm-trust-firmware. We add a special clock-type to handle that.
>
> Signed-off-by: Lin Huang
Applied wi
Hi,
On 26 August 2016 at 10:28, Rob Clark wrote:
> On Thu, Aug 25, 2016 at 9:48 PM, Xinliang Liu
> wrote:
>> On 17 August 2016 at 19:11, Daniel Vetter wrote:
>>> On Wed, Aug 17, 2016 at 07:02:01PM +0800, Xinliang Liu wrote:
Hi,
On 17 August 2016 at 18:17, Daniel Vetter
wr
On 31/08/16 17:09, Daniel Vetter wrote:
> Again move it from the unmaintainable csv into DOC free-form overview
> sections.
>
> Cc: Lionel Landwerlin
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst| 12 +
> Documentation/gpu/kms-properties.csv | 5
>
Hi Vinod,
Thanks for reviewing.
On Tue, 30 Aug 2016, Vinod Koul wrote:
> On Fri, Aug 26, 2016 at 03:56:40PM +0100, Peter Griffin wrote:
>
> > config STM32_DMA
> > bool "STMicroelectronics STM32 DMA support"
> > depends on ARCH_STM32
> > @@ -567,7 +580,6 @@ config ZX_DMA
> > help
>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160901/2b4bc660/attachment.sig>
On 09/01/2016 10:24 AM, Ayaka wrote:
>
> å¾æç iPad å³é
> Thank you
>> Andrzej Hajda æ¼ 2016å¹´9æ1æ¥ ä¸å3:04
>> 寫éï¼
>>
>>> On 08/31/2016 07:55 PM, ayaka wrote:
>>>
On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
Hi,
> On 08/30/2016 12:50 AM, Randy Li wrote
anged, 310 insertions(+), 248 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_color_mgmt.c
> create mode 100644 include/drm/drm_color_mgmt.h
Acked-by: Lionel Landwerlin
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/fced9ec0/attachment.html>
On Thu, Sep 01, 2016 at 09:41:35AM +0200, Tomeu Vizoso wrote:
> Also provide some pointers for building IGT as some kernel hackers might
> not be that familiar with building stuff on Linux distros.
>
> Signed-off-by: Tomeu Vizoso
> Cc: Daniel Vetter
Applied to drm-misc, thanks.
-Daniel
> ---
>
www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
Aside the few minor comments I had, for the series:
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/fe9e5753/attachment-0001.sig>
text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/100b5bb2/attachment.sig>
On 09/01/16 10:13, Tomi Valkeinen wrote:
> On 31/08/16 16:14, Jyri Sarha wrote:
>> Write DMA base and ceiling address with a single instruction, if
>> available. This should make it more unlikely that LCDC would fetch the
>> DMA addresses in the middle of an update. Having bad combination of
>> add
od to have the register names mentioned in the
above comment. Otherwise I can imagine grepping for CEILING_ADDR, and
not finding it set anywhere in the driver...
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Si
ute part or whole of this message
without written permission.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/6fe7ec5a/attachment.html>
#x27;ve picked this up for 4.9.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/ea068edd/attachment.sig>
From: Daniel Kurtz
There is a mediatek drm kms driver: Add "mediatek" to the static
lists of driver names.
Signed-off-by: Daniel Kurtz
Signed-off-by: JB Tsai
Signed-off-by: Nicolas Boichat
---
tests/util/kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/kms.c b/tests/util/
Also provide some pointers for building IGT as some kernel hackers might
not be that familiar with building stuff on Linux distros.
Signed-off-by: Tomeu Vizoso
Cc: Daniel Vetter
---
Documentation/gpu/drm-uapi.rst | 37 +
1 file changed, 37 insertions(+)
diff
On Wed, Aug 31, 2016 at 10:45 PM, Stéphane Marchesin
wrote:
> This can be useful for debugging. xrandr prints it, so why not.
> ---
> tests/modetest/modetest.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Alex Deucher
>
> diff --git a/tests/modetest/modetest.c b/t
On 08/31/2016 07:55 PM, ayaka wrote:
>
> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>> Hi,
>>
>>
>> On 08/30/2016 12:50 AM, Randy Li wrote:
>>> It is actually a lvds panel connected through a rga-lvds bridge.
>>> But I really have no idea about what does a port mean in fimd node.
>>>
>>> Also how
On Thu, Sep 1, 2016 at 3:22 AM, Haixia Shi wrote:
> Daniel
>
> Thanks! I agree the PATCH 1/2 needs some more work.
>
> What do you think about the PATCH 2/2 (suspend/resume) -- would it
> make sense to review it as a single standalone patch?
Sure, but I have no clue about usb or udl-specific issu
Op 31-08-16 om 21:07 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> There is now a new property called FENCE_FD attached to every plane
> state that receives the sync_file fd from userspace via the atomic commit
> IOCTL.
>
> The fd is then translated to a fence (that may be a fence_collectio
https://bugzilla.kernel.org/show_bug.cgi?id=100871
--- Comment #13 from Reg ---
Created attachment 231671
--> https://bugzilla.kernel.org/attachment.cgi?id=231671&action=edit
Xorg.0.log - All 6 screens good kernel-3.16.7-35-default
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=100871
--- Comment #12 from Reg ---
Created attachment 231661
--> https://bugzilla.kernel.org/attachment.cgi?id=231661&action=edit
dmsg - All 6 screens good kernel-3.16.7-35-default
--
You are receiving this mail because:
You are watching the assign
https://bugzilla.kernel.org/show_bug.cgi?id=100871
Reg changed:
What|Removed |Added
CC||reg at regproctor.com
--- Comment #11 from Reg --
1 - 100 of 108 matches
Mail list logo
