Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2:
Rebased.
v3:
Extra comments are removed.
Signed-off-by: Ramalingam C
---
driver
Notifier Chain is defined to inform all its clients about the mei
client device state change. Routine is defined for the clients to
register and unregister for the notification on state change.
v2:
Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
Signed-off-by: Ramalingam
ME FW is contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.
ME FW prepare and HDCP2.2 authentication parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and co
In preparation for implementing HDCP2.2 in I915, this patch adds
HDCP register definitions for HDMI and DP HDCP adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where are HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field def
The sequence for HDCP2.2 authentication and encryption is implemented
in I915. Encoder specific implementations are moved into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 ca
This patch defines the hdcp2.2 protocol messages for the
HDCP2.2 authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 183
https://bugzilla.kernel.org/show_bug.cgi?id=199269
Bug ID: 199269
Summary: amdgpu/DC on Kaveri results in corrupt color output on
HDMI
Product: Drivers
Version: 2.5
Kernel Version: 4.16
Hardware: x86-64
https://bugs.freedesktop.org/show_bug.cgi?id=90217
--- Comment #9 from Matthew Dawson ---
(In reply to Timothy Arceri from comment #8)
> Hi guys,
>
> There have been many improvements since this was reported, and I don't see
> any other reports like this. Is this still happening or can we close
On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
> On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
>> On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
> Am 01.04.2018 um 20:
On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
> On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
>>> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
> On Sun, 01 Apr 201
From: Mirela Rabulea
Do not hardcode pixel_format to 0x77 but calculate it from dsi->format.
Report all the supported bus formats in get_modes:
MEDIA_BUS_FMT_RGB888_1X24
MEDIA_BUS_FMT_RGB666_1X18
MEDIA_BUS_FMT_RGB565_1X16
Change pixelclock from 120 to 132 MHz, or 16 bpp fo
On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote:
> Quoting Matthew Wilcox (2018-04-02 15:10:58)
> > Souptick and I have been auditing the various page fault handler routines
> > and we've noticed that graphics drivers assume that a signal should be
> > able to interrupt a page fault.
Add support for the OLED display based on MIPI-DSI protocol from Raydium:
RM67191.
Signed-off-by: Robert Chiras
---
.../bindings/display/panel/raydium,rm67191.txt | 55 ++
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1 +
This commit adds support for AUO's 7.0" display.
Signed-off-by: Lukasz Majewski
---
.../bindings/display/panel/auo,g070vvn01 | 30 +
drivers/gpu/drm/panel/panel-simple.c | 31 ++
2 files changed, 61 insertions(+)
create mode 100644
We have to check dma-buf reservation objects
of our framebuffers before we use them.
Otherwise, another driver might be writing
on the same buffer which we are using.
This would cause visible tearing effects
on display.
We can use existing atomic helper functions
to solve this problem.
Signed-off
On 2018-04-03 11:10, Daniel Vetter wrote:
> On Wed, Mar 28, 2018 at 12:03:39PM +0200, Peter Rosin wrote:
>> On 2018-03-28 09:34, Boris Brezillon wrote:
>>> Hi Peter,
>>>
>>> On Mon, 26 Mar 2018 09:35:02 +0200
>>> Peter Rosin wrote:
>>>
I have an sama5d31-based system with 64MB of memory and a
This patch-set add support for Raydium RM67191 FHD (1080x1920)
OLED panel driver.
The first patch is the initial version of the driver, while the second
patch adds support for all the actually supported pixel formats by the
panel.
Mirela Rabulea (1):
drm/panel: rm67191: Add support for new bus
On 04/03/2018 03:32 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add myself as drivers/gpu/drm/xen maintainer.
Signed-off-by: Oleksandr Andrushchenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 622f3e4c5ef
On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
>> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
>>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
On Sun, 01 Apr 2018 19:58:11 +0200,
Christian K6nig wrote:
> Am 01.04
The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.
However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're go
The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu-sun5i.h | 4
include/dt-bindings/clock/sun5i-ccu.h | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/dri
The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.
Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.
One of the most notable thi
Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.
These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.
Add supp
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/sunxi-mbus.txt |
Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.
We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able t
Hi,
We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x4000 for most SoCs).
After some discussion after
The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.
However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules. W
On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
>> > On Sun, 01 Apr 2018 19:58:11 +0200,
>> > Christian K6nig wrote:
>> > > Am 01.04.2018 um 19:45 schrieb Ilia Mirkin:
>> > > > O
On Tue, 03 Apr 2018, Lucas Stach wrote:
> To be honest I don't understand why you are trying to enforce your
> model on everyone. Maybe the drm-misc thing has solved some problems
> for you, but I just don't see the point why others who seem to have
> something that works for them should switch to
Quoting Matthew Wilcox (2018-04-03 14:10:25)
> On Tue, Apr 03, 2018 at 01:33:15PM +0100, Chris Wilson wrote:
> > Quoting Matthew Wilcox (2018-04-02 15:10:58)
> > > I don't think the graphics drivers really want to be interrupted by
> > > any signal.
> >
> > Assume the worst case and we may block f
On 04/03/2018 02:33 PM, Chris Wilson wrote:
Quoting Matthew Wilcox (2018-04-02 15:10:58)
Souptick and I have been auditing the various page fault handler routines
and we've noticed that graphics drivers assume that a signal should be
able to interrupt a page fault. In contrast, the page cache t
On 2018-04-03 11:44 AM, Takashi Iwai wrote:
> On Tue, 03 Apr 2018 11:18:34 +0200,
> Michel D4nzer wrote:
>>
>> On 2018-04-03 11:02 AM, Takashi Iwai wrote:
>>> On Tue, 03 Apr 2018 10:57:56 +0200,
>>> Christian K6nig wrote:
Am 03.04.2018 um 10:36 schrieb Michel Dänzer:
> On 2018-04-01 0
Quoting Matthew Wilcox (2018-04-02 15:10:58)
>
> Souptick and I have been auditing the various page fault handler routines
> and we've noticed that graphics drivers assume that a signal should be
> able to interrupt a page fault. In contrast, the page cache takes great
> care to allow only fatal
Hi Rob,
sorry for pointing to you directly :)
On Mon, Apr 02, 2018 at 04:36:55PM +0300, Laurent Pinchart wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> > On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > > On Tue, Mar 27, 2018 at 12:37:31PM +0300, V
From: Oleksandr Andrushchenko
Add myself as drivers/gpu/drm/xen maintainer.
Signed-off-by: Oleksandr Andrushchenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 622f3e4c5efa..6cf1bd5593b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Hi Liviu,
On Tue, Apr 3, 2018 at 12:15 PM, Liviu Dudau wrote:
> On Tue, Apr 03, 2018 at 11:58:17AM +0200, Daniel Vetter wrote:
>> On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
>> > Hi Linus,
>> >
>> > This is the main drm pull request for 4.17-rc1.
>> >
>> > I'm sending it early be
On Tue, Apr 3, 2018 at 1:52 PM, Daniel Vetter wrote:
> On Tue, Apr 3, 2018 at 1:13 PM, Lucas Stach wrote:
>> Hi Daniel,
>>
>> Am Dienstag, den 03.04.2018, 12:01 +0200 schrieb Daniel Vetter:
>>> On Tue, Apr 3, 2018 at 11:58 AM, Daniel Vetter wrote:
>>> > On Thu, Mar 29, 2018 at 11:15:50AM +1000,
On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote:
Resending with even more checkpatch code-style fixes.
Applied,
thank you!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 3, 2018 at 1:13 PM, Lucas Stach wrote:
> Hi Daniel,
>
> Am Dienstag, den 03.04.2018, 12:01 +0200 schrieb Daniel Vetter:
>> On Tue, Apr 3, 2018 at 11:58 AM, Daniel Vetter wrote:
>> > On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
>> > > Hi Linus,
>> > >
>> > > This is the
Am 03.04.2018 um 11:29 schrieb Daniel Vetter:
On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
[SNIP]
Well exactly that's the point, nothing.
The problem is that the option name is confusing to the end user because the
expectation is
Hi Daniel,
On Tuesday, 3 April 2018 12:07:31 EEST Daniel Vetter wrote:
> On Mon, Apr 02, 2018 at 06:05:22PM +0300, Laurent Pinchart wrote:
> > On Thursday, 29 March 2018 12:41:33 EEST Tomi Valkeinen wrote:
> >> On 28/03/18 14:41, Daniel Vetter wrote:
> >>> The only thing that omap_gem_free_object
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
X
From: Oleksandr Andrushchenko
Resending with even more checkpatch code-style fixes.
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implem
Hi Daniel,
Am Dienstag, den 03.04.2018, 12:01 +0200 schrieb Daniel Vetter:
> On Tue, Apr 3, 2018 at 11:58 AM, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
> > > Hi Linus,
> > >
> > > This is the main drm pull request for 4.17-rc1.
> > >
> > > I'm sending
Hi Tomi,
Thank you for the patch.
On Thursday, 29 March 2018 13:40:37 EEST Tomi Valkeinen wrote:
> tiler_reserve_2d allocates memory but does not check if it got the
> memory. Add the check and return ENOMEM on failure.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/omap_dmm
Hi Tomi,
Thank you for the patch.
On Thursday, 29 March 2018 13:40:36 EEST Tomi Valkeinen wrote:
> audio_config function for both HDMI4 and HDMI5 return uninitialized
> value as the error code if the display is not currently enabled. For
> some reason this has not caused any issues.
>
> Signed-o
Hi!
> +- rotation: Display rotation in degrees counter clockwise (0,90,180,270).
> + The following values are possible:
> +
> +0 = The top side of the panel matches the top side of the
> +device's casing (default).
This is still ambiguous for devices such as N900 and Droid4, which ca
On Fri 2018-03-30 19:18:21, Sebastian Reichel wrote:
> From: Sebastian Reichel
>
> Add support to inform the DRM subsystem about the orientation
> the display has been mounted to the casing.
>
> Signed-off-by: Sebastian Reichel
1-5,7: Reviewed-by: Pavel Machek
Thanks,
On Fri 2018-03-30 19:18:22, Sebastian Reichel wrote:
> This adds a LCD panel rotation hint to the Droid 4. If the
> display is rotated this way the keyboard can be used properly.
>
> Signed-off-by: Sebastian Reichel
Hmm. Aha. And this the place where confusion matters. I believe most
users would
Hi Daniel,
On Tue, Apr 03, 2018 at 11:58:17AM +0200, Daniel Vetter wrote:
> On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
> > Hi Linus,
> >
> > This is the main drm pull request for 4.17-rc1.
> >
> > I'm sending it early because Easter is coming and I'm going to be on
> > holidays/h
On Tue, 03 Apr 2018, Julia Lawall wrote:
> On Tue, 3 Apr 2018, Jani Nikula wrote:
>> Please do consider limiting the distribution in the future,
>> though. There's no need to include lkml or even dri-devel for trivial
>> patches like this.
>
> It's complex to have to remember the preferences for e
On Tue, Apr 03, 2018 at 11:41:05AM +0200, Julia Lawall wrote:
>
>
> On Tue, 3 Apr 2018, Jani Nikula wrote:
>
> > On Fri, 30 Mar 2018, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Trivial fix to spelling mistake in DRM_ERROR error message text
> >
> > Thanks for the patch.
> >
> > P
On Tue, Apr 3, 2018 at 11:58 AM, Daniel Vetter wrote:
> On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
>> Hi Linus,
>>
>> This is the main drm pull request for 4.17-rc1.
>>
>> I'm sending it early because Easter is coming and I'm going to be on
>> holidays/have relatives staying for
Wait until we have enough space in the virt queue to actually queue up
our request. Avoids the guest spinning in case we have a non-zero
amount of free entries but not enough for the request.
Cc: sta...@vger.kernel.org
Reported-by: Alain Magloire
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/dr
On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
> Hi Linus,
>
> This is the main drm pull request for 4.17-rc1.
>
> I'm sending it early because Easter is coming and I'm going to be on
> holidays/have relatives staying for most of the next three weeks.
> I'll be near email for any emer
On Tue, 03 Apr 2018, Michel Dänzer wrote:
> On 2018-04-03 11:02 AM, Takashi Iwai wrote:
>> Agreed with the naming mess. But OTOH, it's already a thing that is
>> too popular to kill. You can add a more suitable option name, but you
>> cannot drop these existing ones easily. It's already in a gr
On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
> +static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj)
> +{
> + grant_ref_t priv_gref_head;
> + int ret, j, cur_ref, num_pages;
> + struct sg_page_iter sg_iter;
On Tue, 03 Apr 2018 11:18:34 +0200,
Michel D4nzer wrote:
>
> On 2018-04-03 11:02 AM, Takashi Iwai wrote:
> > On Tue, 03 Apr 2018 10:57:56 +0200,
> > Christian K6nig wrote:
> >>
> >> Am 03.04.2018 um 10:36 schrieb Michel Dänzer:
> >>> On 2018-04-01 07:45 PM, Ilia Mirkin wrote:
> On Sun, Apr 1,
On Tue, 3 Apr 2018, Jani Nikula wrote:
> On Fri, 30 Mar 2018, Colin King wrote:
> > From: Colin Ian King
> >
> > Trivial fix to spelling mistake in DRM_ERROR error message text
>
> Thanks for the patch.
>
> Please do consider limiting the distribution in the future,
> though. There's no need t
On Fri, 30 Mar 2018, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_ERROR error message text
Thanks for the patch.
Please do consider limiting the distribution in the future,
though. There's no need to include lkml or even dri-devel for trivial
patches like
https://bugs.freedesktop.org/show_bug.cgi?id=105530
--- Comment #8 from Michel Dänzer ---
(In reply to Mez from comment #7)
> I've always had Tearfree option on though and it didn't occur before these
> last
> few weeks.
Can you help narrow down whether this was introduced by a change in the ke
On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote:
> Am 01.04.2018 um 20:21 schrieb Takashi Iwai:
> > On Sun, 01 Apr 2018 19:58:11 +0200,
> > Christian K6nig wrote:
> > > Am 01.04.2018 um 19:45 schrieb Ilia Mirkin:
> > > > On Sun, Apr 1, 2018 at 1:39 PM, Christian König
> > > > wrote
https://bugs.freedesktop.org/show_bug.cgi?id=95058
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
On Mon, Apr 02, 2018 at 11:45:31AM -0400, Sean Paul wrote:
> On Fri, Mar 30, 2018 at 11:39:05AM -0700, Eric Anholt wrote:
> > Boris Brezillon writes:
> >
> > > ->atomic_async_update() requires that drivers update the plane->state
> > > object before returning. Make sure at least common properties
On 2018-04-03 11:02 AM, Takashi Iwai wrote:
> On Tue, 03 Apr 2018 10:57:56 +0200,
> Christian K6nig wrote:
>>
>> Am 03.04.2018 um 10:36 schrieb Michel Dänzer:
>>> On 2018-04-01 07:45 PM, Ilia Mirkin wrote:
On Sun, Apr 1, 2018 at 1:39 PM, Christian König
wrote:
> Am 30.03.2018 um 22:4
Am 02.04.2018 um 20:49 schrieb Eric Anholt:
[SNIP]
This call will pick a VMID and remember that the process of the job is
now the owner of this VMID. If the VMID previously didn't belonged to
the process of the current job all fences of the old process are added
to the job->sync object again.
T
version: 1.1 libva 2.1.0 ?) ,
vainfo shows me for the H264_BASELINE "" .
Graphics: AMD/ATI HD 5550 Redwood LE, Evergreen Series
mesa3D 17.2 OK => since 17.3 , Mesa 18.0 also tested
ArchLinux 64bit: Latest updates since 20180403 .
Best regards, berni
=== ENV ===
VDPA
On Wed, Mar 28, 2018 at 12:03:39PM +0200, Peter Rosin wrote:
> On 2018-03-28 09:34, Boris Brezillon wrote:
> > Hi Peter,
> >
> > On Mon, 26 Mar 2018 09:35:02 +0200
> > Peter Rosin wrote:
> >
> >> I have an sama5d31-based system with 64MB of memory and a 1920x1080
> >> LVDS display wired for 16-b
On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote:
> Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
> > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
> > > Add a peer2peer flag noting that the importer can deal with device
> > > resources which are not backed by page
On Mon, Apr 02, 2018 at 06:05:22PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Thursday, 29 March 2018 12:41:33 EEST Tomi Valkeinen wrote:
> > On 28/03/18 14:41, Daniel Vetter wrote:
> > > The only thing that omap_gem_free_object does that might need the
> > > magic protection of struct_mutex (
https://bugs.freedesktop.org/show_bug.cgi?id=99923
Michel Dänzer changed:
What|Removed |Added
CC||arse...@gmail.com
--- Comment #25 from M
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #24 from Martin Pilarski ---
The bug was enabled with LLVM revision 281112 (or commit
d5a5e9043a23bdcf0f3e4d05e007a3d67488b445 [0]).
After reverting the change in lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
everything seems to be worki
On Tue, 03 Apr 2018 10:57:56 +0200,
Christian K6nig wrote:
>
> Am 03.04.2018 um 10:36 schrieb Michel Dänzer:
> > On 2018-04-01 07:45 PM, Ilia Mirkin wrote:
> >> On Sun, Apr 1, 2018 at 1:39 PM, Christian König
> >> wrote:
> >>> Am 30.03.2018 um 22:45 schrieb Takashi Iwai:
> amdgpu driver lack
Am 03.04.2018 um 10:36 schrieb Michel Dänzer:
On 2018-04-01 07:45 PM, Ilia Mirkin wrote:
On Sun, Apr 1, 2018 at 1:39 PM, Christian König
wrote:
Am 30.03.2018 um 22:45 schrieb Takashi Iwai:
amdgpu driver lacks of modeset module option other drm drivers provide
for enforcing or disabling the dr
On Mon, Apr 02, 2018 at 09:50:35PM +0300, Laurent Pinchart wrote:
> GEM objects mmap offsets are created by calling
> drm_gem_create_mmap_offset_size() that doesn't need struct_mutex
> protection as it includes its own locking, based on a size that is
> static across the object's life time. Remove
On 2018-04-01 07:45 PM, Ilia Mirkin wrote:
> On Sun, Apr 1, 2018 at 1:39 PM, Christian König
> wrote:
>> Am 30.03.2018 um 22:45 schrieb Takashi Iwai:
>>>
>>> amdgpu driver lacks of modeset module option other drm drivers provide
>>> for enforcing or disabling the driver load. Interestingly, the
>
Op 02-04-18 om 19:49 schreef Thomas Hellstrom:
> Maarten, Daniel,
>
> Do we have any ww-mutex performance tests somewhere that can be used to test
> the impact of implementation details on various locking scenarios?
>
> Thanks,
>
> /Thomas
>
>
The thing that comes to my mind are some of the kms_cu
https://bugs.freedesktop.org/show_bug.cgi?id=102885
--- Comment #12 from Timothy Arceri ---
Possibly a duplicate of bug 105152
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesk
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
X
From: Oleksandr Andrushchenko
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif
On 27/03/18 00:25, Rob Herring wrote:
> On Fri, Mar 23, 2018 at 01:59:13PM +0100, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Some boards have both a DesignWare and their own CEC controller.
>> The CEC pin is only hooked up to their own CEC controller and not
>> to the DW controller.
>>
>> Add
Hey Chih-Wei,
Thanks for the poke, the patch has been pushed now.
Rob.
On 04/03/2018 04:58 AM, Chih-Wei Huang wrote:
2018-03-28 23:22 GMT+08:00 Rob Herring :
On Wed, Mar 28, 2018 at 10:19 AM, Rob Herring wrote:
On Sat, Mar 17, 2018 at 2:33 PM, Stefan Schake wrote:
Hey John,
On Fri, Mar
Hey again,
Actually, I might as well just push this fix.
Pushed!
Rob.
On 04/03/2018 10:18 AM, Robert Foss wrote:
Hey John,
This looks good to me, feel free to add my:
Reviewed-by: Robert Foss
On 04/03/2018 05:37 AM, John Stultz wrote:
In trying to integrate the new gralloc_handle.h with t
Hey John,
This looks good to me, feel free to add my:
Reviewed-by: Robert Foss
On 04/03/2018 05:37 AM, John Stultz wrote:
In trying to integrate the new gralloc_handle.h with the
drm_hwcomposer, I started seeing the following compilation
errors:
In file included from external/drm_hwcomposer/p
https://bugzilla.kernel.org/show_bug.cgi?id=197327
Stuart Foster (smf.li...@ntlworld.com) changed:
What|Removed |Added
CC||smf.li...@ntlworl
Hi,
These are the remaining patches from my previous patchset to get
Droid 4 (OMAP4) display working. The patches have been rebased to
linux-next tag next-20180329. I skipped the OMAP3 support patches.
They should get their own series, once this patchset has landed.
Working on Droid 4:
* Framebu
Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg
structure") reworked some code inside of this driver and made it select
CONFIG_OF. This results in the entire OF layer being enabled when
building an allmodconfig on ia64. OF on ia64 is completely unsupported
so this isn't a great state
On 02/04/18 11:20 AM, Jerome Glisse wrote:
> The point i have been trying to get accross is that you do have this
> information with dma_map_resource() you know the device to which you
> are trying to map (dev argument to dma_map_resource()) and you can
> easily get the device to which the memory
During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
freed leading to leaking many 128B allocations. Fix the memory leak by
releasing it at teardown time.
To: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Dave Airlie
Cc: sta...@vger.kern
Hi,
On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
> drm_framebuffer already holds per-plane pitch and offsets, which is
> filled out for us when we create the framebuffer. Nuke our local copy in
> the plane struct.
>
> Signed-off-by: Daniel Stone
> Cc: Tomi Valkeinen
Reviewed-b
Hi,
On Fri, Mar 30, 2018 at 03:11:20PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reu
On 30/03/18 01:45 PM, Jerome Glisse wrote:
> Looking at upstream code it seems that the x86 bits never made it upstream
> and thus what is now upstream is only for ARM. See [1] for x86 code. Dunno
> what happen, i was convince it got merge. So yes current code is broken on
> x86. ccing Joerg mayb
This patch uses existing method drm_display_mode_to_videomode for
calculating front/back porches, sync lengths for mediatek dsi/dpi drivers;
instead of manually calculating them
Signed-off-by: Satendra Singh Thakur
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 60 +++-
Merge "rotation" property description into common panel
binding.
Suggested-by: Rob Herring
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/display/panel/panel-common.txt | 12
Documentation/devicetree/bindings/display/panel/panel.txt| 4
2 files changed
On 02/04/18 01:16 PM, Jerome Glisse wrote:
> There isn't good API at the moment AFAIK, closest thing would either be
> lookup_resource() or region_intersects(), but a more appropriate one can
> easily be added, code to walk down the tree is readily available. More-
> over this can be optimize lik
Souptick and I have been auditing the various page fault handler routines
and we've noticed that graphics drivers assume that a signal should be
able to interrupt a page fault. In contrast, the page cache takes great
care to allow only fatal signals to interrupt a page fault.
I believe (but have
This adds support for setting DRM panel orientation property
based on rotation information from the display driver.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 ++
drivers/gpu/drm/omapdrm/omap_connector.c | 34 +++-
2 files chang
This adds a LCD panel rotation hint to the Droid 4. If the
display is rotated this way the keyboard can be used properly.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/omap4-droid4-xt894.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts
b/
omap_framebuffer_get_next_connector() is only required within omap_fb,
so let's make it static. The function had to be moved before the first
(and only) user.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_fb.c | 54 +++
drivers/gpu/drm/omap
From: Sebastian Reichel
Add support to inform the DRM subsystem about the orientation
the display has been mounted to the casing.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/
101 - 200 of 208 matches
Mail list logo
