[Bug 99680] VM/GPU fault on 4.10-rc6 (Kaveri + Topaz)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99680

--- Comment #2 from SET  ---
This happened since 4.10-rc1, much has changed since, it's not fatal and
bisecting is much time taking. I reported this in case it might be helpful to
devs. If it's perceived as annoying noise, I do apologize.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/7] dt-bindings: display: Add common rotation property

[Thierry Reding]

On Fri, Feb 03, 2017 at 01:16:45PM +0100, Noralf Trønnes wrote:
> Thierry, please have a look at this.
> In which direction should we rotate to match how drm rotation works?
> 
> 
> Den 01.02.2017 18.41, skrev Rob Herring:
> > On Tue, Jan 31, 2017 at 05:03:17PM +0100, Noralf Trønnes wrote:
> > > Display panels can be oriented many ways, especially in the embedded
> > > world. The rotation property is a way to describe this orientation.
> > > The counter clockwise direction is chosen because that's what fbdev
> > > and drm use.
> > The h/w mounting is rotated counter clockwise, so the framebuffers'
> > contents are rotated clockwise, right?

Given that this describes the rotation of the panel, I think it should
be described in terms of how the panel is rotated, not how the
framebuffer needs to be rotated. Using counter-clockwise, as described
in this binding seems fine to me.

It would have to be up to fbdev and DRM/KMS to transform that into a
clockwise rotation for the framebuffer, CRTC, plane, ...

Ideally with some sort of helper.

Thierry

> > 
> > > Signed-off-by: Noralf Trønnes 
> > > ---
> > >   Documentation/devicetree/bindings/display/display.txt | 4 
> > This is panel property, so bindings/display/panel/panel.txt.
> > 
> > >   1 file changed, 4 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/display/display.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/display.txt 
> > > b/Documentation/devicetree/bindings/display/display.txt
> > > new file mode 100644
> > > index 000..e2e6867
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/display.txt
> > > @@ -0,0 +1,4 @@
> > > +Common display properties
> > > +-
> > > +
> > > +- rotation:  Display rotation in degrees counter clockwise 
> > > (0,90,180,270)
> > > -- 
> > > 2.10.2
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

[Jani Nikula]

On Sun, 25 Dec 2016, Hans de Goede  wrote:
> If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may
> use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation
> for a vbt in mailbox #4 for this.
>
> This fixes the driver not finding the VBT on a jumper ezpad mini3
> cherrytrail tablet.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hans de Goede 
> ---
> Note even with this fixed the panel still does not work with 4.9,
> but it does with drm-intel-next-queued :) I believe the missing bit in
> 4.9 is the "drm/915: Parsing the missed out DTD fields from the VBT"
> commit, but I've not verified this.
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index f4429f6..eff35ae 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -982,7 +982,9 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   opregion->vbt_size = vbt_size;
>   } else {
>   vbt = base + OPREGION_VBT_OFFSET;
> - vbt_size = OPREGION_ASLE_EXT_OFFSET - 
> OPREGION_VBT_OFFSET;
> + vbt_size = (mboxes & MBOX_ASLE_EXT) ?
> + OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
> + vbt_size -= OPREGION_VBT_OFFSET;

First, I want a big fat warning comment about what's going on
here. Otherwise someone's bound to "fix" this later on.

Second, per the spec, the ASLE ext mailbox is 1k in size, and there's a
1k reserved region at the end. We probably shouldn't allow VBT to extend
over there. But hey, per the spec we also shouldn't allow VBT to extend
over mailbox #5 either. So if you can't be bothered with that, neither
will I.


BR,
Jani.



>   if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
>   DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (Mailbox #4)\n");
>   opregion->vbt = vbt;

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99528] Wine game doesn't redraw properly in fullscreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99528

--- Comment #7 from Michel Dänzer  ---
(In reply to fin4478 from comment #4)
> Those stock kernels have very little new  amdgpu and radeon drivers code
> (see diff in kernel.org), use latest drivers when you make bug reports.

There is no such requirement. Depending on the circumstances, we may ask bug
reporters to try a newer kernel, but in this case it seems unlikely that the
problem is kernel related.


> This kernel is latest and stable:
> https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.11-wip

This is the development tree for the amdgpu/radeon drivers, with changes going
into the Linux 4.11 release, which will only get its first release candidate
after the final 4.10 release. I.e. it's cutting edge, *not* stable.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99687] Radeon RV790 Choppy cursor and framerates under xwayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99687

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Michel Dänzer  ---
Nick reported on IRC that this doesn't happen with weston, so it seems to be
gnome-shell/sway compositor issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #18 from siyia  ---
just tick it in ur game and test it

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #17 from siyia  ---
posted a screenshot of the graphics options with blood effect

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #16 from siyia  ---
Created attachment 129352
  --> https://bugs.freedesktop.org/attachment.cgi?id=129352=edit
blood effects options in menu

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #15 from siyia  ---
when you open the graphics menu on the right side it has some options that can
be ticked for example vsync,blood effects is one of them.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #14 from siyia  ---
lol start the game >in the game menu choose options
->graphics-->advanced->then tick the blood effects and press accept
changes.
Finally try and play a custom battle.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99679] DRI PRIME doesn't always work with intel/radeon

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99679

--- Comment #1 from Michel Dänzer  ---
Please attach the corresponding Xorg log file, and the output of the following
from when the problem occurs:

* dmesg
* LIBGL_DEBUG=verbose glxinfo 2>&1
* LIBGL_DEBUG=verbose glxgears -info 2>&1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99680] VM/GPU fault on 4.10-rc6 (Kaveri + Topaz)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99680

--- Comment #1 from Michel Dänzer  ---
If this is a regression from older kernels, can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99687] Radeon RV790 Choppy cursor and framerates under xwayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99687

--- Comment #1 from Nick Tenney  ---
Major thing I forgot to mention in the initial report: I verified that sway
also had the issue, which I believes eliminates gnome/mutter as the culprit.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99687] Radeon RV790 Choppy cursor and framerates under xwayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99687

Bug ID: 99687
   Summary: Radeon RV790 Choppy cursor and framerates under
xwayland
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nick.ten...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Running Archlinux with up-to-date packages (git mesa and xf86-video-ati), I
have been experiencing stutters (frame drops *including* the cursor) when
running Diablo 3 via wine in a wayland gnome session.  If I run the game via
classic xorg session, I have no issues.  I verified that using modesetting in
xorg worked fine as well.

Most notable is the fact that I do *not* have these issues on my
nouveau-running laptop with the same set of software.

I am running wine-staging with Gallium nine patches.  I have absolutely no idea
how to debug the issue, what information may help, or where exactly the bug
should be reported, so ideas are welcome!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Emil Velikov]

On 3 February 2017 at 08:00, Daniel Vetter  wrote:
> On Thu, Feb 02, 2017 at 12:37:21PM +, Emil Velikov wrote:
>>  - Daniel, gents - is drm-misc aimed at devs with limited (no?)
>> review/commit history in the area and/or the kernel in general ?
>> In this case, Peter have quite noticeable experience [in kernel
>> development] with little-to no in DRM.
>> Should one draw a line in the sand somewhere ?
>
> We're fairly lenient with accepting new drivers already, and for drivers
> in drm-misc we require some checks and peer review to make sure new folks
> learn faster. But it's an expirement, I fully expect some fallout and then
> some learnign and fine tuning from that, and maybe we even need to crank
> requirements back up to a much higher level of experience.
>
> But for drivers I'm honestly not too concerned: As long as there's some
> process in place to foster learning (which I think will be
> better with this) I really don't see much harm in merging non-perfect
> driver code.
>
Thank you Daniel, this is very well said. Being lenient to begin with
and adjusting where/if needed is the more welcoming approach, indeed.
Doubt there'll be (m)any cases of (ab|mis)use but even if so, nobody
can see the future.

