https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 106209, which changed state.
Bug 106209 Summary: [opencl] [llvm-svn] build failure undefined reference to
`clang::FrontendTimesIsEnabled'
https://bugs.freedesktop.org/show_bug.cgi?id=106209
What|Removed
Hi Linus,
This patch fixes the mmap regression reported to me on irc by an i686
kernel user today, he's tested the fix works, and I've audited all the
drm drivers for the bad mmap usage and since we use the mmap offset as
a lookup in a table we aren't inclined to have anything bad in there.
Hi, Stu:
I've some inline comments.
On Mon, 2018-05-14 at 17:59 +0800, Stu Hsieh wrote:
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
>
> Signed-off-by: Stu Hsieh
> ---
>
From: Gaurav K Singh
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific
DP 1.4 spec defines DP secondary data packet for DSC
picture parameter set. This patch defines its payload size
according to the DP 1.4 specification.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
VESA Display Stream Compression is a specification for visually losless
video compression over display links. The DSC standard also defines
a picture parameter set (PPS) which encoder must communicate to decoders.
This is done by encapsulating PPS header and payload bytes in an infoframe
that can
fs_init = mipi_dbi_debugfs_init,
+ .name = "ili9341",
+ .desc = "Ilitek ILI9341",
+ .date = "20180514",
+ .major = 1,
+ .minor
This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.
A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
anywhere, so I have used "noname" as the vendor prefix. If someone has
This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).
The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in
This fixes the path to the ilitek,ili9225 device tree binding file.
Signed-off-by: David Lechner
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
+++
https://bugs.freedesktop.org/show_bug.cgi?id=104790
--- Comment #5 from i...@yahoo.com ---
How exactly do you enable compat or core profiles?
Afaik Gallium Nine should not be affected by any OpenGL related options...
Also, when wine program crashes and you refuse the dialog (press ESC?), the
From: Stefan Adolfsson
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
throught it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device
https://bugs.freedesktop.org/show_bug.cgi?id=106500
--- Comment #3 from Andrey Grodzovsky ---
(In reply to Bas Nieuwenhuizen from comment #2)
> Created attachment 139568 [details]
> dmesg after trying 139562
>
> I tried the patch and as expected we do not deadlock at
https://bugs.freedesktop.org/show_bug.cgi?id=106500
--- Comment #2 from Bas Nieuwenhuizen ---
Created attachment 139568
--> https://bugs.freedesktop.org/attachment.cgi?id=139568=edit
dmesg after trying 139562
I tried the patch and as expected we do not deadlock at
Hi all,
Commits
cb8ba171ae6c ("drm/i915/gvt: let force_to_nonpriv cmd handler only valid for
LRI cmd")
0438a1059877 ("drm/i915/gvt: do not return error on handling force_to_nonpriv
registers")
3d8b9e258b9d ("drm/i915/gvt: let NOPID be the default value of
force_to_nonpriv registers")
https://bugs.freedesktop.org/show_bug.cgi?id=106519
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 139567
--> https://bugs.freedesktop.org/attachment.cgi?id=139567=edit
Video in Totem player
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106519
--- Comment #2 from mikhail.v.gavri...@gmail.com ---
$ inxi -bM
System:Host: localhost.localdomain Kernel: 4.17.0-0.rc3.git4.1.fc29.x86_64
x86_64 bits: 64
Desktop: Gnome 3.29.1 Distro: Fedora release 29 (Rawhide)
Machine:
https://bugs.freedesktop.org/show_bug.cgi?id=106519
Bug ID: 106519
Summary: Is it normal that the 4K video on the Vega 56 GPU
played with loud turbine noise, 200% load of the
desktop Core i7 CPU and at the same time playable with
Hi,
Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > This adds timings
Hi and thanks for the review!
Le vendredi 11 mai 2018 à 16:36 +0200, Maxime Ripard a écrit :
> On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,297 @@
> > +/*
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
Hi Lin,
2018-05-14 11:53 GMT+02:00 Lin Huang :
> From: Chris Zhong
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong
https://bugs.freedesktop.org/show_bug.cgi?id=106517
--- Comment #1 from Dhinakaran Pandiyan ---
Created attachment 139563
--> https://bugs.freedesktop.org/attachment.cgi?id=139563=edit
SSH public key
--
You are receiving this mail because:
You are the assignee
Hi Andrzej,
On 05/14/2018 12:33 PM, Andrzej Hajda wrote:
> On 14.05.2018 11:38, Philippe CORNU wrote:
>> Hi Laurent, Archit, Andrzej & Yannick,
>>
>> Do you have any comments on this v2 driver part?
>> (more details regarding v1/v2 differences in the cover letter
>>
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #202 from Ioannis Panagiotopoulos ---
Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland
and the right boot arguments. However this worked when I had the R9 390
installed alone.
On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
>
> v2:
> * Moved helper function which attaches
https://bugs.freedesktop.org/show_bug.cgi?id=106500
--- Comment #1 from Andrey Grodzovsky ---
Created attachment 139562
--> https://bugs.freedesktop.org/attachment.cgi?id=139562=edit
Quick try to avoid deadlock
Can u give this a quick try and seed if it helps ?
--
https://bugs.freedesktop.org/show_bug.cgi?id=106517
Bug ID: 106517
Summary: IGT commit rights
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
On Mon, May 14, 2018 at 06:50:28PM +0200, Daniel Vetter wrote:
> On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> > VESA Display Stream Compression is a specification for visually losless
> > video compression over display links. The DSC standard also defines
> > a picture
On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski wrote:
> Dear All,
It is only Thierry that you need to ping. It goes thru his tree as I
mentioned on another panel you sent.
>> This commit adds support for AUO's 7.0" display.
>
> If I may gentle remind about this patch
>
>>
Hi Philippe,
On Monday, 14 May 2018 12:22:16 EEST Philippe CORNU wrote:
> On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
> >> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
> >>> On Wednesday, 25 April 2018
Hi!
> WLED4 peripheral is present on some PMICs like pmi8998
> and pm660l. It has a different register map and also
> configurations are different. Add support for it.
>
> Signed-off-by: Kiran Gunda
> ---
> .../bindings/leds/backlight/qcom-wled.txt | 172 -
>
On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done
On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > Change how dma_fence_add_callback() behaves, when the fence
> > has error-signaled by the time it is being add. After this commit,
> > dma_fence_add_callback() returns the fence error,
On Mon, May 14, 2018 at 1:20 AM, Jagan Teki wrote:
> On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai wrote:
>> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki
>> wrote:
>>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable
On Wed, May 09, 2018 at 04:52:38PM +0200, Boris Brezillon wrote:
> On Mon, 7 May 2018 17:24:08 +0200
> Daniel Vetter wrote:
>
> > On Mon, May 07, 2018 at 04:44:34PM +0200, Boris Brezillon wrote:
> > > Now that the plane code takes the underscan setup into account, we can
> > >
On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote:
> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote:
> > > I haven't seen any comments in the week since I wrote this. I'm not
> > > familiar with the process for the drm changes - so what are the usual next
> > > steps?
On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
>
On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> > Hi Sean,
> >
> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
> > wrote:
> > > Use new return type vm_fault_t for fault handler.
> > >
>
On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
Am 14.05.2018 um 18:00 schrieb Alex Deucher:
On Wed, May 2, 2018 at 10:00 AM, Christian König
wrote:
Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:
From: Dirk Hohndel
This is dual licensed under GPL-2.0 or MIT.
Cc: "Christian König"
On Wed, May 2, 2018 at 10:00 AM, Christian König
wrote:
> Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:
>>
>> From: Dirk Hohndel
>>
>> This is dual licensed under GPL-2.0 or MIT.
>>
>> Cc: "Christian König"
>>
Thank you for the review comments Uma Shankar!
On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To:
SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.
Currently, in dpu driver, all the power resource
management is part of power_handle which
MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.
Also dpu core clock management code is restricted to
dpu_core_perf module.
Changes in v3:
- none
Changes in v2:
- remove local variable to hold and
Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.
Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss
dpu_core_perf_crtc_update() is responsible for aggregating
the data bus bandwidth and dpu core clock rate requirements
and request the same for all active crtcs.
Currently, there is no error handling support in this function
so there is no way caller can know if the perf request fails.
This change
Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.
Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle
SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.
Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.
Add mdss helper interface
Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.
Changes in v3:
- none
Changes in v2:
- resolved conflict in dpu_unbind
- dropped (Reviewed-by: Sean Paul)
DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from
Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.
Changes in v3:
- remove redundant param check from
dpu_power_resource_init() (Sean
The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.
Use pm_runtime_get/put_sync calls on dpu device.
The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via
The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.
Changes in v3:
- none
Changes in v2:
- none
Signed-off-by: Rajesh
MDSS top level device includes the common power resources
and it's corresponding driver (i.e. mdp5_mdss) handles call
to enable/disable runtime_pm for enabling these resources.
Remove redundant pm_runtime_enable call from msm_drv.
Changes in v3:
- none
Changes in v2:
- none
SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes
sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper
manages common resources like common clocks, main power supply and
interrupts for its sub-blocks.
But current dpu driver implementation is based on a flat
On Mon, May 14, 2018 at 05:53:55PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying
On 05/14/2018 04:54 PM, Dirk Hohndel wrote:
On Mon, May 14, 2018 at 07:59:56AM +0200, Thomas Gleixner wrote:
Dirk,
On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote:
License clarifications and SPDX headers for a bunch of files which were
authored by VMware.
This should address the comments
On Mon, May 14, 2018 at 05:53:54PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong
>
https://bugs.freedesktop.org/show_bug.cgi?id=106513
Alex Deucher changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://bugs.freedesktop.org/show_bug.cgi?id=105760
Alex Deucher changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=106513
Bug ID: 106513
Summary: AMDGPU not working on ubuntu 18.04
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On 2018-05-11 20:58, Sean Paul wrote:
On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its
On Friday, April 27, 2018 02:09:31 PM Daniel Vetter wrote:
> On Fri, Apr 27, 2018 at 1:36 PM, Laurent Pinchart
> wrote:
> > Hi Bartlomiej,
> >
> > On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote:
> >> Hi,
> >>
> >> This patchset removes
On Friday, April 27, 2018 05:07:41 PM Heiko Stuebner wrote:
> Am Freitag, 27. April 2018, 13:04:24 CEST schrieb Bartlomiej Zolnierkiewicz:
> > auo_k1900fb and auo_k1901fb drivers have been introduced six
> > years ago by following commits:
> >
> > commit 2c8304d3125b ("video: auo_k190x: add code
On Tue, Apr 24, 2018 at 9:48 AM, Maxime Ripard
wrote:
> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
On Wed, 9 May 2018 10:18:52 -0300
Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is
Hi Eric,
On Tue, Apr 24, 2018 at 09:53:28AM -0700, Eric Anholt wrote:
> Maxime Ripard writes:
>
> > The vc4 HVS uses an internal RGB888 representation of the frames, and will
> > by default expand formats using a lower depth using zeros.
> >
> > This causes an issue
On Tue, Apr 17, 2018 at 07:17:55PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
https://bugs.freedesktop.org/show_bug.cgi?id=106499
--- Comment #2 from Gregor Münch ---
There is another bug Report, bisecting to another commit (which might make more
sense): https://bugs.freedesktop.org/show_bug.cgi?id=106511
Was in a hurry while bisecting it, cant test
On Mon, May 14, 2018 at 01:34:27PM +0300, Dmitry Osipenko wrote:
> On 14.05.2018 13:13, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> > sure that this cache is available, obtain a reference to it
On 14.05.2018 11:38, Philippe CORNU wrote:
> Hi Laurent, Archit, Andrzej & Yannick,
>
> Do you have any comments on this v2 driver part?
> (more details regarding v1/v2 differences in the cover letter
> https://www.spinics.net/lists/dri-devel/msg174137.html)
>
> Thank you,
> Philippe :-)
>
>
> On
https://bugs.freedesktop.org/show_bug.cgi?id=106490
--- Comment #1 from Leonid Maksymchuk ---
It looks like it's Chromium or VA-API bug, but not Mesa.
Chromium VA-API decoding works with Mesa 18.0 if RGB10 visual configs is
disabled.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=106496
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://bugs.freedesktop.org/show_bug.cgi?id=106245
Michel Dänzer changed:
What|Removed |Added
CC||c...@atamisk.net
https://bugs.freedesktop.org/show_bug.cgi?id=106496
Michel Dänzer changed:
What|Removed |Added
Attachment #139536|text/x-log |text/plain
From: Thierry Reding
The IOVA API uses a memory cache to allocate IOVA nodes from. To make
sure that this cache is available, obtain a reference to it and release
the reference when the cache is no longer needed.
On 64-bit ARM this is hidden by the fact that the DMA mapping
On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote:
Hi Daniel,
> On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau wrote:
> > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote:
> >> >
On Mon, May 14, 2018 at 10:19:27AM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> >Status register contains a lot of bits for reporting internal errors
> >inside Mali DP. Currently, we just silently ignore all of the erorrs,
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=97025
--- Comment #28 from Michel Dänzer ---
(In reply to Bernd Steinhauser from comment #27)
>
> Although I'm not sure if it works as expected, since the display does still
> seem to disconnect when I turn the screen off.
AFAIK
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
Hi Laurent, Archit, Andrzej & Yannick,
Do you have any comments on this v2 driver part?
(more details regarding v1/v2 differences in the cover letter
https://www.spinics.net/lists/dri-devel/msg174137.html)
Thank you,
Philippe :-)
On 04/25/2018 09:53 AM, Philippe Cornu wrote:
> Add the
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
Hi Rob & Laurent :)
On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> Hi Rob,
>
> On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
>> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
>>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
On
Hi Alex,
On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the erorrs,
Being picky: s/erorrs/errors/
that doesn't help when we are investigating
On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the erorrs,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
Hi,
> > So my expectation that a backmerge happens anyway after -rc1/2 is in
> > line with reality, it is just to be delayed this time. I'll stay
> > tuned ;)
>
> Is this patch already merged in drm-misc-next tree ?
Pushed now.
cheers,
Gerd
___
On Mon, Apr 23, 2018 at 11:43:16AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 11:41, Dmitry Osipenko wrote:
> > On 23.04.2018 11:34, Dmitry Osipenko wrote:
> >> On 23.04.2018 09:57, Thierry Reding wrote:
> >>> From: Thierry Reding
> >>>
> >>> The IOVA API uses a memory
On Mon, Apr 23, 2018 at 11:35:14AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 09:57, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The original code works fine, this is merely a cosmetic change to make
> > the teardown order the reverse of the setup order.
> >
>
On Mon, Apr 23, 2018 at 12:54:56PM +0300, Dmitry Osipenko wrote:
> If IOVA allocation or IOMMU mapping fails, dma_free_wc() is invoked with
> size=0 because of a typo, that triggers "kernel BUG at mm/vmalloc.c:124!".
>
> Signed-off-by: Dmitry Osipenko
> ---
>
On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> The compiler is complaining with the following errors:
>
> drivers/gpu/host1x/cdma.c:94:48: error:
> passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>
>
On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> + hdmi_phy: hdmi-phy@1ef {
> >> +
1 - 100 of 117 matches
Mail list logo