Am 10.09.2018 um 02:57 schrieb jgli...@redhat.com:
From: Jérôme Glisse
[This depends on some HMM patchset queued upstream see branch [1]]
This is simple change to switch to use HMM for user ptr buffer object
which conveniently avoid to pin pages. I have more things in the pipe
to make HMM more
The A64 HDMI PHY seems to be not able to use the second video PLL as
clock parent in experiments.
Drop the support for the second PLL from A64 HDMI PHY driver.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/
The Allwinner R40 HDMI PHY is currently the only one that seems to be
able to select between two PLL inputs.
Add a compatible string for it, and the pll-1 clock input definition.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
1 file chan
The R40 SoC has a HDMI PHY that is possible to mux two video PLLs.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_
Now as Amstrad Delta board - the only user of this driver - provides
GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
use the table to locate required GPIO pins.
Declare static variables for storing GPIO descriptors and replace
gpio_ function calls with their gpiod_ equivalents
Hi Rob,
2018-09-05 21:37 GMT+02:00 Rob Herring :
> This series adds an iterator for cpu nodes and converts users over to use
> it or of_get_cpu_node in some cases. This allows us to remove the
> dependency on device_type property for cpu nodes though removing that
> from DTS files will have to wa
On Wed, Aug 8, 2018 at 9:43 PM Souptick Joarder wrote:
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> saved_state in tilcdc_drm_private will not be used
> anymore, so it can be removed.
Any comment on this patch ?
>
> Signed-off-by: Ajit Negi
When adding support for A64 HDMI PHY in 4.19, we assumed that the two
PLL-VIDEOs can both feed the HDMI PHY clock. However experiments show
that the mux bit discovered in R40 blob is not applicable on A64. This
is not discovered, as normally with a single display pipeline only
PLL-VIDEO0 will be us
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_win2 data struct may very well need to be updated
with some ex
Now as Amstrad Delta board - the only user of this driver - provides
GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
use the table to locate required GPIO pins.
Declare static variables for storing GPIO descriptors and replace
gpio_ function calls with their gpiod_ equivalents
As noticed by kbuild test robot ,
remove_conflicting_pci_framebuffers()'s second argument
is called res_id not resource_id. Fix this.
Signed-off-by: Michał Mirosław
---
* Against drm-misc-next, as that's where original patchset went to.
v2: include second occurrence of @resource_id
---
drivers
By experiments it seems that the A64 HDMI PHY is not able to use the
second video PLL as the clock parent.
Drop pll-1 from the device tree binding of A64 HDMI PHY.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 -
1 file changed, 1 deletion(-)
The value in the wrong position will cause misunderstanding,
when the debug infomations display in the window.
Signed-off-by: jun qian
---
drivers/staging/android/ion/ion_system_heap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_system_
Copy remove*_conflicting_framebuffers() kerneldocs from fbdev code
to make DRM developers' life easier.
Signed-off-by: Michał Mirosław
---
* Against drm-misc-next.
---
include/drm/drm_fb_helper.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/drm/drm_fb_hel
As noticed by kbuild test robot ,
remove_conflicting_pci_framebuffers()'s second argument
is called res_id not resource_id. Fix this.
Signed-off-by: Michał Mirosław
---
* Against drm-misc-next, as this is the branch original patchset was
applied to.
---
drivers/video/fbdev/core/fbmem.c | 2 +-
On 7 September 2018 at 15:11, Jon Hunter wrote:
>
> On 11/07/18 15:43, Arnd Bergmann wrote:
>> Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results in
>> a link error, as we try to access a symbol from the sun8i_tcon_top.ko module:
>>
>> ERROR: "sun8i_tcon_top_of_table" [driv
This is a follow up of initial submission of a series consisted of
6 changes, 3 of which have been already applied or reworkeed.
Janusz Krzysztofik (3):
video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table
mtd: rawnand: ams-delta: use GPIO lookup table
ARM: OMAP1: ams-de
Now as board header file is no longer included by drivers, move it to
the root directory of mach-omap1.
Signed-off-by: Janusz Krzysztofik
---
arch/arm/mach-omap1/ams-delta-fiq-handler.S | 2 +-
arch/arm/mach-omap1/ams-delta-fiq.c | 3 +--
arch/arm/mach-omap1/boa
On 8/2/18 12:51 PM, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping! Who can take this?
>
> Thanks
> --
> Gustavo
>
> On 07/24/2018 08:27 AM, Gustavo A. R. Silva wrote:
>> In case memory resources for *bl_desc* were allocated, release
>> them before return.
>>
>> Addresses-Coverity-ID: 14
Add an initial kerneldoc entry for vkms with a todo list.
Signed-off-by: Haneen Mohammed
---
Documentation/gpu/drivers.rst | 1 +
Documentation/gpu/todo.rst | 12
Documentation/gpu/vkms.rst | 21 +
drivers/gpu/drm/vkms/vkms_drv.c | 9 +
4 fi
Hi All,
This series fixes (works around) the gpd win 2's eDP panel being a
portait mode panel being used in a landscape case (clamshell model).
I plan to merge the i915 bit through dinq and the actual quirk through
drm-misc. These 2 are related in the sense that the quirk will not do
anything wit
On Mon, Aug 6, 2018 at 11:42 AM Souptick Joarder wrote:
>
> On Wed, Aug 1, 2018 at 1:37 AM, Souptick Joarder wrote:
> > convert drm_atomic_helper_suspend/resume() to use
> > drm_mode_config_helper_suspend/resume().
> >
> > With this conversion, tegra_drm_fb_suspend() and
> > tegra_drm_fb_resume()
The R40 HDMI PHY seems to be different to the A64 one, the A64 one
has no input mux, but the R40 one has.
Drop the A64 fallback compatible from the HDMI PHY node in R40 DT.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
The requirement is to render interlaced alternate buffers. In case of
alternate, top field and bottom field are in two different buffers.
The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
and DRM_MODE_PRESENT_TOP_FIELD to DRM_IOCTL_MODE_SETPLANE ioctl?
But in case if urrent fr
So far we have only been calling
drm_connector_init_panel_orientation_property(), which checks for
panel orientation quirks in the drm_panel_orientation_quirks.c file,
for DSI panels as so far only devices with DSI panels have had panels
which are not mounted up right.
The new GPD win2 device uses
On Mon, Sep 10, 2018 at 12:55 AM Janusz Krzysztofik wrote:
> Now as Amstrad Delta board - the only user of this driver - provides
> GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
> use the table to locate required GPIO pins.
>
> Declare static variables for storing GPIO desc
Hi Sam,
On Sat, 8 Sep 2018 22:17:55 +0200
Sam Ravnborg wrote:
> Hi all.
>
> When working on the DRM driver for Atmel LCDC the first approach
> was to use a MFD driver, that had two sub-drivers:
> - PWM dirver
> - DRM driver
>
> Feedback was that the PWM feature was too small to warrant a MFD d
On Sat, Sep 08, 2018 at 03:46:43PM +0200, Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_fu
On 10/09/18 09:45, Souptick Joarder wrote:
> On Wed, Aug 8, 2018 at 9:43 PM Souptick Joarder wrote:
>>
>> convert drm_atomic_helper_suspend/resume() to use
>> drm_mode_config_helper_suspend/resume().
>>
>> saved_state in tilcdc_drm_private will not be used
>> anymore, so it can be removed.
>
> An
Only specific N value (0x8000) would be acceptable for LG
LP140WF6-SPM1 eDP panel which is running at asynchronous
clock mode. With the other N value, it will enter BITS mode
and display black screen. This patch series set constant N
value for specific sink/branch device that would cover
similar is
DP quirk list just compare sink or branch device's OUI so far.
That means particular vendor's products will be applied specific
change. This change would confirm device_id the same or not.
Then driver can implement some changes for branch/sink device
that really need additional WA.
Cc: Jani Nikula
The N value was computed by kernel driver that based on synchronous clock
mode. But only specific N value (0x8000) would be acceptable for
LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
With the other N value, Tcon will enter BITS mode and display black screen.
Add this pan
Some DP dongles in particular seem to be fussy about too large
link M/N values. Set specific value for N divider can resolve
this issue per dongle vendor's comment. So configure N as
constant value (0x8000) to instead of reduce M/N formula when
specific DP dongle connected.
Cc: Jani Nikula
Cc: Co
On 09/06/2018 01:38 AM, Deepak Rawat wrote:
Add a new struct vmw_du_update_plane similar to vmw_kms_dirty which
represent the flow of operations needed to update a display unit from
surface or bo(blit a new framebuffer).
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10
On 09/06/2018 01:38 AM, Deepak Rawat wrote:
With new interface to do plane update on STDU available, use that
instead of old kms_dirty. Update the commet to sync with code.
s/commet/comment/
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 38 +++---
On 09/06/2018 01:38 AM, Deepak Rawat wrote:
STDU primary plane now support damage clips, enable it for user-space.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/
On Mon, 10 Sep 2018, Thomas Hellstrom wrote:
> On 09/06/2018 01:38 AM, Deepak Rawat wrote:
>> +/**
>> + * vmw_du_helper_plane_update - helper to do plane update on display unit
>> + *
>> + * @update: The closure structure.
>> + *
>> + * RETURNS:
>> + *
>> + * 0 on success or a negative error code
https://bugs.freedesktop.org/show_bug.cgi?id=107880
Bug ID: 107880
Summary: Regression: System fails to boot on raven ridge 4.18
vs 4.19 rc
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (A
/Gerd-Hoffmann/drm-refuse-ADDFB2-ioctl-for-broken-bigendian-drivers/20180910-142802
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
Hi Greg
Am 02.08.2018 um 09:29 schrieb Greg KH:
> On Tue, Jul 31, 2018 at 08:37:35AM +0200, Thomas Zimmermann wrote:
>> The function ttm_bo_put releases a reference to a TTM buffer object. The
>> function's name is more aligned to the Linux kernel convention of naming
>> ref-counting function _get
On Mon, Sep 10, 2018 at 10:39:57AM +0200, Thomas Zimmermann wrote:
> Hi Greg
>
> Am 02.08.2018 um 09:29 schrieb Greg KH:
> > On Tue, Jul 31, 2018 at 08:37:35AM +0200, Thomas Zimmermann wrote:
> >> The function ttm_bo_put releases a reference to a TTM buffer object. The
> >> function's name is more
Hi,
On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote:
On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote:
Hi Daniel,
On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote:
> On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote:
> > Some formats have a n
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian K??nig
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/
The tbo pointer will still have value even the amdgpu bo is freed.
It doesn't make sense that it still points a freed memory. It could be refered
mistakenly, so set it as null.
Signed-off-by: Huang Rui
Cc: Christian K??nig
Cc: Tom StDenis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
1
Hi Ray,
well those patches doesn't make sense, the pointer is only local to the
function.
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo
Am Sonntag, 5. August 2018, 14:48:07 CEST schrieb Marc Zyngier:
> Leaving the DRM driver enabled on reboot or kexec has the annoying
> effect of leaving the display generating transactions whilst the
> IOMMU has been shut down.
>
> In turn, the IOMMU driver (which shares its interrupt line with
>
https://bugs.freedesktop.org/show_bug.cgi?id=107880
Michel Dänzer changed:
What|Removed |Added
Attachment #141500|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #1 from Michel Dänzer ---
(In reply to Marvin Damschen from comment #0)
> System hangs after "fb: switching to amdgpudrmfb from EFI VGA".
How long have you waited for? E.g. if a microcode file is missing, the attempt
to load it can
https://bugs.freedesktop.org/show_bug.cgi?id=107784
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
> Hi Ray,
>
> well those patches doesn't make sense, the pointer is only local to
> the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = &b
The rk3328 uses a dw-hdmi controller with an external hdmi phy from
Innosilicon which uses the generic phy framework for access.
Add the necessary data and the compatible for the rk3328 to the
rockchip dw-hdmi driver.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
Acked-by: Rob Herring
In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
vendor-type phy from Innosilicon but still report the HDMI20_TX type.
So allow the glue driver to force the vendor-phy for these cases.
In the future it may
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct.
As the chip-data that occupies the phy_data pointer initially gets
assigned to the rockchip_hdmi struct, we can now re-use this phy_data
pointer to hold the reference to the rockchip_hdmi struct and use
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy
from Innosilicon that resides completely separate from the dw-hdmi block
and gets accessed via mmio.
Additionally the rk3328 dw-hdmi does not report the vendor-phy type
but a different one instead, so add the possibility to ove
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general
mmio, so allow these to be referenced via the regular phy interfaces
and therefore add optional phy-related properties to the binding.
Signed-off-by: Heiko Stuebner
Reviewed-by: Rob Herring
---
.../devicetree/bindings/disp
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that no output-switchi
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. Thi
2018-09-08 15:46 GMT+02:00 Noralf Trønnes :
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_cha
https://bugs.freedesktop.org/show_bug.cgi?id=107876
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107858
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
https://bugs.freedesktop.org/show_bug.cgi?id=107863
Michel Dänzer changed:
What|Removed |Added
Attachment #141478|text/x-log |text/plain
mime type|
On Mon, Sep 10, 2018 at 1:11 PM Jyri Sarha wrote:
>
> On 10/09/18 09:45, Souptick Joarder wrote:
> > On Wed, Aug 8, 2018 at 9:43 PM Souptick Joarder
> > wrote:
> >>
> >> convert drm_atomic_helper_suspend/resume() to use
> >> drm_mode_config_helper_suspend/resume().
> >>
> >> saved_state in tilcd
https://bugs.freedesktop.org/show_bug.cgi?id=107855
--- Comment #9 from Pontus Gråskæg ---
Just to be clear, booting with kernel 4.19rc2 does indeed remove the "*ERROR*
VCE not responding, giving up!!!" and associated messages. So that can be
marked solved (I think).
However, there is still a reg
https://bugs.freedesktop.org/show_bug.cgi?id=107855
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #2 from Marvin Damschen ---
(In reply to Michel Dänzer from comment #1)
> (In reply to Marvin Damschen from comment #0)
> > System hangs after "fb: switching to amdgpudrmfb from EFI VGA".
>
> How long have you waited for? E.g. if a
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #3 from Marvin Damschen ---
Created attachment 141502
--> https://bugs.freedesktop.org/attachment.cgi?id=141502&action=edit
Modprobe amdgpu freezes video output with 4.19-rc3
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #4 from Michel Dänzer ---
Looks like there may be an issue with the VCN microcode loading. Does
amdgpu.ip_block_mask=0xff
on the kernel command line avoid the problem?
Can you bisect?
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=107595
Pontus Gråskæg changed:
What|Removed |Added
CC||graaskaeg.via.forwarder@nev
https://bugs.freedesktop.org/show_bug.cgi?id=107880
--- Comment #5 from Marvin Damschen ---
(In reply to Michel Dänzer from comment #4)
> Looks like there may be an issue with the VCN microcode loading. Does
>
> amdgpu.ip_block_mask=0xff
>
> on the kernel command line avoid the problem?
It doe
Add gamma_lut/degamma_lut/ctm checking before pushing
staged color management properties on the CRTC.
If above object is NULL, return directly.
Signed-off-by: Aaron Liu
---
src/drmmode_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/drmmode_display.c b/src/drmm
https://bugs.freedesktop.org/show_bug.cgi?id=107880
Marvin Damschen changed:
What|Removed |Added
Attachment #141500|0 |1
is obsolete|
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> DP quirk list just compare sink or branch device's OUI so far.
> That means particular vendor's products will be applied specific
> change. This change would confirm device_id the same or not.
> Then driver can implement some changes for branch/sink dev
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> Some DP dongles in particular seem to be fussy about too large
> link M/N values. Set specific value for N divider can resolve
> this issue per dongle vendor's comment. So configure N as
> constant value (0x8000) to instead of reduce M/N formula when
>
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> The N value was computed by kernel driver that based on synchronous clock
> mode. But only specific N value (0x8000) would be acceptable for
> LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
> With the other N value, Tcon will en
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
> Am 10.09.2018 um 11:23 schrieb Huang Rui:
> > On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
> >> Hi Ray,
> >>
> >> well those patches doesn't make sense, the pointer is only local to
> >> the function.
> > You'r
Hi Pavel,
(dropping Dave, no need to spam him)
On 30/08/18 12:04, Pavel Machek wrote:
> Hi!
>
> There's neat series of patches on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19
>
> They enable display support for my hardware. As you can im
On Fri, Sep 07, 2018 at 02:46:21PM -0700, Satish Kumar Nagireddy wrote:
> The requirement is to render interlaced alternate buffers. In case of
> alternate, top field and bottom field are in two different buffers.
>
> The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
> and DRM
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
> Am 10.09.2018 um 11:23 schrieb Huang Rui:
> > On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
> >> Hi Ray,
> >>
> >> well those patches doesn't make sense, the pointer is only local to
> >> the function.
> > You'r
Hi Gerd,
Thank you for the patch.
CC'ing the linux-api mailing list as this creates a new userspace API.
On Monday, 27 August 2018 12:34:44 EEST Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer o
Hello,
On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote:
> Hi Pavel,
>
> (dropping Dave, no need to spam him)
>
> On 30/08/18 12:04, Pavel Machek wrote:
> > Hi!
> >
> > There's neat series of patches on
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.gi
On Sun, Sep 09, 2018 at 02:03:57PM +0200, Daniel Vetter wrote:
> On Sat, Sep 08, 2018 at 03:58:53PM +0200, Neil Armstrong wrote:
> > Hi Ayan,
> >
> > On 10/07/2018 15:18, Ayan Kumar Halder wrote:
> > > In the current series of patches, we are trying to add support for AFBC
> > > modifiers in malid
On 07/09/18 12:42, Maxime Ripard wrote:
> On Fri, Sep 07, 2018 at 01:26:30PM +0200, Arnd Bergmann wrote:
>> On Fri, Sep 7, 2018 at 11:41 AM Jon Hunter wrote:
>>>
>>>
>>> On 11/07/18 15:43, Arnd Bergmann wrote:
Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results
i
https://bugs.freedesktop.org/show_bug.cgi?id=103300
--- Comment #3 from Ian Bruene ---
(In reply to Timothy Arceri from comment #2)
> Hi Ian,
>
> Is this still a problem with a recent version of Mesa?
Tested with a just updated ubuntu 18.04 + padoka unstable. The problem still
exists.
> If so
On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> This was only added for the drm's fbdev emulation support, so that it
> would try harder to show the Oops.
>
> Unfortunately this never really worked reliably, and in practice ended
> up pushing the real Oops off the screen due to plentyfull locking,
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
t
On 08/22/2018 10:54 AM, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics bu
Den 10.09.2018 09.28, skrev Maxime Ripard:
On Sat, Sep 08, 2018 at 03:46:43PM +0200, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callba
Hi Christian,
Are you adding new traces or turning on existing ones? Would you like
me to try them out in my setup?
Tom
On 2018-09-10 8:49 a.m., Christian König wrote:
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.201
Den 10.09.2018 14.31, skrev Alexey Brodkin:
Hi Noralf,
On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client
Den 09.09.2018 16.13, skrev Laurent Pinchart:
Hi Noralf,
Thank you for the patch.
On Saturday, 8 September 2018 16:46:35 EEST Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbd
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Am 10.09.2018 um 14:59 schrieb Tom St Denis:
Hi Christian,
Are you adding new traces or turning on existing ones? Would you like
me to try them out in my setup?
Tom
On 2018-
On 2018-09-10 9:04 a.m., Christian König wrote:
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Hi Christian,
Sure, if you want to send me a simple patch that adds more printk I'll
gladly give it a try (doubly so since my wo
Am 10.09.2018 um 15:05 schrieb Tom St Denis:
On 2018-09-10 9:04 a.m., Christian König wrote:
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Hi Christian,
Sure, if you want to send me a simple patch that adds more printk I'l
Lots of code can be removed by relying on fb-helper:
- "struct drm_framebuffer" moves to fb_helper.fb.
- "struct drm_gem_object" moves to fb_helper.obj[0].
- "struct qxl_device" can be inferred as drm_fb_helper is embedded.
- qxl_user_framebuffer_create -> drm_gem_fb_create.
- qxl_user_framebuffer_
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.18.0-rc7, 4.18.5, 4.18.6, |4.18.0-rc7, 4.
https://bugs.freedesktop.org/show_bug.cgi?id=107855
Pontus Gråskæg changed:
What|Removed |Added
CC||graaskaeg.via.forwarder@nev
Hi,
Thanks for reporting this issue.
On 08/09/2018 18:48, MOHAMMAD RASIM wrote:
> Hi,
>
> I've an issue where the drm_meson driver doesn't work, it used to work in
> earlier 4.18 release and stopped working after about 4.18-rc3.
>
> My board is videostrong k2 pro (S905 SoC), I use the meson-gx
On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote:
> On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote:
> > Some formats have a non-integer number of bytes per pixel, which can't
> > be handled with the existing 'cpp' field in drm_format_info. To handle
> > these formats, ad
1 - 100 of 160 matches
Mail list logo
