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 assig
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: Darius
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 ma
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.
> >
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
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 tha
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 dele
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 insert
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 for
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 extern
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 7978555
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
On Thu, Oct 17, 2019 at 09:28:42AM +0200, Hans Verkuil wrote:
> 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/i
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 +, Brian Starkey wrote:
> >
> > If James is strongly against merging this, maybe we just swap
> > wholesale to bridge? But for me, the pragmatic approach would be this
On Thu, Oct 17, 2019 at 09:47:05AM +0200, Thomas Zimmermann wrote:
> The DRM TODO list now contains an entry for converting fbdev
> drivers over to DRM.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 27 +++
> 1 fil
On 2019/10/16 下午12:57, Parav Pandit wrote:
+static struct mdev_class_id id_table[] = {
static const
+ { MDEV_ID_VFIO },
I guess you don't need extra braces for each entry.
Since this enum represents MDEV class id, it better to name it as
MDEV_CLASS_ID_VFIO.
(Similar to PCI_VENDOR_ID
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; linux-s...@vger.kernel.org;
On 10/17/19 10:11 AM, Russell King - ARM Linux admin wrote:
> On Thu, Oct 17, 2019 at 09:28:42AM +0200, Hans Verkuil wrote:
>> From: Dariusz Marcinkiewicz
>>
>> Fill in the cec_connector_info when calling cec_notifier_conn_register().
>>
>> Signed-off-by: Dariusz Marcinkiewicz
>> Tested-by: Hans
Quoting Sebastian Andrzej Siewior (2019-10-17 09:40:01)
> The locks (active.lock and rq->lock) need to be taken with disabled
> interrupts. This is done in i915_request_retire() by disabling the
> interrupts independently of the locks itself.
> While local_irq_disable()+spin_lock() equals spin_lock
On Thu, 17 Oct 2019 16:30:43 +0800
Jason Wang wrote:
> On 2019/10/17 上午12:53, Alex Williamson wrote:
> >>> Yet another suggestion: have the class id derive from the function
> >>> you use to set up the ops.
> >>>
> >>> void mdev_set_vfio_ops(struct mdev_device *mdev, const struct
> >>> vfio_mdev
On 2019/10/17 下午4:45, Cornelia Huck wrote:
On Thu, 17 Oct 2019 16:30:43 +0800
Jason Wang wrote:
On 2019/10/17 上午12:53, Alex Williamson wrote:
Yet another suggestion: have the class id derive from the function
you use to set up the ops.
void mdev_set_vfio_ops(struct mdev_device *mdev, const
Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers ar
Am 16.10.19 um 16:23 schrieb Daniel Vetter:
> On Wed, Oct 16, 2019 at 3:46 PM Koenig, Christian
> wrote:
>> Am 08.10.19 um 10:55 schrieb Daniel Vetter:
>>> On Wed, Oct 02, 2019 at 08:37:50AM +, Koenig, Christian wrote:
Hi Daniel,
once more a ping on this. Any more comments or ca
On Mon, 14 Oct 2019 06:02:59 -0700
James Jones wrote:
> On 10/13/19 2:05 PM, Scott Anderson wrote:
> > (Sorry to CCs for spam, I made an error in my first posting)
> >
> > Hi,
> >
> > There were certainly some interesting changes discussed at the allocator
> > workshop during XDC this year, and
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 'baco_
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.
> >
> > S
> 3) Make sure host_stride == guest_stride at allocation time
> For (3), since we have to do something like
> VIRTIO_GPU_CMD_METADATA_QUERY (or whatever we call it) for Vulkan and
> zero-copy anyways, this seemed like the most natural choice.
Yep, for shared resources it certainly makes sense to
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), tr
On Thu, Oct 17, 2019 at 09:42:53AM +0800, Jason Wang wrote:
>
> On 2019/10/15 下午10:37, Stefan Hajnoczi wrote:
> > On Tue, Oct 15, 2019 at 11:37:17AM +0800, Jason Wang wrote:
> > > On 2019/10/15 上午1:49, Stefan Hajnoczi wrote:
> > > > On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote:
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=205147
wwa (10dma...@gmail.com) changed:
What|Removed |Added
CC||10dma...@gmail.com
--- Comment
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
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), triggered
by the VSYNC irq and does not handle the RDMA
The Amlogic 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.
This adds the register defines.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_registers.h
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 RDMA is used here to reset and program the AFBC decoder unit
on each vsync without involving the interrupt handle
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), triggered
by the VSYNC irq and does not handle the RDMA
On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:
> On Wed, Oct 16, 2019 at 1:33 PM Maxime Ripard wrote:
> >
> > On Mon, Oct 14, 2019 at 05:37:50PM +0530, Jagan Teki wrote:
> > > On Mon, Oct 7, 2019 at 4:27 PM Maxime Ripard wrote:
> > > >
> > > > On Sat, Oct 05, 2019 at 07:49:12PM +0530
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 implemented state")) changed the
> > semantic of pwm_get_state() and disclosed an (a
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 +, Brian Starkey wrote:
> > >
> > > If James is strongly against merging this, maybe we just swap
>
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 +,
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 re
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.
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 b/driver
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 b
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 fil
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 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 'v
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: Ger
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
th
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 Gund
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 implemente
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?
drivers/gpu/drm/arm/malidp_drv.c:494:
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 conf
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 a/drive
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 Kc
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 Technol
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 driv
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 r
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
https://bugs.freedesktop.org/show_bug.cgi?id=107296
Janpieter Sollie changed:
What|Removed |Added
Attachment #144689|0 |1
is obsolete|
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
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
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 pwm_get_sta
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 ca
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 pa
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
p
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 sepa
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 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
dri-devel@lists.freedesktop.org
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 th
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 t
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 core
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 outpu
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
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. By
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 10:10:59AM
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 > powe
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 va
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 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
> sim
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() re
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 whic
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| 16
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 del
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 &drm_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
+++ b/drivers/
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
--- a/drivers/
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 b/drivers/gpu/drm/qxl/qxl_o
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 bisec
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 OV
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: symb
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 01ccf90
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 enab
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 advanc
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 rcar_du
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 since
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 cons
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 Kleine-König
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
1 - 100 of 162 matches
Mail list logo