>>  - You patch has been on a long [bit rocky road] for a while, with
>> devs giving you [what seems like] a partial reviews.
>> Have you considered reviewing others' patches in exchange for a [more
>> complete one] of this one ? According to git log people have poked you
>> a handful of times, but seemingly you were busy.
>
> Just a clarification: When I review drivers I don't do a fairly cursor
> look, hunting for areas where some refactoring and align with drm best
> practices would be good. And I think that's perfectly fine and enough to
> get a driver landed, but we're definitely not 100% consistent on this
> within drm-misc. Probably will take some time to figure this out.
Seems like I've missed "Peter, your patch..." above, silly me.

Thanks for answering my [what may seem silly] questions ;-)
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Fabio Estevam]

Hi Rob,

On Sat, Feb 4, 2017 at 1:36 AM, Rob Herring  wrote:

> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> index fa8d17399407..f7d729aa09bd 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -82,20 +83,15 @@ static const struct drm_connector_funcs 
> mxsfb_panel_connector_funcs = {
> .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>
> -static int mxsfb_attach_endpoint(struct drm_device *drm,
> -const struct of_endpoint *ep)
> +int mxsfb_create_output(struct drm_device *drm)
>  {
> struct mxsfb_drm_private *mxsfb = drm->dev_private;
> -   struct device_node *np;
> struct drm_panel *panel;
> -   int ret = -EPROBE_DEFER;
> -
> -   np = of_graph_get_remote_port_parent(ep->local_node);
> -   panel = of_drm_find_panel(np);
> -   of_node_put(np);
> +   int ret;
>
> -   if (!panel)
> -   return -EPROBE_DEFER;
> +   ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, , 
> NULL);
> +   if (ret)
> +   return ret;

I fixed some build issues of this series and I am trying to use it
with the mxsfb drm driver.

I would like to add bridge support for this driver, so that I can use
the TDA19988 HDMI bridge on a imx6sx-udoo-neo-full board.

My dts looks like this:

--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -185,6 +185,41 @@
};
 };

+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   clock-frequency = <10>;
+   status = "okay";
+
+   hdmi-transmitter@70 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+   pinctrl-0 = <_hdmi>;
+   pinctrl-names = "default";
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+   clocks = < IMX6SX_CLK_CKO2>;
+
+   port {
+   tda998x_input: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd>;
+   status = "okay";
+
+   port {
+   lcdif1_output: endpoint {
+   remote-endpoint = <_input>;
+   };
+   };
+};

and I changed it to:

ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, , );

,but drm_of_find_panel_or_bridge() always returns -EPROBE_DEFER.

Shouldn't it be able to find the bridge chip in this case? Any ideas
of what it is missing?

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] of: introduce of_graph_get_remote_node

[Rob Herring]

The OF graph API leaves too much of the graph walking to clients when
in many cases the driver doesn't care about accessing the port or
endpoint nodes. The drivers typically just want the device connected via
a particular graph connection. of_graph_get_remote_node provides this
functionality.

Signed-off-by: Rob Herring 
---
 drivers/of/base.c| 28 
 include/linux/of_graph.h |  8 
 2 files changed, 36 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..ea18ab16b92c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2469,3 +2469,31 @@ struct device_node *of_graph_get_remote_port(const 
struct device_node *node)
return of_get_next_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port);
+
+struct device_node *of_graph_get_remote_node(const struct device_node *node,
+int port, int endpoint)
+{
+   struct device_node *endpoint_node, *remote;
+
+   endpoint_node = of_graph_get_endpoint_by_regs(node, port, endpoint);
+   if (!endpoint_node) {
+   pr_debug("no valid endpoint (%d, %d) for node %s\n",
+port, endpoint, node->full_name);
+   return NULL;
+   }
+
+   remote = of_graph_get_remote_port_parent(endpoint_node);
+   of_node_put(endpoint);
+   if (!remote) {
+   pr_debug("no valid remote node\n");
+   return NULL;
+   }
+
+   if (!of_device_is_available(remote)) {
+   pr_debug("not available for remote node\n");
+   return NULL;
+   }
+
+   return remote;
+}
+EXPORT_SYMBOL(of_graph_get_remote_node);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2cd570..7b71d3e09209 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -51,6 +51,8 @@ struct device_node *of_graph_get_endpoint_by_regs(
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
+struct device_node *of_graph_get_remote_node(const struct device_node *node,
+int port, int endpoint);
 #else
 
 static inline int of_graph_parse_endpoint(const struct device_node *node,
@@ -89,6 +91,12 @@ static inline struct device_node *of_graph_get_remote_port(
 {
return NULL;
 }
+static inline struct device_node *of_graph_get_remote_node(
+   const struct device_node *node,
+   int port, int endpoint)
+{
+   return NULL;
+}
 
 #endif /* CONFIG_OF */
 
-- 
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv2 PATCH 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkuil's CEC code

[Pierre-Hugues Husson]

Hi,

2016-11-14 16:22 GMT+01:00 Hans Verkuil :
> From: Russell King 
>
> Add a CEC driver for the dw-hdmi hardware using Hans Verkuil's CEC
> implementation.
>
> Signed-off-by: Russell King 
I've seen that the patchset concerning CEC/HDMI notifier after this
one dropped dw-hdmi support.
Is this only temporary, or does this driver need someone to take care of it?

> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-cec.c 
> b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
> new file mode 100644
> index 000..e7e12b5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
> @@ -0,0 +1,346 @@
> +/* http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
> + * tree/drivers/mxc/hdmi-cec/mxc_hdmi-cec.c?h=imx_3.0.35_4.1.0 */
It is perhaps mandatory to have GPL header?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#define DEV_NAME "mxc_hdmi_cec"
I think that to respect the convention it should be dw-hdmi-cec?

> +   writeb_relaxed(addresses & 255, cec->base + HDMI_CEC_ADDR_L);
> +   writeb_relaxed(addresses >> 8, cec->base + HDMI_CEC_ADDR_H);
Some platforms (at least rockchip) discuss with dw-hdmi with longs
instead of bytes
dw-hdmi-i2s-audio.c uses hdmi_read/hdmi_write for that

Is it ok to add write and read functions to dw_hdmi_cec_ops ?

> +static unsigned int parse_hdmi_addr(const struct edid *edid)
> +{
> +   if (!edid || edid->extensions == 0)
> +   return (u16)~0;
> +
> +   return cec_get_edid_phys_addr((u8 *)edid,
> +   EDID_LENGTH * (edid->extensions + 1), NULL);
> +}
> +
> +static int dw_hdmi_cec_notify(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> +   struct dw_hdmi_cec *cec = container_of(nb, struct dw_hdmi_cec, nb);
> +   struct hdmi_notifier *n = data;
> +   unsigned int phys;
> +
> +   dev_info(cec->adap->devnode.parent, "event %lu\n", event);
> +
> +   switch (event) {
> +   case HDMI_CONNECTED:
> +   break;
> +
> +   case HDMI_DISCONNECTED:
> +   cec_s_phys_addr(cec->adap, CEC_PHYS_ADDR_INVALID, false);
> +   break;
> +
> +   case HDMI_NEW_EDID:
> +   phys = parse_hdmi_addr(n->edid);
> +   cec_s_phys_addr(cec->adap, phys, false);
> +   break;
> +   }
> +
> +   return NOTIFY_OK;
> +}
Thanks to "cec: integrate HDMI notifier support" this code can be dropped
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Rob Herring]

Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
 drivers/gpu/drm/bridge/tc358767.c| 27 +--
 drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |  5 +-
 drivers/gpu/drm/imx/imx-ldb.c| 28 ++--
 drivers/gpu/drm/imx/parallel-display.c   | 35 ++---
 drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 17 ++---
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 ++--
 14 files changed, 88 insertions(+), 379 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b5085501..4614048a4935 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #include "atmel_hlcdc_dc.h"
 
@@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
-   struct device_node *np;
-   void *obj;
-
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   obj = of_drm_find_panel(np);
-   if (!obj)
-   obj = of_drm_find_bridge(np);
-
-   of_node_put(np);
-
-   return obj ? 0 : -EPROBE_DEFER;
-}
-
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
-  const struct of_endpoint *ep)
+  const struct device_node *np)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
-   struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
 
output->encoder.possible_crtcs = 0x1;
 
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   ret = -EPROBE_DEFER;
+   ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
+   if (ret)
+   return ret;
 
