There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.
Signed-off-by: Chr
There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.
If the board has 2
rockchip,uphy-dp-sel is the register of type-c phy enable DP function.
Signed-off-by: Chris Zhong
---
Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
b/Documentati
rockchip,uphy-dp-sel is the register of type-c phy enable DP function.
Signed-off-by: Chris Zhong
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8e6d1bd
There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.
If the board has
On Thu, 09 Feb 2017, Thierry Reding wrote:
> On Thu, Feb 09, 2017 at 08:07:41PM +0100, Daniel Vetter wrote:
>> On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
>> > On Thu, 09 Feb 2017, Daniel Vetter wrote:
>> > > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
>> > >> On
From: Tomasz Figa
The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.
Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
ready to landed, this series just rebase them to lastest drm-next.
Thanks Heiko's Tested-by on rk3288 and rk3399 platform.
Changes in v3:
Advices by Tomas
From: Shunqian Zheng
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.
Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API a
https://bugzilla.kernel.org/show_bug.cgi?id=190971
gnube...@gmail.com changed:
What|Removed |Added
CC||gnube...@gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=194533
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to nucrap from comment #3)
> So this error warning will never disappear?
Correct. The message is not actually from the driver. It's printed by the
core pci rom code.
--
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=194533
--- Comment #3 from nuc...@hotmail.com ---
So this error warning will never disappear?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-d
https://bugzilla.kernel.org/show_bug.cgi?id=194533
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #7 from Alex Deucher ---
Created attachment 129464
--> https://bugs.freedesktop.org/attachment.cgi?id=129464&action=edit
possible fix
This patch should fix the issue.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #20 from Shmerl ---
FYI: I just tested it with wine-staging 2.1 with CSMT enabled (that version
allows using it with DX11 already), and corruption in the start menu is gone.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #9 from Timothy Arceri ---
(In reply to Timothy Arceri from comment #8)
> Actually no I take that back it is using core profile.
It's requesting a core profile and using compat features.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #8 from Timothy Arceri ---
Actually no I take that back it is using core profile.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #6 from Matt Corallo ---
Created attachment 129463
--> https://bugs.freedesktop.org/attachment.cgi?id=129463&action=edit
xrandr --verbose
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #7 from Timothy Arceri ---
Planetary Annihilation is using compat profile. When I override the Mesa
version
with MESA_GL_VERSION_OVERRIDE=3.1COMPAT the corruptions are fixed but it later
crashes.
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #5 from Michel Dänzer ---
This bugzilla is preferred for kernel driver issues as well. I reassigned this
report to the correct product and component.
Can you also attach the output of xrandr --verbose?
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=99744
Michel Dänzer changed:
What|Removed |Added
Attachment #129462|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=99744
Michel Dänzer changed:
What|Removed |Added
Attachment #129461|text/x-log |text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #8 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to fin4478 from comment #5)
fin4...@hotmail.com, this kind of comment is essentially noise and makes the
lives of those of us working with bug reports and fixing problems harder
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #4 from Matt Corallo ---
Attached (possibly) relevant logs. Will test on the staging branch when I get a
chance (probably in a week or two). I figured the issue would be with the
kernel driver but didnt see an obviously better place t
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #3 from Matt Corallo ---
Created attachment 129462
--> https://bugs.freedesktop.org/attachment.cgi?id=129462&action=edit
dmesg grep amd, drm, dmar (in case its relevant)
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=99744
--- Comment #2 from Matt Corallo ---
Created attachment 129461
--> https://bugs.freedesktop.org/attachment.cgi?id=129461&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #76 from fin4...@hotmail.com ---
I tested the game and with default video settings it did hang sometimes, but
dialing video settings down, the Rocket League works fine with Debian testing
Xfce. Oipaf ppa and custom adg5f drm-next-4.11-
This adds a file in i915's debugfs directory that allows userspace to
manually control HPD storm detection. This is mainly for hotplugging
tests, where we might want to test HPD storm functionality or disable
storm detection to speed up hotplugging tests without breaking anything.
Changes since v1
drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi for the port.
drm_dp_atomic_rele
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add
From: Wei Yongjun
Fixes the following sparse warning:
drivers/gpu/drm/bridge/ti-tfp410.c:223:24: warning:
symbol 'tfp410_platform_driver' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
For drm_of_find_panel_or_bridge() added in the next commit, an empty
version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.
Signed-off-by: Rob Herring
---
v2:
- new patch
include/drm/drm_panel.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_panel.h b
From: Wei Yongjun
Fix to return error code -ENOMEM from the malloc error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/d
Having a ->atomic_release callback is useful to release shared resources
that get allocated in compute_config(). This function is expected to be
called in the atomic_check() phase before new resources are acquired.
v2: Moved the caller hunk to this patch (Daniel)
Suggested-by: Daniel Vetter
Sign
[CC CMA people]
On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> Modules might want to check their CMA pool size and address for debugging
> and / or have additional checks.
>
> The obvious way to do this would be through dev_get_cma_area and
> cma_get_base and cma_get_size, that are currently no
Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or
The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.
In dss_init_ports, we invert the loop,
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos4210-trats.dts | 23 ++-
1 file changed, 2 insertions(+
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel. So this patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++--
1 file changed, 2 inse
Hi,
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel.
So the 1/5 patch parse the Pll, burst and esc clock frequency
properties in dsi_par
Rob Herring writes:
> Convert drivers to use the new of_graph_get_remote_node() helper
> instead of parsing the endpoint node and then getting the remote device
> node. Now drivers can just specify the device node and which
> port/endpoint and get back the connected remote device node. The detail
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos4412-trats2.dts | 23 ++-
1 file changed, 2 insertions(
Hi,
just for my knowledge and all those working on the tm2(e)
devices, is this patch going in or not?
If not, Thierry, could you please say what Hoegeun needs to do in
order to get this in?
Thanks,
Andi
On Wed, Jan 11, 2017 at 03:33:58PM +0900, Hoegeun Kwon wrote:
> This patch add support for M
Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> Having a ->atomic_release callback is useful to release shared
> resources
> that get allocated in compute_config(). This function is expected to
> be
> called in the atomic_check() phase before new resources are acquired.
>
> v2: Mo
Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the
shared link bandwidth for a primary link directly connected to the GPU. For
atomic modesetting drivers, checking if there is sufficient link bandwidth
for a mode n
On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > Having a ->atomic_release callback is useful to release shared
> > resources
> > that get allocated in compute_config(). This function is expected to
> > be
> > called i
Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious
The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total slots, 63. So, let's make that check obvious and remove
avail_slots. While at it, make debug messages more descriptive.
Signed-off-by: Dhinakaran Pandiyan
I've been unhappy with the OF graph API for some time and decided to
do something about it. The problem is drivers have to do too much of the
graph parsing and walking themselves. This has led to the same pattern
duplicated over and over. This series adds 2 new helpers and adapts DRM
drivers to use
Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nic
Daniel Vetter wrote:
Latest report just says that the revert isn't helping either. I suspect
the report is a giantic conflagration of everything ever that kills
various reporters boxes. I still believe that the patch here fixes the
original bug, but there might be a lot more hiding.
I
Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_check() with the connector
helper
Link bandwidth is a shared resource between multiple displays in DP MST
configurations. For atomic modesetting drivers, checking if there is
sufficient link bandwidth for a mode needs to be done during the
atomic_check phase to avoid failed modesets when multiple CRTC's and
connectors are involved.
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos3250-rinato.dts | 23 ++-
1 file changed, 2 insertions(
The OF graph API leaves too much of the graph walking to clients when
in many cases the driver doesn't care about accessing the port or
endpoint nodes. The drivers typically just want the device connected via
a particular graph connection. of_graph_get_remote_node provides this
functionality.
Sign
On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart
> wrote:
> > Hi Swati,
> >
> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> >> From: Swati Dhingra
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if ther
On Thu, 2017-02-09 at 08:08 +, Chris Wilson wrote:
> On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote:
> > +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i,
> > __funcs) \
> > + for ((__i) = 0; \
> >
The total vcpi time slots is always 63 and does not depend on the link BW,
remove total_slots from MST topology manager struct. The next change is to
remove total_pbn which is hardcoded to 2560. The total PBN that the
topology manager allocates from depends on the link rate and is not a
constant. S
https://bugs.freedesktop.org/show_bug.cgi?id=99744
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
Hi Linus,
This should be the final set of drm fixes for 4.10, one vmwgfx boot
fix, one vc4 fix, and a few i915 fixes.
Hopefully haven't missed anything.
Dave.
The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:
Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)
are availabl
https://bugs.freedesktop.org/show_bug.cgi?id=99747
--- Comment #2 from Michel Dänzer ---
What does
apt-cache policy libllvm3.9
say?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=99748
Bug ID: 99748
Summary: [radeonsi] Civ6 Assert in LLVM SIMachineScheduler.cpp
with R600_DEBUG=sisched
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #56 from Jaime Rodrigo ---
I tried 4.10 RC7, and I could successfully login with this kernel. But after 5
mins of using it, I had a blackout again :/ . Guess I'll stick to RC5 for a
while
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #75 from Michel Dänzer ---
(In reply to Clemens Eisserer from comment #73)
> just to be curious, does it actually map the buffer with the READ flag?
According to Timothee and the apitrace it does, so
https://patchwork.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #74 from i...@posteo.net ---
Do you need more testing?
Has anyone yet reported that to psyonix?
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99747
--- Comment #1 from APoliTech ---
The links to the launchpad.net reports
https://bugs.launchpad.net/ubuntu-mate/+bug/1663379
https://bugs.launchpad.net/ubuntu-mate/+bug/1663391
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=99747
APoliTech changed:
What|Removed |Added
Component|Other |Drivers/Gallium/radeonsi
QA Contact|
https://bugs.freedesktop.org/show_bug.cgi?id=98869
Grazvydas Ignotas changed:
What|Removed |Added
CC||nota...@gmail.com
--- Comment #19 fr
On 9 February 2017 at 20:41, Thierry Reding wrote:
> On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
>> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
>> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
>> > > From: Thierry Reding
>> > >
>> > > For cons
https://bugs.freedesktop.org/show_bug.cgi?id=99450
--- Comment #5 from Samuel Pitoiset ---
Okay, you hit a second issue that should be definitely fixed in mesa 17. I
confirm the visual glitches with 13.0.4, but not with latest mesa/llvm.
Fwiw, the commit previously mentionned should prevent VM f
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #24 from Samuel Pitoiset ---
I do have the blood dlc now. Unfortunately, after trying few minutes I can't
reproduce the issue with latest mesa/LLVM. Maybe it's on my side but I don't
really have much time to investigate into that issu
https://bugzilla.kernel.org/show_bug.cgi?id=194533
Bug ID: 194533
Summary: Invalid PCI ROM header signature: expecting 0xaa55,
got 0x9125
Product: Drivers
Version: 2.5
Kernel Version: 4.9.8
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=194533
nuc...@hotmail.com changed:
What|Removed |Added
CC||nuc...@hotmail.com
Hardwar
https://bugzilla.kernel.org/show_bug.cgi?id=194533
--- Comment #1 from nuc...@hotmail.com ---
Created attachment 254693
--> https://bugzilla.kernel.org/attachment.cgi?id=254693&action=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > For consistency with other reference counting APIs in the kernel,
On Thu, Feb 09, 2017 at 08:07:41PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> > On Thu, 09 Feb 2017, Daniel Vetter wrote:
> > > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> > >> On Wed, 08 Feb 2017, Thierry Reding wrote:
> > >> >
Hi Dave,
Some additional fixes for 4.11. Delayed a bit due to Chinese New Year.
Highlights:
- Powerplay fixes
- VCE and UVD powergating fixes
- Clean up amdgpu SI gfx code to match CI and VI
- Misc bug fixes
The following changes since commit 18566acac18f5784347bc5fe636a26897d1c963b:
Merge b
On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> On Thu, 09 Feb 2017, Daniel Vetter wrote:
> > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> >> On Wed, 08 Feb 2017, Thierry Reding wrote:
> >> > This series introduces DRM reference counting APIs that are consistent
>
On Thu, Feb 09, 2017 at 05:38:26PM +, Daniel Stone wrote:
> Hi,
>
> On 9 February 2017 at 17:01, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned
> >> long arg)
> >> +{
> >>
If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache. If we then reused it before it expired from the cache,
the kernel would OOPS.
Signed-off-by: Eric Anholt
Fixes: c826a6e10644 ("drm/vc4: Add a BO
On Thu, 09 Feb 2017, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
>> On Wed, 08 Feb 2017, Thierry Reding wrote:
>> > This series introduces DRM reference counting APIs that are consistent
>> > with other reference counting APIs in the kernel. They are also m
On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
>
> struct foo_bar_state
> {
> struct drm_bar_state bar_state;
> struct foo_private priv;
> struct foo_private2 *priv2;
> };
>
> memcpy priv and priv2 to the new instance o
Hi,
On 9 February 2017 at 17:01, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
>> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned
>> long arg)
>> +{
>> + struct drm_fb_helper *fb_helper = info->par;
>> + struct drm_device
On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
>
> struct foo_bar_state
> {
> struct drm_bar_state bar_state;
> struct foo_private priv;
> struct foo_private2 *priv2;
> };
>
> memcpy priv and priv2 to the new instance o
On Thu, Feb 09, 2017 at 04:39:29PM +0200, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter wrote:
> > On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote:
> >> Op 21-12-16 om 11:36 schreef Chris Wilson:
> >> > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> >>
On Thu, Feb 09, 2017 at 05:57:04PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> > Hi,
> >
> > I was working on a few patches adding fields to struct malidp_crtc_state and
> > found myself writing memcpy multiple times in the ->atomic_duplicate_s
Assuming a derived struct of the form:
struct foo_bar_state
{
struct drm_bar_state bar_state;
struct foo_private priv;
struct foo_private2 *priv2;
};
memcpy priv and priv2 to the new instance of foo_bar_state. The
intention is to use this macro in ->atomic_duplicate_state
On Wed, Feb 08, 2017 at 12:47:01PM -0800, Eric Anholt wrote:
> Unlike the other encoders in the driver, I've also dropped the debug
> dump function. There's only really one register to this device, and
> we have the debugfs reg entry still.
>
> Signed-off-by: Eric Anholt
Yeah, dmesg spew by def
https://bugs.freedesktop.org/show_bug.cgi?id=99476
--- Comment #1 from Alex Deucher ---
Does the firmware here help?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/
--
You are receiving this mail because:
You are the assignee for the bug._
On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> On Wed, 08 Feb 2017, Thierry Reding wrote:
> > This series introduces DRM reference counting APIs that are consistent
> > with other reference counting APIs in the kernel. They are also much
> > shorter. Compatibility aliases are added
On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > For consistency with other reference counting APIs in the kernel, add
> > drm_mode_object_get() and drm_mode_object_put() to reference coun
On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote:
> From: Xinliang Liu
>
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
>
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev
On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> From: Stefan Christ
>
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
>
On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> Hi,
>
> I was working on a few patches adding fields to struct malidp_crtc_state and
> found myself writing memcpy multiple times in the ->atomic_duplicate_state
> hook because I wanted to avoid copying the drm_crtc_state twice
>
The operating-points-v2 binding gives a way to provide the OPP of the GPU.
Let's use it.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4
1 file changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/arm,ma
Allow to provide an optional memory region to allocate from for our DRM
driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/s
Modules might want to check their CMA pool size and address for debugging
and / or have additional checks.
The obvious way to do this would be through dev_get_cma_area and
cma_get_base and cma_get_size, that are currently not exported, which
results in a build failure.
Export them to prevent such
The Mali GPU in the A33 has various operating frequencies used in the
Allwinner BSP.
Add them to our DT.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a33.dtsi | 17 +
1 file changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/ar
1 - 100 of 145 matches
Mail list logo
