Re: [PATCHv5 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
Hi Ong,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc4 next-20170804]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hean-Loong-Ong/Intel-FPGA-VIP-Frame-Buffer-II-drm-driver/20170803-200814
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
drivers/gpu/drm/ivip/intel_vip_core.c: In function 'intelvipfb_enable':
>> drivers/gpu/drm/ivip/intel_vip_core.c:57:2: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 3 has type 'dma_addr_t'
>> [-Wformat]
vim +57 drivers/gpu/drm/ivip/intel_vip_core.c
39
40 static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
41 struct drm_crtc_state *crtc_state)
42 {
43 /*
44 * The frameinfo variable has to correspond to the size of the
VIP Suite
45 * Frame Reader register 7 which will determine the maximum
size used
46 * in this frameinfo
47 */
48
49 u32 frameinfo;
50 struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
51 void __iomem *base = priv->base;
52 struct drm_plane_state *state = pipe->plane.state;
53 dma_addr_t addr;
54
55 addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
56
> 57 dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
58
59 frameinfo =
60 readl(base + INTELVIPFB_FRAME_READER) & 0x00ff;
61 writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
62 writel(addr, base + INTELVIPFB_FRAME_START);
63 /* Finally set the control register to 1 to start streaming */
64 writel(1, base + INTELVIPFB_CONTROL);
65 }
66
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102044] Testing Report
https://bugs.freedesktop.org/show_bug.cgi?id=102044 Jani Nikula changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102044] Testing Report
https://bugs.freedesktop.org/show_bug.cgi?id=102044 Jani Nikula changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dw-hdmi: add missing cec_notifier_put
The __dw_hdmi_remove() function was missing a call to cec_notifier_put to balance the cec_notifier_get in the probe function. Signed-off-by: Hans Verkuil --- This fix was in the v3 patch but unfortunately the v2 patch ended up being merged. So fix this in a separate patch. --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index f8171cd07e74..a24ec4ad18bd 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2496,6 +2496,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) /* Disable all interrupts */ hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0); + if (hdmi->cec_notifier) + cec_notifier_put(hdmi->cec_notifier); + clk_disable_unprepare(hdmi->iahb_clk); clk_disable_unprepare(hdmi->isfr_clk); -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #20 from 247 --- now even kodi (which was the only player working) started to give me the same problems and seems i can't play mp4 and mkv anymore...think i will just give up and end up doing a clean install... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102013] GTK3 tooltips are corrupted after updating to Radeon 7.9.0
https://bugs.freedesktop.org/show_bug.cgi?id=102013 Michel Dänzer changed: What|Removed |Added Version|7.7 (2012.06) |unspecified Product|xorg|Mesa Component|Driver/Radeon |Drivers/Gallium/r600 Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org --- Comment #14 from Michel Dänzer --- Given that there haven't seemed to be any similar reports with GCN hardware, I suspect the tooltip issue is a Mesa r600 driver bug. E.g. https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/r600?id=e6d7937b86d8f3c7e0605741de8721caf991af05 or something like that might explain it. The window resizing issue is probably separate and should be tracked separately. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
After going through the previous discussions, here are some summaries may be
related to the current discussion:
1. How does user mode figure the device capabilities between region and dma-buf?
VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case.
Otherwise, the mdev supports dma-buf.
2. For dma-buf, how to differentiate unsupported vs not initialized?
For dma-buf, when the mdev doesn't support some arguments, -EINVAL will be
returned. And -errno will return when meeting other failures, like -ENOMEM.
If the mdev is not initialized, there won't be any returned err. Just zero all
the fields in structure vfio_device_gfx_plane_info.
3. The id field in structure vfio_device_gfx_plane_info
So far we haven't figured out the usage of this field for dma-buf usage. So,
this field is changed to "region_index" and only used for region usage.
In previous discussions, we thought this "id" field might be used for both
dma-buf and region usages.
So, we proposed some ways, like adding flags field to the structure. Another
way to do it was to add this:
enum vfio_device_gfx_type {
VFIO_DEVICE_GFX_NONE,
VFIO_DEVICE_GFX_DMABUF,
VFIO_DEVICE_GFX_REGION,
};
struct vfio_device_gfx_query_caps {
__u32 argsz;
__u32 flags;
enum vfio_device_gfx_type;
};
Obviously, we don't need to consider this again, unless we find the
"region_index" means something for dma-buf usage.
Thanks.
BR,
Tina
> -Original Message-
> From: Zhang, Tina
> Sent: Monday, August 7, 2017 11:23 AM
> To: 'Alex Williamson'
> Cc: Tian, Kevin ; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; kwankh...@nvidia.com; kra...@redhat.com;
> intel-gvt-...@lists.freedesktop.org; Wang, Zhi A ; Lv,
> Zhiyuan
> Subject: RE: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
>
>
>
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> > Behalf Of Alex Williamson
> > Sent: Thursday, August 3, 2017 10:43 PM
> > To: Zhang, Tina
> > Cc: Tian, Kevin ;
> > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org;
> > kwankh...@nvidia.com; kra...@redhat.com;
> > intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> > ; Lv, Zhiyuan
> > Subject: Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf
> > operation
> >
> > On Thu, 3 Aug 2017 07:08:15 +
> > "Zhang, Tina" wrote:
> >
> > > > -Original Message-
> > > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > > Sent: Thursday, August 3, 2017 11:38 AM
> > > > To: Zhang, Tina
> > > > Cc: Tian, Kevin ;
> > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org;
> > > > kwankh...@nvidia.com; kra...@redhat.com;
> > > > intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> > > > ; Lv, Zhiyuan
> > > > Subject: Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf
> > > > operation
> > > >
> > > > On Thu, 3 Aug 2017 03:17:09 +
> > > > "Zhang, Tina" wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: dri-devel
> > > > > > [mailto:dri-devel-boun...@lists.freedesktop.org]
> > > > > > On Behalf Of Alex Williamson
> > > > > > Sent: Wednesday, August 2, 2017 5:18 AM
> > > > > > To: Zhang, Tina
> > > > > > Cc: Tian, Kevin ; kra...@redhat.com;
> > > > > > intel- g...@lists.freedesktop.org; Wang, Zhi A
> > > > > > ; kwankh...@nvidia.com;
> > > > > > dri-devel@lists.freedesktop.org; intel-gvt-
> > > > > > d...@lists.freedesktop.org; Lv, Zhiyuan
> > > > > > Subject: Re: [PATCH v13 5/7] vfio: ABI for mdev display
> > > > > > dma-buf operation
> > > > > >
> > > > > > On Tue, 25 Jul 2017 17:28:18 +0800 Tina Zhang
> > > > > > wrote:
> > > > > >
> > > > > > > Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user
> > mode
> > > > > > > query and get the plan and its related information.
> > > > > > >
> > > > > > > The dma-buf's life cycle is handled by user mode and tracked by
> kernel.
> > > > > > > The returned fd in struct vfio_device_query_gfx_plane can be
> > > > > > > a new fd or an old fd of a re-exported dma-buf. Host User
> > > > > > > mode can check the value of fd and to see if it needs to
> > > > > > > create new resource according to the new fd or just use the
> > > > > > > existed resource related to the old
> > > > fd.
> > > > > > >
> > > > > > > Signed-off-by: Tina Zhang
> > > > > > > ---
> > > > > > > include/uapi/linux/vfio.h | 28
> > > > > > > 1 file changed, 28 insertions(+)
> > > > > > >
> > > > > > > diff --git a/include/uapi/linux/vfio.h
> > > > > > > b/include/uapi/linux/vfio.h index ae46105..827a230 100644
> > > > > > > --- a/include/uapi/linux/vfio.h
> > > > > > > +++ b/include/uapi/linux/vfio.h
> > > > > > > @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
> > > > > > >
> > > > > > > #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE,
> VFIO_BASE +
> > > > > > 13)
> > > > > > >
> > > > > > > +/**
> > > > > > > + * VFIO_DEVICE_QUERY_GFX_PLANE
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #21 from 247 --- just a quick update...since wayland is quite laggy to me i returned to xorg...my problems with kodi started with that, so i decided to return back to wayland to see if kodi worked, and it's perfectly working...so now the situation is : no player is working on xorg and no player except kodi is working on wayland... this bug will make me mad :P -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v13 6/7] drm/i915: Introduce GEM proxy
On ti, 2017-07-25 at 17:28 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such a special kind of GEM, a new flag
> I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
> backing storage of GEM proxy.
>
It is a good idea to add a changelog here to indicate what was changed
since the last patch revision. It'll be easier for the reviewer to spot
the differences.
It's also a good idea to add Cc: line for somebody who provided
previous review, this will, too, allow spotting the patch quicker.
> Signed-off-by: Tina Zhang
> @@ -1730,7 +1744,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> */
> if (!obj->base.filp) {
> i915_gem_object_put(obj);
> - return -EINVAL;
> + return -EPERM;
> }
This hunk should be separate bugfix patch, but other than that the
patch looks OK to me.
I'll let Chris comment if he feels previous comments were adequately
addressed.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
On Sun, Aug 6, 2017 at 5:32 AM, Keith Packard wrote: > Daniel Vetter writes: > >> Since I missed all the details Michel spotted, so I'll defer to his r-b. >> Also, before merging we need the userspace user. Do we have e.g. >> -modesetting patch for this, fully reviewed&ready for merging, just as >> demonstration? > > Well, given that we'll have to keep the old API around for older > kernels, at least for a decade or so, I'm not sure why we'd actually > want that anytime soon, if ever? I guess it does provide 64-bit sequence > numbers, which Present wants? I just figured that -modesetting would be the simplest domenstration vehicle, since the vulkan patches don't look ready yet. I need fully reviewed&tested userspace before we can land any kernel stuff. Doing the quick modesetting conversion would unblock. >> This way we could land this before the lease stuff for the >> vk extension is all solid&ready. > > Do you think there's a pile more work to be done for the lease changes > in the kernel? Or are you just trying to separate the work flows? > > I can go re-write the modesetting present support to use this new API > and use that for testing the kernel, if you think that would help move > the kernel bits along. Just trying to separate flows and get stuff landed as soon as it's ready. There's always the chance someone rewrites the code meanwhile if we wait until all the vk stuff is ready. >>> +drm_modeset_lock(&crtc->mutex, NULL); >>> +if (crtc->state) >>> +get_seq->active = crtc->state->enable; >>> +else >>> +get_seq->active = crtc->enabled; >>> +drm_modeset_unlock(&crtc->mutex); >> >> This is really heavywheight, given the lockless dance we attempt above. >> Also, when the crtc is off the vblank_get will fail, so you never get >> here. I guess my idea wasn't all that useful and well-thought out, or we >> need to be a bit more clever about this. To fix this we need to continue >> even when vblank_get fails (but only call vblank_put if ret == 0 ofc). And >> to avoid the locking you can use READ_ONCE(vblank->enabled) instead. > > So, in reality, the client can more-or-less tell that the crtc is > disabled because the call fails? Sounds like I can just remove the > little dance to get the CRTC enabled state entirely. I don't understand > your comment about READ_ONCE(vblank->enabled); that doesn't relate to > the crtc enabled state, I don't think? It's supposed to, at least for atomic drivers. For legacy kms drivers they're supposed to reject the enable attempt with some error code, when the CRTC is off. It's all pretty awkward ad-hoc uabi :-( I'm leaning more-and-more towards just dropping this part as a bad idea from my side. At least until we have someone who really needs this. >>> + >>> +/* Queue event to be delivered at specified sequence */ >>> + >>> +#define DRM_CRTC_SEQUENCE_RELATIVE 0x0001 /* sequence is >>> relative to current */ >>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS 0x0002 /* Use >>> next sequence if we've missed */ >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x0004 /* Signal when >>> first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen" around vblank (right before up to >> first pixel are all things current drivers implement). >> - An atomic update or pageflip ioctl call right after a vblank event will >> hit (assuming no stalls) sequence + 1. radeon/amdgpu have some sw hacks >> to handle this because their vblank event gets delivered before the last >> possible time to update the next frame. >> - The timestamp is corrected to be top-of-frame. >> >> Would be a good time to document this a bit better, and might not exactly >> match what vk expects ... > > (NEXT_ON_MISS is not used by the new Vulkan code; I added it only to keep > compatibility with the old API, in case we want to switch someday). > > FIRST_PIXEL_OUT is an attempt to signal to the kernel that the > application really wants to see the event when the first pixel hits the > display. I assume the important thing here is the timestamp in the > event and not the actual delivery, but I don't actually know that. > > If the timestamp is the only important thing, it sounds like the kernel > already satisfies that, which is cool. Would be good to confirm that. If it's not, we have a problem. > If Vulkan really wants the event to be delivered when the first pixel is > displayed, then having this bit in the ioctl means we can let drivers > continue to do whatever they are now when the bit isn't set, but try > harder to deliver the event at first-pixel when requested. > > So, I think what I want to do is leave the bit in the request so that > drivers can at least see what user space is asking for, and if we learn > that it's important to deliver the event at the requested time, we can > go fix drivers later. Not sure that's a good idea without fixing up dr
Re: [PATCH v2] drm: dw-hdmi-i2s: add missing company name on Copyright
Hi Morimoto-san, Thank you for the patch. On Monday 07 Aug 2017 04:09:41 Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This driver's Copyright is under Renesas Solutions Corp. > This patch updates the year, because this driver was moved > into synopsys folder in 2017. > > Signed-off-by: Kuninori Morimoto > --- > v1 -> v2 > > - update year 2016 -> 2017 > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index > b2cf59f..3b7e5c5 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > @@ -1,7 +1,8 @@ > /* > * dw-hdmi-i2s-audio.c > * > - * Copyright (c) 2016 Kuninori Morimoto > + * Copyright (c) 2017 Renesas Solutions Corp. > + * Kuninori Morimoto What does this mean ? The first line makes it clear that you want to assign copyright ownership to Renesas for the work you've done on this driver. The second line, however, isn't very clear. If you want to list your e-mail address as an author or contact person, you should make that explicit: * Author: Kuninori Morimoto or * Contact: Kuninori Morimoto Or it could be that you have joint copyright ownership with Renesas, or own parts of the copyright yourself, in which case it should be * Copyright (c) 2017 Renesas Solutions Corp. * Copyright (c) 2017 Kuninori Morimoto > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dim: symbolic link for the rr-cache
After about a month and a few attempts it's clear that my rr-cache gc
logic is busted. When copying stuff back&forth between the git branch
and git's rr-cache dir, something somewhere (or maybe it's git rerere
itself) touches all files and wreaks the timestamps.
End result is that over this month, every time when someone gc'ed a
few files, they've been resurrected a few days later by someone else.
I think the only way to fix this is by dropping the copying and
replacing git's rr-cache with a symbolic link. That way, when we
delete an rr-cache entry in the git branch, it won't be able to
resurrect. I hope at least ...
This also makes dim revert-rerere no longer needed, delete it.
v2: Unfunny the ln option placement (Jani).
Acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
dim | 22 +++---
dim.rst | 9 -
2 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/dim b/dim
index d52510529fa2..f8be76df4952 100755
--- a/dim
+++ b/dim
@@ -504,8 +504,13 @@ function update_rerere_cache
cd $DIM_PREFIX/drm-rerere/
git pull &> /dev/null
- mkdir $(rr_cache_dir) &> /dev/null || true
- cp rr-cache/* $(rr_cache_dir) -r --preserve=timestamps
+ if [ -d $(rr_cache_dir) ] ; then
+ rm -Rf $(rr_cache_dir)
+ fi
+ if [ ! -L $(rr_cache_dir) ] ; then
+ ln -s "$DIM_PREFIX/drm-rerere/rr-cache" $(dirname
$(rr_cache_dir))
+ fi
+
cd - > /dev/null
echo "Done."
@@ -519,8 +524,6 @@ function commit_rerere_cache
if git_is_current_branch rerere-cache ; then
remote=$(branch_to_remote rerere-cache)
- rm $(rr_cache_dir)/rr-cache -Rf &> /dev/null || true
- cp $(rr_cache_dir)/* rr-cache -r --preserve=timestamps
git pull >& /dev/null
git add ./*.patch >& /dev/null || true
for file in $(git ls-files); do
@@ -543,17 +546,6 @@ function commit_rerere_cache
fi
}
-function dim_revert_rerere
-{
- local commit
-
- commit=${1:?$usage}
-
- cd $DIM_PREFIX/drm-rerere/
- git revert $commit
- rm $(rr_cache_dir)/* -Rf
-}
-
dim_alias_rebuild_nightly=rebuild-tip
function dim_rebuild_tip
{
diff --git a/dim.rst b/dim.rst
index f012a831da74..a2c110a054ee 100644
--- a/dim.rst
+++ b/dim.rst
@@ -247,15 +247,6 @@ Rebuild and push the integration tree.
ADVANCED COMMANDS FOR COMMITTERS AND MAINTAINERS
-revert-rerere *rerere-cache-commit-ish*
-When a stored conflict resolution in the integration tree is wrong, this
command
-can be used to fix up the mess. First figure out which commit in the
-*rerere-cache* branch contains the bogus conflict resolution, then revert it
-using this command. This ensures the resolution is also purged from any local
-caches, to make sure it doesn't get resurrected. Then run *rebuild-tip* to redo
-the merges, correctly.
-
cat-to-fixup
Pipes stdin into the fixup patch file for the current drm-tip merge.
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] dim: Continue also for dry runs
On Thu, Aug 3, 2017 at 2:44 PM, Jani Nikula wrote:
> On Thu, 27 Jul 2017, Daniel Vetter wrote:
>> It's a bit silly to have to spec both -d and -f to see what dim would
>> all complain about. And dry-run should never cause bad side-effects.
>
> Ack.
>
> We don't do dry-run all that well in general, partly because you need to
> have one part actually succeed to make the rest succeed. And some things
> don't do dry-run at all. Those could bail out with an error right
> away. To the endless todo list...
Yeah, one of the biggest things I'd like to see is dim push-branch not
pushing until the dry-run (and entirely offline) rebuild-tip
succeeded. I think otherwise we're fairly good with dry-runs ...
-Daniel
>
> BR,
> Jani.
>
>>
>> Signed-off-by: Daniel Vetter
>> ---
>> dim | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/dim b/dim
>> index c0cbe352b165..96aaf7101d6b 100755
>> --- a/dim
>> +++ b/dim
>> @@ -126,6 +126,8 @@ function warn_or_fail
>> {
>> if [[ $FORCE ]] ; then
>> echoerr "WARNING: $1, but continuing"
>> + elif [[ $DRY ]] ; then
>> + echoerr "WARNING: $1, but continuing dry-run"
>> else
>> echoerr "ERROR: $1, aborting"
>> exit 1
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/29] drm/i915: switch to drm_*{get,put} helpers
On Thu, Aug 3, 2017 at 5:52 PM, Cihangir Akturk wrote: > On Thu, Aug 03, 2017 at 02:49:03PM +0200, Daniel Vetter wrote: >> On Thu, Aug 03, 2017 at 03:26:01PM +0300, Jani Nikula wrote: >> > On Thu, 03 Aug 2017, Cihangir Akturk wrote: >> > > drm_*_reference() and drm_*_unreference() functions are just >> > > compatibility alias for drm_*_get() and drm_*_put() adn should not be >> > > used by new code. So convert all users of compatibility functions to use >> > > the new APIs. >> > >> > Please include the cocci script in the commit message. If you didn't use >> > cocci, you should check it out! :) >> >> Yeah I assume you've created these with spatch/cocci, not with your own >> script. I trust cocci a lot more than any kind of scripting, and the >> coccie patch is already in there kernel (the commits you've cited in the >> cover letter contain it iirc). > > I wrote a simple shell script, which you can see in the cover letter. > But you are right I take function list from > scripts/coccinelle/api/drm-get-put.cocci > file. > > Daniel Should I use coccinelle to generate patches and resend a v2? > If so, do i need to include reviewed-by and acked-by tags to patches myself? I think regenerating the patches using cocci would be great, I trust cocci a lot more than random scripts. And cocci is a great tool to learn anyway (if you don't know it yet). If the resulting patches match, you can keep the r-b/a-b tags for v2. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] staging: vboxvideo: remove dead gamma lut code
On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code that was not doing anything
> sensible anyway.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/staging/vboxvideo/vbox_fb.c | 15 ---
> drivers/staging/vboxvideo/vbox_mode.c | 5 -
> 2 files changed, 20 deletions(-)
>
> [This time with an improved Cc list, sorry for the noise. For new
> people, please refer to https://lkml.org/lkml/2017/7/13/593 for
> context]
>
> Hi Daniel,
>
> Here it goes, but do you really need me to resend v5 14/14?
Well it's not yet on dri-devel, but our pre-merge CI bots can't read such
instructions. They expect a clean new series that applies cleanly, as a
top-post, when resending stuff.
Anyway, applied.
Thanks, Daniel
>
> Cheers,
> peda
>
> diff --git a/drivers/staging/vboxvideo/vbox_fb.c
> b/drivers/staging/vboxvideo/vbox_fb.c
> index 35f6d9f8c203..bf6635826159 100644
> --- a/drivers/staging/vboxvideo/vbox_fb.c
> +++ b/drivers/staging/vboxvideo/vbox_fb.c
> @@ -317,22 +317,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
> return 0;
> }
>
> -static void vbox_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
> - u16 blue, int regno)
> -{
> -}
> -
> -static void vbox_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
> - u16 *blue, int regno)
> -{
> - *red = regno;
> - *green = regno;
> - *blue = regno;
> -}
> -
> static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
> - .gamma_set = vbox_fb_gamma_set,
> - .gamma_get = vbox_fb_gamma_get,
> .fb_probe = vboxfb_create,
> };
>
> diff --git a/drivers/staging/vboxvideo/vbox_mode.c
> b/drivers/staging/vboxvideo/vbox_mode.c
> index f2b85f3256fa..996da1c79158 100644
> --- a/drivers/staging/vboxvideo/vbox_mode.c
> +++ b/drivers/staging/vboxvideo/vbox_mode.c
> @@ -134,10 +134,6 @@ static int vbox_set_view(struct drm_crtc *crtc)
> return 0;
> }
>
> -static void vbox_crtc_load_lut(struct drm_crtc *crtc)
> -{
> -}
> -
> static void vbox_crtc_dpms(struct drm_crtc *crtc, int mode)
> {
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> @@ -330,7 +326,6 @@ static const struct drm_crtc_helper_funcs
> vbox_crtc_helper_funcs = {
> .mode_set = vbox_crtc_mode_set,
> /* .mode_set_base = vbox_crtc_mode_set_base, */
> .disable = vbox_crtc_disable,
> - .load_lut = vbox_crtc_load_lut,
> .prepare = vbox_crtc_prepare,
> .commit = vbox_crtc_commit,
> };
> --
> 2.11.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
Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack
Op 04-08-17 om 12:02 schreef Daniel Vetter: > On Fri, Aug 4, 2017 at 11:57 AM, Tomi Valkeinen wrote: >>> Here you go, compile tested version. :) >>> 8< >>> I want/need to rework the core property handling, and this hack is >>> getting in the way. But since it's a non-standard propety only used by >>> legacy userspace we know that this will only every be called from >>> ioctl code. And never on some other free-standing state struct, where >>> this old hack wouldn't work either. >>> >>> v2: don't forget zorder and get_property! >>> >>> v3: Shadow the legacy state to avoid locking issues in get_property >>> (Maarten). >>> >>> v4: Review from Laurent >>> - Move struct omap_crtc_state into omap_crtc.c >>> - Clean up comments. >>> - Don't forget to copy the shadowed state over on duplicate. >>> >>> v5: Don't forget to update the reset handler (Maarten). >>> v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check >>> (Maarten). >>> >>> Reviewed-by: Laurent Pinchart (v4) >>> Cc: Maarten Lankhorst >>> Cc: Tomi Valkeinen >> Cc: Laurent Pinchart >>> Signed-off-by: Daniel Vetter >>> Signed-off-by: Maarten Lankhorst >>> --- >>> drivers/gpu/drm/omapdrm/omap_crtc.c | 118 >>> +--- >>> 1 file changed, 81 insertions(+), 37 deletions(-) >> This makes all the CRTC properties disappear... > Strange, we should still register them, that's really surprising. > >> This doesn't depend on anything in drm-next, does it? I'm currently on >> v4.13-rc3. I'll look a bit more on what's going on later today. > Not that I know of. Later patches will, but this one should be stand-alone. > -Daniel The properties should not disappear, does kms_properties pass? ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.
On Sat, Aug 05, 2017 at 12:59:07PM +0200, Noralf Trønnes wrote: > (I had to switch to Daniel's Intel address to get this sent) > > Den 05.08.2017 00.19, skrev Ilia Mirkin: > > On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > > > Laurent Pinchart writes: > > > > > > > Hi Eric, > > > > > > > > (CC'ing Daniel) > > > > > > > > Thank you for the patch. > > > > > > > > On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: > > > > > This will let drivers reduce the error cleanup they need, in > > > > > particular the "is_panel_bridge" flag. > > > > > > > > > > v2: Slight cleanup of remove function by Andrzej > > > > I just want to point out that, in the context of Daniel's work on > > > > hot-unplug, > > > > 90% of the devm_* allocations are wrong and will get in the way. All > > > > DRM core > > > > objects that are accessible one way or another from userspace will need > > > > to be > > > > properly reference-counted and freed only when the last reference > > > > disappears, > > > > which could be well after the corresponding device is removed. I > > > > believe this > > > > could be one such objects :-/ > > > Sure, if you're hotplugging, your life is pain. For non-hotpluggable > > > devices, like our SOC platform devices (current panel-bridge consumers), > > > this still seems like an excellent simplification of memory management. > > At that point you may as well make your module non-unloadable, and > > return failure when trying to remove a device from management by the > > driver (whatever the opposite of "probe" is, I forget). Hotplugging > > doesn't only happen when physically removing, it can happen for all > > kinds of reasons... and userspace may still hold references in some of > > those cases. > > If drm_open() gets a ref on dev->dev and puts it in drm_release(), > won't that delay devm_* cleanup until userspace is done? No. drm_device is the thing that is refcounted for userspace references like open FD (we're not perfect about it, e.g. sysfs and dma-buf/fence don't). devm_ otoh is tied to the lifetime of the underlying device, and that one can get outlived by drm_device. Or at least afaiui, devm_ stuff is nuked on unplug, and not when the final sw reference of the struct device disappears. Not sure tough, it's complicated. -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] drm: Wake up next in drm_read() chain if we are forced to putback the event
On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote: > After an event is sent, we try to copy it into the user buffer of the > first waiter in drm_read() and if the user buffer doesn't have enough > room we put it back onto the list. However, we didn't wake up any > subsequent waiter, so that event may sit on the list until either a new > vblank event is sent or a new waiter appears. Rare, but in the worst > case may lead to a stuck process. > > Signed-off-by: Chris Wilson > Cc: Daniel Vetter New subtestcase in igt@drm_read? -Daniel > --- > drivers/gpu/drm/drm_file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > index 59b75a974357..7e6db9f7a058 100644 > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -524,6 +524,7 @@ ssize_t drm_read(struct file *filp, char __user *buffer, > file_priv->event_space -= length; > list_add(&e->link, &file_priv->event_list); > spin_unlock_irq(&dev->event_lock); > + wake_up_interruptible(&file_priv->event_wait); > break; > } > > -- > 2.13.3 > -- 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] drm/imx: ipuv3-plane: fix YUV framebuffer scanout on the base plane
Historically, only RGB framebuffers could be assigned to the primary
plane. This changed with universal plane support. Since no colorspace
conversion was set up for the IPUv3 full plane, assigning YUV frame
buffers to the primary plane caused incorrect output.
Fix this by enabling color space conversion also for the primary plane.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6276bb834b4fe..d3845989a29df 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -545,15 +545,13 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
return;
}
+ ics = ipu_drm_fourcc_to_colorspace(fb->format->format);
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
- ipu_dp_setup_channel(ipu_plane->dp,
- IPUV3_COLORSPACE_RGB,
- IPUV3_COLORSPACE_RGB);
+ ipu_dp_setup_channel(ipu_plane->dp, ics, IPUV3_COLORSPACE_RGB);
ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
break;
case IPU_DP_FLOW_SYNC_FG:
- ics = ipu_drm_fourcc_to_colorspace(state->fb->format->format);
ipu_dp_setup_channel(ipu_plane->dp, ics,
IPUV3_COLORSPACE_UNKNOWN);
/* Enable local alpha on partial plane */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/fb-helper: pass physical dimensions to fbdev
On Fri, Aug 04, 2017 at 11:25:24AM -0500, David Lechner wrote:
> The fbdev subsystem has a place for physical dimensions (width and height
> in mm) that is readable by userspace. Since DRM also knows these
> dimensions, pass this information to the fbdev device.
>
> This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs()
> because fb_helper->fbdev may be NULL in drm_setup_crtcs().
You'r sob line is missing here.
-Daniel
> ---
>
> v1 changes (from RFC):
> * Use loop to get info from first connected connector instead of just the
> first connector.
>
> v2 changes:
> * Update width in height in drm_setup_crtcs() also to handle hotplug events.
>
> v3 changes:
> * Add new patch to handle post-fb allocation crcts setup.
> * Use new drm_setup_crtcs_fb() function from new patch to avoid duplication
> of code.
>
> v4 changes:
> * Drop patch "drm/fb-helper: add new drm_setup_crtcs_fb() function" since it
> has been applied already.
> * Add mutex lock.
>
> v5 changes:
> * Fix height = width mismatch.
>
> drivers/gpu/drm/drm_fb_helper.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4447a28..24787d6 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1882,8 +1882,6 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> struct drm_fb_helper *fb_helpe
> info->var.xoffset = 0;
> info->var.yoffset = 0;
> info->var.activate = FB_ACTIVATE_NOW;
> - info->var.height = -1;
> - info->var.width = -1;
>
> switch (fb->format->depth) {
> case 8:
> @@ -2435,11 +2433,26 @@ static void drm_setup_crtcs(struct drm_fb_helper
> *fb_helper,
> */
> static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
> {
> + struct fb_info *info = fb_helper->fbdev;
> int i;
>
> for (i = 0; i < fb_helper->crtc_count; i++)
> if (fb_helper->crtc_info[i].mode_set.num_connectors)
> fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
> +
> + mutex_lock(&fb_helper->dev->mode_config.mutex);
> + drm_fb_helper_for_each_connector(fb_helper, i) {
> + struct drm_connector *connector =
> + fb_helper->connector_info[i]->connector;
> +
> + /* use first connected connector for the physical dimensions */
> + if (connector->status == connector_status_connected) {
> + info->var.width = connector->display_info.width_mm;
> + info->var.height = connector->display_info.height_mm;
> + break;
> + }
> + }
> + mutex_unlock(&fb_helper->dev->mode_config.mutex);
> }
>
> /* Note: Drops fb_helper->lock before returning. */
> --
> 2.7.4
>
> ___
> 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
Re: [PATCH v06 32/36] uapi drm/armada_drm.h: use __u32 and __u64 instead of uint32_t and uint64_t
On Sun, Aug 06, 2017 at 06:44:23PM +0200, Mikko Rapeli wrote:
> These are defined in linux/types.h or drm/drm.h. Fixes
> user space compilation errors like:
>
> drm/armada_drm.h:26:2: error: unknown type name ‘uint32_t’
> uint32_t handle;
> ^~~~
>
> Signed-off-by: Mikko Rapeli
> Cc: Emil Velikov
> Cc: Gabriel Laskar
> Cc: Russell King
> Cc: Rob Clark
Applied to drm-misc, thanks.
-Daniel
> ---
> include/uapi/drm/armada_drm.h | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/uapi/drm/armada_drm.h b/include/uapi/drm/armada_drm.h
> index 72e326f9c7de..0cb932416cfe 100644
> --- a/include/uapi/drm/armada_drm.h
> +++ b/include/uapi/drm/armada_drm.h
> @@ -23,27 +23,27 @@ extern "C" {
> DRM_##dir(DRM_COMMAND_BASE + DRM_ARMADA_##name, struct drm_armada_##str)
>
> struct drm_armada_gem_create {
> - uint32_t handle;
> - uint32_t size;
> + __u32 handle;
> + __u32 size;
> };
> #define DRM_IOCTL_ARMADA_GEM_CREATE \
> ARMADA_IOCTL(IOWR, GEM_CREATE, gem_create)
>
> struct drm_armada_gem_mmap {
> - uint32_t handle;
> - uint32_t pad;
> - uint64_t offset;
> - uint64_t size;
> - uint64_t addr;
> + __u32 handle;
> + __u32 pad;
> + __u64 offset;
> + __u64 size;
> + __u64 addr;
> };
> #define DRM_IOCTL_ARMADA_GEM_MMAP \
> ARMADA_IOCTL(IOWR, GEM_MMAP, gem_mmap)
>
> struct drm_armada_gem_pwrite {
> - uint64_t ptr;
> - uint32_t handle;
> - uint32_t offset;
> - uint32_t size;
> + __u64 ptr;
> + __u32 handle;
> + __u32 offset;
> + __u32 size;
> };
> #define DRM_IOCTL_ARMADA_GEM_PWRITE \
> ARMADA_IOCTL(IOW, GEM_PWRITE, gem_pwrite)
> --
> 2.13.3
>
> ___
> 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
Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack
Op 04-08-17 om 12:02 schreef Daniel Vetter: > On Fri, Aug 4, 2017 at 11:57 AM, Tomi Valkeinen wrote: >>> Here you go, compile tested version. :) >>> 8< >>> I want/need to rework the core property handling, and this hack is >>> getting in the way. But since it's a non-standard propety only used by >>> legacy userspace we know that this will only every be called from >>> ioctl code. And never on some other free-standing state struct, where >>> this old hack wouldn't work either. >>> >>> v2: don't forget zorder and get_property! >>> >>> v3: Shadow the legacy state to avoid locking issues in get_property >>> (Maarten). >>> >>> v4: Review from Laurent >>> - Move struct omap_crtc_state into omap_crtc.c >>> - Clean up comments. >>> - Don't forget to copy the shadowed state over on duplicate. >>> >>> v5: Don't forget to update the reset handler (Maarten). >>> v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check >>> (Maarten). >>> >>> Reviewed-by: Laurent Pinchart (v4) >>> Cc: Maarten Lankhorst >>> Cc: Tomi Valkeinen >> Cc: Laurent Pinchart >>> Signed-off-by: Daniel Vetter >>> Signed-off-by: Maarten Lankhorst >>> --- >>> drivers/gpu/drm/omapdrm/omap_crtc.c | 118 >>> +--- >>> 1 file changed, 81 insertions(+), 37 deletions(-) >> This makes all the CRTC properties disappear... > Strange, we should still register them, that's really surprising. > >> This doesn't depend on anything in drm-next, does it? I'm currently on >> v4.13-rc3. I'll look a bit more on what's going on later today. > Not that I know of. Later patches will, but this one should be stand-alone. > -Daniel Oh derp, I also see what's going wrong.. omap_crtc_atomic_get_property returns the value, instead of setting *val and returning 0. Next version coming up! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7] drm/omap: Rework the rotation-on-crtc hack
Op 04-08-17 om 12:02 schreef Daniel Vetter:
> On Fri, Aug 4, 2017 at 11:57 AM, Tomi Valkeinen wrote:
>>> Here you go, compile tested version. :)
>>> 8<
>>> I want/need to rework the core property handling, and this hack is
>>> getting in the way. But since it's a non-standard propety only used by
>>> legacy userspace we know that this will only every be called from
>>> ioctl code. And never on some other free-standing state struct, where
>>> this old hack wouldn't work either.
>>>
>>> v2: don't forget zorder and get_property!
>>>
>>> v3: Shadow the legacy state to avoid locking issues in get_property
>>> (Maarten).
>>>
>>> v4: Review from Laurent
>>> - Move struct omap_crtc_state into omap_crtc.c
>>> - Clean up comments.
>>> - Don't forget to copy the shadowed state over on duplicate.
>>>
>>> v5: Don't forget to update the reset handler (Maarten).
>>> v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check
>>> (Maarten).
>>>
>>> Reviewed-by: Laurent Pinchart (v4)
>>> Cc: Maarten Lankhorst
>>> Cc: Tomi Valkeinen >> Cc: Laurent Pinchart
>>> Signed-off-by: Daniel Vetter
>>> Signed-off-by: Maarten Lankhorst
>>> ---
>>> drivers/gpu/drm/omapdrm/omap_crtc.c | 118
>>> +---
>>> 1 file changed, 81 insertions(+), 37 deletions(-)
>> This makes all the CRTC properties disappear...
> Strange, we should still register them, that's really surprising.
>
>> This doesn't depend on anything in drm-next, does it? I'm currently on
>> v4.13-rc3. I'll look a bit more on what's going on later today.
> Not that I know of. Later patches will, but this one should be stand-alone.
> -Daniel
->8
I want/need to rework the core property handling, and this hack is
getting in the way. But since it's a non-standard propety only used by
legacy userspace we know that this will only every be called from
ioctl code. And never on some other free-standing state struct, where
this old hack wouldn't work either.
v2: don't forget zorder and get_property!
v3: Shadow the legacy state to avoid locking issues in get_property
(Maarten).
v4: Review from Laurent
- Move struct omap_crtc_state into omap_crtc.c
- Clean up comments.
- Don't forget to copy the shadowed state over on duplicate.
v5: Don't forget to update the reset handler (Maarten).
v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check (Maarten).
v7:
- Fix get_property to return 0 and set value in *val (Maarten).
- Update comment in set_property for changes in v6 (Maarten).
Reviewed-by: Laurent Pinchart (v4)
Cc: Maarten Lankhorst
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 124
1 file changed, 85 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 14e8a7738b06..09e05e002703 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -26,6 +26,16 @@
#include "omap_drv.h"
+#define to_omap_crtc_state(x) container_of(x, struct omap_crtc_state, base)
+
+struct omap_crtc_state {
+ /* Must be first. */
+ struct drm_crtc_state base;
+ /* Shadow values for legacy userspace support. */
+ unsigned int rotation;
+ unsigned int zpos;
+};
+
#define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
struct omap_crtc {
@@ -445,6 +455,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
static int omap_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
+ struct drm_plane_state *pri_state;
+
if (state->color_mgmt_changed && state->gamma_lut) {
uint length = state->gamma_lut->length /
sizeof(struct drm_color_lut);
@@ -453,6 +465,16 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
return -EINVAL;
}
+ pri_state = drm_atomic_get_new_plane_state(state->state, crtc->primary);
+ if (pri_state) {
+ struct omap_crtc_state *omap_crtc_state =
+ to_omap_crtc_state(state);
+
+ /* Mirror new values for zpos and rotation in omap_crtc_state */
+ omap_crtc_state->zpos = pri_state->zpos;
+ omap_crtc_state->rotation = pri_state->rotation;
+ }
+
return 0;
}
@@ -498,39 +520,32 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
spin_unlock_irq(&crtc->dev->event_lock);
}
-static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
- struct drm_property *property)
-{
- struct drm_device *dev = crtc->dev;
- struct omap_drm_private *priv = dev->dev_private;
-
- return property == priv->zorder_prop ||
- property == crtc->primary->rotation_property;
-}
-
static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.
Hi Daniel, On Monday 07 Aug 2017 11:25:07 Daniel Vetter wrote: > On Sat, Aug 05, 2017 at 12:59:07PM +0200, Noralf Trønnes wrote: > > Den 05.08.2017 00.19, skrev Ilia Mirkin: > >> On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > >>> Laurent Pinchart writes: > On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: > > This will let drivers reduce the error cleanup they need, in > > particular the "is_panel_bridge" flag. > > > > v2: Slight cleanup of remove function by Andrzej > > I just want to point out that, in the context of Daniel's work on > hot-unplug, 90% of the devm_* allocations are wrong and will get in > the way. All DRM core objects that are accessible one way or > another from userspace will need to be properly reference-counted > and freed only when the last reference disappears, which could be > well after the corresponding device is removed. I believe this > could be one such objects :-/ > >>> > >>> Sure, if you're hotplugging, your life is pain. For non-hotpluggable > >>> devices, like our SOC platform devices (current panel-bridge > >>> consumers), this still seems like an excellent simplification of > >>> memory management. > >> > >> At that point you may as well make your module non-unloadable, and > >> return failure when trying to remove a device from management by the > >> driver (whatever the opposite of "probe" is, I forget). Hotplugging > >> doesn't only happen when physically removing, it can happen for all > >> kinds of reasons... and userspace may still hold references in some of > >> those cases. > > > > If drm_open() gets a ref on dev->dev and puts it in drm_release(), > > won't that delay devm_* cleanup until userspace is done? > > No. drm_device is the thing that is refcounted for userspace references > like open FD (we're not perfect about it, e.g. sysfs and dma-buf/fence > don't). > > devm_ otoh is tied to the lifetime of the underlying device, and that one > can get outlived by drm_device. Or at least afaiui, devm_ stuff is nuked > on unplug, and not when the final sw reference of the struct device > disappears. > > Not sure tough, it's complicated. It's complicated when you have to understand the behaviour by reading the code, but the behaviour isn't that complex. devm resources are released both 1. right after the driver's .remove() operation returns 2. when the device is deleted (last reference released) It's the first one that makes devm_* allocation unsuitable for any structure that is accessible from userspace (such as in file operation handlers). -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dw-hdmi: add missing cec_notifier_put
On 08/07/2017 12:50 PM, Hans Verkuil wrote: The __dw_hdmi_remove() function was missing a call to cec_notifier_put to balance the cec_notifier_get in the probe function. Queued to drm-misc-next. Thanks, Archit Signed-off-by: Hans Verkuil --- This fix was in the v3 patch but unfortunately the v2 patch ended up being merged. So fix this in a separate patch. --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index f8171cd07e74..a24ec4ad18bd 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2496,6 +2496,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi) /* Disable all interrupts */ hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0); + if (hdmi->cec_notifier) + cec_notifier_put(hdmi->cec_notifier); + clk_disable_unprepare(hdmi->iahb_clk); clk_disable_unprepare(hdmi->isfr_clk); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 3/4] drm/bridge: dw-hdmi: add cec driver
On 08/03/2017 12:11 AM, Hans Verkuil wrote:
From: Russell King
Add a CEC driver for the dw-hdmi hardware.
Queued to drm-misc-next after fixing up some minor
Makefile/Kconfig conflicts.
Thanks,
Archit
Reviewed-by: Neil Armstrong
Signed-off-by: Russell King
[hans.verkuil: unsigned -> unsigned int]
[hans.verkuil: cec_transmit_done -> cec_transmit_attempt_done]
[hans.verkuil: add missing CEC_CAP_PASSTHROUGH]
Acked-by: Hans Verkuil
Tested-by: Hans Verkuil
Tested-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 9 +
drivers/gpu/drm/bridge/synopsys/Makefile | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 327 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 42 +++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
6 files changed, 398 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 351db000599a..d34c3dc04ba9 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -23,3 +23,12 @@ config DRM_DW_HDMI_I2S_AUDIO
help
Support the I2S Audio interface which is part of the Synopsys
Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsys
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a65b57e..6fe415903668 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,4 @@
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
new file mode 100644
index ..6c323510f128
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -0,0 +1,327 @@
+/*
+ * Designware HDMI CEC driver
+ *
+ * Copyright (C) 2015-2017 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "dw-hdmi-cec.h"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_FRAME_TYP = 3 << 1,
+ CEC_CTRL_RETRY = 0 << 1,
+ CEC_CTRL_NORMAL = 1 << 1,
+ CEC_CTRL_IMMED = 2 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM= BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST= BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
+
+ HDMI_CEC_MASK = 0x7d02,
+ HDMI_CEC_POLARITY = 0x7d03,
+ HDMI_CEC_INT= 0x7d04,
+ HDMI_CEC_ADDR_L = 0x7d05,
+ HDMI_CEC_ADDR_H = 0x7d06,
+ HDMI_CEC_TX_CNT = 0x7d07,
+ HDMI_CEC_RX_CNT = 0x7d08,
+ HDMI_CEC_TX_DATA0 = 0x7d10,
+ HDMI_CEC_RX_DATA0 = 0x7d20,
+ HDMI_CEC_LOCK = 0x7d30,
+ HDMI_CEC_WKUPCTRL = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+ struct dw_hdmi *hdmi;
+ const struct dw_hdmi_cec_ops *ops;
+ u32 addresses;
+ struct cec_adapter *adap;
+ struct cec_msg rx_msg;
+ unsigned int tx_status;
+ bool tx_done;
+ bool rx_done;
+ struct cec_notifier *notify;
+ int irq;
+};
+
+static void dw_hdmi_write(struct dw_hdmi_cec *cec, u8 val, int offset)
+{
+ cec->ops->write(cec->hdmi, val, offset);
+}
+
+static u8 dw_hdmi_read(struct dw_hdmi_cec *cec, int offset)
+{
+ return cec->ops->read(cec->hdmi, offset);
+}
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+ struct dw_hdmi_cec *cec = cec_get_drvdata(adap);
+
+ if (logical_addr == CEC_LOG_ADDR_INVALID)
+ cec->addresses = 0;
+ else
+ cec->addresses |= BIT(logical_addr) | BIT(15);
+
+ dw_hdmi_write(cec, cec->addresses & 255, HDMI_CEC_ADDR_L);
+ dw_hdmi_write(cec, cec->addresses >> 8, HDMI_CEC_ADDR_H);
+
Re: [PATCHv3 4/4] drm/bridge: dw-hdmi: remove CEC engine register definitions
On 08/03/2017 12:11 AM, Hans Verkuil wrote: From: Russell King We don't need the CEC engine register definitions, so let's remove them. Queued to drm-misc-next. Thanks, Archit Signed-off-by: Russell King Acked-by: Hans Verkuil Tested-by: Hans Verkuil Tested-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 --- 1 file changed, 45 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index 69644c83a0f8..9d90eb9c46e5 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h @@ -478,51 +478,6 @@ #define HDMI_A_PRESETUP 0x501A #define HDMI_A_SRM_BASE 0x5020 -/* CEC Engine Registers */ -#define HDMI_CEC_CTRL 0x7D00 -#define HDMI_CEC_STAT 0x7D01 -#define HDMI_CEC_MASK 0x7D02 -#define HDMI_CEC_POLARITY 0x7D03 -#define HDMI_CEC_INT0x7D04 -#define HDMI_CEC_ADDR_L 0x7D05 -#define HDMI_CEC_ADDR_H 0x7D06 -#define HDMI_CEC_TX_CNT 0x7D07 -#define HDMI_CEC_RX_CNT 0x7D08 -#define HDMI_CEC_TX_DATA0 0x7D10 -#define HDMI_CEC_TX_DATA1 0x7D11 -#define HDMI_CEC_TX_DATA2 0x7D12 -#define HDMI_CEC_TX_DATA3 0x7D13 -#define HDMI_CEC_TX_DATA4 0x7D14 -#define HDMI_CEC_TX_DATA5 0x7D15 -#define HDMI_CEC_TX_DATA6 0x7D16 -#define HDMI_CEC_TX_DATA7 0x7D17 -#define HDMI_CEC_TX_DATA8 0x7D18 -#define HDMI_CEC_TX_DATA9 0x7D19 -#define HDMI_CEC_TX_DATA10 0x7D1a -#define HDMI_CEC_TX_DATA11 0x7D1b -#define HDMI_CEC_TX_DATA12 0x7D1c -#define HDMI_CEC_TX_DATA13 0x7D1d -#define HDMI_CEC_TX_DATA14 0x7D1e -#define HDMI_CEC_TX_DATA15 0x7D1f -#define HDMI_CEC_RX_DATA0 0x7D20 -#define HDMI_CEC_RX_DATA1 0x7D21 -#define HDMI_CEC_RX_DATA2 0x7D22 -#define HDMI_CEC_RX_DATA3 0x7D23 -#define HDMI_CEC_RX_DATA4 0x7D24 -#define HDMI_CEC_RX_DATA5 0x7D25 -#define HDMI_CEC_RX_DATA6 0x7D26 -#define HDMI_CEC_RX_DATA7 0x7D27 -#define HDMI_CEC_RX_DATA8 0x7D28 -#define HDMI_CEC_RX_DATA9 0x7D29 -#define HDMI_CEC_RX_DATA10 0x7D2a -#define HDMI_CEC_RX_DATA11 0x7D2b -#define HDMI_CEC_RX_DATA12 0x7D2c -#define HDMI_CEC_RX_DATA13 0x7D2d -#define HDMI_CEC_RX_DATA14 0x7D2e -#define HDMI_CEC_RX_DATA15 0x7D2f -#define HDMI_CEC_LOCK 0x7D30 -#define HDMI_CEC_WKUPCTRL 0x7D31 - /* I2C Master Registers (E-DDC) */ #define HDMI_I2CM_SLAVE 0x7E00 #define HDMI_I2CM_ADDRESS 0x7E01 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #24 from alvarex --- In my case make my card completely useless stuck on 300mhz of memory clock and 174mhz of GPU. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #25 from alvarex --- Is there any sort of bios signature enforcement that makes powerplay go bananas when the bios is not signed?? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #26 from alvarex --- I tried amd staging kernel and it boots but it spams like crazy message about IO ERROR and IRQ NOTHREAD, and I can't do nothing just hard reboot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: fix memory leak when FB init fails
Hi Tomi, Thank you for the patch. On Friday 04 Aug 2017 12:24:10 Tomi Valkeinen wrote: > omap_framebuffer_create() fails to unref all the gem objects if creating > the FB fails, leading to a memory leak. > > Fix the loop so that it goes through all the reffed gem objects. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c > b/drivers/gpu/drm/omapdrm/omap_fb.c index ddf7a457951b..b1a762b70cbf 100644 > --- a/drivers/gpu/drm/omapdrm/omap_fb.c > +++ b/drivers/gpu/drm/omapdrm/omap_fb.c > @@ -379,7 +379,7 @@ struct drm_framebuffer *omap_framebuffer_create(struct > drm_device *dev, return fb; > > error: > - while (--i > 0) > + while (--i >= 0) How about i-- > 0 ? That way we could make i an unsigned int as it should be, given that a negative array index doesn't make sense here. > drm_gem_object_unreference_unlocked(bos[i]); > > return fb; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 Bug ID: 102068 Summary: Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! ) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: edisonalva...@arnet.com.ar Created attachment 133280 --> https://bugs.freedesktop.org/attachment.cgi?id=133280&action=edit dmesg kernel-4.12.4 Powerplay is not working tested on several kernels, kernel 4.12.4, amd staging 4.11, 4.13rc3. Whatever I do the clock won't change they are stuck in the lowest value which makes my card completely useless. I'm attaching a bios a believe is correctly signed but drm say the signature is wrong. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #1 from alvarex --- Created attachment 133281 --> https://bugs.freedesktop.org/attachment.cgi?id=133281&action=edit dmidecode kernel 4.12.4 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #2 from alvarex --- Created attachment 133282 --> https://bugs.freedesktop.org/attachment.cgi?id=133282&action=edit lspci kernel 4.12.4 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #3 from alvarex --- Created attachment 133283 --> https://bugs.freedesktop.org/attachment.cgi?id=133283&action=edit Gigabyte bios gigabyte bios RX460 Windforce 4GB OC -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #27 from alvarex --- I opened a new bug report https://bugs.freedesktop.org/show_bug.cgi?id=102068 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #4 from alvarex --- IMO I think amdgpu kernel module is not parsing the voltage values correctly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/omap: fix i886 work-around
Hi Tomi,
Thank you for the patch.
On Tuesday 13 Jun 2017 12:02:10 Tomi Valkeinen wrote:
> 7d267f068a8b4944d52e8b0ae4c8fcc1c1c5c5ba ("drm/omap: work-around for
> errata i886") changed how the PLL dividers and multipliers are
> calculated. While the new way should work fine for all the PLLs, it
> breaks omap5 PLLs. The issues seen are rather odd: seemed that the
> output clock rate is half of what we asked. It is unclear what's causing
> there issues.
Does this patch result in PLL parameters for half of the expected rate, or
does it compute the expected parameters, with the PLL producing half of the
expected rate for an unknown reason ?
> As a work-around this patch adds a "errata_i886" flag, which is set only
> for DRA7's PLLs, and the PLL setup is done according to that flag.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dss.h | 3 +++
> drivers/gpu/drm/omapdrm/dss/pll.c | 29 -
> drivers/gpu/drm/omapdrm/dss/video-pll.c | 2 ++
> 3 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
> b/drivers/gpu/drm/omapdrm/dss/dss.h index 5dd29c98143a..8ea3daa9aed9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.h
> @@ -174,6 +174,9 @@ struct dss_pll_hw {
> bool has_freqsel;
> bool has_selfreqdco;
> bool has_refsel;
> +
> + /* DRA7 errata i886: use high N & M to avoid jitter */
> + bool errata_i886;
> };
>
> struct dss_pll {
> diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c
> b/drivers/gpu/drm/omapdrm/dss/pll.c index 5e221302768b..9d9d9d42009b 100644
> --- a/drivers/gpu/drm/omapdrm/dss/pll.c
> +++ b/drivers/gpu/drm/omapdrm/dss/pll.c
> @@ -215,8 +215,8 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned
> long clkin, dss_pll_calc_func func, void *data)
> {
> const struct dss_pll_hw *hw = pll->hw;
> - int n, n_min, n_max;
> - int m, m_min, m_max;
> + int n, n_start, n_stop, n_inc;
> + int m, m_start, m_stop, m_inc;
> unsigned long fint, clkdco;
> unsigned long pll_hw_max;
> unsigned long fint_hw_min, fint_hw_max;
> @@ -226,22 +226,33 @@ bool dss_pll_calc_a(const struct dss_pll *pll,
> unsigned long clkin, fint_hw_min = hw->fint_min;
> fint_hw_max = hw->fint_max;
>
> - n_min = max(DIV_ROUND_UP(clkin, fint_hw_max), 1ul);
> - n_max = min((unsigned)(clkin / fint_hw_min), hw->n_max);
> + n_start = max(DIV_ROUND_UP(clkin, fint_hw_max), 1ul);
> + n_stop = min((unsigned)(clkin / fint_hw_min), hw->n_max);
> + n_inc = 1;
> +
> + if (hw->errata_i886) {
> + swap(n_start, n_stop);
> + n_inc = -1;
> + }
>
> pll_max = pll_max ? pll_max : ULONG_MAX;
>
> - /* Try to find high N & M to avoid jitter (DRA7 errata i886) */
> - for (n = n_max; n >= n_min; --n) {
> + for (n = n_start; n != n_stop; n += n_inc) {
> fint = clkin / n;
>
> - m_min = max(DIV_ROUND_UP(DIV_ROUND_UP(pll_min, fint), 2),
> + m_start = max(DIV_ROUND_UP(DIV_ROUND_UP(pll_min, fint), 2),
> 1ul);
> - m_max = min3((unsigned)(pll_max / fint / 2),
> + m_stop = min3((unsigned)(pll_max / fint / 2),
> (unsigned)(pll_hw_max / fint / 2),
> hw->m_max);
> + m_inc = 1;
> +
> + if (hw->errata_i886) {
> + swap(m_start, m_stop);
> + m_inc = -1;
> + }
>
> - for (m = m_max; m >= m_min; --m) {
> + for (m = m_start; m != m_stop; m += m_inc) {
> clkdco = 2 * m * fint;
>
> if (func(n, m, fint, clkdco, data))
> diff --git a/drivers/gpu/drm/omapdrm/dss/video-pll.c
> b/drivers/gpu/drm/omapdrm/dss/video-pll.c index 7429de928d4e..8201ecf826d9
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/video-pll.c
> +++ b/drivers/gpu/drm/omapdrm/dss/video-pll.c
> @@ -131,6 +131,8 @@ static const struct dss_pll_hw dss_dra7_video_pll_hw = {
> .mX_lsb[3] = 5,
>
> .has_refsel = true,
> +
> + .errata_i886 = true,
> };
>
> struct dss_pll *dss_video_pll_init(struct platform_device *pdev, int id,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #5 from alvarex --- I tested on Windows 7 and for Windows the bios is correctly signed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: fix memory leak when FB init fails
On 07/08/17 14:29, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Friday 04 Aug 2017 12:24:10 Tomi Valkeinen wrote: >> omap_framebuffer_create() fails to unref all the gem objects if creating >> the FB fails, leading to a memory leak. >> >> Fix the loop so that it goes through all the reffed gem objects. >> >> Signed-off-by: Tomi Valkeinen >> --- >> drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c >> b/drivers/gpu/drm/omapdrm/omap_fb.c index ddf7a457951b..b1a762b70cbf 100644 >> --- a/drivers/gpu/drm/omapdrm/omap_fb.c >> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c >> @@ -379,7 +379,7 @@ struct drm_framebuffer *omap_framebuffer_create(struct >> drm_device *dev, return fb; >> >> error: >> -while (--i > 0) >> +while (--i >= 0) > > How about i-- > 0 ? That way we could make i an unsigned int as it should be, > given that a negative array index doesn't make sense here. I tried that too, but I think it's a bit confusing. It's nice to see the limit of the iteration directly from the comparison, and with i--, we decrease i after the comparison. So "> 0" actually means ">= 0 inside the body of the while loop"... Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/omap: fix i886 work-around
On 07/08/17 14:47, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tuesday 13 Jun 2017 12:02:10 Tomi Valkeinen wrote:
>> 7d267f068a8b4944d52e8b0ae4c8fcc1c1c5c5ba ("drm/omap: work-around for
>> errata i886") changed how the PLL dividers and multipliers are
>> calculated. While the new way should work fine for all the PLLs, it
>> breaks omap5 PLLs. The issues seen are rather odd: seemed that the
>> output clock rate is half of what we asked. It is unclear what's causing
>> there issues.
>
> Does this patch result in PLL parameters for half of the expected rate, or
> does it compute the expected parameters, with the PLL producing half of the
> expected rate for an unknown reason ?
The PLL parameters look fine, and inside the HW limits, afaics, but the
produced clock rate seems to be about half.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102048] Radeon module takes over two seconds to initialize on a Radeon HD 8470D (Richland)
https://bugs.freedesktop.org/show_bug.cgi?id=102048 --- Comment #2 from Paul Menzel --- The majority of the time spent in pci_device_probe (2322.294 ms @ 17.587483). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #28 from alvarex --- Is there any way of disabling powerplay ?? amdgpu.powerplay=0 on grub, and options powerplay=0 on kernel loading doesn't work -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/19] drm/sti: Use .dumb_map_offset and .dumb_destroy defaults
Hi Noralf,
Thanks for the patch.
Acked-by: Vincent Abriou
On 08/06/2017 05:40 PM, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/sti/sti_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 06ef1e38..1700c54 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -175,8 +175,6 @@ static struct drm_driver sti_driver = {
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .dumb_create = drm_gem_cma_dumb_create,
> - .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
> .fops = &sti_driver_fops,
>
> .enable_vblank = sti_crtc_enable_vblank,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/fb-helper: pass physical dimensions to fbdev
On 08/04/2017 11:25 AM, David Lechner wrote: The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs() because fb_helper->fbdev may be NULL in drm_setup_crtcs(). Signed-off-by: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 --- Comment #6 from alvarex --- Ok so it seems, I'm an idiot!! I was setting incorrectly /sys/class/drm/card0/device/pp_mclk_od -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 alvarex changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102068] Stuck in the lowest possible clock powerplay error ( Can't find requested voltage id in vdd_dep_on_sclk table! )
https://bugs.freedesktop.org/show_bug.cgi?id=102068 Jan Vesely changed: What|Removed |Added Resolution|FIXED |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.
Den 07.08.2017 12.22, skrev Laurent Pinchart: Hi Daniel, On Monday 07 Aug 2017 11:25:07 Daniel Vetter wrote: On Sat, Aug 05, 2017 at 12:59:07PM +0200, Noralf Trønnes wrote: Den 05.08.2017 00.19, skrev Ilia Mirkin: On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: Laurent Pinchart writes: On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: This will let drivers reduce the error cleanup they need, in particular the "is_panel_bridge" flag. v2: Slight cleanup of remove function by Andrzej I just want to point out that, in the context of Daniel's work on hot-unplug, 90% of the devm_* allocations are wrong and will get in the way. All DRM core objects that are accessible one way or another from userspace will need to be properly reference-counted and freed only when the last reference disappears, which could be well after the corresponding device is removed. I believe this could be one such objects :-/ Sure, if you're hotplugging, your life is pain. For non-hotpluggable devices, like our SOC platform devices (current panel-bridge consumers), this still seems like an excellent simplification of memory management. At that point you may as well make your module non-unloadable, and return failure when trying to remove a device from management by the driver (whatever the opposite of "probe" is, I forget). Hotplugging doesn't only happen when physically removing, it can happen for all kinds of reasons... and userspace may still hold references in some of those cases. If drm_open() gets a ref on dev->dev and puts it in drm_release(), won't that delay devm_* cleanup until userspace is done? No. drm_device is the thing that is refcounted for userspace references like open FD (we're not perfect about it, e.g. sysfs and dma-buf/fence don't). devm_ otoh is tied to the lifetime of the underlying device, and that one can get outlived by drm_device. Or at least afaiui, devm_ stuff is nuked on unplug, and not when the final sw reference of the struct device disappears. Not sure tough, it's complicated. It's complicated when you have to understand the behaviour by reading the code, but the behaviour isn't that complex. devm resources are released both 1. right after the driver's .remove() operation returns 2. when the device is deleted (last reference released) It's the first one that makes devm_* allocation unsuitable for any structure that is accessible from userspace (such as in file operation handlers). I see, when the device is removed, the driver is released. No help holding a ref on struct device. I did a test and this is the stack trace in devm_tinydrm_release(): [ 129.433179] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 129.433213] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 129.433242] [] (dump_stack) from [] (__warn+0xe4/0x10c) [ 129.433264] [] (__warn) from [] (warn_slowpath_null+0x30/0x38) [ 129.433324] [] (warn_slowpath_null) from [] (devm_tinydrm_release+0x24/0x48 [tinydrm]) [ 129.433389] [] (devm_tinydrm_release [tinydrm]) from [] (devm_action_release+0x1c/0x20) [ 129.433414] [] (devm_action_release) from [] (release_nodes+0x188/0x21c) [ 129.433437] [] (release_nodes) from [] (devres_release_all+0x44/0x64) [ 129.433461] [] (devres_release_all) from [] (__device_release_driver+0x9c/0x118) [ 129.433480] [] (__device_release_driver) from [] (device_release_driver+0x2c/0x38) [ 129.433499] [] (device_release_driver) from [] (bus_remove_device+0xe4/0x114) [ 129.433532] [] (bus_remove_device) from [] (device_del+0x118/0x22c) [ 129.433554] [] (device_del) from [] (device_unregister+0x1c/0x30) [ 129.433592] [] (device_unregister) from [] (spi_unregister_device+0x60/0x64) [ 129.433617] [] (spi_unregister_device) from [] (of_spi_notify+0x70/0x164) [ 129.433642] [] (of_spi_notify) from [] (notifier_call_chain+0x54/0x94) [ 129.433664] [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x58/0x70) [ 129.433683] [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x28/0x30) [ 129.433721] [] (blocking_notifier_call_chain) from [] (__of_changeset_entry_notify+0x90/0xe0) [ 129.433748] [] (__of_changeset_entry_notify) from [] (__of_changeset_revert+0x70/0xcc) [ 129.433774] [] (__of_changeset_revert) from [] (of_overlay_destroy+0x10c/0x1bc) [ 129.433795] [] (of_overlay_destroy) from [] (cfs_overlay_release+0x2c/0x50) [ 129.433832] [] (cfs_overlay_release) from [] (config_item_release+0x68/0x8c) [ 129.433859] [] (config_item_release) from [] (config_item_put+0x44/0x48) [ 129.433879] [] (config_item_put) from [] (configfs_rmdir+0x190/0x220) [ 129.433902] [] (configfs_rmdir) from [] (vfs_rmdir+0x80/0x118) [ 129.433922] [] (vfs_rmdir) from [] (do_rmdir+0x144/0x1a0) [ 129.433941] [] (do_rmdir) from [] (SyS_rmdir+0x20/0x24) [ 129.433966] [] (SyS_rmdir) from [] (ret_fast_syscall+0x0/0x1c) This means that tinydrm won't work with usb devices. I need to look into moving cleanup to drm_driver->cleanup. Nora
Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.
On Mon, Aug 07, 2017 at 01:22:23PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > On Monday 07 Aug 2017 11:25:07 Daniel Vetter wrote: > > On Sat, Aug 05, 2017 at 12:59:07PM +0200, Noralf Trønnes wrote: > > > Den 05.08.2017 00.19, skrev Ilia Mirkin: > > >> On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > > >>> Laurent Pinchart writes: > > On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: > > > This will let drivers reduce the error cleanup they need, in > > > particular the "is_panel_bridge" flag. > > > > > > v2: Slight cleanup of remove function by Andrzej > > > > I just want to point out that, in the context of Daniel's work on > > hot-unplug, 90% of the devm_* allocations are wrong and will get in > > the way. All DRM core objects that are accessible one way or > > another from userspace will need to be properly reference-counted > > and freed only when the last reference disappears, which could be > > well after the corresponding device is removed. I believe this > > could be one such objects :-/ > > >>> > > >>> Sure, if you're hotplugging, your life is pain. For non-hotpluggable > > >>> devices, like our SOC platform devices (current panel-bridge > > >>> consumers), this still seems like an excellent simplification of > > >>> memory management. > > >> > > >> At that point you may as well make your module non-unloadable, and > > >> return failure when trying to remove a device from management by the > > >> driver (whatever the opposite of "probe" is, I forget). Hotplugging > > >> doesn't only happen when physically removing, it can happen for all > > >> kinds of reasons... and userspace may still hold references in some of > > >> those cases. > > > > > > If drm_open() gets a ref on dev->dev and puts it in drm_release(), > > > won't that delay devm_* cleanup until userspace is done? > > > > No. drm_device is the thing that is refcounted for userspace references > > like open FD (we're not perfect about it, e.g. sysfs and dma-buf/fence > > don't). > > > > devm_ otoh is tied to the lifetime of the underlying device, and that one > > can get outlived by drm_device. Or at least afaiui, devm_ stuff is nuked > > on unplug, and not when the final sw reference of the struct device > > disappears. > > > > Not sure tough, it's complicated. > > It's complicated when you have to understand the behaviour by reading the > code, but the behaviour isn't that complex. devm resources are released both > > 1. right after the driver's .remove() operation returns > 2. when the device is deleted (last reference released) Right, I had vague memories when reading the code ... But iirc there's also some way to delay cleanup until it's deleted, maybe we could exploit that (and wrap it up into a drm_devm_add wrapper)? Plan B, but that is a lot more ugly, would be to create a fake struct device that we never bind (hence remove can't be called) and use to track the lifetime of drm_device stuff. Would avoid re-inventing all the devm_ functions, but would also result in a dummy device in sysfs. Why is this stuff tied to struct device and not struct kobject anyway. Or at least something we could embed in random cool place (like drm_device). Greg, any ideas how we could simplify management of stuff that's created at driver load, but its lifetime tied to something which isn't directly a struct device? > It's the first one that makes devm_* allocation unsuitable for any structure > that is accessible from userspace (such as in file operation handlers). Yeah, if we could release at 2. it would be perfect I think ... -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 v06 36/36] uapi linux/kfd_ioctl.h: use __u32 and __u64 instead of uint32_t and uint64_t
On Sun, Aug 6, 2017 at 6:44 PM, Mikko Rapeli wrote: > Include instead of which on Linux includes > and on non-Linux platforms defines __u32 etc types. > > Fixes user space compilation errors like: > > linux/kfd_ioctl.h:33:2: error: unknown type name ‘uint32_t’ > uint32_t major_version; /* from KFD */ > ^~~~ > > Signed-off-by: Mikko Rapeli > Cc: Yair Shachar > Cc: Oded Gabbay > Cc: Andrew Lewycky Looks good to me, Acked-by: Arnd Bergmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/fb-helper: pass physical dimensions to fbdev
On Mon, Aug 07, 2017 at 08:40:35AM -0500, David Lechner wrote: > On 08/04/2017 11:25 AM, David Lechner wrote: > > The fbdev subsystem has a place for physical dimensions (width and height > > in mm) that is readable by userspace. Since DRM also knows these > > dimensions, pass this information to the fbdev device. > > > > This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs() > > because fb_helper->fbdev may be NULL in drm_setup_crtcs(). > > Signed-off-by: David Lechner Thanks, applied. -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 v2 11/19] drm/i915: Use the drm_driver.dumb_destroy default
On Sun, Aug 06, 2017 at 05:41:00PM +0200, Noralf Trønnes wrote:
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
We haven't pulled drm-misc into drm-intel yet, so easier to merge to
drm-misc. Can you pls push it there?
Thanks for doing this.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d310d82..4c96a72 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2755,7 +2755,6 @@ static struct drm_driver driver = {
>
> .dumb_create = i915_gem_dumb_create,
> .dumb_map_offset = i915_gem_mmap_gtt,
> - .dumb_destroy = drm_gem_dumb_destroy,
> .ioctls = i915_ioctls,
> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> .fops = &i915_driver_fops,
> --
> 2.7.4
>
> ___
> 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
Re: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video IP
Hi Jeffrey,
On Fri, 2017-08-04 at 11:49 -0700, Jeffrey Mouroux wrote:
> The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
> support video memory formats that are not represented in the
> current DRM fourcc library. This patch adds those missing
> fourcc codes.
>
> Signed-off-by: Jeffrey Mouroux
> ---
> include/uapi/drm/drm_fourcc.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ef20abb..3e80130 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -112,6 +112,14 @@
> #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_AVUY fourcc_code('A', 'V', 'U', 'Y') /*
> [31:0] A:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y little endian */
> +#define DRM_FORMAT_XVUY fourcc_code('X', 'V', '2', '4') /* [31:0]
> x:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0') /*
> [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> +
> +/* Grey scale */
> +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /* 8
> Greyscale */
That would be useful for me as well.
> +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /* 10
> Greyscale */
It is not clear to me from the description, how this should be laid out
in memory. Is it padded to 16 bits? Packed?
> /*
> * 2 plane YCbCr
> @@ -126,6 +134,7 @@
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_XV15 fourcc_code('X', 'V', '2', '0') /* 2x2
> subsampled Cb:Cr plane 2:10:10:10 */
Same here.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #29 from alvarex --- just ignore my comments I was setting /sys/class/drm/card0/device/pp_mclk_od incorrectly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/radeon: fix incorrect use of the lru_lock
From: Christian König
The BO manager has its own lock and doesn't use the lru_lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 6499832..78be75a 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -1030,19 +1030,17 @@ int radeon_mmap(struct file *filp, struct
vm_area_struct *vma)
static int radeon_mm_dump_table(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
- unsigned ttm_pl = *(int *)node->info_ent->data;
+ unsigned ttm_pl = *(int*)node->info_ent->data;
struct drm_device *dev = node->minor->dev;
struct radeon_device *rdev = dev->dev_private;
- struct drm_mm *mm = (struct drm_mm *)rdev->mman.bdev.man[ttm_pl].priv;
- struct ttm_bo_global *glob = rdev->mman.bdev.glob;
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[ttm_pl];
struct drm_printer p = drm_seq_file_printer(m);
- spin_lock(&glob->lru_lock);
- drm_mm_print(mm, &p);
- spin_unlock(&glob->lru_lock);
+ man->func->debug(man, &p);
return 0;
}
+
static int ttm_pl_vram = TTM_PL_VRAM;
static int ttm_pl_tt = TTM_PL_TT;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/ttm: make ttm_mem_type_manager_func debug more usfull
From: Christian König
Provide the drm printer directly instead of just the callback.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 7 +++
drivers/gpu/drm/nouveau/nouveau_ttm.c | 6 --
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 5 ++---
drivers/gpu/drm/virtio/virtgpu_ttm.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 ++--
include/drm/ttm/ttm_bo_driver.h | 5 +++--
8 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 5e6b90c..26818b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -253,18 +253,17 @@ static void amdgpu_gtt_mgr_del(struct
ttm_mem_type_manager *man,
* amdgpu_gtt_mgr_debug - dump VRAM table
*
* @man: TTM memory type manager
- * @prefix: text prefix
+ * @printer: DRM printer to use
*
* Dump the table content using printk.
*/
static void amdgpu_gtt_mgr_debug(struct ttm_mem_type_manager *man,
- const char *prefix)
+struct drm_printer *printer)
{
struct amdgpu_gtt_mgr *mgr = man->priv;
- struct drm_printer p = drm_debug_printer(prefix);
spin_lock(&mgr->lock);
- drm_mm_print(&mgr->mm, &p);
+ drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index a2c59a0..3f86b47 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -204,18 +204,17 @@ static void amdgpu_vram_mgr_del(struct
ttm_mem_type_manager *man,
* amdgpu_vram_mgr_debug - dump VRAM table
*
* @man: TTM memory type manager
- * @prefix: text prefix
+ * @printer: DRM printer to use
*
* Dump the table content using printk.
*/
static void amdgpu_vram_mgr_debug(struct ttm_mem_type_manager *man,
- const char *prefix)
+ struct drm_printer *printer)
{
struct amdgpu_vram_mgr *mgr = man->priv;
- struct drm_printer p = drm_debug_printer(prefix);
spin_lock(&mgr->lock);
- drm_mm_print(&mgr->mm, &p);
+ drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 13e5cc5..9142068 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -179,7 +179,8 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
}
static void
-nouveau_gart_manager_debug(struct ttm_mem_type_manager *man, const char
*prefix)
+nouveau_gart_manager_debug(struct ttm_mem_type_manager *man,
+ struct drm_printer *printer)
{
}
@@ -252,7 +253,8 @@ nv04_gart_manager_new(struct ttm_mem_type_manager *man,
}
static void
-nv04_gart_manager_debug(struct ttm_mem_type_manager *man, const char *prefix)
+nv04_gart_manager_debug(struct ttm_mem_type_manager *man,
+ struct drm_printer *printer)
{
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d3463eb..58e7fce 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -70,6 +70,7 @@ static inline int ttm_mem_type_from_place(const struct
ttm_place *place,
static void ttm_mem_type_debug(struct ttm_bo_device *bdev, int mem_type)
{
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
+ struct drm_printer p = drm_debug_printer(TTM_PFX);
pr_err("has_type: %d\n", man->has_type);
pr_err("use_type: %d\n", man->use_type);
@@ -79,7 +80,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev,
int mem_type)
pr_err("available_caching: 0x%08X\n", man->available_caching);
pr_err("default_caching: 0x%08X\n", man->default_caching);
if (mem_type != TTM_PL_SYSTEM)
- (*man->func->debug)(man, TTM_PFX);
+ (*man->func->debug)(man, &p);
}
static void ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 90a6c0b..a7c232d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -136,13 +136,12 @@ static int ttm_bo_man_takedown(struct
ttm_mem_type_manager *man)
}
static void ttm_bo_man_debug(struct ttm_mem_type_manager *man,
-const char *prefix)
+struct drm_printer *printer)
{
struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
- struct drm_printer p = drm_debug_printer(prefix);
spin
[PATCH 2/7] drm/qxl: fix incorrect use of the lru_lock
From: Christian König
The BO manager has its own lock and doesn't use the lru_lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 0fdedee..07dc08d 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -454,15 +454,10 @@ void qxl_ttm_fini(struct qxl_device *qdev)
static int qxl_mm_dump_table(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_mm *mm = (struct drm_mm *)node->info_ent->data;
- struct drm_device *dev = node->minor->dev;
- struct qxl_device *rdev = dev->dev_private;
- struct ttm_bo_global *glob = rdev->mman.bdev.glob;
+ struct ttm_mem_type_manager *man = node->info_ent->data;
struct drm_printer p = drm_seq_file_printer(m);
- spin_lock(&glob->lru_lock);
- drm_mm_print(mm, &p);
- spin_unlock(&glob->lru_lock);
+ man->func->debug(man, &p);
return 0;
}
#endif
@@ -483,9 +478,9 @@ int qxl_ttm_debugfs_init(struct qxl_device *qdev)
qxl_mem_types_list[i].show = &qxl_mm_dump_table;
qxl_mem_types_list[i].driver_features = 0;
if (i == 0)
- qxl_mem_types_list[i].data =
qdev->mman.bdev.man[TTM_PL_VRAM].priv;
+ qxl_mem_types_list[i].data =
&qdev->mman.bdev.man[TTM_PL_VRAM];
else
- qxl_mem_types_list[i].data =
qdev->mman.bdev.man[TTM_PL_PRIV].priv;
+ qxl_mem_types_list[i].data =
&qdev->mman.bdev.man[TTM_PL_PRIV];
}
return qxl_debugfs_add_files(qdev, qxl_mem_types_list, i);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/amdgpu: fix incorrect use of the lru_lock
From: Christian König
The BO manager has its own lock and doesn't use the lru_lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f6bc4ae..d26ec55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1605,13 +1605,10 @@ static int amdgpu_mm_dump_table(struct seq_file *m,
void *data)
unsigned ttm_pl = *(int *)node->info_ent->data;
struct drm_device *dev = node->minor->dev;
struct amdgpu_device *adev = dev->dev_private;
- struct drm_mm *mm = (struct drm_mm *)adev->mman.bdev.man[ttm_pl].priv;
- struct ttm_bo_global *glob = adev->mman.bdev.glob;
+ struct ttm_mem_type_manager *man = &adev->mman.bdev.man[ttm_pl];
struct drm_printer p = drm_seq_file_printer(m);
- spin_lock(&glob->lru_lock);
- drm_mm_print(mm, &p);
- spin_unlock(&glob->lru_lock);
+ man->func->debug(man, &p);
switch (ttm_pl) {
case TTM_PL_VRAM:
seq_printf(m, "man size:%llu pages, ram usage:%lluMB, vis
usage:%lluMB\n",
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/amdgpu: move debug print into the MM managers
From: Christian König
Instead of the separate switch/case in the calling function.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 ++
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 26818b0..97c63ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -153,15 +153,6 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
return r;
}
-void amdgpu_gtt_mgr_print(struct seq_file *m, struct ttm_mem_type_manager *man)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
- struct amdgpu_gtt_mgr *mgr = man->priv;
-
- seq_printf(m, "man size:%llu pages, gtt available:%llu pages,
usage:%lluMB\n",
- man->size, mgr->available,
(u64)atomic64_read(&adev->gtt_usage) >> 20);
-
-}
/**
* amdgpu_gtt_mgr_new - allocate a new node
*
@@ -260,11 +251,16 @@ static void amdgpu_gtt_mgr_del(struct
ttm_mem_type_manager *man,
static void amdgpu_gtt_mgr_debug(struct ttm_mem_type_manager *man,
struct drm_printer *printer)
{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
struct amdgpu_gtt_mgr *mgr = man->priv;
spin_lock(&mgr->lock);
drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
+
+ drm_printf(printer, "man size:%llu pages, gtt available:%llu pages,
usage:%lluMB\n",
+ man->size, mgr->available,
+ (u64)atomic64_read(&adev->gtt_usage) >> 20);
}
const struct ttm_mem_type_manager_func amdgpu_gtt_mgr_func = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d26ec55..076edf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1597,8 +1597,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo,
#if defined(CONFIG_DEBUG_FS)
-extern void amdgpu_gtt_mgr_print(struct seq_file *m, struct
ttm_mem_type_manager
-*man);
static int amdgpu_mm_dump_table(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -1609,17 +1607,6 @@ static int amdgpu_mm_dump_table(struct seq_file *m, void
*data)
struct drm_printer p = drm_seq_file_printer(m);
man->func->debug(man, &p);
- switch (ttm_pl) {
- case TTM_PL_VRAM:
- seq_printf(m, "man size:%llu pages, ram usage:%lluMB, vis
usage:%lluMB\n",
- adev->mman.bdev.man[ttm_pl].size,
- (u64)atomic64_read(&adev->vram_usage) >> 20,
- (u64)atomic64_read(&adev->vram_vis_usage) >> 20);
- break;
- case TTM_PL_TT:
- amdgpu_gtt_mgr_print(m, &adev->mman.bdev.man[TTM_PL_TT]);
- break;
- }
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 3f86b47..1eb8d5d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -211,11 +211,17 @@ static void amdgpu_vram_mgr_del(struct
ttm_mem_type_manager *man,
static void amdgpu_vram_mgr_debug(struct ttm_mem_type_manager *man,
struct drm_printer *printer)
{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
struct amdgpu_vram_mgr *mgr = man->priv;
spin_lock(&mgr->lock);
drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
+
+ drm_printf(printer, "man size:%llu pages, ram usage:%lluMB, vis
usage:%lluMB\n",
+ adev->mman.bdev.man[TTM_PL_VRAM].size,
+ (u64)atomic64_read(&adev->vram_usage) >> 20,
+ (u64)atomic64_read(&adev->vram_vis_usage) >> 20);
}
const struct ttm_mem_type_manager_func amdgpu_vram_mgr_func = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/amdgpu: move gtt usage tracking into the gtt manager
From: Christian König
It doesn't make much sense to count those numbers twice.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 18 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
5 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 67c5286..aff89d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1486,7 +1486,6 @@ struct amdgpu_device {
struct amdgpu_wbwb;
atomic64_t vram_usage;
atomic64_t vram_vis_usage;
- atomic64_t gtt_usage;
atomic64_t num_bytes_moved;
atomic64_t num_evictions;
atomic64_t num_vram_cpu_page_faults;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 97c63ee..0e47c20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -241,6 +241,20 @@ static void amdgpu_gtt_mgr_del(struct ttm_mem_type_manager
*man,
}
/**
+ * amdgpu_gtt_mgr_usage - return usage of GTT domain
+ *
+ * @man: TTM memory type manager
+ *
+ * Return how many bytes are used in the GTT domain
+ */
+uint64_t amdgpu_gtt_mgr_usage(struct ttm_mem_type_manager *man)
+{
+ struct amdgpu_gtt_mgr *mgr = man->priv;
+
+ return (u64)(man->size - READ_ONCE(mgr->available)) * PAGE_SIZE;
+}
+
+/**
* amdgpu_gtt_mgr_debug - dump VRAM table
*
* @man: TTM memory type manager
@@ -251,7 +265,6 @@ static void amdgpu_gtt_mgr_del(struct ttm_mem_type_manager
*man,
static void amdgpu_gtt_mgr_debug(struct ttm_mem_type_manager *man,
struct drm_printer *printer)
{
- struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
struct amdgpu_gtt_mgr *mgr = man->priv;
spin_lock(&mgr->lock);
@@ -259,8 +272,7 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_mem_type_manager *man,
spin_unlock(&mgr->lock);
drm_printf(printer, "man size:%llu pages, gtt available:%llu pages,
usage:%lluMB\n",
- man->size, mgr->available,
- (u64)atomic64_read(&adev->gtt_usage) >> 20);
+ man->size, mgr->available, amdgpu_gtt_mgr_usage(man) >> 20);
}
const struct ttm_mem_type_manager_func amdgpu_gtt_mgr_func = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a96c703..3209198 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -461,7 +461,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
ui64 = atomic64_read(&adev->vram_vis_usage);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GTT_USAGE:
- ui64 = atomic64_read(&adev->gtt_usage);
+ ui64 = amdgpu_gtt_mgr_usage(&adev->mman.bdev.man[TTM_PL_TT]);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GDS_CONFIG: {
struct drm_amdgpu_info_gds gds_info;
@@ -514,7 +514,8 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
mem.gtt.total_heap_size *= PAGE_SIZE;
mem.gtt.usable_heap_size = mem.gtt.total_heap_size
- adev->gart_pin_size;
- mem.gtt.heap_usage = atomic64_read(&adev->gtt_usage);
+ mem.gtt.heap_usage =
+ amdgpu_gtt_mgr_usage(&adev->mman.bdev.man[TTM_PL_TT]);
mem.gtt.max_allocation = mem.gtt.usable_heap_size * 3 / 4;
return copy_to_user(out, &mem,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 16f31cb..d67a997 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -62,7 +62,6 @@ static void amdgpu_update_memory_usage(struct amdgpu_device
*adev,
if (new_mem) {
switch (new_mem->mem_type) {
case TTM_PL_TT:
- atomic64_add(new_mem->size, &adev->gtt_usage);
break;
case TTM_PL_VRAM:
atomic64_add(new_mem->size, &adev->vram_usage);
@@ -75,7 +74,6 @@ static void amdgpu_update_memory_usage(struct amdgpu_device
*adev,
if (old_mem) {
switch (old_mem->mem_type) {
case TTM_PL_TT:
- atomic64_sub(old_mem->size, &adev->gtt_usage);
break;
case
[PATCH 7/7] drm/amdgpu: move vram usage tracking into the vram manager
From: Christian König
Looks like a better place for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 50 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 64 ++--
6 files changed, 71 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index aff89d7..03d6342 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1484,8 +1484,6 @@ struct amdgpu_device {
struct amdgpu_mman mman;
struct amdgpu_vram_scratch vram_scratch;
struct amdgpu_wbwb;
- atomic64_t vram_usage;
- atomic64_t vram_vis_usage;
atomic64_t num_bytes_moved;
atomic64_t num_evictions;
atomic64_t num_vram_cpu_page_faults;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index fe974f7..6741deb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -243,7 +243,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
}
total_vram = adev->mc.real_vram_size - adev->vram_pin_size;
- used_vram = atomic64_read(&adev->vram_usage);
+ used_vram = amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
spin_lock(&adev->mm_stats.lock);
@@ -289,7 +289,8 @@ static void amdgpu_cs_get_threshold_for_moves(struct
amdgpu_device *adev,
/* Do the same for visible VRAM if half of it is free */
if (adev->mc.visible_vram_size < adev->mc.real_vram_size) {
u64 total_vis_vram = adev->mc.visible_vram_size;
- u64 used_vis_vram = atomic64_read(&adev->vram_vis_usage);
+ u64 used_vis_vram =
+
amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
if (used_vis_vram < total_vis_vram) {
u64 free_vis_vram = total_vis_vram - used_vis_vram;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 3209198..4a6407d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -455,10 +455,10 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VRAM_USAGE:
- ui64 = atomic64_read(&adev->vram_usage);
+ ui64 = amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VIS_VRAM_USAGE:
- ui64 = atomic64_read(&adev->vram_vis_usage);
+ ui64 =
amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_GTT_USAGE:
ui64 = amdgpu_gtt_mgr_usage(&adev->mman.bdev.man[TTM_PL_TT]);
@@ -497,7 +497,8 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
mem.vram.total_heap_size = adev->mc.real_vram_size;
mem.vram.usable_heap_size =
adev->mc.real_vram_size - adev->vram_pin_size;
- mem.vram.heap_usage = atomic64_read(&adev->vram_usage);
+ mem.vram.heap_usage =
+
amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
mem.cpu_accessible_vram.total_heap_size =
@@ -506,7 +507,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
adev->mc.visible_vram_size -
(adev->vram_pin_size - adev->invisible_pin_size);
mem.cpu_accessible_vram.heap_usage =
- atomic64_read(&adev->vram_vis_usage);
+
amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
mem.cpu_accessible_vram.max_allocation =
mem.cpu_accessible_vram.usable_heap_size * 3 / 4;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d67a997..01a125b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -37,53 +37,6 @@
#includ
Re: [PATCH v3 4/6] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
On 08/05/2017 01:19 PM, Noralf Trønnes wrote:
Den 04.08.2017 00.33, skrev David Lechner:
+
+buf = kmalloc(len, GFP_KERNEL);
+if (!buf)
+return;
+
+tinydrm_xrgb_to_gray8(buf, vaddr, fb, clip);
+src = buf;
+
+for (y = clip->y1; y < clip->y2; y++) {
+for (x = clip->x1; x < clip->x2; x += 3) {
+val = *src++ & 0xc0;
+if (val & 0xc0)
+val |= 0x20;
+val |= (*src++ & 0xc0) >> 3;
+if (val & 0x18)
+val |= 0x04;
+val |= *src++ >> 6;
+*dst++ = ~val;
I don't understand how this pixel packing matches the one described in
the datasheet. Why do you flip the bits at the end?
I a trying to be too clever. :-)
Here is the comment I will add to the next revision:
/*
* The ST7586 controller has an unusual pixel format where 2bpp
grayscale is
* packed 3 pixels per byte with the first two pixels using 3 bits and
the 3rd
* pixel using only 2 bits.
*
* | D7 | D6 | D5 || D1 | D0 || 2bpp |
* | (D4) | (D3) | (D2) || | || GRAY |
* +--+--+--++--+--++--+
* | 1 | 1 | 1 || 1 | 1 || 0 0 | black
* | 1 | 0 | 0 || 1 | 0 || 0 1 | dark gray
* | 0 | 1 | 0 || 0 | 1 || 1 0 | light gray
* | 0 | 0 | 0 || 0 | 0 || 1 1 | white
*/
As you can see, in the controller DRAM 1's are black and 0's are white,
but in the kernel, it is the opposite. Also, if you look at the truth
table, you can see that the extra 3rd bit has the pattern if D7 == 0 or
D6 == 0 then D5 is zero.
I suppose it could be better to do this with a lookup table:
static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };
...
for (y = clip->y1; y < clip->y2; y++) {
for (x = clip->x1; x < clip->x2; x += 3) {
val = st7586_lookup[*src++ >> 6] << 5;
val |= st7586_lookup[*src++ >> 6] << 2;
val |= st7586_lookup[*src++ >> 6] >> 1;
*dst++ = val;
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] dt-bindings: add binding for Sitronix ST7586 display panels
This adds a new binding for Sitronix ST7586 display panels.
Using lego as the vendor prefix in the compatible string because the display
panel I am working with is an integral part of the LEGO MINDSTORMS EV3.
Signed-off-by: David Lechner
---
v4 changes:
* Dropped optional properties and only use pins actually used on LEGO EV3.
* Rename dc to a0 since that is what is on the datasheet/LEGO schematic.
.../bindings/display/sitronix,st7586.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sitronix,st7586.txt
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.txt
b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
new file mode 100644
index 000..1d0dad1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
@@ -0,0 +1,22 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible: "lego,ev3-lcd".
+- a0-gpios:The A0 signal (since this binding is for serial mode, this is
+the pin labeled D1 on the controller, not the pin labeled A0)
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/tinydrm: Generalize tinydrm_xrgb8888_to_gray8()
This adds parameters for vaddr and clip to tinydrm_xrgb_to_gray8() to
make it more generic.
dma_buf_{begin,end}_cpu_access() are moved out to the repaper driver.
Return type is change to void to simplify error handling by callers.
Signed-off-by: David Lechner
---
v4 changes:
* Change return type to void.
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 42 +-
drivers/gpu/drm/tinydrm/repaper.c | 28 +++--
include/drm/tinydrm/tinydrm-helpers.h | 3 +-
3 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index 75808bb..bd6cce0 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -185,7 +185,9 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
/**
* tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
* @dst: 8-bit grayscale destination buffer
+ * @vaddr: XRGB source buffer
* @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
*
* Drm doesn't have native monochrome or grayscale support.
* Such drivers can announce the commonly supported XR24 format to userspace
@@ -195,41 +197,31 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
* where 1 means foreground color and 0 background color.
*
* ITU BT.601 is used for the RGB -> luma (brightness) conversion.
- *
- * Returns:
- * Zero on success, negative error code on failure.
*/
-int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb)
+void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer
*fb,
+ struct drm_clip_rect *clip)
{
- struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
- struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
- unsigned int x, y, pitch = fb->pitches[0];
- int ret = 0;
+ unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
+ unsigned int x, y;
void *buf;
u32 *src;
if (WARN_ON(fb->format->format != DRM_FORMAT_XRGB))
- return -EINVAL;
+ return;
/*
* The cma memory is write-combined so reads are uncached.
* Speed up by fetching one line at a time.
*/
- buf = kmalloc(pitch, GFP_KERNEL);
+ buf = kmalloc(len, GFP_KERNEL);
if (!buf)
- return -ENOMEM;
-
- if (import_attach) {
- ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
- DMA_FROM_DEVICE);
- if (ret)
- goto err_free;
- }
+ return;
- for (y = 0; y < fb->height; y++) {
- src = cma_obj->vaddr + (y * pitch);
- memcpy(buf, src, pitch);
+ for (y = clip->y1; y < clip->y2; y++) {
+ src = vaddr + (y * fb->pitches[0]);
+ src += clip->x1;
+ memcpy(buf, src, len);
src = buf;
- for (x = 0; x < fb->width; x++) {
+ for (x = clip->x1; x < clip->x2; x++) {
u8 r = (*src & 0x00ff) >> 16;
u8 g = (*src & 0xff00) >> 8;
u8 b = *src & 0x00ff;
@@ -240,13 +232,7 @@ int tinydrm_xrgb_to_gray8(u8 *dst, struct
drm_framebuffer *fb)
}
}
- if (import_attach)
- ret = dma_buf_end_cpu_access(import_attach->dmabuf,
-DMA_FROM_DEVICE);
-err_free:
kfree(buf);
-
- return ret;
}
EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
diff --git a/drivers/gpu/drm/tinydrm/repaper.c
b/drivers/gpu/drm/tinydrm/repaper.c
index 3343d3f..30dc97b 100644
--- a/drivers/gpu/drm/tinydrm/repaper.c
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -18,6 +18,7 @@
*/
#include
+#include
#include
#include
#include
@@ -525,11 +526,20 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
struct drm_clip_rect *clips,
unsigned int num_clips)
{
+ struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+ struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
struct tinydrm_device *tdev = fb->dev->dev_private;
struct repaper_epd *epd = epd_from_tinydrm(tdev);
+ struct drm_clip_rect clip;
u8 *buf = NULL;
int ret = 0;
+ /* repaper can't do partial updates */
+ clip.x1 = 0;
+ clip.x2 = fb->width;
+ clip.y1 = 0;
+ clip.y2 = fb->height;
+
mutex_lock(&tdev->dirty_lock);
if (!epd->enabled)
@@ -550,9 +560,21 @@ static int repaper_fb_dirty(struct drm_framebuffer *fb,
goto out_unlock;
}
- ret = tinydrm_xrgb_to_gray8(buf, fb);
- if (ret)
- goto out_unlock;
+ if (
[PATCH v4 0/5] Support for LEGO MINDSTORMS EV3 LCD display
The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3 working. v2 changes: * Wrote a new driver for ST7586 instead of combining it with existing drivers * Don't touch MIPI DBI code (other than the patch suggested by Noralf) * New defconfig patch v3 changes: * New patch to generalize tinydrm_xrgb_to_gray8() so that it can be reused. * Device tree bindings in separate patch. * Fixed incorrect device tree binding pin descriptions. * Added MAINTAINERS entry for drivers/gpu/drm/tinydrm/st7586.c. * Removed "mipi_dbi_" from function names in st7586.c. * Moved init and fini to pipe_enable and pipe_disable ops. * Dropped RGB565 format. * Made adjustments for the fact the controller cannot be read via SPI. * Dropped st7586.h - values moved into st7586.c. v4 changes: * Dropped patch "drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()" since it has been applied. * correct order for MAINTAINERS entry * Drop code/dt bindings not used by LEGO EV3 (regulator, backlight, etc) * Make gpios required * Use lookup table for pixel packing algorithm * Don't modify clip when used as function parameter * Rename dc to a0 since that is what is on the datasheet/LEGO schematic. David Lechner (5): drm/tinydrm: Generalize tinydrm_xrgb_to_gray8() dt-bindings: add binding for Sitronix ST7586 display panels drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD ARM: dts: da850-lego-ev3: Add node for LCD display ARM: davinci_all_defconfig: enable tinydrm and ST7586 .../bindings/display/sitronix,st7586.txt | 22 ++ MAINTAINERS| 6 + arch/arm/boot/dts/da850-lego-ev3.dts | 24 ++ arch/arm/configs/davinci_all_defconfig | 2 + drivers/gpu/drm/tinydrm/Kconfig| 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 42 +- drivers/gpu/drm/tinydrm/repaper.c | 28 +- drivers/gpu/drm/tinydrm/st7586.c | 428 + include/drm/tinydrm/tinydrm-helpers.h | 3 +- 10 files changed, 534 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/sitronix,st7586.txt create mode 100644 drivers/gpu/drm/tinydrm/st7586.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the LEGO MINDSTORMS
EV3 LCD display.
Signed-off-by: David Lechner
---
v4 changes:
* correct order for MAINTAINERS entry
* Drop code not used by LEGO EV3 (regulator, backlight, suspend/resume)
* Make gpios required
* Use lookup table for pixel packing algorithm
* Don't modify clip when used as function parameter
* Use roundup/rounddown macros
MAINTAINERS | 6 +
drivers/gpu/drm/tinydrm/Kconfig | 10 +
drivers/gpu/drm/tinydrm/Makefile | 1 +
drivers/gpu/drm/tinydrm/st7586.c | 428 +++
4 files changed, 445 insertions(+)
create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a1e772e..19ca3e6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4380,6 +4380,12 @@ S: Orphan / Obsolete
F: drivers/gpu/drm/sis/
F: include/uapi/drm/sis_drm.h
+DRM DRIVER FOR SITRONIX ST7586 PANELS
+M: David Lechner
+S: Maintained
+F: drivers/gpu/drm/tinydrm/st7586.c
+F: Documentation/devicetree/bindings/display/st7586.txt
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
2.71" TFT EPD Panel (E2271CS021)
If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+ tristate "DRM support for Sitronix ST7586 display panels"
+ depends on DRM_TINYDRM && SPI
+ select TINYDRM_MIPI_DBI
+ help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
# Displays
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..1b39d3f
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,428 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/* controller-specific commands */
+#define ST7586_DISP_MODE_GRAY 0x38
+#define ST7586_DISP_MODE_MONO 0x39
+#define ST7586_ENABLE_DDRAM0x3a
+#define ST7586_SET_DISP_DUTY 0xb0
+#define ST7586_SET_PART_DISP 0xb4
+#define ST7586_SET_NLINE_INV 0xb5
+#define ST7586_SET_VOP 0xc0
+#define ST7586_SET_BIAS_SYSTEM 0xc3
+#define ST7586_SET_BOOST_LEVEL 0xc4
+#define ST7586_SET_VOP_OFFSET 0xc7
+#define ST7586_ENABLE_ANALOG 0xd0
+#define ST7586_AUTO_READ_CTRL 0xd7
+#define ST7586_OTP_RW_CTRL 0xe0
+#define ST7586_OTP_CTRL_OUT0xe1
+#define ST7586_OTP_READ0xe3
+
+#define ST7586_DISP_CTRL_MXBIT(6)
+#define ST7586_DISP_CTRL_MYBIT(7)
+
+/*
+ * The ST7586 controller has an unusual pixel format where 2bpp grayscale is
+ * packed 3 pixels per byte with the first two pixels using 3 bits and the 3rd
+ * pixel using only 2 bits.
+ *
+ * | D7 | D6 | D5 || | || 2bpp |
+ * | (D4) | (D3) | (D2) || D1 | D0 || GRAY |
+ * +--+--+--++--+--++--+
+ * | 1 | 1 | 1 || 1 | 1 || 0 0 | black
+ * | 1 | 0 | 0 || 1 | 0 || 0 1 | dark gray
+ * | 0 | 1 | 0 || 0 | 1 || 1 0 | light gray
+ * | 0 | 0 | 0 || 0 | 0 || 1 1 | white
+ */
+
+static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };
+
+static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
+ size_t len = (clip->x2 - clip->x1) * (clip->y2 - clip->y1);
+ unsigned int x, y;
+ u8 *src, *buf, val;
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ tinydrm_xrgb_to_gray8(buf, vaddr, fb, clip);
+ src = buf;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ for (x = clip->x1; x < clip->x2; x += 3) {
+ val = st7586_lookup[*src++ >> 6] << 5;
+
[PATCH v4 4/5] ARM: dts: da850-lego-ev3: Add node for LCD display
This adds a new node for the LEGO MINDSTORMS EV3 LCD display.
Signed-off-by: David Lechner
---
v4 changes:
* changed dc to a0
arch/arm/boot/dts/da850-lego-ev3.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..413dbd5 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+ ev3_lcd_pins: pinmux_lcd {
+ pinctrl-single,bits = <
+ /* SIMO, GP2[11], GP2[12], CLK */
+ 0x14 0x00188100 0x0000
+ /* GP5[0] */
+ 0x30 0x8000 0xf000
+ >;
+ };
};
&pinconf {
@@ -357,6 +366,21 @@
};
};
+&spi1 {
+ status = "okay";
+ pinctrl-0 = <&ev3_lcd_pins>;
+ pinctrl-names = "default";
+ cs-gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ehrpwm0 {
status = "okay";
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] ARM: davinci_all_defconfig: enable tinydrm and ST7586
This enables the tinydrm and ST7586 panel modules used by the display on LEGO MINDSTORMS EV3. Signed-off-by: David Lechner --- arch/arm/configs/davinci_all_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index 06e2e2a..27d9720 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -143,6 +143,8 @@ CONFIG_VIDEO_ADV7343=m CONFIG_DRM=m CONFIG_DRM_TILCDC=m CONFIG_DRM_DUMB_VGA_DAC=m +CONFIG_DRM_TINYDRM=m +CONFIG_TINYDRM_ST7586=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DA8XX=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On Mon, 7 Aug 2017 08:11:43 +
"Zhang, Tina" wrote:
> After going through the previous discussions, here are some summaries may be
> related to the current discussion:
> 1. How does user mode figure the device capabilities between region and
> dma-buf?
> VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case.
> Otherwise, the mdev supports dma-buf.
Why do we need to make this assumption? What happens when dma-buf is
superseded? What happens if a device supports both dma-buf and
regions? We have a flags field in vfio_device_gfx_plane_info, doesn't
it make sense to use it to identify which field, between region_index
and fd, is valid? We could even put region_index and fd into a union
with the flag bits indicating how to interpret the union, but I'm not
sure everyone was onboard with this idea. Seems like a waste of 4
bytes not to do that though.
Thinking further, is the user ever in a situation where they query the
graphics plane info and can handle either a dma-buf or a region? It
seems more likely that the user needs to know early on which is
supported and would then require that they continue to see compatible
plane information... Should the user then be able to specify whether
they want a dma-buf or a region? Perhaps these flag bits are actually
input and the return should be -errno if the driver cannot produce
something compatible.
Maybe we'd therefore define 3 flag bits: PROBE, DMABUF, REGION. In
this initial implementation, DMABUF or REGION would always be set by
the user to request that type of interface. Additionally, the QUERY
bit could be set to probe compatibility, thus if PROBE and REGION are
set, the vendor driver would return success only if it supports the
region based interface. If PROBE and DMABUF are set, the vendor driver
returns success only if the dma-buf based interface is supported. The
value of the remainder of the structure is undefined for PROBE.
Additionally setting both DMABUF and REGION is invalid. Undefined
flags bits must be validated as zero by the drivers for future use
(thus if we later define DMABUFv2, an older driver should
automatically return -errno when probed or requested).
It seems like this handles all the cases, the user can ask what's
supported and specifies the interface they want on every call. The
user therefore can also choose between region_index and fd and we can
make that a union.
> 2. For dma-buf, how to differentiate unsupported vs not initialized?
> For dma-buf, when the mdev doesn't support some arguments, -EINVAL will be
> returned. And -errno will return when meeting other failures, like -ENOMEM.
> If the mdev is not initialized, there won't be any returned err. Just zero
> all the fields in structure vfio_device_gfx_plane_info.
So we're relying on special values again :-\ For which fields is zero
not a valid value? I prefer the probe interface above unless there are
better ideas.
> 3. The id field in structure vfio_device_gfx_plane_info
> So far we haven't figured out the usage of this field for dma-buf usage. So,
> this field is changed to "region_index" and only used for region usage.
> In previous discussions, we thought this "id" field might be used for both
> dma-buf and region usages.
> So, we proposed some ways, like adding flags field to the structure. Another
> way to do it was to add this:
> enum vfio_device_gfx_type {
> VFIO_DEVICE_GFX_NONE,
> VFIO_DEVICE_GFX_DMABUF,
> VFIO_DEVICE_GFX_REGION,
> };
>
> struct vfio_device_gfx_query_caps {
> __u32 argsz;
> __u32 flags;
> enum vfio_device_gfx_type;
> };
> Obviously, we don't need to consider this again, unless we find the
> "region_index" means something for dma-buf usage.
The usefulness of this ioctl seems really limited and once again we get
into a situation where having two ioctls leaves doubt whether this is
describing the current plane state. Thanks,
Alex
> > > > > > > > include/uapi/linux/vfio.h | 28
> > > > > > > > 1 file changed, 28 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/include/uapi/linux/vfio.h
> > > > > > > > b/include/uapi/linux/vfio.h index ae46105..827a230 100644
> > > > > > > > --- a/include/uapi/linux/vfio.h
> > > > > > > > +++ b/include/uapi/linux/vfio.h
> > > > > > > > @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
> > > > > > > >
> > > > > > > > #define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE,
> > VFIO_BASE +
> > > > > > > 13)
> > > > > > > >
> > > > > > > > +/**
> > > > > > > > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE,
> > VFIO_BASE
> > > +
> > > > > 14,
> > > > > > > > +struct vfio_device_query_gfx_plane)
> > > > > > > > + *
> > > > > > > > + * Set the drm_plane_type and retrieve information about
> > > > > > > > +the gfx
> > > plane.
> > > > > > > > + *
> > > > > > > > + * Return: 0 on success, -errno on failure.
> > > > > > > > + */
> > > > > > > > +struct vfio_device_gf
[Bug 102013] GTK3 tooltips are corrupted after updating to Radeon 7.9.0
https://bugs.freedesktop.org/show_bug.cgi?id=102013 --- Comment #15 from Amr Ibrahim --- Thanks Michel. Should I open a new bug about the window resizing issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access
On 08/04/2017 01:49 AM, Noralf Trønnes wrote: Den 04.08.2017 00.41, skrev David Lechner: On 08/01/2017 03:14 PM, David Lechner wrote: If we return here and import_attach is true, then dma_buf_end_cpu_access() will not be called balance dma_buf_begin_cpu_access(). Fix by setting ret instead of returning. Signed-off-by: David Lechner --- drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c index c83eeb7..e10fa4b 100644 --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c @@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb, dev_err_once(fb->dev->dev, "Format is not supported: %s\n", drm_get_format_name(fb->format->format, &format_name)); -return -EINVAL; +ret = -EINVAL; +break; } if (import_attach) I just realized that the next line here can mask ret. if (import_attach) ret = dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE); So, we should either ignore the return value from dma_buf_end_cpu_access() always or add some logic to ignore it if ret is already an error. In some of the other patches I have been sending, we have the same situation. I those, I have opted to just ignore the return value from dma_buf_end_cpu_access(). e.g... if (import_attach) dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE); Is this a reasonable thing to do? mipi_dbi_buf_copy() can be used by other rgb565 controllers, hence the format check I think. So when that happens, it can be moved to tinydrm-helpers. Currently it's not possible to get an illegal format, since mipi-dbi only supports those two formats. Userspace can't set an illegal format, beacuse it's checked: drm_atomic_commit -> drm_atomic_check_only -> drm_atomic_plane_check -> drm_plane_check_pixel_format So I think we can just leave this alone, or put the check before import_attach if you really want to put this straight. I guess we can just leave it alone for now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 76130] Radeon HD 4570 set dpm state fails after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=76130 --- Comment #23 from mirh --- (In reply to Thaddaeus Tintenfisch from comment #22) > I was able to resolve the FPS drop by running the following two commands: > > echo battery > /sys/class/drm/card0/device/power_dpm_state > echo balanced > /sys/class/drm/card0/device/power_dpm_state In this case, I guess this now becomes bug 66963 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #12 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #11) > Unfortunately, I can't reproduce the issue with > 3f38e64270c03c9a9eb5368c06dcfd1896fbf6d0 and the same settings, etc. > > Can you try again with latest mesa and boot your kernel with > amdgpu.vm_debug=1? It should be easier to catch all VM faults. > > Though, ideally it would be better to record an apitrace which reproduces > the hang. Sorry it took so long, I've been updating entire distro, and had trouble building Mesa. Currently I'm on git master 4468764ef0cd0e71db03e14aaed7c650ffa1f77d & llvm revision 310200, and I'm not able to reproduce hangs myself. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/amdgpu: move vram usage tracking into the vram manager
On Mon, Aug 7, 2017 at 11:49 AM, Christian König
wrote:
> From: Christian König
>
> Looks like a better place for this.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 9 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 50 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 64
> ++--
> 6 files changed, 71 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index aff89d7..03d6342 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1484,8 +1484,6 @@ struct amdgpu_device {
> struct amdgpu_mman mman;
> struct amdgpu_vram_scratch vram_scratch;
> struct amdgpu_wbwb;
> - atomic64_t vram_usage;
> - atomic64_t vram_vis_usage;
> atomic64_t num_bytes_moved;
> atomic64_t num_evictions;
> atomic64_t num_vram_cpu_page_faults;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index fe974f7..6741deb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -243,7 +243,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct
> amdgpu_device *adev,
> }
>
> total_vram = adev->mc.real_vram_size - adev->vram_pin_size;
> - used_vram = atomic64_read(&adev->vram_usage);
> + used_vram = amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
> free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
>
> spin_lock(&adev->mm_stats.lock);
> @@ -289,7 +289,8 @@ static void amdgpu_cs_get_threshold_for_moves(struct
> amdgpu_device *adev,
> /* Do the same for visible VRAM if half of it is free */
> if (adev->mc.visible_vram_size < adev->mc.real_vram_size) {
> u64 total_vis_vram = adev->mc.visible_vram_size;
> - u64 used_vis_vram = atomic64_read(&adev->vram_vis_usage);
> + u64 used_vis_vram =
> +
> amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
>
> if (used_vis_vram < total_vis_vram) {
> u64 free_vis_vram = total_vis_vram - used_vis_vram;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 3209198..4a6407d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -455,10 +455,10 @@ static int amdgpu_info_ioctl(struct drm_device *dev,
> void *data, struct drm_file
> ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
> return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
> case AMDGPU_INFO_VRAM_USAGE:
> - ui64 = atomic64_read(&adev->vram_usage);
> + ui64 =
> amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
> return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
> case AMDGPU_INFO_VIS_VRAM_USAGE:
> - ui64 = atomic64_read(&adev->vram_vis_usage);
> + ui64 =
> amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
> return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
> case AMDGPU_INFO_GTT_USAGE:
> ui64 = amdgpu_gtt_mgr_usage(&adev->mman.bdev.man[TTM_PL_TT]);
> @@ -497,7 +497,8 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file
> mem.vram.total_heap_size = adev->mc.real_vram_size;
> mem.vram.usable_heap_size =
> adev->mc.real_vram_size - adev->vram_pin_size;
> - mem.vram.heap_usage = atomic64_read(&adev->vram_usage);
> + mem.vram.heap_usage =
> +
> amdgpu_vram_mgr_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
> mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
>
> mem.cpu_accessible_vram.total_heap_size =
> @@ -506,7 +507,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file
> adev->mc.visible_vram_size -
> (adev->vram_pin_size - adev->invisible_pin_size);
> mem.cpu_accessible_vram.heap_usage =
> - atomic64_read(&adev->vram_vis_usage);
> +
> amdgpu_vram_mgr_vis_usage(&adev->mman.bdev.man[TTM_PL_VRAM]);
> mem.cpu_accessible_vram.max_allocation =
> mem.cpu_accessible_vram
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #13 from Samuel Pitoiset --- Did you boot with amdgpu.vm_debug=1? Anyway, I think the previous hangs were related to the CLEAR_state changes which are now fixed in master. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/19] drm/radeon: Use the drm_driver.dumb_destroy default
On Sun, Aug 6, 2017 at 11:41 AM, Noralf Trønnes wrote:
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
>
> Cc: Alex Deucher
> Cc: Christian König
> Signed-off-by: Noralf Trønnes
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index b401f16..f4becad 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -583,7 +583,6 @@ static struct drm_driver kms_driver = {
> .gem_close_object = radeon_gem_object_close,
> .dumb_create = radeon_mode_dumb_create,
> .dumb_map_offset = radeon_mode_dumb_mmap,
> - .dumb_destroy = drm_gem_dumb_destroy,
> .fops = &radeon_driver_kms_fops,
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> --
> 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
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102053] SI card renders noise on Gnome Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=102053 --- Comment #4 from Luya Tshimbalanga --- Shall we mark as duplicate to consolidate the report then? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102053] SI card renders noise on Gnome Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=102053 --- Comment #5 from Luya Tshimbalanga --- (In reply to Luya Tshimbalanga from comment #4) > Shall we mark as duplicate to consolidate the report then? Nevermind. I realized the bug report is on kernel development website. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102053] SI card renders noise on Gnome Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=102053 Luya Tshimbalanga changed: What|Removed |Added URL||https://bugzilla.kernel.org ||/show_bug.cgi?id=194761 --- Comment #6 from Luya Tshimbalanga --- Adding link to related bug -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #38 from MirceaKitsune --- Created attachment 133368 --> https://bugs.freedesktop.org/attachment.cgi?id=133368&action=edit Output of "dmesg -w" (full) Full output of "dmesg -w", recorded by running "dmesg -w > filename.txt". The previous one was incomplete as it was subject to console line limitations, cutting off the moment when the crash actually occurs. I left the command running in a different runlevel; This time the crash didn't shut down the monitor after switching to it (Control + Alt + F1) so I was able to cleanly shut down dmesg then issue a normal reboot. I waited there for about 5 minutes before doing so, to give dmesg time to record as much information as possible. The crash appears to start at the following lines: [112873.658950] radeon :03:00.0: ring 4 stalled for more than 10024msec [112873.658953] radeon :03:00.0: GPU lockup (current fence id 0x0072f6bd last fence id 0x0072f6c1 on ring 4) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video IP
On 08/07/2017 10:13 AM, Philipp Zabel wrote:
Hi Jeffrey,
On Fri, 2017-08-04 at 11:49 -0700, Jeffrey Mouroux wrote:
The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
support video memory formats that are not represented in the
current DRM fourcc library. This patch adds those missing
fourcc codes.
Signed-off-by: Jeffrey Mouroux
---
include/uapi/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..3e80130 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,6 +112,14 @@
#define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_AVUYfourcc_code('A', 'V', 'U', 'Y') /*
[31:0] A:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y little endian */
+#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* [31:0]
x:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
x:Cr:Cb:Y 2:10:10:10 little endian */
+
+/* Grey scale */
+#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8 Greyscale
*/
That would be useful for me as well.
I'm also interested in 8-bit grayscale. I applied these patches then
naively tried to add support for DRM_FORMAT_Y8 to a driver I am working on.
diff --git a/drivers/gpu/drm/tinydrm/st7586.c
b/drivers/gpu/drm/tinydrm/st7586.c
index 1b39d3f..f6db7be 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -56,6 +56,34 @@
static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };
+static void st7586_gray8_to_gray332(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
...
+}
+
static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_clip_rect *clip)
@@ -98,7 +126,14 @@ static int st7586_buf_copy(void *dst, struct
drm_framebuffer *fb,
return ret;
}
- st7586_xrgb_to_gray332(dst, src, fb, clip);
+ switch(fb->format->format) {
+ case DRM_FORMAT_Y8:
+ st7586_gray8_to_gray332(dst, src, fb, clip);
+ break;
+ case DRM_FORMAT_XRGB:
+ st7586_xrgb_to_gray332(dst, src, fb, clip);
+ break;
+ }
if (import_attach)
ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -260,6 +295,7 @@ static void st7586_pipe_disable(struct
drm_simple_display_pipe *pipe)
}
static const u32 st7586_formats[] = {
+ DRM_FORMAT_Y8,
DRM_FORMAT_XRGB,
};
@@ -290,7 +326,7 @@ static int st7586_init(struct device *dev, struct
mipi_dbi *mipi,
if (ret)
return ret;
- tdev->drm->mode_config.preferred_depth = 32;
+ tdev->drm->mode_config.preferred_depth = 8;
mipi->rotation = rotation;
drm_mode_config_reset(tdev->drm);
But it just caused a crash. (Note: had to set fb.lockless_register_fb=1
in the kernel command line to get stack trace.)
Console: switching to colour frame buffer device 22x16
Unable to handle kernel paging request at virtual address c4bd4158
pgd = c2e0c000
[c4bd4158] *pgd=c2dfd811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM
Modules linked in: st7586(+) mipi_dbi tinydrm drm_kms_helper syscopyarea
sysfill
rect sysimgblt fb_sys_fops ofpart drm backlight m25p80 spi_nor
ti_ads7950 indust
rialio_triggered_buffer mtd da8xx kfifo_buf phy_generic pwm_beeper
ohci_da8xx mu
sb_hdrc ohci_hcd usbcore pwm_tiehrpwm davinci_wdt phy_da8xx_usb
pinctrl_da850_pu
pd rtc_omap leds_gpio led_class lego_ev3_battery industrialio tun
libcomposite c
onfigfs udc_core usb_common autofs4
CPU: 0 PID: 126 Comm: systemd-udevd Tainted: GW
4.13.0-rc2-dlech-e
v3+ #486
Hardware name: Generic DA850/OMAP-L138/AM18x
task: c3afd4a0 task.stack: c2d36000
PC is at sys_imageblit+0x278/0x4c8 [sysimgblt]
LR is at 0xc4bd3f40
pc : []lr : []psr: 2013
sp : c2d37810 ip : fp : c2d37864
r10: 0008 r9 : 0018 r8 : c4bd3f40
r7 : c2d26a42 r6 : r5 : 0007 r4 : 0008
r3 : 0010 r2 : c4bd4158 r1 : 00b0 r0 :
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0005317f Table: c2e0c000 DAC: 0051
Process systemd-udevd (pid: 126, stack limit = 0xc2d36190)
Stack: (0xc2d37810 to 0xc2d38000)
7800: 02c8 00b2 c4bd4158
0016
7820: c2d26a42 c2d378e8 0010 0010 c4bd4158 bf1e6154
c2d378e8
7840: c1882000
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 MirceaKitsune changed: What|Removed |Added CC||sonichedgehog_hyperblast00@ ||yahoo.com --- Comment #16 from MirceaKitsune --- I did not expect to find another report on this. I've been struggling with what appears to be the exact same crash for over 6 months. The difference for me is that, this is not caused by Unreal Editor 4; It's triggered exclusively by the KDE desktop, usually when alt-tab switching between windows. My machine is rendered unresponsive approximately every 1 to 4 days. I found this after googling parts of my own dmesg output, which seem to be identical to what you've pasted in the first comment. I too have a RadeonSI card, in my case a Radeon R7 370 from Gigabyte. My OS is openSUSE Tumbleweed x64. More information is available on my report, where I've posted my fair share of logs and observations on the problem. We should first of all determine if this is the same issue beyond doubt, then hopefully combining the information we've both obtained can lead to a solution. https://bugs.freedesktop.org/show_bug.cgi?id=100306 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #39 from MirceaKitsune --- I randomly decided to google parts of my dmesg output. I was surprised to discover that someone else has reported a very similar issue, which looks like it might have the same root as mine! https://bugs.freedesktop.org/show_bug.cgi?id=101325 The dmesg output their provided almost perfectly matches my last log, and they also have a RadeonSI card which further narrows down the problem. The main difference is that they experience this with Unreal Engine 4 Editor, whereas for me the trigger is the Plasma desktop. That report seems to contain a fair amount of logs, so hopefully bringing it and this together can help produce a solution at long last. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 MirceaKitsune changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=101325 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 MirceaKitsune changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=100306 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dma-buf: add reservation_object_copy_fences
From: Christian König
Allows us to copy all the fences in a reservation object to another one.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/dma-buf/reservation.c | 58 +++
include/linux/reservation.h | 3 +++
2 files changed, 61 insertions(+)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 87f8f57..e2eff86 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -262,6 +262,64 @@ void reservation_object_add_excl_fence(struct
reservation_object *obj,
EXPORT_SYMBOL(reservation_object_add_excl_fence);
/**
+* reservation_object_copy_fences - Copy all fences from src to dst.
+* @dst: the destination reservation object
+* @src: the source reservation object
+*
+* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
+* held.
+*/
+int reservation_object_copy_fences(struct reservation_object *dst,
+ struct reservation_object *src)
+{
+ struct reservation_object_list *src_list, *dst_list;
+ struct dma_fence *old, *new;
+ size_t size;
+ unsigned i;
+
+ src_list = reservation_object_get_list(src);
+
+ /*
+* resize dst->fence or allocate if it doesn't exist,
+* noop if already correct size
+*/
+ size = offsetof(typeof(*src_list), shared[src_list->shared_count]);
+ dst_list = kmalloc(size, GFP_KERNEL);
+ if (!dst_list)
+ return -ENOMEM;
+
+ kfree(dst->staged);
+ dst->staged = NULL;
+
+ dst_list->shared_count = src_list->shared_count;
+ dst_list->shared_max = src_list->shared_count;
+ for (i = 0; i < src_list->shared_count; ++i)
+ dst_list->shared[i] = dma_fence_get(src_list->shared[i]);
+
+ src_list = reservation_object_get_list(dst);
+
+ old = reservation_object_get_excl(dst);
+ new = reservation_object_get_excl(src);
+
+ dma_fence_get(new);
+
+ preempt_disable();
+ write_seqcount_begin(&dst->seq);
+ /* write_seqcount_begin provides the necessary memory barrier */
+ RCU_INIT_POINTER(dst->fence_excl, new);
+ RCU_INIT_POINTER(dst->fence, dst_list);
+ write_seqcount_end(&dst->seq);
+ preempt_enable();
+
+ if (src_list)
+ kfree_rcu(src_list, rcu);
+ dma_fence_put(old);
+
+ return 0;
+}
+EXPORT_SYMBOL(reservation_object_copy_fences);
+
+/**
* reservation_object_get_fences_rcu - Get an object's shared and exclusive
* fences without update side lock held
* @obj: the reservation object
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 156cfd3..21fc84d 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -254,6 +254,9 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
unsigned *pshared_count,
struct dma_fence ***pshared);
+int reservation_object_copy_fences(struct reservation_object *dst,
+ struct reservation_object *src);
+
long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
bool wait_all, bool intr,
unsigned long timeout);
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] dma-buf changes for ttm and amdgpu
We have some changes in ttm and amdgpu that depend on these patches. Sumit, can you pull these in via dma-buf or should I roll them up through my amdgpu tree? Christian König (3): dma-buf: dma_fence_put is NULL safe dma-buf: add reservation_object_copy_fences dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2 drivers/dma-buf/reservation.c | 97 +-- include/linux/reservation.h | 3 ++ 2 files changed, 78 insertions(+), 22 deletions(-) -- 2.5.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf: dma_fence_put is NULL safe
From: Christian König No need to check. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/dma-buf/reservation.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 393817e..87f8f57 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -195,8 +195,7 @@ reservation_object_add_shared_replace(struct reservation_object *obj, if (old) kfree_rcu(old, rcu); - if (old_fence) - dma_fence_put(old_fence); + dma_fence_put(old_fence); } /** @@ -258,8 +257,7 @@ void reservation_object_add_excl_fence(struct reservation_object *obj, dma_fence_put(rcu_dereference_protected(old->shared[i], reservation_object_held(obj))); - if (old_fence) - dma_fence_put(old_fence); + dma_fence_put(old_fence); } EXPORT_SYMBOL(reservation_object_add_excl_fence); -- 2.5.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2
From: Christian König
With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.
v2: make sure we always wait for the exclusive fence
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
drivers/dma-buf/reservation.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index e2eff86..302c137 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -429,12 +429,25 @@ long reservation_object_wait_timeout_rcu(struct
reservation_object *obj,
long ret = timeout ? timeout : 1;
retry:
- fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(&obj->seq);
rcu_read_lock();
- if (wait_all) {
+ fence = rcu_dereference(obj->fence_excl);
+ if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+ if (!dma_fence_get_rcu(fence))
+ goto unlock_retry;
+
+ if (dma_fence_is_signaled(fence)) {
+ dma_fence_put(fence);
+ fence = NULL;
+ }
+
+ } else {
+ fence = NULL;
+ }
+
+ if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj->fence);
@@ -461,22 +474,6 @@ long reservation_object_wait_timeout_rcu(struct
reservation_object *obj,
}
}
- if (!shared_count) {
- struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
- if (fence_excl &&
- !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &fence_excl->flags)) {
- if (!dma_fence_get_rcu(fence_excl))
- goto unlock_retry;
-
- if (dma_fence_is_signaled(fence_excl))
- dma_fence_put(fence_excl);
- else
- fence = fence_excl;
- }
- }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(&obj->seq, seq)) {
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #40 from Alex Deucher --- (In reply to MirceaKitsune from comment #39) > I randomly decided to google parts of my dmesg output. I was surprised to > discover that someone else has reported a very similar issue, which looks > like it might have the same root as mine! > > https://bugs.freedesktop.org/show_bug.cgi?id=101325 > > The dmesg output their provided almost perfectly matches my last log, and > they also have a RadeonSI card which further narrows down the problem. The > main difference is that they experience this with Unreal Engine 4 Editor, > whereas for me the trigger is the Plasma desktop. > > That report seems to contain a fair amount of logs, so hopefully bringing it > and this together can help produce a solution at long last. All of these bug reports are GPU lockups. Whether they are the same root cause or not remains to be seen. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #17 from MirceaKitsune --- Created attachment 133369 --> https://bugs.freedesktop.org/attachment.cgi?id=133369&action=edit Output of "dmesg -w" (full) Full output of "dmesg -w", recorded by running "dmesg -w > filename.txt". It includes the dmesg log of the entire session, up until the crash occurs and the monitor turns off. My issue looks very related to yours, so I felt it would make sense to also publish this here. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge.
Hi Daniel, On Monday 07 Aug 2017 16:59:39 Daniel Vetter wrote: > On Mon, Aug 07, 2017 at 01:22:23PM +0300, Laurent Pinchart wrote: > > On Monday 07 Aug 2017 11:25:07 Daniel Vetter wrote: > >> On Sat, Aug 05, 2017 at 12:59:07PM +0200, Noralf Trønnes wrote: > >>> Den 05.08.2017 00.19, skrev Ilia Mirkin: > On Fri, Aug 4, 2017 at 4:43 PM, Eric Anholt wrote: > > Laurent Pinchart writes: > >> On Tuesday 18 Jul 2017 14:05:06 Eric Anholt wrote: > >>> This will let drivers reduce the error cleanup they need, in > >>> particular the "is_panel_bridge" flag. > >>> > >>> v2: Slight cleanup of remove function by Andrzej > >> > >> I just want to point out that, in the context of Daniel's work on > >> hot-unplug, 90% of the devm_* allocations are wrong and will get in > >> the way. All DRM core objects that are accessible one way or > >> another from userspace will need to be properly reference-counted > >> and freed only when the last reference disappears, which could be > >> well after the corresponding device is removed. I believe this > >> could be one such objects :-/ > > > > Sure, if you're hotplugging, your life is pain. For > > non-hotpluggable devices, like our SOC platform devices (current > > panel-bridge consumers), this still seems like an excellent > > simplification of memory management. > > At that point you may as well make your module non-unloadable, and > return failure when trying to remove a device from management by the > driver (whatever the opposite of "probe" is, I forget). Hotplugging > doesn't only happen when physically removing, it can happen for all > kinds of reasons... and userspace may still hold references in some > of those cases. > >>> > >>> If drm_open() gets a ref on dev->dev and puts it in drm_release(), > >>> won't that delay devm_* cleanup until userspace is done? > >> > >> No. drm_device is the thing that is refcounted for userspace references > >> like open FD (we're not perfect about it, e.g. sysfs and dma-buf/fence > >> don't). > >> > >> devm_ otoh is tied to the lifetime of the underlying device, and that > >> one can get outlived by drm_device. Or at least afaiui, devm_ stuff is > >> nuked on unplug, and not when the final sw reference of the struct device > >> disappears. > >> > >> Not sure tough, it's complicated. > > > > It's complicated when you have to understand the behaviour by reading the > > code, but the behaviour isn't that complex. devm resources are released > > both > > > > 1. right after the driver's .remove() operation returns > > 2. when the device is deleted (last reference released) > > Right, I had vague memories when reading the code ... But iirc there's > also some way to delay cleanup until it's deleted, maybe we could exploit > that (and wrap it up into a drm_devm_add wrapper)? > > Plan B, but that is a lot more ugly, would be to create a fake struct > device that we never bind (hence remove can't be called) and use to track > the lifetime of drm_device stuff. Would avoid re-inventing all the devm_ > functions, but would also result in a dummy device in sysfs. If we wanted to go that way, we should decouple devm_* from struct device (or even struct kobject) and tie it to a new resource tracker structure. The current devm_* API would remain the same, embedding that resource tracker object in struct device, but we could also use the machinery with the resource tracker object directly. However, I'm not convince we should do so. We don't have any automatic memory allocation system for DRM objects (such as framebuffers or planes). Instead, drivers must implement a destroy operation for the object, and the core calls it when the last reference to the object goes away. This works fine, and I don't see what would prevent use from implementing the same mechanism for bridges or other similar structures. > Why is this stuff tied to struct device and not struct kobject anyway. Or > at least something we could embed in random cool place (like drm_device). > > Greg, any ideas how we could simplify management of stuff that's created > at driver load, but its lifetime tied to something which isn't directly a > struct device? > > > It's the first one that makes devm_* allocation unsuitable for any > > structure that is accessible from userspace (such as in file operation > > handlers). > > Yeah, if we could release at 2. it would be perfect I think ... It wouldn't, as unbind/rebind cycles would allocate new objects each time without freeing the previous ones until the device is deleted. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/14] clean up drm_bridge_add
Daniel, please ping~ 2017년 07월 03일 17:42에 Inki Dae 이(가) 쓴 글: > This patch series changes return type of drm_bridge_add > function to void one and also removes unnecessary checking > of the return type from relevant drivers. > > Ps. I had just build test so each maintainer may need to check this. > > Inki Dae (14): > drm/bridge: change return type of drm_bridge_add function > drm/bridge: adv7511: clean up drm_bridge_add call > drm/bridge: analogix-anx78xx: clean up drm_bridge_add call > drm/bridge: vga-dac: clean up drm_bridge_add call > drm/bridge: nxp-ptn3460: clean up drm_bridge_add call > drm/bridge: panel: clean up drm_bridge_add call > drm/bridge: ps8622: clean up drm_bridge_add call > drm/bridge: sii902x: clean up drm_bridge_add call > drm/bridge: synopsys: dw-hdmi: clean up drm_bridge_add call > drm/bridge: tc358767: clean up drm_bridge_add call > drm/bridge: ti-tfp410: clean up drm_bridge_add call > drm/exynos: mic: clean up drm_bridge_add call > drm/mediatek: hdmi: clean up drm_bridge_add call > drm/sti: sti_vdo: clean up drm_bridge_add call > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c| 6 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c| 9 +++-- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 6 +- > drivers/gpu/drm/bridge/panel.c | 5 + > drivers/gpu/drm/bridge/parade-ps8622.c | 6 +- > drivers/gpu/drm/bridge/sii902x.c | 6 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 7 +-- > drivers/gpu/drm/bridge/tc358767.c| 6 +- > drivers/gpu/drm/bridge/ti-tfp410.c | 6 +- > drivers/gpu/drm/drm_bridge.c | 7 +-- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 +- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 6 +- > drivers/gpu/drm/sti/sti_dvo.c| 6 +- > include/drm/drm_bridge.h | 2 +- > 15 files changed, 17 insertions(+), 73 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=101977 --- Comment #3 from Timothee Besset --- Created attachment 133372 --> https://bugs.freedesktop.org/attachment.cgi?id=133372&action=edit apitrace Stepped through and commented out code until I could narrow down the last GL call that leads to a crash. Captured an apitrace up until the call that will ultimately cause the problem. https://gist.github.com/TTimo/05222bd524b534977c5e72bcb3df3dfc -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=94410 --- Comment #7 from Felix Hellmann --- I tested with the current promoted branch (which has the linker script commented out by default). This gives me a complete desktop freeze like Thomas Kowaliczek already reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=94410 --- Comment #8 from Timothee Besset --- The freeze problems are very likely this issue: https://bugs.freedesktop.org/show_bug.cgi?id=101977 I haven't seen this allocator problem in 4.16 with ubuntu 16.x, I suspect it's tied to a clang / libstdc++ / distribution combo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=101977 --- Comment #4 from Timothee Besset --- Created attachment 133373 --> https://bugs.freedesktop.org/attachment.cgi?id=133373&action=edit apitrace FBlackCubeArrayTexture::InitRHI Another trace: same crash, but initializing a different resource (FBlackCubeArrayTexture::InitRHI). The skipped call triggering the crash: TexSubImage3D #2: target = 36873 level = 0 xoffset = 0 yoffset = 0 zoffset = 0 width = 1 height = 1 depth = 1 format = 32993 type = 33639 pixels = 0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: Add missing panel_simple_unprepare calls
During panel removal or system shutdown panel_simple_disable is called
which disables the panel backlight but the panel is still powered due to
missing calls to panel_simple_unprepare.
Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown")
Cc: sta...@vger.kernel.org # v3.16+
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 474fa759e06e..234af81fb3d0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -369,6 +369,7 @@ static int panel_simple_remove(struct device *dev)
drm_panel_remove(&panel->base);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
if (panel->ddc)
put_device(&panel->ddc->dev);
@@ -384,6 +385,7 @@ static void panel_simple_shutdown(struct device *dev)
struct panel_simple *panel = dev_get_drvdata(dev);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
}
static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
--
2.13.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video IP
Hi Philipp,
Thanks for the reply. Please see me comments inline:
-Original Message-
From: Philipp Zabel [mailto:p.za...@pengutronix.de]
Sent: Monday, August 07, 2017 8:14 AM
To: Jeff Mouroux
Cc: daniel.vet...@intel.com; jani.nik...@linux.intel.com;
seanp...@chromium.org; airl...@linux.ie; dri-devel@lists.freedesktop.org; Jeff
Mouroux
Subject: Re: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video
IP
Hi Jeffrey,
On Fri, 2017-08-04 at 11:49 -0700, Jeffrey Mouroux wrote:
> The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
> support video memory formats that are not represented in the
> current DRM fourcc library. This patch adds those missing
> fourcc codes.
>
> Signed-off-by: Jeffrey Mouroux
> ---
> include/uapi/drm/drm_fourcc.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ef20abb..3e80130 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -112,6 +112,14 @@
> #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_AVUY fourcc_code('A', 'V', 'U', 'Y') /*
> [31:0] A:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y little endian */
> +#define DRM_FORMAT_XVUY fourcc_code('X', 'V', '2', '4') /* [31:0]
> x:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0') /*
> [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> +
> +/* Grey scale */
> +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /* 8
> Greyscale */
That would be useful for me as well.
> +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /* 10
> Greyscale */
It is not clear to me from the description, how this should be laid out
in memory. Is it padded to 16 bits? Packed?
[Jeff Mouroux] I expect this is 2:10:10:10 (i.e. x:Y2:Y1:Y0). I can clarify
in the comments for v2.
> /*
> * 2 plane YCbCr
> @@ -126,6 +134,7 @@
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_XV15 fourcc_code('X', 'V', '2', '0') /* 2x2
> subsampled Cb:Cr plane 2:10:10:10 */
Same here.
[Jeff Mouroux] The chroma plane is described but I suppose the luma is what's
missing. The luma should work just like
Y10 (2:10:10:10 as in x:Y2:Y1:Y0). I didn't want the comment string to be too
long but can reference Y10 layout for luma
if that would help.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