-   panel = of_drm_find_panel(np);
if (panel) {
-   of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(>connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
return 0;
}
 
-   bridge = of_drm_find_bridge(np);
-   of_node_put(np);
-
if (bridge) {
output->encoder.bridge = bridge;
bridge->encoder = >encoder;
@@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
 
 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
-   struct device_node *ep_np = NULL;
-   struct of_endpoint ep;
+   struct device_node *remote;
int ret;
 
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_check_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_attach_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
+   remote = of_graph_get_remote_node(dev->dev->of_node, 0, 0);
+   if (!remote)
+   return -ENODEV;
 
-   return 0;
+   ret = atmel_hlcdc_attach_endpoint(dev, remote);
+   of_node_put(remote);
+   return ret;
 }
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 

[PATCH] drm/exynos: fimd: Do not use HW trigger for exynos3250

[Hoegeun Kwon]

Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
hardware trigger support to the FIMD controller driver. I have tested
but this broke the display in at least the exynos3250 Gear 2. So until
the issue is fixed, avoid using HW trigger for the exynos3250 based
boards and use SW trigger as it was before the mentioned commit.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e2e4051..b5e0fe1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -125,10 +125,8 @@ struct fimd_driver_data {
.timing_base = 0x2,
.lcdblk_offset = 0x210,
.lcdblk_bypass_shift = 1,
-   .trg_type = I80_HW_TRG,
.has_shadowcon = 1,
.has_vidoutcon = 1,
-   .has_trigger_per_te = 1,
 };
 
 static struct fimd_driver_data exynos4_fimd_driver_data = {
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

答复: [PATCH] drm/amdgpu/virt: fix double kfree on bo_va

[Liu, Monk]

thanks for this catch!


Reviewed-by: Monk Liu 


发件人: Colin King 
发送时间: 2017年2月4日 4:23:42
收件人: Deucher, Alexander; Koenig, Christian; David Airlie; Liu, Monk; Yu, 
Xiangliang; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
抄送: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
主题: [PATCH] drm/amdgpu/virt: fix double kfree on bo_va

From: Colin Ian King 

bo_va is being kfree'd twice, once in the call to amdgpu_vm_bo_rmv
and then a short while later. Fix this double free by removing
the 2nd kfree.

Detected by CoverityScan, CID#1399524 ("Double Free")

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 3fd951c..dcfb7df 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -83,7 +83,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)
 DRM_ERROR("failed to do bo_map on static CSA, err=%d\n", r);
 amdgpu_vm_bo_rmv(adev, bo_va);
 ttm_eu_backoff_reservation(, );
-   kfree(bo_va);
 return r;
 }

--
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] DRM OF graph clean-up

[Rob Herring]

I've been unhappy with the OF graph API for some time and decided to 
do something about it. The problem is drivers have to do too much of the 
graph parsing and walking themselves. This has led to the same pattern 
duplicated over and over. This series adds 2 new helpers and adapts DRM 
drivers to use them. It only adds one new graph helper, but reduces the 
use of the others which I hope to remove at some point. But we're not 
there yet.

There's a few other things I'd like to clean-up.

The Armada and Rockchip drivers remain oddballs with their own graph 
parsing. I can't see how the armada driver even can work. There's 
nothing to instantiate the armada-drm device either in DT or the kernel.

The omapdrm driver still has some custom helpers similar to the common 
ones, but still slightly different. It got to be more changes than I 
wanted to make to address.

Build tested only (and probably not every last driver).

Rob

Rob Herring (5):
  of: introduce of_graph_get_remote_node
  drm: of: introduce drm_of_find_panel_or_bridge
  drm: convert drivers to use of_graph_get_remote_node
  drm: convert drivers to use drm_of_find_panel_or_bridge
  drm: omap: use common OF graph helpers

 drivers/gpu/drm/arm/hdlcd_drv.c  |  22 +
 drivers/gpu/drm/arm/malidp_drv.c |  29 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  64 +++---
 drivers/gpu/drm/bridge/adv7511/adv7533.c |  12 +--
 drivers/gpu/drm/bridge/dumb-vga-dac.c|  15 +---
 drivers/gpu/drm/bridge/nxp-ptn3460.c |  16 +---
 drivers/gpu/drm/bridge/parade-ps8622.c   |  16 +---
 drivers/gpu/drm/bridge/tc358767.c|  27 +-
 drivers/gpu/drm/bridge/ti-tfp410.c   |  15 ++--
 drivers/gpu/drm/drm_of.c |  50 +++
 drivers/gpu/drm/exynos/exynos_dp.c   |  35 +++-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  16 +---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  13 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c  |  27 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|  49 ---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |  27 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |  30 +--
 drivers/gpu/drm/imx/imx-ldb.c|  28 ++-
 drivers/gpu/drm/imx/parallel-display.c   |  35 +---
 drivers/gpu/drm/mediatek/mtk_dpi.c   |  12 +--
 drivers/gpu/drm/mediatek/mtk_dsi.c   |  23 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  26 +-
 drivers/gpu/drm/meson/meson_drv.c|  12 +--
 drivers/gpu/drm/meson/meson_venc_cvbs.c  |  19 +
 drivers/gpu/drm/msm/dsi/dsi_host.c   |   3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c  |  28 +--
 drivers/gpu/drm/mxsfb/mxsfb_out.c|  36 ++--
 drivers/gpu/drm/omapdrm/dss/dpi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 102 +--
 drivers/gpu/drm/omapdrm/dss/dss.c|  61 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c  |   2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  11 ---
 drivers/gpu/drm/omapdrm/dss/venc.c   |   3 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  |  26 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  18 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c|  17 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   |  90 ++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  11 +--
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  66 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c|  15 +---
 drivers/of/base.c|  28 +++
 include/drm/drm_of.h |  13 +++
 include/linux/of_graph.h |   8 ++
 45 files changed, 272 insertions(+), 891 deletions(-)

-- 
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm: of: introduce drm_of_find_panel_or_bridge

[Rob Herring]

Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/drm_of.c | 50 
 include/drm/drm_of.h | 13 +
 2 files changed, 63 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 47848ed8ca48..b29ce2f52113 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -3,7 +3,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 static void drm_release_of(struct device *dev, void *data)
@@ -207,3 +209,51 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
+
+/*
+ * drm_of_find_panel_or_bridge - return connected panel or bridge device
+ * @np: device tree node containing encoder input ports
+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge device.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_find_panel_or_bridge(const struct device_node *np,
+   int port, int endpoint,
+   struct drm_panel **panel,
+   struct drm_bridge **bridge)
+{
+   int ret = -ENODEV;
+   struct device_node *remote;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   if (bridge)
+   *bridge = NULL;
+
+   if (panel) {
+   *panel = of_drm_find_panel(remote);
+   if (*panel) {
+   ret = 0;
+   goto out_put;
+   }
+   ret = -EPROBE_DEFER;
+   }
+
+   if (bridge) {
+   *bridge = of_drm_find_bridge(remote);
+   if (*bridge)
+   ret = 0;
+   else
+   ret = -EPROBE_DEFER;
+   }
+out_put:
+   of_node_put(remote);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 26a64805cc15..f86507f0599b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -8,6 +8,8 @@ struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
+struct drm_panel;
+struct drm_bridge;
 struct device_node;
 
 #ifdef CONFIG_OF
@@ -23,6 +25,10 @@ extern int drm_of_component_probe(struct device *dev,
 extern int drm_of_encoder_active_endpoint(struct device_node *node,
  struct drm_encoder *encoder,
  struct of_endpoint *endpoint);
+extern int drm_of_find_panel_or_bridge(const struct device_node *np,
+  int port, int endpoint,
+  struct drm_panel **panel,
+  struct drm_bridge **bridge);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -52,6 +58,13 @@ static inline int drm_of_encoder_active_endpoint(struct 
device_node *node,
 {
return -EINVAL;
 }
+static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
+ int port, int endpoint,
+ struct drm_panel **panel,
+ struct drm_bridge **bridge)
+{
+   return -EINVAL;
+}
 #endif
 
 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
-- 
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

[Rob Herring]

Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++---
 drivers/gpu/drm/arm/malidp_drv.c| 29 ++-
 drivers/gpu/drm/bridge/adv7511/adv7533.c| 12 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c   | 15 ++
 drivers/gpu/drm/bridge/ti-tfp410.c  | 15 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 26 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +--
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 12 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++
 drivers/gpu/drm/meson/meson_drv.c   | 12 ++---
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 11 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c| 66 +++--
 drivers/gpu/drm/vc4/vc4_dpi.c   | 15 ++
 20 files changed, 64 insertions(+), 351 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e5f4f4a6546d..0f70f5fe9970 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data)
 
 static int hdlcd_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
/* there is only one output port inside each device, find it */
-   ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
-   if (!ep)
-   return -ENODEV;
-
-   if (!of_device_is_available(ep)) {
-   of_node_put(ep);
+   port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
+   if (!port)
return -ENODEV;
-   }
-
-   /* add the remote encoder port as component */
-   port = of_graph_get_remote_port_parent(ep);
-   of_node_put(ep);
-   if (!port || !of_device_is_available(port)) {
-   of_node_put(port);
-   return -EAGAIN;
-   }
 
