date:20151014

[PATCH v4 2/6] apple-gmux: Add switch_ddc support

2015-10-14 Thread Darren Hart

On Fri, Aug 14, 2015 at 06:18:55PM +0200, Lukas Wunner wrote:
> Originally by Seth Forshee , 2012-10-04:
> The gmux allows muxing the DDC independently from the display, so
> support this functionality. This will allow reading the EDID for the
> inactive GPU, fixing issues with machines that either don't have a
> VBT or have invalid mode data in the VBT.
> 
> Modified by Lukas Wunner , 2015-10-07:
> Advertise ->switch_ddc handler callback only on the pre-retina
> Macbook Pro. The retina uses eDP and its mux is incapable of
> switching the AUX channel separately from the main link.
> It's an NXP CBTL06142 (alternate parts: TI HD3SS212,
> Pericom PPI3VDP12412).
> 
> Sources:
> http://www.electronicproducts.com/-whatsinside_text-145.aspx
> 
> http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display
> 
> http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/
> 
> Datasheets:
> http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
> https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
> Tested-by: Lukas Wunner 
> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
> 
> Cc: Seth Forshee 
> Signed-off-by: Lukas Wunner 

For platform/drivers/x86:

Acked-by: Darren Hart 

Daniel, I presume this will ultimately get pulled in by you with the rest of the
series?
-- 
Darren Hart
Intel Open Source Technology Center

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)!

2015-10-14 Thread Darren Hart

On Mon, Oct 12, 2015 at 10:02:06AM +0300, Jani Nikula wrote:
> On Sat, 10 Oct 2015, Darren Hart  wrote:
> > The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
> > bisection.
> >
> > The warning was added by:
> > 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
> >  2014-06-18 (1 year, 4 months ago), Oscar Mateo 
> 
> But we don't start hitting the warning right away with that commit, do
> we? There's a bug about this with a bisected bad commit [1], please
> let's track this there.

I did a google search and didn't find any relevant hits for this error. So I
reported it here. I should ahve searched the bug list also. I'll do that next
time.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH 01/22] drm: Add drm_format_plane_width() and drm_format_plane_height()

2015-10-14 Thread ville.syrj...@linux.intel.com

From: Ville SyrjÃ¤lÃ¤ 

Add a few helpers to get the dimensions of the chroma plane(s).

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville SyrjÃ¤lÃ¤ 
---
 include/drm/drm_crtc.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 33ddedd..317baf9 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1497,6 +1497,18 @@ extern int drm_format_num_planes(uint32_t format);
 extern int drm_format_plane_cpp(uint32_t format, int plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
+static inline int drm_format_plane_width(int width, uint32_t format, int plane)
+{
+   if (plane == 0)
+   return width;
+   return width / drm_format_horz_chroma_subsampling(format);
+}
+static inline int drm_format_plane_height(int height, uint32_t format, int 
plane)
+{
+   if (plane == 0)
+   return height;
+   return height / drm_format_vert_chroma_subsampling(format);
+}
 extern const char *drm_get_format_name(uint32_t format);
 extern struct drm_property *drm_mode_create_rotation_property(struct 
drm_device *dev,
  unsigned int 
supported_rotations);
-- 
2.4.9

[PATCH RFC 5/5] gpu/doc: Convert to markdown harder

2015-10-14 Thread Daniel Vetter

On Wed, Oct 14, 2015 at 05:54:31PM +0200, Lukas Wunner wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 11:04:37AM -0300, Danilo Cesar Lemes de Paula wrote:
> > On 10/14/2015 10:59 AM, Daniel Vetter wrote:
> > > On Mon, Oct 12, 2015 at 09:10:33AM +0200, Lukas Wunner wrote:
> > >> This snippet...
> > >>
> > >> * Lock VMA manager for extended lookups. Only *_locked() VMA 
> > >> function calls
> > >> * are allowed while holding this lock. All other contexts are 
> > >> blocked from VMA
> > >> * until the lock is released via drm_vma_offset_unlock_lookup().
> > >>
> > >> ...causes markdown-enabled kernel-doc to barf:
> > >>
> > >> debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: 
> > >> parser error : Opening and ending tag mismatch: emphasis line 3247 and 
> > >> function
> > >>*locked VMA function calls are 
> > >> allowed while
> > >>  ^
> > >> 
> > >> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249:
> > >>  parser error : Opening and ending tag mismatch: function line 3249 and 
> > >> emphasis
> > >>released via 
> > >> drmvma_offset_unlock_lookup.
> > >> ^
> > >> unable to parse 
> > >> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml
> > >>
> > >> A quick workaround is to replace *_locked() by X_locked().
> > >>
> > >> Cc: Danilo Cesar Lemes de Paula 
> > >> Signed-off-by: Lukas Wunner 
> > >> ---
> > >>  include/drm/drm_vma_manager.h | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/include/drm/drm_vma_manager.h 
> > >> b/include/drm/drm_vma_manager.h
> > >> index 2ca44db..c1e41b8 100644
> > >> --- a/include/drm/drm_vma_manager.h
> > >> +++ b/include/drm/drm_vma_manager.h
> > >> @@ -97,7 +97,7 @@ drm_vma_offset_exact_lookup(struct 
> > >> drm_vma_offset_manager *mgr,
> > >>   * drm_vma_offset_lock_lookup() - Lock lookup for extended private use
> > >>   * @mgr: Manager object
> > >>   *
> > >> - * Lock VMA manager for extended lookups. Only *_locked() VMA function 
> > >> calls
> > >> + * Lock VMA manager for extended lookups. Only X_locked() VMA function 
> > >> calls
> > > 
> > > I went with a plain _unlocked since the X_unlocked looked a bit strange.
> > > Anyway Dave acked the rename idea on irc, so all applied. Well except
> > > patch 1, there wasn't any conflict when I pushed this to drm-misc.
> > > -Daniel
> > 
> > I didn't test it (not a big fan of doing this), but \* or \_ should
> > escape the sequence. Did you consider that?
> 
> I did test \* and it didn't help.
> I can't remember if I also tested \_.
> 
> In any case the issue is not the asterisk but rather that the
> underscore in *_locked() is interpreted as the beginning of an
> _emphasis_. It seems any underscore at the beginning of a word is
> interpreted like that. The question is why the leading asterisk is
> not interpreted as the actual beginning of the word. Replacing the
> asterisk with an alphabetic character solved it.

Ok, missed that, so now we have just "locked" instead of "_locked()".
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/dp/mst: make mst i2c transfer code more robust.

2015-10-14 Thread Dave Airlie

This zeroes the msg so no random stack data ends up getting
sent, it also limits the function to not accepting > 4
i2c msgs.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
 include/drm/drm_dp_mst_helper.h   | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index bf27a07..5bca390 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2801,12 +2801,13 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter 
*adapter, struct i2c_msg *msgs
if (msgs[num - 1].flags & I2C_M_RD)
reading = true;

-   if (!reading) {
+   if (!reading || (num - 1 > DP_REMOTE_I2C_READ_MAX_TRANSACTIONS)) {
DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
ret = -EIO;
goto out;
}

+   memset(, 0, sizeof(msg));
msg.req_type = DP_REMOTE_I2C_READ;
msg.u.i2c_read.num_transactions = num - 1;
msg.u.i2c_read.port_number = port->port_num;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0f408b0..5340099 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -253,6 +253,7 @@ struct drm_dp_remote_dpcd_write {
u8 *bytes;
 };

+#define DP_REMOTE_I2C_READ_MAX_TRANSACTIONS 4
 struct drm_dp_remote_i2c_read {
u8 num_transactions;
u8 port_number;
@@ -262,7 +263,7 @@ struct drm_dp_remote_i2c_read {
u8 *bytes;
u8 no_stop_bit;
u8 i2c_transaction_delay;
-   } transactions[4];
+   } transactions[DP_REMOTE_I2C_READ_MAX_TRANSACTIONS];
u8 read_i2c_device_id;
u8 num_bytes_read;
 };
-- 
2.4.3

[PATCH 2/2] rnndb/dsi: Populate bitfields for SFPB_CFG register

2015-10-14 Thread Archit Taneja

Signed-off-by: Archit Taneja 
---
 rnndb/dsi/sfpb.xml | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/rnndb/dsi/sfpb.xml b/rnndb/dsi/sfpb.xml
index f42f867..a08c82f 100644
--- a/rnndb/dsi/sfpb.xml
+++ b/rnndb/dsi/sfpb.xml
@@ -5,7 +5,13 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">
 

 
-   
+   
+   
+   
+   
+   
+   
+   
 

 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/2] rnndb/dsi: Create proper domains for 8960 DSI

2015-10-14 Thread Archit Taneja

8960 DSI PHY/PLL is crumpled into one piece. Split it out into domains,
similar to the way we do for the 28nm/20nm DSI PHY/PLL domains.

Signed-off-by: Archit Taneja 
---
 rnndb/dsi/dsi.xml | 171 --
 1 file changed, 114 insertions(+), 57 deletions(-)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index 956f3ff..65d41a4 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -293,9 +293,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

-
+

-   
+   



@@ -304,65 +304,122 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-
-   
-   
-   
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
-   
-   
-   
-   
-
-   
-   
-   
-
-   
-   
-   
-   
-   
-
-   
-
-   
-   
-   
-   
-   
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
+   
+   
+   
+
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+
+   
+   
+   
+
+   
+   
+   
+   
+   
+
+   
+
+
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   


 

+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+
+
 


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/2] rnndb: dsi: Some updates for DSIv2

2015-10-14 Thread Archit Taneja

Archit Taneja (2):
  rnndb/dsi: Create proper domains for 8960 DSI
  rnndb/dsi: Populate bitfields for SFPB_CFG register

 rnndb/dsi/dsi.xml  | 171 +++--
 rnndb/dsi/sfpb.xml |   8 ++-
 2 files changed, 121 insertions(+), 58 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 12/12] dt-bindings: Add DSIv2 documentation

2015-10-14 Thread Archit Taneja

Add additional property info needed for DSIv2 DT.

Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/drm/msm/dsi.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt 
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index d56923c..75f8492 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -13,18 +13,25 @@ Required properties:
 - power-domains: Should be < MDSS_GDSC>.
 - clocks: device clocks
   See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: these vary based on the DSI version. For DSI6G:
   * "bus_clk"
   * "byte_clk"
+  * "byte_clk_src
   * "core_clk"
   * "core_mmss_clk"
   * "iface_clk"
   * "mdp_core_clk"
   * "pixel_clk"
+  * "pixel_clk_src"
+  For DSIv2, we need a few more:
+   * "dsi_clk_src"
+   * "esc_clk_src"
+   * "src_clk"
 - vdd-supply: phandle to vdd regulator device node
 - vddio-supply: phandle to vdd-io regulator device node
 - vdda-supply: phandle to vdda regulator device node
 - qcom,dsi-phy: phandle to DSI PHY device node
+- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)

 Optional properties:
 - panel at 0: Node of panel connected to this DSI controller.
@@ -51,6 +58,7 @@ Required properties:
   * "qcom,dsi-phy-28nm-hpm"
   * "qcom,dsi-phy-28nm-lp"
   * "qcom,dsi-phy-20nm"
+  * "qcom,dsi-phy-28nm-8960"
 - reg: Physical base address and length of the registers of PLL, PHY and PHY
   regulator
 - reg-names: The names of register regions. The following regions are required:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 11/12] drm/msm/dsi: Enable MMSS SPFB port via syscon

2015-10-14 Thread Archit Taneja

For DSIv2 to work, we need to enable MMSS_AHB_ARB_MASTER_PORT in
MMSS_SFPB. We enable the required bitfield by retrieving MMSS_SFPB
regmap pointer via syscon.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 006591d..5f3142a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -24,10 +24,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 

 #include "dsi.h"
 #include "dsi.xml.h"
+#include "sfpb.xml.h"
 #include "dsi_cfg.h"

 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
@@ -149,6 +152,8 @@ struct msm_dsi_host {

u8 *rx_buf;

+   struct regmap *sfpb;
+
struct drm_display_mode *mode;

/* connected device info */
@@ -1573,6 +1578,16 @@ static int dsi_host_parse_dt(struct msm_dsi_host 
*msm_host)

msm_host->device_node = device_node;

+   if (of_property_read_bool(np, "syscon-sfpb")) {
+   msm_host->sfpb = syscon_regmap_lookup_by_phandle(np,
+   "syscon-sfpb");
+   if (IS_ERR(msm_host->sfpb)) {
+   dev_err(dev, "%s: failed to get sfpb regmap\n",
+   __func__);
+   return PTR_ERR(msm_host->sfpb);
+   }
+   }
+
return 0;
 }

@@ -2036,6 +2051,20 @@ int msm_dsi_host_disable(struct mipi_dsi_host *host)
return 0;
 }

+static void msm_dsi_sfpb_config(struct msm_dsi_host *msm_host, bool enable)
+{
+   enum sfpb_ahb_arb_master_port_en en;
+
+   if (!msm_host->sfpb)
+   return;
+
+   en = enable ? SFPB_MASTER_PORT_ENABLE : SFPB_MASTER_PORT_DISABLE;
+
+   regmap_update_bits(msm_host->sfpb, REG_SFPB_GPREG,
+   SFPB_GPREG_MASTER_PORT_EN__MASK,
+   SFPB_GPREG_MASTER_PORT_EN(en));
+}
+
 int msm_dsi_host_power_on(struct mipi_dsi_host *host)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
@@ -2048,6 +2077,8 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host)
goto unlock_ret;
}

+   msm_dsi_sfpb_config(msm_host, true);
+
ret = dsi_calc_clk_rate(msm_host);
if (ret) {
pr_err("%s: unable to calc clk rate, %d\n", __func__, ret);
@@ -2135,6 +2166,8 @@ int msm_dsi_host_power_off(struct mipi_dsi_host *host)

dsi_host_regulator_disable(msm_host);

+   msm_dsi_sfpb_config(msm_host, false);
+
DBG("-");

msm_host->power_on = false;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 10/12] drm/msm/dsi: SFPB: Update generated headers

2015-10-14 Thread Archit Taneja

Update SFPB register data now that we intend to use it.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/sfpb.xml.h | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/sfpb.xml.h 
b/drivers/gpu/drm/msm/dsi/sfpb.xml.h
index 06cbddf..63947b2 100644
--- a/drivers/gpu/drm/msm/dsi/sfpb.xml.h
+++ b/drivers/gpu/drm/msm/dsi/sfpb.xml.h
@@ -8,17 +8,8 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2576 bytes, from 2015-07-09 22:10:24)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
36021 bytes, from 2015-07-09 22:10:24)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
26057 bytes, from 2015-08-14 21:47:57)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
29154 bytes, from 2015-08-10 21:25:43)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2015-05-20 20:03:14)
+- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/dsi/sfpb.xml   (  
  602 bytes, from 2015-10-14 11:09:08)
+- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml (  
 1453 bytes, from 2015-02-09 03:18:10)

 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
@@ -45,7 +36,18 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 */


-#define REG_SFPB_CFG   0x0058
+enum sfpb_ahb_arb_master_port_en {
+   SFPB_MASTER_PORT_ENABLE = 3,
+   SFPB_MASTER_PORT_DISABLE = 0,
+};
+
+#define REG_SFPB_GPREG 0x0058
+#define SFPB_GPREG_MASTER_PORT_EN__MASK
0x1800
+#define SFPB_GPREG_MASTER_PORT_EN__SHIFT   11
+static inline uint32_t SFPB_GPREG_MASTER_PORT_EN(enum 
sfpb_ahb_arb_master_port_en val)
+{
+   return ((val) << SFPB_GPREG_MASTER_PORT_EN__SHIFT) & 
SFPB_GPREG_MASTER_PORT_EN__MASK;
+}


 #endif /* SFPB_XML */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 09/12] drm/msm/dsi: Don't use iommu for command TX buffer for DSIv2

2015-10-14 Thread Archit Taneja

We currently use iommu allocated DMA buffers for sending DSI commands.
DSIv2 doesn't have a port connected to the MDP iommu. Therefore, it
can't use iommu allocated buffers to fetch DSI commands.

Use a regular contiguous DMA buffer if we are DSIv2.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.h |   4 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c| 110 +++---
 drivers/gpu/drm/msm/dsi/dsi_manager.c |   6 +-
 3 files changed, 79 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 7336b55..749fbb2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -91,7 +91,7 @@ int msm_dsi_manager_phy_enable(int id,
u32 *clk_pre, u32 *clk_post);
 void msm_dsi_manager_phy_disable(int id);
 int msm_dsi_manager_cmd_xfer(int id, const struct mipi_dsi_msg *msg);
-bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 iova, u32 len);
+bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len);
 int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
 void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);

