Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
On Thu, Sep 8, 2016 at 8:17 PM, Maxime Ripard
wrote:
> Now that we have support for the VGA bridges using our DRM driver, enable
> the display engine for the Olimex A13-Olinuxino.
>
> Signed-off-by: Maxime Ripard
Assuming the bridge bindings are good,
Acked-by: Chen-Yu Tsai
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/30555701/attachment.html>
When adding an extra argument to a function, one really should try a bit
harder to catch *all* the callers...
CC: Marek Szyprowski
CC: Inki Dae
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Robin Murphy
---
Ideally, this should be squashed into "iommu/dma: Avoid PCI
Issue hot-plug detection, EDID update, and ELD update notifications
from DP drivers.
Signed-off-by: Chris Zhong
---
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
Hi all
This series patch is for rockchip Type-C DisplayPort controller driver.
The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data
so far.
--
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/20160909/da1f679e/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/193596a2/attachment.html>
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/f770ec38/attachment.html>
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/6b0e0823/attachment-0001.html>
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Update commit message
- Add DP_TIMEOUT_PSR_LOOP_MS marcos
- Correct the return val
Signed-off-by: Yakir Yang
---
Changes in v3:
- Suggested by Sean
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/
ML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/17ec3061/attachment.html>
David,
Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
with SHA1 3e980591945eadbfdf4cbc05d56e5f44010a5a87.
This adds the ASoC codec interfaces for TDA998x HDMI audio from
Jyri Sarha.
T
On 09/08/2016 10:12 PM, Sean Paul wrote:
> On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang wrote:
>> Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
>> function, or printing the error Sink PSR state if we failed to effect
>> the request PSR setting.
>>
>
> Let's change to:
>
and alibaba.
Maxime
--
Maxime Ripard, Free Electrons
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://lis
t this point.
Maxime
--
Maxime Ripard, Free Electrons
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/20160909/d72d8656/attachment.sig>
Am 09.09.2016 um 15:54 schrieb Emil Velikov:
> On 9 September 2016 at 12:24, Christian König
> wrote:
>> Hi Hawking,
>>
>>> Removing the flag will make ttm_mem_type_from_place skip counting the
>>> corresponding placement and thus have impact on mem region create and bo
>>> movement.
>> And that
On Fri, 2016-09-09 at 12:09 +0300, Ville Syrjälä wrote:
> On Fri, Sep 09, 2016 at 10:45:27AM +0300, Mika Kahola wrote:
> >
> > On Thu, 2016-09-08 at 15:48 +0300, Ville Syrjälä wrote:
> > >
> > > On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> > > >
> > > >
> > > > Respect max
Am 09.09.2016 um 15:41 schrieb Deucher, Alexander:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Christian König
>> Sent: Friday, September 09, 2016 7:24 AM
>> To: Zhang, Hawking; Koenig, Christian; Cui, Flora; Zhou, David(ChunMing
On 9 September 2016 at 15:30, Christian König
wrote:
> Am 09.09.2016 um 15:54 schrieb Emil Velikov:
>>
>> On 9 September 2016 at 12:24, Christian König
>> wrote:
>>>
>>> Hi Hawking,
>>>
Removing the flag will make ttm_mem_type_from_place skip counting the
corresponding placement and
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/bd43a96d/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/4e025e1e/attachment.html>
yes. please don't do this, I need them.
On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
>
>
> On 2016å¹´09æ08æ¥ 21:41, Christian König wrote:
> >From: Christian König
> >
> >Either never used or not used in quite a while.
> No, I remember Flora's Direct GMA is using them like GDS
On 9 September 2016 at 12:24, Christian König
wrote:
> Hi Hawking,
>
>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and bo
>> movement.
>
> And that is exactly the reason why I want to remove the unuse
On 2016å¹´09æ08æ¥ 21:41, Christian König wrote:
> From: Christian König
>
> Makes more sense to keep that together.
>
> Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
> ---
> include/drm/ttm/ttm_bo_api.h| 32 +---
> include/drm/ttm/ttm_placem
On 2016å¹´09æ08æ¥ 21:41, Christian König wrote:
> From: Christian König
>
> Either never used or not used in quite a while.
No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2.
And you cannot make sure there isn't no one using them in other closed
projects, right?
If you
https://bugzilla.kernel.org/show_bug.cgi?id=119831
Peter Wu changed:
What|Removed |Added
CC||peter at lekensteyn.nl
--- Comment #15 from P
Respect max TMDS clock frequency from DPCD for active
DP to HDMI adapters.
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
2 files changed, 30 insertions(+)
diff --git a/driver
Read DisplayPort branch device info from through debugfs
interface.
v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to m
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.
v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v3: Fill bpc for connector's display info in separate
drm_dp_helper function
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
v2: DPCD read outs and c
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register fields 0x50A
and 0x50B.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print SW revision inf
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.
v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print HW revision info to dmesg
Let's remove reference to "struct intel_connector *connector"
in intel_dp_aux_init() function as it is no longer required.
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
Read DisplayPort branch device id string.
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 12
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_he
Helper routine to read out maximum supported bits per
component for DisplayPort legay converters.
v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper
Helper routine to read out maximum supported pixel rate
for DisplayPort legay VGA converter or TMDS clock rate
for other digital legacy converters. The helper returns
clock rate in kHz.
v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)
Drop "VGA" from bits per component definitions as these
are also used by other standards such as DVI, HDMI,
DP++.
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
include/drm/drm_dp_helper.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_dp_h
Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.
Reviewed-by: Jim Bride
Signed-off-by: Mika Kahola
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
i
Prep work for DP branch device handling
This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards
- DP to VGA
- DP to DVI
- DP to HDMI
- DP++ dual mode
- Wireless WiGig
DPCD register d
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 5, 2016 at 2:46 PM, Jussi Kukkonen
wrote:
> Add --with-cunit to make it easier to do reproducible builds. Default
> is still to probe cunit and build opportunistically.
>
> Signed-off-by: Jussi Kukkonen
> ---
> configure.ac | 14 --
>
Hi Laurent,
I plan to take this patch in my pull request that will be done next week.
BR
Vincent
On 09/08/2016 04:44 PM, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Lau
Hello,
The following program triggers GPF in drm_getcap:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int fd = open("/dev/dri/card0", O_RDONLY);
uint64_t data[2] = {0x11, 0x80};
On 8 September 2016 at 10:56, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 10:35:17 AM CEST Emil Velikov wrote:
>> On 7 September 2016 at 12:05, Baoyou Xie wrote:
>> > We get 2 warnings when building kernel with W=1:
>> As you're going through DRM I was wondering if you have a rough numb
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Friday, September 09, 2016 7:24 AM
> To: Zhang, Hawking; Koenig, Christian; Cui, Flora; Zhou, David(ChunMing);
> amd-gfx at lists.freedesktop.org
> Cc: dri-devel at
On 09/09/16 13:20, Deucher, Alexander wrote:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Friday, September 09, 2016 4:16 AM
>> To: Mark Fortescue; Koenig, Christian; David Airlie
>> Cc: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
>> devel at lists.freedesktop.org
Hi Hawking,
> Removing the flag will make ttm_mem_type_from_place skip counting the
> corresponding placement and thus have impact on mem region create and bo
> movement.
And that is exactly the reason why I want to remove the unused flags.
> There is no guarantee that amdgpu would never introd
> -Original Message-
> From: Koenig, Christian
> Sent: Friday, September 09, 2016 4:16 AM
> To: Mark Fortescue; Koenig, Christian; David Airlie
> Cc: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 001/001] drivers/gpu/radeon:
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/20160909/2c9d8e6d/attachment.html>
ure
Size: 800 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/4499cdcd/attachment.sig>
On Fri, Sep 09, 2016 at 10:45:27AM +0300, Mika Kahola wrote:
> On Thu, 2016-09-08 at 15:48 +0300, Ville Syrjälä wrote:
> > On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> > >
> > > Respect max TMDS clock frequency from DPCD for active
> > > DP to HDMI adapters.
> > >
> > > Signed
Hi Fabien,
On Friday 19 Aug 2016 11:01:37 Fabien DESSENNE wrote:
> Hi Laurent,
>
> Daniel talked about a planned reorg from you around DRM formats (or
> something like this) and I have proposed to fix some missing parts with
> the XRGB444 formats.
>
> Can you let us know if you can consider this
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong v
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
b
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
Signed-off-by: Tomeu Vizo
Hi,
this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.
The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.
Other drivers fo
From: Ray Strode
The qxl driver currently destroys and recreates the
qxl "primary" any time the first crtc is set.
A side-effect of destroying the primary is mouse state
associated with the crtc is lost, which leads to
disappearing mouse cursors on wayland sessions.
This commit changes the driv
In this case please just add them back in your tree. That should be a
two liner.
For upstream it certainly doesn't make sense to keep them.
Regards,
Christian.
Am 09.09.2016 um 09:01 schrieb Flora Cui:
> yes. please don't do this, I need them.
>
> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhouc
On Thu, 2016-09-08 at 15:48 +0300, Ville Syrjälä wrote:
> On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> >
> > Respect max TMDS clock frequency from DPCD for active
> > DP to HDMI adapters.
> >
> > Signed-off-by: Mika Kahola
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h  |Â
Hi Chris,
Removing the flag will make ttm_mem_type_from_place skip counting the
corresponding placement and thus have impact on mem region create and bo
movement. There is no guarantee that amdgpu would never introduce new memory
domain in future. In such case, I'd like to vote for keeping thes
Am Donnerstag, den 08.09.2016, 18:36 -0700 schrieb Stephen Boyd:
> These GPU drivers only depend on the RESET_CONTROLLER config
> option to fix build issues that existed when there weren't stub
> reset APIs for reset controller consumers. Given that these
> drivers aren't providing any reset contro
Hi Chris,
Removing the flag will make ttm_mem_type_from_place skip counting the
corresponding placement and thus have impact on mem region create and bo
movement. There is no guarantee that amdgpu would never introduce new memory
domain in future. In such case, I'd like to vote for keeping thes
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/4fb85d99/attachment.html>
On 09/09/16 01:23 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
>> On 09/08/2016 08:30 AM, Chris Wilson wrote:
>>> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
amdgpu-kms uses shared fences for its prime exported dmabufs,
instea
>> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
>> interface and DP-2 is a DVI interface (which I can connect to my
>> monitor if testing this is useful). There are no displayport connectors.
>
> Yeah, but from the driver point of view there are only DP connectors on
> the chi
On Fri, Sep 09, 2016 at 02:10:57PM +0300, Mika Kahola wrote:
> Read DisplayPort branch device info from through debugfs
> interface.
>
> v2: use drm_dp_helper routines to collect data
> v3: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v4: move DP branch de
On Fri, Sep 09, 2016 at 02:10:56PM +0300, Mika Kahola wrote:
> DisplayPort branch device may define max supported bits per
> component. Update display info based on this value if bpc
> is defined.
>
> v2: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v3: Fi
On Fri, Sep 09, 2016 at 02:10:54PM +0300, Mika Kahola wrote:
> SW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register fields 0x50A
> and 0x50B.
>
> v2: move drm_dp_ds_revision structure to be part of
> drm_dp_link structure (Daniel)
> v3: remove depen
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/1b3a19c5/attachment.html>
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/20160909/75d135ff/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/ed955f15/attachment.html>
is 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/20160909/c6286ffb/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/48d0b071/attachment.html>
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/9bd9bd63/attachment.html>
ktop.org/archives/dri-devel/attachments/20160909/70e6dd7b/attachment.html>
Sep 8 18:21:04 2016 +0200
Revert "radeonsi: enable SDMA on CIK"
--
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/attach
vel/attachments/20160909/b5cc6e1e/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/b1e59f8b/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/ca565461/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/20160909/850172e1/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/ad62e922/attachment-0001.html>
||
--
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/20160909/9b331b2a/attachment.html>
85 matches
Mail list logo