drm_of_component_match_add(>dev, , compare_dev, port);
of_node_put(port);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..bfa04be7f5de 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev)
 {
struct resource *res;
struct drm_device *drm;
-   struct device_node *ep;
struct malidp_drm *malidp;
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
@@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev)
goto init_fail;
 
/* Set the CRTC's port so that the encoder component can find it */
-   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto port_fail;
-   }
-   malidp->crtc.port = of_get_next_parent(ep);
+   malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);
 
ret = component_bind_all(dev, drm);
if (ret) {
@@ -418,9 +412,7 @@ static int malidp_bind(struct device *dev)
 irq_init_fail:
component_unbind_all(dev, drm);
 bind_fail:
-   of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-port_fail:
malidp_fini(drm);
 init_fail:
drm->dev_private = NULL;
@@ -478,29 +470,16 @@ static int malidp_compare_dev(struct device *dev, void 
*data)
 
 static int malidp_platform_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;
 
if (!pdev->dev.of_node)
return -ENODEV;
 
/* there is only one output port inside each device, find it */
-   ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
-   if 

Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Daniel Vetter]

On Thu, Feb 02, 2017 at 12:37:21PM +, Emil Velikov wrote:
>  - Daniel, gents - is drm-misc aimed at devs with limited (no?)
> review/commit history in the area and/or the kernel in general ?
> In this case, Peter have quite noticeable experience [in kernel
> development] with little-to no in DRM.
> Should one draw a line in the sand somewhere ?

We're fairly lenient with accepting new drivers already, and for drivers
in drm-misc we require some checks and peer review to make sure new folks
learn faster. But it's an expirement, I fully expect some fallout and then
some learnign and fine tuning from that, and maybe we even need to crank
requirements back up to a much higher level of experience.

But for drivers I'm honestly not too concerned: As long as there's some
process in place to foster learning (which I think will be
better with this) I really don't see much harm in merging non-perfect
driver code.

>  - You patch has been on a long [bit rocky road] for a while, with
> devs giving you [what seems like] a partial reviews.
> Have you considered reviewing others' patches in exchange for a [more
> complete one] of this one ? According to git log people have poked you
> a handful of times, but seemingly you were busy.

Just a clarification: When I review drivers I don't do a fairly cursor
look, hunting for areas where some refactoring and align with drm best
practices would be good. And I think that's perfectly fine and enough to
get a driver landed, but we're definitely not 100% consistent on this
within drm-misc. Probably will take some time to figure this out.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Rob Herring]

On Sat, Feb 4, 2017 at 2:26 PM, Fabio Estevam  wrote:
> Hi Rob,
>
> On Sat, Feb 4, 2017 at 1:36 AM, Rob Herring  wrote:
>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c 
>> b/drivers/gpu/drm/mxsfb/mxsfb_out.c
>> index fa8d17399407..f7d729aa09bd 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -82,20 +83,15 @@ static const struct drm_connector_funcs 
>> mxsfb_panel_connector_funcs = {
>> .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>>  };
>>
>> -static int mxsfb_attach_endpoint(struct drm_device *drm,
>> -const struct of_endpoint *ep)
>> +int mxsfb_create_output(struct drm_device *drm)
>>  {
>> struct mxsfb_drm_private *mxsfb = drm->dev_private;
>> -   struct device_node *np;
>> struct drm_panel *panel;
>> -   int ret = -EPROBE_DEFER;
>> -
>> -   np = of_graph_get_remote_port_parent(ep->local_node);
>> -   panel = of_drm_find_panel(np);
>> -   of_node_put(np);
>> +   int ret;
>>
>> -   if (!panel)
>> -   return -EPROBE_DEFER;
>> +   ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, , 
>> NULL);
>> +   if (ret)
>> +   return ret;
>
> I fixed some build issues of this series and I am trying to use it
> with the mxsfb drm driver.
>
> I would like to add bridge support for this driver, so that I can use
> the TDA19988 HDMI bridge on a imx6sx-udoo-neo-full board.
>
> My dts looks like this:
>
> --- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> +++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> @@ -185,6 +185,41 @@
> };
>  };
>
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_i2c3>;
> +   clock-frequency = <10>;
> +   status = "okay";
> +
> +   hdmi-transmitter@70 {
> +   compatible = "nxp,tda998x";
> +   reg = <0x70>;
> +   pinctrl-0 = <_hdmi>;
> +   pinctrl-names = "default";
> +   interrupt-parent = <>;
> +   interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> +   clocks = < IMX6SX_CLK_CKO2>;
> +
> +   port {
> +   tda998x_input: endpoint {
> +   remote-endpoint = <_output>;
> +   };
> +   };
> +   };
> +};
> +
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_lcd>;
> +   status = "okay";
> +
> +   port {
> +   lcdif1_output: endpoint {
> +   remote-endpoint = <_input>;
> +   };
> +   };
> +};
>
> and I changed it to:
>
> ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, , );
>
> ,but drm_of_find_panel_or_bridge() always returns -EPROBE_DEFER.
>
> Shouldn't it be able to find the bridge chip in this case? Any ideas
> of what it is missing?

Did the bridge driver probe? This function just checks lists of
registered panels and bridges.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv2 PATCH 3/5] drm/bridge: dw_hdmi: add HDMI notifier support

[Pierre-Hugues Husson]

Hi

2016-11-14 16:22 GMT+01:00 Hans Verkuil :
> From: Russell King 
>
> Add HDMI notifiers to the HDMI bridge driver.


> @@ -1448,9 +1450,11 @@ static int dw_hdmi_connector_get_modes(struct 
> drm_connector *connector)
> hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> drm_mode_connector_update_edid_property(connector, edid);
> +   hdmi_event_new_edid(hdmi->n, edid, 0);
Considering current hdmi-notifier code, the size must not be 0

Should this be done this way?
> hdmi_event_new_edid(hdmi->n, edid, (edid->extensions + 1) * EDID_LENGTH);

> ret = drm_add_edid_modes(connector, edid);
> /* Store the ELD */
> drm_edid_to_eld(connector, edid);
> +   hdmi_event_new_eld(hdmi->n, connector->eld);
> kfree(edid);
> } else {
> dev_dbg(hdmi->dev, "failed to get edid\n");
> @@ -1579,6 +1583,12 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> dw_hdmi_update_phy_mask(hdmi);
> }
> mutex_unlock(>mutex);
> +
> +   if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> +   hdmi_event_disconnect(hdmi->n);
> +   else if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) ==
> +(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_PHY_HPD))
> +   hdmi_event_connect(hdmi->n);
On rk3288, I never get this event (connect) to trigger, everything
else (disconnect/edid/eld) are ok though. (which is enough for CEC)
I'll need some extra debugging...
Do you have a platform to test on, which does trigger this event?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/ttm: Fix unused variable warning

[Kent Russell]

This cleans up a remnant from Christian's patch (drm/ttm: revert "add 
optional LRU removal callback v2")


 Kent

>From dfdf89a8dff0e378db6fa9578f75b02eec02ca0e Mon Sep 17 00:00:00 2001
From: Kent Russell 
Date: Tue, 31 Jan 2017 06:44:10 -0500
Subject: [PATCH] drm/ttm: Fix unused variable warning

