Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 31352 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/c38fe047/attachment-0001.obj>
inliang Liu
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 51365 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/01faa652/attachment-0001.obj>
.gz
Type: application/octet-stream
Size: 21001 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/72dc1d97/attachment-0001.obj>
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
---
Changes in v6:
- none
Changes in v5:
- delete unuse mux_flag
- use div_f
Signed-off-by: Lin Huang
---
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
include/dt-bindings/clock/rk3399-cru.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clock/rk3399-cru.h
b/inc
add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.
Signed-off-by: Lin Huang
---
Changes in v6:
- None
Changes in v5:
- fit for the ddr type
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list
Cha
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
---
Changes in v6:
- fix some nit suggest by Chanwoo Choi
Changes in v5:
- improve dmc driver suggest by Chanwoo Choi
Ch
Hi Lin,
I add the additional comment.
On 2016ë
08ì 17ì¼ 09:31, Chanwoo Choi wrote:
> Hi Lin,
>
> I add one minor comment.
>
> After fixing it, looks good to me.
> Acked-by: Chanwoo Choi
>
> On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
>> This patch adds the documentation for rockchip d
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
Hi Lin,
I add one minor comment.
After fixing it, looks good to me.
Acked-by: Chanwoo Choi
On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v6:
> -None
>
> Changes in v5:
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
---
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
.../bindings/devfreq/event/rockchip-dfi.txt | 20 +++
Hi Lin,
I add just one comment to remove the blank line.
On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
> 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
> --
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
Acked-by: Chanwoo Choi
---
Changes in v6:
-None
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
This patch adds the documentation for rockchip rk3399 dmc driver.
Signed-off-by: Lin Huang
---
Changes in v6:
-Add more detail in Documentation
Changes in v5:
-None
Changes in v4:
-None
Changes in v3:
-None
Changes in v2:
-None
Changes in v1:
-None
.../devicetree/bindings/devfreq/rk3399_dm
when in ddr frequency scaling process, vop can not do
enable or disable operation, since dcf will base on vop vblank
time to do frequency scaling and need to get vop irq if there
have vop enabled. So need register to devfreq notifier, and we can
get the dmc status. Also, when there have two vop ena
On 08/17/2016 09:11 AM, Sean Paul wrote:
> This patch converts the psr_list_mutex to a spinlock and locks
> all access to psr_list to avoid races (however unlikely they
> were).
>
> Signed-off-by: Sean Paul
Reviewed-by: Yakir Yang
> ---
>
> Changes in v2:
> - Rebased on
> https://cgit.fre
On 08/17/2016 09:11 AM, Sean Paul wrote:
> The delayed worker isn't needed and is racey. Remove it and do
> the state change in line.
>
> Signed-off-by: Sean Paul
Reviewed-by: Yakir Yang
Tested-by: Yakir Yang
> ---
>
> Changes in v2:
> - Rebased on
> https://cgit.freedesktop.org/~seanpau
On 08/17/2016 09:11 AM, Sean Paul wrote:
> The handling of psr state is racey, shore that up with
> a per-psr driver lock.
>
> Signed-off-by: Sean Paul
Reviewed-by: Yakir Yang
> ---
>
> Changes in v2:
> - Rebased on
> https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
>
> dr
On 08/17/2016 09:11 AM, Sean Paul wrote:
> A few things that need tidying up, no functional changes.
>
> Signed-off-by: Sean Paul
Reviewed-by: Yakir Yang
> ---
>
> Changes in v2:
> - Introduced
>
> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 19 +++
> 1 file changed, 7
On 08/17/2016 09:11 AM, Sean Paul wrote:
> Remove the delayed worker, opting instead for the non-delayed
> variety. Also introduce a lock to ensure we don't have races
> with the worker and psr_state. Finally, cancel and wait for
> the worker to finish when disabling the bridge.
>
> Signed-off-by:
Sean,
Thanks a lot for your good fixes. I have reviewed most of them, and all
looks good to me.
But I got a question for merging things. My PSR patch set still under
reviewing, haven't been picked up Mark or other maintainers. Feel a
little bit embarrassed, how could we handle this situation ?
Sean,
On 08/17/2016 10:41 AM, Yakir Yang wrote:
> Sean,
>
> Thanks a lot for your good fixes. I have reviewed most of them, and
> all looks good to me.
>
> But I got a question for merging things. My PSR patch set still under
> reviewing, haven't been picked up Mark or other maintainers. Feel a
Hi Randy,
On 17 August 2016 at 05:01, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix dma-buf kernel-doc warning and 2 minor typos in
> fence_array_create().
>
Thanks for your patch, I will queue it up!
> Fixes this warning:
> ..//drivers/dma-buf/fence-array.c:124: warning: No description found
On 13 August 2016 at 04:48, 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 oper
drm/rockchip: Improve analogix-dp psr handling
> >>drm/rockchip: Enable vblank without event
> >>
> >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 --
> >> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> >> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
> >> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 90
> -
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++--
> >> 5 files changed, 69 insertions(+), 59 deletions(-)
> >>
> >
> >
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/6767c7a5/attachment.html>
Sean,
On 08/17/2016 09:11 AM, Sean Paul wrote:
> vblank should be enabled regardless of whether an event
> is expected back. This is especially important for a cursor
> plane.
Yep, I also found that sometimes vblank haven't been enabled when I move
the mouse lightly, that would cause eDP panel wo
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/20160817/a80f82e4/attachment.html>
On 08/09/2016 08:05 AM, Yakir Yang wrote:
> + Archit
>
>
> On 08/09/2016 02:53 AM, Sean Paul wrote:
>> Instead of just preparing the panel on bind, actually prepare/unprepare
>> during modeset/disable. The panel must be prepared in order to read hpd
>> status and edid, so we need to keep state ar
Hi,
On 07/24/2016 12:27 PM, Yakir Yang wrote:
> The full name of PSR is Panel Self Refresh, panel device could refresh
> itself with the hardware framebuffer in panel, this would make lots of
> sense to save the power consumption.
>
> This patch have exported two symbols for platform driver to imp
Hi Lin,
On 2016ë
08ì 17ì¼ 07:36, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v6:
> -Add more detail in Documentation
>
> Changes in v5:
> -None
>
> Changes in v4:
> -None
>
> Changes in v3:
> -None
>
Hello Archit,
On 08/17/2016 01:41 PM, Archit Taneja wrote:
> Hi,
>
> On 07/24/2016 12:27 PM, Yakir Yang wrote:
>> The full name of PSR is Panel Self Refresh, panel device could refresh
>> itself with the hardware framebuffer in panel, this would make lots of
>> sense to save the power consumption.
From: Junzhi Zhao
Pixel clock should be 297MHz when resolution is 4K.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/
From: Junzhi Zhao
The mtk_hdmi_send_infoframe have to
be run after PLL and PIXEL clock of HDMI enable.
Make sure that HDMI inforframes can be sent
successfully.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++--
1 file chang
From: Junzhi Zhao
In order to improve 4K resolution performance,
we have to enhance the HDMI driving current
when clock rate is greater than 165MHz.
Signed-off-by: Junzhi Zhao
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 +---
1 file
This is MT8173 HDMI 4K support PATCH v4, based on 4.8-rc1.
In order to support HDMI 4K on MT8173,
we have to make some modifications.
1) Make sure that mtk_hdmi_send_infoframe is sent successfully.
2) Enhance the HDMI driving current to improve performance.
3) Make sure that pixel clock is 297MHz
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/20160817/a4ec65b1/attachment.html>
Sean,
On 08/16/2016 07:12 AM, Sean Paul wrote:
> If vop_enable fails, don't continue on, it causes system hangs.
>
> Signed-off-by: Sean Paul
Also meet this problem on my Rk3399 Kevin board. VOP just failed to get
the pm_runtime at resume time, but ï½ï½ï½ï½er still just continue without
an
ceiving 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/20160817/13ca3477/attachment.html>
eceiving 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/20160817/bb06d7ee/attachment-0001.html>
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/1c5e6c60/attachment.sig>
On Tue, Aug 16, 2016 at 9:38 PM, Noralf Trønnes wrote:
>> That's still a lot for what amounts to reimplementing mmap on shmem, but
>> badly. What I mean with redirecting is pointing the entire ->mmap
>> operation to the mmap implementation for the underlying mmap. Roughly:
>>
>> /* normal
On Wed, Aug 17, 2016 at 10:26:44AM +0100, Mark Brown wrote:
> On Wed, Aug 17, 2016 at 08:28:17AM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
> > arm64-allmodconfig
> > ../drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c:140:18: error:
I just broke the build :(
Cc: Xinliang Liu
Cc: Xinwei Kong
Cc: Chen Feng
Cc: Sean Paul
Fixes: d25bcfb8c2e1 ("drm/hisilicon: Don't set drm_device->platformdev")
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 9 +
drivers/gpu/drm/hisilicon/kirin/Kconfig | 3
I just broke the build :(
Note that the cleanup function is a bit confused: ade_data was never
set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
is called indirectly through drm_mode_config_cleanup, which calls into
crtc->destroy, which already has the call to drm_crtc_cleanup.
Den 17.08.2016 11:30, skrev Daniel Vetter:
> On Tue, Aug 16, 2016 at 9:38 PM, Noralf Trønnes
> wrote:
>>> That's still a lot for what amounts to reimplementing mmap on shmem, but
>>> badly. What I mean with redirecting is pointing the entire ->mmap
>>> operation to the mmap implementation for t
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/acc68e32/attachment-0001.sig>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/9a6f29c5/attachment.html>
On Wed, Aug 17, 2016 at 12:19:02PM +0200, Noralf Trønnes wrote:
>
> Den 17.08.2016 11:30, skrev Daniel Vetter:
> > On Tue, Aug 16, 2016 at 9:38 PM, Noralf Trønnes
> > wrote:
> > > > That's still a lot for what amounts to reimplementing mmap on shmem, but
> > > > badly. What I mean with redirec
Hi,
On 17 August 2016 at 18:17, Daniel Vetter wrote:
> I just broke the build :(
>
> Note that the cleanup function is a bit confused: ade_data was never
> set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
Yes, this is a bug. Thanks for pointing out this.
> is called indirec
From: Colin Ian King
Fix build error by adding back the closing } on ade_dc_ops which
got accidentally removed from an earlier commit.
Fixes: d25bcfb8c2e18b9b36 ("Don't set drm_device->platformdev")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
1 fil
On Wed, Aug 17, 2016 at 07:02:01PM +0800, Xinliang Liu wrote:
> Hi,
>
> On 17 August 2016 at 18:17, Daniel Vetter wrote:
> > I just broke the build :(
> >
> > Note that the cleanup function is a bit confused: ade_data was never
> > set as drvdata, and calling drm_crtc_cleanup directly is a bug -
.org/archives/dri-devel/attachments/20160817/d975ee10/attachment-0001.html>
On Wed, Aug 17, 2016 at 12:09:24PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Fix build error by adding back the closing } on ade_dc_ops which
> got accidentally removed from an earlier commit.
>
> Fixes: d25bcfb8c2e18b9b36 ("Don't set drm_device->platformdev")
Yeah that patch was horr
/archives/dri-devel/attachments/20160817/0b94b235/attachment.html>
kernel
driver used.
--
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/20160817/f40af435/attachment.html>
Hello,
I was wondering about the call to copy_from_user in function
submit_lookup_objects for drive
/gpu/drm/msm/msm_gem_submit.c It calls copy_from_user[1] in a spin_lock, which
is not normally
allowed, due to the possibility of a deadlock.
Is there some reason that I am overlooking why it
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/bca989bd/attachment.html>
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/20160817/a784beed/attachment.html>
esg.
--
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/20160817/98fdbbc6/attachment.html>
return
check.
Please try the attached patch.
--
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/20160817/5255e0a8/attachment.html>
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)
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
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
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
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
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
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)
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
Hi Russell,
On 17-08-2016 12:21, Russell King - ARM Linux wrote:
> On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>> When using driver dw-hdmi in any other colorspace than RGB the
>> Y1, Y0 and YCC values are not correct. I confirmed in databook
>> that these regist
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
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
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
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
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 info to dmesg
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
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
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
On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
> Hi Russell,
>
> When using driver dw-hdmi in any other colorspace than RGB the
> Y1, Y0 and YCC values are not correct. I confirmed in databook
> that these registers are being written to the wrong offset (per
> my databook they should
On Wed, Aug 17, 2016 at 12:37:27PM +0100, Jose Abreu wrote:
> Hi Russell,
>
>
> On 17-08-2016 12:21, Russell King - ARM Linux wrote:
> > On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
> >> Hi Russell,
> >>
> >> When using driver dw-hdmi in any other colorspace than RGB the
> >> Y1, Y
Hi Russell,
When using driver dw-hdmi in any other colorspace than RGB the
Y1, Y0 and YCC values are not correct. I confirmed in databook
that these registers are being written to the wrong offset (per
my databook they should be written in bits 0:1 and 7 instead of
bits 4:5). The piece of code in
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
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
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
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
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.
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 info to dmesg
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
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
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 | 3 +++
drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv
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
Let's remove reference to "struct intel_connector *connector"
in intel_dp_aux_init() function as it is no longer required.
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/drm/i915/intel_dp.c b/driv
Let's remove reference to "struct intel_connector *connector"
in intel_dp_aux_init() function as it is no longer required.
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/drm/i915/intel_dp.c b/driv
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 | 3 +++
drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv
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
rchives/dri-devel/attachments/20160817/cbc53e9a/attachment.html>
On 17 August 2016 at 11:17, Daniel Vetter wrote:
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index d5ad60d3cf06..6544c74d250a 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -389,6 +389,15 @@ connector and plane objects by
Am Montag, den 15.08.2016, 16:41 +0800 schrieb Liu Ying:
> We don't support configuring active plane on-the-fly for imx-drm.
> The relevant CRTC should be disabled before the plane configuration.
> Of course, the plane itself should be disabled as well.
> This patch adds active plane reconfiguratio
On Wed, Aug 17, 2016 at 7:40 AM, Vaishali Thakkar
wrote:
> Hello,
>
> I was wondering about the call to copy_from_user in function
> submit_lookup_objects for drive
> /gpu/drm/msm/msm_gem_submit.c It calls copy_from_user[1] in a spin_lock,
> which is not normally
> allowed, due to the possibili
hment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 26651 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160817/69e0c342/attachment-0001.obj>
From: Thierry Reding
The MIPI DSI output on Tegra SoCs requires some external logic to
calibrate the MIPI pads before a video signal can be transmitted. This
MIPI calibration logic requires to be powered on while the MIPI pads are
being used, which is currently done as part of the DSI driver's pr
Hi,
i spent some time playing with DRI3/Present + PRIME for testing
how well it works for Optimus/Enduro style setups wrt. page flipping
on the current kernel/mesa/xorg. I want page flipping, because
neuroscience/medical applications need the reliable timing/timestamping
and tear free presentation
Scanout bo's which are dmabuf backed in RAM and
imported via prime will not update their content
with new rendering from the renderoffload gpu
once they've been flipped onto the scanout once.
The reason is that at preparation of first flip
they get pinned into VRAM, then unpinned at some
later poin
1 - 100 of 145 matches
Mail list logo