@@ -145,7 +145,7 @@ int msm_dsi_host_cmd_tx(struct mipi_dsi_host *host,
 int msm_dsi_host_cmd_rx(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
 void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host *host,
-   u32 iova, u32 len);
+   u32 dma_base, u32 len);
 int msm_dsi_host_enable(struct mipi_dsi_host *host);
 int msm_dsi_host_disable(struct mipi_dsi_host *host);
 int msm_dsi_host_power_on(struct mipi_dsi_host *host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 16c5cfb..006591d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -138,7 +138,15 @@ struct msm_dsi_host {
struct work_struct err_work;
struct workqueue_struct *workqueue;

+   /* DSI 6G TX buffer*/
struct drm_gem_object *tx_gem_obj;
+
+   /* DSI v2 TX buffer */
+   void *tx_buf;
+   dma_addr_t tx_buf_paddr;
+
+   int tx_size;
+
u8 *rx_buf;

struct drm_display_mode *mode;
@@ -988,29 +996,46 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host 
*msm_host)
 static int dsi_tx_buf_alloc(struct msm_dsi_host *msm_host, int size)
 {
struct drm_device *dev = msm_host->dev;
+   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
int ret;
u32 iova;

-   mutex_lock(>struct_mutex);
-   msm_host->tx_gem_obj = msm_gem_new(dev, size, MSM_BO_UNCACHED);
-   if (IS_ERR(msm_host->tx_gem_obj)) {
-   ret = PTR_ERR(msm_host->tx_gem_obj);
-   pr_err("%s: failed to allocate gem, %d\n", __func__, ret);
-   msm_host->tx_gem_obj = NULL;
+   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
+   mutex_lock(>struct_mutex);
+   msm_host->tx_gem_obj = msm_gem_new(dev, size, MSM_BO_UNCACHED);
+   if (IS_ERR(msm_host->tx_gem_obj)) {
+   ret = PTR_ERR(msm_host->tx_gem_obj);
+   pr_err("%s: failed to allocate gem, %d\n",
+   __func__, ret);
+   msm_host->tx_gem_obj = NULL;
+   mutex_unlock(>struct_mutex);
+   return ret;
+   }
+
+   ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj, 0, );
+   if (ret) {
+   pr_err("%s: failed to get iova, %d\n", __func__, ret);
+   return ret;
+   }
mutex_unlock(>struct_mutex);
-   return ret;
-   }

-   ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj, 0, );
-   if (ret) {
-   pr_err("%s: failed to get iova, %d\n", __func__, ret);
-   return ret;
-   }
-   mutex_unlock(>struct_mutex);
+   if (iova & 0x07) {
+   pr_err("%s: buf NOT 8 bytes aligned\n", __func__);
+   return -EINVAL;
+   }

-   if (iova & 0x07) {
-   pr_err("%s: buf NOT 8 bytes aligned\n", __func__);
-   return -EINVAL;
+   msm_host->tx_size = msm_host->tx_gem_obj->size;
+   } else {
+   msm_host->tx_buf = dma_alloc_coherent(dev->dev, size,
+   _host->tx_buf_paddr, GFP_KERNEL);
+   if (!msm_host->tx_buf) {
+   ret = -ENOMEM;
+   pr_err("%s: failed to allocate tx buf, %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   msm_host->tx_size = size;
}

return 0;
@@ -1027,14 +1052,19 @@ static void dsi_tx_buf_free(struct msm_dsi_host 
*msm_host)

[PATCH 08/12] drm/msm/dsi: Add dsi_cfg for APQ8064

2015-10-14 Thread Archit Taneja

Add a dsi_cfg entry for APQ8064. Since this is the first DSIv2 chip to
be supported, add a list of bus clocks that are required by the DSIv2
block.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 19 ---
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  2 ++
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index c40044f..2a827d8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -13,9 +13,22 @@

 #include "dsi_cfg.h"

-/* DSI v2 has not been supported by now */
-static const struct msm_dsi_config dsi_v2_cfg = {
+static const char * const dsi_v2_bus_clk_names[] = {
+   "core_mmss_clk", "iface_clk", "bus_clk",
+};
+
+static const struct msm_dsi_config apq8064_dsi_cfg = {
.io_offset = 0,
+   .reg_cfg = {
+   .num = 3,
+   .regs = {
+   {"vdda", 120, 120, 10, 100},
+   {"avdd", 300, 300, 11, 100},
+   {"vddio", 180, 180, 10, 100},
+   },
+   },
+   .bus_clk_names = dsi_v2_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_v2_bus_clk_names),
 };

 static const char * const dsi_6g_bus_clk_names[] = {
@@ -75,7 +88,7 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
 };

 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
-   {MSM_DSI_VER_MAJOR_V2, U32_MAX, _v2_cfg},
+   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
_apq8084_dsi_cfg},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 5a36836..a68c836 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -25,6 +25,8 @@
 #define MSM_DSI_6G_VER_MINOR_V1_3  0x1003
 #define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001

+#define MSM_DSI_V2_VER_MINOR_8064  0x0
+
 #define DSI_6G_REG_SHIFT   4

 struct msm_dsi_config {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 07/12] drm/msm/dsi: Set up link clocks for DSIv2

2015-10-14 Thread Archit Taneja

DSIv2 (DSI on older A family chips) has slightly different link clock
requirements.

First, we have an extra clock called src_clk (with a dedicated RCG).
This is required by the DSI controller to process the pixel data
coming from MDP. It needs to be set at the rate "pclk * bytes_per_pixel".

We also need to explicitly configure esc_clk. On DSI6G chips, we don't
need to set a rate to esc_clk because its RCG is always sourced from
crystal clock (19.2 Mhz in all cases), which is within the escape clock
frequency range in the mipi DSI spec. For chips with DSIv2, the crystal
clock rate may not be within the required range (27Mhz on APQ8064).
Therefore, we derive it from the DSI byte clock. We calculate an esc_clck
rate that is within the mipi spec and also divisible by the byte clock
rate.

When setting rate and enabling the link clocks, we make sure that byte_clk
is configured before esc_clk, and src_clk before pixel_clk. We create two
different link_enable funcs for DSI6G and DSIv2 since the sequences are
different.

We also obtain two extra source clocks (dsi_src_clk and esc_src_clk) and
set their parent to the clocks provided by DSI PLL.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 193 -
 1 file changed, 188 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 008726f..16c5cfb 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -113,6 +113,14 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;

u32 byte_clk_rate;
+   u32 esc_clk_rate;
+
+   /* DSI v2 specific clocks */
+   struct clk *src_clk;
+   struct clk *esc_clk_src;
+   struct clk *dsi_clk_src;
+
+   u32 src_clk_rate;

struct gpio_desc *disp_en_gpio;
struct gpio_desc *te_gpio;
@@ -318,7 +326,8 @@ static int dsi_regulator_init(struct msm_dsi_host *msm_host)
 static int dsi_clk_init(struct msm_dsi_host *msm_host)
 {
struct device *dev = _host->pdev->dev;
-   const struct msm_dsi_config *cfg = msm_host->cfg_hnd->cfg;
+   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
+   const struct msm_dsi_config *cfg = cfg_hnd->cfg;
int i, ret = 0;

/* get bus clocks */
@@ -377,6 +386,34 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}

+   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {
+   msm_host->src_clk = devm_clk_get(dev, "src_clk");
+   if (IS_ERR(msm_host->src_clk)) {
+   ret = PTR_ERR(msm_host->src_clk);
+   pr_err("%s: can't find dsi_src_clk. ret=%d\n",
+   __func__, ret);
+   msm_host->src_clk = NULL;
+   goto exit;
+   }
+
+   msm_host->esc_clk_src = devm_clk_get(dev, "esc_clk_src");
+   if (IS_ERR(msm_host->esc_clk_src)) {
+   ret = PTR_ERR(msm_host->esc_clk_src);
+   pr_err("%s: can't find esc_clk_src. ret=%d\n",
+   __func__, ret);
+   msm_host->esc_clk_src = NULL;
+   goto exit;
+   }
+
+   msm_host->dsi_clk_src = devm_clk_get(dev, "dsi_clk_src");
+   if (IS_ERR(msm_host->dsi_clk_src)) {
+   ret = PTR_ERR(msm_host->dsi_clk_src);
+   pr_err("%s: can't find dsi_clk_src. ret=%d\n",
+   __func__, ret);
+   msm_host->dsi_clk_src = NULL;
+   goto exit;
+   }
+   }
 exit:
return ret;
 }
@@ -416,7 +453,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host 
*msm_host)
clk_disable_unprepare(msm_host->bus_clks[i]);
 }

-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)
+static int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
 {
int ret;

@@ -463,11 +500,98 @@ error:
return ret;
 }