Remove an unused variable in ttm_bo

Signed-off-by: Kent Russell 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index dfaeac4..bdb5812 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -230,7 +230,6 @@ EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);
 
 void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
 {
-	struct ttm_bo_device *bdev = bo->bdev;
 	int put_count = 0;
 
 	lockdep_assert_held(>resv->lock.base);
-- 
2.7.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/debugfs: Add i915_hpd_storm_ctl

[Lyude]

This adds a file in i915's debugfs directory that allows userspace to
manually control HPD storm detection. This is mainly for hotplugging
tests, where we might want to test HPD storm functionality or disable
storm detection to speed up hotplugging tests without breaking anything.

Signed-off-by: Lyude 
Cc: Tomeu Vizoso 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 102 ++-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_irq.c  |   2 +
 drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
 4 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3ae0656..b985c7b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4624,6 +4624,105 @@ static int i915_forcewake_create(struct dentry *root, 
struct drm_minor *minor)
return drm_add_fake_info_node(minor, ent, _forcewake_fops);
 }
 
+static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = m->private;
+
+   if (delayed_work_pending(_priv->hotplug.reenable_work))
+   seq_printf(m, "detected\n");
+   else if (dev_priv->hotplug.hpd_storm_detect_enabled)
+   seq_printf(m, "on\n");
+   else
+   seq_printf(m, "off\n");
+
+   return 0;
+}
+
+static void i915_hpd_storm_reset(struct drm_i915_private *dev_priv)
+{
+   int i;
+
+   spin_lock_irq(_priv->irq_lock);
+   for (i = 0; i < ARRAY_SIZE(dev_priv->hotplug.stats); i++) {
+   dev_priv->hotplug.stats[i].count = 0;
+   dev_priv->hotplug.stats[i].last_jiffies = jiffies;
+   }
+   spin_unlock_irq(_priv->irq_lock);
+
+   if (delayed_work_pending(_priv->hotplug.reenable_work))
+   flush_delayed_work(_priv->hotplug.reenable_work);
+   else
+   schedule_delayed_work(_priv->hotplug.reenable_work, 0);
+}
+
+static ssize_t i915_hpd_storm_ctl_write(struct file *file,
+   const char __user *ubuf, size_t len,
+   loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   struct drm_i915_private *dev_priv = m->private;
+   struct i915_hotplug *hotplug = _priv->hotplug;
+   char tmp[16];
+   enum {
+   HPD_STORM_DISABLE = 0,
+   HPD_STORM_ENABLE,
+   HPD_STORM_RESET
+   } action;
+
+   if (len >= sizeof(tmp))
+   return -EINVAL;
+
+   if (copy_from_user(tmp, ubuf, len))
+   return -EFAULT;
+
+   tmp[len] = '\0';
+
+   if (strcmp(tmp, "off") == 0 || strcmp(tmp, "off\n") == 0)
+   action = HPD_STORM_DISABLE;
+   else if (strcmp(tmp, "on") == 0 || strcmp(tmp, "on\n") == 0)
+   action = HPD_STORM_ENABLE;
+   else if (strcmp(tmp, "reset") == 0 || strcmp(tmp, "reset\n") == 0)
+   action = HPD_STORM_RESET;
+   else
+   return -EINVAL;
+
+   switch (action) {
+   case HPD_STORM_DISABLE:
+   DRM_DEBUG_KMS("Disabling HPD storm detection\n");
+
+   WRITE_ONCE(hotplug->hpd_storm_detect_enabled, false);
+   i915_hpd_storm_reset(dev_priv);
+   break;
+   case HPD_STORM_ENABLE:
+   DRM_DEBUG_KMS("Enabling HPD storm detection\n");
+
+   i915_hpd_storm_reset(dev_priv);
+   hotplug->hpd_storm_detect_enabled = true;
+   break;
+   case HPD_STORM_RESET:
+   DRM_DEBUG_KMS("Resetting HPD storm stats\n");
+
+   i915_hpd_storm_reset(dev_priv);
+   break;
+   }
+
+   return len;
+}
+
+static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
+}
+
+static const struct file_operations i915_hpd_storm_ctl_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_hpd_storm_ctl_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_hpd_storm_ctl_write
+};
+
 static int i915_debugfs_create(struct dentry *root,
   struct drm_minor *minor,
   const char *name,
@@ -4717,7 +4816,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
-   {"i915_guc_log_control", _guc_log_control_fops}
+   {"i915_guc_log_control", _guc_log_control_fops},
+   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops}
 };
 
 int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git 

Re: [PATCH v5 0/3] Allow ASYNC flip with atomic helpers.

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 02/04/2017 04:46 AM, Alex Deucher wrote:
> On Thu, Feb 2, 2017 at 4:56 PM, Andrey Grodzovsky
>  wrote:
>> This series is a folow-up on
>> https://patchwork.kernel.org/patch/9501787/
>>
>> The first patch makes changes to atomic helpers to allow for drives with 
>> ASYNC flip support to use them.
>> Patch 2 is to use this in AMDGPU/DC.
>> Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate 
>> the helper as we did to support ASYNC flips.
>>
>> v2:
>> Resend drm/atomic: Save flip flags in drm_plane_state since the original 
>> patch was incomplete.
>> Squash 2 AMD changes into one to not break compilation.
>>
>> v3:
>> Following Daniel's comments, save flip flags in crtc_state instead of 
>> plane_state.
>>
>> v4:
>> Lauren's comment, reset flp flags before using again.
>> Harry's comment, fix identation in amd/display.
>>
>> v5:
>> Rename the flag, fix typo in header.
> 
> Looks good.  The series is:
> Reviewed-by: Alex Deucher 
> Unless there are any objections I'll push to drm-misc today.
> 
> Thanks!
> 
> Alex
> 
>>
>> Andrey Grodzovsky (3):
>>   drm/atomic: Save flip flags in drm_crtc_state
>>   drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
>>   drm/amd/display: Switch to using atomic_helper for flip.
>>
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   1 -
>>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 
>> +
>>  drivers/gpu/drm/drm_atomic_helper.c|  20 ++--
>>  drivers/gpu/drm/nouveau/nv50_display.c |  84 ++-
>>  include/drm/drm_crtc.h |   9 +-
>>  5 files changed, 48 insertions(+), 179 deletions(-)
>>
>> --
>> 1.9.1
>>
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm: mxsfb: fix error return code in mxsfb_load()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index cdfbe02..28a75cb 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -221,6 +221,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
  drm->mode_config.num_connector);
if (IS_ERR(mxsfb->fbdev)) {
+   ret = PTR_ERR(mxsfb->fbdev);
mxsfb->fbdev = NULL;
dev_err(drm->dev, "Failed to init FB CMA area\n");
goto err_cma;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm: remove unnecessary fault wrappers

[Ross Zwisler]

The fault wrappers drm_vm_fault(), drm_vm_shm_fault(), drm_vm_dma_fault()
and drm_vm_sg_fault() used to provide extra logic beyond what was in the
"drm_do_*" versions of these functions, but as of this commit:

commit ca0b07d9a969 ("drm: convert drm from nopage to fault.")

They are just unnecessary wrappers that do nothing.  Remove them, and
rename the the drm_do_* fault handlers to remove the "do_" since they no
longer have corresponding wrappers.

Signed-off-by: Ross Zwisler 
Reviewed-by: Sean Paul 
Acked-by: Daniel Vetter 

---

Andrew,

I initially posted this to the dri-devel list, but Daniel Vetter thought it
would be better to have it go through your MM tree to avoid merge
conflicts.  This code was recently changed in the MM tree by Dave Jiang,
which is why I was looking at it.  Here's the previous posting along with
that discussion:

https://lkml.org/lkml/2017/1/30/794

This patch applies cleanly to v4.10-rc6-mmots-2017-02-02-16-28.

The only difference from v2 is the mail list I'm sending it to and the
added Reviewed-by and Acked-by tags.

Thanks,
- Ross
---
 drivers/gpu/drm/drm_vm.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index bae6e26..1170b32 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -96,7 +96,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct 
vm_area_struct *vma)
  * map, get the page, increment the use count and return it.
  */
 #if IS_ENABLED(CONFIG_AGP)
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -169,7 +169,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS; /* Disallow mremap */
 }
 #else
