[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
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 assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 1/2] drm: tda998x: use cec_notifier_conn_(un)register
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: Dariusz Marcinkiewicz
>> Signed-off-by: Hans Verkuil
>
> Please explain in detail what this mutex actually achieves.
Dariusz, since you're the author, can you reply to Russell?
If this is going to be a delaying factor, then I'll post a new version
without the mutex that just replaces the cec_notifier API.
Regards,
Hans
>
>> ---
>> drivers/gpu/drm/i2c/tda998x_drv.c | 21 -
>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> index 84c6d4c91c65..8262b44b776e 100644
>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -82,6 +82,9 @@ struct tda998x_priv {
>> u8 audio_port_enable[AUDIO_ROUTE_NUM];
>> struct tda9950_glue cec_glue;
>> struct gpio_desc *calib;
>> +
>> +/* protect cec_notify */
>> +struct mutex cec_notify_mutex;
>> struct cec_notifier *cec_notify;
>> };
>>
>> @@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void
>> *data)
>> tda998x_edid_delay_start(priv);
>> } else {
>> schedule_work(&priv->detect_work);
>> -cec_notifier_set_phys_addr(priv->cec_notify,
>> - CEC_PHYS_ADDR_INVALID);
>> +
>> +mutex_lock(&priv->cec_notify_mutex);
>> +cec_notifier_phys_addr_invalidate(
>> +priv->cec_notify);
>> +mutex_unlock(&priv->cec_notify_mutex);
>> }
>>
>> handled = true;
>> @@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
>>
>> i2c_unregister_device(priv->cec);
>>
>> -if (priv->cec_notify)
>> -cec_notifier_put(priv->cec_notify);
>> +mutex_lock(&priv->cec_notify_mutex);
>> +cec_notifier_conn_unregister(priv->cec_notify);
>> +priv->cec_notify = NULL;
>> +mutex_unlock(&priv->cec_notify_mutex);
>
> By the time we get here:
>
> 1) The interrupt has been freed (which is a synchronous operation)
>tda998x_irq_thread() can't be called and can't be running, and
>therefore cec_notifier_phys_addr_invalidate() also can't be called
>or be running.
> 2) You don't touch the cec_notifier_set_phys_addr_from_edid() site;
>if there's any case that _might_ possibly conflict, it is that one.
> 3) tda998x_destroy() and tda998x_create() can't be called concurrently
>in any case; the driver model guarantees that ->probe and ->remove
>for the same device are serialised.
>
>> }
>>
>> static int tda998x_create(struct device *dev)
>> @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev)
>> mutex_init(&priv->mutex); /* protect the page access */
>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */
>> mutex_init(&priv->edid_mutex);
>> +mutex_init(&priv->cec_notify_mutex);
>> INIT_LIST_HEAD(&priv->bridge.list);
>> init_waitqueue_head(&priv->edid_delay_waitq);
>> timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
>> @@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev)
>> cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
>> }
>>
>> -priv->cec_notify = cec_notifier_get(dev);
>> +mutex_lock(&priv->cec_notify_mutex);
>> +priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
>> +mutex_unlock(&priv->cec_notify_mutex);
>
> and:
>
> 4) priv->cec_notify will be NULL here until such time that
>cec_notifier_conn_register() has returned. If the mutex is trying
>to protect something, it's very unclear what it is.
>
> Trying to guess what it's protecting against:
>
> - Is it protecting against NULL priv->cec_notify? No, because it can
> be NULL just before we take the lock.
> - Is it protecting the internals of cec_notifier_conn_register()
> against the other calls - no, because priv->cec_notify will be NULL
> until the function has finished.
> - Is it protecting the write to priv->cec_notify? Maybe, but that
> doesn't need any protection - architectures are single-copy atomic,
> which means that a pointer is either written or it is not written.
> Therefore, it will either be NULL (the state before the call is made)
> or it will be set correctly (after the call has completed.)
>
> So, all in all, I don't see what this lock is doing, and I think it
> should be removed.
>
> If it's necessary for a future change (which may or may not be merged)
> then the
Re: [PATCH] spi: pxa2xx: Set controller->max_transfer_size in dma mode
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 max transfer size to inform spi clients that they need
> to do something smarter.
>
> This was uncovered by the drm_mipi_dbi spi panel code, which does
> large spi transfers, but stopped splitting them after:
>
> commit e143364b4c1774f68e923a5a0bb0fca28ac25888
> Author: Noralf Trønnes
> Date: Fri Jul 19 17:59:10 2019 +0200
>
> drm/tinydrm: Remove tinydrm_spi_max_transfer_size()
>
> After this commit the code relied on the spi core to split transfers
> into max dma-able blocks, which also papered over the PIO fallback issue.
>
> Fix this by setting the overall max transfer size to the DMA limit,
> but only when the controller runs in DMA mode.
>
Thank you, Daniel!
> Fixes: e143364b4c17 ("drm/tinydrm: Remove tinydrm_spi_max_transfer_size()")
> Cc: Sam Ravnborg
> Cc: Noralf Trønnes
> Cc: Andy Shevchenko
> Reported-and-tested-by: Andy Shevchenko
> Cc: Daniel Mack
> Cc: Haojian Zhuang
> Cc: Robert Jarzmik
> Cc: Mark Brown
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> --
> v2: Brown paper bag edition, it needs to be a function ...
> ---
> drivers/spi/spi-pxa2xx.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index bb6a14d1ab0f..068c21037679 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -1602,6 +1602,11 @@ static int pxa2xx_spi_fw_translate_cs(struct
> spi_controller *controller,
> return cs;
> }
>
> +static size_t pxa2xx_spi_max_dma_transfer_size(struct spi_device *spi)
> +{
> + return MAX_DMA_LEN;
> +}
> +
> static int pxa2xx_spi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1707,6 +1712,8 @@ static int pxa2xx_spi_probe(struct platform_device
> *pdev)
> } else {
> controller->can_dma = pxa2xx_spi_can_dma;
> controller->max_dma_len = MAX_DMA_LEN;
> + controller->max_transfer_size =
> + pxa2xx_spi_max_dma_transfer_size;
> }
> }
>
> --
> 2.23.0
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Funnel drm logs to tracepoints
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. > > > > Those semantics, "only use this content for attaching into a bug > > report" should be made very clear in the UAPI. > > Has this ever worked? As soon as a userspace program starts depending on > the content of this file, it becomes kabi. From the incidents I know, > Linus has always been quite strict about this. Even for broken interfaces. The kernel log content is not kabi, is it? I've seen it change plenty during the years. This would be just another similar log with free-form text. Thanks, pq pgpN3SUOmZ2L8.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] backlight: gpio: simplify the driver
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 we're just waiting for the SH Acks now? > > > > The one maintainer with this board is probably overloaded. > > > > I would say just apply it, it can't hold back the entire series. > > I've been able to resurect the Ecovec, and I've also been given a copy > of its schematics file a few weeks ago. > > It's in my TODO list to test this series but I didn't manage to find > time. If I pinky promise I get back to you before end of the week, > could you wait for me ? :) Yes, no problem. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv9 0/2] drm: tda998x: use cec_notifier_conn_(un)register
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 that this isn't implemented yet. Dariusz, can you comment on the use of the mutex in the second patch? This second patch won't be merged for v5.5 so you can take your time :-) But the replacement of the cec_notifier_get/put functions is something that needs to be finished for v5.5. By splitting this patch up I can merge the first half, but delay the second half. This tda driver just won't be able to report the connector information in the meantime. Changes since v8: - Moved the mutex addition to the second patch where I think it actually belongs. Regards, Hans (1) https://patchwork.linuxtv.org/patch/58464/ Dariusz Marcinkiewicz (2): drm: tda998x: use cec_notifier_conn_(un)register drm: tda998x: set the connector info drivers/gpu/drm/i2c/tda998x_drv.c | 38 ++- 1 file changed, 27 insertions(+), 11 deletions(-) -- 2.23.0
[PATCHv9 1/2] drm: tda998x: use cec_notifier_conn_(un)register
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 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 84c6d4c91c65..dde8decb52a6 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -805,8 +805,8 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
tda998x_edid_delay_start(priv);
} else {
schedule_work(&priv->detect_work);
- cec_notifier_set_phys_addr(priv->cec_notify,
- CEC_PHYS_ADDR_INVALID);
+ cec_notifier_phys_addr_invalidate(
+ priv->cec_notify);
}
handled = true;
@@ -1790,8 +1790,7 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify)
- cec_notifier_put(priv->cec_notify);
+ cec_notifier_conn_unregister(priv->cec_notify);
}
static int tda998x_create(struct device *dev)
@@ -1916,7 +1915,7 @@ static int tda998x_create(struct device *dev)
cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
}
- priv->cec_notify = cec_notifier_get(dev);
+ priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
if (!priv->cec_notify) {
ret = -ENOMEM;
goto fail;
--
2.23.0
[PATCHv9 2/2] drm: tda998x: set the connector info
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 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index dde8decb52a6..b0620842fa3a 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -82,6 +82,9 @@ struct tda998x_priv {
u8 audio_port_enable[AUDIO_ROUTE_NUM];
struct tda9950_glue cec_glue;
struct gpio_desc *calib;
+
+ /* protect cec_notify */
+ struct mutex cec_notify_mutex;
struct cec_notifier *cec_notify;
};
@@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
tda998x_edid_delay_start(priv);
} else {
schedule_work(&priv->detect_work);
+
+ mutex_lock(&priv->cec_notify_mutex);
cec_notifier_phys_addr_invalidate(
priv->cec_notify);
+ mutex_unlock(&priv->cec_notify_mutex);
}
handled = true;
@@ -1331,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
struct drm_device *drm)
{
struct drm_connector *connector = &priv->connector;
+ struct cec_connector_info conn_info;
+ struct cec_notifier *notifier;
int ret;
connector->interlace_allowed = 1;
@@ -1347,6 +1355,17 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
if (ret)
return ret;
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ notifier = cec_notifier_conn_register(priv->cec_glue.parent,
+ NULL, &conn_info);
+ if (!notifier)
+ return -ENOMEM;
+
+ mutex_lock(&priv->cec_notify_mutex);
+ priv->cec_notify = notifier;
+ mutex_unlock(&priv->cec_notify_mutex);
+
drm_connector_attach_encoder(&priv->connector,
priv->bridge.encoder);
@@ -1366,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge
*bridge)
{
struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
+ mutex_lock(&priv->cec_notify_mutex);
+ cec_notifier_conn_unregister(priv->cec_notify);
+ priv->cec_notify = NULL;
+ mutex_unlock(&priv->cec_notify_mutex);
+
drm_connector_cleanup(&priv->connector);
}
@@ -1789,8 +1813,6 @@ static void tda998x_destroy(struct device *dev)
cancel_work_sync(&priv->detect_work);
i2c_unregister_device(priv->cec);
-
- cec_notifier_conn_unregister(priv->cec_notify);
}
static int tda998x_create(struct device *dev)
@@ -1811,6 +1833,7 @@ static int tda998x_create(struct device *dev)
mutex_init(&priv->mutex); /* protect the page access */
mutex_init(&priv->audio_mutex); /* protect access from audio thread */
mutex_init(&priv->edid_mutex);
+ mutex_init(&priv->cec_notify_mutex);
INIT_LIST_HEAD(&priv->bridge.list);
init_waitqueue_head(&priv->edid_delay_waitq);
timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
@@ -1915,12 +1938,6 @@ static int tda998x_create(struct device *dev)
cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
}
- priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
- if (!priv->cec_notify) {
- ret = -ENOMEM;
- goto fail;
- }
-
priv->cec_glue.parent = dev;
priv->cec_glue.data = priv;
priv->cec_glue.init = tda998x_cec_hook_init;
--
2.23.0
Re: [PATCHv8 1/2] drm: tda998x: use cec_notifier_conn_(un)register
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 the HDMI connector.
>>>
>>> Signed-off-by: Dariusz Marcinkiewicz
>>> Signed-off-by: Hans Verkuil
>>
>> Please explain in detail what this mutex actually achieves.
>
> Dariusz, since you're the author, can you reply to Russell?
>
> If this is going to be a delaying factor, then I'll post a new version
> without the mutex that just replaces the cec_notifier API.
I decided to post a v9, moving the mutex to the second patch, which should
make the first patch acceptable to everyone for v5.5.
Regards,
Hans
>
> Regards,
>
> Hans
>
>>
>>> ---
>>> drivers/gpu/drm/i2c/tda998x_drv.c | 21 -
>>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> index 84c6d4c91c65..8262b44b776e 100644
>>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> @@ -82,6 +82,9 @@ struct tda998x_priv {
>>> u8 audio_port_enable[AUDIO_ROUTE_NUM];
>>> struct tda9950_glue cec_glue;
>>> struct gpio_desc *calib;
>>> +
>>> + /* protect cec_notify */
>>> + struct mutex cec_notify_mutex;
>>> struct cec_notifier *cec_notify;
>>> };
>>>
>>> @@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void
>>> *data)
>>> tda998x_edid_delay_start(priv);
>>> } else {
>>> schedule_work(&priv->detect_work);
>>> - cec_notifier_set_phys_addr(priv->cec_notify,
>>> - CEC_PHYS_ADDR_INVALID);
>>> +
>>> + mutex_lock(&priv->cec_notify_mutex);
>>> + cec_notifier_phys_addr_invalidate(
>>> + priv->cec_notify);
>>> + mutex_unlock(&priv->cec_notify_mutex);
>>> }
>>>
>>> handled = true;
>>> @@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
>>>
>>> i2c_unregister_device(priv->cec);
>>>
>>> - if (priv->cec_notify)
>>> - cec_notifier_put(priv->cec_notify);
>>> + mutex_lock(&priv->cec_notify_mutex);
>>> + cec_notifier_conn_unregister(priv->cec_notify);
>>> + priv->cec_notify = NULL;
>>> + mutex_unlock(&priv->cec_notify_mutex);
>>
>> By the time we get here:
>>
>> 1) The interrupt has been freed (which is a synchronous operation)
>>tda998x_irq_thread() can't be called and can't be running, and
>>therefore cec_notifier_phys_addr_invalidate() also can't be called
>>or be running.
>> 2) You don't touch the cec_notifier_set_phys_addr_from_edid() site;
>>if there's any case that _might_ possibly conflict, it is that one.
>> 3) tda998x_destroy() and tda998x_create() can't be called concurrently
>>in any case; the driver model guarantees that ->probe and ->remove
>>for the same device are serialised.
>>
>>> }
>>>
>>> static int tda998x_create(struct device *dev)
>>> @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev)
>>> mutex_init(&priv->mutex); /* protect the page access */
>>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */
>>> mutex_init(&priv->edid_mutex);
>>> + mutex_init(&priv->cec_notify_mutex);
>>> INIT_LIST_HEAD(&priv->bridge.list);
>>> init_waitqueue_head(&priv->edid_delay_waitq);
>>> timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
>>> @@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev)
>>> cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
>>> }
>>>
>>> - priv->cec_notify = cec_notifier_get(dev);
>>> + mutex_lock(&priv->cec_notify_mutex);
>>> + priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
>>> + mutex_unlock(&priv->cec_notify_mutex);
>>
>> and:
>>
>> 4) priv->cec_notify will be NULL here until such time that
>>cec_notifier_conn_register() has returned. If the mutex is trying
>>to protect something, it's very unclear what it is.
>>
>> Trying to guess what it's protecting against:
>>
>> - Is it protecting against NULL priv->cec_notify? No, because it can
>> be NULL just before we take the lock.
>> - Is it protecting the internals of cec_notifier_conn_register()
>> against the other calls - no, because priv->cec_notify will be NULL
>> until the function has finished.
>> - Is it protecting the write to priv->cec_notify? Maybe, but that
>> doesn't need any protection - architectures are single-copy atomic,
>> which means that a pointer is either written or it is not written.
>> Therefore, it will either be NULL (the
[PATCH v3 0/1] DRM fbconv helpers for converting fbdev drivers
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 external tree and documentation. v3: * replace patchset in favor of TODO item that refers to external tree v2: * rename to fbconv helpers * rewrite as helper library * switch over to simple KMS helpers * switch over to SHMEM * add documentation Thomas Zimmermann (1): drm: Add TODO item for fbdev driver conversion Documentation/gpu/todo.rst | 27 +++ 1 file changed, 27 insertions(+) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/1] drm: Add TODO item for fbdev driver conversion
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 79785559d711..23b3a67794ba 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -462,3 +462,30 @@ Contact: Sam Ravnborg Outside DRM === + +Convert fbdev drivers to DRM + + +There are plenty of fbdev drivers for older hardware. Some hwardware has +become obsolete, but some still provides good(-enough) framebuffers. The +drivers that are still useful should be converted to DRM and afterwards +removed from fbdev. + +Very simple fbdev drivers can best be converted by starting with a new +DRM driver. Simple KMS helpers and SHMEM should be able to handle any +existing hardware. The new driver's call-back functions are filled from +existing fbdev code. + +More complex fbdev drivers can be refactored step-by-step into a DRM +driver with the help of the DRM fbconv helpers. [1] These helpers provide +the transition layer between the DRM core infrastructure and the fbdev +driver interface. Create a new DRM driver on top of the fbconv helpers, +copy over the fbdev driver, and hook it up to the DRM code. Examples for +several fbdev drivers are available at [1] and a tutorial of this process +available at [2]. The result is a primitive DRM driver that can run X11 +and Weston. + + - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv + - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c + +Contact: Thomas Zimmermann -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 disabled PWM this type of problem is
worked around.
Apart from this issue only calling the pwm_get_state/pwm_apply_state
combo once is also more effective.
Signed-off-by: Uwe Kleine-König
---
Hello,
There are now two reports about 01ccf903edd6 breaking a backlight. As
far as I understand the problem this is a combination of the backend pwm
driver yielding surprising results and the pwm-bl driver doing things
more complicated than necessary.
So I guess this patch works around these problems. Still it would be
interesting to find out the details in the imx driver that triggers the
problem. So Adam, can you please instrument the pwm-imx27 driver to
print *state at the beginning of pwm_imx27_apply() and the end of
pwm_imx27_get_state() and provide the results?
Note I only compile tested this change.
Best regards
Uwe
drivers/video/backlight/pwm_bl.c | 34 +++-
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 746eebc411df..ddebd62b3978 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -42,10 +42,8 @@ struct pwm_bl_data {
static void pwm_backlight_power_on(struct pwm_bl_data *pb)
{
- struct pwm_state state;
int err;
- pwm_get_state(pb->pwm, &state);
if (pb->enabled)
return;
@@ -53,9 +51,6 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
if (err < 0)
dev_err(pb->dev, "failed to enable power supply\n");
- state.enabled = true;
- pwm_apply_state(pb->pwm, &state);
-
if (pb->post_pwm_on_delay)
msleep(pb->post_pwm_on_delay);
@@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
static void pwm_backlight_power_off(struct pwm_bl_data *pb)
{
- struct pwm_state state;
-
- pwm_get_state(pb->pwm, &state);
- if (!pb->enabled)
- return;
-
if (pb->enable_gpio)
gpiod_set_value_cansleep(pb->enable_gpio, 0);
if (pb->pwm_off_delay)
msleep(pb->pwm_off_delay);
- state.enabled = false;
- state.duty_cycle = 0;
- pwm_apply_state(pb->pwm, &state);
-
regulator_disable(pb->power_supply);
pb->enabled = false;
}
-static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
+static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness, struct
pwm_state *state)
{
unsigned int lth = pb->lth_brightness;
- struct pwm_state state;
u64 duty_cycle;
- pwm_get_state(pb->pwm, &state);
-
if (pb->levels)
duty_cycle = pb->levels[brightness];
else
duty_cycle = brightness;
- duty_cycle *= state.period - lth;
+ duty_cycle *= state->period - lth;
do_div(duty_cycle, pb->scale);
return duty_cycle + lth;
@@ -122,12 +104,20 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
if (brightness > 0) {
pwm_get_state(pb->pwm, &state);
- state.duty_cycle = compute_duty_cycle(pb, brightness);
+ state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
+ state.enabled = true;
pwm_apply_state(pb->pwm, &state);
+
pwm_backlight_power_on(pb);
- } else
+ } else {
pwm_backlight_power_off(pb);
+ pwm_get_state(pb->pwm, &state);
+ state.enabled = false;
+ state.duty_cycle = 0;
+ pwm_apply_state(pb->pwm, &state);
+ }
+
if (pb->notify_after)
pb->notify_after(pb->dev, brightness);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv9 2/2] drm: tda998x: set the connector info
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/i2c/tda998x_drv.c | 33 +++
> 1 file changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index dde8decb52a6..b0620842fa3a 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -82,6 +82,9 @@ struct tda998x_priv {
> u8 audio_port_enable[AUDIO_ROUTE_NUM];
> struct tda9950_glue cec_glue;
> struct gpio_desc *calib;
> +
> + /* protect cec_notify */
> + struct mutex cec_notify_mutex;
> struct cec_notifier *cec_notify;
> };
>
> @@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void
> *data)
> tda998x_edid_delay_start(priv);
> } else {
> schedule_work(&priv->detect_work);
> +
> + mutex_lock(&priv->cec_notify_mutex);
> cec_notifier_phys_addr_invalidate(
> priv->cec_notify);
> + mutex_unlock(&priv->cec_notify_mutex);
> }
>
> handled = true;
> @@ -1331,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> struct drm_device *drm)
> {
> struct drm_connector *connector = &priv->connector;
> + struct cec_connector_info conn_info;
> + struct cec_notifier *notifier;
> int ret;
>
> connector->interlace_allowed = 1;
> @@ -1347,6 +1355,17 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> if (ret)
> return ret;
>
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> + NULL, &conn_info);
> + if (!notifier)
> + return -ENOMEM;
> +
> + mutex_lock(&priv->cec_notify_mutex);
> + priv->cec_notify = notifier;
> + mutex_unlock(&priv->cec_notify_mutex);
You haven't taken on board what I said about the mutex in this
instance.
> +
> drm_connector_attach_encoder(&priv->connector,
>priv->bridge.encoder);
>
> @@ -1366,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge
> *bridge)
> {
> struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
>
> + mutex_lock(&priv->cec_notify_mutex);
> + cec_notifier_conn_unregister(priv->cec_notify);
> + priv->cec_notify = NULL;
> + mutex_unlock(&priv->cec_notify_mutex);
> +
> drm_connector_cleanup(&priv->connector);
> }
>
> @@ -1789,8 +1813,6 @@ static void tda998x_destroy(struct device *dev)
> cancel_work_sync(&priv->detect_work);
>
> i2c_unregister_device(priv->cec);
> -
> - cec_notifier_conn_unregister(priv->cec_notify);
> }
>
> static int tda998x_create(struct device *dev)
> @@ -1811,6 +1833,7 @@ static int tda998x_create(struct device *dev)
> mutex_init(&priv->mutex); /* protect the page access */
> mutex_init(&priv->audio_mutex); /* protect access from audio thread */
> mutex_init(&priv->edid_mutex);
> + mutex_init(&priv->cec_notify_mutex);
> INIT_LIST_HEAD(&priv->bridge.list);
> init_waitqueue_head(&priv->edid_delay_waitq);
> timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
> @@ -1915,12 +1938,6 @@ static int tda998x_create(struct device *dev)
> cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
> }
>
> - priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
> - if (!priv->cec_notify) {
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> priv->cec_glue.parent = dev;
> priv->cec_glue.data = priv;
> priv->cec_glue.init = tda998x_cec_hook_init;
> --
> 2.23.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
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 > > stop-gap. > > > > This is a good idea, and I vote +ULONG_MAX :) > > and I also checked tda998x driver, it supports bridge. so swap the > wholesale to brige is perfect. :) > Well, as Mihail wrote, it's definitely not perfect. Today, if you rmmod tda998x with the DPU driver still loaded, everything will be unbound gracefully. If we swap to bridge, then rmmod'ing tda998x (or any other bridge driver the DPU is using) with the DPU driver still loaded will result in a crash. So, there really are proper benefits to sticking with the component code for tda998x, which is why I'd like to understand why you're so against this patch? Thanks, -Brian
Re: [PATCH v3 1/1] drm: Add TODO item for fbdev driver conversion
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 file changed, 27 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 79785559d711..23b3a67794ba 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -462,3 +462,30 @@ Contact: Sam Ravnborg > > Outside DRM > === > + > +Convert fbdev drivers to DRM > + > + > +There are plenty of fbdev drivers for older hardware. Some hwardware has > +become obsolete, but some still provides good(-enough) framebuffers. The > +drivers that are still useful should be converted to DRM and afterwards > +removed from fbdev. > + > +Very simple fbdev drivers can best be converted by starting with a new > +DRM driver. Simple KMS helpers and SHMEM should be able to handle any > +existing hardware. The new driver's call-back functions are filled from > +existing fbdev code. > + > +More complex fbdev drivers can be refactored step-by-step into a DRM > +driver with the help of the DRM fbconv helpers. [1] These helpers provide > +the transition layer between the DRM core infrastructure and the fbdev > +driver interface. Create a new DRM driver on top of the fbconv helpers, > +copy over the fbdev driver, and hook it up to the DRM code. Examples for > +several fbdev drivers are available at [1] and a tutorial of this process > +available at [2]. The result is a primitive DRM driver that can run X11 > +and Weston. > + > + - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv > + - [2] > https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c btw if you want to push a patch to get this built and published: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml The "pages" job is the one which gets published to https://drm.pages.freedesktop.org/igt-gpu-tools/ With that you could point at the pretty hmtl even. -Daniel > + > +Contact: Thomas Zimmermann > -- > 2.23.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 1/7] mdev: class id support
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, PCI_DEVICE_ID)..
Gcc start to complain like:
warning: missing braces around initializer [-Wmissing-braces]
static const struct mdev_class_id id_table[] = {
^
MDEV_ID_VFIO, 0,
{ } {
};
}
So I will keep this part untouched.
Thanks
+ { 0 },
+};
Re: [PATCH V3 4/7] mdev: introduce device specific ops
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;
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
kwankh...@nvidia.com; m...@redhat.com; tiwei@intel.com;
virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
maxime.coque...@redhat.com; cunming.li...@intel.com;
zhihong.w...@intel.com; rob.mil...@broadcom.com; xiao.w.w...@intel.com;
haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
lingshan@intel.com; Ido Shamay ;
epere...@redhat.com; l...@redhat.com; christophe.de.dinec...@gmail.com;
kevin.t...@intel.com
Subject: Re: [PATCH V3 4/7] mdev: introduce device specific ops
On Wed, 16 Oct 2019 05:50:08 +
Parav Pandit wrote:
Hi Alex,
-Original Message-
From: Alex Williamson
Sent: Tuesday, October 15, 2019 12:27 PM
To: Jason Wang
Cc: Cornelia Huck ; k...@vger.kernel.org; linux-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
de...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
intel-gvt- d...@lists.freedesktop.org; kwankh...@nvidia.com;
m...@redhat.com; tiwei@intel.com;
virtualizat...@lists.linux-foundation.org;
net...@vger.kernel.org; maxime.coque...@redhat.com;
cunming.li...@intel.com; zhihong.w...@intel.com;
rob.mil...@broadcom.com; xiao.w.w...@intel.com;
haotian.w...@sifive.com; zhen...@linux.intel.com;
zhi.a.w...@intel.com; jani.nik...@linux.intel.com;
joonas.lahti...@linux.intel.com; rodrigo.v...@intel.com;
airl...@linux.ie; dan...@ffwll.ch; far...@linux.ibm.com;
pa...@linux.ibm.com; seb...@linux.ibm.com; ober...@linux.ibm.com;
heiko.carst...@de.ibm.com; g...@linux.ibm.com;
borntrae...@de.ibm.com; akrow...@linux.ibm.com;
fre...@linux.ibm.com; lingshan@intel.com; Ido Shamay
; epere...@redhat.com; l...@redhat.com; Parav
Pandit ; christophe.de.dinec...@gmail.com;
kevin.t...@intel.com
Subject: Re: [PATCH V3 4/7] mdev: introduce device specific ops
On Tue, 15 Oct 2019 20:17:01 +0800
Jason Wang wrote:
On 2019/10/15 下午6:41, Cornelia Huck wrote:
On Fri, 11 Oct 2019 16:15:54 +0800 Jason Wang
wrote:
@@ -167,9 +176,10 @@ register itself with the mdev core driver::
extern int mdev_register_device(struct device *dev,
const struct
mdev_parent_ops *ops);
-It is also required to specify the class_id through::
+It is also required to specify the class_id and device
+specific ops
through::
- extern int mdev_set_class(struct device *dev, u16 id);
+ extern int mdev_set_class(struct device *dev, u16 id,
+ const void *ops);
Apologies if that has already been discussed, but do we want a
1:1 relationship between id and ops, or can different devices
with the same id register different ops?
I think we have a N:1 mapping between id and ops, e.g we want both
virtio-mdev and vhost-mdev use a single set of device ops.
The contents of the ops structure is essentially defined by the id,
which is why I was leaning towards them being defined together.
They are effectively interlocked, the id defines which mdev "endpoint"
driver is loaded and that driver requires mdev_get_dev_ops() to
return the structure required by the driver. I wish there was a way
we could incorporate type checking here. We toyed with the idea of
having the class in the same structure as the ops, but I think this
approach was chosen for simplicity. We could still do something like:
int mdev_set_class_struct(struct device *dev, const struct
mdev_class_struct *class);
struct mdev_class_struct {
u16 id;
union {
struct vfio_mdev_ops vfio_ops;
struct virtio_mdev_ops virtio_ops;
};
};
Maybe even:
struct vfio_mdev_ops *mdev_get_vfio_ops(struct mdev_device *mdev) {
BUG_ON(mdev->class.id != MDEV_ID_VFIO);
return &mdev->class.vfio_ops;
}
The match callback would of course just use the mdev->class.id value.
Functionally equivalent, but maybe better type characteristics.
Thanks,
Alex
We have 3 use cases of mdev.
1. current mdev binding to vfio_mdev
2. mdev binding to virtio
3. mdev binding to mlx5_core without dev_ops
Also
(a) a given parent may serve multiple types of classes in future.
(b) number of classes may not likely explode, they will be handful of
them. (vfio_mdev, virtio)
So, instead of making copies of this dev_ops pointer in each mde
Re: [PATCHv9 2/2] drm: tda998x: set the connector info
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 Verkuil
>> Signed-off-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/i2c/tda998x_drv.c | 33 +++
>> 1 file changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> index dde8decb52a6..b0620842fa3a 100644
>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -82,6 +82,9 @@ struct tda998x_priv {
>> u8 audio_port_enable[AUDIO_ROUTE_NUM];
>> struct tda9950_glue cec_glue;
>> struct gpio_desc *calib;
>> +
>> +/* protect cec_notify */
>> +struct mutex cec_notify_mutex;
>> struct cec_notifier *cec_notify;
>> };
>>
>> @@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void
>> *data)
>> tda998x_edid_delay_start(priv);
>> } else {
>> schedule_work(&priv->detect_work);
>> +
>> +mutex_lock(&priv->cec_notify_mutex);
>> cec_notifier_phys_addr_invalidate(
>> priv->cec_notify);
>> +mutex_unlock(&priv->cec_notify_mutex);
>> }
>>
>> handled = true;
>> @@ -1331,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv
>> *priv,
>>struct drm_device *drm)
>> {
>> struct drm_connector *connector = &priv->connector;
>> +struct cec_connector_info conn_info;
>> +struct cec_notifier *notifier;
>> int ret;
>>
>> connector->interlace_allowed = 1;
>> @@ -1347,6 +1355,17 @@ static int tda998x_connector_init(struct tda998x_priv
>> *priv,
>> if (ret)
>> return ret;
>>
>> +cec_fill_conn_info_from_drm(&conn_info, connector);
>> +
>> +notifier = cec_notifier_conn_register(priv->cec_glue.parent,
>> + NULL, &conn_info);
>> +if (!notifier)
>> +return -ENOMEM;
>> +
>> +mutex_lock(&priv->cec_notify_mutex);
>> +priv->cec_notify = notifier;
>> +mutex_unlock(&priv->cec_notify_mutex);
>
> You haven't taken on board what I said about the mutex in this
> instance.
That's because I didn't. See the cover letter.
I need this info from the author of the patch, Dariusz. Once I have that,
and we agree with the reasoning, then I'll post a new patch for it.
For now all I am interested in is getting patch 1/2 merged. Patch 2/2 won't
be merged any time soon.
Regards,
Hans
>
>> +
>> drm_connector_attach_encoder(&priv->connector,
>> priv->bridge.encoder);
>>
>> @@ -1366,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge
>> *bridge)
>> {
>> struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
>>
>> +mutex_lock(&priv->cec_notify_mutex);
>> +cec_notifier_conn_unregister(priv->cec_notify);
>> +priv->cec_notify = NULL;
>> +mutex_unlock(&priv->cec_notify_mutex);
>> +
>> drm_connector_cleanup(&priv->connector);
>> }
>>
>> @@ -1789,8 +1813,6 @@ static void tda998x_destroy(struct device *dev)
>> cancel_work_sync(&priv->detect_work);
>>
>> i2c_unregister_device(priv->cec);
>> -
>> -cec_notifier_conn_unregister(priv->cec_notify);
>> }
>>
>> static int tda998x_create(struct device *dev)
>> @@ -1811,6 +1833,7 @@ static int tda998x_create(struct device *dev)
>> mutex_init(&priv->mutex); /* protect the page access */
>> mutex_init(&priv->audio_mutex); /* protect access from audio thread */
>> mutex_init(&priv->edid_mutex);
>> +mutex_init(&priv->cec_notify_mutex);
>> INIT_LIST_HEAD(&priv->bridge.list);
>> init_waitqueue_head(&priv->edid_delay_waitq);
>> timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
>> @@ -1915,12 +1938,6 @@ static int tda998x_create(struct device *dev)
>> cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
>> }
>>
>> -priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
>> -if (!priv->cec_notify) {
>> -ret = -ENOMEM;
>> -goto fail;
>> -}
>> -
>> priv->cec_glue.parent = dev;
>> priv->cec_glue.data = priv;
>> priv->cec_glue.init = tda998x_cec_hook_init;
>> --
>> 2.23.0
>>
>>
>
Re: [PATCH v2] drm/i915: Don't disable interrupts independently of the lock
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_irq() on vanilla > it does not on PREEMPT_RT. > Chris Wilson confirmed that local_irq_disable() was just introduced as > an optimisation to avoid enabling/disabling interrupts during > lock/unlock combo. > > Enable/disable interrupts as part of the locking instruction. > > Cc: Chris Wilson > Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 4/7] mdev: introduce device specific ops
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_ops *vfio_ops) {
> >>> mdev->device_ops = vfio_ops;
> >>> mdev->class_id = MDEV_ID_VFIO;
> >>> }
> >>>
> >>> void mdev_set_virtio_ops(struct mdev_device *mdev, const struct
> >>> virtio_mdev_ops *virtio_ops) {
> >>> mdev->device_ops = virtio_ops;
> >>> mdev->class_id = MDEV_ID_VIRTIO;
> >>> }
> >>>
> >>> void mdev_set_vhost_ops(struct mdev_device *mdev, const struct
> >>> virtio_mdev_ops *virtio_ops) {
> >>> mdev->device_ops = virtio_ops;
> >>> mdev->class_id = MDEV_ID_VHOST;
> >>> }
> >>>
> >>> void mdev_set_vendor_ops(struct mdev_device *mdev) /* no ops */ {
> >>> mdev->class_id = MDEV_ID_VENDOR;
> >>> }
> > One further step towards making this hard to use incorrectly might be
> > to return an error if class_id is already set. Thanks,
> >
> > Alex
>
>
> I will add a BUG_ON() when class_id has already set.
Probably better a WARN_ON()?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 4/7] mdev: introduce device specific ops
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 struct
vfio_mdev_ops *vfio_ops) {
mdev->device_ops = vfio_ops;
mdev->class_id = MDEV_ID_VFIO;
}
void mdev_set_virtio_ops(struct mdev_device *mdev, const struct
virtio_mdev_ops *virtio_ops) {
mdev->device_ops = virtio_ops;
mdev->class_id = MDEV_ID_VIRTIO;
}
void mdev_set_vhost_ops(struct mdev_device *mdev, const struct
virtio_mdev_ops *virtio_ops) {
mdev->device_ops = virtio_ops;
mdev->class_id = MDEV_ID_VHOST;
}
void mdev_set_vendor_ops(struct mdev_device *mdev) /* no ops */ {
mdev->class_id = MDEV_ID_VENDOR;
}
One further step towards making this hard to use incorrectly might be
to return an error if class_id is already set. Thanks,
Alex
I will add a BUG_ON() when class_id has already set.
Probably better a WARN_ON()?
Right.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
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 are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others are
simple linear search lists.
Of the ones I checked they largely seem to have various kinds of races,
bugs and poor implementation. This is a result of the complexity in how
the notifier interacts with get_user_pages(). It is extremely difficult to
use it correctly.
Consolidate all of this code together into the core mmu_notifier and
provide a locking scheme similar to hmm_mirror that allows the user to
safely use get_user_pages() and reliably know if the page list still
matches the mm.
That sounds really good, but could you outline for a moment how that is
archived?
It uses the same basic scheme as hmm and rdma odp, outlined in the
revisions to hmm.rst later on.
Basically,
seq = mmu_range_read_begin(&mrn);
// This is a speculative region
.. get_user_pages()/hmm_range_fault() ..
How do we enforce that this get_user_pages()/hmm_range_fault() doesn't
see outdated page table information?
In other words how the the following race prevented:
CPU A CPU B
invalidate_range_start()
mmu_range_read_begin()
get_user_pages()/hmm_range_fault()
Updating the ptes
invalidate_range_end()
I mean get_user_pages() tries to circumvent this issue by grabbing a
reference to the pages in question, but that isn't sufficient for the
SVM use case.
That's the reason why we had this horrible solution with a r/w lock and
a linked list of BOs in an interval tree.
Regards,
Christian.
// Result cannot be derferenced
take_lock(driver->update);
if (mmu_range_read_retry(&mrn, range.notifier_seq) {
// collision! The results are not correct
goto again
}
// no collision, and now under lock. Now we can de-reference the pages/etc
// program HW
// Now the invalidate callback is responsible to synchronize against changes
unlock(driver->update)
Basically, anything that was using hmm_mirror correctly transisions
over fairly trivially, just with the modification to store a sequence
number to close that race described in the hmm commit.
For something like AMD gpu I expect it to transition to use dma_fence
from the notifier for coherency right before it unlocks driver->update.
Jason
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dma-buf: change DMA-buf locking convention
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 can we get it comitted?
>>> Sorry got a bit smashed past weeks, but should be resurrected now back
>>> from xdc.
>> And any more thoughts on this? I mean we are blocked for month on this
>> now :(
> I replied to both 1 and 2 in this series on 8th Oct. You even replied
> to me in the thread on patch 2 ... but not here (I top posted since
> this detour here just me being confused).
Ok, in this case its my fault. I totally missed your reply on 1 and
thought that the reply on 2 was actually for a different thread.
I'm going to submit the TTM changes separately, cause that is actually a
bug fix for a completely different issue which just happens to surface
because we change the locking.
Thanks,
Christian.
> -Daniel
>
>> Thanks,
>> Christian.
>>
>>> -Daniel
Thanks,
Christian.
Am 24.09.19 um 11:50 schrieb Christian König:
> Am 17.09.19 um 16:56 schrieb Daniel Vetter:
>> [SNIP]
+/* When either the importer or the exporter
can't handle dynamic
+ * mappings we cache the mapping here to avoid issues
with the
+ * reservation object lock.
+ */
+if (dma_buf_attachment_is_dynamic(attach) !=
+dma_buf_is_dynamic(dmabuf)) {
+struct sg_table *sgt;
+
+if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+
+sgt = dmabuf->ops->map_dma_buf(attach,
DMA_BIDIRECTIONAL);
>>> Now we're back to enforcing DMA_BIDI, which works nicely
>>> around the
>>> locking pain, but apparently upsets the arm-soc folks who
>>> want to
>>> control
>>> this better.
>> Take another look at dma_buf_map_attachment(), we still try
>> to get the
>> caching there for ARM.
>>
>> What we do here is to bidirectionally map the buffer to avoid
>> the
>> locking hydra when importer and exporter disagree on locking.
>>
>> So the ARM folks can easily avoid that by switching to
>> dynamic locking
>> for both.
So you still break the contract between importer and exporter,
except not
for anything that's run in intel-gfx-ci so all is good?
>>> No, the contract between importer and exporter stays exactly the
>>> same it
>>> is currently as long as you don't switch to dynamic dma-buf
>>> handling.
>>>
>>> There is no functional change for the ARM folks here. The only
>>> change
>>> which takes effect is between i915 and amdgpu and that is perfectly
>>> covered by intel-gfx-ci.
>> There's people who want to run amdgpu on ARM?
> Sure there are, we even recently fixed some bugs for this.
>
> But as far as I know there is no one currently which is affect by
> this
> change on ARM with amdgpu.
But don't you break them with this now?
>>> No, we see the bidirectional attachment as compatible with the other
>>> ones.
>>>
amdgpu will soon set the dynamic flag on exports, which forces the
caching
at create time (to avoid the locking fun), which will then result in a
EBUSY at map_attachment time because we have a cached mapping, but
it's
the wrong type.
>>> See the check in dma_buf_map_attachment():
>>>
>>> if (attach->dir != direction && attach->dir !=
>>> DMA_BIDIRECTIONAL)
>>> return ERR_PTR(-EBUSY);
>> Hm, I misread this. So yeah should work, +/- the issue that we might
>> not flush enough. But I guess that can be fixed whenever, it's not
>> like dma-api semantics are a great fit for us. Maybe a fixme comment
>> would be useful here ... I'll look at this tomorrow or so because atm
>> brain is slow, I'm down with the usual post-conference cold it seems
>> :-/
> Hope your are feeling better now, adding a comment is of course not a
> problem.
>
> With that fixed can I get an reviewed-by or at least and acked-by?
>
> I want to land at least some parts of those changes now.
>
> Regards,
> Christian.
>
>> -Daniel
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: XDC allocator workshop and Wayland dmabuf hints
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 I'd like to just summarise my > > thoughts on it and make sure everybody is on the same page. Hi Scott and James, thanks for the write-up, it all sounds good to me FWI'mW. > -As you note, this limits things to formats/layouts that can be > composited (basically, things that can be textures). "Things that can > be textures" is a superset of "Things that can be scanned out" for these > purposes on our HW, so that's fine for NVIDIA. Does that hold up > elsewhere? A secondary motivation for me was that the compositor could > transition back to compositing from overlay compositing without > requiring a blit or a new frame from the client in cases where that > didn't hold up, but I don't know if that's interesting or not. It is interesting. The compositor transitioning back from overlay to compositing without requiring a new frame from the client is a minimum requirement under normal circumstances in Wayland architecture. If a compositor cannot do that because of a buffer format, how could a conversion blit be possible either? In Wayland architecture, having the compositor (display server) wait for any client before it is able to update the screen is unacceptable because it has a high risk of disturbing visual glitches. OTOH, I have heard of special use cases, where all buffers should always go on overlays and falling back to composition would be considered a bug. For such cases, there are some ideas towards that at https://gitlab.freedesktop.org/wayland/weston/issues/244 . Thanks, pq pgpwlEJtN4BW1.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/vi: silence an uninitialized variable warning
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_reset'.
Fixes: 425db2553e43 ("drm/amdgpu: expose BACO interfaces to upper level from
PP")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 83196b79edd5..f4ff15378e61 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1421,6 +1421,7 @@ static int pp_get_asic_baco_capability(void *handle, bool
*cap)
{
struct pp_hwmgr *hwmgr = handle;
+ *cap = false;
if (!hwmgr)
return -EINVAL;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 2/2] drm: tda998x: set the connector info
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,
> > struct drm_device *drm)
> > {
> > struct drm_connector *connector = &priv->connector;
> > + struct cec_connector_info conn_info;
> > + struct cec_notifier *notifier;
> > int ret;
> >
> > connector->interlace_allowed = 1;
> > @@ -1353,6 +1355,17 @@ static int tda998x_connector_init(struct
> > tda998x_priv *priv,
> > if (ret)
> > return ret;
> >
> > + cec_fill_conn_info_from_drm(&conn_info, connector);
> > +
> > + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> > + NULL, &conn_info);
> > + if (!notifier)
> > + return -ENOMEM;
> > +
> > + mutex_lock(&priv->cec_notify_mutex);
> > + priv->cec_notify = notifier;
> > + mutex_unlock(&priv->cec_notify_mutex);
>
> As per my previous comments, this is a single-copy atomic operation.
> Either priv->cec_notify is set or it isn't; there is no intermediate
> value. It can't be set to a value until cec_notifier_conn_register()
> has completed. So the lock doesn't help.
>
> > +
> > drm_connector_attach_encoder(&priv->connector,
> >priv->bridge.encoder);
> >
> > @@ -1372,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge
> > *bridge)
...
> > + mutex_lock(&priv->cec_notify_mutex);
> > + cec_notifier_conn_unregister(priv->cec_notify);
> > + priv->cec_notify = NULL;
> > + mutex_unlock(&priv->cec_notify_mutex);
>
> This is the only case where the lock makes sense - to ensure that any
> of the cec_notifier_set_phys_addr*() functions aren't called
> concurrently with it. However, there's no locking around the instance
> in tda998x_connector_get_modes(), so have you ensured that that
> function can't be called concurrently?
>
I assumed that tda998x_connector_get_modes does not need to be
synchronized as it belongs to the connector that gets cleaned up here.
But, on a closer look, I don't think that this assumption necessarily
holds.
If this patch is to be merged, I can send an update that:
- strips locking from tda998x_connector_init,
- in tda998x_connector_get_modes calls cec_notifier* with the lock held.
Thank you!
Re: [PATCHv8 1/2] drm: tda998x: use cec_notifier_conn_(un)register
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. > > > > Signed-off-by: Dariusz Marcinkiewicz > > Signed-off-by: Hans Verkuil > > Please explain in detail what this mutex actually achieves. > > So, all in all, I don't see what this lock is doing, and I think it > should be removed. > > If it's necessary for a future change (which may or may not be merged) > then the lock should be part of that future change, because the change > proposed by this patch certainly does not need it. > Yes, with the change being split into 2 patches like that, the mutex is not needed here. Thank you.
Re: [PATCH 2/2] [RFC] drm/virtgpu: modify uapi with stride/layer_stride fix
> 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 have host and guest agree on the stride. I'd tend to not touch the current TRANSFER ioctls (and virtio commands) though, but integrate that into the blob resource support instead. We probably need blob transfer ioctls and virtio commands anyway. > > I don't think we can simply use the args here without checking we > actually got something from userspace ... > > Correct me if I'm wrong, but doesn't drm_ioctl(..) already make sure > that the pointer is the intersection of the kernel and userspace > sizes, so we can safely append data? i.e, layer_stride and stride > will be zero for old user space + a new kernel. Ah, right, I forgot the generic drm ioctl code does that service for us. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/meson: add RDMA module driver
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), triggered
> by the VSYNC irq and does not handle the RDMA irq.
>
> The RDMA will be usefull to reset and program the AFBC decoder unit
> on each vsync without involving the interrupt handler that can
> be masked for a long period of time, producing display glitches.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/Makefile | 2 +-
> drivers/gpu/drm/meson/meson_drv.c | 14 +++-
> drivers/gpu/drm/meson/meson_drv.h | 6 ++
> drivers/gpu/drm/meson/meson_rdma.c | 123 +
> drivers/gpu/drm/meson/meson_rdma.h | 20 +
> 5 files changed, 161 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/meson/meson_rdma.c
> create mode 100644 drivers/gpu/drm/meson/meson_rdma.h
>
> diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
> index b1fa055aaed3..9e36f0c7b816 100644
> --- a/drivers/gpu/drm/meson/Makefile
> +++ b/drivers/gpu/drm/meson/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
> meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o
> meson_overlay.o
> -meson-drm-y += meson_osd_afbcd.o
> +meson-drm-y += meson_osd_afbcd.o meson_rdma.o
>
> obj-$(CONFIG_DRM_MESON) += meson-drm.o
> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 0f31e70bb94f..2200d8b5252e 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -33,6 +33,7 @@
> #include "meson_venc_cvbs.h"
> #include "meson_viu.h"
> #include "meson_vpp.h"
> +#include "meson_rdma.h"
>
> #define DRIVER_NAME "meson"
> #define DRIVER_DESC "Amlogic Meson DRM driver"
> @@ -295,8 +296,11 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
> meson_venc_init(priv);
> meson_vpp_init(priv);
> meson_viu_init(priv);
> - if (priv->afbcd.ops)
> - priv->afbcd.ops->init(priv);
> + if (priv->afbcd.ops) {
> + ret = priv->afbcd.ops->init(priv);
> + if (ret)
> + return ret;
> + }
>
> /* Encoder Initialization */
>
> @@ -367,12 +371,16 @@ static void meson_drv_unbind(struct device *dev)
> meson_canvas_free(priv->canvas, priv->canvas_id_vd1_2);
> }
>
> + if (priv->afbcd.ops) {
> + priv->afbcd.ops->reset(priv);
> + meson_rdma_free(priv);
> + }
> +
> drm_dev_unregister(drm);
> drm_irq_uninstall(drm);
> drm_kms_helper_poll_fini(drm);
> drm_mode_config_cleanup(drm);
> drm_dev_put(drm);
> -
> }
>
> static const struct component_master_ops meson_drv_master_ops = {
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index de25349be8aa..9995d74c5ded 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -139,6 +139,12 @@ struct meson_drm {
> u64 modifier;
> u32 format;
> } afbcd;
> +
> + struct {
> + dma_addr_t addr_phys;
> + uint32_t *addr;
> + unsigned int offset;
> + } rdma;
> };
>
> static inline int meson_vpu_is_compatible(struct meson_drm *priv,
> diff --git a/drivers/gpu/drm/meson/meson_rdma.c
> b/drivers/gpu/drm/meson/meson_rdma.c
> new file mode 100644
> index ..13fd9b173439
> --- /dev/null
> +++ b/drivers/gpu/drm/meson/meson_rdma.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +
> +#include "meson_drv.h"
> +#include "meson_registers.h"
> +#include "meson_rdma.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 initial implementation handles a single channel (over 8), triggered
> + * by the VSYNC irq and does not handle the RDMA irq.
> + */
> +
> +int meson_rdma_init(struct meson_drm *priv)
> +{
> + /* Allocate a PAGE buffer */
Should be "Allocate a 4K buffer"
> + priv->rdma.addr = dma_alloc_coherent(priv->dev, SZ_4K,
> + &priv->rdma.addr_phys,
> + GFP_KERNEL);
> + if (!priv->rdma.addr)
> + return -ENOMEM;
> +
> + priv->rdma.offset = 0;
> +
> + writel_relaxed(RDMA_CTRL_SW_RESET,
> +priv->io_base + _REG(RDMA_CTRL));
> + writel_relaxed(R
Re: [PATCH V3 0/7] mdev based hardware virtio offloading support
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: > > > > > There are hardware 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 register itself as a new kind of mdev driver. Then > > > > > it provides a unified way for kernel virtio driver to talk with mdev > > > > > device implementation. > > > > > > > > > > Though the series only contains kernel driver support, the goal is to > > > > > make the transport generic enough to support userspace drivers. This > > > > > means vhost-mdev[1] could be built on top as well by resuing the > > > > > transport. > > > > > > > > > > A sample driver is also implemented which simulate a virito-net > > > > > loopback ethernet device on top of vringh + workqueue. This could be > > > > > used as a reference implementation for real hardware driver. > > > > > > > > > > Consider mdev framework only support VFIO device and driver right now, > > > > > this series also extend it to support other types. This is done > > > > > through introducing class id to the device and pairing it with > > > > > id_talbe claimed by the driver. On top, this seris also decouple > > > > > device specific parents ops out of the common ones. > > > > I was curious so I took a quick look and posted comments. > > > > > > > > I guess this driver runs inside the guest since it registers virtio > > > > devices? > > > > > > It could run in either guest or host. But the main focus is to run in the > > > host then we can use virtio drivers in containers. > > > > > > > > > > If this is used with physical PCI devices that support datapath > > > > offloading then how are physical devices presented to the guest without > > > > SR-IOV? > > > > > > We will do control path meditation through vhost-mdev[1] and > > > vhost-vfio[2]. > > > Then we will present a full virtio compatible ethernet device for guest. > > > > > > SR-IOV is not a must, any mdev device that implements the API defined in > > > patch 5 can be used by this framework. > > What I'm trying to understand is: if you want to present a virtio-pci > > device to the guest (e.g. using vhost-mdev or vhost-vfio), then how is > > that related to this patch series? > > > This series introduce some infrastructure that would be used by vhost-mdev: > > 1) allow new type of mdev devices/drivers other than vfio (through class_id > and device ops) > > 2) a set of virtio specific callbacks that will be used by both vhost-mdev > and virtio-mdev defined in patch 5 > > Then vhost-mdev can be implemented on top: a new mdev class id but reuse the > callback defined in 2. Through this way the parent can provides a single set > of callbacks (device ops) for both kernel virtio driver (through > virtio-mdev) or userspace virtio driver (through vhost-mdev). Okay, thanks for explaining! Stefan signature.asc Description: PGP signature
[Bug 205147] Unable to shut down - radeon_drv.c - radeon_suspend_kms()
https://bugzilla.kernel.org/show_bug.cgi?id=205147 wwa (10dma...@gmail.com) changed: What|Removed |Added CC||10dma...@gmail.com --- Comment #2 from wwa (10dma...@gmail.com) --- Hi, I also have same problem and can confirm that reverting commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 fixes it. my hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770], PCI-E, on a MICRO-STAR INTERNATIONAL CO.,LTD MS-7599/770-C45 (MS-7599), BIOS V1.15 03/04/2011 (this bug kind of reminds me of https://bugs.freedesktop.org/show_bug.cgi?id=99524) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 2/2] drm: tda998x: set the connector info
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 int tda998x_connector_init(struct
> > > tda998x_priv *priv,
> > > struct drm_device *drm)
> > > {
> > > struct drm_connector *connector = &priv->connector;
> > > + struct cec_connector_info conn_info;
> > > + struct cec_notifier *notifier;
> > > int ret;
> > >
> > > connector->interlace_allowed = 1;
> > > @@ -1353,6 +1355,17 @@ static int tda998x_connector_init(struct
> > > tda998x_priv *priv,
> > > if (ret)
> > > return ret;
> > >
> > > + cec_fill_conn_info_from_drm(&conn_info, connector);
> > > +
> > > + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> > > + NULL, &conn_info);
> > > + if (!notifier)
> > > + return -ENOMEM;
> > > +
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + priv->cec_notify = notifier;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > As per my previous comments, this is a single-copy atomic operation.
> > Either priv->cec_notify is set or it isn't; there is no intermediate
> > value. It can't be set to a value until cec_notifier_conn_register()
> > has completed. So the lock doesn't help.
> >
>
> > > +
> > > drm_connector_attach_encoder(&priv->connector,
> > >priv->bridge.encoder);
> > >
> > > @@ -1372,6 +1385,11 @@ static void tda998x_bridge_detach(struct
> > > drm_bridge *bridge)
> ...
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + cec_notifier_conn_unregister(priv->cec_notify);
> > > + priv->cec_notify = NULL;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > This is the only case where the lock makes sense - to ensure that any
> > of the cec_notifier_set_phys_addr*() functions aren't called
> > concurrently with it. However, there's no locking around the instance
> > in tda998x_connector_get_modes(), so have you ensured that that
> > function can't be called concurrently?
> >
> I assumed that tda998x_connector_get_modes does not need to be
> synchronized as it belongs to the connector that gets cleaned up here.
> But, on a closer look, I don't think that this assumption necessarily
> holds.
>
> If this patch is to be merged, I can send an update that:
> - strips locking from tda998x_connector_init,
> - in tda998x_connector_get_modes calls cec_notifier* with the lock held.
Okay, I'd suggest a comment in the code describing precisely what the
lock is doing would be a good idea, as it may not be obvious in the
future.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH v2 0/3] drm/meson: implement RDMA for AFBC reset on vsync
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 irq. The RDMA will be usefull to reset and program the AFBC decoder unit on each vsync without involving the interrupt handler that can be masked for a long period of time, producing display glitches. For this we use the meson_rdma_writel_sync() which adds the register write tuple (VPU register offset and register value) to the RDMA buffer and write the value to the HW. When enabled, the RDMA is enabled to rewritte the same sequence at the next VSYNC event, until a new buffer is committed to the OSD plane. The the Amlogic G12A is switched to RDMA, the Amlogic GXM Decoder doesn't need a reset/reprogram at each vsync. Changes since v1 at [1]: - Fixed a regression when AFBC was not used, adding a reset() call for the afbc module - Added a define for the RDMA descriptor size - Fixed overflow detection [1] https://patchwork.freedesktop.org/series/68021/#rev1 Neil Armstrong (3): drm/meson: add RDMA register bits defines drm/meson: add RDMA module driver drm/meson: use RDMA to reconfigure AFBC on vsync drivers/gpu/drm/meson/Makefile | 2 +- drivers/gpu/drm/meson/meson_crtc.c | 27 ++--- drivers/gpu/drm/meson/meson_drv.c | 14 ++- drivers/gpu/drm/meson/meson_drv.h | 6 ++ drivers/gpu/drm/meson/meson_osd_afbcd.c | 100 ++ drivers/gpu/drm/meson/meson_rdma.c | 132 drivers/gpu/drm/meson/meson_rdma.h | 21 drivers/gpu/drm/meson/meson_registers.h | 48 + 8 files changed, 283 insertions(+), 67 deletions(-) create mode 100644 drivers/gpu/drm/meson/meson_rdma.c create mode 100644 drivers/gpu/drm/meson/meson_rdma.h -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/meson: add RDMA register bits defines
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 | 48 + 1 file changed, 48 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h index 547bee04b46e..8ea00546cd4e 100644 --- a/drivers/gpu/drm/meson/meson_registers.h +++ b/drivers/gpu/drm/meson/meson_registers.h @@ -1211,11 +1211,59 @@ #define RDMA_AHB_START_ADDR_7 0x110e #define RDMA_AHB_END_ADDR_7 0x110f #define RDMA_ACCESS_AUTO 0x1110 +#defineRDMA_ACCESS_TRIGGER_CHAN3 GENMASK(31, 24) +#defineRDMA_ACCESS_TRIGGER_CHAN2 GENMASK(23, 16) +#defineRDMA_ACCESS_TRIGGER_CHAN1 GENMASK(15, 8) +#defineRDMA_ACCESS_TRIGGER_STOP0 +#defineRDMA_ACCESS_TRIGGER_VSYNC 1 +#defineRDMA_ACCESS_TRIGGER_LINE32 +#defineRDMA_ACCESS_RW_FLAG_CHAN3 BIT(7) +#defineRDMA_ACCESS_RW_FLAG_CHAN2 BIT(6) +#defineRDMA_ACCESS_RW_FLAG_CHAN1 BIT(5) +#defineRDMA_ACCESS_ADDR_INC_CHAN3 BIT(3) +#defineRDMA_ACCESS_ADDR_INC_CHAN2 BIT(2) +#defineRDMA_ACCESS_ADDR_INC_CHAN1 BIT(1) #define RDMA_ACCESS_AUTO2 0x +#defineRDMA_ACCESS_RW_FLAG_CHAN7 BIT(7) +#defineRDMA_ACCESS_RW_FLAG_CHAN6 BIT(6) +#defineRDMA_ACCESS_RW_FLAG_CHAN5 BIT(5) +#defineRDMA_ACCESS_RW_FLAG_CHAN4 BIT(4) +#defineRDMA_ACCESS_ADDR_INC_CHAN7 BIT(3) +#defineRDMA_ACCESS_ADDR_INC_CHAN6 BIT(2) +#defineRDMA_ACCESS_ADDR_INC_CHAN5 BIT(1) +#defineRDMA_ACCESS_ADDR_INC_CHAN4 BIT(0) #define RDMA_ACCESS_AUTO3 0x1112 +#defineRDMA_ACCESS_TRIGGER_CHAN7 GENMASK(31, 24) +#defineRDMA_ACCESS_TRIGGER_CHAN6 GENMASK(23, 16) +#defineRDMA_ACCESS_TRIGGER_CHAN5 GENMASK(15, 8) +#defineRDMA_ACCESS_TRIGGER_CHAN4 GENMASK(7, 0) #define RDMA_ACCESS_MAN 0x1113 +#defineRDMA_ACCESS_MAN_RW_FLAG BIT(2) +#defineRDMA_ACCESS_MAN_ADDR_INCBIT(1) +#defineRDMA_ACCESS_MAN_START BIT(0) #define RDMA_CTRL 0x1114 +#defineRDMA_IRQ_CLEAR_CHAN7BIT(31) +#defineRDMA_IRQ_CLEAR_CHAN6BIT(30) +#defineRDMA_IRQ_CLEAR_CHAN5BIT(29) +#defineRDMA_IRQ_CLEAR_CHAN4BIT(28) +#defineRDMA_IRQ_CLEAR_CHAN3BIT(27) +#defineRDMA_IRQ_CLEAR_CHAN2BIT(26) +#defineRDMA_IRQ_CLEAR_CHAN1BIT(25) +#defineRDMA_IRQ_CLEAR_CHAN_MAN BIT(24) +#defineRDMA_DEFAULT_CONFIG (BIT(7) | BIT(6)) +#defineRDMA_CTRL_AHB_WR_BURST GENMASK(5, 4) +#defineRDMA_CTRL_AHB_RD_BURST GENMASK(3, 2) +#defineRDMA_CTRL_SW_RESET BIT(1) +#defineRDMA_CTRL_FREE_CLK_EN BIT(0) #define RDMA_STATUS 0x1115 +#defineRDMA_IRQ_STAT_CHAN7 BIT(31) +#defineRDMA_IRQ_STAT_CHAN6 BIT(30) +#defineRDMA_IRQ_STAT_CHAN5 BIT(29) +#defineRDMA_IRQ_STAT_CHAN4 BIT(28) +#defineRDMA_IRQ_STAT_CHAN3 BIT(27) +#defineRDMA_IRQ_STAT_CHAN2 BIT(26) +#defineRDMA_IRQ_STAT_CHAN1 BIT(25) +#defineRDMA_IRQ_STAT_CHAN_MAN BIT(24) #define RDMA_STATUS2 0x1116 #define RDMA_STATUS3 0x1117 #define L_GAMMA_CNTL_PORT 0x1400 -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/meson: use RDMA to reconfigure AFBC on vsync
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 handler that can
be masked for a long period of time, producing display glitches.
For this we use the meson_rdma_writel_sync() which adds the register
write tuple (VPU register offset and register value) to the RDMA buffer
and write the value to the HW.
When enabled, the RDMA is enabled to rewritte the same sequence at the
next VSYNC event, until a new buffer is committed to the OSD plane.
The the Amlogic G12A is switched to RDMA, the Amlogic GXM Decoder
doesn't need a reset/reprogram at each vsync.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 27 ++-
drivers/gpu/drm/meson/meson_osd_afbcd.c | 100 ++--
2 files changed, 64 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index d28efd0dbf11..8e0cf03e45eb 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -23,6 +23,7 @@
#include "meson_registers.h"
#include "meson_venc.h"
#include "meson_viu.h"
+#include "meson_rdma.h"
#include "meson_vpp.h"
#include "meson_osd_afbcd.h"
@@ -39,8 +40,6 @@ struct meson_crtc {
void (*enable_osd1_afbc)(struct meson_drm *priv);
void (*disable_osd1_afbc)(struct meson_drm *priv);
unsigned int viu_offset;
- bool vsync_forced;
- bool vsync_disabled;
};
#define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
@@ -51,7 +50,6 @@ static int meson_crtc_enable_vblank(struct drm_crtc *crtc)
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
- meson_crtc->vsync_disabled = false;
meson_venc_enable_vsync(priv);
return 0;
@@ -62,10 +60,7 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
- if (!meson_crtc->vsync_forced) {
- meson_crtc->vsync_disabled = true;
- meson_venc_disable_vsync(priv);
- }
+ meson_venc_disable_vsync(priv);
}
static const struct drm_crtc_funcs meson_crtc_funcs = {
@@ -368,10 +363,11 @@ void meson_crtc_irq(struct meson_drm *priv)
if (meson_crtc->enable_osd1)
meson_crtc->enable_osd1(priv);
- if (priv->viu.osd1_afbcd)
- meson_crtc->vsync_forced = true;
- else
- meson_crtc->vsync_forced = false;
+ if (priv->viu.osd1_afbcd) {
+ priv->afbcd.ops->reset(priv);
+ priv->afbcd.ops->setup(priv);
+ priv->afbcd.ops->enable(priv);
+ }
priv->viu.osd1_commit = false;
}
@@ -595,15 +591,6 @@ void meson_crtc_irq(struct meson_drm *priv)
priv->viu.vd1_commit = false;
}
- if (meson_crtc->vsync_forced && priv->viu.osd1_afbcd) {
- priv->afbcd.ops->reset(priv);
- priv->afbcd.ops->setup(priv);
- priv->afbcd.ops->enable(priv);
- }
-
- if (meson_crtc->vsync_disabled)
- return;
-
drm_crtc_handle_vblank(priv->crtc);
spin_lock_irqsave(&priv->drm->event_lock, flags);
diff --git a/drivers/gpu/drm/meson/meson_osd_afbcd.c
b/drivers/gpu/drm/meson/meson_osd_afbcd.c
index aae4341bedaf..f12e0271f166 100644
--- a/drivers/gpu/drm/meson/meson_osd_afbcd.c
+++ b/drivers/gpu/drm/meson/meson_osd_afbcd.c
@@ -12,6 +12,7 @@
#include "meson_drv.h"
#include "meson_registers.h"
#include "meson_viu.h"
+#include "meson_rdma.h"
#include "meson_osd_afbcd.h"
/*
@@ -270,6 +271,14 @@ static bool meson_g12a_afbcd_supported_fmt(u64 modifier,
uint32_t format)
static int meson_g12a_afbcd_init(struct meson_drm *priv)
{
+ int ret;
+
+ ret = meson_rdma_init(priv);
+ if (ret)
+ return ret;
+
+ meson_rdma_setup(priv);
+
/* Handle AFBC Decoder reset manually */
writel_bits_relaxed(MALI_AFBCD_MANUAL_RESET, MALI_AFBCD_MANUAL_RESET,
priv->io_base + _REG(MALI_AFBCD_TOP_CTRL));
@@ -279,27 +288,32 @@ static int meson_g12a_afbcd_init(struct meson_drm *priv)
static int meson_g12a_afbcd_reset(struct meson_drm *priv)
{
- writel_relaxed(VIU_SW_RESET_G12A_AFBC_ARB |
- VIU_SW_RESET_G12A_OSD1_AFBCD,
- priv->io_base + _REG(VIU_SW_RESET));
- writel_relaxed(0, priv->io_base + _REG(VIU_SW_RESET));
+ meson_rdma_reset(priv);
+
+ meson_rdma_writel_sync(priv, VIU_SW_RESET_G12A_AFBC_ARB |
+ VIU_SW_RESET_G12A_O
[PATCH v2 2/3] drm/meson: add RDMA module driver
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 irq.
The RDMA will be usefull to reset and program the AFBC decoder unit
on each vsync without involving the interrupt handler that can
be masked for a log period of time, producing display glitches.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Makefile | 2 +-
drivers/gpu/drm/meson/meson_drv.c | 14 ++-
drivers/gpu/drm/meson/meson_drv.h | 6 ++
drivers/gpu/drm/meson/meson_rdma.c | 132 +
drivers/gpu/drm/meson/meson_rdma.h | 21 +
5 files changed, 171 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/meson/meson_rdma.c
create mode 100644 drivers/gpu/drm/meson/meson_rdma.h
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index b1fa055aaed3..9e36f0c7b816 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o
meson_overlay.o
-meson-drm-y += meson_osd_afbcd.o
+meson-drm-y += meson_osd_afbcd.o meson_rdma.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 0f31e70bb94f..2200d8b5252e 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -33,6 +33,7 @@
#include "meson_venc_cvbs.h"
#include "meson_viu.h"
#include "meson_vpp.h"
+#include "meson_rdma.h"
#define DRIVER_NAME "meson"
#define DRIVER_DESC "Amlogic Meson DRM driver"
@@ -295,8 +296,11 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
meson_venc_init(priv);
meson_vpp_init(priv);
meson_viu_init(priv);
- if (priv->afbcd.ops)
- priv->afbcd.ops->init(priv);
+ if (priv->afbcd.ops) {
+ ret = priv->afbcd.ops->init(priv);
+ if (ret)
+ return ret;
+ }
/* Encoder Initialization */
@@ -367,12 +371,16 @@ static void meson_drv_unbind(struct device *dev)
meson_canvas_free(priv->canvas, priv->canvas_id_vd1_2);
}
+ if (priv->afbcd.ops) {
+ priv->afbcd.ops->reset(priv);
+ meson_rdma_free(priv);
+ }
+
drm_dev_unregister(drm);
drm_irq_uninstall(drm);
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
drm_dev_put(drm);
-
}
static const struct component_master_ops meson_drv_master_ops = {
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index de25349be8aa..9995d74c5ded 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -139,6 +139,12 @@ struct meson_drm {
u64 modifier;
u32 format;
} afbcd;
+
+ struct {
+ dma_addr_t addr_phys;
+ uint32_t *addr;
+ unsigned int offset;
+ } rdma;
};
static inline int meson_vpu_is_compatible(struct meson_drm *priv,
diff --git a/drivers/gpu/drm/meson/meson_rdma.c
b/drivers/gpu/drm/meson/meson_rdma.c
new file mode 100644
index ..4ef5e402d5ca
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_rdma.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+
+#include "meson_drv.h"
+#include "meson_registers.h"
+#include "meson_rdma.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 initial implementation handles a single channel (over 8), triggered
+ * by the VSYNC irq and does not handle the RDMA irq.
+ */
+
+#define RDMA_DESC_SIZE (sizeof(uint32_t) * 2)
+
+int meson_rdma_init(struct meson_drm *priv)
+{
+ /* Allocate a 4k buffer */
+ priv->rdma.addr = dma_alloc_coherent(priv->dev, SZ_4K,
+&priv->rdma.addr_phys,
+GFP_KERNEL);
+ if (!priv->rdma.addr)
+ return -ENOMEM;
+
+ priv->rdma.offset = 0;
+
+ writel_relaxed(RDMA_CTRL_SW_RESET,
+ priv->io_base + _REG(RDMA_CTRL));
+ writel_relaxed(RDMA_DEFAULT_CONFIG |
+ FIELD_PREP(RDMA_CTRL_AHB_WR_BURST, 3) |
+ FIELD_PREP(RDMA_CTRL_AHB_RD_BURST, 0),
+ priv->io_base + _REG(RDMA_CTRL));
+
+ return 0;
+}
+
+void mes
Re: [PATCH v10 5/6] arm64: dts: allwinner: a64: Add MIPI DSI pipeline
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, Jagan Teki wrote:
> > > > > Add MIPI DSI pipeline for Allwinner A64.
> > > > >
> > > > > - dsi node, with A64 compatible since it doesn't support
> > > > > DSI_SCLK gating unlike A33
> > > > > - dphy node, with A64 compatible with A33 fallback since
> > > > > DPHY on A64 and A33 is similar
> > > > > - finally, attach the dsi_in to tcon0 for complete MIPI DSI
> > > > >
> > > > > Signed-off-by: Jagan Teki
> > > > > Tested-by: Merlijn Wajer
> > > > > ---
> > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 38
> > > > > +++
> > > > > 1 file changed, 38 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > > index 69128a6dfc46..ad4170b8aee0 100644
> > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > > > @@ -382,6 +382,12 @@
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > > reg = <1>;
> > > > > +
> > > > > + tcon0_out_dsi: endpoint@1 {
> > > > > + reg = <1>;
> > > > > + remote-endpoint =
> > > > > <&dsi_in_tcon0>;
> > > > > + allwinner,tcon-channel
> > > > > = <1>;
> > > > > + };
> > > > > };
> > > > > };
> > > > > };
> > > > > @@ -1003,6 +1009,38 @@
> > > > > status = "disabled";
> > > > > };
> > > > >
> > > > > + dsi: dsi@1ca {
> > > > > + compatible = "allwinner,sun50i-a64-mipi-dsi";
> > > > > + reg = <0x01ca 0x1000>;
> > > > > + interrupts = ;
> > > > > + clocks = <&ccu CLK_BUS_MIPI_DSI>;
> > > > > + clock-names = "bus";
> > > >
> > > > This won't validate with the bindings you have either here, since it
> > > > still expects bus and mod.
> > > >
> > > > I guess in that cas, we can just drop clock-names, which will require
> > > > a bit of work on the driver side as well.
> > >
> > > Okay.
> > > mod clock is not required for a64, ie reason we have has_mod_clk quirk
> > > patch. Adjust the clock-names: on dt-bindings would make sense here,
> > > what do you think?
> >
> > I'm confused, what are you suggesting?
>
> Sorry for the confusion.
>
> The mod clock is not required for A64 and we have a patch for handling
> mod clock using has_mod_clk quirk(on the series), indeed the mod clock
> is available in A31 and not needed for A64. So, to satisfy this
> requirement the clock-names on dt-bindings can update to make mod
> clock-name is optional and bus clock is required.
No, the bus clock name is not needed if there's only one clock.
> I'm not exactly sure, this is correct but trying to understand if it
> is possible or not? something like
>
>clocks:
> minItems: 1
> maxItems: 2
> items:
>- description: Bus Clock
>- description: Module Clock
That's correct.
>clock-names:
> minItems: 1
> maxItems: 2
> items:
>- const: bus
>- const: mod
Here, just keep the current clock-names definition, and make it
required only for SoCs that are not the A64
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 (as it seems) common
> > problem in lowlevel PWM drivers. By not relying on the period and duty
> > cycle being retrievable from a disabled PWM this type of problem is
> > worked around.
> >
> > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > combo once is also more effective.
> >
> > Signed-off-by: Uwe Kleine-König
> > ---
> > Hello,
> >
> > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > far as I understand the problem this is a combination of the backend pwm
> > driver yielding surprising results and the pwm-bl driver doing things
> > more complicated than necessary.
> >
> > So I guess this patch works around these problems. Still it would be
> > interesting to find out the details in the imx driver that triggers the
> > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > print *state at the beginning of pwm_imx27_apply() and the end of
> > pwm_imx27_get_state() and provide the results?
> >
> > Note I only compile tested this change.
>
> Hi Uwe,
> I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> thread that I have a similar problem when you submitted this patch.
>
> So here are my few cents:
>
> My setup is as follows:
> - imx6dl-yapp4-draco with i.MX6Solo
> - backlight is controlled with inverted PWM signal
> - max brightness level = 32, default brightness level set to 32 in DT.
>
> 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
>pwm_get_state() return the last implemented state):
>
> - System boots to userspace and backlight is enabled all the time from
>power up.
>
>$ dmesg | grep state
>[1.763381] get state end: -1811360608, enabled: 0
What is -1811360608? When I wrote "print *state" above, I thought about
something like:
pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
__func__, state->period, state->duty_cycle, state->polarity,
state->enabled);
A quick look into drivers/pwm/pwm-imx27.c shows that this is another
driver that yields duty_cycle = 0 when the hardware is off.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
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 > > > wholesale to bridge? But for me, the pragmatic approach would be this > > > stop-gap. > > > > > > > This is a good idea, and I vote +ULONG_MAX :) > > > > and I also checked tda998x driver, it supports bridge. so swap the > > wholesale to brige is perfect. :) > > > > Well, as Mihail wrote, it's definitely not perfect. > > Today, if you rmmod tda998x with the DPU driver still loaded, > everything will be unbound gracefully. > > If we swap to bridge, then rmmod'ing tda998x (or any other bridge > driver the DPU is using) with the DPU driver still loaded will result > in a crash. I haven't read the bridge code, but seems this is a bug of drm_bridge, since if the bridge is still in using by others, the rmmod should fail And personally opinion, if the bridge doesn't handle the dependence. for us: - add such support to bridge or - just do the insmod/rmmod in correct order. > So, there really are proper benefits to sticking with the component > code for tda998x, which is why I'd like to understand why you're so > against this patch? > This change handles two different connectors in komeda internally, compare with one interface, it increases the complexity, more risk of bug and more cost of maintainance. So my suggestion is keeping on one single interface in komeda, no matter it is bridge or component, but I'd like it only one, but not them both in komeda. Thanks James > Thanks, > -Brian
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
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 +, 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 > > > > stop-gap. > > > > > > > > > > This is a good idea, and I vote +ULONG_MAX :) > > > > > > and I also checked tda998x driver, it supports bridge. so swap the > > > wholesale to brige is perfect. :) > > > > > > > Well, as Mihail wrote, it's definitely not perfect. > > > > Today, if you rmmod tda998x with the DPU driver still loaded, > > everything will be unbound gracefully. > > > > If we swap to bridge, then rmmod'ing tda998x (or any other bridge > > driver the DPU is using) with the DPU driver still loaded will result > > in a crash. > > I haven't read the bridge code, but seems this is a bug of drm_bridge, > since if the bridge is still in using by others, the rmmod should fail > Correct, but there's no fix for that today. You can also take a look at the thread linked from Mihail's cover letter. > And personally opinion, if the bridge doesn't handle the dependence. > for us: > > - add such support to bridge That would certainly be helpful. I don't know if there's consensus on how to do that. > or > - just do the insmod/rmmod in correct order. > > > So, there really are proper benefits to sticking with the component > > code for tda998x, which is why I'd like to understand why you're so > > against this patch? > > > > This change handles two different connectors in komeda internally, compare > with one interface, it increases the complexity, more risk of bug and more > cost of maintainance. > Well, it's only about how to bind the drivers - two different methods of binding, not two different connectors. I would argue that carrying our out-of-tree patches to support both platforms is a larger maintenance burden. Honestly this looks like a win-win to me. We get the superior approach when its supported, and still get to support bridges which are more common. As/when improvements are made to the bridge code we can remove the component bits and not lose anything. > So my suggestion is keeping on one single interface in komeda, no > matter it is bridge or component, but I'd like it only one, but not > them both in komeda. If we can put the effort into fixing bridges then I guess that's the best approach for everyone :-) Might not be easy though! -Brian > > Thanks > James > > > Thanks, > > -Brian
[PATCH V4 0/6] mdev based hardware virtio offloading support
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 register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to talk with mdev device implementation. Though the series only contains kernel driver support, the goal is to make the transport generic enough to support userspace drivers. This means vhost-mdev[1] could be built on top as well by resuing the transport. A sample driver is also implemented which simulate a virito-net loopback ethernet device on top of vringh + workqueue. This could be used as a reference implementation for real hardware driver. Also a real ICF VF driver was also posted here[2] which is a good reference for vendors who is interested in their own virtio datapath offloading product. Consider mdev framework only support VFIO device and driver right now, this series also extend it to support other types. This is done through introducing class id to the device and pairing it with id_talbe claimed by the driver. On top, this seris also decouple device specific parents ops out of the common ones. Pktgen test was done with virito-net + mvnet loop back device. Please review. [1] https://lkml.org/lkml/2019/9/26/15 [2] https://lkml.org/lkml/2019/10/15/1226 Changes from V3: - document that class id (device ops) must be specified in create() - add WARN() when trying to set class_id when it has already set - add WARN() when class_id is not specified in create() and correctly return an error in this case - correct the prototype of mdev_set_class() in the doc - add documention of mdev_set_class() - remove the unnecessary "class_id_fail" label when class id is not specified in create() - convert id_table in vfio_mdev to const - move mdev_set_class and its friends after mdev_uuid() - suqash the patch of bus uevent into patch of introducing class id - tweak the words in the docs per Cornelia suggestion - tie class_id and device ops through class specific initialization routine like mdev_set_vfio_ops() - typos fixes in the docs of virtio-mdev callbacks - document the usage of virtqueues in struct virtio_mdev_device - remove the useless vqs array in struct virtio_mdev_device - rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX Changes from V2: - fail when class_id is not specified - drop the vringh patch - match the doc to the code - tweak the commit log - move device_ops from parent to mdev device - remove the unused MDEV_ID_VHOST Changes from V1: - move virtio_mdev.c to drivers/virtio - store class_id in mdev_device instead of mdev_parent - store device_ops in mdev_device instead of mdev_parent - reorder the patch, vringh fix comes first - really silent compiling warnings - really switch to use u16 for class_id - uevent and modpost support for mdev class_id - vraious tweaks per comments from Parav Changes from RFC-V2: - silent compile warnings on some specific configuration - use u16 instead u8 for class id - reseve MDEV_ID_VHOST for future vhost-mdev work - introduce "virtio" type for mvnet and make "vhost" type for future work - add entries in MAINTAINER - tweak and typos fixes in commit log Changes from RFC-V1: - rename device id to class id - add docs for class id and device specific ops (device_ops) - split device_ops into seperate headers - drop the mdev_set_dma_ops() - use device_ops to implement the transport API, then it's not a part of UAPI any more - use GFP_ATOMIC in mvnet sample device and other tweaks - set_vring_base/get_vring_base support for mvnet device Jason Wang (6): mdev: class id support modpost: add support for mdev class id mdev: introduce device specific ops mdev: introduce virtio device and its device ops virtio: introduce a mdev based transport docs: sample driver to demonstrate how to implement virtio-mdev framework .../driver-api/vfio-mediated-device.rst | 22 +- MAINTAINERS | 2 + drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 13 +- drivers/vfio/mdev/mdev_core.c | 38 + drivers/vfio/mdev/mdev_driver.c | 22 + drivers/vfio/mdev/mdev_private.h | 2 + drivers/vfio/mdev/vfio_mdev.c | 45 +- drivers/virtio/Kconfig| 7 + drivers/virtio/Makefile | 1 + drivers/virtio/virtio_mdev.c | 409 +++ include/linux/mdev.h | 55 +- include/linux/mod_devicetable.h | 8 + include/linux/vfio_mdev.h | 52 ++ include/linux/virtio_mdev.h | 151 samples/Kconfig | 7 + sa
[PATCH V4 1/6] mdev: class id support
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.
So this patch adds id_table to mdev_driver and class_id for mdev
device with the match method for mdev bus.
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 7 +-
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/mdev/mdev_core.c | 18 +++
drivers/vfio/mdev/mdev_driver.c | 22 +++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 +
include/linux/mdev.h | 8 +++
include/linux/mod_devicetable.h | 8 +++
samples/vfio-mdev/mbochs.c| 1 +
samples/vfio-mdev/mdpy.c | 1 +
samples/vfio-mdev/mtty.c | 1 +
13 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..f9a78d75a67a 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
* @probe: called when new device created
* @remove: called when device removed
* @driver: device driver structure
+ * @id_table: the ids serviced by this driver
*/
struct mdev_driver {
const char *name;
int (*probe) (struct device *dev);
void (*remove) (struct device *dev);
struct device_driverdriver;
+const struct mdev_class_id *id_table;
};
A mediated bus driver for mdev should use this structure in the function calls
@@ -165,12 +167,15 @@ register itself with the mdev core driver::
extern int mdev_register_device(struct device *dev,
const struct mdev_parent_ops *ops);
+It is also required to specify the class_id in create() callback through::
+
+ int mdev_set_class(struct mdev_device *mdev, u16 id);
+
However, the mdev_parent_ops structure is not required in the function call
that a driver should use to unregister itself with the mdev core driver::
extern void mdev_unregister_device(struct device *dev);
-
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 343d79c1cb7e..6420f0dbd31b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
out:
return ret;
}
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f0d71ab77c50..cf2c013ae32f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
struct mdev_device *mdev)
private->sch->schid.ssid,
private->sch->schid.sch_no);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 5c0f53c6dde7..07c31070afeb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_dev->lock);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..3a9c52d71b4e 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -45,6 +45,16 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
}
EXPORT_SYMBOL(mdev_set_drvdata);
+/* Specify the class for the mdev device, this must be called during
+ * create() callback.
+ */
+void mdev_set_class(struct mdev_device *mdev, u16 id)
+{
+ WARN_ON(mdev->class_id);
+ mdev->class_id = id;
+}
+EXPORT_SYMBOL(mdev_set_class);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return &mdev->dev;
@@ -135,6 +145,7 @@ static int mdev_device_remove_cb(struct device *dev, void
*data)
* mdev_register_device : Register a device
* @dev: devic
[PATCH V4 2/6] modpost: add support for mdev class id
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/drivers/vfio/mdev/vfio_mdev.c
index 7b24ee9cb8dd..cb701cd646f0 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -125,6 +125,8 @@ static const struct mdev_class_id id_table[] = {
{ 0 },
};
+MODULE_DEVICE_TABLE(mdev, id_table);
+
static struct mdev_driver vfio_mdev_driver = {
.name = "vfio_mdev",
.probe = vfio_mdev_probe,
diff --git a/scripts/mod/devicetable-offsets.c
b/scripts/mod/devicetable-offsets.c
index 054405b90ba4..6cbb1062488a 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -231,5 +231,8 @@ int main(void)
DEVID(wmi_device_id);
DEVID_FIELD(wmi_device_id, guid_string);
+ DEVID(mdev_class_id);
+ DEVID_FIELD(mdev_class_id, id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index c91eba751804..d365dfe7c718 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1335,6 +1335,15 @@ static int do_wmi_entry(const char *filename, void
*symval, char *alias)
return 1;
}
+/* looks like: "mdev:cN" */
+static int do_mdev_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, mdev_class_id, id);
+
+ sprintf(alias, "mdev:c%02X", id);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1407,6 +1416,7 @@ static const struct devtable devtable[] = {
{"typec", SIZE_typec_device_id, do_typec_entry},
{"tee", SIZE_tee_client_device_id, do_tee_entry},
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
+ {"mdev", SIZE_mdev_class_id, do_mdev_entry},
};
/* Create MODULE_ALIAS() statements.
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 3/6] mdev: introduce device specific ops
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 be used by
vfio-mdev and virtio-mdev.
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 25 +
MAINTAINERS | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ---
drivers/s390/cio/vfio_ccw_ops.c | 18 ---
drivers/s390/crypto/vfio_ap_ops.c | 14 +++--
drivers/vfio/mdev/mdev_core.c | 18 +--
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 37 ++---
include/linux/mdev.h | 45
include/linux/vfio_mdev.h | 52 +++
samples/vfio-mdev/mbochs.c| 20 ---
samples/vfio-mdev/mdpy.c | 20 ---
samples/vfio-mdev/mtty.c | 18 ---
13 files changed, 184 insertions(+), 103 deletions(-)
create mode 100644 include/linux/vfio_mdev.h
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index f9a78d75a67a..0cca84d19603 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -152,11 +152,22 @@ callbacks per mdev parent device, per mdev type, or any
other categorization.
Vendor drivers are expected to be fully asynchronous in this respect or
provide their own internal resource protection.)
-The callbacks in the mdev_parent_ops structure are as follows:
-
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
+As multiple types of mediated devices may be supported, the device
+must set up the class id and the device specific callbacks in create()
+callback. E.g for vfio-mdev device it needs to be done through:
+
+int mdev_set_vfio_ops(struct mdev_device *mdev,
+ const struct vfio_mdev_ops *vfio_ops);
+
+The class id (set to MDEV_CLASS_ID_VFIO) is used to match a device
+with an mdev driver via its id table. The device specific callbacks
+(specified in *ops) are obtainable via mdev_get_dev_ops() (for use by
+the mdev bus driver). A vfio-mdev device (class id MDEV_CLASS_ID_VFIO)
+uses the following device-specific ops:
+
+* open: open callback of vfio mediated device
+* close: close callback of vfio mediated device
+* ioctl: ioctl callback of vfio mediated device
* read : read emulation callback
* write: write emulation callback
* mmap: mmap emulation callback
@@ -167,10 +178,6 @@ register itself with the mdev core driver::
extern int mdev_register_device(struct device *dev,
const struct mdev_parent_ops *ops);
-It is also required to specify the class_id in create() callback through::
-
- int mdev_set_class(struct mdev_device *mdev, u16 id);
-
However, the mdev_parent_ops structure is not required in the function call
that a driver should use to unregister itself with the mdev core driver::
diff --git a/MAINTAINERS b/MAINTAINERS
index 8824f61cd2c0..3d196a023b5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17127,6 +17127,7 @@ S: Maintained
F: Documentation/driver-api/vfio-mediated-device.rst
F: drivers/vfio/mdev/
F: include/linux/mdev.h
+F: include/linux/vfio_mdev.h
F: samples/vfio-mdev/
VFIO PLATFORM DRIVER
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 6420f0dbd31b..306f934c7857 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
}
+static const struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops;
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -678,7 +681,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
- mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
+ mdev_set_vfio_ops(mdev, &intel_vfio_vgpu_dev_ops);
out:
return ret;
}
@@ -1599,20 +1602,21 @@ static const struct attribute_group
*intel_vgpu_groups[] = {
NULL,
};
-static struct mdev_parent_ops intel_vgpu_ops = {
- .mdev_attr_groups = intel_vgpu_groups,
- .create = intel_vgpu_create,
- .remove = intel_vgpu_remove,
-
+static const struct vfio_mdev_device_ops intel_vf
[PATCH V4 4/6] mdev: introduce virtio device and its device ops
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 files changed, 167 insertions(+)
create mode 100644 include/linux/virtio_mdev.h
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index d0f3113c8071..5834f6b7c7a5 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -57,6 +57,18 @@ void mdev_set_vfio_ops(struct mdev_device *mdev,
}
EXPORT_SYMBOL(mdev_set_vfio_ops);
+/* Specify the virtio device ops for the mdev device, this
+ * must be called during create() callback for virtio mdev device.
+ */
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct virtio_mdev_device_ops *virtio_ops)
+{
+ BUG_ON(mdev->class_id);
+ mdev->class_id = MDEV_CLASS_ID_VIRTIO;
+ mdev->device_ops = virtio_ops;
+}
+EXPORT_SYMBOL(mdev_set_virtio_ops);
+
const void *mdev_get_dev_ops(struct mdev_device *mdev)
{
return mdev->device_ops;
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 3d29e09e20c9..13e045e09d3b 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -17,6 +17,7 @@
struct mdev_device;
struct vfio_mdev_device_ops;
+struct virtio_mdev_device_ops;
/*
* Called by the parent device driver to set the device which represents
@@ -111,6 +112,8 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data);
const guid_t *mdev_uuid(struct mdev_device *mdev);
void mdev_set_vfio_ops(struct mdev_device *mdev,
const struct vfio_mdev_device_ops *vfio_ops);
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+ const struct virtio_mdev_device_ops *virtio_ops);
const void *mdev_get_dev_ops(struct mdev_device *mdev);
extern struct bus_type mdev_bus_type;
@@ -127,6 +130,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_CLASS_ID_VFIO = 1,
+ MDEV_CLASS_ID_VIRTIO = 2,
/* New entries must be added here */
};
diff --git a/include/linux/virtio_mdev.h b/include/linux/virtio_mdev.h
new file mode 100644
index ..b965b50f9b24
--- /dev/null
+++ b/include/linux/virtio_mdev.h
@@ -0,0 +1,151 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ * Author: Jason Wang
+ */
+#ifndef _LINUX_VIRTIO_MDEV_H
+#define _LINUX_VIRTIO_MDEV_H
+
+#include
+#include
+#include
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+#define VIRTIO_MDEV_F_VERSION_1 0x1
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *data);
+ void *private;
+};
+
+/**
+ * struct vfio_mdev_device_ops - Structure to be registered for each
+ * mdev device to register the device to virtio-mdev module.
+ *
+ * @set_vq_address:Set the address of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @desc_area: address of desc area
+ * @driver_area: address of driver area
+ * @device_area: address of device area
+ * Returns integer: success (0) or error (< 0)
+ * @set_vq_num:Set the size of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @num: the size of virtqueue
+ * @kick_vq: Kick the virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @set_vq_cb: Set the interrupt callback function for
+ * a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @cb: virtio-mdev interrupt callback structure
+ * @set_vq_ready: Set ready status for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @ready: ready (true) not ready(false)
+ * @get_vq_ready: Get ready status for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * Returns boolean: ready (true) or not (false)
+ * @set_vq_state: Set the state for a virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @state: virtqueue state (last_avail_idx)
+ * Returns integer: success (0) or error (< 0)
+ * @get_vq_state: Get the state for a vir
[PATCH V4 5/6] virtio: introduce a mdev based transport
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 device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
device specific ops which is a part of mdev_parent_ops now.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 7 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 409 +++
3 files changed, 417 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..8d18722ab572 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,13 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV_DEVICE
+ tristate "VIRTIO driver for Mediated devices"
+ depends on VFIO_MDEV && VIRTIO
+ default n
+ help
+ VIRTIO based driver for Mediated devices.
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..ebc7fa15ae82 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV_DEVICE) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..24c0df5ffe77
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ unsigned long version;
+
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ /* List of virtio_mdev_vq_info */
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_generation(mdev);
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+
+ return ops->set_status(mdev, 0);
+}
+
+static bool virtio_mdev_notify(struct virtqueue *vq)
+{
+ struct mdev_device *mdev = vm_get_mdev(vq->vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_o
[PATCH V4 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
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 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 7 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet.c | 691 +
4 files changed, 700 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d196a023b5e..cb51351cd5c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17254,6 +17254,7 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: samples/vfio-mdev/mvnet.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..a1a1ca2c00b7 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET
+tristate "Build virtio mdev net example mediated device sample code --
loadable modules only"
+ depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..f34af90ed0a0 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
new file mode 100644
index ..19e823a449cd
--- /dev/null
+++ b/samples/vfio-mdev/mvnet.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet
+ * # cd /sys/devices/virtual/mvnet/mvnet/mdev_supported_types/mvnet-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet"
+#define MVNET_NAME "mvnet"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex mdev_list_lock;
+static struct list_head mdev_devices_list;
+
+static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned int idx)
+{
+ struct mvnet_virtqueue *vq = &mvnet->vqs[idx];
+ int ret;
+
+ ret = vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
+ false, (struct vring_desc *)vq->desc_addr,
+ (struct vring_avail *)vq->driver_addr,
+
Re: [PATCH v4 06/11] drm/ttm: factor out ttm_bo_mmap_vma_setup
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: Gerd Hoffmann
>
> Reviewed-by: Christian König for this one
> and #7 in the series.
Any objections that I add these two to my drm-ttm-next pull request or
did you wanted to merge that through some other tree?
Thanks,
Christian.
>
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 46 +
>> 1 file changed, 24 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 4aa007edffb0..53345c0854d5 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -426,6 +426,28 @@ static struct ttm_buffer_object
>> *ttm_bo_vm_lookup(struct ttm_bo_device *bdev,
>> return bo;
>> }
>> +static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo,
>> struct vm_area_struct *vma)
>> +{
>> + vma->vm_ops = &ttm_bo_vm_ops;
>> +
>> + /*
>> + * Note: We're transferring the bo reference to
>> + * vma->vm_private_data here.
>> + */
>> +
>> + vma->vm_private_data = bo;
>> +
>> + /*
>> + * We'd like to use VM_PFNMAP on shared mappings, where
>> + * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
>> + * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
>> + * bad for performance. Until that has been sorted out, use
>> + * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
>> + */
>> + vma->vm_flags |= VM_MIXEDMAP;
>> + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>> +}
>> +
>> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
>> struct ttm_bo_device *bdev)
>> {
>> @@ -449,24 +471,7 @@ int ttm_bo_mmap(struct file *filp, struct
>> vm_area_struct *vma,
>> if (unlikely(ret != 0))
>> goto out_unref;
>> - vma->vm_ops = &ttm_bo_vm_ops;
>> -
>> - /*
>> - * Note: We're transferring the bo reference to
>> - * vma->vm_private_data here.
>> - */
>> -
>> - vma->vm_private_data = bo;
>> -
>> - /*
>> - * We'd like to use VM_PFNMAP on shared mappings, where
>> - * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
>> - * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
>> - * bad for performance. Until that has been sorted out, use
>> - * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
>> - */
>> - vma->vm_flags |= VM_MIXEDMAP;
>> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>> + ttm_bo_mmap_vma_setup(bo, vma);
>> return 0;
>> out_unref:
>> ttm_bo_put(bo);
>> @@ -481,10 +486,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma,
>> struct ttm_buffer_object *bo)
>> ttm_bo_get(bo);
>> - vma->vm_ops = &ttm_bo_vm_ops;
>> - vma->vm_private_data = bo;
>> - vma->vm_flags |= VM_MIXEDMAP;
>> - vma->vm_flags |= VM_IO | VM_DONTEXPAND;
>> + ttm_bo_mmap_vma_setup(bo, vma);
>> return 0;
>> }
>> EXPORT_SYMBOL(ttm_fbdev_mmap);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 4/6] backlight: qcom-wled: Add support for WLED4 peripheral.
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
that will be handed to the backlight sub-system.
It's purpose needs to be explained in the patch description (or the code
moved to a new patch).
Daniel.
>
> Signed-off-by: Kiran Gunda
> Reviewed-by: Bjorn Andersson
> ---
> drivers/video/backlight/qcom-wled.c | 263
> +++-
> 1 file changed, 257 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index 45eeda4..2807b4b 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -17,7 +17,7 @@
>
> #define WLED3_SINK_REG_BRIGHT_MAX0xFFF
>
> -/* WLED3 control registers */
> +/* WLED3/WLED4 control registers */
> #define WLED3_CTRL_REG_MOD_EN0x46
> #define WLED3_CTRL_REG_MOD_EN_MASK BIT(7)
> #define WLED3_CTRL_REG_MOD_EN_SHIFT 7
> @@ -31,7 +31,7 @@
> #define WLED3_CTRL_REG_ILIMIT0x4e
> #define WLED3_CTRL_REG_ILIMIT_MASK GENMASK(2, 0)
>
> -/* WLED3 sink registers */
> +/* WLED3/WLED4 sink registers */
> #define WLED3_SINK_REG_SYNC 0x47
> #define WLED3_SINK_REG_SYNC_CLEAR 0x00
>
> @@ -56,6 +56,28 @@
> #define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
> #define WLED3_SINK_REG_STR_CABC_MASKBIT(7)
>
> +/* WLED4 specific sink registers */
> +#define WLED4_SINK_REG_CURR_SINK 0x46
> +#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
> +#define WLED4_SINK_REG_CURR_SINK_SHFT 4
> +
> +/* WLED4 specific per-'string' registers below */
> +#define WLED4_SINK_REG_STR_MOD_EN(n) (0x50 + (n * 0x10))
> +#define WLED4_SINK_REG_STR_MOD_MASK BIT(7)
> +
> +#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n)(0x52 + (n *
> 0x10))
> +#define WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(3, 0)
> +
> +#define WLED4_SINK_REG_STR_MOD_SRC(n)(0x53 + (n *
> 0x10))
> +#define WLED4_SINK_REG_STR_MOD_SRC_MASK BIT(0)
> +#define WLED4_SINK_REG_STR_MOD_SRC_INT 0x00
> +#define WLED4_SINK_REG_STR_MOD_SRC_EXT 0x01
> +
> +#define WLED4_SINK_REG_STR_CABC(n) (0x56 + (n * 0x10))
> +#define WLED4_SINK_REG_STR_CABC_MASKBIT(7)
> +
> +#define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
> +
> struct wled_var_cfg {
> const u32 *values;
> u32 (*fn)(u32);
> @@ -90,6 +112,7 @@ struct wled {
> struct device *dev;
> struct regmap *regmap;
> u16 ctrl_addr;
> + u16 sink_addr;
> u16 max_string_count;
> u32 brightness;
> u32 max_brightness;
> @@ -116,6 +139,29 @@ static int wled3_set_brightness(struct wled *wled, u16
> brightness)
> return 0;
> }
>
> +static int wled4_set_brightness(struct wled *wled, u16 brightness)
> +{
> + int rc, i;
> + u16 low_limit = wled->max_brightness * 4 / 1000;
> + u8 v[2];
> +
> + /* WLED4's lower limit of operation is 0.4% */
> + if (brightness > 0 && brightness < low_limit)
> + brightness = low_limit;
> +
> + v[0] = brightness & 0xff;
> + v[1] = (brightness >> 8) & 0xf;
> +
> + for (i = 0; i < wled->cfg.num_strings; ++i) {
> + rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
> +WLED4_SINK_REG_BRIGHT(i), v, 2);
> + if (rc < 0)
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> static int wled_module_enable(struct wled *wled, int val)
> {
> int rc;
> @@ -267,6 +313,120 @@ static int wled3_setup(struct wled *wled)
> .enabled_strings = {0, 1, 2, 3},
> };
>
> +static int wled4_setup(struct wled *wled)
> +{
> + int rc, temp, i, j;
> + u16 addr;
> + u8 sink_en = 0;
> + u32 sink_cfg = 0;
> +
> + rc = regmap_update_bits(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_OVP,
> + WLED3_CTRL_REG_OVP_MASK, wled->cfg.ovp);
> + if (rc < 0)
> + return rc;
> +
> + rc = regmap_update_bits(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_ILIMIT,
> + WLED3_CTRL_REG_ILIMIT_MASK,
> + wled->cfg.boost_i_limit);
> + if (rc < 0)
> + return rc;
> +
> + rc = regmap_update_bits(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_FRE
Re: [PATCH V7 5/6] backlight: qcom-wled: add support for short circuit handling.
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 Gunda
> Reviewed-by: Bjorn Andersson
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/qcom-wled.c | 132
> ++--
> 1 file changed, 128 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index 2807b4b..b5b125c 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -2,6 +2,9 @@
> /* Copyright (c) 2015, Sony Mobile Communications, AB.
> */
>
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -56,6 +59,16 @@
> #define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
> #define WLED3_SINK_REG_STR_CABC_MASKBIT(7)
>
> +/* WLED4 specific control registers */
> +#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
> +#define WLED4_CTRL_REG_SHORT_EN_MASKBIT(7)
> +
> +#define WLED4_CTRL_REG_SEC_ACCESS0xd0
> +#define WLED4_CTRL_REG_SEC_UNLOCK 0xa5
> +
> +#define WLED4_CTRL_REG_TEST1 0xe2
> +#define WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
> +
> /* WLED4 specific sink registers */
> #define WLED4_SINK_REG_CURR_SINK 0x46
> #define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
> @@ -105,17 +118,23 @@ struct wled_config {
> bool cs_out_en;
> bool ext_gen;
> bool cabc;
> + bool external_pfet;
> };
>
> struct wled {
> const char *name;
> struct device *dev;
> struct regmap *regmap;
> + struct mutex lock; /* Lock to avoid race from thread irq handler */
> + ktime_t last_short_event;
> u16 ctrl_addr;
> u16 sink_addr;
> u16 max_string_count;
> u32 brightness;
> u32 max_brightness;
> + u32 short_count;
> + bool disabled_by_short;
> + bool has_short_detect;
>
> struct wled_config cfg;
> int (*wled_set_brightness)(struct wled *wled, u16 brightness);
> @@ -166,6 +185,9 @@ static int wled_module_enable(struct wled *wled, int val)
> {
> int rc;
>
> + if (wled->disabled_by_short)
> + return -ENXIO;
> +
> rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
> WLED3_CTRL_REG_MOD_EN,
> WLED3_CTRL_REG_MOD_EN_MASK,
> @@ -202,18 +224,19 @@ static int wled_update_status(struct backlight_device
> *bl)
> bl->props.state & BL_CORE_FBBLANK)
> brightness = 0;
>
> + mutex_lock(&wled->lock);
> if (brightness) {
> rc = wled->wled_set_brightness(wled, brightness);
> if (rc < 0) {
> dev_err(wled->dev, "wled failed to set brightness
> rc:%d\n",
> rc);
> - return rc;
> + goto unlock_mutex;
> }
>
> rc = wled_sync_toggle(wled);
> if (rc < 0) {
> dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
> - return rc;
> + goto unlock_mutex;
> }
> }
>
> @@ -221,15 +244,61 @@ static int wled_update_status(struct backlight_device
> *bl)
> rc = wled_module_enable(wled, !!brightness);
> if (rc < 0) {
> dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
> - return rc;
> + goto unlock_mutex;
> }
> }
>
> wled->brightness = brightness;
>
> +unlock_mutex:
> + mutex_unlock(&wled->lock);
> +
> return rc;
> }
>
> +#define WLED_SHORT_DLY_MS20
> +#define WLED_SHORT_CNT_MAX 5
> +#define WLED_SHORT_RESET_CNT_DLY_US USEC_PER_SEC
> +
> +static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + s64 elapsed_time;
> +
> + wled->short_count++;
> + mutex_lock(&wled->lock);
> + rc = wled_module_enable(wled, false);
> + if (rc < 0) {
> + dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
> + goto unlock_mutex;
> + }
> +
> + elapsed_time = ktime_us_delta(ktime_get(),
> + wled->last_short_event);
> + if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
> + wled->short_count = 1;
> +
> + if (wled->short_count > WLED_SHORT_CNT_MAX) {
> + dev_err(wled->dev, "Short trigged %d times, disabling WLED
> forever!\n",
> + wled->short_count);
> +
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 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 disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> > >
> > > Signed-off-by: Uwe Kleine-König
> > > ---
> > > Hello,
> > >
> > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > far as I understand the problem this is a combination of the backend pwm
> > > driver yielding surprising results and the pwm-bl driver doing things
> > > more complicated than necessary.
> > >
> > > So I guess this patch works around these problems. Still it would be
> > > interesting to find out the details in the imx driver that triggers the
> > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > pwm_imx27_get_state() and provide the results?
> > >
> > > Note I only compile tested this change.
> >
> > Hi Uwe,
> > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > thread that I have a similar problem when you submitted this patch.
> >
> > So here are my few cents:
> >
> > My setup is as follows:
> > - imx6dl-yapp4-draco with i.MX6Solo
> > - backlight is controlled with inverted PWM signal
> > - max brightness level = 32, default brightness level set to 32 in DT.
> >
> > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> >pwm_get_state() return the last implemented state):
> >
> > - System boots to userspace and backlight is enabled all the time from
> >power up.
> >
> >$ dmesg | grep state
> >[1.763381] get state end: -1811360608, enabled: 0
>
> What is -1811360608? When I wrote "print *state" above, I thought about
> something like:
>
> pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> __func__, state->period, state->duty_cycle, state->polarity,
> state->enabled);
>
> A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> driver that yields duty_cycle = 0 when the hardware is off.
It seems to me like the best recourse to fix this for now would be to
patch up the drivers that return 0 when the hardware is off by caching
the currently configured duty cycle.
How about the patch below?
Thierry
--- >8 ---
From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 17 Oct 2019 12:56:00 +0200
Subject: [PATCH] pwm: imx27: Cache duty cycle register value
The hardware register containing the duty cycle value cannot be accessed
when the PWM is disabled. This causes the ->get_state() callback to read
back a duty cycle value of 0, which can confuse consumer drivers.
Signed-off-by: Thierry Reding
---
drivers/pwm/pwm-imx27.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index ae11d8577f18..4113d5cd4c62 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -85,6 +85,13 @@ struct pwm_imx27_chip {
struct clk *clk_per;
void __iomem*mmio_base;
struct pwm_chip chip;
+
+ /*
+* The driver cannot read the current duty cycle from the hardware if
+* the hardware is disabled. Cache the last programmed duty cycle
+* value to return in that case.
+*/
+ unsigned int duty_cycle;
};
#define to_pwm_imx27_chip(chip)container_of(chip, struct
pwm_imx27_chip, chip)
@@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
tmp = NSEC_PER_SEC * (u64)(period + 2);
state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- /* PWMSAR can be read only if PWM is enabled */
- if (state->enabled) {
+ /*
+* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
+* use the cached value.
+*/
+ if (state->enabled)
val = readl(imx->mmio_base + MX3_PWMSAR);
- tmp = NSEC_PER_SEC * (u64)(val);
- state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- } else {
- state->duty_cycle = 0;
- }
+ else
+ val = imx->duty_cycle;
+
+ tmp = NSEC_PER_SEC * (u64)(val);
+ state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
if (!state->enabled)
pwm_imx27_clk_disable_unprepare(chip);
@@ -261,6 +271,13 @@ static int pwm_imx27_apply(struc
[PATCH] drm/arm: make undeclared items static
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:6: warning: symbol
'malidp_error_stats_dump' was not declared. Should it be static?
drivers/gpu/drm/arm/malidp_drv.c:668:1: warning: symbol 'dev_attr_core_id' was
not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: David Airlie
Cc: Daniel Vetter
Cc: mal...@foss.arm.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
.. (open list)
---
drivers/gpu/drm/arm/malidp_drv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 333b88a5efb0..18ca43c9cef4 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -368,7 +368,7 @@ malidp_verify_afbc_framebuffer(struct drm_device *dev,
struct drm_file *file,
return false;
}
-struct drm_framebuffer *
+static struct drm_framebuffer *
malidp_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
@@ -491,9 +491,9 @@ void malidp_error(struct malidp_drm *malidp,
spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
}
-void malidp_error_stats_dump(const char *prefix,
-struct malidp_error_stats error_stats,
-struct seq_file *m)
+static void malidp_error_stats_dump(const char *prefix,
+ struct malidp_error_stats error_stats,
+ struct seq_file *m)
{
seq_printf(m, "[%s] num_errors : %d\n", prefix,
error_stats.num_errors);
@@ -665,7 +665,7 @@ static ssize_t core_id_show(struct device *dev, struct
device_attribute *attr,
return snprintf(buf, PAGE_SIZE, "%08x\n", malidp->core_id);
}
-DEVICE_ATTR_RO(core_id);
+static DEVICE_ATTR_RO(core_id);
static int malidp_init_sysfs(struct device *dev)
{
--
2.23.0
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 configuration.
> Auto calibration will be triggered when the OVP fault interrupts
> are seen frequently thereby it tries to fix the sink configuration.
>
> The auto-detection also kicks in when the connected LED string
> of the display-backlight malfunctions (because of damage) and
> requires the damaged string to be turned off to prevent the
> complete panel and/or board from being damaged.
>
> Signed-off-by: Kiran Gunda
It's a complex bit of code but I'm OK with it in principle. Everything
below is about small details and/or nitpicking.
> +static void wled_ovp_work(struct work_struct *work)
> +{
> + struct wled *wled = container_of(work,
> + struct wled, ovp_work.work);
> + enable_irq(wled->ovp_irq);
> +}
> +
A bit of commenting about why we have to wait 10ms before enabling the
OVP interrupt would be appreciated.
> +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + u32 int_sts, fault_sts;
> +
> + rc = regmap_read(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, &int_sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
> + rc);
> + return IRQ_HANDLED;
> + }
> +
> + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_FAULT_STATUS, &fault_sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
> + rc);
> + return IRQ_HANDLED;
> + }
> +
> + if (fault_sts &
> + (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
> + dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x
> fault_sts= %x\n",
> + int_sts, fault_sts);
> +
> + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) {
> + mutex_lock(&wled->lock);
> + disable_irq_nosync(wled->ovp_irq);
We're currently running the threaded ISR for this irq. Do we really need
to disable it?
> +
> + if (wled_auto_detection_required(wled))
> + wled_auto_string_detection(wled);
> +
> + enable_irq(wled->ovp_irq);
> +
> + mutex_unlock(&wled->lock);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
Snip.
> +static int wled_remove(struct platform_device *pdev)
> +{
> + struct wled *wled = dev_get_drvdata(&pdev->dev);
> +
> + cancel_delayed_work_sync(&wled->ovp_work);
> + mutex_destroy(&wled->lock);
Have the irq handlers been disabled at this point?
Also, if you want to destroy the mutex shouldn't that code be
introduced in the same patch that introduces the mutex?
> +
> + return 0;
> +}
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/cirrus: Remove obsolete header file
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/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
deleted file mode 100644
index 1f73916e528e..
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ /dev/null
@@ -1,247 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright 2012 Red Hat
- *
- * Authors: Matthew Garrett
- * Dave Airlie
- */
-#ifndef __CIRRUS_DRV_H__
-#define __CIRRUS_DRV_H__
-
-#include
-
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#define DRIVER_AUTHOR "Matthew Garrett"
-
-#define DRIVER_NAME"cirrus"
-#define DRIVER_DESC"qemu Cirrus emulation"
-#define DRIVER_DATE"20110418"
-
-#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 0
-#define DRIVER_PATCHLEVEL 0
-
-#define CIRRUSFB_CONN_LIMIT 1
-
-#define RREG8(reg) ioread8(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cdev->rmmio) + (reg))
-#define RREG32(reg) ioread32(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cdev->rmmio) + (reg))
-
-#define SEQ_INDEX 4
-#define SEQ_DATA 5
-
-#define WREG_SEQ(reg, v) \
- do {\
- WREG8(SEQ_INDEX, reg); \
- WREG8(SEQ_DATA, v); \
- } while (0) \
-
-#define CRT_INDEX 0x14
-#define CRT_DATA 0x15
-
-#define WREG_CRT(reg, v) \
- do {\
- WREG8(CRT_INDEX, reg); \
- WREG8(CRT_DATA, v); \
- } while (0) \
-
-#define GFX_INDEX 0xe
-#define GFX_DATA 0xf
-
-#define WREG_GFX(reg, v) \
- do {\
- WREG8(GFX_INDEX, reg); \
- WREG8(GFX_DATA, v); \
- } while (0) \
-
-/*
- * Cirrus has a "hidden" DAC register that can be accessed by writing to
- * the pixel mask register to reset the state, then reading from the register
- * four times. The next write will then pass to the DAC
- */
-#define VGA_DAC_MASK 0x6
-
-#define WREG_HDR(v)\
- do {\
- RREG8(VGA_DAC_MASK);\
- RREG8(VGA_DAC_MASK);\
- RREG8(VGA_DAC_MASK);\
- RREG8(VGA_DAC_MASK);\
- WREG8(VGA_DAC_MASK, v); \
- } while (0) \
-
-
-#define CIRRUS_MAX_FB_HEIGHT 4096
-#define CIRRUS_MAX_FB_WIDTH 4096
-
-#define CIRRUS_DPMS_CLEARED (-1)
-
-#define to_cirrus_crtc(x) container_of(x, struct cirrus_crtc, base)
-#define to_cirrus_encoder(x) container_of(x, struct cirrus_encoder, base)
-
-struct cirrus_crtc {
- struct drm_crtc base;
- int last_dpms;
- boolenabled;
-};
-
-struct cirrus_fbdev;
-struct cirrus_mode_info {
- struct cirrus_crtc *crtc;
- /* pointer to fbdev info structure */
- struct cirrus_fbdev *gfbdev;
-};
-
-struct cirrus_encoder {
- struct drm_encoder base;
- int last_dpms;
-};
-
-struct cirrus_connector {
- struct drm_connectorbase;
-};
-
-struct cirrus_mc {
- resource_size_t vram_size;
- resource_size_t vram_base;
-};
-
-struct cirrus_device {
- struct drm_device *dev;
- unsigned long flags;
-
- resource_size_t rmmio_base;
- resource_size_t rmmio_size;
- void __iomem*rmmio;
-
- struct cirrus_mcmc;
- struct cirrus_mode_info mode_info;
-
- int num_crtc;
- int fb_mtrr;
-
- struct {
- struct ttm_bo_device bdev;
- } ttm;
- bool mm_inited;
-};
-
-
-struct cirrus_fbdev {
- struct drm_fb_helper helper; /* must be first */
- struct drm_framebuff
Re: [PATCH 29/34] backlight/jornada720: Use CONFIG_PREEMPTION
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 Kconfig dependency to CONFIG_PREEMPTION. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Bartlomiej Zolnierkiewicz > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Thomas Gleixner > [bigeasy: +LCD_HP700] > Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Daniel Thompson (I know... the review for this particular patch is trivial but an Acked-by from a maintainer means something specific and it is Lee Jones who coordinates landing cross sub-system patch sets for backlight). Daniel. > --- > drivers/video/backlight/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig > index 40676be2e46aa..d09396393724b 100644 > --- a/drivers/video/backlight/Kconfig > +++ b/drivers/video/backlight/Kconfig > @@ -99,7 +99,7 @@ config LCD_TOSA > > config LCD_HP700 > tristate "HP Jornada 700 series LCD Driver" > - depends on SA1100_JORNADA720_SSP && !PREEMPT > + depends on SA1100_JORNADA720_SSP && !PREEMPTION > default y > help > If you have an HP Jornada 700 series handheld (710/720/728) > @@ -228,7 +228,7 @@ config BACKLIGHT_HP680 > > config BACKLIGHT_HP700 > tristate "HP Jornada 700 series Backlight Driver" > - depends on SA1100_JORNADA720_SSP && !PREEMPT > + depends on SA1100_JORNADA720_SSP && !PREEMPTION > default y > help > If you have an HP Jornada 700 series, > -- > 2.23.0 >
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
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 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 > > > > > stop-gap. > > > > > > > > > > > > > This is a good idea, and I vote +ULONG_MAX :) > > > > > > > > and I also checked tda998x driver, it supports bridge. so swap the > > > > wholesale to brige is perfect. :) > > > > > > > > > > Well, as Mihail wrote, it's definitely not perfect. > > > > > > Today, if you rmmod tda998x with the DPU driver still loaded, > > > everything will be unbound gracefully. > > > > > > If we swap to bridge, then rmmod'ing tda998x (or any other bridge > > > driver the DPU is using) with the DPU driver still loaded will result > > > in a crash. > > > > I haven't read the bridge code, but seems this is a bug of drm_bridge, > > since if the bridge is still in using by others, the rmmod should fail > > > > Correct, but there's no fix for that today. You can also take a look > at the thread linked from Mihail's cover letter. > > > And personally opinion, if the bridge doesn't handle the dependence. > > for us: > > > > - add such support to bridge > > That would certainly be helpful. I don't know if there's consensus on > how to do that. > > > or > > - just do the insmod/rmmod in correct order. > > > > > So, there really are proper benefits to sticking with the component > > > code for tda998x, which is why I'd like to understand why you're so > > > against this patch? > > > > > > > This change handles two different connectors in komeda internally, compare > > with one interface, it increases the complexity, more risk of bug and more > > cost of maintainance. > > > > Well, it's only about how to bind the drivers - two different methods > of binding, not two different connectors. I would argue that carrying > our out-of-tree patches to support both platforms is a larger > maintenance burden. > > Honestly this looks like a win-win to me. We get the superior approach > when its supported, and still get to support bridges which are more > common. > > As/when improvements are made to the bridge code we can remove the > component bits and not lose anything. There was an idea a while back about using the device links code to solve the bridge issue - but at the time the device links code wasn't up to the job. I think that's been resolved now, but I haven't been able to confirm it. I did propose some patches for bridge at the time but they probably need updating. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 drivers. By not relying on the period and duty
> cycle being retrievable from a disabled PWM this type of problem is
> worked around.
>
> Apart from this issue only calling the pwm_get_state/pwm_apply_state
> combo once is also more effective.
I'm only interested in the second paragraph here.
There seems to be a reasonable consensus that the i.MX27 and cros-ec
PWM drivers should be fixed for the benefit of other PWM clients.
So we make this change because it makes the pwm-bl better... not to
work around bugs ;-).
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 746eebc411df..ddebd62b3978 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
>
> static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> -
> - pwm_get_state(pb->pwm, &state);
> - if (!pb->enabled)
> - return;
> -
Why remove the pb->enabled check? I thought that was there to ensure we
don't mess up the regular reference counts.
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
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 receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 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 disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > > >
> > > > Signed-off-by: Uwe Kleine-König
> > > > ---
> > > > Hello,
> > > >
> > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > far as I understand the problem this is a combination of the backend pwm
> > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > more complicated than necessary.
> > > >
> > > > So I guess this patch works around these problems. Still it would be
> > > > interesting to find out the details in the imx driver that triggers the
> > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > pwm_imx27_get_state() and provide the results?
> > > >
> > > > Note I only compile tested this change.
> > >
> > > Hi Uwe,
> > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > thread that I have a similar problem when you submitted this patch.
> > >
> > > So here are my few cents:
> > >
> > > My setup is as follows:
> > > - imx6dl-yapp4-draco with i.MX6Solo
> > > - backlight is controlled with inverted PWM signal
> > > - max brightness level = 32, default brightness level set to 32 in DT.
> > >
> > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > >pwm_get_state() return the last implemented state):
> > >
> > > - System boots to userspace and backlight is enabled all the time from
> > >power up.
> > >
> > >$ dmesg | grep state
> > >[1.763381] get state end: -1811360608, enabled: 0
> >
> > What is -1811360608? When I wrote "print *state" above, I thought about
> > something like:
> >
> > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > __func__, state->period, state->duty_cycle, state->polarity,
> > state->enabled);
> >
> > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > driver that yields duty_cycle = 0 when the hardware is off.
>
> It seems to me like the best recourse to fix this for now would be to
> patch up the drivers that return 0 when the hardware is off by caching
> the currently configured duty cycle.
>
> How about the patch below?
>
> Thierry
>
> --- >8 ---
> From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Thu, 17 Oct 2019 12:56:00 +0200
> Subject: [PATCH] pwm: imx27: Cache duty cycle register value
>
> The hardware register containing the duty cycle value cannot be accessed
> when the PWM is disabled. This causes the ->get_state() callback to read
> back a duty cycle value of 0, which can confuse consumer drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/pwm/pwm-imx27.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index ae11d8577f18..4113d5cd4c62 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> struct clk *clk_per;
> void __iomem*mmio_base;
> struct pwm_chip chip;
> +
> + /*
> + * The driver cannot read the current duty cycle from the hardware if
> + * the hardware is disabled. Cache the last programmed duty cycle
> + * value to return in that case.
> + */
> + unsigned int duty_cycle;
> };
>
> #define to_pwm_imx27_chip(chip) container_of(chip, struct
> pwm_imx27_chip, chip)
> @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> tmp = NSEC_PER_SEC * (u64)(period + 2);
> state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
>
> - /* PWMSAR can be read only if PWM is enabled */
> - if (state->enabled) {
> + /*
> + * PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> + * use the cached value.
> + */
> + if (state->enabled)
> val = readl(imx->mmio_base + MX3_PWMSAR);
> - tmp = NSEC_PER_SEC * (u64)(val);
> - state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> - } else {
> - state->duty_cycle = 0;
> - }
> + else
> + val = imx->duty_cycle;
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296
Janpieter Sollie changed:
What|Removed |Added
Attachment #144689|0 |1
is obsolete||
--- Comment #21 from Janpieter Sollie ---
Created attachment 145764
--> https://bugs.freedesktop.org/attachment.cgi?id=145764&action=edit
dmesg of PPLIB error
still present on linux 5.3, with the following exceptions:
- the values in mV seem to be initialized,
- DRM does not complain about 'Cannot find any crtc or sizes' after GPU adding
- DRM: construct error is gone
So it's going the good way, I guess ...
I investigated the source around dcn_bw_update_from_pplib
And I saw the following code in gpu/drm/amd/display/dc/calcs/dcn_calcs.c
bool res;
/* TODO: This is not the proper way to obtain
fabric_and_dram_bandwidth, should be min(fclk, memclk) */
res = dm_pp_get_clock_levels_by_type_with_voltage(
ctx, DM_PP_CLOCK_TYPE_FCLK, &fclks);
kernel_fpu_begin();
if (res)
res = verify_clock_values(&fclks);
if (res) {
//unimportant, left out
} else
BREAK_TO_DEBUGGER();
=
which probably explains what happens: fclks gets a number of clock values from
dm_pp_get_clock_levels_by_type_with_voltage, setting res to true.
It tries to validate the clock values then, which fails because of the invalid
numbers
After that, it breaks to debugger.
Is it possible the vega11 needs more time to initialize its clock limits?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 detects and enables the valid sink configuration.
Auto calibration will be triggered when the OVP fault interrupts
are seen frequently thereby it tries to fix the sink configuration.
The auto-detection also kicks in when the connected LED string
of the display-backlight malfunctions (because of damage) and
requires the damaged string to be turned off to prevent the
complete panel and/or board from being damaged.
Signed-off-by: Kiran Gunda
It's a complex bit of code but I'm OK with it in principle. Everything
below is about small details and/or nitpicking.
+static void wled_ovp_work(struct work_struct *work)
+{
+ struct wled *wled = container_of(work,
+struct wled, ovp_work.work);
+ enable_irq(wled->ovp_irq);
+}
+
A bit of commenting about why we have to wait 10ms before enabling the
OVP interrupt would be appreciated.
Sure. Will add the comment in the next series.
+static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
+{
+ struct wled *wled = _wled;
+ int rc;
+ u32 int_sts, fault_sts;
+
+ rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, &int_sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
+ rc);
+ return IRQ_HANDLED;
+ }
+
+ rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_FAULT_STATUS, &fault_sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
+ rc);
+ return IRQ_HANDLED;
+ }
+
+ if (fault_sts &
+ (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
+ dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts=
%x\n",
+ int_sts, fault_sts);
+
+ if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) {
+ mutex_lock(&wled->lock);
+ disable_irq_nosync(wled->ovp_irq);
We're currently running the threaded ISR for this irq. Do we really
need
to disable it?
We need to disable this IRQ, during the auto string detection logic.
Because
in the auto string detection we configure the current sinks one by one
and check the
status register for the OVPs and set the right string configuration. We
enable it later after
the auto string detection is completed.
+
+ if (wled_auto_detection_required(wled))
+ wled_auto_string_detection(wled);
+
+ enable_irq(wled->ovp_irq);
+
+ mutex_unlock(&wled->lock);
+ }
+
+ return IRQ_HANDLED;
+}
+
Snip.
+static int wled_remove(struct platform_device *pdev)
+{
+ struct wled *wled = dev_get_drvdata(&pdev->dev);
+
+ cancel_delayed_work_sync(&wled->ovp_work);
+ mutex_destroy(&wled->lock);
Have the irq handlers been disabled at this point?
Ok.. may not be. I will disable the irq's here in next series.
Also, if you want to destroy the mutex shouldn't that code be
introduced in the same patch that introduces the mutex?
Ok.. I will move it to the same patch where the mutex introduced in next
series.
+
+ return 0;
+}
Daniel.
[PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
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 the GPU itself
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
---
drivers/pci/pci.c| 7 ++
drivers/pci/quirks.c | 53
include/linux/pci.h | 1 +
3 files changed, 61 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b97d9e10c9cc..02e71e0bcdd7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -850,6 +850,13 @@ static int pci_raw_set_power_state(struct pci_dev *dev,
pci_power_t state)
|| (state == PCI_D2 && !dev->d2_support))
return -EIO;
+ /*
+* check if we have a bad combination of bridge controller and nvidia
+ * GPU, see quirk_broken_nv_runpm for more info
+*/
+ if (state != PCI_D0 && dev->broken_nv_runpm)
+ return 0;
+
pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
/*
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 44c4ae1abd00..0006c9e37b6f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5268,3 +5268,56 @@ static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct
pci_dev *pdev)
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1,
PCI_CLASS_DISPLAY_VGA, 8,
quirk_reset_lenovo_thinkpad_p50_nvgpu);
+
+/*
+ * Some Intel PCIe bridges cause devices to disappear from the PCIe bus after
+ * those were put into D3cold state if they were put into a non D0 PCI PM
+ * device state before doing so.
+ *
+ * This leads to various issue different issues which all manifest differently,
+ * but have the same root cause:
+ * - AIML code execution hits an infinite loop (as the coe waits on device
+ *memory to change).
+ * - kernel crashes, as all pci reads return -1, which most code isn't able
+ *to handle well enough.
+ * - sudden shutdowns, as the kernel identified an unrecoverable error after
+ *userspace tries to access the GPU.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * ACPI code writes bit 0x80 to the not documented PCI register 0x248 of the
+ * PCIe bridge controller in order to power down the GPU.
+ * Nonetheless, there are other code paths inside the ACPI firmware which use
+ * other registers, which seem to work fine:
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Pascal GPU. It cannot be ruled out that this issue
+ * only occurs in combination with listed Intel PCIe bridge controllers and
+ * the mentioned GPUs or if it's only a hw bug in the bridge controller.
+ *
+ * But because this issue was NOT seen on laptops with an Nvidia Pascal GPU
+ * and an Intel Coffee Lake SoC, there is a higher chance of there being a bug
+ * in the bridge controller rather than in the GPU.
+ *
+ * This issue was not able to be reproduced on non laptop systems.
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *dev)
+{
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+ if (bridge->vendor == PCI_VENDOR_ID_INTEL &&
+ bridge->device == 0x1901)
+ dev->broken_nv_runpm = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
+ PCI_BASE_CLASS_DISPLAY, 16,
+ quirk_broken_nv_runpm);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index ac8a6c4e1792..903a0b3a39ec 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -416,6 +416,7 @@ struct pci_dev {
unsigned int__aer_firmware_first_valid:1;
unsigned int__aer_firmware_first:1;
unsigned intbroken_intx_masking:1; /* INTx masking can't be used */
+ unsigned intbroken_nv_runpm:1; /* some combinations of intel
bridge controller and nvidia GPUs break rtd3 */
unsigned intio_window_1k:1; /* Intel bridge 1K I/O windows
*/
unsigned intirq_managed:1;
unsigned inthas_secondary_link:1;
--
2.21.0
_
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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_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 disabled PWM this type of problem is
> > worked around.
> >
> > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > combo once is also more effective.
>
> I'm only interested in the second paragraph here.
>
> There seems to be a reasonable consensus that the i.MX27 and cros-ec
> PWM drivers should be fixed for the benefit of other PWM clients.
> So we make this change because it makes the pwm-bl better... not to
> work around bugs ;-).
That's fine, still I think it's fair to explain the motivation of
creating this patch.
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c
> > index 746eebc411df..ddebd62b3978 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
> > *pb)
> >
> > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > {
> > - struct pwm_state state;
> > -
> > - pwm_get_state(pb->pwm, &state);
> > - if (!pb->enabled)
> > - return;
> > -
>
> Why remove the pb->enabled check? I thought that was there to ensure we
> don't mess up the regular reference counts.
I havn't looked yet, but I guess I have to respin. Expect a v2 later
today.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 calibration will be triggered when the OVP fault interrupts
> are seen frequently thereby it tries to fix the sink configuration.
>
> The auto-detection also kicks in when the connected LED string
> of the display-backlight malfunctions (because of damage) and
> requires the damaged string to be turned off to prevent the
> complete panel and/or board from being damaged.
>
> Signed-off-by: Kiran Gunda
> ---
> drivers/video/backlight/qcom-wled.c | 410
> +++-
> 1 file changed, 404 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index b5b125c..ff7c409 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
[...]
> + /* iterate through the strings one by one */
Please use proper English in comments (less a full stop).
In this case, just s/iterate/Iterate/.
> + for (i = 0; i < wled->cfg.num_strings; i++) {
> + sink_test = BIT((WLED4_SINK_REG_CURR_SINK_SHFT + i));
> +
> + /* Enable feedback control */
> + rc = regmap_write(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_FEEDBACK_CONTROL, i + 1);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to enable feedback for SINK
> %d rc = %d\n",
> + i + 1, rc);
> + goto failed_detect;
> + }
> +
> + /* enable the sink */
Here too. And everywhere else.
> + rc = regmap_write(wled->regmap, wled->sink_addr +
> + WLED4_SINK_REG_CURR_SINK, sink_test);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to configure SINK %d
> rc=%d\n",
> + i + 1, rc);
> + goto failed_detect;
> + }
> +
> + /* Enable the module */
> + rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_MOD_EN,
> + WLED3_CTRL_REG_MOD_EN_MASK,
> + WLED3_CTRL_REG_MOD_EN_MASK);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to enable WLED module
> rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> +
> + usleep_range(WLED_SOFT_START_DLY_US,
> + WLED_SOFT_START_DLY_US + 1000);
> +
> + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> + WLED3_CTRL_REG_INT_RT_STS, &int_sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading
> WLED3_CTRL_INT_RT_STS rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> +
> + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> + dev_dbg(wled->dev, "WLED OVP fault detected with SINK
> %d\n",
> + i + 1);
I haven't reviewed the whole patch, but this caught my eye.
I think this should be upgraded to dev_warn().
> + else
> + sink_valid |= sink_test;
> +
> + /* Disable the module */
> + rc = regmap_update_bits(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
> + WLED3_CTRL_REG_MOD_EN_MASK, 0);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to disable WLED module
> rc=%d\n",
> + rc);
> + goto failed_detect;
> + }
> + }
> +
> + if (!sink_valid) {
> + dev_err(wled->dev, "No valid WLED sinks found\n");
> + wled->disabled_by_short = true;
> + goto failed_detect;
> + }
> +
> + if (sink_valid == sink_config) {
> + dev_dbg(wled->dev, "WLED auto-detection complete,
> sink-config=%x OK!\n",
> + sink_config);
Does this really need to be placed in the kernel log?
> + } else {
> + dev_warn(wled->dev, "New WLED string configuration found %x\n",
> + sink_valid);
Why would the user care about this? Is it not normal?
> + sink_config = sink_valid;
> + }
[...]
> +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + u32 int_sts, fault_sts;
> +
> + rc = regmap_read(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL
Re: [PATCH V7 4/6] backlight: qcom-wled: Add support for WLED4 peripheral.
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 patch that looks like it changes the name
that will be handed to the backlight sub-system.
It's purpose needs to be explained in the patch description (or the
code
moved to a new patch).
I will address it in next series.
Daniel.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
---
drivers/video/backlight/qcom-wled.c | 263
+++-
1 file changed, 257 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 45eeda4..2807b4b 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -17,7 +17,7 @@
#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
-/* WLED3 control registers */
+/* WLED3/WLED4 control registers */
#define WLED3_CTRL_REG_MOD_EN 0x46
#define WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
#define WLED3_CTRL_REG_MOD_EN_SHIFT 7
@@ -31,7 +31,7 @@
#define WLED3_CTRL_REG_ILIMIT 0x4e
#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)
-/* WLED3 sink registers */
+/* WLED3/WLED4 sink registers */
#define WLED3_SINK_REG_SYNC0x47
#define WLED3_SINK_REG_SYNC_CLEAR 0x00
@@ -56,6 +56,28 @@
#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+/* WLED4 specific sink registers */
+#define WLED4_SINK_REG_CURR_SINK 0x46
+#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
+#define WLED4_SINK_REG_CURR_SINK_SHFT 4
+
+/* WLED4 specific per-'string' registers below */
+#define WLED4_SINK_REG_STR_MOD_EN(n) (0x50 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_MASK BIT(7)
+
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n) (0x52 + (n * 0x10))
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(3, 0)
+
+#define WLED4_SINK_REG_STR_MOD_SRC(n) (0x53 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_SRC_MASK BIT(0)
+#define WLED4_SINK_REG_STR_MOD_SRC_INT0x00
+#define WLED4_SINK_REG_STR_MOD_SRC_EXT0x01
+
+#define WLED4_SINK_REG_STR_CABC(n) (0x56 + (n * 0x10))
+#define WLED4_SINK_REG_STR_CABC_MASK BIT(7)
+
+#define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
+
struct wled_var_cfg {
const u32 *values;
u32 (*fn)(u32);
@@ -90,6 +112,7 @@ struct wled {
struct device *dev;
struct regmap *regmap;
u16 ctrl_addr;
+ u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
@@ -116,6 +139,29 @@ static int wled3_set_brightness(struct wled
*wled, u16 brightness)
return 0;
}
+static int wled4_set_brightness(struct wled *wled, u16 brightness)
+{
+ int rc, i;
+ u16 low_limit = wled->max_brightness * 4 / 1000;
+ u8 v[2];
+
+ /* WLED4's lower limit of operation is 0.4% */
+ if (brightness > 0 && brightness < low_limit)
+ brightness = low_limit;
+
+ v[0] = brightness & 0xff;
+ v[1] = (brightness >> 8) & 0xf;
+
+ for (i = 0; i < wled->cfg.num_strings; ++i) {
+ rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_BRIGHT(i), v, 2);
+ if (rc < 0)
+ return rc;
+ }
+
+ return 0;
+}
+
static int wled_module_enable(struct wled *wled, int val)
{
int rc;
@@ -267,6 +313,120 @@ static int wled3_setup(struct wled *wled)
.enabled_strings = {0, 1, 2, 3},
};
+static int wled4_setup(struct wled *wled)
+{
+ int rc, temp, i, j;
+ u16 addr;
+ u8 sink_en = 0;
+ u32 sink_cfg = 0;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_OVP,
+ WLED3_CTRL_REG_OVP_MASK, wled->cfg.ovp);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_ILIMIT,
+ WLED3_CTRL_REG_ILIMIT_MASK,
+ wled->cfg.boost_i_limit);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_FREQ,
+ WLED3_CTRL_REG_FREQ_MASK,
+ wled->cfg.swit
Re: [PATCH V7 5/6] backlight: qcom-wled: add support for short circuit handling.
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
persists.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Daniel Thompson
Thanks for that !
---
drivers/video/backlight/qcom-wled.c | 132
++--
1 file changed, 128 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 2807b4b..b5b125c 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -2,6 +2,9 @@
/* Copyright (c) 2015, Sony Mobile Communications, AB.
*/
+#include
+#include
+#include
#include
#include
#include
@@ -56,6 +59,16 @@
#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+/* WLED4 specific control registers */
+#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
+#define WLED4_CTRL_REG_SHORT_EN_MASK BIT(7)
+
+#define WLED4_CTRL_REG_SEC_ACCESS 0xd0
+#define WLED4_CTRL_REG_SEC_UNLOCK 0xa5
+
+#define WLED4_CTRL_REG_TEST1 0xe2
+#define WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
+
/* WLED4 specific sink registers */
#define WLED4_SINK_REG_CURR_SINK 0x46
#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
@@ -105,17 +118,23 @@ struct wled_config {
bool cs_out_en;
bool ext_gen;
bool cabc;
+ bool external_pfet;
};
struct wled {
const char *name;
struct device *dev;
struct regmap *regmap;
+ struct mutex lock; /* Lock to avoid race from thread irq handler */
+ ktime_t last_short_event;
u16 ctrl_addr;
u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
+ u32 short_count;
+ bool disabled_by_short;
+ bool has_short_detect;
struct wled_config cfg;
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
@@ -166,6 +185,9 @@ static int wled_module_enable(struct wled *wled,
int val)
{
int rc;
+ if (wled->disabled_by_short)
+ return -ENXIO;
+
rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
WLED3_CTRL_REG_MOD_EN,
WLED3_CTRL_REG_MOD_EN_MASK,
@@ -202,18 +224,19 @@ static int wled_update_status(struct
backlight_device *bl)
bl->props.state & BL_CORE_FBBLANK)
brightness = 0;
+ mutex_lock(&wled->lock);
if (brightness) {
rc = wled->wled_set_brightness(wled, brightness);
if (rc < 0) {
dev_err(wled->dev, "wled failed to set brightness
rc:%d\n",
rc);
- return rc;
+ goto unlock_mutex;
}
rc = wled_sync_toggle(wled);
if (rc < 0) {
dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
@@ -221,15 +244,61 @@ static int wled_update_status(struct
backlight_device *bl)
rc = wled_module_enable(wled, !!brightness);
if (rc < 0) {
dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
- return rc;
+ goto unlock_mutex;
}
}
wled->brightness = brightness;
+unlock_mutex:
+ mutex_unlock(&wled->lock);
+
return rc;
}
+#define WLED_SHORT_DLY_MS 20
+#define WLED_SHORT_CNT_MAX 5
+#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC
+
+static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
+{
+ struct wled *wled = _wled;
+ int rc;
+ s64 elapsed_time;
+
+ wled->short_count++;
+ mutex_lock(&wled->lock);
+ rc = wled_module_enable(wled, false);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
+ goto unlock_mutex;
+ }
+
+ elapsed_time = ktime_us_delta(ktime_get(),
+ wled->last_short_event);
+ if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
+ wled->short_count = 1;
+
+ if (wled->short_count > WLED_SHORT_CNT_MAX) {
+ dev_err(wled->dev, "Short trigged %d times, disabling WLED
forever!\n",
+ wled->short_count);
+ wled->disabled_by_short = true;
+ goto unlock_mutex;
+ }
+
+ wled->last_
Re: [PATCH v4 06/11] drm/ttm: factor out ttm_bo_mmap_vma_setup
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 separate patch). > >> v4: make ttm_bo_mmap_vma_setup static. > >> > >> Signed-off-by: Gerd Hoffmann > > > > Reviewed-by: Christian König for this one > > and #7 in the series. > > Any objections that I add these two to my drm-ttm-next pull request or > did you wanted to merge that through some other tree? Pushed series to drm-misc-next a few minutes ago (before I saw your mail). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/qxl: Fix randbuild error
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cirrus: Remove obsolete header file
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 https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 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 disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> >
> > I'm only interested in the second paragraph here.
> >
> > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > PWM drivers should be fixed for the benefit of other PWM clients.
> > So we make this change because it makes the pwm-bl better... not to
> > work around bugs ;-).
>
> That's fine, still I think it's fair to explain the motivation of
> creating this patch.
>
> > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > b/drivers/video/backlight/pwm_bl.c
> > > index 746eebc411df..ddebd62b3978 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data
> > > *pb)
> > >
> > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > {
> > > - struct pwm_state state;
> > > -
> > > - pwm_get_state(pb->pwm, &state);
> > > - if (!pb->enabled)
> > > - return;
> > > -
> >
> > Why remove the pb->enabled check? I thought that was there to ensure we
> > don't mess up the regular reference counts.
>
> I havn't looked yet, but I guess I have to respin. Expect a v2 later
> today.
I would agree that a high-level fix is better than a series of low
level driver fixes. For what its worth, your V1 patch worked fine on
my i.MX6Q. I can test the V2 patch when its ready.
adam
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205147] Unable to shut down - radeon_drv.c - radeon_suspend_kms()
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 the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 (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 disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > >
> > > I'm only interested in the second paragraph here.
> > >
> > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > So we make this change because it makes the pwm-bl better... not to
> > > work around bugs ;-).
> >
> > That's fine, still I think it's fair to explain the motivation of
> > creating this patch.
> >
> > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > b/drivers/video/backlight/pwm_bl.c
> > > > index 746eebc411df..ddebd62b3978 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > pwm_bl_data *pb)
> > > >
> > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > {
> > > > - struct pwm_state state;
> > > > -
> > > > - pwm_get_state(pb->pwm, &state);
> > > > - if (!pb->enabled)
> > > > - return;
> > > > -
> > >
> > > Why remove the pb->enabled check? I thought that was there to ensure we
> > > don't mess up the regular reference counts.
> >
> > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > today.
>
> I would agree that a high-level fix is better than a series of low
> level driver fixes. For what its worth, your V1 patch worked fine on
> my i.MX6Q. I can test the V2 patch when its ready.
I may have spoken too soon. The patch fixes the display in that it
comes on when it previously did not, but changes to brightness do not
appear to do anything anymore. I don't have an oscilloscope where I
am now, so I cannot verify whether or not the PWM duty cycle changes.
To my eye, the following do not appear to change the brightness of the screen:
echo 7 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
echo 2 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
echo 5 >
/sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
adam
>
> adam
> >
> > Best regards
> > Uwe
> >
> > --
> > Pengutronix e.K. | Uwe Kleine-König|
> > Industrial Linux Solutions | http://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/8] drm: rcar-du: Add support for CMM
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 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 advanced CMM features will be
> > implemented on top of this initial one.
> >
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Kieran Bingham
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> > 4 files changed, 278 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig
> > index 1529849e217e..539d232790d1 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > Choose this option if you have an R-Car chipset.
> > If M is selected the module will be called rcar-du-drm.
> >
> > +config DRM_RCAR_CMM
> > + bool "R-Car DU Color Management Module (CMM) Support"
> > + depends on DRM && OF
> > + depends on DRM_RCAR_DU
> > + help
> > + Enable support for R-Car Color Management Module (CMM).
> > +
> > config DRM_RCAR_DW_HDMI
> > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > depends on DRM && OF
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index 6c2ed9c46467..4d1187ccc3e5 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > \
> > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >
> > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > new file mode 100644
> > index ..4170626208cf
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > + *
> > + * Copyright (C) 2019 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "rcar_cmm.h"
> > +
> > +#define CM2_LUT_CTRL 0x
> > +#define CM2_LUT_CTRL_LUT_ENBIT(0)
> > +#define CM2_LUT_TBL_BASE 0x0600
> > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > +
> > +struct rcar_cmm {
> > + void __iomem *base;
> > +
> > + /*
> > +* @lut:1D-LUT state
> > +* @lut.enabled:1D-LUT enabled flag
> > +*/
> > + struct {
> > + bool enabled;
> > + } lut;
> > +};
> > +
> > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > +{
> > + return ioread32(rcmm->base + reg);
> > +}
> > +
> > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
> > +{
> > + iowrite32(data, rcmm->base + reg);
> > +}
> > +
> > +/*
> > + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> > precision
> > + * and write to the CMM registers
> > + * @rcmm: Pointer to the CMM device
> > + * @drm_lut: Pointer to the DRM LUT table
> > + */
> > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> > + const struct drm_color_lut *drm_lut)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> > + u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
> > + | drm_color_lut_extract(drm_lut[i].green, 8) << 8
> > + | drm_color_lut_extract(drm_lut[i].blue, 8);
> > +
> > + rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
> > + }
> > +}
> > +
> > +/*
> > + * rcar_cmm_setup() - Configure the CMM unit
> > + * @pdev: The platform device associated with the CMM instance
> > + * @config: The CMM unit configuration
> > + *
> > + * Configure the CMM unit with the given configuration. Currently enabling,
> > + * disabling and programming of the 1-D LUT unit is supported.
>
> Did you miss the comment in the previous version about explaining when
> rcar_cmm_setup() can be called (basically requ
Re: [PATCH v6 3/8] drm: rcar-du: Add support for CMM
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 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 advanced CMM features will be
> > > implemented on top of this initial one.
> > >
> > > Reviewed-by: Laurent Pinchart
> > > Reviewed-by: Kieran Bingham
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
> > > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> > > 4 files changed, 278 insertions(+)
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > > b/drivers/gpu/drm/rcar-du/Kconfig
> > > index 1529849e217e..539d232790d1 100644
> > > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > > Choose this option if you have an R-Car chipset.
> > > If M is selected the module will be called rcar-du-drm.
> > >
> > > +config DRM_RCAR_CMM
> > > + bool "R-Car DU Color Management Module (CMM) Support"
> > > + depends on DRM && OF
> > > + depends on DRM_RCAR_DU
> > > + help
> > > + Enable support for R-Car Color Management Module (CMM).
> > > +
> > > config DRM_RCAR_DW_HDMI
> > > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > > depends on DRM && OF
> > > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > > b/drivers/gpu/drm/rcar-du/Makefile
> > > index 6c2ed9c46467..4d1187ccc3e5 100644
> > > --- a/drivers/gpu/drm/rcar-du/Makefile
> > > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > > \
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> > >
> > > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > > obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> > > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > > obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > new file mode 100644
> > > index ..4170626208cf
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > > @@ -0,0 +1,212 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > > + *
> > > + * Copyright (C) 2019 Jacopo Mondi
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "rcar_cmm.h"
> > > +
> > > +#define CM2_LUT_CTRL 0x
> > > +#define CM2_LUT_CTRL_LUT_EN BIT(0)
> > > +#define CM2_LUT_TBL_BASE 0x0600
> > > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > > +
> > > +struct rcar_cmm {
> > > + void __iomem *base;
> > > +
> > > + /*
> > > + * @lut:1D-LUT state
> > > + * @lut.enabled:1D-LUT enabled flag
> > > + */
> > > + struct {
> > > + bool enabled;
> > > + } lut;
> > > +};
> > > +
> > > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > > +{
> > > + return ioread32(rcmm->base + reg);
> > > +}
> > > +
> > > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32
> > > data)
> > > +{
> > > + iowrite32(data, rcmm->base + reg);
> > > +}
> > > +
> > > +/*
> > > + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> > > precision
> > > + * and write to the CMM registers
> > > + * @rcmm: Pointer to the CMM device
> > > + * @drm_lut: Pointer to the DRM LUT table
> > > + */
> > > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> > > +const struct drm_color_lut *drm_lut)
> > > +{
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < CM2_LUT_SIZE; ++i) {
> > > + u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
> > > + | drm_color_lut_extract(drm_lut[i].green, 8) << 8
> > > + | drm_color_lut_extract(drm_lut[i].blue, 8);
> > > +
> > > + rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
> > > + }
> > > +}
> > > +
> > > +/*
> > > + * rcar_cmm_setup() - Configure the CMM unit
> > > + * @pdev: The platform device associated with the CMM instance
> > > + * @config: The CMM unit configuration
> > > + *
> > > + * Configure the CM
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 not relying on the period and duty
> cycle being retrievable from a disabled PWM this type of problem is
> worked around.
>
> Apart from this issue only calling the pwm_get_state/pwm_apply_state
> combo once is also more effective.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> There are now two reports about 01ccf903edd6 breaking a backlight. As
> far as I understand the problem this is a combination of the backend pwm
> driver yielding surprising results and the pwm-bl driver doing things
> more complicated than necessary.
>
> So I guess this patch works around these problems. Still it would be
> interesting to find out the details in the imx driver that triggers the
> problem. So Adam, can you please instrument the pwm-imx27 driver to
> print *state at the beginning of pwm_imx27_apply() and the end of
> pwm_imx27_get_state() and provide the results?
>
> Note I only compile tested this change.
>
> Best regards
> Uwe
>
> drivers/video/backlight/pwm_bl.c | 34 +++-
> 1 file changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 746eebc411df..ddebd62b3978 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -42,10 +42,8 @@ struct pwm_bl_data {
>
> static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> int err;
>
> - pwm_get_state(pb->pwm, &state);
> if (pb->enabled)
> return;
>
> @@ -53,9 +51,6 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> if (err < 0)
> dev_err(pb->dev, "failed to enable power supply\n");
>
> - state.enabled = true;
> - pwm_apply_state(pb->pwm, &state);
> -
> if (pb->post_pwm_on_delay)
> msleep(pb->post_pwm_on_delay);
>
> @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
>
> static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> {
> - struct pwm_state state;
> -
> - pwm_get_state(pb->pwm, &state);
> - if (!pb->enabled)
> - return;
> -
> if (pb->enable_gpio)
> gpiod_set_value_cansleep(pb->enable_gpio, 0);
>
> if (pb->pwm_off_delay)
> msleep(pb->pwm_off_delay);
>
> - state.enabled = false;
> - state.duty_cycle = 0;
> - pwm_apply_state(pb->pwm, &state);
> -
> regulator_disable(pb->power_supply);
> pb->enabled = false;
> }
>
> -static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> +static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness, struct
> pwm_state *state)
> {
> unsigned int lth = pb->lth_brightness;
> - struct pwm_state state;
> u64 duty_cycle;
>
> - pwm_get_state(pb->pwm, &state);
> -
> if (pb->levels)
> duty_cycle = pb->levels[brightness];
> else
> duty_cycle = brightness;
>
> - duty_cycle *= state.period - lth;
> + duty_cycle *= state->period - lth;
> do_div(duty_cycle, pb->scale);
>
> return duty_cycle + lth;
> @@ -122,12 +104,20 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
>
> if (brightness > 0) {
> pwm_get_state(pb->pwm, &state);
> - state.duty_cycle = compute_duty_cycle(pb, brightness);
> + state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
> + state.enabled = true;
> pwm_apply_state(pb->pwm, &state);
> +
> pwm_backlight_power_on(pb);
> - } else
> + } else {
> pwm_backlight_power_off(pb);
>
> + pwm_get_state(pb->pwm, &state);
> + state.enabled = false;
> + state.duty_cycle = 0;
> + pwm_apply_state(pb->pwm, &state);
Both cases where (brightness > 0) and 'else' contain the
pwm_apply_state() call with the same parameters. Can this be moved
outside of the if statements?
> + }
> +
> if (pb->notify_after)
> pb->notify_after(pb->dev, brightness);
>
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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, 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 not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > > >
> > > > > Signed-off-by: Uwe Kleine-König
> > > > > ---
> > > > > Hello,
> > > > >
> > > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > > far as I understand the problem this is a combination of the backend
> > > > > pwm
> > > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > > more complicated than necessary.
> > > > >
> > > > > So I guess this patch works around these problems. Still it would be
> > > > > interesting to find out the details in the imx driver that triggers
> > > > > the
> > > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > > pwm_imx27_get_state() and provide the results?
> > > > >
> > > > > Note I only compile tested this change.
> > > >
> > > > Hi Uwe,
> > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > > thread that I have a similar problem when you submitted this patch.
> > > >
> > > > So here are my few cents:
> > > >
> > > > My setup is as follows:
> > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > - backlight is controlled with inverted PWM signal
> > > > - max brightness level = 32, default brightness level set to 32 in DT.
> > > >
> > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > > >pwm_get_state() return the last implemented state):
> > > >
> > > > - System boots to userspace and backlight is enabled all the time from
> > > >power up.
> > > >
> > > >$ dmesg | grep state
> > > >[1.763381] get state end: -1811360608, enabled: 0
> > >
> > > What is -1811360608? When I wrote "print *state" above, I thought about
> > > something like:
> > >
> > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > __func__, state->period, state->duty_cycle, state->polarity,
> > > state->enabled);
> > >
> > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > driver that yields duty_cycle = 0 when the hardware is off.
> >
> > It seems to me like the best recourse to fix this for now would be to
> > patch up the drivers that return 0 when the hardware is off by caching
> > the currently configured duty cycle.
> >
> > How about the patch below?
> >
> > Thierry
> >
> > --- >8 ---
> > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding
> > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> >
> > The hardware register containing the duty cycle value cannot be accessed
> > when the PWM is disabled. This causes the ->get_state() callback to read
> > back a duty cycle value of 0, which can confuse consumer drivers.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/pwm/pwm-imx27.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > index ae11d8577f18..4113d5cd4c62 100644
> > --- a/drivers/pwm/pwm-imx27.c
> > +++ b/drivers/pwm/pwm-imx27.c
> > @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> > struct clk *clk_per;
> > void __iomem*mmio_base;
> > struct pwm_chip chip;
> > +
> > + /*
> > +* The driver cannot read the current duty cycle from the hardware if
> > +* the hardware is disabled. Cache the last programmed duty cycle
> > +* value to return in that case.
> > +*/
> > + unsigned int duty_cycle;
> > };
> >
> > #define to_pwm_imx27_chip(chip)container_of(chip, struct
> > pwm_imx27_chip, chip)
> > @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> > tmp = NSEC_PER_SEC * (u64)(period + 2);
> > state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> >
> > - /* PWMSAR can be read only if PWM is enabled */
> > - if (state->enabled) {
> > + /*
> > +* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> > +* use the cached value.
> > +*/
> > + if (state->enabled)
> > val = r
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 +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 drivers. By not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > >
> > > > I'm only interested in the second paragraph here.
> > > >
> > > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > > So we make this change because it makes the pwm-bl better... not to
> > > > work around bugs ;-).
> > >
> > > That's fine, still I think it's fair to explain the motivation of
> > > creating this patch.
> > >
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > index 746eebc411df..ddebd62b3978 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > > pwm_bl_data *pb)
> > > > >
> > > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > > {
> > > > > - struct pwm_state state;
> > > > > -
> > > > > - pwm_get_state(pb->pwm, &state);
> > > > > - if (!pb->enabled)
> > > > > - return;
> > > > > -
> > > >
> > > > Why remove the pb->enabled check? I thought that was there to ensure we
> > > > don't mess up the regular reference counts.
> > >
> > > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > > today.
> >
> > I would agree that a high-level fix is better than a series of low
> > level driver fixes. For what its worth, your V1 patch worked fine on
> > my i.MX6Q. I can test the V2 patch when its ready.
>
> I may have spoken too soon. The patch fixes the display in that it
> comes on when it previously did not, but changes to brightness do not
> appear to do anything anymore. I don't have an oscilloscope where I
> am now, so I cannot verify whether or not the PWM duty cycle changes.
>
> To my eye, the following do not appear to change the brightness of the screen:
> echo 7 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> echo 2 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> echo 5 >
> /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
Hi Adam,
can you try the i.MX PWM patch that I posted earlier instead? I really
think we need to fix this in the PWM drivers because they are broken.
pwm-backlight is not. -rc3 is really not a time to work around breakage
in consumers.
If my patch doesn't help, can you try reverting the offending patch? If
we can't come up with a good fix for the drivers, reverting is the next
best option.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111987] Unstable performance (periodic and repeating patterns of fps change) and changing VDDGFX
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 > power_dpm_force_performance_level The behavior will depend on the workload. If the workload is really bursty, it may cause the clocks to ramp up and down if there are sufficiently long idle periods between workloads. You can manually adjust the heuristics by selecting the custom profile and tweaking each parameter. See the documentation here: https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html#gpu-power-thermal-controls-and-monitoring -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 valid sink configuration.
Auto calibration will be triggered when the OVP fault interrupts
are seen frequently thereby it tries to fix the sink configuration.
The auto-detection also kicks in when the connected LED string
of the display-backlight malfunctions (because of damage) and
requires the damaged string to be turned off to prevent the
complete panel and/or board from being damaged.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 410
+++-
1 file changed, 404 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index b5b125c..ff7c409 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
[...]
+ /* iterate through the strings one by one */
Please use proper English in comments (less a full stop).
In this case, just s/iterate/Iterate/.
Sorry for that ! will fix it in next series.
+ for (i = 0; i < wled->cfg.num_strings; i++) {
+ sink_test = BIT((WLED4_SINK_REG_CURR_SINK_SHFT + i));
+
+ /* Enable feedback control */
+ rc = regmap_write(wled->regmap, wled->ctrl_addr +
+ WLED3_CTRL_REG_FEEDBACK_CONTROL, i + 1);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to enable feedback for SINK %d rc =
%d\n",
+ i + 1, rc);
+ goto failed_detect;
+ }
+
+ /* enable the sink */
Here too. And everywhere else.
Will fix it in next series.
+ rc = regmap_write(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_CURR_SINK, sink_test);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to configure SINK %d
rc=%d\n",
+ i + 1, rc);
+ goto failed_detect;
+ }
+
+ /* Enable the module */
+ rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
+ WLED3_CTRL_REG_MOD_EN,
+ WLED3_CTRL_REG_MOD_EN_MASK,
+ WLED3_CTRL_REG_MOD_EN_MASK);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to enable WLED module
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+
+ usleep_range(WLED_SOFT_START_DLY_US,
+WLED_SOFT_START_DLY_US + 1000);
+
+ rc = regmap_read(wled->regmap, wled->ctrl_addr +
+WLED3_CTRL_REG_INT_RT_STS, &int_sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Error in reading WLED3_CTRL_INT_RT_STS
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+
+ if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
+ dev_dbg(wled->dev, "WLED OVP fault detected with SINK
%d\n",
+ i + 1);
I haven't reviewed the whole patch, but this caught my eye.
I think this should be upgraded to dev_warn().
Thought of keeping these messages silent, Because the string
configuration will be corrected in this
and informing it at end of the auto string detection.
+ else
+ sink_valid |= sink_test;
+
+ /* Disable the module */
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
+ WLED3_CTRL_REG_MOD_EN_MASK, 0);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to disable WLED module
rc=%d\n",
+ rc);
+ goto failed_detect;
+ }
+ }
+
+ if (!sink_valid) {
+ dev_err(wled->dev, "No valid WLED sinks found\n");
+ wled->disabled_by_short = true;
+ goto failed_detect;
+ }
+
+ if (sink_valid == sink_config) {
+ dev_dbg(wled->dev, "WLED auto-detection complete, sink-config=%x
OK!\n",
+ sink_config);
Does this really need to be placed in the kernel log?
Ok. This can be removed. I will remove it in next series.
+ } else {
+ dev_warn(wled->dev, "New WLED string configuration found %x\n",
+sink_valid);
Why would the user care about this? Is it not normal?
Actually, it comes here if the user provided string configuration in the
device tree is in-
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 +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_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 disabled PWM this type of problem is
> > > > > > worked around.
> > > > > >
> > > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > > combo once is also more effective.
> > > > >
> > > > > I'm only interested in the second paragraph here.
> > > > >
> > > > > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > > > > PWM drivers should be fixed for the benefit of other PWM clients.
> > > > > So we make this change because it makes the pwm-bl better... not to
> > > > > work around bugs ;-).
> > > >
> > > > That's fine, still I think it's fair to explain the motivation of
> > > > creating this patch.
> > > >
> > > > > > diff --git a/drivers/video/backlight/pwm_bl.c
> > > > > > b/drivers/video/backlight/pwm_bl.c
> > > > > > index 746eebc411df..ddebd62b3978 100644
> > > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > > @@ -67,40 +62,27 @@ static void pwm_backlight_power_on(struct
> > > > > > pwm_bl_data *pb)
> > > > > >
> > > > > > static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > > > > > {
> > > > > > - struct pwm_state state;
> > > > > > -
> > > > > > - pwm_get_state(pb->pwm, &state);
> > > > > > - if (!pb->enabled)
> > > > > > - return;
> > > > > > -
> > > > >
> > > > > Why remove the pb->enabled check? I thought that was there to ensure
> > > > > we
> > > > > don't mess up the regular reference counts.
> > > >
> > > > I havn't looked yet, but I guess I have to respin. Expect a v2 later
> > > > today.
> > >
> > > I would agree that a high-level fix is better than a series of low
> > > level driver fixes. For what its worth, your V1 patch worked fine on
> > > my i.MX6Q. I can test the V2 patch when its ready.
> >
> > I may have spoken too soon. The patch fixes the display in that it
> > comes on when it previously did not, but changes to brightness do not
> > appear to do anything anymore. I don't have an oscilloscope where I
> > am now, so I cannot verify whether or not the PWM duty cycle changes.
> >
> > To my eye, the following do not appear to change the brightness of the
> > screen:
> > echo 7 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> > echo 2 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
> > echo 5 >
> > /sys/devices/soc0/backlight-lvds/backlight/backlight-lvds/brightness
>
> Hi Adam,
>
> can you try the i.MX PWM patch that I posted earlier instead? I really
> think we need to fix this in the PWM drivers because they are broken.
> pwm-backlight is not. -rc3 is really not a time to work around breakage
> in consumers.
I did try your patch, but it did not appear to make any difference on my i.MX6Q.
>
> If my patch doesn't help, can you try reverting the offending patch? If
> we can't come up with a good fix for the drivers, reverting is the next
> best option.
I am able to get an image after reverting the offending patch. I did
not try playing with brightness levels after reverting.
>
> Thierry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/mipi_dbi: Use simple right shift instead of double negation
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 > simple right shift and satisfy compiler. It also reduces amount of > operations needed. > > Signed-off-by: Andy Shevchenko > --- > drivers/gpu/drm/drm_mipi_dbi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c > index 1961f713aaab..445e88b1fc9a 100644 > --- a/drivers/gpu/drm/drm_mipi_dbi.c > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > @@ -1021,7 +1021,7 @@ static int mipi_dbi_typec3_command_read(struct mipi_dbi > *dbi, u8 *cmd, > unsigned int i; > > for (i = 0; i < len; i++) > - data[i] = (buf[i] << 1) | !!(buf[i + 1] & BIT(7)); > + data[i] = (buf[i] << 1) | (buf[i + 1] >> 7); You should probably have ((buf[i + 1] >> 7) & 0x1) to be super safe. Do you know anything about this code? It seems like nothing is protecting us from overrunning buf in this loop. We're just assuming that len < tr[1].len through this loop and I'm not sure what's protecting us from looking where we shouldn't. Sean > } > > MIPI_DBI_DEBUG_COMMAND(*cmd, data, len); > -- > 2.23.0 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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() 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 disabled PWM this type of problem is
> > > worked around.
> > >
> > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > combo once is also more effective.
> >
> > I'm only interested in the second paragraph here.
> >
> > There seems to be a reasonable consensus that the i.MX27 and cros-ec
> > PWM drivers should be fixed for the benefit of other PWM clients.
> > So we make this change because it makes the pwm-bl better... not to
> > work around bugs ;-).
>
> That's fine, still I think it's fair to explain the motivation of
> creating this patch.
Maybe.
Whether this patch is a workaround or simply an improvement to pwm-bl
does need to be clear since it affects whether Lee steers it towards
v5.4-rcX or linux-next .
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/34] backlight/jornada720: Use CONFIG_PREEMPTION
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 which today > > depends on CONFIG_PREEMPT. > > > > Switch the Kconfig dependency to CONFIG_PREEMPTION. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Bartlomiej Zolnierkiewicz > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fb...@vger.kernel.org > > Signed-off-by: Thomas Gleixner > > [bigeasy: +LCD_HP700] > > Signed-off-by: Sebastian Andrzej Siewior > > Reviewed-by: Daniel Thompson > > (I know... the review for this particular patch is trivial but an > Acked-by from a maintainer means something specific and it is Lee > Jones who coordinates landing cross sub-system patch sets for > backlight). Right. Thanks Dan. 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 bisectability issues in the next release kernel. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
dri-devel@lists.freedesktop.org
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
4 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index d4051409ce64..a5cb3864d686 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -355,7 +355,6 @@ int qxl_mode_dumb_mmap(struct drm_file *filp,
/* qxl ttm */
int qxl_ttm_init(struct qxl_device *qdev);
void qxl_ttm_fini(struct qxl_device *qdev);
-int qxl_mmap(struct file *filp, struct vm_area_struct *vma);
/* qxl image */
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 483b4c57554a..65464630ac98 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -157,7 +157,7 @@ static const struct file_operations qxl_fops = {
.unlocked_ioctl = drm_ioctl,
.poll = drm_poll,
.read = drm_read,
- .mmap = qxl_mmap,
+ .mmap = drm_gem_mmap,
};
static int qxl_drm_freeze(struct drm_device *dev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index c013c516f561..927ab917b834 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -86,6 +86,7 @@ static const struct drm_gem_object_funcs qxl_object_funcs = {
.get_sg_table = qxl_gem_prime_get_sg_table,
.vmap = qxl_gem_prime_vmap,
.vunmap = qxl_gem_prime_vunmap,
+ .mmap = drm_gem_ttm_mmap,
.print_info = drm_gem_ttm_print_info,
};
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index dba925589e17..629ac8e77a21 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,22 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
-{
- struct drm_file *file_priv = filp->private_data;
- struct qxl_device *qdev = file_priv->minor->dev->dev_private;
-
- if (qdev == NULL) {
- DRM_ERROR(
-"filp->private_data->minor->dev->dev_private == NULL\n");
- return -EINVAL;
- }
- DRM_DEBUG_DRIVER("filp->private_data = 0x%p, vma->vm_pgoff = %lx\n",
- filp->private_data, vma->vm_pgoff);
-
- return ttm_bo_mmap(filp, vma, &qdev->mman.bdev);
-}
-
static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
{
return 0;
--
2.18.1
[PATCH 1/5] drm/qxl: drop qxl_ttm_fault
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 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index cbc6c2ba8630..dba925589e17 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,24 +48,8 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static struct vm_operations_struct qxl_ttm_vm_ops;
-static const struct vm_operations_struct *ttm_vm_ops;
-
-static vm_fault_t qxl_ttm_fault(struct vm_fault *vmf)
-{
- struct ttm_buffer_object *bo;
- vm_fault_t ret;
-
- bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
- if (bo == NULL)
- return VM_FAULT_NOPAGE;
- ret = ttm_vm_ops->fault(vmf);
- return ret;
-}
-
int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
{
- int r;
struct drm_file *file_priv = filp->private_data;
struct qxl_device *qdev = file_priv->minor->dev->dev_private;
@@ -77,16 +61,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
DRM_DEBUG_DRIVER("filp->private_data = 0x%p, vma->vm_pgoff = %lx\n",
filp->private_data, vma->vm_pgoff);
- r = ttm_bo_mmap(filp, vma, &qdev->mman.bdev);
- if (unlikely(r != 0))
- return r;
- if (unlikely(ttm_vm_ops == NULL)) {
- ttm_vm_ops = vma->vm_ops;
- qxl_ttm_vm_ops = *ttm_vm_ops;
- qxl_ttm_vm_ops.fault = &qxl_ttm_fault;
- }
- vma->vm_ops = &qxl_ttm_vm_ops;
- return 0;
+ return ttm_bo_mmap(filp, vma, &qdev->mman.bdev);
}
static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/qxl: a collection of small tweaks.
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() drm/qxl: allocate small objects top-down drivers/gpu/drm/qxl/qxl_drv.h| 1 - drivers/gpu/drm/qxl/qxl_drv.c| 10 +-- drivers/gpu/drm/qxl/qxl_object.c | 8 - drivers/gpu/drm/qxl/qxl_ttm.c| 50 4 files changed, 8 insertions(+), 61 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/qxl: drop verify_access
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/gpu/drm/qxl/qxl_ttm.c
@@ -110,14 +110,6 @@ static void qxl_evict_flags(struct ttm_buffer_object *bo,
*placement = qbo->placement;
}
-static int qxl_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct qxl_bo *qbo = to_qxl_bo(bo);
-
- return drm_vma_node_verify_access(&qbo->tbo.base.vma_node,
- filp->private_data);
-}
-
static int qxl_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
{
@@ -269,7 +261,6 @@ static struct ttm_bo_driver qxl_bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = &qxl_evict_flags,
.move = &qxl_bo_move,
- .verify_access = &qxl_verify_access,
.io_mem_reserve = &qxl_ttm_io_mem_reserve,
.io_mem_free = &qxl_ttm_io_mem_free,
.move_notify = &qxl_bo_move_notify,
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/qxl: use DEFINE_DRM_GEM_FOPS()
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/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -150,15 +150,7 @@ qxl_pci_remove(struct pci_dev *pdev)
drm_dev_put(dev);
}
-static const struct file_operations qxl_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .poll = drm_poll,
- .read = drm_read,
- .mmap = drm_gem_mmap,
-};
+DEFINE_DRM_GEM_FOPS(qxl_fops);
static int qxl_drm_freeze(struct drm_device *dev)
{
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/qxl: allocate small objects top-down
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_object.c
index 927ab917b834..ad336c98a0cf 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -54,9 +54,14 @@ bool qxl_ttm_bo_is_qxl_bo(struct ttm_buffer_object *bo)
void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 domain, bool pinned)
{
u32 c = 0;
- u32 pflag = pinned ? TTM_PL_FLAG_NO_EVICT : 0;
+ u32 pflag = 0;
unsigned int i;
+ if (pinned)
+ pflag |= TTM_PL_FLAG_NO_EVICT;
+ if (qbo->tbo.base.size <= PAGE_SIZE)
+ pflag |= TTM_PL_FLAG_TOPDOWN;
+
qbo->placement.placement = qbo->placements;
qbo->placement.busy_placement = qbo->placements;
if (domain == QXL_GEM_DOMAIN_VRAM)
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/34] backlight/jornada720: Use CONFIG_PREEMPTION
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 bisectability issues in the > next release kernel. It is independent, you can apply it to your -next branch. All dependencies are merged. Sebastian
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 OVP fault is observed. Based on this information
> > > it detects and enables the valid sink configuration.
> > > Auto calibration will be triggered when the OVP fault interrupts
> > > are seen frequently thereby it tries to fix the sink configuration.
> > >
> > > The auto-detection also kicks in when the connected LED string
> > > of the display-backlight malfunctions (because of damage) and
> > > requires the damaged string to be turned off to prevent the
> > > complete panel and/or board from being damaged.
> > >
> > > Signed-off-by: Kiran Gunda
> > > ---
> > > drivers/video/backlight/qcom-wled.c | 410
> > > +++-
> > > 1 file changed, 404 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/qcom-wled.c
> > > b/drivers/video/backlight/qcom-wled.c
> > > index b5b125c..ff7c409 100644
> > > --- a/drivers/video/backlight/qcom-wled.c
> > > +++ b/drivers/video/backlight/qcom-wled.c
[...]
> > > + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> > > + dev_dbg(wled->dev, "WLED OVP fault detected with SINK
> > > %d\n",
> > > + i + 1);
> >
> > I haven't reviewed the whole patch, but this caught my eye.
> >
> > I think this should be upgraded to dev_warn().
> >
> Thought of keeping these messages silent, Because the string configuration
> will be corrected in this
> and informing it at end of the auto string detection.
[...]
> > > + } else {
> > > + dev_warn(wled->dev, "New WLED string configuration found %x\n",
> > > + sink_valid);
> >
> > Why would the user care about this? Is it not normal?
> >
> Actually, it comes here if the user provided string configuration in the
> device tree is in-correct.
> That's why just informing the user about the right string configuration,
> after the auto string detection.
Then I think we need to be more forthcoming. Tell the user the
configuration is incorrect and what you've done to rectify it.
"XXX is not a valid configuration - using YYY instead"
[...]
> > > +static int wled_configure_ovp_irq(struct wled *wled,
> > > + struct platform_device *pdev)
> > > +{
> > > + int rc;
> > > + u32 val;
> > > +
> > > + wled->ovp_irq = platform_get_irq_byname(pdev, "ovp");
> > > + if (wled->ovp_irq < 0) {
> > > + dev_dbg(&pdev->dev, "ovp irq is not used\n");
> >
> > I assume this is optional. What happens if no IRQ is provided?
> >
> Here OVP IRQ is used to detect the wrong string detection. If it is not
> provided the auto string detection logic won't work.
"OVP IRQ not found - disabling automatic string detection"
> > If, for instance, polling mode is enabled, maybe something like this
> > would be better?
> >
> > dev_warn(&pdev->dev, "No IRQ found, falling back to polling
> > mode\n");
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] gpu: host1x: make 'host1x_cdma_wait_pushbuffer_space' static
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: symbol > 'host1x_cdma_wait_pushbuffer_space' was not declared. Should it be static? > > Signed-off-by: Ben Dooks > --- > Cc: Thierry Reding > Cc: dri-devel@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/host1x/cdma.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 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 disabled PWM this type of problem is
> > > > worked around.
> > > >
> > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > combo once is also more effective.
> > > >
> > > > Signed-off-by: Uwe Kleine-König
> > > > ---
> > > > Hello,
> > > >
> > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > far as I understand the problem this is a combination of the backend pwm
> > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > more complicated than necessary.
> > > >
> > > > So I guess this patch works around these problems. Still it would be
> > > > interesting to find out the details in the imx driver that triggers the
> > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > pwm_imx27_get_state() and provide the results?
> > > >
> > > > Note I only compile tested this change.
> > >
> > > Hi Uwe,
> > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > thread that I have a similar problem when you submitted this patch.
> > >
> > > So here are my few cents:
> > >
> > > My setup is as follows:
> > > - imx6dl-yapp4-draco with i.MX6Solo
> > > - backlight is controlled with inverted PWM signal
> > > - max brightness level = 32, default brightness level set to 32 in DT.
> > >
> > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > >pwm_get_state() return the last implemented state):
> > >
> > > - System boots to userspace and backlight is enabled all the time from
> > >power up.
> > >
> > >$ dmesg | grep state
> > >[1.763381] get state end: -1811360608, enabled: 0
> >
> > What is -1811360608? When I wrote "print *state" above, I thought about
> > something like:
> >
> > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > __func__, state->period, state->duty_cycle, state->polarity,
> > state->enabled);
> >
> > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > driver that yields duty_cycle = 0 when the hardware is off.
>
> It seems to me like the best recourse to fix this for now would be to
> patch up the drivers that return 0 when the hardware is off by caching
> the currently configured duty cycle.
>
> How about the patch below?
>
> Thierry
>
> --- >8 ---
> From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Thu, 17 Oct 2019 12:56:00 +0200
> Subject: [PATCH] pwm: imx27: Cache duty cycle register value
>
> The hardware register containing the duty cycle value cannot be accessed
> when the PWM is disabled. This causes the ->get_state() callback to read
> back a duty cycle value of 0, which can confuse consumer drivers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/pwm/pwm-imx27.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index ae11d8577f18..4113d5cd4c62 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> struct clk *clk_per;
> void __iomem*mmio_base;
> struct pwm_chip chip;
> +
> + /*
> +* The driver cannot read the current duty cycle from the hardware if
> +* the hardware is disabled. Cache the last programmed duty cycle
> +* value to return in that case.
> +*/
> + unsigned int duty_cycle;
> };
>
> #define to_pwm_imx27_chip(chip)container_of(chip, struct
> pwm_imx27_chip, chip)
> @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> tmp = NSEC_PER_SEC * (u64)(period + 2);
> state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
>
> - /* PWMSAR can be read only if PWM is enabled */
> - if (state->enabled) {
> + /*
> +* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
> +* use the cached value.
> +*/
> + if (state->enabled)
> val = readl(imx->mmio_base + MX3_PWMSAR);
> - tmp = NSEC_PER_SEC * (u64)(val);
> - state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
> - } else {
> - state->duty_cycle = 0;
> - }
> + else
> +
Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic
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 enabling every sink and
> > > checks if the OVP fault is observed. Based on this information
> > > it detects and enables the valid sink configuration.
> > > Auto calibration will be triggered when the OVP fault interrupts
> > > are seen frequently thereby it tries to fix the sink configuration.
> > >
> > > The auto-detection also kicks in when the connected LED string
> > > of the display-backlight malfunctions (because of damage) and
> > > requires the damaged string to be turned off to prevent the
> > > complete panel and/or board from being damaged.
> > >
> > > Signed-off-by: Kiran Gunda
> >
> > It's a complex bit of code but I'm OK with it in principle. Everything
> > below is about small details and/or nitpicking.
> >
> >
> > > +static void wled_ovp_work(struct work_struct *work)
> > > +{
> > > + struct wled *wled = container_of(work,
> > > + struct wled, ovp_work.work);
> > > + enable_irq(wled->ovp_irq);
> > > +}
> > > +
> >
> > A bit of commenting about why we have to wait 10ms before enabling the
> > OVP interrupt would be appreciated.
> >
> >
> Sure. Will add the comment in the next series.
> > > +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> > > +{
> > > + struct wled *wled = _wled;
> > > + int rc;
> > > + u32 int_sts, fault_sts;
> > > +
> > > + rc = regmap_read(wled->regmap,
> > > + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, &int_sts);
> > > + if (rc < 0) {
> > > + dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
> > > + rc);
> > > + return IRQ_HANDLED;
> > > + }
> > > +
> > > + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> > > + WLED3_CTRL_REG_FAULT_STATUS, &fault_sts);
> > > + if (rc < 0) {
> > > + dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
> > > + rc);
> > > + return IRQ_HANDLED;
> > > + }
> > > +
> > > + if (fault_sts &
> > > + (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
> > > + dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x
> > > fault_sts= %x\n",
> > > + int_sts, fault_sts);
> > > +
> > > + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) {
> > > + mutex_lock(&wled->lock);
> > > + disable_irq_nosync(wled->ovp_irq);
> >
> > We're currently running the threaded ISR for this irq. Do we really need
> > to disable it?
> >
> We need to disable this IRQ, during the auto string detection logic. Because
> in the auto string detection we configure the current sinks one by one and
> check the
> status register for the OVPs and set the right string configuration. We
> enable it later after
> the auto string detection is completed.
This is a threaded oneshot interrupt handler. Why isn't the framework
masking sufficient for you here?
Daniel.
[PATCH 6.1 3/8] drm: rcar-du: Add support for CMM
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 advanced CMM features will be
implemented on top of this initial one.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Expand rcar_cmm_setup() function documentation to detail its relationship
with rcar_cmm_enable() and their call order precedence.
---
drivers/gpu/drm/rcar-du/Kconfig| 7 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
4 files changed, 283 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..539d232790d1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -13,6 +13,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ bool "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..952316eb202b
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT state
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1-D LUT unit is supported.
+ *
+ * As rcar_cmm_setup() accesses the CMM registers the unit should be powered
+ * and its functional clock enabled. To guarantee this, before any call to
+ * this function is made, the CMM unit has to be enabled by calling
+ * rcar_cmm_enable() first.
+ *
+ * TODO: Add support for LUT double buffer operations to avoid updating the
+ * LUT table entries while a frame is being displayed.
+ */
+int rcar_cmm_setup(struct platform_device *pdev,
+ const struct rcar_cmm_config *config)
+{
+ struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
+
+
[PATCH v6.1 5/8] drm: rcar-du: crtc: Control CMM operations
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_cmm_check as if the gamma_table property is
available, a CMM unit for this CRTC was registered
- Add TODO note to investigate how the activation order of CMM and CRTC
impact on the first displayed fram
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..3f0f16946f42 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+
+ /*
+* TODO: The chip manual indicates that CMM tables should be written
+* after the DU channel has been activated. Investigate the impact
+* of this restriction on the first displayed frame.
+*/
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -135,6 +135,7 @@ static void rcar_du_group_setup_didsr(struct rcar_du_group
*rgrp)
static void rcar_du_group_setup(struct rcar_du_group *rgrp)
{
struct rcar_du_device *rcdu =
[PULL] drm-intel-fixes
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 commit 4f5cafb5cb8471e54afdc9054d973535614f7675: Linux 5.4-rc3 (2019-10-13 16:37:36 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-10-17 for you to fetch changes up to 0a544a2a728e2e33bb7fc38dd542ecb90ee393eb: drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request (2019-10-16 10:57:33 -0700) - 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 Chris Wilson (3): drm/i915/execlists: Refactor -EIO markup of hung requests drm/i915/userptr: Never allow userptr into the mappable GGTT drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request Ville Syrjälä (1): drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin drivers/gpu/drm/i915/display/intel_bios.c| 22 ++--- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++ drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 +++ drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 63 drivers/gpu/drm/i915/i915_gem.c | 3 ++ 7 files changed, 78 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] new uapi policy for drm
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 considered. > > > > We are getting requests via both amdgpu/amdkfd and i915 for new user > > APIs for userspace drivers that throw code over the wall instead of > > being open source developed projects, but we are also seeing it for > > android drivers and kms properties, and we had that i915 crappy crtc > > background thing that was for Chrome but Chrome didn't want it. > > > > Now this presents a couple of issues: > > > > a) these projects don't seem to that good at following our development > > guidelines, avoid developing userspace features in parallel in the > > open and having good development implementations before submitting > > upstream. > > > > b) these projects don't have experienced userspace developers > > reviewing their kernel uapis. One big advantage of adding uapis with > > mesa developers is they have a lot of experience in the area as well. > > > > It's leading me to think I want to just stop all uapi submissions via > > driver trees, and instead mandate that all driver uapi changes are > > sent in separate git pull requests to dri-devel, I'd try (with some > > help) to catch all uapi modifications in normal trees, and refuse > > pulls that modified uapi. > > > > At least I'm considered writing the script and refusing and pulls that > > have a uapi change that doesn't contain a link to the userspace > > changes required for it in a public developed repo. > > > > Thoughts? > > This seems like more hassle for questionable benefits. I don't know > that mesa is really any better than any other driver teams with > respect to UAPI. This just seems like sort of a arbitrary political > decision. The people working on mesa have as much of an agenda as > those working on other projects. Moreover, especially with the > migration to gitlab and MRs, I feel that mesa development has gotten > more opaque. Say what you will about mailing lists, but at least you > could have a drive by view of what's going on. With MRs, you sort of > have to seek out what to review; if stuff is not tagged with something > you feel is relevant, you probably won't look at it, so the only > people likely to review it are the people involved in writing it in > the first place, which would be the same whether it's mesa or some > other project. I think all of the projects generally have the best > intentions at heart, but for better or worse they just have different > development models. In the case of the AMD throw it over the wall > stuff, it's not really an anti-open source or community engagement > issue, it's more of how to we support several OSes, tons of new > products, several custom projects, etc. while leveraging as much > shared code as possible. There are ways to make it work, but they are > usually a pretty heavy lift that not all teams can make. I think there's a difference between All Tools Sucks (tm) and the discussions not even being accessible at all. I do agree that generally everyone screws up uapi once in a while, and we seem to overall do a not too shoddy job. So code is probably all ok enough. But imo long term code is fungible and really doesn't matter much, the important stuff is the people and teams who create it, and all the shared knowledge. That's also were I see the benefit in upstream (for customers and vendors and everyone), we can learn from each another. As an example, I've spent lots of time recently reading amdgpu code and how it's used in userspace. Understanding that without having access to the discussion or being able to ping people on irc and mailing lists would have been impossible - lots of questions where I just plain guessed wrong. For the code-over-wall projects that stuff all simply doesn't exist. It's nigh impossible to figure out whether uapi makes sense or not if you can't see all the tradeoffs and discussions that influenced it and why. That's also why I think the separate pull won't help at all, since Dave will still have incomplete information. All he can do with more pulls is roll the die more often, that's not helping. Now short term "moar hw support" is cool and all that, but long term I do think it's missing the point of upstreaming. It's not that mesa (or any other cross vendor project, we have a bunch of those on the kms side) is better at uapi, it's that it's more open and so _much_ easier to understand how we ended up at a specific place. That's at least my take on all this. > All of that said, I think providing a link to the userspace user of > the API is reasonable, but I don't think there have been any egregious > cases of badly designed UAPI that were not caught using the existing > processes. Imo the problem isn't the lack of links, but lack of (public) disc
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
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 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 not relying on the period and duty
> > > > > cycle being retrievable from a disabled PWM this type of problem is
> > > > > worked around.
> > > > >
> > > > > Apart from this issue only calling the pwm_get_state/pwm_apply_state
> > > > > combo once is also more effective.
> > > > >
> > > > > Signed-off-by: Uwe Kleine-König
> > > > > ---
> > > > > Hello,
> > > > >
> > > > > There are now two reports about 01ccf903edd6 breaking a backlight. As
> > > > > far as I understand the problem this is a combination of the backend
> > > > > pwm
> > > > > driver yielding surprising results and the pwm-bl driver doing things
> > > > > more complicated than necessary.
> > > > >
> > > > > So I guess this patch works around these problems. Still it would be
> > > > > interesting to find out the details in the imx driver that triggers
> > > > > the
> > > > > problem. So Adam, can you please instrument the pwm-imx27 driver to
> > > > > print *state at the beginning of pwm_imx27_apply() and the end of
> > > > > pwm_imx27_get_state() and provide the results?
> > > > >
> > > > > Note I only compile tested this change.
> > > >
> > > > Hi Uwe,
> > > > I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
> > > > thread that I have a similar problem when you submitted this patch.
> > > >
> > > > So here are my few cents:
> > > >
> > > > My setup is as follows:
> > > > - imx6dl-yapp4-draco with i.MX6Solo
> > > > - backlight is controlled with inverted PWM signal
> > > > - max brightness level = 32, default brightness level set to 32 in DT.
> > > >
> > > > 1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
> > > >pwm_get_state() return the last implemented state):
> > > >
> > > > - System boots to userspace and backlight is enabled all the time from
> > > >power up.
> > > >
> > > >$ dmesg | grep state
> > > >[1.763381] get state end: -1811360608, enabled: 0
> > >
> > > What is -1811360608? When I wrote "print *state" above, I thought about
> > > something like:
> > >
> > > pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
> > > __func__, state->period, state->duty_cycle,
> > > state->polarity, state->enabled);
> > >
> > > A quick look into drivers/pwm/pwm-imx27.c shows that this is another
> > > driver that yields duty_cycle = 0 when the hardware is off.
> >
> > It seems to me like the best recourse to fix this for now would be to
> > patch up the drivers that return 0 when the hardware is off by caching
> > the currently configured duty cycle.
> >
> > How about the patch below?
> >
> > Thierry
> >
> > --- >8 ---
> > From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
> > From: Thierry Reding
> > Date: Thu, 17 Oct 2019 12:56:00 +0200
> > Subject: [PATCH] pwm: imx27: Cache duty cycle register value
> >
> > The hardware register containing the duty cycle value cannot be accessed
> > when the PWM is disabled. This causes the ->get_state() callback to read
> > back a duty cycle value of 0, which can confuse consumer drivers.
> >
> > Signed-off-by: Thierry Reding
Your patch doesn't appear to being the PWM on by default, but I appear
to be able to do stuff without the screen going blank, so I think
we're making some progress. I unrolled the pwm_bl changes, but kept
yours but I am not seeing any ability to change the brightness.
Level 1-7 all appear to me to be the same.
> > ---
> > drivers/pwm/pwm-imx27.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> > index ae11d8577f18..4113d5cd4c62 100644
> > --- a/drivers/pwm/pwm-imx27.c
> > +++ b/drivers/pwm/pwm-imx27.c
> > @@ -85,6 +85,13 @@ struct pwm_imx27_chip {
> > struct clk *clk_per;
> > void __iomem*mmio_base;
> > struct pwm_chip chip;
> > +
> > + /*
> > +* The driver cannot read the current duty cycle from the hardware
> > if
> > +* the hardware is disabled. Cache the last programmed duty cycle
> > +* value to return in that case.
> > +*/
> > + unsigned int duty_cycle;
> > };
> >
> > #define to_pwm_imx27_chip(chip)container_of(chip, struct
> > pwm_imx27_chip, chip)
> > @@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
> > tmp = NSEC_PER_SEC * (u64)(period + 2);
> >
[PATCH] drivers/staging/fbtft/fb_seps525: New driver for SEPS525 (Syncoam) LCD Controllers
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 Signed-off-by: Michael Hennerich Co-developed-by: Beniamin Bia Signed-off-by: Beniamin Bia --- MAINTAINERS| 8 ++ drivers/staging/fbtft/Kconfig | 7 + drivers/staging/fbtft/Makefile | 1 + drivers/staging/fbtft/fb_seps525.c | 213 + 4 files changed, 229 insertions(+) create mode 100644 drivers/staging/fbtft/fb_seps525.c diff --git a/MAINTAINERS b/MAINTAINERS index ef00d6210cff..d077d04f9bc5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15389,6 +15389,14 @@ L: linux-wirel...@vger.kernel.org S: Supported F: drivers/staging/wilc1000/ +STAGING - SEPS525 LCD CONTROLLER DRIVERS +M: Michael Hennerich +M: Beniamin Bia +L: linux-fb...@vger.kernel.org +S: Supported +F: drivers/staging/fbtft/fb_seps525.c +F: Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml + STAGING SUBSYSTEM M: Greg Kroah-Hartman T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig index 8ec524a95ec8..55af11ee2f5b 100644 --- a/drivers/staging/fbtft/Kconfig +++ b/drivers/staging/fbtft/Kconfig @@ -112,6 +112,13 @@ config FB_TFT_S6D1121 help Generic Framebuffer support for S6D1121 +config FB_TFT_SEPS525 + tristate "FB driver for the SEPS525 LCD Controller" + depends on FB_TFT + help + Generic Framebuffer support for SEPS525 + Say Y if you have such a display that utilizes this controller. + config FB_TFT_SH1106 tristate "FB driver for the SH1106 OLED Controller" depends on FB_TFT diff --git a/drivers/staging/fbtft/Makefile b/drivers/staging/fbtft/Makefile index 6bc03311c9c7..e7a0cd9166e9 100644 --- a/drivers/staging/fbtft/Makefile +++ b/drivers/staging/fbtft/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_FB_TFT_PCD8544) += fb_pcd8544.o obj-$(CONFIG_FB_TFT_RA8875) += fb_ra8875.o obj-$(CONFIG_FB_TFT_S6D02A1) += fb_s6d02a1.o obj-$(CONFIG_FB_TFT_S6D1121) += fb_s6d1121.o +obj-$(CONFIG_FB_TFT_SEPS525) += fb_seps525.o obj-$(CONFIG_FB_TFT_SH1106) += fb_sh1106.o obj-$(CONFIG_FB_TFT_SSD1289) += fb_ssd1289.o obj-$(CONFIG_FB_TFT_SSD1305) += fb_ssd1305.o diff --git a/drivers/staging/fbtft/fb_seps525.c b/drivers/staging/fbtft/fb_seps525.c new file mode 100644 index ..05882e2cde7f --- /dev/null +++ b/drivers/staging/fbtft/fb_seps525.c @@ -0,0 +1,213 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * FB driver for the NHD-1.69-160128UGC3 (Newhaven Display International, Inc.) + * using the SEPS525 (Syncoam) LCD Controller + * + * Copyright (C) 2016 Analog Devices Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include + +#include "fbtft.h" + +#define DRVNAME"fb_seps525" +#define WIDTH 160 +#define HEIGHT 128 + +#define SEPS525_INDEX 0x00 +#define SEPS525_STATUS_RD 0x01 +#define SEPS525_OSC_CTL 0x02 +#define SEPS525_IREF 0x80 +#define SEPS525_CLOCK_DIV 0x03 +#define SEPS525_REDUCE_CURRENT 0x04 +#define SEPS525_SOFT_RST 0x05 +#define SEPS525_DISP_ONOFF 0x06 +#define SEPS525_PRECHARGE_TIME_R 0x08 +#define SEPS525_PRECHARGE_TIME_G 0x09 +#define SEPS525_PRECHARGE_TIME_B 0x0A +#define SEPS525_PRECHARGE_CURRENT_R 0x0B +#define SEPS525_PRECHARGE_CURRENT_G 0x0C +#define SEPS525_PRECHARGE_CURRENT_B 0x0D +#define SEPS525_DRIVING_CURRENT_R 0x10 +#define SEPS525_DRIVING_CURRENT_G 0x11 +#define SEPS525_DRIVING_CURRENT_B 0x12 +#define SEPS525_DISPLAYMODE_SET 0x13 +#define SEPS525_RGBIF 0x14 +#define SEPS525_RGB_POL 0x15 +#define SEPS525_MEMORY_WRITEMODE 0x16 +#define SEPS525_MX1_ADDR 0x17 +#define SEPS525_MX2_ADDR 0x18 +#define SEPS525_MY1_ADDR 0x19 +#define SEPS525_MY2_ADDR 0x1A +#define SEPS525_MEMORY_ACCESS_POINTER_X 0x20 +#define SEPS525_MEMORY_ACCESS_POINTER_Y 0x21 +#define SEPS525_DDRAM_DATA_ACCESS_PORT 0x22 +#define SEPS525_GRAY_SCALE_TABLE_INDEX 0x50 +#define SEPS525_GRAY_SCALE_TABLE_DATA 0x51 +#define SEPS525_DUTY 0x28 +#define SEPS525_DSL 0x29 +#define SEPS525_D1_DDRAM_FAC 0x2E +#define SEPS525_D1_DDRAM_FAR 0x2F +#define SEPS525_D2_DDRAM_SAC 0x31 +#define SEPS525_D2_DDRAM_SAR 0x32 +#define SEP
