Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: > Apologies, I'm not sure I'm understanding your suggestion here. > dma_alloc_contiguous() does have some interesting optimizations > (avoiding allocating single page from cma), though its focus on > default area vs specific device area doesn't quite match up the usage > model for dma heaps. Instead of allocating memory for a single > device, we want to be able to allow userland, for a given usage mode, > to be able to allocate a dmabuf from a specific heap of memory which > will satisfy the usage mode for that buffer pipeline (across multiple > devices). > > Now, indeed, the system and cma heaps in this patchset are a bit > simple/trivial (though useful with my devices that require contiguous > buffers for the display driver), but more complex ION heaps have > traditionally stayed out of tree in vendor code, in many cases making > incompatible tweaks to the ION core dmabuf exporter logic. So what would the more complicated heaps be? > That's why > dmabuf heaps is trying to destage ION in a way that allows heaps to > implement their exporter logic themselves, so we can start pulling > those more complicated heaps out of their vendor hidey-holes and get > some proper upstream review. > > But I suspect I just am confused as to what your suggesting. Maybe > could you expand a bit? Apologies for being a bit dense. My suggestion is to merge the system and CMA heaps. CMA (at least the system-wide CMA area) is really just an optimization to get large contigous regions more easily. We should make use of it as transparent as possible, just like we do in the DMA code.
Re: [PATCH] drm: rcar_lvds: Fix dual link mode operations
Hi Jacopo,
On Wed, Jul 24, 2019 at 3:38 AM Jacopo Mondi wrote:
> The R-Car LVDS encoder units support dual-link operations by splitting
> the pixel output between the primary encoder and the companion one.
>
> In order for the primary encoder to succesfully control the companion's
> operations this should not fail at probe time and register itself its
> associated drm bridge so that the primary one can find it.
>
> Currently the companion encoder fails at probe time, causing the
> registration of the primary to fail preventing the whole DU unit to be
> registered correctly.
>
> Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
> Reported-by: Fabrizio Castro
> Signed-off-by: Jacopo Mondi
>
> ---
> The "Fixes" tag refers to a patch currently part of the
> renesas-drivers-2019-07-09-v5.2 branch of Geert's renesas-drivers tree.
The broken commit is also present in v5.3-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
On Mon 2019-07-22 16:54:10, Stephen Boyd wrote: > Quoting Brendan Higgins (2019-07-22 15:30:49) > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote: > > > > > > > > > What's the calling context of the assertions and expectations? I still > > > don't like the fact that string stream needs to allocate buffers and > > > throw them into a list somewhere because the calling context matters > > > there. > > > > The calling context is the same as before, which is anywhere. > > Ok. That's concerning then. > > > > > > I'd prefer we just wrote directly to the console/log via printk > > > instead. That way things are simple because we use the existing > > > buffering path of printk, but maybe there's some benefit to the string > > > stream that I don't see? Right now it looks like it builds a string and > > > then dumps it to printk so I'm sort of lost what the benefit is over > > > just writing directly with printk. > > > > It's just buffering it so the whole string gets printed uninterrupted. > > If we were to print out piecemeal to printk, couldn't we have another > > call to printk come in causing it to garble the KUnit message we are > > in the middle of printing? > > Yes, printing piecemeal by calling printk many times could lead to > interleaving of messages if something else comes in such as an interrupt > printing something. Printk has some support to hold "records" but I'm > not sure how that would work here because KERN_CONT talks about only > being used early on in boot code. I haven't looked at printk in detail > though so maybe I'm all wrong and KERN_CONT just works? KERN_CONT does not guarantee that the message will get printed together. The pieces get interleaved with messages printed in parallel. Note that KERN_CONT was originally really meant to be used only during boot. It was later used more widely and ended in the best effort category. There were several attempts to make it more reliable. But it was always either too complicated or error prone or both. You need to use your own buffering if you rely want perfect output. The question is if it is really worth the complexity. Also note that any buffering reduces the chance that the messages will reach the console. BTW: There is a work in progress on a lockless printk ring buffer. It will make printk() more secure regarding deadlocks. But it might make transparent handling of continuous lines even more tricky. I guess that local buffering, before calling printk(), will be even more important then. Well, it might really force us to create an API for it. > Can printk be called once with whatever is in the struct? Otherwise if > this is about making printk into a structured log then maybe printk > isn't the proper solution anyway. Maybe a dev interface should be used > instead that can handle starting and stopping tests (via ioctl) in > addition to reading test results, records, etc. with read() and a > clearing of the records. Then the seqfile API works naturally. All of > this is a bit premature, but it looks like you're going down the path of > making something akin to ftrace that stores binary formatted > assertion/expectation records in a lockless ring buffer that then > formats those records when the user asks for them. IMHO, ftrace postpones the text formatting primary because it does not not want to slow down the traced code more than necessary. It is yet another layer and there should be some strong reason for it. > I can imagine someone wanting to write unit tests that check conditions > from a simulated hardirq context via irq works (a driver mock > framework?), so this doesn't seem far off. Note that stroring the messages into the printk log is basically safe in any context. It uses temporary per-CPU buffers for recursive messages and in NMI. The only problem is panic() when some CPU gets stuck with the lock taken. This will get solved by the lockless ringbuffer. Also the temporary buffers will not be necessary any longer. Much bigger problems are with consoles. There are many of them. It means a lot of code and more locks involved, including scheduler locks. Note that console lock is a semaphore. Best Regards, Petr
Re: [PATCH -next] drm/mga: remove set but not used variable 'buf_priv'
Am 24.07.19 um 03:46 schrieb YueHaibing:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/mga/mga_state.c: In function 'mga_dma_iload':
> drivers/gpu/drm/mga/mga_state.c:945:22: warning:
> variable 'buf_priv' set but not used [-Wunused-but-set-variable]
>
> It is never used, so can be removed.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/mga/mga_state.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mga/mga_state.c b/drivers/gpu/drm/mga/mga_state.c
> index 77a0b006f066..0dec4062e5a2 100644
> --- a/drivers/gpu/drm/mga/mga_state.c
> +++ b/drivers/gpu/drm/mga/mga_state.c
> @@ -942,7 +942,6 @@ static int mga_dma_iload(struct drm_device *dev, void
> *data, struct drm_file *fi
> struct drm_device_dma *dma = dev->dma;
> drm_mga_private_t *dev_priv = dev->dev_private;
> struct drm_buf *buf;
> - drm_mga_buf_priv_t *buf_priv;
> drm_mga_iload_t *iload = data;
> DRM_DEBUG("\n");
>
> @@ -959,7 +958,6 @@ static int mga_dma_iload(struct drm_device *dev, void
> *data, struct drm_file *fi
> return -EINVAL;
>
> buf = dma->buflist[iload->idx];
> - buf_priv = buf->dev_private;
>
> if (mga_verify_iload(dev_priv, iload->dstorg, iload->length)) {
> mga_freelist_put(dev, buf);
>
Thanks!
Acked-by: Thomas Zimmermann
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/syncobj: extend syncobj query ability v2
Am 24.07.19 um 08:32 schrieb zhoucm1:
>
>
> On 2019年07月24日 03:20, Lionel Landwerlin wrote:
>> On 23/07/2019 17:21, Chunming Zhou wrote:
>>> user space needs a flexiable query ability.
>>> So that umd can get last signaled or submitted point.
>>> v2:
>>> add sanitizer checking.
>>>
>>> Change-Id: I6512b430524ebabe715e602a2bf5abb0a7e780ea
>>> Signed-off-by: Chunming Zhou
>>> Cc: Lionel Landwerlin
>>> Cc: Christian König
>>
>> Reviewed-by: Lionel Landwerlin
>
> Thanks.
> Which branch should this patch go to?
> Is it OK to push to amd-staging-drm-next?
> Or should it go to drm-misc?
> If drm-misc, I need your help to push it since I have no permission to
> write.
drm-misc-next is probably more appropriated.
I'm going to take of that, but first let me push my fix now.
Christian.
>
> -David
>>
>>> ---
>>> drivers/gpu/drm/drm_syncobj.c | 34 --
>>> include/uapi/drm/drm.h | 3 ++-
>>> 2 files changed, 22 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index 3d400905100b..3fc8f66ada68 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -1197,7 +1197,7 @@ drm_syncobj_timeline_signal_ioctl(struct
>>> drm_device *dev, void *data,
>>> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
>>> return -EOPNOTSUPP;
>>> - if (args->pad != 0)
>>> + if (args->flags != 0)
>>> return -EINVAL;
>>> if (args->count_handles == 0)
>>> @@ -1268,7 +1268,7 @@ int drm_syncobj_query_ioctl(struct drm_device
>>> *dev, void *data,
>>> if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE))
>>> return -EOPNOTSUPP;
>>> - if (args->pad != 0)
>>> + if (args->flags & ~DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED)
>>> return -EINVAL;
>>> if (args->count_handles == 0)
>>> @@ -1291,23 +1291,29 @@ int drm_syncobj_query_ioctl(struct
>>> drm_device *dev, void *data,
>>> if (chain) {
>>> struct dma_fence *iter, *last_signaled = NULL;
>>> - dma_fence_chain_for_each(iter, fence) {
>>> - if (!iter)
>>> - break;
>>> - dma_fence_put(last_signaled);
>>> - last_signaled = dma_fence_get(iter);
>>> - if (!to_dma_fence_chain(last_signaled)->prev_seqno)
>>> - /* It is most likely that timeline has
>>> - * unorder points. */
>>> - break;
>>> + if (args->flags &
>>> + DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED) {
>>> + point = fence->seqno;
>>> + } else {
>>> + dma_fence_chain_for_each(iter, fence) {
>>> + if (!iter)
>>> + break;
>>> + dma_fence_put(last_signaled);
>>> + last_signaled = dma_fence_get(iter);
>>> + if
>>> (!to_dma_fence_chain(last_signaled)->prev_seqno)
>>> + /* It is most likely that timeline has
>>> + * unorder points. */
>>> + break;
>>> + }
>>> + point = dma_fence_is_signaled(last_signaled) ?
>>> + last_signaled->seqno :
>>> + to_dma_fence_chain(last_signaled)->prev_seqno;
>>> }
>>> - point = dma_fence_is_signaled(last_signaled) ?
>>> - last_signaled->seqno :
>>> - to_dma_fence_chain(last_signaled)->prev_seqno;
>>> dma_fence_put(last_signaled);
>>> } else {
>>> point = 0;
>>> }
>>> + dma_fence_put(fence);
>>> ret = copy_to_user(&points[i], &point, sizeof(uint64_t));
>>> ret = ret ? -EFAULT : 0;
>>> if (ret)
>>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>>> index 661d73f9a919..fd987ce24d9f 100644
>>> --- a/include/uapi/drm/drm.h
>>> +++ b/include/uapi/drm/drm.h
>>> @@ -777,11 +777,12 @@ struct drm_syncobj_array {
>>> __u32 pad;
>>> };
>>> +#define DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED (1 << 0) /* last
>>> available point on timeline syncobj */
>>> struct drm_syncobj_timeline_array {
>>> __u64 handles;
>>> __u64 points;
>>> __u32 count_handles;
>>> - __u32 pad;
>>> + __u32 flags;
>>> };
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/23] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Hi
Am 23.07.19 um 14:44 schrieb Andrzej Pietrasiewicz:
> Hi Sam,
>
> W dniu 23.07.2019 o 11:05, Sam Ravnborg pisze:
>> Hi Andrzej
>>
>> On Thu, Jul 11, 2019 at 01:26:41PM +0200, Andrzej Pietrasiewicz wrote:
>>> Use the ddc pointer provided by the generic connector.
>>>
>>> Signed-off-by: Andrzej Pietrasiewicz
>>> ---
>>> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>>> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>>> index 62d014c20988..c373edb95666 100644
>>> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>>> @@ -219,6 +219,7 @@ static struct drm_connector
>>> *tfp410_connector_create(struct drm_device *dev,
>>> tfp410_connector->mod = mod;
>>> connector = &tfp410_connector->base;
>>> + connector->ddc = mod->i2c;
>>> drm_connector_init(dev, connector, &tfp410_connector_funcs,
>>> DRM_MODE_CONNECTOR_DVID);
>>
>> When reading this code, it looks strange that we set connector->ddc
>> *before* the call to init the connector.
>> One could risk that drm_connector_init() used memset(..) to clear all
>> fields or so, and it would break this order.
>
> I verified the code of drm_connector_init() and cannot find any memset()
> invocations there. What is your actual concern?
I think this echoes my concern about the implicit order of operation. It
seems too easy to get this wrong. If you don't want to add an additional
interface for setting the ddc field, why not add a dedicated initializer
function that sets the ddc field? Something like this.
int drm_connector_init_with_ddc(connector, funcs, ..., ddc)
{
ret = drm_connector_init(connector, funcs, ...);
if (ret)
return ret;
if (!ddc)
return 0;
connector->ddc = ddc;
/* set up sysfs */
return 0;
}
Best regards
Thomas
> Andrzej
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] libdrm: wrap new flexible syncobj query interface
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
Cc: Christian König
---
amdgpu/amdgpu-symbol-check | 1 +
amdgpu/amdgpu.h| 18 ++
amdgpu/amdgpu_cs.c | 10 ++
include/drm/drm.h | 3 ++-
xf86drm.c | 19 +++
xf86drm.h | 2 ++
6 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 274b4c6d..3bc1a9f1 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -56,6 +56,7 @@ amdgpu_cs_syncobj_export_sync_file2
amdgpu_cs_syncobj_import_sync_file
amdgpu_cs_syncobj_import_sync_file2
amdgpu_cs_syncobj_query
+amdgpu_cs_syncobj_query1
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
amdgpu_cs_syncobj_timeline_signal
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 9d9b0832..ce7e2bbb 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1591,6 +1591,24 @@ int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle
dev,
int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
uint32_t *handles, uint64_t *points,
unsigned num_handles);
+/**
+ * Query sync objects payloads.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param num_handles - \c [in] self-explanatory
+ * \param flags - \c [in] a bitmask of DRM_SYNCOBJ_QUERY_FLAGS_*
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query1(amdgpu_device_handle dev,
+uint32_t *handles, uint64_t *points,
+unsigned num_handles, uint32_t flags);
/**
* Export kernel sync object to shareable fd.
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 977fa3cf..e2287fa0 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -721,6 +721,16 @@ drm_public int
amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
return drmSyncobjQuery(dev->fd, handles, points, num_handles);
}
+drm_public int amdgpu_cs_syncobj_query1(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles, uint32_t flags)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjQuery1(dev->fd, handles, points, num_handles, flags);
+}
+
drm_public int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 532787bf..af37a80b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -771,11 +771,12 @@ struct drm_syncobj_array {
__u32 pad;
};
+#define DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED (1 << 0) /* last available
point on timeline syncobj */
struct drm_syncobj_timeline_array {
__u64 handles;
__u64 points;
__u32 count_handles;
- __u32 pad;
+ __u32 flags;
};
diff --git a/xf86drm.c b/xf86drm.c
index 953fc762..fb7d5cc5 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4314,6 +4314,25 @@ drm_public int drmSyncobjQuery(int fd, uint32_t
*handles, uint64_t *points,
return 0;
}
+drm_public int drmSyncobjQuery1(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count, uint32_t flags)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uintptr_t)points;
+args.count_handles = handle_count;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, &args);
+if (ret)
+return ret;
+return 0;
+}
+
+
drm_public int drmSyncobjTransfer(int fd,
uint32_t dst_handle, uint64_t dst_point,
uint32_t src_handle, uint64_t src_point,
diff --git a/xf86drm.h b/xf86drm.h
index 3fb1d1ca..29c1df6d 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -884,6 +884,8 @@ extern int drmSyncobjTimelineWait(int fd, uint32_t
*handles, uint64_t *points,
uint32_t *first_signaled);
extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
uint32_t handle_count);
+extern int drmSyncobjQuery1(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count, uint32_t flags);
extern int drmSyncobjTransfer(int fd,
uint32_t dst_handle, uint64_t dst_point,
uint32_t src_handle, uint64_t src_point,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
Le mer. 24 juil. 2019 à 09:00, Christoph Hellwig a écrit : > > On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: > > Apologies, I'm not sure I'm understanding your suggestion here. > > dma_alloc_contiguous() does have some interesting optimizations > > (avoiding allocating single page from cma), though its focus on > > default area vs specific device area doesn't quite match up the usage > > model for dma heaps. Instead of allocating memory for a single > > device, we want to be able to allow userland, for a given usage mode, > > to be able to allocate a dmabuf from a specific heap of memory which > > will satisfy the usage mode for that buffer pipeline (across multiple > > devices). > > > > Now, indeed, the system and cma heaps in this patchset are a bit > > simple/trivial (though useful with my devices that require contiguous > > buffers for the display driver), but more complex ION heaps have > > traditionally stayed out of tree in vendor code, in many cases making > > incompatible tweaks to the ION core dmabuf exporter logic. > > So what would the more complicated heaps be? > > > That's why > > dmabuf heaps is trying to destage ION in a way that allows heaps to > > implement their exporter logic themselves, so we can start pulling > > those more complicated heaps out of their vendor hidey-holes and get > > some proper upstream review. > > > > But I suspect I just am confused as to what your suggesting. Maybe > > could you expand a bit? Apologies for being a bit dense. > > My suggestion is to merge the system and CMA heaps. CMA (at least > the system-wide CMA area) is really just an optimization to get > large contigous regions more easily. We should make use of it as > transparent as possible, just like we do in the DMA code. CMA has made possible to get large regions of memories and to give some priority on device allocating pages on it. I don't think that possible with system heap so I suggest to keep CMA heap if we want to be able to port a maximum of applications on dma-buf-heap. Benjamin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: rcar_lvds: Fix dual link mode operations
Hi Jacopo,
Thank you for your patch!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Jacopo Mondi
> Sent: 23 July 2019 17:57
> Subject: [PATCH] drm: rcar_lvds: Fix dual link mode operations
>
> The R-Car LVDS encoder units support dual-link operations by splitting
> the pixel output between the primary encoder and the companion one.
>
> In order for the primary encoder to succesfully control the companion's
> operations this should not fail at probe time and register itself its
> associated drm bridge so that the primary one can find it.
>
> Currently the companion encoder fails at probe time, causing the
> registration of the primary to fail preventing the whole DU unit to be
> registered correctly.
>
> Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
> Reported-by: Fabrizio Castro
> Signed-off-by: Jacopo Mondi
Reviewed-by: Fabrizio Castro
Tested-by: Fabrizio Castro
>
> ---
> The "Fixes" tag refers to a patch currently part of the
> renesas-drivers-2019-07-09-v5.2 branch of Geert's renesas-drivers tree.
>
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 31 +
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index bada7ee98544..8b015ba95895 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -767,14 +767,29 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
> of_node_put(remote_input);
> of_node_put(remote);
>
> - /*
> - * On D3/E3 the LVDS encoder provides a clock to the DU, which can be
> - * used for the DPAD output even when the LVDS output is not connected.
> - * Don't fail probe in that case as the DU will need the bridge to
> - * control the clock.
> - */
> - if (lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)
> - return ret == -ENODEV ? 0 : ret;
> + switch (ret) {
> + case -ENODEV:
> + /*
> + * On D3/E3 the LVDS encoder provides a clock to the DU, which
> + * can be used for the DPAD output even when the LVDS output is
> + * not connected. Don't fail probe in that case as the DU will
> + * need the bridge to control the clock.
> + */
> + if (lvds->info->quirks & RCAR_LVDS_QUIRK_EXT_PLL)
> + ret = 0;
> + break;
> + case -ENXIO:
> + /*
> + * When the LVDS output is used in dual link mode, the
> + * companion encoder fails at
> + * 'rcar_lvds_parse_dt_companion()'. Don't fail probe in
> + * that case as the master encoder will need the companion's
> + * bridge to control its operations.
> + */
> + if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
> + ret = 0;
> + break;
> + }
>
> return ret;
> }
> --
> 2.22.0
[PATCH v3 3/7] sh: ecovec24: don't set unused fields in platform data
From: Bartosz Golaszewski
Platform data fields other than fbdev are no longer used by the
backlight driver. Remove them.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
---
arch/sh/boards/mach-ecovec24/setup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index 6926bb3865b9..64a5a1662b6d 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -386,9 +386,6 @@ static struct property_entry gpio_backlight_props[] = {
static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = &lcdc_device.dev,
- .gpio = GPIO_PTR1,
- .def_value = 1,
- .name = "backlight",
};
static const struct platform_device_info gpio_backlight_device_info = {
--
2.21.0
[PATCH v3 2/7] backlight: gpio: simplify the platform data handling
From: Bartosz Golaszewski
Now that the last user of platform data (sh ecovec24) defines a proper
GPIO lookup and sets the 'default-on' device property, we can drop the
platform_data-specific GPIO handling and unify a big chunk of code.
The only field used from the platform data is now the fbdev pointer.
Signed-off-by: Bartosz Golaszewski
---
drivers/video/backlight/gpio_backlight.c | 64 +---
1 file changed, 13 insertions(+), 51 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e84f3087e29f..01262186fa1e 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -55,30 +55,6 @@ static const struct backlight_ops gpio_backlight_ops = {
.check_fb = gpio_backlight_check_fb,
};
-static int gpio_backlight_probe_dt(struct platform_device *pdev,
- struct gpio_backlight *gbl)
-{
- struct device *dev = &pdev->dev;
- enum gpiod_flags flags;
- int ret;
-
- gbl->def_value = device_property_read_bool(dev, "default-on");
- flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
-
- gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
- if (IS_ERR(gbl->gpiod)) {
- ret = PTR_ERR(gbl->gpiod);
-
- if (ret != -EPROBE_DEFER) {
- dev_err(dev,
- "Error: The gpios parameter is missing or
invalid.\n");
- }
- return ret;
- }
-
- return 0;
-}
-
static int gpio_backlight_probe(struct platform_device *pdev)
{
struct gpio_backlight_platform_data *pdata =
@@ -86,6 +62,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
+ enum gpiod_flags flags;
int ret;
gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
@@ -94,35 +71,20 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
gbl->dev = &pdev->dev;
- if (pdev->dev.fwnode) {
- ret = gpio_backlight_probe_dt(pdev, gbl);
- if (ret)
- return ret;
- } else if (pdata) {
- /*
-* Legacy platform data GPIO retrieveal. Do not expand
-* the use of this code path, currently only used by one
-* SH board.
-*/
- unsigned long flags = GPIOF_DIR_OUT;
-
+ if (pdata)
gbl->fbdev = pdata->fbdev;
- gbl->def_value = pdata->def_value;
- flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
-
- ret = devm_gpio_request_one(gbl->dev, pdata->gpio, flags,
- pdata ? pdata->name : "backlight");
- if (ret < 0) {
- dev_err(&pdev->dev, "unable to request GPIO\n");
- return ret;
+
+ gbl->def_value = device_property_read_bool(&pdev->dev, "default-on");
+ flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+
+ gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
+ if (IS_ERR(gbl->gpiod)) {
+ ret = PTR_ERR(gbl->gpiod);
+ if (ret != -EPROBE_DEFER) {
+ dev_err(&pdev->dev,
+ "Error: The gpios parameter is missing or
invalid.\n");
}
- gbl->gpiod = gpio_to_desc(pdata->gpio);
- if (!gbl->gpiod)
- return -EINVAL;
- } else {
- dev_err(&pdev->dev,
- "failed to find platform data or device tree node.\n");
- return -ENODEV;
+ return ret;
}
memset(&props, 0, sizeof(props));
--
2.21.0
[PATCH v3 6/7] backlight: gpio: remove def_value from struct gpio_backlight
From: Bartosz Golaszewski
This field is unused outside of probe(). There's no need to store it.
We can make it into a local variable.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 70882556f047..cd6a75bca9cc 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -21,7 +21,6 @@
struct gpio_backlight {
struct device *fbdev;
struct gpio_desc *gpiod;
- int def_value;
};
static int gpio_backlight_update_status(struct backlight_device *bl)
@@ -61,7 +60,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
- int ret;
+ int ret, def_value;
gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
@@ -70,8 +69,8 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (pdata)
gbl->fbdev = pdata->fbdev;
- gbl->def_value = device_property_read_bool(&pdev->dev, "default-on");
- flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+ def_value = device_property_read_bool(&pdev->dev, "default-on");
+ flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
@@ -94,7 +93,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = def_value;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.21.0
dri-devel@lists.freedesktop.org
wt., 23 lip 2019 o 17:34 Andy Shevchenko
napisał(a):
>
> On Tue, Jul 23, 2019 at 08:29:52AM +0200, Bartosz Golaszewski wrote:
> > pon., 22 lip 2019 o 18:09 Andy Shevchenko
> > napisał(a):
> > >
> > > On Mon, Jul 22, 2019 at 05:03:02PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski
> > > >
> > > > Instead of dereferencing pdev each time, use a helper variable for
> > > > the associated device pointer.
> > >
> > > > static int gpio_backlight_probe(struct platform_device *pdev)
> > > > {
> > > > - struct gpio_backlight_platform_data *pdata =
> > > > - dev_get_platdata(&pdev->dev);
> > > > + struct gpio_backlight_platform_data *pdata;
> > > > struct backlight_properties props;
> > > > struct backlight_device *bl;
> > > > struct gpio_backlight *gbl;
> > > > enum gpiod_flags flags;
> > > > + struct device *dev;
> > >
> > > Can't we do
> > >
> > > struct device dev = &pdev->dev;
> > > struct gpio_backlight_platform_data *pdata =
> > > dev_get_platdata(dev);
> > >
> > > ? It fits 80 nicely.
> > >
> >
> > IMO it's more readable like that with the reverse christmas tree layout.
>
> It makes more churn in the original code and for initializers the order is
> defined by its nature.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Fair enough, I changed it in v3.
Bart
Re: [PATCH v2 2/7] backlight: gpio: simplify the platform data handling
wt., 23 lip 2019 o 17:32 Andy Shevchenko
napisał(a):
>
> On Tue, Jul 23, 2019 at 08:28:00AM +0200, Bartosz Golaszewski wrote:
> > pon., 22 lip 2019 o 18:06 Andy Shevchenko
> > napisał(a):
> > >
> > > On Mon, Jul 22, 2019 at 05:02:57PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski
> > > >
> > > > Now that the last user of platform data (sh ecovec24) defines a proper
> > > > GPIO lookup and sets the 'default-on' device property, we can drop the
> > > > platform_data-specific GPIO handling and unify a big chunk of code.
> > > >
> > > > The only field used from the platform data is now the fbdev pointer.
> > >
> > > > -static int gpio_backlight_probe_dt(struct platform_device *pdev,
> > > > -struct gpio_backlight *gbl)
> > > > -{
> > > > - struct device *dev = &pdev->dev;
> > > > - enum gpiod_flags flags;
> > > > - int ret;
> > > > -
> > > > - gbl->def_value = device_property_read_bool(dev, "default-on");
> > > > - flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> > > > -
> > > > - gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> > > > - if (IS_ERR(gbl->gpiod)) {
> > > > - ret = PTR_ERR(gbl->gpiod);
> > > > -
> > > > - if (ret != -EPROBE_DEFER) {
> > > > - dev_err(dev,
> > > > - "Error: The gpios parameter is missing or
> > > > invalid.\n");
> > > > - }
> > > > - return ret;
> > > > - }
> > > > -
> > > > - return 0;
> > > > -}
> > >
> > > Why not leave this function (perhaps with different name)?
> >
> > Why would we do that if the entire probe() function is now less than
> > 50 lines long? Also: it gets inlined by the compiler anyway. It
> > doesn't make sense IMO.
>
> I'm not against this, perhaps, dropping and moving can be split to two
> changes.
>
This really is unnecessary - we can do it in a single patch alright.
Bart
Re: [PATCH v3 0/7] backlight: gpio: simplify the driver
śr., 24 lip 2019 o 10:25 Bartosz Golaszewski napisał(a): > > From: Bartosz Golaszewski > > While working on my other series related to gpio-backlight[1] I noticed > that we could simplify the driver if we made the only user of platform > data use GPIO lookups and device properties. This series tries to do > that. > > The first patch adds all necessary data structures to ecovec24. Patch > 2/7 unifies much of the code for both pdata and non-pdata cases. Patches > 3-4/7 remove unused platform data fields. Last three patches contain > additional improvements for the GPIO backlight driver while we're already > modifying it. > > I don't have access to this HW but hopefully this works. Only compile > tested. > > [1] https://lkml.org/lkml/2019/6/25/900 > > v1 -> v2: > - rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy > - added additional two patches with minor improvements > > v2 -> v3: > - in patch 7/7: used initializers to set values for pdata and dev local vars > > Bartosz Golaszewski (7): > sh: ecovec24: add additional properties to the backlight device > backlight: gpio: simplify the platform data handling > sh: ecovec24: don't set unused fields in platform data > backlight: gpio: remove unused fields from platform data > backlight: gpio: remove dev from struct gpio_backlight > backlight: gpio: remove def_value from struct gpio_backlight > backlight: gpio: use a helper variable for &pdev->dev > > arch/sh/boards/mach-ecovec24/setup.c | 33 ++-- > drivers/video/backlight/gpio_backlight.c | 82 +--- > include/linux/platform_data/gpio_backlight.h | 3 - > 3 files changed, 44 insertions(+), 74 deletions(-) > > -- > 2.21.0 > Daniel, I missed your review tags - could you add them again? Thanks, Bart
Re: [PATCH] Enable backlight when trigger is activated
Hi! > >>> +++ b/drivers/leds/trigger/ledtrig-backlight.c > >>> @@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led) > >>> n->old_status = UNBLANK; > >>> n->notifier.notifier_call = fb_notifier_callback; > >>> > >>> + led_set_brightness(led, LED_ON); > >>> + > >> > >> This looks fishy. > >> > >> Maybe you should use a default-state = "keep" instead? (and you'll have > >> to support it in the LED driver). > >> > >> That'll give you proper "don't touch the LED if it was turned on" behavior, > >> which is what you seem to want. > > > > Actually no, that's not what I want. LED should go on if the display > > is active, as soon as trigger is activated. > > > > Unfortunately, I have see no good way to tell if the display is > > active (and display is usually active when trigger is activated). > > default-state DT property can be also set to "on" > (see Documentation/devicetree/bindings/leds/common.txt). Yes, except that it does not work with all drivers :-(. In particular, it does not work with lm3532. We should really move more of the device tree parsing into core, so that there's one place to fix... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] drm: rcar_lvds: Fix dual link mode operations
Hi Geert,
On Wed, Jul 24, 2019 at 09:28:58AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Jul 24, 2019 at 3:38 AM Jacopo Mondi
> wrote:
> > The R-Car LVDS encoder units support dual-link operations by splitting
> > the pixel output between the primary encoder and the companion one.
> >
> > In order for the primary encoder to succesfully control the companion's
> > operations this should not fail at probe time and register itself its
> > associated drm bridge so that the primary one can find it.
> >
> > Currently the companion encoder fails at probe time, causing the
> > registration of the primary to fail preventing the whole DU unit to be
> > registered correctly.
> >
> > Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
> > Reported-by: Fabrizio Castro
> > Signed-off-by: Jacopo Mondi
> >
> > ---
> > The "Fixes" tag refers to a patch currently part of the
> > renesas-drivers-2019-07-09-v5.2 branch of Geert's renesas-drivers tree.
>
> The broken commit is also present in v5.3-rc1.
You're right... This is then entitled to be collected for rc2 then.
Thanks
j
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
signature.asc
Description: PGP signature
Re: [PATCH v4 14/23] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Hi Thomas,
W dniu 24.07.2019 o 10:01, Thomas Zimmermann pisze:
Hi
I think this echoes my concern about the implicit order of operation. It
seems too easy to get this wrong. If you don't want to add an additional
interface for setting the ddc field, why not add a dedicated initializer
function that sets the ddc field? Something like this.
int drm_connector_init_with_ddc(connector, funcs, ..., ddc)
{
ret = drm_connector_init(connector, funcs, ...);
if (ret)
return ret;
if (!ddc)
return 0;
connector->ddc = ddc;
/* set up sysfs */
return 0;
}
True. I will send a v5 soon.
Thanks,
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> Hi Maxime,
>
> On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> wrote:
> >
> > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > > wrote:
> > > > > > > tcon-pixel clock is the rate that you want to achive on display
> > > > > > > side
> > > > > > > and if you have 4 lanes 32bit or lanes and different bit number
> > > > > > > that
> > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > speed
> > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock
> > > > > > > of
> > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most
> > > > > > > of
> > > > > > > the display.
> > > > > >
> > > > > > So this is what the issue is then?
> > > > > >
> > > > > > This one does make sense, and you should just change the rate in the
> > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > >
> > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > discussion or the commit log before though.
> > > > > >
> > > > > Something like this?
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > drm_display_mode *mode,
> > > > > }
> > > > >
> > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > - const struct drm_display_mode
> > > > > *mode)
> > > > > + const struct drm_display_mode
> > > > > *mode,
> > > > > + u32 tcon_mul)
> > > > > {
> > > > > /* Configure the dot clock */
> > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > >
> > > > > /* Set the resolution */
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > u8 lanes = device->lanes;
> > > > > u32 block_space, start_delay;
> > > > > - u32 tcon_div;
> > > > > + u32 tcon_div, tcon_mul;
> > > > >
> > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > + tcon->dclk_min_div = 4;
> > > > > + tcon->dclk_max_div = 127;
> > > > >
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + tcon_mul = bpp / lanes;
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > > sun4i_tcon_get_connector(encoder));
> > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > */
> > > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > > tcon_div &= GENMASK(6, 0);
> > > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > > block_space -= mode->hdisplay + 40;
> > > > >
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > > sun4i_tcon *tcon,
> > > > >
> > > > > tcon->dclk_min_div = 7;
> > > > > tcon->dclk_max_div = 7;
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > > sun4i_tcon_get_connector(encoder));
> > > > > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > > > > sun4i_tcon *tcon,
> > > > >
> > > > > tcon->dclk_min_div = 6;
> > > > > tcon->dclk_max_div = 127;
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > > > > diff
Re: [PATCH v3] drm/tegra: sor: Enable HDA interrupts at plug-in
23.07.2019 15:40, Viswanath L пишет:
> HDMI plugout calls runtime suspend, which clears interrupt registers
> and causes audio functionality to break on subsequent plug-in; setting
> interrupt registers in sor_audio_prepare() solves the issue.
>
> Signed-off-by: Viswanath L
Yours signed-off-by always should be the last line of the commit's
message because the text below it belongs to a person who applies this
patch, Thierry in this case. This is not a big deal at all and Thierry
could make a fixup while applying the patch if will deem that as necessary.
Secondly, there is no need to add "sta...@vger.kernel.org" to the
email's recipients because the patch will flow into stable kernel
versions from the mainline once it will get applied. That happens based
on the stable tag presence, hence it's enough to add the 'Cc' tag to the
commit's message in order to get patch backported.
Lastly, next time please add everyone to the email's recipients whom
you're expecting to get a reply. Otherwise there is a chance that patch
will be left unnoticed.
Everything else looks good to me, thanks!
Reviewed-by: Dmitry Osipenko
> Fixes: 8e2988a76c26 ("drm/tegra: sor: Support for audio over HDMI")
> Cc:
> ---
> drivers/gpu/drm/tegra/sor.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 5be5a08..0470cfe 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -2164,6 +2164,15 @@ static void tegra_sor_audio_prepare(struct tegra_sor
> *sor)
>
> value = SOR_AUDIO_HDA_PRESENSE_ELDV | SOR_AUDIO_HDA_PRESENSE_PD;
> tegra_sor_writel(sor, value, SOR_AUDIO_HDA_PRESENSE);
> +
> + /*
> + * Enable and unmask the HDA codec SCRATCH0 register interrupt. This
> + * is used for interoperability between the HDA codec driver and the
> + * HDMI/DP driver.
> + */
> + value = SOR_INT_CODEC_SCRATCH1 | SOR_INT_CODEC_SCRATCH0;
> + tegra_sor_writel(sor, value, SOR_INT_ENABLE);
> + tegra_sor_writel(sor, value, SOR_INT_MASK);
> }
>
> static void tegra_sor_audio_unprepare(struct tegra_sor *sor)
> @@ -2913,15 +2922,6 @@ static int tegra_sor_init(struct host1x_client *client)
> if (err < 0)
> return err;
>
> - /*
> - * Enable and unmask the HDA codec SCRATCH0 register interrupt. This
> - * is used for interoperability between the HDA codec driver and the
> - * HDMI/DP driver.
> - */
> - value = SOR_INT_CODEC_SCRATCH1 | SOR_INT_CODEC_SCRATCH0;
> - tegra_sor_writel(sor, value, SOR_INT_ENABLE);
> - tegra_sor_writel(sor, value, SOR_INT_MASK);
> -
> return 0;
> }
>
>
Re: memory leak in dma_buf_ioctl
On Wed, Jul 24, 2019 at 11:48 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:abdfd52a Merge tag 'armsoc-defconfig' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=131441d060 > kernel config: https://syzkaller.appspot.com/x/.config?x=d31de3d88059b7fa > dashboard link: https://syzkaller.appspot.com/bug?extid=b2098bc44728a4efb3e9 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12526e5860 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161784f060 +drivers/dma-buf/dma-buf.c maintainers > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+b2098bc44728a4efb...@syzkaller.appspotmail.com > > executing program > executing program > executing program > executing program > executing program > BUG: memory leak > unreferenced object 0x888114034680 (size 32): >comm "syz-executor110", pid 6894, jiffies 4294947136 (age 13.580s) >hex dump (first 32 bytes): > 00 64 6d 61 62 75 66 3a 00 00 00 00 00 00 00 00 .dmabuf: > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [] kmemleak_alloc_recursive > /./include/linux/kmemleak.h:43 [inline] > [ ] slab_post_alloc_hook /mm/slab.h:522 [inline] > [ ] slab_alloc /mm/slab.c:3319 [inline] > [ ] __do_kmalloc /mm/slab.c:3653 [inline] > [ ] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670 > [ ] memdup_user+0x26/0xa0 /mm/util.c:165 > [ ] strndup_user+0x62/0x80 /mm/util.c:224 > [ ] dma_buf_set_name /drivers/dma-buf/dma-buf.c:331 > [inline] > [ ] dma_buf_ioctl+0x60/0x1b0 > /drivers/dma-buf/dma-buf.c:391 > [ ] vfs_ioctl /fs/ioctl.c:46 [inline] > [ ] file_ioctl /fs/ioctl.c:509 [inline] > [ ] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696 > [ ] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713 > [ ] __do_sys_ioctl /fs/ioctl.c:720 [inline] > [ ] __se_sys_ioctl /fs/ioctl.c:718 [inline] > [ ] __x64_sys_ioctl+0x1e/0x30 /fs/ioctl.c:718 > [<5a8e86d5>] do_syscall_64+0x76/0x1a0 > /arch/x86/entry/common.c:296 > [<7d83529f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x888113b044a0 (size 32): >comm "syz-executor110", pid 6895, jiffies 4294947728 (age 7.660s) >hex dump (first 32 bytes): > 00 64 6d 61 62 75 66 3a 00 00 00 00 00 00 00 00 .dmabuf: > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [ ] kmemleak_alloc_recursive > /./include/linux/kmemleak.h:43 [inline] > [ ] slab_post_alloc_hook /mm/slab.h:522 [inline] > [ ] slab_alloc /mm/slab.c:3319 [inline] > [ ] __do_kmalloc /mm/slab.c:3653 [inline] > [ ] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670 > [ ] memdup_user+0x26/0xa0 /mm/util.c:165 > [ ] strndup_user+0x62/0x80 /mm/util.c:224 > [ ] dma_buf_set_name /drivers/dma-buf/dma-buf.c:331 > [inline] > [ ] dma_buf_ioctl+0x60/0x1b0 > /drivers/dma-buf/dma-buf.c:391 > [ ] vfs_ioctl /fs/ioctl.c:46 [inline] > [ ] file_ioctl /fs/ioctl.c:509 [inline] > [ ] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696 > [ ] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713 > [ ] __do_sys_ioctl /fs/ioctl.c:720 [inline] > [ ] __se_sys_ioctl /fs/ioctl.c:718 [inline] > [ ] __x64_sys_ioctl+0x1e/0x30 /fs/ioctl.c:718 > [<5a8e86d5>] do_syscall_64+0x76/0x1a0 > /arch/x86/entry/common.c:296 > [<7d83529f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/b68e04058e6a3421%40goog
Re: [PATCH v1] backlight: lm3630a: Switch to use fwnode_property_count_uXX()
On Tue, Jul 23, 2019 at 10:34:00PM +0300, Andy Shevchenko wrote: > Use use fwnode_property_count_uXX() directly, that makes code neater. > > Signed-off-by: Andy Shevchenko Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/lm3630a_bl.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/video/backlight/lm3630a_bl.c > b/drivers/video/backlight/lm3630a_bl.c > index b04b35d007a2..2d8e8192e4e2 100644 > --- a/drivers/video/backlight/lm3630a_bl.c > +++ b/drivers/video/backlight/lm3630a_bl.c > @@ -377,8 +377,7 @@ static int lm3630a_parse_led_sources(struct fwnode_handle > *node, > u32 sources[LM3630A_NUM_SINKS]; > int ret, num_sources, i; > > - num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL, > - 0); > + num_sources = fwnode_property_count_u32(node, "led-sources"); > if (num_sources < 0) > return default_led_sources; > else if (num_sources > ARRAY_SIZE(sources)) > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value
On Fri, 2019-07-05 at 19:15 +0200, Lucas Stach wrote:
> The call site expects to get either a valid suballoc or an error
> pointer, so a NULL return will not be treated as an error. Make
> sure to always return a proper error pointer in case something goes
> wrong.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index bb4900bc1c4c..7b77992f31c4 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -48,8 +48,10 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
>
> suballoc->vaddr = dma_alloc_wc(gpu->dev, SUBALLOC_SIZE,
> &suballoc->paddr, GFP_KERNEL);
> - if (!suballoc->vaddr)
> + if (!suballoc->vaddr) {
> + ret = -ENOMEM;
> goto free_suballoc;
> + }
>
> ret = etnaviv_iommu_get_suballoc_va(gpu, suballoc->paddr,
> &suballoc->vram_node, SUBALLOC_SIZE,
> @@ -64,7 +66,7 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
> free_suballoc:
> kfree(suballoc);
>
> - return NULL;
> + return ERR_PTR(ret);
> }
>
> void etnaviv_cmdbuf_suballoc_destroy(struct etnaviv_cmdbuf_suballoc
> *suballoc)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/etnaviv: remove unused function etnaviv_gem_mapping_reference
On Fri, 2019-07-05 at 19:15 +0200, Lucas Stach wrote:
> Hasn't been used for quite a while. There is no point in keeping
> unused code around.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12
> drivers/gpu/drm/etnaviv/etnaviv_gem.h | 1 -
> 2 files changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 727bb3f5ceb2..e199a6833ff0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -235,18 +235,6 @@ etnaviv_gem_get_vram_mapping(struct etnaviv_gem_object
> *obj,
> return NULL;
> }
>
> -void etnaviv_gem_mapping_reference(struct etnaviv_vram_mapping *mapping)
> -{
> - struct etnaviv_gem_object *etnaviv_obj = mapping->object;
> -
> - drm_gem_object_get(&etnaviv_obj->base);
> -
> - mutex_lock(&etnaviv_obj->lock);
> - WARN_ON(mapping->use == 0);
> - mapping->use += 1;
> - mutex_unlock(&etnaviv_obj->lock);
> -}
> -
> void etnaviv_gem_mapping_unreference(struct etnaviv_vram_mapping *mapping)
> {
> struct etnaviv_gem_object *etnaviv_obj = mapping->object;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index 753c458497d0..d7d8a835f379 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -120,7 +120,6 @@ void etnaviv_gem_put_pages(struct etnaviv_gem_object
> *obj);
>
> struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> struct drm_gem_object *obj, struct etnaviv_gpu *gpu);
> -void etnaviv_gem_mapping_reference(struct etnaviv_vram_mapping *mapping);
> void etnaviv_gem_mapping_unreference(struct etnaviv_vram_mapping *mapping);
>
> #endif /* __ETNAVIV_GEM_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Export all GPU feature registers
Midgard/Bifrost GPUs have a bunch of feature registers providing details
of what the hardware supports. Panfrost already reads these, this patch
exports them all to user space so that the jobs created by the user space
driver can be tuned for the particular hardware implementation.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 38 +++--
drivers/gpu/drm/panfrost/panfrost_gpu.c| 2 ++
include/uapi/drm/panfrost_drm.h| 39 ++
4 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 83cc01cafde1..ea5948ff3647 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -43,6 +43,7 @@ struct panfrost_features {
u32 js_features[16];
u32 nr_core_groups;
+ u32 thread_tls_alloc;
unsigned long hw_features[64 / BITS_PER_LONG];
unsigned long hw_issues[64 / BITS_PER_LONG];
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 85b4b51b6a0d..4b554c8d56da 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -32,10 +32,42 @@ static int panfrost_ioctl_get_param(struct drm_device
*ddev, void *data, struct
if (param->pad != 0)
return -EINVAL;
+#define PANFROST_FEATURE(name, member) \
+ case DRM_PANFROST_PARAM_ ## name: \
+ param->value = pfdev->features.member; \
+ break
+#define PANFROST_FEATURE_ARRAY(name, member, max) \
+ case DRM_PANFROST_PARAM_ ## name ## 0 ... \
+ DRM_PANFROST_PARAM_ ## name ## max: \
+ param->value = pfdev->features.member[param->param -\
+ DRM_PANFROST_PARAM_ ## name ## 0]; \
+ break
+
switch (param->param) {
- case DRM_PANFROST_PARAM_GPU_PROD_ID:
- param->value = pfdev->features.id;
- break;
+ PANFROST_FEATURE(GPU_PROD_ID, id);
+ PANFROST_FEATURE(GPU_REVISION, revision);
+ PANFROST_FEATURE(SHADER_PRESENT, shader_present);
+ PANFROST_FEATURE(TILER_PRESENT, tiler_present);
+ PANFROST_FEATURE(L2_PRESENT, l2_present);
+ PANFROST_FEATURE(STACK_PRESENT, stack_present);
+ PANFROST_FEATURE(AS_PRESENT, as_present);
+ PANFROST_FEATURE(JS_PRESENT, js_present);
+ PANFROST_FEATURE(L2_FEATURES, l2_features);
+ PANFROST_FEATURE(CORE_FEATURES, core_features);
+ PANFROST_FEATURE(TILER_FEATURES, tiler_features);
+ PANFROST_FEATURE(MEM_FEATURES, mem_features);
+ PANFROST_FEATURE(MMU_FEATURES, mmu_features);
+ PANFROST_FEATURE(THREAD_FEATURES, thread_features);
+ PANFROST_FEATURE(MAX_THREADS, max_threads);
+ PANFROST_FEATURE(THREAD_MAX_WORKGROUP_SZ,
+ thread_max_workgroup_sz);
+ PANFROST_FEATURE(THREAD_MAX_BARRIER_SZ,
+ thread_max_barrier_sz);
+ PANFROST_FEATURE(COHERENCY_FEATURES, coherency_features);
+ PANFROST_FEATURE_ARRAY(TEXTURE_FEATURES, texture_features, 3);
+ PANFROST_FEATURE_ARRAY(JS_FEATURES, js_features, 15);
+ PANFROST_FEATURE(NR_CORE_GROUPS, nr_core_groups);
+ PANFROST_FEATURE(THREAD_TLS_ALLOC, thread_tls_alloc);
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 20ab333fc925..f67ed925c0ef 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -232,6 +232,8 @@ static void panfrost_gpu_init_features(struct
panfrost_device *pfdev)
pfdev->features.stack_present = gpu_read(pfdev, GPU_STACK_PRESENT_LO);
pfdev->features.stack_present |= (u64)gpu_read(pfdev,
GPU_STACK_PRESENT_HI) << 32;
+ pfdev->features.thread_tls_alloc = gpu_read(pfdev,
GPU_THREAD_TLS_ALLOC);
+
gpu_id = gpu_read(pfdev, GPU_ID);
pfdev->features.revision = gpu_id & 0x;
pfdev->features.id = gpu_id >> 16;
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index b5d370638846..cb577fb96b38 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -127,6 +127,45 @@ struct drm_panfrost_mmap_bo {
enum drm_panfrost_param {
DRM_PANFROST_PARAM_GPU_PROD_ID,
+ DRM_PANFROST_PARAM_GPU_REVISION,
+ DRM_PANFROST_PARAM_SHADER_PRESENT,
+ DRM_PANFROST_PARAM_TILER_PRESENT,
+ DRM_PANFROST_PARAM_L2_PRESENT,
+
RE: [PATCH v3] drm/tegra: sor: Enable HDA interrupts at plug-in
Thanks very much for the review, Dmitry!
-Original Message-
From: Dmitry Osipenko
Sent: Wednesday, July 24, 2019 2:58 PM
To: Viswanath L ; thierry.red...@gmail.com; Jonathan
Hunter
Cc: airl...@linux.ie; dan...@ffwll.ch; dri-devel@lists.freedesktop.org;
linux-te...@vger.kernel.org; linux-ker...@vger.kernel.org;
sta...@vger.kernel.org
Subject: Re: [PATCH v3] drm/tegra: sor: Enable HDA interrupts at plug-in
23.07.2019 15:40, Viswanath L пишет:
> HDMI plugout calls runtime suspend, which clears interrupt registers
> and causes audio functionality to break on subsequent plug-in; setting
> interrupt registers in sor_audio_prepare() solves the issue.
>
> Signed-off-by: Viswanath L
Yours signed-off-by always should be the last line of the commit's message
because the text below it belongs to a person who applies this patch, Thierry
in this case. This is not a big deal at all and Thierry could make a fixup
while applying the patch if will deem that as necessary.
Secondly, there is no need to add "sta...@vger.kernel.org" to the email's
recipients because the patch will flow into stable kernel versions from the
mainline once it will get applied. That happens based on the stable tag
presence, hence it's enough to add the 'Cc' tag to the commit's message in
order to get patch backported.
Lastly, next time please add everyone to the email's recipients whom you're
expecting to get a reply. Otherwise there is a chance that patch will be left
unnoticed.
Everything else looks good to me, thanks!
Reviewed-by: Dmitry Osipenko
> Fixes: 8e2988a76c26 ("drm/tegra: sor: Support for audio over HDMI")
> Cc:
> ---
> drivers/gpu/drm/tegra/sor.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 5be5a08..0470cfe 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -2164,6 +2164,15 @@ static void tegra_sor_audio_prepare(struct
> tegra_sor *sor)
>
> value = SOR_AUDIO_HDA_PRESENSE_ELDV | SOR_AUDIO_HDA_PRESENSE_PD;
> tegra_sor_writel(sor, value, SOR_AUDIO_HDA_PRESENSE);
> +
> + /*
> + * Enable and unmask the HDA codec SCRATCH0 register interrupt. This
> + * is used for interoperability between the HDA codec driver and the
> + * HDMI/DP driver.
> + */
> + value = SOR_INT_CODEC_SCRATCH1 | SOR_INT_CODEC_SCRATCH0;
> + tegra_sor_writel(sor, value, SOR_INT_ENABLE);
> + tegra_sor_writel(sor, value, SOR_INT_MASK);
> }
>
> static void tegra_sor_audio_unprepare(struct tegra_sor *sor) @@
> -2913,15 +2922,6 @@ static int tegra_sor_init(struct host1x_client *client)
> if (err < 0)
> return err;
>
> - /*
> - * Enable and unmask the HDA codec SCRATCH0 register interrupt. This
> - * is used for interoperability between the HDA codec driver and the
> - * HDMI/DP driver.
> - */
> - value = SOR_INT_CODEC_SCRATCH1 | SOR_INT_CODEC_SCRATCH0;
> - tegra_sor_writel(sor, value, SOR_INT_ENABLE);
> - tegra_sor_writel(sor, value, SOR_INT_MASK);
> -
> return 0;
> }
>
>
Re: [PATCH v3] drm/tegra: sor: Enable HDA interrupts at plug-in
On 24/07/2019 10:27, Dmitry Osipenko wrote: > 23.07.2019 15:40, Viswanath L пишет: >> HDMI plugout calls runtime suspend, which clears interrupt registers >> and causes audio functionality to break on subsequent plug-in; setting >> interrupt registers in sor_audio_prepare() solves the issue. >> >> Signed-off-by: Viswanath L > > Yours signed-off-by always should be the last line of the commit's > message because the text below it belongs to a person who applies this > patch, Thierry in this case. This is not a big deal at all and Thierry > could make a fixup while applying the patch if will deem that as necessary. > > Secondly, there is no need to add "sta...@vger.kernel.org" to the > email's recipients because the patch will flow into stable kernel > versions from the mainline once it will get applied. That happens based > on the stable tag presence, hence it's enough to add the 'Cc' tag to the > commit's message in order to get patch backported. I believe 'git send-email' automatically does this. Jon -- nvpublic
Re: [PATCH v3 2/7] backlight: gpio: simplify the platform data handling
On Wed, Jul 24, 2019 at 10:25:03AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Now that the last user of platform data (sh ecovec24) defines a proper
> GPIO lookup and sets the 'default-on' device property, we can drop the
> platform_data-specific GPIO handling and unify a big chunk of code.
>
> The only field used from the platform data is now the fbdev pointer.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 64 +---
> 1 file changed, 13 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index e84f3087e29f..01262186fa1e 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -55,30 +55,6 @@ static const struct backlight_ops gpio_backlight_ops = {
> .check_fb = gpio_backlight_check_fb,
> };
>
> -static int gpio_backlight_probe_dt(struct platform_device *pdev,
> -struct gpio_backlight *gbl)
> -{
> - struct device *dev = &pdev->dev;
> - enum gpiod_flags flags;
> - int ret;
> -
> - gbl->def_value = device_property_read_bool(dev, "default-on");
> - flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> -
> - gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> - if (IS_ERR(gbl->gpiod)) {
> - ret = PTR_ERR(gbl->gpiod);
> -
> - if (ret != -EPROBE_DEFER) {
> - dev_err(dev,
> - "Error: The gpios parameter is missing or
> invalid.\n");
> - }
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> static int gpio_backlight_probe(struct platform_device *pdev)
> {
> struct gpio_backlight_platform_data *pdata =
> @@ -86,6 +62,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> + enum gpiod_flags flags;
> int ret;
>
> gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> @@ -94,35 +71,20 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
>
> gbl->dev = &pdev->dev;
>
> - if (pdev->dev.fwnode) {
> - ret = gpio_backlight_probe_dt(pdev, gbl);
> - if (ret)
> - return ret;
> - } else if (pdata) {
> - /*
> - * Legacy platform data GPIO retrieveal. Do not expand
> - * the use of this code path, currently only used by one
> - * SH board.
> - */
> - unsigned long flags = GPIOF_DIR_OUT;
> -
> + if (pdata)
> gbl->fbdev = pdata->fbdev;
> - gbl->def_value = pdata->def_value;
> - flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
> -
> - ret = devm_gpio_request_one(gbl->dev, pdata->gpio, flags,
> - pdata ? pdata->name : "backlight");
> - if (ret < 0) {
> - dev_err(&pdev->dev, "unable to request GPIO\n");
> - return ret;
> +
> + gbl->def_value = device_property_read_bool(&pdev->dev, "default-on");
> + flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> +
> + gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
> + if (IS_ERR(gbl->gpiod)) {
> + ret = PTR_ERR(gbl->gpiod);
> + if (ret != -EPROBE_DEFER) {
> + dev_err(&pdev->dev,
> + "Error: The gpios parameter is missing or
> invalid.\n");
> }
> - gbl->gpiod = gpio_to_desc(pdata->gpio);
> - if (!gbl->gpiod)
> - return -EINVAL;
> - } else {
> - dev_err(&pdev->dev,
> - "failed to find platform data or device tree node.\n");
> - return -ENODEV;
> + return ret;
> }
>
> memset(&props, 0, sizeof(props));
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/7] backlight: gpio: remove dev from struct gpio_backlight
On Wed, Jul 24, 2019 at 10:25:06AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This field is unused. Remove it.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Andy Shevchenko
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index 01262186fa1e..70882556f047 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -19,9 +19,7 @@
> #include
>
> struct gpio_backlight {
> - struct device *dev;
> struct device *fbdev;
> -
> struct gpio_desc *gpiod;
> int def_value;
> };
> @@ -69,8 +67,6 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> if (gbl == NULL)
> return -ENOMEM;
>
> - gbl->dev = &pdev->dev;
> -
> if (pdata)
> gbl->fbdev = pdata->fbdev;
>
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/7] backlight: gpio: remove unused fields from platform data
On Wed, Jul 24, 2019 at 10:25:05AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Remove the platform data fields that nobody uses.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Andy Shevchenko
Reviewed-by: Daniel Thompson
> ---
> include/linux/platform_data/gpio_backlight.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/linux/platform_data/gpio_backlight.h
> b/include/linux/platform_data/gpio_backlight.h
> index 34179d600360..1a8b5b1946fe 100644
> --- a/include/linux/platform_data/gpio_backlight.h
> +++ b/include/linux/platform_data/gpio_backlight.h
> @@ -9,9 +9,6 @@ struct device;
>
> struct gpio_backlight_platform_data {
> struct device *fbdev;
> - int gpio;
> - int def_value;
> - const char *name;
> };
>
> #endif
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] backlight: gpio: remove def_value from struct gpio_backlight
On Wed, Jul 24, 2019 at 10:25:07AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This field is unused outside of probe(). There's no need to store it.
> We can make it into a local variable.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Andy Shevchenko
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index 70882556f047..cd6a75bca9cc 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -21,7 +21,6 @@
> struct gpio_backlight {
> struct device *fbdev;
> struct gpio_desc *gpiod;
> - int def_value;
> };
>
> static int gpio_backlight_update_status(struct backlight_device *bl)
> @@ -61,7 +60,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> enum gpiod_flags flags;
> - int ret;
> + int ret, def_value;
>
> gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> if (gbl == NULL)
> @@ -70,8 +69,8 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> if (pdata)
> gbl->fbdev = pdata->fbdev;
>
> - gbl->def_value = device_property_read_bool(&pdev->dev, "default-on");
> - flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> + def_value = device_property_read_bool(&pdev->dev, "default-on");
> + flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
>
> gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
> if (IS_ERR(gbl->gpiod)) {
> @@ -94,7 +93,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> return PTR_ERR(bl);
> }
>
> - bl->props.brightness = gbl->def_value;
> + bl->props.brightness = def_value;
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
On Wed, Jul 24, 2019 at 10:25:08AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Instead of dereferencing pdev each time, use a helper variable for
> the associated device pointer.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index cd6a75bca9cc..7dc4f90d926b 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -54,29 +54,29 @@ static const struct backlight_ops gpio_backlight_ops = {
>
> static int gpio_backlight_probe(struct platform_device *pdev)
> {
> - struct gpio_backlight_platform_data *pdata =
> - dev_get_platdata(&pdev->dev);
> + struct device *dev = &pdev->dev;
> + struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> enum gpiod_flags flags;
> int ret, def_value;
>
> - gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> + gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
> if (gbl == NULL)
> return -ENOMEM;
>
> if (pdata)
> gbl->fbdev = pdata->fbdev;
>
> - def_value = device_property_read_bool(&pdev->dev, "default-on");
> + def_value = device_property_read_bool(dev, "default-on");
> flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
>
> - gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
> + gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> if (IS_ERR(gbl->gpiod)) {
> ret = PTR_ERR(gbl->gpiod);
> if (ret != -EPROBE_DEFER) {
> - dev_err(&pdev->dev,
> + dev_err(dev,
> "Error: The gpios parameter is missing or
> invalid.\n");
> }
> return ret;
> @@ -85,11 +85,10 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = 1;
> - bl = devm_backlight_device_register(&pdev->dev, dev_name(&pdev->dev),
> - &pdev->dev, gbl, &gpio_backlight_ops,
> - &props);
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, gbl,
> + &gpio_backlight_ops, &props);
> if (IS_ERR(bl)) {
> - dev_err(&pdev->dev, "failed to register backlight\n");
> + dev_err(dev, "failed to register backlight\n");
> return PTR_ERR(bl);
> }
>
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fixes for mgag200 cursors
Am 23.07.19 um 10:40 schrieb Sam Ravnborg: > Hi Thomas. > > On Tue, Jul 23, 2019 at 09:54:22AM +0200, Thomas Zimmermann wrote: >> This patch set fixes a number of bugs that where introduced by the >> recent changes to mgag200's handling of cursor BOs. >> >> Thomas Zimmermann (3): >> drm/mgag200: Pin displayed cursor BO to video memory >> drm/mgag200: Set cursor scanout address to correct BO >> drm/mgag200: Don't unpin the current cursor image's buffer. > > Browsed the fixes - looks good to me. > > Acked-by: Sam Ravnborg > Thanks! -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/tegra: sor: Enable HDA interrupts at plug-in
24.07.2019 14:11, Jon Hunter пишет: > > On 24/07/2019 10:27, Dmitry Osipenko wrote: >> 23.07.2019 15:40, Viswanath L пишет: >>> HDMI plugout calls runtime suspend, which clears interrupt registers >>> and causes audio functionality to break on subsequent plug-in; setting >>> interrupt registers in sor_audio_prepare() solves the issue. >>> >>> Signed-off-by: Viswanath L >> >> Yours signed-off-by always should be the last line of the commit's >> message because the text below it belongs to a person who applies this >> patch, Thierry in this case. This is not a big deal at all and Thierry >> could make a fixup while applying the patch if will deem that as necessary. >> >> Secondly, there is no need to add "sta...@vger.kernel.org" to the >> email's recipients because the patch will flow into stable kernel >> versions from the mainline once it will get applied. That happens based >> on the stable tag presence, hence it's enough to add the 'Cc' tag to the >> commit's message in order to get patch backported. > > I believe 'git send-email' automatically does this. Indeed, completely forgot that I have '--suppress-cc=all' in my git's setup.
[PATCH 1/3] drm/vram: Provide vmap and vunmap operations for GEM VRAM objects
The pattern of temporarily pinning and kmap-ing the BO's memory is
common enough to justify helper functions that do and undo these
operations.
The implementation of vmap and vunmap for GEM VRAM helpers is
already in PRIME helpers. The patch moves the operations to separate
functions and exports them for general use.
The patch also adds a note about possible kmap counting. So far this
isn't required by drivers, but more complex use cases might make it
necessary.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 55 ++-
include/drm/drm_gem_vram_helper.h | 12 ++
2 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e0fbfb6570cf..54758e4debca 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -340,6 +340,48 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_kunmap);
+/**
+ * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
+ space
+ * @gem: The GEM VRAM object to map
+ *
+ * The vmap function pins a GEM VRAM object to it's current location, either
+ * system or video memory, and maps it's buffer into kernel address space. As
+ * pinned object cannot be reloacted, you should not permanently pin objects.
+ *
+ * Returns:
+ * The buffer's virtual address on success, or
+ * an ERR_PTR()-encoded error code otherwise.
+ */
+void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
+{
+ int ret;
+ void *base;
+
+ ret = drm_gem_vram_pin(gbo, 0);
+ if (ret)
+ return ERR_PTR(ret);
+ base = drm_gem_vram_kmap(gbo, true, NULL);
+ if (IS_ERR(base)) {
+ drm_gem_vram_unpin(gbo);
+ return base;
+ }
+ return base;
+}
+EXPORT_SYMBOL(drm_gem_vram_vmap);
+
+/**
+ * drm_gem_vram_vunmap() - Unmaps and unpins a GEM VRAM object
+ * @gem: The GEM VRAM object to unmap
+ * @vaddr: The mapping's base address
+ */
+void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, void *vaddr)
+{
+ drm_gem_vram_kunmap(gbo);
+ drm_gem_vram_unpin(gbo);
+}
+EXPORT_SYMBOL(drm_gem_vram_vunmap);
+
/**
* drm_gem_vram_fill_create_dumb() - \
Helper for implementing &struct drm_driver.dumb_create
@@ -595,17 +637,11 @@ static void drm_gem_vram_object_unpin(struct
drm_gem_object *gem)
static void *drm_gem_vram_object_vmap(struct drm_gem_object *gem)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
- int ret;
void *base;
- ret = drm_gem_vram_pin(gbo, 0);
- if (ret)
+ base = drm_gem_vram_vmap(gbo);
+ if (IS_ERR(base))
return NULL;
- base = drm_gem_vram_kmap(gbo, true, NULL);
- if (IS_ERR(base)) {
- drm_gem_vram_unpin(gbo);
- return NULL;
- }
return base;
}
@@ -620,8 +656,7 @@ static void drm_gem_vram_object_vunmap(struct
drm_gem_object *gem,
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
- drm_gem_vram_kunmap(gbo);
- drm_gem_vram_unpin(gbo);
+ drm_gem_vram_vunmap(gbo, vaddr);
}
/*
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index b41d932eb53a..5192c169cec2 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -44,6 +44,16 @@ struct drm_gem_vram_object {
struct ttm_placement placement;
struct ttm_place placements[2];
+ /* TODO: Maybe implement a map counter.
+*
+* So far, drivers based on VRAM helpers don't have overlapping
+* mapping operations. A driver temporarily maps an object and
+* unmaps it ASAP. This works well for fbdev emulation or cursors.
+*
+* If we ever have a driver with buffer objects that are mapped
+* by multiple code fragments concurrently, we may need a map
+* counter to get the mapping right.
+*/
int pin_count;
};
@@ -84,6 +94,8 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo);
void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo, bool map,
bool *is_iomem);
void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo);
+void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo);
+void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, void *vaddr);
int drm_gem_vram_fill_create_dumb(struct drm_file *file,
struct drm_device *dev,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/ast: Use drm_gem_vram_{vmap, vunmap}() to map cursor source BO
The VRAM helper's vmap interfaces provide pinning and mapping of BO
memory. This patch replaces the respective code in ast cursor handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c792362024a5..6e9434175c46 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1176,26 +1176,22 @@ static int ast_cursor_set(struct drm_crtc *crtc,
return -ENOENT;
}
gbo = drm_gem_vram_of_gem(obj);
-
- ret = drm_gem_vram_pin(gbo, 0);
- if (ret)
- goto err_drm_gem_object_put_unlocked;
- src = drm_gem_vram_kmap(gbo, true, NULL);
+ src = drm_gem_vram_vmap(gbo);
if (IS_ERR(src)) {
ret = PTR_ERR(src);
- goto err_drm_gem_vram_unpin;
+ goto err_drm_gem_object_put_unlocked;
}
dst = drm_gem_vram_kmap(drm_gem_vram_of_gem(ast->cursor_cache),
false, NULL);
if (IS_ERR(dst)) {
ret = PTR_ERR(dst);
- goto err_drm_gem_vram_kunmap;
+ goto err_drm_gem_vram_vunmap;
}
dst_gpu = drm_gem_vram_offset(drm_gem_vram_of_gem(ast->cursor_cache));
if (dst_gpu < 0) {
ret = (int)dst_gpu;
- goto err_drm_gem_vram_kunmap;
+ goto err_drm_gem_vram_vunmap;
}
dst += (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE)*ast->next_cursor;
@@ -1230,16 +1226,13 @@ static int ast_cursor_set(struct drm_crtc *crtc,
ast_show_cursor(crtc);
- drm_gem_vram_kunmap(gbo);
- drm_gem_vram_unpin(gbo);
+ drm_gem_vram_vunmap(gbo, src);
drm_gem_object_put_unlocked(obj);
return 0;
-err_drm_gem_vram_kunmap:
- drm_gem_vram_kunmap(gbo);
-err_drm_gem_vram_unpin:
- drm_gem_vram_unpin(gbo);
+err_drm_gem_vram_vunmap:
+ drm_gem_vram_vunmap(gbo, src);
err_drm_gem_object_put_unlocked:
drm_gem_object_put_unlocked(obj);
return ret;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Provide vmap/vunmap for VRAM helpers
The vmap operation is pin+kmap, as already implemented for PRIME
support. The vunmap operation is the inverse. This patch set makes
both available for drivers that use VRAM helpers, and replaces the
respective code in ast and mgag200.
Thomas Zimmermann (3):
drm/vram: Provide vmap and vunmap operations for GEM VRAM objects
drm/ast: Use drm_gem_vram_{vmap,vunmap}() to map cursor source BO
drm/mgag200: Use drm_gem_vram_{vmap,vunmap}() to map cursor source BO
drivers/gpu/drm/ast/ast_mode.c | 21 +++--
drivers/gpu/drm/drm_gem_vram_helper.c| 55 +++-
drivers/gpu/drm/mgag200/mgag200_cursor.c | 22 +++---
include/drm/drm_gem_vram_helper.h| 12 ++
4 files changed, 71 insertions(+), 39 deletions(-)
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/mgag200: Use drm_gem_vram_{vmap, vunmap}() to map cursor source BO
The VRAM helper's vmap interfaces provide pinning and mapping of BO
memory. This patch replaces the respective code in mgag200 cursor handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 289ce3e29032..89f61573a497 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -85,17 +85,12 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
if (!obj)
return -ENOENT;
gbo = drm_gem_vram_of_gem(obj);
- ret = drm_gem_vram_pin(gbo, 0);
- if (ret) {
- dev_err(&dev->pdev->dev, "failed to lock user bo\n");
- goto err_drm_gem_object_put_unlocked;
- }
- src = drm_gem_vram_kmap(gbo, true, NULL);
+ src = drm_gem_vram_vmap(gbo);
if (IS_ERR(src)) {
ret = PTR_ERR(src);
dev_err(&dev->pdev->dev,
- "failed to kmap user buffer updates\n");
- goto err_drm_gem_vram_unpin_src;
+ "failed to map user buffer updates\n");
+ goto err_drm_gem_object_put_unlocked;
}
/* Pin and map up-coming buffer to write colour indices */
@@ -103,7 +98,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
if (ret) {
dev_err(&dev->pdev->dev,
"failed to pin cursor buffer: %d\n", ret);
- goto err_drm_gem_vram_kunmap_src;
+ goto err_drm_gem_vram_vunmap;
}
dst = drm_gem_vram_kmap(pixels_next, true, NULL);
if (IS_ERR(dst)) {
@@ -213,8 +208,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
mdev->cursor.pixels_current = pixels_next;
drm_gem_vram_kunmap(pixels_next);
- drm_gem_vram_kunmap(gbo);
- drm_gem_vram_unpin(gbo);
+ drm_gem_vram_vunmap(gbo, src);
drm_gem_object_put_unlocked(obj);
return 0;
@@ -223,10 +217,8 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
drm_gem_vram_kunmap(pixels_next);
err_drm_gem_vram_unpin_dst:
drm_gem_vram_unpin(pixels_next);
-err_drm_gem_vram_kunmap_src:
- drm_gem_vram_kunmap(gbo);
-err_drm_gem_vram_unpin_src:
- drm_gem_vram_unpin(gbo);
+err_drm_gem_vram_vunmap:
+ drm_gem_vram_vunmap(gbo, src);
err_drm_gem_object_put_unlocked:
drm_gem_object_put_unlocked(obj);
return ret;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] fbcon: fix ypos over boundary issue
On Fri, Jul 12, 2019 at 03:13:36AM +, Zenghui Yu wrote: > From: Feng Tiantian > > While using "top" on a CentOS guest's VNC-client, then continuously press > "Shift+PgUp", the guest kernel will get panic! Backtrace is attached below. > We tested it on 5.2.0, and the issue remains. > > [ 66.946362] Unable to handle kernel paging request at virtual address > 0e240840 > [ 66.946363] Mem abort info: > [ 66.946364] Exception class = DABT (current EL), IL = 32 bits > [ 66.946365] SET = 0, FnV = 0 > [ 66.946366] EA = 0, S1PTW = 0 > [ 66.946367] Data abort info: > [ 66.946368] ISV = 0, ISS = 0x0047 > [ 66.946368] CM = 0, WnR = 1 > [ 66.946370] swapper pgtable: 64k pages, 48-bit VAs, pgd = 0966 > [ 66.946372] [0e240840] *pgd=00023ffe0003, > *pud=00023ffe0003, *pmd=00023ffd0003, *pte= > [ 66.946378] Internal error: Oops: 9647 [#1] SMP > [ 66.946379] Modules linked in: vfat fat crc32_ce ghash_ce sg sha2_ce > sha256_arm64 virtio_balloon virtio_net sha1_ce ip_tables ext4 mbcache jbd2 > virtio_gpu drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm > drm i2c_core virtio_scsi virtio_pci virtio_mmio virtio_ring virtio > [ 66.946403] CPU: 0 PID: 1035 Comm: top Not tainted 4.14.0-49.el7a.aarch64 > #1 > [ 66.946404] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 > [ 66.946405] task: 8001c18fdc00 task.stack: 0d4e > [ 66.946409] PC is at sys_imageblit+0x40c/0x1 [sysimgblt] > [ 66.946431] LR is at drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper] > [ 66.946433] pc : [] lr : [] pstate: > 0005 > [ 66.946433] sp : 0d4ef7f0 > [ 66.946434] x29: 0d4ef7f0 x28: 01ff > [ 66.946436] x27: 8001c1c88100 x26: 0001 > [ 66.946438] x25: 01f0 x24: 0018 > [ 66.946440] x23: x22: 0d4ef978 > [ 66.946442] x21: 0e240840 x20: > [ 66.946444] x19: 8001c98c9000 x18: f9d56670 > [ 66.946445] x17: x16: > [ 66.946447] x15: 0008 x14: 1b20202020202020 > [ 66.946449] x13: 01f0 x12: 003e > [ 66.946450] x11: 000f x10: 8001c840 > [ 66.946452] x9 : 00aa x8 : 0001 > [ 66.946454] x7 : 020b0090 x6 : 0001 > [ 66.946456] x5 : x4 : > [ 66.946457] x3 : 8001c840 x2 : 0e240840 > [ 66.946459] x1 : 01ef x0 : 0007 > [ 66.946461] Process top (pid: 1035, stack limit = 0x0d4e) > [ 66.946462] Call trace: > [ 66.946464] Exception stack(0x0d4ef6b0 to 0x0d4ef7f0) > [ 66.946465] f6a0: 0007 > 01ef > [ 66.946467] f6c0: 0e240840 8001c840 > > [ 66.946468] f6e0: 0001 020b0090 0001 > 00aa > [ 66.946470] f700: 8001c840 000f 003e > 01f0 > [ 66.946471] f720: 1b20202020202020 0008 > > [ 66.946472] f740: f9d56670 8001c98c9000 > 0e240840 > [ 66.946474] f760: 0d4ef978 0018 > 01f0 > [ 66.946475] f780: 0001 8001c1c88100 01ff > 0d4ef7f0 > [ 66.946476] f7a0: 02202e74 0d4ef7f0 020a040c > 0005 > [ 66.946478] f7c0: 0d4ef7e0 080ea614 0001 > 08152f08 > [ 66.946479] f7e0: 0d4ef7f0 020a040c > [ 66.946481] [] sys_imageblit+0x40c/0x1 [sysimgblt] > [ 66.946501] [] drm_fb_helper_sys_imageblit+0x28/0x4c > [drm_kms_helper] > [ 66.946510] [] virtio_gpu_3d_imageblit+0x2c/0x78 > [virtio_gpu] > [ 66.946515] [] bit_putcs+0x288/0x49c > [ 66.946517] [] fbcon_putcs+0x114/0x148 > [ 66.946519] [] do_update_region+0x118/0x19c > [ 66.946521] [] do_con_trol+0x114c/0x1314 > [ 66.946523] [] do_con_write.part.22+0x1d8/0x890 > [ 66.946525] [] con_write+0x84/0x8c > [ 66.946527] [] n_tty_write+0x19c/0x408 > [ 66.946529] [] tty_write+0x150/0x270 > [ 66.946532] [] __vfs_write+0x58/0x180 > [ 66.946534] [] vfs_write+0xa8/0x1a0 > [ 66.946536] [] SyS_write+0x60/0xc0 > [ 66.946537] Exception stack(0x0d4efec0 to 0x0d4f) > [ 66.946539] fec0: 0001 00457958 0800 > > [ 66.946540] fee0: fbad2885 0bd0 8556add4 > > [ 66.946541] ff00: 0040 00434a88 > 0012 > [ 66.946543] ff20: 0001 f9d564f0 f9d564a0 > 0008 > [ 66.946544] ff40: 8
Re: [PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 7/24/19 2:59 AM, Christoph Hellwig wrote: On Mon, Jul 22, 2019 at 10:04:06PM -0700, John Stultz wrote: Apologies, I'm not sure I'm understanding your suggestion here. dma_alloc_contiguous() does have some interesting optimizations (avoiding allocating single page from cma), though its focus on default area vs specific device area doesn't quite match up the usage model for dma heaps. Instead of allocating memory for a single device, we want to be able to allow userland, for a given usage mode, to be able to allocate a dmabuf from a specific heap of memory which will satisfy the usage mode for that buffer pipeline (across multiple devices). Now, indeed, the system and cma heaps in this patchset are a bit simple/trivial (though useful with my devices that require contiguous buffers for the display driver), but more complex ION heaps have traditionally stayed out of tree in vendor code, in many cases making incompatible tweaks to the ION core dmabuf exporter logic. So what would the more complicated heaps be? That's why dmabuf heaps is trying to destage ION in a way that allows heaps to implement their exporter logic themselves, so we can start pulling those more complicated heaps out of their vendor hidey-holes and get some proper upstream review. But I suspect I just am confused as to what your suggesting. Maybe could you expand a bit? Apologies for being a bit dense. My suggestion is to merge the system and CMA heaps. CMA (at least the system-wide CMA area) is really just an optimization to get large contigous regions more easily. We should make use of it as transparent as possible, just like we do in the DMA code. It's not just an optimization for Ion though. Ion was designed to let the callers choose between system and multiple CMA heaps. On other systems there may be multiple CMA regions dedicated to a specific purpose or placed at a specific address. The callers need to be able to choose exactly whether they want a particular CMA region or discontiguous regions. Thanks, Laura ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm/tinydrm: Move mipi_dbi
On Tue, Jul 23, 2019 at 03:41:11PM +0200, Noralf Trønnes wrote: > Den 23.07.2019 09.10, skrev Daniel Vetter: > > On Mon, Jul 22, 2019 at 11:06:15AM -0700, Eric Anholt wrote: > >> Noralf Trønnes writes: > >> > >>> This series ticks off the last tinydrm todo entry and moves out mipi_dbi > >>> to be a core helper. > >>> > >>> It splits struct mipi_dbi into an interface part and a display pipeline > >>> part (upload framebuffer over SPI). I also took the opportunity to > >>> rename the ambiguous 'mipi' variable name to 'dbi'. This lines up with > >>> the use of the 'dsi' variable name in the MIPI DSI helper. > >>> > >>> Note: > >>> This depends on series: drm/tinydrm: Remove tinydrm.ko > >>> > >>> Series is also available here: > >>> https://github.com/notro/linux/tree/move_mipi_dbi > >> > >> Congratulations on making it to this stage. This looks like a fine > >> conclusion to tinydrm. > >> > >> Acked-by: Eric Anholt > > > > Yeah let me heap on the congrats too, this has ben a long but really > > impressive journey to watch! > > Looking back it's suprising to me that I continued to work on this. > After Linus took a dump on tinydrm I wasn't much interested in doing any > further work on Linux, there are lots of other interesting projects to > work on. Then you cc'ed me on a patch telling me that someone was using > the simple display helper I made, and before I knew it I was knee deep > in refactoring work. Historical aside: That dump from Linus was one of the reasons we finally decided to enact a code of conduct and enforce it against everyone. We just can't afford to lose great people just because some big guns have a hard time controlling their temper. Aside from it's just nicer to work together with some respect. > One big take away for me has been how much better my code becomes after > going through a review process. Some times, looking back, I wonder - did > I actually write that nice piece of code? And the real answer I guess is > that I did the typing and often had the idea, but many times the fleshed > out solution was not something that I came up with. For me great review (both for as reviewer and as author) is when everyone learns something. Personally I definitely learned a lot from all the small driver work that's been going on the past few years - completely different world compared to drivers mearsured in 100kloc units :-) Cheers, Daniel -- 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 2/7] backlight: gpio: simplify the platform data handling
On Wed, Jul 24, 2019 at 10:25:03AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Now that the last user of platform data (sh ecovec24) defines a proper
> GPIO lookup and sets the 'default-on' device property, we can drop the
> platform_data-specific GPIO handling and unify a big chunk of code.
>
> The only field used from the platform data is now the fbdev pointer.
Reviewed-by: Andy Shevchenko
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/video/backlight/gpio_backlight.c | 64 +---
> 1 file changed, 13 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index e84f3087e29f..01262186fa1e 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -55,30 +55,6 @@ static const struct backlight_ops gpio_backlight_ops = {
> .check_fb = gpio_backlight_check_fb,
> };
>
> -static int gpio_backlight_probe_dt(struct platform_device *pdev,
> -struct gpio_backlight *gbl)
> -{
> - struct device *dev = &pdev->dev;
> - enum gpiod_flags flags;
> - int ret;
> -
> - gbl->def_value = device_property_read_bool(dev, "default-on");
> - flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> -
> - gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> - if (IS_ERR(gbl->gpiod)) {
> - ret = PTR_ERR(gbl->gpiod);
> -
> - if (ret != -EPROBE_DEFER) {
> - dev_err(dev,
> - "Error: The gpios parameter is missing or
> invalid.\n");
> - }
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> static int gpio_backlight_probe(struct platform_device *pdev)
> {
> struct gpio_backlight_platform_data *pdata =
> @@ -86,6 +62,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> + enum gpiod_flags flags;
> int ret;
>
> gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> @@ -94,35 +71,20 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
>
> gbl->dev = &pdev->dev;
>
> - if (pdev->dev.fwnode) {
> - ret = gpio_backlight_probe_dt(pdev, gbl);
> - if (ret)
> - return ret;
> - } else if (pdata) {
> - /*
> - * Legacy platform data GPIO retrieveal. Do not expand
> - * the use of this code path, currently only used by one
> - * SH board.
> - */
> - unsigned long flags = GPIOF_DIR_OUT;
> -
> + if (pdata)
> gbl->fbdev = pdata->fbdev;
> - gbl->def_value = pdata->def_value;
> - flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
> -
> - ret = devm_gpio_request_one(gbl->dev, pdata->gpio, flags,
> - pdata ? pdata->name : "backlight");
> - if (ret < 0) {
> - dev_err(&pdev->dev, "unable to request GPIO\n");
> - return ret;
> +
> + gbl->def_value = device_property_read_bool(&pdev->dev, "default-on");
> + flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> +
> + gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
> + if (IS_ERR(gbl->gpiod)) {
> + ret = PTR_ERR(gbl->gpiod);
> + if (ret != -EPROBE_DEFER) {
> + dev_err(&pdev->dev,
> + "Error: The gpios parameter is missing or
> invalid.\n");
> }
> - gbl->gpiod = gpio_to_desc(pdata->gpio);
> - if (!gbl->gpiod)
> - return -EINVAL;
> - } else {
> - dev_err(&pdev->dev,
> - "failed to find platform data or device tree node.\n");
> - return -ENODEV;
> + return ret;
> }
>
> memset(&props, 0, sizeof(props));
> --
> 2.21.0
>
--
With Best Regards,
Andy Shevchenko
Re: OLED panel brightness support
On Tue, Jul 23, 2019 at 06:46:55PM +0800, Kai-Heng Feng wrote: > Hi, > > Currently, OLED panel brightness [1] is not supported. > We have a similar Dell system that also affect by lack of OLED brightness > support. > > I’ve investigated both kernel and user space but I haven’t found a good > general solution yet. > Dell systems use EDID descriptor 4 as Dell specific descriptor, which > reports its panel type and we can know it’s an OLED panel or not. > > My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to > let userspace like clutter [3] to control the brightness. > However other DEs may need to implement their own OLED brightness support > which isn’t ideal. > > So I’d like to know if there’s any good way to support OLED brightness in > good old backlight sysfs, to let userspace keep to the current interface. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=97883 > [2] https://pastebin.ubuntu.com/p/QYrRBppVT9/ > [3] > https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-brightness-contrast-effect.c#L559 I think the Most Proper Solution would be to integrate the backlight support into drm, by adding the backlight knobs as kms properties to the correct connector. This would fix a whole bag of issue: - no more ill-defined magic for userspace to find the right backlight - we could have well-defined semantics what happens with the backlight across a kms modeset - issues like this could be solved with a small helper and a bit of code in the kernel (there's also other DDC knobs to control backlight, which we also don't really expose in a consistent way). Downside is how to roll this out in a backward compatible way, without breaking the world: - fbcon/fbdev needs to be taught to not do it's own backlight wrangling for kms drivers which handle backlight natively - we might need an opt-in magic for this, if it turns out that the kms driver handling the backlight breaks stuff - userspace ofc needs to fall back to its current pile of hacks if the backlight stuff isn't supported natively. Adding more ill-defined sysfs files, or more magice ordering rules, or anything else like that doesn't sound too appealing. -Daniel -- 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] MAINTAINERS: handle fbdev changes through drm-misc tree
On Tue, Jul 23, 2019 at 04:33:27PM +0200, Bartlomiej Zolnierkiewicz wrote: > fbdev patches will now go to upstream through drm-misc tree (IOW > starting with v5.4 merge window fbdev changes will be included in > DRM pull request) for improved maintainership and better integration > testing. Update MAINTAINERS file accordingly. > > Cc: Daniel Vetter > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/MAINTAINERS > === > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6389,7 +6389,7 @@ FRAMEBUFFER LAYER > M: Bartlomiej Zolnierkiewicz > L: dri-devel@lists.freedesktop.org > L: linux-fb...@vger.kernel.org > -T: git git://github.com/bzolnier/linux.git > +T: git git://anongit.freedesktop.org/drm/drm-misc > Q: http://patchwork.kernel.org/project/linux-fbdev/list/ > S: Maintained > F: Documentation/fb/ Acked-by: Daniel Vetter -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #13 from rol...@rptd.ch --- I checked out the 18.2 branch which I assume should work (if the theory is correct). Modifying files won't work with bisecting, right? -- 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 1/3] drm/vram: Provide vmap and vunmap operations for GEM VRAM objects
On Wed, Jul 24, 2019 at 1:30 PM Thomas Zimmermann wrote:
>
> The pattern of temporarily pinning and kmap-ing the BO's memory is
> common enough to justify helper functions that do and undo these
> operations.
>
> The implementation of vmap and vunmap for GEM VRAM helpers is
> already in PRIME helpers. The patch moves the operations to separate
> functions and exports them for general use.
>
> The patch also adds a note about possible kmap counting. So far this
> isn't required by drivers, but more complex use cases might make it
> necessary.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 55 ++-
> include/drm/drm_gem_vram_helper.h | 12 ++
> 2 files changed, 57 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index e0fbfb6570cf..54758e4debca 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -340,6 +340,48 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_kunmap);
>
> +/**
> + * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
> + space
> + * @gem: The GEM VRAM object to map
variable names need to match, kernel-doc should be complaining here.
> + *
> + * The vmap function pins a GEM VRAM object to it's current location, either
> + * system or video memory, and maps it's buffer into kernel address space. As
> + * pinned object cannot be reloacted, you should not permanently pin objects.
Imo also good to point at the corresponding functions, i.e. reference
unmap here and in the unmap function reference the map function. And
please make sure the links work in the generated doc output.
> + *
> + * Returns:
> + * The buffer's virtual address on success, or
> + * an ERR_PTR()-encoded error code otherwise.
> + */
> +void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
> +{
> + int ret;
> + void *base;
> +
> + ret = drm_gem_vram_pin(gbo, 0);
> + if (ret)
> + return ERR_PTR(ret);
> + base = drm_gem_vram_kmap(gbo, true, NULL);
> + if (IS_ERR(base)) {
> + drm_gem_vram_unpin(gbo);
> + return base;
> + }
> + return base;
> +}
> +EXPORT_SYMBOL(drm_gem_vram_vmap);
> +
> +/**
> + * drm_gem_vram_vunmap() - Unmaps and unpins a GEM VRAM object
> + * @gem: The GEM VRAM object to unmap
> + * @vaddr: The mapping's base address
> + */
> +void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, void *vaddr)
> +{
> + drm_gem_vram_kunmap(gbo);
> + drm_gem_vram_unpin(gbo);
> +}
> +EXPORT_SYMBOL(drm_gem_vram_vunmap);
> +
> /**
> * drm_gem_vram_fill_create_dumb() - \
> Helper for implementing &struct drm_driver.dumb_create
> @@ -595,17 +637,11 @@ static void drm_gem_vram_object_unpin(struct
> drm_gem_object *gem)
> static void *drm_gem_vram_object_vmap(struct drm_gem_object *gem)
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> - int ret;
> void *base;
>
> - ret = drm_gem_vram_pin(gbo, 0);
> - if (ret)
> + base = drm_gem_vram_vmap(gbo);
> + if (IS_ERR(base))
> return NULL;
> - base = drm_gem_vram_kmap(gbo, true, NULL);
> - if (IS_ERR(base)) {
> - drm_gem_vram_unpin(gbo);
> - return NULL;
> - }
> return base;
> }
>
> @@ -620,8 +656,7 @@ static void drm_gem_vram_object_vunmap(struct
> drm_gem_object *gem,
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
>
> - drm_gem_vram_kunmap(gbo);
> - drm_gem_vram_unpin(gbo);
> + drm_gem_vram_vunmap(gbo, vaddr);
> }
>
> /*
> diff --git a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> index b41d932eb53a..5192c169cec2 100644
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -44,6 +44,16 @@ struct drm_gem_vram_object {
> struct ttm_placement placement;
> struct ttm_place placements[2];
>
> + /* TODO: Maybe implement a map counter.
Kerneldoc is missing here. You can use the inline style so that the
todo comment here is still included.
-Daniel
> +*
> +* So far, drivers based on VRAM helpers don't have overlapping
> +* mapping operations. A driver temporarily maps an object and
> +* unmaps it ASAP. This works well for fbdev emulation or cursors.
> +*
> +* If we ever have a driver with buffer objects that are mapped
> +* by multiple code fragments concurrently, we may need a map
> +* counter to get the mapping right.
> +*/
> int pin_count;
> };
>
> @@ -84,6 +94,8 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo);
> void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo, bool map,
> bool *is_iomem);
> void
Re: [PATCH v2 1/8] drm/etnaviv: simplify unbind checks
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> Remember if the GPU has been sucessfully initialized. Only in that case
> do we need to clean up various structures in the unbind path. If the
> GPU hasn't been sucessfully initialized all the cleanups should happen
> in the failure paths of the init function.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20 +++-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
> 2 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 4822549500ee..e84a0ed904aa 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -799,17 +799,16 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
> pm_runtime_mark_last_busy(gpu->dev);
> pm_runtime_put_autosuspend(gpu->dev);
>
> + gpu->initialized = true;
> +
> return 0;
>
> free_buffer:
> etnaviv_cmdbuf_free(&gpu->buffer);
> - gpu->buffer.suballoc = NULL;
> destroy_suballoc:
> etnaviv_cmdbuf_suballoc_destroy(gpu->cmdbuf_suballoc);
> - gpu->cmdbuf_suballoc = NULL;
> destroy_iommu:
> etnaviv_iommu_destroy(gpu->mmu);
> - gpu->mmu = NULL;
> fail:
> pm_runtime_mark_last_busy(gpu->dev);
> pm_runtime_put_autosuspend(gpu->dev);
> @@ -1521,7 +1520,7 @@ int etnaviv_gpu_wait_idle(struct etnaviv_gpu *gpu,
> unsigned int timeout_ms)
>
> static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu *gpu)
> {
> - if (gpu->buffer.suballoc) {
> + if (gpu->initialized) {
> /* Replace the last WAIT with END */
> mutex_lock(&gpu->lock);
> etnaviv_buffer_end(gpu);
> @@ -1680,19 +1679,14 @@ static void etnaviv_gpu_unbind(struct device *dev,
> struct device *master,
> etnaviv_gpu_hw_suspend(gpu);
> #endif
>
> - if (gpu->buffer.suballoc)
> + if (gpu->initialized) {
> etnaviv_cmdbuf_free(&gpu->buffer);
> -
> - if (gpu->cmdbuf_suballoc) {
> etnaviv_cmdbuf_suballoc_destroy(gpu->cmdbuf_suballoc);
> - gpu->cmdbuf_suballoc = NULL;
> - }
> -
> - if (gpu->mmu) {
> etnaviv_iommu_destroy(gpu->mmu);
> - gpu->mmu = NULL;
> + gpu->initialized = false;
> }
>
> +
Superfluous whitespace, apart from that
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] backlight: gpio: remove dev from struct gpio_backlight
From: Bartosz Golaszewski
This field is unused. Remove it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 01262186fa1e..70882556f047 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -19,9 +19,7 @@
#include
struct gpio_backlight {
- struct device *dev;
struct device *fbdev;
-
struct gpio_desc *gpiod;
int def_value;
};
@@ -69,8 +67,6 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (gbl == NULL)
return -ENOMEM;
- gbl->dev = &pdev->dev;
-
if (pdata)
gbl->fbdev = pdata->fbdev;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] backlight: gpio: simplify the driver
From: Bartosz Golaszewski While working on my other series related to gpio-backlight[1] I noticed that we could simplify the driver if we made the only user of platform data use GPIO lookups and device properties. This series tries to do that. The first patch adds all necessary data structures to ecovec24. Patch 2/7 unifies much of the code for both pdata and non-pdata cases. Patches 3-4/7 remove unused platform data fields. Last three patches contain additional improvements for the GPIO backlight driver while we're already modifying it. I don't have access to this HW but hopefully this works. Only compile tested. [1] https://lkml.org/lkml/2019/6/25/900 v1 -> v2: - rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy - added additional two patches with minor improvements v2 -> v3: - in patch 7/7: used initializers to set values for pdata and dev local vars Bartosz Golaszewski (7): sh: ecovec24: add additional properties to the backlight device backlight: gpio: simplify the platform data handling sh: ecovec24: don't set unused fields in platform data backlight: gpio: remove unused fields from platform data backlight: gpio: remove dev from struct gpio_backlight backlight: gpio: remove def_value from struct gpio_backlight backlight: gpio: use a helper variable for &pdev->dev arch/sh/boards/mach-ecovec24/setup.c | 33 ++-- drivers/video/backlight/gpio_backlight.c | 82 +--- include/linux/platform_data/gpio_backlight.h | 3 - 3 files changed, 44 insertions(+), 74 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] backlight: gpio: remove unused fields from platform data
From: Bartosz Golaszewski
Remove the platform data fields that nobody uses.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
---
include/linux/platform_data/gpio_backlight.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/platform_data/gpio_backlight.h
b/include/linux/platform_data/gpio_backlight.h
index 34179d600360..1a8b5b1946fe 100644
--- a/include/linux/platform_data/gpio_backlight.h
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -9,9 +9,6 @@ struct device;
struct gpio_backlight_platform_data {
struct device *fbdev;
- int gpio;
- int def_value;
- const char *name;
};
#endif
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] modetest: Add a new "-r" option to set a default mode
On Monday, 22 July 2019 18:08:23 CEST Ezequiel Garcia wrote:
> This option finds the first connected connector and then
> sets its preferred mode on it.
>
> Set this option to be set when no mode or plane is set
> explicitily. This allows to quickly test, in cases where
> one just needs something displayed.
>
> Signed-off-by: Ezequiel Garcia
> ---
> tests/modetest/modetest.c | 81 ---
> 1 file changed, 75 insertions(+), 6 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 5e628127a130..6042aaae7cca 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -901,7 +901,9 @@ static int pipe_find_crtc_and_mode(struct device *dev,
> struct pipe_arg *pipe) drmModeModeInfo *mode = NULL;
> int i;
>
> - pipe->mode = NULL;
> + /* If set_preferred is used, a mode is already set. */
> + if (pipe->mode)
> + goto find_crtc;
>
> for (i = 0; i < (int)pipe->num_cons; i++) {
> mode = connector_find_mode(dev, pipe->con_ids[i],
> @@ -913,7 +915,9 @@ static int pipe_find_crtc_and_mode(struct device *dev,
> struct pipe_arg *pipe) return -EINVAL;
> }
> }
> + pipe->mode = mode;
>
> +find_crtc:
> /* If the CRTC ID was specified, get the corresponding CRTC.
Otherwise
>* locate a CRTC that can be attached to all the connectors.
>*/
> @@ -935,7 +939,6 @@ static int pipe_find_crtc_and_mode(struct device *dev,
> struct pipe_arg *pipe) return -EINVAL;
> }
>
> - pipe->mode = mode;
> pipe->crtc->mode = mode;
>
> return 0;
> @@ -1813,7 +1816,7 @@ static void parse_fill_patterns(char *arg)
>
> static void usage(char *name)
> {
> - fprintf(stderr, "usage: %s [-acDdefMPpsCvw]\n", name);
> + fprintf(stderr, "usage: %s [-acDdefMPpsCvrw]\n", name);
>
> fprintf(stderr, "\n Query options:\n\n");
> fprintf(stderr, "\t-c\tlist connectors\n");
> @@ -1826,6 +1829,7 @@ static void usage(char *name)
> fprintf(stderr, "\t-s
> [,][@]:[-][@]\
> tset a mode\n"); fprintf(stderr, "\t-C\ttest hw cursor\n");
> fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
> + fprintf(stderr, "\t-r\tset the preferred mode\n");
> fprintf(stderr, "\t-w ::\tset
property\n");
> fprintf(stderr, "\t-a \tuse atomic API\n");
> fprintf(stderr, "\t-F pattern1,pattern2\tspecify fill
patterns\n");
> @@ -1874,6 +1878,9 @@ static int pipe_resolve_connectors(struct device *dev,
> struct pipe_arg *pipe) char *endp;
>
> for (i = 0; i < pipe->num_cons; i++) {
> + /* If set_preferred is used, the connector is already
resolved. */
> + if (pipe->con_ids[i])
> + continue;
> id = strtoul(pipe->cons[i], &endp, 10);
> if (endp == pipe->cons[i]) {
> connector = get_connector_by_name(dev, pipe-
>cons[i]);
> @@ -1885,14 +1892,62 @@ static int pipe_resolve_connectors(struct device
> *dev, struct pipe_arg *pipe)
>
> id = connector->connector_id;
> }
> -
> pipe->con_ids[i] = id;
> }
>
> return 0;
> }
>
> -static char optstr[] = "acdD:efF:M:P:ps:Cvw:";
> +static char optstr[] = "acdD:efF:M:P:ps:Cvrw:";
> +
> +static int pipe_find_preferred(struct device *dev, struct pipe_arg *pipe)
> +{
> + drmModeRes *res = dev->resources->res;
> + drmModeConnector *con = NULL;
> + char *con_str;
> + int i;
> +
> + for (i = 0; i < res->count_connectors; i++) {
> + con = drmModeGetConnector(dev->fd, res->connectors[i]);
> + if (con->connection == DRM_MODE_CONNECTED)
> + break;
> + drmModeFreeConnector(con);
> + con = NULL;
> + }
> +
> + if (!con) {
> + printf("no connected connector!\n");
> + return -1;
> + }
> +
> + con_str = malloc(8);
> + sprintf(con_str, "%d", con->connector_id);
> + strcpy(pipe->format_str, "XR24");
> + pipe->fourcc = util_format_fourcc(pipe->format_str);
> + pipe->num_cons = 1;
> + pipe->con_ids = calloc(1, sizeof(*pipe->con_ids));
> + pipe->cons = calloc(1, sizeof(*pipe->cons));
> + pipe->con_ids[0] = con->connector_id;
> + pipe->cons[0] = (const char*)con_str;
> +
> + /* A CRTC possible will be chosen by pipe_find_crtc_and_mode. */
> + pipe->crtc_id = (uint32_t)-1;
> +
> + /* Return the first mode if no preferred. */
> + pipe->mode = &con->modes[0];
> + for (i = 0; i < con->count_modes; i++) {
> + drmModeModeInfo *current_mode = &con->modes[i];
> +
> + if (current_mode->type & DRM_MODE_TYPE_PREFERRED) {
> + pipe->mode = current_mode;
> + break;
> + }
> + }
> +
> + sprintf(pipe->mode_str, "%dx%d", pipe->mode->hdisplay,
> pipe->mode->vdisplay); +
> + return 0;
> +}
>
> int main(int a
dri-devel@lists.freedesktop.org
From: Bartosz Golaszewski
Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.
Signed-off-by: Bartosz Golaszewski
---
drivers/video/backlight/gpio_backlight.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index cd6a75bca9cc..7dc4f90d926b 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -54,29 +54,29 @@ static const struct backlight_ops gpio_backlight_ops = {
static int gpio_backlight_probe(struct platform_device *pdev)
{
- struct gpio_backlight_platform_data *pdata =
- dev_get_platdata(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
int ret, def_value;
- gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
+ gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
if (pdata)
gbl->fbdev = pdata->fbdev;
- def_value = device_property_read_bool(&pdev->dev, "default-on");
+ def_value = device_property_read_bool(dev, "default-on");
flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
- gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
+ gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
if (ret != -EPROBE_DEFER) {
- dev_err(&pdev->dev,
+ dev_err(dev,
"Error: The gpios parameter is missing or
invalid.\n");
}
return ret;
@@ -85,11 +85,10 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = 1;
- bl = devm_backlight_device_register(&pdev->dev, dev_name(&pdev->dev),
- &pdev->dev, gbl, &gpio_backlight_ops,
- &props);
+ bl = devm_backlight_device_register(dev, dev_name(dev), dev, gbl,
+ &gpio_backlight_ops, &props);
if (IS_ERR(bl)) {
- dev_err(&pdev->dev, "failed to register backlight\n");
+ dev_err(dev, "failed to register backlight\n");
return PTR_ERR(bl);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] sh: ecovec24: add additional properties to the backlight device
From: Bartosz Golaszewski
Add a GPIO lookup entry and a device property for GPIO backlight to the
board file. Tie them to the platform device which is now registered using
platform_device_register_full() because of the properties. These changes
are inactive now but will be used once the gpio backlight driver is
modified.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
---
arch/sh/boards/mach-ecovec24/setup.c | 30 +++-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index f402aa741bf3..6926bb3865b9 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -371,6 +371,19 @@ static struct platform_device lcdc_device = {
},
};
+static struct gpiod_lookup_table gpio_backlight_lookup = {
+ .dev_id = "gpio-backlight.0",
+ .table = {
+ GPIO_LOOKUP("sh7724_pfc", GPIO_PTR1, NULL, GPIO_ACTIVE_HIGH),
+ { }
+ },
+};
+
+static struct property_entry gpio_backlight_props[] = {
+ PROPERTY_ENTRY_BOOL("default-on"),
+ { }
+};
+
static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = &lcdc_device.dev,
.gpio = GPIO_PTR1,
@@ -378,13 +391,15 @@ static struct gpio_backlight_platform_data
gpio_backlight_data = {
.name = "backlight",
};
-static struct platform_device gpio_backlight_device = {
+static const struct platform_device_info gpio_backlight_device_info = {
.name = "gpio-backlight",
- .dev = {
- .platform_data = &gpio_backlight_data,
- },
+ .data = &gpio_backlight_data,
+ .size_data = sizeof(gpio_backlight_data),
+ .properties = gpio_backlight_props,
};
+static struct platform_device *gpio_backlight_device;
+
/* CEU0 */
static struct ceu_platform_data ceu0_pdata = {
.num_subdevs= 2,
@@ -1006,7 +1021,6 @@ static struct platform_device *ecovec_devices[]
__initdata = {
&usb1_common_device,
&usbhs_device,
&lcdc_device,
- &gpio_backlight_device,
&keysc_device,
&cn12_power,
#if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
@@ -1464,6 +1478,12 @@ static int __init arch_setup(void)
#endif
#endif
+ gpiod_add_lookup_table(&gpio_backlight_lookup);
+ gpio_backlight_device = platform_device_register_full(
+ &gpio_backlight_device_info);
+ if (IS_ERR(gpio_backlight_device))
+ return PTR_ERR(gpio_backlight_device);
+
return platform_add_devices(ecovec_devices,
ARRAY_SIZE(ecovec_devices));
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: kernel panic: stack is corrupted in pointer
On Tue, Jul 23, 2019 at 7:26 PM John Fastabend wrote:
>
> Dmitry Vyukov wrote:
> > On Wed, Jul 17, 2019 at 10:58 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:1438cde7 Add linux-next specific files for 20190716
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1398805860
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa0
> >
> > From the repro it looks like the same bpf stack overflow bug. +John
> > We need to dup them onto some canonical report for this bug, or this
> > becomes unmanageable.
>
> Fixes in bpf tree should fix this. Hopefully, we will squash this once fixes
> percolate up.
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Cool! What is the fix?
We don't need to wait for the fix to percolate up (and then down
too!). syzbot gracefully handles when a patch is not yet present
everywhere (it happens all the time).
Btw, this was due to a stack overflow, right? Or something else?
We are trying to make KASAN configuration detect stack overflows too,
so that it does not cause havoc next time. But it turns out to be
non-trivial and our current attempt seems to fail:
https://groups.google.com/forum/#!topic/kasan-dev/IhYv7QYhLfY
> > #syz dup: kernel panic: corrupted stack end in dput
> >
> > > The bug was bisected to:
> > >
> > > commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
> > > Author: Leo Liu
> > > Date: Fri Jul 13 15:26:28 2018 +
> > >
> > > drm/amdgpu: Make sure IB tests flushed after IP resume
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=14a4620060
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=16a4620060
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=12a4620060
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+79f5f028005a77ecb...@syzkaller.appspotmail.com
> > > Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
> > > resume")
> > >
> > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> > > pointer+0x702/0x750 lib/vsprintf.c:2187
> > > Shutting down cpus with NMI
> > > Kernel Offset: disabled
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkal...@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> > > syzbot can test patches for this bug, for details see:
> > > https://goo.gl/tpsmEJ#testing-patches
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/5d37433a832d_3aba2ae4f6ec05bc3a%40john-XPS-13-9370.notmuch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
On Wed, Jul 24, 2019 at 10:25:08AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Instead of dereferencing pdev each time, use a helper variable for
> the associated device pointer.
Reviewed-by: Andy Shevchenko
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/video/backlight/gpio_backlight.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index cd6a75bca9cc..7dc4f90d926b 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -54,29 +54,29 @@ static const struct backlight_ops gpio_backlight_ops = {
>
> static int gpio_backlight_probe(struct platform_device *pdev)
> {
> - struct gpio_backlight_platform_data *pdata =
> - dev_get_platdata(&pdev->dev);
> + struct device *dev = &pdev->dev;
> + struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> enum gpiod_flags flags;
> int ret, def_value;
>
> - gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
> + gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
> if (gbl == NULL)
> return -ENOMEM;
>
> if (pdata)
> gbl->fbdev = pdata->fbdev;
>
> - def_value = device_property_read_bool(&pdev->dev, "default-on");
> + def_value = device_property_read_bool(dev, "default-on");
> flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
>
> - gbl->gpiod = devm_gpiod_get(&pdev->dev, NULL, flags);
> + gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
> if (IS_ERR(gbl->gpiod)) {
> ret = PTR_ERR(gbl->gpiod);
> if (ret != -EPROBE_DEFER) {
> - dev_err(&pdev->dev,
> + dev_err(dev,
> "Error: The gpios parameter is missing or
> invalid.\n");
> }
> return ret;
> @@ -85,11 +85,10 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = 1;
> - bl = devm_backlight_device_register(&pdev->dev, dev_name(&pdev->dev),
> - &pdev->dev, gbl, &gpio_backlight_ops,
> - &props);
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, gbl,
> + &gpio_backlight_ops, &props);
> if (IS_ERR(bl)) {
> - dev_err(&pdev->dev, "failed to register backlight\n");
> + dev_err(dev, "failed to register backlight\n");
> return PTR_ERR(bl);
> }
>
> --
> 2.21.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 0/3] RFT: PL111 DRM conversion of nspire
On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg wrote: > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote: > > So this is a cold-coded attempt to move the TI nspire over to > > using DRM. It is more or less the last user of the old fbdev > > driver so it is a noble cause and interesting usecase. > > Do we need to support arm,pl11x,tft-r0g0b0-pads before > we can obsolete fbdev stuff? No I don't think so, the only in-tree platform that was using it was the Nomadik and all it did was to switch RGB to BGR and I already handle that in the driver using the hardware feature to switch RGB and BGR around instead. Right now I just check that the pads are there, I might just remove the check. However Pawel added this binding and might be able to tell something about if there are platforms out there that really needs this. Possibly Liviu knows more. > Looked through the patches. > 1 and 3 are: > Acked-by: Sam Ravnborg Thanks! Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
On Tue, Jul 23, 2019 at 5:19 PM Fabian Vogt wrote: > I gave the series a try (virtual CX and TP so far, will do on a real CX > later): > OOPS with a nullptr deref during probe. > This diff which just moves some lines around fixes that and the LCD appears to > work properly. OK I folded this into my patch, thanks! > Once I verified the 24bit depth and clock speed config on HW as well, I can > give you my Tested-by, or would you prefer that I resubmit your series with > the > fix below? It's fine if you test it just with your patch as-is, I didn't change anything else. I would be amazed if it "just works" now. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
On Tue, Jul 23, 2019 at 11:07 PM Daniel Vetter wrote:
> On Tue, Jul 23, 2019 at 7:25 PM Adam Jackson wrote:
> >
> > On Tue, 2019-07-23 at 15:37 +0200, Linus Walleij wrote:
> > > Migrating the TI nspire calculators to use the PL111 driver for
> > > framebuffer requires grayscale support for the elder panel
> > > which uses 8bit grayscale only.
> > >
> > > DRM does not support 8bit grayscale framebuffers in memory,
> > > but by defining the bus format to be MEDIA_BUS_FMT_Y8_1X8 we
> > > can get the hardware to turn on a grayscaling feature and
> > > convert the RGB framebuffer to grayscale for us.
> >
> > What's wrong with DRM_FORMAT_R8? Yes the hardware is not really
> > "redscale", but it's still a single color channel and there's not
> > really any ambiguity.
>
> Yeah, I think with a comment or an aliasing #define to _Y8 (or both)
> this is good to go.
Is there something really wrong with just biting the bullet and do this:
/* 8 bpp grayscale */
#define DRM_FORMAT_Y8 fourcc_code('Y', '8', ' ', ' ') /* [7:0] Y */
It's quite an embarrasement for my OCD tendencies to talk about
black-and-white TV as if it was 256 Shades of Red (good title
for a novel by the way).
I don't know how these FOURCC things work, possibly new
fourcc:s can only be defined by some especially enlightened
cabal of standardization?
(It beats me how it can not already exist in that case.)
> You probably still want to expose the rgb format since too much
> userspace just assumes that xrgb works. Same reason why the
> tinydrm drivers do the sw conversion.
Yes this is what we do on PL111 now, we just run it through
the hardware grayscaler.
This hardware graciously supports reading black-white and
grayscale bitmaps with 1 (monochrome), 2, 4 and 8 bits per
pixel which would be Y1, Y2, Y4 and Y8. But we only have
hardware supporting Y8 at least on the other side so
I don't see any need for the others ATM.
I suspect the Y1 etc could be useful for people doing not
only Hercules video drivers (hah!) but also for ePaper
displays of say, some random Kindle.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFT: PL111 DRM conversion of nspire
On Wed, Jul 24, 2019 at 2:47 PM Pawel Moll wrote: > On Wed, 2019-07-24 at 13:28 +0100, Linus Walleij wrote: > > On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg wrote: > > > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote: > > > Do we need to support arm,pl11x,tft-r0g0b0-pads before > > > we can obsolete fbdev stuff? > > > > No I don't think so, the only in-tree platform that was using it was > > the Nomadik and all it did was to switch RGB to BGR and > > I already handle that in the driver using the hardware > > feature to switch RGB and BGR around instead. > > > > Right now I just check that the pads are there, I might just > > remove the check. > > > > However Pawel added this binding and might be able to tell > > something about if there are platforms out there that really > > needs this. Possibly Liviu knows more. > > It was only there so the fbdev driver could figure out the output mode. > I take that DRM "pipeline" now takes care of it, so I'd say that the > moment the fbdev driver dies, the binding can go along :-) OK I'll get rid of it. :) Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
> I cannot speak for others. In my case,U would say no. I installed windows10 in > a separate ssd, just to check there was no hardware issue of any kind. > On windows10 with latest amd drivers, I have no freezes or any other issue > running same games. Native gnu/linux game or going through wine/dxvk? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #64 from Sylvain BERTRAND --- > I cannot speak for others. In my case,U would say no. I installed windows10 in > a separate ssd, just to check there was no hardware issue of any kind. > On windows10 with latest amd drivers, I have no freezes or any other issue > running same games. Native gnu/linux game or going through wine/dxvk? -- 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
[PATCH] video: fbdev: aty: Use dev_get_drvdata
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
---
drivers/video/fbdev/aty/radeon_base.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index 6f891d82eebe..5d042653e9bd 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2217,8 +2217,7 @@ static ssize_t radeon_show_edid1(struct file *filp,
struct kobject *kobj,
char *buf, loff_t off, size_t count)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct pci_dev *pdev = to_pci_dev(dev);
-struct fb_info *info = pci_get_drvdata(pdev);
+ struct fb_info *info = dev_get_drvdata(dev);
struct radeonfb_info *rinfo = info->par;
return radeon_show_one_edid(buf, off, count, rinfo->mon1_EDID);
@@ -2230,8 +2229,7 @@ static ssize_t radeon_show_edid2(struct file *filp,
struct kobject *kobj,
char *buf, loff_t off, size_t count)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct pci_dev *pdev = to_pci_dev(dev);
-struct fb_info *info = pci_get_drvdata(pdev);
+ struct fb_info *info = dev_get_drvdata(dev);
struct radeonfb_info *rinfo = info->par;
return radeon_show_one_edid(buf, off, count, rinfo->mon2_EDID);
--
2.20.1
[PATCH 1/2] drm/pl111: Deprecate the pads from the DT binding
The pads were an earlier workaround for the internal image
pipeline in the Linux fbdev subsystem. As we move to generic
definition of display properties and drivers that no longer
need this to work, deprecate this property.
Cc: Sam Ravnborg
Cc: Pawel Moll
Cc: Liviu Dudau
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
Documentation/devicetree/bindings/display/arm,pl11x.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt
b/Documentation/devicetree/bindings/display/arm,pl11x.txt
index 572fa2773ec4..3f977e72a200 100644
--- a/Documentation/devicetree/bindings/display/arm,pl11x.txt
+++ b/Documentation/devicetree/bindings/display/arm,pl11x.txt
@@ -39,9 +39,11 @@ Required sub-nodes:
- port: describes LCD panel signals, following the common binding
for video transmitter interfaces; see
- Documentation/devicetree/bindings/media/video-interfaces.txt;
- when it is a TFT panel, the port's endpoint must define the
- following property:
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Deprecated properties:
+ The port's endbpoint subnode had this, now deprecated property
+ in the past. Drivers should be able to survive without it:
- arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
defining the way CLD pads are wired up; first value
@@ -80,7 +82,6 @@ Example:
port {
clcd_pads: endpoint {
remote-endpoint = <&clcd_panel>;
- arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/pl111: Drop special pads config check
This drops the check of the surplus "pads" configuration
from the device tree that is completely unused in the DRM
driver.
This was only used to work around limitations in the earlier
fbdev driver.
Cc: Sam Ravnborg
Cc: Pawel Moll
Cc: Liviu Dudau
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_display.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index e42fb6353623..8595a676b084 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -572,24 +572,8 @@ int pl111_display_init(struct drm_device *drm)
{
struct pl111_drm_dev_private *priv = drm->dev_private;
struct device *dev = drm->dev;
- struct device_node *endpoint;
- u32 tft_r0b0g0[3];
int ret;
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
- if (!endpoint)
- return -ENODEV;
-
- if (of_property_read_u32_array(endpoint,
- "arm,pl11x,tft-r0g0b0-pads",
- tft_r0b0g0,
- ARRAY_SIZE(tft_r0b0g0)) != 0) {
- dev_err(dev, "arm,pl11x,tft-r0g0b0-pads should be 3 ints\n");
- of_node_put(endpoint);
- return -ENOENT;
- }
- of_node_put(endpoint);
-
ret = pl111_init_clock_divider(drm);
if (ret)
return ret;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 23
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 35 ++--
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 11 +++-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 19 +--
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 70 +++-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 12 ++--
> 8 files changed, 114 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index fe0d2d67007d..6400a88cd778 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -118,7 +118,8 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
> u32 *ptr = buf->vaddr + off;
>
> dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
> - ptr, etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 -
> off);
> + ptr, etnaviv_cmdbuf_get_va(buf, &gpu->cmdbuf_mapping) +
> + off, size - len * 4 - off);
>
> print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
> ptr, len * 4, 0);
> @@ -151,7 +152,8 @@ static u32 etnaviv_buffer_reserve(struct etnaviv_gpu *gpu,
> if (buffer->user_size + cmd_dwords * sizeof(u64) > buffer->size)
> buffer->user_size = 0;
>
> - return etnaviv_cmdbuf_get_va(buffer) + buffer->user_size;
> + return etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping) +
> +buffer->user_size;
> }
>
> u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> @@ -164,8 +166,8 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> buffer->user_size = 0;
>
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> return buffer->user_size / 8;
> }
> @@ -291,8 +293,8 @@ void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu,
> unsigned int event)
>
> /* Append waitlink */
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> /*
>* Kick off the 'sync point' command by replacing the previous
> @@ -319,7 +321,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
>
> - link_target = etnaviv_cmdbuf_get_va(cmdbuf);
> + link_target = etnaviv_cmdbuf_get_va(cmdbuf, &gpu->cmdbuf_mapping);
> link_dwords = cmdbuf->size / 8;
>
> /*
> @@ -412,12 +414,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
> VIVS_GL_EVENT_FROM_PE);
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, &gpu->cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> if (drm_debug & DRM_UT_DRIVER)
> pr_info("stream link to 0x%08x @ 0x%08x %p\n",
> - return_target, etnaviv_cmdbuf_get_va(cmdbuf),
> + return_target,
> + etnaviv_cmdbuf_get_va(cmdbuf, &gpu->cmdbuf_mapping),
> cmdbuf->vaddr);
>
> if (drm_debug & DRM_UT_DRIVER) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 7b77992f31c4..8915d9d056a6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -8,6 +8,7 @@
> #include
>
> #include "etnaviv_cmdbuf.h"
> +#include "etnaviv_gem.h"
> #include "etnaviv_gpu.h"
> #include "etnaviv_mmu.h"
>
> @@ -21,10 +22,6 @@ struct etnaviv_cmdbuf_suballoc {
> void *vaddr;
> dma_addr_t paddr;
>
> - /* GPU mapping */
> - u32 iova;
> - struct drm_mm_node vram_node; /* only used on MMUv2 */
> -
> /* allocation management */
> struct mutex lock;
> DECLARE_BITMAP(granule_map, SUBALLOC_GRANULES);
> @@ -53,26 +50,31 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
> goto free_suballoc;
> }
>
> - ret = etnaviv_iommu_get_suballoc_va(gpu, suba
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote: > On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard > wrote: > > > > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote: > > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard > > > wrote: > > > > > > > There's another issue: if we introduce edp-connector we'll have to > > > > > > > specify power up delays somewhere (in dts? or in platform > > > > > > > driver?), so > > > > > > > edp-connector doesn't really solve the issue of multiple panels > > > > > > > with > > > > > > > same motherboard. > > > > > > > > > > > > And that's what that compatible is about :) > > > > > > > > > > Sorry, I fail to see how it would be different from using existing > > > > > panels infrastructure and different panels compatibles. I think Rob's > > > > > idea was to introduce generic edp-connector. > > > > > > > > Again, there's no such thing as a generic edp-connector. The spec > > > > doesn't define anything related to the power sequence for example. > > > > > > > > > If we can't make it generic then let's use panel infrastructure. > > > > > > > > Which uses a device specific compatible. Really, I'm not sure what > > > > your objection and / or argument is here. > > > > > > > > In addition, when that was brought up in the discussion, you rejected > > > > it because it was inconvenient: > > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206 > > > > > > It is inconvenient, but I don't understand how having board-specific > > > connectors fixes it. > > > > How it would not fix it? > > I think I got your idea, but yet I think it's not the best solution. > > Do I understand correctly that you're proposing to introduce > board-specific edp-connector driver that will be aware of worst case > power up delays and will control backlight and power? > > Then why not to add another board-specific panel (e.g. > "pine64,pinebook-panel") to simple-panel.c that does the same? That would be fine for me too. Thierry was against it though IIRC, and I don't recall why exactly. > > You'll have one connector, without the need to describe each and every > > panel in the device tree and rely on the EDID instead, and you'll have > > the option to power up the regulator you need. > > > > I really don't understand what's the issue here, so let's take a step > > back. What are is the issue , what are your requirements, and how > > would you like that to be described ? > > We have a device (Pinebook) that uses the same board with multiple edp > panels. So far there're pinebooks with 3 different panels: 11" with > 768p panel, 11" with 1080p panel, 14" with 768p panel. > > Currently there's no way to describe all pinebooks with a single dts. > There's a simple workaround though -- we can just specify a panel with > worst power up delays in dts and it'll work since anx6345 driver > ignores panel modes anyway and uses EDID. > > Originally I proposed to extend simple-panel driver to support generic > edp-panel but it was rejected. I still believe that it's the best > solution assuming we can specify delays in dts, since panels list is > specific to particular device and it probably can't be reused, i.e. > there's no good reason to move it into C code. > > Rob Herring proposed to introduce edp-connector. While I still believe > that it's not accurate description of hardware since it'll have to > have backlight node (backlight is actually panel property) I was OK > with this approach assuming we can store delays in dts. > > Later it evolved into board-specific edp-connector. I think you got that wrong. As far as I'm concerned, the plan was to have two compatibles: the board-specific one, and the generic one. Something like compatible = "pine64,pinebook-edp-connector", "edp-connector"; or whatever. > So far I don't understand why everyone is trying to avoid introducing > edp-panel driver that can read delays from dts. Basically, I don't > understand what's the magic behind simple-panel.c and why new panels > should be added there rather than described in dts. [1] Doesn't > explain that. So others might have different viewpoints here as well, but the major downside I see in putting those kind of values in the device tree is that at some point, someone will get it wrong, and chances are that even for the same panel, everyone will use a slightly different set of timings. And once it's wrong, then it's a mess to fix. You have to track down every DT using it, make sure it's corrected, and then every user will have to change their DT in their system. Whereas if you have just a compatible and those timings in the kernel, then the only thing required is a kernel update, which should be a pretty standard operation. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org h
Re: [PATCH 2/3] RTF: drm/panel: simple: Add TI nspire panels
Hi Sam, fixed most things, one question remain: On Tue, Jul 23, 2019 at 7:54 PM Sam Ravnborg wrote: > Furthermore I did not see any bindings for the panels. > If they indeed are missing, then please provide bindings in the yaml > format. IIUC we do not create binding documents for the simple panels, but I can do this of course, just vaguely remember that the DT people didn't want to see bindings that all look the same but instead rely on panel-common.txt Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 00/24] Associate ddc adapters with connectors
It is difficult for a user to know which of the i2c adapters is for which drm connector. This series addresses this problem. The idea is to have a symbolic link in connector's sysfs directory, e.g.: ls -l /sys/class/drm/card0-HDMI-A-1/ddc lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \ -> ../../../../soc/1388.i2c/i2c-2 The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run ddcutil: ddcutil -b 2 getvcp 0x10 VCP code 0x10 (Brightness): current value =90, max value = 100 The first patch in the series adds struct i2c_adapter pointer to struct drm_connector. If the field is used by a particular driver, then an appropriate symbolic link is created by the generic code, which is also added by this patch. Patch 2 adds a new variant of drm_connector_init(), see the changelog below. Patches 3..24 are examples of how to convert a driver to this new scheme. v1..v2: - used fixed name "ddc" for the symbolic link in order to make it easy for userspace to find the i2c adapter v2..v3: - converted as many drivers as possible. v3..v4: - added Reviewed-by for patch 01/23 - moved "ddc" field assignment to before drm_connector_init() is called in msm, vc4, sti, mgag200, ast, amdgpu, radeon - simplified the code in amdgpu and radeon at the expense of some lines exceeding 80 characters as per Alex Deucher's suggestion - added i915 v4..v5: - changed "include " to "struct i2c_adapter;" in drm_connector.h, consequently, added "include " in drm_sysfs.c. - added "drm_connector_init_with_ddc()" variant to ensure that the ddc field of drm_connector is preserved accross its invocation - accordingly changed invocations of drm_connector_init() in the touched drivers to use the new variant @Benjamin @Shawn @Thomas There were your Acked-by or Reviewed-by for some patches in v4, but now that the patches use the newly added function I'm not sure I can still include those tags without you actually confirming. Can I? Or can you please re-review? TODO: nouveau, gma500, omapdrm, panel-simple - if applicable. Other drivers are either already converted or don't mention neither "ddc" nor "i2c_adapter". Andrzej Pietrasiewicz (24): drm: Include ddc adapter pointer in struct drm_connector drm: Add drm_connector_init() variant with ddc drm/exynos: Provide ddc symlink in connector's sysfs drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory drm/tegra: Provide ddc symlink in output connector sysfs directory drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs drm/imx: imx-tve: Provide ddc symlink in connector's sysfs drm/vc4: Provide ddc symlink in connector sysfs directory drm: zte: Provide ddc symlink in hdmi connector sysfs directory drm: zte: Provide ddc symlink in vga connector sysfs directory drm/tilcdc: Provide ddc symlink in connector sysfs directory drm: sti: Provide ddc symlink in hdmi connector sysfs directory drm/mgag200: Provide ddc symlink in connector sysfs directory drm/ast: Provide ddc symlink in connector sysfs directory drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory drm/amdgpu: Provide ddc symlink in connector sysfs directory drm/radeon: Provide ddc symlink in connector sysfs directory drm/i915: Provide ddc symlink in hdmi connector sysfs directory .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 95 drivers/gpu/drm/ast/ast_mode.c| 13 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 25 ++-- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++--- drivers/gpu/drm/bridge/ti-tfp410.c| 25 ++-- drivers/gpu/drm/drm_connector.c | 19 +++ drivers/gpu/drm/drm_sysfs.c | 8 + drivers/gpu/drm/exynos/exynos_hdmi.c | 17 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +- drivers/gpu/drm/imx/imx-ldb.c | 20 +-- drivers/gpu/drm/imx/imx-tve.c | 14 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 16 +- drivers/gpu/drm/mgag200/mgag200_mode.c| 13 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +- drivers/gpu/drm/radeon/radeon_connectors.c| 141 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 23 +-- drivers/gpu/drm/rockchip/rk3066_hdmi.c| 24 +-- drivers/gpu/drm/sti/sti_hdmi.c| 6 +- drivers/gpu/drm/sun4i/sun4i_hdmi.h| 1 - drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 21 +-- drivers/gpu/drm/tegra/drm.h | 1 - d
[PATCH v5 01/24] drm: Include ddc adapter pointer in struct drm_connector
Add generic code which creates symbolic links in sysfs, pointing to ddc
interface used by a particular video output. For example:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/1388.i2c/i2c-2
This makes it easy for user to associate a display with its ddc adapter
and use e.g. ddcutil to control the chosen monitor.
This patch adds an i2c_adapter pointer to struct drm_connector. Particular
drivers can then use it instead of using their own private instance. If a
connector contains a ddc, then create a symbolic link in sysfs.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Daniel Vetter
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_sysfs.c | 8
include/drm/drm_connector.h | 11 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ad10810bc972..e962a9d45f7e 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(dev);
+ if (connector->ddc)
+ return sysfs_create_link(&connector->kdev->kobj,
+&connector->ddc->dev.kobj, "ddc");
return 0;
}
@@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
*connector)
{
if (!connector->kdev)
return;
+
+ if (connector->ddc)
+ sysfs_remove_link(&connector->kdev->kobj, "ddc");
+
DRM_DEBUG("removing \"%s\" from sysfs\n",
connector->name);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4c30d751487a..33a6fff85fdb 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -41,6 +41,7 @@ struct drm_property;
struct drm_property_blob;
struct drm_printer;
struct edid;
+struct i2c_adapter;
enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
@@ -1311,6 +1312,16 @@ struct drm_connector {
* [0]: progressive, [1]: interlaced
*/
int audio_latency[2];
+
+ /**
+* @ddc: associated ddc adapter.
+* A connector usually has its associated ddc adapter. If a driver uses
+* this field, then an appropriate symbolic link is created in connector
+* sysfs directory to make it easy for the user to tell which i2c
+* adapter is for a particular display.
+*/
+ struct i2c_adapter *ddc;
+
/**
* @null_edid_counter: track sinks that give us all zeros for the EDID.
* Needed to workaround some HW bugs where we get all 0s
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/24] drm: Add drm_connector_init() variant with ddc
Allow passing ddc adapter pointer to the init function. Even if
drm_connector_init() sometime in the future decides to e.g. memset() all
connector fields to zeros, the newly added function ensures that at its
completion the ddc member of connector is correctly set.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_connector.c | 19 +++
include/drm/drm_connector.h | 5 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 068d4b05f1be..06fbfc44fb48 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -296,6 +296,25 @@ int drm_connector_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_connector_init);
+int drm_connector_init_with_ddc(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc)
+{
+ int ret;
+
+ ret = drm_connector_init(dev, connector, funcs, connector_type);
+ if (ret)
+ return ret;
+
+ /* provide ddc symlink in sysfs */
+ connector->ddc = ddc;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_connector_init_with_ddc);
+
/**
* drm_connector_attach_edid_property - attach edid property.
* @connector: the connector
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 33a6fff85fdb..937fda9c1374 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1410,6 +1410,11 @@ int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
int connector_type);
+int drm_connector_init_with_ddc(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc);
void drm_connector_attach_edid_property(struct drm_connector *connector);
int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 03/24] drm/exynos: Provide ddc symlink in connector's sysfs
Switch to using the ddc provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bc1565f1822a..dda94de4afe0 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -125,7 +125,6 @@ struct hdmi_context {
void __iomem*regs;
void __iomem*regs_hdmiphy;
struct i2c_client *hdmiphy_port;
- struct i2c_adapter *ddc_adpt;
struct gpio_desc*hpd_gpio;
int irq;
struct regmap *pmureg;
@@ -871,10 +870,10 @@ static int hdmi_get_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!hdata->ddc_adpt)
+ if (!connector->ddc)
return -ENODEV;
- edid = drm_get_edid(connector, hdata->ddc_adpt);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid)
return -ENODEV;
@@ -940,8 +939,10 @@ static int hdmi_create_connector(struct drm_encoder
*encoder)
connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(hdata->drm_dev, connector,
- &hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(hdata->drm_dev, connector,
+ &hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ connector->ddc);
if (ret) {
DRM_DEV_ERROR(hdata->dev,
"Failed to initialize connector with drm\n");
@@ -1892,7 +1893,7 @@ static int hdmi_get_ddc_adapter(struct hdmi_context
*hdata)
return -EPROBE_DEFER;
}
- hdata->ddc_adpt = adpt;
+ hdata->connector.ddc = adpt;
return 0;
}
@@ -2044,7 +2045,7 @@ static int hdmi_probe(struct platform_device *pdev)
if (hdata->regs_hdmiphy)
iounmap(hdata->regs_hdmiphy);
err_ddc:
- put_device(&hdata->ddc_adpt->dev);
+ put_device(&hdata->connector.ddc->dev);
return ret;
}
@@ -2071,7 +2072,7 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata->regs_hdmiphy)
iounmap(hdata->regs_hdmiphy);
- put_device(&hdata->ddc_adpt->dev);
+ put_device(&hdata->connector.ddc->dev);
mutex_destroy(&hdata->mutex);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/24] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index ed344a795b4d..0f7ed664600f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -58,7 +58,6 @@ struct inno_hdmi {
struct drm_encoder encoder;
struct inno_hdmi_i2c *i2c;
- struct i2c_adapter *ddc;
unsigned int tmds_rate;
@@ -551,10 +550,10 @@ static int inno_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, hdmi->connector.ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
@@ -624,8 +623,10 @@ static int inno_hdmi_register(struct drm_device *drm,
struct inno_hdmi *hdmi)
drm_connector_helper_add(&hdmi->connector,
&inno_hdmi_connector_helper_funcs);
- drm_connector_init(drm, &hdmi->connector, &inno_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(drm, &hdmi->connector,
+ &inno_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->connector.ddc);
drm_connector_attach_encoder(&hdmi->connector, encoder);
@@ -849,10 +850,10 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
inno_hdmi_reset(hdmi);
- hdmi->ddc = inno_hdmi_i2c_adapter(hdmi);
- if (IS_ERR(hdmi->ddc)) {
- ret = PTR_ERR(hdmi->ddc);
- hdmi->ddc = NULL;
+ hdmi->connector.ddc = inno_hdmi_i2c_adapter(hdmi);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
+ hdmi->connector.ddc = NULL;
goto err_disable_clk;
}
@@ -885,7 +886,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
err_put_adapter:
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
err_disable_clk:
clk_disable_unprepare(hdmi->pclk);
return ret;
@@ -899,7 +900,7 @@ static void inno_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->pclk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 04/24] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 85fc5f01f761..06511296ceaa 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -49,7 +49,6 @@ struct rk3066_hdmi {
struct drm_encoder encoder;
struct rk3066_hdmi_i2c *i2c;
- struct i2c_adapter *ddc;
unsigned int tmdsclk;
@@ -470,10 +469,10 @@ static int rk3066_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!connector->ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
drm_connector_update_edid_property(connector, edid);
@@ -564,9 +563,10 @@ rk3066_hdmi_register(struct drm_device *drm, struct
rk3066_hdmi *hdmi)
drm_connector_helper_add(&hdmi->connector,
&rk3066_hdmi_connector_helper_funcs);
- drm_connector_init(drm, &hdmi->connector,
- &rk3066_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(drm, &hdmi->connector,
+ &rk3066_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->connector.ddc);
drm_connector_attach_encoder(&hdmi->connector, encoder);
@@ -789,10 +789,10 @@ static int rk3066_hdmi_bind(struct device *dev, struct
device *master,
/* internal hclk = hdmi_hclk / 25 */
hdmi_writeb(hdmi, HDMI_INTERNAL_CLK_DIVIDER, 25);
- hdmi->ddc = rk3066_hdmi_i2c_adapter(hdmi);
- if (IS_ERR(hdmi->ddc)) {
- ret = PTR_ERR(hdmi->ddc);
- hdmi->ddc = NULL;
+ hdmi->connector.ddc = rk3066_hdmi_i2c_adapter(hdmi);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
+ hdmi->connector.ddc = NULL;
goto err_disable_hclk;
}
@@ -824,7 +824,7 @@ static int rk3066_hdmi_bind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
err_disable_i2c:
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
err_disable_hclk:
clk_disable_unprepare(hdmi->hclk);
@@ -839,7 +839,7 @@ static void rk3066_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->hclk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 07/24] drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 -
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 21 +++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 7ad3f06c127e..1649273b1493 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -265,7 +265,6 @@ struct sun4i_hdmi {
struct clk *tmds_clk;
struct i2c_adapter *i2c;
- struct i2c_adapter *ddc_i2c;
/* Regmap fields for I2C adapter */
struct regmap_field *field_ddc_en;
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index b2df76addc75..4cc0bb232f6a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -214,7 +214,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
+ edid = drm_get_edid(connector, connector->ddc ?: hdmi->i2c);
if (!edid)
return 0;
@@ -599,11 +599,11 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
goto err_disable_mod_clk;
}
- hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
- if (IS_ERR(hdmi->ddc_i2c)) {
- ret = PTR_ERR(hdmi->ddc_i2c);
+ hdmi->connector.ddc = sun4i_hdmi_get_ddc(dev);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
if (ret == -ENODEV)
- hdmi->ddc_i2c = NULL;
+ hdmi->connector.ddc = NULL;
else
goto err_del_i2c_adapter;
}
@@ -640,9 +640,10 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
drm_connector_helper_add(&hdmi->connector,
&sun4i_hdmi_connector_helper_funcs);
- ret = drm_connector_init(drm, &hdmi->connector,
-&sun4i_hdmi_connector_funcs,
-DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(drm, &hdmi->connector,
+ &sun4i_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->connector.ddc);
if (ret) {
dev_err(dev,
"Couldn't initialise the HDMI connector\n");
@@ -664,7 +665,7 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
cec_delete_adapter(hdmi->cec_adap);
drm_encoder_cleanup(&hdmi->encoder);
err_put_ddc_i2c:
- i2c_put_adapter(hdmi->ddc_i2c);
+ i2c_put_adapter(hdmi->connector.ddc);
err_del_i2c_adapter:
i2c_del_adapter(hdmi->i2c);
err_disable_mod_clk:
@@ -685,7 +686,7 @@ static void sun4i_hdmi_unbind(struct device *dev, struct
device *master,
drm_connector_cleanup(&hdmi->connector);
drm_encoder_cleanup(&hdmi->encoder);
i2c_del_adapter(hdmi->i2c);
- i2c_put_adapter(hdmi->ddc_i2c);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->mod_clk);
clk_disable_unprepare(hdmi->bus_clk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/24] drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index ce91b61364eb..cc4ab8b070a4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -150,7 +150,6 @@ struct mtk_hdmi {
struct device *dev;
struct phy *phy;
struct device *cec_dev;
- struct i2c_adapter *ddc_adpt;
struct clk *clk[MTK_HDMI_CLK_COUNT];
struct drm_display_mode mode;
bool dvi_mode;
@@ -1217,10 +1216,10 @@ static int mtk_hdmi_conn_get_modes(struct drm_connector
*conn)
struct edid *edid;
int ret;
- if (!hdmi->ddc_adpt)
+ if (!conn->ddc)
return -ENODEV;
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
+ edid = drm_get_edid(conn, conn->ddc);
if (!edid)
return -ENODEV;
@@ -1299,9 +1298,10 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge
*bridge)
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
int ret;
- ret = drm_connector_init(bridge->encoder->dev, &hdmi->conn,
-&mtk_hdmi_connector_funcs,
-DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(bridge->encoder->dev, &hdmi->conn,
+ &mtk_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->conn.ddc);
if (ret) {
dev_err(hdmi->dev, "Failed to initialize connector: %d\n", ret);
return ret;
@@ -1513,9 +1513,9 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
}
of_node_put(remote);
- hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+ hdmi->conn.ddc = of_find_i2c_adapter_by_node(i2c_np);
of_node_put(i2c_np);
- if (!hdmi->ddc_adpt) {
+ if (!hdmi->conn.ddc) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 06/24] drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 07b4cb877d82..1f03262b8a52 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -450,8 +450,10 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi) connector = &hdmi_connector->base; - drm_connector_init(hdmi->dev, connector, &hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(hdmi->dev, connector, + &hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->i2c); drm_connector_helper_add(connector, &msm_hdmi_connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 10/24] drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/imx/imx-ldb.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index de62a4cd4827..94945dd937cc 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -57,7 +57,6 @@ struct imx_ldb_channel {
struct drm_bridge *bridge;
struct device_node *child;
- struct i2c_adapter *ddc;
int chno;
void *edid;
int edid_len;
@@ -133,8 +132,8 @@ static int imx_ldb_connector_get_modes(struct drm_connector
*connector)
return num_modes;
}
- if (!imx_ldb_ch->edid && imx_ldb_ch->ddc)
- imx_ldb_ch->edid = drm_get_edid(connector, imx_ldb_ch->ddc);
+ if (!imx_ldb_ch->edid && connector->ddc)
+ imx_ldb_ch->edid = drm_get_edid(connector, connector->ddc);
if (imx_ldb_ch->edid) {
drm_connector_update_edid_property(connector,
@@ -462,9 +461,10 @@ static int imx_ldb_register(struct drm_device *drm,
*/
drm_connector_helper_add(&imx_ldb_ch->connector,
&imx_ldb_connector_helper_funcs);
- drm_connector_init(drm, &imx_ldb_ch->connector,
- &imx_ldb_connector_funcs,
- DRM_MODE_CONNECTOR_LVDS);
+ drm_connector_init_with_ddc(drm, &imx_ldb_ch->connector,
+ &imx_ldb_connector_funcs,
+ DRM_MODE_CONNECTOR_LVDS,
+ imx_ldb_ch->connector.ddc);
drm_connector_attach_encoder(&imx_ldb_ch->connector, encoder);
}
@@ -552,15 +552,15 @@ static int imx_ldb_panel_ddc(struct device *dev,
ddc_node = of_parse_phandle(child, "ddc-i2c-bus", 0);
if (ddc_node) {
- channel->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ channel->connector.ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!channel->ddc) {
+ if (!channel->connector.ddc) {
dev_warn(dev, "failed to get ddc i2c adapter\n");
return -EPROBE_DEFER;
}
}
- if (!channel->ddc) {
+ if (!channel->connector.ddc) {
/* if no DDC available, fallback to hardcoded EDID */
dev_dbg(dev, "no ddc available\n");
@@ -727,7 +727,7 @@ static void imx_ldb_unbind(struct device *dev, struct
device *master,
drm_panel_detach(channel->panel);
kfree(channel->edid);
- i2c_put_adapter(channel->ddc);
+ i2c_put_adapter(channel->connector.ddc);
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 11/24] drm/imx: imx-tve: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/imx/imx-tve.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 649515868f86..e25df9bba393 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -111,7 +111,6 @@ struct imx_tve {
struct regmap *regmap;
struct regulator *dac_reg;
- struct i2c_adapter *ddc;
struct clk *clk;
struct clk *di_sel_clk;
struct clk_hw clk_hw_di;
@@ -220,14 +219,13 @@ static int tve_setup_vga(struct imx_tve *tve)
static int imx_tve_connector_get_modes(struct drm_connector *connector)
{
- struct imx_tve *tve = con_to_tve(connector);
struct edid *edid;
int ret = 0;
- if (!tve->ddc)
+ if (!connector->ddc)
return 0;
- edid = drm_get_edid(connector, tve->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
if (edid) {
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
@@ -484,8 +482,10 @@ static int imx_tve_register(struct drm_device *drm, struct
imx_tve *tve)
drm_connector_helper_add(&tve->connector,
&imx_tve_connector_helper_funcs);
- drm_connector_init(drm, &tve->connector, &imx_tve_connector_funcs,
- DRM_MODE_CONNECTOR_VGA);
+ drm_connector_init_with_ddc(drm, &tve->connector,
+ &imx_tve_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ tve->connector.ddc);
drm_connector_attach_encoder(&tve->connector, &tve->encoder);
@@ -553,7 +553,7 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
- tve->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ tve->connector.ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/24] drm/tegra: Provide ddc symlink in output connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/tegra/drm.h| 1 -
drivers/gpu/drm/tegra/hdmi.c | 7 ---
drivers/gpu/drm/tegra/output.c | 12 ++--
drivers/gpu/drm/tegra/sor.c| 13 +++--
4 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 86daa19fcf24..9bf72bcd3ec1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -120,7 +120,6 @@ struct tegra_output {
struct device *dev;
struct drm_panel *panel;
- struct i2c_adapter *ddc;
const struct edid *edid;
struct cec_notifier *cec;
unsigned int hpd_irq;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 334c4d7d238b..aac871847be4 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1425,9 +1425,10 @@ static int tegra_hdmi_init(struct host1x_client *client)
hdmi->output.dev = client->dev;
- drm_connector_init(drm, &hdmi->output.connector,
- &tegra_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(drm, &hdmi->output.connector,
+ &tegra_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->output.connector.ddc);
drm_connector_helper_add(&hdmi->output.connector,
&tegra_hdmi_connector_helper_funcs);
hdmi->output.connector.dpms = DRM_MODE_DPMS_OFF;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 274cb955e2e1..0b5037a29c63 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -30,8 +30,8 @@ int tegra_output_connector_get_modes(struct drm_connector
*connector)
if (output->edid)
edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
- else if (output->ddc)
- edid = drm_get_edid(connector, output->ddc);
+ else if (connector->ddc)
+ edid = drm_get_edid(connector, connector->ddc);
cec_notifier_set_phys_addr_from_edid(output->cec, edid);
drm_connector_update_edid_property(connector, edid);
@@ -111,8 +111,8 @@ int tegra_output_probe(struct tegra_output *output)
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
- output->ddc = of_find_i2c_adapter_by_node(ddc);
- if (!output->ddc) {
+ output->connector.ddc = of_find_i2c_adapter_by_node(ddc);
+ if (!output->connector.ddc) {
err = -EPROBE_DEFER;
of_node_put(ddc);
return err;
@@ -174,8 +174,8 @@ void tegra_output_remove(struct tegra_output *output)
if (output->hpd_gpio)
free_irq(output->hpd_irq, output);
- if (output->ddc)
- put_device(&output->ddc->dev);
+ if (output->connector.ddc)
+ put_device(&output->connector.ddc->dev);
}
int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 4ffe3794e6d3..63b6cfbbd17e 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -2311,7 +2311,7 @@ static void tegra_sor_hdmi_disable_scrambling(struct
tegra_sor *sor)
static void tegra_sor_hdmi_scdc_disable(struct tegra_sor *sor)
{
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
drm_scdc_set_high_tmds_clock_ratio(ddc, false);
drm_scdc_set_scrambling(ddc, false);
@@ -2339,7 +2339,7 @@ static void tegra_sor_hdmi_enable_scrambling(struct
tegra_sor *sor)
static void tegra_sor_hdmi_scdc_enable(struct tegra_sor *sor)
{
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
drm_scdc_set_high_tmds_clock_ratio(ddc, true);
drm_scdc_set_scrambling(ddc, true);
@@ -2350,7 +2350,7 @@ static void tegra_sor_hdmi_scdc_enable(struct tegra_sor
*sor)
static void tegra_sor_hdmi_scdc_work(struct work_struct *work)
{
struct tegra_sor *sor = container_of(work, struct tegra_sor, scdc.work);
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
if (!drm_scdc_get_scrambling_status(ddc)) {
DRM_DEBUG_KMS("SCDC not scrambled\n");
@@ -2832,9 +2832,10 @@ static int tegra_sor_init(struct host1x_client *client)
sor->output.dev = sor->dev;
- drm_connector_init(drm, &sor->output.connector,
- &tegra_sor_connector_funcs,
- connector);
+ drm_connector_init_with_ddc(drm, &sor->output.connector,
+
Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
Hi Andrey,
On Tue, Jul 23, 2019 at 08:03:29PM +0200, Andrey Konovalov wrote:
> On Tue, Jul 23, 2019 at 7:59 PM Andrey Konovalov
> wrote:
> >
> > === Overview
> >
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > Right now the kernel is already able to handle user faults with tagged
> > pointers, due to these patches:
> >
> > 1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a
> > tagged pointer")
> > 2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged
> > pointers")
> > 3. 276e9327 ("arm64: entry: improve data abort handling of tagged
> > pointers")
> >
> > This patchset extends tagged pointer support to syscall arguments.
[...]
> Do you think this is ready to be merged?
>
> Should this go through the mm or the arm tree?
I would certainly prefer to take at least the arm64 bits via the arm64 tree
(i.e. patches 1, 2 and 15). We also need a Documentation patch describing
the new ABI.
Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 13/24] drm: zte: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_hdmi.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index a50f5a1f09b8..502d357b40a5 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -29,15 +29,11 @@
#define ZX_HDMI_INFOFRAME_SIZE 31
#define DDC_SEGMENT_ADDR 0x30
-struct zx_hdmi_i2c {
- struct i2c_adapter adap;
- struct mutex lock;
-};
-
struct zx_hdmi {
struct drm_connector connector;
struct drm_encoder encoder;
- struct zx_hdmi_i2c *ddc;
+ /* protects ddc access */
+ struct mutex ddc_lock;
struct device *dev;
struct drm_device *drm;
void __iomem *mmio;
@@ -264,7 +260,7 @@ static int zx_hdmi_connector_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- edid = drm_get_edid(connector, &hdmi->ddc->adap);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid)
return 0;
@@ -319,8 +315,10 @@ static int zx_hdmi_register(struct drm_device *drm, struct
zx_hdmi *hdmi)
hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
- drm_connector_init(drm, &hdmi->connector, &zx_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(drm, &hdmi->connector,
+ &zx_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->connector.ddc);
drm_connector_helper_add(&hdmi->connector,
&zx_hdmi_connector_helper_funcs);
@@ -562,10 +560,9 @@ static int zx_hdmi_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
struct zx_hdmi *hdmi = i2c_get_adapdata(adap);
- struct zx_hdmi_i2c *ddc = hdmi->ddc;
int i, ret = 0;
- mutex_lock(&ddc->lock);
+ mutex_lock(&hdmi->ddc_lock);
/* Enable DDC master access */
hdmi_writeb_mask(hdmi, TPI_DDC_MASTER_EN, HW_DDC_MASTER, HW_DDC_MASTER);
@@ -590,7 +587,7 @@ static int zx_hdmi_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
/* Disable DDC master access */
hdmi_writeb_mask(hdmi, TPI_DDC_MASTER_EN, HW_DDC_MASTER, 0);
- mutex_unlock(&ddc->lock);
+ mutex_unlock(&hdmi->ddc_lock);
return ret;
}
@@ -608,17 +605,15 @@ static const struct i2c_algorithm zx_hdmi_algorithm = {
static int zx_hdmi_ddc_register(struct zx_hdmi *hdmi)
{
struct i2c_adapter *adap;
- struct zx_hdmi_i2c *ddc;
int ret;
- ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
- if (!ddc)
+ adap = devm_kzalloc(hdmi->dev, sizeof(*adap), GFP_KERNEL);
+ if (!adap)
return -ENOMEM;
- hdmi->ddc = ddc;
- mutex_init(&ddc->lock);
+ hdmi->connector.ddc = adap;
+ mutex_init(&hdmi->ddc_lock);
- adap = &ddc->adap;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DDC;
adap->dev.parent = hdmi->dev;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 12/24] drm/vc4: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ee7d4e7b0ee3..671018c9ecc9 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,7 +76,6 @@ struct vc4_hdmi {
struct vc4_hdmi_audio audio;
- struct i2c_adapter *ddc;
void __iomem *hdmicore_regs;
void __iomem *hd_regs;
int hpd_gpio;
@@ -207,7 +206,7 @@ vc4_hdmi_connector_detect(struct drm_connector *connector,
bool force)
return connector_status_disconnected;
}
- if (drm_probe_ddc(vc4->hdmi->ddc))
+ if (drm_probe_ddc(connector->ddc))
return connector_status_connected;
if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
@@ -233,7 +232,7 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
int ret = 0;
struct edid *edid;
- edid = drm_get_edid(connector, vc4->hdmi->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
if (!edid)
return -ENODEV;
@@ -267,7 +266,8 @@ static const struct drm_connector_helper_funcs
vc4_hdmi_connector_helper_funcs =
};
static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
-struct drm_encoder
*encoder)
+struct drm_encoder
*encoder,
+struct i2c_adapter *ddc)
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
@@ -281,8 +281,10 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
hdmi_connector->encoder = encoder;
- drm_connector_init(dev, connector, &vc4_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(dev, connector,
+ &vc4_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
/* Create and attach TV margin props to this connector. */
@@ -1291,6 +1293,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
struct vc4_hdmi *hdmi;
struct vc4_hdmi_encoder *vc4_hdmi_encoder;
struct device_node *ddc_node;
+ struct i2c_adapter *ddc;
u32 value;
int ret;
@@ -1338,9 +1341,9 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
return -ENODEV;
}
- hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!hdmi->ddc) {
+ if (ddc) {
DRM_DEBUG("Failed to get ddc i2c adapter by node\n");
return -EPROBE_DEFER;
}
@@ -1395,7 +1398,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(hdmi->encoder, &vc4_hdmi_encoder_helper_funcs);
- hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder);
+ hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder, ddc);
if (IS_ERR(hdmi->connector)) {
ret = PTR_ERR(hdmi->connector);
goto err_destroy_encoder;
@@ -1452,7 +1455,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
err_put_i2c:
- put_device(&hdmi->ddc->dev);
+ put_device(&ddc->dev);
return ret;
}
@@ -1463,6 +1466,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = drm->dev_private;
struct vc4_hdmi *hdmi = vc4->hdmi;
+ struct i2c_adapter *ddc = hdmi->connector->ddc;
cec_unregister_adapter(hdmi->cec_adap);
vc4_hdmi_connector_destroy(hdmi->connector);
@@ -1471,7 +1475,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
- put_device(&hdmi->ddc->dev);
+ put_device(&ddc->dev);
vc4->hdmi = NULL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 14/24] drm: zte: Provide ddc symlink in vga connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_vga.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 9b67e419280c..1bc6e9bce7e0 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -25,15 +25,11 @@ struct zx_vga_pwrctrl {
u32 mask;
};
-struct zx_vga_i2c {
- struct i2c_adapter adap;
- struct mutex lock;
-};
-
struct zx_vga {
struct drm_connector connector;
struct drm_encoder encoder;
- struct zx_vga_i2c *ddc;
+ /* protects ddc access */
+ struct mutex ddc_lock;
struct device *dev;
void __iomem *mmio;
struct clk *i2c_wclk;
@@ -88,7 +84,7 @@ static int zx_vga_connector_get_modes(struct drm_connector
*connector)
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
- edid = drm_get_edid(connector, &vga->ddc->adap);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid) {
/*
* If EDID reading fails, we set the device state into
@@ -165,8 +161,10 @@ static int zx_vga_register(struct drm_device *drm, struct
zx_vga *vga)
vga->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(drm, connector, &zx_vga_connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(drm, connector,
+ &zx_vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ connector->ddc);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init connector: %d\n", ret);
goto clean_encoder;
@@ -284,11 +282,10 @@ static int zx_vga_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
struct zx_vga *vga = i2c_get_adapdata(adap);
- struct zx_vga_i2c *ddc = vga->ddc;
int ret = 0;
int i;
- mutex_lock(&ddc->lock);
+ mutex_lock(&vga->ddc_lock);
for (i = 0; i < num; i++) {
if (msgs[i].flags & I2C_M_RD)
@@ -303,7 +300,7 @@ static int zx_vga_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs,
if (!ret)
ret = num;
- mutex_unlock(&ddc->lock);
+ mutex_unlock(&vga->ddc_lock);
return ret;
}
@@ -322,17 +319,15 @@ static int zx_vga_ddc_register(struct zx_vga *vga)
{
struct device *dev = vga->dev;
struct i2c_adapter *adap;
- struct zx_vga_i2c *ddc;
int ret;
- ddc = devm_kzalloc(dev, sizeof(*ddc), GFP_KERNEL);
- if (!ddc)
+ adap = devm_kzalloc(dev, sizeof(*adap), GFP_KERNEL);
+ if (!adap)
return -ENOMEM;
- vga->ddc = ddc;
- mutex_init(&ddc->lock);
+ vga->connector.ddc = adap;
+ mutex_init(&vga->ddc_lock);
- adap = &ddc->adap;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DDC;
adap->dev.parent = dev;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 15/24] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index c6e4e52f32bc..d51776dd7a03 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -222,8 +222,10 @@ static struct drm_connector *tfp410_connector_create(struct drm_device *dev, connector = &tfp410_connector->base; - drm_connector_init(dev, connector, &tfp410_connector_funcs, - DRM_MODE_CONNECTOR_DVID); + drm_connector_init_with_ddc(dev, connector, + &tfp410_connector_funcs, + DRM_MODE_CONNECTOR_DVID, + mod->i2c); drm_connector_helper_add(connector, &tfp410_connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 16/24] drm: sti: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/sti/sti_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index f03d617edc4c..33d06e0a9168 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -1284,8 +1284,10 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data) drm_connector->polled = DRM_CONNECTOR_POLL_HPD; - drm_connector_init(drm_dev, drm_connector, - &sti_hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm_dev, drm_connector, + &sti_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc_adapt); drm_connector_helper_add(drm_connector, &sti_hdmi_connector_helper_funcs); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 18/24] drm/ast: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/ast/ast_mode.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c792362024a5..1c899a6e87b7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -867,7 +867,14 @@ static int ast_connector_init(struct drm_device *dev)
return -ENOMEM;
connector = &ast_connector->base;
- drm_connector_init(dev, connector, &ast_connector_funcs,
DRM_MODE_CONNECTOR_VGA);
+ ast_connector->i2c = ast_i2c_create(dev);
+ if (!ast_connector->i2c)
+ DRM_ERROR("failed to add ddc bus for connector\n");
+
+ drm_connector_init_with_ddc(dev, connector,
+ &ast_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ &ast_connector->i2c->adapter);
drm_connector_helper_add(connector, &ast_connector_helper_funcs);
@@ -881,10 +888,6 @@ static int ast_connector_init(struct drm_device *dev)
encoder = list_first_entry(&dev->mode_config.encoder_list, struct
drm_encoder, head);
drm_connector_attach_encoder(connector, encoder);
- ast_connector->i2c = ast_i2c_create(dev);
- if (!ast_connector->i2c)
- DRM_ERROR("failed to add ddc bus for connector\n");
-
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 17/24] drm/mgag200: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 822f2a13748f..5e778b5f1a10 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1678,18 +1678,19 @@ static struct drm_connector *mga_vga_init(struct
drm_device *dev)
return NULL;
connector = &mga_connector->base;
+ mga_connector->i2c = mgag200_i2c_create(dev);
+ if (!mga_connector->i2c)
+ DRM_ERROR("failed to add ddc bus\n");
- drm_connector_init(dev, connector,
- &mga_vga_connector_funcs, DRM_MODE_CONNECTOR_VGA);
+ drm_connector_init_with_ddc(dev, connector,
+ &mga_vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ &mga_connector->i2c->adapter);
drm_connector_helper_add(connector, &mga_vga_connector_helper_funcs);
drm_connector_register(connector);
- mga_connector->i2c = mgag200_i2c_create(dev);
- if (!mga_connector->i2c)
- DRM_ERROR("failed to add ddc bus\n");
-
return connector;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index d32885b906ae..ec04402eca38 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -20,7 +20,6 @@ struct dumb_vga {
struct drm_bridge bridge;
struct drm_connectorconnector;
- struct i2c_adapter *ddc;
struct regulator*vdd;
};
@@ -42,10 +41,10 @@ static int dumb_vga_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- if (IS_ERR(vga->ddc))
+ if (IS_ERR(vga->connector.ddc))
goto fallback;
- edid = drm_get_edid(connector, vga->ddc);
+ edid = drm_get_edid(connector, vga->connector.ddc);
if (!edid) {
DRM_INFO("EDID readout failed, falling back to standard
modes\n");
goto fallback;
@@ -84,7 +83,7 @@ dumb_vga_connector_detect(struct drm_connector *connector,
bool force)
* wire the DDC pins, or the I2C bus might not be working at
* all.
*/
- if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ if (!IS_ERR(vga->connector.ddc) && drm_probe_ddc(vga->connector.ddc))
return connector_status_connected;
return connector_status_unknown;
@@ -111,8 +110,10 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
drm_connector_helper_add(&vga->connector,
&dumb_vga_con_helper_funcs);
- ret = drm_connector_init(bridge->dev, &vga->connector,
-&dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(bridge->dev, &vga->connector,
+ &dumb_vga_con_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ vga->connector.ddc);
if (ret) {
DRM_ERROR("Failed to initialize connector\n");
return ret;
@@ -190,14 +191,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
}
- vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
- if (IS_ERR(vga->ddc)) {
- if (PTR_ERR(vga->ddc) == -ENODEV) {
+ vga->connector.ddc = dumb_vga_retrieve_ddc(&pdev->dev);
+ if (IS_ERR(vga->connector.ddc)) {
+ if (PTR_ERR(vga->connector.ddc) == -ENODEV) {
dev_dbg(&pdev->dev,
"No i2c bus specified. Disabling EDID
readout\n");
} else {
dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
- return PTR_ERR(vga->ddc);
+ return PTR_ERR(vga->connector.ddc);
}
}
@@ -216,8 +217,8 @@ static int dumb_vga_remove(struct platform_device *pdev)
drm_bridge_remove(&vga->bridge);
- if (!IS_ERR(vga->ddc))
- i2c_put_adapter(vga->ddc);
+ if (!IS_ERR(vga->connector.ddc))
+ i2c_put_adapter(vga->connector.ddc);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 20/24] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 ---
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 218a7b2308f7..1ff6d2cf6f3a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -161,7 +161,6 @@ struct dw_hdmi {
struct drm_display_mode previous_mode;
- struct i2c_adapter *ddc;
void __iomem *regs;
bool sink_is_hdmi;
bool sink_has_audio;
@@ -1133,7 +1132,7 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
return false;
/* Disable if no DDC bus */
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return false;
/* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
@@ -1171,10 +1170,11 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
*hdmi)
/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
if (dw_hdmi_support_scdc(hdmi)) {
+ struct i2c_adapter *ddc = hdmi->connector.ddc;
if (mtmdsclock > HDMI14_MAX_TMDSCLK)
- drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
+ drm_scdc_set_high_tmds_clock_ratio(ddc, 1);
else
- drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
+ drm_scdc_set_high_tmds_clock_ratio(ddc, 0);
}
}
EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
@@ -1765,6 +1765,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
if (dw_hdmi_support_scdc(hdmi)) {
if (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
hdmi_info->scdc.scrambling.low_rates) {
+ struct i2c_adapter *ddc = hdmi->connector.ddc;
/*
* HDMI2.0 Specifies the following procedure:
* After the Source Device has determined that
@@ -1774,13 +1775,12 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
* Source Devices compliant shall set the
* Source Version = 1.
*/
- drm_scdc_readb(hdmi->ddc, SCDC_SINK_VERSION,
- &bytes);
- drm_scdc_writeb(hdmi->ddc, SCDC_SOURCE_VERSION,
+ drm_scdc_readb(ddc, SCDC_SINK_VERSION, &bytes);
+ drm_scdc_writeb(ddc, SCDC_SOURCE_VERSION,
min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
/* Enabled Scrambling in the Sink */
- drm_scdc_set_scrambling(hdmi->ddc, 1);
+ drm_scdc_set_scrambling(hdmi->connector.ddc, 1);
/*
* To activate the scrambler feature, you must ensure
@@ -1796,7 +1796,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
- drm_scdc_set_scrambling(hdmi->ddc, 0);
+ drm_scdc_set_scrambling(hdmi->connector.ddc, 0);
}
}
@@ -2142,10 +2142,10 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, hdmi->connector.ddc);
if (edid) {
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);
@@ -2200,8 +2200,10 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
- drm_connector_init(bridge->dev, connector, &dw_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(bridge->dev, connector,
+ &dw_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ connector->ddc);
drm_connector_attach_encoder(connector, encoder);
@@ -2563,9 +2565,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
- hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
+ hdmi->connector.ddc = of_get_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!hdmi->ddc) {
+ if (!hdmi->connecto
[PATCH v5 21/24] drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/ti-tfp410.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index dbf35c7bc85e..ca8e2f382851 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -26,7 +26,6 @@ struct tfp410 {
unsigned intconnector_type;
u32 bus_format;
- struct i2c_adapter *ddc;
struct gpio_desc*hpd;
int hpd_irq;
struct delayed_work hpd_work;
@@ -55,10 +54,10 @@ static int tfp410_get_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!dvi->ddc)
+ if (!dvi->connector.ddc)
goto fallback;
- edid = drm_get_edid(connector, dvi->ddc);
+ edid = drm_get_edid(connector, dvi->connector.ddc);
if (!edid) {
DRM_INFO("EDID read failed. Fallback to standard modes\n");
goto fallback;
@@ -98,8 +97,8 @@ tfp410_connector_detect(struct drm_connector *connector, bool
force)
return connector_status_disconnected;
}
- if (dvi->ddc) {
- if (drm_probe_ddc(dvi->ddc))
+ if (dvi->connector.ddc) {
+ if (drm_probe_ddc(dvi->connector.ddc))
return connector_status_connected;
else
return connector_status_disconnected;
@@ -134,8 +133,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
drm_connector_helper_add(&dvi->connector,
&tfp410_con_helper_funcs);
- ret = drm_connector_init(bridge->dev, &dvi->connector,
-&tfp410_con_funcs, dvi->connector_type);
+ ret = drm_connector_init_with_ddc(bridge->dev, &dvi->connector,
+ &tfp410_con_funcs,
+ dvi->connector_type,
+ dvi->connector.ddc);
if (ret) {
dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
return ret;
@@ -297,8 +298,8 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
if (!ddc_phandle)
goto fail;
- dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
- if (dvi->ddc)
+ dvi->connector.ddc = of_get_i2c_adapter_by_node(ddc_phandle);
+ if (dvi->connector.ddc)
dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
else
ret = -EPROBE_DEFER;
@@ -367,7 +368,7 @@ static int tfp410_init(struct device *dev, bool i2c)
return 0;
fail:
- i2c_put_adapter(dvi->ddc);
+ i2c_put_adapter(dvi->connector.ddc);
if (dvi->hpd)
gpiod_put(dvi->hpd);
return ret;
@@ -382,8 +383,8 @@ static int tfp410_fini(struct device *dev)
drm_bridge_remove(&dvi->bridge);
- if (dvi->ddc)
- i2c_put_adapter(dvi->ddc);
+ if (dvi->connector.ddc)
+ i2c_put_adapter(dvi->connector.ddc);
if (dvi->hpd)
gpiod_put(dvi->hpd);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 22/24] drm/amdgpu: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 95 ++-
1 file changed, 69 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 73b2ede773d3..e16e553e7f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1574,17 +1574,21 @@ amdgpu_connector_add(struct amdgpu_device *adev,
amdgpu_connector->con_priv = amdgpu_dig_connector;
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus = amdgpu_i2c_lookup(adev,
i2c_bus);
- if (amdgpu_connector->ddc_bus)
+ if (amdgpu_connector->ddc_bus) {
has_aux = true;
- else
+ connector->ddc =
&amdgpu_connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
default:
- drm_connector_init(dev, &amdgpu_connector->base,
- &amdgpu_connector_dp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&amdgpu_connector->base,
+ &amdgpu_connector_dp_funcs,
+ connector_type,
+ amdgpu_connector->base.ddc);
drm_connector_helper_add(&amdgpu_connector->base,
&amdgpu_connector_dp_helper_funcs);
connector->interlace_allowed = true;
@@ -1602,8 +1606,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
case DRM_MODE_CONNECTOR_HDMIA:
case DRM_MODE_CONNECTOR_HDMIB:
case DRM_MODE_CONNECTOR_DisplayPort:
- drm_connector_init(dev, &amdgpu_connector->base,
- &amdgpu_connector_dp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&amdgpu_connector->base,
+ &amdgpu_connector_dp_funcs,
+ connector_type,
+ amdgpu_connector->base.ddc);
drm_connector_helper_add(&amdgpu_connector->base,
&amdgpu_connector_dp_helper_funcs);
drm_object_attach_property(&amdgpu_connector->base.base,
@@ -1644,8 +1650,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
break;
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
- drm_connector_init(dev, &amdgpu_connector->base,
- &amdgpu_connector_edp_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&amdgpu_connector->base,
+ &amdgpu_connector_edp_funcs,
+ connector_type,
+ amdgpu_connector->base.ddc);
drm_connector_helper_add(&amdgpu_connector->base,
&amdgpu_connector_dp_helper_funcs);
drm_object_attach_property(&amdgpu_connector->base.base,
@@ -1659,13 +1667,18 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, &amdgpu_connector->base,
&amdgpu_connector_vga_funcs, connector_type);
- drm_connector_helper_add(&amdgpu_connector->base,
&amdgpu_connector_vga_helper_funcs);
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus =
amdgpu_i2c_lookup(adev, i2c_bus);
if (!amdgpu_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
&amdgpu_connector->ddc_bus->adapter;
}
+ drm_connector_init_with_ddc(dev,
&amdgpu_connector->base,
+ &amdgpu_connector_vga_funcs,
+
[PATCH v5 23/24] drm/radeon: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/radeon/radeon_connectors.c | 141 +++--
1 file changed, 105 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c60d1a44d22a..1b743edb3fbe 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1947,17 +1947,21 @@ radeon_add_atom_connector(struct drm_device *dev,
radeon_connector->con_priv = radeon_dig_connector;
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
- if (radeon_connector->ddc_bus)
+ if (radeon_connector->ddc_bus) {
has_aux = true;
- else
+ connector->ddc =
&radeon_connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
default:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+ &radeon_dp_connector_funcs,
+ connector_type,
+ radeon_connector->base.ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
connector->interlace_allowed = true;
@@ -1979,8 +1983,10 @@ radeon_add_atom_connector(struct drm_device *dev,
case DRM_MODE_CONNECTOR_HDMIA:
case DRM_MODE_CONNECTOR_HDMIB:
case DRM_MODE_CONNECTOR_DisplayPort:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+ &radeon_dp_connector_funcs,
+ connector_type,
+ radeon_connector->base.ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
drm_object_attach_property(&radeon_connector->base.base,
@@ -2027,8 +2033,10 @@ radeon_add_atom_connector(struct drm_device *dev,
break;
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_lvds_bridge_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+
&radeon_lvds_bridge_connector_funcs,
+ connector_type,
+ radeon_connector->base.ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
drm_object_attach_property(&radeon_connector->base.base,
@@ -2042,13 +2050,18 @@ radeon_add_atom_connector(struct drm_device *dev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, &radeon_connector->base,
&radeon_vga_connector_funcs, connector_type);
- drm_connector_helper_add(&radeon_connector->base,
&radeon_vga_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
&radeon_connector->ddc_bus->adapter;
}
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+ &radeon_vga_connector_funcs,
+
Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
On Wed, Jul 24, 2019 at 2:52 PM Linus Walleij wrote:
>
> On Tue, Jul 23, 2019 at 11:07 PM Daniel Vetter wrote:
> > On Tue, Jul 23, 2019 at 7:25 PM Adam Jackson wrote:
> > >
> > > On Tue, 2019-07-23 at 15:37 +0200, Linus Walleij wrote:
> > > > Migrating the TI nspire calculators to use the PL111 driver for
> > > > framebuffer requires grayscale support for the elder panel
> > > > which uses 8bit grayscale only.
> > > >
> > > > DRM does not support 8bit grayscale framebuffers in memory,
> > > > but by defining the bus format to be MEDIA_BUS_FMT_Y8_1X8 we
> > > > can get the hardware to turn on a grayscaling feature and
> > > > convert the RGB framebuffer to grayscale for us.
> > >
> > > What's wrong with DRM_FORMAT_R8? Yes the hardware is not really
> > > "redscale", but it's still a single color channel and there's not
> > > really any ambiguity.
> >
> > Yeah, I think with a comment or an aliasing #define to _Y8 (or both)
> > this is good to go.
>
> Is there something really wrong with just biting the bullet and do this:
>
> /* 8 bpp grayscale */
> #define DRM_FORMAT_Y8 fourcc_code('Y', '8', ' ', ' ') /* [7:0] Y */
>
> It's quite an embarrasement for my OCD tendencies to talk about
> black-and-white TV as if it was 256 Shades of Red (good title
> for a novel by the way).
>
> I don't know how these FOURCC things work, possibly new
> fourcc:s can only be defined by some especially enlightened
> cabal of standardization?
>
> (It beats me how it can not already exist in that case.)
The drm subsystem cabal owns drm_fourcc.h. And yeah I guess we can
also add Y version of all these, I think the R/RG was added since that
matches modern GL, where your texture contents are entirely up to
interpretation by shaders. Y also exists in GL, but only in legacy
contexts and is kinda discouraged. That was the idea behind just
making them aliasing (since I just can't come up with any reason why
you'd actually want a red-only texture). In a way R = red = the first
channel in GL shaders, which happens to be called r for red !=
actually red color channel on the display.
Hence we might as well state that if you give a kms driver a
single-channel fourcc code, then that should be interpreted as
greyscale. Plus add a huge comment about why this single channel is
called R :-)
-Daniel
> > You probably still want to expose the rgb format since too much
> > userspace just assumes that xrgb works. Same reason why the
> > tinydrm drivers do the sw conversion.
>
> Yes this is what we do on PL111 now, we just run it through
> the hardware grayscaler.
>
> This hardware graciously supports reading black-white and
> grayscale bitmaps with 1 (monochrome), 2, 4 and 8 bits per
> pixel which would be Y1, Y2, Y4 and Y8. But we only have
> hardware supporting Y8 at least on the other side so
> I don't see any need for the others ATM.
>
> I suspect the Y1 etc could be useful for people doing not
> only Hercules video drivers (hah!) but also for ePaper
> displays of say, some random Kindle.
I guess if we bother with Y (whether aliased to R or new ones) we
might as well roll out all of them.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 24/24] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 9bf28de10401..9948a8a1833a 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -3077,8 +3077,13 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_dig_port->max_lanes, port_name(port))) return; - drm_connector_init(dev, connector, &intel_hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); + connector->ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); + + drm_connector_init_with_ddc(dev, connector, + &intel_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + connector->ddc); drm_connector_helper_add(connector, &intel_hdmi_connector_helper_funcs); connector->interlace_allowed = 1; @@ -3088,8 +3093,6 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) connector->ycbcr_420_allowed = true; - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); - if (WARN_ON(port == PORT_A)) return; intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #65 from weden...@yandex.ru --- (In reply to Sylvain BERTRAND from comment #62) > unstable power supply lines to the gpu if overheating is excluded? It's not overheating in my case, but my PSU is pretty old (I'm waiting for components for my new build to arrive, including new PSU). I've lowered power limit (to 80W) and I haven't had any crashes yet. So, in my case the problem *might be* related to PSU. But I can't exclude (nor confirm) possibility of driver problems with higher power states (until I have a better PSU). I'll report back if I have any crashes with new PSU or lowered PL. -- 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
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #66 from Hadet --- I don't think it's faulty hardware in any of our cases to be perfectly honest, it's a bad instruction set, this didn't happen with older kernels or firmware and the issue now is there are so few of us with Vega cards that we're really on our own trying to troubleshoot this situatio. Since switching to wayland my crashing has been a lot less frequent, it'd say once every couple days as opposed to once every few hours when gaming with Vulkan/DXVK -- 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: [RFC] Expanding drm_mode_modeinfo flags
On Mon, Jul 22, 2019 at 04:50:43PM -0700, Jeykumar Sankaran wrote: > On 2019-07-19 07:29, Sean Paul wrote: > > On Fri, Jul 19, 2019 at 05:15:28PM +0300, Ville Syrjälä wrote: > > > On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote: > > > > On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote: > > > > > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote: > > > > > > On 2019-07-16 02:07, Daniel Vetter wrote: > > > > > > > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote: > > > > /snip > > > > > > > > > > drm: add mode flags in uapi for seamless mode switch > > > > > > > > > > > > > > I think the uapi is the trivial part here, the real deal is how > > > > > > > userspace > > > > > > > uses this. Can you pls post the patches for your compositor? > > > > > > > > > > > > > > Also note that we already allow userspace to tell the kernel > > > > > > > whether > > > > > > > flickering is ok or not for a modeset. msm driver could use that > > > > > > > to at > > > > > > > least tell userspace whether a modeset change is possible. So you > > > > > > > can > > > > > > > already implement glitch-free modeset changes for at least video > > > > > > > mode. > > > > > > > -Daniel > > > > > > > > > > > > I believe you are referring to the below tv property of the > > > > > > connector. > > > > > > > > > > > > /** > > > > > > * @tv_flicker_reduction_property: Optional TV property to control > > > > > > the > > > > > > * flicker reduction mode. > > > > > > */ > > > > > > struct drm_property *tv_flicker_reduction_property; > > > > > > > > > > Not even close :-) > > > > > > > > > > I mean the DRM_MODE_ATOMIC_ALLOW_MODESET flag for the atomic ioctl. > > > > > This > > > > > is not a property of a mode, this is a property of a _transition_ > > > > > between > > > > > configurations. Some transitions can be done flicker free, others > > > > > can't. > > > > > > > > Agree that an atomic flag on a commit is the way to accomplish this. > > > > It's pretty > > > > similar to the psr transitions, where we want to reuse most of the > > > > atomic > > > > circuitry, but in a specialized way. We'd also have to be careful to > > > > only > > > > involve the drm objects which are seamless modeset aware (you could > > > > imagine > > > > a bridge chain where the bridges downstream of the first bridge don't > > > > care). > > > > > > > > > > > > > > There's then still the question of how to pick video vs command mode, > > > > > but > > > > > imo better to start with implementing the transition behaviour > > > > > correctly > > > > > first. > > > > > > > > Connector property? Possibly a terrible idea, but I wonder if we could > > > > [re]use > > > > the vrr properties for command mode. The docs state that the driver has > > > > the > > > > option of putting upper and lower bounds on the refresh rate. > > > > > > Not really sure why this needs new props and whatnot. This is kinda > > > what > > > the i915 "fastset" stuff already does: > > > 1. userspace asks for something to be changed via atomic > > > 2. driver calculates whether a modeset is actually required > > > 3. atomic validates need_modeset() vs. DRM_MODE_ATOMIC_ALLOW_MODESET > > > 4. if (need_modeset) heavyweight_commit() else lightweight_commit() > > > > > > Ie. why should userspace really care about anything except the > > > "flickers are OK" vs. "flickers not wanted" thing? > > > > Agree, I don't think the seamless modeset (ie: changing resolution > > without > > flicker) needs a property. Just need to test the commit without > > ALLOW_MODESET > > and commit it if the test passes. > > > > Agreed that a TEST_ONLY commit without ALLOW_MODESET flag can be used to > check > whether the modeset can be done seamless. But since there are no error code > returns, > the client cannot distinguish the test_only commit failures from other > invalid config failures. > > Also, note that when the client sees two 1080p modes (vid/cmd) and it is > interested only > to do *only* seamless switches, without any additional flag it cannot > distinguish between > these two 1080p modes. The client has to invoke two test_only commits with > these > modes to identify the seamless one. Is that a preferred approach? Hi Jey! Yeah, pretty much. Stepping back a bit though, why is the kernel exposing 2 1080p modes in the first place? If you just expose one mode and then use a property to enter "low-latency operation" (or overloading vrr for cmd mode), you shouldn't need to do the mode switch, just flip the property and let the kernel figure out how to transition to video/cmd mode. > > Intel's "fastset" calculates the need for modeset internally based on the > configuration and chooses the best commit path. But the requirement here > is to expose the information up-front since the use case cannot afford > to fall back to the normal modeset when it has requested for a seamless one. > > > > > > > Also what's the benefit of using video
[PATCH] drm/panel: check failure cases in the probe func
The following function calls may fail and return NULL, so the null check
is added.
of_graph_get_next_endpoint
of_graph_get_remote_port_parent
of_graph_get_remote_port
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 28c0620dfe0f..9484fdb60f68 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -399,7 +399,13 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
/* Look up the DSI host. It needs to probe before we do. */
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (!endpoint)
+ return -ENODEV;
+
dsi_host_node = of_graph_get_remote_port_parent(endpoint);
+ if (!dsi_host_node)
+ return -ENODEV;
+
host = of_find_mipi_dsi_host_by_node(dsi_host_node);
of_node_put(dsi_host_node);
if (!host) {
@@ -408,6 +414,9 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
}
info.node = of_graph_get_remote_port(endpoint);
+ if (!info.node)
+ return -ENODEV;
+
of_node_put(endpoint);
ts->dsi = mipi_dsi_device_register_full(host, &info);
--
2.17.1
Re: [Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
> ... > Vulkan/DXVK The bugs may be in wine/DXVK then. You should report to a bug to them and link this bug to theirs. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #67 from Sylvain BERTRAND --- > ... > Vulkan/DXVK The bugs may be in wine/DXVK then. You should report to a bug to them and link this bug to theirs. -- 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