-static int drm_do_vm_fault(struct vm_fault *vmf)
+static int drm_vm_fault(struct vm_fault *vmf)
 {
return VM_FAULT_SIGBUS;
 }
@@ -185,7 +185,7 @@ static int drm_do_vm_fault(struct vm_fault *vmf)
  * Get the mapping, find the real physical page to map, get the page, and
  * return it.
  */
-static int drm_do_vm_shm_fault(struct vm_fault *vmf)
+static int drm_vm_shm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -287,7 +287,7 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
  *
  * Determine the page number from the page offset and get it from 
drm_device_dma::pagelist.
  */
-static int drm_do_vm_dma_fault(struct vm_fault *vmf)
+static int drm_vm_dma_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -322,7 +322,7 @@ static int drm_do_vm_dma_fault(struct vm_fault *vmf)
  *
  * Determine the map offset from the page offset and get it from 
drm_sg_mem::pagelist.
  */
-static int drm_do_vm_sg_fault(struct vm_fault *vmf)
+static int drm_vm_sg_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -349,26 +349,6 @@ static int drm_do_vm_sg_fault(struct vm_fault *vmf)
return 0;
 }
 
-static int drm_vm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_fault(vmf);
-}
-
-static int drm_vm_shm_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_shm_fault(vmf);
-}
-
-static int drm_vm_dma_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_dma_fault(vmf);
-}
-
-static int drm_vm_sg_fault(struct vm_fault *vmf)
-{
-   return drm_do_vm_sg_fault(vmf);
-}
-
 /** AGP virtual memory operations */
 static const struct vm_operations_struct drm_vm_ops = {
.fault = drm_vm_fault,
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

[Øyvind A . Holm]

This reverts commit 2d8e60e8b0742b7a5cddc806fe38bb81ee876c33.

The commit belongs to the series of 1285 patches sent to LKML on
2016-08-02, it changes the representation of file permissions from the
octal value "0600" to "S_IRUSR | S_IWUSR".

The general consensus was that the changes does not increase
readability, quite the opposite; 0600 is easier to parse mentally than
S_IRUSR | S_IWUSR.

It also causes argument inconsistency, due to commit 04319d89fbec
("drm/vmwgfx: Add an option to change assumed FB bpp") that added
another call to module_param_named() where the permissions are written
as 0600.

Signed-off-by: Øyvind A. Holm 
---
This is a resend of the patch originally sent on 2017-01-16. The only
difference from v1 is an improved commit message with some more details.

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 18061a4bc2f2..e8ae3dc476d1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -241,15 +241,15 @@ static int vmwgfx_pm_notifier(struct notifier_block *nb, 
unsigned long val,
  void *ptr);
 
 MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
-module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
+module_param_named(enable_fbdev, enable_fbdev, int, 0600);
 MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
-module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
+module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
 MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
-module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | S_IWUSR);
+module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
 MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
-module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | S_IWUSR);
+module_param_named(force_coherent, vmw_force_coherent, int, 0600);
 MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with IOMMU");
-module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | 
S_IWUSR);
+module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
 MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
 module_param_named(assume_16bpp, vmw_assume_16bpp, int, 0600);
 
-- 
2.12.0.rc0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm: mxsfb: Make local symbol mxsfb_funcs static

[Wei Yongjun]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/gpu/drm/mxsfb/mxsfb_drv.c:129:38: warning:
 symbol 'mxsfb_funcs' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index cdfbe02..ff0495d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -126,7 +126,7 @@ static int mxsfb_pipe_prepare_fb(struct 
drm_simple_display_pipe *pipe,
return drm_fb_cma_prepare_fb(>plane, plane_state);
 }
 
-struct drm_simple_display_pipe_funcs mxsfb_funcs = {
+static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
.enable = mxsfb_pipe_enable,
.disable= mxsfb_pipe_disable,
.update = mxsfb_pipe_update,



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm: omap: use common OF graph helpers

[Rob Herring]

The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.

In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c  | 102 +-
 drivers/gpu/drm/omapdrm/dss/dss.c |  61 +---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c   |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c   |   2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  11 
 drivers/gpu/drm/omapdrm/dss/venc.c|   3 +-
 8 files changed, 23 insertions(+), 163 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e75162d26ac0..e5bb494d4689 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -855,7 +855,7 @@ int dpi_init_port(struct platform_device *pdev, struct 
device_node *port)
if (!dpi)
return -ENOMEM;
 
-   ep = omapdss_of_get_next_endpoint(port, NULL);
+   ep = of_get_next_child(port, NULL);
if (!ep)
return 0;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index f060bda31235..a9235b9fdaaf 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5091,7 +5091,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;
 
-   ep = omapdss_of_get_first_endpoint(node);
+   ep = of_graph_get_endpoint_by_regs(node, 0, 0);
if (!ep)
return 0;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e9621e3b..eb520ab45ddd 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,77 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "omapdss.h"
 #include "dss.h"
 
-struct device_node *
-omapdss_of_get_next_port(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *port = NULL;
-
-   if (!parent)
-   return NULL;
-
-   if (!prev) {
-   struct device_node *ports;
-   /*
-* It's the first call, we have to find a port subnode
-* within this node or within an optional 'ports' node.
-*/
-   ports = of_get_child_by_name(parent, "ports");
-   if (ports)
-   parent = ports;
-
-   port = of_get_child_by_name(parent, "port");
-
-   /* release the 'ports' node */
-   of_node_put(ports);
-   } else {
-   struct device_node *ports;
-
-   ports = of_get_parent(prev);
-   if (!ports)
-   return NULL;
-
-   do {
-   port = of_get_next_child(ports, prev);
-   if (!port) {
-   of_node_put(ports);
-   return NULL;
-   }
-   prev = port;
-   } while (of_node_cmp(port->name, "port") != 0);
-
-   of_node_put(ports);
-   }
-
-   return port;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_port);
-
-struct device_node *
-omapdss_of_get_next_endpoint(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *ep = NULL;
-
-   if (!parent)
-   return NULL;
-
-   do {
-   ep = of_get_next_child(parent, prev);
-   if (!ep)
-   return NULL;
-   prev = ep;
-   } while (of_node_cmp(ep->name, "endpoint") != 0);
-
-   return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_endpoint);
-
 struct device_node *dss_of_port_get_parent_device(struct device_node *port)
 {
struct device_node *np;
@@ -123,37 +58,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
return reg;
 }
 
-static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
-{
-   struct device_node *np;
-
-   np = of_parse_phandle(node, "remote-endpoint", 0);
-   if (!np)
-   return NULL;
-
-   np = of_get_next_parent(np);
-
-   return np;
-}
-
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
-   struct device_node *port, *ep;
-
-   port = omapdss_of_get_next_port(parent, NULL);
-
-   if (!port)
-   return NULL;
-
-   ep = 

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Fabio Estevam]

On Sun, Feb 5, 2017 at 8:25 PM, Rob Herring  wrote:

> Did the bridge driver probe? This function just checks lists of
> registered panels and bridges.

The tda998x_probe() returns success, but tda998x_bind() is never called.

I am trying to understand what needs to be done in
drivers/gpu/drm/mxsfb/ so that it can bind the tda998x driver.

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Mauro Carvalho Chehab]

Em Thu, 5 Jan 2017 20:27:17 +0200
Sakari Ailus  escreveu:

