RE: [PATCH 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update
> > > > +#include > > > > +#include > > > > + > > > > +/** > > > > + * DOC: overview > > > > + * > > > > + * FB_DAMAGE_CLIPS is an optional plane property which provides a > > > means to > > > > + * specify a list of damage rectangles on a plane in framebuffer > > > coordinates of > > > > + * the framebuffer attached to the plane. In current context damage is > > > the area > > > > + * of plane framebuffer (excluding the framebuffer area which is > > > > outside > > > of > > > > + * plane src) > > > > > > Not sure why the plane src coordinates need to be mentioned here. The > > > damage is just the part of the fb that has changed. Whether or not it > > > extends past the src coordinates is totally irrelevant as far as I can > > > see. > > > > Thanks Ville for the review, > > > > Well this is plane damage property and only those clips which falls inside > > will be used for plane update, so outside plane src is not required. > > Actually we've never specified that properly. My usual interpretation is > that the plane is allowed to sample past the edge of the src rectangle > (to get nicer looking edges). But not sure whether that would be too > surprising to people though. So we might want follow the GL linear filter > rules by default, and if someone wants better looking edges we could > add a property that allows the filter to reach further past the edge. Ok, it makes sense not to specify plane src part, anyway with current implementation kernel do not error if damage clips are outside plane src. The helper iterator clip to plane_src but depending on the above use case can have other implementations as well. Thanks, Deepak ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103300] Tear rendering bug in Bioshock Infinite
https://bugs.freedesktop.org/show_bug.cgi?id=103300 --- Comment #4 from Ian Bruene --- (In reply to Timothy Arceri from comment #2) > If so do you think you could get an apitrace [1] of the problem? > > [1] https://github.com/apitrace/apitrace/wiki/Steam I tried today and was unable to get a trace I'm afraid. -- 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 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update
> > On Thu, 6 Sep 2018 21:36:51 + > Deepak Singh Rawat wrote: > > > > > > > - Why no input validation on the damage clips against the framebuffer > > > size? Ime not validating just leads to funny driver bugs down the road, > > > so what's the use-case you have in mind here? > > > > My motivation behind not informing user-space if damage is outside plane > > src, sent during modeset(where it should be provided) or damage is outside > > framebuffer coordinate (simply put damage clips are invalid) is that it's a > > hint. The contract between kernel and user-space is simple, if damage > > clips are valid, kernel might use them (but not always) otherwise they > > will be ignored. Damage can be ignored deep in the stack (like network), > > so all the input validation for nothing. > > > > Also, what all to consider in input validation ? > > * clips are outside plane src > > * damage clips sent during modeset should error ? > > * any other properties. > > > > This will lead to a complex input validation during modeset check like > > if some drivers are OK with damage while scaling whereas others > > cannot support, should this error? > > > > However I am alright doing input validation if this becomes clear what > > kind of validation to actually do. My understanding of drm core is limited. > > Hi, > > I think validating that the area of any clip rectangle does not extend > beyond the framebuffer size would be good. A userspace violating that > is arguably broken, so it would help catch userspace bugs. > > I also would not assume that damage is irrelevant on modeset. Userspace > does not always know if an update will be a modeset or not: drivers vary > there, and userspace that just wants the update through will allow > modesets always while still providing damage. Userspace could also > change video mode timings or pixel format while keeping the resolution > the same, and in that case damage could be meaningful to a driver. > Thanks Pekka, for explanation. I agree clips outside framebuffer should be errored and also it's not a lot for drm core. Also, will look into the cases where drm core should clear the damage clips, like resolution change, etc. May be the better approach would be drm core just provide the helper and driver takes care of driver specific scenarios. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/21] fbdev: fsl-diu: get cpu node with of_get_cpu_node
On 9/5/18 2:37 PM, Rob Herring wrote: #ifdef CONFIG_NOT_COHERENT_CACHE - np = of_find_node_by_type(NULL, "cpu"); + np = of_get_cpu_node(0, NULL); This #ifdef means that it's only compiled on an MPC5121, which is a very dead platform. of_get_cpu_node() looks okay to me, but I'm going to have to assume that you know what you're doing. Acked-by: Timur Tabi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 0/3] add LG panel to dpcd quirk database
On Mon, Sep 10, 2018 at 10:55 AM Alex Deucher wrote: >> >> Only specific N value (0x8000) would be acceptable for LG >> LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode. >> With the other N value, it will enter BITS mode and display black >> screen. This patch series set constant N value for specific >> sink/branch device that would cover similar issue. > >Is this an explicit requirement of the panel itself or just a workaround for >for a PLL limitation on a particular GPU? For example, due to hw design and >electrical characteristics, certain divider combinations may not be viable on >certain asics. If that's the case, shouldn't this be handled in an asic >specific manor? If it's a requirement of the panel itself, ignore me and >carry on. > >Alex > This is a special requirement that panel's tcon ask a particular value of N divider. Tcon needs this value for internal configuration. >> >> Cc: Jani Nikula >> Cc: Cooper Chiou >> Cc: Matt Atwood >> Cc: Maarten Lankhorst >> Cc: Dhinakaran Pandiyan >> Cc: Clint Taylor >> >> Lee, Shawn C (3): >> drm: Add support for device_id based detection. >> drm: Change limited M/N quirk to constant N quirk. >> drm: add LG eDP panel to quirk database >> >> drivers/gpu/drm/drm_dp_helper.c | 17 - >> drivers/gpu/drm/i915/intel_display.c | 28 >> +--- drivers/gpu/drm/i915/intel_display.h | 2 +- >> drivers/gpu/drm/i915/intel_dp.c | 8 >> drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++--- >> include/drm/drm_dp_helper.h | 6 +++--- >> 6 files changed, 40 insertions(+), 27 deletions(-) >> >> -- >> 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
Re: [PATCH] qxl: refactor to use drm_fb_helper_fbdev_setup
Hi Peter,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc3 next-20180910]
[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/Peter-Wu/qxl-refactor-to-use-drm_fb_helper_fbdev_setup/20180911-071413
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/qxl/qxl_drv.c:144:9: sparse: undefined identifier
'qxl_fbdev_set_suspend'
drivers/gpu/drm/qxl/qxl_drv.c:181:9: sparse: undefined identifier
'qxl_fbdev_set_suspend'
>> drivers/gpu/drm/qxl/qxl_drv.c:144:30: sparse: call with no type!
drivers/gpu/drm/qxl/qxl_drv.c:181:30: sparse: call with no type!
drivers/gpu/drm/qxl/qxl_drv.c: In function 'qxl_drm_freeze':
drivers/gpu/drm/qxl/qxl_drv.c:144:2: error: implicit declaration of function
'qxl_fbdev_set_suspend'; did you mean 'fb_set_suspend'?
[-Werror=implicit-function-declaration]
qxl_fbdev_set_suspend(qdev, 1);
^
fb_set_suspend
cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/qxl/qxl_fb.c:166:21: sparse: incorrect type in assignment
>> (different address spaces) @@expected char const *data @@got char
>> [noderchar const *data @@
drivers/gpu/drm/qxl/qxl_fb.c:166:21:expected char const *data
drivers/gpu/drm/qxl/qxl_fb.c:166:21:got char [noderef] *
include/linux/overflow.h:251:13: sparse: undefined identifier
'__builtin_mul_overflow'
include/linux/overflow.h:251:13: sparse: incorrect type in conditional
include/linux/overflow.h:251:13:got void
include/linux/overflow.h:251:13: sparse: call with no type!
vim +166 drivers/gpu/drm/qxl/qxl_fb.c
130
131 /*
132 * FIXME
133 * It should not be necessary to have a special dirty() callback for
fbdev.
134 */
135 static int qxlfb_framebuffer_dirty(struct drm_framebuffer *fb,
136 struct drm_file *file_priv,
137 unsigned flags, unsigned color,
138 struct drm_clip_rect *clips,
139 unsigned num_clips)
140 {
141 struct qxl_device *qdev = fb->dev->dev_private;
142 struct fb_info *info = qdev->fb_helper.fbdev;
143 struct qxl_fb_image qxl_fb_image;
144 struct fb_image *image = _fb_image.fb_image;
145
146 /* TODO: hard coding 32 bpp */
147 int stride = fb->pitches[0];
148
149 /*
150 * we are using a shadow draw buffer, at qdev->surface0_shadow
151 */
152 image->dx = clips->x1;
153 image->dy = clips->y1;
154 image->width = clips->x2 - clips->x1;
155 image->height = clips->y2 - clips->y1;
156 image->fg_color = 0x; /* unused, just to avoid
uninitialized
157 warnings */
158 image->bg_color = 0;
159 image->depth = 32; /* TODO: take from somewhere? */
160 image->cmap.start = 0;
161 image->cmap.len = 0;
162 image->cmap.red = NULL;
163 image->cmap.green = NULL;
164 image->cmap.blue = NULL;
165 image->cmap.transp = NULL;
> 166 image->data = info->screen_base + (clips->x1 * 4) + (stride *
> clips->y1);
167
168 qxl_fb_image_init(_fb_image, qdev, info, NULL);
169 qxl_draw_opaque_fb(_fb_image, stride);
170
171 return 0;
172 }
173
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104906] Mesa crashes randomly during Youtube playback
https://bugs.freedesktop.org/show_bug.cgi?id=104906 Timothy Arceri changed: What|Removed |Added Resolution|--- |INVALID Status|NEEDINFO|RESOLVED --- Comment #3 from Timothy Arceri --- Closing as invalid for lack of better option as reporter is unable to test on the setup reported against and there have been various KDE/Mesa related bugs fixed on both side in the months since this bug was 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 201067] [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 --- Comment #2 from Nick Sarnie (sar...@gentoo.org) --- Hi Nicholas, Thank you for the fast response. I can confirm the patch fixes the issue. If you intend to submit this: Tested-by: Nick Sarnie Thanks, Sarnex -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 --- Comment #4 from Alex Deucher --- Can you bisect? Also please attach your dmesg output. -- 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 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 Alex Deucher changed: What|Removed |Added Attachment #141511|text/x-log |text/plain mime type|| -- 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 0/3] add LG panel to dpcd quirk database
On Mon, Sep 10, 2018 at 10:55 AM Lee, Shawn C wrote: > > Only specific N value (0x8000) would be acceptable for LG > LP140WF6-SPM1 eDP panel which is running at asynchronous > clock mode. With the other N value, it will enter BITS mode > and display black screen. This patch series set constant N > value for specific sink/branch device that would cover > similar issue. Is this an explicit requirement of the panel itself or just a workaround for for a PLL limitation on a particular GPU? For example, due to hw design and electrical characteristics, certain divider combinations may not be viable on certain asics. If that's the case, shouldn't this be handled in an asic specific manor? If it's a requirement of the panel itself, ignore me and carry on. Alex > > Cc: Jani Nikula > Cc: Cooper Chiou > Cc: Matt Atwood > Cc: Maarten Lankhorst > Cc: Dhinakaran Pandiyan > Cc: Clint Taylor > > Lee, Shawn C (3): > drm: Add support for device_id based detection. > drm: Change limited M/N quirk to constant N quirk. > drm: add LG eDP panel to quirk database > > drivers/gpu/drm/drm_dp_helper.c | 17 - > drivers/gpu/drm/i915/intel_display.c | 28 +--- > drivers/gpu/drm/i915/intel_display.h | 2 +- > drivers/gpu/drm/i915/intel_dp.c | 8 > drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++--- > include/drm/drm_dp_helper.h | 6 +++--- > 6 files changed, 40 insertions(+), 27 deletions(-) > > -- > 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
Re: omap4: support for manually updated display
Hi, On Mon, Sep 10, 2018 at 03:24:37PM +0300, Laurent Pinchart wrote: > On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote: > > On 30/08/18 12:04, Pavel Machek wrote: > > > There's neat series of patches on > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/ > > > ?h=droid4-pending-v4.19 > > > > > > They enable display support for my hardware. As you can imagine, > > > display is rather important for a cellphone. > > > > > > Tomi, can you take the patches? I can resubmit them in email, or > > > shuffle them to another branch without mfd changes, or clean them up > > > etc... > > > > A large omapdrm change set from Laurent was merged into drm-next, and > > I'm certain they conflict with this series. Laurent also has continued > > that work, and while those new patches haven't been sent for review yet, > > I fear they'll also conflict with these. > > > > So in the minimum, a rebase on top of drm-next is needed. > > > > I also continue to be very worried that adding DSI support to omapdrm at > > this stage will be a huge extra burden for Laurent's work. > > > > We should transform the panel-dsi-cm.c towards the common DRM model. > > With a quick look, there seems to be a driver for Samsung's S6E63J0X03 > > panel. So possibly all the DSI features are there in the DRM framework, > > but someone needs to check that and start working on panel-dsi-cm.c so > > that it's ready when we finally switch to the DRM model. > > > > In my opinion, which I've also expressed before, the above work is much > > easier to do by first changing the omapdrm to DRM model, without any DSI > > displays, and then add the DSI command mode support. But if people > > insist on adding the DSI support already now, I would appreciate the > > same people working on the DSI support so that Laurent doesn't have to > > do it all. > > I want to make it clear that I don't want to claim any privilege in getting > patches merged first. I am however worried that, without an easy way to test > DSI support, and without enough time to focus on it, I would break whatever > would be merged now in future reworks. I would thus like to find out how to > collaborate on this task, hopefully to move towards usage of drm_bridge and > drm_panel for DSI-based pipelines. I'm currently quite busy and barely find enough time to do my work as power-supply subsystem maintainer, but I already started to rebase the series. I agree, that it would be very nice to move towards usage of common DRM framework(s), but it's also nice to see which patch breaks DSI ;) P.S.: Laurent, if its helpful for your work I'm willing to sponsor a Droid 4. It's OMAP4 based and uses a manually updated DSI panel. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201015] [amdgpu] BUG: unable to handle kernel NULL pointer dereference on resume with 2 monitors (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201015 --- Comment #7 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- (In reply to Nicholas Kazlauskas from comment #6) > I'd imagine you're probably running GNOME on Wayland from that setup > environment. > > The patch seems to fix the null pointer deference but you're probably > getting a black screen from those failed atomic commits. > > Might not be a problem with the driver but with the GNOME Wayland > implementation - I would need to do more investigation to see which atomic > commits are failing and if the failures are valid (but unchecked). > > You would probably not see this occur for GNOME over Xorg. No, it occurs with Gnome on Xorg, with modesetting driver. Gnome on Wayland seems to handle suspend and resume fine (even on unpatched 4.19-rc3). Also, I tried xf86-video-amdgpu. It works like Gnome on Wayland, but sometimes after resume one display is limited to 800x600 resolution only (it's a 4k display). Probably another different issue. I expected modesetting driver to work though. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
On Mon, Sep 10, 2018 at 06:29:46PM +0100, Alexandru Gheorghe wrote:
> DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> to me, so try to clarify that with a bit of ascii graphics.
>
> Changes since v1:
> - Move the ascii graphics in the kerneldoc where all plane
> properties are already documented and make sure it's properly
> rendered, suggestested by Daniel Vetter.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_blend.c | 22 ++
> include/uapi/drm/drm_mode.h | 3 ++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 402b62d3f072..92f75c5c93ac 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -101,6 +101,28 @@
> * Without this property the rectangle is only scaled, but not rotated or
> * reflected.
> *
> + * Possbile values:
> + *
> + * "rotate-":
> + * Signals that a drm plane is rotated degrees in counter
> + * clockwise direction.
> + *
> + * "reflect-":
> + * Signals that the contents of a drm plane is reflected along the
> + *axis, in the same way as mirroring.
> + *
> + * reflect-x::
> + *
> + * |o || o|
> + * | | -> | |
> + * | v||v |
> + *
> + * reflect-y::
> + *
> + * |o || ^|
> + * | | -> | |
> + * | v||o |
> + *
> * zpos:
> * Z position is set up with drm_plane_create_zpos_immutable_property() and
> * drm_plane_create_zpos_property(). It controls the visibility of
> overlapping
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8d67243952f4..d3e0fe31efc5 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -186,8 +186,9 @@ extern "C" {
> /*
> * DRM_MODE_REFLECT_
> *
> - * Signals that the contents of a drm plane is reflected in the axis,
> + * Signals that the contents of a drm plane is reflected along the
> axis,
> * in the same way as mirroring.
> + * See kerneldoc chapter "Plane Composition Properties" for more details.
I think that won't properly hyperlink. Bonus if you fix that (kernel-doc
is just normal sphinx text, plus some additional parsing for backwards
compat). Either way:
Reviewed-by: Daniel Vetter
> *
> * This define is provided as a convenience, looking up the property id
> * using the name->prop id lookup is the preferred method.
> --
> 2.18.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: Add new DIRTY fb flags to pass interlaced alternate fields
On Mon, Sep 10, 2018 at 03:02:16PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 07, 2018 at 02:46:21PM -0700, Satish Kumar Nagireddy wrote:
> > The requirement is to render interlaced alternate buffers. In case of
> > alternate, top field and bottom field are in two different buffers.
> >
> > The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
> > and DRM_MODE_PRESENT_TOP_FIELD to DRM_IOCTL_MODE_SETPLANE ioctl?
>
> The original idea with those flags was bob deinterlacing type of stuff.
>
> For fbs with non-interleaved fields I think we'd have to extend addfb
> somewhat to allow passing a separate buffer for each field. The problem
> with that is that we only have 4 buffers in addfb, so we'd run out for
> three plane formats. So we'd have to increase the number of buffers in
> addfb, or add some kind of implicit assumption on how the fields are
> stored in the single bo (which I presume might not even be possible on
> some crazy hardware).
Yeah given that an fb is supposed to stick around potentially forever, I
think we need to have both fields in one logical framebuffer object. But I
have no idea how exactly we'd best go about for this, at least for true
interlaced. Doubling up the drm_mode_fb_cmd2 structure (including fourcc
and modifiers, or not?) is probably simplest.
-Daniel
> > But in case if urrent frame out of display range, application
> > will invoke DRM_IOCTL_MODE_PAGE_FLIP ioctl. So, it is not guaranteed
> > that application will always call setplane(), it may also call page_flip().
> > Then we will have to introduce two more flags to pass with page_flip()
> > ioctl, which is complicating things.
> >
> > Background of DRM_IOCTL_MODE_DIRTYFB ioctl: This ioctl is defined, so
> > that userspace can notify the driver that an area of framebuffer has
> > changed and should be flushed to display hardware.
> >
> > The proposed solution is to introduce new dirty fb flags, so that userspace
> > can pass them with every alternate field buffer and the same is reached
> > display hardware. This patch adds new dirty framebuffer flags, so that
> > application can pass interlaced alternate field information to driver.
> >
> > Signed-off-by: Satish Kumar Nagireddy
> >
> > ---
> > include/uapi/drm/drm_mode.h | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index ce7efe2..40fef85 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -428,7 +428,9 @@ struct drm_mode_fb_cmd2 {
> >
> > #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
> > #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
> > -#define DRM_MODE_FB_DIRTY_FLAGS 0x03
> > +#define DRM_MODE_FB_DIRTY_TOP_FIELD 0x03
> > +#define DRM_MODE_FB_DIRTY_BOTTOM_FIELD 0x04
> > +#define DRM_MODE_FB_DIRTY_FLAGS 0x07
> >
> > #define DRM_MODE_FB_DIRTY_MAX_CLIPS 256
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
> ___
> 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
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 Marvin Damschen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Marvin Damschen --- I overlooked that the ubuntu kernel builds bring their own firmware for each version. In my case, I had the recent firmware in /lib/firmware/amdgpu, but /lib/firmware/4.19.0-041900rc3-generic/amdgpu/ was actually used. I moved the files accordingly and 4.19-rc3 boots perfectly fine now without any extra parameters. Thank you and sorry for the trouble. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Mon, Sep 10, 2018 at 09:50:03AM +0100, Brian Starkey wrote: > Hi, > > On Fri, Sep 07, 2018 at 09:28:44PM +0200, Daniel Vetter wrote: > > On Fri, Sep 07, 2018 at 01:45:36PM +0100, Brian Starkey wrote: > > > Hi Daniel, > > > > > > On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: > > > > On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: > > > > > Some formats have a non-integer number of bytes per pixel, which can't > > > > > be handled with the existing 'cpp' field in drm_format_info. To handle > > > > > these formats, add a 'bpp' field, which is only used if cpp[0] == 0. > > > > > > > > > > This updates all the users of format->cpp in the core DRM code, > > > > > converting them to use a new function to get the bits-per-pixel for > > > > > any > > > > > format. > > > > > > > > > > It's assumed that drivers will use the 'bpp' field when they add > > > > > support > > > > > for pixel formats with non-integer bytes-per-pixel. > > > > > > > > > > Signed-off-by: Brian Starkey > > > > > > > > I assume you still require that stuff is eventually aligned to bytes? In > > > > that case, can we subsume this into the tile work Alex is doing? It's > > > > essentially just another special case of having storage-size units > > > > measured in bytes which span more than 1x1 pixel. And I kinda don't > > > > want a > > > > metric pile of special cases here in the format code, because that just > > > > means every driver handles a different subset, with different bugs. > > > > -Daniel > > > > > > Sorry for the delay, been struggling to free some cycles to think > > > about this. > > > > > > I'm not sure how to pull this in with the tiling stuff. In the AFBC > > > case then our AFBC superblocks are always nice round numbers (256 > > > pixels), and so it does end up being a multiple of bytes. > > > > > > However, AFBC supports different superblock sizes, so picking just one > > > doesn't really work out, and putting AFBC in the core format table > > > which reflects AFBC doesn't seem good. > > > > > > We could make something up (e.g. call these formats "tiled" with 2x4 > > > tiles, which guarantees a multiple of 8), but it would be an > > > arbitrarily-selected lie, which often seems to spell trouble. If we > > > did do that, would you re-define cpp as "bytes-per-tile"? Otherwise > > > we still need to add a new field anyway. > > > > > > What's the pile of special cases you're worried about? The helper I've > > > added here means that drivers which need to care can use one API and > > > not implement their own bugs. > > > > I'm confused ... the new bits-per-pixel stuff you're adding here is for > > yuv formats, not afbc. I'm just suggesting we have only 1 way of > > describing such formats that need more descriptive power than cpp, whether > > they have some kind of pixel-groups or small tiles. > > Well, not really. The three formats which have non-integer cpp are: > DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and > DRM_FORMAT_YUV420_10BIT. These formats are only valid with non-linear > modifiers (no linear encoding is defined). Mali only supports them > with AFBC. > > The formats themselves have no notion of tiling or grouping - the > modifier adds that. I'm not aware of any non-AFBC uses of these > formats, so I don't want to "make up" a small-tile layout restriction > for them. Ah, I missed that. > > For very special stuff like afbc you need to validate in the driver > > anyway, too complicated. So I have no idea why you bring this up here? > > Sure, we can just let drivers provide their own format_info's for > these, if that's what you prefer. The core format checking code can > error out if it ever encounters them. It's format_info we're talking about. What I mean is that you just set all these to 0 and let the format_info code ignore it. And then having a bespoke drm_format_check_afbc helper function or similar, which checks all the layout restrictions of afbc. I still maintain that bpp and tile_size are equavalent, and we really don't need both. Both are defacto a form of numerator/denumerator. If you don't like that you have to introduce "fake" tiles for afbc, then we can rename tile_size to numerator and tile_h/w to denumerator_h/w. Doesn't change one bit of the math. bpp simply hardcodes a denumerator of 8, and I don't see why we need that special case. Except if you love to write redundant self tests for all the math :-) So two options that I think are reasonable: - one common numerator/denumerator. I don't care how you call that bikeshed. - don't check afbc using format_info, have your own helper that does that using custom code. Cheers, Daniel > Cheers, > -Brian > > > -Daniel > > > > > > > > Cheers, > > > -Brian > > > > > > > > > > > > --- > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++- > > > > > drivers/gpu/drm/drm_fb_helper.c | 8 +++-- > > > > > drivers/gpu/drm/drm_fourcc.c | 50 > > > > >
Re: [PATCH v2 09/23] drm/dsc: Define Rate Control values that do not change over configurations
On Tue, Jul 31, 2018 at 02:07:05PM -0700, Manasi Navare wrote:
> From: "Srivatsa, Anusha"
>
> DSC has some Rate Control values that remain constant
> across all configurations. These are as per the DSC
> standard.
>
> v3:
> * Define them in drm_dsc.h as they are
> DSC constants (Manasi)
> v2:
> * Add DP_DSC_ prefix (Jani Nikula)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Gaurav K Singh
> Cc: Harry Wentland
> Signed-off-by: Anusha Srivatsa
Tested and double checked the values with DSC spec so
Reviewed-by: Manasi Navare
> ---
> include/drm/drm_dsc.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index eda323d..ebd99d7 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -33,6 +33,12 @@
> #define DSC_MUX_WORD_SIZE_8_10_BPC 48
> #define DSC_MUX_WORD_SIZE_12_BPC 64
>
> +/* DSC Rate Control Constants */
> +#define DSC_RC_MODEL_SIZE_CONST 8192
> +#define DSC_RC_EDGE_FACTOR_CONST 6
> +#define DSC_RC_TGT_OFFSET_HI_CONST 3
> +#define DSC_RC_TGT_OFFSET_LO_CONST 3
> +
> /* Configuration for a single Rate Control model range */
> struct dsc_rc_range_parameters {
> /* Min Quantization Parameters allowed for this range */
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] gpu/radeon: use HMM mirror for userptr buffer object.
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180910]
[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/jglisse-redhat-com/Getting-rid-of-GUP-and-use-HMM-for-user-ptr-features/20180911-020741
config: x86_64-randconfig-x000-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/radeon/radeon_mn.c:43:20: error: field 'mirror' has
incomplete type
struct hmm_mirror mirror;
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_destroy':
drivers/gpu/drm/radeon/radeon_mn.c:90:2: error: implicit declaration of
function 'hmm_mirror_unregister'; did you mean 'drm_dp_aux_unregister'?
[-Werror=implicit-function-declaration]
hmm_mirror_unregister(>mirror);
^
drm_dp_aux_unregister
In file included from include/linux/firmware.h:6:0,
from drivers/gpu/drm/radeon/radeon_mn.c:31:
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mirror_release':
include/linux/kernel.h:997:32: error: dereferencing pointer to incomplete
type 'struct hmm_mirror'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~
include/linux/compiler.h:335:18: note: in definition of macro
'__compiletime_assert'
int __cond = !(condition);\
^
include/linux/compiler.h:358:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/kernel.h:997:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~
include/linux/kernel.h:997:20: note: in expansion of macro '__same_type'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~
drivers/gpu/drm/radeon/radeon_mn.c:103:26: note: in expansion of macro
'container_of'
struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
^~~~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
drivers/gpu/drm/radeon/radeon_mn.c:119:24: warning: 'struct hmm_update'
declared inside parameter list will not be visible outside of this definition
or declaration
const struct hmm_update *update)
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function
'radeon_sync_cpu_device_pagetables':
drivers/gpu/drm/radeon/radeon_mn.c:128:14: error: dereferencing pointer to
incomplete type 'const struct hmm_update'
end = update->end - 1;
^~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
drivers/gpu/drm/radeon/radeon_mn.c:183:21: error: variable
'radeon_mirror_ops' has initializer but incomplete type
static const struct hmm_mirror_ops radeon_mirror_ops = {
^~
drivers/gpu/drm/radeon/radeon_mn.c:184:3: error: 'const struct
hmm_mirror_ops' has no member named 'sync_cpu_device_pagetables'
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^~
drivers/gpu/drm/radeon/radeon_mn.c:184:32: warning: excess elements in
struct initializer
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^
drivers/gpu/drm/radeon/radeon_mn.c:184:32: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu/drm/radeon/radeon_mn.c:185:3: error: 'const struct
hmm_mirror_ops' has no member named 'release'
.release = _mirror_release,
^~~
drivers/gpu/drm/radeon/radeon_mn.c:185:13: warning: excess elements in
struct initializer
.release = _mirror_release,
^
drivers/gpu/drm/radeon/radeon_mn.c:185:13: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_get':
drivers/gpu/drm/radeon/radeon_mn.c:224:6: error: implicit declaration of
function 'hmm_mirror_register'; did you mean 'drm_dp_aux_register'?
[-Werror=implicit-function-declaration]
r = hmm_mirror_register(>mirror, mm);
^~~
drm_dp_aux_register
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_bo_map':
>> drivers/gpu/drm/radeon/radeon_mn.c:373:43: error: 'HMM_PFN_FLAG_MAX'
>> undeclare
Re: [PATCH 1/2] gpu/radeon: use HMM mirror instead of mmu_notifier
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180910]
[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/jglisse-redhat-com/Getting-rid-of-GUP-and-use-HMM-for-user-ptr-features/20180911-020741
config: i386-randconfig-s0-09101230 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu//drm/radeon/radeon_mn.c:43:20: error: field 'mirror' has
incomplete type
struct hmm_mirror mirror;
^~
drivers/gpu//drm/radeon/radeon_mn.c: In function 'radeon_mn_destroy':
>> drivers/gpu//drm/radeon/radeon_mn.c:90:2: error: implicit declaration of
>> function 'hmm_mirror_unregister' [-Werror=implicit-function-declaration]
hmm_mirror_unregister(>mirror);
^
In file included from include/linux/firmware.h:6:0,
from drivers/gpu//drm/radeon/radeon_mn.c:31:
drivers/gpu//drm/radeon/radeon_mn.c: In function 'radeon_mirror_release':
include/linux/kernel.h:997:32: error: dereferencing pointer to incomplete
type 'struct hmm_mirror'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~
include/linux/compiler.h:335:18: note: in definition of macro
'__compiletime_assert'
int __cond = !(condition);\
^
include/linux/compiler.h:358:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/kernel.h:997:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~
include/linux/kernel.h:997:20: note: in expansion of macro '__same_type'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~
drivers/gpu//drm/radeon/radeon_mn.c:103:26: note: in expansion of macro
'container_of'
struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
^~~~
drivers/gpu//drm/radeon/radeon_mn.c: At top level:
drivers/gpu//drm/radeon/radeon_mn.c:119:24: warning: 'struct hmm_update'
declared inside parameter list will not be visible outside of this definition
or declaration
const struct hmm_update *update)
^~
drivers/gpu//drm/radeon/radeon_mn.c: In function
'radeon_sync_cpu_device_pagetables':
drivers/gpu//drm/radeon/radeon_mn.c:128:14: error: dereferencing pointer to
incomplete type 'const struct hmm_update'
end = update->end - 1;
^~
drivers/gpu//drm/radeon/radeon_mn.c: At top level:
drivers/gpu//drm/radeon/radeon_mn.c:183:21: error: variable
'radeon_mirror_ops' has initializer but incomplete type
static const struct hmm_mirror_ops radeon_mirror_ops = {
^~
>> drivers/gpu//drm/radeon/radeon_mn.c:184:2: error: unknown field
>> 'sync_cpu_device_pagetables' specified in initializer
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^
drivers/gpu//drm/radeon/radeon_mn.c:184:32: warning: excess elements in
struct initializer
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^
drivers/gpu//drm/radeon/radeon_mn.c:184:32: note: (near initialization for
'radeon_mirror_ops')
>> drivers/gpu//drm/radeon/radeon_mn.c:185:2: error: unknown field 'release'
>> specified in initializer
.release = _mirror_release,
^
drivers/gpu//drm/radeon/radeon_mn.c:185:13: warning: excess elements in
struct initializer
.release = _mirror_release,
^
drivers/gpu//drm/radeon/radeon_mn.c:185:13: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu//drm/radeon/radeon_mn.c: In function 'radeon_mn_get':
>> drivers/gpu//drm/radeon/radeon_mn.c:224:6: error: implicit declaration of
>> function 'hmm_mirror_register' [-Werror=implicit-function-declaration]
r = hmm_mirror_register(>mirror, mm);
^~~
drivers/gpu//drm/radeon/radeon_mn.c: At top level:
drivers/gpu//drm/radeon/radeon_mn.c:183:36: error: storage size of
'radeon_mirror_ops' isn't known
static const struct hmm_mirror_ops radeon_mirror_ops = {
^
cc1
[Bug 201015] [amdgpu] BUG: unable to handle kernel NULL pointer dereference on resume with 2 monitors (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201015 --- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- I'd imagine you're probably running GNOME on Wayland from that setup environment. The patch seems to fix the null pointer deference but you're probably getting a black screen from those failed atomic commits. Might not be a problem with the driver but with the GNOME Wayland implementation - I would need to do more investigation to see which atomic commits are failing and if the failures are valid (but unchecked). You would probably not see this occur for GNOME over Xorg. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107891] [wine, regression, bisected] RAGE, Wolfenstein The New Order hangs in menu
https://bugs.freedesktop.org/show_bug.cgi?id=107891 Bug ID: 107891 Summary: [wine, regression, bisected] RAGE, Wolfenstein The New Order hangs in menu Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: s...@whiz.se QA Contact: dri-devel@lists.freedesktop.org The games RAGE and Wolfenstein The New Order (using Wine) hangs after a short while in the menu. Trying older Mesa releases (and a hacked Wine to work around the need for a compatibility context) 17.3.9 does not have this issue. Bisecting lead to bc65dcab3bc48673ff6180afb036561a4b8b1119 radeonsi: avoid syncing the driver thread in si_fence_finish It is really only required when we need to flush for deferred fences. It's not possibly to revert that commit cleanly on 18.2.0, but moving back "ctx = threaded_context_unwrap_sync(ctx);" to its original place is enough to get rid of the hang. -- 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 2/2] gpu/radeon: use HMM mirror for userptr buffer object.
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180910]
[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/jglisse-redhat-com/Getting-rid-of-GUP-and-use-HMM-for-user-ptr-features/20180911-020741
config: x86_64-randconfig-x017-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/radeon/radeon_mn.c:43:20: error: field 'mirror' has
incomplete type
struct hmm_mirror mirror;
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_destroy':
drivers/gpu/drm/radeon/radeon_mn.c:90:2: error: implicit declaration of
function 'hmm_mirror_unregister'; did you mean 'drm_dp_aux_unregister'?
[-Werror=implicit-function-declaration]
hmm_mirror_unregister(>mirror);
^
drm_dp_aux_unregister
In file included from include/linux/firmware.h:6:0,
from drivers/gpu/drm/radeon/radeon_mn.c:31:
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mirror_release':
include/linux/kernel.h:997:32: error: dereferencing pointer to incomplete
type 'struct hmm_mirror'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~
include/linux/compiler.h:335:18: note: in definition of macro
'__compiletime_assert'
int __cond = !(condition);\
^
include/linux/compiler.h:358:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/kernel.h:997:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~
include/linux/kernel.h:997:20: note: in expansion of macro '__same_type'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~
drivers/gpu/drm/radeon/radeon_mn.c:103:26: note: in expansion of macro
'container_of'
struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
^~~~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
drivers/gpu/drm/radeon/radeon_mn.c:119:24: warning: 'struct hmm_update'
declared inside parameter list will not be visible outside of this definition
or declaration
const struct hmm_update *update)
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function
'radeon_sync_cpu_device_pagetables':
drivers/gpu/drm/radeon/radeon_mn.c:128:14: error: dereferencing pointer to
incomplete type 'const struct hmm_update'
end = update->end - 1;
^~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
drivers/gpu/drm/radeon/radeon_mn.c:183:21: error: variable
'radeon_mirror_ops' has initializer but incomplete type
static const struct hmm_mirror_ops radeon_mirror_ops = {
^~
drivers/gpu/drm/radeon/radeon_mn.c:184:3: error: 'const struct
hmm_mirror_ops' has no member named 'sync_cpu_device_pagetables'
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^~
drivers/gpu/drm/radeon/radeon_mn.c:184:32: warning: excess elements in
struct initializer
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^
drivers/gpu/drm/radeon/radeon_mn.c:184:32: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu/drm/radeon/radeon_mn.c:185:3: error: 'const struct
hmm_mirror_ops' has no member named 'release'
.release = _mirror_release,
^~~
drivers/gpu/drm/radeon/radeon_mn.c:185:13: warning: excess elements in
struct initializer
.release = _mirror_release,
^
drivers/gpu/drm/radeon/radeon_mn.c:185:13: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_get':
drivers/gpu/drm/radeon/radeon_mn.c:224:6: error: implicit declaration of
function 'hmm_mirror_register'; did you mean 'drm_dp_aux_register'?
[-Werror=implicit-function-declaration]
r = hmm_mirror_register(>mirror, mm);
^~~
drm_dp_aux_register
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_bo_map':
>> drivers/gpu/drm/radeon/radeon_mn.c:373:43: error: 'HMM_PFN_FLAG_MAX'
>> undeclared
Re: [PATCH 1/2] gpu/radeon: use HMM mirror instead of mmu_notifier
Hi Jérôme,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180910]
[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/jglisse-redhat-com/Getting-rid-of-GUP-and-use-HMM-for-user-ptr-features/20180911-020741
config: x86_64-randconfig-x017-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
>> drivers/gpu/drm/radeon/radeon_mn.c:43:20: error: field 'mirror' has
>> incomplete type
struct hmm_mirror mirror;
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_destroy':
>> drivers/gpu/drm/radeon/radeon_mn.c:90:2: error: implicit declaration of
>> function 'hmm_mirror_unregister'; did you mean 'drm_dp_aux_unregister'?
>> [-Werror=implicit-function-declaration]
hmm_mirror_unregister(>mirror);
^
drm_dp_aux_unregister
In file included from include/linux/firmware.h:6:0,
from drivers/gpu/drm/radeon/radeon_mn.c:31:
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mirror_release':
>> include/linux/kernel.h:997:32: error: dereferencing pointer to incomplete
>> type 'struct hmm_mirror'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~
include/linux/compiler.h:335:18: note: in definition of macro
'__compiletime_assert'
int __cond = !(condition);\
^
include/linux/compiler.h:358:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/kernel.h:997:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~
include/linux/kernel.h:997:20: note: in expansion of macro '__same_type'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~
>> drivers/gpu/drm/radeon/radeon_mn.c:103:26: note: in expansion of macro
>> 'container_of'
struct radeon_mn *rmn = container_of(mirror, struct radeon_mn, mirror);
^~~~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
>> drivers/gpu/drm/radeon/radeon_mn.c:119:24: warning: 'struct hmm_update'
>> declared inside parameter list will not be visible outside of this
>> definition or declaration
const struct hmm_update *update)
^~
drivers/gpu/drm/radeon/radeon_mn.c: In function
'radeon_sync_cpu_device_pagetables':
>> drivers/gpu/drm/radeon/radeon_mn.c:128:14: error: dereferencing pointer to
>> incomplete type 'const struct hmm_update'
end = update->end - 1;
^~
drivers/gpu/drm/radeon/radeon_mn.c: At top level:
>> drivers/gpu/drm/radeon/radeon_mn.c:183:21: error: variable
>> 'radeon_mirror_ops' has initializer but incomplete type
static const struct hmm_mirror_ops radeon_mirror_ops = {
^~
>> drivers/gpu/drm/radeon/radeon_mn.c:184:3: error: 'const struct
>> hmm_mirror_ops' has no member named 'sync_cpu_device_pagetables'
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^~
>> drivers/gpu/drm/radeon/radeon_mn.c:184:32: warning: excess elements in
>> struct initializer
.sync_cpu_device_pagetables = _sync_cpu_device_pagetables,
^
drivers/gpu/drm/radeon/radeon_mn.c:184:32: note: (near initialization for
'radeon_mirror_ops')
>> drivers/gpu/drm/radeon/radeon_mn.c:185:3: error: 'const struct
>> hmm_mirror_ops' has no member named 'release'
.release = _mirror_release,
^~~
drivers/gpu/drm/radeon/radeon_mn.c:185:13: warning: excess elements in
struct initializer
.release = _mirror_release,
^
drivers/gpu/drm/radeon/radeon_mn.c:185:13: note: (near initialization for
'radeon_mirror_ops')
drivers/gpu/drm/radeon/radeon_mn.c: In function 'radeon_mn_get':
>> drivers/gpu/drm/radeon/radeon_mn.c:224:6: error: implicit declaration of
>> function 'hmm_mirror_register'; did you mean 'drm_dp_aux_register'?
>> [-Werror=implicit-function-declaration]
r = hmm_mirror_register(>mirror, mm);
^~~
[Bug 201015] [amdgpu] BUG: unable to handle kernel NULL pointer dereference on resume with 2 monitors (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201015 --- Comment #5 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- Created attachment 278427 --> https://bugzilla.kernel.org/attachment.cgi?id=278427=edit Kernel log, 2 suspend-resume attempts, second one failed (In reply to Nicholas Kazlauskas from comment #4) > Created attachment 278425 [details] > 0001-drm-amd-display-Add-null-checks-to-surface-update-in.patch > > I'm unable to reproduce the issue under Ubuntu 18.04, GNOME, 4.19 rc2 and a > Vega. > > What's your userspace setup like? Arch Linux, 4.19-rc3, GNOME 3.28.3 > > You can try the attached patch and see if that helps the problem. Try > booting with drm.debug=6 in your bootline and post the results of the > suspend with the patch. This time first suspend-resume worked fine, second one failed -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 regression fix 2/2] staging: vboxvideo: Change address of scanout buffer on page-flip
Commit 2408898e3b6c ("staging: vboxvideo: Add page-flip support") only
calls vbox_crtc_do_set_base() on page-flips, but despite that function's
name it only pins the new fb, unpins the old fb and sets
vbox_crtc->fb_offset. It does not program the hardware to scan out at the
new vbox_crtc->fb_offset value.
This was causing only every other frame (assuming page-flipping between 2
buffers) to be shown since we kept scanning out of the old (now unpinned!)
buffer.
This commit fixes this by adding code to vbox_crtc_page_flip() to tell
the hardware to scanout from the new fb_offset.
Fixes: 2408898e3b6c ("staging: vboxvideo: Add page-flip support")
Cc: Steve Longerbeam
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index a83eac8668d0..79836c8fb909 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -323,6 +323,11 @@ static int vbox_crtc_page_flip(struct drm_crtc *crtc,
if (rc)
return rc;
+ mutex_lock(>hw_mutex);
+ vbox_set_view(crtc);
+ vbox_do_modeset(crtc, >mode);
+ mutex_unlock(>hw_mutex);
+
spin_lock_irqsave(>event_lock, flags);
if (event)
--
2.19.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 regression fix 1/2] staging: vboxvideo: Fix IRQs no longer working
Commit 1daddbc8dec5 ("staging: vboxvideo: Update driver to use
drm_dev_register.") replaced the obsolere drm_get_pci_dev() with
normal pci probe and remove functions.
But the new vbox_pci_probe() is missing a pci_enable_device() call,
causing interrupts to not be delivered. This causes resizes of the
vm window to not get seen by the drm/kms code.
This commit adds the missing pci_enable_device() call, fixing this.
Fixes: 1daddbc8dec5 ("staging: vboxvideo: Update driver to use ...")
Cc: Fabio Rafael da Rosa
Cc: Nicholas Mc Guire
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index da92c493f157..69cc508af1bc 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -59,6 +59,11 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
ret = PTR_ERR(dev);
goto err_drv_alloc;
}
+
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto err_pci_enable;
+
dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
@@ -75,6 +80,8 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
err_drv_dev_register:
vbox_driver_unload(dev);
err_vbox_driver_load:
+ pci_disable_device(pdev);
+ err_pci_enable:
drm_dev_put(dev);
err_drv_alloc:
return ret;
--
2.19.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201015] [amdgpu] BUG: unable to handle kernel NULL pointer dereference on resume with 2 monitors (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201015 --- Comment #4 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Created attachment 278425 --> https://bugzilla.kernel.org/attachment.cgi?id=278425=edit 0001-drm-amd-display-Add-null-checks-to-surface-update-in.patch I'm unable to reproduce the issue under Ubuntu 18.04, GNOME, 4.19 rc2 and a Vega. What's your userspace setup like? You can try the attached patch and see if that helps the problem. Try booting with drm.debug=6 in your bootline and post the results of the suspend with the patch. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #7 from jam...@amd.com --- Dmesg shows: Found VCN firmware Version: 1.24 Family ID: 18. It is really old. Please update with latest vcn firmware for raven (1.73) https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=bd63ccb9d9dd926aa7072f416363dd8f529b5fca. -- 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 v2] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
to me, so try to clarify that with a bit of ascii graphics.
Changes since v1:
- Move the ascii graphics in the kerneldoc where all plane
properties are already documented and make sure it's properly
rendered, suggestested by Daniel Vetter.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_blend.c | 22 ++
include/uapi/drm/drm_mode.h | 3 ++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 402b62d3f072..92f75c5c93ac 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -101,6 +101,28 @@
* Without this property the rectangle is only scaled, but not rotated or
* reflected.
*
+ * Possbile values:
+ *
+ * "rotate-":
+ * Signals that a drm plane is rotated degrees in counter
+ * clockwise direction.
+ *
+ * "reflect-":
+ * Signals that the contents of a drm plane is reflected along the
+ * axis, in the same way as mirroring.
+ *
+ * reflect-x::
+ *
+ * |o || o|
+ * | | -> | |
+ * | v||v |
+ *
+ * reflect-y::
+ *
+ * |o || ^|
+ * | | -> | |
+ * | v||o |
+ *
* zpos:
* Z position is set up with drm_plane_create_zpos_immutable_property() and
* drm_plane_create_zpos_property(). It controls the visibility of
overlapping
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8d67243952f4..d3e0fe31efc5 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -186,8 +186,9 @@ extern "C" {
/*
* DRM_MODE_REFLECT_
*
- * Signals that the contents of a drm plane is reflected in the axis,
+ * Signals that the contents of a drm plane is reflected along the axis,
* in the same way as mirroring.
+ * See kerneldoc chapter "Plane Composition Properties" for more details.
*
* This define is provided as a convenience, looking up the property id
* using the name->prop id lookup is the preferred method.
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Fix crtc color management when doing suspend/resume
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problem is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the saved state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true in
drm_atomic_helper_check_modeset when at least one of gamma_lut,
degamma_lut, ctm is different between the new and the old crtc state.
All current drivers that use color_mgmt_changed, either call directly
drm_atomic_helper_check_modeset or they use drm_atomic_helper_check
which calls drm_atomic_helper_check_modeset, so this makes unnecessary
the setting of color_mgmt_changed in places where
gamma_lut/degamma_lut/ctm are set in the new crtc_state.
Changes since v2:
- Instead of setting color_mgmt_changed in commit_duplicated_set
just set it in check_modeset and clean up other place where it was
set, suggested by Maarten Lankhorst.
Changes since v3:
- Rebased v2 on top of drm-misc-next and fix conflicts introduced by
the move of drm_atomic_crtc_set_property in drm_atomic_uapi.c.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
drivers/gpu/drm/drm_atomic_uapi.c | 12 +++-
drivers/gpu/drm/drm_fb_helper.c | 1 -
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..53e60daa1bb6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -612,6 +612,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return -EINVAL;
}
+ if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
||
+ new_crtc_state->ctm != old_crtc_state->ctm ||
+ new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
changed\n",
+crtc->base.id, crtc->name);
+ new_crtc_state->color_mgmt_changed = true;
+ }
}
ret = handle_conflicting_encoders(state, false);
@@ -3948,7 +3955,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
replaced = drm_property_replace_blob(_state->degamma_lut, NULL);
replaced |= drm_property_replace_blob(_state->ctm, NULL);
replaced |= drm_property_replace_blob(_state->gamma_lut, blob);
- crtc_state->color_mgmt_changed |= replaced;
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 26690a664ec6..686da206427e 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -434,29 +434,23 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
val,
-1, sizeof(struct drm_color_lut),
);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->ctm_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
>ctm,
val,
sizeof(struct drm_color_ctm), -1,
);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->gamma_lut_property) {
- ret = drm_atomic_replace_property_blob_from_id(dev,
+ return drm_atomic_replace_property_blob_from_id(dev,
>gamma_lut,
val,
-1, sizeof(struct drm_color_lut),
);
- state->color_mgmt_changed |= replaced;
- return ret;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 73cf10adebbf..a53e169e6824 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1442,7 +1442,6 @@ static
[Bug 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 --- Comment #3 from Mauro Carvalho Chehab --- Created attachment 141511 --> https://bugs.freedesktop.org/attachment.cgi?id=141511=edit Xorg logs with Kernel 4.17.3 + drm-next patches submitted for 4.18-rc1 -- 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 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 --- Comment #2 from Mauro Carvalho Chehab --- Created attachment 141510 --> https://bugs.freedesktop.org/attachment.cgi?id=141510=edit Xorg logs with Kernel 4.18.5 -- 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 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 --- Comment #1 from Mauro Carvalho Chehab --- Created attachment 141509 --> https://bugs.freedesktop.org/attachment.cgi?id=141509=edit output of xrandr -- 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 107889] colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=107889 Bug ID: 107889 Summary: colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mche...@infradead.org Created attachment 141508 --> https://bugs.freedesktop.org/attachment.cgi?id=141508=edit Picture with the 3 monitors. The colors at the center one are wrong I have a 3 monitors setup on a NUC8i7HNK (with latest BIOS: 0049). I'm currently using Kernel 4.17 + DRM patches for 4.18-rc1. Everything works OK. However, upgrading the Kernel to 4.18.5 (kernel-4.18.5-200.fc28.x86_64) causes that the center (and default) monitor to mangle colors. The same issue also happens with upstream Kernel 4.18 vanilla. I'm enclosing a picture of what's happening there. -- 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 201067] [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 --- Comment #1 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Created attachment 278423 --> https://bugzilla.kernel.org/attachment.cgi?id=278423=edit Patch that reverts the 15% reduction in set dispclk While I can't reproduce your issue under a similar setup I think I have an idea of what the issue is. Can you try this patch? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107581] Graphics Not Rendered Due to Missing 4.5 COMPAT Profile
https://bugs.freedesktop.org/show_bug.cgi?id=107581 --- Comment #22 from Benjamin Hodgetts --- Just an FYI, testing with Mesa GIT this morning and the coloured space nebulae are being rendered correctly as well. Additionally the weird garbage/distortion below the "NEXT" notification when you first start the game has also disappeared. -- 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 v4 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
Hi Heiko,
CEC is not working when CEC 5V is enabled
On 2018-09-10 11:22, Heiko Stuebner wrote:
> The rk3328 uses a dw-hdmi controller with an external hdmi phy from
> Innosilicon which uses the generic phy framework for access.
> Add the necessary data and the compatible for the rk3328 to the
> rockchip dw-hdmi driver.
>
> Signed-off-by: Heiko Stuebner
> Tested-by: Robin Murphy
> Acked-by: Rob Herring
>
> changes in v3:
> - reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
> ---
> .../display/rockchip/dw_hdmi-rockchip.txt | 1 +
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 106 ++
> 2 files changed, 107 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> index 937bfb472e1d..39143424a474 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> @@ -13,6 +13,7 @@ Required properties:
>
> - compatible: should be one of the following:
> "rockchip,rk3288-dw-hdmi"
> + "rockchip,rk3328-dw-hdmi"
> "rockchip,rk3399-dw-hdmi"
> - reg: See dw_hdmi.txt.
> - reg-io-width: See dw_hdmi.txt. Shall be 4.
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 19f002fa0a09..237f31fd8403 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -25,6 +25,24 @@
>
> #define RK3288_GRF_SOC_CON6 0x025C
> #define RK3288_HDMI_LCDC_SEL BIT(4)
> +#define RK3328_GRF_SOC_CON2 0x0408
> +
> +#define RK3328_HDMI_SDAIN_MSKBIT(11)
> +#define RK3328_HDMI_SCLIN_MSKBIT(10)
> +#define RK3328_HDMI_HPD_IOE BIT(2)
> +#define RK3328_GRF_SOC_CON3 0x040c
> +/* need to be unset if hdmi or i2c should control voltage */
> +#define RK3328_HDMI_SDA5V_GRFBIT(15)
> +#define RK3328_HDMI_SCL5V_GRFBIT(14)
> +#define RK3328_HDMI_HPD5V_GRFBIT(13)
> +#define RK3328_HDMI_CEC5V_GRFBIT(12)
> +#define RK3328_GRF_SOC_CON4 0x0410
> +#define RK3328_HDMI_HPD_SARADC BIT(13)
> +#define RK3328_HDMI_CEC_5V BIT(11)
> +#define RK3328_HDMI_SDA_5V BIT(10)
> +#define RK3328_HDMI_SCL_5V BIT(9)
> +#define RK3328_HDMI_HPD_5V BIT(8)
> +
> #define RK3399_GRF_SOC_CON20 0x6250
> #define RK3399_HDMI_LCDC_SEL BIT(6)
>
> @@ -292,6 +310,68 @@ static const struct drm_encoder_helper_funcs
> dw_hdmi_rockchip_encoder_helper_fun
> .atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
> };
>
> +static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
> + struct drm_display_mode *mode)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> +
> + return phy_power_on(hdmi->phy);
> +}
> +
> +static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void
> *data)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> +
> + phy_power_off(hdmi->phy);
> +}
> +
> +static enum drm_connector_status
> +dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> + enum drm_connector_status status;
> +
> + status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
> +
> + if (status == connector_status_connected)
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
> + RK3328_HDMI_SCL_5V,
> + RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
> + RK3328_HDMI_SCL_5V));
This differs from BSP kernel and enable of CEC 5V stops CEC from working.
BSP kernel do not set write enable bit for CEC 5V:
RK3328_IO_5V_DOMAIN ((7 << 9) | (3 << (9 + 16)))
https://github.com/Kwiboo/linux-rockchip/commit/e74ac6a3a581bcb7b2ac9f4d70cf7298df01e417
makes CEC work on v3 of this patch.
> + else
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + HIWORD_UPDATE(0,
> + RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
> + RK3328_HDMI_SCL_5V));
> + return status;
> +}
> +
> +static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
> +{
> + struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
> +
> + dw_hdmi_phy_setup_hpd(dw_hdmi, data);
> +
> + /* Enable and map pins to 3V grf-controlled io-voltage */
> + regmap_write(hdmi->regmap,
> + RK3328_GRF_SOC_CON4,
> + HIWORD_UPDATE(0,
Re: [PATCH v3] backlight: pwm_bl: switch to using "atomic" PWM API
On Tue, 14 Aug 2018, Enric Balletbo i Serra wrote: > The "atomic" API allows us to configure PWM period and duty_cycle and > enable it in one call. > > The patch also moves the pwm_init_state just before any use of the > pwm_state struct, this fixes a potential bug where pwm_get_state > can be called before pwm_init_state. > > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v3: > - Get rid of duty_cycle variable from pwm_backlight_update_status. > - Get rid of pb->enabled and use only the status.enabled variable. > - Make power_on match power_off. > - Do not share status between ...update_status and ...power_on > > Changes in v2: > - Do not force the PWM be off in the first call to pwm_apply_state. > - Delayed applying the state until we know what the period is. > - Removed pb->period as after the conversion is not needed. > > drivers/video/backlight/pwm_bl.c | 81 +--- > 1 file changed, 42 insertions(+), 39 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] add LG panel to dpcd quirk database
Only specific N value (0x8000) would be acceptable for LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode. With the other N value, it will enter BITS mode and display black screen. This patch series set constant N value for specific sink/branch device that would cover similar issue. Cc: Jani Nikula Cc: Cooper Chiou Cc: Matt Atwood Cc: Maarten Lankhorst Cc: Dhinakaran Pandiyan Cc: Clint Taylor Lee, Shawn C (3): drm: Add support for device_id based detection. drm: Change limited M/N quirk to constant N quirk. drm: add LG eDP panel to quirk database drivers/gpu/drm/drm_dp_helper.c | 17 - drivers/gpu/drm/i915/intel_display.c | 28 +--- drivers/gpu/drm/i915/intel_display.h | 2 +- drivers/gpu/drm/i915/intel_dp.c | 8 drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++--- include/drm/drm_dp_helper.h | 6 +++--- 6 files changed, 40 insertions(+), 27 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm: Change limited M/N quirk to constant N quirk.
Some DP dongles in particular seem to be fussy about too large
link M/N values. Set specific value for N divider can resolve
this issue per dongle vendor's comment. So configure N as
constant value (0x8000) to instead of reduce M/N formula when
specific DP dongle connected.
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Matt Atwood
Cc: Maarten Lankhorst
Cc: Dhinakaran Pandiyan
Cc: Clint Taylor
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 28 +---
drivers/gpu/drm/i915/intel_display.h | 2 +-
drivers/gpu/drm/i915/intel_dp.c | 8
drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++---
include/drm/drm_dp_helper.h | 6 +++---
6 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0362c645d96e..f3a7563eb8a1 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1269,7 +1269,7 @@ struct dpcd_quirk {
static const struct dpcd_quirk dpcd_quirk_list[] = {
/* Analogix 7737 needs reduced M and N at HBR2 link rates */
- { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+ { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_CONSTANT_N) },
};
#undef OUI
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ec3e24f07486..da0c7fbef3ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6680,22 +6680,20 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
static void compute_m_n(unsigned int m, unsigned int n,
uint32_t *ret_m, uint32_t *ret_n,
- bool reduce_m_n)
+ bool constant_n)
{
/*
-* Reduce M/N as much as possible without loss in precision. Several DP
-* dongles in particular seem to be fussy about too large *link* M/N
-* values. The passed in values are more likely to have the least
-* significant bits zero than M after rounding below, so do this first.
+* Several DP dongles in particular seem to be fussy about
+* too large link M/N values. Give N value as 0x8000 that
+* should be acceptable by specific devices. 0x8000 is the
+* specified fixed N value for asynchronous clock mode,
+* which the devices expect also in synchronous clock mode.
*/
- if (reduce_m_n) {
- while ((m & 1) == 0 && (n & 1) == 0) {
- m >>= 1;
- n >>= 1;
- }
- }
+ if (constant_n)
+ *ret_n = 0x8000;
+ else
+ *ret_n = min_t(unsigned int, roundup_pow_of_two(n),
DATA_LINK_N_MAX);
- *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
*ret_m = div_u64((uint64_t) m * *ret_n, n);
intel_reduce_m_n_ratio(ret_m, ret_n);
}
@@ -6704,18 +6702,18 @@ void
intel_link_compute_m_n(int bits_per_pixel, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool reduce_m_n)
+ bool constant_n)
{
m_n->tu = 64;
compute_m_n(bits_per_pixel * pixel_clock,
link_clock * nlanes * 8,
_n->gmch_m, _n->gmch_n,
- reduce_m_n);
+ constant_n);
compute_m_n(pixel_clock, link_clock,
_n->link_m, _n->link_n,
- reduce_m_n);
+ constant_n);
}
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 43f080c6538d..8e8bd5eed2c2 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -379,7 +379,7 @@ struct intel_link_m_n {
void intel_link_compute_m_n(int bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool reduce_m_n);
+ bool constant_n);
bool is_ccs_modifier(u64 modifier);
#endif
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..6b4c19123f2a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1998,8 +1998,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(conn_state);
- bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
- DP_DPCD_QUIRK_LIMITED_M_N);
+ bool constant_n = drm_dp_has_quirk(_dp->desc,
+
[PATCH v2 3/3] drm: add LG eDP panel to quirk database
The N value was computed by kernel driver that based on synchronous clock
mode. But only specific N value (0x8000) would be acceptable for
LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
With the other N value, Tcon will enter BITS mode and display black screen.
Add this panel into quirk database and give particular N value when
calculate M/N divider.
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Matt Atwood
Cc: Maarten Lankhorst
Cc: Dhinakaran Pandiyan
Cc: Clint Taylor
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f3a7563eb8a1..67d683453f1c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1270,6 +1270,8 @@ struct dpcd_quirk {
static const struct dpcd_quirk dpcd_quirk_list[] = {
/* Analogix 7737 needs reduced M and N at HBR2 link rates */
{ OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_CONSTANT_N) },
+ /* LG LP140WF6-SPM1 eDP panel */
+ { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'),
false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
};
#undef OUI
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm: Add support for device_id based detection.
DP quirk list just compare sink or branch device's OUI so far.
That means particular vendor's products will be applied specific
change. This change would confirm device_id the same or not.
Then driver can implement some changes for branch/sink device
that really need additional WA.
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Matt Atwood
Cc: Maarten Lankhorst
Cc: Dhinakaran Pandiyan
Cc: Clint Taylor
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/drm_dp_helper.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0cccbcb2d03e..0362c645d96e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1256,15 +1256,20 @@ EXPORT_SYMBOL(drm_dp_stop_crc);
struct dpcd_quirk {
u8 oui[3];
+ u8 device_id[6];
bool is_branch;
u32 quirks;
};
#define OUI(first, second, third) { (first), (second), (third) }
+#define DEVICE_ID(first, second, third, fourth, fifth, sixth) \
+ { (first), (second), (third), (fourth), (fifth), (sixth) }
+
+#define DEVICE_ID_ANY DEVICE_ID(0, 0, 0, 0, 0, 0)
static const struct dpcd_quirk dpcd_quirk_list[] = {
/* Analogix 7737 needs reduced M and N at HBR2 link rates */
- { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
+ { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
};
#undef OUI
@@ -1283,6 +1288,7 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident,
bool is_branch)
const struct dpcd_quirk *quirk;
u32 quirks = 0;
int i;
+ u8 any_device[] = DEVICE_ID_ANY;
for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
quirk = _quirk_list[i];
@@ -1293,12 +1299,19 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident
*ident, bool is_branch)
if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
continue;
+ if (memcmp(quirk->device_id, any_device, sizeof(any_device)) !=
0 &&
+ memcmp(quirk->device_id, ident->device_id,
sizeof(ident->device_id)) != 0)
+ continue;
+
quirks |= quirk->quirks;
}
return quirks;
}
+#undef DEVICE_ID_ANY
+#undef DEVICE_ID
+
/**
* drm_dp_read_desc - read sink/branch descriptor from DPCD
* @aux: DisplayPort AUX channel
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68059] with radeon.dpm=1, Xorg crashed a while after resume
https://bugs.freedesktop.org/show_bug.cgi?id=68059 --- Comment #14 from Alex Deucher --- dpm has been enabled by default for just about all card except the original r6xx asics for years now. -- 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 04/10] phy: dphy: Add configuration helpers
Hi Maxime,
On Monday, 10 September 2018 17:16:03 EEST Maxime Ripard wrote:
> On Fri, Sep 07, 2018 at 05:26:29PM +0300, Laurent Pinchart wrote:
> + */
> +int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
> + unsigned int bpp,
> + unsigned int lanes,
> + struct
> phy_configure_opts_mipi_dphy *cfg)
> +{
> +unsigned long hs_clk_rate;
> +unsigned long ui;
> +
> +if (!cfg)
> +return -EINVAL;
> >>>
> >>> Should we really expect cfg to be NULL ?
> >>
> >> It avoids a kernel panic and it's not in a hot patch, so I'd say yes?
> >
> > A few line below you divide by the lanes parameter without checking
> > whether it is equal to 0 first, which would also cause issues.
>
> You say that like it would be a bad thing to test for this.
>
> > I believe that invalid values in input parameters should only be handled
> > explicitly when considered acceptable for the caller to pass such values.
> > In this case a NULL cfg pointer is a bug in the caller, which would get
> > noticed during development if the kernel panics.
>
> In the common case, yes. In the case where that pointer is actually
> being lost by the caller somewhere down the line and you have to wait
> for a while before it happens, then having the driver inoperant
> instead of just having a panic seems like the right thing to do.
But why would it happen in the first place ? Why would the pointer be more
likely here to be NULL than to contain, for instance, an uninitialized value,
which we don't guard against ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
Hi Ayan, On Mon, Sep 10, 2018 at 03:11:34PM +0100, Ayan Halder wrote: On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote: On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote: [snip] >unsigned int min_size; > + u8 bpp = drm_format_info_plane_bpp(fb->format, i); You might want to pass info here instead of fb->format because fb is NULL. ie drm_format_info_plane_bpp(info, i); Thanks, good catch. I have to admit I only compile-tested these. -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: udl: Destroy framebuffer only if it was initialized
On Mon, May 28, 2018 at 10:27 AM Emil Lundmark wrote:
>
> This fixes a NULL pointer dereference that can happen if the UDL
> driver is unloaded before the framebuffer is initialized. This can
> happen e.g. if the USB device is unplugged right after it was plugged
> in.
>
> As explained by Stéphane Marchesin:
>
> It happens when fbdev is disabled (which is the case for Chrome OS).
> Even though intialization of the fbdev part is optional (it's done in
> udlfb_create which is the callback for fb_probe()), the teardown isn't
> optional (udl_driver_unload -> udl_fbdev_cleanup ->
> udl_fbdev_destroy).
>
> Note that udl_fbdev_cleanup *tries* to be conditional (you can see it
> does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is
> always set during udl_fbdev_init.
>
> Suggested-by: Sean Paul
> Signed-off-by: Emil Lundmark
Many apologies, Emil, I completely dropped the ball on this one. I've
just applied it to -misc-fixes.
Sean
> ---
> Changes in v2:
> - Updated commit message with explanation from Stéphane Marchesin
>
> drivers/gpu/drm/udl/udl_fb.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 2ebdc6d5a76e..5754e37f741b 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
> {
> drm_fb_helper_unregister_fbi(>helper);
> drm_fb_helper_fini(>helper);
> - drm_framebuffer_unregister_private(>ufb.base);
> - drm_framebuffer_cleanup(>ufb.base);
> - drm_gem_object_put_unlocked(>ufb.obj->base);
> + if (ufbdev->ufb.obj) {
> + drm_framebuffer_unregister_private(>ufb.base);
> + drm_framebuffer_cleanup(>ufb.base);
> + drm_gem_object_put_unlocked(>ufb.obj->base);
> + }
> }
>
> int udl_fbdev_init(struct drm_device *dev)
> --
> 2.17.0.921.gf22659ad46-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT
On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> The R40 HDMI PHY seems to be different to the A64 one, the A64 one
> has no input mux, but the R40 one has.
>
> Drop the A64 fallback compatible from the HDMI PHY node in R40 DT.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> b/arch/arm/boot/dts/sun8i-r40.dtsi
> index ffd9f00f74a4..5f547c161baf 100644
> --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> @@ -800,8 +800,7 @@
> };
>
> hdmi_phy: hdmi-phy@1ef {
> - compatible = "allwinner,sun8i-r40-hdmi-phy",
> - "allwinner,sun50i-a64-hdmi-phy";
> + compatible = "allwinner,sun8i-r40-hdmi-phy";
If you could use the A64 phy before, you can still use it now.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] dt-bindings: sun4i-drm: drop second PLL from A64 HDMI PHY binding
On Fri, Sep 07, 2018 at 03:22:30PM +0800, Icenowy Zheng wrote: > By experiments it seems that the A64 HDMI PHY is not able to use the > second video PLL as the clock parent. > > Drop pll-1 from the device tree binding of A64 HDMI PHY. > > Signed-off-by: Icenowy Zheng > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index f8773ecb7525..62034039cee1 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -114,7 +114,6 @@ Required properties: > > H3 and A64 HDMI PHY require additional clocks: >- pll-0: parent of phy clock > - - pll-1: second possible phy clock parent (A64 only) You shouldn't need to do this. The DT is about the hardware. The fact that we haven't figured out how to use it is quite irrelevant, and can change in the future, unlike this binding. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/10] phy: Add MIPI D-PHY configuration options
On Fri, Sep 07, 2018 at 05:50:52PM +0300, Laurent Pinchart wrote: > On Friday, 7 September 2018 11:56:23 EEST Maxime Ripard wrote: > > On Wed, Sep 05, 2018 at 04:43:57PM +0300, Laurent Pinchart wrote: > > >> The current set of parameters should cover all the potential users. > > >> > > >> Signed-off-by: Maxime Ripard > > >> --- > > >> > > >> include/linux/phy/phy-mipi-dphy.h | 241 ++- > > >> include/linux/phy/phy.h | 6 +- > > >> 2 files changed, 247 insertions(+) > > >> create mode 100644 include/linux/phy/phy-mipi-dphy.h > > >> > > >> diff --git a/include/linux/phy/phy-mipi-dphy.h > > >> b/include/linux/phy/phy-mipi-dphy.h new file mode 100644 > > >> index ..792724145290 > > >> --- /dev/null > > >> +++ b/include/linux/phy/phy-mipi-dphy.h > > >> @@ -0,0 +1,241 @@ > > >> +/* SPDX-License-Identifier: GPL-2.0 */ > > >> +/* > > >> + * Copyright (C) 2018 Cadence Design Systems Inc. > > >> + */ > > >> + > > >> +#ifndef __PHY_MIPI_DPHY_H_ > > >> +#define __PHY_MIPI_DPHY_H_ > > >> + > > >> +#include > > >> + > > >> +/** > > >> + * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set > > >> + * > > >> + * This structure is used to represent the configuration state of a > > >> + * MIPI D-PHY phy. > > > > > > Shouldn't we split the RX and TX parameters in two structures ? > > > > Are they different? As far as I understood it, both were having the > > same parameters. > > clk_miss, for instance, is a receiver parameter, while clk_post is a > transmitter parameter. There are relationships between the transmitter and > receiver parameters in the sense that they have to be compatible, and we may > want to compute one set of parameters based on the other one, but I think > they > target RX and TX separately. That would require however to have to fill a structure in the consumer whose sole purpose would be to validate things in the phy framework. That looks quite weird from an API point-of-view. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] phy: dphy: Add configuration helpers
Hi,
On Fri, Sep 07, 2018 at 05:26:29PM +0300, Laurent Pinchart wrote:
> > >> + */
> > >> +int phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
> > >> + unsigned int bpp,
> > >> + unsigned int lanes,
> > >> + struct
> > >> phy_configure_opts_mipi_dphy *cfg)
> > >> +{
> > >> +unsigned long hs_clk_rate;
> > >> +unsigned long ui;
> > >> +
> > >> +if (!cfg)
> > >> +return -EINVAL;
> > >
> > > Should we really expect cfg to be NULL ?
> >
> > It avoids a kernel panic and it's not in a hot patch, so I'd say yes?
>
> A few line below you divide by the lanes parameter without checking whether
> it
> is equal to 0 first, which would also cause issues.
You say that like it would be a bad thing to test for this.
> I believe that invalid values in input parameters should only be handled
> explicitly when considered acceptable for the caller to pass such values. In
> this case a NULL cfg pointer is a bug in the caller, which would get noticed
> during development if the kernel panics.
In the common case, yes. In the case where that pointer is actually
being lost by the caller somewhere down the line and you have to wait
for a while before it happens, then having the driver inoperant
instead of just having a panic seems like the right thing to do.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Fri, Aug 31, 2018 at 10:17:30AM +0200, Daniel Vetter wrote:
> On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote:
> > Some formats have a non-integer number of bytes per pixel, which can't
> > be handled with the existing 'cpp' field in drm_format_info. To handle
> > these formats, add a 'bpp' field, which is only used if cpp[0] == 0.
> >
> > This updates all the users of format->cpp in the core DRM code,
> > converting them to use a new function to get the bits-per-pixel for any
> > format.
> >
> > It's assumed that drivers will use the 'bpp' field when they add support
> > for pixel formats with non-integer bytes-per-pixel.
> >
> > Signed-off-by: Brian Starkey
>
> I assume you still require that stuff is eventually aligned to bytes? In
> that case, can we subsume this into the tile work Alex is doing? It's
> essentially just another special case of having storage-size units
> measured in bytes which span more than 1x1 pixel. And I kinda don't want a
> metric pile of special cases here in the format code, because that just
> means every driver handles a different subset, with different bugs.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++-
> > drivers/gpu/drm/drm_fb_helper.c | 8 +++--
> > drivers/gpu/drm/drm_fourcc.c | 50
> >
> > drivers/gpu/drm/drm_framebuffer.c| 8 ++---
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +-
> > include/drm/drm_fourcc.h | 4 +++
> > 6 files changed, 70 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 186d00adfb5f..e279d70d3e60 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -118,13 +118,17 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > {
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > + u8 bpp = drm_format_info_plane_bpp(fb->format, plane);
> > +
> > + /* This can't work for non-integer bytes-per-pixel */
> > + WARN_ON(bpp % 8);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > return 0;
> >
> > paddr = obj->paddr + fb->offsets[plane];
> > - paddr += fb->format->cpp[plane] * (state->src_x >> 16);
> > + paddr += (bpp / 8) * (state->src_x >> 16);
> > paddr += fb->pitches[plane] * (state->src_y >> 16);
> >
> > return paddr;
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 0646b108030b..ab369f250af4 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1572,6 +1572,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> > *var,
> > struct drm_fb_helper *fb_helper = info->par;
> > struct drm_framebuffer *fb = fb_helper->fb;
> > int depth;
> > + u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
> >
> > if (var->pixclock != 0 || in_dbg_master())
> > return -EINVAL;
> > @@ -1580,14 +1581,14 @@ int drm_fb_helper_check_var(struct
> > fb_var_screeninfo *var,
> > * Changes struct fb_var_screeninfo are currently not pushed back
> > * to KMS, hence fail if different settings are requested.
> > */
> > - if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> > + if (var->bits_per_pixel != bpp ||
> > var->xres > fb->width || var->yres > fb->height ||
> > var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> > DRM_DEBUG("fb requested width/height/bpp can't fit in current
> > fb "
> > "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> > var->xres, var->yres, var->bits_per_pixel,
> > var->xres_virtual, var->yres_virtual,
> > - fb->width, fb->height, fb->format->cpp[0] * 8);
> > + fb->width, fb->height, bpp);
> > return -EINVAL;
> > }
> >
> > @@ -1949,11 +1950,12 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> > struct drm_fb_helper *fb_helpe
> > uint32_t fb_width, uint32_t fb_height)
> > {
> > struct drm_framebuffer *fb = fb_helper->fb;
> > + u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
> >
> > info->pseudo_palette = fb_helper->pseudo_palette;
> > info->var.xres_virtual = fb->width;
> > info->var.yres_virtual = fb->height;
> > - info->var.bits_per_pixel = fb->format->cpp[0] * 8;
> > + info->var.bits_per_pixel = bpp;
> > info->var.accel_flags = FB_ACCELF_TEXT;
> > info->var.xoffset = 0;
> > info->var.yoffset = 0;
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 3b42c25bd58d..bb28919c32f3 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -272,10 +272,60 @@ int drm_format_plane_cpp(uint32_t format, int plane)
> >
Re: Regression in drm: drm/fbdev doesn't initialize if set to triple buffer
Hi, Thanks for reporting this issue. On 08/09/2018 18:48, MOHAMMAD RASIM wrote: > Hi, > > I've an issue where the drm_meson driver doesn't work, it used to work in > earlier 4.18 release and stopped working after about 4.18-rc3. > > My board is videostrong k2 pro (S905 SoC), I use the meson-gxbb-p201 device > tree. > > on the latest 4.19 tree the board boots fine but the drm driver doesn't work, > and spits the following error in dmesg > > [ 2.489825] meson-drm d010.vpu: Queued 3 outputs on vpu > [ 2.494685] meson-drm d010.vpu: Failed to create d010.vpu debugfs > directory > [ 2.502051] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2.508668] [drm] No driver support for vblank timestamp query. > [ 2.573756] meson-drm d010.vpu: bound c883a000.hdmi-tx (ops > meson_dw_hdmi_ops) > [ 2.695917] meson-drm d010.vpu: [drm:drm_fb_helper_fbdev_setup] > *ERROR* Failed to set fbdev configuration > [ 2.700310] meson-drm d010.vpu: master bind failed: -22 > [ 2.705747] meson-drm: probe of d010.vpu failed with error -22 > > Digging deeper into the problem revealed that the problem is related to the > CONFIG_DRM_FBDEV_OVERALLOC option, If I set it to 100 or 200 it works fine > and the drm driver works ( or by passing > drm_kms_helper.drm_fbdev_overalloc=200 in the bootargs). The problem > reappears when setting it to 300. > > Bisecting shows that the first bad commit that introduced this regression is > this: 244007ecb6bb94fa4e9b9a969fa86f2ad86ec543 This commit points when the DRM driver has been switched to the generic fbdev emulation. Do you use the CONFIG_DRM_FBDEV_OVERALLOC to use the fbdev libMali ? if yes, it won't work anymore since the generic fbdev emulation does not export the fbdev smem physical address anymore. The solution is to switch to the GBM libMali and drop any fbdev legacy code. > > Another problem that I face and might be related is that the sometimes the > boot get stuck on the following lines: > > [ 2.501539] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2.508158] [drm] No driver support for vblank timestamp query. > > This problem is random and can't always reproduced, sometimes it takes a few > reboots to get the board to boot pass those lines. Weird, can you elaborate on you complete linux version, patches and HW ? > > Regards > Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107855] [regression] [amdgpu] [drm:vce_v2_0_start [amdgpu]] *ERROR* VCE not responding, giving up!!!
https://bugs.freedesktop.org/show_bug.cgi?id=107855 Pontus Gråskæg changed: What|Removed |Added CC||graaskaeg.via.forwarder@nev ||erbox.com --- Comment #11 from Pontus Gråskæg --- The new bug I have appears already to be documented: Bug 107595 -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.18.0-rc7, 4.18.5, 4.18.6, |4.18.0-rc7, 4.18.5, 4.18.6, |4.19-rc1, 4.19-rc2 |4.18.7, 4.19-rc1, 4.19-rc2, ||4.19-rc3 --- Comment #9 from Claude Heiland-Allen (cla...@mathr.co.uk) --- still an issue with 4.18.7 still an issue with 4.19-rc3 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] qxl: refactor to use drm_fb_helper_fbdev_setup
Lots of code can be removed by relying on fb-helper:
- "struct drm_framebuffer" moves to fb_helper.fb.
- "struct drm_gem_object" moves to fb_helper.obj[0].
- "struct qxl_device" can be inferred as drm_fb_helper is embedded.
- qxl_user_framebuffer_create -> drm_gem_fb_create.
- qxl_user_framebuffer_destroy -> drm_gem_fb_destroy.
- qxl_fbdev_destroy -> drm_fb_helper_fbdev_teardown + vfree(shadow).
Remove unused code:
- qxl_fbdev_qobj_is_fb, qxl_fbdev_set_suspend.
- Unused fields of qxl_fbdev: delayed_ops, delayed_ops_lock, size.
Misc notes:
- The dirty callback is preserved as it is necessary to trigger update
commands in the hw (the screen stays black otherwise).
- No idea when .create_handle in drm_framebuffer_funcs is used, but use
the same drm_gem_fb_create_handle to match drm_gem_fb_funcs.
- I don't know why qxl_fb_find_or_create_single used to check for an
existing framebuffer and removed that check to match other drivers.
- Use of drm_fb_helper_fbdev_teardown also requires "info->fbdefio" to
be dynamically allocated. Replace the existing defio config by
drm_fb_helper_defio_init to accomodate this.
Testing results: startx with fbdev, modesetting and qxl all seems to
work. Tested also with CONFIG_DRM_FBDEV_EMULATION=n, fbdev obviously
fails but others are fine. QEMU -spice and QEMU -spice with vdagent and
multiple (resized) displays (via remote-viewer) also works.
unbind vtconsole and rmmod has *not* regressed (i.e. it still trips on a
use-after-free in qxl_check_idle via qxl_ttm_fini).
Ideally setup/teardown is replaced by drm_fbdev_generic_setup as that
would result in further code reduction, improve error handling (like not
leaking shadow memory), but unfortunately QXL has no implementation for
qxl_gem_prime_vmap.
Signed-off-by: Peter Wu
---
rmmod/unbind PCI driver is still broken for both the
CONFIG_DRM_FBDEV_EMULATION=y/n cases, but hopefully this cleanup makes it easier
to prepare further fixes (if it is worth it).
---
drivers/gpu/drm/qxl/qxl_display.c | 101 +++
drivers/gpu/drm/qxl/qxl_draw.c| 6 +-
drivers/gpu/drm/qxl/qxl_drv.h | 32 +
drivers/gpu/drm/qxl/qxl_fb.c | 197 +-
4 files changed, 60 insertions(+), 276 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 01704a7f07cb..87d16a0ce01e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "qxl_drv.h"
#include "qxl_object.h"
@@ -388,17 +389,6 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
-void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
-{
- struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
- struct qxl_bo *bo = gem_to_qxl_bo(qxl_fb->obj);
-
- WARN_ON(bo->shadow);
- drm_gem_object_put_unlocked(qxl_fb->obj);
- drm_framebuffer_cleanup(fb);
- kfree(qxl_fb);
-}
-
static int qxl_framebuffer_surface_dirty(struct drm_framebuffer *fb,
struct drm_file *file_priv,
unsigned flags, unsigned color,
@@ -406,15 +396,14 @@ static int qxl_framebuffer_surface_dirty(struct
drm_framebuffer *fb,
unsigned num_clips)
{
/* TODO: vmwgfx where this was cribbed from had locking. Why? */
- struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
- struct qxl_device *qdev = qxl_fb->base.dev->dev_private;
+ struct qxl_device *qdev = fb->dev->dev_private;
struct drm_clip_rect norect;
struct qxl_bo *qobj;
int inc = 1;
drm_modeset_lock_all(fb->dev);
- qobj = gem_to_qxl_bo(qxl_fb->obj);
+ qobj = gem_to_qxl_bo(fb->obj[0]);
/* if we aren't primary surface ignore this */
if (!qobj->is_primary) {
drm_modeset_unlock_all(fb->dev);
@@ -432,7 +421,7 @@ static int qxl_framebuffer_surface_dirty(struct
drm_framebuffer *fb,
inc = 2; /* skip source rects */
}
- qxl_draw_dirty_fb(qdev, qxl_fb, qobj, flags, color,
+ qxl_draw_dirty_fb(qdev, fb, qobj, flags, color,
clips, num_clips, inc);
drm_modeset_unlock_all(fb->dev);
@@ -441,31 +430,11 @@ static int qxl_framebuffer_surface_dirty(struct
drm_framebuffer *fb,
}
static const struct drm_framebuffer_funcs qxl_fb_funcs = {
- .destroy = qxl_user_framebuffer_destroy,
+ .destroy = drm_gem_fb_destroy,
.dirty = qxl_framebuffer_surface_dirty,
-/* TODO?
- * .create_handle = qxl_user_framebuffer_create_handle, */
+ .create_handle = drm_gem_fb_create_handle,
};
-int
-qxl_framebuffer_init(struct drm_device *dev,
-struct qxl_framebuffer *qfb,
-const struct drm_mode_fb_cmd2 *mode_cmd,
-
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
Am 10.09.2018 um 15:05 schrieb Tom St Denis:
On 2018-09-10 9:04 a.m., Christian König wrote:
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Hi Christian,
Sure, if you want to send me a simple patch that adds more printk I'll
gladly give it a try (doubly so since my workstation depends on our
staging tree to work properly...).
Just add a printk to ttm_bo_bulk_move_helper to print pos->first and
pos->last.
And another one to amdgpu_bo_destroy to printk the value of tbo.
Christian.
Tom
Am 10.09.2018 um 14:59 schrieb Tom St Denis:
Hi Christian,
Are you adding new traces or turning on existing ones? Would you
like me to try them out in my setup?
Tom
On 2018-09-10 8:49 a.m., Christian König wrote:
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only
local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b,
the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos,
but it
doesn't update pos->first pointer, then we still use it during
the bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set
bulk_moveable
to false when a per VM is released" and when we use a destroyed
VM we
would see other problems as well.
If a VM instance is teared down, all BOs which belong that VM
should be
removed from LRU. But how can we submit cmd based on a destroyed
VM? You
know, we do the bulk move at last step of submission.
Well exactly that's the point this can't happen :)
Otherwise we would crash because of using freed up memory much
earlier in the command submission.
The best idea I have to track this down further is to add some
trace_printk in ttm_bo_bulk_move_helper and amdgpu_bo_destroy and
see why and when we are actually using a destroyed BO.
Christian.
Thanks,
Ray
BTW: Just pushed this commit to the repository, should show up
any second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object
*bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct
ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
On 2018-09-10 9:04 a.m., Christian König wrote:
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Hi Christian,
Sure, if you want to send me a simple patch that adds more printk I'll
gladly give it a try (doubly so since my workstation depends on our
staging tree to work properly...).
Tom
Am 10.09.2018 um 14:59 schrieb Tom St Denis:
Hi Christian,
Are you adding new traces or turning on existing ones? Would you like
me to try them out in my setup?
Tom
On 2018-09-10 8:49 a.m., Christian König wrote:
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos, but it
doesn't update pos->first pointer, then we still use it during the
bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set bulk_moveable
to false when a per VM is released" and when we use a destroyed VM we
would see other problems as well.
If a VM instance is teared down, all BOs which belong that VM should be
removed from LRU. But how can we submit cmd based on a destroyed VM?
You
know, we do the bulk move at last step of submission.
Well exactly that's the point this can't happen :)
Otherwise we would crash because of using freed up memory much
earlier in the command submission.
The best idea I have to track this down further is to add some
trace_printk in ttm_bo_bulk_move_helper and amdgpu_bo_destroy and see
why and when we are actually using a destroyed BO.
Christian.
Thanks,
Ray
BTW: Just pushed this commit to the repository, should show up any
second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct
ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
Hi Tom,
I'm talking about adding new printks to figure out what the heck is
going wrong here.
Thanks,
Christian.
Am 10.09.2018 um 14:59 schrieb Tom St Denis:
Hi Christian,
Are you adding new traces or turning on existing ones? Would you like
me to try them out in my setup?
Tom
On 2018-09-10 8:49 a.m., Christian König wrote:
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos, but it
doesn't update pos->first pointer, then we still use it during the
bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set bulk_moveable
to false when a per VM is released" and when we use a destroyed VM we
would see other problems as well.
If a VM instance is teared down, all BOs which belong that VM should be
removed from LRU. But how can we submit cmd based on a destroyed VM?
You
know, we do the bulk move at last step of submission.
Well exactly that's the point this can't happen :)
Otherwise we would crash because of using freed up memory much
earlier in the command submission.
The best idea I have to track this down further is to add some
trace_printk in ttm_bo_bulk_move_helper and amdgpu_bo_destroy and see
why and when we are actually using a destroyed BO.
Christian.
Thanks,
Ray
BTW: Just pushed this commit to the repository, should show up any
second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct
ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/20] drm/rcar-du: Use drm_fbdev_generic_setup()
Den 09.09.2018 16.13, skrev Laurent Pinchart:
Hi Noralf,
Thank you for the patch.
On Saturday, 8 September 2018 16:46:35 EEST Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Use the drm_mode_config_helper_suspend/resume helpers instead of open
coding it.
As Sam already pointed out, shouldn't this change be split to a separate patch
?
I can split it up in the next round.
Apart from that this patch looks good to me.
Reviewed-by: Laurent Pinchart
I assume you will push the entire series through drm-misc. If you'd like me to
take this patch in my tree instead please let me know.
Yes I plan to do that unless someone specifically says that they'll take
through their tree.
Noralf.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 34 ++--
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
3 files changed, 6 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 02aee6cb0e53..bcb01d7b4a89
100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -25,7 +25,9 @@
#include
#include
#include
+#include
#include
+#include
#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
@@ -316,19 +318,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
* DRM operations
*/
-static void rcar_du_lastclose(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(rcdu->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .lastclose = rcar_du_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
@@ -357,30 +351,15 @@ static struct drm_driver rcar_du_driver = {
static int rcar_du_pm_suspend(struct device *dev)
{
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
- struct drm_atomic_state *state;
- drm_kms_helper_poll_disable(rcdu->ddev);
- drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, true);
-
- state = drm_atomic_helper_suspend(rcdu->ddev);
- if (IS_ERR(state)) {
- drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
- drm_kms_helper_poll_enable(rcdu->ddev);
- return PTR_ERR(state);
- }
-
- rcdu->suspend_state = state;
-
- return 0;
+ return drm_mode_config_helper_suspend(rcdu->ddev);
}
static int rcar_du_pm_resume(struct device *dev)
{
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
- drm_atomic_helper_resume(rcdu->ddev, rcdu->suspend_state);
- drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
- drm_kms_helper_poll_enable(rcdu->ddev);
+ drm_mode_config_helper_resume(rcdu->ddev);
return 0;
}
@@ -401,9 +380,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
- if (rcdu->fbdev)
- drm_fbdev_cma_fini(rcdu->fbdev);
-
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
@@ -463,6 +439,8 @@ static int rcar_du_probe(struct platform_device *pdev)
DRM_INFO("Device %s probed\n", dev_name(>dev));
+ drm_fbdev_generic_setup(ddev, 32);
+
return 0;
error:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index b3a25e8e07d0..58d5c730d2d2
100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -24,7 +24,6 @@
struct clk;
struct device;
struct drm_device;
-struct drm_fbdev_cma;
struct rcar_du_device;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK(1 << 0) /* Per-CRTC IRQ and
clock
*/ @@ -77,8 +76,6 @@ struct rcar_du_device {
void __iomem *mmio;
struct drm_device *ddev;
- struct
Re: [PATCH 02/20] drm/arc: Use drm_fbdev_generic_setup()
Den 10.09.2018 14.31, skrev Alexey Brodkin: Hi Noralf, On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Alexey Brodkin Signed-off-by: Noralf Trønnes --- Thanks for making these improvements! Glad you like it. Funny how a simple idea can turn into 6 months of work. I'm wondering what is a base for these changes so that I may try it on my board? Preferably I'd like to get a link to the tag in your git tree with all the prerequisites in place. It's only this one patch to apply for you. I replied to the cover letter with some more context. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
Hi Christian,
Are you adding new traces or turning on existing ones? Would you like
me to try them out in my setup?
Tom
On 2018-09-10 8:49 a.m., Christian König wrote:
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos, but it
doesn't update pos->first pointer, then we still use it during the bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set bulk_moveable
to false when a per VM is released" and when we use a destroyed VM we
would see other problems as well.
If a VM instance is teared down, all BOs which belong that VM should be
removed from LRU. But how can we submit cmd based on a destroyed VM? You
know, we do the bulk move at last step of submission.
Well exactly that's the point this can't happen :)
Otherwise we would crash because of using freed up memory much earlier
in the command submission.
The best idea I have to track this down further is to add some
trace_printk in ttm_bo_bulk_move_helper and amdgpu_bo_destroy and see
why and when we are actually using a destroyed BO.
Christian.
Thanks,
Ray
BTW: Just pushed this commit to the repository, should show up any
second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct
ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/20] drm/sun4i: Use drm_fbdev_generic_setup()
Den 10.09.2018 09.28, skrev Maxime Ripard: On Sat, Sep 08, 2018 at 03:46:43PM +0200, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Maxime Ripard Signed-off-by: Noralf Trønnes It's hard to tell anything about this patch without context, but is the mali userspace still broken? I replied to the cover letter with more context. If that's the smem_start thing, then yes. This patch will block smem_start from being used by any DRM driver: drm/fb: Stop leaking physical address https://patchwork.freedesktop.org/patch/245514/ Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag
On 08/22/2018 10:54 AM, Daniel Vetter wrote: > DRM drivers really, really, really don't want random userspace to > share buffer behind it's back, bypassing the dma-buf buffer sharing > machanism. For that reason we've ruthlessly rejected any IOCTL > exposing the physical address of any graphics buffer. > > Unfortunately fbdev comes with that built-in. We could just set > smem_start to 0, but that means we'd have to hand-roll our own fb_mmap > implementation. For good reasons many drivers do that, but > smem_start/length is still super convenient. > > Hence instead just stop the leak in the ioctl, to keep fb mmap working > as-is. A second patch will set this flag for all drm drivers. > > Cc: Bartlomiej Zolnierkiewicz > Cc: Kees Cook > Cc: Daniel Vetter > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
Am 10.09.2018 um 14:05 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos, but it
doesn't update pos->first pointer, then we still use it during the bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set bulk_moveable
to false when a per VM is released" and when we use a destroyed VM we
would see other problems as well.
If a VM instance is teared down, all BOs which belong that VM should be
removed from LRU. But how can we submit cmd based on a destroyed VM? You
know, we do the bulk move at last step of submission.
Well exactly that's the point this can't happen :)
Otherwise we would crash because of using freed up memory much earlier
in the command submission.
The best idea I have to track this down further is to add some
trace_printk in ttm_bo_bulk_move_helper and amdgpu_bo_destroy and see
why and when we are actually using a destroyed BO.
Christian.
Thanks,
Ray
BTW: Just pushed this commit to the repository, should show up any second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
On 08/22/2018 10:54 AM, Daniel Vetter wrote: > This was only added for the drm's fbdev emulation support, so that it > would try harder to show the Oops. > > Unfortunately this never really worked reliably, and in practice ended > up pushing the real Oops off the screen due to plentyfull locking, > sleep-while-atomic and other issues. So we removed all that support > from the fbdev emulation a while back. Aside: We've also removed the > kgdb support, for similar reasons. > > Since it's such a small patch I figured I don't split this up into the > usual 3-phase removal. > > Cc: Ben Skeggs > Cc: Bartlomiej Zolnierkiewicz > Cc: Greg Kroah-Hartman > Cc: Hans de Goede > Cc: Daniel Vetter > Cc: Alexander Kapshuk > Cc: Kees Cook > Cc: Thierry Reding > Cc: David Lechner > Cc: nouv...@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103300] Tear rendering bug in Bioshock Infinite
https://bugs.freedesktop.org/show_bug.cgi?id=103300 --- Comment #3 from Ian Bruene --- (In reply to Timothy Arceri from comment #2) > Hi Ian, > > Is this still a problem with a recent version of Mesa? Tested with a just updated ubuntu 18.04 + padoka unstable. The problem still exists. > If so do you think you could get an apitrace [1] of the problem? > > [1] https://github.com/apitrace/apitrace/wiki/Steam Will do, later today or tomorrow. -- 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] [v3] drm/sun4i: fix build failure with CONFIG_DRM_SUN8I_MIXER=m
On 07/09/18 12:42, Maxime Ripard wrote:
> On Fri, Sep 07, 2018 at 01:26:30PM +0200, Arnd Bergmann wrote:
>> On Fri, Sep 7, 2018 at 11:41 AM Jon Hunter wrote:
>>>
>>>
>>> On 11/07/18 15:43, Arnd Bergmann wrote:
Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results
in
a link error, as we try to access a symbol from the sun8i_tcon_top.ko
module:
ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun8i-drm-hdmi.ko]
undefined!
ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-drm.ko]
undefined!
This solves the problem by adding a silent symbol for the tcon_top module,
building it as a separate module in exactly the cases that we need it,
but in a way that it is reachable by the other modules.
Fixes: 57e23de02f48 ("drm/sun4i: DW HDMI: Expand algorithm for possible
crtcs")
Fixes: ef0cf6441fbb ("drm/sun4i: Add support for traversing graph with
TCON TOP")
Signed-off-by: Arnd Bergmann
>>> I am seeing the following on today's -next (20180907) as well the last
>>> few -next versions for that matter ...
>>>
>>> ERROR: "sun8i_tcon_top_de_config" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>>> undefined!
>>> ERROR: "sun8i_tcon_top_set_hdmi_src" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>>> undefined!
>>> ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun4i-tcon.ko]
>>> undefined!
>>>
>>> Seems like this issue has cropped up again as Arnd's fix is present. I
>>> am seeing this on ARM64 builds.
>>
>> I have not started build testing on linux-next since the merge window, but
>> looking at the changes that got queued up, I find commits cf77d79b4e29
>> ("drm/sun4i: tcon: Add another way for matching mixers with tcon") and
>> 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") that both
>> introduced a reference to the tcon_top file from sun4i_tcon.c.
>>
>> More IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) checks in
>> the caller like I did in my patch would help, or alternatively one could
>> decide to give up and just always include the TCON_TOP.
>
> Sorry for the breakage.
>
> Can you test:
>
> 8<
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 4834c90b4912..c78cd35a1294 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -974,7 +974,8 @@ static bool sun4i_tcon_connected_to_tcon_top(struct
> device_node *node)
>
> remote = of_graph_get_remote_node(node, 0, -1);
> if (remote) {
> - ret = !!of_match_node(sun8i_tcon_top_of_table, remote);
> + ret = !!(IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
> + of_match_node(sun8i_tcon_top_of_table, remote));
> of_node_put(remote);
> }
>
> @@ -1402,13 +1403,20 @@ static int sun8i_r40_tcon_tv_set_mux(struct
> sun4i_tcon *tcon,
> if (!pdev)
> return -EINVAL;
>
> - if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
> + if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
> + encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
> ret = sun8i_tcon_top_set_hdmi_src(>dev, id);
> if (ret)
> return ret;
> }
>
> - return sun8i_tcon_top_de_config(>dev, tcon->id, id);
> + if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP)) {
> + ret = sun8i_tcon_top_de_config(>dev, tcon->id, id);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> }
>
> static const struct sun4i_tcon_quirks sun4i_a10_quirks = {
> 8<
Yes works for me! Thanks, Jon
--
nvpublic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] Add support for Arm Framebuffer Compression(AFBC)
On Sun, Sep 09, 2018 at 02:03:57PM +0200, Daniel Vetter wrote: > On Sat, Sep 08, 2018 at 03:58:53PM +0200, Neil Armstrong wrote: > > Hi Ayan, > > > > On 10/07/2018 15:18, Ayan Kumar Halder wrote: > > > In the current series of patches, we are trying to add support for AFBC > > > modifiers in malidp. AFBC modifiers adds some constraints to framebuffer > > > size, alignment, pitch, formats, etc. Here we are trying to add support > > > for one combination of AFBC modifier ie AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | > > > AFBC_FORMAT_MOD_SPARSE | AFBC_FORMAT_MOD_YTR. > > > In future, we intend to add support for more combination of AFBC > > > modifiers. > > > Currently, we are trying to enable a basic support of AFBC in malidp. > > > > Thanks for pushing AFBC support, this will help supporting it on other SoCs > > implementing support > > like Amlogic, Rockchip or Samsung. > > > > I have one question, is there a way to generate such AFBC buffers without > > the Mali GPU ? > > I mean, is there a way to generate some sample buffers with some of the > > modifier features > > to validate it without having the complete Mali GPU -> DRM chain ? > > An igt would be perfect. We've done that for i915 compressed buffers. Note > that it just needs to be an afbc buffer, not actually compressed. Setting > all the bits to indicate "uncompressed" for each block is what we did for > the i915 test. Actually no. The i915 test does try to put some compressed data into the buffer. I have also a pending patch series [1] that allows us to render to compressed buffers with cairo by compressing the results using the GPU. [1] https://patchwork.freedesktop.org/series/46876/ -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
Hello, On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote: > Hi Pavel, > > (dropping Dave, no need to spam him) > > On 30/08/18 12:04, Pavel Machek wrote: > > Hi! > > > > There's neat series of patches on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/ > > ?h=droid4-pending-v4.19 > > > > They enable display support for my hardware. As you can imagine, > > display is rather important for a cellphone. > > > > Tomi, can you take the patches? I can resubmit them in email, or > > shuffle them to another branch without mfd changes, or clean them up > > etc... > > A large omapdrm change set from Laurent was merged into drm-next, and > I'm certain they conflict with this series. Laurent also has continued > that work, and while those new patches haven't been sent for review yet, > I fear they'll also conflict with these. > > So in the minimum, a rebase on top of drm-next is needed. > > I also continue to be very worried that adding DSI support to omapdrm at > this stage will be a huge extra burden for Laurent's work. > > We should transform the panel-dsi-cm.c towards the common DRM model. > With a quick look, there seems to be a driver for Samsung's S6E63J0X03 > panel. So possibly all the DSI features are there in the DRM framework, > but someone needs to check that and start working on panel-dsi-cm.c so > that it's ready when we finally switch to the DRM model. > > In my opinion, which I've also expressed before, the above work is much > easier to do by first changing the omapdrm to DRM model, without any DSI > displays, and then add the DSI command mode support. But if people > insist on adding the DSI support already now, I would appreciate the > same people working on the DSI support so that Laurent doesn't have to > do it all. I want to make it clear that I don't want to claim any privilege in getting patches merged first. I am however worried that, without an easy way to test DSI support, and without enough time to focus on it, I would break whatever would be merged now in future reworks. I would thus like to find out how to collaborate on this task, hopefully to move towards usage of drm_bridge and drm_panel for DSI-based pipelines. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] Add udmabuf misc device
Hi Gerd,
Thank you for the patch.
CC'ing the linux-api mailing list as this creates a new userspace API.
On Monday, 27 August 2018 12:34:44 EEST Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287 +++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
[snip]
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
Where's the documentation ? :-)
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Could you please keep the #include alphabetically sorted ? It helps locating
duplicates.
> +#include
I think you can just #include , no need to use the uapi/
prefix.
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
Just curious, when do you expect this to happen ?
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
You can return ERR_PTR(-ENOMEM) directly.
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
Shouldn't you propagate the return value from sg_alloc_table_from_pages() ?
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> + goto err3;
> +
> + return sg;
> +
> +err3:
> + sg_free_table(sg);
> +err2:
> + kfree(sg);
> +err1:
> + return ERR_PTR(-ENOMEM);
You can merge
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
> Am 10.09.2018 um 11:23 schrieb Huang Rui:
> > On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
> >> Hi Ray,
> >>
> >> well those patches doesn't make sense, the pointer is only local to
> >> the function.
> > You're right.
> > I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
> > use-after-free should be in below codes:
> >
> > man = >tt[i].first->bdev->man[TTM_PL_TT];
> > ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
> >
> > Is there a case, when orignal bo is destroyed in the bulk pos, but it
> > doesn't update pos->first pointer, then we still use it during the bulk
> > moving?
>
> Only when a per VM BO is freed or the VM destroyed.
>
> The first case should now be handled by "drm/amdgpu: set bulk_moveable
> to false when a per VM is released" and when we use a destroyed VM we
> would see other problems as well.
>
If a VM instance is teared down, all BOs which belong that VM should be
removed from LRU. But how can we submit cmd based on a destroyed VM? You
know, we do the bulk move at last step of submission.
Thanks,
Ray
> BTW: Just pushed this commit to the repository, should show up any second.
>
> Christian.
>
> >
> > Thanks,
> > Ray
> >
> >> Regards,
> >> Christian.
> >>
> >> Am 10.09.2018 um 10:57 schrieb Huang Rui:
> >>> It avoids to be refered again after freed.
> >>>
> >>> Signed-off-by: Huang Rui
> >>> Cc: Christian König
> >>> Cc: Tom StDenis
> >>> ---
> >>> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> index 138c989..d3ef5f8 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> @@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
> >>> static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
> >>> {
> >>> kfree(bo);
> >>> + bo = NULL;
> >>> }
> >>> static inline int ttm_mem_type_from_place(const struct ttm_place *place,
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: Add new DIRTY fb flags to pass interlaced alternate fields
On Fri, Sep 07, 2018 at 02:46:21PM -0700, Satish Kumar Nagireddy wrote:
> The requirement is to render interlaced alternate buffers. In case of
> alternate, top field and bottom field are in two different buffers.
>
> The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
> and DRM_MODE_PRESENT_TOP_FIELD to DRM_IOCTL_MODE_SETPLANE ioctl?
The original idea with those flags was bob deinterlacing type of stuff.
For fbs with non-interleaved fields I think we'd have to extend addfb
somewhat to allow passing a separate buffer for each field. The problem
with that is that we only have 4 buffers in addfb, so we'd run out for
three plane formats. So we'd have to increase the number of buffers in
addfb, or add some kind of implicit assumption on how the fields are
stored in the single bo (which I presume might not even be possible on
some crazy hardware).
> But in case if urrent frame out of display range, application
> will invoke DRM_IOCTL_MODE_PAGE_FLIP ioctl. So, it is not guaranteed
> that application will always call setplane(), it may also call page_flip().
> Then we will have to introduce two more flags to pass with page_flip()
> ioctl, which is complicating things.
>
> Background of DRM_IOCTL_MODE_DIRTYFB ioctl: This ioctl is defined, so
> that userspace can notify the driver that an area of framebuffer has
> changed and should be flushed to display hardware.
>
> The proposed solution is to introduce new dirty fb flags, so that userspace
> can pass them with every alternate field buffer and the same is reached
> display hardware. This patch adds new dirty framebuffer flags, so that
> application can pass interlaced alternate field information to driver.
>
> Signed-off-by: Satish Kumar Nagireddy
> ---
> include/uapi/drm/drm_mode.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2..40fef85 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -428,7 +428,9 @@ struct drm_mode_fb_cmd2 {
>
> #define DRM_MODE_FB_DIRTY_ANNOTATE_COPY 0x01
> #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
> -#define DRM_MODE_FB_DIRTY_FLAGS 0x03
> +#define DRM_MODE_FB_DIRTY_TOP_FIELD 0x03
> +#define DRM_MODE_FB_DIRTY_BOTTOM_FIELD 0x04
> +#define DRM_MODE_FB_DIRTY_FLAGS 0x07
>
> #define DRM_MODE_FB_DIRTY_MAX_CLIPS 256
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omap4: support for manually updated display
Hi Pavel, (dropping Dave, no need to spam him) On 30/08/18 12:04, Pavel Machek wrote: > Hi! > > There's neat series of patches on > > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19 > > They enable display support for my hardware. As you can imagine, > display is rather important for a cellphone. > > Tomi, can you take the patches? I can resubmit them in email, or > shuffle them to another branch without mfd changes, or clean them up > etc... A large omapdrm change set from Laurent was merged into drm-next, and I'm certain they conflict with this series. Laurent also has continued that work, and while those new patches haven't been sent for review yet, I fear they'll also conflict with these. So in the minimum, a rebase on top of drm-next is needed. I also continue to be very worried that adding DSI support to omapdrm at this stage will be a huge extra burden for Laurent's work. We should transform the panel-dsi-cm.c towards the common DRM model. With a quick look, there seems to be a driver for Samsung's S6E63J0X03 panel. So possibly all the DSI features are there in the DRM framework, but someone needs to check that and start working on panel-dsi-cm.c so that it's ready when we finally switch to the DRM model. In my opinion, which I've also expressed before, the above work is much easier to do by first changing the omapdrm to DRM model, without any DSI displays, and then add the DSI command mode support. But if people insist on adding the DSI support already now, I would appreciate the same people working on the DSI support so that Laurent doesn't have to do it all. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
On Mon, Sep 10, 2018 at 05:25:48PM +0800, Koenig, Christian wrote:
> Am 10.09.2018 um 11:23 schrieb Huang Rui:
> > On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
> >> Hi Ray,
> >>
> >> well those patches doesn't make sense, the pointer is only local to
> >> the function.
> > You're right.
> > I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
> > use-after-free should be in below codes:
> >
> > man = >tt[i].first->bdev->man[TTM_PL_TT];
> > ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
> >
> > Is there a case, when orignal bo is destroyed in the bulk pos, but it
> > doesn't update pos->first pointer, then we still use it during the bulk
> > moving?
>
> Only when a per VM BO is freed or the VM destroyed.
>
> The first case should now be handled by "drm/amdgpu: set bulk_moveable
> to false when a per VM is released" and when we use a destroyed VM we
> would see other problems as well.
When a VM instance is teared down, all BOs which belong to that VM should
be removed from LRU list. How can we use a destroyed VM when we submmit a
command? You know, we do the bulk moving at the last step of submission.
>
> BTW: Just pushed this commit to the repository, should show up any second.
I see, thanks.
Thanks,
Ray
>
> Christian.
>
> >
> > Thanks,
> > Ray
> >
> >> Regards,
> >> Christian.
> >>
> >> Am 10.09.2018 um 10:57 schrieb Huang Rui:
> >>> It avoids to be refered again after freed.
> >>>
> >>> Signed-off-by: Huang Rui
> >>> Cc: Christian König
> >>> Cc: Tom StDenis
> >>> ---
> >>> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> index 138c989..d3ef5f8 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>> @@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
> >>> static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
> >>> {
> >>> kfree(bo);
> >>> + bo = NULL;
> >>> }
> >>> static inline int ttm_mem_type_from_place(const struct ttm_place *place,
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: add LG eDP panel to quirk database
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> The N value was computed by kernel driver that based on synchronous clock
> mode. But only specific N value (0x8000) would be acceptable for
> LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
> With the other N value, Tcon will enter BITS mode and display black screen.
> Add this panel into quirk database and give particular N value when
> calculate M/N divider.
>
> Cc: Jani Nikula
> Cc: Cooper Chiou
> Cc: Matt Atwood
> Cc: Maarten Lankhorst
> Cc: Dhinakaran Pandiyan
> Cc: Clint Taylor
> Signed-off-by: Lee, Shawn C
No access to the panel or its details, so instead of review,
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index d0c1250975ab..0ef7c43a9025 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1270,6 +1270,8 @@ struct dpcd_quirk {
> static const struct dpcd_quirk dpcd_quirk_list[] = {
> /* Analogix 7737 needs reduced M and N at HBR2 link rates */
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> + /* LG LP140WF6-SPM1 eDP panel */
> + { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'),
> false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> };
>
> #undef OUI
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: Change limited M/N quirk to constant N quirk.
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> Some DP dongles in particular seem to be fussy about too large
> link M/N values. Set specific value for N divider can resolve
> this issue per dongle vendor's comment. So configure N as
> constant value (0x8000) to instead of reduce M/N formula when
> specific DP dongle connected.
>
> Cc: Jani Nikula
> Cc: Cooper Chiou
> Cc: Matt Atwood
> Cc: Maarten Lankhorst
> Cc: Dhinakaran Pandiyan
> Cc: Clint Taylor
> Signed-off-by: Lee, Shawn C
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 26 +++---
> drivers/gpu/drm/i915/intel_display.h | 2 +-
> drivers/gpu/drm/i915/intel_dp.c | 8
> drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++---
> include/drm/drm_dp_helper.h | 6 +++---
> 6 files changed, 23 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 22753928af41..d0c1250975ab 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1269,7 +1269,7 @@ struct dpcd_quirk {
>
> static const struct dpcd_quirk dpcd_quirk_list[] = {
> /* Analogix 7737 needs reduced M and N at HBR2 link rates */
> - { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
> + { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ec3e24f07486..b26f4ae60810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6680,22 +6680,18 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
>
> static void compute_m_n(unsigned int m, unsigned int n,
> uint32_t *ret_m, uint32_t *ret_n,
> - bool reduce_m_n)
> + bool constant_n)
> {
> /*
> - * Reduce M/N as much as possible without loss in precision. Several DP
> - * dongles in particular seem to be fussy about too large *link* M/N
> - * values. The passed in values are more likely to have the least
> - * significant bits zero than M after rounding below, so do this first.
> + * Several DP dongles in particular seem to be fussy about
> + * too large *link* M/N * values. Give N value as 0x8000
^
Extra *.
> + * that should be acceptable by specific devices.
Please also add something like:
0x8000 is the specified fixed N value for asynchronous clock
mode, which the devices expect also in synchronous clock mode.
>*/
> - if (reduce_m_n) {
> - while ((m & 1) == 0 && (n & 1) == 0) {
> - m >>= 1;
> - n >>= 1;
> - }
> - }
> + if (constant_n)
> + *ret_n = 0x8000;
> + else
> + *ret_n = min_t(unsigned int, roundup_pow_of_two(n),
> DATA_LINK_N_MAX);
>
> - *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
> *ret_m = div_u64((uint64_t) m * *ret_n, n);
> intel_reduce_m_n_ratio(ret_m, ret_n);
> }
> @@ -6704,18 +6700,18 @@ void
> intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> -bool reduce_m_n)
> +bool constant_n)
> {
> m_n->tu = 64;
>
> compute_m_n(bits_per_pixel * pixel_clock,
> link_clock * nlanes * 8,
> _n->gmch_m, _n->gmch_n,
> - reduce_m_n);
> + constant_n);
>
> compute_m_n(pixel_clock, link_clock,
> _n->link_m, _n->link_n,
> - reduce_m_n);
> + constant_n);
> }
>
> static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 43f080c6538d..8e8bd5eed2c2 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -379,7 +379,7 @@ struct intel_link_m_n {
> void intel_link_compute_m_n(int bpp, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> - bool reduce_m_n);
> + bool constant_n);
>
> bool is_ccs_modifier(u64 modifier);
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..fce4be57ccc9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1998,8 +1998,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> struct intel_digital_connector_state
Re: [PATCH 1/3] drm: Add support for device_id based detection.
On Mon, 10 Sep 2018, "Lee, Shawn C" wrote:
> DP quirk list just compare sink or branch device's OUI so far.
> That means particular vendor's products will be applied specific
> change. This change would confirm device_id the same or not.
> Then driver can implement some changes for branch/sink device
> that really need additional WA.
>
> Cc: Jani Nikula
> Cc: Cooper Chiou
> Cc: Matt Atwood
> Cc: Maarten Lankhorst
> Cc: Dhinakaran Pandiyan
> Cc: Clint Taylor
> Signed-off-by: Lee, Shawn C
> ---
> drivers/gpu/drm/drm_dp_helper.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 0cccbcb2d03e..22753928af41 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1256,15 +1256,20 @@ EXPORT_SYMBOL(drm_dp_stop_crc);
>
> struct dpcd_quirk {
> u8 oui[3];
> + u8 device_id[6];
> bool is_branch;
> u32 quirks;
> };
>
> #define OUI(first, second, third) { (first), (second), (third) }
> +#define DEVICE_ID(first, second, third, fourth, fifth, sixth) \
> + { (first), (second), (third), (fourth), (fifth), (sixth) }
> +
> +#define DEVICE_ID_ANYDEVICE_ID(0, 0, 0, 0, 0, 0)
>
> static const struct dpcd_quirk dpcd_quirk_list[] = {
> /* Analogix 7737 needs reduced M and N at HBR2 link rates */
> - { OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
> + { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
> };
>
> #undef OUI
> @@ -1283,6 +1288,7 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident
> *ident, bool is_branch)
> const struct dpcd_quirk *quirk;
> u32 quirks = 0;
> int i;
> + u8 any_device[6] = DEVICE_ID_ANY;
Please make that any_device[] without the size.
>
> for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
> quirk = _quirk_list[i];
> @@ -1293,12 +1299,19 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident
> *ident, bool is_branch)
> if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
> continue;
>
> + if (memcmp(quirk->device_id, any_device, 6) != 0 &&
> + memcmp(quirk->device_id, ident->device_id, 6) != 0)
Please use sizeof instead of hard coded 6.
With those changes,
Reviewed-by: Jani Nikula
> + continue;
> +
> quirks |= quirk->quirks;
> }
>
> return quirks;
> }
>
> +#undef DEVICE_ID_ANY
> +#undef DEVICE_ID
> +
> /**
> * drm_dp_read_desc - read sink/branch descriptor from DPCD
> * @aux: DisplayPort AUX channel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 Marvin Damschen changed: What|Removed |Added Attachment #141500|0 |1 is obsolete|| --- Comment #6 from Marvin Damschen --- Created attachment 141503 --> https://bugs.freedesktop.org/attachment.cgi?id=141503=edit 4.19-rc3 with amdgpu.ip_block_mask=0xff -- 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 xf86-video-amdgpu] Add checking color management properties
Add gamma_lut/degamma_lut/ctm checking before pushing
staged color management properties on the CRTC.
If above object is NULL, return directly.
Signed-off-by: Aaron Liu
---
src/drmmode_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 68fca1b..006ae7c 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1116,6 +1116,11 @@ static int drmmode_crtc_push_cm_prop(xf86CrtcPtr crtc,
switch (cm_prop_index) {
case CM_GAMMA_LUT:
+ if (!drmmode_crtc->gamma_lut) {
+ xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING,
+ "gamma_lut is NULL!\n");
+ return BadRequest;
+ }
/* Calculate the expected size of value in bytes */
expected_bytes = sizeof(struct drm_color_lut) *
drmmode->gamma_lut_size;
@@ -1154,11 +1159,21 @@ static int drmmode_crtc_push_cm_prop(xf86CrtcPtr crtc,
}
break;
case CM_DEGAMMA_LUT:
+ if (!drmmode_crtc->degamma_lut) {
+ xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING,
+ "degamma_lut is NULL!\n");
+ return BadRequest;
+ }
expected_bytes = sizeof(struct drm_color_lut) *
drmmode->degamma_lut_size;
blob_data = drmmode_crtc->degamma_lut;
break;
case CM_CTM:
+ if (!drmmode_crtc->ctm) {
+ xf86DrvMsg(crtc->scrn->scrnIndex, X_WARNING,
+ "ctm is NULL!\n");
+ return BadRequest;
+ }
expected_bytes = sizeof(struct drm_color_ctm);
blob_data = drmmode_crtc->ctm;
break;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #5 from Marvin Damschen --- (In reply to Michel Dänzer from comment #4) > Looks like there may be an issue with the VCN microcode loading. Does > > amdgpu.ip_block_mask=0xff > > on the kernel command line avoid the problem? It does! dmesg contains a lot of call traces though (I will attach). > Can you bisect? I can, but will probably find time by the end of the week only. Thank you Marvin -- 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 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 Pontus Gråskæg changed: What|Removed |Added CC||graaskaeg.via.forwarder@nev ||erbox.com --- Comment #11 from Pontus Gråskæg --- I appear to be experiencing the same bug. Same set of internal and external connectors. My hardware is Lenovo G75 A10-7300 [Kaveri] Kernel booted with - amdgpu.cik_support=1 - radeon.cik_support=0 - amdgpu.dc=1 - drm.debug=1 The internal (eDP) display fails to work. The VGA display doesn't work either (as expected), and I can't comment on the HDMI as I don't have an HDMI monitor. Used ssh to get in and copy the dmesg buffer. I do not have the capability to compile kernel+patches. Sorry. graaskaeg [1.963843] [drm] radeon kernel modesetting enabled. [1.965577] checking generic (e000 7f) vs hw (e000 1000) [1.965579] fb: switching to radeondrmfb from EFI VGA [1.967248] Console: switching to colour dummy device 80x25 [1.967463] [drm:drm_get_pci_dev [drm]] [1.967928] [drm:drm_minor_register [drm]] [1.968070] [drm:drm_minor_register [drm]] new minor registered 128 [1.968084] [drm:drm_minor_register [drm]] [1.968157] [drm:drm_minor_register [drm]] new minor registered 0 [1.968163] radeon :00:01.0: CIK support disabled by module param [2.019315] [drm] amdgpu kernel modesetting enabled. [2.022536] AMD IOMMUv2 driver by Joerg Roedel [2.022542] AMD IOMMUv2 functionality not available on this system [2.027931] CRAT table not found [2.027941] Virtual CRAT table created for CPU [2.027944] Parsing CRAT table with 1 nodes [2.027948] Creating topology SYSFS entries [2.027967] Topology: Add CPU node [2.027970] Finished initializing topology [2.028045] kfd kfd: Initialized module [2.028770] [drm:drm_minor_register [drm]] [2.028930] [drm:drm_minor_register [drm]] new minor registered 128 [2.028939] [drm:drm_minor_register [drm]] [2.029042] [drm:drm_minor_register [drm]] new minor registered 0 [2.029066] [drm] initializing kernel modesetting (KAVERI 0x1002:0x130A 0x17AA:0x3988 0x00). [2.068203] [drm] register mmio base: 0xF0B0 [2.068212] [drm] register mmio size: 262144 [2.068221] [drm] add ip block number 0 [2.068225] [drm] add ip block number 1 [2.068227] [drm] add ip block number 2 [2.068229] [drm] add ip block number 3 [2.068232] [drm] add ip block number 4 [2.068234] [drm] add ip block number 5 [2.068237] [drm] add ip block number 6 [2.068239] [drm] add ip block number 7 [2.068241] [drm] add ip block number 8 [2.093099] [drm] BIOS signature incorrect 0 0 [2.093117] resource sanity check: requesting [mem 0x000c-0x000d], which spans more than PCI Bus :00 [mem 0x000c-0x000c3fff window] [2.093126] caller pci_map_rom+0x71/0x1c0 mapping multiple BARs [2.093295] [drm:check_atom_bios [amdgpu]] ATOMBIOS detected [2.093299] ATOM BIOS: 113-SPEC-X24 [2.093354] [drm:amdgpu_atombios_init [amdgpu]] atom firmware requested 000fffe0 32kb [2.093419] [drm:amdgpu_atombios_get_clock_info [amdgpu]] Changing default dispclk from 514Mhz to 600Mhz [2.093453] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit [2.093611] [drm:gmc_v7_0_sw_init [amdgpu]] [2.093619] amdgpu :00:01.0: VRAM: 1024M 0x00F4 - 0x00F43FFF (1024M used) [2.093625] amdgpu :00:01.0: GART: 1024M 0x - 0x3FFF [2.093636] [drm] Detected VRAM RAM=1024M, BAR=1024M [2.093639] [drm] RAM width 64bits UNKNOWN [2.093950] [TTM] Zone kernel: Available graphics memory: 3531364 kiB [2.093958] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [2.093961] [TTM] Initializing pool allocator [2.093975] [TTM] Initializing DMA pool allocator [2.094057] [drm] amdgpu: 1024M of VRAM memory ready [2.094061] [drm] amdgpu: 3072M of GTT memory ready. [2.094081] [drm] GART: num cpu pages 262144, num gpu pages 262144 [2.094120] [drm] PCIE GART of 1024M enabled (table at 0x00F4007E9000). [2.094242] [drm:drm_irq_install [drm]] irq=35 [2.094387] [drm:amdgpu_irq_init [amdgpu]] amdgpu: irq initialized. [2.094398] [drm] Internal thermal controller without fan control [2.094402] [drm] amdgpu: dpm initialized [2.094468] [drm:gfx_v7_0_sw_init [amdgpu]] [2.095601] [drm:cik_sdma_sw_init [amdgpu]] [2.095932] [drm] Found UVD firmware Version: 1.55 Family ID: 9 [2.096349] [drm] Found VCE firmware Version: 50.10 Binary ID: 2 [2.098025] usb 1-4: New USB device found, idVendor=050d, idProduct=0307, bcdDevice= 0.00 [2.098037] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [2.098328] hub 1-4:1.0:
[Bug 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #4 from Michel Dänzer --- Looks like there may be an issue with the VCN microcode loading. Does amdgpu.ip_block_mask=0xff on the kernel command line avoid the problem? Can you bisect? -- 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 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #3 from Marvin Damschen --- Created attachment 141502 --> https://bugs.freedesktop.org/attachment.cgi?id=141502=edit Modprobe amdgpu freezes video output with 4.19-rc3 -- 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 107880] Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
https://bugs.freedesktop.org/show_bug.cgi?id=107880 --- Comment #2 from Marvin Damschen --- (In reply to Michel Dänzer from comment #1) > (In reply to Marvin Damschen from comment #0) > > System hangs after "fb: switching to amdgpudrmfb from EFI VGA". > > How long have you waited for? E.g. if a microcode file is missing, the > attempt to load it can hang for one or several minutes before timing out. Waited for ~5min now, but nothing changed. > > I am unable to obtain any logs of the crash (LUKS encryption might be the > > reason?). > > One possibility is to prevent the driver from loading by passing > > modprobe.blacklist=amdgpu > > on the kernel command line, then you can try manually loading it with > > sudo modprobe amdgpu > > and should get the full dmesg output. Thank you, this worked. Full output is attached, but appears fine. Still, the video output freezes. -- 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 107855] [regression] [amdgpu] [drm:vce_v2_0_start [amdgpu]] *ERROR* VCE not responding, giving up!!!
https://bugs.freedesktop.org/show_bug.cgi?id=107855 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Michel Dänzer --- Makes sense, thanks. -- 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 107855] [regression] [amdgpu] [drm:vce_v2_0_start [amdgpu]] *ERROR* VCE not responding, giving up!!!
https://bugs.freedesktop.org/show_bug.cgi?id=107855 --- Comment #9 from Pontus Gråskæg --- Just to be clear, booting with kernel 4.19rc2 does indeed remove the "*ERROR* VCE not responding, giving up!!!" and associated messages. So that can be marked solved (I think). However, there is still a regression in behaviour, but I'll raise a separate bug for that, as it appears to be a different issue. graaskaeg -- 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/tilcdc: Convert drm_atomic_helper_suspend/resume()
On Mon, Sep 10, 2018 at 1:11 PM Jyri Sarha wrote:
>
> On 10/09/18 09:45, Souptick Joarder wrote:
> > On Wed, Aug 8, 2018 at 9:43 PM Souptick Joarder
> > wrote:
> >>
> >> convert drm_atomic_helper_suspend/resume() to use
> >> drm_mode_config_helper_suspend/resume().
> >>
> >> saved_state in tilcdc_drm_private will not be used
> >> anymore, so it can be removed.
> >
> > Any comment on this patch ?
>
> I planned to test this out, but I did not find time to do that. But here
> is my:
>
> Reviewed-by: Jyri Sarha
>
> I'll pick this up for my next pull request.
>
Thanks, Hopefully It will make into 4.20 :)
> BR,
> Jyri
>
> >>
> >> Signed-off-by: Ajit Negi
> >> Signed-off-by: Souptick Joarder
> >> ---
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 14 --
> >> drivers/gpu/drm/tilcdc/tilcdc_drv.h | 3 ---
> >> 2 files changed, 4 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >> index 0fb300d..33e5332 100644
> >> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> >> @@ -554,29 +554,23 @@ static int tilcdc_debugfs_init(struct drm_minor
> >> *minor)
> >> static int tilcdc_pm_suspend(struct device *dev)
> >> {
> >> struct drm_device *ddev = dev_get_drvdata(dev);
> >> - struct tilcdc_drm_private *priv = ddev->dev_private;
> >> + int ret = 0;
> >>
> >> - priv->saved_state = drm_atomic_helper_suspend(ddev);
> >> + ret = drm_mode_config_helper_suspend(ddev);
> >>
> >> /* Select sleep pin state */
> >> pinctrl_pm_select_sleep_state(dev);
> >>
> >> - return 0;
> >> + return ret;
> >> }
> >>
> >> static int tilcdc_pm_resume(struct device *dev)
> >> {
> >> struct drm_device *ddev = dev_get_drvdata(dev);
> >> - struct tilcdc_drm_private *priv = ddev->dev_private;
> >> - int ret = 0;
> >>
> >> /* Select default pin state */
> >> pinctrl_pm_select_default_state(dev);
> >> -
> >> - if (priv->saved_state)
> >> - ret = drm_atomic_helper_resume(ddev, priv->saved_state);
> >> -
> >> - return ret;
> >> + return drm_mode_config_helper_resume(ddev);
> >> }
> >> #endif
> >>
> >> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >> index ead5122..62cea5f 100644
> >> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> >> @@ -70,9 +70,6 @@ struct tilcdc_drm_private {
> >> const uint32_t *pixelformats;
> >> uint32_t num_pixelformats;
> >>
> >> - /* The context for pm susped/resume cycle is stored here */
> >> - struct drm_atomic_state *saved_state;
> >> -
> >> #ifdef CONFIG_CPU_FREQ
> >> struct notifier_block freq_transition;
> >> #endif
> >> --
> >> 1.9.1
> >>
>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107863] Kernel panic when external monitors go blank
https://bugs.freedesktop.org/show_bug.cgi?id=107863 Michel Dänzer changed: What|Removed |Added Attachment #141478|text/x-log |text/plain mime type|| -- 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 107858] Screen resolution wrong after turning monitor off and on
https://bugs.freedesktop.org/show_bug.cgi?id=107858 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com, ||sunpeng...@amd.com --- Comment #8 from Michel Dänzer --- (In reply to Lothar Paltins from comment #7) > But the client must know the possible resolutions and this information must > come from the X server and the driver. Right, looks like there's indeed a problem with the kernel driver DC code obtaining / processing EDID. > Now there are lines with "get vblank counter failed: Invalid argument" in the > Xorg.0.log file, which I didn't see previously. Those can happen occasionally with a DisplayPort connection, they should be harmless. -- 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 107876] GPU lockup with Radeon HD 7850 in 18.1.6 driver
https://bugs.freedesktop.org/show_bug.cgi?id=107876 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Michel Dänzer --- *** This bug has been marked as a duplicate of bug 105381 *** -- 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 13/20] drm/sti: Use drm_fbdev_generic_setup()
2018-09-08 15:46 GMT+02:00 Noralf Trønnes :
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> If drm_fbdev_generic_setup() fails, an error is printed by the function.
>
> drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
> In that case it retries fbdev setup on the next .output_poll_changed.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Signed-off-by: Noralf Trønnes
Acked-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/sti/sti_drv.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 832fc43960ee..6dced8abcf16 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -121,7 +121,6 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
>
> static const struct drm_mode_config_funcs sti_mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> };
> @@ -206,7 +205,6 @@ static void sti_cleanup(struct drm_device *ddev)
> {
> struct sti_private *private = ddev->dev_private;
>
> - drm_fb_cma_fbdev_fini(ddev);
> drm_kms_helper_poll_fini(ddev);
> component_unbind_all(ddev->dev, ddev);
> kfree(private);
> @@ -236,11 +234,7 @@ static int sti_bind(struct device *dev)
>
> drm_mode_config_reset(ddev);
>
> - if (ddev->mode_config.num_connector) {
> - ret = drm_fb_cma_fbdev_init(ddev, 32, 0);
> - if (ret)
> - DRM_DEBUG_DRIVER("Warning: fails to create fbdev\n");
> - }
> + drm_fbdev_generic_setup(ddev, 32);
>
> return 0;
>
> --
> 2.15.1
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging/vboxvideo: Replace ttm_bo_unref with ttm_bo_put
The function ttm_bo_put releases a reference to a TTM buffer object. The function's name is more aligned to the Linux kernel convention of naming ref-counting function _get and _put. A call to ttm_bo_unref takes the address of the TTM BO object's pointer and clears the pointer's value to NULL. This is not necessary in most cases and sometimes even worked around by the calling code. A call to ttm_bo_put only releases the reference without clearing the pointer. The current behaviour of cleaning the pointer is kept in the calling code, but should be removed if not required in a later patch. Signed-off-by: Thomas Zimmermann --- drivers/staging/vboxvideo/vbox_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_main.c b/drivers/staging/vboxvideo/vbox_main.c index 429f6a453619..b6cff31903b3 100644 --- a/drivers/staging/vboxvideo/vbox_main.c +++ b/drivers/staging/vboxvideo/vbox_main.c @@ -490,9 +490,8 @@ static void vbox_bo_unref(struct vbox_bo **bo) return; tbo = &((*bo)->bo); - ttm_bo_unref(); - if (!tbo) - *bo = NULL; + ttm_bo_put(tbo); + *bo = NULL; } void vbox_gem_free_object(struct drm_gem_object *obj) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: set ttm_buffer_object pointer as null after it's freed
Am 10.09.2018 um 11:23 schrieb Huang Rui:
On Mon, Sep 10, 2018 at 11:00:04AM +0200, Christian König wrote:
Hi Ray,
well those patches doesn't make sense, the pointer is only local to
the function.
You're right.
I narrowed it with gdb dump from ttm_bo_bulk_move_lru_tail+0x2b, the
use-after-free should be in below codes:
man = >tt[i].first->bdev->man[TTM_PL_TT];
ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
Is there a case, when orignal bo is destroyed in the bulk pos, but it
doesn't update pos->first pointer, then we still use it during the bulk
moving?
Only when a per VM BO is freed or the VM destroyed.
The first case should now be handled by "drm/amdgpu: set bulk_moveable
to false when a per VM is released" and when we use a destroyed VM we
would see other problems as well.
BTW: Just pushed this commit to the repository, should show up any second.
Christian.
Thanks,
Ray
Regards,
Christian.
Am 10.09.2018 um 10:57 schrieb Huang Rui:
It avoids to be refered again after freed.
Signed-off-by: Huang Rui
Cc: Christian König
Cc: Tom StDenis
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 138c989..d3ef5f8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -54,6 +54,7 @@ static struct attribute ttm_bo_count = {
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
kfree(bo);
+ bo = NULL;
}
static inline int ttm_mem_type_from_place(const struct ttm_place *place,
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/6] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that no output-switching is necessary.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
changes in v3:
- fixed wording issue found by Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 11309a2a4e43..b09c3531305b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,7 +36,7 @@
* @lcdsel_lit: reg value of selecting vop little for HDMI
*/
struct rockchip_hdmi_chip_data {
- u32 lcdsel_grf_reg;
+ int lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
};
@@ -245,6 +245,9 @@ static void dw_hdmi_rockchip_encoder_enable(struct
drm_encoder *encoder)
u32 val;
int ret;
+ if (hdmi->chip_data->lcdsel_grf_reg < 0)
+ return;
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/6] drm/rockchip: dw_hdmi: allow including external phys
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b09c3531305b..57e76dfd5f6d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,7 @@ struct rockchip_hdmi {
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+ struct phy *phy;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -376,6 +378,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ hdmi->phy = devm_phy_optional_get(dev, "hdmi");
+ if (IS_ERR(hdmi->phy)) {
+ ret = PTR_ERR(hdmi->phy);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, _hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/6] dt-bindings: allow optional phys in Rockchip dw_hdmi binding
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general mmio, so allow these to be referenced via the regular phy interfaces and therefore add optional phy-related properties to the binding. Signed-off-by: Heiko Stuebner Reviewed-by: Rob Herring --- .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt index adc94fc3c9f8..937bfb472e1d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -34,6 +34,8 @@ Optional properties - clock-names: May contain "cec" as defined in dw_hdmi.txt. - clock-names: May contain "grf", power for grf io. - clock-names: May contain "vpll", external clock for some hdmi phy. +- phys: from general PHY binding: the phandle for the PHY device. +- phy-names: Should be "hdmi" if phys references an external phy. Example: -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/6] drm/rockchip: hdmi support for rk3328
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy from Innosilicon that resides completely separate from the dw-hdmi block and gets accessed via mmio. Additionally the rk3328 dw-hdmi does not report the vendor-phy type but a different one instead, so add the possibility to override the phy type when the glue driver knows better than the ip block itself. changes in v4: - rebased onto 4.19-rc2 - no actual changes - added Rob's Ack on the dw-hdmi compatible changes in v3: - split off phy driver into a separate series - only allow forcing vendor phy type - wording fixes and other nits changes in v2: - phy: prevent overflow in tmdsclk calculation as reported by Martin Cerveny - phy: use unsigned long for all tmdsclk rate uses - phy: simplify tmds rate calculation - dropped patch exporting some dw-hdmi phy functions as a similar patch entered drm-misc already Heiko Stuebner (6): drm/bridge: dw-hdmi: allow forcing vendor phy-type drm/rockchip: dw_hdmi: Allow outputs that don't need output switching dt-bindings: allow optional phys in Rockchip dw_hdmi binding drm/rockchip: dw_hdmi: allow including external phys drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328 .../display/rockchip/dw_hdmi-rockchip.txt | 3 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +- include/drm/bridge/dw_hdmi.h | 1 + 4 files changed, 134 insertions(+), 4 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/6] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct.
As the chip-data that occupies the phy_data pointer initially gets
assigned to the rockchip_hdmi struct, we can now re-use this phy_data
pointer to hold the reference to the rockchip_hdmi struct and use this
reference later on.
Inspiration for this comes from meson and sunxi dw-hdmi, which are using
the same method.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
changes in v3:
- reword commit message
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 57e76dfd5f6d..19f002fa0a09 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -335,7 +335,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
+ struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -350,9 +350,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ plat_data = devm_kmemdup(>dev, match->data,
+sizeof(*plat_data), GFP_KERNEL);
+ if (!plat_data)
+ return -ENOMEM;
+
hdmi->dev = >dev;
hdmi->chip_data = plat_data->phy_data;
+ plat_data->phy_data = hdmi;
encoder = >encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
The rk3328 uses a dw-hdmi controller with an external hdmi phy from
Innosilicon which uses the generic phy framework for access.
Add the necessary data and the compatible for the rk3328 to the
rockchip dw-hdmi driver.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
Acked-by: Rob Herring
changes in v3:
- reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
---
.../display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 106 ++
2 files changed, 107 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 937bfb472e1d..39143424a474 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -13,6 +13,7 @@ Required properties:
- compatible: should be one of the following:
"rockchip,rk3288-dw-hdmi"
+ "rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
- reg: See dw_hdmi.txt.
- reg-io-width: See dw_hdmi.txt. Shall be 4.
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 19f002fa0a09..237f31fd8403 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -25,6 +25,24 @@
#define RK3288_GRF_SOC_CON60x025C
#define RK3288_HDMI_LCDC_SEL BIT(4)
+#define RK3328_GRF_SOC_CON20x0408
+
+#define RK3328_HDMI_SDAIN_MSK BIT(11)
+#define RK3328_HDMI_SCLIN_MSK BIT(10)
+#define RK3328_HDMI_HPD_IOEBIT(2)
+#define RK3328_GRF_SOC_CON30x040c
+/* need to be unset if hdmi or i2c should control voltage */
+#define RK3328_HDMI_SDA5V_GRF BIT(15)
+#define RK3328_HDMI_SCL5V_GRF BIT(14)
+#define RK3328_HDMI_HPD5V_GRF BIT(13)
+#define RK3328_HDMI_CEC5V_GRF BIT(12)
+#define RK3328_GRF_SOC_CON40x0410
+#define RK3328_HDMI_HPD_SARADC BIT(13)
+#define RK3328_HDMI_CEC_5V BIT(11)
+#define RK3328_HDMI_SDA_5V BIT(10)
+#define RK3328_HDMI_SCL_5V BIT(9)
+#define RK3328_HDMI_HPD_5V BIT(8)
+
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
@@ -292,6 +310,68 @@ static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
};
+static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
+struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ return phy_power_on(hdmi->phy);
+}
+
+static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void
*data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ enum drm_connector_status status;
+
+ status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+ if (status == connector_status_connected)
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ else
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ return status;
+}
+
+static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+ /* Enable and map pins to 3V grf-controlled io-voltage */
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0, RK3328_HDMI_HPD_SARADC | RK3328_HDMI_CEC_5V |
+RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V |
+RK3328_HDMI_HPD_5V));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON3,
+ HIWORD_UPDATE(0, RK3328_HDMI_SDA5V_GRF | RK3328_HDMI_SCL5V_GRF |
+RK3328_HDMI_HPD5V_GRF |
RK3328_HDMI_CEC5V_GRF));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON2,
+ HIWORD_UPDATE(RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK,
+
