Re: [PATCH] host1x: hdmi: Make sure clock is enabled before dumping registers
On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote: > The debugfs register dumping function did not enable the HDMI clock. > This led to a possible system hang when reading the debugfs entry > while no HDMI cable was connected to the system. This patch makes > sure that the clock is enabled during the read. > > Signed-off-by: Mikko Perttunen > --- > drivers/gpu/host1x/drm/hdmi.c | 7 +++ > 1 file changed, 7 insertions(+) Applied, thanks. Thierry pgpegPtC9nR0h.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 9:46 AM, Lothar Waßmann
wrote:
> the function imx_drm_driver_load() must have been called before
> calling imx_drm_add_crtc(), but the following hunk in the commit:
> @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
> unsigned long flags)
> */
> imxdrm->drm->vblank_disable_allowed = 1;
>
> + if (!imx_drm_device_get())
> + ret = -EINVAL;
> +
> ret = 0;
>
> err_init:
>
> makes imx_drm_add_crtc() bail out at:
>
> if (imxdrm->references) {
> ret = -EBUSY;
> goto err_busy;
> }
>
> Thus it is not possible to register any CRTCs.
Ok I've now read around a bit in the imx core and I think my call to rip
this out was right ;-)
If I understand stuff correctly you have a main driver plus a bunch of
encoder/crtc modules and you expect that everything gets loaded and then
only when the kms driver is first opened. The current drm core just
doesn't support hotplugging of encoder/crtc objects after driver init has
completed. If you try to do that it'll go down in flames due to all the
races involved.
So as a stopgap measuret I sugges you rip out the imxdrm->references
trickery since it won't actually protect you from anything truly nasty
happening. And I wouldn't worry about module unloading and refcounting for
now since core drm is terminally broken in that area already anyway.
Then we can move ahead and how to really fix this init ordering. So I
think we have another TODO here:
Cheers, Daniel
---
diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index f806415..f8ef245 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,6 +6,11 @@ TODO:
- Factor out more code to common helper functions
- decide where to put the base driver. It is not specific to a subsystem
and would be used by DRM/KMS and media/V4L2
+- Fix up the driver load sequence to make sure all submodules for
encoders/crtcs
+ are fully loaded before the drm driver is registered. Might require a core
drm
+ rework to break away the drm core init sequence from its midlayer drug and
+ assorted control inversion issues. Or we restructure imx to just built in
+ everything, dunno. Requested by Daniel Vetter
Missing features (not necessarily for moving out of staging):
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
Hi Daniel,
Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 9:46 AM, Lothar Waßmann
> wrote:
> > the function imx_drm_driver_load() must have been called before
> > calling imx_drm_add_crtc(), but the following hunk in the commit:
> > @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
> > unsigned long flags)
> > */
> > imxdrm->drm->vblank_disable_allowed = 1;
> >
> > + if (!imx_drm_device_get())
> > + ret = -EINVAL;
> > +
> > ret = 0;
> >
> > err_init:
> >
> > makes imx_drm_add_crtc() bail out at:
> >
> > if (imxdrm->references) {
> > ret = -EBUSY;
> > goto err_busy;
> > }
> >
> > Thus it is not possible to register any CRTCs.
>
> Ok I've now read around a bit in the imx core and I think my call to rip
> this out was right ;-)
>
> If I understand stuff correctly you have a main driver plus a bunch of
> encoder/crtc modules and you expect that everything gets loaded and then
> only when the kms driver is first opened. The current drm core just
> doesn't support hotplugging of encoder/crtc objects after driver init has
> completed. If you try to do that it'll go down in flames due to all the
> races involved.
>
You know the logic you broke here was just a moderately sane approach to
get around the monolithic DRM driver nonsense, while not having to use
real hotplug in DRM.
The thing is we don't know if we will ever have all submodules loaded,
as this driver is mostly used on embedded devices where people randomly
decide to exclude things from their kernel config, because they don't
use the feature on their board. The current logic is under the premise
that there are no early DRM clients in something like Plymouth, which is
a bit flaky, but worked very well for the targeted use-cases.
Regards,
Lucas
> So as a stopgap measuret I sugges you rip out the imxdrm->references
> trickery since it won't actually protect you from anything truly nasty
> happening. And I wouldn't worry about module unloading and refcounting for
> now since core drm is terminally broken in that area already anyway.
>
> Then we can move ahead and how to really fix this init ordering. So I
> think we have another TODO here:
>
> Cheers, Daniel
>
> ---
> diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
> index f806415..f8ef245 100644
> --- a/drivers/staging/imx-drm/TODO
> +++ b/drivers/staging/imx-drm/TODO
> @@ -6,6 +6,11 @@ TODO:
> - Factor out more code to common helper functions
> - decide where to put the base driver. It is not specific to a subsystem
>and would be used by DRM/KMS and media/V4L2
> +- Fix up the driver load sequence to make sure all submodules for
> encoders/crtcs
> + are fully loaded before the drm driver is registered. Might require a core
> drm
> + rework to break away the drm core init sequence from its midlayer drug and
> + assorted control inversion issues. Or we restructure imx to just built in
> + everything, dunno. Requested by Daniel Vetter
>
> Missing features (not necessarily for moving out of staging):
>
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 1/2] gpu: host1x: fix an integer overflow check
On Fri, Aug 23, 2013 at 01:18:25PM +0300, Dan Carpenter wrote: > Tegra is a 32 bit arch. On 32 bit systems then size_t is 32 bits so > "total" will never be higher than UINT_MAX because of integer overflows. > We need cast to u64 first before doing the math. > > Also the addition earlier: > > unsigned int num_unpins = num_cmdbufs + num_relocs; > > That can overflow as well, but I think it's still safe because we check > both "num_cmdbufs" and "num_relocs" again in this test. > > Signed-off-by: Dan Carpenter > --- > This is something I spotted in code review. I can't actually compile > this code. I assume this overflow test has security implications. It did compile and looks good to me, so I've applied it. Thanks, Thierry pgp4xwYzLJ19e.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote: >> If I understand stuff correctly you have a main driver plus a bunch of >> encoder/crtc modules and you expect that everything gets loaded and then >> only when the kms driver is first opened. The current drm core just >> doesn't support hotplugging of encoder/crtc objects after driver init has >> completed. If you try to do that it'll go down in flames due to all the >> races involved. >> > You know the logic you broke here was just a moderately sane approach to > get around the monolithic DRM driver nonsense, while not having to use > real hotplug in DRM. > > The thing is we don't know if we will ever have all submodules loaded, > as this driver is mostly used on embedded devices where people randomly > decide to exclude things from their kernel config, because they don't > use the feature on their board. The current logic is under the premise > that there are no early DRM clients in something like Plymouth, which is > a bit flaky, but worked very well for the targeted use-cases. Imo the imxdrm->references logic is broken already and simply removing those checks would be the right course of action - pretending to have fixed races but not actually having fixed much is imo much worse than openly admitting that the code is racy and needs work. Wrt embedded guys shaving off a few kb by not loading a bunch of modules I think you should simply make that compile-time options instead of modules. More hassle but at least it should work. And if we ever see the need to hotplug crtcs I think the right way is to hotplug an entire drm driver. Connector/encoder hotplugging might eventually be required for real to support stuff like multi-stream DP, but until that happens I really don't see a need for funny games, especially on SoC boards where everything is soldered on and can't possibly be hotplugged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 David "okias" Heidelberger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from David "okias" Heidelberger --- it work well with 3.10, so it's fixed for me. Thank you. Closing bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: > On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote: > >> If I understand stuff correctly you have a main driver plus a bunch of > >> encoder/crtc modules and you expect that everything gets loaded and then > >> only when the kms driver is first opened. The current drm core just > >> doesn't support hotplugging of encoder/crtc objects after driver init has > >> completed. If you try to do that it'll go down in flames due to all the > >> races involved. > >> > > You know the logic you broke here was just a moderately sane approach to > > get around the monolithic DRM driver nonsense, while not having to use > > real hotplug in DRM. > > > > The thing is we don't know if we will ever have all submodules loaded, > > as this driver is mostly used on embedded devices where people randomly > > decide to exclude things from their kernel config, because they don't > > use the feature on their board. The current logic is under the premise > > that there are no early DRM clients in something like Plymouth, which is > > a bit flaky, but worked very well for the targeted use-cases. > > Imo the imxdrm->references logic is broken already and simply removing > those checks would be the right course of action - pretending to have > fixed races but not actually having fixed much is imo much worse than > openly admitting that the code is racy and needs work. > > Wrt embedded guys shaving off a few kb by not loading a bunch of > modules I think you should simply make that compile-time options > instead of modules. More hassle but at least it should work. It's not about the few kb. The problem is that our devices are not monolithic, but instead we have multiple devices in and around the SoC which form a DRM device. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 2/2] gpu: host1x: returning success instead of -ENOMEM
On Fri, Aug 23, 2013 at 01:19:11PM +0300, Dan Carpenter wrote: > There is a mistake here so it returns PTR_ERR(NULL) which is success > instead of -ENOMEM. > > Signed-off-by: Dan Carpenter > --- > I can't compile this. Good catch! Applied, thanks. Thierry pgpe9f5h46uC2.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter: > On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote: > >> If I understand stuff correctly you have a main driver plus a bunch of > >> encoder/crtc modules and you expect that everything gets loaded and then > >> only when the kms driver is first opened. The current drm core just > >> doesn't support hotplugging of encoder/crtc objects after driver init has > >> completed. If you try to do that it'll go down in flames due to all the > >> races involved. > >> > > You know the logic you broke here was just a moderately sane approach to > > get around the monolithic DRM driver nonsense, while not having to use > > real hotplug in DRM. > > > > The thing is we don't know if we will ever have all submodules loaded, > > as this driver is mostly used on embedded devices where people randomly > > decide to exclude things from their kernel config, because they don't > > use the feature on their board. The current logic is under the premise > > that there are no early DRM clients in something like Plymouth, which is > > a bit flaky, but worked very well for the targeted use-cases. > > Imo the imxdrm->references logic is broken already and simply removing > those checks would be the right course of action - pretending to have > fixed races but not actually having fixed much is imo much worse than > openly admitting that the code is racy and needs work. > I don't see how this is overly racy. We are doing delayed DRM device setup not delayed HW setup. We simply look around which modules are there and what DRM we can build up from them. With some small work we would even be able to make the Plymouth + modules in initrd case work. The only case that would not really be solvable without full hotplug is the Plymouth in initrd + modules on the late rootfs. > Wrt embedded guys shaving off a few kb by not loading a bunch of > modules I think you should simply make that compile-time options > instead of modules. More hassle but at least it should work. > This would be really moving in the wrong direction. We want to get more modular, not less. We have a lot different on- and off-chip encoders and other stuff where we want distinct drivers and not some cludged together thing. > And if we ever see the need to hotplug crtcs I think the right way is > to hotplug an entire drm driver. Connector/encoder hotplugging might > eventually be required for real to support stuff like multi-stream DP, > but until that happens I really don't see a need for funny games, > especially on SoC boards where everything is soldered on and can't > possibly be hotplugged. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 06/19] video: display: OF support
Hi Laurent,
I have another small issue with the graph helpers below:
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
> +/*
> -
> * Graph Helpers
> */
>
> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> struct list_head *entities)
> }
> EXPORT_SYMBOL_GPL(display_entity_link_graph);
>
> +#ifdef CONFIG_OF
> +
> +static int display_of_entity_link_entity(struct device *dev,
> + struct display_entity *entity,
> + struct list_head *entities,
> + struct display_entity *root)
> +{
> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + const struct device_node *node = entity->dev->of_node;
> + struct media_entity *local = &entity->entity;
> + struct device_node *ep = NULL;
> + int ret = 0;
> +
> + dev_dbg(dev, "creating links for entity %s\n", local->name);
> +
> + while (1) {
> + struct media_entity *remote = NULL;
> + struct media_pad *remote_pad;
> + struct media_pad *local_pad;
> + struct display_of_link link;
> + struct display_entity *ent;
> + struct device_node *next;
> +
> + /* Get the next endpoint and parse its link. */
> + next = display_of_get_next_endpoint(node, ep);
> + if (next == NULL)
> + break;
> +
> + of_node_put(ep);
> + ep = next;
> +
> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> +
> + ret = display_of_parse_link(ep, &link);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse link for %s\n",
> + ep->full_name);
> + continue;
> + }
> +
> + /* Skip source pads, they will be processed from the other end
> of
> + * the link.
> + */
> + if (link.local_port >= local->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.local_port, link.local_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + local_pad = &local->pads[link.local_port];
> +
> + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> + dev_dbg(dev, "skipping source port %s:%u\n",
> + link.local_node->full_name, link.local_port);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + /* Find the remote entity. If not found, just skip the link as
> + * it goes out of scope of the entities handled by the notifier.
> + */
> + list_for_each_entry(ent, entities, list) {
> + if (ent->dev->of_node == link.remote_node) {
> + remote = &ent->entity;
> + break;
> + }
> + }
> +
> + if (root->dev->of_node == link.remote_node)
> + remote = &root->entity;
> +
> + if (remote == NULL) {
> + dev_dbg(dev, "no entity found for %s\n",
> + link.remote_node->full_name);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + if (link.remote_port >= remote->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.remote_port, link.remote_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + remote_pad = &remote->pads[link.remote_port];
> +
> + display_of_put_link(&link);
> +
> + /* Create the media link. */
> + dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> +
> + ret = media_entity_create_link(remote, remote_pad->index,
> +local, local_pad->index,
> +link_flags);
> + if (ret < 0) {
> + dev_err(dev,
> + "failed to create %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> + break;
> + }
> + }
> +
> + of_node_put(ep);
> + return ret;
> +}
> +
> +/**
> + * display_of_entity_link_graph - Link all entities
Re: [PATCH 03/14] drm/edid: Parse the HDMI CEA block and look for 4k modes
On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
[...]
> + u8 vic;
> +
> + vic = db[9 + offset + i];
> +
> + vic--; /* VICs start at 1 */
This could've all gone on a single line, perhaps with the comment on
top, like so:
/* VICs start at 1 */
u8 vic = db[9 + offset + i] - 1;
Thierry
pgpmIIFWKzAof.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HDMI 4k support v4
On Mon, Aug 19, 2013 at 04:58:51PM +0100, Damien Lespiau wrote: > Follow up on v3: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html > > Changes between v3 and v4: > - Future proof the sending of 3D_Ext_Data > - Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn, > renaming the hdmi_vendor_infoframe enum to hdmi_vendor_any_infoframe) > - Renamed HDMI_IDENTIFIER to HDMI_IEEE_OUI The series looks good to me. Thanks for doing this Damien! Reviewed-by: Thierry Reding pgpHKWtPnCMHm.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #4 from Richard Van Den Boom --- According to bisect, the commit that cause the crashes is this one : git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed # first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure that the stages setup outputs I've attached the full git bisect log output. Whatever Kwin does in the R300 driver, the above commit seems to trigger an issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #5 from Richard Van Den Boom --- Created attachment 84696 --> https://bugs.freedesktop.org/attachment.cgi?id=84696&action=edit Git bisect log output -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote: > On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: >> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote: >> >> If I understand stuff correctly you have a main driver plus a bunch of >> >> encoder/crtc modules and you expect that everything gets loaded and then >> >> only when the kms driver is first opened. The current drm core just >> >> doesn't support hotplugging of encoder/crtc objects after driver init has >> >> completed. If you try to do that it'll go down in flames due to all the >> >> races involved. >> >> >> > You know the logic you broke here was just a moderately sane approach to >> > get around the monolithic DRM driver nonsense, while not having to use >> > real hotplug in DRM. >> > >> > The thing is we don't know if we will ever have all submodules loaded, >> > as this driver is mostly used on embedded devices where people randomly >> > decide to exclude things from their kernel config, because they don't >> > use the feature on their board. The current logic is under the premise >> > that there are no early DRM clients in something like Plymouth, which is >> > a bit flaky, but worked very well for the targeted use-cases. >> >> Imo the imxdrm->references logic is broken already and simply removing >> those checks would be the right course of action - pretending to have >> fixed races but not actually having fixed much is imo much worse than >> openly admitting that the code is racy and needs work. >> >> Wrt embedded guys shaving off a few kb by not loading a bunch of >> modules I think you should simply make that compile-time options >> instead of modules. More hassle but at least it should work. > > It's not about the few kb. The problem is that our devices are not > monolithic, but instead we have multiple devices in and around the SoC > which form a DRM device. right, but the cores on the SoC, and even any external encoder chips, are not actually hot-pluggable. I have a similar scenario w/ msm drm, where there is the core display controller (for ex, 'mdp4'), plus hdmi/dsi/etc blocks around that (with their own irq, io/register region, etc). It would be nice if the kernel provided a better mechanism for composite drivers, but what I do is just register the platform drivers for those other blocks first (in the init code, before calling 'platform_driver_register(&msm_platform_driver)'. This way, if the device is actually present, I know before drm dev_load. I do not attempt to build hdmi/dsi/etc as separate modules. I could if I wanted to include/exclude them at compile time, but separate modules seems like a bad idea. BR, -R > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark wrote: > On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote: >> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: >>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach >>> wrote: >>> >> If I understand stuff correctly you have a main driver plus a bunch of >>> >> encoder/crtc modules and you expect that everything gets loaded and then >>> >> only when the kms driver is first opened. The current drm core just >>> >> doesn't support hotplugging of encoder/crtc objects after driver init has >>> >> completed. If you try to do that it'll go down in flames due to all the >>> >> races involved. >>> >> >>> > You know the logic you broke here was just a moderately sane approach to >>> > get around the monolithic DRM driver nonsense, while not having to use >>> > real hotplug in DRM. >>> > >>> > The thing is we don't know if we will ever have all submodules loaded, >>> > as this driver is mostly used on embedded devices where people randomly >>> > decide to exclude things from their kernel config, because they don't >>> > use the feature on their board. The current logic is under the premise >>> > that there are no early DRM clients in something like Plymouth, which is >>> > a bit flaky, but worked very well for the targeted use-cases. >>> >>> Imo the imxdrm->references logic is broken already and simply removing >>> those checks would be the right course of action - pretending to have >>> fixed races but not actually having fixed much is imo much worse than >>> openly admitting that the code is racy and needs work. >>> >>> Wrt embedded guys shaving off a few kb by not loading a bunch of >>> modules I think you should simply make that compile-time options >>> instead of modules. More hassle but at least it should work. >> >> It's not about the few kb. The problem is that our devices are not >> monolithic, but instead we have multiple devices in and around the SoC >> which form a DRM device. > > right, but the cores on the SoC, and even any external encoder chips, > are not actually hot-pluggable. I have a similar scenario w/ msm drm, oh, and come to think of it, same approach it tilcdc. And I'm sure there are other drivers with the same scenario. BR, -R > where there is the core display controller (for ex, 'mdp4'), plus > hdmi/dsi/etc blocks around that (with their own irq, io/register > region, etc). It would be nice if the kernel provided a better > mechanism for composite drivers, but what I do is just register the > platform drivers for those other blocks first (in the init code, > before calling 'platform_driver_register(&msm_platform_driver)'. This > way, if the device is actually present, I know before drm dev_load. I > do not attempt to build hdmi/dsi/etc as separate modules. I could if > I wanted to include/exclude them at compile time, but separate modules > seems like a bad idea. > > BR, > -R > >> Sascha >> >> -- >> Pengutronix e.K. | | >> Industrial Linux Solutions | http://www.pengutronix.de/ | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote: >> right, but the cores on the SoC, and even any external encoder chips, >> are not actually hot-pluggable. I have a similar scenario w/ msm drm, > > oh, and come to think of it, same approach it tilcdc. And I'm sure > there are other drivers with the same scenario. i915 and nouveau also support encoder slaves, and they also have them all built-in. And I think requesting the module at driver init time (where I mean any point in time between when the master module loads and userspace first starts using it) seems fraught with with deadlock issues if we have to wait for it. So imo in the current drm state there is no way you can built slave drivers as modules. It's simply broken. I agree that it'd be nice to have a better solution, but atm I don't even have an idea what it is. But applying duct-tape in ->firstopen is certainly not the right way. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote: > On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote: > >> right, but the cores on the SoC, and even any external encoder chips, > >> are not actually hot-pluggable. I have a similar scenario w/ msm drm, > > > > oh, and come to think of it, same approach it tilcdc. And I'm sure > > there are other drivers with the same scenario. > > i915 and nouveau also support encoder slaves, and they also have them > all built-in. And I think requesting the module at driver init time > (where I mean any point in time between when the master module loads > and userspace first starts using it) seems fraught with with deadlock > issues if we have to wait for it. > > So imo in the current drm state there is no way you can built slave > drivers as modules. It's simply broken. I agree that it'd be nice to > have a better solution, but atm I don't even have an idea what it is. > But applying duct-tape in ->firstopen is certainly not the right way. The imx-drm does not request modules itself. It also does not do hotplug. It also does not change the drm device structure while being opened. The drm device structure is only ever changed when the device is closed. Once it's opened it's completely static and will not be changed. All this 'core' stuff in the drm driver is only done to be able to separate the different encoders into linux platform_devices, module support is only a side effect of this. What the imx-drm driver does is: - collect subcomponents via imx_drm_add_connector, imx_drm_add_crtc and imx_drm_add_encoder - During drm device open time the try_module_get will make sure the modules providing encoders/crtcs do not get unloaded. once the device is opened imx_drm_add_* will return -EBUSY. - When the drm device is closed module_put is called and components are allowed to be registered/unregistered again. Indeed hotplug support for components would be nice, but as said this is not supported by drm and by the imx-drm driver. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)
https://bugs.freedesktop.org/show_bug.cgi?id=68468
--- Comment #4 from adam...@gmail.com ---
Well, the digging phase is over, I pretty much hit a wall.
As stated above, the general bisecting idea is clear, but I'm having problem
actually building mesa.
Here what I've done:
I downloaded the PKGBUILD and needed packages (clang-svn, llvm-svn etc.) from
Laurent Carlier's folder (an Arch developer).
I modified the PKGBUILD a bit - comment out unnecessary packages
(intel-dri-git, for example).
In order to build a specific commit, I added the following line to the build()
section:
cd ${srcdir}/mesa
git checkout 5b2855bfe79bfc3995969f2bf775d89b1bc1808a
makepkg -s was invoked later, but failed pretty soon. A bit of googling and the
blame was with bison 3.0.
Since the commit I'm trying to build is from April 11th and the bison 3.0 fix
is from July 31st and since I have no idea how to backport the bison 3.0
patches, I downgraded to bison 2.7.1 from the AUR
(https://bugs.freedesktop.org/show_bug.cgi?id=67354).
makepkg -s then got over the problematic bison part but failed again, this time
with an error related to llvm 3.4
(https://bugs.freedesktop.org/show_bug.cgi?id=64590).
Again, The fix is from May 14th (http://cgit.freedesktop.org/mesa/mesa/c …
773efbc181), so I reverted to LLVM 3.3 and modified PKGBUILD accordingly (llvm
instead of llvm-svn etc.).
This is, unfortunately, where I got stuck.
Build fails again, with an error that seems to be related to llvm 3.4, though
I'm on 3.3.
Log is here - http://pastebin.com/DwFAVKxC
PKGBUILD is here - http://pastebin.com/PwiZXVGv
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix handling of variable sized arrays for router objects
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly. Use pointers and update the offset
appropriately when accessing the Dst members.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 112c963..ad91354 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -711,13 +711,16 @@ bool
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
(ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *)
(ctx->bios +
data_offset +
le16_to_cpu(router_obj->asObjects[k].usSrcDstTableOffset));
+ u8 *num_dst_objs = (u8
*)
+ ((u8
*)router_src_dst_table + 1 +
+
(router_src_dst_table->ucNumberOfSrc * 2));
+ u16 *dst_objs = (u16
*)(num_dst_objs + 1);
int enum_id;
router.router_id =
router_obj_id;
- for (enum_id = 0;
enum_id < router_src_dst_table->ucNumberOfDst;
-enum_id++) {
+ for (enum_id = 0;
enum_id < (*num_dst_objs); enum_id++) {
if
(le16_to_cpu(path->usConnObjectId) ==
-
le16_to_cpu(router_src_dst_table->usDstObjectID[enum_id]))
+
le16_to_cpu(dst_objs[enum_id]))
break;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #19 from Alex Deucher --- Created attachment 84747 --> https://bugs.freedesktop.org/attachment.cgi?id=84747&action=edit possible fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/nouveau: Add priv field for event handlers
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 20 +++-
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ad4d8c2 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -7,6 +7,7 @@
struct nouveau_eventh {
struct list_head head;
+ void *priv;
int (*func)(struct nouveau_eventh *, int index);
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..c2e3167 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -165,17 +165,11 @@ nouveau_fence_done(struct nouveau_fence *fence)
return !fence->channel;
}
-struct nouveau_fence_uevent {
- struct nouveau_eventh handler;
- struct nouveau_fence_priv *priv;
-};
-
static int
-nouveau_fence_wait_uevent_handler(struct nouveau_eventh *event, int index)
+nouveau_fence_wait_uevent_handler(struct nouveau_eventh *handler, int index)
{
- struct nouveau_fence_uevent *uevent =
- container_of(event, struct nouveau_fence_uevent, handler);
- wake_up_all(&uevent->priv->waiting);
+ struct nouveau_fence_priv *priv = handler->priv;
+ wake_up_all(&priv->waiting);
return NVKM_EVENT_KEEP;
}
@@ -186,13 +180,13 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence,
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
- struct nouveau_fence_uevent uevent = {
- .handler.func = nouveau_fence_wait_uevent_handler,
+ struct nouveau_eventh handler = {
+ .func = nouveau_fence_wait_uevent_handler,
.priv = priv,
};
int ret = 0;
- nouveau_event_get(pfifo->uevent, 0, &uevent.handler);
+ nouveau_event_get(pfifo->uevent, 0, &handler);
if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -224,7 +218,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool
intr)
}
}
- nouveau_event_put(pfifo->uevent, 0, &uevent.handler);
+ nouveau_event_put(pfifo->uevent, 0, &handler);
if (unlikely(ret < 0))
return ret;
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/nouveau: Move event index check from critical section
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..e69c463 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -40,9 +40,11 @@ nouveau_event_put(struct nouveau_event *event, int index,
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr)
- nouveau_event_put_locked(event, index, handler);
+ nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(&event->lock, flags);
}
@@ -52,13 +54,14 @@ nouveau_event_get(struct nouveau_event *event, int index,
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr) {
- list_add(&handler->head, &event->index[index].list);
- if (!event->index[index].refs++) {
- if (event->enable)
- event->enable(event, index);
- }
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
}
spin_unlock_irqrestore(&event->lock, flags);
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/nouveau: Cleanup event/handler design
This series was originally motivated by a deadlock, introduced in commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b 'drm/nouveau/disp: port vblank handling to event interface', due to inverted lock order between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() (the complete lockdep report is included in the patch 4/5 changelog). Because this series fixes the vblank event deadlock, it is a competing solution to Maarten Lankhorst's 'drm/nouveau: fix vblank deadlock'. This series fixes the vblank event deadlock by converting the event handler list to RCU. This solution allows the event trigger to be lockless, and thus avoiding the lock inversion. Typical hurdles to RCU conversion include: 1) ensuring the object lifetime exceeds the lockless access; 2) preventing premature object reuse; and 3) verifying that stale object use not present logical errors. Because object reuse is not safe in RCU-based operations, the nouveau_event_get/_put interface is migrated from add/remove semantics to enable/disable semantics with a separate install/remove step (which also serves to document the handler lifetime). This also corrects an unsafe interface design where handlers can mistakenly be reused while in use. The nouveau driver currently supports 4 events -- gpio, uevent, cevent, and vblank. Every event is created by and stored within its respective subdev/engine object -- gpio in the GPIO subdev, uevent and cevent in the FIFO engine, and vblank in the DISP engine. Thus event lifetime extends until the subdev is destructed during devobj teardown. Event handler lifetime varies and is detailed in the table below (apologies for the wide-format): Event Handler function Container Until - --- -- gpio nouveau_connector_hotplug struct nouveau_connector nouveau_connector_destroy uevent nouveau_fence_wait_uevent_handler local stack object nouveau_fence_wait_uevent returns cevent none n/a n/a vblank nouveau_drm_vblank_handler struct nouveau_drm nouveau_drm_remove vblank nv50_software_vblsem_release struct nouveau_software_chan _nouveau_engctx_dtor (call stack originates with nouveau_abi16_chan_free ioctl) vblank nvc0_software_vblsem_release struct nouveau_software_chan same as above RCU lifetime considerations for handlers: Event HandlerLifetime - - gpio nouveau_connector_hotplug kfree_rcu(nv_connector) uevent nouveau_fence_wait_uevent_handler explicit use of nouveau_event_hander_create/_destroy cevent none n/a vblank nouveau_drm_vblank_handler synchronize_rcu() in nouveau_drm_unload vblank nv50_software_vblsem_release synchronize_rcu() in container dtor vblank nvc0_software_vblsem_release synchronize_rcu() in container dtor synchronize_rcu() is used for nouveau_object-based containers for which kfree_rcu() is not suitable/possible. Stale event handler execution is not a concern for the existing handlers because either: 1) the handler is responsible for disabling itself (via returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale, as is the case with nouveau_connector_hotplug, which only schedules a work item, and nouveau_drm_vblank_handler, which the drm core expects may be stale. Peter Hurley (9): drm/nouveau: Add priv field for event handlers drm/nouveau: Move event index check from critical section drm/nouveau: Allocate local event handlers drm/nouveau: Allow asymmetric nouveau_event_get/_put drm/nouveau: Add install/remove semantics for event handlers drm/nouveau: Convert event handler list to RCU drm/nouveau: Fold nouveau_event_put_locked into caller drm/nouveau: Simplify event interface drm/nouveau: Simplify event handler interface drivers/gpu/drm/nouveau/core/core/event.c | 121 + .../gpu/drm/nouveau/core/engine/software/nv50.c| 32 -- .../gpu/drm/nouveau/core/engine/software/nvc0.c| 32 -- drivers/gpu/drm/nouveau/core/include/core/event.h | 27 - .../gpu/drm/nouveau/core/include/engine/software.h | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c| 16 ++- drivers/gpu/drm/nouveau/nouveau_display.c | 16 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 35 +++--- drivers/gpu/drm/nouveau/nouveau_fence.c| 27 ++--- 9 files changed, 220 insertions(+), 88 deletions(-) -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/list
[PATCH 3/9] drm/nouveau: Allocate local event handlers
Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.
Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 ++
drivers/gpu/drm/nouveau/nouveau_fence.c | 15 +++---
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index e69c463..1a8d685 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,6 +23,30 @@
#include
#include
+int
+nouveau_event_handler_create(struct nouveau_event *event, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **phandler)
+{
+ struct nouveau_eventh *handler;
+
+ handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
+ if (!handler)
+ return -ENOMEM;
+ handler->func = func;
+ handler->priv = priv;
+ nouveau_event_get(event, index, handler);
+ return 0;
+}
+
+void
+nouveau_event_handler_destroy(struct nouveau_event *event, int index,
+ struct nouveau_eventh *handler)
+{
+ nouveau_event_put(event, index, handler);
+ kfree(handler);
+}
+
static void
nouveau_event_put_locked(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index ad4d8c2..bdf1a0a 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -34,4 +34,10 @@ void nouveau_event_get(struct nouveau_event *, int index,
void nouveau_event_put(struct nouveau_event *, int index,
struct nouveau_eventh *);
+int nouveau_event_handler_create(struct nouveau_event *, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **);
+void nouveau_event_handler_destroy(struct nouveau_event *, int index,
+ struct nouveau_eventh *);
+
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index c2e3167..6dde483 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -180,13 +180,14 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence,
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
- struct nouveau_eventh handler = {
- .func = nouveau_fence_wait_uevent_handler,
- .priv = priv,
- };
- int ret = 0;
+ struct nouveau_eventh *handler;
+ int ret;
- nouveau_event_get(pfifo->uevent, 0, &handler);
+ ret = nouveau_event_handler_create(pfifo->uevent, 0,
+ nouveau_fence_wait_uevent_handler,
+ priv, &handler);
+ if (ret)
+ return ret;
if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -218,7 +219,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool
intr)
}
}
- nouveau_event_put(pfifo->uevent, 0, &handler);
+ nouveau_event_handler_destroy(pfifo->uevent, 0, handler);
if (unlikely(ret < 0))
return ret;
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/nouveau: Allow asymmetric nouveau_event_get/_put
Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corrupted.
Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 20
drivers/gpu/drm/nouveau/core/include/core/event.h | 4
drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++--
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 1a8d685..0a65ede 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -51,11 +51,13 @@ static void
nouveau_event_put_locked(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
- if (!--event->index[index].refs) {
- if (event->disable)
- event->disable(event, index);
+ if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ list_del(&handler->head);
}
- list_del(&handler->head);
}
void
@@ -82,10 +84,12 @@ nouveau_event_get(struct nouveau_event *event, int index,
return;
spin_lock_irqsave(&event->lock, flags);
- list_add(&handler->head, &event->index[index].list);
- if (!event->index[index].refs++) {
- if (event->enable)
- event->enable(event, index);
+ if (!__test_and_set_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
+ }
}
spin_unlock_irqrestore(&event->lock, flags);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index bdf1a0a..3e704d5 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -5,8 +5,12 @@
#define NVKM_EVENT_DROP 0
#define NVKM_EVENT_KEEP 1
+/* nouveau_eventh.flags bit #s */
+#define NVKM_EVENT_ENABLE 0
+
struct nouveau_eventh {
struct list_head head;
+ unsigned long flags;
void *priv;
int (*func)(struct nouveau_eventh *, int index);
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ccea2c4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -88,7 +88,6 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank)))
return -EIO;
- WARN_ON_ONCE(drm->vblank[head].func);
drm->vblank[head].func = nouveau_drm_vblank_handler;
nouveau_event_get(pdisp->vblank, head, &drm->vblank[head]);
return 0;
@@ -99,11 +98,8 @@ nouveau_drm_vblank_disable(struct drm_device *dev, int head)
{
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm->device);
- if (drm->vblank[head].func)
- nouveau_event_put(pdisp->vblank, head, &drm->vblank[head]);
- else
- WARN_ON_ONCE(1);
- drm->vblank[head].func = NULL;
+
+ nouveau_event_put(pdisp->vblank, head, &drm->vblank[head]);
}
static u64
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/nouveau: Add install/remove semantics for event handlers
Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.
Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler lifetime, and distinguishes "one-of" event handlers
(such as gpio) from "many temporary" event handlers (such as uevent).
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 63 +++---
.../gpu/drm/nouveau/core/engine/software/nv50.c| 31 +--
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 31 +--
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 +++
.../gpu/drm/nouveau/core/include/engine/software.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 17 +-
7 files changed, 140 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 0a65ede..4cd1ebe 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,19 +23,60 @@
#include
#include
+void
+nouveau_event_handler_install(struct nouveau_event *event, int index,
+ int (*func)(struct nouveau_eventh*, int),
+ void *priv, struct nouveau_eventh *handler)
+{
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ handler->func = func;
+ handler->priv = priv;
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_add(&handler->head, &event->index[index].list);
+ spin_unlock_irqrestore(&event->lock, flags);
+}
+
+void
+nouveau_event_handler_remove(struct nouveau_event *event, int index,
+struct nouveau_eventh *handler)
+{
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_del(&handler->head);
+ spin_unlock_irqrestore(&event->lock, flags);
+}
+
int
nouveau_event_handler_create(struct nouveau_event *event, int index,
int (*func)(struct nouveau_eventh*, int),
void *priv, struct nouveau_eventh **phandler)
{
struct nouveau_eventh *handler;
+ unsigned long flags;
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
handler->func = func;
handler->priv = priv;
- nouveau_event_get(event, index, handler);
+ __set_bit(NVKM_EVENT_ENABLE, &handler->flags);
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
+ }
+ spin_unlock_irqrestore(&event->lock, flags);
return 0;
}
@@ -43,7 +84,18 @@ void
nouveau_event_handler_destroy(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
- nouveau_event_put(event, index, handler);
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ spin_lock_irqsave(&event->lock, flags);
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ list_del(&handler->head);
+ spin_unlock_irqrestore(&event->lock, flags);
kfree(handler);
}
@@ -56,7 +108,6 @@ nouveau_event_put_locked(struct nouveau_event *event, int
index,
if (event->disable)
event->disable(event, index);
}
- list_del(&handler->head);
}
}
@@ -85,7 +136,6 @@ nouveau_event_get(struct nouveau_event *event, int index,
spin_lock_irqsave(&event->lock, flags);
if (!__test_and_set_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- list_add(&handler->head, &event->index[index].list);
if (!event->index[index].refs++) {
if (event->enable)
event->enable(event, index);
@@ -105,8 +155,9 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
spin_lock_irqsave(&event->lock, flags);
list_for_each_entry_safe(handler, temp, &event->index[index].list,
head) {
- if (handler->func(handler, index) == NVKM_EVENT_DROP) {
- nouveau_event_put_locked(event, index, handler);
+ if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (handler->func(handler, index) == NVKM_EVENT_DROP)
+ nouveau_event_put_locked(event, index, handler);
}
}
[PATCH 6/9] drm/nouveau: Convert event handler list to RCU
Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event->lock with drm core's
dev->vblank_time_lock.
Fix vblank event deadlock by converting event handler list to RCU.
List updates remain serialized by event->lock.
List traversal & handler execution is lockless which prevents
inverted lock order problems with the drm core.
Safe deletion of the event handler is accomplished with
synchronize_rcu() for those handlers stored in nouveau_object-based
containers (nouveau_drm & nv50_/nvc0_software_context); otherwise,
with kfree_rcu (for nouveau_connector & uevent temporary handlers).
[1]
==
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
---
swapper/7/0 is trying to acquire lock:
(&(&dev->vblank_time_lock)->rlock){-.}, at: []
drm_handle_vblank+0x69/0x400 [drm]
but task is already holding lock:
(&(&event->lock)->rlock){-.}, at: []
nouveau_event_trigger+0x4d/0xd0 [nouveau]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&event->lock)->rlock){-.}:
[] lock_acquire+0x92/0x1f0
[] _raw_spin_lock_irqsave+0x46/0x60
[] nouveau_event_get+0x27/0xa0 [nouveau]
[] nouveau_drm_vblank_enable+0x8d/0xf0 [nouveau]
[] drm_vblank_get+0xf8/0x2c0 [drm]
[] drm_wait_vblank+0x84/0x6f0 [drm]
[] drm_ioctl+0x559/0x690 [drm]
[] do_vfs_ioctl+0x97/0x590
[] SyS_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
-> #0 (&(&dev->vblank_time_lock)->rlock){-.}:
[] __lock_acquire+0x1c43/0x1d30
[] lock_acquire+0x92/0x1f0
[] _raw_spin_lock_irqsave+0x46/0x60
[] drm_handle_vblank+0x69/0x400 [drm]
[] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
[] nouveau_event_trigger+0x90/0xd0 [nouveau]
[] nv50_disp_intr+0xdd/0x230 [nouveau]
[] nouveau_mc_intr+0xa1/0x100 [nouveau]
[] handle_irq_event_percpu+0x6c/0x3d0
[] handle_irq_event+0x48/0x70
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] ret_from_intr+0x0/0x13
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] start_secondary+0x255/0x25c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(&(&event->lock)->rlock);
lock(&(&dev->vblank_time_lock)->rlock);
lock(&(&event->lock)->rlock);
lock(&(&dev->vblank_time_lock)->rlock);
*** DEADLOCK ***
1 lock held by swapper/7/0:
#0: (&(&event->lock)->rlock){-.}, at: []
nouveau_event_trigger+0x4d/0xd0 [nouveau]
stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11
04/30/2012
821ccf60 8802bfdc3b08 81755f39 8802bfdc3b58
8174f526 0002 8802bfdc3be8 8802b330a7f8
8802b330a820 8802b330a7f8 0001
Call Trace:
[] dump_stack+0x19/0x1b
[] print_circular_bug+0x1fb/0x20c
[] __lock_acquire+0x1c43/0x1d30
[] ? trace_hardirqs_off+0xd/0x10
[] ? flat_send_IPI_mask+0x88/0xa0
[] lock_acquire+0x92/0x1f0
[] ? drm_handle_vblank+0x69/0x400 [drm]
[] _raw_spin_lock_irqsave+0x46/0x60
[] ? drm_handle_vblank+0x69/0x400 [drm]
[] drm_handle_vblank+0x69/0x400 [drm]
[] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
[] nouveau_event_trigger+0x90/0xd0 [nouveau]
[] nv50_disp_intr+0xdd/0x230 [nouveau]
[] ? _raw_spin_unlock_irqrestore+0x42/0x80
[] ? __hrtimer_start_range_ns+0x16c/0x530
[] nouveau_mc_intr+0xa1/0x100 [nouveau]
[] handle_irq_event_percpu+0x6c/0x3d0
[] handle_irq_event+0x48/0x70
[] ? handle_fasteoi_irq+0x1e/0x100
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] common_interrupt+0x6f/0x6f
[] ? default_idle+0x1d/0x290
[] ? default_idle+0x1b/0x290
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] ? clockevents_register_device+0xdc/0x140
[] start_secondary+0x255/0x25c
Reported-by: Dave Jones
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 22 +++---
.../gpu/drm/nouveau/core/engine/software/nv50.c| 1 +
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 1 +
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 4cd1ebe..ce0a0ef 100644
--- a/drive
[PATCH 7/9] drm/nouveau: Fold nouveau_event_put_locked into caller
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index ce0a0ef..45bcb37 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -100,18 +100,6 @@ nouveau_event_handler_destroy(struct nouveau_event *event,
int index,
kfree_rcu(handler, rcu);
}
-static void
-nouveau_event_put_locked(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
-{
- if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- if (!--event->index[index].refs) {
- if (event->disable)
- event->disable(event, index);
- }
- }
-}
-
void
nouveau_event_put(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
@@ -122,7 +110,12 @@ nouveau_event_put(struct nouveau_event *event, int index,
return;
spin_lock_irqsave(&event->lock, flags);
- nouveau_event_put_locked(event, index, handler);
+ if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ }
spin_unlock_irqrestore(&event->lock, flags);
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/nouveau: Simplify event interface
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++-
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 11 ++-
drivers/gpu/drm/nouveau/core/include/core/event.h | 15 +
drivers/gpu/drm/nouveau/nouveau_connector.c| 5 +--
drivers/gpu/drm/nouveau/nouveau_display.c | 16 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_fence.c| 2 +-
8 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 45bcb37..b7d8ae1 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -34,6 +34,9 @@ nouveau_event_handler_install(struct nouveau_event *event,
int index,
if (index >= event->index_nr)
return;
+ handler->event = event;
+ handler->index = index;
+
handler->func = func;
handler->priv = priv;
@@ -43,12 +46,12 @@ nouveau_event_handler_install(struct nouveau_event *event,
int index,
}
void
-nouveau_event_handler_remove(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
+nouveau_event_handler_remove(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -67,6 +70,10 @@ nouveau_event_handler_create(struct nouveau_event *event,
int index,
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
+
+ handler->event = event;
+ handler->index = index;
+
handler->func = func;
handler->priv = priv;
__set_bit(NVKM_EVENT_ENABLE, &handler->flags);
@@ -82,13 +89,12 @@ nouveau_event_handler_create(struct nouveau_event *event,
int index,
}
void
-nouveau_event_handler_destroy(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_handler_destroy(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
- return;
spin_lock_irqsave(&event->lock, flags);
if (!--event->index[index].refs) {
@@ -101,12 +107,13 @@ nouveau_event_handler_destroy(struct nouveau_event
*event, int index,
}
void
-nouveau_event_put(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_put(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -120,12 +127,13 @@ nouveau_event_put(struct nouveau_event *event, int index,
}
void
-nouveau_event_get(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_get(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -150,7 +158,7 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
list_for_each_entry_rcu(handler, &event->index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
if (handler->func(handler, index) == NVKM_EVENT_DROP)
- nouveau_event_put(event, index, handler);
+ nouveau_event_put(handler);
}
}
rcu_read_unlock();
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index 87aeee1..e969f0c 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -92,12 +92,11 @@ nv50_software_mthd_vblsem_release(struct nouveau_object
*object, u32 mthd,
void *args, u32 size)
{
struct nv50_software_chan *chan = (void *)nv_engctx(object->parent);
- struct nouveau_disp *disp = nouveau_disp(object);
u32 crtc = *(u32 *)args;
if (crtc > 1)
return -EINVAL;
- nouveau_event_get(disp->vblank, crtc, &chan->base.vblank.event[crtc]);
+ nouveau_ev
[PATCH 9/9] drm/nouveau: Simplify event handler interface
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/nv50.c | 7 +++
drivers/gpu/drm/nouveau/core/engine/software/nvc0.c | 7 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 +++---
drivers/gpu/drm/nouveau/nouveau_connector.c | 9 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
7 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index b7d8ae1..1240fef 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
void
nouveau_event_handler_install(struct nouveau_event *event, int index,
- int (*func)(struct nouveau_eventh*, int),
+ int (*func)(struct nouveau_eventh*),
void *priv, struct nouveau_eventh *handler)
{
unsigned long flags;
@@ -61,7 +61,7 @@ nouveau_event_handler_remove(struct nouveau_eventh *handler)
int
nouveau_event_handler_create(struct nouveau_event *event, int index,
-int (*func)(struct nouveau_eventh*, int),
+int (*func)(struct nouveau_eventh*),
void *priv, struct nouveau_eventh **phandler)
{
struct nouveau_eventh *handler;
@@ -157,7 +157,7 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
rcu_read_lock();
list_for_each_entry_rcu(handler, &event->index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- if (handler->func(handler, index) == NVKM_EVENT_DROP)
+ if (handler->func(handler) == NVKM_EVENT_DROP)
nouveau_event_put(handler);
}
}
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index e969f0c..bf6f23b 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -131,10 +131,9 @@ nv50_software_sclass[] = {
**/
static int
-nv50_software_vblsem_release(struct nouveau_eventh *event, int head)
+nv50_software_vblsem_release(struct nouveau_eventh *handler)
{
- struct nouveau_software_chan *chan =
- container_of(event, struct nouveau_software_chan,
vblank.event[head]);
+ struct nouveau_software_chan *chan = handler->priv;
struct nv50_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);
@@ -172,7 +171,7 @@ nv50_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
nv50_software_vblsem_release,
- NULL,
+ chan,
&chan->base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
index d06658a..1a2a7a8 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
@@ -143,10 +143,9 @@ nvc0_software_sclass[] = {
**/
static int
-nvc0_software_vblsem_release(struct nouveau_eventh *event, int head)
+nvc0_software_vblsem_release(struct nouveau_eventh *handler)
{
- struct nouveau_software_chan *chan =
- container_of(event, struct nouveau_software_chan,
vblank.event[head]);
+ struct nouveau_software_chan *chan = handler->priv;
struct nvc0_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);
@@ -178,7 +177,7 @@ nvc0_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
nvc0_software_vblsem_release,
- NULL,
+ chan,
&chan->base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #6 from Marek Olšák --- Created attachment 84748 --> https://bugs.freedesktop.org/attachment.cgi?id=84748&action=edit possible fix Could you please test this patch? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #7 from Richard Van Den Boom --- I'll see what I can do. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #12 from Peter Kraus --- Hello, I guess I'm just really unlucky. Compilation of "required merge" according to git bisect fails with: CXXLDlibOSMesa.la /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_expr.o)' is incompatible with i386 output Which is similar to a bug report here: bug 50754. Adding those variables into the build script doesn't help (in fact, they've been in before). Looks like I'm stuffed yet again! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #8 from Richard Van Den Boom --- I did a git pull to be as possible up to date and applied the patch. It does indeed seem to fix Kwin crash at startup. Congratulations! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #9 from tux_mind ---
hello there, i'm having the same issue and i recompiled mesa with debugging
symbols.
i'm using mesa-9.2.0_rc1 on gentoo.
i attached gdb and i found that the issue is at
src/gallium/drivers/r600/r600_query.c:743.
735 void r600_init_query_functions(struct r600_context *rctx)
736 {
737 rctx->context.create_query = r600_create_query;
738 rctx->context.destroy_query = r600_destroy_query;
739 rctx->context.begin_query = r600_begin_query;
740 rctx->context.end_query = r600_end_query;
741 rctx->context.get_query_result = r600_get_query_result;
742
743 if (rctx->screen->info.r600_num_backends > 0)
breaking gdb on line 743 i got this: http://pastebin.com/A4JANB5F
as you can see rctx->screen is null ( 0x0 ), please, can you fix that?
i hope this helps.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67107] Xorg starts and crashes with DPM enable
https://bugs.freedesktop.org/show_bug.cgi?id=67107 --- Comment #7 from Christopher Chmielewski --- Created attachment 84753 --> https://bugs.freedesktop.org/attachment.cgi?id=84753&action=edit dmesg Like I said it freezes up my computer so I had to restart in single user mode so there might be some extra stuff at the bottom. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67107] Xorg starts and crashes with DPM enable
https://bugs.freedesktop.org/show_bug.cgi?id=67107 --- Comment #8 from Christopher Chmielewski --- Created attachment 84754 --> https://bugs.freedesktop.org/attachment.cgi?id=84754&action=edit xorg log Both the dmesg and xorg log are from rc7 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #12 from Brian Hall --- Bisect results below. According to my Xorg.0.log, my board is a "ATI Radeon HD 4200" (ChipID = 0x9710) and lspci calls it a RS880. 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 Author: Alex Deucher Date: Tue Jul 30 00:22:53 2013 -0400 drm/radeon/atom: initialize more atom interpretor elements to 0 commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream. The ProcessAuxChannel table on some rv635 boards assumes the divmul members are initialized to 0 otherwise we get an invalid fb offset since it has a bad mask set when setting the fb base. While here initialize all the atom interpretor elements to 0. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60639 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman :04 04 d2bb057047f71419a89def40e6e21dc948c5784c 7e49987ae73078e644723f0cb6c791e15e102ab0 Mdrivers -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Nouveau on ARM fixes
This is the first set of patches to make Nouveau work on Tegra. Those are only the obvious correctness fixes, a lot of optimization work remains to be done, but at least it's enough to get accel working and let the machine survive a piglit run. A new BO flag is introduced to allow userspace to hint the kernel about possible optimizations. Lucas Stach (6): drm/ttm: recognize ARM arch in ioprot handler drm/ttm: introduce dma cache sync helpers drm/nouveau: hook up cache sync functions drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS drm/nouveau: map IB write-combined drm/nouveau: use MSI interrupts drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 + drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 ++ drivers/gpu/drm/nouveau/nouveau_bo.c | 15 - drivers/gpu/drm/nouveau/nouveau_bo.h | 1 + drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_gem.c| 5 + drivers/gpu/drm/ttm/ttm_bo_util.c| 2 +- drivers/gpu/drm/ttm/ttm_tt.c | 25 + include/drm/ttm/ttm_bo_driver.h | 28 include/uapi/drm/nouveau_drm.h | 1 + 10 files changed, 95 insertions(+), 3 deletions(-) -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/nouveau: map IB write-combined
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e84f4c3..3b54e8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -114,7 +114,8 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nouveau_cli *cli,
if (nouveau_vram_pushbuf)
target = TTM_PL_FLAG_VRAM;
- ret = nouveau_bo_new(drm->dev, size, 0, target, 0, 0, NULL,
+ ret = nouveau_bo_new(drm->dev, size, 0, target, 0,
+ NOUVEAU_GEM_TILE_WCUS, NULL,
&chan->push.buffer);
if (ret == 0) {
ret = nouveau_bo_pin(chan->push.buffer, target);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/nouveau: use MSI interrupts
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include
+#include
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc->use_msi)
+ nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
+
if (intr) {
nv_error(pmc, "unknown intr 0x%08x\n", stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device->pdev->irq, pmc);
+ if (pmc->use_msi)
+ pci_disable_msi(device->pdev);
nouveau_subdev_destroy(&pmc->base);
}
@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct
nouveau_object *engine,
pmc->intr_map = intr_map;
+ pmc->use_msi = nouveau_boolopt(device->cfgopt, "NvMSI", true);
+ if (pmc->use_msi) {
+ ret = pci_enable_msi(device->pdev);
+ if (ret) {
+ pmc->use_msi = false;
+ } else {
+ nv_wr08(device, 0x00088068, 0xff);
+ nv_info(pmc, "MSI interrupts enabled\n");
+ }
+ }
+
ret = request_irq(device->pdev->irq, nouveau_mc_intr,
IRQF_SHARED, "nouveau", pmc);
if (ret < 0)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/ttm: recognize ARM arch in ioprot handler
Signed-off-by: Lucas Stach --- drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 319cf41..db15687 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -487,7 +487,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) pgprot_val(tmp) |= _PAGE_GUARDED; } #endif -#if defined(__ia64__) +#if defined(__ia64__) || defined(__arm__) if (caching_flags & TTM_PL_FLAG_WC) tmp = pgprot_writecombine(tmp); else -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/nouveau: hook up cache sync functions
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index af20fba..f4a2eb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -411,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
interruptible,
{
int ret;
+ if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
+ ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt
*)nvbo->bo.ttm,
+ &nouveau_bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev);
+
ret = ttm_bo_validate(&nvbo->bo, &nvbo->placement,
interruptible, no_wait_gpu);
if (ret)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 830cb7b..f632b92 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -901,6 +901,11 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
spin_unlock(&nvbo->bo.bdev->fence_lock);
drm_gem_object_unreference_unlocked(gem);
+
+ if (!ret && nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
+ ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
+ &dev->pdev->dev);
+
return ret;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/ttm: introduce dma cache sync helpers
On arches with non-coherent PCI, we need to flush caches ourselfes at
the appropriate places. Introduce two small helpers to make things easy
for TTM based drivers.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/ttm/ttm_tt.c| 25 +
include/drm/ttm/ttm_bo_driver.h | 28
2 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5e93a52..935e121 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -249,6 +250,30 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
}
EXPORT_SYMBOL(ttm_dma_tt_fini);
+void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+ int i;
+
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+ dma_sync_single_for_device(dev, ttm_dma->dma_address[i],
+ PAGE_SIZE, DMA_TO_DEVICE);
+ }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_device);
+
+void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+ int i;
+
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+ dma_sync_single_for_cpu(dev, ttm_dma->dma_address[i],
+ PAGE_SIZE, DMA_FROM_DEVICE);
+ }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_cpu);
+
void ttm_tt_unbind(struct ttm_tt *ttm)
{
int ret;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 984fc2d..db5f3b5 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
struct ttm_backend_func {
/**
@@ -681,6 +682,33 @@ extern int ttm_tt_set_placement_caching(struct ttm_tt
*ttm, uint32_t placement);
extern int ttm_tt_swapout(struct ttm_tt *ttm,
struct file *persistent_swap_storage);
+/**
+ * ttm_dma_tt_cache_sync_for_device:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device to which to sync.
+ *
+ * This function will flush the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an
(almost)
+ * noop. This makes sure that data written by the CPU is visible to the device.
+ */
+extern void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+struct device *dev);
+
+/**
+ * ttm_dma_tt_cache_sync_for_cpu:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device from which to sync.
+ *
+ * This function will invalidate the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an
(almost)
+ * noop. This makes sure that the CPU does not read any stale cached or
+ * prefetched data.
+ */
+extern void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+ struct device *dev);
+
/*
* ttm_bo.c
*/
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from those resources.
Signed-off-by: Lucas Stach
---
On x86 an optimized userspace can save up on snoop traffic in the
system, on ARM the benefits are potentially much larger, as we can save
the manual cache flush/invalidate.
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
include/uapi/drm/nouveau_drm.h | 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f4a2eb9..c5fcbcc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
nouveau_bo_fixup_align(nvbo, flags, &align, &size);
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
+
+ if (tile_flags & NOUVEAU_GEM_TILE_WCUS)
+ nvbo->valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ else
+ nvbo->valid_caching = TTM_PL_MASK_CACHING;
+
nouveau_bo_placement_set(nvbo, flags, 0);
acc_size = ttm_bo_dma_acc_size(&drm->ttm.bdev, size,
@@ -292,7 +298,7 @@ void
nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
{
struct ttm_placement *pl = &nvbo->placement;
- uint32_t flags = TTM_PL_MASK_CACHING |
+ uint32_t flags = nvbo->valid_caching |
(nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
pl->placement = nvbo->placements;
@@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
+ if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED))
+ vma->access |= NV_MEM_ACCESS_NOSNOOP;
+
if (node->sg)
nouveau_vm_map_sg_table(vma, 0, size, node);
else
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 653dbbb..2ecf8b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -9,6 +9,7 @@ struct nouveau_bo {
struct ttm_buffer_object bo;
struct ttm_placement placement;
u32 valid_domains;
+ u32 valid_caching;
u32 placements[3];
u32 busy_placements[3];
struct ttm_bo_kmap_obj kmap;
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 2a5769f..4948eee2 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -36,6 +36,7 @@
#define NOUVEAU_GEM_TILE_32BPP 0x0002
#define NOUVEAU_GEM_TILE_ZETA0x0004
#define NOUVEAU_GEM_TILE_NONCONTIG 0x0008
+#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, unsnooped */
struct drm_nouveau_gem_info {
uint32_t handle;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #10 from tux_mind --- (In reply to comment #3) > I think the problem is that egl_gallium.so links both radeonsi and r600g, > which have some conflicting symbols. you're right! http://pastebin.com/Zq3NDDeX i'm patching mesa 9.2.0_rc1 to get this working. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #11 from tux_mind --- Created attachment 84756 --> https://bugs.freedesktop.org/attachment.cgi?id=84756&action=edit fix multiple symbols bug -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Check return value of anon_inode_getfile
anon_inode_getfile might fail, so check its return value.
Signed-off-by: Tuomas Tynkkynen
---
drivers/base/dma-buf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1219ab7..2d5ac1a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -133,7 +133,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
-
+ if (IS_ERR(file)) {
+ kfree(dmabuf);
+ return ERR_CAST(file);
+ }
dmabuf->file = file;
mutex_init(&dmabuf->lock);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #20 from Daniel T. --- Hi Alex, I with the patch you have posted (commnet #19) against 3.10.9 , I have so far been able to suspend and resume about 8 times without issue! Before the first try would always fail. This part seems to be solved you can add my Tested-by: Daniel Tobias dan.g@gmail.com I have however got warnings about low memory corruption caused by bios, doesnt seem to cause any issues however [ 120.373369] Corrupted low memory at c0009ff4 (9ff4 phys) = 0cd7 [ 120.375589] Corrupted low memory at c0009ff8 (9ff8 phys) = 0100 [ 120.377841] [ cut here ] [ 120.380103] WARNING: at arch/x86/kernel/check.c:140 check_for_bios_corruption+0xbe/0xd0() [ 120.382386] Memory corruption detected in low memory [ 120.384616] Modules linked in: [ 120.386901] CPU: 0 PID: 190 Comm: kworker/0:3 Not tainted 3.10.9-ARCH #1 [ 120.389250] Hardware name: /D101GGC , BIOS GC11010N.86A.0313.2006.0915.1840 09/15/2006 [ 120.391682] Workqueue: events check_corruption [ 120.394125] f363fecc f363fecc f363fe94 c16ad588 f363febc c103af4e c1815f00 f363fee8 [ 120.396693] 008c c102f48e c102f48e c001 c1a38570 f363fed4 c103afa3 [ 120.399336] 0009 f363fecc c1815f00 f363fee8 f363fefc c102f48e c180deed 008c [ 120.402004] Call Trace: [ 120.404622] [] dump_stack+0x16/0x18 [ 120.407244] [] warn_slowpath_common+0x5e/0x80 [ 120.409884] [] ? check_for_bios_corruption+0xbe/0xd0 [ 120.412562] [] ? check_for_bios_corruption+0xbe/0xd0 [ 120.415234] [] warn_slowpath_fmt+0x33/0x40 [ 120.417846] [] check_for_bios_corruption+0xbe/0xd0 [ 120.420536] [] check_corruption+0x10/0x40 [ 120.423224] [] process_one_work+0x107/0x380 [ 120.425944] [] worker_thread+0x101/0x340 [ 120.428678] [] ? manage_workers.isra.26+0x250/0x250 [ 120.431440] [] kthread+0x94/0xa0 [ 120.434116] [] ? down_interruptible+0x20/0x50 [ 120.436897] [] ret_from_kernel_thread+0x1b/0x28 [ 120.439745] [] ? kthread_create_on_node+0xc0/0xc0 [ 120.442585] ---[ end trace 81f23fa39f4c88a9 ]--- If you need any more info let me know. thanks -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> > Op 22-08-13 02:10, Ilia Mirkin schreef:
> > > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > > set, it will do a null deref down the line. Warn on that condition and
> > > return an error.
> > >
> > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> > >
> > > Reported-by: Pasi Kärkkäinen
> > > Tested-by: Pasi Kärkkäinen
> > > Signed-off-by: Ilia Mirkin
> > > Cc: # 3.8+
> > > ---
> > >
> > > I don't exactly understand what's going on, but this is just a
> > > straightforward way to avoid a null deref that you see happens in the
> > > bug. I haven't figured out the root cause of this, but it's getting
> > > well into the "I have no idea how TTM works" space. However this seems
> > > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > > node->pages as a list down, which will be dereferenced by
> > > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > > dereferencing not happen, but it definitely was happening here, as you
> > > can see in the bug.
> > >
> > > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > > since like I hope I was able to convey above, I'm just not really sure :)
> > Not it really isn't appropriate..
> >
> > You'd have to call call nouveau_vm_map_sg_table instead, the only place
> > that doesn't handle that correctly
> > is where it's not expected to be called.
> >
> > Here, have a completely untested patch to fix things...
> >
>
> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify
> the patch a bit to make it apply there..
> I've attached the modified copy that applies to 3.10.9, hopefully I did the
> backport correctly.
>
> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and
> I get this error in dmesg:
>
> [ 76.105643] nouveau W[ DRM] Trying to create a fb in vram with
> valid_domains=0004
>
> Does that help?
>
Any comments?
Maarten's patch works for me, I get that warning instead of a kernel crash,
but it's also a bigger change that doesn't apply to older kernels as-is.
Ilia's original patch in this thread can be applied to older kernels as-is,
and it also prevents the kernel crash from happening.
Should we get both applied, so Ilia's patch can be CC'd to stable ?
-- Pasi
> ---
> linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig
> 2013-07-01 01:13:29.0 +0300
> +++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c
> 2013-08-23 19:56:52.038234281 +0300
> @@ -137,18 +137,31 @@
> {
> struct nouveau_framebuffer *nouveau_fb;
> struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
> int ret;
>
> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> if (!gem)
> return ERR_PTR(-ENOENT);
>
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + drm_gem_object_unreference(gem);
> + return ERR_PTR(ret);
> + }
> +
> nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> - if (!nouveau_fb)
> + if (!nouveau_fb) {
> + drm_gem_object_unreference(gem);
> return ERR_PTR(-ENOMEM);
> + }
>
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd,
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
> if (ret) {
> + kfree(nouveau_fb);
> drm_gem_object_unreference(gem);
> return ERR_PTR(ret);
> }
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
trees for secondary powerdown
Hi Takashi, I've put two branches in my repo, http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge git://people.freedesktop.org/~airlied/linux is the tree. The second tree is just the vga switcheroo and sound patch, I've changed one line from the previous posted patch to reinstate the irq handler check for runtime pm, but only for cards with the runtime pm flag. Can you see if this merges into your tree okay? if so we can both merge that branch to our trees and I'll build on top of it. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #11 from Brian Hall --- Working the bisection now, may take me a day or two. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort
https://bugzilla.kernel.org/show_bug.cgi?id=60639 --- Comment #11 from douglas_peale at yahoo.com --- Created attachment 107330 --> https://bugzilla.kernel.org/attachment.cgi?id=107330&action=edit Requested rom dump Requested file. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #17 from Tom Stellard --- (In reply to comment #15) > r600g initializes LLVM without first setting the > llvm::DisablePrettyStackTrace variable to true. If this variable is false > (the default), LLVM will register a bunch of signal handlers, including for > SIGXCPU and SIGPWR, both of which are used by Mono's garbage collector. > > gallivm correctly sets llvm::DisablePrettyStackTrace to true, but it runs > after r600g has already started calling into LLVM and the signal handlers > have been registered. > > If you set a breakpoint on r600_create_context, manually set > llvm::DisablePrettyStackTrace to true and then continue, the application > will function correctly. I tested this using Fractal (a Unity game which > deadlocks in sem_wait on startup), Bastion (a MonoGame, also deadlocks in > sem_wait), and RepetierHost (an OpenTK app which dies in the SIGXCPU handler > at startup). Thanks for tracking this down. I think we'll need to extend the LLVM C API in order to get access to this variable. However, looking through the LLVM code it looks like the PrettyStackTrace handler is registered by a static initializer, so I wonder if setting this variable is enough and if we can guarantee that r600g will set this variable before the handler is initialized. Also, this seems to me like it is a bug in LLVM. Is it common practice for libraries to override signal handlers of applications? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/43bbac3a/attachment.html>
[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> Sent: Friday, August 23, 2013 3:35 PM
> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at
> gmail.com;
> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
> patches at linaro.org; linaro-dev at lists.linaro.org
> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
> contiguous memory for gem_dumb_create
>
> To address the case where physically contiguous memory MAY NOT be a
> mandatory
> requirement for framebuffer for the application calling
> exynos_drm_gem_dumb_create,
> the patch adds a feature to get non physically contiguous memory for
> framebuffer,
> if physically contiguous memory allocation fails and if IOMMU is
supported.
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 2eabe1a..66d1b40 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -17,6 +17,7 @@
> #include "exynos_drm_drv.h"
> #include "exynos_drm_gem.h"
> #include "exynos_drm_buf.h"
> +#include "exynos_drm_iommu.h"
>
> static unsigned int convert_to_vm_err_msg(int msg)
> {
> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
> *file_priv,
>
> exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
> EXYNOS_BO_WC, args->size);
> + /*
> + * If physically contiguous memory allocation fails and if IOMMU is
> + * supported then try to get buffer from non physically contiguous
> + * memory area.
> + */
> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
> + dev_warn(dev->dev, "contiguous FB allocation failed, falling
> back to non-contiguous\n");
> + exynos_gem_obj = exynos_drm_gem_create(dev,
> + EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
> + args->size);
> + }
> +
> if (IS_ERR(exynos_gem_obj))
> return PTR_ERR(exynos_gem_obj);
>
> --
> 1.7.9.5
[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
> -Original Message- > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc- > owner at vger.kernel.org] On Behalf Of Andrzej Hajda > Sent: Wednesday, August 21, 2013 11:22 PM > To: open list:DRM DRIVERS FOR E... > Cc: Andrzej Hajda; Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park; > David Airlie; moderated list:ARM/S5P EXYNOS AR...; t.figa at samsung.com; > s.nawrocki at samsung.com > Subject: [PATCH 0/3] drm/exynos: fimd: get signal polarities from device > tree > > Hi, > > This patch series adds signal polarities parsing from display-timings > devicetree node. To do it efficiently struct fb_videomode is replaced > with struct videomode and some additional code cleaning is performed. > Good patch set. Applied. Thanks, Inki Dae > The patches are for drm-exynos/exynos-drm-next branch. > > Regards > Andrzej Hajda > > Andrzej Hajda (3): > drm/exynos: fimd: replace struct fb_videomode with videomode > drm/exynos: fimd: get signal polarities from device tree > drm/exynos: fimd: move platform data parsing to separate function > > drivers/gpu/drm/exynos/exynos_drm_connector.c | 33 + > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 189 +- > > include/drm/exynos_drm.h | 3 +- > 3 files changed, 103 insertions(+), 122 deletions(-) > > -- > 1.8.1.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung- > soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
Hi Sachin,
Could you rebase your patch set to the below patch series?
[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
Your patch set is conflicted.
Thanks,
Inki Dae
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Thursday, August 22, 2013 2:45 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com; sw0312.kim at
> samsung.com;
> sachin.kamat at linaro.org; patches at linaro.org
> Subject: [PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
>
> Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
> for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
> all the conditional macros and make the driver DT only.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54
+++---
>
> 1 file changed, 13 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index f8889d2..90da9ef 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -123,7 +123,6 @@ struct fimd_context {
> struct fimd_driver_data *driver_data;
> };
>
> -#ifdef CONFIG_OF
> static const struct of_device_id fimd_driver_dt_match[] = {
> { .compatible = "samsung,s3c6400-fimd",
> .data = &s3c64xx_fimd_driver_data },
> @@ -133,21 +132,14 @@ static const struct of_device_id
> fimd_driver_dt_match[] = {
> .data = &exynos5_fimd_driver_data },
> {},
> };
> -#endif
>
> static inline struct fimd_driver_data *drm_fimd_get_driver_data(
> struct platform_device *pdev)
> {
> -#ifdef CONFIG_OF
> const struct of_device_id *of_id =
> of_match_device(fimd_driver_dt_match, &pdev->dev);
>
> - if (of_id)
> - return (struct fimd_driver_data *)of_id->data;
> -#endif
> -
> - return (struct fimd_driver_data *)
> - platform_get_device_id(pdev)->driver_data;
> + return (struct fimd_driver_data *)of_id->data;
> }
>
> static bool fimd_display_is_connected(struct device *dev)
> @@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
> int win;
> int ret = -EINVAL;
>
> - if (dev->of_node) {
> - pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata)
> - return -ENOMEM;
> + if (!dev->of_node)
> + return -ENODEV;
>
> - ret = of_get_fb_videomode(dev->of_node,
&pdata->panel.timing,
> - OF_USE_NATIVE_MODE);
> - if (ret) {
> - DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
ret);
> - return ret;
> - }
> - } else {
> - pdata = dev->platform_data;
> - if (!pdata) {
> - DRM_ERROR("no platform data specified\n");
> - return -EINVAL;
> - }
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
> + OF_USE_NATIVE_MODE);
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
> + return ret;
> }
>
> panel = &pdata->panel;
> @@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
> }
> #endif
>
> -static struct platform_device_id fimd_driver_ids[] = {
> - {
> - .name = "s3c64xx-fb",
> - .driver_data= (unsigned long)&s3c64xx_fimd_driver_data,
> - }, {
> - .name = "exynos4-fb",
> - .driver_data= (unsigned long)&exynos4_fimd_driver_data,
> - }, {
> - .name = "exynos5-fb",
> - .driver_data= (unsigned long)&exynos5_fimd_driver_data,
> - },
> - {},
> -};
> -
> static const struct dev_pm_ops fimd_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
> SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
> @@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
> struct platform_driver fimd_driver = {
> .probe = fimd_probe,
> .remove = fimd_remove,
> - .id_table = fimd_driver_ids,
> .driver = {
> .name = "exynos4-fb",
> .owner = THIS_MODULE,
> .pm = &fimd_pm_ops,
> - .of_match_table = of_match_ptr(fimd_driver_dt_match),
> + .of_match_table = fimd_driver_dt_match,
> },
> };
> --
> 1.7.9.5
[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create
One more thing, changed the subject to "Consider fallback option to
allocation fail". The subject is too long :)
Thanks,
Inki Dae
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Tuesday, August 27, 2013 12:05 PM
> To: Inki Dae
> Cc: DRI mailing list; kgene.kim; Sylwester Nawrocki; Rob Clark; Tomasz
> Figa; Laurent Pinchart; Patch Tracking; linaro-dev at lists.linaro.org; sunil
> joshi; linux-samsung-soc at vger.kernel.org
> Subject: Re: [PATCH] drm/exynos: Add fallback option to get non physically
> contiguous memory for gem_dumb_create
>
> Thanks.
>
> On 27 August 2013 08:14, Inki Dae wrote:
> > Applied.
> >
> > Thanks,
> > Inki Dae
> >
> >> -Original Message-
> >> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> >> Sent: Friday, August 23, 2013 3:35 PM
> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> >> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at
> >> gmail.com;
> >> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
> >> patches at linaro.org; linaro-dev at lists.linaro.org
> >> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
> >> contiguous memory for gem_dumb_create
> >>
> >> To address the case where physically contiguous memory MAY NOT be a
> >> mandatory
> >> requirement for framebuffer for the application calling
> >> exynos_drm_gem_dumb_create,
> >> the patch adds a feature to get non physically contiguous memory for
> >> framebuffer,
> >> if physically contiguous memory allocation fails and if IOMMU is
> > supported.
> >>
> >> Signed-off-by: Vikas Sajjan
> >> Signed-off-by: Arun Kumar
> >> ---
> >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> index 2eabe1a..66d1b40 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> @@ -17,6 +17,7 @@
> >> #include "exynos_drm_drv.h"
> >> #include "exynos_drm_gem.h"
> >> #include "exynos_drm_buf.h"
> >> +#include "exynos_drm_iommu.h"
> >>
> >> static unsigned int convert_to_vm_err_msg(int msg)
> >> {
> >> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
> >> *file_priv,
> >>
> >> exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
> >> EXYNOS_BO_WC,
args->size);
> >> + /*
> >> + * If physically contiguous memory allocation fails and if IOMMU
> is
> >> + * supported then try to get buffer from non physically
contiguous
> >> + * memory area.
> >> + */
> >> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
> >> + dev_warn(dev->dev, "contiguous FB allocation failed,
falling
> >> back to non-contiguous\n");
> >> + exynos_gem_obj = exynos_drm_gem_create(dev,
> >> + EXYNOS_BO_NONCONTIG |
EXYNOS_BO_WC,
> >> + args->size);
> >> + }
> >> +
> >> if (IS_ERR(exynos_gem_obj))
> >> return PTR_ERR(exynos_gem_obj);
> >>
> >> --
> >> 1.7.9.5
> >
>
>
>
> --
> Thanks and Regards
> Vikas Sajjan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #7 from Alexandre Demers --- Hi Alex. I'm about to test your suggestion. Meanwhile, I identified the original commit that broke the driver before being fixed by f90555cbe629e14c6af1dcec1933a3833ecd321f (but ending by the display hanging, eventhough I can connect through ssh) So the first bad commit was: 7ad8d0687bb5030c3328bc7229a3183ce179ab25 is the first bad commit commit 7ad8d0687bb5030c3328bc7229a3183ce179ab25 Author: Alex Deucher Date: Mon Jul 1 16:07:18 2013 -0400 drm/radeon/dpm: re-enable state transitions for Cayman Was disabled due to stability issues on certain boards caused by the a bug in the parsing of the atom mc reg tables. That's fixed now so re-enable. Signed-off-by: Alex Deucher :04 04 de8dfc2a15d5114e81636811d7e3b39c15fc515b d0e1ee828f10456d39e2ab30cc6598203e50fa6e Mdrivers Heading for your suggestion right away with http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.12-wip-gcc-fixes. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a1803f5/attachment.html>
[Bug 68544] cannot build mesa 9.2 without llvm
https://bugs.freedesktop.org/show_bug.cgi?id=68544 Matt Turner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|dri-devel at lists.freedesktop |mattst88 at gmail.com |.org| CC||dri-devel at lists.freedesktop ||.org --- Comment #7 from Matt Turner --- Committed, thanks! Should get picked to the 9.2 branch before release. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/c9adfdaf/attachment.html>
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #18 from Nicholas Miell --- (In reply to comment #17) > Thanks for tracking this down. I think we'll need to extend the LLVM C API > in order to get access to this variable. However, looking through the LLVM > code it looks like the PrettyStackTrace handler is registered by a static > initializer, so I wonder if setting this variable is enough and if we can > guarantee that r600g will set this variable before the handler is > initialized. I don't think this is true -- IIRC, all the stack traces I saw were the result of one of the runOnFunction methods (either BBPassManager or FPPassManager, I wasn't paying attention) creating a PassManagerPrettyStackEntry object. > Also, this seems to me like it is a bug in LLVM. Is it common practice for > libraries to override signal handlers of applications? Common enough that both Mono and LLVM stomp on each other, but its unambiguously wrong for a shared library to globally modify signal handlers. (Temporarily setting a new handler on entry to your library and later restoring the saved handler before returning is fine, but that only works in the single-threaded case since handlers aren't per-thread. Arguably modern applications shouldn't use any signals at all.) Mono (generally) gets away with it because it uses crazy signals that applications never touch (SIGPWR is only sent to PID 1 by the kernel on power failure, SIGXCPU is relic of obsolete job billing infrastructure that nobody uses), but had the bad luck of LLVM deciding to future-proof itself against all possible fatal signals. If I were to be prescriptive, llvm::DisablePrettyStackTrace should be true by default, should only ever be set by clang, and shouldn't be a global variable. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/b765e6a2/attachment-0001.html>
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #3 from Richard Van Den Boom --- I'm no git expert but this seems simple enough. It may take a bit of time though as this is a slow laptop (8 years old). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d237d5c4/attachment.html>
[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
Hi Inki,
Sure, I will rebase and send tomorrow.
Thanks
On 27 August 2013 08:18, Inki Dae wrote:
> Hi Sachin,
>
> Could you rebase your patch set to the below patch series?
> [PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
>
> Your patch set is conflicted.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Thursday, August 22, 2013 2:45 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com; sw0312.kim at
>> samsung.com;
>> sachin.kamat at linaro.org; patches at linaro.org
>> Subject: [PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
>>
>> Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
>> for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
>> all the conditional macros and make the driver DT only.
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54
> +++---
>>
>> 1 file changed, 13 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index f8889d2..90da9ef 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -123,7 +123,6 @@ struct fimd_context {
>> struct fimd_driver_data *driver_data;
>> };
>>
>> -#ifdef CONFIG_OF
>> static const struct of_device_id fimd_driver_dt_match[] = {
>> { .compatible = "samsung,s3c6400-fimd",
>> .data = &s3c64xx_fimd_driver_data },
>> @@ -133,21 +132,14 @@ static const struct of_device_id
>> fimd_driver_dt_match[] = {
>> .data = &exynos5_fimd_driver_data },
>> {},
>> };
>> -#endif
>>
>> static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>> struct platform_device *pdev)
>> {
>> -#ifdef CONFIG_OF
>> const struct of_device_id *of_id =
>> of_match_device(fimd_driver_dt_match, &pdev->dev);
>>
>> - if (of_id)
>> - return (struct fimd_driver_data *)of_id->data;
>> -#endif
>> -
>> - return (struct fimd_driver_data *)
>> - platform_get_device_id(pdev)->driver_data;
>> + return (struct fimd_driver_data *)of_id->data;
>> }
>>
>> static bool fimd_display_is_connected(struct device *dev)
>> @@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
>> int win;
>> int ret = -EINVAL;
>>
>> - if (dev->of_node) {
>> - pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> - if (!pdata)
>> - return -ENOMEM;
>> + if (!dev->of_node)
>> + return -ENODEV;
>>
>> - ret = of_get_fb_videomode(dev->of_node,
> &pdata->panel.timing,
>> - OF_USE_NATIVE_MODE);
>> - if (ret) {
>> - DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
> ret);
>> - return ret;
>> - }
>> - } else {
>> - pdata = dev->platform_data;
>> - if (!pdata) {
>> - DRM_ERROR("no platform data specified\n");
>> - return -EINVAL;
>> - }
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata)
>> + return -ENOMEM;
>> +
>> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
>> + OF_USE_NATIVE_MODE);
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
>> + return ret;
>> }
>>
>> panel = &pdata->panel;
>> @@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
>> }
>> #endif
>>
>> -static struct platform_device_id fimd_driver_ids[] = {
>> - {
>> - .name = "s3c64xx-fb",
>> - .driver_data= (unsigned long)&s3c64xx_fimd_driver_data,
>> - }, {
>> - .name = "exynos4-fb",
>> - .driver_data= (unsigned long)&exynos4_fimd_driver_data,
>> - }, {
>> - .name = "exynos5-fb",
>> - .driver_data= (unsigned long)&exynos5_fimd_driver_data,
>> - },
>> - {},
>> -};
>> -
>> static const struct dev_pm_ops fimd_pm_ops = {
>> SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
>> SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
>> @@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
>> struct platform_driver fimd_driver = {
>> .probe = fimd_probe,
>> .remove = fimd_remove,
>> - .id_table = fimd_driver_ids,
>> .driver = {
>> .name = "exynos4-fb",
>> .owner = THIS_MODULE,
>> .pm = &fimd_pm_ops,
>> - .of_match_table = of_match_ptr(fimd_driver_dt_match),
>> + .of_match_table = fimd_d
[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create
Thanks.
On 27 August 2013 08:14, Inki Dae wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> Sent: Friday, August 23, 2013 3:35 PM
>> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at
>> gmail.com;
>> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
>> patches at linaro.org; linaro-dev at lists.linaro.org
>> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
>> contiguous memory for gem_dumb_create
>>
>> To address the case where physically contiguous memory MAY NOT be a
>> mandatory
>> requirement for framebuffer for the application calling
>> exynos_drm_gem_dumb_create,
>> the patch adds a feature to get non physically contiguous memory for
>> framebuffer,
>> if physically contiguous memory allocation fails and if IOMMU is
> supported.
>>
>> Signed-off-by: Vikas Sajjan
>> Signed-off-by: Arun Kumar
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 2eabe1a..66d1b40 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -17,6 +17,7 @@
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_gem.h"
>> #include "exynos_drm_buf.h"
>> +#include "exynos_drm_iommu.h"
>>
>> static unsigned int convert_to_vm_err_msg(int msg)
>> {
>> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
>> *file_priv,
>>
>> exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
>> EXYNOS_BO_WC, args->size);
>> + /*
>> + * If physically contiguous memory allocation fails and if IOMMU is
>> + * supported then try to get buffer from non physically contiguous
>> + * memory area.
>> + */
>> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
>> + dev_warn(dev->dev, "contiguous FB allocation failed, falling
>> back to non-contiguous\n");
>> + exynos_gem_obj = exynos_drm_gem_create(dev,
>> + EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
>> + args->size);
>> + }
>> +
>> if (IS_ERR(exynos_gem_obj))
>> return PTR_ERR(exynos_gem_obj);
>>
>> --
>> 1.7.9.5
>
--
Thanks and Regards
Vikas Sajjan
[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create
OK.
On 27 August 2013 09:44, Inki Dae wrote:
>
> One more thing, changed the subject to "Consider fallback option to
> allocation fail". The subject is too long :)
>
> Thanks,
> Inki Dae
>
>
>> -Original Message-
>> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
>> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
>> Sent: Tuesday, August 27, 2013 12:05 PM
>> To: Inki Dae
>> Cc: DRI mailing list; kgene.kim; Sylwester Nawrocki; Rob Clark; Tomasz
>> Figa; Laurent Pinchart; Patch Tracking; linaro-dev at lists.linaro.org; sunil
>> joshi; linux-samsung-soc at vger.kernel.org
>> Subject: Re: [PATCH] drm/exynos: Add fallback option to get non physically
>> contiguous memory for gem_dumb_create
>>
>> Thanks.
>>
>> On 27 August 2013 08:14, Inki Dae wrote:
>> > Applied.
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> >> -Original Message-
>> >> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> >> Sent: Friday, August 23, 2013 3:35 PM
>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> >> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at
>> >> gmail.com;
>> >> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
>> >> patches at linaro.org; linaro-dev at lists.linaro.org
>> >> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
>> >> contiguous memory for gem_dumb_create
>> >>
>> >> To address the case where physically contiguous memory MAY NOT be a
>> >> mandatory
>> >> requirement for framebuffer for the application calling
>> >> exynos_drm_gem_dumb_create,
>> >> the patch adds a feature to get non physically contiguous memory for
>> >> framebuffer,
>> >> if physically contiguous memory allocation fails and if IOMMU is
>> > supported.
>> >>
>> >> Signed-off-by: Vikas Sajjan
>> >> Signed-off-by: Arun Kumar
>> >> ---
>> >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 13 +
>> >> 1 file changed, 13 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> index 2eabe1a..66d1b40 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> @@ -17,6 +17,7 @@
>> >> #include "exynos_drm_drv.h"
>> >> #include "exynos_drm_gem.h"
>> >> #include "exynos_drm_buf.h"
>> >> +#include "exynos_drm_iommu.h"
>> >>
>> >> static unsigned int convert_to_vm_err_msg(int msg)
>> >> {
>> >> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
>> >> *file_priv,
>> >>
>> >> exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
>> >> EXYNOS_BO_WC,
> args->size);
>> >> + /*
>> >> + * If physically contiguous memory allocation fails and if IOMMU
>> is
>> >> + * supported then try to get buffer from non physically
> contiguous
>> >> + * memory area.
>> >> + */
>> >> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
>> >> + dev_warn(dev->dev, "contiguous FB allocation failed,
> falling
>> >> back to non-contiguous\n");
>> >> + exynos_gem_obj = exynos_drm_gem_create(dev,
>> >> + EXYNOS_BO_NONCONTIG |
> EXYNOS_BO_WC,
>> >> + args->size);
>> >> + }
>> >> +
>> >> if (IS_ERR(exynos_gem_obj))
>> >> return PTR_ERR(exynos_gem_obj);
>> >>
>> >> --
>> >> 1.7.9.5
>> >
>>
>>
>>
>> --
>> Thanks and Regards
>> Vikas Sajjan
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
>> soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thanks and Regards
Vikas Sajjan
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #8 from Alexandre Demers --- Tested with http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.12-wip-gcc-fixes and it does exactly the same thing: it boots fine, show the login screen. I can even login in if it doesn't hang right away. Then, it will hang at some point (either at login screen or after loading the desktop). It displays generally grey vertical bars. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/1d56bbf1/attachment.html>
[Bug 67800] Computer freezes after idle for several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 --- Comment #10 from Kertesz Laszlo --- It froze after 1 days and 13 hours. Subsequent reboots all ended in freeze in 6-12 hours time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/03a08587/attachment.html>
[PATCH] host1x: hdmi: Make sure clock is enabled before dumping registers
On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote: > The debugfs register dumping function did not enable the HDMI clock. > This led to a possible system hang when reading the debugfs entry > while no HDMI cable was connected to the system. This patch makes > sure that the clock is enabled during the read. > > Signed-off-by: Mikko Perttunen > --- > drivers/gpu/host1x/drm/hdmi.c | 7 +++ > 1 file changed, 7 insertions(+) Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/f0e64604/attachment.pgp>
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann
wrote:
> the function imx_drm_driver_load() must have been called before
> calling imx_drm_add_crtc(), but the following hunk in the commit:
> @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
> unsigned long flags)
> */
> imxdrm->drm->vblank_disable_allowed = 1;
>
> + if (!imx_drm_device_get())
> + ret = -EINVAL;
> +
> ret = 0;
>
> err_init:
>
> makes imx_drm_add_crtc() bail out at:
>
> if (imxdrm->references) {
> ret = -EBUSY;
> goto err_busy;
> }
>
> Thus it is not possible to register any CRTCs.
Ok I've now read around a bit in the imx core and I think my call to rip
this out was right ;-)
If I understand stuff correctly you have a main driver plus a bunch of
encoder/crtc modules and you expect that everything gets loaded and then
only when the kms driver is first opened. The current drm core just
doesn't support hotplugging of encoder/crtc objects after driver init has
completed. If you try to do that it'll go down in flames due to all the
races involved.
So as a stopgap measuret I sugges you rip out the imxdrm->references
trickery since it won't actually protect you from anything truly nasty
happening. And I wouldn't worry about module unloading and refcounting for
now since core drm is terminally broken in that area already anyway.
Then we can move ahead and how to really fix this init ordering. So I
think we have another TODO here:
Cheers, Daniel
---
diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index f806415..f8ef245 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,6 +6,11 @@ TODO:
- Factor out more code to common helper functions
- decide where to put the base driver. It is not specific to a subsystem
and would be used by DRM/KMS and media/V4L2
+- Fix up the driver load sequence to make sure all submodules for
encoders/crtcs
+ are fully loaded before the drm driver is registered. Might require a core
drm
+ rework to break away the drm core init sequence from its midlayer drug and
+ assorted control inversion issues. Or we restructure imx to just built in
+ everything, dunno. Requested by Daniel Vetter
Missing features (not necessarily for moving out of staging):
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
Hi Daniel,
Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann
> wrote:
> > the function imx_drm_driver_load() must have been called before
> > calling imx_drm_add_crtc(), but the following hunk in the commit:
> > @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
> > unsigned long flags)
> > */
> > imxdrm->drm->vblank_disable_allowed = 1;
> >
> > + if (!imx_drm_device_get())
> > + ret = -EINVAL;
> > +
> > ret = 0;
> >
> > err_init:
> >
> > makes imx_drm_add_crtc() bail out at:
> >
> > if (imxdrm->references) {
> > ret = -EBUSY;
> > goto err_busy;
> > }
> >
> > Thus it is not possible to register any CRTCs.
>
> Ok I've now read around a bit in the imx core and I think my call to rip
> this out was right ;-)
>
> If I understand stuff correctly you have a main driver plus a bunch of
> encoder/crtc modules and you expect that everything gets loaded and then
> only when the kms driver is first opened. The current drm core just
> doesn't support hotplugging of encoder/crtc objects after driver init has
> completed. If you try to do that it'll go down in flames due to all the
> races involved.
>
You know the logic you broke here was just a moderately sane approach to
get around the monolithic DRM driver nonsense, while not having to use
real hotplug in DRM.
The thing is we don't know if we will ever have all submodules loaded,
as this driver is mostly used on embedded devices where people randomly
decide to exclude things from their kernel config, because they don't
use the feature on their board. The current logic is under the premise
that there are no early DRM clients in something like Plymouth, which is
a bit flaky, but worked very well for the targeted use-cases.
Regards,
Lucas
> So as a stopgap measuret I sugges you rip out the imxdrm->references
> trickery since it won't actually protect you from anything truly nasty
> happening. And I wouldn't worry about module unloading and refcounting for
> now since core drm is terminally broken in that area already anyway.
>
> Then we can move ahead and how to really fix this init ordering. So I
> think we have another TODO here:
>
> Cheers, Daniel
>
> ---
> diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
> index f806415..f8ef245 100644
> --- a/drivers/staging/imx-drm/TODO
> +++ b/drivers/staging/imx-drm/TODO
> @@ -6,6 +6,11 @@ TODO:
> - Factor out more code to common helper functions
> - decide where to put the base driver. It is not specific to a subsystem
>and would be used by DRM/KMS and media/V4L2
> +- Fix up the driver load sequence to make sure all submodules for
> encoders/crtcs
> + are fully loaded before the drm driver is registered. Might require a core
> drm
> + rework to break away the drm core init sequence from its midlayer drug and
> + assorted control inversion issues. Or we restructure imx to just built in
> + everything, dunno. Requested by Daniel Vetter
>
> Missing features (not necessarily for moving out of staging):
>
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[patch 1/2] gpu: host1x: fix an integer overflow check
On Fri, Aug 23, 2013 at 01:18:25PM +0300, Dan Carpenter wrote: > Tegra is a 32 bit arch. On 32 bit systems then size_t is 32 bits so > "total" will never be higher than UINT_MAX because of integer overflows. > We need cast to u64 first before doing the math. > > Also the addition earlier: > > unsigned int num_unpins = num_cmdbufs + num_relocs; > > That can overflow as well, but I think it's still safe because we check > both "num_cmdbufs" and "num_relocs" again in this test. > > Signed-off-by: Dan Carpenter > --- > This is something I spotted in code review. I can't actually compile > this code. I assume this overflow test has security implications. It did compile and looks good to me, so I've applied it. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/bf6a6e9c/attachment.pgp>
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach wrote: >> If I understand stuff correctly you have a main driver plus a bunch of >> encoder/crtc modules and you expect that everything gets loaded and then >> only when the kms driver is first opened. The current drm core just >> doesn't support hotplugging of encoder/crtc objects after driver init has >> completed. If you try to do that it'll go down in flames due to all the >> races involved. >> > You know the logic you broke here was just a moderately sane approach to > get around the monolithic DRM driver nonsense, while not having to use > real hotplug in DRM. > > The thing is we don't know if we will ever have all submodules loaded, > as this driver is mostly used on embedded devices where people randomly > decide to exclude things from their kernel config, because they don't > use the feature on their board. The current logic is under the premise > that there are no early DRM clients in something like Plymouth, which is > a bit flaky, but worked very well for the targeted use-cases. Imo the imxdrm->references logic is broken already and simply removing those checks would be the right course of action - pretending to have fixed races but not actually having fixed much is imo much worse than openly admitting that the code is racy and needs work. Wrt embedded guys shaving off a few kb by not loading a bunch of modules I think you should simply make that compile-time options instead of modules. More hassle but at least it should work. And if we ever see the need to hotplug crtcs I think the right way is to hotplug an entire drm driver. Connector/encoder hotplugging might eventually be required for real to support stuff like multi-stream DP, but until that happens I really don't see a need for funny games, especially on SoC boards where everything is soldered on and can't possibly be hotplugged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 David "okias" Heidelberger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from David "okias" Heidelberger --- it work well with 3.10, so it's fixed for me. Thank you. Closing bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d6c82343/attachment.html>
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: > On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach > wrote: > >> If I understand stuff correctly you have a main driver plus a bunch of > >> encoder/crtc modules and you expect that everything gets loaded and then > >> only when the kms driver is first opened. The current drm core just > >> doesn't support hotplugging of encoder/crtc objects after driver init has > >> completed. If you try to do that it'll go down in flames due to all the > >> races involved. > >> > > You know the logic you broke here was just a moderately sane approach to > > get around the monolithic DRM driver nonsense, while not having to use > > real hotplug in DRM. > > > > The thing is we don't know if we will ever have all submodules loaded, > > as this driver is mostly used on embedded devices where people randomly > > decide to exclude things from their kernel config, because they don't > > use the feature on their board. The current logic is under the premise > > that there are no early DRM clients in something like Plymouth, which is > > a bit flaky, but worked very well for the targeted use-cases. > > Imo the imxdrm->references logic is broken already and simply removing > those checks would be the right course of action - pretending to have > fixed races but not actually having fixed much is imo much worse than > openly admitting that the code is racy and needs work. > > Wrt embedded guys shaving off a few kb by not loading a bunch of > modules I think you should simply make that compile-time options > instead of modules. More hassle but at least it should work. It's not about the few kb. The problem is that our devices are not monolithic, but instead we have multiple devices in and around the SoC which form a DRM device. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[patch 2/2] gpu: host1x: returning success instead of -ENOMEM
On Fri, Aug 23, 2013 at 01:19:11PM +0300, Dan Carpenter wrote: > There is a mistake here so it returns PTR_ERR(NULL) which is success > instead of -ENOMEM. > > Signed-off-by: Dan Carpenter > --- > I can't compile this. Good catch! Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/8f7b12f5/attachment.pgp>
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter: > On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach > wrote: > >> If I understand stuff correctly you have a main driver plus a bunch of > >> encoder/crtc modules and you expect that everything gets loaded and then > >> only when the kms driver is first opened. The current drm core just > >> doesn't support hotplugging of encoder/crtc objects after driver init has > >> completed. If you try to do that it'll go down in flames due to all the > >> races involved. > >> > > You know the logic you broke here was just a moderately sane approach to > > get around the monolithic DRM driver nonsense, while not having to use > > real hotplug in DRM. > > > > The thing is we don't know if we will ever have all submodules loaded, > > as this driver is mostly used on embedded devices where people randomly > > decide to exclude things from their kernel config, because they don't > > use the feature on their board. The current logic is under the premise > > that there are no early DRM clients in something like Plymouth, which is > > a bit flaky, but worked very well for the targeted use-cases. > > Imo the imxdrm->references logic is broken already and simply removing > those checks would be the right course of action - pretending to have > fixed races but not actually having fixed much is imo much worse than > openly admitting that the code is racy and needs work. > I don't see how this is overly racy. We are doing delayed DRM device setup not delayed HW setup. We simply look around which modules are there and what DRM we can build up from them. With some small work we would even be able to make the Plymouth + modules in initrd case work. The only case that would not really be solvable without full hotplug is the Plymouth in initrd + modules on the late rootfs. > Wrt embedded guys shaving off a few kb by not loading a bunch of > modules I think you should simply make that compile-time options > instead of modules. More hassle but at least it should work. > This would be really moving in the wrong direction. We want to get more modular, not less. We have a lot different on- and off-chip encoders and other stuff where we want distinct drivers and not some cludged together thing. > And if we ever see the need to hotplug crtcs I think the right way is > to hotplug an entire drm driver. Connector/encoder hotplugging might > eventually be required for real to support stuff like multi-stream DP, > but until that happens I really don't see a need for funny games, > especially on SoC boards where everything is soldered on and can't > possibly be hotplugged. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH/RFC v3 06/19] video: display: OF support
Hi Laurent,
I have another small issue with the graph helpers below:
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
> +/*
> -
> * Graph Helpers
> */
>
> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> struct list_head *entities)
> }
> EXPORT_SYMBOL_GPL(display_entity_link_graph);
>
> +#ifdef CONFIG_OF
> +
> +static int display_of_entity_link_entity(struct device *dev,
> + struct display_entity *entity,
> + struct list_head *entities,
> + struct display_entity *root)
> +{
> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + const struct device_node *node = entity->dev->of_node;
> + struct media_entity *local = &entity->entity;
> + struct device_node *ep = NULL;
> + int ret = 0;
> +
> + dev_dbg(dev, "creating links for entity %s\n", local->name);
> +
> + while (1) {
> + struct media_entity *remote = NULL;
> + struct media_pad *remote_pad;
> + struct media_pad *local_pad;
> + struct display_of_link link;
> + struct display_entity *ent;
> + struct device_node *next;
> +
> + /* Get the next endpoint and parse its link. */
> + next = display_of_get_next_endpoint(node, ep);
> + if (next == NULL)
> + break;
> +
> + of_node_put(ep);
> + ep = next;
> +
> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> +
> + ret = display_of_parse_link(ep, &link);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse link for %s\n",
> + ep->full_name);
> + continue;
> + }
> +
> + /* Skip source pads, they will be processed from the other end
> of
> + * the link.
> + */
> + if (link.local_port >= local->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.local_port, link.local_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + local_pad = &local->pads[link.local_port];
> +
> + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> + dev_dbg(dev, "skipping source port %s:%u\n",
> + link.local_node->full_name, link.local_port);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + /* Find the remote entity. If not found, just skip the link as
> + * it goes out of scope of the entities handled by the notifier.
> + */
> + list_for_each_entry(ent, entities, list) {
> + if (ent->dev->of_node == link.remote_node) {
> + remote = &ent->entity;
> + break;
> + }
> + }
> +
> + if (root->dev->of_node == link.remote_node)
> + remote = &root->entity;
> +
> + if (remote == NULL) {
> + dev_dbg(dev, "no entity found for %s\n",
> + link.remote_node->full_name);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + if (link.remote_port >= remote->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.remote_port, link.remote_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + remote_pad = &remote->pads[link.remote_port];
> +
> + display_of_put_link(&link);
> +
> + /* Create the media link. */
> + dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> +
> + ret = media_entity_create_link(remote, remote_pad->index,
> +local, local_pad->index,
> +link_flags);
> + if (ret < 0) {
> + dev_err(dev,
> + "failed to create %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> + break;
> + }
> + }
> +
> + of_node_put(ep);
> + return ret;
> +}
> +
> +/**
> + * display_of_entity_link_graph - Link all entities
[PATCH 03/14] drm/edid: Parse the HDMI CEA block and look for 4k modes
On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
[...]
> + u8 vic;
> +
> + vic = db[9 + offset + i];
> +
> + vic--; /* VICs start at 1 */
This could've all gone on a single line, perhaps with the comment on
top, like so:
/* VICs start at 1 */
u8 vic = db[9 + offset + i] - 1;
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/59a1dfa4/attachment-0001.pgp>
HDMI 4k support v4
On Mon, Aug 19, 2013 at 04:58:51PM +0100, Damien Lespiau wrote: > Follow up on v3: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html > > Changes between v3 and v4: > - Future proof the sending of 3D_Ext_Data > - Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn, > renaming the hdmi_vendor_infoframe enum to hdmi_vendor_any_infoframe) > - Renamed HDMI_IDENTIFIER to HDMI_IEEE_OUI The series looks good to me. Thanks for doing this Damien! Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/2767d9a3/attachment.pgp>
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #4 from Richard Van Den Boom --- According to bisect, the commit that cause the crashes is this one : git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed # first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure that the stages setup outputs I've attached the full git bisect log output. Whatever Kwin does in the R300 driver, the above commit seems to trigger an issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/3a641401/attachment.html>
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #5 from Richard Van Den Boom --- Created attachment 84696 --> https://bugs.freedesktop.org/attachment.cgi?id=84696&action=edit Git bisect log output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/d37f5ef2/attachment.html>
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer wrote: > On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: >> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach >> wrote: >> >> If I understand stuff correctly you have a main driver plus a bunch of >> >> encoder/crtc modules and you expect that everything gets loaded and then >> >> only when the kms driver is first opened. The current drm core just >> >> doesn't support hotplugging of encoder/crtc objects after driver init has >> >> completed. If you try to do that it'll go down in flames due to all the >> >> races involved. >> >> >> > You know the logic you broke here was just a moderately sane approach to >> > get around the monolithic DRM driver nonsense, while not having to use >> > real hotplug in DRM. >> > >> > The thing is we don't know if we will ever have all submodules loaded, >> > as this driver is mostly used on embedded devices where people randomly >> > decide to exclude things from their kernel config, because they don't >> > use the feature on their board. The current logic is under the premise >> > that there are no early DRM clients in something like Plymouth, which is >> > a bit flaky, but worked very well for the targeted use-cases. >> >> Imo the imxdrm->references logic is broken already and simply removing >> those checks would be the right course of action - pretending to have >> fixed races but not actually having fixed much is imo much worse than >> openly admitting that the code is racy and needs work. >> >> Wrt embedded guys shaving off a few kb by not loading a bunch of >> modules I think you should simply make that compile-time options >> instead of modules. More hassle but at least it should work. > > It's not about the few kb. The problem is that our devices are not > monolithic, but instead we have multiple devices in and around the SoC > which form a DRM device. right, but the cores on the SoC, and even any external encoder chips, are not actually hot-pluggable. I have a similar scenario w/ msm drm, where there is the core display controller (for ex, 'mdp4'), plus hdmi/dsi/etc blocks around that (with their own irq, io/register region, etc). It would be nice if the kernel provided a better mechanism for composite drivers, but what I do is just register the platform drivers for those other blocks first (in the init code, before calling 'platform_driver_register(&msm_platform_driver)'. This way, if the device is actually present, I know before drm dev_load. I do not attempt to build hdmi/dsi/etc as separate modules. I could if I wanted to include/exclude them at compile time, but separate modules seems like a bad idea. BR, -R > Sascha > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark wrote: > On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer > wrote: >> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote: >>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach >>> wrote: >>> >> If I understand stuff correctly you have a main driver plus a bunch of >>> >> encoder/crtc modules and you expect that everything gets loaded and then >>> >> only when the kms driver is first opened. The current drm core just >>> >> doesn't support hotplugging of encoder/crtc objects after driver init has >>> >> completed. If you try to do that it'll go down in flames due to all the >>> >> races involved. >>> >> >>> > You know the logic you broke here was just a moderately sane approach to >>> > get around the monolithic DRM driver nonsense, while not having to use >>> > real hotplug in DRM. >>> > >>> > The thing is we don't know if we will ever have all submodules loaded, >>> > as this driver is mostly used on embedded devices where people randomly >>> > decide to exclude things from their kernel config, because they don't >>> > use the feature on their board. The current logic is under the premise >>> > that there are no early DRM clients in something like Plymouth, which is >>> > a bit flaky, but worked very well for the targeted use-cases. >>> >>> Imo the imxdrm->references logic is broken already and simply removing >>> those checks would be the right course of action - pretending to have >>> fixed races but not actually having fixed much is imo much worse than >>> openly admitting that the code is racy and needs work. >>> >>> Wrt embedded guys shaving off a few kb by not loading a bunch of >>> modules I think you should simply make that compile-time options >>> instead of modules. More hassle but at least it should work. >> >> It's not about the few kb. The problem is that our devices are not >> monolithic, but instead we have multiple devices in and around the SoC >> which form a DRM device. > > right, but the cores on the SoC, and even any external encoder chips, > are not actually hot-pluggable. I have a similar scenario w/ msm drm, oh, and come to think of it, same approach it tilcdc. And I'm sure there are other drivers with the same scenario. BR, -R > where there is the core display controller (for ex, 'mdp4'), plus > hdmi/dsi/etc blocks around that (with their own irq, io/register > region, etc). It would be nice if the kernel provided a better > mechanism for composite drivers, but what I do is just register the > platform drivers for those other blocks first (in the init code, > before calling 'platform_driver_register(&msm_platform_driver)'. This > way, if the device is actually present, I know before drm dev_load. I > do not attempt to build hdmi/dsi/etc as separate modules. I could if > I wanted to include/exclude them at compile time, but separate modules > seems like a bad idea. > > BR, > -R > >> Sascha >> >> -- >> Pengutronix e.K. | | >> Industrial Linux Solutions | http://www.pengutronix.de/ | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote: >> right, but the cores on the SoC, and even any external encoder chips, >> are not actually hot-pluggable. I have a similar scenario w/ msm drm, > > oh, and come to think of it, same approach it tilcdc. And I'm sure > there are other drivers with the same scenario. i915 and nouveau also support encoder slaves, and they also have them all built-in. And I think requesting the module at driver init time (where I mean any point in time between when the master module loads and userspace first starts using it) seems fraught with with deadlock issues if we have to wait for it. So imo in the current drm state there is no way you can built slave drivers as modules. It's simply broken. I agree that it'd be nice to have a better solution, but atm I don't even have an idea what it is. But applying duct-tape in ->firstopen is certainly not the right way. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support
On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote: > On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark wrote: > >> right, but the cores on the SoC, and even any external encoder chips, > >> are not actually hot-pluggable. I have a similar scenario w/ msm drm, > > > > oh, and come to think of it, same approach it tilcdc. And I'm sure > > there are other drivers with the same scenario. > > i915 and nouveau also support encoder slaves, and they also have them > all built-in. And I think requesting the module at driver init time > (where I mean any point in time between when the master module loads > and userspace first starts using it) seems fraught with with deadlock > issues if we have to wait for it. > > So imo in the current drm state there is no way you can built slave > drivers as modules. It's simply broken. I agree that it'd be nice to > have a better solution, but atm I don't even have an idea what it is. > But applying duct-tape in ->firstopen is certainly not the right way. The imx-drm does not request modules itself. It also does not do hotplug. It also does not change the drm device structure while being opened. The drm device structure is only ever changed when the device is closed. Once it's opened it's completely static and will not be changed. All this 'core' stuff in the drm driver is only done to be able to separate the different encoders into linux platform_devices, module support is only a side effect of this. What the imx-drm driver does is: - collect subcomponents via imx_drm_add_connector, imx_drm_add_crtc and imx_drm_add_encoder - During drm device open time the try_module_get will make sure the modules providing encoders/crtcs do not get unloaded. once the device is opened imx_drm_add_* will return -EBUSY. - When the drm device is closed module_put is called and components are allowed to be registered/unregistered again. Indeed hotplug support for components would be nice, but as said this is not supported by drm and by the imx-drm driver. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)
https://bugs.freedesktop.org/show_bug.cgi?id=68468
--- Comment #4 from adam777 at gmail.com ---
Well, the digging phase is over, I pretty much hit a wall.
As stated above, the general bisecting idea is clear, but I'm having problem
actually building mesa.
Here what I've done:
I downloaded the PKGBUILD and needed packages (clang-svn, llvm-svn etc.) from
Laurent Carlier's folder (an Arch developer).
I modified the PKGBUILD a bit - comment out unnecessary packages
(intel-dri-git, for example).
In order to build a specific commit, I added the following line to the build()
section:
cd ${srcdir}/mesa
git checkout 5b2855bfe79bfc3995969f2bf775d89b1bc1808a
makepkg -s was invoked later, but failed pretty soon. A bit of googling and the
blame was with bison 3.0.
Since the commit I'm trying to build is from April 11th and the bison 3.0 fix
is from July 31st and since I have no idea how to backport the bison 3.0
patches, I downgraded to bison 2.7.1 from the AUR
(https://bugs.freedesktop.org/show_bug.cgi?id=67354).
makepkg -s then got over the problematic bison part but failed again, this time
with an error related to llvm 3.4
(https://bugs.freedesktop.org/show_bug.cgi?id=64590).
Again, The fix is from May 14th (http://cgit.freedesktop.org/mesa/mesa/c ?
773efbc181), so I reverted to LLVM 3.3 and modified PKGBUILD accordingly (llvm
instead of llvm-svn etc.).
This is, unfortunately, where I got stuck.
Build fails again, with an error that seems to be related to llvm 3.4, though
I'm on 3.3.
Log is here - http://pastebin.com/DwFAVKxC
PKGBUILD is here - http://pastebin.com/PwiZXVGv
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/91051e56/attachment.html>
[PATCH] drm/radeon: fix handling of variable sized arrays for router objects
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset
pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly. Use pointers and update the offset
appropriately when accessing the Dst members.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 112c963..ad91354 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -711,13 +711,16 @@ bool
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)
(ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *)
(ctx->bios +
data_offset +
le16_to_cpu(router_obj->asObjects[k].usSrcDstTableOffset));
+ u8 *num_dst_objs = (u8
*)
+ ((u8
*)router_src_dst_table + 1 +
+
(router_src_dst_table->ucNumberOfSrc * 2));
+ u16 *dst_objs = (u16
*)(num_dst_objs + 1);
int enum_id;
router.router_id =
router_obj_id;
- for (enum_id = 0;
enum_id < router_src_dst_table->ucNumberOfDst;
-enum_id++) {
+ for (enum_id = 0;
enum_id < (*num_dst_objs); enum_id++) {
if
(le16_to_cpu(path->usConnObjectId) ==
-
le16_to_cpu(router_src_dst_table->usDstObjectID[enum_id]))
+
le16_to_cpu(dst_objs[enum_id]))
break;
}
--
1.8.3.1
[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure
https://bugs.freedesktop.org/show_bug.cgi?id=52952 --- Comment #19 from Alex Deucher --- Created attachment 84747 --> https://bugs.freedesktop.org/attachment.cgi?id=84747&action=edit possible fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/fbc3355a/attachment.html>
[PATCH 0/9] drm/nouveau: Cleanup event/handler design
This series was originally motivated by a deadlock, introduced in commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b 'drm/nouveau/disp: port vblank handling to event interface', due to inverted lock order between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() (the complete lockdep report is included in the patch 4/5 changelog). Because this series fixes the vblank event deadlock, it is a competing solution to Maarten Lankhorst's 'drm/nouveau: fix vblank deadlock'. This series fixes the vblank event deadlock by converting the event handler list to RCU. This solution allows the event trigger to be lockless, and thus avoiding the lock inversion. Typical hurdles to RCU conversion include: 1) ensuring the object lifetime exceeds the lockless access; 2) preventing premature object reuse; and 3) verifying that stale object use not present logical errors. Because object reuse is not safe in RCU-based operations, the nouveau_event_get/_put interface is migrated from add/remove semantics to enable/disable semantics with a separate install/remove step (which also serves to document the handler lifetime). This also corrects an unsafe interface design where handlers can mistakenly be reused while in use. The nouveau driver currently supports 4 events -- gpio, uevent, cevent, and vblank. Every event is created by and stored within its respective subdev/engine object -- gpio in the GPIO subdev, uevent and cevent in the FIFO engine, and vblank in the DISP engine. Thus event lifetime extends until the subdev is destructed during devobj teardown. Event handler lifetime varies and is detailed in the table below (apologies for the wide-format): Event Handler function Container Until - --- -- gpio nouveau_connector_hotplug struct nouveau_connector nouveau_connector_destroy uevent nouveau_fence_wait_uevent_handler local stack object nouveau_fence_wait_uevent returns cevent none n/a n/a vblank nouveau_drm_vblank_handler struct nouveau_drm nouveau_drm_remove vblank nv50_software_vblsem_release struct nouveau_software_chan _nouveau_engctx_dtor (call stack originates with nouveau_abi16_chan_free ioctl) vblank nvc0_software_vblsem_release struct nouveau_software_chan same as above RCU lifetime considerations for handlers: Event HandlerLifetime - - gpio nouveau_connector_hotplug kfree_rcu(nv_connector) uevent nouveau_fence_wait_uevent_handler explicit use of nouveau_event_hander_create/_destroy cevent none n/a vblank nouveau_drm_vblank_handler synchronize_rcu() in nouveau_drm_unload vblank nv50_software_vblsem_release synchronize_rcu() in container dtor vblank nvc0_software_vblsem_release synchronize_rcu() in container dtor synchronize_rcu() is used for nouveau_object-based containers for which kfree_rcu() is not suitable/possible. Stale event handler execution is not a concern for the existing handlers because either: 1) the handler is responsible for disabling itself (via returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale, as is the case with nouveau_connector_hotplug, which only schedules a work item, and nouveau_drm_vblank_handler, which the drm core expects may be stale. Peter Hurley (9): drm/nouveau: Add priv field for event handlers drm/nouveau: Move event index check from critical section drm/nouveau: Allocate local event handlers drm/nouveau: Allow asymmetric nouveau_event_get/_put drm/nouveau: Add install/remove semantics for event handlers drm/nouveau: Convert event handler list to RCU drm/nouveau: Fold nouveau_event_put_locked into caller drm/nouveau: Simplify event interface drm/nouveau: Simplify event handler interface drivers/gpu/drm/nouveau/core/core/event.c | 121 + .../gpu/drm/nouveau/core/engine/software/nv50.c| 32 -- .../gpu/drm/nouveau/core/engine/software/nvc0.c| 32 -- drivers/gpu/drm/nouveau/core/include/core/event.h | 27 - .../gpu/drm/nouveau/core/include/engine/software.h | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c| 16 ++- drivers/gpu/drm/nouveau/nouveau_display.c | 16 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 35 +++--- drivers/gpu/drm/nouveau/nouveau_fence.c| 27 ++--- 9 files changed, 220 insertions(+), 88 deletions(-) -- 1.8.1.2
[PATCH 1/9] drm/nouveau: Add priv field for event handlers
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 20 +++-
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ad4d8c2 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -7,6 +7,7 @@
struct nouveau_eventh {
struct list_head head;
+ void *priv;
int (*func)(struct nouveau_eventh *, int index);
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..c2e3167 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -165,17 +165,11 @@ nouveau_fence_done(struct nouveau_fence *fence)
return !fence->channel;
}
-struct nouveau_fence_uevent {
- struct nouveau_eventh handler;
- struct nouveau_fence_priv *priv;
-};
-
static int
-nouveau_fence_wait_uevent_handler(struct nouveau_eventh *event, int index)
+nouveau_fence_wait_uevent_handler(struct nouveau_eventh *handler, int index)
{
- struct nouveau_fence_uevent *uevent =
- container_of(event, struct nouveau_fence_uevent, handler);
- wake_up_all(&uevent->priv->waiting);
+ struct nouveau_fence_priv *priv = handler->priv;
+ wake_up_all(&priv->waiting);
return NVKM_EVENT_KEEP;
}
@@ -186,13 +180,13 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence,
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
- struct nouveau_fence_uevent uevent = {
- .handler.func = nouveau_fence_wait_uevent_handler,
+ struct nouveau_eventh handler = {
+ .func = nouveau_fence_wait_uevent_handler,
.priv = priv,
};
int ret = 0;
- nouveau_event_get(pfifo->uevent, 0, &uevent.handler);
+ nouveau_event_get(pfifo->uevent, 0, &handler);
if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -224,7 +218,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool
intr)
}
}
- nouveau_event_put(pfifo->uevent, 0, &uevent.handler);
+ nouveau_event_put(pfifo->uevent, 0, &handler);
if (unlikely(ret < 0))
return ret;
--
1.8.1.2
[PATCH 2/9] drm/nouveau: Move event index check from critical section
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..e69c463 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -40,9 +40,11 @@ nouveau_event_put(struct nouveau_event *event, int index,
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr)
- nouveau_event_put_locked(event, index, handler);
+ nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(&event->lock, flags);
}
@@ -52,13 +54,14 @@ nouveau_event_get(struct nouveau_event *event, int index,
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr) {
- list_add(&handler->head, &event->index[index].list);
- if (!event->index[index].refs++) {
- if (event->enable)
- event->enable(event, index);
- }
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
}
spin_unlock_irqrestore(&event->lock, flags);
}
--
1.8.1.2
[PATCH 3/9] drm/nouveau: Allocate local event handlers
Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.
Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 ++
drivers/gpu/drm/nouveau/nouveau_fence.c | 15 +++---
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index e69c463..1a8d685 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,6 +23,30 @@
#include
#include
+int
+nouveau_event_handler_create(struct nouveau_event *event, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **phandler)
+{
+ struct nouveau_eventh *handler;
+
+ handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
+ if (!handler)
+ return -ENOMEM;
+ handler->func = func;
+ handler->priv = priv;
+ nouveau_event_get(event, index, handler);
+ return 0;
+}
+
+void
+nouveau_event_handler_destroy(struct nouveau_event *event, int index,
+ struct nouveau_eventh *handler)
+{
+ nouveau_event_put(event, index, handler);
+ kfree(handler);
+}
+
static void
nouveau_event_put_locked(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index ad4d8c2..bdf1a0a 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -34,4 +34,10 @@ void nouveau_event_get(struct nouveau_event *, int index,
void nouveau_event_put(struct nouveau_event *, int index,
struct nouveau_eventh *);
+int nouveau_event_handler_create(struct nouveau_event *, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **);
+void nouveau_event_handler_destroy(struct nouveau_event *, int index,
+ struct nouveau_eventh *);
+
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index c2e3167..6dde483 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -180,13 +180,14 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence,
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
- struct nouveau_eventh handler = {
- .func = nouveau_fence_wait_uevent_handler,
- .priv = priv,
- };
- int ret = 0;
+ struct nouveau_eventh *handler;
+ int ret;
- nouveau_event_get(pfifo->uevent, 0, &handler);
+ ret = nouveau_event_handler_create(pfifo->uevent, 0,
+ nouveau_fence_wait_uevent_handler,
+ priv, &handler);
+ if (ret)
+ return ret;
if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -218,7 +219,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool
intr)
}
}
- nouveau_event_put(pfifo->uevent, 0, &handler);
+ nouveau_event_handler_destroy(pfifo->uevent, 0, handler);
if (unlikely(ret < 0))
return ret;
--
1.8.1.2
[PATCH 4/9] drm/nouveau: Allow asymmetric nouveau_event_get/_put
Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corrupted.
Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 20
drivers/gpu/drm/nouveau/core/include/core/event.h | 4
drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++--
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 1a8d685..0a65ede 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -51,11 +51,13 @@ static void
nouveau_event_put_locked(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
- if (!--event->index[index].refs) {
- if (event->disable)
- event->disable(event, index);
+ if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ list_del(&handler->head);
}
- list_del(&handler->head);
}
void
@@ -82,10 +84,12 @@ nouveau_event_get(struct nouveau_event *event, int index,
return;
spin_lock_irqsave(&event->lock, flags);
- list_add(&handler->head, &event->index[index].list);
- if (!event->index[index].refs++) {
- if (event->enable)
- event->enable(event, index);
+ if (!__test_and_set_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
+ }
}
spin_unlock_irqrestore(&event->lock, flags);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index bdf1a0a..3e704d5 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -5,8 +5,12 @@
#define NVKM_EVENT_DROP 0
#define NVKM_EVENT_KEEP 1
+/* nouveau_eventh.flags bit #s */
+#define NVKM_EVENT_ENABLE 0
+
struct nouveau_eventh {
struct list_head head;
+ unsigned long flags;
void *priv;
int (*func)(struct nouveau_eventh *, int index);
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ccea2c4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -88,7 +88,6 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank)))
return -EIO;
- WARN_ON_ONCE(drm->vblank[head].func);
drm->vblank[head].func = nouveau_drm_vblank_handler;
nouveau_event_get(pdisp->vblank, head, &drm->vblank[head]);
return 0;
@@ -99,11 +98,8 @@ nouveau_drm_vblank_disable(struct drm_device *dev, int head)
{
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm->device);
- if (drm->vblank[head].func)
- nouveau_event_put(pdisp->vblank, head, &drm->vblank[head]);
- else
- WARN_ON_ONCE(1);
- drm->vblank[head].func = NULL;
+
+ nouveau_event_put(pdisp->vblank, head, &drm->vblank[head]);
}
static u64
--
1.8.1.2
[PATCH 5/9] drm/nouveau: Add install/remove semantics for event handlers
Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.
Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler lifetime, and distinguishes "one-of" event handlers
(such as gpio) from "many temporary" event handlers (such as uevent).
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 63 +++---
.../gpu/drm/nouveau/core/engine/software/nv50.c| 31 +--
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 31 +--
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 +++
.../gpu/drm/nouveau/core/include/engine/software.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 17 +-
7 files changed, 140 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 0a65ede..4cd1ebe 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,19 +23,60 @@
#include
#include
+void
+nouveau_event_handler_install(struct nouveau_event *event, int index,
+ int (*func)(struct nouveau_eventh*, int),
+ void *priv, struct nouveau_eventh *handler)
+{
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ handler->func = func;
+ handler->priv = priv;
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_add(&handler->head, &event->index[index].list);
+ spin_unlock_irqrestore(&event->lock, flags);
+}
+
+void
+nouveau_event_handler_remove(struct nouveau_event *event, int index,
+struct nouveau_eventh *handler)
+{
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_del(&handler->head);
+ spin_unlock_irqrestore(&event->lock, flags);
+}
+
int
nouveau_event_handler_create(struct nouveau_event *event, int index,
int (*func)(struct nouveau_eventh*, int),
void *priv, struct nouveau_eventh **phandler)
{
struct nouveau_eventh *handler;
+ unsigned long flags;
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
handler->func = func;
handler->priv = priv;
- nouveau_event_get(event, index, handler);
+ __set_bit(NVKM_EVENT_ENABLE, &handler->flags);
+
+ spin_lock_irqsave(&event->lock, flags);
+ list_add(&handler->head, &event->index[index].list);
+ if (!event->index[index].refs++) {
+ if (event->enable)
+ event->enable(event, index);
+ }
+ spin_unlock_irqrestore(&event->lock, flags);
return 0;
}
@@ -43,7 +84,18 @@ void
nouveau_event_handler_destroy(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
- nouveau_event_put(event, index, handler);
+ unsigned long flags;
+
+ if (index >= event->index_nr)
+ return;
+
+ spin_lock_irqsave(&event->lock, flags);
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ list_del(&handler->head);
+ spin_unlock_irqrestore(&event->lock, flags);
kfree(handler);
}
@@ -56,7 +108,6 @@ nouveau_event_put_locked(struct nouveau_event *event, int
index,
if (event->disable)
event->disable(event, index);
}
- list_del(&handler->head);
}
}
@@ -85,7 +136,6 @@ nouveau_event_get(struct nouveau_event *event, int index,
spin_lock_irqsave(&event->lock, flags);
if (!__test_and_set_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- list_add(&handler->head, &event->index[index].list);
if (!event->index[index].refs++) {
if (event->enable)
event->enable(event, index);
@@ -105,8 +155,9 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
spin_lock_irqsave(&event->lock, flags);
list_for_each_entry_safe(handler, temp, &event->index[index].list,
head) {
- if (handler->func(handler, index) == NVKM_EVENT_DROP) {
- nouveau_event_put_locked(event, index, handler);
+ if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (handler->func(handler, index) == NVKM_EVENT_DROP)
+ nouveau_event_put_locked(event, index, handler);
}
}
sp
[PATCH 6/9] drm/nouveau: Convert event handler list to RCU
Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event->lock with drm core's
dev->vblank_time_lock.
Fix vblank event deadlock by converting event handler list to RCU.
List updates remain serialized by event->lock.
List traversal & handler execution is lockless which prevents
inverted lock order problems with the drm core.
Safe deletion of the event handler is accomplished with
synchronize_rcu() for those handlers stored in nouveau_object-based
containers (nouveau_drm & nv50_/nvc0_software_context); otherwise,
with kfree_rcu (for nouveau_connector & uevent temporary handlers).
[1]
==
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
---
swapper/7/0 is trying to acquire lock:
(&(&dev->vblank_time_lock)->rlock){-.}, at: []
drm_handle_vblank+0x69/0x400 [drm]
but task is already holding lock:
(&(&event->lock)->rlock){-.}, at: []
nouveau_event_trigger+0x4d/0xd0 [nouveau]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&(&event->lock)->rlock){-.}:
[] lock_acquire+0x92/0x1f0
[] _raw_spin_lock_irqsave+0x46/0x60
[] nouveau_event_get+0x27/0xa0 [nouveau]
[] nouveau_drm_vblank_enable+0x8d/0xf0 [nouveau]
[] drm_vblank_get+0xf8/0x2c0 [drm]
[] drm_wait_vblank+0x84/0x6f0 [drm]
[] drm_ioctl+0x559/0x690 [drm]
[] do_vfs_ioctl+0x97/0x590
[] SyS_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
-> #0 (&(&dev->vblank_time_lock)->rlock){-.}:
[] __lock_acquire+0x1c43/0x1d30
[] lock_acquire+0x92/0x1f0
[] _raw_spin_lock_irqsave+0x46/0x60
[] drm_handle_vblank+0x69/0x400 [drm]
[] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
[] nouveau_event_trigger+0x90/0xd0 [nouveau]
[] nv50_disp_intr+0xdd/0x230 [nouveau]
[] nouveau_mc_intr+0xa1/0x100 [nouveau]
[] handle_irq_event_percpu+0x6c/0x3d0
[] handle_irq_event+0x48/0x70
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] ret_from_intr+0x0/0x13
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] start_secondary+0x255/0x25c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(&(&event->lock)->rlock);
lock(&(&dev->vblank_time_lock)->rlock);
lock(&(&event->lock)->rlock);
lock(&(&dev->vblank_time_lock)->rlock);
*** DEADLOCK ***
1 lock held by swapper/7/0:
#0: (&(&event->lock)->rlock){-.}, at: []
nouveau_event_trigger+0x4d/0xd0 [nouveau]
stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11
04/30/2012
821ccf60 8802bfdc3b08 81755f39 8802bfdc3b58
8174f526 0002 8802bfdc3be8 8802b330a7f8
8802b330a820 8802b330a7f8 0001
Call Trace:
[] dump_stack+0x19/0x1b
[] print_circular_bug+0x1fb/0x20c
[] __lock_acquire+0x1c43/0x1d30
[] ? trace_hardirqs_off+0xd/0x10
[] ? flat_send_IPI_mask+0x88/0xa0
[] lock_acquire+0x92/0x1f0
[] ? drm_handle_vblank+0x69/0x400 [drm]
[] _raw_spin_lock_irqsave+0x46/0x60
[] ? drm_handle_vblank+0x69/0x400 [drm]
[] drm_handle_vblank+0x69/0x400 [drm]
[] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
[] nouveau_event_trigger+0x90/0xd0 [nouveau]
[] nv50_disp_intr+0xdd/0x230 [nouveau]
[] ? _raw_spin_unlock_irqrestore+0x42/0x80
[] ? __hrtimer_start_range_ns+0x16c/0x530
[] nouveau_mc_intr+0xa1/0x100 [nouveau]
[] handle_irq_event_percpu+0x6c/0x3d0
[] handle_irq_event+0x48/0x70
[] ? handle_fasteoi_irq+0x1e/0x100
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] common_interrupt+0x6f/0x6f
[] ? default_idle+0x1d/0x290
[] ? default_idle+0x1b/0x290
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] ? clockevents_register_device+0xdc/0x140
[] start_secondary+0x255/0x25c
Reported-by: Dave Jones
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 22 +++---
.../gpu/drm/nouveau/core/engine/software/nv50.c| 1 +
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 1 +
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 4cd1ebe..ce0a0ef 100644
--- a/drive
[PATCH 7/9] drm/nouveau: Fold nouveau_event_put_locked into caller
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index ce0a0ef..45bcb37 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -100,18 +100,6 @@ nouveau_event_handler_destroy(struct nouveau_event *event,
int index,
kfree_rcu(handler, rcu);
}
-static void
-nouveau_event_put_locked(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
-{
- if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- if (!--event->index[index].refs) {
- if (event->disable)
- event->disable(event, index);
- }
- }
-}
-
void
nouveau_event_put(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
@@ -122,7 +110,12 @@ nouveau_event_put(struct nouveau_event *event, int index,
return;
spin_lock_irqsave(&event->lock, flags);
- nouveau_event_put_locked(event, index, handler);
+ if (__test_and_clear_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
+ if (!--event->index[index].refs) {
+ if (event->disable)
+ event->disable(event, index);
+ }
+ }
spin_unlock_irqrestore(&event->lock, flags);
}
--
1.8.1.2
[PATCH 8/9] drm/nouveau: Simplify event interface
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++-
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 11 ++-
drivers/gpu/drm/nouveau/core/include/core/event.h | 15 +
drivers/gpu/drm/nouveau/nouveau_connector.c| 5 +--
drivers/gpu/drm/nouveau/nouveau_display.c | 16 +++---
drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_fence.c| 2 +-
8 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 45bcb37..b7d8ae1 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -34,6 +34,9 @@ nouveau_event_handler_install(struct nouveau_event *event,
int index,
if (index >= event->index_nr)
return;
+ handler->event = event;
+ handler->index = index;
+
handler->func = func;
handler->priv = priv;
@@ -43,12 +46,12 @@ nouveau_event_handler_install(struct nouveau_event *event,
int index,
}
void
-nouveau_event_handler_remove(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
+nouveau_event_handler_remove(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -67,6 +70,10 @@ nouveau_event_handler_create(struct nouveau_event *event,
int index,
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
+
+ handler->event = event;
+ handler->index = index;
+
handler->func = func;
handler->priv = priv;
__set_bit(NVKM_EVENT_ENABLE, &handler->flags);
@@ -82,13 +89,12 @@ nouveau_event_handler_create(struct nouveau_event *event,
int index,
}
void
-nouveau_event_handler_destroy(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_handler_destroy(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
- return;
spin_lock_irqsave(&event->lock, flags);
if (!--event->index[index].refs) {
@@ -101,12 +107,13 @@ nouveau_event_handler_destroy(struct nouveau_event
*event, int index,
}
void
-nouveau_event_put(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_put(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -120,12 +127,13 @@ nouveau_event_put(struct nouveau_event *event, int index,
}
void
-nouveau_event_get(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_get(struct nouveau_eventh *handler)
{
+ struct nouveau_event *event = handler->event;
+ int index = handler->index;
unsigned long flags;
- if (index >= event->index_nr)
+ if (!event)
return;
spin_lock_irqsave(&event->lock, flags);
@@ -150,7 +158,7 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
list_for_each_entry_rcu(handler, &event->index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
if (handler->func(handler, index) == NVKM_EVENT_DROP)
- nouveau_event_put(event, index, handler);
+ nouveau_event_put(handler);
}
}
rcu_read_unlock();
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index 87aeee1..e969f0c 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -92,12 +92,11 @@ nv50_software_mthd_vblsem_release(struct nouveau_object
*object, u32 mthd,
void *args, u32 size)
{
struct nv50_software_chan *chan = (void *)nv_engctx(object->parent);
- struct nouveau_disp *disp = nouveau_disp(object);
u32 crtc = *(u32 *)args;
if (crtc > 1)
return -EINVAL;
- nouveau_event_get(disp->vblank, crtc, &chan->base.vblank.event[crtc]);
+ nouveau_event_get(&chan->
[PATCH 9/9] drm/nouveau: Simplify event handler interface
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/nv50.c | 7 +++
drivers/gpu/drm/nouveau/core/engine/software/nvc0.c | 7 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 +++---
drivers/gpu/drm/nouveau/nouveau_connector.c | 9 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
7 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index b7d8ae1..1240fef 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
void
nouveau_event_handler_install(struct nouveau_event *event, int index,
- int (*func)(struct nouveau_eventh*, int),
+ int (*func)(struct nouveau_eventh*),
void *priv, struct nouveau_eventh *handler)
{
unsigned long flags;
@@ -61,7 +61,7 @@ nouveau_event_handler_remove(struct nouveau_eventh *handler)
int
nouveau_event_handler_create(struct nouveau_event *event, int index,
-int (*func)(struct nouveau_eventh*, int),
+int (*func)(struct nouveau_eventh*),
void *priv, struct nouveau_eventh **phandler)
{
struct nouveau_eventh *handler;
@@ -157,7 +157,7 @@ nouveau_event_trigger(struct nouveau_event *event, int
index)
rcu_read_lock();
list_for_each_entry_rcu(handler, &event->index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, &handler->flags)) {
- if (handler->func(handler, index) == NVKM_EVENT_DROP)
+ if (handler->func(handler) == NVKM_EVENT_DROP)
nouveau_event_put(handler);
}
}
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index e969f0c..bf6f23b 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -131,10 +131,9 @@ nv50_software_sclass[] = {
**/
static int
-nv50_software_vblsem_release(struct nouveau_eventh *event, int head)
+nv50_software_vblsem_release(struct nouveau_eventh *handler)
{
- struct nouveau_software_chan *chan =
- container_of(event, struct nouveau_software_chan,
vblank.event[head]);
+ struct nouveau_software_chan *chan = handler->priv;
struct nv50_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);
@@ -172,7 +171,7 @@ nv50_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
nv50_software_vblsem_release,
- NULL,
+ chan,
&chan->base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
index d06658a..1a2a7a8 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
@@ -143,10 +143,9 @@ nvc0_software_sclass[] = {
**/
static int
-nvc0_software_vblsem_release(struct nouveau_eventh *event, int head)
+nvc0_software_vblsem_release(struct nouveau_eventh *handler)
{
- struct nouveau_software_chan *chan =
- container_of(event, struct nouveau_software_chan,
vblank.event[head]);
+ struct nouveau_software_chan *chan = handler->priv;
struct nvc0_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);
@@ -178,7 +177,7 @@ nvc0_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
nvc0_software_vblsem_release,
- NULL,
+ chan,
&chan->base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index e839d
[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver
https://bugs.freedesktop.org/show_bug.cgi?id=68585 --- Comment #6 from Marek Ol??k --- Created attachment 84748 --> https://bugs.freedesktop.org/attachment.cgi?id=84748&action=edit possible fix Could you please test this patch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/b776b1cc/attachment.html>
