Re: [PATCH v3 2/2] dmabuf: Add dmabuf inode number to /proc/*/fdinfo
Am 05.02.21 um 03:23 schrieb Kalesh Singh:
If a FD refers to a DMA buffer add the DMA buffer inode number to
/proc//fdinfo/ and /proc//task//fdindo/.
The dmabuf inode number allows userspace to uniquely identify the buffer
and avoids a dependency on /proc//fd/* when accounting per-process
DMA buffer sizes.
BTW: Why do we make this DMA-buf specific? Couldn't we always print the
inode number for all fds?
Regards,
Christian.
Signed-off-by: Kalesh Singh
---
Changes in v3:
- Add documentation in proc.rst
Changes in v2:
- Update patch description
Documentation/filesystems/proc.rst | 17 +
drivers/dma-buf/dma-buf.c | 1 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/filesystems/proc.rst
b/Documentation/filesystems/proc.rst
index 2fa69f710e2a..fdd38676f57f 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -2031,6 +2031,23 @@ details]. 'it_value' is remaining time until the timer
expiration.
with TIMER_ABSTIME option which will be shown in 'settime flags', but
'it_value'
still exhibits timer's remaining time.
+DMA Buffer files
+
+
+::
+
+ pos:0
+ flags: 04002
+ mnt_id: 9
+ dmabuf_inode_no: 63107
+ size: 32768
+ count: 2
+ exp_name: system-heap
+
+where 'dmabuf_inode_no' is the unique inode number of the DMA buffer file.
+'size' is the size of the DMA buffer in bytes. 'count' is the file count of
+the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter.
+
3.9 /proc//map_files - Information about memory mapped files
-
This directory contains symbolic links which represent memory mapped files
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 9ad6397aaa97..d869099ede83 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -414,6 +414,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
{
struct dma_buf *dmabuf = file->private_data;
+ seq_printf(m, "dmabuf_inode_no:\t%lu\n", file_inode(file)->i_ino);
seq_printf(m, "size:\t%zu\n", dmabuf->size);
/* Don't count the temporary reference taken inside procfs seq_show */
seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/qxl: do not run release if qxl failed to init
On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote: > if qxl_device_init() fail, drm device will not be registered, > in this case, do not run qxl_drm_release() How do you trigger this? take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm_dp_mst_topology: export two functions
On Tue, 2 Feb 2021 at 09:03, Lyude Paul wrote:
>
> On Wed, 2020-09-23 at 12:13 +1000, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > These are required for the CEC MST support.
> >
> > Signed-off-by: Hans Verkuil
> > Signed-off-by: Sam McNally
> > ---
> >
> > (no changes since v1)
> >
> > drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
> > include/drm/drm_dp_mst_helper.h | 4
> > 2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 0d753201adbd..c783a2a1c114 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
> > static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> > char *buf);
> >
> > -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> > -
> > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > int id,
> > struct drm_dp_payload *payload);
> > @@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct
> > drm_dp_mst_port *port)
> > * drm_dp_mst_topology_try_get_port()
> > * drm_dp_mst_topology_get_port()
> > */
> > -static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
> > +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
>
> Mhh-can you think of some way around this? I really don't think it's a
> good
> idea for us to be exposing topology references to things as-is, the thing is
> they're really meant to be used for critical sections in code where it'd
> become
> very painful to deal with an mst port disappearing from under us. Outside of
> MST
> helpers, everyone else should be dealing with the expectation that these
> things
> can disappear as a result of hotplugs at any moment.
>
> Note that we do expose malloc refs, but that's intentional as holding a malloc
> ref to something doesn't cause it to stay around even when it's unplugged - it
> just stops it from being unallocated.
>
>
Yes, it turns out we won't need this after all.
> > {
> > topology_ref_history_lock(port->mgr);
> >
> > @@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct
> > drm_dp_mst_branch *mstb,
> > return NULL;
> > }
> >
> > -static struct drm_dp_mst_port *
> > +struct drm_dp_mst_port *
> > drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
> >struct drm_dp_mst_port *port)
> > {
> > diff --git a/include/drm/drm_dp_mst_helper.h
> > b/include/drm/drm_dp_mst_helper.h
> > index c7c79e0ced18..d036222e0d64 100644
> > --- a/include/drm/drm_dp_mst_helper.h
> > +++ b/include/drm/drm_dp_mst_helper.h
> > @@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> >struct drm_dp_mst_topology_mgr *mgr,
> >struct drm_dp_mst_port *port);
> >
> > +struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
> > +(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
> > +void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
> > +
> > struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
> > drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
> >
> >
>
> --
> Sincerely,
>Lyude Paul (she/her)
>Software Engineer at Red Hat
>
> Note: I deal with a lot of emails and have a lot of bugs on my plate. If
> you've
> asked me a question, are waiting for a review/merge on a patch, etc. and I
> haven't responded in a while, please feel free to send me another email to
> check
> on my status. I don't bite!
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/10] [hack] silence ttm fini WARNING
On Thu, Feb 04, 2021 at 03:58:33PM +0100, Christian König wrote:
> ?
>
> What's the background here?
>
> Christian.
>
> Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
> > kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put()
> > is being called.
> > WARNING: CPU: 0 PID: 209 at lib/kobject.c:750 kobject_put+0x3a/0x60
> > [ ... ]
> > Call Trace:
> > ttm_device_fini+0x133/0x1b0 [ttm]
> > qxl_ttm_fini+0x2f/0x40 [qxl]
Happens on driver removal. Seen with both qxl and bochs (the later
using vram helpers).
Testcase: "drmtest --unbind" (https://git.kraxel.org/cgit/drminfo/).
static int try_unbind(int card)
{
char path[256];
char *device, *name;
int fd;
snprintf(path, sizeof(path), "/sys/class/drm/card%d/device", card);
device = realpath(path, NULL);
if (device == NULL) {
fprintf(stderr, "%s: can't resolve sysfs device path\n", __func__);
return -1;
}
snprintf(path, sizeof(path), "%s/driver/unbind", device);
fd = open(path, O_WRONLY);
if (fd < 0) {
fprintf(stderr, "open %s: %s\n", path, strerror(errno));
return -1;
}
name = strrchr(device, '/') + 1;
write(fd, name, strlen(name));
close(fd);
return 0;
}
take care,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm_dp_cec: add MST support
On Thu, 4 Feb 2021 at 21:42, Hans Verkuil wrote:
>
> On 23/09/2020 04:13, Sam McNally wrote:
> > With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> > topology.
> >
> > There are some minor differences for CEC tunneling through an MST
> > topology compared to CEC tunneling to an SST port:
> > - CEC IRQs are delivered via a sink event notify message
> > - CEC-related DPCD registers are accessed via remote DPCD reads and
> > writes.
> >
> > This results in the MST implementation diverging from the existing SST
> > implementation:
> > - sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
> > than ESI1
> > - setting edid and handling CEC IRQs, which can be triggered from
> > contexts where locks held preclude HPD handling, are deferred to avoid
> > remote DPCD access which would block until HPD handling is performed
> > or a timeout
> >
> > Register and unregister for all MST connectors, ensuring their
> > drm_dp_aux_cec struct won't be accessed uninitialized.
> >
> > Reviewed-by: Hans Verkuil
> > Signed-off-by: Sam McNally
> > ---
> >
> > Changes in v3:
> > - Fixed whitespace in drm_dp_cec_mst_irq_work()
> > - Moved drm_dp_cec_mst_set_edid_work() with the other set_edid functions
> >
> > Changes in v2:
> > - Used aux->is_remote instead of aux->cec.is_mst, removing the need for
> > the previous patch in the series
> > - Added a defensive check for null edid in the deferred set_edid work,
> > in case the edid is no longer valid at that point
> >
> > drivers/gpu/drm/drm_dp_cec.c | 68 +--
> > drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
> > include/drm/drm_dp_helper.h | 4 ++
> > 3 files changed, 91 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> > index 3ab2609f9ec7..1020b2cffdf0 100644
> > --- a/drivers/gpu/drm/drm_dp_cec.c
> > +++ b/drivers/gpu/drm/drm_dp_cec.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * Unfortunately it turns out that we have a chicken-and-egg situation
> > @@ -248,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
> > if (!aux->transfer)
> > return;
> >
> > + if (aux->is_remote) {
> > + schedule_work(>cec.mst_irq_work);
> > + return;
> > + }
>
> Are these workqueues for cec_irq and cec_set_edid actually needed? They are
> called
> directly from drm_dp_mst_topology.c, and I think they can be handled
> identically to
> a normal, non-remote, aux device.
>
> Avoiding using a workqueue probably also means that there is no need for
> exporting
> drm_dp_mst_topology_get_port_validated and drm_dp_mst_topology_put_port.
>
> Provided that I am not missing something, this should simplify the code quite
> a bit.
Indeed; with commit 9408cc94eb04 ("drm/dp_mst: Handle UP requests
asynchronously") they're unnecessary. This all simplifies quite
nicely.
>
> Regards,
>
> Hans
>
> > mutex_lock(>cec.lock);
> > if (!aux->cec.adap)
> > goto unlock;
> > @@ -276,6 +281,23 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8
> > *cec_cap)
> > return true;
> > }
> >
> > +static void drm_dp_cec_mst_irq_work(struct work_struct *work)
> > +{
> > + struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
> > + cec.mst_irq_work);
> > + struct drm_dp_mst_port *port =
> > + container_of(aux, struct drm_dp_mst_port, aux);
> > +
> > + port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
> > + if (!port)
> > + return;
> > + mutex_lock(>cec.lock);
> > + if (aux->cec.adap)
> > + drm_dp_cec_handle_irq(aux);
> > + mutex_unlock(>cec.lock);
> > + drm_dp_mst_topology_put_port(port);
> > +}
> > +
> > /*
> > * Called if the HPD was low for more than drm_dp_cec_unregister_delay
> > * seconds. This unregisters the CEC adapter.
> > @@ -297,7 +319,8 @@ static void drm_dp_cec_unregister_work(struct
> > work_struct *work)
> > * were unchanged and just update the CEC physical address. Otherwise
> > * unregister the old CEC adapter and create a new one.
> > */
> > -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> > +static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
> > +const struct edid *edid)
> > {
> > struct drm_connector *connector = aux->cec.connector;
> > u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> > @@ -306,10 +329,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> > struct edid *edid)
> > unsigned int num_las = 1;
> > u8 cap;
> >
> > - /* No transfer function was set, so not a DP connector */
> > - if (!aux->transfer)
> > - return;
> > -
> > #ifndef CONFIG_MEDIA_CEC_RC
> > /*
> >* CEC_CAP_RC is part of
Re: [PATCH] drm/msm: Fix legacy relocs path
On 2/5/2021 4:26 AM, Rob Clark wrote:
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually use relocs.
But this broke ancient mesa on modern kernels.
Reported-by: Emil Velikov
Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index d04c349d8112..5480852bdeda 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -198,6 +198,8 @@ static int submit_lookup_cmds(struct msm_gem_submit *submit,
submit->cmd[i].idx = submit_cmd.submit_idx;
submit->cmd[i].nr_relocs = submit_cmd.nr_relocs;
+ userptr = u64_to_user_ptr(submit_cmd.relocs);
+
sz = array_size(submit_cmd.nr_relocs,
sizeof(struct drm_msm_gem_submit_reloc));
/* check for overflow: */
Reviewed-by: Akhil P Oommen
-Akhil.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
On Thu, 4 Feb 2021 at 21:19, Hans Verkuil wrote:
>
> On 01/02/2021 23:13, Ville Syrjälä wrote:
> > On Wed, Sep 23, 2020 at 12:13:53PM +1000, Sam McNally wrote:
> >> From: Hans Verkuil
> >>
> >> For adapters behind an MST hub use the correct AUX channel.
> >>
> >> Signed-off-by: Hans Verkuil
> >> [sa...@chromium.org: rebased, removing redundant changes]
> >> Signed-off-by: Sam McNally
> >> ---
> >>
> >> (no changes since v1)
> >>
> >> drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
> >> 1 file changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> index 15b6cc39a754..0d753201adbd 100644
> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> >> @@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >> drm_dp_mst_topology_put_port(port);
> >> }
> >>
> >> +static ssize_t
> >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> >> *msg);
> >> +
> >> static struct drm_dp_mst_port *
> >> drm_dp_mst_add_port(struct drm_device *dev,
> >> struct drm_dp_mst_topology_mgr *mgr,
> >> @@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
> >> port->port_num = port_number;
> >> port->mgr = mgr;
> >> port->aux.name = "DPMST";
> >> +mutex_init(>aux.hw_mutex);
> >> +mutex_init(>aux.cec.lock);
> >> port->aux.dev = dev->dev;
> >> port->aux.is_remote = true;
> >>
> >> +port->aux.transfer = drm_dp_mst_aux_transfer;
> >> +
> >
> > This was supposed to be handled via higher levels checking for
> > is_remote==true.
>
> Ah, I suspect this patch can be dropped entirely: it predates commit
> 2f221a5efed4
> ("drm/dp_mst: Add MST support to DP DPCD R/W functions").
>
> It looks like that commit basically solved what this older patch attempts to
> do
> as well.
>
> Sam, can you test if it works without this patch?
It almost just works; drm_dp_cec uses whether aux.transfer is non-null
to filter out non-DP connectors. Using aux.is_remote as another signal
indicating a DP connector seems plausible. We can drop this patch.
Thanks all!
>
> Regards,
>
> Hans
>
> >
> >> /* initialize the MST downstream port's AUX crc work queue */
> >> drm_dp_remote_aux_init(>aux);
> >>
> >> @@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
> >> drm_dp_mst_topology_mgr *mgr,
> >> return 0;
> >> }
> >>
> >> +static ssize_t
> >> +drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> >> *msg)
> >> +{
> >> +struct drm_dp_mst_port *port =
> >> +container_of(aux, struct drm_dp_mst_port, aux);
> >> +int ret;
> >> +
> >> +switch (msg->request & ~DP_AUX_I2C_MOT) {
> >> +case DP_AUX_NATIVE_WRITE:
> >> +case DP_AUX_I2C_WRITE:
> >> +case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> >> +ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
> >> + msg->size, msg->buffer);
> >
> > That doesn't make sense to me. I2c writes and DPCD writes
> > are definitely not the same thing.
> >
> > aux->transfer is a very low level thing. I don't think it's the
> > correct level of abstraction for sideband.
> >
> >> +break;
> >> +
> >> +case DP_AUX_NATIVE_READ:
> >> +case DP_AUX_I2C_READ:
> >> +ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
> >> +msg->size, msg->buffer);
> >> +break;
> >> +
> >> +default:
> >> +ret = -EINVAL;
> >> +break;
> >> +}
> >> +
> >> +return ret;
> >> +}
> >> +
> >> static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
> >> {
> >> if (dp_link_bw == 0 || dp_link_count == 0)
> >> --
> >> 2.28.0.681.g6f77f65b4e-goog
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210849] Black screen after resume from long suspend. Open/Close lid. AMDGPU
https://bugzilla.kernel.org/show_bug.cgi?id=210849 --- Comment #10 from JerryD (jvdeli...@charter.net) --- This bug has basically disabled two different machines I have that use AMD graphics cards. One, a work station running Fedora 33 will lose the display if I do not log on right away after a power up. The defaults that blank the screen or just a simple lock screen sequence basically causes the monitor to shutoff to save energy. At this point the display can not be recovered since the driver loses it self. It is a real shame as this system was working perfectly for over a year beofre this happened. The guilty patch should be reverted immediately. I can remote into the system from elsewhere ussing ssh and command a reboot to bring it back. The kernel underlying is running and completely functional. The device driver AMDGPU is 'F'ed up. In my many many years of using Fedora and other linux distros, this is by far the worse cluster bug I have ever see. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, amdkfd drm-next-5.12
On Thu, Feb 4, 2021 at 6:52 PM Dave Airlie wrote: > > On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote: > > > > Hi Dave, Daniel, > > > > More fixes for 5.12. Same PR from last week with the issue Felix reported > > fixed and a few more additional fixes on top. > > > > The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0: > > > > Merge tag 'amd-drm-next-5.12-2021-01-20' of > > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-01-20 > > 13:08:18 +0100) > > > This brought an arm32 warning with it, I've applied Arnd's patch to > drm-next to fix it. > > https://patchwork.freedesktop.org/patch/msgid/20210125124849.102037-1-a...@kernel.org > > However that function has an ifdef around an ifdef that probably could > do with cleaning up. Sorry about that. Bhawan fixed that up at the time: https://patchwork.freedesktop.org/patch/415092/ Daniel said he picked that up last week: https://lists.freedesktop.org/archives/dri-devel/2021-January/294941.html but I guess it never landed, otherwise I would have included it in my PR. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 5/5] drm/sun4i: dw-hdmi: Fix max. frequency for H6
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> It turns out that reasoning for lowering max. supported frequency is
> wrong. Scrambling works just fine. Several now fixed bugs prevented
> proper functioning, even with rates lower than 340 MHz. Issues were just
> more pronounced with higher frequencies.
>
> Fix that by allowing max. supported frequency in HW and fix the comment.
>
> Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> cpce value for 594 MHz is set differently in BSP driver. Fix that.
>
> Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/sun4i: dw-hdmi: always set clock rate
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> As expected, HDMI controller clock should always match pixel clock. In
> the past, changing HDMI controller rate would seemingly worsen
> situation. However, that was the result of other bugs which are now
> fixed.
>
> Fix that by removing set_rate quirk and always set clock rate.
>
> Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Channel 1 has polarity bits for vsync and hsync signals but driver never
> sets them. It turns out that with pre-HDMI2 controllers seemingly there
> is no issue if polarity is not set. However, with HDMI2 controllers
> (H6) there often comes to de-synchronization due to phase shift. This
> causes flickering screen. It's safe to assume that similar issues might
> happen also with pre-HDMI2 controllers.
>
> Solve issue with setting vsync and hsync polarity. Note that display
> stacks with tcon top have polarity bits actually in tcon0 polarity
> register.
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 6b9af4c08cd6..0d132dae58c0 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> SUN4I_TCON1_BASIC5_H_SYNC(hsync));
>
> + /* Setup the polarity of sync signals */
> + if (tcon->quirks->polarity_in_ch0) {
> + val = 0;
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> + } else {
> + val = SUN4I_TCON1_IO_POL_UNKNOWN;
I think a comment for the origin of this is warranted.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
> + }
> +
> /* Map output pins to channel 1 */
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
> @@ -1500,6 +1523,7 @@ static const struct sun4i_tcon_quirks
> sun8i_a83t_tv_quirks = {
>
> static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
> .has_channel_1 = true,
> + .polarity_in_ch0= true,
> .set_mux= sun8i_r40_tcon_tv_set_mux,
> };
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index c5ac1b02482c..b504fb2d3de5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -154,6 +154,10 @@
> #define SUN4I_TCON1_BASIC5_V_SYNC(height) (((height) - 1) &
> 0x3ff)
>
> #define SUN4I_TCON1_IO_POL_REG 0xf0
> +#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
> +#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE BIT(25)
> +#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE BIT(24)
> +
> #define SUN4I_TCON1_IO_TRI_REG 0xf4
>
> #define SUN4I_TCON_ECC_FIFO_REG0xf8
> @@ -236,6 +240,7 @@ struct sun4i_tcon_quirks {
> boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
> boolsupports_lvds; /* Does the TCON support an LVDS output? */
> + boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in
> tcon0 pol register */
> u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
>
> /* callback to handle tcon muxing options */
> --
> 2.30.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the amdgpu tree
Hi all,
After merging the amdgpu tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
13a75af50484 ("drm/amd/display: Fix unused variable warning")
interacting with commit
4c3a3292730c ("drm/amd/display: fix unused variable warning")
from the drm tree.
I reverted the drm tree commit for now.
--
Cheers,
Stephen Rothwell
pgpbpifOU3SUf.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.11-rc7
Hi Linus, Fixes for rc7, bit bigger than I'd like at this stage, but most of the i915 stuff and some amdgpu is destined for staging and I'd rather not hold it up, the i915 changes also pulled in a few precusor code movement patches to make things cleaner, but nothing seems that horrible, and I've checked over all of it. Otherwise there is a nouveau dma-api warning regression, and a ttm page allocation warning fix, and some fixes for a bridge chip, Dave. drm-fixes-2021-02-05-1: drm fixes for 5.11-rc7 ttm: - fix huge page warning regression i915: - Skip vswing programming for TBT - Power up combo PHY lanes for HDMI - Fix double YUV range correction on HDR planes - Fix the MST PBN divider calculation - Fix LTTPR vswing/pre-emp setting in non-transparent mode - Move the breadcrumb to the signaler if completed upon cancel - Close race between enable_breadcrumbs and cancel_breadcrumbs - Drop lru bumping on display unpinning amdgpu: - Fix retry in gem create - Vangogh fixes - Fix for display from shared buffers - Various display fixes amdkfd: - Fix regression in buffer free nouveau: - fix DMA API warning regression drm/bridge/lontium-lt9611uxc: - EDID fixes - Don't handle hotplug events in IRQ handler The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-05-1 for you to fetch changes up to 59854811c08cfbdf52d79231666e7c07c46ff338: Merge tag 'drm-intel-fixes-2021-02-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-02-05 11:03:28 +1000) drm fixes for 5.11-rc7 ttm: - fix huge page warning regression i915: - Skip vswing programming for TBT - Power up combo PHY lanes for HDMI - Fix double YUV range correction on HDR planes - Fix the MST PBN divider calculation - Fix LTTPR vswing/pre-emp setting in non-transparent mode - Move the breadcrumb to the signaler if completed upon cancel - Close race between enable_breadcrumbs and cancel_breadcrumbs - Drop lru bumping on display unpinning amdgpu: - Fix retry in gem create - Vangogh fixes - Fix for display from shared buffers - Various display fixes amdkfd: - Fix regression in buffer free nouveau: - fix DMA API warning regression drm/bridge/lontium-lt9611uxc: - EDID fixes - Don't handle hotplug events in IRQ handler Andres Calderon Jaramillo (1): drm/i915/display: Prevent double YUV range correction on HDR planes Bhawanpreet Lakha (1): drm/amd/display: reuse current context instead of recreating one Chris Wilson (3): drm/i915/gt: Move the breadcrumb to the signaler if completed upon cancel drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs drm/i915/gem: Drop lru bumping on display unpinning Christian König (1): drm/amdgpu: enable freesync for A+A configs Dave Airlie (4): drm/nouveau: fix dma syncing warning with debugging on. Merge tag 'drm-misc-fixes-2021-02-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.11-2021-02-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-02-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Dmitry Baryshkov (3): drm/bridge/lontium-lt9611uxc: fix waiting for EDID to become available drm/bridge/lontium-lt9611uxc: fix get_edid return code drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler George Shen (1): drm/amd/display: Fix DPCD translation for LTTPR AUX_RD_INTERVAL Huang Rui (2): drm/amdgpu: fix the issue that retry constantly once the buffer is oversize drm/amdkfd: fix null pointer panic while free buffer in kfd Imre Deak (4): drm/dp/mst: Export drm_dp_get_vc_payload_bw() drm/i915: Fix the MST PBN divider calculation drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode Michel Dänzer (1): drm/ttm: Use __GFP_NOWARN for huge pages in ttm_pool_alloc_page Mikita Lipski (1): drm/amd/display: Release DSC before acquiring Stylon Wang (1): drm/amd/display: Revert "Fix EDID parsing after resume from suspend" Sung Lee (1): drm/amd/display: Add more Clock Sources to DCN2.1 Victor Lu (3): drm/amd/display: Fix dc_sink kref count in emulated_link_detect drm/amd/display: Free atomic state after drm_atomic_commit drm/amd/display: Decrement refcount of dc_sink before reassignment Ville Syrjälä (3): drm/i915: Skip vswing programming for TBT drm/i915: Extract intel_ddi_power_up_lanes() drm/i915: Power up combo PHY lanes for for HDMI as well Xiaojian Du (1): drm/amd/pm: fill in the data
[PATCH] drm/vmwgfx: add some 16:9 / 16:10 default resolutions
The default list was old and in particular lacking all common 16:9
resolutions, as well as some newer 16:10 ones.
This makes them selectable in resolution change lists, which can be
quite useful (for instance in case auto-fit isn't enabled).
Signed-off-by: Roland Scheidegger
Reviewed-by: Martin Krastev
Reviewed-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b90b3fb16937..60f095511f09 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2057,6 +2057,10 @@ static struct drm_display_mode
vmw_kms_connector_builtin[] = {
{ DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 108000, 1152, 1216,
1344, 1600, 0, 864, 865, 868, 900, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 1280x720@60Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74500, 1280, 1344,
+ 1472, 1664, 0, 720, 723, 728, 748, 0,
+ DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x768@60Hz */
{ DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
1472, 1664, 0, 768, 771, 778, 798, 0,
@@ -2101,6 +2105,10 @@ static struct drm_display_mode
vmw_kms_connector_builtin[] = {
{ DRM_MODE("1856x1392", DRM_MODE_TYPE_DRIVER, 218250, 1856, 1952,
2176, 2528, 0, 1392, 1393, 1396, 1439, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 1920x1080@60Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 173000, 1920, 2048,
+ 2248, 2576, 0, 1080, 1083, 1088, 1120, 0,
+ DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1920x1200@60Hz */
{ DRM_MODE("1920x1200", DRM_MODE_TYPE_DRIVER, 193250, 1920, 2056,
2256, 2592, 0, 1200, 1203, 1209, 1245, 0,
@@ -2109,10 +2117,26 @@ static struct drm_display_mode
vmw_kms_connector_builtin[] = {
{ DRM_MODE("1920x1440", DRM_MODE_TYPE_DRIVER, 234000, 1920, 2048,
2256, 2600, 0, 1440, 1441, 1444, 1500, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 2560x1440@60Hz */
+ { DRM_MODE("2560x1440", DRM_MODE_TYPE_DRIVER, 241500, 2560, 2608,
+ 2640, 2720, 0, 1440, 1443, 1448, 1481, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 2560x1600@60Hz */
{ DRM_MODE("2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2752,
3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+ /* 2880x1800@60Hz */
+ { DRM_MODE("2880x1800", DRM_MODE_TYPE_DRIVER, 337500, 2880, 2928,
+ 2960, 3040, 0, 1800, 1803, 1809, 1852, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 3840x2160@60Hz */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 533000, 3840, 3888,
+ 3920, 4000, 0, 2160, 2163, 2168, , 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 3840x2400@60Hz */
+ { DRM_MODE("3840x2400", DRM_MODE_TYPE_DRIVER, 592250, 3840, 3888,
+ 3920, 4000, 0, 2400, 2403, 2409, 2469, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* Terminate */
{ DRM_MODE("", 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) },
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v2 3/3] configure: Add check for the presence of DRM headers
Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
that are installed by either the kernel-header or the libdrm package.
The installation is optional and the location is not unique.
Check the presence of the headers at both the standard locations and
any location defined by custom libdrm installation. If the headers
are missing, the dmabuf allocation routines are replaced by stubs that
return suitable error to allow the related tests to skip.
Signed-off-by: Jianxin Xiong
---
CMakeLists.txt | 15 +++
pyverbs/CMakeLists.txt | 14 --
pyverbs/dmabuf_alloc.c | 8
pyverbs/dmabuf_alloc_stub.c | 39 +++
4 files changed, 70 insertions(+), 6 deletions(-)
create mode 100644 pyverbs/dmabuf_alloc_stub.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4113423..95aec11 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -515,6 +515,21 @@ find_package(Systemd)
include_directories(${SYSTEMD_INCLUDE_DIRS})
RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
+# drm headers
+
+# First check the standard locations. The headers could have been installed
+# by either the kernle-headers package or the libdrm package.
+find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")
+
+# Then check custom installation of libdrm
+if (NOT DRM_INCLUDE_DIRS)
+ pkg_check_modules(DRM libdrm)
+endif()
+
+if (DRM_INCLUDE_DIRS)
+ include_directories(${DRM_INCLUDE_DIRS})
+endif()
+
#-
# Apply fixups
diff --git a/pyverbs/CMakeLists.txt b/pyverbs/CMakeLists.txt
index 6fd7625..922253f 100644
--- a/pyverbs/CMakeLists.txt
+++ b/pyverbs/CMakeLists.txt
@@ -13,8 +13,6 @@ rdma_cython_module(pyverbs ""
cmid.pyx
cq.pyx
device.pyx
- dmabuf.pyx
- dmabuf_alloc.c
enums.pyx
mem_alloc.pyx
mr.pyx
@@ -25,6 +23,18 @@ rdma_cython_module(pyverbs ""
xrcd.pyx
)
+if (DRM_INCLUDE_DIRS)
+rdma_cython_module(pyverbs ""
+ dmabuf.pyx
+ dmabuf_alloc.c
+)
+else()
+rdma_cython_module(pyverbs ""
+ dmabuf.pyx
+ dmabuf_alloc_stub.c
+)
+endif()
+
rdma_python_module(pyverbs
__init__.py
pyverbs_error.py
diff --git a/pyverbs/dmabuf_alloc.c b/pyverbs/dmabuf_alloc.c
index 85ffb7a..9978a5b 100644
--- a/pyverbs/dmabuf_alloc.c
+++ b/pyverbs/dmabuf_alloc.c
@@ -9,12 +9,12 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
#include
+#include
+#include
+#include
+#include
#include "dmabuf_alloc.h"
/*
diff --git a/pyverbs/dmabuf_alloc_stub.c b/pyverbs/dmabuf_alloc_stub.c
new file mode 100644
index 000..a73a5da
--- /dev/null
+++ b/pyverbs/dmabuf_alloc_stub.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
+/*
+ * Copyright 2021 Intel Corporation. All rights reserved. See COPYING file
+ */
+
+#include
+#include
+#include
+#include "dmabuf_alloc.h"
+
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt)
+{
+ errno = EOPNOTSUPP;
+ return NULL;
+}
+
+void dmabuf_free(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+}
+
+int dmabuf_get_drm_fd(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
+int dmabuf_get_fd(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
+uint64_t dmabuf_get_offset(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v2 1/3] verbs: Fix gcc warnings when building for 32bit systems
Commit 6b0a3238289f ("verbs: Support dma-buf based memory region") caused
a build failure when building for 32b systems with gcc:
$ mkdir build && cd build && CFLAGS="-m32" cmake -GNinja .. \
-DIOCTL_MODE=both -DNO_PYVERBS=1 -DENABLE_WERROR=1 && ninja
...
../libibverbs/cmd_mr.c: In function 'ibv_cmd_reg_dmabuf_mr':
../libibverbs/cmd_mr.c:152:21: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
vmr->ibv_mr.addr = (void *)offset;
...
../libibverbs/verbs.c: In function 'ibv_reg_dmabuf_mr':
../libibverbs/verbs.c:387:13: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
mr->addr = (void *)offset;
...
Reported-by: Ali Alnubani
Signed-off-by: Jianxin Xiong
---
libibverbs/cmd_mr.c | 2 +-
libibverbs/verbs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index af0fad7..736fce0 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -149,7 +149,7 @@ int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t
offset, size_t length,
vmr->ibv_mr.lkey = lkey;
vmr->ibv_mr.rkey = rkey;
vmr->ibv_mr.pd = pd;
- vmr->ibv_mr.addr = (void *)offset;
+ vmr->ibv_mr.addr = (void *)(uintptr_t)offset;
vmr->ibv_mr.length = length;
vmr->mr_type = IBV_MR_TYPE_DMABUF_MR;
return 0;
diff --git a/libibverbs/verbs.c b/libibverbs/verbs.c
index b93046a..f95 100644
--- a/libibverbs/verbs.c
+++ b/libibverbs/verbs.c
@@ -384,7 +384,7 @@ struct ibv_mr *ibv_reg_dmabuf_mr(struct ibv_pd *pd,
uint64_t offset,
mr->context = pd->context;
mr->pd = pd;
- mr->addr = (void *)offset;
+ mr->addr = (void *)(uintptr_t)offset;
mr->length = length;
return mr;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v2 2/3] pyverbs, tests: Cosmetic improvements for dma-buf allocation routines
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
Reviewed-by: John Hubbard
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
tests/test_mr.py | 78 +-
5 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/pyverbs/dmabuf.pyx b/pyverbs/dmabuf.pyx
index b9406bd..591c4e8 100644
--- a/pyverbs/dmabuf.pyx
+++ b/pyverbs/dmabuf.pyx
@@ -12,7 +12,7 @@ from pyverbs.mr cimport DmaBufMR
cdef extern from "dmabuf_alloc.h":
cdef struct dmabuf:
pass
-dmabuf *dmabuf_alloc(unsigned long size, int unit, int gtt)
+dmabuf *dmabuf_alloc(unsigned long size, int gpu, int gtt)
void dmabuf_free(dmabuf *dmabuf)
int dmabuf_get_drm_fd(dmabuf *dmabuf)
int dmabuf_get_fd(dmabuf *dmabuf)
@@ -20,20 +20,20 @@ cdef extern from "dmabuf_alloc.h":
cdef class DmaBuf:
-def __init__(self, size, unit=0, gtt=0):
+def __init__(self, size, gpu=0, gtt=0):
"""
Allocate DmaBuf object from a GPU device. This is done through the
DRI device interface. Usually this requires the effective user id
being a member of the 'render' group.
:param size: The size (in number of bytes) of the buffer.
-:param unit: The unit number of the GPU to allocate the buffer from.
-:param gtt: Allocate from GTT instead of VRAM.
+:param gpu: The GPU unit to allocate the buffer from.
+:param gtt: Allocate from GTT (Graphics Translation Table) instead of
VRAM.
:return: The newly created DmaBuf object on success.
"""
self.dmabuf_mrs = weakref.WeakSet()
-self.dmabuf = dmabuf_alloc(size, unit, gtt)
+self.dmabuf = dmabuf_alloc(size, gpu, gtt)
if self.dmabuf == NULL:
-raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on unit {unit}')
+raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on gpu {gpu}')
self.drm_fd = dmabuf_get_drm_fd(self.dmabuf)
self.fd = dmabuf_get_fd(self.dmabuf)
self.map_offset = dmabuf_get_offset(self.dmabuf)
diff --git a/pyverbs/dmabuf_alloc.c b/pyverbs/dmabuf_alloc.c
index 05eae75..85ffb7a 100644
--- a/pyverbs/dmabuf_alloc.c
+++ b/pyverbs/dmabuf_alloc.c
@@ -95,7 +95,7 @@ static int amdgpu_mmap_offset(struct drm *drm, uint32_t
handle,
return 0;
}
-static struct drm *drm_open(int unit)
+static struct drm *drm_open(int gpu)
{
char path[32];
struct drm_version version = {};
@@ -107,7 +107,7 @@ static struct drm *drm_open(int unit)
if (!drm)
return NULL;
- snprintf(path, sizeof(path), "/dev/dri/renderD%d", unit + 128);
+ snprintf(path, sizeof(path), "/dev/dri/renderD%d", gpu + 128);
drm->fd = open(path, O_RDWR);
if (drm->fd < 0)
@@ -204,10 +204,10 @@ struct dmabuf {
/*
* dmabuf_alloc - allocate a dmabuf from GPU
* @size - byte size of the buffer to allocate
- * @unit - the GPU unit to use
- * @gtt - if true, allocate from GTT instead of VRAM
+ * @gpu - the GPU unit to use
+ * @gtt - if true, allocate from GTT (Graphics Translation Table) instead of
VRAM
*/
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt)
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt)
{
struct dmabuf *dmabuf;
int err;
@@ -216,7 +216,7 @@ struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int
gtt)
if (!dmabuf)
return NULL;
- dmabuf->drm = drm_open(unit);
+ dmabuf->drm = drm_open(gpu);
if (!dmabuf->drm)
goto out_free;
diff --git a/pyverbs/dmabuf_alloc.h b/pyverbs/dmabuf_alloc.h
index f1b03c5..4698b11 100644
--- a/pyverbs/dmabuf_alloc.h
+++ b/pyverbs/dmabuf_alloc.h
@@ -10,7 +10,7 @@
struct dmabuf;
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt);
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt);
void dmabuf_free(struct dmabuf *dmabuf);
int dmabuf_get_drm_fd(struct dmabuf *dmabuf);
int dmabuf_get_fd(struct dmabuf *dmabuf);
diff --git a/pyverbs/mr.pyx b/pyverbs/mr.pyx
index aad47e2..d05d044 100644
--- a/pyverbs/mr.pyx
+++ b/pyverbs/mr.pyx
@@ -384,7 +384,7 @@ cdef class DMMR(MR):
cdef class DmaBufMR(MR):
def __init__(self, PD pd not None, length, access, DmaBuf dmabuf=None,
- offset=0, unit=0, gtt=0):
+ offset=0, gpu=0, gtt=0):
"""
Initializes a DmaBufMR (DMA-BUF Memory Region) of the given length
and access flags using the given PD and DmaBuf objects.
@@ -393,14 +393,14 @@ cdef class DmaBufMR(MR):
:param access: Access flags, see ibv_access_flags enum
:param dmabuf: A DmaBuf object. One will be allocated if absent
:param offset: Byte offset from the beginning of the dma-buf
-:param unit: GPU
[PATCH rdma-core v2 0/3] Dma-buf related fixes
This is the second version of the patch series. Change log: v2: * Use pgk_check_modules() to check libdrm configuration instead of calling pkg-config directly * Put all the DRM header checking logic in CMakeLists.txt * Use a seperate source file for dma-buf allocation stubs * Remove the definition of HAVE_DRM_H from config.h * Add space between the acronym and the full name v1: https://www.spinics.net/lists/linux-rdma/msg99815.html * Fix compilation warnings for 32bit builds * Cosmetic improvement for dma-buf allocation routines * Add check for DRM headers This series fixes a few issues related to the dma-buf support. It consists of three patches. The first patch fixes a compilation warning for 32-bit builds. Patch 2 renames a function parameter and adds full name to an acronym. Patch 3 adds check for DRM headers. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/942 Jianxin Xiong (3): verbs: Fix gcc warnings when building for 32bit systems pyverbs,tests: Cosmetic improvements for dma-buf allocation routines configure: Add check for the presence of DRM headers CMakeLists.txt | 15 + libibverbs/cmd_mr.c | 2 +- libibverbs/verbs.c | 2 +- pyverbs/CMakeLists.txt | 14 ++-- pyverbs/dmabuf.pyx | 12 +++ pyverbs/dmabuf_alloc.c | 20 ++-- pyverbs/dmabuf_alloc.h | 2 +- pyverbs/dmabuf_alloc_stub.c | 39 +++ pyverbs/mr.pyx | 6 ++-- tests/test_mr.py| 78 ++--- 10 files changed, 127 insertions(+), 63 deletions(-) create mode 100644 pyverbs/dmabuf_alloc_stub.c -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/disp/mdp5: mdp5_cfg: Fix msm8974v2 max_clk
On 2021-02-03 15:15, Konrad Dybcio wrote:
The maximum mdp clock rate on msm8974v2 is 320MHz. Fix it.
Signed-off-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index dfffd9cf0613..bd07d2e1ad90 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -177,7 +177,7 @@ static const struct mdp5_cfg_hw msm8x74v2_config =
{
[3] = INTF_HDMI,
},
},
- .max_clk = 2,
+ .max_clk = 32000,
};
static const struct mdp5_cfg_hw apq8084_config = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, amdkfd drm-next-5.12
On Thu, 4 Feb 2021 at 14:57, Alex Deucher wrote: > > Hi Dave, Daniel, > > More fixes for 5.12. Same PR from last week with the issue Felix reported > fixed and a few more additional fixes on top. > > The following changes since commit a6b8720c2f85143561c3453e1cf928a2f8586ac0: > > Merge tag 'amd-drm-next-5.12-2021-01-20' of > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-01-20 13:08:18 > +0100) > This brought an arm32 warning with it, I've applied Arnd's patch to drm-next to fix it. https://patchwork.freedesktop.org/patch/msgid/20210125124849.102037-1-a...@kernel.org However that function has an ifdef around an ifdef that probably could do with cleaning up. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
On 2/4/21 11:29 PM, Laurent Pinchart wrote: Hi Jagan, Thank you for the patch. On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote: SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from Texas Instruments. SN65DSI83, SN65DSI85 are variants of the same family of bridge controllers. Right now the bridge driver is supporting a single link, dual-link support requires to initiate I2C Channel B registers. MArek Vasut (on CC) has very recently posted a driver for the SN65DSI86. Should the two drivers be merged together ? Since Jagan's V1 was out first, I will let Jagan pick whatever might be useful from the driver I posted, probably the O(1) clock rate calculation and some of the regmap stuff, and once there is some merged result, I am happy to test it on my hardware. The DSI83 is I think the same as DSI84, except with half of the channels. [...] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-core 2/3] pyverbs,tests: Cosmetic improvements for dma-buf allocation routines
On 2/4/21 10:50 AM, Jianxin Xiong wrote:
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
tests/test_mr.py | 78 +-
5 files changed, 55 insertions(+), 55 deletions(-)
Looks good!
If you care, you might want to add a space, like this, to the few GTT cases:
GTT (Graphics Translation Table)
Obviously not worth spinning another version for that, as it is still readable
as-is. Just mentioning it for the sake of pointless perfectionism, and in case
someone ever wonders why it was missed during a review. :) Either way, feel free
to add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff --git a/pyverbs/dmabuf.pyx b/pyverbs/dmabuf.pyx
index b9406bd..9ed7f02 100644
--- a/pyverbs/dmabuf.pyx
+++ b/pyverbs/dmabuf.pyx
@@ -12,7 +12,7 @@ from pyverbs.mr cimport DmaBufMR
cdef extern from "dmabuf_alloc.h":
cdef struct dmabuf:
pass
-dmabuf *dmabuf_alloc(unsigned long size, int unit, int gtt)
+dmabuf *dmabuf_alloc(unsigned long size, int gpu, int gtt)
void dmabuf_free(dmabuf *dmabuf)
int dmabuf_get_drm_fd(dmabuf *dmabuf)
int dmabuf_get_fd(dmabuf *dmabuf)
@@ -20,20 +20,20 @@ cdef extern from "dmabuf_alloc.h":
cdef class DmaBuf:
-def __init__(self, size, unit=0, gtt=0):
+def __init__(self, size, gpu=0, gtt=0):
"""
Allocate DmaBuf object from a GPU device. This is done through the
DRI device interface. Usually this requires the effective user id
being a member of the 'render' group.
:param size: The size (in number of bytes) of the buffer.
-:param unit: The unit number of the GPU to allocate the buffer from.
-:param gtt: Allocate from GTT instead of VRAM.
+:param gpu: The GPU unit to allocate the buffer from.
+:param gtt: Allocate from GTT(Graphics Translation Table) instead of
VRAM.
:return: The newly created DmaBuf object on success.
"""
self.dmabuf_mrs = weakref.WeakSet()
-self.dmabuf = dmabuf_alloc(size, unit, gtt)
+self.dmabuf = dmabuf_alloc(size, gpu, gtt)
if self.dmabuf == NULL:
-raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on unit {unit}')
+raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on gpu {gpu}')
self.drm_fd = dmabuf_get_drm_fd(self.dmabuf)
self.fd = dmabuf_get_fd(self.dmabuf)
self.map_offset = dmabuf_get_offset(self.dmabuf)
diff --git a/pyverbs/dmabuf_alloc.c b/pyverbs/dmabuf_alloc.c
index 05eae75..93267bf 100644
--- a/pyverbs/dmabuf_alloc.c
+++ b/pyverbs/dmabuf_alloc.c
@@ -95,7 +95,7 @@ static int amdgpu_mmap_offset(struct drm *drm, uint32_t
handle,
return 0;
}
-static struct drm *drm_open(int unit)
+static struct drm *drm_open(int gpu)
{
char path[32];
struct drm_version version = {};
@@ -107,7 +107,7 @@ static struct drm *drm_open(int unit)
if (!drm)
return NULL;
- snprintf(path, sizeof(path), "/dev/dri/renderD%d", unit + 128);
+ snprintf(path, sizeof(path), "/dev/dri/renderD%d", gpu + 128);
drm->fd = open(path, O_RDWR);
if (drm->fd < 0)
@@ -204,10 +204,10 @@ struct dmabuf {
/*
* dmabuf_alloc - allocate a dmabuf from GPU
* @size - byte size of the buffer to allocate
- * @unit - the GPU unit to use
- * @gtt - if true, allocate from GTT instead of VRAM
+ * @gpu - the GPU unit to use
+ * @gtt - if true, allocate from GTT(Graphics Translation Table) instead of
VRAM
*/
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt)
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt)
{
struct dmabuf *dmabuf;
int err;
@@ -216,7 +216,7 @@ struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int
gtt)
if (!dmabuf)
return NULL;
- dmabuf->drm = drm_open(unit);
+ dmabuf->drm = drm_open(gpu);
if (!dmabuf->drm)
goto out_free;
diff --git a/pyverbs/dmabuf_alloc.h b/pyverbs/dmabuf_alloc.h
index f1b03c5..4698b11 100644
--- a/pyverbs/dmabuf_alloc.h
+++ b/pyverbs/dmabuf_alloc.h
@@ -10,7 +10,7 @@
struct dmabuf;
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt);
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt);
void dmabuf_free(struct dmabuf *dmabuf);
int dmabuf_get_drm_fd(struct dmabuf *dmabuf);
int dmabuf_get_fd(struct dmabuf *dmabuf);
diff --git a/pyverbs/mr.pyx b/pyverbs/mr.pyx
index aad47e2..d05d044 100644
--- a/pyverbs/mr.pyx
+++ b/pyverbs/mr.pyx
@@ -384,7 +384,7 @@ cdef class DMMR(MR):
cdef class DmaBufMR(MR):
def __init__(self, PD pd not None, length, access, DmaBuf dmabuf=None,
- offset=0,
[PATCH] drm/msm: Fix legacy relocs path
From: Rob Clark
In moving code around, we ended up using the same pointer to
copy_from_user() the relocs tables as we used for the cmd table
entry, which is clearly not right. This went unnoticed because
modern mesa on non-ancent kernels does not actually use relocs.
But this broke ancient mesa on modern kernels.
Reported-by: Emil Velikov
Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index d04c349d8112..5480852bdeda 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -198,6 +198,8 @@ static int submit_lookup_cmds(struct msm_gem_submit *submit,
submit->cmd[i].idx = submit_cmd.submit_idx;
submit->cmd[i].nr_relocs = submit_cmd.nr_relocs;
+ userptr = u64_to_user_ptr(submit_cmd.relocs);
+
sz = array_size(submit_cmd.nr_relocs,
sizeof(struct drm_msm_gem_submit_reloc));
/* check for overflow: */
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
Hi Jagan, Thank you for the patch. On Wed, Feb 03, 2021 at 12:42:56PM +0530, Jagan Teki wrote: > SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from > Texas Instruments. > > SN65DSI83, SN65DSI85 are variants of the same family of bridge > controllers. > > Right now the bridge driver is supporting a single link, dual-link > support requires to initiate I2C Channel B registers. MArek Vasut (on CC) has very recently posted a driver for the SN65DSI86. Should the two drivers be merged together ? > Tested with STM32MP1 MIPI DSI host design configuration. > > Signed-off-by: Jagan Teki > --- > Changes for v2: > - dropped the mdelays between commands as delays in init script in > datasheet is based Aardvark I2C host adaptor. > https://e2e.ti.com/support/interface/f/138/t/974276 > > MAINTAINERS | 6 + > drivers/gpu/drm/bridge/Kconfig| 19 ++ > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ti-sn65dsi84.c | 457 ++ > 4 files changed, 483 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi84.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 12dd1fff2a39..44750ff7640c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5984,6 +5984,12 @@ S: Maintained > F: Documentation/devicetree/bindings/display/ti/ > F: drivers/gpu/drm/omapdrm/ > > +DRM DRIVERS FOR TI SN65DSI84 DSI TO LVDS BRIDGE > +M: Jagan Teki > +S: Maintained > +F: Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml > +F: drivers/gpu/drm/bridge/ti-sn65dsi84.c > + > DRM DRIVERS FOR V3D > M: Eric Anholt > S: Supported > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index e4110d6ca7b3..6494881bffb3 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -232,6 +232,25 @@ config DRM_TI_TFP410 > help > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > +config DRM_TI_SN65DSI84 > + tristate "TI SN65DSI84 DSI to LVDS bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + select DRM_MIPI_DSI > + help > + Texas Instruments SN65DSI84 Single Channel DSI to Dual-link LVDS > + bridge driver. > + > + Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and > + converts the formatted video data stream to a FlatLink compatible > + LVDS output operating at pixel clocks operating from 25 MHx to > + 154 MHz. > + > + SN65DSI84 offers a Dual-Link LVDS, Single-Link LVDS interface with > + four data lanes per link. > + > config DRM_TI_SN65DSI86 > tristate "TI SN65DSI86 DSI to eDP bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 86e7acc76f8d..3906052ef639 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > +obj-$(CONFIG_DRM_TI_SN65DSI84) += ti-sn65dsi84.o > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi84.c > b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > new file mode 100644 > index ..27a9074db17e > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > @@ -0,0 +1,457 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2021 Engicam srl > + * Copyright (C) 2021 Amarula Solutions(India) > + * Author: Jagan Teki > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +/* sn65dsi84 registers */ > +#define SN65DSI_SOFT_RESET 0x09 > +#define SN65DSI_LVDS_CLK 0x0a > +#define SN65DSI_CLK_DIV 0x0b > +#define SN65DSI_CLK_PLL 0x0d > +#define SN65DSI_DSI_CFG 0x10 > +#define SN65DSI_DSI_CLK_EQ 0x11 > +#define SN65DSI_DSI_CLK_RANGE0x12 > +#define SN65DSI_LVDS_MODE0x18 > +#define SN65DSI_CHA_LINE_LO 0x20 > +#define SN65DSI_CHA_LINE_HI 0x21 > +#define SN65DSI_CHA_VIRT_LO 0x24 > +#define SN65DSI_CHA_VIRT_HI 0x25 > +#define SN65DSI_CHA_SYNC_DELAY_LO0x28 > +#define SN65DSI_CHA_SYNC_DELAY_HI0x29 > +#define SN65DSI_CHA_HSYNC_WIDTH_LO 0x2c > +#define SN65DSI_CHA_HSYNC_WIDTH_HI 0x2d > +#define SN65DSI_CHA_VSYNC_WIDTH_LO 0x30 > +#define SN65DSI_CHA_VSYNC_WIDTH_HI 0x31 > +#define SN65DSI_CHA_HBACK_PORCH 0x34 > +#define SN65DSI_CHA_VBACK_PORCH 0x36 > +#define SN65DSI_CHA_HFRONT_PORCH 0x38 > +#define SN65DSI_CHA_VFRONT_PORCH 0x3a >
Re: [PATCH] drm/bridge: anx7625: enable DSI EOTP
On Thu, Feb 4, 2021 at 8:59 PM Andrzej Hajda wrote:
>
>
> W dniu 04.02.2021 o 13:34, Nicolas Boichat pisze:
> > On Thu, Feb 4, 2021 at 8:07 PM Robert Foss wrote:
> >> Hi Xin,
> >>
> >> Thanks for the patch.
> >>
> >> On Thu, 28 Jan 2021 at 12:17, Xin Ji wrote:
> >>> Enable DSI EOTP feature for fixing some panel screen constance
> >>> shift issue.
> >>> Removing MIPI flag MIPI_DSI_MODE_EOT_PACKET to enable DSI EOTP.
> >> I don't think I quite understand how removing the
> >> MIPI_DSI_MODE_EOT_PACKET flag will cause DSI EOTP to be enabled. Could
> >> you extrapolate on this in the commit message?
> > That confused me as well, but it turns out that's how the flag is defined:
> > ```
> > /* disable EoT packets in HS mode */
> > #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> > ```
> > (https://protect2.fireeye.com/v1/url?k=5bd95ebd-044267fb-5bd8d5f2-0cc47a3003e8-ce9db8ea264d6901=1=900556dc-d199-4c18-9432-5c3465a98eae=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Finclude%2Fdrm%2Fdrm_mipi_dsi.h%23L129)
> >
> > I'm almost tempted to put together a mass patch to rename all of these
> > flags...
>
>
> Yes that would be good, many of these flags were just copy pasted from
> some hw datasheet, without good analysis how to adapt them to the framework.
I'll look into it (but that shouldn't block this patch).
>
>
> Regards
>
> Andrzej
>
>
> >
> >>> Signed-off-by: Xin Ji
> >>> ---
> >>> drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
> >>> 1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> >>> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> >>> index 65cc059..e31eeb1b 100644
> >>> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> >>> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> >>> @@ -1334,7 +1334,6 @@ static int anx7625_attach_dsi(struct anx7625_data
> >>> *ctx)
> >>> dsi->format = MIPI_DSI_FMT_RGB888;
> >>> dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> >>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> >>> - MIPI_DSI_MODE_EOT_PACKET|
> >>> MIPI_DSI_MODE_VIDEO_HSE;
> >>>
> >>> if (mipi_dsi_attach(dsi) < 0) {
> >>> --
> >>> 2.7.4
> >>>
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://protect2.fireeye.com/v1/url?k=457f3f39-1ae4067f-457eb476-0cc47a3003e8-b702072da729d8c9=1=900556dc-d199-4c18-9432-5c3465a98eae=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH rdma-core 3/3] configure: Add check for the presence of DRM headers
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, February 04, 2021 1:12 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> ; Edward Srouji ; Yishai Hadas
> ; John Hubbard
> ; Ali Alnubani ; Gal Pressman
> ; Emil Velikov
>
> Subject: Re: [PATCH rdma-core 3/3] configure: Add check for the presence of
> DRM headers
>
> On Thu, Feb 04, 2021 at 10:50:51AM -0800, Jianxin Xiong wrote:
> > Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> > that are installed by either the kernel-header or the libdrm package.
> > The installation is optional and the location is not unique.
> >
> > The standard locations (such as /usr/include/drm, /usr/include/libdrm)
> > are checked first. If failed, pkg-config is tried to find the include
> > path of custom libdrm installation. The dmabuf allocation routines now
> > return suitable error when the headers are not available. The related
> > tests will recognize this error code and skip.
> >
> > Signed-off-by: Jianxin Xiong
> > CMakeLists.txt | 7 +++
> > buildlib/Finddrm.cmake | 19 +++
> > buildlib/config.h.in | 2 ++
> > pyverbs/dmabuf_alloc.c | 47
> > ++-
> > 4 files changed, 70 insertions(+), 5 deletions(-) create mode 100644
> > buildlib/Finddrm.cmake
> >
> > diff --git a/CMakeLists.txt b/CMakeLists.txt index 4113423..feaba3a
> > 100644
> > +++ b/CMakeLists.txt
> > @@ -515,6 +515,13 @@ find_package(Systemd)
> > include_directories(${SYSTEMD_INCLUDE_DIRS})
> > RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
> >
> > +# drm headers
> > +find_package(drm)
> > +if (DRM_INCLUDE_DIRS)
> > + include_directories(${DRM_INCLUDE_DIRS})
> > + set(HAVE_DRM_H 1)
> > +endif()
> > +
> > #-
> > # Apply fixups
> >
> > diff --git a/buildlib/Finddrm.cmake b/buildlib/Finddrm.cmake new file
> > mode 100644 index 000..6f8e5f2
> > +++ b/buildlib/Finddrm.cmake
> > @@ -0,0 +1,19 @@
> > +# COPYRIGHT (c) 2021 Intel Corporation.
> > +# Licensed under BSD (MIT variant) or GPLv2. See COPYING.
> > +
> > +# Check standard locations first
> > +find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")
> > +
> > +# Check custom libdrm installation, if any if (NOT DRM_INCLUDE_DIRS)
> > + execute_process(COMMAND pkg-config --cflags-only-I libdrm
> > +OUTPUT_VARIABLE _LIBDRM
> > +RESULT_VARIABLE _LIBDRM_RESULT
> > +ERROR_QUIET)
> > +
> > + if (NOT _LIBDRM_RESULT)
> > +string(REGEX REPLACE "^-I" "" DRM_INCLUDE_DIRS "${_LIBDRM}")
> > + endif()
> > + unset(_LIBDRM)
> > + unset(_LIBDRM_RESULT)
> > +endif()
>
> I think this should be using pkg_check_modules() ??
>
> Look at the NL stuff:
>
> pkg_check_modules(NL libnl-3.0 libnl-route-3.0 REQUIRED)
> include_directories(${NL_INCLUDE_DIRS})
> link_directories(${NL_LIBRARY_DIRS})
>
Yes, this is much simpler than the pkg-config method.
> > +#if HAVE_DRM_H
> > +
>
> Would rather you use cmake to conditionally compile a dmabuf_alloc.c or a
> dmabuf_alloc_stub.c than ifdef the entire file
Sure, will try that.
>
> Jaason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 driver
On 2/4/21 10:10 PM, Doug Anderson wrote:
Hi,
Hi,
[...]
+ regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
Do you need to list REG_RC_RESET as volatile? Specifically you need
to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is
not cached ?
Sorry, I was unclear I guess. I'm suggesting that you add
REG_RC_RESET to the list of volatile ones since I don't see it there.
Ah, yes, it should.
+static const struct regmap_config sn65dsi83_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .rd_table = _readable_table,
+ .wr_table = _writeable_table,
+ .volatile_table = _volatile_table,
+ .cache_type = REGCACHE_RBTREE,
+ .max_register = REG_IRQ_STAT,
+};
I'm curious how much the "readable" and "writable" sections get you.
In theory only the "volatile" should really matter, right?
They are useful when dumping the regs from debugfs regmap registers .
OK, fair enough. When I thought about doing this on sn65dsi86, it
came to be that a better way might be something like:
#define ACC_RO BIT(0)
#define ACC_RW BIT(1)
#define ACC_W1C BIT(2)
#define ACC_WO BIT(3)
u8 reg_acceess[] = {
[0x00] = ACC_RO,
[0x01] = ACC_RO,
...
[0x0a] = ACC_RO | ACC_RW,
[0x0b] = ACC_RW,
[0x0d] = ACC_RW
...
};
The above maps really nicely to the public datasheet and is easy to
validate. Then you can just look up in that array in a constant time
lookup. In other words, "readable" if either RO or RW is set.
"writable" if any of RW, W1C, or WO is set. Everything that's not RW
is volatile (technically you could differentiate between RO things
that are hardcoded and ones that aren't, but you probably don't need
to).
Anyway, feel free to ignore... What you have is fine too.
It might make sense to implement some more generic support for this ^
into the regmap core ? This seems to be a rather common pattern.
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+ /*
+* Reset the chip, pull EN line low for t_reset=10ms,
+* then high for t_en=1ms.
+*/
+ gpiod_set_value(ctx->enable_gpio, 0);
Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
As I understand it:
* If a client calls gpiod_set_value() then the underlying GPIO can
only be one that doesn't sleep.
* If a client calls gpiod_set_value_cansleep() then the underlying
GPIO can be either one that does or doesn't sleep.
* A client is only allowed to call gpiod_set_value_cansleep() if it's
not in interrupt context.
You are definitely not in an interrupt context (right?), so calling
the "cansleep" version has no downsides but allows board designers to
hook up an enable that can sleep.
Linus, can you please confirm this ? I find this hard to believe, since
there are plenty of places in the kernel which use gpiod_set_value()
without the _cansleep, are those problematic then ?
+ usleep_range(1, 11000);
It seems like it would be worth it to read the enable_gpio first? If
it was already 0 maybe you can skip the 10 ms delay? I would imagine
that most of the time the bridge would already be disabled to start?
How do you guarantee the GPIO was LO for 10 mS here? You can sample that
it is LO, but you won't know how long it was LO before this code was
executed.
Ah, true. I guess the best we could do would be keep track of the
GPIO ourselves so that if we were the one to last turn it off we could
avoid the delay.
Does the extra complexity outweigh the benefit of saving those 10mS ?
+ regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
Probably you don't need this? It's the default and in pre-enable you
just reset the chip. Maybe it was needed since you don't flush the
cache in pre-enable?
Have a look at the Example Script in the DSI83 datasheet, this PLL part
is needed.
I think that script is written without the assumption that you have
just reset the chip using the enable GPIO. If you have just reset
with the enable GPIO it shouldn't be needed.
I don't think it hurts anything, so let's keep it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
[+cc Oliver, Pali, Krzysztof]
s/also/Also/ in subject
On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> We are already doing this for all the regular sysfs files on PCI
> devices, but not yet on the legacy io files on the PCI buses. Thus far
> now problem, but in the next patch I want to wire up iomem revoke
> support. That needs the vfs up an running already to make so that
> iomem_get_mapping() works.
s/now problem/no problem/
s/an running/and running/
s/so that/sure that/ ?
iomem_get_mapping() doesn't exist; I don't know what that should be.
> Wire it up exactly like the existing code. Note that
> pci_remove_legacy_files() doesn't need a check since the one for
> pci_bus->legacy_io is sufficient.
I'm not sure exactly what you mean by "the existing code." I could
probably figure it out, but it would save time to mention the existing
function here.
This looks like another instance where we should really apply Oliver's
idea of converting these to attribute_groups [1].
The cover letter mentions options discussed with Greg in [2], but I
don't think the "sysfs_initialized" hack vs attribute_groups was part
of that discussion.
It's not absolutely a show-stopper, but it *is* a shame to extend the
sysfs_initialized hack if attribute_groups could do this more cleanly
and help solve more than one issue.
Bjorn
[1]
https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
[2]
https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
> Signed-off-by: Daniel Vetter
> Cc: Stephen Rothwell
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: Greg Kroah-Hartman
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> ---
> drivers/pci/pci-sysfs.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index fb072f4b3176..0c45b4f7b214 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> {
> int error;
>
> + if (!sysfs_initialized)
> + return;
> +
> b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> GFP_ATOMIC);
> if (!b->legacy_io)
> @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> static int __init pci_sysfs_init(void)
> {
> struct pci_dev *pdev = NULL;
> + struct pci_bus *pbus = NULL;
> int retval;
>
> sysfs_initialized = 1;
> @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> }
> }
>
> + while ((pbus = pci_find_next_bus(pbus)))
> + pci_create_legacy_files(pbus);
> +
> return 0;
> }
> late_initcall(pci_sysfs_init);
> --
> 2.30.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard
On Thursday, February 4th, 2021 at 10:15 PM, James Park wrote: > No, I haven't pushed anything with DRM_BASIC_TYPES_DEFINED yet. I was > just illustrating since DRM_BASIC_TYPES_H would not be a great > choice for a name in this case. This approach looks fine to me too. I'd R-b it. Thanks for your patience. > I'll send a patch tonight (USA time). I have to remember how to do the > git-send-email dance. https://git-send-email.io/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
On Wed, Feb 3, 2021 at 2:51 PM Michael Nazzareno Trimarchi wrote: > > Hi > > On Wed, Feb 3, 2021 at 8:13 AM Jagan Teki wrote: > > > > SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from > > Texas Instruments. > > > > SN65DSI83, SN65DSI85 are variants of the same family of bridge > > controllers. > > > > Right now the bridge driver is supporting a single link, dual-link > > support requires to initiate I2C Channel B registers. > > > > Tested with STM32MP1 MIPI DSI host design configuration. > > > > Signed-off-by: Jagan Teki > > --- > > Changes for v2: > > - dropped the mdelays between commands as delays in init script in > > datasheet is based Aardvark I2C host adaptor. > > https://e2e.ti.com/support/interface/f/138/t/974276 > > > > MAINTAINERS | 6 + > > drivers/gpu/drm/bridge/Kconfig| 19 ++ > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ti-sn65dsi84.c | 457 ++ > > 4 files changed, 483 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 12dd1fff2a39..44750ff7640c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5984,6 +5984,12 @@ S: Maintained > > F: Documentation/devicetree/bindings/display/ti/ > > F: drivers/gpu/drm/omapdrm/ > > > > +DRM DRIVERS FOR TI SN65DSI84 DSI TO LVDS BRIDGE > > +M: Jagan Teki > > +S: Maintained > > +F: Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml > > +F: drivers/gpu/drm/bridge/ti-sn65dsi84.c > > + > > DRM DRIVERS FOR V3D > > M: Eric Anholt > > S: Supported > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index e4110d6ca7b3..6494881bffb3 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -232,6 +232,25 @@ config DRM_TI_TFP410 > > help > > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > > > +config DRM_TI_SN65DSI84 > > + tristate "TI SN65DSI84 DSI to LVDS bridge" > > + depends on OF > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + select DRM_PANEL > > + select DRM_MIPI_DSI > > + help > > + Texas Instruments SN65DSI84 Single Channel DSI to Dual-link LVDS > > + bridge driver. > > + > > + Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and > > + converts the formatted video data stream to a FlatLink compatible > > + LVDS output operating at pixel clocks operating from 25 MHx to > > + 154 MHz. > > + > > + SN65DSI84 offers a Dual-Link LVDS, Single-Link LVDS interface with > > + four data lanes per link. > > + > > config DRM_TI_SN65DSI86 > > tristate "TI SN65DSI86 DSI to eDP bridge" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile > > b/drivers/gpu/drm/bridge/Makefile > > index 86e7acc76f8d..3906052ef639 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > > +obj-$(CONFIG_DRM_TI_SN65DSI84) += ti-sn65dsi84.o > > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > new file mode 100644 > > index ..27a9074db17e > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > @@ -0,0 +1,457 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2021 Engicam srl > > + * Copyright (C) 2021 Amarula Solutions(India) > > + * Author: Jagan Teki > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* sn65dsi84 registers */ > > +#define SN65DSI_SOFT_RESET 0x09 > > +#define SN65DSI_LVDS_CLK 0x0a > > +#define SN65DSI_CLK_DIV0x0b > > +#define SN65DSI_CLK_PLL0x0d > > +#define SN65DSI_DSI_CFG0x10 > > +#define SN65DSI_DSI_CLK_EQ 0x11 > > +#define SN65DSI_DSI_CLK_RANGE 0x12 > > +#define SN65DSI_LVDS_MODE 0x18 > > +#define SN65DSI_CHA_LINE_LO0x20 > > +#define SN65DSI_CHA_LINE_HI0x21 > > +#define SN65DSI_CHA_VIRT_LO0x24 > > +#define SN65DSI_CHA_VIRT_HI0x25 > > +#define SN65DSI_CHA_SYNC_DELAY_LO 0x28 > > +#define SN65DSI_CHA_SYNC_DELAY_HI 0x29 > > +#define SN65DSI_CHA_HSYNC_WIDTH_LO 0x2c > > +#define SN65DSI_CHA_HSYNC_WIDTH_HI 0x2d > > +#define SN65DSI_CHA_VSYNC_WIDTH_LO
Re: [PATCH v2] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard
On Thu, Feb 4, 2021 at 1:07 PM Emil Velikov wrote:
>
> On Thu, 4 Feb 2021 at 18:17, James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 9:37 AM James Park
> > wrote:
> > >
> > > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > > wrote:
> > > >
> > > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > > > At the same time drm.h pulls a lot of unneeded symbols.
> > > >
> > > > Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> > > > declaration of said symbols.
> > > >
> > > > When used on linux - we pull linux/types.h which is used either way.
> > > > On other platforms, BSDs et al, we need a couple of typedefs.
> > > >
> > > > Since those can trigger a warning in some corner-cases*, add some GCC
> > > > magic to silence them. Note that incorrect type redefinitions will still
> > > > be flagged, and the GCC pragma is ignored by other compilers.
> > > >
> > > > *Corner-case:
> > > > If one sets DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
> > > > also using -pedantic _and_ the header lives outside of the standard
> > > > /usr/include (like BSDs normally do).
> > > >
> > > > v2:
> > > > - Add corner-case handling, based on popular demand.
> > > >
> > > > Cc: James Park
> > > > Cc: Pekka Paalanen
> > > > Cc: Simon Ser
> > > > Signed-off-by: Emil Velikov
> > > > ---
> > > > include/uapi/drm/drm.h| 10 ++
> > > > include/uapi/drm/drm_fourcc.h | 29 +
> > > > 2 files changed, 39 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 808b48a93330..cd78950e05ce 100644
> > > > --- a/include/uapi/drm/drm.h
> > > > +++ b/include/uapi/drm/drm.h
> > > > @@ -53,6 +53,15 @@ typedef unsigned int drm_handle_t;
> > > > #include
> > > > #include
> > > > #include
> > > > +
> > > > +/*
> > > > + * When using C99 -pedantic the typedefs will trigger a warning.
> > > > + * If the header is considered a system one (-isystem) those will be
> > > > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > > > + * in a non-system location.
> > > > + */
> > > > +#pragma GCC diagnostic push
> > > > +#pragma GCC diagnostic ignored "-Wpedantic"
> > > > typedef int8_t __s8;
> > > > typedef uint8_t __u8;
> > > > typedef int16_t __s16;
> > > > @@ -63,6 +72,7 @@ typedef int64_t __s64;
> > > > typedef uint64_t __u64;
> > > > typedef size_t __kernel_size_t;
> > > > typedef unsigned long drm_handle_t;
> > > > +#pragma GCC diagnostic pop
> > > >
> > > > #endif
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 6f0628eb13a6..84a1f96cc4ef 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -24,7 +24,36 @@
> > > > #ifndef DRM_FOURCC_H
> > > > #define DRM_FOURCC_H
> > > >
> > > > +/*
> > > > + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do
> > > > not want
> > > > + * to pull drm.h into your application.
> > > > + */
> > > > +#ifdef DRM_FOURCC_STANDALONE
> > > > +#if defined(__linux__)
> > > > +
> > > > +#include
> > > > +
> > > > +#else /* One of the BSDs */
> > > > +
> > > > +#include
> > > > +
> > > > +/*
> > > > + * When using C99 -pedantic the typedefs will trigger a warning.
> > > > + * If the header is considered a system one (-isystem) those will be
> > > > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > > > + * in a non-system location.
> > > > + */
> > > > +#pragma GCC diagnostic push
> > > > +#pragma GCC diagnostic ignored "-Wpedantic"
> > > > +typedef uint32_t __u32;
> > > > +typedef uint64_t __u64;
> > > > +#pragma GCC diagnostic pop
> > > > +
> > > > +#endif /* __linux __ */
> > > > +
> > > > +#else
> > > > #include "drm.h"
> > > > +#endif /* DRM_FOURCC_STANDALONE */
> > > >
> > > > #if defined(__cplusplus)
> > > > extern "C" {
> > > > --
> > > > 2.30.0
> > > >
> > >
> > > I remember reading GCC diagnostic push/pop requires a recent enough
> > > compiler version to be supported, which is pretty old, but I don't
> > > know how old is old enough for Linux headers:
> > > https://github.com/protocolbuffers/protobuf/issues/4156
> > >
> > > Testing snippets in godbolt, I think the pragmas need to be wrapped. MSVC
> > > says:
> > >
> > > warning C4068: unknown pragma 'GCC'
> > >
> /me shakes fist at MSVC - why are you being so silly
>
> > > Also, Clang seems to want -Wtypedef-redefinition, not -Wpedantic. GCC
> > > complains it doesn't know what -Wtypedef-redefinition is, so that
> > > would also need to be wrapped.
> >
> Clang seemed fine here. Must have used a different version or something.
>
> > If we're already conceding copy/paste, then how about inlining my
> > previous header?
> >
> > #ifndef DRM_BASIC_TYPES_DEFINED
> > #define DRM_BASIC_TYPES_DEFINED
> > // Sync modifications between drm.h and drm_fourcc.h
> > ...
> > #endif
> >
> > No compiler games. Valid on all
Re: [PATCH rdma-core 3/3] configure: Add check for the presence of DRM headers
On Thu, Feb 04, 2021 at 10:50:51AM -0800, Jianxin Xiong wrote:
> Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> that are installed by either the kernel-header or the libdrm package.
> The installation is optional and the location is not unique.
>
> The standard locations (such as /usr/include/drm, /usr/include/libdrm)
> are checked first. If failed, pkg-config is tried to find the include
> path of custom libdrm installation. The dmabuf allocation routines now
> return suitable error when the headers are not available. The related
> tests will recognize this error code and skip.
>
> Signed-off-by: Jianxin Xiong
> CMakeLists.txt | 7 +++
> buildlib/Finddrm.cmake | 19 +++
> buildlib/config.h.in | 2 ++
> pyverbs/dmabuf_alloc.c | 47 ++-
> 4 files changed, 70 insertions(+), 5 deletions(-)
> create mode 100644 buildlib/Finddrm.cmake
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 4113423..feaba3a 100644
> +++ b/CMakeLists.txt
> @@ -515,6 +515,13 @@ find_package(Systemd)
> include_directories(${SYSTEMD_INCLUDE_DIRS})
> RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
>
> +# drm headers
> +find_package(drm)
> +if (DRM_INCLUDE_DIRS)
> + include_directories(${DRM_INCLUDE_DIRS})
> + set(HAVE_DRM_H 1)
> +endif()
> +
> #-
> # Apply fixups
>
> diff --git a/buildlib/Finddrm.cmake b/buildlib/Finddrm.cmake
> new file mode 100644
> index 000..6f8e5f2
> +++ b/buildlib/Finddrm.cmake
> @@ -0,0 +1,19 @@
> +# COPYRIGHT (c) 2021 Intel Corporation.
> +# Licensed under BSD (MIT variant) or GPLv2. See COPYING.
> +
> +# Check standard locations first
> +find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")
> +
> +# Check custom libdrm installation, if any
> +if (NOT DRM_INCLUDE_DIRS)
> + execute_process(COMMAND pkg-config --cflags-only-I libdrm
> +OUTPUT_VARIABLE _LIBDRM
> +RESULT_VARIABLE _LIBDRM_RESULT
> +ERROR_QUIET)
> +
> + if (NOT _LIBDRM_RESULT)
> +string(REGEX REPLACE "^-I" "" DRM_INCLUDE_DIRS "${_LIBDRM}")
> + endif()
> + unset(_LIBDRM)
> + unset(_LIBDRM_RESULT)
> +endif()
I think this should be using pkg_check_modules() ??
Look at the NL stuff:
pkg_check_modules(NL libnl-3.0 libnl-route-3.0 REQUIRED)
include_directories(${NL_INCLUDE_DIRS})
link_directories(${NL_LIBRARY_DIRS})
> +#if HAVE_DRM_H
> +
Would rather you use cmake to conditionally compile a dmabuf_alloc.c
or a dmabuf_alloc_stub.c than ifdef the entire file
Jaason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 driver
Hi,
On Thu, Feb 4, 2021 at 10:41 AM Marek Vasut wrote:
>
> >> +static const struct regmap_range sn65dsi83_volatile_ranges[] = {
> >> + regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
> >
> > Why is REG_RC_LVDS_PLL volatile?
>
> See register 0xa bit 7, PLL_EN_STAT .
Wow, I looked at it a few times and still didn't see it. OK, fair enough.
> >> + regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> >
> > Do you need to list REG_RC_RESET as volatile? Specifically you need
> > to make sure it's not cached...
>
> Isn't volatile table exactly for this purpose -- to make sure the reg is
> not cached ?
Sorry, I was unclear I guess. I'm suggesting that you add
REG_RC_RESET to the list of volatile ones since I don't see it there.
> >> +static const struct regmap_config sn65dsi83_regmap_config = {
> >> + .reg_bits = 8,
> >> + .val_bits = 8,
> >> + .rd_table = _readable_table,
> >> + .wr_table = _writeable_table,
> >> + .volatile_table = _volatile_table,
> >> + .cache_type = REGCACHE_RBTREE,
> >> + .max_register = REG_IRQ_STAT,
> >> +};
> >
> > I'm curious how much the "readable" and "writable" sections get you.
> > In theory only the "volatile" should really matter, right?
>
> They are useful when dumping the regs from debugfs regmap registers .
OK, fair enough. When I thought about doing this on sn65dsi86, it
came to be that a better way might be something like:
#define ACC_RO BIT(0)
#define ACC_RW BIT(1)
#define ACC_W1C BIT(2)
#define ACC_WO BIT(3)
u8 reg_acceess[] = {
[0x00] = ACC_RO,
[0x01] = ACC_RO,
...
[0x0a] = ACC_RO | ACC_RW,
[0x0b] = ACC_RW,
[0x0d] = ACC_RW
...
};
The above maps really nicely to the public datasheet and is easy to
validate. Then you can just look up in that array in a constant time
lookup. In other words, "readable" if either RO or RW is set.
"writable" if any of RW, W1C, or WO is set. Everything that's not RW
is volatile (technically you could differentiate between RO things
that are hardcoded and ones that aren't, but you probably don't need
to).
Anyway, feel free to ignore... What you have is fine too.
> >> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
> >> +{
> >> + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >> +
> >> + /*
> >> +* Reset the chip, pull EN line low for t_reset=10ms,
> >> +* then high for t_en=1ms.
> >> +*/
> >> + gpiod_set_value(ctx->enable_gpio, 0);
> >
> > Why not use the "cansleep" version to give some flexibility?
>
> Does that make a difference in non-interrupt context ?
As I understand it:
* If a client calls gpiod_set_value() then the underlying GPIO can
only be one that doesn't sleep.
* If a client calls gpiod_set_value_cansleep() then the underlying
GPIO can be either one that does or doesn't sleep.
* A client is only allowed to call gpiod_set_value_cansleep() if it's
not in interrupt context.
You are definitely not in an interrupt context (right?), so calling
the "cansleep" version has no downsides but allows board designers to
hook up an enable that can sleep.
> >> + usleep_range(1, 11000);
> >
> > It seems like it would be worth it to read the enable_gpio first? If
> > it was already 0 maybe you can skip the 10 ms delay? I would imagine
> > that most of the time the bridge would already be disabled to start?
>
> How do you guarantee the GPIO was LO for 10 mS here? You can sample that
> it is LO, but you won't know how long it was LO before this code was
> executed.
Ah, true. I guess the best we could do would be keep track of the
GPIO ourselves so that if we were the one to last turn it off we could
avoid the delay.
> >> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >
> > Probably you don't need this? It's the default and in pre-enable you
> > just reset the chip. Maybe it was needed since you don't flush the
> > cache in pre-enable?
>
> Have a look at the Example Script in the DSI83 datasheet, this PLL part
> is needed.
I think that script is written without the assumption that you have
just reset the chip using the enable GPIO. If you have just reset
with the enable GPIO it shouldn't be needed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard
On Thu, 4 Feb 2021 at 18:17, James Park wrote:
>
> On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
> >
> > On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov
> > wrote:
> > >
> > > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > > At the same time drm.h pulls a lot of unneeded symbols.
> > >
> > > Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> > > declaration of said symbols.
> > >
> > > When used on linux - we pull linux/types.h which is used either way.
> > > On other platforms, BSDs et al, we need a couple of typedefs.
> > >
> > > Since those can trigger a warning in some corner-cases*, add some GCC
> > > magic to silence them. Note that incorrect type redefinitions will still
> > > be flagged, and the GCC pragma is ignored by other compilers.
> > >
> > > *Corner-case:
> > > If one sets DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
> > > also using -pedantic _and_ the header lives outside of the standard
> > > /usr/include (like BSDs normally do).
> > >
> > > v2:
> > > - Add corner-case handling, based on popular demand.
> > >
> > > Cc: James Park
> > > Cc: Pekka Paalanen
> > > Cc: Simon Ser
> > > Signed-off-by: Emil Velikov
> > > ---
> > > include/uapi/drm/drm.h| 10 ++
> > > include/uapi/drm/drm_fourcc.h | 29 +
> > > 2 files changed, 39 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 808b48a93330..cd78950e05ce 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -53,6 +53,15 @@ typedef unsigned int drm_handle_t;
> > > #include
> > > #include
> > > #include
> > > +
> > > +/*
> > > + * When using C99 -pedantic the typedefs will trigger a warning.
> > > + * If the header is considered a system one (-isystem) those will be
> > > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > > + * in a non-system location.
> > > + */
> > > +#pragma GCC diagnostic push
> > > +#pragma GCC diagnostic ignored "-Wpedantic"
> > > typedef int8_t __s8;
> > > typedef uint8_t __u8;
> > > typedef int16_t __s16;
> > > @@ -63,6 +72,7 @@ typedef int64_t __s64;
> > > typedef uint64_t __u64;
> > > typedef size_t __kernel_size_t;
> > > typedef unsigned long drm_handle_t;
> > > +#pragma GCC diagnostic pop
> > >
> > > #endif
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index 6f0628eb13a6..84a1f96cc4ef 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -24,7 +24,36 @@
> > > #ifndef DRM_FOURCC_H
> > > #define DRM_FOURCC_H
> > >
> > > +/*
> > > + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not
> > > want
> > > + * to pull drm.h into your application.
> > > + */
> > > +#ifdef DRM_FOURCC_STANDALONE
> > > +#if defined(__linux__)
> > > +
> > > +#include
> > > +
> > > +#else /* One of the BSDs */
> > > +
> > > +#include
> > > +
> > > +/*
> > > + * When using C99 -pedantic the typedefs will trigger a warning.
> > > + * If the header is considered a system one (-isystem) those will be
> > > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > > + * in a non-system location.
> > > + */
> > > +#pragma GCC diagnostic push
> > > +#pragma GCC diagnostic ignored "-Wpedantic"
> > > +typedef uint32_t __u32;
> > > +typedef uint64_t __u64;
> > > +#pragma GCC diagnostic pop
> > > +
> > > +#endif /* __linux __ */
> > > +
> > > +#else
> > > #include "drm.h"
> > > +#endif /* DRM_FOURCC_STANDALONE */
> > >
> > > #if defined(__cplusplus)
> > > extern "C" {
> > > --
> > > 2.30.0
> > >
> >
> > I remember reading GCC diagnostic push/pop requires a recent enough
> > compiler version to be supported, which is pretty old, but I don't
> > know how old is old enough for Linux headers:
> > https://github.com/protocolbuffers/protobuf/issues/4156
> >
> > Testing snippets in godbolt, I think the pragmas need to be wrapped. MSVC
> > says:
> >
> > warning C4068: unknown pragma 'GCC'
> >
/me shakes fist at MSVC - why are you being so silly
> > Also, Clang seems to want -Wtypedef-redefinition, not -Wpedantic. GCC
> > complains it doesn't know what -Wtypedef-redefinition is, so that
> > would also need to be wrapped.
>
Clang seemed fine here. Must have used a different version or something.
> If we're already conceding copy/paste, then how about inlining my
> previous header?
>
> #ifndef DRM_BASIC_TYPES_DEFINED
> #define DRM_BASIC_TYPES_DEFINED
> // Sync modifications between drm.h and drm_fourcc.h
> ...
> #endif
>
> No compiler games. Valid on all flavors of C (I think).
Hmm cannot find any patch mentioning DRM_BASIC_TYPES_DEFINED - perhaps
you did one in the mesa MR?
Either way, if the proposal is to have the include/typedefs guarded as
above - sure, that works. Please add the guard in both drm.h and
drm_fourcc.h
The comment seems slightly confusing, but that's nitpicking.
Do send
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote: > On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > > > So I think just checking for VM_PFNMAP after the vma is set up should > > > be enough to guarantee we'll only have pte_special ptes in there, > > > ever. But I'm not sure, this stuff all isn't really documented much > > > and the code is sometimes a maze (to me at least). > > > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > > check after the VMA is populated > > > > But how do you stuff special pfns into a VMA outside the fault > > handler? > > Many drivers we have don't have dynamic buffer management (kinda > overkill for a few framebuffers on a display-only IP block), so the > just remap_pfn_range on ->mmap, and don't have a fault handler at all. remap_pfn_range() makes sense, do you expect drivers using struct page backed memory to call that as well? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"
> On Feb 4, 2021, at 2:06 PM, Thomas Zimmermann wrote: > > Hi Tong > >> I have posted an updated patch. >> The new patch use the following logic >> +if (!qdev->ddev.mode_config.funcs) >> + return; > > This is again just papering over the issue. Better don't call > qxl_drm_release() in the error path if qxl_device_init() fails. > > I see two solutions: either roll-back manually, or use our new managed DRM > interfaces. This is what the other drivers do. > > Best regards > Thomas IMHO - qdev->ddev.mode_config.funcs is set only if the initialization is successful, so using this as an indicator of error case looks ok to me. The other two options you suggested would require some serious significant amount of work to be done, which I don’t think I currently have such ability to do. Thanks, - Tong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > > > So I think just checking for VM_PFNMAP after the vma is set up should > > be enough to guarantee we'll only have pte_special ptes in there, > > ever. But I'm not sure, this stuff all isn't really documented much > > and the code is sometimes a maze (to me at least). > > Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right > check after the VMA is populated > > But how do you stuff special pfns into a VMA outside the fault > handler? Many drivers we have don't have dynamic buffer management (kinda overkill for a few framebuffers on a display-only IP block), so the just remap_pfn_range on ->mmap, and don't have a fault handler at all. Or I'm not understanding what you're asking? -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] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote: > So I think just checking for VM_PFNMAP after the vma is set up should > be enough to guarantee we'll only have pte_special ptes in there, > ever. But I'm not sure, this stuff all isn't really documented much > and the code is sometimes a maze (to me at least). Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right check after the VMA is populated But how do you stuff special pfns into a VMA outside the fault handler? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/udl: Move vmap out of commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 34 ---
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 9d34ec9d03f6..8d98bf69d075 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -266,18 +267,17 @@ static int udl_aligned_damage_clip(struct drm_rect *clip,
int x, int y,
return 0;
}
-static int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
-int width, int height)
+static int udl_handle_damage(struct drm_framebuffer *fb, const struct
dma_buf_map *map,
+int x, int y, int width, int height)
{
struct drm_device *dev = fb->dev;
struct dma_buf_attachment *import_attach = fb->obj[0]->import_attach;
+ void *vaddr = map->vaddr; /* TODO: Use mapping abstraction properly */
int i, ret, tmp_ret;
char *cmd;
struct urb *urb;
struct drm_rect clip;
int log_bpp;
- struct dma_buf_map map;
- void *vaddr;
ret = udl_log_cpp(fb->format->cpp[0]);
if (ret < 0)
@@ -297,17 +297,10 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
return ret;
}
- ret = drm_gem_shmem_vmap(fb->obj[0], );
- if (ret) {
- DRM_ERROR("failed to vmap fb\n");
- goto out_dma_buf_end_cpu_access;
- }
- vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
-
urb = udl_get_urb(dev);
if (!urb) {
ret = -ENOMEM;
- goto out_drm_gem_shmem_vunmap;
+ goto out_dma_buf_end_cpu_access;
}
cmd = urb->transfer_buffer;
@@ -320,7 +313,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
, byte_offset, dev_byte_offset,
byte_width);
if (ret)
- goto out_drm_gem_shmem_vunmap;
+ goto out_dma_buf_end_cpu_access;
}
if (cmd > (char *)urb->transfer_buffer) {
@@ -336,8 +329,6 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
ret = 0;
-out_drm_gem_shmem_vunmap:
- drm_gem_shmem_vunmap(fb->obj[0], );
out_dma_buf_end_cpu_access:
if (import_attach) {
tmp_ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -375,6 +366,7 @@ udl_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = plane_state->fb;
struct udl_device *udl = to_udl(dev);
struct drm_display_mode *mode = _state->mode;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
char *buf;
char *wrptr;
int color_depth = UDL_COLOR_DEPTH_16BPP;
@@ -400,7 +392,7 @@ udl_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
udl->mode_buf_len = wrptr - buf;
- udl_handle_damage(fb, 0, 0, fb->width, fb->height);
+ udl_handle_damage(fb, _plane_state->map[0], 0, 0, fb->width,
fb->height);
if (!crtc_state->mode_changed)
return;
@@ -435,6 +427,7 @@ udl_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_plane_state *old_plane_state)
{
struct drm_plane_state *state = pipe->plane.state;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
@@ -442,17 +435,16 @@ udl_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
return;
if (drm_atomic_helper_damage_merged(old_plane_state, state, ))
- udl_handle_damage(fb, rect.x1, rect.y1, rect.x2 - rect.x1,
- rect.y2 - rect.y1);
+ udl_handle_damage(fb, _plane_state->map[0], rect.x1,
rect.y1,
+ rect.x2 - rect.x1, rect.y2 - rect.y1);
}
-static const
-struct drm_simple_display_pipe_funcs udl_simple_display_pipe_funcs = {
+static const struct drm_simple_display_pipe_funcs
udl_simple_display_pipe_funcs = {
.mode_valid = udl_simple_display_pipe_mode_valid,
.enable = udl_simple_display_pipe_enable,
.disable = udl_simple_display_pipe_disable,
[PATCH 5/6] drm/gm12u320: Move vmap out of commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 33f65f4626e5..0b4f4f2af1ef 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -16,8 +16,9 @@
#include
#include
#include
-#include
+#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,7 @@ struct gm12u320_device {
struct drm_rect rect;
int frame;
int draw_status_timeout;
+ struct dma_buf_map src_map;
} fb_update;
};
@@ -250,7 +252,6 @@ static void gm12u320_copy_fb_to_blocks(struct
gm12u320_device *gm12u320)
{
int block, dst_offset, len, remain, ret, x1, x2, y1, y2;
struct drm_framebuffer *fb;
- struct dma_buf_map map;
void *vaddr;
u8 *src;
@@ -264,20 +265,14 @@ static void gm12u320_copy_fb_to_blocks(struct
gm12u320_device *gm12u320)
x2 = gm12u320->fb_update.rect.x2;
y1 = gm12u320->fb_update.rect.y1;
y2 = gm12u320->fb_update.rect.y2;
-
- ret = drm_gem_shmem_vmap(fb->obj[0], );
- if (ret) {
- GM12U320_ERR("failed to vmap fb: %d\n", ret);
- goto put_fb;
- }
- vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
+ vaddr = gm12u320->fb_update.src_map.vaddr; /* TODO: Use mapping
abstraction properly */
if (fb->obj[0]->import_attach) {
ret = dma_buf_begin_cpu_access(
fb->obj[0]->import_attach->dmabuf, DMA_FROM_DEVICE);
if (ret) {
GM12U320_ERR("dma_buf_begin_cpu_access err: %d\n", ret);
- goto vunmap;
+ goto put_fb;
}
}
@@ -321,8 +316,6 @@ static void gm12u320_copy_fb_to_blocks(struct
gm12u320_device *gm12u320)
if (ret)
GM12U320_ERR("dma_buf_end_cpu_access err: %d\n", ret);
}
-vunmap:
- drm_gem_shmem_vunmap(fb->obj[0], );
put_fb:
drm_framebuffer_put(fb);
gm12u320->fb_update.fb = NULL;
@@ -410,7 +403,7 @@ static void gm12u320_fb_update_work(struct work_struct
*work)
GM12U320_ERR("Frame update error: %d\n", ret);
}
-static void gm12u320_fb_mark_dirty(struct drm_framebuffer *fb,
+static void gm12u320_fb_mark_dirty(struct drm_framebuffer *fb, const struct
dma_buf_map *map,
struct drm_rect *dirty)
{
struct gm12u320_device *gm12u320 = to_gm12u320(fb->dev);
@@ -424,6 +417,7 @@ static void gm12u320_fb_mark_dirty(struct drm_framebuffer
*fb,
drm_framebuffer_get(fb);
gm12u320->fb_update.fb = fb;
gm12u320->fb_update.rect = *dirty;
+ gm12u320->fb_update.src_map = *map;
wakeup = true;
} else {
struct drm_rect *rect = >fb_update.rect;
@@ -452,6 +446,7 @@ static void gm12u320_stop_fb_update(struct gm12u320_device
*gm12u320)
mutex_lock(>fb_update.lock);
old_fb = gm12u320->fb_update.fb;
gm12u320->fb_update.fb = NULL;
+ dma_buf_map_clear(>fb_update.src_map);
mutex_unlock(>fb_update.lock);
drm_framebuffer_put(old_fb);
@@ -564,9 +559,10 @@ static void gm12u320_pipe_enable(struct
drm_simple_display_pipe *pipe,
{
struct drm_rect rect = { 0, 0, GM12U320_USER_WIDTH, GM12U320_HEIGHT };
struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev);
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
gm12u320->fb_update.draw_status_timeout = FIRST_FRAME_TIMEOUT;
- gm12u320_fb_mark_dirty(plane_state->fb, );
+ gm12u320_fb_mark_dirty(plane_state->fb, _plane_state->map[0],
);
}
static void gm12u320_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -580,16 +576,18 @@ static void gm12u320_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_plane_state *old_state)
{
struct drm_plane_state *state = pipe->plane.state;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(state);
struct drm_rect rect;
if (drm_atomic_helper_damage_merged(old_state, state, ))
- gm12u320_fb_mark_dirty(pipe->plane.state->fb, );
+ gm12u320_fb_mark_dirty(state->fb, _plane_state->map[0],
);
}
static const struct
[PATCH 2/6] drm: Add additional atomic helpers for shadow-buffered planes
Several drivers use GEM buffer objects as shadow buffers for the actual
framebuffer memory. Right now, drivers do these vmap operations in their
commit tail, which is actually not allowed by the locking rules for
the dma-buf reservation lock. The involved BO has to be vmapped in the
plane's prepare_fb callback and vunmapped in cleanup_fb.
This patch introduces atomic helpers for such shadow planes. Plane
functions manage the plane state for shadow planes. The provided
implementations for prepare_fb and cleanup_fb vmap and vunmap all BOs of
struct drm_plane_state.fb. The mappings are afterwards available in the
plane's commit-tail functions.
For now, all rsp drivers use the simple KMS helpers, so we add the plane
callbacks and wrappers for simple KMS. The internal plane functions can
late rbe exported as needed.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-kms-helpers.rst | 12 ++
drivers/gpu/drm/Makefile| 3 +-
drivers/gpu/drm/drm_gem_atomic_helper.c | 210
include/drm/drm_gem_atomic_helper.h | 75 +
4 files changed, 299 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_gem_atomic_helper.c
create mode 100644 include/drm/drm_gem_atomic_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index b89ddd06dabb..389892f36185 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -80,6 +80,18 @@ Atomic State Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
+GEM Atomic Helper Reference
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_atomic_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
+ :export:
+
Simple KMS Helper Reference
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 926adef289db..02c229392345 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -44,7 +44,8 @@ drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o
drm_dp_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
- drm_scdc_helper.o drm_gem_framebuffer_helper.o \
+ drm_scdc_helper.o drm_gem_atomic_helper.o \
+ drm_gem_framebuffer_helper.o \
drm_atomic_state_helper.o drm_damage_helper.o \
drm_format_helper.o drm_self_refresh_helper.o
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
new file mode 100644
index ..b6ad2b91a011
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+#include
+
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * The GEM atomic helpers library implements generic atomic-commit
+ * functions for drivers that use GEM objects. Currently, it provides
+ * plane state and framebuffer BO mappings for planes with shadow
+ * buffers.
+ */
+
+/*
+ * Shadow-buffered Planes
+ */
+
+static struct drm_plane_state *
+drm_gem_duplicate_shadow_plane_state(struct drm_plane *plane,
+struct drm_plane_state *plane_state)
+{
+ struct drm_shadow_plane_state *new_shadow_plane_state;
+
+ if (!plane_state)
+ return NULL;
+
+ new_shadow_plane_state = kzalloc(sizeof(*new_shadow_plane_state),
GFP_KERNEL);
+ if (!new_shadow_plane_state)
+ return NULL;
+ __drm_atomic_helper_plane_duplicate_state(plane,
_shadow_plane_state->base);
+
+ return _shadow_plane_state->base;
+}
+
+static void drm_gem_destroy_shadow_plane_state(struct drm_plane *plane,
+ struct drm_plane_state
*plane_state)
+{
+ struct drm_shadow_plane_state *shadow_plane_state =
+ to_drm_shadow_plane_state(plane_state);
+
+ __drm_atomic_helper_plane_destroy_state(_plane_state->base);
+ kfree(shadow_plane_state);
+}
+
+static void drm_gem_reset_shadow_plane(struct drm_plane *plane)
+{
+ struct drm_shadow_plane_state *shadow_plane_state;
+
+ if (plane->state) {
+ drm_gem_destroy_shadow_plane_state(plane, plane->state);
+ plane->state = NULL; /* must be set to NULL here */
+ }
+
+ shadow_plane_state = kzalloc(sizeof(*shadow_plane_state), GFP_KERNEL);
+ if (!shadow_plane_state)
+ return;
+ __drm_atomic_helper_plane_reset(plane, _plane_state->base);
+}
+
+static int drm_gem_prepare_shadow_fb(struct drm_plane *plane, struct
drm_plane_state *plane_state)
+{
+ struct drm_shadow_plane_state
[PATCH 3/6] drm/mgag200: Move vmap out of commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..f871753e898e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1549,22 +1550,12 @@ mgag200_simple_display_pipe_mode_valid(struct
drm_simple_display_pipe *pipe,
static void
mgag200_handle_damage(struct mga_device *mdev, struct drm_framebuffer *fb,
- struct drm_rect *clip)
+ struct drm_rect *clip, const struct dma_buf_map *map)
{
- struct drm_device *dev = >base;
- struct dma_buf_map map;
- void *vmap;
- int ret;
-
- ret = drm_gem_shmem_vmap(fb->obj[0], );
- if (drm_WARN_ON(dev, ret))
- return; /* BUG: SHMEM BO should always be vmapped */
- vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
+ void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
- drm_gem_shmem_vunmap(fb->obj[0], );
-
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
mgag200_set_offset(mdev, fb);
@@ -1580,6 +1571,7 @@ mgag200_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct mga_device *mdev = to_mga_device(dev);
struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_rect fullscreen = {
.x1 = 0,
.x2 = fb->width,
@@ -1608,7 +1600,7 @@ mgag200_simple_display_pipe_enable(struct
drm_simple_display_pipe *pipe,
mga_crtc_load_lut(crtc);
mgag200_enable_display(mdev);
- mgag200_handle_damage(mdev, fb, );
+ mgag200_handle_damage(mdev, fb, ,
_plane_state->map[0]);
}
static void
@@ -1649,6 +1641,7 @@ mgag200_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
struct drm_device *dev = plane->dev;
struct mga_device *mdev = to_mga_device(dev);
struct drm_plane_state *state = plane->state;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct drm_rect damage;
@@ -1656,7 +1649,7 @@ mgag200_simple_display_pipe_update(struct
drm_simple_display_pipe *pipe,
return;
if (drm_atomic_helper_damage_merged(old_state, state, ))
- mgag200_handle_damage(mdev, fb, );
+ mgag200_handle_damage(mdev, fb, ,
_plane_state->map[0]);
}
static const struct drm_simple_display_pipe_funcs
@@ -1666,7 +1659,7 @@ mgag200_simple_display_pipe_funcs = {
.disable= mgag200_simple_display_pipe_disable,
.check = mgag200_simple_display_pipe_check,
.update = mgag200_simple_display_pipe_update,
- .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+ DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,
};
static const uint32_t mgag200_simple_display_pipe_formats[] = {
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers
Several SHMEM-based drivers use the BO as shadow buffer for the real framebuffer memory. Damage handling requires a vmap of the BO memory. But vmap/vunmap can acquire the dma-buf reservation lock, which is not allowed in commit tails. This patchset introduces a set of helpers that implement vmap/vunmap in the plane's prepare_fb and cleanup_fb; and provide the mapping's address to commit-tail functions. Wrappers for simple KMS are provides, as all of the involved drivers are built upon simple-KMS helpers. Patch 1 adds the support for private plane state to the simple-KMS helper library. Patch 2 provides plane state for shadow-buffered planes. It's a DRM plane with BO mappings into kernel address space. The involved helpers take care of the details. The code is independent from GEM SHMEM and can be used with other shadow-buffered planes. I put all this in a new file. In a later patch, drm_gem_fb_prepare_fb() et al could be moved there as well. Patches 3 to 6 convert each involved driver to the new helpers. The vmap operations are being removed from commit-tail functions. An additional benefit is that vmap errors are now detected before the commit starts. The original commit-tail functions could not handle failed vmap operations. I smoke-tested the code by running fbdev, Xorg and weston with the converted mgag200 driver. Thomas Zimmermann (6): drm/simple-kms: Add plane-state helpers drm: Add additional atomic helpers for shadow-buffered planes drm/mgag200: Move vmap out of commit tail drm/cirrus: Move vmap out of commit tail drm/gm12u320: Move vmap out of commit tail drm/udl: Move vmap out of commit tail Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/drm_gem_atomic_helper.c | 210 drivers/gpu/drm/drm_simple_kms_helper.c | 40 - drivers/gpu/drm/mgag200/mgag200_mode.c | 23 +-- drivers/gpu/drm/tiny/cirrus.c | 43 ++--- drivers/gpu/drm/tiny/gm12u320.c | 28 ++-- drivers/gpu/drm/udl/udl_modeset.c | 34 ++-- include/drm/drm_gem_atomic_helper.h | 75 + include/drm/drm_simple_kms_helper.h | 28 10 files changed, 415 insertions(+), 81 deletions(-) create mode 100644 drivers/gpu/drm/drm_gem_atomic_helper.c create mode 100644 include/drm/drm_gem_atomic_helper.h base-commit: f9173d6435c6a9bb0b0076ebf9122d876da208ae prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d prerequisite-patch-id: f8140f08b77c49beb6243d9a2a88ebcc7097e391 prerequisite-patch-id: 6bffaf03d01daeb29a0b0ffbc78b415e72907a17 prerequisite-patch-id: 6386ca949b8b677a7eada2672990dab2f84f734f prerequisite-patch-id: 706e35d0b2185d2332f725e1c22d8ffed910ea7b -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/cirrus: Move vmap out of commit tail
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit tail use the pre-established mapping for damage handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 43 ++-
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index a043e602199e..ad922c3ec681 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -33,8 +33,9 @@
#include
#include
#include
-#include
+#include
#include
+#include
#include
#include
#include
@@ -311,22 +312,15 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
return 0;
}
-static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
+static int cirrus_fb_blit_rect(struct drm_framebuffer *fb, const struct
dma_buf_map *map,
struct drm_rect *rect)
{
struct cirrus_device *cirrus = to_cirrus(fb->dev);
- struct dma_buf_map map;
- void *vmap;
- int idx, ret;
+ void *vmap = map->vaddr; /* TODO: Use mapping abstraction properly */
+ int idx;
- ret = -ENODEV;
if (!drm_dev_enter(>dev, ))
- goto out;
-
- ret = drm_gem_shmem_vmap(fb->obj[0], );
- if (ret)
- goto out_dev_exit;
- vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
+ return -ENODEV;
if (cirrus->cpp == fb->format->cpp[0])
drm_fb_memcpy_dstclip(cirrus->vram,
@@ -345,16 +339,12 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
else
WARN_ON_ONCE("cpp mismatch");
- drm_gem_shmem_vunmap(fb->obj[0], );
- ret = 0;
-
-out_dev_exit:
drm_dev_exit(idx);
-out:
- return ret;
+
+ return 0;
}
-static int cirrus_fb_blit_fullscreen(struct drm_framebuffer *fb)
+static int cirrus_fb_blit_fullscreen(struct drm_framebuffer *fb, const struct
dma_buf_map *map)
{
struct drm_rect fullscreen = {
.x1 = 0,
@@ -362,7 +352,7 @@ static int cirrus_fb_blit_fullscreen(struct drm_framebuffer
*fb)
.y1 = 0,
.y2 = fb->height,
};
- return cirrus_fb_blit_rect(fb, );
+ return cirrus_fb_blit_rect(fb, map, );
}
static int cirrus_check_size(int width, int height,
@@ -441,9 +431,10 @@ static void cirrus_pipe_enable(struct
drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
cirrus_mode_set(cirrus, _state->mode, plane_state->fb);
- cirrus_fb_blit_fullscreen(plane_state->fb);
+ cirrus_fb_blit_fullscreen(plane_state->fb, _plane_state->map[0]);
}
static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
@@ -451,16 +442,15 @@ static void cirrus_pipe_update(struct
drm_simple_display_pipe *pipe,
{
struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
struct drm_plane_state *state = pipe->plane.state;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(state);
struct drm_crtc *crtc = >crtc;
struct drm_rect rect;
- if (pipe->plane.state->fb &&
- cirrus->cpp != cirrus_cpp(pipe->plane.state->fb))
- cirrus_mode_set(cirrus, >mode,
- pipe->plane.state->fb);
+ if (state->fb && cirrus->cpp != cirrus_cpp(state->fb))
+ cirrus_mode_set(cirrus, >mode, state->fb);
if (drm_atomic_helper_damage_merged(old_state, state, ))
- cirrus_fb_blit_rect(pipe->plane.state->fb, );
+ cirrus_fb_blit_rect(state->fb, _plane_state->map[0],
);
}
static const struct drm_simple_display_pipe_funcs cirrus_pipe_funcs = {
@@ -468,6 +458,7 @@ static const struct drm_simple_display_pipe_funcs
cirrus_pipe_funcs = {
.check = cirrus_pipe_check,
.enable = cirrus_pipe_enable,
.update = cirrus_pipe_update,
+ DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS,
};
static const uint32_t cirrus_formats[] = {
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/simple-kms: Add plane-state helpers
Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_simple_kms_helper.c | 40 +++--
include/drm/drm_simple_kms_helper.h | 28 +
2 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 6ce8f5cd1eb5..0c5bb0f98fa0 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -253,13 +253,47 @@ static const struct drm_plane_helper_funcs
drm_simple_kms_plane_helper_funcs = {
.atomic_update = drm_simple_kms_plane_atomic_update,
};
+static void drm_simple_kms_plane_reset(struct drm_plane *plane)
+{
+ struct drm_simple_display_pipe *pipe;
+
+ pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+ if (!pipe->funcs || !pipe->funcs->reset_plane)
+ return drm_atomic_helper_plane_reset(plane);
+
+ return pipe->funcs->reset_plane(pipe);
+}
+
+static struct drm_plane_state *drm_simple_kms_plane_duplicate_state(struct
drm_plane *plane)
+{
+ struct drm_simple_display_pipe *pipe;
+
+ pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+ if (!pipe->funcs || !pipe->funcs->duplicate_plane_state)
+ return drm_atomic_helper_plane_duplicate_state(plane);
+
+ return pipe->funcs->duplicate_plane_state(pipe, plane->state);
+}
+
+static void drm_simple_kms_plane_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_simple_display_pipe *pipe;
+
+ pipe = container_of(plane, struct drm_simple_display_pipe, plane);
+ if (!pipe->funcs || !pipe->funcs->destroy_plane_state)
+ drm_atomic_helper_plane_destroy_state(plane, state);
+ else
+ pipe->funcs->destroy_plane_state(pipe, state);
+}
+
static const struct drm_plane_funcs drm_simple_kms_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
- .reset = drm_atomic_helper_plane_reset,
- .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .reset = drm_simple_kms_plane_reset,
+ .atomic_duplicate_state = drm_simple_kms_plane_duplicate_state,
+ .atomic_destroy_state = drm_simple_kms_plane_destroy_state,
.format_mod_supported = drm_simple_kms_format_mod_supported,
};
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index e6dbf3161c2f..0c1a2e07caf2 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -149,6 +149,34 @@ struct drm_simple_display_pipe_funcs {
* more details.
*/
void (*disable_vblank)(struct drm_simple_display_pipe *pipe);
+
+ /**
+* @reset_plane:
+*
+* Optional, called by _plane_funcs.reset. Please read the
+* documentation for the _plane_funcs.reset hook for more details.
+*/
+ void (*reset_plane)(struct drm_simple_display_pipe *pipe);
+
+ /**
+* @duplicate_plane_state:
+*
+* Optional, called by _plane_funcs.atomic_duplicate_state. Please
+* read the documentation for the
_plane_funcs.atomic_duplicate_state
+* hook for more details.
+*/
+ struct drm_plane_state * (*duplicate_plane_state)(struct
drm_simple_display_pipe *pipe,
+ struct
drm_plane_state *plane_state);
+
+ /**
+* @destroy_plane_state:
+*
+* Optional, called by _plane_funcs.atomic_destroy_state. Please
+* read the documentation for the _plane_funcs.atomic_destroy_state
+* hook for more details.
+*/
+ void (*destroy_plane_state)(struct drm_simple_display_pipe *pipe,
+ struct drm_plane_state *plane_state);
};
/**
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 4, 2021 at 7:38 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote: > > > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: > > > > tldr; DMA buffers aren't normal memory, expecting that you can use > > > > them like that (like calling get_user_pages works, or that they're > > > > accounting like any other normal memory) cannot be guaranteed. > > > > > > > > Since some userspace only runs on integrated devices, where all > > > > buffers are actually all resident system memory, there's a huge > > > > temptation to assume that a struct page is always present and useable > > > > like for any more pagecache backed mmap. This has the potential to > > > > result in a uapi nightmare. > > > > > > > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which > > > > blocks get_user_pages and all the other struct page based > > > > infrastructure for everyone. In spirit this is the uapi counterpart to > > > > the kernel-internal CONFIG_DMABUF_DEBUG. > > > > > > Fast gup needs the special flag set on the PTE as well.. Feels weird > > > to have a special VMA without also having special PTEs? > > > > There's kinda no convenient & cheap way to check for the pte_special > > flag. This here should at least catch accidental misuse, people > > building their own ptes we can't stop. Maybe we should exclude > > VM_MIXEDMAP to catch vm_insert_page in one of these. > > > > Hm looking at code I think we need to require VM_PFNMAP here to stop > > vm_insert_page. And looking at the various functions, that seems to be > > required (and I guess VM_IO is more for really funky architectures > > where io-space is somewhere else?). I guess I should check for > > VM_PFNMAP instead of VM_SPECIAL? > > Well, you said the goal was to block GUP usage, that won't happen > without the PTE special flag, at least on x86 > > So, really, what you are saying is all dmabuf users should always use > vmf_insert_pfn_prot() or something similar - and never insert_page/etc? > > It might make sense to check the vma flags in all the insert paths, eg > vm_insert_page() can't work with VMAs that should not have struct > pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand > it right) Well that's what I've done, and it /looks/ like all the checks are there already, as long as we use VM_PFNMAP. vm_insert_page tries to auto-add VM_MIXEDMAP, but bails out with a BUG_ON if VM_PFNMAP is set. And all the vm_insert_pfn_prot/remap_pfn_range functions require (or set) VM_PFNMAP. So I think just checking for VM_PFNMAP after the vma is set up should be enough to guarantee we'll only have pte_special ptes in there, ever. But I'm not sure, this stuff all isn't really documented much and the code is sometimes a maze (to me at least). > At least as some VM debug option Seems to be there already unconditionally. -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 RFC v1 2/6] swiotlb: convert variables to arrays
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote: > On 2021-02-04 07:29, Christoph Hellwig wrote: > > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote: > > > This patch converts several swiotlb related variables to arrays, in > > > order to maintain stat/status for different swiotlb buffers. Here are > > > variables involved: > > > > > > - io_tlb_start and io_tlb_end > > > - io_tlb_nslabs and io_tlb_used > > > - io_tlb_list > > > - io_tlb_index > > > - max_segment > > > - io_tlb_orig_addr > > > - no_iotlb_memory > > > > > > There is no functional change and this is to prepare to enable 64-bit > > > swiotlb. > > > > Claire Chang (on Cc) already posted a patch like this a month ago, > > which looks much better because it actually uses a struct instead > > of all the random variables. > > Indeed, I skimmed the cover letter and immediately thought that this whole > thing is just the restricted DMA pool concept[1] again, only from a slightly > different angle. Kind of. Let me lay out how some of these pieces are right now: +---+ +--+ | | | | | | | | | a)Xen-SWIOTLB | | b)SWIOTLB (for !Xen) | | | | | +---XX--+ +---X--+ X XX XXX X XX +--XX---+ | | | | | c) SWIOTLB generic | | | +---+ Dongli's patches modify the SWIOTLB generic c), and Xen-SWIOTLB a) parts. Also see the IOMMU_INIT logic which lays this a bit more deepth (for example how to enable SWIOTLB on AMD boxes, or IBM with Calgary IOMMU, etc - see iommu_table.h). Furtheremore it lays the groundwork to allocate AMD SEV SWIOTLB buffers later after boot (so that you can stich different pools together). All the bits are kind of inside of the SWIOTLB code. And also it changes the Xen-SWIOTLB to do something similar. The mempool did it similarly by taking the internal parts (aka the various io_tlb) of SWIOTLB and exposing them out and having other code: +---+ +--+ | | | | | | | | | a)Xen-SWIOTLB | | b)SWIOTLB (for !Xen) | | | | | +---XX--+ +---X--+ X XX XXX X XX +--XX---+ +--+ | | | Device tree | | +<+ enabling SWIOTLB | |c) SWIOTLB generic | | | | | | mempool | +---+ +--+ What I was suggesting to Clarie to follow Xen model, that is do something like this: +---+ +--+ ++ | | | | || | | | | || | a)Xen-SWIOTLB | | b)SWIOTLB (for !Xen) | | e) DT-SWIOTLB | | | | | || +---XX--+ +---X--+ +XX-X+ XXXX X X XX X XX XX XXX X XX X +--XXX--+ | | | | |c) SWIOTLB generic | | | +---+ so using the SWIOTLB generic parts, and then bolt on top of the device-tree logic, along with the mempool logic. But Christopher has an interesting suggestion which is to squash the all the existing code (a, b, c) all together and pepper it with various jump-tables. So: -+ | SWIOTLB: | || | a) SWIOTLB (for non-Xen) | | b) Xen-SWIOTLB| | c) DT-SWIOTLB | || || -+ with all the various bits (M2P/P2M for Xen, mempool for ARM, and normal allocation for BM) in one big file. ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"
Hi Thomas,
The original problem was qxl_device_init() can fail,
when it fails there is no need to call
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
But those two functions are otherwise called in the qxl_drm_release() -
I have posted an updated patch.
The new patch use the following logic
+ if (!qdev->ddev.mode_config.funcs)
+ return;
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
Thanks,
- Tong
> On Feb 4, 2021, at 1:34 PM, Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
>> This reverts commit b91907a6241193465ca92e357adf16822242296d.
>
> This should be in the correct format, as given by 'dim cite'.
>
> dim cite b91907a6241193465ca92e357adf16822242296d
> b91907a62411 ("drm/qxl: do not run release if qxl failed to init")
>
>> Patch is broken, it effectively makes qxl_drm_release() a nop
>> because on normal driver shutdown qxl_drm_release() is called
>> *after* drm_dev_unregister().
>> Cc: Tong Zhang
>> Signed-off-by: Gerd Hoffmann
>> ---
>> drivers/gpu/drm/qxl/qxl_drv.c | 2 --
>> 1 file changed, 2 deletions(-)
>> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
>> index 34c8b25b5780..fb5f6a5e81d7 100644
>> --- a/drivers/gpu/drm/qxl/qxl_drv.c
>> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
>> @@ -144,8 +144,6 @@ static void qxl_drm_release(struct drm_device *dev)
>> * reodering qxl_modeset_fini() + qxl_device_fini() calls is
>> * non-trivial though.
>> */
>> -if (!dev->registered)
>> -return;
>
> I'm not sure what the original problem was, but I'm sure that this isn't the
> fix for it. If there's a problem with shutdown, the operations rather have to
> be reordered correctly.
>
> With the citation style address:
>
> Acked-by: Thomas Zimmermann
>
>> qxl_modeset_fini(qdev);
>> qxl_device_fini(qdev);
>> }
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/v3d: Add job timeout module param
On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova wrote: > > On 3/9/20 18:48, Yukimasa Sugizaki wrote: > > From: Yukimasa Sugizaki > > > > The default timeout is 500 ms which is too short for some workloads > > including Piglit. Adding this parameter will help users to run heavier > > tasks. > > > > Signed-off-by: Yukimasa Sugizaki > > --- > > drivers/gpu/drm/v3d/v3d_sched.c | 24 +--- > > 1 file changed, 13 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/gpu/drm/v3d/v3d_sched.c > > b/drivers/gpu/drm/v3d/v3d_sched.c > > index feef0c749e68..983efb018560 100644 > > --- a/drivers/gpu/drm/v3d/v3d_sched.c > > +++ b/drivers/gpu/drm/v3d/v3d_sched.c > > @@ -19,11 +19,17 @@ > >*/ > > > > #include > > +#include > > > > #include "v3d_drv.h" > > #include "v3d_regs.h" > > #include "v3d_trace.h" > > > > +static uint timeout = 500; > > +module_param(timeout, uint, 0444); > > +MODULE_PARM_DESC(timeout, > > + "Timeout for a job in ms (0 means infinity and default is 500 ms)"); > > + > > I think that parameter definition could be included at v3d_drv.c as > other drivers do. Then we would have all future parameters together. In > that case we would need also to include the extern definition at > v3d_drv.h for the driver variable. > > The param name could be more descriptive like "sched_timeout_ms" in the > lima driver. > > I wonder if it would make sense to have different timeouts parameters > for different type of jobs we have. At least this series come from the > need additional time to complete compute jobs. This is what amdgpu does, > but we probably don't need something such complex. > > I think it would also make sense to increase our default value for the > compute jobs. > > What do you think? > > In any case I think that having this general scheduling timeout > parameter as other drivers do is a good idea. Having a param for being able to test if the job completes eventually is a good idea, but if tests are triggering timeouts, then you probably need to investigate what's going on in the driver -- it's not like you want .5second unpreemptible jobs to be easy to produce. Also, for CS, I wonder if we have another reg besides CSD_CURRENT_CFG4 we could be looking at for "we're making progress on the job". Half a second with no discernible progress sounds like a bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/qxl: do not run release if qxl failed to init
if qxl_device_init() fail, drm device will not be registered, in this case, do not run qxl_drm_release() [5.258534] == [5.258931] BUG: KASAN: user-memory-access in qxl_destroy_monitors_object+0x42/0xa0 [qxl] [5.259388] Write of size 8 at addr 14dc by task modprobe/95 [5.259754] [5.259842] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc6-7-g88bb507a74ea #62 [5.260309] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda54 [5.260917] Call Trace: [5.261056] dump_stack+0x7d/0xa3 [5.261245] kasan_report.cold+0x10c/0x10e [5.261475] ? qxl_destroy_monitors_object+0x42/0xa0 [qxl] [5.261789] check_memory_region+0x17c/0x1e0 [5.262029] qxl_destroy_monitors_object+0x42/0xa0 [qxl] [5.262332] qxl_modeset_fini+0x9/0x20 [qxl] [5.262595] qxl_drm_release+0x22/0x30 [qxl] [5.262841] drm_dev_release+0x32/0x50 [5.263047] release_nodes+0x39e/0x410 [5.263253] ? devres_release+0x40/0x40 [5.263462] really_probe+0x2ea/0x420 [5.263664] driver_probe_device+0x6d/0xd0 [5.263888] device_driver_attach+0x82/0x90 [5.264116] ? device_driver_attach+0x90/0x90 [5.264353] __driver_attach+0x60/0x100 [5.264563] ? device_driver_attach+0x90/0x90 [5.264801] bus_for_each_dev+0xe1/0x140 [5.265014] ? subsys_dev_iter_exit+0x10/0x10 [5.265251] ? klist_node_init+0x61/0x80 [5.265464] bus_add_driver+0x254/0x2a0 [5.265673] driver_register+0xd3/0x150 [5.265882] ? 0xc0048000 [5.266064] do_one_initcall+0x84/0x250 [5.266274] ? trace_event_raw_event_initcall_finish+0x150/0x150 [5.266596] ? unpoison_range+0xf/0x30 [5.266801] ? kasan_kmalloc.constprop.0+0x84/0xa0 [5.267082] ? unpoison_range+0xf/0x30 [5.267287] ? unpoison_range+0xf/0x30 [5.267491] do_init_module+0xf8/0x350 [5.267697] load_module+0x3fe6/0x4340 [5.267902] ? vm_unmap_ram+0x1d0/0x1d0 [5.268115] ? module_frob_arch_sections+0x20/0x20 [5.268375] ? __do_sys_finit_module+0x108/0x170 [5.268624] __do_sys_finit_module+0x108/0x170 [5.268865] ? __ia32_sys_init_module+0x40/0x40 [5.269111] ? file_open_root+0x200/0x200 [5.269330] ? do_sys_open+0x85/0xe0 [5.269527] ? filp_open+0x50/0x50 [5.269714] ? exit_to_user_mode_prepare+0xfc/0x130 [5.269978] do_syscall_64+0x33/0x40 [5.270176] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [5.270450] RIP: 0033:0x7fa3f685bcf7 [5.270646] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d1 [5.271634] RSP: 002b:7ffca83048d8 EFLAGS: 0246 ORIG_RAX: 0139 [5.272037] RAX: ffda RBX: 01e94a70 RCX: 7fa3f685bcf7 [5.272416] RDX: RSI: 01e939e0 RDI: 0003 [5.272794] RBP: 0003 R08: R09: 0001 [5.273171] R10: 7fa3f68bf300 R11: 0246 R12: 01e939e0 [5.273550] R13: R14: 01e93bd0 R15: 0001 [5.273928] == Signed-off-by: Tong Zhang --- v2: use qdev->ddev.mode_config.funcs instead of dev->registered, since mode_config.funcs will only be set if qxl_modeset_init() returns 0 drivers/gpu/drm/qxl/qxl_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index 6e7f16f4cec7..839d9e7a5765 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -144,6 +144,8 @@ static void qxl_drm_release(struct drm_device *dev) * reodering qxl_modeset_fini() + qxl_device_fini() calls is * non-trivial though. */ + if (!qdev->ddev.mode_config.funcs) + return; qxl_modeset_fini(qdev); qxl_device_fini(qdev); } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
Channel 1 has polarity bits for vsync and hsync signals but driver never
sets them. It turns out that with pre-HDMI2 controllers seemingly there
is no issue if polarity is not set. However, with HDMI2 controllers
(H6) there often comes to de-synchronization due to phase shift. This
causes flickering screen. It's safe to assume that similar issues might
happen also with pre-HDMI2 controllers.
Solve issue with setting vsync and hsync polarity. Note that display
stacks with tcon top have polarity bits actually in tcon0 polarity
register.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 6b9af4c08cd6..0d132dae58c0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
SUN4I_TCON1_BASIC5_H_SYNC(hsync));
+ /* Setup the polarity of sync signals */
+ if (tcon->quirks->polarity_in_ch0) {
+ val = 0;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
+
+ regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
+ } else {
+ val = SUN4I_TCON1_IO_POL_UNKNOWN;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
+
+ regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
+ }
+
/* Map output pins to channel 1 */
regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
SUN4I_TCON_GCTL_IOMAP_MASK,
@@ -1500,6 +1523,7 @@ static const struct sun4i_tcon_quirks
sun8i_a83t_tv_quirks = {
static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
.has_channel_1 = true,
+ .polarity_in_ch0= true,
.set_mux= sun8i_r40_tcon_tv_set_mux,
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index c5ac1b02482c..b504fb2d3de5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -154,6 +154,10 @@
#define SUN4I_TCON1_BASIC5_V_SYNC(height) (((height) - 1) & 0x3ff)
#define SUN4I_TCON1_IO_POL_REG 0xf0
+#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
+#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE BIT(25)
+#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE BIT(24)
+
#define SUN4I_TCON1_IO_TRI_REG 0xf4
#define SUN4I_TCON_ECC_FIFO_REG0xf8
@@ -236,6 +240,7 @@ struct sun4i_tcon_quirks {
boolneeds_de_be_mux; /* sun6i needs mux to select backend */
boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
boolsupports_lvds; /* Does the TCON support an LVDS output? */
+ boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in
tcon0 pol register */
u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
/* callback to handle tcon muxing options */
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Feb 4 (gpu/drm/i915/)
On 2/4/21 1:13 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210203: > on x86_64: Still seeing 2 unrelated issues: WARNING: unmet direct dependencies detected for DRM_I915_WERROR Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && !COMPILE_TEST [=y] Selected by [m]: - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] ../drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_freeze_late’: ../drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of function ‘wbinvd_on_all_cpus’; did you mean ‘wrmsr_on_cpus’? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap config-r7644.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: remove atomic helper dirtyfb
On Thu, Feb 4, 2021, 18:18 Daniel Vetter wrote: > On Thu, Feb 4, 2021 at 5:03 PM Toni Spets wrote: > > > > > > > > On Thu, Feb 4, 2021, 17:20 Daniel Vetter wrote: > >> > >> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote: > >> > The blocking implementation of the dirtyfb ioctl is extremely slow > when > >> > used for damage tracking on RK3399. If this implementation is in > place Xorg > >> > will default to using it and will slow down considerably when doing a > lot > >> > of small draws. This is most apparent with the fvwm window manager on > >> > startup where it will almost lock up for many seconds seconds on > RK3399. > >> > > >> > Removing this implementation did not cause any visible issues on > RK3399 but > >> > it did fix the performance issues on Xorg as it will disable damage > >> > tracking when the ioctl returns it's not supported. > >> > >> Then you don't have a manual update panel. > >> > >> Iirc there were patches to make this faster in recent kernels, on what > >> kernels did you try this? > > > > > > Latest was 5.10.12. If there are fixes for this in later kernels I will > definitely try it out. > > Hm I thought it landed already. But checking it the optimization was > for fbdev to batch up updates more (because that one doesn't even > try), not direct X usage. So your X should work faster if you use > fbdev as backend (just as an experiment). > Yeah, I used fbdev to test before which got me down this path to look up what's wrong with the modesetting driver. Fbdev runs flawlessly but then we lose panfrost for other acceleration so it's unfortunately not a silver bullet. > >> Also X should only call this in the blocker handler, not all the time. > > > > > > It does but fvwm is an example that forces it to be called a lot and > it's slow enough to cause significant issues. > > > >> > >> So yeah we need to make this faster, not break manual update panels. > > > > > > Pardon my ignorance but while making this operation faster will indeed > make it better wouldn't the correct behavior be to know if a panel requires > this or not? > > Not impossible, but there's a pile of layers in the way. And generally > frontbuffer rendering doesn't see a lot of love, since aside from > bootloaders and old sckool X window systems without compositors, > they're not really seeing any use. Everything Wayland or composited > desktops is double-buffered and fast. > It's not this black and white, unfortunately. Compositing even on Xorg is slower than not using it at all at least on Xfce where currently this hardware gets the best results with this patch applied and compositor off. Maybe the implementation is just bad on Xfce? > For fbdev we're also doing the dirty tracking now at a driver level > (using the helpers), unconditionally whether the given hw actually > needs it or not. > > More pragmatic approach would be to throw a kernel thread at this > problem. Will be tricky since we need to make sure that from > userspace's pov nothing breaks, which is always a bit an issue when > making things more asynchronous. Specifically we need to make sure > that userspace doesn't get ahead of the kernel, so might need to > require that we only batch up updates for the same framebuffer object, > but stall when we switch. > > The locking for this will get interesting. > Sounds like an awful lot of work for a niche use. Although if Wayland ends up calling this even every now and then it may prove to be useful. I haven't done any testing or benchmarking on Wayland so I have no knowledge if this makes any difference there. Maybe this could solved in Xorg by having an option to disable damage tracking manually, though ideally no manual setup would be needed and I doubt anyone wants new options for the modesetting driver for an edge case like this. Don't really know where to go from here. Wouldn't want to carry this patch manually just to get a well working X either. Thanks for the insight and I'm happy to test any solution if something comes up! > Cheers, Daniel > > > Making a low performance device wait any extra time for no reason > doesn't sound like the correct fix either. > > > > I'm not defending the patch itself as I don't have enough understanding > of the drm or kernel so if it's indeed definitely breaking something then > of course it can't be used as is. > > > > Thanks. > > > > > >> -Daniel > >> > >> > > >> > -- > >> > Toni Spets > >> > >> > From 79984ee67c801f552e9eaf4d0cfb62101d1f0f2e Mon Sep 17 00:00:00 2001 > >> > From: Toni Spets > >> > Date: Wed, 3 Feb 2021 21:14:50 +0200 > >> > Subject: [PATCH] drm/rockchip: remove atomic helper dirtyfb > >> > > >> > --- > >> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 - > >> > 1 file changed, 1 deletion(-) > >> > > >> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > >> > index 3aa37e177667..2554fd1c8aeb 100644 > >> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c > >> > +++
[PATCH 0/5] sunxi: fix H6 HDMI related issues
Over the year I got plenty of reports of troubles with H6 HDMI signal. Sometimes monitor flickers, sometimes there was no image at all and sometimes it didn't play well with AVR. It turns out there are multiple issues. Patch 1 fixes clock issue, which didn't adjust parent rate, even if it is allowed to do so. Patch 2 adds polarity config in tcon1. This is seemingly not needed for pre-HDMI2 controllers, although BSP drivers set it accordingly every time. It turns out that HDMI2 controllers often don't work with monitors if polarity is not set correctly. Patch 3 always set clock rate for HDMI controller. Patch 4 fixes cpce PHY setting for 594 MHz. Patch 5 fixes comment and clock rate limit (wrong reasoning). Please take a look. Best regards, Jernej Jernej Skrabec (5): clk: sunxi-ng: mp: fix parent rate change flag check drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 drivers/clk/sunxi-ng/ccu_mp.c | 2 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 24 drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 10 +++--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 2 +- 6 files changed, 34 insertions(+), 10 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 driver
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
+ regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
Why is REG_RC_LVDS_PLL volatile?
See register 0xa bit 7, PLL_EN_STAT .
+ regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
Do you need to list REG_RC_RESET as volatile? Specifically you need
to make sure it's not cached...
Isn't volatile table exactly for this purpose -- to make sure the reg is
not cached ?
+};
+
+static const struct regmap_access_table sn65dsi83_volatile_table = {
+ .yes_ranges = sn65dsi83_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),
+};
+
+static const struct regmap_config sn65dsi83_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .rd_table = _readable_table,
+ .wr_table = _writeable_table,
+ .volatile_table = _volatile_table,
+ .cache_type = REGCACHE_RBTREE,
+ .max_register = REG_IRQ_STAT,
+};
I'm curious how much the "readable" and "writable" sections get you.
In theory only the "volatile" should really matter, right?
They are useful when dumping the regs from debugfs regmap registers .
+
+static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct sn65dsi83, bridge);
+}
+
+static int sn65dsi83_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+ struct device *dev = ctx->dev;
+ struct mipi_dsi_device *dsi;
+ struct mipi_dsi_host *host;
+ int ret = 0;
+
+ const struct mipi_dsi_device_info info = {
+ .type = "sn65dsi83",
+ .channel = 0,
+ .node = NULL,
+ };
+
+ host = of_find_mipi_dsi_host_by_node(ctx->host_node);
+ if (!host) {
+ dev_err(dev, "failed to find dsi host\n");
I notice that the sn65dsi86 driver usually uses DRM_ERROR instead of dev_err().
I guess you want DRM maintainers to comment on this one. I think simple
dev_err() is clear in what it does, DRM_ERROR seems like another level
of indirection.
+ return -EPROBE_DEFER;
+ }
+
+ dsi = mipi_dsi_device_register_full(host, );
+ if (IS_ERR(dsi)) {
+ ret = PTR_ERR(dsi);
+ dev_err(dev, "failed to create dsi device, ret=%i\n", ret);
+ goto err_dsi_device;
Why not just "return ret" and get rid of the "err_dsi_device" label?
Oh, right, or even dev_err_probe().
[...]
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+ /*
+* Reset the chip, pull EN line low for t_reset=10ms,
+* then high for t_en=1ms.
+*/
+ gpiod_set_value(ctx->enable_gpio, 0);
Why not use the "cansleep" version to give some flexibility?
Does that make a difference in non-interrupt context ?
+ usleep_range(1, 11000);
It seems like it would be worth it to read the enable_gpio first? If
it was already 0 maybe you can skip the 10 ms delay? I would imagine
that most of the time the bridge would already be disabled to start?
How do you guarantee the GPIO was LO for 10 mS here? You can sample that
it is LO, but you won't know how long it was LO before this code was
executed.
+ gpiod_set_value(ctx->enable_gpio, 1);
+ usleep_range(1000, 1100);
This fully resets the chip, right? So you need to invalidate your regmap cache?
Right
+}
+
[...]
+static void sn65dsi83_enable(struct drm_bridge *bridge)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+ u16 val;
+
+ /* Clear reset, disable PLL */
+ regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
I don't think you need to clear reset, do you? The doc says "This bit
automatically clears when set to 1 and returns 0s when read." Maybe
was needed because you forgot to list this register as volatile?
I need to check this one.
+ regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
Probably you don't need this? It's the default and in pre-enable you
just reset the chip. Maybe it was needed since you don't flush the
cache in pre-enable?
Have a look at the Example Script in the DSI83 datasheet, this PLL part
is needed.
+ /* Reference clock derived from DSI link clock. */
+ regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
+ REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
+ REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
+ regmap_write(ctx->regmap, REG_DSI_CLK,
+ REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
+ regmap_write(ctx->regmap, REG_RC_DSI_CLK,
+ REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
+
+ /* Set number of DSI lanes, keep reserved bits. */
+
[PATCH 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
one. Fix that.
Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when allowed")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_mp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index fa4ecb915590..5f40be6d2dfd 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -108,7 +108,7 @@ static unsigned long ccu_mp_round_rate(struct
ccu_mux_internal *mux,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
- if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
+ if (!(clk_hw_get_flags(>common.hw) & CLK_SET_RATE_PARENT)) {
ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
rate = *parent_rate / p / m;
} else {
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: > tldr; DMA buffers aren't normal memory, expecting that you can use > them like that (like calling get_user_pages works, or that they're > accounting like any other normal memory) cannot be guaranteed. > > Since some userspace only runs on integrated devices, where all > buffers are actually all resident system memory, there's a huge > temptation to assume that a struct page is always present and useable > like for any more pagecache backed mmap. This has the potential to > result in a uapi nightmare. > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which > blocks get_user_pages and all the other struct page based > infrastructure for everyone. In spirit this is the uapi counterpart to > the kernel-internal CONFIG_DMABUF_DEBUG. Fast gup needs the special flag set on the PTE as well.. Feels weird to have a special VMA without also having special PTEs? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote: > On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote: > > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: > > > tldr; DMA buffers aren't normal memory, expecting that you can use > > > them like that (like calling get_user_pages works, or that they're > > > accounting like any other normal memory) cannot be guaranteed. > > > > > > Since some userspace only runs on integrated devices, where all > > > buffers are actually all resident system memory, there's a huge > > > temptation to assume that a struct page is always present and useable > > > like for any more pagecache backed mmap. This has the potential to > > > result in a uapi nightmare. > > > > > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which > > > blocks get_user_pages and all the other struct page based > > > infrastructure for everyone. In spirit this is the uapi counterpart to > > > the kernel-internal CONFIG_DMABUF_DEBUG. > > > > Fast gup needs the special flag set on the PTE as well.. Feels weird > > to have a special VMA without also having special PTEs? > > There's kinda no convenient & cheap way to check for the pte_special > flag. This here should at least catch accidental misuse, people > building their own ptes we can't stop. Maybe we should exclude > VM_MIXEDMAP to catch vm_insert_page in one of these. > > Hm looking at code I think we need to require VM_PFNMAP here to stop > vm_insert_page. And looking at the various functions, that seems to be > required (and I guess VM_IO is more for really funky architectures > where io-space is somewhere else?). I guess I should check for > VM_PFNMAP instead of VM_SPECIAL? Well, you said the goal was to block GUP usage, that won't happen without the PTE special flag, at least on x86 So, really, what you are saying is all dmabuf users should always use vmf_insert_pfn_prot() or something similar - and never insert_page/etc? It might make sense to check the vma flags in all the insert paths, eg vm_insert_page() can't work with VMAs that should not have struct pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand it right) At least as some VM debug option Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings
On 2/4/21 7:38 PM, Doug Anderson wrote: Hi, Hi, [...] +properties: + compatible: +const: ti,sn65dsi83 + + reg: +const: 0x2d + + enable-gpios: +maxItems: 1 +description: GPIO specifier for bridge_en pin (active high). I see two regulators: vcc and vcore. Shouldn't those be listed? Those are not implemented and not tested, so if someone needs them later on, they can be added then. Sure. I guess it can go either way. For the regulator it'd the kind of thing that's super easy to add support for and hard to mess up. If someone can test those regulators (I might be able to, in next revision of hardware, we'll see), then this can be added. + endpoint: +type: object +additionalProperties: false +properties: + remote-endpoint: true + data-lanes: +description: array of physical DSI data lane indexes. The chip doesn't allow for arbitrary remapping here, right? So you're just using this as the official way to specify the number of lanes? I guess the only valid values are: <0> <0 1> <0 1 2> <0 1 2 3> Shouldn't that be <1 2 3 4> ? The data manual refers to the channels starting at 0, so if it's arbitrary that seems a better way to go? Either way is OK, but before I change this, I would like some confirmation this enumeration really is arbitrary. In sn65dsi86 we attempted to enforce that a valid option was selected for the output lanes. Could you do something similar? If nothing else adding a description of the valid options would be good. I saw the binding, but I was under the impressions the DSI86 can do lane reordering, isn't that the case ? Maybe I misunderstood it. DSI86 can reorder the output lanes quite flexibly. It can't reorder the input lanes, though. The eDP ones ? OK But yes, if you have a suggestion how to make a non-cryptic list of those four lane mapping options, please do share this info. I doubt I can write this correctly without a whole lot of futzing / messing, but maybe something like: data-lanes: oneOf: - items: - 0 - items: - 0 - 1 - items: - 0 - 1 - 2 - items: - 0 - 1 - 2 - 3 I was hoping for some better syntax. Maybe there is one ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
cpce value for 594 MHz is set differently in BSP driver. Fix that.
Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 35c2133724e2..89aff19ddeb4 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -89,7 +89,7 @@ static const struct dw_hdmi_mpll_config sun50i_h6_mpll_cfg[]
= {
},
}, {
59400, {
- { 0x1a40, 0x0003 },
+ { 0x1a7c, 0x0003 },
{ 0x3b4c, 0x0003 },
{ 0x5a64, 0x0003 },
},
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: remove atomic helper dirtyfb
On Thu, Feb 4, 2021, 17:20 Daniel Vetter wrote:
> On Wed, Feb 03, 2021 at 09:53:40PM +0200, Toni Spets wrote:
> > The blocking implementation of the dirtyfb ioctl is extremely slow when
> > used for damage tracking on RK3399. If this implementation is in place
> Xorg
> > will default to using it and will slow down considerably when doing a lot
> > of small draws. This is most apparent with the fvwm window manager on
> > startup where it will almost lock up for many seconds seconds on RK3399.
> >
> > Removing this implementation did not cause any visible issues on RK3399
> but
> > it did fix the performance issues on Xorg as it will disable damage
> > tracking when the ioctl returns it's not supported.
>
> Then you don't have a manual update panel.
>
> Iirc there were patches to make this faster in recent kernels, on what
> kernels did you try this?
>
Latest was 5.10.12. If there are fixes for this in later kernels I will
definitely try it out.
> Also X should only call this in the blocker handler, not all the time.
>
It does but fvwm is an example that forces it to be called a lot and it's
slow enough to cause significant issues.
> So yeah we need to make this faster, not break manual update panels.
>
Pardon my ignorance but while making this operation faster will indeed make
it better wouldn't the correct behavior be to know if a panel requires this
or not?
Making a low performance device wait any extra time for no reason doesn't
sound like the correct fix either.
I'm not defending the patch itself as I don't have enough understanding of
the drm or kernel so if it's indeed definitely breaking something then of
course it can't be used as is.
Thanks.
-Daniel
>
> >
> > --
> > Toni Spets
>
> > From 79984ee67c801f552e9eaf4d0cfb62101d1f0f2e Mon Sep 17 00:00:00 2001
> > From: Toni Spets
> > Date: Wed, 3 Feb 2021 21:14:50 +0200
> > Subject: [PATCH] drm/rockchip: remove atomic helper dirtyfb
> >
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > index 3aa37e177667..2554fd1c8aeb 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > @@ -21,7 +21,6 @@
> > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> > .destroy = drm_gem_fb_destroy,
> > .create_handle = drm_gem_fb_create_handle,
> > - .dirty = drm_atomic_helper_dirtyfb,
> > };
> >
> > static struct drm_framebuffer *
> > --
> > 2.27.0
> >
>
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
> 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
[PATCH 3/5] drm/sun4i: dw-hdmi: always set clock rate
As expected, HDMI controller clock should always match pixel clock. In
the past, changing HDMI controller rate would seemingly worsen
situation. However, that was the result of other bugs which are now
fixed.
Fix that by removing set_rate quirk and always set clock rate.
Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 4 +---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 92add2cef2e7..23773a5e0650 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -21,8 +21,7 @@ static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder
*encoder,
{
struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
- if (hdmi->quirks->set_rate)
- clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
+ clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
}
static const struct drm_encoder_helper_funcs
@@ -295,7 +294,6 @@ static int sun8i_dw_hdmi_remove(struct platform_device
*pdev)
static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
.mode_valid = sun8i_dw_hdmi_mode_valid_a83t,
- .set_rate = true,
};
static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d983746fa194..d4b55af0592f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -179,7 +179,6 @@ struct sun8i_dw_hdmi_quirks {
enum drm_mode_status (*mode_valid)(struct dw_hdmi *hdmi, void *data,
const struct drm_display_info *info,
const struct drm_display_mode *mode);
- unsigned int set_rate : 1;
unsigned int use_drm_infoframe : 1;
};
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard
On Thu, Feb 4, 2021 at 9:37 AM James Park wrote:
>
> On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov wrote:
> >
> > Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> > At the same time drm.h pulls a lot of unneeded symbols.
> >
> > Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> > declaration of said symbols.
> >
> > When used on linux - we pull linux/types.h which is used either way.
> > On other platforms, BSDs et al, we need a couple of typedefs.
> >
> > Since those can trigger a warning in some corner-cases*, add some GCC
> > magic to silence them. Note that incorrect type redefinitions will still
> > be flagged, and the GCC pragma is ignored by other compilers.
> >
> > *Corner-case:
> > If one sets DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
> > also using -pedantic _and_ the header lives outside of the standard
> > /usr/include (like BSDs normally do).
> >
> > v2:
> > - Add corner-case handling, based on popular demand.
> >
> > Cc: James Park
> > Cc: Pekka Paalanen
> > Cc: Simon Ser
> > Signed-off-by: Emil Velikov
> > ---
> > include/uapi/drm/drm.h| 10 ++
> > include/uapi/drm/drm_fourcc.h | 29 +
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index 808b48a93330..cd78950e05ce 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -53,6 +53,15 @@ typedef unsigned int drm_handle_t;
> > #include
> > #include
> > #include
> > +
> > +/*
> > + * When using C99 -pedantic the typedefs will trigger a warning.
> > + * If the header is considered a system one (-isystem) those will be
> > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > + * in a non-system location.
> > + */
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wpedantic"
> > typedef int8_t __s8;
> > typedef uint8_t __u8;
> > typedef int16_t __s16;
> > @@ -63,6 +72,7 @@ typedef int64_t __s64;
> > typedef uint64_t __u64;
> > typedef size_t __kernel_size_t;
> > typedef unsigned long drm_handle_t;
> > +#pragma GCC diagnostic pop
> >
> > #endif
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 6f0628eb13a6..84a1f96cc4ef 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -24,7 +24,36 @@
> > #ifndef DRM_FOURCC_H
> > #define DRM_FOURCC_H
> >
> > +/*
> > + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not
> > want
> > + * to pull drm.h into your application.
> > + */
> > +#ifdef DRM_FOURCC_STANDALONE
> > +#if defined(__linux__)
> > +
> > +#include
> > +
> > +#else /* One of the BSDs */
> > +
> > +#include
> > +
> > +/*
> > + * When using C99 -pedantic the typedefs will trigger a warning.
> > + * If the header is considered a system one (-isystem) those will be
> > + * ignored, yet on the target platforms BSDs, et al - the headers live
> > + * in a non-system location.
> > + */
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wpedantic"
> > +typedef uint32_t __u32;
> > +typedef uint64_t __u64;
> > +#pragma GCC diagnostic pop
> > +
> > +#endif /* __linux __ */
> > +
> > +#else
> > #include "drm.h"
> > +#endif /* DRM_FOURCC_STANDALONE */
> >
> > #if defined(__cplusplus)
> > extern "C" {
> > --
> > 2.30.0
> >
>
> I remember reading GCC diagnostic push/pop requires a recent enough
> compiler version to be supported, which is pretty old, but I don't
> know how old is old enough for Linux headers:
> https://github.com/protocolbuffers/protobuf/issues/4156
>
> Testing snippets in godbolt, I think the pragmas need to be wrapped. MSVC
> says:
>
> warning C4068: unknown pragma 'GCC'
>
> Also, Clang seems to want -Wtypedef-redefinition, not -Wpedantic. GCC
> complains it doesn't know what -Wtypedef-redefinition is, so that
> would also need to be wrapped.
If we're already conceding copy/paste, then how about inlining my
previous header?
#ifndef DRM_BASIC_TYPES_DEFINED
#define DRM_BASIC_TYPES_DEFINED
// Sync modifications between drm.h and drm_fourcc.h
...
#endif
No compiler games. Valid on all flavors of C (I think).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: introduce DRM_FOURCC_STANDALONE guard
On Thu, Feb 4, 2021 at 3:37 AM Emil Velikov wrote:
>
> Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> At the same time drm.h pulls a lot of unneeded symbols.
>
> Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> declaration of said symbols.
>
> When used on linux - we pull linux/types.h which is used either way.
> On other platforms, BSDs et al, we need a couple of typedefs.
>
> Since those can trigger a warning in some corner-cases*, add some GCC
> magic to silence them. Note that incorrect type redefinitions will still
> be flagged, and the GCC pragma is ignored by other compilers.
>
> *Corner-case:
> If one sets DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
> also using -pedantic _and_ the header lives outside of the standard
> /usr/include (like BSDs normally do).
>
> v2:
> - Add corner-case handling, based on popular demand.
>
> Cc: James Park
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Signed-off-by: Emil Velikov
> ---
> include/uapi/drm/drm.h| 10 ++
> include/uapi/drm/drm_fourcc.h | 29 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 808b48a93330..cd78950e05ce 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -53,6 +53,15 @@ typedef unsigned int drm_handle_t;
> #include
> #include
> #include
> +
> +/*
> + * When using C99 -pedantic the typedefs will trigger a warning.
> + * If the header is considered a system one (-isystem) those will be
> + * ignored, yet on the target platforms BSDs, et al - the headers live
> + * in a non-system location.
> + */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wpedantic"
> typedef int8_t __s8;
> typedef uint8_t __u8;
> typedef int16_t __s16;
> @@ -63,6 +72,7 @@ typedef int64_t __s64;
> typedef uint64_t __u64;
> typedef size_t __kernel_size_t;
> typedef unsigned long drm_handle_t;
> +#pragma GCC diagnostic pop
>
> #endif
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 6f0628eb13a6..84a1f96cc4ef 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,36 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +/*
> + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not want
> + * to pull drm.h into your application.
> + */
> +#ifdef DRM_FOURCC_STANDALONE
> +#if defined(__linux__)
> +
> +#include
> +
> +#else /* One of the BSDs */
> +
> +#include
> +
> +/*
> + * When using C99 -pedantic the typedefs will trigger a warning.
> + * If the header is considered a system one (-isystem) those will be
> + * ignored, yet on the target platforms BSDs, et al - the headers live
> + * in a non-system location.
> + */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wpedantic"
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +#pragma GCC diagnostic pop
> +
> +#endif /* __linux __ */
> +
> +#else
> #include "drm.h"
> +#endif /* DRM_FOURCC_STANDALONE */
>
> #if defined(__cplusplus)
> extern "C" {
> --
> 2.30.0
>
I remember reading GCC diagnostic push/pop requires a recent enough
compiler version to be supported, which is pretty old, but I don't
know how old is old enough for Linux headers:
https://github.com/protocolbuffers/protobuf/issues/4156
Testing snippets in godbolt, I think the pragmas need to be wrapped. MSVC says:
warning C4068: unknown pragma 'GCC'
Also, Clang seems to want -Wtypedef-redefinition, not -Wpedantic. GCC
complains it doesn't know what -Wtypedef-redefinition is, so that
would also need to be wrapped.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/panel: simple: add SGD GKTW70SDAD1SD
On 02/02/21, Marco Felsch wrote: > Hi Oliver, > > On 21-02-02 18:35, Oliver Graute wrote: > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD > > to panel-simple. > > > > The panel spec from Variscite can be found at: > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf > > > > Signed-off-by: Oliver Graute > > Cc: Marco Felsch > > Cc: Fabio Estevam > > --- > > > > v3: > > > > - added flags > > - added delay > > Thanks, did you test the changes? > I just picked it from the datasheet. yes, it didn't break anything. Best regards, Oliver ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 0/4] RDMA: Add dma-buf support
On Thu, Feb 04, 2021 at 08:50:38AM -0500, Alex Deucher wrote: > On Thu, Feb 4, 2021 at 2:48 AM John Hubbard wrote: > > > > On 12/15/20 1:27 PM, Jianxin Xiong wrote: > > > This patch series adds dma-buf importer role to the RDMA driver in > > > attempt to support RDMA using device memory such as GPU VRAM. Dma-buf is > > > chosen for a few reasons: first, the API is relatively simple and allows > > > a lot of flexibility in implementing the buffer manipulation ops. > > > Second, it doesn't require page structure. Third, dma-buf is already > > > supported in many GPU drivers. However, we are aware that existing GPU > > > drivers don't allow pinning device memory via the dma-buf interface. > > > Pinning would simply cause the backing storage to migrate to system RAM. > > > True peer-to-peer access is only possible using dynamic attach, which > > > requires on-demand paging support from the NIC to work. For this reason, > > > this series only works with ODP capable NICs. > > > > Hi, > > > > Looking ahead to after this patchset is merged... > > > > Are there design thoughts out there, about the future of pinning to vidmem, > > for this? It would allow a huge group of older GPUs and NICs and such to > > do p2p with this approach, and it seems like a natural next step, right? > > The argument is that vram is a scarce resource, but I don't know if > that is really the case these days. At this point, we often have as > much vram as system ram if not more. I thought the main argument was that GPU memory could move at any time between the GPU and CPU and the DMA buf would always track its current location? IMHO there is no reason not to have a special API to create small amounts of GPU dedicated locked memory that cannot be moved off the GPU. For instance this paper: http://www.ziti.uni-heidelberg.de/ziti/uploads/ce_group/2014-ASHESIPDPS.pdf Considers using the GPU to directly drive the RDMA work queues. Putting the queues themselves in GPU VRAM would make alot of sense. But that is impossible without fixed non-invalidating dma bufs. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings
On 2/4/21 6:15 PM, Doug Anderson wrote:
Hi,
[...]
+properties:
+ compatible:
+const: ti,sn65dsi83
+
+ reg:
+const: 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
I see two regulators: vcc and vcore. Shouldn't those be listed?
Those are not implemented and not tested, so if someone needs them later
on, they can be added then.
I also see an interrupt pin on the datasheet. Probably should be
listed too even if the chip can be made to work fine without hooking
it up. It can just be optional, right?
It is optional and again completely untested, so it can be added later
if needed.
It wouldn't hurt to list the refclk here too even if the code doesn't
use it. From sn65dsi86 it was handy that the bindings already had all
this type of stuff so that when we added the feature we didn't have to
go back to the bindings.
In my case, the refclock are derived from the DSI link.
+ ports:
+type: object
+additionalProperties: false
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+additionalProperties: false
+
+description:
+ Video port for MIPI DSI input
+
+properties:
+ reg:
+const: 0
+
+ endpoint:
+type: object
+additionalProperties: false
+properties:
+ remote-endpoint: true
+ data-lanes:
+description: array of physical DSI data lane indexes.
The chip doesn't allow for arbitrary remapping here, right? So you're
just using this as the official way to specify the number of lanes? I
guess the only valid values are:
<0>
<0 1>
<0 1 2>
<0 1 2 3>
Shouldn't that be <1 2 3 4> ?
In sn65dsi86 we attempted to enforce that a valid option was selected
for the output lanes. Could you do something similar? If nothing
else adding a description of the valid options would be good.
I saw the binding, but I was under the impressions the DSI86 can do lane
reordering, isn't that the case ? Maybe I misunderstood it.
But yes, if you have a suggestion how to make a non-cryptic list of
those four lane mapping options, please do share this info.
+required:
+ - reg
+
+ port@1:
+type: object
+additionalProperties: false
+
+description:
+ Video port for LVDS output (panel or bridge).
+
+properties:
+ reg:
+const: 1
+
+ endpoint:
+type: object
+additionalProperties: false
+properties:
+ remote-endpoint: true
Worth adding the data-lanes here too? I guess this part allows you
two different orders for the LVDS outputs?
I don't really want to add any properties which I cannot test and then
end up with DT bindings which would become poor ABI in the future.
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+compatible = "ti,sn65dsi83";
+reg = <0x2d>;
+
+enable-gpios = < 1 GPIO_ACTIVE_HIGH>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+endpoint {
+ remote-endpoint = <_out>;
+ data-lanes = <1 2 3 4>;
Should the above be <0 1 2 3>?
Well, git grep data-lanes seems to indicate some count from 1, some from 0 .
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/sun4i: dw-hdmi: Fix max. frequency for H6
It turns out that reasoning for lowering max. supported frequency is
wrong. Scrambling works just fine. Several now fixed bugs prevented
proper functioning, even with rates lower than 340 MHz. Issues were just
more pronounced with higher frequencies.
Fix that by allowing max. supported frequency in HW and fix the comment.
Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
Tested-by: Andre Heider
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 23773a5e0650..bbdfd5e26ec8 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -47,11 +47,9 @@ sun8i_dw_hdmi_mode_valid_h6(struct dw_hdmi *hdmi, void *data,
{
/*
* Controller support maximum of 594 MHz, which correlates to
-* 4K@60Hz 4:4:4 or RGB. However, for frequencies greater than
-* 340 MHz scrambling has to be enabled. Because scrambling is
-* not yet implemented, just limit to 340 MHz for now.
+* 4K@60Hz 4:4:4 or RGB.
*/
- if (mode->clock > 34)
+ if (mode->clock > 594000)
return MODE_CLOCK_HIGH;
return MODE_OK;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][V2] drm/mgag200: make a const array static, makes object smaller
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
textdata bss dechex filename
347364552 0 39288 9978 drivers/gpu/drm/mgag200/mgag200_mode.o
After:
textdata bss dechex filename
346254616 0 39241 9949 drivers/gpu/drm/mgag200/mgag200_mode.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King
Reviewed-by: Thomas Zimmermann
---
V2: move static declaration to the top of the declarations
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..c3dfde8cad25 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -706,13 +706,13 @@ static int mga_g200eh_set_plls(struct mga_device *mdev,
long clock)
static int mga_g200er_set_plls(struct mga_device *mdev, long clock)
{
+ static const unsigned int m_div_val[] = { 1, 2, 4, 8 };
unsigned int vcomax, vcomin, pllreffreq;
unsigned int delta, tmpdelta;
int testr, testn, testm, testo;
unsigned int p, m, n;
unsigned int computed, vco;
int tmp;
- const unsigned int m_div_val[] = { 1, 2, 4, 8 };
m = n = p = 0;
vcomax = 1488000;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: make a const array static, makes object smaller
Hi Colin,
Thank you for the patch.
On Thu, Feb 04, 2021 at 06:33:44PM +, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the const array frs_limits on the stack but instead make
> it static. Makes the object code smaller by 128 bytes:
>
> Before:
>textdata bss dec hex filename
> 248457440 64 323497e5d ./drivers/gpu/drm/bridge/tc358768.o
>
> After:
>textdata bss dec hex filename
> 247497408 64 322217ddd ./drivers/gpu/drm/bridge/tc358768.o
>
> (gcc version 10.2.0)
>
> Signed-off-by: Colin Ian King
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358768.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358768.c
> b/drivers/gpu/drm/bridge/tc358768.c
> index 8ed8302d6bbb..2495ea46b091 100644
> --- a/drivers/gpu/drm/bridge/tc358768.c
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -291,7 +291,7 @@ static int tc358768_calc_pll(struct tc358768_priv *priv,
>const struct drm_display_mode *mode,
>bool verify_only)
> {
> - const u32 frs_limits[] = {
> + static const u32 frs_limits[] = {
> 10,
> 5,
> 25000,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"
Hi Tong
Am 04.02.21 um 19:52 schrieb Tong Zhang:
Hi Thomas,
The original problem was qxl_device_init() can fail,
when it fails there is no need to call
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
But those two functions are otherwise called in the qxl_drm_release() -
OK, makes sense. Thanks for the explanation.
I have posted an updated patch.
The new patch use the following logic
+ if (!qdev->ddev.mode_config.funcs)
+ return;
This is again just papering over the issue. Better don't call
qxl_drm_release() in the error path if qxl_device_init() fails.
I see two solutions: either roll-back manually, or use our new managed
DRM interfaces. This is what the other drivers do.
Best regards
Thomas
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
Thanks,
- Tong
On Feb 4, 2021, at 1:34 PM, Thomas Zimmermann wrote:
Hi
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
This reverts commit b91907a6241193465ca92e357adf16822242296d.
This should be in the correct format, as given by 'dim cite'.
dim cite b91907a6241193465ca92e357adf16822242296d
b91907a62411 ("drm/qxl: do not run release if qxl failed to init")
Patch is broken, it effectively makes qxl_drm_release() a nop
because on normal driver shutdown qxl_drm_release() is called
*after* drm_dev_unregister().
Cc: Tong Zhang
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 34c8b25b5780..fb5f6a5e81d7 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -144,8 +144,6 @@ static void qxl_drm_release(struct drm_device *dev)
* reodering qxl_modeset_fini() + qxl_device_fini() calls is
* non-trivial though.
*/
- if (!dev->registered)
- return;
I'm not sure what the original problem was, but I'm sure that this isn't the
fix for it. If there's a problem with shutdown, the operations rather have to
be reordered correctly.
With the citation style address:
Acked-by: Thomas Zimmermann
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 0/4] RDMA: Add dma-buf support
On 2/4/21 10:44 AM, Alex Deucher wrote: ... The argument is that vram is a scarce resource, but I don't know if that is really the case these days. At this point, we often have as much vram as system ram if not more. I thought the main argument was that GPU memory could move at any time between the GPU and CPU and the DMA buf would always track its current location? I think the reason for that is that VRAM is scarce so we have to be able to move it around. We don't enforce the same limitations for buffers in system memory. We could just support pinning dma-bufs in vram like we do with system ram. Maybe with some conditions, e.g., p2p is possible, and the device has a large BAR so you aren't tying up the BAR window. Excellent. And yes, we are already building systems in which VRAM is definitely not scarce, but on the other hand, those newer systems can also handle GPU (and NIC) page faults, so not really an issue. For that, we just need to enhance HMM so that it does peer to peer. We also have some older hardware with large BAR1 apertures, specifically for this sort of thing. And again, for slightly older hardware, without pinning to VRAM there is no way to use this solution here for peer-to-peer. So I'm glad to see that so far you're not ruling out the pinning option. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: adv7511: Add set_jack handler
W dniu 19.01.2021 o 05:41, Jun Nie pisze:
> With commit 55c5cc63ab, the hdmi_codec_set_jack() will report unsupport
> failure if set_jack handler is missing. Add set_jack handler to resolve
> this failure.
>
> Signed-off-by: Jun Nie
> ---
> .../gpu/drm/bridge/adv7511/adv7511_audio.c| 27 ++-
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> index f101dd2819b5..16de1a8ca7a0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
> @@ -217,22 +217,35 @@ static int adv7511_hdmi_i2s_get_dai_id(struct
> snd_soc_component *component,
> return -EINVAL;
> }
>
> +static int adv7511_hdmi_i2s_hook_plugged_cb(struct device *dev, void *data,
> + hdmi_codec_plugged_cb fn,
> + struct device *codec_dev)
> +{
> + struct adv7511 *adv7511 = data;
> + bool plugged = adv7511->connector.status == connector_status_connected;
Maybe some locking, to protect access to adv7511->connector.status.
> +
> + fn(codec_dev, plugged);
> + return 0;
> +}
> +
> static const struct hdmi_codec_ops adv7511_codec_ops = {
> .hw_params = adv7511_hdmi_hw_params,
> .audio_shutdown = audio_shutdown,
> .audio_startup = audio_startup,
> .get_dai_id = adv7511_hdmi_i2s_get_dai_id,
> -};
> -
> -static const struct hdmi_codec_pdata codec_data = {
> - .ops = _codec_ops,
> - .max_i2s_channels = 2,
> - .i2s = 1,
> - .spdif = 1,
> + .hook_plugged_cb = adv7511_hdmi_i2s_hook_plugged_cb,
> };
>
> int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
> {
> + struct hdmi_codec_pdata codec_data = {
I think const modifier should be OK here.
Regards
Andrzej
> + .ops = _codec_ops,
> + .max_i2s_channels = 2,
> + .i2s = 1,
> + .spdif = 1,
> + .data = adv7511,
> + };
> +
> adv7511->audio_pdev = platform_device_register_data(dev,
> HDMI_CODEC_DRV_NAME,
> PLATFORM_DEVID_AUTO,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 0/4] RDMA: Add dma-buf support
On Thu, Feb 4, 2021 at 1:29 PM Jason Gunthorpe wrote: > > On Thu, Feb 04, 2021 at 08:50:38AM -0500, Alex Deucher wrote: > > On Thu, Feb 4, 2021 at 2:48 AM John Hubbard wrote: > > > > > > On 12/15/20 1:27 PM, Jianxin Xiong wrote: > > > > This patch series adds dma-buf importer role to the RDMA driver in > > > > attempt to support RDMA using device memory such as GPU VRAM. Dma-buf is > > > > chosen for a few reasons: first, the API is relatively simple and allows > > > > a lot of flexibility in implementing the buffer manipulation ops. > > > > Second, it doesn't require page structure. Third, dma-buf is already > > > > supported in many GPU drivers. However, we are aware that existing GPU > > > > drivers don't allow pinning device memory via the dma-buf interface. > > > > Pinning would simply cause the backing storage to migrate to system RAM. > > > > True peer-to-peer access is only possible using dynamic attach, which > > > > requires on-demand paging support from the NIC to work. For this reason, > > > > this series only works with ODP capable NICs. > > > > > > Hi, > > > > > > Looking ahead to after this patchset is merged... > > > > > > Are there design thoughts out there, about the future of pinning to > > > vidmem, > > > for this? It would allow a huge group of older GPUs and NICs and such to > > > do p2p with this approach, and it seems like a natural next step, right? > > > > The argument is that vram is a scarce resource, but I don't know if > > that is really the case these days. At this point, we often have as > > much vram as system ram if not more. > > I thought the main argument was that GPU memory could move at any time > between the GPU and CPU and the DMA buf would always track its current > location? I think the reason for that is that VRAM is scarce so we have to be able to move it around. We don't enforce the same limitations for buffers in system memory. We could just support pinning dma-bufs in vram like we do with system ram. Maybe with some conditions, e.g., p2p is possible, and the device has a large BAR so you aren't tying up the BAR window. Alex > > IMHO there is no reason not to have a special API to create small > amounts of GPU dedicated locked memory that cannot be moved off the > GPU. > > For instance this paper: > > http://www.ziti.uni-heidelberg.de/ziti/uploads/ce_group/2014-ASHESIPDPS.pdf > > Considers using the GPU to directly drive the RDMA work > queues. Putting the queues themselves in GPU VRAM would make alot of > sense. > > But that is impossible without fixed non-invalidating dma bufs. > > Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings
Hi, On Thu, Feb 4, 2021 at 10:09 AM Marek Vasut wrote: > > On 2/4/21 6:15 PM, Doug Anderson wrote: > > Hi, > > [...] > > >> +properties: > >> + compatible: > >> +const: ti,sn65dsi83 > >> + > >> + reg: > >> +const: 0x2d > >> + > >> + enable-gpios: > >> +maxItems: 1 > >> +description: GPIO specifier for bridge_en pin (active high). > > > > I see two regulators: vcc and vcore. Shouldn't those be listed? > > Those are not implemented and not tested, so if someone needs them later > on, they can be added then. Sure. I guess it can go either way. For the regulator it'd the kind of thing that's super easy to add support for and hard to mess up. > >> + endpoint: > >> +type: object > >> +additionalProperties: false > >> +properties: > >> + remote-endpoint: true > >> + data-lanes: > >> +description: array of physical DSI data lane indexes. > > > > The chip doesn't allow for arbitrary remapping here, right? So you're > > just using this as the official way to specify the number of lanes? I > > guess the only valid values are: > > > > <0> > > <0 1> > > <0 1 2> > > <0 1 2 3> > > Shouldn't that be <1 2 3 4> ? The data manual refers to the channels starting at 0, so if it's arbitrary that seems a better way to go? > > In sn65dsi86 we attempted to enforce that a valid option was selected > > for the output lanes. Could you do something similar? If nothing > > else adding a description of the valid options would be good. > > I saw the binding, but I was under the impressions the DSI86 can do lane > reordering, isn't that the case ? Maybe I misunderstood it. DSI86 can reorder the output lanes quite flexibly. It can't reorder the input lanes, though. > But yes, if you have a suggestion how to make a non-cryptic list of > those four lane mapping options, please do share this info. I doubt I can write this correctly without a whole lot of futzing / messing, but maybe something like: data-lanes: oneOf: - items: - 0 - items: - 0 - 1 - items: - 0 - 1 - 2 - items: - 0 - 1 - 2 - 3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core 2/3] pyverbs, tests: Cosmetic improvements for dma-buf allocation routines
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
tests/test_mr.py | 78 +-
5 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/pyverbs/dmabuf.pyx b/pyverbs/dmabuf.pyx
index b9406bd..9ed7f02 100644
--- a/pyverbs/dmabuf.pyx
+++ b/pyverbs/dmabuf.pyx
@@ -12,7 +12,7 @@ from pyverbs.mr cimport DmaBufMR
cdef extern from "dmabuf_alloc.h":
cdef struct dmabuf:
pass
-dmabuf *dmabuf_alloc(unsigned long size, int unit, int gtt)
+dmabuf *dmabuf_alloc(unsigned long size, int gpu, int gtt)
void dmabuf_free(dmabuf *dmabuf)
int dmabuf_get_drm_fd(dmabuf *dmabuf)
int dmabuf_get_fd(dmabuf *dmabuf)
@@ -20,20 +20,20 @@ cdef extern from "dmabuf_alloc.h":
cdef class DmaBuf:
-def __init__(self, size, unit=0, gtt=0):
+def __init__(self, size, gpu=0, gtt=0):
"""
Allocate DmaBuf object from a GPU device. This is done through the
DRI device interface. Usually this requires the effective user id
being a member of the 'render' group.
:param size: The size (in number of bytes) of the buffer.
-:param unit: The unit number of the GPU to allocate the buffer from.
-:param gtt: Allocate from GTT instead of VRAM.
+:param gpu: The GPU unit to allocate the buffer from.
+:param gtt: Allocate from GTT(Graphics Translation Table) instead of
VRAM.
:return: The newly created DmaBuf object on success.
"""
self.dmabuf_mrs = weakref.WeakSet()
-self.dmabuf = dmabuf_alloc(size, unit, gtt)
+self.dmabuf = dmabuf_alloc(size, gpu, gtt)
if self.dmabuf == NULL:
-raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on unit {unit}')
+raise PyverbsRDMAErrno(f'Failed to allocate dmabuf of size {size}
on gpu {gpu}')
self.drm_fd = dmabuf_get_drm_fd(self.dmabuf)
self.fd = dmabuf_get_fd(self.dmabuf)
self.map_offset = dmabuf_get_offset(self.dmabuf)
diff --git a/pyverbs/dmabuf_alloc.c b/pyverbs/dmabuf_alloc.c
index 05eae75..93267bf 100644
--- a/pyverbs/dmabuf_alloc.c
+++ b/pyverbs/dmabuf_alloc.c
@@ -95,7 +95,7 @@ static int amdgpu_mmap_offset(struct drm *drm, uint32_t
handle,
return 0;
}
-static struct drm *drm_open(int unit)
+static struct drm *drm_open(int gpu)
{
char path[32];
struct drm_version version = {};
@@ -107,7 +107,7 @@ static struct drm *drm_open(int unit)
if (!drm)
return NULL;
- snprintf(path, sizeof(path), "/dev/dri/renderD%d", unit + 128);
+ snprintf(path, sizeof(path), "/dev/dri/renderD%d", gpu + 128);
drm->fd = open(path, O_RDWR);
if (drm->fd < 0)
@@ -204,10 +204,10 @@ struct dmabuf {
/*
* dmabuf_alloc - allocate a dmabuf from GPU
* @size - byte size of the buffer to allocate
- * @unit - the GPU unit to use
- * @gtt - if true, allocate from GTT instead of VRAM
+ * @gpu - the GPU unit to use
+ * @gtt - if true, allocate from GTT(Graphics Translation Table) instead of
VRAM
*/
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt)
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt)
{
struct dmabuf *dmabuf;
int err;
@@ -216,7 +216,7 @@ struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int
gtt)
if (!dmabuf)
return NULL;
- dmabuf->drm = drm_open(unit);
+ dmabuf->drm = drm_open(gpu);
if (!dmabuf->drm)
goto out_free;
diff --git a/pyverbs/dmabuf_alloc.h b/pyverbs/dmabuf_alloc.h
index f1b03c5..4698b11 100644
--- a/pyverbs/dmabuf_alloc.h
+++ b/pyverbs/dmabuf_alloc.h
@@ -10,7 +10,7 @@
struct dmabuf;
-struct dmabuf *dmabuf_alloc(uint64_t size, int unit, int gtt);
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt);
void dmabuf_free(struct dmabuf *dmabuf);
int dmabuf_get_drm_fd(struct dmabuf *dmabuf);
int dmabuf_get_fd(struct dmabuf *dmabuf);
diff --git a/pyverbs/mr.pyx b/pyverbs/mr.pyx
index aad47e2..d05d044 100644
--- a/pyverbs/mr.pyx
+++ b/pyverbs/mr.pyx
@@ -384,7 +384,7 @@ cdef class DMMR(MR):
cdef class DmaBufMR(MR):
def __init__(self, PD pd not None, length, access, DmaBuf dmabuf=None,
- offset=0, unit=0, gtt=0):
+ offset=0, gpu=0, gtt=0):
"""
Initializes a DmaBufMR (DMA-BUF Memory Region) of the given length
and access flags using the given PD and DmaBuf objects.
@@ -393,14 +393,14 @@ cdef class DmaBufMR(MR):
:param access: Access flags, see ibv_access_flags enum
:param dmabuf: A DmaBuf object. One will be allocated if absent
:param offset: Byte offset from the beginning of the dma-buf
-:param unit: GPU unit for internal dmabuf
[PATCH rdma-core 0/3] Dma-buf related fixes
This series fixes a few issues related to the dma-buf support. It consists of three patches. The first patch fixes a compilation warning for 32-bit builds. Patch 2 renames a function parameter and expands an abbreviation. Patch 3 adds check for DRM headers. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/942 Jianxin Xiong (3): verbs: Fix gcc warnings when building for 32bit systems pyverbs,tests: Cosmetic improvements for dma-buf allocation routines configure: Add check for the presence of DRM headers CMakeLists.txt | 7 + buildlib/Finddrm.cmake | 19 buildlib/config.h.in | 2 ++ libibverbs/cmd_mr.c| 2 +- libibverbs/verbs.c | 2 +- pyverbs/dmabuf.pyx | 12 pyverbs/dmabuf_alloc.c | 59 +++--- pyverbs/dmabuf_alloc.h | 2 +- pyverbs/mr.pyx | 6 ++-- tests/test_mr.py | 78 +- 10 files changed, 127 insertions(+), 62 deletions(-) create mode 100644 buildlib/Finddrm.cmake -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core 3/3] configure: Add check for the presence of DRM headers
Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
that are installed by either the kernel-header or the libdrm package.
The installation is optional and the location is not unique.
The standard locations (such as /usr/include/drm, /usr/include/libdrm)
are checked first. If failed, pkg-config is tried to find the include
path of custom libdrm installation. The dmabuf allocation routines now
return suitable error when the headers are not available. The related
tests will recognize this error code and skip.
Signed-off-by: Jianxin Xiong
---
CMakeLists.txt | 7 +++
buildlib/Finddrm.cmake | 19 +++
buildlib/config.h.in | 2 ++
pyverbs/dmabuf_alloc.c | 47 ++-
4 files changed, 70 insertions(+), 5 deletions(-)
create mode 100644 buildlib/Finddrm.cmake
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4113423..feaba3a 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -515,6 +515,13 @@ find_package(Systemd)
include_directories(${SYSTEMD_INCLUDE_DIRS})
RDMA_DoFixup("${SYSTEMD_FOUND}" "systemd/sd-daemon.h")
+# drm headers
+find_package(drm)
+if (DRM_INCLUDE_DIRS)
+ include_directories(${DRM_INCLUDE_DIRS})
+ set(HAVE_DRM_H 1)
+endif()
+
#-
# Apply fixups
diff --git a/buildlib/Finddrm.cmake b/buildlib/Finddrm.cmake
new file mode 100644
index 000..6f8e5f2
--- /dev/null
+++ b/buildlib/Finddrm.cmake
@@ -0,0 +1,19 @@
+# COPYRIGHT (c) 2021 Intel Corporation.
+# Licensed under BSD (MIT variant) or GPLv2. See COPYING.
+
+# Check standard locations first
+find_path(DRM_INCLUDE_DIRS "drm.h" PATH_SUFFIXES "drm" "libdrm")
+
+# Check custom libdrm installation, if any
+if (NOT DRM_INCLUDE_DIRS)
+ execute_process(COMMAND pkg-config --cflags-only-I libdrm
+OUTPUT_VARIABLE _LIBDRM
+RESULT_VARIABLE _LIBDRM_RESULT
+ERROR_QUIET)
+
+ if (NOT _LIBDRM_RESULT)
+string(REGEX REPLACE "^-I" "" DRM_INCLUDE_DIRS "${_LIBDRM}")
+ endif()
+ unset(_LIBDRM)
+ unset(_LIBDRM_RESULT)
+endif()
diff --git a/buildlib/config.h.in b/buildlib/config.h.in
index c5b0bf5..e8dff54 100644
--- a/buildlib/config.h.in
+++ b/buildlib/config.h.in
@@ -67,6 +67,8 @@
# define VERBS_WRITE_ONLY 0
#endif
+#define HAVE_DRM_H @HAVE_DRM_H@
+
// Configuration defaults
#define IBACM_SERVER_MODE_UNIX 0
diff --git a/pyverbs/dmabuf_alloc.c b/pyverbs/dmabuf_alloc.c
index 93267bf..22a8ab8 100644
--- a/pyverbs/dmabuf_alloc.c
+++ b/pyverbs/dmabuf_alloc.c
@@ -9,13 +9,18 @@
#include
#include
#include
-#include
-#include
-#include
-#include
+
+#include "config.h"
+#include "dmabuf_alloc.h"
+
+#if HAVE_DRM_H
+
+#include
+#include
+#include
+#include
#include
#include
-#include "dmabuf_alloc.h"
/*
* Abstraction of the buffer allocation mechanism using the DRM interface.
@@ -276,3 +281,35 @@ uint64_t dmabuf_get_offset(struct dmabuf *dmabuf)
return dmabuf->map_offset;
}
+#else
+
+struct dmabuf *dmabuf_alloc(uint64_t size, int gpu, int gtt)
+{
+ errno = EOPNOTSUPP;
+ return NULL;
+}
+
+void dmabuf_free(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+}
+
+int dmabuf_get_drm_fd(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
+int dmabuf_get_fd(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
+uint64_t dmabuf_get_offset(struct dmabuf *dmabuf)
+{
+ errno = EOPNOTSUPP;
+ return -1;
+}
+
+#endif
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core 1/3] verbs: Fix gcc warnings when building for 32bit systems
Commit 6b0a3238289f ("verbs: Support dma-buf based memory region") caused
a build failure when building for 32b systems with gcc:
$ mkdir build && cd build && CFLAGS="-m32" cmake -GNinja .. \
-DIOCTL_MODE=both -DNO_PYVERBS=1 -DENABLE_WERROR=1 && ninja
...
../libibverbs/cmd_mr.c: In function 'ibv_cmd_reg_dmabuf_mr':
../libibverbs/cmd_mr.c:152:21: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
vmr->ibv_mr.addr = (void *)offset;
...
../libibverbs/verbs.c: In function 'ibv_reg_dmabuf_mr':
../libibverbs/verbs.c:387:13: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
mr->addr = (void *)offset;
...
Reported-by: Ali Alnubani
Signed-off-by: Jianxin Xiong
---
libibverbs/cmd_mr.c | 2 +-
libibverbs/verbs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index af0fad7..736fce0 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -149,7 +149,7 @@ int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t
offset, size_t length,
vmr->ibv_mr.lkey = lkey;
vmr->ibv_mr.rkey = rkey;
vmr->ibv_mr.pd = pd;
- vmr->ibv_mr.addr = (void *)offset;
+ vmr->ibv_mr.addr = (void *)(uintptr_t)offset;
vmr->ibv_mr.length = length;
vmr->mr_type = IBV_MR_TYPE_DMABUF_MR;
return 0;
diff --git a/libibverbs/verbs.c b/libibverbs/verbs.c
index b93046a..f95 100644
--- a/libibverbs/verbs.c
+++ b/libibverbs/verbs.c
@@ -384,7 +384,7 @@ struct ibv_mr *ibv_reg_dmabuf_mr(struct ibv_pd *pd,
uint64_t offset,
mr->context = pd->context;
mr->pd = pd;
- mr->addr = (void *)offset;
+ mr->addr = (void *)(uintptr_t)offset;
mr->length = length;
return mr;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: share scheduler score on VCN3 instances
The series are:
Reviewed-and-Tested-by: Leo Liu
On 2021-02-04 9:44 a.m., Christian König wrote:
The VCN3 instances can do both decode as well as encode.
Share the scheduler load balancing score and remove fixing encode to
only the second instance.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 11 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
index 13aa417f6be7..d10bc4f0a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
@@ -211,6 +211,7 @@ struct amdgpu_vcn_inst {
void*saved_bo;
struct amdgpu_ring ring_dec;
struct amdgpu_ring ring_enc[AMDGPU_VCN_MAX_ENC_RINGS];
+ atomic_tsched_score;
struct amdgpu_irq_src irq;
struct amdgpu_vcn_reg external;
struct amdgpu_bo*dpg_sram_bo;
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index 239a4eb52c61..b33f513fd2ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -171,6 +171,7 @@ static int vcn_v3_0_sw_init(void *handle)
for (i = 0; i < adev->vcn.num_vcn_inst; i++) {
volatile struct amdgpu_fw_shared *fw_shared;
+
if (adev->vcn.harvest_config & (1 << i))
continue;
@@ -198,6 +199,8 @@ static int vcn_v3_0_sw_init(void *handle)
if (r)
return r;
+ atomic_set(>vcn.inst[i].sched_score, 0);
+
ring = >vcn.inst[i].ring_dec;
ring->use_doorbell = true;
if (amdgpu_sriov_vf(adev)) {
@@ -209,7 +212,8 @@ static int vcn_v3_0_sw_init(void *handle)
ring->no_scheduler = true;
sprintf(ring->name, "vcn_dec_%d", i);
r = amdgpu_ring_init(adev, ring, 512, >vcn.inst[i].irq, 0,
-AMDGPU_RING_PRIO_DEFAULT, NULL);
+AMDGPU_RING_PRIO_DEFAULT,
+>vcn.inst[i].sched_score);
if (r)
return r;
@@ -227,11 +231,10 @@ static int vcn_v3_0_sw_init(void *handle)
} else {
ring->doorbell_index =
(adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 2 + j + 8 * i;
}
- if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 1)
- ring->no_scheduler = true;
sprintf(ring->name, "vcn_enc_%d.%d", i, j);
r = amdgpu_ring_init(adev, ring, 512,
>vcn.inst[i].irq, 0,
-AMDGPU_RING_PRIO_DEFAULT, NULL);
+AMDGPU_RING_PRIO_DEFAULT,
+>vcn.inst[i].sched_score);
if (r)
return r;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"
Hi
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
This reverts commit b91907a6241193465ca92e357adf16822242296d.
This should be in the correct format, as given by 'dim cite'.
dim cite b91907a6241193465ca92e357adf16822242296d
b91907a62411 ("drm/qxl: do not run release if qxl failed to init")
Patch is broken, it effectively makes qxl_drm_release() a nop
because on normal driver shutdown qxl_drm_release() is called
*after* drm_dev_unregister().
Cc: Tong Zhang
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 34c8b25b5780..fb5f6a5e81d7 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -144,8 +144,6 @@ static void qxl_drm_release(struct drm_device *dev)
* reodering qxl_modeset_fini() + qxl_device_fini() calls is
* non-trivial though.
*/
- if (!dev->registered)
- return;
I'm not sure what the original problem was, but I'm sure that this isn't
the fix for it. If there's a problem with shutdown, the operations
rather have to be reordered correctly.
With the citation style address:
Acked-by: Thomas Zimmermann
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: make a const array static, makes object smaller
From: Colin Ian King
Don't populate the const array frs_limits on the stack but instead make
it static. Makes the object code smaller by 128 bytes:
Before:
textdata bss dec hex filename
248457440 64 323497e5d ./drivers/gpu/drm/bridge/tc358768.o
After:
textdata bss dec hex filename
247497408 64 322217ddd ./drivers/gpu/drm/bridge/tc358768.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/bridge/tc358768.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358768.c
b/drivers/gpu/drm/bridge/tc358768.c
index 8ed8302d6bbb..2495ea46b091 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -291,7 +291,7 @@ static int tc358768_calc_pll(struct tc358768_priv *priv,
const struct drm_display_mode *mode,
bool verify_only)
{
- const u32 frs_limits[] = {
+ static const u32 frs_limits[] = {
10,
5,
25000,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: make a const array static, makes object smaller
Hi
Am 04.02.21 um 19:17 schrieb Colin King:
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
text data bss dechex filename
34736 4552 0 39288 9978
drivers/gpu/drm/mgag200/mgag200_mode.o
After:
text data bss dechex filename
34625 4616 0 39241 9949
drivers/gpu/drm/mgag200/mgag200_mode.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King
Very nice. I'm actually surprised that the compiler doesn't figure this
out automatically. When I once tested this (in userspace) it did so.
Maybe the kernel is different?
For style reasons, I would have moved the static definition to the top
of the function; before the variable declarations. In any case:
Reviewed-by: Thomas Zimmermann
If I don't here from you, I'll merge the patch soonish.
Best regards
Thomas
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..27f33af09798 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -712,7 +712,7 @@ static int mga_g200er_set_plls(struct mga_device *mdev,
long clock)
unsigned int p, m, n;
unsigned int computed, vco;
int tmp;
- const unsigned int m_div_val[] = { 1, 2, 4, 8 };
+ static const unsigned int m_div_val[] = { 1, 2, 4, 8 };
m = n = p = 0;
vcomax = 1488000;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
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/panel: simple: add SGD GKTW70SDAD1SD
Hi Oliver,
On Tue, Feb 2, 2021 at 2:35 PM Oliver Graute wrote:
> +static const struct panel_desc sgd_gktw70sdad1sd = {
> + .timings = _gktw70sdad1sd_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 153,
> + .height = 86,
> + },
> + .delay = {
> + .prepare = 20 + 20 + 10 + 10,
Adding the datasheet label like Marco suggested make it clearer where
these numbers come from : /* T0 + T2 + T3 + T4 */
Glad you got it working on your imx6ul board:
Reviewed-by: Fabio Estevam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 10/10] drm/qxl: allocate dumb buffers in ram
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann: dumb buffers are shadowed anyway, so there is no need to store them in device memory. Use QXL_GEM_DOMAIN_CPU (TTM_PL_SYSTEM) instead. Makes sense. I had similar issues in other drivers about the placement of buffers. For them, all new buffers now go into system ram by default, and only move into device memory when they have to. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_dumb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c index c04cd5a2553c..48a58ba1db96 100644 --- a/drivers/gpu/drm/qxl/qxl_dumb.c +++ b/drivers/gpu/drm/qxl/qxl_dumb.c @@ -59,7 +59,7 @@ int qxl_mode_dumb_create(struct drm_file *file_priv, surf.stride = pitch; surf.format = format; r = qxl_gem_object_create_with_handle(qdev, file_priv, - QXL_GEM_DOMAIN_SURFACE, + QXL_GEM_DOMAIN_CPU, args->size, , , ); if (r) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 06/10] drm/qxl: properly pin/unpin shadow
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
Suggested-by: Thomas Zimmermann
Signed-off-by: Gerd Hoffmann
Thanks for this.
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 60331e31861a..d25fd3acc891 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -802,12 +802,14 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane,
}
if (user_bo->shadow != qdev->dumb_shadow_bo) {
if (user_bo->shadow) {
+ qxl_bo_unpin(user_bo->shadow);
drm_gem_object_put
(_bo->shadow->tbo.base);
user_bo->shadow = NULL;
}
drm_gem_object_get(>dumb_shadow_bo->tbo.base);
user_bo->shadow = qdev->dumb_shadow_bo;
+ qxl_bo_pin(user_bo->shadow);
}
}
@@ -833,6 +835,7 @@ static void qxl_plane_cleanup_fb(struct drm_plane *plane,
qxl_bo_unpin(user_bo);
if (old_state->fb != plane->state->fb && user_bo->shadow) {
+ qxl_bo_unpin(user_bo->shadow);
drm_gem_object_put(_bo->shadow->tbo.base);
user_bo->shadow = NULL;
}
@@ -1230,6 +1233,7 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
if (qdev->dumb_shadow_bo) {
+ qxl_bo_unpin(qdev->dumb_shadow_bo);
drm_gem_object_put(>dumb_shadow_bo->tbo.base);
qdev->dumb_shadow_bo = NULL;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] immutable branch for amba changes targeting v5.12-rc1
On Thu, Feb 04, 2021 at 04:59:51PM +, Russell King - ARM Linux admin wrote: > On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Feb 04, 2021 at 04:52:24PM +, Russell King - ARM Linux admin > > wrote: > > > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote: > > > > I'm glad to take this through my char/misc tree, as that's where the > > > > other coresight changes flow through. So if no one else objects, I will > > > > do so... > > > > > > Greg, did you end up pulling this after all? If not, Uwe produced a v2. > > > I haven't merged v2 yet as I don't know what you've done. > > > > I thought you merged this? > > I took v1, and put it in a branch I've promised in the past not to > rebase/rewind. Uwe is now asking for me to take a v2 or apply a patch > on top. > > The only reason to produce an "immutable" branch is if it's the basis > for some dependent work and you need that branch merged into other > people's trees... so the whole "lets produce a v2" is really odd > workflow... I'm confused about what I should do, and who has to be > informed which option I take. > > I'm rather lost here too. Sorry to have cause this confusion. After I saw that my initial tag missed to adapt a driver I wanted to make it easy for you to fix the situation. So I created a patch to fix it and created a second tag with the patch squashed in. Obviously only one of them have to be picked and I hoped you (= Russell + Greg) would agree which option to pick. My preference would be if you both pick up v2 of the tag to yield a history that is bisectable without build problems, but if Russell (who already picked up the broken tag) considers his tree immutable and so isn't willing to rebase, then picking up the patch is the way to go. I suggest that Russell descides which option he wants to pick and tells Greg to do the same!? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: make a const array static, makes object smaller
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
textdata bss dechex filename
347364552 0 39288 9978 drivers/gpu/drm/mgag200/mgag200_mode.o
After:
textdata bss dechex filename
346254616 0 39241 9949 drivers/gpu/drm/mgag200/mgag200_mode.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..27f33af09798 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -712,7 +712,7 @@ static int mga_g200er_set_plls(struct mga_device *mdev,
long clock)
unsigned int p, m, n;
unsigned int computed, vco;
int tmp;
- const unsigned int m_div_val[] = { 1, 2, 4, 8 };
+ static const unsigned int m_div_val[] = { 1, 2, 4, 8 };
m = n = p = 0;
vcomax = 1488000;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 05/10] drm/qxl: release shadow on shutdown
Am 04.02.21 um 15:57 schrieb Gerd Hoffmann:
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
+ if (qdev->dumb_shadow_bo) {
+ drm_gem_object_put(>dumb_shadow_bo->tbo.base);
+ qdev->dumb_shadow_bo = NULL;
+ }
qxl_destroy_monitors_object(qdev);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/v3d: Add job timeout module param
On 3/9/20 18:48, Yukimasa Sugizaki wrote:
From: Yukimasa Sugizaki
The default timeout is 500 ms which is too short for some workloads
including Piglit. Adding this parameter will help users to run heavier
tasks.
Signed-off-by: Yukimasa Sugizaki
---
drivers/gpu/drm/v3d/v3d_sched.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index feef0c749e68..983efb018560 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -19,11 +19,17 @@
*/
#include
+#include
#include "v3d_drv.h"
#include "v3d_regs.h"
#include "v3d_trace.h"
+static uint timeout = 500;
+module_param(timeout, uint, 0444);
+MODULE_PARM_DESC(timeout,
+ "Timeout for a job in ms (0 means infinity and default is 500 ms)");
+
I think that parameter definition could be included at v3d_drv.c as
other drivers do. Then we would have all future parameters together. In
that case we would need also to include the extern definition at
v3d_drv.h for the driver variable.
The param name could be more descriptive like "sched_timeout_ms" in the
lima driver.
I wonder if it would make sense to have different timeouts parameters
for different type of jobs we have. At least this series come from the
need additional time to complete compute jobs. This is what amdgpu does,
but we probably don't need something such complex.
I think it would also make sense to increase our default value for the
compute jobs.
What do you think?
In any case I think that having this general scheduling timeout
parameter as other drivers do is a good idea.
Regards,
Chema Casanova
static struct v3d_job *
to_v3d_job(struct drm_sched_job *sched_job)
{
@@ -432,13 +438,13 @@ v3d_sched_init(struct v3d_dev *v3d)
{
int hw_jobs_limit = 1;
int job_hang_limit = 0;
- int hang_limit_ms = 500;
+ long timeout_jiffies = timeout ?
+ msecs_to_jiffies(timeout) : MAX_SCHEDULE_TIMEOUT;
int ret;
ret = drm_sched_init(>queue[V3D_BIN].sched,
_bin_sched_ops,
-hw_jobs_limit, job_hang_limit,
-msecs_to_jiffies(hang_limit_ms),
+hw_jobs_limit, job_hang_limit, timeout_jiffies,
"v3d_bin");
if (ret) {
dev_err(v3d->drm.dev, "Failed to create bin scheduler: %d.",
ret);
@@ -447,8 +453,7 @@ v3d_sched_init(struct v3d_dev *v3d)
ret = drm_sched_init(>queue[V3D_RENDER].sched,
_render_sched_ops,
-hw_jobs_limit, job_hang_limit,
-msecs_to_jiffies(hang_limit_ms),
+hw_jobs_limit, job_hang_limit, timeout_jiffies,
"v3d_render");
if (ret) {
dev_err(v3d->drm.dev, "Failed to create render scheduler: %d.",
@@ -459,8 +464,7 @@ v3d_sched_init(struct v3d_dev *v3d)
ret = drm_sched_init(>queue[V3D_TFU].sched,
_tfu_sched_ops,
-hw_jobs_limit, job_hang_limit,
-msecs_to_jiffies(hang_limit_ms),
+hw_jobs_limit, job_hang_limit, timeout_jiffies,
"v3d_tfu");
if (ret) {
dev_err(v3d->drm.dev, "Failed to create TFU scheduler: %d.",
@@ -472,8 +476,7 @@ v3d_sched_init(struct v3d_dev *v3d)
if (v3d_has_csd(v3d)) {
ret = drm_sched_init(>queue[V3D_CSD].sched,
_csd_sched_ops,
-hw_jobs_limit, job_hang_limit,
-msecs_to_jiffies(hang_limit_ms),
+hw_jobs_limit, job_hang_limit,
timeout_jiffies,
"v3d_csd");
if (ret) {
dev_err(v3d->drm.dev, "Failed to create CSD scheduler:
%d.",
@@ -484,8 +487,7 @@ v3d_sched_init(struct v3d_dev *v3d)
ret = drm_sched_init(>queue[V3D_CACHE_CLEAN].sched,
_cache_clean_sched_ops,
-hw_jobs_limit, job_hang_limit,
-msecs_to_jiffies(hang_limit_ms),
+hw_jobs_limit, job_hang_limit,
timeout_jiffies,
"v3d_cache_clean");
if (ret) {
dev_err(v3d->drm.dev, "Failed to create CACHE_CLEAN
scheduler: %d.",
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH 2/4] drm/dp_mst: Don't cache EDIDs for physical ports
On Mon, Feb 01, 2021 at 02:01:43PM +0200, Imre Deak wrote:
> Caching EDIDs for physical ports prevents updating the EDID if a port
> gets reconnected via a Connection Status Notification message, fix this.
>
> Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
> Cc: Wayne Lin
> Cc: Lyude Paul
> Signed-off-by: Imre Deak
Pushed patches 2-4 to drm-misc-next, thanks for the review.
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index deb7995f42fa..309afe61afdd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2302,7 +2302,8 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
> *mstb,
> }
>
> if (port->pdt != DP_PEER_DEVICE_NONE &&
> - drm_dp_mst_is_end_device(port->pdt, port->mcs)) {
> + drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
> + port->port_num >= DP_MST_LOGICAL_PORT_0) {
> port->cached_edid = drm_get_edid(port->connector,
>>aux.ddc);
> drm_connector_set_tile_property(port->connector);
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge
On Thu, Feb 4, 2021 at 6:26 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Thu, Feb 04, 2021 at 06:19:22PM +0100, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote: > > > W dniu 04.02.2021 o 17:05, Daniel Vetter pisze: > > > > On Thu, Feb 04, 2021 at 11:56:32AM +0100, Michael Tretter wrote: > > > >> On Thu, 04 Feb 2021 11:17:49 +0100, Daniel Vetter wrote: > > > >>> On Wed, Feb 3, 2021 at 9:32 PM Michael Tretter wrote: > > > On Mon, 01 Feb 2021 17:33:14 +0100, Michael Tretter wrote: > > > > On Tue, 15 Sep 2020 21:40:40 +0200, Andrzej Hajda wrote: > > > >> W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze: > > > >>> On 14.09.2020 22:01, Michael Tretter wrote: > > > On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote: > > > > On 14.09.2020 10:29, Marek Szyprowski wrote: > > > >> On 11.09.2020 15:54, Michael Tretter wrote: > > > >>> Make the exynos_dsi driver a full drm bridge that can be > > > >>> found and > > > >>> used > > > >>> from other drivers. > > > >>> > > > >>> Other drivers can only attach to the bridge, if a mipi dsi > > > >>> device > > > >>> already attached to the bridge. This allows to defer the > > > >>> probe of the > > > >>> display pipe until the downstream bridges are available, too. > > > >>> > > > >>> Signed-off-by: Michael Tretter > > > >> This one (and the whole series applied) still fails on Exynos > > > >> boards: > > > >> > > > >> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping > > > >> operations > > > >> exynos-drm exynos-drm: bound 11c0.fimd (ops > > > >> fimd_component_ops) > > > >> OF: graph: no port node found in /soc/dsi@11c8 > > > >> 8<--- cut here --- > > > >> Unable to handle kernel NULL pointer dereference at virtual > > > >> address > > > >> 0084 > > > >> pgd = (ptrval) > > > >> [0084] *pgd= > > > >> Internal error: Oops: 5 [#1] PREEMPT SMP ARM > > > >> Modules linked in: > > > >> CPU: 1 PID: 1 Comm: swapper/0 Not tainted > > > >> 5.9.0-rc4-next-20200911-00010-g417dc70d70ec #1608 > > > >> Hardware name: Samsung Exynos (Flattened Device Tree) > > > >> PC is at drm_bridge_attach+0x18/0x164 > > > >> LR is at exynos_dsi_bind+0x88/0xa8 > > > >> pc : []lr : []psr: 2013 > > > >> sp : ef0dfca8 ip : 0002 fp : c13190e0 > > > >> r10: r9 : ee46d580 r8 : c13190e0 > > > >> r7 : ee438800 r6 : 0018 r5 : ef253810 r4 : ef39e840 > > > >> r3 : r2 : 0018 r1 : ef39e888 r0 : ef39e840 > > > >> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > > > >> none > > > >> Control: 10c5387d Table: 4000404a DAC: 0051 > > > >> Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) > > > >> Stack: (0xef0dfca8 to 0xef0e) > > > >> ... > > > >> [] (drm_bridge_attach) from [] > > > >> (exynos_dsi_bind+0x88/0xa8) > > > >> [] (exynos_dsi_bind) from [] > > > >> (component_bind_all+0xfc/0x290) > > > >> [] (component_bind_all) from [] > > > >> (exynos_drm_bind+0xe4/0x19c) > > > >> [] (exynos_drm_bind) from [] > > > >> (try_to_bring_up_master+0x1e4/0x2c4) > > > >> [] (try_to_bring_up_master) from [] > > > >> (component_master_add_with_match+0xd4/0x108) > > > >> [] (component_master_add_with_match) from > > > >> [] > > > >> (exynos_drm_platform_probe+0xe4/0x110) > > > >> [] (exynos_drm_platform_probe) from [] > > > >> (platform_drv_probe+0x6c/0xa4) > > > >> [] (platform_drv_probe) from [] > > > >> (really_probe+0x200/0x4fc) > > > >> [] (really_probe) from [] > > > >> (driver_probe_device+0x78/0x1fc) > > > >> [] (driver_probe_device) from [] > > > >> (device_driver_attach+0x58/0x60) > > > >> [] (device_driver_attach) from [] > > > >> (__driver_attach+0xdc/0x174) > > > >> [] (__driver_attach) from [] > > > >> (bus_for_each_dev+0x68/0xb4) > > > >> [] (bus_for_each_dev) from [] > > > >> (bus_add_driver+0x158/0x214) > > > >> [] (bus_add_driver) from [] > > > >> (driver_register+0x78/0x110) > > > >> [] (driver_register) from [] > > > >> (exynos_drm_init+0xe4/0x118) > > > >> [] (exynos_drm_init) from [] > > > >> (do_one_initcall+0x8c/0x42c) > > > >> [] (do_one_initcall) from [] > > > >> (kernel_init_freeable+0x190/0x1dc) > > > >> [] (kernel_init_freeable) from [] > > > >> (kernel_init+0x8/0x118) > > > >> [] (kernel_init) from [] > > > >> (ret_from_fork+0x14/0x20) > > > >>
Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add documentation for SN65DSI84
On Wed, Feb 03, 2021 at 12:42:55PM +0530, Jagan Teki wrote:
> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> Texas Instruments.
>
> SN65DSI83, SN65DSI85 are variants of the same family of bridge
> controllers.
>
> Right now the bridge driver is supporting a single link, dual-link
> support requires to initiate I2C Channel B registers, so dt-bindings
> documented with single link LVDS.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - none
>
> .../bindings/display/bridge/ti,sn65dsi84.yaml | 127 ++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
> new file mode 100644
> index ..891382a76c1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi84.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI SN65DSI84 MIPI DSI to LVDS bridge bindings
> +
> +maintainers:
> + - Jagan Teki
> +
> +description: |
> + The SN65DSI84 DSI to FlatLink bridge features a single channel MIPI D-PHY
> receiver
> + front-end configuration with 4 lanes per channel operating at 1 Gbps per
> lanes.
> + The bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and
> converts
> + the formatted video data stream to a FlatLink compatible LVDS output
> operating
> + at pixel clocks operating from 25 MHx to 154 MHz, offering a Dual-Link
> LVDS,
> + Single-Link LVDS interface with four data lanes per link.
> +
> + https://www.ti.com/product/SN65DSI84
> +
> +properties:
> + compatible:
> +const: ti,sn65dsi84
> +
> + reg:
> +maxItems: 1
> +description: i2c address of the bridge, 0x2c
Just 'const: 0x2c' if that's the only valid address.
> +
> + enable-gpios:
> +maxItems: 1
> +description: GPIO specifier for bridge enable pin (active high).
> +
> + ports:
> +type: object
> +description:
> + A node containing input and output port nodes with endpoint definitions
> + as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + DSI Input. The remote endpoint phandle should be a
> + reference to a valid mipi_dsi_host device node.
> +
> + port@1:
> +type: object
> +description: |
> + Video port for LVDS output (panel or connector).
This needs to use the graph.yaml schema. See the ones in drm-misc-next
that are already converted.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi_in: endpoint {
> + remote-endpoint = <_ep0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi_out: endpoint {
> + remote-endpoint = <_in>;
> + data-lanes = <0 1>;
> + };
> + };
> + };
> +};
> +
> +i2c6 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bridge@2c {
> + compatible = "ti,sn65dsi84";
> + reg = <0x2c>;
> + enable-gpios = < 15 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + bridge_in: endpoint {
> +remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + bridge_out: endpoint {
> +remote-endpoint = <_in_lvds>;
> + };
> + };
> + };
> + };
> +};
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge
Hi Daniel, On Thu, Feb 04, 2021 at 06:19:22PM +0100, Daniel Vetter wrote: > On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote: > > W dniu 04.02.2021 o 17:05, Daniel Vetter pisze: > > > On Thu, Feb 04, 2021 at 11:56:32AM +0100, Michael Tretter wrote: > > >> On Thu, 04 Feb 2021 11:17:49 +0100, Daniel Vetter wrote: > > >>> On Wed, Feb 3, 2021 at 9:32 PM Michael Tretter wrote: > > On Mon, 01 Feb 2021 17:33:14 +0100, Michael Tretter wrote: > > > On Tue, 15 Sep 2020 21:40:40 +0200, Andrzej Hajda wrote: > > >> W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze: > > >>> On 14.09.2020 22:01, Michael Tretter wrote: > > On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote: > > > On 14.09.2020 10:29, Marek Szyprowski wrote: > > >> On 11.09.2020 15:54, Michael Tretter wrote: > > >>> Make the exynos_dsi driver a full drm bridge that can be found > > >>> and > > >>> used > > >>> from other drivers. > > >>> > > >>> Other drivers can only attach to the bridge, if a mipi dsi > > >>> device > > >>> already attached to the bridge. This allows to defer the probe > > >>> of the > > >>> display pipe until the downstream bridges are available, too. > > >>> > > >>> Signed-off-by: Michael Tretter > > >> This one (and the whole series applied) still fails on Exynos > > >> boards: > > >> > > >> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping > > >> operations > > >> exynos-drm exynos-drm: bound 11c0.fimd (ops > > >> fimd_component_ops) > > >> OF: graph: no port node found in /soc/dsi@11c8 > > >> 8<--- cut here --- > > >> Unable to handle kernel NULL pointer dereference at virtual > > >> address > > >> 0084 > > >> pgd = (ptrval) > > >> [0084] *pgd= > > >> Internal error: Oops: 5 [#1] PREEMPT SMP ARM > > >> Modules linked in: > > >> CPU: 1 PID: 1 Comm: swapper/0 Not tainted > > >> 5.9.0-rc4-next-20200911-00010-g417dc70d70ec #1608 > > >> Hardware name: Samsung Exynos (Flattened Device Tree) > > >> PC is at drm_bridge_attach+0x18/0x164 > > >> LR is at exynos_dsi_bind+0x88/0xa8 > > >> pc : []lr : []psr: 2013 > > >> sp : ef0dfca8 ip : 0002 fp : c13190e0 > > >> r10: r9 : ee46d580 r8 : c13190e0 > > >> r7 : ee438800 r6 : 0018 r5 : ef253810 r4 : ef39e840 > > >> r3 : r2 : 0018 r1 : ef39e888 r0 : ef39e840 > > >> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > >> Control: 10c5387d Table: 4000404a DAC: 0051 > > >> Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) > > >> Stack: (0xef0dfca8 to 0xef0e) > > >> ... > > >> [] (drm_bridge_attach) from [] > > >> (exynos_dsi_bind+0x88/0xa8) > > >> [] (exynos_dsi_bind) from [] > > >> (component_bind_all+0xfc/0x290) > > >> [] (component_bind_all) from [] > > >> (exynos_drm_bind+0xe4/0x19c) > > >> [] (exynos_drm_bind) from [] > > >> (try_to_bring_up_master+0x1e4/0x2c4) > > >> [] (try_to_bring_up_master) from [] > > >> (component_master_add_with_match+0xd4/0x108) > > >> [] (component_master_add_with_match) from [] > > >> (exynos_drm_platform_probe+0xe4/0x110) > > >> [] (exynos_drm_platform_probe) from [] > > >> (platform_drv_probe+0x6c/0xa4) > > >> [] (platform_drv_probe) from [] > > >> (really_probe+0x200/0x4fc) > > >> [] (really_probe) from [] > > >> (driver_probe_device+0x78/0x1fc) > > >> [] (driver_probe_device) from [] > > >> (device_driver_attach+0x58/0x60) > > >> [] (device_driver_attach) from [] > > >> (__driver_attach+0xdc/0x174) > > >> [] (__driver_attach) from [] > > >> (bus_for_each_dev+0x68/0xb4) > > >> [] (bus_for_each_dev) from [] > > >> (bus_add_driver+0x158/0x214) > > >> [] (bus_add_driver) from [] > > >> (driver_register+0x78/0x110) > > >> [] (driver_register) from [] > > >> (exynos_drm_init+0xe4/0x118) > > >> [] (exynos_drm_init) from [] > > >> (do_one_initcall+0x8c/0x42c) > > >> [] (do_one_initcall) from [] > > >> (kernel_init_freeable+0x190/0x1dc) > > >> [] (kernel_init_freeable) from [] > > >> (kernel_init+0x8/0x118) > > >> [] (kernel_init) from [] > > >> (ret_from_fork+0x14/0x20) > > >> Exception stack(0xef0dffb0 to 0xef0dfff8) > > >> ... > > >> ---[ end trace ee27f313f9ed9da1 ]--- > > >> > > >> # arm-linux-gnueabi-addr2line -e vmlinux c0628c08 > > >> drivers/gpu/drm/drm_bridge.c:184 (discriminator 1) > > >> > >
Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge
On Thu, Feb 4, 2021 at 5:28 PM Andrzej Hajda wrote: > > > W dniu 04.02.2021 o 17:05, Daniel Vetter pisze: > > On Thu, Feb 04, 2021 at 11:56:32AM +0100, Michael Tretter wrote: > >> On Thu, 04 Feb 2021 11:17:49 +0100, Daniel Vetter wrote: > >>> On Wed, Feb 3, 2021 at 9:32 PM Michael Tretter > >>> wrote: > On Mon, 01 Feb 2021 17:33:14 +0100, Michael Tretter wrote: > > On Tue, 15 Sep 2020 21:40:40 +0200, Andrzej Hajda wrote: > >> W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze: > >>> On 14.09.2020 22:01, Michael Tretter wrote: > On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote: > > On 14.09.2020 10:29, Marek Szyprowski wrote: > >> On 11.09.2020 15:54, Michael Tretter wrote: > >>> Make the exynos_dsi driver a full drm bridge that can be found and > >>> used > >>> from other drivers. > >>> > >>> Other drivers can only attach to the bridge, if a mipi dsi device > >>> already attached to the bridge. This allows to defer the probe of > >>> the > >>> display pipe until the downstream bridges are available, too. > >>> > >>> Signed-off-by: Michael Tretter > >> This one (and the whole series applied) still fails on Exynos > >> boards: > >> > >> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping > >> operations > >> exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) > >> OF: graph: no port node found in /soc/dsi@11c8 > >> 8<--- cut here --- > >> Unable to handle kernel NULL pointer dereference at virtual address > >> 0084 > >> pgd = (ptrval) > >> [0084] *pgd= > >> Internal error: Oops: 5 [#1] PREEMPT SMP ARM > >> Modules linked in: > >> CPU: 1 PID: 1 Comm: swapper/0 Not tainted > >> 5.9.0-rc4-next-20200911-00010-g417dc70d70ec #1608 > >> Hardware name: Samsung Exynos (Flattened Device Tree) > >> PC is at drm_bridge_attach+0x18/0x164 > >> LR is at exynos_dsi_bind+0x88/0xa8 > >> pc : []lr : []psr: 2013 > >> sp : ef0dfca8 ip : 0002 fp : c13190e0 > >> r10: r9 : ee46d580 r8 : c13190e0 > >> r7 : ee438800 r6 : 0018 r5 : ef253810 r4 : ef39e840 > >> r3 : r2 : 0018 r1 : ef39e888 r0 : ef39e840 > >> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > >> Control: 10c5387d Table: 4000404a DAC: 0051 > >> Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) > >> Stack: (0xef0dfca8 to 0xef0e) > >> ... > >> [] (drm_bridge_attach) from [] > >> (exynos_dsi_bind+0x88/0xa8) > >> [] (exynos_dsi_bind) from [] > >> (component_bind_all+0xfc/0x290) > >> [] (component_bind_all) from [] > >> (exynos_drm_bind+0xe4/0x19c) > >> [] (exynos_drm_bind) from [] > >> (try_to_bring_up_master+0x1e4/0x2c4) > >> [] (try_to_bring_up_master) from [] > >> (component_master_add_with_match+0xd4/0x108) > >> [] (component_master_add_with_match) from [] > >> (exynos_drm_platform_probe+0xe4/0x110) > >> [] (exynos_drm_platform_probe) from [] > >> (platform_drv_probe+0x6c/0xa4) > >> [] (platform_drv_probe) from [] > >> (really_probe+0x200/0x4fc) > >> [] (really_probe) from [] > >> (driver_probe_device+0x78/0x1fc) > >> [] (driver_probe_device) from [] > >> (device_driver_attach+0x58/0x60) > >> [] (device_driver_attach) from [] > >> (__driver_attach+0xdc/0x174) > >> [] (__driver_attach) from [] > >> (bus_for_each_dev+0x68/0xb4) > >> [] (bus_for_each_dev) from [] > >> (bus_add_driver+0x158/0x214) > >> [] (bus_add_driver) from [] > >> (driver_register+0x78/0x110) > >> [] (driver_register) from [] > >> (exynos_drm_init+0xe4/0x118) > >> [] (exynos_drm_init) from [] > >> (do_one_initcall+0x8c/0x42c) > >> [] (do_one_initcall) from [] > >> (kernel_init_freeable+0x190/0x1dc) > >> [] (kernel_init_freeable) from [] > >> (kernel_init+0x8/0x118) > >> [] (kernel_init) from [] > >> (ret_from_fork+0x14/0x20) > >> Exception stack(0xef0dffb0 to 0xef0dfff8) > >> ... > >> ---[ end trace ee27f313f9ed9da1 ]--- > >> > >> # arm-linux-gnueabi-addr2line -e vmlinux c0628c08 > >> drivers/gpu/drm/drm_bridge.c:184 (discriminator 1) > >> > >> I will try to debug it a bit more today. > > The above crash has been caused by lack of in_bridge initialization > > to > > NULL in exynos_dsi_bind() in this patch. However, fixing it reveals > > another issue: > > > > [drm] Exynos DRM: using 11c0.fimd device for DMA
Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote: > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote: > > tldr; DMA buffers aren't normal memory, expecting that you can use > > them like that (like calling get_user_pages works, or that they're > > accounting like any other normal memory) cannot be guaranteed. > > > > Since some userspace only runs on integrated devices, where all > > buffers are actually all resident system memory, there's a huge > > temptation to assume that a struct page is always present and useable > > like for any more pagecache backed mmap. This has the potential to > > result in a uapi nightmare. > > > > To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which > > blocks get_user_pages and all the other struct page based > > infrastructure for everyone. In spirit this is the uapi counterpart to > > the kernel-internal CONFIG_DMABUF_DEBUG. > > Fast gup needs the special flag set on the PTE as well.. Feels weird > to have a special VMA without also having special PTEs? There's kinda no convenient & cheap way to check for the pte_special flag. This here should at least catch accidental misuse, people building their own ptes we can't stop. Maybe we should exclude VM_MIXEDMAP to catch vm_insert_page in one of these. Hm looking at code I think we need to require VM_PFNMAP here to stop vm_insert_page. And looking at the various functions, that seems to be required (and I guess VM_IO is more for really funky architectures where io-space is somewhere else?). I guess I should check for VM_PFNMAP instead of VM_SPECIAL? -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 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 driver
Hi, On Sat, Jan 30, 2021 at 10:10 AM Marek Vasut wrote: > > Add driver for TI SN65DSI83 Single-Channel DSI to Single-Link LVDS bridge. > The driver operates the chip over I2C bus. Currently the LVDS clock are > always derived from DSI clock lane, which is the usual mode of operation, > support for clock from external oscillator is not implemented, but it is > easy to add if ever needed. Only RGB888 pixel format is implemented, the > LVDS666 is not supported, but could be added if needed. > > Signed-off-by: Marek Vasut > Cc: Douglas Anderson > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Philippe Schenker > Cc: Sam Ravnborg > Cc: Stephen Boyd > Cc: Valentin Raevsky > To: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 535 ++ > 3 files changed, 546 insertions(+) I shouldn't be the main reviewer because, as I've said elsewhere, I'm a DRM noob and know almost nothing about LVDS or MIPI. :-P ...but I've hacked a bunch on the sn65dsi86 driver and lots of others have helped me with reviews, so I'll give it a shot... > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index cc401786962a..5e4f674e3fdb 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -234,6 +234,16 @@ config DRM_TI_TFP410 > help > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > +config DRM_TI_SN65DSI83 > + tristate "TI SN65DSI83 DSI to LVDS bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + select DRM_MIPI_DSI > + help > + Texas Instruments SN65DSI83 DSI to LVDS Bridge driver > + > config DRM_TI_SN65DSI86 > tristate "TI SN65DSI86 DSI to eDP bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 21ea8fe09992..e11415db0a31 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -21,6 +21,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > new file mode 100644 > index ..79c023ba3dce > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -0,0 +1,535 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2021 Marek Vasut > + * > + * Based on previous work of: > + * Valentin Raevsky > + * Philippe Schenker > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* ID registers */ > +#define REG_ID(n) (0x00 + (n)) > +/* Reset and clock registers */ > +#define REG_RC_RESET 0x09 > +#define REG_RC_RESET_SOFT_RESET BIT(0) > +#define REG_RC_LVDS_PLL0x0a > +#define REG_RC_LVDS_PLL_PLL_EN_STAT BIT(7) > +#define REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n) (((n) & 0x7) << 1) > +#define REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY BIT(0) > +#define REG_RC_DSI_CLK 0x0b > +#define REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n) (((n) & 0x1f) << 3) > +#define REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n) ((n) & 0x3) > +#define REG_RC_PLL_EN 0x0d > +#define REG_RC_PLL_EN_PLL_EN BIT(0) > +/* DSI registers */ > +#define REG_DSI_LANE 0x10 > +#define REG_DSI_LANE_RESERVED BIT(5) > +#define REG_DSI_LANE_CHA_DSI_LANES(n) (((n) & 0x3) << 3) > +#define REG_DSI_LANE_SOT_ERR_TOL_DIS BIT(0) > +#define REG_DSI_EQ 0x11 > +#define REG_DSI_EQ_CHA_DSI_DATA_EQ(n) (((n) & 0x3) << 6) > +#define REG_DSI_EQ_CHA_DSI_CLK_EQ(n) (((n) & 0x3) << 2) > +#define REG_DSI_CLK0x12 > +#define REG_DSI_CLK_CHA_DSI_CLK_RANGE(n) ((n) & 0xff) > +/* LVDS registers */ > +#define REG_LVDS_FMT 0x18 > +#define REG_LVDS_FMT_DE_NEG_POLARITY BIT(7) > +#define REG_LVDS_FMT_HS_NEG_POLARITY BIT(6) > +#define REG_LVDS_FMT_VS_NEG_POLARITY BIT(5) > +#define REG_LVDS_FMT_RESERVED BIT(4) /* Set to 1 */ > +#define REG_LVDS_FMT_CHA_24BPP_MODE BIT(3) > +#define REG_LVDS_FMT_CHA_24BPP_FORMAT1