> Hi Randy,
> 
> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
> > 
> > 
> > On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
> > >Hi Randy,
> > >
> > >Thanks for the update.
> > >
> > >On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
> > >>The formats added by this patch are:
> > >>  V4L2_PIX_FMT_P010
> > >>  V4L2_PIX_FMT_P010M
> > >>  V4L2_PIX_FMT_P016
> > >>  V4L2_PIX_FMT_P016M
> > >>Currently, none of driver uses those format, but some video device
> > >>has been confirmed with could as those format for video output.
> > >>The Rockchip's new decoder has supported those 10 bits format for
> > >>profile_10 HEVC/AVC video.
> > >>
> > >>Signed-off-by: Randy Li 
> > >>
> > >>v4l2
> > >>---
> > >>  Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 
> > >>  Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++
> > >>  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 
> > >> 
> > >>  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 
> > >> ++  
> > >You need to include the formats in pixfmt.rst in order to compile the
> > >documentation.
> > >
> > >$ make htmldocs
> > >
> > >And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
> > >
> > >In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
> > >.  
> > OK, I would fix them in new version.
> > The view of byte order for P010 serial is left empty, it is a little hard
> > for me to use flat-table to draw them. Is there possible to use something
> > like latex to do this job?  
> 
> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
> ReST being more simple to use AFAIU. I think LaTeX output could be produced
> ReST, that might not be very helpful here though.

No, you can't use LaTeX, as it won't be properly displayed on all output
formats. There are a few options to define tables in ReST, but we prefer
using flat-table because the other formats are harder to maintain at the
V4L2 uAPI documentation.

Just one note about this series: it won't be merged upstream until
someone adds a driver needing those pixel formats.

Regards,
Mauro


Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] DRM OF graph clean-up

[Russell King - ARM Linux]

On Fri, Feb 03, 2017 at 09:36:30PM -0600, Rob Herring wrote:
> The Armada and Rockchip drivers remain oddballs with their own graph 
> parsing. I can't see how the armada driver even can work. There's 
> nothing to instantiate the armada-drm device either in DT or the kernel.

Correct, that's sitting out of tree because it requires either legacy
code in arch/arm/mach-dove at the moment, or stuff for DT.  Each time
that I looked at the DT reserved memory stuff I've ended up giving up
as it always seemed to be half complete, and the documentation was
confusing (seemingly referring to things that weren't merged.)

Maybe that's changed today, but I've not had a chance to look at it
again.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] of: introduce of_graph_get_remote_node

[Vladimir Zapolskiy]

Hi Rob,

On 02/04/2017 05:36 AM, Rob Herring wrote:
> The OF graph API leaves too much of the graph walking to clients when
> in many cases the driver doesn't care about accessing the port or
> endpoint nodes. The drivers typically just want the device connected via
> a particular graph connection. of_graph_get_remote_node provides this
> functionality.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/of/base.c| 28 
>  include/linux/of_graph.h |  8 
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..ea18ab16b92c 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2469,3 +2469,31 @@ struct device_node *of_graph_get_remote_port(const 
> struct device_node *node)
>   return of_get_next_parent(np);
>  }
>  EXPORT_SYMBOL(of_graph_get_remote_port);
> +
> +struct device_node *of_graph_get_remote_node(const struct device_node *node,
> +  int port, int endpoint)

it would be nice to add a short comment that a returned device
node is expected to be dereferenced with of_node_put().

> +{
> + struct device_node *endpoint_node, *remote;
> +
> + endpoint_node = of_graph_get_endpoint_by_regs(node, port, endpoint);
> + if (!endpoint_node) {
> + pr_debug("no valid endpoint (%d, %d) for node %s\n",
> +  port, endpoint, node->full_name);
> + return NULL;
> + }
> +
> + remote = of_graph_get_remote_port_parent(endpoint_node);
> + of_node_put(endpoint);

Typo, here it should be of_node_put(endpoint_node);

> + if (!remote) {
> + pr_debug("no valid remote node\n");
> + return NULL;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + pr_debug("not available for remote node\n");
> + return NULL;
> + }
> +
> + return remote;
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_node);

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99528] Wine game doesn't redraw properly in fullscreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99528

--- Comment #6 from Fabian Maurer  ---
(In reply to fin4478 from comment #4)
> Those stock kernels have very little new  amdgpu and radeon drivers code
> (see diff in kernel.org), use latest drivers when you make bug reports. This
> kernel is latest and stable:
> https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.11-wip
Thanks, didn't know that. There's also
https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next

Which one of those should I chose, they both seem to be fairly recent. But why
is it 4.11?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99685] [amdgpu R9 390X] GPU hang on windows switching while running Quetoo

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99685

Bug ID: 99685
   Summary: [amdgpu R9 390X] GPU hang on windows switching while
running Quetoo
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: d...@illwieckz.net
QA Contact: dri-devel@lists.freedesktop.org

Hi, I trigger a GPU hang whenever I switch between the Quetoo window and
another windows using Alt+Tab. A map must be loaded to trigger the hang. Once
the GPU hanged, the display does not update (but everything else is still
running, I can hear sound effects, connect from a remote computer to monitor
things etc) and every action that query the GPU will hang, for example after
the display hang, it's not possible to run clinfo otherwise it will never
return.

GPU: R9 390X
Distro: Ubuntu 16.10
Kernel: Linux 4.9.0-6.1 (from https://liquorix.net/ )
KMD: amdgpu
UMD: Mesa 17.1.0-devel (from
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa )

How to trigger the bug:

1. Untar Quetoo prebuild binary (from http://quetoo.org/pages/downloads )
2. run bin/quetoo-update to get data
3. delete lib/libdrm.so.2 and lib/libstdc++.so.6 from quetoo dir if needed
4. run bin/quetoo
5. load a map (or join a server)
6. do the Alt+Tab thing to switch between windows and come back to Quetoo.

If you want to build quetoo yourself, you can run it that way after having
built it:
$ src/main/quetoo -p …/quetoo/share/default -p …/quetoo/lib/default

"…/quetoo" being the path where you ran quetoo-update before (share/default
contains pk3 game data and lib/default contains glsl etc.)

I don't know if the bug is on Mesa side or kernel side.

dmesg
http://pastebin.com/eQt6radD
Xorg.0.log
http://pastebin.com/Ge11mwN6
journactl /usr/lib/gdm3/gdm-x-session
http://pastebin.com/3hYX08H7

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99488] [r600g]OpenCL driver causes ImageMagick to hang on JPEG input in Gaussian Blur kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99488

--- Comment #7 from Jan Vesely  ---
Thanks for the info. I think it's the same bug that hangs GROMACS kernel (my
patch was originally written to debug GROMACS).
you can change the assert to if and use "I->dump()" to print the triggering
instruction.
If it's "MOVA_INT_eg" then it's the same bug that hangs GROMACS.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99450

--- Comment #4 from fin4...@hotmail.com ---
Use latest amdgpu driver, those stock kernels are buggy.
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.11-wip
Also Oibaf ppa have latest mesa and Debian testing Xfce is more stable, easier
and compatible than Majanro Linux.

(In reply to Hugo Posnic from comment #3)
> I've receive the 13.0.4 update but still the same problem...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99528] Wine game doesn't redraw properly in fullscreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99528

--- Comment #5 from fin4...@hotmail.com ---
Also Debian testing Xfce is more stable, easier and compatible than Arch Linux.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99528] Wine game doesn't redraw properly in fullscreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99528

--- Comment #4 from fin4...@hotmail.com ---
(In reply to Fabian Maurer from comment #3)
> Still present for me with mesa 88752.3f064e9a40 and linux 4.9.6.

Those stock kernels have very little new  amdgpu and radeon drivers code (see
diff in kernel.org), use latest drivers when you make bug reports. This kernel
is latest and stable:
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.11-wip

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99450

Hugo Posnic  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #3 from Hugo Posnic  ---
I've receive the 13.0.4 update but still the same problem...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99488] [r600g]OpenCL driver causes ImageMagick to hang on JPEG input in Gaussian Blur kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99488

--- Comment #6 from nixscrip...@gmail.com ---
Replicating the issue again, here is the backtrace you requested:

(gdb) bt
#0  0x03b11dea95d4 in
llvm::MachineInstr::findRegisterUseOperandIdx(unsigned int, bool,
llvm::TargetRegisterInfo const*) const ()
   from /usr/lib/libLLVM-5.0svn.so
#1  0x03b11ed8c96e in (anonymous
namespace)::R600EmitClauseMarkers::MakeALUClause(llvm::MachineBasicBlock&,
llvm::MachineInstrBundleIterator) () from
/usr/lib/libLLVM-5.0svn.so
#2  0x03b11ed8d7fe in (anonymous
namespace)::R600EmitClauseMarkers::runOnMachineFunction(llvm::MachineFunction&)
() from /usr/lib/libLLVM-5.0svn.so
#3  0x03b11dea3bf1 in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from
/usr/lib/libLLVM-5.0svn.so
#4  0x03b11dd19342 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib/libLLVM-5.0svn.so
#5  0x03b11dd193e3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
   from /usr/lib/libLLVM-5.0svn.so