-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)
+static int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
 {
+   int ret;
+
+   DBG("Set clk rates: pclk=%d, byteclk=%d, esc_clk=%d, dsi_src_clk=%d",
+   msm_host->mode->clock, msm_host->byte_clk_rate,
+   msm_host->esc_clk_rate, msm_host->src_clk_rate);
+
+   ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
+   if (ret) {
+   pr_err("%s: Failed to set rate byte clk, %d\n", __func__, ret);
+   goto error;
+   }
+
+   ret = clk_set_rate(msm_host->esc_clk, msm_host->esc_clk_rate);
+   if (ret) {
+   pr_err("%s: Failed to set rate esc clk, %d\n", __func__, ret);
+   goto error;
+   }
+
+   ret = clk_set_rate(msm_host->src_clk, msm_host->src_clk_rate);
+   if (ret) {
+

[PATCH 06/12] drm/msm/dsi: Parse bus clocks from a list

2015-10-14 Thread Archit Taneja

DSI bus clocks seem to vary between different DSI host versions, and the
SOC to which they belong. Even the enable/disable sequence varies.

Provide a list of bus clock names in dsi_cfg. The driver will use this to
retrieve the clocks, and enable/disable them.

Add bus clock lists for DSI6G, and DSI for MSM8916(this is DSI6G too, but
there is no MMSS_CC specific clock since there is no MMSS clock controller
on 8916).

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.h  |   1 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  16 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |   2 +
 drivers/gpu/drm/msm/dsi/dsi_host.c | 107 -
 4 files changed, 53 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 8140e8b..7336b55 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -36,6 +36,7 @@ enum msm_dsi_phy_type {
 };

 #define DSI_DEV_REGULATOR_MAX  8
+#define DSI_BUS_CLK_MAX4

 /* Regulators for DSI devices */
 struct dsi_reg_entry {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 5872d5e..c40044f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -18,6 +18,10 @@ static const struct msm_dsi_config dsi_v2_cfg = {
.io_offset = 0,
 };

+static const char * const dsi_6g_bus_clk_names[] = {
+   "mdp_core_clk", "iface_clk", "bus_clk", "core_mmss_clk",
+};
+
 static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
@@ -29,6 +33,12 @@ static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = 
{
{"vddio", 180, 180, 10, 100},
},
},
+   .bus_clk_names = dsi_6g_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_6g_bus_clk_names),
+};
+
+static const char * const dsi_8916_bus_clk_names[] = {
+   "mdp_core_clk", "iface_clk", "bus_clk",
 };

 static const struct msm_dsi_config msm8916_dsi_cfg = {
@@ -42,6 +52,8 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
{"vddio", 180, 180, 10, 100},
},
},
+   .bus_clk_names = dsi_8916_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_8916_bus_clk_names),
 };

 static const struct msm_dsi_config msm8994_dsi_cfg = {
@@ -57,7 +69,9 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
{"lab_reg", -1, -1, -1, -1},
{"ibb_reg", -1, -1, -1, -1},
},
-   }
+   },
+   .bus_clk_names = dsi_6g_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_6g_bus_clk_names),
 };

 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 4cf8872..5a36836 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -30,6 +30,8 @@
 struct msm_dsi_config {
u32 io_offset;
struct dsi_reg_config reg_cfg;
+   const char * const *bus_clk_names;
+   const int num_bus_clks;
 };

 struct msm_dsi_cfg_handler {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 12ac3bc3..008726f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -103,10 +103,9 @@ struct msm_dsi_host {

void __iomem *ctrl_base;
struct regulator_bulk_data supplies[DSI_DEV_REGULATOR_MAX];
-   struct clk *mdp_core_clk;
-   struct clk *ahb_clk;
-   struct clk *axi_clk;
-   struct clk *mmss_misc_ahb_clk;
+
+   struct clk *bus_clks[DSI_BUS_CLK_MAX];
+
struct clk *byte_clk;
struct clk *esc_clk;
struct clk *pixel_clk;
@@ -319,40 +318,22 @@ static int dsi_regulator_init(struct msm_dsi_host 
*msm_host)
 static int dsi_clk_init(struct msm_dsi_host *msm_host)
 {
struct device *dev = _host->pdev->dev;
-   int ret = 0;
-
-   msm_host->mdp_core_clk = devm_clk_get(dev, "mdp_core_clk");
-   if (IS_ERR(msm_host->mdp_core_clk)) {
-   ret = PTR_ERR(msm_host->mdp_core_clk);
-   pr_err("%s: Unable to get mdp core clk. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->ahb_clk = devm_clk_get(dev, "iface_clk");
-   if (IS_ERR(msm_host->ahb_clk)) {
-   ret = PTR_ERR(msm_host->ahb_clk);
-   pr_err("%s: Unable to get mdss ahb clk. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->axi_clk = devm_clk_get(dev, "bus_clk");
-   if (IS_ERR(msm_host->axi_clk)) {
-   ret = PTR_ERR(msm_host->axi_clk);
-   pr_err("%s: Unable to get axi bus clk. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->mmss_misc_ahb_clk =

[PATCH 05/12] drm/msm/dsi: Delay dsi_clk_init

2015-10-14 Thread Archit Taneja

Initialize clocks only after we get the DSI host version. This will allow
us to get clocks using a pre-defined list based on the DSI major/minor
version of the host. This is required since clock requirements of
different major DSI revisions(v2 vs 6g) aren't the same.

Modify dsi_get_version to get the interface clock, and then put it after
it is used.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index f26e8be..12ac3bc3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -177,21 +177,31 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
struct msm_dsi_host *msm_host)
 {
const struct msm_dsi_cfg_handler *cfg_hnd = NULL;
+   struct device *dev = _host->pdev->dev;
struct regulator *gdsc_reg;
+   struct clk *ahb_clk;
int ret;
u32 major = 0, minor = 0;

-   gdsc_reg = regulator_get(_host->pdev->dev, "gdsc");
+   gdsc_reg = regulator_get(dev, "gdsc");
if (IS_ERR(gdsc_reg)) {
pr_err("%s: cannot get gdsc\n", __func__);
goto exit;
}
+
+   ahb_clk = clk_get(dev, "iface_clk");
+   if (IS_ERR(ahb_clk)) {
+   pr_err("%s: cannot get interface clock\n", __func__);
+   goto put_gdsc;
+   }
+
ret = regulator_enable(gdsc_reg);
if (ret) {
pr_err("%s: unable to enable gdsc\n", __func__);
-   goto put_gdsc;
+   goto put_clk;
}
-   ret = clk_prepare_enable(msm_host->ahb_clk);
+
+   ret = clk_prepare_enable(ahb_clk);
if (ret) {
pr_err("%s: unable to enable ahb_clk\n", __func__);
goto disable_gdsc;
@@ -208,9 +218,11 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
DBG("%s: Version %x:%x\n", __func__, major, minor);

 disable_clks:
-   clk_disable_unprepare(msm_host->ahb_clk);
+   clk_disable_unprepare(ahb_clk);
 disable_gdsc:
regulator_disable(gdsc_reg);
+put_clk:
+   clk_put(ahb_clk);
 put_gdsc:
regulator_put(gdsc_reg);
 exit:
@@ -1420,12 +1432,6 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}

-   ret = dsi_clk_init(msm_host);
-   if (ret) {
-   pr_err("%s: unable to initialize dsi clks\n", __func__);
-   goto fail;
-   }
-
msm_host->ctrl_base = msm_ioremap(pdev, "dsi_ctrl", "DSI CTRL");
if (IS_ERR(msm_host->ctrl_base)) {
pr_err("%s: unable to map Dsi ctrl base\n", __func__);
@@ -1449,6 +1455,12 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}

+   ret = dsi_clk_init(msm_host);
+   if (ret) {
+   pr_err("%s: unable to initialize dsi clks\n", __func__);
+   goto fail;
+   }
+
msm_host->rx_buf = devm_kzalloc(>dev, SZ_4K, GFP_KERNEL);
if (!msm_host->rx_buf) {
pr_err("%s: alloc rx temp buf failed\n", __func__);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 04/12] drm/msm/dsi: Use a better way to figure out DSI version

2015-10-14 Thread Archit Taneja

The current version checking mechanism works fine for DSI6G blocks. It
doesn't work so well for older generation DSIv2 blocks.

The initial read of REG_DSI_6G_HW_VERSION(offset 0x0) would result in a
read of REG_DSI_CTRL for DSIv2. This register won't necessarily be 0 on
DSIv2. It can be non zero if DSI was previously initialized by the
bootloader.

Instead of reading offset 0x0, we now read offset 0x1f0. For DSIv2, this
register is DSI_VERSION, and is bound to be non-zero. On DSI6G, this
register(offset 0x1f0) is SCRATCH_REGISTER_0, which no one ever seems to
touch, and from all register dumps I'vc seen, holds 0 all the time.

Modify dsi_get_version to read REG_DSI_VERSION to determine whether we
are DSI6G or DSIv2.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 8d82973f..f26e8be 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -33,17 +33,24 @@
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
-   u32 ver_6g;

if (!major || !minor)
return -EINVAL;

-   /* From DSI6G(v3), addition of a 6G_HW_VERSION register at offset 0
+   /*
+* From DSI6G(v3), addition of a 6G_HW_VERSION register at offset 0
 * makes all other registers 4-byte shifted down.
+*
+* In order to identify between DSI6G(v3) and beyond, and DSIv2 and
+* older, we read the DSI_VERSION register without any shift(offset
+* 0x1f0). In the case of DSIv2, this hast to be a non-zero value. In
+* the case of DSI6G, this has to be zero (the offset points to a
+* scratch register which we never touch)
 */
-   ver_6g = msm_readl(base + REG_DSI_6G_HW_VERSION);
-   if (ver_6g == 0) {
-   ver = msm_readl(base + REG_DSI_VERSION);
+
+   ver = msm_readl(base + REG_DSI_VERSION);
+   if (ver) {
+   /* older dsi host, there is no register shift */
ver = FIELD(ver, DSI_VERSION_MAJOR);
if (ver <= MSM_DSI_VER_MAJOR_V2) {
/* old versions */
@@ -54,12 +61,17 @@ static int dsi_get_version(const void __iomem *base, u32 
*major, u32 *minor)
return -EINVAL;
}
} else {
+   /*
+* newer host, offset 0 has 6G_HW_VERSION, the rest of the
+* registers are shifted down, read DSI_VERSION again with
+* the shifted offset
+*/
ver = msm_readl(base + DSI_6G_REG_SHIFT + REG_DSI_VERSION);
ver = FIELD(ver, DSI_VERSION_MAJOR);
if (ver == MSM_DSI_VER_MAJOR_6G) {
/* 6G version */
*major = ver;
-   *minor = ver_6g;
+   *minor = msm_readl(base + REG_DSI_6G_HW_VERSION);
return 0;
} else {
return -EINVAL;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 03/12] drm/msm/dsi: Add DSI PLL for 28nm 8960 PHY

2015-10-14 Thread Archit Taneja

Add DSI PLL common clock framework clocks for 8960 PHY.

The PLL here is different from the ones found in B family msm chips. As
before, the DSI provides two clocks to the outside world. dsixpll and
dsixpllbyte (x = 1, 2). dsixpll is a regular clock divider, but
dsixpllbyte is modelled as a custom clock divider.

dsixpllbyte is the starting point of the PLL configuration. It is the
one that sets up the VCO clock rate. We need the VCO clock rate in the
form: F * byteclk, where F is a multiplication factor that varies on
the byte clock the DSI driver is trying to set. We use the custom
clk_ops for dsixpllbyte to ensure that the parent (VCO) is set at this
rate.

An additional divider (POSTDIV1) generates the bitclk. Since bit clock
can be derived from byteclock, we calculate it internally, and don't
expose it as a clock.

Cc: Stephen Boyd 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c   |   3 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h   |  10 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 529 
 4 files changed, 543 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 96bcb66..93cc042 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -67,6 +67,7 @@ msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += 
dsi/phy/dsi_phy_28nm_8960.o
 ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
 msm-y += dsi/pll/dsi_pll.o
 msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/pll/dsi_pll_28nm.o
+msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/pll/dsi_pll_28nm_8960.o
 endif

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
index 5104fc9..5cd438f 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
@@ -151,6 +151,9 @@ struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device 
*pdev,
case MSM_DSI_PHY_28NM_LP:
pll = msm_dsi_pll_28nm_init(pdev, type, id);
break;
+   case MSM_DSI_PHY_28NM_8960:
+   pll = msm_dsi_pll_28nm_8960_init(pdev, id);
+   break;
default:
pll = ERR_PTR(-ENXIO);
break;
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
index 063caa2..80b6038 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
@@ -93,6 +93,16 @@ static inline struct msm_dsi_pll *msm_dsi_pll_28nm_init(
return ERR_PTR(-ENODEV);
 }
 #endif
+#ifdef CONFIG_DRM_MSM_DSI_28NM_8960_PHY
+struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device *pdev,
+  int id);
+#else
+struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device *pdev,
+  int id)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif

 #endif /* __DSI_PLL_H__ */

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
new file mode 100644
index 000..e71b4ee
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
@@ -0,0 +1,529 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+#include "dsi_pll.h"
+#include "dsi.xml.h"
+
+/*
+ * DSI PLL 28nm (8960/A family) - clock diagram (eg: DSI1):
+ *
+ *
+ *+--+
+ *  dsi1vco_clk o-| DIV1 |---dsi1pllbit (not exposed as clock)
+ *  F * byte_clk| +--+
+ *  | bit clock divider (F / 8)
+ *  |
+ *  | +--+
+ *  o-| DIV2 |---dsi0pllbyte---o---> To byte RCG
+ *  | +--+ | (sets parent rate)
+ *  | byte clock divider (F)   |
+ *  |  |
+ *  |  o---> To esc RCG
+ *  |(doesn't set parent rate)
+ *  |
+ *  | +--+
+ *  o-| DIV3 |dsi0pll--o---> To dsi RCG
+ *+--+ | (sets parent rate)
+ *  dsi clock divider (F * magic)  |
+ * |
+ *

[PATCH 02/12] drm/msm/dsi: Add support for 28nm PHY on 8960

2015-10-14 Thread Archit Taneja

DSI PHY on MSM8960 and APQ8064 is a 28nm PHY that's different from the
supported 28nm LP PHY found in newer chips.

Add support for the new PHY.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/Kconfig |   8 +
 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/dsi/dsi.h   |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c   |   4 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h   |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 195 
 6 files changed, 210 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 8e6c7c6..38a618e 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -68,3 +68,11 @@ config DRM_MSM_DSI_20NM_PHY
default y
help
  Choose this option if the 20nm DSI PHY is used on the platform.
+
+config DRM_MSM_DSI_28NM_8960_PHY
+   bool "Enable DSI 28nm 8960 PHY driver in MSM DRM"
+   depends on DRM_MSM_DSI
+   default y
+   help
+ Choose this option if the 28nm DSI PHY 8960 variant is used on the
+ platform.
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 0a543eb..96bcb66 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -62,6 +62,7 @@ msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \

 msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/phy/dsi_phy_28nm.o
 msm-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += dsi/phy/dsi_phy_20nm.o
+msm-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += dsi/phy/dsi_phy_28nm_8960.o

 ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
 msm-y += dsi/pll/dsi_pll.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 5f5a373..8140e8b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -31,6 +31,7 @@ enum msm_dsi_phy_type {
MSM_DSI_PHY_28NM_HPM,
MSM_DSI_PHY_28NM_LP,
MSM_DSI_PHY_20NM,
+   MSM_DSI_PHY_28NM_8960,
MSM_DSI_PHY_MAX
 };

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 401ff58..d54e450 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -277,6 +277,10 @@ static const struct of_device_id dsi_phy_dt_match[] = {
{ .compatible = "qcom,dsi-phy-20nm",
  .data = _phy_20nm_cfgs },
 #endif
+#ifdef CONFIG_DRM_MSM_DSI_28NM_8960_PHY
+   { .compatible = "qcom,dsi-phy-28nm-8960",
+ .data = _phy_28nm_8960_cfgs },
+#endif
{}
 };

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 0456b25..0d54ed0 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -43,6 +43,7 @@ struct msm_dsi_phy_cfg {
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
 extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;

 struct msm_dsi_dphy_timing {
u32 clk_pre;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
new file mode 100644
index 000..197b039
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi_phy.h"
+#include "dsi.xml.h"
+
+static void dsi_28nm_dphy_set_timing(struct msm_dsi_phy *phy,
+   struct msm_dsi_dphy_timing *timing)
+{
+   void __iomem *base = phy->base;
+
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_0,
+   DSI_28nm_8960_PHY_TIMING_CTRL_0_CLK_ZERO(timing->clk_zero));
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_1,
+   DSI_28nm_8960_PHY_TIMING_CTRL_1_CLK_TRAIL(timing->clk_trail));
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_2,
+   
DSI_28nm_8960_PHY_TIMING_CTRL_2_CLK_PREPARE(timing->clk_prepare));
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_3, 0x0);
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_4,
+   DSI_28nm_8960_PHY_TIMING_CTRL_4_HS_EXIT(timing->hs_exit));
+   dsi_phy_write(base + REG_DSI_28nm_8960_PHY_TIMING_CTRL_5,
+   DSI_28nm_8960_PHY_TIMING_CTRL_5_HS_ZERO(timing->hs_zero));
+   dsi_phy_write(base +

[PATCH 01/12] drm/msm/dsi: Update generated header for 8960

2015-10-14 Thread Archit Taneja

The DSI PLL and PHY registers are already there for 8960, but their
offsets are relative to the top level DSI controller base.

Make the offsets relative to the individual sub blocks. Add "28nm" in
the register names while we're at it.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 243 +++---
 1 file changed, 177 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 1d2e32f..3d6297f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -8,17 +8,8 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2576 bytes, from 2015-07-09 22:10:24)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
36021 bytes, from 2015-07-09 22:10:24)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
26057 bytes, from 2015-08-14 21:47:57)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
29154 bytes, from 2015-08-10 21:25:43)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2015-05-20 20:03:14)
+- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/dsi/dsi.xml(  
27887 bytes, from 2015-09-02 06:17:10)
+- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml (  
 1453 bytes, from 2015-02-09 03:18:10)

 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
@@ -567,114 +558,234 @@ static inline uint32_t DSI_VERSION_MAJOR(uint32_t val)
 #define REG_DSI_8x60_PHY_CAL_STATUS0x00fc
 #define DSI_8x60_PHY_CAL_STATUS_CAL_BUSY   0x1000

-static inline uint32_t REG_DSI_8960_LN(uint32_t i0) { return 0x0300 + 
0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN(uint32_t i0) { return 
0x + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_CFG_0(uint32_t i0) { return 0x0300 
+ 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_CFG_0(uint32_t i0) { return 
0x + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_CFG_1(uint32_t i0) { return 0x0304 
+ 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_CFG_1(uint32_t i0) { return 
0x0004 + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_CFG_2(uint32_t i0) { return 0x0308 
+ 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_CFG_2(uint32_t i0) { return 
0x0008 + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_TEST_DATAPATH(uint32_t i0) { return 
0x030c + 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_TEST_DATAPATH(uint32_t i0) { 
return 0x000c + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_TEST_STR_0(uint32_t i0) { return 
0x0314 + 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_TEST_STR_0(uint32_t i0) { 
return 0x0014 + 0x40*i0; }

-static inline uint32_t REG_DSI_8960_LN_TEST_STR_1(uint32_t i0) { return 
0x0318 + 0x40*i0; }
+static inline uint32_t REG_DSI_28nm_8960_PHY_LN_TEST_STR_1(uint32_t i0) { 
return 0x0018 + 0x40*i0; }

-#define REG_DSI_8960_PHY_LNCK_CFG_00x0400
+#define REG_DSI_28nm_8960_PHY_LNCK_CFG_0   0x0100

-#define REG_DSI_8960_PHY_LNCK_CFG_10x0404
+#define REG_DSI_28nm_8960_PHY_LNCK_CFG_1   0x0104

-#define REG_DSI_8960_PHY_LNCK_CFG_20x0408
+#define REG_DSI_28nm_8960_PHY_LNCK_CFG_2   0x0108

-#define REG_DSI_8960_PHY_LNCK_TEST_DATAPATH0x040c
+#define REG_DSI_28nm_8960_PHY_LNCK_TEST_DATAPATH   0x010c

-#define REG_DSI_8960_PHY_LNCK_TEST_STR0
0x0414
+#define REG_DSI_28nm_8960_PHY_LNCK_TEST_STR0   0x0114

-#define REG_DSI_8960_PHY_LNCK_TEST_STR1
0x0418
+#define REG_DSI_28nm_8960_PHY_LNCK_TEST_STR1   0x0118

-#define REG_DSI_8960_PHY_TIMING_CTRL_0 0x0440
+#define

[PATCH 00/12] drm/msm/dsi: Add support for DSI on MSM8960/APQ8064

2015-10-14 Thread Archit Taneja

Add support for DSI on 8960/8064. The DSI IP used in these chips is an
older version(DSIv2) of what we have right now(DSI6G).

The bulk of the additions come thanks to a different PHY/PLL. The DSI
host in itself doesn't have too many changes.

Archit Taneja (12):
  drm/msm/dsi: Update generated header for 8960
  drm/msm/dsi: Add support for 28nm PHY on 8960
  drm/msm/dsi: Add DSI PLL for 28nm 8960 PHY
  drm/msm/dsi: Use a better way to figure out DSI version
  drm/msm/dsi: Delay dsi_clk_init
  drm/msm/dsi: Parse bus clocks from a list
  drm/msm/dsi: Set up link clocks for DSIv2
  drm/msm/dsi: Add dsi_cfg for APQ8064
  drm/msm/dsi: Don't use iommu for command TX buffer for DSIv2
  drm/msm/dsi: SFPB: Update generated headers
  drm/msm/dsi: Enable MMSS SPFB port via syscon
  dt-bindings: Add DSIv2 documentation

 Documentation/devicetree/bindings/drm/msm/dsi.txt |  10 +-
 drivers/gpu/drm/msm/Kconfig   |   8 +
 drivers/gpu/drm/msm/Makefile  |   2 +
 drivers/gpu/drm/msm/dsi/dsi.h |   6 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 243 +++---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c |  35 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |   4 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 497 ++--
 drivers/gpu/drm/msm/dsi/dsi_manager.c |   6 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |   4 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c   | 195 
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c |   3 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h |  10 +
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c   | 529 ++
 drivers/gpu/drm/msm/dsi/sfpb.xml.h|  26 +-
 16 files changed, 1363 insertions(+), 216 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
 create mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH RFC 5/5] gpu/doc: Convert to markdown harder

2015-10-14 Thread Lukas Wunner

Hi,

On Wed, Oct 14, 2015 at 11:04:37AM -0300, Danilo Cesar Lemes de Paula wrote:
> On 10/14/2015 10:59 AM, Daniel Vetter wrote:
> > On Mon, Oct 12, 2015 at 09:10:33AM +0200, Lukas Wunner wrote:
> >> This snippet...
> >>
> >> * Lock VMA manager for extended lookups. Only *_locked() VMA function 
> >> calls
> >> * are allowed while holding this lock. All other contexts are blocked 
> >> from VMA
> >> * until the lock is released via drm_vma_offset_unlock_lookup().
> >>
> >> ...causes markdown-enabled kernel-doc to barf:
> >>
> >> debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser 
> >> error : Opening and ending tag mismatch: emphasis line 3247 and function
> >>*locked VMA function calls are 
> >> allowed while
> >>  ^
> >> 
> >> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249:
> >>  parser error : Opening and ending tag mismatch: function line 3249 and 
> >> emphasis
> >>released via 
> >> drmvma_offset_unlock_lookup.
> >> ^
> >> unable to parse 
> >> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml
> >>
> >> A quick workaround is to replace *_locked() by X_locked().
> >>
> >> Cc: Danilo Cesar Lemes de Paula 
> >> Signed-off-by: Lukas Wunner 
> >> ---
> >>  include/drm/drm_vma_manager.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> >> index 2ca44db..c1e41b8 100644
> >> --- a/include/drm/drm_vma_manager.h
> >> +++ b/include/drm/drm_vma_manager.h
> >> @@ -97,7 +97,7 @@ drm_vma_offset_exact_lookup(struct 
> >> drm_vma_offset_manager *mgr,
> >>   * drm_vma_offset_lock_lookup() - Lock lookup for extended private use
> >>   * @mgr: Manager object
> >>   *
> >> - * Lock VMA manager for extended lookups. Only *_locked() VMA function 
> >> calls
> >> + * Lock VMA manager for extended lookups. Only X_locked() VMA function 
> >> calls
> > 
> > I went with a plain _unlocked since the X_unlocked looked a bit strange.
> > Anyway Dave acked the rename idea on irc, so all applied. Well except
> > patch 1, there wasn't any conflict when I pushed this to drm-misc.
> > -Daniel
> 
> I didn't test it (not a big fan of doing this), but \* or \_ should
> escape the sequence. Did you consider that?

I did test \* and it didn't help.
I can't remember if I also tested \_.

In any case the issue is not the asterisk but rather that the
underscore in *_locked() is interpreted as the beginning of an
_emphasis_. It seems any underscore at the beginning of a word is
interpreted like that. The question is why the leading asterisk is
not interpreted as the actual beginning of the word. Replacing the
asterisk with an alphabetic character solved it.

Best regards,

Lukas

[GIT PULL] TDA998x I2C driver development updates

2015-10-14 Thread Russell King

David,

Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:

  git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-devel

with SHA1 9525c4dd923f8ffe38818f86cee523a5f7b19617.

This series:

* removes the now unused DRM slave encoder support, which all users have
  migrated away from, allowing us to simplify the code.
* ensure all pending interrupts are processed together, rather than
  needing the handler to be re-entered each time.
* use more HDMI helpers to setup the info frames.
* fix EDID read handling by ensuring that we always wait the specified time
  before attempting to read the EDID, no matter where the EDID read request
  came from.

This will update the following files:

 drivers/gpu/drm/i2c/tda998x_drv.c | 487 +++---
 1 file changed, 185 insertions(+), 302 deletions(-)

through these changes:

Russell King (11):
  drm/i2c: tda998x: remove useless NULL checks
  drm/i2c: tda998x: report whether we actually handled the IRQ
  drm/i2c: tda998x: re-implement "Fix EDID read timeout on HDMI connect"
  drm/i2c: tda998x: convert to u8/u16/u32 types
  drm/i2c: tda998x: handle all outstanding interrupts
  drm/i2c: tda998x: use more HDMI helpers
  drm/i2c: tda998x: remove DRM slave encoder support
  drm/i2c: tda998x: remove encoder pointer
  drm/i2c: tda998x: move connector into struct tda998x_priv
  drm/i2c: tda998x: kill struct tda998x_priv2
  drm/i2c: tda998x: clean up after struct tda998x_priv2 removal

Many thanks.

[GIT PULL] Armada DRM development updates development updates

2015-10-14 Thread Russell King

David,

Please incorporate the latest Armada DRM development updates development
updates, which can be found at:

  git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel

with SHA1 7cb410cdbdc9b71e2d4f356f2e4cea0b925abb21.

These changes:

* remove support for the non-component support from the Armada DRM driver,
  switching it to component-only mode.
* create a "armada plane" to allow the primary and overlay planes to share
  some code.
* increase efficiency by using inherently atomic operations, rather than
  spinlocking to achieve atomicity.  Eg, if we want to exchange a value,
  using xchg().
* increase PM savings by stopping the external pixel clock when we're in
  DPMS mode.

Please merge this for the 4.4 merge window.  Thanks.

This will update the following files:

 drivers/gpu/drm/armada/Kconfig  |   9 --
 drivers/gpu/drm/armada/Makefile |   3 +-
 drivers/gpu/drm/armada/armada_crtc.c| 258 +++-
 drivers/gpu/drm/armada/armada_crtc.h|  34 +++--
 drivers/gpu/drm/armada/armada_drm.h |  16 --
 drivers/gpu/drm/armada/armada_drv.c | 148 +++---
 drivers/gpu/drm/armada/armada_output.c  | 142 --
 drivers/gpu/drm/armada/armada_output.h  |  33 
 drivers/gpu/drm/armada/armada_overlay.c | 147 +-
 drivers/gpu/drm/armada/armada_slave.c   | 139 -
 drivers/gpu/drm/armada/armada_slave.h   |  26 
 11 files changed, 297 insertions(+), 658 deletions(-)
 delete mode 100644 drivers/gpu/drm/armada/armada_output.c
 delete mode 100644 drivers/gpu/drm/armada/armada_output.h
 delete mode 100644 drivers/gpu/drm/armada/armada_slave.c
 delete mode 100644 drivers/gpu/drm/armada/armada_slave.h

through these changes:

Russell King (20):
  drm/armada: remove non-component support
  drm/armada: move vbl code into armada_crtc
  drm/armada: use drm_plane_force_disable() to disable the overlay plane
  drm/armada: disable CRTC clock during DPMS
  drm/armada: redo locking and atomics for 
armada_drm_crtc_complete_frame_work()
  drm/armada: rename overlay identifiers
  drm/armada: factor out retirement of old fb
  drm/armada: use xchg() to atomically update dplane->old_fb
  drm/armada: update armada overlay to use drm_universal_plane_init()
  drm/armada: introduce generic armada_plane struct
  drm/armada: add primary plane creation
  drm/armada: allocate primary plane ourselves
  drm/armada: provide a common helper to disable a plane
  drm/armada: move write to dma_ctrl0 to armada_drm_crtc_plane_disable()
  drm/armada: move the update of dplane->ctrl0 out of spinlock
  drm/armada: move the locking for armada_drm_vbl_event_remove()
  drm/armada: move frame wait into armada_frame
  drm/armada: move CRTC flip work to primary plane work
  drm/armada: convert overlay plane vbl worker to a armada plane worker
  drm/armada: move frame wait wakeup into plane work

Many thanks.

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Laurent Vivier



Le 14/10/2015 16:52, Ilia Mirkin a Ã©crit :
> On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering  wrote:
>> On Sun, Oct 11, Laurent Vivier wrote:
>>
>>> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp()
>>> returns NULL. But in fact the OpenFirmware has given us the size
>>> we can store in image->size.
>>
>>> CC: imirkin at alum.mit.edu
>>> Signed-off-by: Laurent Vivier 
>>
>> Tested-by: Olaf Hering 
>>
>> Broken since a while already...
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126737.html
> 
> FTR, looks like my version is upstream now:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0
> 
> I agree that my of_size thing was a bit of a hack, if you want to redo
> it by removing of_size/of_read from shadowof.c and copying it in at
> init time (also a hack, IMHO), I certainly wouldn't object. As before,
> it's Ben's call though.

It's nice to have a fix upstream.

I'll send a patch to remove the of_size.

Rereading your patch and mine, I think we don't need no_pcir, we can do
instead:

if (!nvbios_rd16(bios, base + 0x18)) {
/* no PCIr */
image.base = 0;
image.type = 0;
image.size = bios->size;
image.last = 1;
} else {
if (!shadow_fetch(bios, mthd, offset + 0x1000)) {

...
What is you opinion ?

Laurent

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Olaf Hering

On Wed, Oct 14, Ilia Mirkin wrote:

> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0

Thanks.
Almost perfect, lacks a stable tag.

Olaf

[pull] amdgpu and radeon drm-next-4.4

2015-10-14 Thread Alex Deucher

Hi Dave,

This is the first radeon and amdgpu pull for drm-next. Highlights include:
- Efficiency improvements to the CS checker for pre-SI asics
- Cursor fixes ported from radeon to amdgpu
- Enable GPU scheduler by default
- Add a bunch of GPUVM debugging options
- Add support for some new atombios opcodes
- Misc cleanups and fixes

The following changes since commit d4070ff71363a2b6598633f23558f809600ebad2:

  Merge tag 'drm-intel-next-2015-09-11' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-10-02 15:41:17 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-next-4.4

for you to fetch changes up to 2fcef6ec87a044221fc3c2f16873f7c02b9ae991:

  drm/amdgpu: fix lockup when clean pending fences (2015-10-14 16:20:32 -0400)


Alex Deucher (24):
  drm/amdgpu: split gfx8 gpu init into sw and hw parts
  drm/amdgpu: disable hw semaphores by default
  drm/amdgpu/atom: implement debug opcode
  drm/amdgpu/atom: add support for process ds opcode
  drm/amdgpu/atom: add support for new mul32 opcodes (v2)
  drm/amdgpu/atom: add support for new div32 opcodes (v3)
  drm/amdgpu/dce10: Use cursor_set2 hook for enabling / disabling the HW 
cursor
  drm/amdgpu/dce10: Re-show the cursor after a modeset (v2)
  drm/amdgpu/dce10: Move hotspot handling out of set_cursor
  drm/amdgpu/dce10: Clean up reference counting and pinning of the cursor 
BOs
  drm/amdgpu/dce10: Fold set_cursor() into show_cursor()
  drm/amdgpu/dce11: Use cursor_set2 hook for enabling / disabling the HW 
cursor
  drm/amdgpu/dce11: Re-show the cursor after a modeset (v2)
  drm/amdgpu/dce11: Move hotspot handling out of set_cursor
  drm/amdgpu/dce11: Clean up reference counting and pinning of the cursor 
BOs
  drm/amdgpu/dce11: Fold set_cursor() into show_cursor()
  drm/amdgpu/dce8: Use cursor_set2 hook for enabling / disabling the HW 
cursor
  drm/amdgpu/dce8: Re-show the cursor after a modeset (v2)
  drm/amdgpu/dce8: Move hotspot handling out of set_cursor
  drm/amdgpu/dce8: Clean up reference counting and pinning of the cursor BOs
  drm/amdgpu/dce8: Fold set_cursor() into show_cursor()
  drm/amdgpu: unpin cursor BOs on suspend and pin them again on resume
  drm/amdgpu: rework sdma structures
  drm/amdgpu: clean up pageflip interrupt handling

Christian KÃ¶nig (5):
  drm/amdgpu: also trace already allocated VMIDs
  drm/amdgpu: only print meaningful VM faults
  drm/amdgpu: add option to stop on VM fault
  drm/amdgpu: add option to clear VM page tables after every submit
  drm/amdgpu: add VM CS mapping trace point

Chunming Zhou (3):
  drm/amdgpu: add vram usage into debugfs
  drm/amdgpu: add TOPDOWN flag to the whole vram
  drm/amdgpu: enable scheduler by default

Grazvydas Ignotas (4):
  drm/radeon: simplify register checker
  drm/radeon: split evergreen_cs_check_reg
  drm/radeon: refactor register check loop
  drm/radeon: remove volatile qualifier

Junwei Zhang (2):
  drm/amdgpu: add timer to fence to detect scheduler lockup
  drm/amdgpu: fix lockup when clean pending fences

Lukas Wunner (4):
  drm/radeon: Spell vga_switcheroo consistently
  drm/amdgpu: Spell vga_switcheroo consistently
  drm/radeon: Drop unnecessary #include 
  drm/amdgpu: Drop unnecessary #include 

 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  29 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c  |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  24 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  33 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  12 +-
 drivers/gpu/drm/amd/amdgpu/atom.c |  53 ++-
 drivers/gpu/drm/amd/amdgpu/atom.h |   2 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 130 
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 190 +--
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 190 +--
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 190 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 387 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c

[PATCH] drm/gem: consolidate handle deletion code.

2015-10-14 Thread Dave Airlie

From: Dave Airlie 

This code was duplicated, make it decidely
less duplicated.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_gem.c | 35 +--
 1 file changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 3c2d4ab..12d0dc7 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -239,6 +239,21 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }

+static void
+drm_gem_handle_delete_tail(struct drm_file *filp,
+  struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj->dev;
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, filp);
+   drm_vma_node_revoke(>vma_node, filp->filp);
+
+   if (dev->driver->gem_close_object)
+   dev->driver->gem_close_object(obj, filp);
+   drm_gem_object_handle_unreference_unlocked(obj);
+}
+
 /**
  * drm_gem_handle_delete - deletes the given file-private handle
  * @filp: drm file-private structure to use for the handle look up
@@ -276,14 +291,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);

-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_gem_remove_prime_handles(obj, filp);
-   drm_vma_node_revoke(>vma_node, filp->filp);
-
-   if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, filp);
-   drm_gem_object_handle_unreference_unlocked(obj);
-
+   drm_gem_handle_delete_tail(filp, obj);
return 0;
 }
 EXPORT_SYMBOL(drm_gem_handle_delete);
@@ -708,17 +716,8 @@ drm_gem_object_release_handle(int id, void *ptr, void 
*data)
 {
struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
-   struct drm_device *dev = obj->dev;
-
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_gem_remove_prime_handles(obj, file_priv);
-   drm_vma_node_revoke(>vma_node, file_priv->filp);
-
-   if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, file_priv);
-
-   drm_gem_object_handle_unreference_unlocked(obj);

+   drm_gem_handle_delete_tail(file_priv, obj);
return 0;
 }

-- 
2.5.0

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Olaf Hering

On Sun, Oct 11, Laurent Vivier wrote:

> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp()
> returns NULL. But in fact the OpenFirmware has given us the size
> we can store in image->size.

> CC: imirkin at alum.mit.edu
> Signed-off-by: Laurent Vivier 

Tested-by: Olaf Hering 

Broken since a while already...
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126737.html

Olaf

[PATCH] drm/dp/mst: zero out i2c read msg before sending

2015-10-14 Thread Dave Airlie

From: Dave Airlie 

This avoids some of the fields being random garbage.

found this while debugging some other pain.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ac3c273..2e4f8a3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2627,6 +2627,7 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter 
*adapter, struct i2c_msg *msgs
goto out;
}

+   memset(, 0, sizeof(msg));
msg.req_type = DP_REMOTE_I2C_READ;
msg.u.i2c_read.num_transactions = num - 1;
msg.u.i2c_read.port_number = port->port_num;
-- 
2.4.3

[PATCH RFC 5/5] gpu/doc: Convert to markdown harder

2015-10-14 Thread Daniel Vetter

On Mon, Oct 12, 2015 at 09:10:33AM +0200, Lukas Wunner wrote:
> This snippet...
> 
> * Lock VMA manager for extended lookups. Only *_locked() VMA function 
> calls
> * are allowed while holding this lock. All other contexts are blocked 
> from VMA
> * until the lock is released via drm_vma_offset_unlock_lookup().
> 
> ...causes markdown-enabled kernel-doc to barf:
> 
> debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser 
> error : Opening and ending tag mismatch: emphasis line 3247 and function
>*locked VMA function calls are allowed 
> while
>  ^
> 
> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249: 
> parser error : Opening and ending tag mismatch: function line 3249 and 
> emphasis
>released via 
> drmvma_offset_unlock_lookup.
> ^
> unable to parse 
> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml
> 
> A quick workaround is to replace *_locked() by X_locked().
> 
> Cc: Danilo Cesar Lemes de Paula 
> Signed-off-by: Lukas Wunner 
> ---
>  include/drm/drm_vma_manager.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index 2ca44db..c1e41b8 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -97,7 +97,7 @@ drm_vma_offset_exact_lookup(struct drm_vma_offset_manager 
> *mgr,
>   * drm_vma_offset_lock_lookup() - Lock lookup for extended private use
>   * @mgr: Manager object
>   *
> - * Lock VMA manager for extended lookups. Only *_locked() VMA function calls
> + * Lock VMA manager for extended lookups. Only X_locked() VMA function calls

I went with a plain _unlocked since the X_unlocked looked a bit strange.
Anyway Dave acked the rename idea on irc, so all applied. Well except
patch 1, there wasn't any conflict when I pushed this to drm-misc.
-Daniel

>   * are allowed while holding this lock. All other contexts are blocked from 
> VMA
>   * until the lock is released via drm_vma_offset_unlock_lookup().
>   *
> -- 
> 1.8.5.2 (Apple Git-48)
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/amdgpu: Keep the pflip interrupts always enabled v6

2015-10-14 Thread Alex Deucher

From: Michel DÃ¤nzer 

This fixes flickering issues caused by prematurely firing pflip
interrupts.

v2 (chk): add commit message, fix DCE V10/V11 and DM as well
v3: Re-enable pflip interrupt wherever we re-enable a CRTC
v4: Enable pflip interrupt in DAL as well
v5: drop DAL changes for upstream
v6: (agd): only enable interrupts on crtcs that exist

Signed-off-by: Michel DÃ¤nzer 
Signed-off-by: Christian KÃ¶nig 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 30 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 30 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   | 30 +++--
 4 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index e3d7077..dc29ed8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -85,8 +85,6 @@ static void amdgpu_flip_work_func(struct work_struct *__work)
/* We borrow the event spin lock for protecting flip_status */
spin_lock_irqsave(>dev->event_lock, flags);

-   /* set the proper interrupt */
-   amdgpu_irq_get(adev, >pageflip_irq, work->crtc_id);
/* do the flip (mmio) */
adev->mode_info.funcs->page_flip(adev, work->crtc_id, work->base);
/* set the flip status */
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index e4d101b..492e83b 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -255,6 +255,24 @@ static u32 dce_v10_0_vblank_get_counter(struct 
amdgpu_device *adev, int crtc)
return RREG32(mmCRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
 }

+static void dce_v10_0_pageflip_interrupt_init(struct amdgpu_device *adev)
+{
+   unsigned i;
+
+   /* Enable pflip interrupts */
+   for (i = AMDGPU_PAGEFLIP_IRQ_D1; i < adev->mode_info.num_crtc; i++)
+   amdgpu_irq_get(adev, >pageflip_irq, i);
+}
+
+static void dce_v10_0_pageflip_interrupt_fini(struct amdgpu_device *adev)
+{
+   unsigned i;
+
+   /* Disable pflip interrupts */
+   for (i = AMDGPU_PAGEFLIP_IRQ_D1; i < adev->mode_info.num_crtc; i++)
+   amdgpu_irq_put(adev, >pageflip_irq, i);
+}
+
 /**
  * dce_v10_0_page_flip - pageflip callback.
  *
@@ -2663,9 +2681,10 @@ static void dce_v10_0_crtc_dpms(struct drm_crtc *crtc, 
int mode)
dce_v10_0_vga_enable(crtc, true);
amdgpu_atombios_crtc_blank(crtc, ATOM_DISABLE);
dce_v10_0_vga_enable(crtc, false);
-   /* Make sure VBLANK interrupt is still enabled */
+   /* Make sure VBLANK and PFLIP interrupts are still enabled */
type = amdgpu_crtc_idx_to_irq_type(adev, amdgpu_crtc->crtc_id);
amdgpu_irq_update(adev, >crtc_irq, type);
+   amdgpu_irq_update(adev, >pageflip_irq, type);
drm_vblank_post_modeset(dev, amdgpu_crtc->crtc_id);
dce_v10_0_crtc_load_lut(crtc);
break;
@@ -3025,6 +3044,8 @@ static int dce_v10_0_hw_init(void *handle)
dce_v10_0_audio_enable(adev, >mode_info.audio.pin[i], 
false);
}

+   dce_v10_0_pageflip_interrupt_init(adev);
+
return 0;
 }

@@ -3039,6 +3060,8 @@ static int dce_v10_0_hw_fini(void *handle)
dce_v10_0_audio_enable(adev, >mode_info.audio.pin[i], 
false);
}

+   dce_v10_0_pageflip_interrupt_fini(adev);
+
return 0;
 }

@@ -3050,6 +3073,8 @@ static int dce_v10_0_suspend(void *handle)

dce_v10_0_hpd_fini(adev);

+   dce_v10_0_pageflip_interrupt_fini(adev);
+
return 0;
 }

@@ -3075,6 +3100,8 @@ static int dce_v10_0_resume(void *handle)
/* initialize hpd */
dce_v10_0_hpd_init(adev);

+   dce_v10_0_pageflip_interrupt_init(adev);
+
return 0;
 }

@@ -3369,7 +3396,6 @@ static int dce_v10_0_pageflip_irq(struct amdgpu_device 
*adev,
spin_unlock_irqrestore(>ddev->event_lock, flags);

drm_vblank_put(adev->ddev, amdgpu_crtc->crtc_id);
-   amdgpu_irq_put(adev, >pageflip_irq, crtc_id);
queue_work(amdgpu_crtc->pflip_queue, >unpin_work);

return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index fcd2ed5..5727471 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -233,6 +233,24 @@ static u32 dce_v11_0_vblank_get_counter(struct 
amdgpu_device *adev, int crtc)
return RREG32(mmCRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
 }

+static void dce_v11_0_pageflip_interrupt_init(struct amdgpu_device *adev)
+{
+   unsigned i;
+
+   /* Enable pflip interrupts */
+   for (i = AMDGPU_PAGEFLIP_IRQ_D1; i <

[Bug 92086] AMD Trinity No screen at HDMI after S3 wakeup

2015-10-14 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #10 from Alex Deucher  ---
The logs are enough.

-- 
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/20151014/bdab5410/attachment.html>

[Bug 92086] AMD Trinity No screen at HDMI after S3 wakeup

2015-10-14 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from BalÃ¡zs Vinarz  ---
Dear Alex,
i'm having also a video. Should i upload it, or are the dmesg and xorg logs
enough?

-- 
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/20151014/c282b056/attachment.html>

[PATCH 03/12] drm/msm/dsi: Add DSI PLL for 28nm 8960 PHY

2015-10-14 Thread Stephen Boyd

On 10/14, Archit Taneja wrote:
> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c 
> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> new file mode 100644
> index 000..e71b4ee
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c
> @@ -0,0 +1,529 @@
> +/*
> + * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 

Is this include used?

> +#include 
> +
> +#include "dsi_pll.h"
> +#include "dsi.xml.h"
> +
> +/*
[..]
> +
> +#define to_pll_28nm(x)   container_of(x, struct dsi_pll_28nm, base)
> +
> +static bool pll_28nm_poll_for_ready(struct dsi_pll_28nm *pll_28nm,
> + u32 nb_tries, u32 timeout_us)

Why not use unsigned types for these counts? I don't imagine we
care about being precisely 32 bits.

> +{
> + bool pll_locked = false;
> + u32 val;
> +
[..]
> + DBG("id=%d", pll_28nm->id);
> +
> + /*
> +  * before enabling the PLL, configure the bit clock divider since we
> +  * don't expose it as a clock to the outside world
> +  * 1: read back the byte clock divider that should aready be set

s/aready/already/

> +  * 2: divide by 8 to get bit clock divider
> +  * 3: write it to POSTDIV1
> +  */
> + val = pll_read(base + REG_DSI_28nm_8960_PHY_PLL_CTRL_9);
> + byte_div = val + 1;
> + bit_div = byte_div / 8;
> +
> + val = pll_read(base + REG_DSI_28nm_8960_PHY_PLL_CTRL_8);
[..]
> +
> +static void dsi_pll_28nm_destroy(struct msm_dsi_pll *pll)
> +{
> + struct dsi_pll_28nm *pll_28nm = to_pll_28nm(pll);
> + int i;
> +
> + msm_dsi_pll_helper_unregister_clks(pll_28nm->pdev,
> + pll_28nm->clks, pll_28nm->num_clks);
> +
> + for (i = 0; i < NUM_PROVIDED_CLKS; i++)
> + pll_28nm->provided_clks[i] = NULL;
> +
> + pll_28nm->num_clks = 0;
> + pll_28nm->clk_data.clks = NULL;
> + pll_28nm->clk_data.clk_num = 0;

Is all this really necessary?

> +}
> +
> +static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
> +{
> + char clk_name[32], parent[32], vco_name[32];
> + struct clk_init_data vco_init = {
> + .parent_names = (const char *[]){ "pxo" },
> + .num_parents = 1,
> + .name = vco_name,
> + .ops = _ops_dsi_pll_28nm_vco,
> + };
> + struct device *dev = _28nm->pdev->dev;
> + struct clk **clks = pll_28nm->clks;
> + struct clk **provided_clks = pll_28nm->provided_clks;
> + struct clk_bytediv *bytediv;
> + struct clk_init_data bytediv_init;


struct clk_init_data bytediv_init = { };

Just in case we add some new field there?

> + int ret, num = 0;
> +
> + DBG("%d", pll_28nm->id);
> +
> + bytediv = devm_kzalloc(dev, sizeof(*bytediv), GFP_KERNEL);
> + if (!bytediv)
> + return -ENOMEM;
> +
> + pll_28nm->bytediv = bytediv;
> +
> + snprintf(vco_name, 32, "dsi%dvco_clk", pll_28nm->id);
> + pll_28nm->base.clk_hw.init = _init;
> +
> + clks[num++] = clk_register(dev, _28nm->base.clk_hw);
> +
> + /* prepare and register bytediv */
> + bytediv->hw.init = _init;
> + bytediv->reg = pll_28nm->mmio + REG_DSI_28nm_8960_PHY_PLL_CTRL_9;
> +
> + snprintf(parent, 32, "dsi%dvco_clk", pll_28nm->id);
> + snprintf(clk_name, 32, "dsi%dpllbyte", pll_28nm->id);
> +
> + bytediv_init.name = clk_name;
> + bytediv_init.ops = _bytediv_ops;
> + bytediv_init.flags = CLK_SET_RATE_PARENT;
> + bytediv_init.parent_names = (const char *[]) { parent };

Can't we just do  instead of this anonymous array?

> + bytediv_init.num_parents = 1;
> +
> + /* DIV2 */

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/dp/mst: make mst i2c transfer code more robust.

2015-10-14 Thread Daniel Vetter

On Wed, Oct 14, 2015 at 06:51:17PM +1000, Dave Airlie wrote:
> This zeroes the msg so no random stack data ends up getting
> sent, it also limits the function to not accepting > 4
> i2c msgs.
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Dave Airlie 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
>  include/drm/drm_dp_mst_helper.h   | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index bf27a07..5bca390 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2801,12 +2801,13 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter 
> *adapter, struct i2c_msg *msgs
>   if (msgs[num - 1].flags & I2C_M_RD)
>   reading = true;
>  
> - if (!reading) {
> + if (!reading || (num - 1 > DP_REMOTE_I2C_READ_MAX_TRANSACTIONS)) {
>   DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
>   ret = -EIO;
>   goto out;
>   }
>  
> + memset(, 0, sizeof(msg));
>   msg.req_type = DP_REMOTE_I2C_READ;
>   msg.u.i2c_read.num_transactions = num - 1;
>   msg.u.i2c_read.port_number = port->port_num;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 0f408b0..5340099 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -253,6 +253,7 @@ struct drm_dp_remote_dpcd_write {
>   u8 *bytes;
>  };
>  
> +#define DP_REMOTE_I2C_READ_MAX_TRANSACTIONS 4
>  struct drm_dp_remote_i2c_read {
>   u8 num_transactions;
>   u8 port_number;
> @@ -262,7 +263,7 @@ struct drm_dp_remote_i2c_read {
>   u8 *bytes;
>   u8 no_stop_bit;
>   u8 i2c_transaction_delay;
> - } transactions[4];
> + } transactions[DP_REMOTE_I2C_READ_MAX_TRANSACTIONS];
>   u8 read_i2c_device_id;
>   u8 num_bytes_read;
>  };
> -- 
> 2.4.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

2015-10-14 Thread Michel Thierry

On 10/14/2015 8:19 AM, Daniel Vetter wrote:
> On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian HÃ¸gsberg wrote:
>> On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
>>  wrote:
>>> On 10/13/2015 3:13 PM, Emil Velikov wrote:

 On 13 October 2015 at 13:16, Michel Thierry 
 wrote:
>
> On 10/6/2015 2:12 PM, Michel Thierry wrote:
>>
>>
>> On 10/5/2015 7:06 PM, Kristian HÃ¸gsberg wrote:
>>>
>>>
>>> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
>>>  wrote:


 On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote:
>
>
>
> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>>
>>
>>
>> Gen8+ supports 48-bit virtual addresses, but some objects must
>> always be
>> allocated inside the 32-bit address range.
>>
>> In specific, any resource used with flat/heapless
>> (0x-0xf000)
>> General State Heap (GSH) or Instruction State Heap (ISH) must be in
>> a
>> 32-bit range, because the General State Offset and Instruction State
>> Offset
>> are limited to 32-bits.
>>
>> The i915 driver has been modified to provide a flag to set when the
>> 4GB
>> limit is not necessary in a given bo
>> (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>> 48-bit range will only be used when explicitly requested.
>>
>> Callers to the existing drm_intel_bo_emit_reloc function should set
>> the
>> use_48b_address_range flag beforehand, in order to use full ppgtt
>> range.
>>
>> v2: Make set/clear functions nops on pre-gen8 platforms, and use
>> them
>> internally in emit_reloc functions (Ben)
>> s/48BADDRESS/48B_ADDRESS/ (Dave)
>> v3: Keep set/clear functions internal, no-one needs to use them
>> directly.
>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
>> before enabling set/clear function, print full offsets in
>> debug
>> statements, using port of lower_32_bits and upper_32_bits
>> from linux
>> kernel (MichaÅ)
>>
>> References:
>>
>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>> Cc: Ben Widawsky 
>> Cc: MichaÅ Winiarski 
>
>
>
>
> +Kristian
>
> LGTM.
> Acked-by: MichaÅ Winiarski 
>
>> Signed-off-by: Michel Thierry 





 Hi Kristian,

 More comments on this?
 I've resent the mesa patch with the last changes


 (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).


 MichaÅ has agreed with the interface and will use it for his work.
 If mesa doesn't plan to use this for now, it's ok. The kernel changes
 have
 been done to prevent any regressions when the support 48-bit flag is
 not
 set.
>>>
>>>
>>>
>>> I didn't get any replies to my last comments on this:
>>>
>>> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
>>>
>>> Basically, I tried explicitly placing buffers above 8G and didn't see
>>> the HW problem described (ie it all worked fine).  I still think
>>> there's some confusion as to what the W/A is about.
>>>
>>> Here's my take: the W/A is a SW-only workaround to handle the cases
>>> where a driver uses heapless and 48-bit ppgtt. The problem is that the
>>> heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
>>> anywhere it the 48 bit address space. If that happens it's consideredd
>>> out-of-bounds for the heap and access fails. To prevent this we need
>>> to make sure the bos we address in a heapless fashion are placed below
>>> 4g.
>>>
>>> For mesa, we only configure general state base as heap-less, which
>>> affects scratch bos. What this boils down to is that we need the 4G
>>> restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
>>> and 3DSTATE_PS (and tesselation stage eventually). Look for the
>>> OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
>>> and gen8_ps_state.c
>>
>>
>>
>> I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it
>> isn't exclusive to the scratch bos (the error state points to that
>> instruction).
>>
>>
>
> Hi,
>
> Anymore inputs about this patch?
> AFAIK, if changes are required based on further comments from Kristian,
> these will be in the mesa patch[1], not libdrm. Also, MichaÅ will use
> this
> flag in another project.
>
 The comment seems

drm prime locking recursion

2015-10-14 Thread Dave Airlie

Got this playing with virgl, it happens when gem_object_open driver
callback fails.

Now this probably shouldn't be failing that often, but when it does
deadlock seems wrong.

Dave.

happens if the driver fails
[  677.932957] =
[  677.932957] [ INFO: possible recursive locking detected ]
[  677.932957] 4.3.0-rc5-virtio-gpu+ #11 Not tainted
[  677.932957] -
[  677.932957] Xorg/2661 is trying to acquire lock:
[  677.932957]  (_fpriv->lock){+.+.+.}, at: []
drm_gem_remove_prime_handles.isra.7+0x20/0x50 [drm]
[  677.932957]
   but task is already holding lock:
[  677.932957]  (_fpriv->lock){+.+.+.}, at: []
drm_gem_prime_fd_to_handle+0x4b/0x240 [drm]
[  677.932957]
   other info that might help us debug this:
[  677.932957]  Possible unsafe locking scenario:

[  677.932957]CPU0
[  677.932957]
[  677.932957]   lock(_fpriv->lock);
[  677.932957]   lock(_fpriv->lock);
[  677.932957]
*** DEADLOCK ***

[  677.932957]  May be due to missing lock nesting notation

[  677.932957] 1 lock held by Xorg/2661:
[  677.932957]  #0:  (_fpriv->lock){+.+.+.}, at:
[] drm_gem_prime_fd_to_handle+0x4b/0x240 [drm]
[  677.932957]
   stack backtrace:
[  677.932957] CPU: 1 PID: 2661 Comm: Xorg Not tainted 4.3.0-rc5-virtio-gpu+ #11
[  677.932957] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  677.932957]  82619740 88007b22fb20 813159f9
82619740
[  677.932957]  88007b22fbd8 810d373d 
88007b22fb58
[  677.932957]   88004cfd8700 008e8474
00048af0
[  677.932957] Call Trace:
[  677.932957]  [] dump_stack+0x4b/0x72
[  677.932957]  [] __lock_acquire+0x193d/0x1a60
[  677.932957]  [] lock_acquire+0x6d/0x90
[  677.932957]  [] ?
drm_gem_remove_prime_handles.isra.7+0x20/0x50 [drm]
[  677.932957]  [] mutex_lock_nested+0x64/0x3a0
[  677.932957]  [] ?
drm_gem_remove_prime_handles.isra.7+0x20/0x50 [drm]
[  677.932957]  []
drm_gem_remove_prime_handles.isra.7+0x20/0x50 [drm]
[  677.932957]  [] drm_gem_handle_delete+0xd7/0x110 [drm]
[  677.932957]  [] drm_gem_handle_create_tail+0xff/0x160 [drm]
[  677.932957]  [] drm_gem_prime_fd_to_handle+0xf1/0x240 [drm]
[  677.932957]  []
drm_prime_fd_to_handle_ioctl+0x28/0x40 [drm]
[  677.932957]  [] drm_ioctl+0x124/0x4f0 [drm]
[  677.932957]  [] ?
drm_prime_handle_to_fd_ioctl+0x60/0x60 [drm]
[  677.932957]  [] ? ioctl_has_perm+0xa7/0xc0
[  677.932957]  [] do_vfs_ioctl+0x2da/0x530
[  677.932957]  [] ? selinux_file_ioctl+0x59/0xf0
[  677.932957]  [] ? security_file_ioctl+0x3e/0x60
[  677.932957]  [] SyS_ioctl+0x74/0x80
[  677.932957]  [] entry_SYSCALL_64_fastpath+0x12/0x76
[  840.028068] INFO: task Xorg:2661 blocked for more than 120 seconds.

[PATCH libdrm] Fix void pointer arithmetic in drmProcessPciDevice

2015-10-14 Thread Michel Dänzer

From: Michel DÃ¤nzer 

Arithmetic on void pointers is a GCC extension.

  CC   libdrm_la-xf86drm.lo
../xf86drm.c: In function 'drmProcessPciDevice':
../xf86drm.c:3017:10: warning: pointer of type 'void *' used in arithmetic 
[-Wpointer-arith]
 addr += sizeof(drmDevice);
  ^
../xf86drm.c:3020:10: warning: pointer of type 'void *' used in arithmetic 
[-Wpointer-arith]
 addr += DRM_NODE_MAX * sizeof(void *);
  ^
../xf86drm.c:3023:14: warning: pointer of type 'void *' used in arithmetic 
[-Wpointer-arith]
 addr += max_node_str;
  ^
../xf86drm.c:3035:14: warning: pointer of type 'void *' used in arithmetic 
[-Wpointer-arith]
 addr += sizeof(drmPciBusInfo);
  ^

Signed-off-by: Michel DÃ¤nzer 
---
 xf86drm.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 27313cc..a29db42 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3001,21 +3001,22 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
const char *d_name,
 {
 const int max_node_str = drmGetMaxNodeName();
 int ret, i;
-void *addr;
+char *addr;

-addr = *device = calloc(1, sizeof(drmDevice) +
-   (DRM_NODE_MAX *
-(sizeof(void *) + max_node_str)) +
-   sizeof(drmPciBusInfo) +
-   sizeof(drmPciDeviceInfo));
+*device = calloc(1, sizeof(drmDevice) +
+(DRM_NODE_MAX * (sizeof(void *) + max_node_str)) +
+sizeof(drmPciBusInfo) +
+sizeof(drmPciDeviceInfo));
 if (!*device)
 return -ENOMEM;

+addr = (char*)*device;
+  
 (*device)->bustype = DRM_BUS_PCI;
 (*device)->available_nodes = 1 << node_type;

 addr += sizeof(drmDevice);
-(*device)->nodes = addr;
+(*device)->nodes = (char**)addr;

 addr += DRM_NODE_MAX * sizeof(void *);
 for (i = 0; i < DRM_NODE_MAX; i++) {
@@ -3024,7 +3025,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
const char *d_name,
 }
 memcpy((*device)->nodes[node_type], node, max_node_str);

-(*device)->businfo.pci = addr;
+(*device)->businfo.pci = (drmPciBusInfoPtr)addr;

 ret = drmParsePciBusInfo(maj, min, (*device)->businfo.pci);
 if (ret)
@@ -3033,7 +3034,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
const char *d_name,
 // Fetch the device info if the user has requested it
 if (fetch_deviceinfo) {
 addr += sizeof(drmPciBusInfo);
-(*device)->deviceinfo.pci = addr;
+(*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;

 ret = drmParsePciDeviceInfo(d_name, (*device)->deviceinfo.pci);
 if (ret)
-- 
2.6.0

[Bug 35457] [rs690m] Graphics corruption with ati x1200

2015-10-14 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #102 from d4ddi0  ---
(In reply to Micha from comment #101)
> Another year with only a half working laptop :(
> 
> Is there NOTHING I can do?!???!!!??!
> 
> What causes the problems? The free radeon-driver? Mesa?
> 
> PLEASE
> HELP!
> !
> !
> !!!

I looked at your screenshots, Micha.
Your problem looks like it has to do with the font and typeface.
Both applications look like they use graphical tilesets to display fonts.
I have no idea whether you are experiencing the same type of corruption
described in this bug or something else.

The problem with my system (which was fixed) was that the manufacturer
(Gateway) put incorrect information about the amount of video ram. The
manufacturer never supported Linux, and this type of graphics chip is
relatively rare and odd compared to other radeon families.

Open source radeon developers try to support us, but they don't have our same
hardware. To be honest, I don't expect any remaining bugs with rs690 to get
much attention. They are hard to find, and often problems with the firmware or
hardware that radeon devs can't fix, only try to work around.

Bottom line: No one is still looking at the driver for this hardware.
You have access to the source code and can try looking at it yourself, but the
pros haven't been able to figure it out; it might be hard or impossible to fix.

-- 
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/20151014/f7b628d2/attachment.html>

[Bug 35457] [rs690m] Graphics corruption with ati x1200

2015-10-14 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #101 from Micha  ---
Another year with only a half working laptop :(

Is there NOTHING I can do?!???!!!??!

What causes the problems? The free radeon-driver? Mesa?

PLEASE
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/20151014/00e3810e/attachment.html>

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Ilia Mirkin

On Wed, Oct 14, 2015 at 11:20 AM, Laurent Vivier  wrote:
>
>
> Le 14/10/2015 16:52, Ilia Mirkin a Ã©crit :
>> On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering  wrote:
>>> On Sun, Oct 11, Laurent Vivier wrote:
>>>
 On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp()
 returns NULL. But in fact the OpenFirmware has given us the size
 we can store in image->size.
>>>
 CC: imirkin at alum.mit.edu
 Signed-off-by: Laurent Vivier 
>>>
>>> Tested-by: Olaf Hering 
>>>
>>> Broken since a while already...
>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126737.html
>>
>> FTR, looks like my version is upstream now:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0
>>
>> I agree that my of_size thing was a bit of a hack, if you want to redo
>> it by removing of_size/of_read from shadowof.c and copying it in at
>> init time (also a hack, IMHO), I certainly wouldn't object. As before,
>> it's Ben's call though.
>
> It's nice to have a fix upstream.
>
> I'll send a patch to remove the of_size.
>
> Rereading your patch and mine, I think we don't need no_pcir, we can do
> instead:
>
> if (!nvbios_rd16(bios, base + 0x18)) {
> /* no PCIr */
> image.base = 0;
> image.type = 0;
> image.size = bios->size;
> image.last = 1;
> } else {
> if (!shadow_fetch(bios, mthd, offset + 0x1000)) {
>
> ...
> What is you opinion ?

What if we hit on a real VBIOS without a PCIR? Like, say, some NV4, or
who-knows-what. Seems less safe. My way is very explicit and allows OF
some leeway that "regular" methods don't get.

  -ilia

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Ilia Mirkin

On Wed, Oct 14, 2015 at 11:20 AM, Olaf Hering  wrote:
> On Wed, Oct 14, Ilia Mirkin wrote:
>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0
>
> Thanks.
> Almost perfect, lacks a stable tag.

Code shifted around a lot, I believe. One could create a separate
patch to be backported which would be rather similar, but... meh. Feel
free to do the backport :)

  -ilia

[PATCH libdrm] Fix void pointer arithmetic in drmProcessPciDevice

2015-10-14 Thread Alex Deucher

On Tue, Oct 13, 2015 at 11:55 PM, Michel DÃ¤nzer  wrote:
> From: Michel DÃ¤nzer 
>
> Arithmetic on void pointers is a GCC extension.
>
>   CC   libdrm_la-xf86drm.lo
> ../xf86drm.c: In function 'drmProcessPciDevice':
> ../xf86drm.c:3017:10: warning: pointer of type 'void *' used in arithmetic 
> [-Wpointer-arith]
>  addr += sizeof(drmDevice);
>   ^
> ../xf86drm.c:3020:10: warning: pointer of type 'void *' used in arithmetic 
> [-Wpointer-arith]
>  addr += DRM_NODE_MAX * sizeof(void *);
>   ^
> ../xf86drm.c:3023:14: warning: pointer of type 'void *' used in arithmetic 
> [-Wpointer-arith]
>  addr += max_node_str;
>   ^
> ../xf86drm.c:3035:14: warning: pointer of type 'void *' used in arithmetic 
> [-Wpointer-arith]
>  addr += sizeof(drmPciBusInfo);
>   ^
>
> Signed-off-by: Michel DÃ¤nzer 

Reviewed-by: Alex Deucher 

> ---
>  xf86drm.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 27313cc..a29db42 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3001,21 +3001,22 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
> const char *d_name,
>  {
>  const int max_node_str = drmGetMaxNodeName();
>  int ret, i;
> -void *addr;
> +char *addr;
>
> -addr = *device = calloc(1, sizeof(drmDevice) +
> -   (DRM_NODE_MAX *
> -(sizeof(void *) + max_node_str)) +
> -   sizeof(drmPciBusInfo) +
> -   sizeof(drmPciDeviceInfo));
> +*device = calloc(1, sizeof(drmDevice) +
> +(DRM_NODE_MAX * (sizeof(void *) + max_node_str)) +
> +sizeof(drmPciBusInfo) +
> +sizeof(drmPciDeviceInfo));
>  if (!*device)
>  return -ENOMEM;
>
> +addr = (char*)*device;
> +
>  (*device)->bustype = DRM_BUS_PCI;
>  (*device)->available_nodes = 1 << node_type;
>
>  addr += sizeof(drmDevice);
> -(*device)->nodes = addr;
> +(*device)->nodes = (char**)addr;
>
>  addr += DRM_NODE_MAX * sizeof(void *);
>  for (i = 0; i < DRM_NODE_MAX; i++) {
> @@ -3024,7 +3025,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
> const char *d_name,
>  }
>  memcpy((*device)->nodes[node_type], node, max_node_str);
>
> -(*device)->businfo.pci = addr;
> +(*device)->businfo.pci = (drmPciBusInfoPtr)addr;
>
>  ret = drmParsePciBusInfo(maj, min, (*device)->businfo.pci);
>  if (ret)
> @@ -3033,7 +3034,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
> const char *d_name,
>  // Fetch the device info if the user has requested it
>  if (fetch_deviceinfo) {
>  addr += sizeof(drmPciBusInfo);
> -(*device)->deviceinfo.pci = addr;
> +(*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;
>
>  ret = drmParsePciDeviceInfo(d_name, (*device)->deviceinfo.pci);
>  if (ret)
> --
> 2.6.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC 5/5] gpu/doc: Convert to markdown harder

2015-10-14 Thread Danilo Cesar Lemes de Paula

On 10/14/2015 10:59 AM, Daniel Vetter wrote:
> On Mon, Oct 12, 2015 at 09:10:33AM +0200, Lukas Wunner wrote:
>> This snippet...
>>
>> * Lock VMA manager for extended lookups. Only *_locked() VMA function 
>> calls
>> * are allowed while holding this lock. All other contexts are blocked 
>> from VMA
>> * until the lock is released via drm_vma_offset_unlock_lookup().
>>
>> ...causes markdown-enabled kernel-doc to barf:
>>
>> debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser 
>> error : Opening and ending tag mismatch: emphasis line 3247 and function
>>*locked VMA function calls are allowed 
>> while
>>  ^
>> 
>> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249: 
>> parser error : Opening and ending tag mismatch: function line 3249 and 
>> emphasis
>>released via 
>> drmvma_offset_unlock_lookup.
>> ^
>> unable to parse 
>> /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml
>>
>> A quick workaround is to replace *_locked() by X_locked().
>>
>> Cc: Danilo Cesar Lemes de Paula 
>> Signed-off-by: Lukas Wunner 
>> ---
>>  include/drm/drm_vma_manager.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
>> index 2ca44db..c1e41b8 100644
>> --- a/include/drm/drm_vma_manager.h
>> +++ b/include/drm/drm_vma_manager.h
>> @@ -97,7 +97,7 @@ drm_vma_offset_exact_lookup(struct drm_vma_offset_manager 
>> *mgr,
>>   * drm_vma_offset_lock_lookup() - Lock lookup for extended private use
>>   * @mgr: Manager object
>>   *
>> - * Lock VMA manager for extended lookups. Only *_locked() VMA function calls
>> + * Lock VMA manager for extended lookups. Only X_locked() VMA function calls
> 
> I went with a plain _unlocked since the X_unlocked looked a bit strange.
> Anyway Dave acked the rename idea on irc, so all applied. Well except
> patch 1, there wasn't any conflict when I pushed this to drm-misc.
> -Daniel

I didn't test it (not a big fan of doing this), but \* or \_ should
escape the sequence. Did you consider that?

Danilo


> 
>>   * are allowed while holding this lock. All other contexts are blocked from 
>> VMA
>>   * until the lock is released via drm_vma_offset_unlock_lookup().
>>   *
>> -- 
>> 1.8.5.2 (Apple Git-48)
>>
>

[PATCH] drm/prime: Move all unreferences on fd_to_handle error paths to after unlock

2015-10-14 Thread Chris Wilson

On Wed, Oct 14, 2015 at 10:52:00AM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 27aa7183b20b..1bdd69e1ef43 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -564,26 +564,26 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
>  uint32_t *handle)

>   /* never seen this one, need to import */
> - mutex_lock(>object_name_lock);

I found the use of object_name_lock here confusing. I couldn't see what
it was meant to protect (it is supposed to just lock access to the
global flink name assigned to the object, and I'm sure what value it is
adding to drm_gem_handle_create_tail() either). Anyway the handle here is
protected against concurrent creation/destruction by the prime.lock, so
it looked safe enough to move the object_name_lock back to to
drm_gem_handle_create_tail().
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2] nouveau: fix OpenFirmware support

2015-10-14 Thread Ilia Mirkin

On Wed, Oct 14, 2015 at 10:20 AM, Olaf Hering  wrote:
> On Sun, Oct 11, Laurent Vivier wrote:
>
>> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp()
>> returns NULL. But in fact the OpenFirmware has given us the size
>> we can store in image->size.
>
>> CC: imirkin at alum.mit.edu
>> Signed-off-by: Laurent Vivier 
>
> Tested-by: Olaf Hering 
>
> Broken since a while already...
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126737.html

FTR, looks like my version is upstream now:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=25d295882a1adfcdaaad85369289677b87c7c8f0

I agree that my of_size thing was a bit of a hack, if you want to redo
it by removing of_size/of_read from shadowof.c and copying it in at
init time (also a hack, IMHO), I certainly wouldn't object. As before,
it's Ben's call though.

  -ilia

[PATCH] drm/prime: Move all unreferences on fd_to_handle error paths to after unlock

2015-10-14 Thread Chris Wilson

If we need to take the error path and drop the references to the objects
and handle we created earlier, there is a possibility that we then free
the object and then attempt to free any associated PRIME resources under
the prime mutex. If we are holding the prime mutex when we attempt to
free the handle/object, we risk a recursive deadlock.

[  677.932957] =
[  677.932957] [ INFO: possible recursive locking detected ]
[  677.932957] 4.3.0-rc5-virtio-gpu+ #11 Not tainted
[  677.932957] -
[  677.932957] Xorg/2661 is trying to acquire lock:
[  677.932957]  (_fpriv->lock){+.+.+.}, at: [] 
drm_gem_remove_prime_handles.isra.7+0x20/0x50 [drm]
[  677.932957] but task is already holding lock:
[  677.932957]  (_fpriv->lock){+.+.+.}, at: [] 
drm_gem_prime_fd_to_handle+0x4b/0x240 [drm]

Reported-by: Dave Airlie 
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_prime.c | 47 ++---
 1 file changed, 19 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa7183b20b..1bdd69e1ef43 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -564,26 +564,26 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
   uint32_t *handle)
 {
struct dma_buf *dma_buf;
-   struct drm_gem_object *obj;
+   struct drm_gem_object *obj = NULL;
int ret;

+   *handle = 0;
+
dma_buf = dma_buf_get(prime_fd);
if (IS_ERR(dma_buf))
return PTR_ERR(dma_buf);

mutex_lock(_priv->prime.lock);

-   ret = drm_prime_lookup_buf_handle(_priv->prime,
-   dma_buf, handle);
+   ret = drm_prime_lookup_buf_handle(_priv->prime, dma_buf, handle);
if (ret == 0)
-   goto out_put;
+   goto out;

/* never seen this one, need to import */
-   mutex_lock(>object_name_lock);
obj = dev->driver->gem_prime_import(dev, dma_buf);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
-   goto out_unlock;
+   goto out;
}

if (obj->dma_buf) {
@@ -593,33 +593,24 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
get_dma_buf(dma_buf);
}

-   /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */
-   ret = drm_gem_handle_create_tail(file_priv, obj, handle);
-   drm_gem_object_unreference_unlocked(obj);
+   ret = drm_gem_handle_create(file_priv, obj, handle);
if (ret)
-   goto out_put;
+   goto out;

-   ret = drm_prime_add_buf_handle(_priv->prime,
-   dma_buf, *handle);
-   if (ret)
-   goto fail;
+   ret = drm_prime_add_buf_handle(_priv->prime, dma_buf, *handle);

+out:
mutex_unlock(_priv->prime.lock);
-
-   dma_buf_put(dma_buf);
-
-   return 0;
-
-fail:
-   /* hmm, if driver attached, we are relying on the free-object path
-* to detach.. which seems ok..
-*/
-   drm_gem_handle_delete(file_priv, *handle);
-out_unlock:
-   mutex_unlock(>object_name_lock);
-out_put:
+   if (ret) {
+   /* hmm, if driver attached, we are relying on the
+* free-object path to detach.. which seems ok..
+*/
+   if (*handle)
+   drm_gem_handle_delete(file_priv, *handle);
+   }
+   if (!IS_ERR_OR_NULL(obj))
+   drm_gem_object_unreference_unlocked(obj);
dma_buf_put(dma_buf);
-   mutex_unlock(_priv->prime.lock);
return ret;
 }
 EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
-- 
2.6.1

[GIT PULL] On-demand device probing

2015-10-14 Thread Tomeu Vizoso

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)


Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++--
drivers/base/Kconfig | 18 ++
drivers/base/dd.c | 30 --
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 
drivers/of/device.c | 61
+
drivers/of/platform.c | 30 ++
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu

[GIT PULL] On-demand device probing

2015-10-14 Thread Mark Brown

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:

> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

In don't think that's the URL you intended to use (also everything looks
word wrapped here)?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151014/ecbc901a/attachment.sig>

[PATCH] drm/nouveau: fix memory leak

2015-10-14 Thread Sudip Mukherjee

On Thu, Oct 08, 2015 at 03:22:20PM +0100, Emil Velikov wrote:
> On 8 October 2015 at 14:00, Sudip Mukherjee  
> wrote:
> > On Thu, Oct 01, 2015 at 04:40:59PM +1000, Ben Skeggs wrote:
> >> On 09/25/2015 01:59 AM, Sudip Mukherjee wrote:
> >> > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote:
> >> >> If pm_runtime_get_sync() we were going to "out" but we missed
> >> >> freeing vma.
> >> >>
> >> >> Signed-off-by: Sudip Mukherjee  ---
> >> > Hi Ben, Another gentle ping for another patch.
> >> Both patches are in my tree.
> >
> > Hi Ben,
> > I am not seeing these in linux-next.
> >
> The nouveau tree does not merge into linux-next I'm afraid. Perhaps we
> should as Ben gets the chance/time.

Can I be of any help in that? Maybe I can learn few things about drm in
the proces.

regards
sudip

[PATCH v5 0/17] Add Analogix Core Display Port Driver

2015-10-14 Thread Javier Martinez Canillas

Hello Yakir,

On 10/13/2015 03:50 PM, Yakir Yang wrote:
> On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
> 

[snip]

>>> And it's better to enable pstore function on mainline kernel, so we can 
>>> analysis the last log when
>>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still 
>>> need add ramoops node
>> Interesting, I knew about pstore but I never used it with the Exynos 
>> Chromebooks.
>>
>>> into file, like:
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -750,6 +750,15 @@
>>>  iommu = <_gsc3>;
>>>  };
>>>
>>> +   ramoops: ramoops {
>>> +   compatible = "ramoops";
>>> +   name = "ramoops";
>>> +   reg = <0x41f0 0x10>;
>>> +   record-size = <0x2>;
>>> +   dump-oops;
>>> +   status = "okay";
>>> +   };
>>> +
>> Are you using mainline? There isn't a "ramoops" compatible string documented
>> in the upstream DT bindings, platform_match() would match by driver name as
>> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
>> in your device node. I wonder how this works for you or did I missunderstand?
> 
> Aha, I lost some things that I back port the pstore/ram.c from chrome
> v3.14 tree which driver would parsed the "ramoops" compatible.
>

Ah, that explains it then.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)! [regression]

2015-10-14 Thread Jani Nikula

On Wed, 14 Oct 2015, "Miramontes Caton, Jairo Daniel" 
 wrote:
> Created bug in fdo bugzilla to keep track of this regression:
> https://bugs.freedesktop.org/show_bug.cgi?id=92454

Please disregard that, there's already a bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=92084.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

8086:0f31_freezes_totally

2015-10-14 Thread Jani Nikula

On Wed, 14 Oct 2015, Jani Nikula  wrote:
> On Tue, 13 Oct 2015, Chris Rainey  wrote:
>> [1.] One line summary of the problem:  8086:0f31_freezes_totally
>>
>> [2.] Full description of the problem/report:  Total lockup(cannot even
>> switch to console via Alt-F1, F2, etc.). Bug is most easily
>> reproducible via Chromium browser when opening multiple
>> background-tabs(middle-button(wheel) mouse-clicks) and when using
>> ALT-TAB to switch between browser and Xterms, etc. Very difficult to
>> pin due to randomness(i.e. system may run for 30-seconds, 30-minutes
>> or 30-hours before freeze). However -- it rarely runs stable for more
>> that 24-48/hrs without a lockup.
>
> Please file a bug at [1] running drm-intel-nightly.

Ermh, I meant to say, and attach dmesg from boot with drm.debug=14
module parameter set.

J.




>
> BR,
> Jani.
>
>
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>
>
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/gem: consolidate handle deletion code.

2015-10-14 Thread Daniel Vetter

On Wed, Oct 14, 2015 at 04:30:47PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This code was duplicated, make it decidely
> less duplicated.
> 
> Signed-off-by: Dave Airlie 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_gem.c | 35 +--
>  1 file changed, 17 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 3c2d4ab..12d0dc7 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -239,6 +239,21 @@ drm_gem_object_handle_unreference_unlocked(struct 
> drm_gem_object *obj)
>   drm_gem_object_unreference_unlocked(obj);
>  }
>  
> +static void
> +drm_gem_handle_delete_tail(struct drm_file *filp,
> +struct drm_gem_object *obj)
> +{
> + struct drm_device *dev = obj->dev;
> +
> + if (drm_core_check_feature(dev, DRIVER_PRIME))
> + drm_gem_remove_prime_handles(obj, filp);
> + drm_vma_node_revoke(>vma_node, filp->filp);
> +
> + if (dev->driver->gem_close_object)
> + dev->driver->gem_close_object(obj, filp);
> + drm_gem_object_handle_unreference_unlocked(obj);
> +}
> +
>  /**
>   * drm_gem_handle_delete - deletes the given file-private handle
>   * @filp: drm file-private structure to use for the handle look up
> @@ -276,14 +291,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
>   idr_remove(>object_idr, handle);
>   spin_unlock(>table_lock);
>  
> - if (drm_core_check_feature(dev, DRIVER_PRIME))
> - drm_gem_remove_prime_handles(obj, filp);
> - drm_vma_node_revoke(>vma_node, filp->filp);
> -
> - if (dev->driver->gem_close_object)
> - dev->driver->gem_close_object(obj, filp);
> - drm_gem_object_handle_unreference_unlocked(obj);
> -
> + drm_gem_handle_delete_tail(filp, obj);
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_handle_delete);
> @@ -708,17 +716,8 @@ drm_gem_object_release_handle(int id, void *ptr, void 
> *data)
>  {
>   struct drm_file *file_priv = data;
>   struct drm_gem_object *obj = ptr;
> - struct drm_device *dev = obj->dev;
> -
> - if (drm_core_check_feature(dev, DRIVER_PRIME))
> - drm_gem_remove_prime_handles(obj, file_priv);
> - drm_vma_node_revoke(>vma_node, file_priv->filp);
> -
> - if (dev->driver->gem_close_object)
> - dev->driver->gem_close_object(obj, file_priv);
> -
> - drm_gem_object_handle_unreference_unlocked(obj);
>  
> + drm_gem_handle_delete_tail(file_priv, obj);
>   return 0;
>  }
>  
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

8086:0f31_freezes_totally

2015-10-14 Thread Jani Nikula

On Tue, 13 Oct 2015, Chris Rainey  wrote:
> [1.] One line summary of the problem:  8086:0f31_freezes_totally
>
> [2.] Full description of the problem/report:  Total lockup(cannot even
> switch to console via Alt-F1, F2, etc.). Bug is most easily
> reproducible via Chromium browser when opening multiple
> background-tabs(middle-button(wheel) mouse-clicks) and when using
> ALT-TAB to switch between browser and Xterms, etc. Very difficult to
> pin due to randomness(i.e. system may run for 30-seconds, 30-minutes
> or 30-hours before freeze). However -- it rarely runs stable for more
> that 24-48/hrs without a lockup.

Please file a bug at [1] running drm-intel-nightly.

BR,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/dp/mst: zero out i2c read msg before sending

2015-10-14 Thread Daniel Vetter

On Wed, Oct 14, 2015 at 04:07:20PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This avoids some of the fields being random garbage.
> 
> found this while debugging some other pain.
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Dave Airlie 

Sligthly more serious is that we have a hardcoded limit on the number of
i2c transactions we accept of 4 and we never check that anywhere. And
that's supplied by userspace through i2c-dev nodes potentially and a few
lines below we just loop over that array.

Ofc the mst_i2c_xfer isn't really compliant in general since it doesn't
process any kind of i2c transactions but only those that drm_edid feeds it
(more or less). But that's another topic, but checking num < 4 is an easy
buffer overflow.

With that addressed too this is Reviewed-by: Daniel Vetter 

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ac3c273..2e4f8a3 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2627,6 +2627,7 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter 
> *adapter, struct i2c_msg *msgs
>   goto out;
>   }
>  
> + memset(, 0, sizeof(msg));
>   msg.req_type = DP_REMOTE_I2C_READ;
>   msg.u.i2c_read.num_transactions = num - 1;
>   msg.u.i2c_read.port_number = port->port_num;
> -- 
> 2.4.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 94171] ati multihead black on one output

2015-10-14 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=94171

--- Comment #4 from Felix Miata  ---
Installed in a B85/Haswell/G3220 machine, the Cedar works as expected in
openSUSE Tumbleweed with kernel 4.2.1 and openSUSE 13.1 with kernel 3.12.44
using:
xrandr --dpi 120 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1680x1050 # ati dual
but using X600 or X1300, both displays go black.

With Fedora 23, Plasma 5 and kernel 4.2.2, with X1300 the 1680x1050 screen on
VGA-0 works as expected but the 1920x1080 screen on DVI-0 is black. With X600
and Cedar, all 1920x2130 works as expected.

Using
xrandr --dpi 120 --output HDMI1 --mode 1920x1080 --above VGA1 --output VGA1
--primary --mode 1680x1050 # intel dual
with the onboard video instead of X600, X1300 or Cedar, all OS/kernel
combinations tried run Xorg as expected.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 0/9] drm/exynos: update codes related with gem

2015-10-14 Thread Daniel Vetter

On Wed, Oct 14, 2015 at 09:33:32AM +0900, Joonyoung Shim wrote:
> On 10/13/2015 09:29 PM, Daniel Vetter wrote:
> > On Tue, Oct 13, 2015 at 06:32:53PM +0900, Joonyoung Shim wrote:
> >> On 10/13/2015 05:37 PM, Joonyoung Shim wrote:
> >>> On 10/13/2015 05:27 PM, Daniel Vetter wrote:
>  On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote:
> > Hi,
> >
> > This patchset is about gem codes update of exynos-drm.
> >
> > The first and second patches are cleanup to remove useless codes.
> > The rest is to support cachable gem allocation.
> >
> > The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If
> > it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but
> > DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it
> > doesn't give any effects.
> >
> > This patchset introduces new buffer allocation to use
> > drm_gem_get/put_pages() instead of DMA mapping API. It will be used
> > for the rest except allocation of physically continuous buffer on
> > non-iommu, then exynos-drm can support cachable buffer of gem. Also it
> > can support physically non-continuous buffer on non-iommu.
> >
> > EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care
> > whether buffer is continuous physically if iommu is supported. This
> > patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can
> > mean that the buffer is continuous for device.
> >
> > There is no user API to control cache coherence for the cpu and device
> > about cachable buffer. This patchset introduces two ioctls for cpu
> > access of gem object from user. It will be synced properly in order for
> > the cpu and device if buffer of gem object is cachable.
> 
>  Out of curiosity, where's the userspace part for this work? Usually 
>  kernel
>  abi extensions come with a link to the relevant branch for easier review.
>  -Daniel
> 
> >>>
> >>> Right, thanks for point.
> >>>
> >>> I just modified a little bit exynos_fimg2d_test and exynos parts of
> >>> libdrm to test them as workaround. I will expose it.
> >>>
> >>
> >> Please refer follows.
> >> https://github.com/dofmind/libdrm/commits/exynos
> >>
> >> If fimd2d test program uses cachable gem, it will show cache coherency
> >> problem, so it adds to use new ioctls to keep cache coherency.
> > 
> > Is there some real userspace too, not just a test/demo app?
> 
> Unfortunately not yet, i hope it can be used on real userspace.

In general we wait with merging new userspace ABI until that's really
ready, since very often there's some corner cases that you just didn't
think about in your toy demo compared to the real thing. Like how to
manage buffer caches/reuse for apps that essentially run forever (like X
server or a compositor).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/9] drm/exynos: update codes related with gem

2015-10-14 Thread Joonyoung Shim

On 10/13/2015 09:29 PM, Daniel Vetter wrote:
> On Tue, Oct 13, 2015 at 06:32:53PM +0900, Joonyoung Shim wrote:
>> On 10/13/2015 05:37 PM, Joonyoung Shim wrote:
>>> On 10/13/2015 05:27 PM, Daniel Vetter wrote:
 On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote:
> Hi,
>
> This patchset is about gem codes update of exynos-drm.
>
> The first and second patches are cleanup to remove useless codes.
> The rest is to support cachable gem allocation.
>
> The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If
> it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but
> DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it
> doesn't give any effects.
>
> This patchset introduces new buffer allocation to use
> drm_gem_get/put_pages() instead of DMA mapping API. It will be used
> for the rest except allocation of physically continuous buffer on
> non-iommu, then exynos-drm can support cachable buffer of gem. Also it
> can support physically non-continuous buffer on non-iommu.
>
> EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care
> whether buffer is continuous physically if iommu is supported. This
> patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can
> mean that the buffer is continuous for device.
>
> There is no user API to control cache coherence for the cpu and device
> about cachable buffer. This patchset introduces two ioctls for cpu
> access of gem object from user. It will be synced properly in order for
> the cpu and device if buffer of gem object is cachable.

 Out of curiosity, where's the userspace part for this work? Usually kernel
 abi extensions come with a link to the relevant branch for easier review.
 -Daniel

>>>
>>> Right, thanks for point.
>>>
>>> I just modified a little bit exynos_fimg2d_test and exynos parts of
>>> libdrm to test them as workaround. I will expose it.
>>>
>>
>> Please refer follows.
>> https://github.com/dofmind/libdrm/commits/exynos
>>
>> If fimd2d test program uses cachable gem, it will show cache coherency
>> problem, so it adds to use new ioctls to keep cache coherency.
> 
> Is there some real userspace too, not just a test/demo app?

Unfortunately not yet, i hope it can be used on real userspace.

Thanks.

[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

2015-10-14 Thread Daniel Vetter

On Tue, Oct 13, 2015 at 09:24:26AM -0700, Dan Williams wrote:
> On Tue, Oct 13, 2015 at 1:24 AM, Daniel Vetter  wrote:
> > On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> >> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> >> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> >> > > i915 expects the OpRegion to be cached (i.e. not __iomem), so 
> >> > > explicitly
> >> > > map it with memremap rather than the implied cache setting of
> >> > > acpi_os_ioremap().
> >> > >
> >> > > Cc: Daniel Vetter 
> >> > > Cc: Jani Nikula 
> >> > > Cc: intel-gfx at lists.freedesktop.org
> >> > > Cc: David Airlie 
> >> > > Cc: dri-devel at lists.freedesktop.org
> >> > > Signed-off-by: Dan Williams 
> >> >
> >> > Assuming you've run sparse over this to make sure you've caught them all,
> >> > and with the nit below addressed this is
> >> >
> >> > Reviewed-by: Daniel Vetter 
> >>
> >> Indeed, re-running sparse again found a few conversions of ioread* I
> >> missed as well as moving the force casting out of validate_vbt() to
> >> find_vbt().
> >>
> >> > Feel free to pull v2 into whatever tree you think it's suitable for (but
> >> > you can also resend and I'll pick it up).
> >>
> >> Please pick up v2 below.
> >
> > Queued for -next, thanks for the patch. Aside: Attached or separate mail
> > seems easier, somehow git apply-mbox can't auto-eat this for of patch.
> > -Daniel
> >
> 
> "git am --scissors" should detect the "8<---" cut line.

TIL, works nice indeed. Thanks for the hint.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

2015-10-14 Thread Daniel Vetter

On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian HÃ¸gsberg wrote:
> On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
>  wrote:
> > On 10/13/2015 3:13 PM, Emil Velikov wrote:
> >>
> >> On 13 October 2015 at 13:16, Michel Thierry 
> >> wrote:
> >>>
> >>> On 10/6/2015 2:12 PM, Michel Thierry wrote:
> 
> 
>  On 10/5/2015 7:06 PM, Kristian HÃ¸gsberg wrote:
> >
> >
> > On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
> >  wrote:
> >>
> >>
> >> On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
> 
> 
> 
>  Gen8+ supports 48-bit virtual addresses, but some objects must
>  always be
>  allocated inside the 32-bit address range.
> 
>  In specific, any resource used with flat/heapless
>  (0x-0xf000)
>  General State Heap (GSH) or Instruction State Heap (ISH) must be in
>  a
>  32-bit range, because the General State Offset and Instruction State
>  Offset
>  are limited to 32-bits.
> 
>  The i915 driver has been modified to provide a flag to set when the
>  4GB
>  limit is not necessary in a given bo
>  (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>  48-bit range will only be used when explicitly requested.
> 
>  Callers to the existing drm_intel_bo_emit_reloc function should set
>  the
>  use_48b_address_range flag beforehand, in order to use full ppgtt
>  range.
> 
>  v2: Make set/clear functions nops on pre-gen8 platforms, and use
>  them
> internally in emit_reloc functions (Ben)
> s/48BADDRESS/48B_ADDRESS/ (Dave)
>  v3: Keep set/clear functions internal, no-one needs to use them
>  directly.
>  v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
> before enabling set/clear function, print full offsets in
>  debug
> statements, using port of lower_32_bits and upper_32_bits
>  from linux
> kernel (MichaÅ)
> 
>  References:
> 
>  http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>  Cc: Ben Widawsky 
>  Cc: MichaÅ Winiarski 
> >>>
> >>>
> >>>
> >>>
> >>> +Kristian
> >>>
> >>> LGTM.
> >>> Acked-by: MichaÅ Winiarski 
> >>>
>  Signed-off-by: Michel Thierry 
> >>
> >>
> >>
> >>
> >>
> >> Hi Kristian,
> >>
> >> More comments on this?
> >> I've resent the mesa patch with the last changes
> >>
> >>
> >> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
> >>
> >>
> >> MichaÅ has agreed with the interface and will use it for his work.
> >> If mesa doesn't plan to use this for now, it's ok. The kernel changes
> >> have
> >> been done to prevent any regressions when the support 48-bit flag is
> >> not
> >> set.
> >
> >
> >
> > I didn't get any replies to my last comments on this:
> >
> > http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
> >
> > Basically, I tried explicitly placing buffers above 8G and didn't see
> > the HW problem described (ie it all worked fine).  I still think
> > there's some confusion as to what the W/A is about.
> >
> > Here's my take: the W/A is a SW-only workaround to handle the cases
> > where a driver uses heapless and 48-bit ppgtt. The problem is that the
> > heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
> > anywhere it the 48 bit address space. If that happens it's consideredd
> > out-of-bounds for the heap and access fails. To prevent this we need
> > to make sure the bos we address in a heapless fashion are placed below
> > 4g.
> >
> > For mesa, we only configure general state base as heap-less, which
> > affects scratch bos. What this boils down to is that we need the 4G
> > restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
> > and 3DSTATE_PS (and tesselation stage eventually). Look for the
> > OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
> > and gen8_ps_state.c
> 
> 
> 
>  I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it
>  isn't exclusive to the scratch bos (the error state points to that
>  instruction).
> 
> 
> >>>
> >>> Hi,
> >>>
> >>> Anymore inputs about this patch?
> >>> AFAIK, if changes are required based on further comments from Kristian,
> >>> these will be in the mesa patch[1], not libdrm. Also, MichaÅ will use
> >>> this
> >>> flag in another project.
> >>>
> >> The comment seems quite brief and I'm not sure it fully addresses
> >>

[PATCHv9 06/15] rc: Add HDMI CEC protocol handling

2015-10-14 Thread Hans Verkuil

On 10/14/2015 01:09 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
>> On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
 From: Kamil Debski 

 Add handling of remote control events coming from the HDMI CEC bus.
 This patch includes a new keymap that maps values found in the CEC
 messages to the keys pressed and released. Also, a new protocol has
 been added to the core.

 Signed-off-by: Kamil Debski 
 Signed-off-by: Hans Verkuil 
>>>
>>> (Added Mauro)
>>>
>>> Hmm, how is rc-cec supposed to be loaded?
>>
>> Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
>> you've done
>> that, just checking...)
> 
> CONFIG_RC_MAP=m
> 
> and yes, if depmod hadn't have been run, modprobing rc-cec would not
> have worked - modprobe always looks up in the depmod information to
> find out where the module is located, and also to determine any
> dependencies.
> 
>> It's optional as I understand it, since you could configure the keytable from
>> userspace instead of using this module.
>>
>> For the record (just tried it), it does load fine on my setup.
> 
> Immediately after boot, I have:
> 
> # lsmod
> Module  Size  Used by
> ...
> coda   54685  0
> v4l2_mem2mem   14517  1 coda
> videobuf2_dma_contig 9478  1 coda
> videobuf2_vmalloc   5529  1 coda
> videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
> cecd_dw_hdmi3129  0
> # modprobe rc-cec
> # lsmod
> Module  Size  Used by
> rc_cec  1785  0
> ...
> coda   54685  0
> v4l2_mem2mem   14517  1 coda
> videobuf2_dma_contig 9478  1 coda
> videobuf2_vmalloc   5529  1 coda
> videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
> cecd_dw_hdmi3129  0
> 
> So, rc-cec is perfectly loadable, it just doesn't get loaded at boot.
> Manually loading it like this is useless though - I have to unload
> cecd_dw_hdmi and then re-load it after rc-cec is loaded for rc-cec to
> be seen.  At that point, (and with the help of a userspace program)
> things start working as expected.

Did you compile and install the v4l-utils found here:

http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec

I think that the rc_cec module is loaded through some udev rules and
keytables that are installed by v4l-utils. The standard v4l-utils
doesn't know about cec, but my repo above does.

To be honest, I don't really understand how it works, but if you haven't
installed it yet then try it and see if that solves the problem.

>> BTW, I am still on the fence whether using the kernel RC subsystem is
>> the right thing to do. There are a number of CEC RC commands that use
>> extra parameters that cannot be mapped to the RC API, so you still
>> need to handle those manually.
> 
> Even though it is a remote control which is being forwarded for the
> most part, but there are operation codes which aren't related to
> key presses specified by the standard.  I don't think there's anything
> wrong with having a RC interface present, but allowing other interfaces
> as a possibility is a good thing too - it allows a certain amount of
> flexibility.
> 
> For example, with rc-cec loaded and properly bound, I can control at
> least rhythmbox within gnome using the TVs remote control with no
> modifications - and that happens because the X server passes on the
> events it receives via the event device.
> 
> Given the range of media applications, I think that's key - it needs
> to at least have the capability to plug into the existing ways of doing
> things, even if those ways are not perfect.
> 
>> Perhaps I should split it off into a separate patch and keep it out
>> from the initial pull request once we're ready for that.
> 
> I'm biased because it is an enablement feature - it allows CEC to work
> out of the box with at least some existing media apps. :)
> 

OK, useful feedback. I am considering putting the RC code under a kernel
config option though. So if the RC core is not enabled or you don't want
the RC part to be created, then you can opt to disable it.

Regards,

Hans

[PATCHv9 07/15] cec: add HDMI CEC framework

2015-10-14 Thread Hans Verkuil

On 10/14/2015 12:51 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
>> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
>>> Surely you aren't proposing that drivers should write directly to
>>> adap->phys_addr without calling some notification function that the
>>> physical address has changed?
>>
>> Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
>> enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
>> not set (i.e. the kernel takes care of this), then calling 
>> CEC_ADAP_G_PHYS_ADDR
>> returns the new physical address.
> 
> Okay, so when I see the EDID arrive, I should be doing:
> 
> phys = parse_hdmi_addr(block->edid);
> cec->adap->phys_addr = phys;
> cec_enable(cec->adap, true);
> 
> IOW, you _are_ expecting adap->phys_addr to be written, but only while
> the adapter is disabled?

Right.

And when the hotplug goes down you should call cec_enable(cec->adap, false).
While the adapter is disabled, CEC_ADAP_G_PHYS_ADDR will always return
CEC_PHYS_ADDR_INVALID regardless of the cec->adap->phys_addr value.

Regards,

Hans

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

2015-10-14 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #30 from Barto  ---
I found the cause of this bug,

it's llvm 3.7.0, the llvm git commit who has introduced this bug is :

cd83d5b5071f072882ad06cc4b904b2d27d1e54a

https://github.com/llvm-mirror/llvm/commit/cd83d5b5071f072882ad06cc4b904b2d27d1e54a

the problem is that llvm 3.7.0 treats my pentium dual core as a "penryn",

penryn supports SSE4, but not the pentium dual core series ( CPU family 6 model
23 ),

the faulty commit has deleted a test about SSE4 :

return HasSSE41 ? "penryn" : "core2";

the solution is simply to add this test for CPU family 6 model 23, I created a
patch who solves this bug :

--- a/lib/Support/Host.cpp2015-10-14 07:13:52.381374679 +0200
+++ b/lib/Support/Host.cpp   2015-10-14 07:13:28.224708323 +0200
@@ -332,6 +332,8 @@
// 17h. All processors are manufactured using the 45 nm
process.
//
// 45nm: Penryn , Wolfdale, Yorkfield (XE)
+// Not all Penryn processors support SSE 4.1 (such as the Pentium
brand)
+return HasSSE41 ? "penryn" : "core2";  
   case 29: // Intel Xeon processor MP. All processors are manufactured
using
// the 45 nm process.
 return "penryn";

this patch has been sent to llvm's bugzilla, I hope they will accept it

-- 
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/20151014/b3011d1f/attachment-0001.html>

v4.3-rc4: i915: ThinkPad Yoga 12: ERROR The master control interrupt lied (SDE)! [regression]

2015-10-14 Thread Miramontes Caton, Jairo Daniel

Created bug in fdo bugzilla to keep track of this regression: 
https://bugs.freedesktop.org/show_bug.cgi?id=92454
Regards

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, October 12, 2015 2:06 AM
To: Darren Hart
Cc: Linux Kernel Mailing List; Vetter, Daniel; Daniel Vetter; Jani Nikula; 
David Airlie; intel-gfx at lists.freedesktop.org; dri-devel at 
lists.freedesktop.org; Miramontes Caton, Jairo Daniel
Subject: Re: v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control 
interrupt lied (SDE)! [regression]

Another regression for Jairo to track.
-Daniel

On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not 
> attempted a bisection.
> 
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>  2014-06-18 (1 year, 4 months ago), Oscar Mateo 
> 
> 
> Follows: v3.15-rc8
> Preceedes: 3.17-rc1
> 
> This is not present in v3.16, so perhaps not present in the Debian 
> kernel and this is not a regression, but just reporting the condition as 
> intended.
> 
> Linux Version: v4.3-rc4
> Platform: Lenovo ThinkPad Yoga 12
> OS: Debian 8.2
> 
> $ dmesg | grep -i drm
> [   10.918367] [drm] Initialized drm 1.1.0 20060810
> [   11.235005] [drm] Memory usable by graphics device = 4096M
> [   11.235009] fb: switching to inteldrmfb from simple
> [   11.235093] [drm] Replacing VGA console driver
> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   11.241162] [drm] Driver supports precise vblank timestamp query.
> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
> Can't calculate constants, dotclock = 0!
> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
> banging on pin 5
> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
> minor 0
> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> 
> --
> Darren Hart
> Intel Open Source Technology Center

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

2015-10-14 Thread Miramontes Caton, Jairo Daniel

Created the following bug --> 
https://bugs.freedesktop.org/show_bug.cgi?id=92451  to follow up this regression

Regards

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, October 12, 2015 2:04 AM
To: Takashi Iwai
Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; 
Miramontes Caton, Jairo Daniel
Subject: Re: [Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

Another pile of regressions for Jairo to track ...

On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> Hi,
> 
> I noticed that a HSW laptop gets a few new warnings since 4.2-rc 
> kernels.  One error messages pops at each boot time:
> 
>  Console: switching to colour dummy device 80x25  [drm] Replacing VGA 
> console driver  [drm] Supports vblank timestamp caching Rev 2 
> (21.10.2013).
>  [drm] Driver supports precise vblank timestamp query.
>  vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>  [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate 
> constants, dotclock = 0!

There's patches for this one already, but I accidentally applied them for 
-next, not -fixes. They should land for -rc6.

> Then a warning when I start powertop:
> 
>  WARNING: CPU: 1 PID: 1674 at drivers/gpu/drm/drm_atomic.c:889 
> drm_atomic_get_property+0x232/0x2b0 [drm]()
>  CPU: 1 PID: 1674 Comm: powertop Tainted: GW   4.3.0-rc4-test+ #93
>  Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05 
> 2013/03/15
>   a005b289 880059173ca8 81346fa9 
>   880059173ce0 81063232 8800372bc028 8800373f3740
>   8800372bc000 880062ad37c0 0001 880059173cf0  
> Call Trace:
>   [] dump_stack+0x4b/0x72
>   [] warn_slowpath_common+0x82/0xc0
>   [] warn_slowpath_null+0x1a/0x20
>   [] drm_atomic_get_property+0x232/0x2b0 [drm]
>   [] drm_object_property_get_value+0x6c/0x70 [drm]
>   [] dpms_show+0x2f/0x70 [drm]
>   [] dev_attr_show+0x20/0x50
>   [] sysfs_kf_seq_show+0xbc/0x130
>   [] kernfs_seq_show+0x23/0x30
>   [] seq_read+0xca/0x360
>   [] kernfs_fop_read+0x10a/0x160
>   [] __vfs_read+0x28/0xd0
>   [] ? security_file_permission+0xa0/0xc0
>   [] ? rw_verify_area+0x4f/0xe0
>   [] vfs_read+0x83/0x130
>   [] SyS_read+0x46/0xa0
>   [] ? syscall_return_slowpath+0x50/0x130
>   [] entry_SYSCALL_64_fastpath+0x16/0x75
> 
> 
> Both don't look like serious issues, but not sexy to see at each time.

This should be fixed with

commit 621bd0f6982badd6483acb191eb7b6226a578328
Author: Daniel Vetter 
Date:   Tue Sep 29 09:56:53 2015 +0200

drm: Fix locking for sysfs dpms file

If not please scream.

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

2015-10-14 Thread Russell King - ARM Linux

On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
> > The possible status values that are implemented in the CEC framework
> > are following:
> > 
> > +/* cec status field */
> > +#define CEC_TX_STATUS_OK   (0)
> > +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> > +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> > +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> > +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> > +#define CEC_RX_STATUS_READY(0)
> > 
> > The only two ones I could match with the Exynos CEC module status bits are
> > CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> > 
> > The status bits in Exynos HW are:
> > - Tx_Error
> > - Tx_Done
> > - Tx_Transferring
> > - Tx_Running
> > - Tx_Bytes_Transferred
> > 
> > - Tx_Wait
> > - Tx_Sending_Status_Bit
> > - Tx_Sending_Hdr_Blk
> > - Tx_Sending_Data_Blk
> > - Tx_Latest_Initiator
> > 
> > - Tx_Wait_SFT_Succ
> > - Tx_Wait_SFT_New
> > - Tx_Wait_SFT_Retran
> > - Tx_Retrans_Cnt
> > - Tx_ACK_Failed
> 
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?
> 
> It does look that way...

For the Synopsis DW CEC, I have:

Bit Field   Description
4   ERROR_INIT  An error is detected on cec line (for initiator only).
3   ARB_LOSTThe initiator losses the CEC line arbitration to a second
initiator. (specification CEC 9).
2   NACKA frame is not acknowledged in a directly addressed message.
Or a frame is negatively acknowledged in a broadcast message
(for initiator only).
0   DONEThe current transmission is successful (for initiator only).

That's about as much of a description that there is for this hardware.
Quite what comprises an "ERROR_INIT", I don't know.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCHv9 06/15] rc: Add HDMI CEC protocol handling

2015-10-14 Thread Russell King - ARM Linux

On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
> On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> > On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski 
> >>
> >> Add handling of remote control events coming from the HDMI CEC bus.
> >> This patch includes a new keymap that maps values found in the CEC
> >> messages to the keys pressed and released. Also, a new protocol has
> >> been added to the core.
> >>
> >> Signed-off-by: Kamil Debski 
> >> Signed-off-by: Hans Verkuil 
> > 
> > (Added Mauro)
> > 
> > Hmm, how is rc-cec supposed to be loaded?
> 
> Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
> you've done
> that, just checking...)

CONFIG_RC_MAP=m

and yes, if depmod hadn't have been run, modprobing rc-cec would not
have worked - modprobe always looks up in the depmod information to
find out where the module is located, and also to determine any
dependencies.

> It's optional as I understand it, since you could configure the keytable from
> userspace instead of using this module.
> 
> For the record (just tried it), it does load fine on my setup.

Immediately after boot, I have:

# lsmod
Module  Size  Used by
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0
# modprobe rc-cec
# lsmod
Module  Size  Used by
rc_cec  1785  0
...
coda   54685  0
v4l2_mem2mem   14517  1 coda
videobuf2_dma_contig 9478  1 coda
videobuf2_vmalloc   5529  1 coda
videobuf2_memops1888  2 videobuf2_dma_contig,videobuf2_vmalloc
cecd_dw_hdmi3129  0

So, rc-cec is perfectly loadable, it just doesn't get loaded at boot.
Manually loading it like this is useless though - I have to unload
cecd_dw_hdmi and then re-load it after rc-cec is loaded for rc-cec to
be seen.  At that point, (and with the help of a userspace program)
things start working as expected.

> BTW, I am still on the fence whether using the kernel RC subsystem is
> the right thing to do. There are a number of CEC RC commands that use
> extra parameters that cannot be mapped to the RC API, so you still
> need to handle those manually.

Even though it is a remote control which is being forwarded for the
most part, but there are operation codes which aren't related to
key presses specified by the standard.  I don't think there's anything
wrong with having a RC interface present, but allowing other interfaces
as a possibility is a good thing too - it allows a certain amount of
flexibility.

For example, with rc-cec loaded and properly bound, I can control at
least rhythmbox within gnome using the TVs remote control with no
modifications - and that happens because the X server passes on the
events it receives via the event device.

Given the range of media applications, I think that's key - it needs
to at least have the capability to plug into the existing ways of doing
things, even if those ways are not perfect.

> Perhaps I should split it off into a separate patch and keep it out
> from the initial pull request once we're ready for that.

I'm biased because it is an enablement feature - it allows CEC to work
out of the box with at least some existing media apps. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCHv9 07/15] cec: add HDMI CEC framework

2015-10-14 Thread Russell King - ARM Linux

On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> > Surely you aren't proposing that drivers should write directly to
> > adap->phys_addr without calling some notification function that the
> > physical address has changed?
> 
> Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
> enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
> not set (i.e. the kernel takes care of this), then calling 
> CEC_ADAP_G_PHYS_ADDR
> returns the new physical address.

Okay, so when I see the EDID arrive, I should be doing:

phys = parse_hdmi_addr(block->edid);
cec->adap->phys_addr = phys;
cec_enable(cec->adap, true);

IOW, you _are_ expecting adap->phys_addr to be written, but only while
the adapter is disabled?

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

70 matches

Mail list logo