ardcoded for each partner card?
Can it be done on Linux too?
--
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/7660e8c7/attachment.html>
---
I get bug updates via the mailing list.
--
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/f6307680/attachment-0
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/
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
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
org/archives/dri-devel/attachments/20160901/0d885d0f/attachment.html>
itor is my main screen, it would mean I have to work for 1
week or so without it.
--
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
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
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
#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>
Hi Stefan,
Could you test this patch on vf610, I think it will woks fine.
When could you merge this path? And how about the patches for gamma correction
and multi-layer support by the way?
Best Regards,
Meng
> > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > > b/drivers/gpu/drm/f
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
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
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
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>
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>
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
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160901/2b4bc660/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=100871
Reg changed:
What|Removed |Added
CC||reg at regproctor.com
--- Comment #11 from Reg --
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
--- 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
å¾æç 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
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>
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
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
> ---
>
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
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
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
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
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
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 -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
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
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-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.
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,
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
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/
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
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
>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/fced9ec0/attachment.html>
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
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
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,
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
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 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
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:
-
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),
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
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
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
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
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
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
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
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>
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
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
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:/
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
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
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 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
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 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 +
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
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
pe: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160901/50fb977c/attachment-0001.sig>
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
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
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>
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>
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>
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
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
>
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
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
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
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
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
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
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/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
---
.../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
---
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
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/disp
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
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
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/displays/connector-dvi.c | 5 ++---
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 5 +++--
.../drm/omapdrm/displays/pan
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
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
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
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/
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-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.
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
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/
1 - 100 of 108 matches
Mail list logo
