"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds
Andrew brought up a reasonable concern with the CMA heap
enumeration in the previous patch set, and I had a few other
minor cleanups to add, so here is yet another pass at the
dma-buf heaps patchset Andrew and I have been working on which
tries to destage a fair chunk of ION functionality.
The
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin
On 2019-10-17 19:00, Lee Jones wrote:
On Thu, 17 Oct 2019, kgu...@codeaurora.org wrote:
On 2019-10-17 17:56, Lee Jones wrote:
> On Wed, 16 Oct 2019, Kiran Gunda wrote:
>
> > The auto string detection algorithm checks if the current WLED
> > sink configuration is valid. It tries enabling every
https://bugs.freedesktop.org/show_bug.cgi?id=112017
--- Comment #4 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* TGL: igt@kms_psr@*|igt@gem__* - fail - Failed assertion: data.bufmgr
-
5.3.4-300.fc31.x86_64
seems to be new.
https://retrace.fedoraproject.org/faf/reports/2726149/
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Oct 16, 2019 at 07:44:51PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2019 at 6:13 PM Andy Shevchenko
> wrote:
> > On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> > max_transfer_size should be a function. In that case it works.
>
> Why do you want to make it a
On Wed, 16 Oct 2019, Jacopo Mondi wrote:
> Hi, sorry for not having replied earlier
>
> On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote:
> > On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote:
> >
> > > > arch/sh/boards/mach-ecovec24/setup.c | 33 --
> > >
> > > I guess
On Thu, Oct 17, 2019 at 08:44:26AM +0200, Daniel Vetter wrote:
> In DMA mode we have a maximum transfer size, past that the driver
> falls back to PIO (see the check at the top of pxa2xx_spi_transfer_one).
> Falling back to PIO for big transfers defeats the point of a dma engine,
> hence set the
On 10/16/19 6:14 PM, Russell King - ARM Linux admin wrote:
> On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
>> From: Dariusz Marcinkiewicz
>>
>> Use the new cec_notifier_conn_(un)register() functions to
>> (un)register the notifier for the HDMI connector.
>>
>> Signed-off-by:
On Wed, 16 Oct 2019 15:23:45 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 16.10.19 um 15:05 schrieb Pekka Paalanen:
> > specifically be available in production. So a new file in some fs
> > somewhere it should be, and userspace in production can read it at will
> > to attach to a bug report.
> >
In DMA mode we have a maximum transfer size, past that the driver
falls back to PIO (see the check at the top of pxa2xx_spi_transfer_one).
Falling back to PIO for big transfers defeats the point of a dma engine,
hence set the max transfer size to inform spi clients that they need
to do something
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #100 from Andrew Sheldon ---
I'll add that the SDMA fixes don't help for me either. mpv + gpu-hq profile
(OGL) reproduces the issue the most reliably, albeit still randomly.
--
You are receiving this mail because:
You are the
On 10/17/19 9:03 AM, Hans Verkuil wrote:
> On 10/16/19 6:14 PM, Russell King - ARM Linux admin wrote:
>> On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
>>> From: Dariusz Marcinkiewicz
>>>
>>> Use the new cec_notifier_conn_(un)register() functions to
>>> (un)register the notifier
On Thu, Oct 17, 2019 at 8:30 AM Adam Ford wrote:
>
> On Thu, Oct 17, 2019 at 6:11 AM Thierry Reding
> wrote:
> >
> > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > On 17. 10. 19 10:10, Uwe
From: Michael Hennerich
The SEPS525 is a 160 RGB x 128 Dots, 262K Colors PM-OLED Display Driver and
Controller.
The controller can be found on the NHD-1.69-160128UGC3
(Newhaven Display International, Inc.).
Datasheets:
Link: https://www.newhavendisplay.com/appnotes/datasheets/OLEDs/SEPS525.pdf
On Wed, Oct 16, 2019 at 09:55:11AM -0500, Adam Ford wrote:
> On Wed, Oct 16, 2019 at 9:40 AM Laurent Pinchart
> wrote:
> >
> > Hi Adam,
> >
> > Thank you for the patch.
> >
> > On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote:
> > > This patch adds documentation of device tree bindings
On Thu, Oct 17, 2019 at 9:37 AM Rob Herring wrote:
>
> On Wed, Oct 16, 2019 at 09:55:11AM -0500, Adam Ford wrote:
> > On Wed, Oct 16, 2019 at 9:40 AM Laurent Pinchart
> > wrote:
> > >
> > > Hi Adam,
> > >
> > > Thank you for the patch.
> > >
> > > On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam
This splits the previous v7.2 patch (1) into two parts: one that replaces
cec_notifier_get/put by cec_notifier_conn_(un)register, and one that
sets the connector info.
That second patch moves the CEC notifier code to tda998x_bridge_detach,
but Laurent is making changes in that area and prefers
From: Dariusz Marcinkiewicz
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 9 -
1 file changed, 4 insertions(+), 5
From: Dariusz Marcinkiewicz
Fill in the cec_connector_info when calling cec_notifier_conn_register().
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 33 +++
1 file changed, 25
Hi Dave and Daniel,
Here goes drm-intel-fixes-2019-10-17:
- Display fix on handling VBT information.
- Important circular locking fix
- Fix for preemption vs resubmission on virtual requests
- and a prep patch to make this last one to apply cleanly
Thanks,
Rodrigo.
The following changes
On Wed, Oct 16, 2019 at 04:00:25PM -0400, Alex Deucher wrote:
> On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote:
> >
> > I've kicked this around in my head over the past few weeks but wanted
> > to get some feedback on whether it's a good idea or what impact it
> > might have that I haven't
On Thu, Oct 17, 2019 at 05:00:54PM +0300, Andy Shevchenko wrote:
> On Thu, Oct 17, 2019 at 09:10:52AM -0400, Sean Paul wrote:
> > On Thu, Oct 17, 2019 at 02:49:12PM +0300, Andy Shevchenko wrote:
> > > GCC complains about dubious bitwise OR operand:
> > >
> > >
On Thu, Oct 17, 2019 at 3:11 AM Uwe Kleine-König
wrote:
>
> A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> pwm_get_state() return the last implemented state")) changed the
> semantic of pwm_get_state() and disclosed an (as it seems) common
> problem in lowlevel PWM drivers.
On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
> On 17. 10. 19 14:59, Thierry Reding wrote:
> > On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > > > On Thu, Oct 17, 2019 at 12:11:16PM +0200,
On Wed, 16 Oct 2019 10:55:41 +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
>
On Thu, Oct 17, 2019 at 9:58 AM Daniel Vetter wrote:
>
> On Wed, Oct 16, 2019 at 04:00:25PM -0400, Alex Deucher wrote:
> > On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote:
> > >
> > > I've kicked this around in my head over the past few weeks but wanted
> > > to get some feedback on whether
On Thu, 17 Oct 2019 18:48:33 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and
Am 16.10.19 um 14:18 schrieb Christian König:
> Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
>> Factor out ttm vma setup to a new function.
>> Reduces code duplication a bit.
>>
>> v2: don't change vm_flags (moved to separate patch).
>> v4: make ttm_bo_mmap_vma_setup static.
>>
>> Signed-off-by:
On Tue, Oct 15, 2019 at 09:18:16PM +0200, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner
>
> CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> Both PREEMPT and PREEMPT_RT require the same functionality which today
> depends on CONFIG_PREEMPT.
>
> Switch the
On 2019-10-17 16:39, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:45PM +0530, Kiran Gunda wrote:
Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
On Thu, Oct 17, 2019 at 11:06:33AM +, Koenig, Christian wrote:
> Am 16.10.19 um 14:18 schrieb Christian König:
> > Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
> >> Factor out ttm vma setup to a new function.
> >> Reduces code duplication a bit.
> >>
> >> v2: don't change vm_flags (moved to
On Thu, 17 Oct 2019, Daniel Thompson wrote:
> On Tue, Oct 15, 2019 at 09:18:16PM +0200, Sebastian Andrzej Siewior wrote:
> > From: Thomas Gleixner
> >
> > CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> > Both PREEMPT and PREEMPT_RT require the same functionality
On 2019-10-17 14:23:24 [+0100], Lee Jones wrote:
> So what are the OP's expectations in that regard? I see this is a
> large set and I am only privy to this patch, thus lack wider
> visibility. Does this patch depend on others, or is it independent?
> I'm happy to take it, but wish to avoid
On Thu, Oct 17, 2019 at 05:47:47PM +0530, kgu...@codeaurora.org wrote:
> On 2019-10-17 16:59, Daniel Thompson wrote:
> > On Wed, Oct 16, 2019 at 03:43:46PM +0530, Kiran Gunda wrote:
> > > The auto string detection algorithm checks if the current WLED
> > > sink configuration is valid. It tries
On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology
China) wrote:
> On Thu, Oct 17, 2019 at 08:20:56AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Wed, Oct 16, 2019 at 04:22:07PM +,
On Wed, Oct 16, 2019 at 03:43:45PM +0530, Kiran Gunda wrote:
> Handle the short circuit interrupt and check if the short circuit
> interrupt is valid. Re-enable the module to check if it goes
> away. Disable the module altogether if the short circuit event
> persists.
>
> Signed-off-by: Kiran
On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state() return the last
Make the following items static to avoid clashes with
other parts of the kernel (dev_attr_core_id) or just
silence the following sparse warning:
drivers/gpu/drm/arm/malidp_drv.c:371:24: warning: symbol 'malidp_fb_create' was
not declared. Should it be static?
On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> pwm_get_state() return the last implemented state")) changed the
> semantic of pwm_get_state() and disclosed an (as it seems) common
> problem in lowlevel PWM
On 2019-10-17 16:59, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:46PM +0530, Kiran Gunda wrote:
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it
On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
wrote:
>
> On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state() return
On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
>
> On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> wrote:
> >
> > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > > A previous change in the pwm
Hi Laurent,
On Wed, Oct 16, 2019 at 04:45:26PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen3 SoCs, each DU
On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
> On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> > On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > > On 17. 10. 19 10:10,
On Thu, Oct 17, 2019 at 07:40:47AM -0500, Adam Ford wrote:
> On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
> >
> > On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> > wrote:
> > >
> > > On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > > > On Thu, Oct 17, 2019 at
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More
Add support to parse mdev class id table.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/vfio/mdev/vfio_mdev.c
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c | 12 +++
include/linux/mdev.h | 4 +
include/linux/virtio_mdev.h | 151 ++
3
On Wed, Oct 16, 2019 at 03:43:44PM +0530, Kiran Gunda wrote:
> WLED4 peripheral is present on some PMICs like pmi8998 and
> pm660l. It has a different register map and configurations
> are also different. Add support for it.
There is code buried in this patch that looks like it changes the name
On Thu, Oct 17, 2019 at 10:48:12AM +, Brian Starkey wrote:
> On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology
> China) wrote:
> > On Thu, Oct 17, 2019 at 08:20:56AM +, Brian Starkey wrote:
> > > On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm
https://bugzilla.kernel.org/show_bug.cgi?id=205147
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Revert queued:
https://lists.freedesktop.org/archives/amd-gfx/2019-October/041381.html
Should land this week.
--
You are receiving this mail because:
You are watching the assignee of
On Thu, Oct 17, 2019 at 3:11 AM Uwe Kleine-König
wrote:
>
> A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> pwm_get_state() return the last implemented state")) changed the
> semantic of pwm_get_state() and disclosed an (as it seems) common
> problem in lowlevel PWM drivers.
On Thu, Oct 17, 2019 at 8:05 AM Thierry Reding wrote:
>
> On Thu, Oct 17, 2019 at 07:40:47AM -0500, Adam Ford wrote:
> > On Thu, Oct 17, 2019 at 7:34 AM Adam Ford wrote:
> > >
> > > On Thu, Oct 17, 2019 at 7:19 AM Uwe Kleine-König
> > > wrote:
> > > >
> > > > On Thu, Oct 17, 2019 at 12:47:27PM
On 2019-10-17 17:56, Lee Jones wrote:
On Wed, 16 Oct 2019, Kiran Gunda wrote:
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it detects and enables the
Switch qxl driver to the new mmap workflow,
some cleanups, reduce memory fragmentation.
Series needs latest drm-misc-next to build.
Gerd Hoffmann (5):
drm/qxl: drop qxl_ttm_fault
drm/qxl: switch qxl to _gem_object_funcs.mmap
drm/qxl: drop verify_access
drm/qxl: use DEFINE_DRM_GEM_FOPS()
Not needed any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 629ac8e77a21..54cc5a5b607e 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++
We have no qxl-specific fops any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 65464630ac98..1d601f57a6ba 100644
---
Not sure what this hook is supposed to do. vmf->vma->vm_private_data
should never be NULL, so the extra check in qxl_ttm_fault should have no
effect.
Drop it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 27 +--
1 file changed, 1 insertion(+), 26
Wire up the new drm_gem_ttm_mmap() helper function.
Use generic drm_gem_mmap() and remove qxl_mmap().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 -
drivers/gpu/drm/qxl/qxl_drv.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 1 +
drivers/gpu/drm/qxl/qxl_ttm.c|
On Thu, Oct 17, 2019 at 6:11 AM Thierry Reding wrote:
>
> On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely
The cirrus driver's header file is left over from a recent rewrite.
Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 247
1 file changed, 247 deletions(-)
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=111987
--- Comment #13 from deathloc...@gmail.com ---
did U 'cat pp_dpm_sclk' after 'echo 7 > ...' ?
I have to boot with amdgpu.runpm=0 to be able to change anything
drawback is - notebook fan goes off every2-3 min, for 30 sec, in idle :/
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=107296
Janpieter Sollie changed:
What|Removed |Added
Attachment #144689|0 |1
is obsolete|
On Thu, Oct 17, 2019 at 01:34:27PM +0200, Thomas Zimmermann wrote:
> The cirrus driver's header file is left over from a recent rewrite.
> Remove it.
Queued up for drm-misc-next.
thanks,
Gerd
___
dri-devel mailing list
On Tue, Oct 08, 2019 at 10:40:54AM +0800, YueHaibing wrote:
> If DEM_QXL is y and DRM_TTM_HELPER is m, building fails:
>
> drivers/gpu/drm/qxl/qxl_object.o: undefined reference to
> `drm_gem_ttm_print_info'
>
> Select DRM_TTM_HELPER to fix this.
Queued up for drm-misc-next.
thanks,
Gerd
On Thu, Oct 17, 2019 at 02:49:12PM +0300, Andy Shevchenko wrote:
> GCC complains about dubious bitwise OR operand:
>
> drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y
> CC [M] drivers/gpu/drm/drm_mipi_dbi.o
>
> As long as buffer is consist of byte (u8) values, we may use
>
qxl uses small buffer objects for qxl commands.
Allocate them top-down to reduce fragmentation.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_object.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c
On Wed, Oct 16, 2019 at 03:43:46PM +0530, Kiran Gunda wrote:
> The auto string detection algorithm checks if the current WLED
> sink configuration is valid. It tries enabling every sink and
> checks if the OVP fault is observed. Based on this information
> it detects and enables the valid sink
On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
> On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
> > On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
> > > On 17. 10. 19 10:10, Uwe Kleine-König wrote:
> > > > A previous change in the pwm core (namely
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag
On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > pwm_get_state() return the last implemented state")) changed the
> > semantic of
On 2019-10-17 16:36, Daniel Thompson wrote:
On Wed, Oct 16, 2019 at 03:43:44PM +0530, Kiran Gunda wrote:
WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.
There is code buried in this
On Wed, 16 Oct 2019, Kiran Gunda wrote:
> The auto string detection algorithm checks if the current WLED
> sink configuration is valid. It tries enabling every sink and
> checks if the OVP fault is observed. Based on this information
> it detects and enables the valid sink configuration.
> Auto
Hi Jacopo,
On Thu, Oct 17, 2019 at 02:43:49PM +0200, Jacopo Mondi wrote:
> On Wed, Oct 16, 2019 at 04:45:26PM +0300, Laurent Pinchart wrote:
> > On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In most
https://bugs.freedesktop.org/show_bug.cgi?id=111987
--- Comment #14 from Alex Deucher ---
You can force the clocks low or high by:
echo low > power_dpm_force_performance_level
or
echo high > power_dpm_force_performance_level
setting it to auto will restore the automatic behavior:
echo auto >
On Thu, Oct 17, 2019 at 02:19:45PM +0200, Uwe Kleine-König wrote:
> On Thu, Oct 17, 2019 at 12:47:27PM +0100, Daniel Thompson wrote:
> > On Thu, Oct 17, 2019 at 10:10:59AM +0200, Uwe Kleine-König wrote:
> > > A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
> > > pwm_get_state()
On Thu, 17 Oct 2019, kgu...@codeaurora.org wrote:
> On 2019-10-17 17:56, Lee Jones wrote:
> > On Wed, 16 Oct 2019, Kiran Gunda wrote:
> >
> > > The auto string detection algorithm checks if the current WLED
> > > sink configuration is valid. It tries enabling every sink and
> > > checks if the
On Thu, Oct 17, 2019 at 12:04:27PM +0100, Ben Dooks (Codethink) wrote:
> The host1x_cdma_wait_pushbuffer_space function is not declared
> or directly called from outside the file it is in, so make it
> static.
>
> Fixes the following sparse warnign:
> drivers/gpu/host1x/cdma.c:235:5: warning:
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Drop check for CMM in
On 2019/10/17 上午12:53, Alex Williamson wrote:
On Wed, 16 Oct 2019 15:31:25 +
Parav Pandit wrote:
-Original Message-
From: Cornelia Huck
Sent: Wednesday, October 16, 2019 3:53 AM
To: Parav Pandit
Cc: Alex Williamson ; Jason Wang
; k...@vger.kernel.org;
Hi Russel.
On Wed, Oct 16, 2019 at 6:22 PM Russell King - ARM Linux admin
wrote:
>
...
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1337,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv
> > *priv,
> >
On Wed, Oct 16, 2019 at 6:14 PM Russell King - ARM Linux admin
wrote:
>
> On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
> > From: Dariusz Marcinkiewicz
> >
> > Use the new cec_notifier_conn_(un)register() functions to
> > (un)register the notifier for the HDMI connector.
> >
> >
On 15/10/2019 13:33, Neil Armstrong wrote:
> The VPU embeds a "Register DMA" that can write a sequence of registers
> on the VPU AHB bus, either manually or triggered by an internal IRQ
> event like VSYNC or a line input counter.
>
> The initial implementation handles a single channel (over 8),
On Thu, Oct 17, 2019 at 11:26:38AM +0200, Dariusz Marcinkiewicz wrote:
> Hi Russel.
>
> On Wed, Oct 16, 2019 at 6:22 PM Russell King - ARM Linux admin
> wrote:
> >
> ...
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1337,6 +1337,8 @@ static
Smatch complains that we need to initialized "*cap" otherwise it can
lead to an uninitialized variable bug in the caller. This seems like a
reasonable warning and it doesn't hurt to silence it at least.
drivers/gpu/drm/amd/amdgpu/vi.c:767 vi_asic_reset_method() error: uninitialized
symbol
The DRM TODO list now contains an entry for converting fbdev
drivers over to DRM.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 27 +++
1 file changed, 27 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index
I rebased v2 of this patchset onto v5.3 and uploaded the result
into the git repo at
https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
I'll keep the helpers updated for new Linux releases from time to
time. The attached patch adds a new item to the TODO list that refers
to the
A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state")) changed the
semantic of pwm_get_state() and disclosed an (as it seems) common
problem in lowlevel PWM drivers. By not relying on the period and duty
cycle being retrievable from a
1 - 100 of 160 matches
Mail list logo