#6  0x03b11dd19d94 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from /usr/lib/libLLVM-5.0svn.so
#7  0x03b120ede12c in ?? () from /usr/lib/libMesaOpenCL.so.1
#8  0x03b120ede790 in ?? () from /usr/lib/libMesaOpenCL.so.1
#9  0x03b120eda9ad in ?? () from /usr/lib/libMesaOpenCL.so.1
#10 0x03b120ecb9f9 in ?? () from /usr/lib/libMesaOpenCL.so.1
#11 0x03b120ea98dc in ?? () from /usr/lib/libMesaOpenCL.so.1
#12 0x03b1220f450b in clBuildProgram () from /usr/lib/libOpenCL.so
#13 0x03b127156afe in CompileOpenCLKernels ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#14 0x03b12715728d in InitOpenCLEnvInternal ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#15 0x03b1271573f1 in AcceleratePerfEvaluator ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#16 0x03b127157e5a in autoSelectDevice ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#17 0x03b127158944 in InitOpenCLEnv ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#18 0x03b127051400 in checkOpenCLEnvironment ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#19 0x03b127054a2d in AccelerateBlurImage ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#20 0x03b1270f0c13 in BlurImageChannel ()
   from /usr/lib/libMagickCore-6.Q16HDRI.so.4
#21 0x03b126d9efd0 in MogrifyImage ()
   from /usr/lib/libMagickWand-6.Q16HDRI.so.4
#22 0x03b126da6200 in MogrifyImages ()
   from /usr/lib/libMagickWand-6.Q16HDRI.so.4
#23 0x03b126d2bb86 in ConvertImageCommand ()
   from /usr/lib/libMagickWand-6.Q16HDRI.so.4
#24 0x03b126d9b3ee in MagickCommandGenesis ()
   from /usr/lib/libMagickWand-6.Q16HDRI.so.4
#25 0x004007c7 in main ()

As you can see, it's a different function at the top of the stack this time.
That's beacuse, as you suspected, it is not the culprit. I was just lucky
finding findRegisterDefOperandIdx at the top of the stack when I tested this
before several times.

Per your suggestion, I did "finish" repeatedly until I could find the danging
function:

gdb) finish
Run till exit from #0  0x03b11dea95d4 in
llvm::MachineInstr::findRegisterUseOperandIdx(unsigned int, bool,
llvm::TargetRegisterInfo const*) const ()
   from /usr/lib/libLLVM-5.0svn.so
0x03b11ed8c96e in (anonymous
namespace)::R600EmitClauseMarkers::MakeALUClause(llvm::MachineBasicBlock&,
llvm::MachineInstrBundleIterator) () from
/usr/lib/libLLVM-5.0svn.so
(gdb) finish
Run till exit from #0  0x03b11ed8c96e in (anonymous
namespace)::R600EmitClauseMarkers::MakeALUClause(llvm::MachineBasicBlock&,
llvm::MachineInstrBundleIterator) () from
/usr/lib/libLLVM-5.0svn.so
0x03b11ed8d7fe in (anonymous
namespace)::R600EmitClauseMarkers::runOnMachineFunction(llvm::MachineFunction&)
() from /usr/lib/libLLVM-5.0svn.so
(gdb) finish
Run till exit from #0  0x03b11ed8d7fe in (anonymous
namespace)::R600EmitClauseMarkers::runOnMachineFunction(llvm::MachineFunction&)
()
   from /usr/lib/libLLVM-5.0svn.so
[ ... hangs... ]

So it seems your patch is on the right track.

In addition, I was making a release build. because that was the default in the
recipe file. I am building a debug build as I write this, including your
attached patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #13 from Samuel Pitoiset  ---
My version 1.5, can you try upgrading? I don't see that "blood effects"
options. Last time I tried to reproduce the issue, I used many different
graphics options without success.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99683] Powerplay features request: manually set GPU (Fiji) frequency beyond default limits and per application

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99683

Bug ID: 99683
   Summary: Powerplay features request: manually set GPU (Fiji)
frequency beyond default limits and per application
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bug0xa...@hushmail.com

My R9 Nano is watercooled and does not get hot even when operating at 1000mhz,
its' max frequency.

1) I request the ability to manually set the frequency beyond 1000mhz.

2) I would like the ability to have user determined frequencies to
automatically be applied per application or process as well.

For example: I set somewhere that the GPU runs DOTA2 at 1200mhz until the game
process ends.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v17 0/7] drm/rockchip: Add CDN DP driver

[Mark yao]

Hi Chris

Applied to my drm-next and already sent pull request to Dave.

Thanks.

On 2017年02月05日 15:54, Chris Zhong wrote:

This series adds support for the CDN DP controller to the rockchip drm
driver. This version fixes some coding style error in v16, it post by
Sean Paul, you can find it here:
https://patchwork.kernel.org/patch/9442135/

And I sorted out a few patches to fix the following problems:
- suspend/resume crash cause by drm_helper_hpd_irq_event
- crash during shutdown when cdn-dp failed to bind
- check sink count failed after reconnection
- suspend/reusme crash in mode_set function

I also added these 2 patches to this series, although nothing changed:
https://patchwork.kernel.org/patch/9442141/
https://patchwork.kernel.org/patch/9442151/


Changes in v17:
- Correct the clock check condition
- Correct the coding style
- change LANE_REF_CYC to 0x8000

Chris Zhong (4):
   drm/rockchip: cdn-dp: add cdn DP support for rk3399
   drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event
   drm/rockchip: cdn-dp: retry to check sink count
   drm/rockchip: cdn-dp: don't configure hardware in mode_set

Guenter Roeck (2):
   drm/rockchip: cdn-dp: Load firmware if no monitor connected
   drm/rockchip: cdn-dp: Do not run worker while suspended

Jeffy Chen (1):
   drm/rockchip: cdn-dp: Move mutex_init to probe

  drivers/gpu/drm/rockchip/Kconfig|   10 +
  drivers/gpu/drm/rockchip/Makefile   |2 +
  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1260 +++
  drivers/gpu/drm/rockchip/cdn-dp-core.h  |  112 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  979 +
  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  483 ++
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
  9 files changed, 2867 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h




--
Ｍark Yao


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] drm/rockchip: add cdn-dp support and some fixes

[Mark yao]

Hi Dave

drm/rockchip cdn-dp driver is v17 now, I think it's ready to land it.

Thanks.

The following changes since commit 99743ae4c5f52f8f8ceb17783056fcc9b4f8b64c:

  Merge branch 'drm-etnaviv-next' of 
https://git.pengutronix.de/git/lst/linux into drm-next (2017-02-03 
05:41:58 +1000)


are available in the git repository at:

  https://github.com/markyzq/kernel-drm-rockchip.git 
drm-rockchip-next-2017-02-05


for you to fetch changes up to ef1844b7ed847430955a95d20242f0d1b9f5fa64:

  drm/rockchip: cdn-dp: don't configure hardware in mode_set 
(2017-02-05 16:30:11 +0800)



Chris Zhong (5):
  drm/rockchip: vop: make vop register setting take effect
  drm/rockchip: cdn-dp: add cdn DP support for rk3399
  drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event
  drm/rockchip: cdn-dp: retry to check sink count
  drm/rockchip: cdn-dp: don't configure hardware in mode_set

Guenter Roeck (2):
  drm/rockchip: cdn-dp: Load firmware if no monitor connected
  drm/rockchip: cdn-dp: Do not run worker while suspended

Jeffy Chen (1):
  drm/rockchip: cdn-dp: Move mutex_init to probe

Julia Lawall (1):
  drm/rockchip: return ERR_PTR instead of NULL

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |2 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1260 
++

 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  112 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  979 
++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  483 


 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   17 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 10 files changed, 2872 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

-- Ｍark Yao

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel