---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/f2fbb8f5/attachment.html>
On 12.02.2016 22:31, Chanho Park wrote:
> This patch changes the compatible of exynos5420 fimd
> to "exynos5420-fimd". To support mic bypass from display
> path, the new compatible is introduced for exynos5420.
>
> Cc: Inki Dae
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Signed-off-by: Chanho
Hi,
It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
virtualized support for 3D/OpenGL hardware acceleration in VMs,
allowing using the GPU of the host in VMs.
As per my understanding the following components are needed -
- Linux 4.4 kernel includes the DRM driver for VirtIO-G
org/archives/dri-devel/attachments/20160215/f6f34239/attachment.html>
On 15.02.2016 09:57, Krzysztof Kozlowski wrote:
> On 12.02.2016 22:31, Chanho Park wrote:
>> This patch changes the compatible of exynos5420 fimd
>> to "exynos5420-fimd". To support mic bypass from display
>> path, the new compatible is introduced for exynos5420.
>>
>> Cc: Inki Dae
>> Cc: Kukjin K
||
--
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/20160215/2bd41dad/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/ff7fa740/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160215/5422db47/attachment.html>
HDMI on MSM8996 has a TX block that is compatible with the older
versions apart from some minor changes. The HDMI PHY and PLL on MSM8996
are new.
The series refactors the code such that there is a separate HDMI PHY
driver, similar to what we already have for DSI. This makes it easier
to integrate
The msm Makefile and Kconfig are getting conjusted. Move out
the DSI related stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 40 +---
drivers/gpu/drm/msm/Makefile | 22 --
dr
The msm Makefile and Kconfig are getting conjusted. HDMI is going to
have more configs and files in the future to manage, which will make
managing these harder.
Move HDMI related stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 1 +
The msm Makefile and Kconfig are getting conjusted. Move EDP related
stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile | 7 +--
drivers/gpu/drm/msm/edp/Kconfig | 7 +++
drivers/gpu/drm/m
Make gpio allocation and usage iterative by parsing the gpios on a given
platform from a list. This gives us flexibility over what all gpios exist
for a platform, whether they are input or output, and what value they
should be set to.
In particular, this will make HDMI on 8x96 platforms easier to
Some platforms may not have a HPD gpio line to detect Hot Plug signal from
the connector. They need to rely only on reading REG_HDMI_HPD_INT_STATUS
for HPD.
Modify hdmi_connector_detect logic such that it checks for HPD only using
the status register if there is no HPD gpio.
Signed-off-by: Archit
Create a phy device that represents the TX PHY and PLL parts of the HDMI
block.
This makes management of PHY specific resources (regulators and clocks)
much easier, and makes the PHY and PLL usable independently. It also
simplifies the core HDMI driver, which currently assigns phy ops among
many o
Add a helper to initialize PLL in the PHY driver. HDMI PLLs are going to
have their own mmio base different from that of PHY.
For the clock code in hdmi_phy_8960.c, some changes were needed for it to
work with the updated register offsets. Create a copy of the updated clock
code in hdmi_pll_8960.c
Make HDMI core get its PHY by parsing the qcom,hdmi-phy phandle. The core
will use this PHY reference to enable/disable PHY. The driver defers probe
until PHY isn't available.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 40
drivers/
Remove the old PHY ops managed by hdmi_platform_config and use them as ops
provided by the HDMI PHY driver.
Remove the old HDMI 8960 PLL code that used the top level HDMI TX mmio
base.
NOTE: With this commit, HDMI functionality will break until the HDMI
PHY/PLL register offsets in hdmi.xml.h aren
- Create separate domains for 8960 PHY and PLL
- Create separate domains for 8x60 PHY
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 157 +---
1 file changed, 74 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.xml
Adds HDMI 8996 PHY offsets. The offsets are divided into 3 parts:
- Core HDMI PHY registers
- HDMI PLL registers (part of QSERDES block)
- HDMI TX lane registers (part of QSERDES block)
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 500 +++
Add support for the HDMI PHY/PLL found in MSM8996/APQ8096.
Unlike the previous phys supported in the driver, this doesn't need
the powerup/powerdown ops. The PLL prepare/unprepare clock ops
enable/disable the phy itself.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/Makefile
Add HDMI PHY bindings. Update the example to use HDMI PHY.
Add a missing power-domains property in the HDMI core bindings.
Cc: devicetree at vger.kernel.org
Cc: Rob Herring
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/hdmi.txt | 39 +-
1 file
On 9 February 2016 at 04:12, Rob Herring wrote:
> On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> One comment, otherwise:
>
> Acked-by: Rob Herring
>
>> +Board specific:
>> +
Hi everyone,
I know, it's about f**king time and I apologize for the time it took us
to finally put this together. m(__)m
I have pushed two git branches which enable GM200 and GM204 (GM206 to
follow soon) owners to finally load NVIDIA-provided signed firmware and
start GR:
- https://github.co
dri-devel/attachments/20160215/6d16caa4/attachment.html>
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp
From: Heiko Stuebner
The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.
Signed-off-by: Heiko Stuebner
---
This patch is splited from "[PATCH v13 01/17] drm: bridge: analogix/dp: split
exynos dp driver to b
From: Heiko Stuebner
In the original split we kept the register constants intact to keep the
diff small. Still the constants are Analogix-specific, so rename them now.
Signed-off-by: Heiko Stuebner
---
This patch is splited from "[PATCH v13 01/17] drm: bridge: analogix/dp: split
exynos dp drive
Hi, Ville.
13.02.2016 01:23, Ville Syrjälä wrote:
> Few other ideas:
> - Was the monitor sleeping when you tried this? Can you maybe push
> some button on it and then immediately run the intel_reg read command
> again?
Nope. It just goes to sleep mode after (I suppose) drm module is loaded.
13.02.2016 01:23, Ville Syrjälä wrote:
> - Do you have another monitor to try?
> - Do you have another cable to try?
More on this.
Computer DVI ââ old DVI-HDMI cable ââ old monitor HDMI == not working
Computer DVI ââ another DVI-HDMI cable ââ old monitor HDMI == not
working
Com
On 02/12/16 19:15, Ville Syrjälä wrote:
> On Fri, Feb 12, 2016 at 07:08:46PM +0200, Tomi Valkeinen wrote:
>> On 12/02/16 17:34, Daniel Vetter wrote:
>>> On Fri, Feb 12, 2016 at 05:17:19PM +0200, Jyri Sarha wrote:
Fall back to legacy drm_helper_connector_dpms() call back in
drm_atomic_he
get the ball rolling :)
Ben.
>
> Cheers,
> Alex.
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/e37917a3/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/2defe7dd/attachment-0001.html>
Hi all,
I've already chatted with some of you in private, here's the entire idea with a
bit more thought. My motiviation for group maintainership of drm-misc was that I
got a bit a guilty feeling the last few vacations/conferences when folks pinged
about reviewed/tested pretty patches not landing.
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/c905a3b5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160215/2f00d5ce/attachment.html>
On Sun, Feb 14, 2016 at 2:58 PM, Daniel Vetter wrote:
> On Sun, Feb 14, 2016 at 11:16:52AM +0200, Oded Gabbay wrote:
>> Following Daniel's request, I spent some time removing the hard requirement
>> that radeon and amdgpu will always appear _after_ amdkfd in the drm Makefile.
>>
>> This was done b
On Mon, Feb 15, 2016 at 10:47 AM, Jyri Sarha wrote:
> On 02/12/16 19:15, Ville Syrjälä wrote:
>>
>> On Fri, Feb 12, 2016 at 07:08:46PM +0200, Tomi Valkeinen wrote:
>>>
>>> On 12/02/16 17:34, Daniel Vetter wrote:
On Fri, Feb 12, 2016 at 05:17:19PM +0200, Jyri Sarha wrote:
>
> Fa
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp
From: Heiko Stuebner
The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.
Signed-off-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes i
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Acked-by: Jingoo Han
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Cha
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v1
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
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: None
Cha
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Marti
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not s
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
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: None
Changes in v6: None
Changes
From: Heiko Stuebner
In the original split we kept the register constants intact to keep the
diff small. Still the constants are Analogix-specific, so rename them now.
Signed-off-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Cha
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compati
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
control
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7G
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v14: None
Changes in v13:
- Use .enable instead of preprare/commi
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to
1.18
--
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/20160215/fc727b2c/attachment.html>
The fb helper iterates over connectors, using fb_helper->num_connectors
makes it more clear what size the allocations are.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_f
add_all_connectors doesn't checks whether reallocation is needed, but add_one
does.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_help
These are mainly small fixes in drm/msm. The last patch adds a way to
parse DSI lanes information via DT.
Archit Taneja (5):
drm/msm/mdp: Use atomic helper to set crtc property
drm/msm: Free fb helper resources in msm_unload
drm/msm/dsi: Remove incorrect warning on host attach
drm/msm/dsi:
Assign drm_atomic_helper_crtc_set_property helper to MDP4 and MDP5
crtcs' set_property ops. This replaces the custom funcs that
returned an error even for standard crtc properties.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 9 +
drivers/gpu/drm/msm/mdp/md
From: Sricharan R
attach_dev gets called in mdp4_kms_init, but there is no corresponding
detach_dev called in the error path or in the kms driver unload path.
Detach and destroy mmu in mdp4_destroy.
Signed-off-by: Sricharan R
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4
We have a msm_fbev_free function to uninit fb_helper stuff, but we aren't
using it. Call it in msm_unload.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 5 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b
With the implementation of of_graph parsing, it isn't any longer
necessary for msm_host->device node to be same as dsi->dev.of_node. This
only holds true when the connected device is also a child of the dsi_host.
In the case of external bridge chips belonging to a different control
bus, these are
The min and max voltage levels for the VDD input to DSI were initially set
to 2.85V (as suggested by the spec).
We have a platform (db410c) where the same regulator supply is also needed
by another consumer at a higher voltage. Bump up the max voltage level to
3.3V. No regressions are seen with th
The DSI driver is currently unaware of how the DSI clock and data pins
are mapped to the logical lanes provided by the DSI controller.
Use the generic 'lanes' DT binding provided for DSI lanes (used for DSI
in bindings/display/ti/ti,omap4-dss.txt) to get the desired mapping.
The MSM DSI controlle
Because we record connector_mask using 1 << drm_connector_index now
the connector_mask should stay the same even when other connectors
are removed. This was not the case with MST, in that case when removing
a connector all other connectors may change their index.
This is fixed by waiting until the
On Mon, Feb 15, 2016 at 06:30:54PM +0530, Archit Taneja wrote:
> Assign drm_atomic_helper_crtc_set_property helper to MDP4 and MDP5
> crtcs' set_property ops. This replaces the custom funcs that
> returned an error even for standard crtc properties.
>
> Signed-off-by: Archit Taneja
> ---
> drive
Daniel, thanks for the feedback.
v2 patch will follow-up. :)
On 14-02-2016 18:25, Daniel Vetter wrote:
> On Fri, Feb 12, 2016 at 01:50:53PM +, Carlos Palminha wrote:
>
> Sob-line from you is missing on all patches, I can't merge them. Also
> please copypaste a default blurb to all patches that
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Changes v1->v2:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
at synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by:
Hi Carlos
Any particular reason why this patch isn't squashed with patch 8/17?
Thanks
Patrik
On Mon, Feb 15, 2016 at 1:58 PM, Carlos Palminha
wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-e
Am 15.02.2016 um 13:57 schrieb Carlos Palminha:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
> at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (m
On Mon, Feb 15, 2016 at 2:00 PM, Carlos Palminha
wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha
> at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementation
On Mon, Feb 15, 2016 at 01:45:16PM +0100, Maarten Lankhorst wrote:
> add_all_connectors doesn't checks whether reallocation is needed, but add_one
> does.
>
> Signed-off-by: Maarten Lankhorst
Both applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 12
>
Hi Maarten,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.5-rc4 next-20160215]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-atomic-Allow-for
Hi Philipp,
I tried using this driver with the Jitao Shi's latest Parade PS8640
driver from [0], which is based on Archit's recent DRM/DSI patch set
[1], and the parade bridge driver fails to find its DSI host using
of_find_mipi_dsi_host_by_node().
[0 ]https://patchwork.kernel.org/patch/8199281/
On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> 13.02.2016 01:23, Ville Syrjälä wrote:
> > - Do you have another monitor to try?
> > - Do you have another cable to try?
>
> More on this.
>
> Computer DVI ââ old DVI-HDMI cable ââ old monitor HDMI == not working
> C
Hi Dave,
Some regression fixups and cleanups.
Summary:
- fix compilation warnings on ARM64bit.
- fix mic driver initialization.
. MIC is a part of KMS so it converts it to use component framework
like other KMS drivers did.
- fix wrong driver state and disable clock ord
qxl_execbuffer_ioctl copies a qxl_command from user space into a kernel
buffer and then runs qxl_process_single_command. This then does
reloc_info = kmalloc(sizeof(struct qxl_reloc_info) * cmd->relocs_num,
which since cmd->relocs_num is 32bit can overflow on a 32bit machine. This
then alloc
On Mon, Feb 15, 2016 at 04:42:35PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> > 13.02.2016 01:23, Ville Syrjälä wrote:
> > > - Do you have another monitor to try?
> > > - Do you have another cable to try?
> >
> > More on this.
> >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=112491
Bug ID: 112491
Summary: Radeon: HD 7400G / A4-4355M System overheats with 3D
graphics active.
Product: Drivers
Version: 2.5
Kernel Version: 4.2
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=112491
--- Comment #1 from Dionisus Torimens ---
Created attachment 203661
--> https://bugzilla.kernel.org/attachment.cgi?id=203661&action=edit
dmesg 4.2
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=112491
--- Comment #2 from Dionisus Torimens ---
Created attachment 203671
--> https://bugzilla.kernel.org/attachment.cgi?id=203671&action=edit
dmesg 4.2 bapm=1 hang on radeon load.
This is a time where the system hung up already during boot with bap
1 - 100 of 120 matches
Mail list logo
