[radeon-alex:amd-staging-4.9 3/17] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1328:3-5: WARNING: possible condition with no effect (if == else) (fwd)

[Julia Lawall]

The if on line 1327 only exists to allow the comment in the else case.
Perhaps check on whether it is really useful.

The lines also look quite long.  Perhaps this could be cleaned up as well.

julia

-- Forwarded message --
Date: Fri, 3 Mar 2017 05:06:14 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [radeon-alex:amd-staging-4.9 3/17]
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1328:3-5:
WARNING: possible condition with no effect (if == else)


tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   677efd69b448d24dd74e0dfb1d74fb6408c9df81
commit: 9ca8070c97b1eb2b948f065fdbccc15b6e8be639 [3/17] drm/amd/display: rename 
bandwidth_calcs.c to dce_calcs.c (v2)
:: branch date: 4 hours ago
:: commit date: 4 hours ago

>> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1328:3-5: 
>> WARNING: possible condition with no effect (if == else)

git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 9ca8070c97b1eb2b948f065fdbccc15b6e8be639
vim +1328 drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c

bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1312 data->cpuc_state_change_enable = 
bw_def_no;
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1313 }
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1314 }
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1315 else {
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1316 data->cpup_state_change_enable = bw_def_no;
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1317 data->cpuc_state_change_enable = bw_def_no;
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1318 }
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1319 /*nb p-state change enable*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1320 /*for dram speed/p-state change to be possible for a 
yclk(pclk) and sclk level there has to be positive margin and the dispclk 
required has to be*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1321 /*below the maximum.*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1322 /*the dram speed/p-state change margin is the minimum 
for all surfaces of the maximum latency hiding minus the dram speed/p-state 
change latency,*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1323 /*minus the dmif burst time, minus the source line 
transfer time*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1324 /*the maximum latency hiding is the minimum latency 
hiding plus one source line used for de-tiling in the line buffer, plus half 
the urgent latency*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1325 /*if stutter and dram clock state change are gated 
before cursor then the cursor latency hiding does not limit stutter or dram 
clock state change*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1326 for (i = 0; i <= maximum_number_of_surfaces - 1; i++) {
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1327 if (data->enable[i]) {
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25 @1328 if 
((dceip->graphics_lb_nodownscaling_multi_line_prefetching == 1)) {
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1329 
data->maximum_latency_hiding[i] = bw_add(data->minimum_latency_hiding[i], 
bw_mul(bw_frc_to_fixed(8, 10), data->total_dmifmc_urgent_latency));
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1330 }
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1331 else {
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1332 /*maximum_latency_hiding(i) = 
minimum_latency_hiding(i) + 1 / vsr(i) * h_total(i) / pixel_rate(i) + 0.5 * 
total_dmifmc_urgent_latency*/
bad4c165 drivers/gpu/drm/amd/display/dc/calcs/bandwidth_calcs.c Harry Wentland 
2015-11-25  1333  

Re: [PATCH 10/11] dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension

[Rob Herring]

On Thu, Mar 02, 2017 at 04:40:06PM +0100, Neil Armstrong wrote:
> This binding describes the Amlogic Meson specific extension to the
> Synopsys Designware HDMI Controller.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/display/amlogic,meson-dw-hdmi.txt | 111 
> +
>  1 file changed, 111 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt

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

[PATCH v6 4/6] drm/edid: detect SCDC support in HF-VSDB

[Shashank Sharma]

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
  - Add clock rate calculations for 1/10 and 1/40 ratios
  - Remove leftovers from old patchset

Signed-off-by: Shashank Sharma 
Reviewed-by: Thierry Reding 
---
 drivers/gpu/drm/drm_edid.c|  33 ++-
 drivers/gpu/drm/drm_scdc_helper.c | 121 ++
 include/drm/drm_connector.h   |  19 ++
 include/drm/drm_edid.h|   1 -
 include/drm/drm_scdc_helper.h |  27 +
 5 files changed, 199 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d64b7bd..fad3d44 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -3820,13 +3821,43 @@ enum hdmi_quantization_range
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
-   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
 
if (hf_vsdb[6] & 0x80) {
hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   /* max clock is 5000 KHz times block value */
+   u32 max_tmds_clock = hf_vsdb[5] * 5000;
+   struct drm_scdc *scdc = >scdc;
+
+   if (max_tmds_clock > 34) {
+   display->max_tmds_clock = max_tmds_clock;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+   }
+
+   if (scdc->supported) {
+   scdc->scrambling.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   scdc->scrambling.low_rates = true;
+   }
+   }
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index c2dd33f..3cd96a9 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
  */
 
 #include 
+#include 
 
 #include 
+#include 
 
 /**
  * DOC: scdc helpers
@@ -121,3 +123,122 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
offset,
return 0;
 }
 EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
+{
+   u8 status;
+   int ret;
+
+   ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
+   if (ret < 0) {
+   DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+   return false;
+   }
+
+   return status & SCDC_SCRAMBLING_STATUS;
+}
+EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
+
+/**
+ * drm_scdc_set_scrambling - enable scrambling
+ * @adapter: I2C adapter 

[PATCH v6 0/6] HDMI 2.0: Scrambling in DRM layer

[Shashank Sharma]

HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.

This patch series contains 6 patches:
- First two patches add generic drm helper functions to read and
  write into SCDC registers. These patches are written by Thierry,
  in a patch series published here:
  https://patchwork.kernel.org/patch/9459051/
  Minor changes were done to map the patches into this series.
  
- Next two patches add functions for scrambling detection and
  scrambling control.

- Next two patches use this infrastructure in DRM layer from
  I915 driver, to enable scrambling on a GLK deivce which sports
  a native HDMI 2.0 controller.

V2:
- addressed review comments from Thierry, Ville and Dhinakaran
- added signed-off-by:self in first two patches(Jani N)

V3:
- addressed review comments from Jose and Jani

V4:
- addressed review comments from Maarten on patch 5,
  rebase all other patches

V5:
- addressed review comments from Ville/Ander on patch 1, 4, 5
  rebase all other patches

V6:
- addressed review comments from Ville on patch 4, 5
  rebase all other patches

Shashank Sharma (4):
  drm/edid: detect SCDC support in HF-VSDB
  drm/edid: detect SCDC support in HF-VSDB
  drm/i915: enable scrambling
  drm/i915: allow HDMI 2.0 clock rates

Thierry Reding (2):
  drm: Add SCDC helpers
  drm/edid: check for HF-VSDB block

 Documentation/gpu/drm-kms-helpers.rst |  12 ++
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_edid.c|  60 +
 drivers/gpu/drm/drm_scdc_helper.c | 244 ++
 drivers/gpu/drm/i915/i915_reg.h   |   7 +
 drivers/gpu/drm/i915/intel_ddi.c  |  33 +
 drivers/gpu/drm/i915/intel_display.c  |   5 +
 drivers/gpu/drm/i915/intel_drv.h  |  14 ++
 drivers/gpu/drm/i915/intel_hdmi.c |  76 +++
 include/drm/drm_connector.h   |  52 
 include/drm/drm_edid.h|   1 -
 include/drm/drm_scdc_helper.h | 159 ++
 include/linux/hdmi.h  |   1 +
 13 files changed, 665 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

-- 
1.9.1

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

[PATCH v6 2/6] drm/edid: check for HF-VSDB block

[Shashank Sharma]

From: Thierry Reding 

This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/drm_edid.c | 15 +++
 include/linux/hdmi.h   |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5da5a85..3e0aafa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3251,6 +3251,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
return hdmi_id == HDMI_IEEE_OUI;
 }
 
+static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
+{
+   unsigned int oui;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db) < 7)
+   return false;
+
+   oui = db[3] << 16 | db[2] << 8 | db[1];
+
+   return oui == HDMI_FORUM_IEEE_OUI;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index edbb4fc..d271ff2 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -35,6 +35,7 @@ enum hdmi_infoframe_type {
 };
 
 #define HDMI_IEEE_OUI 0x000c03
+#define HDMI_FORUM_IEEE_OUI 0xc45dd8
 #define HDMI_INFOFRAME_HEADER_SIZE  4
 #define HDMI_AVI_INFOFRAME_SIZE13
 #define HDMI_SPD_INFOFRAME_SIZE25
-- 
1.9.1

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

[PATCH v6 3/6] drm/edid: detect SCDC support in HF-VSDB

[Shashank Sharma]

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
 Thierry:
 - Fix typos in commit message and make abbreviation consistent
   across the commit message.
 - Change structure object name from hdmi_info -> hdmi
 - Fix typos and abbreviations in description of structure drm_hdmi_info
   end the description with a full stop.
 - Create a structure drm_scdc, and keep all information related to SCDC
   register set (supported, read request supported) etc in it.

Ville:
 - Change rr -> read_request
 - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
   of HF-VSDB parsing can be kept in same function, in incremental
   patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Rebase.

Signed-off-by: Shashank Sharma 
Reviewed-by: Thierry Reding 
---
 drivers/gpu/drm/drm_edid.c  | 14 ++
 include/drm/drm_connector.h | 33 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e0aafa..d64b7bd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3817,6 +3817,18 @@ enum hdmi_quantization_range
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+   if (hf_vsdb[6] & 0x80) {
+   hdmi->scdc.supported = true;
+   if (hf_vsdb[6] & 0x40)
+   hdmi->scdc.read_request = true;
+   }
+}
+
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
   const u8 *hdmi)
 {
@@ -3931,6 +3943,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
 
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+   if (cea_db_is_hdmi_forum_vsdb(db))
+   drm_parse_hdmi_forum_vsdb(connector, db);
}
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fabb35a..bf9d6f5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,34 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/*
+ * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
+ *
+ * Provides SCDC register support and capabilities related information on a
+ * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
+ */
+struct drm_scdc {
+   /**
+* @supported: status control & data channel present.
+*/
+   bool supported;
+   /**
+* @read_request: sink is capable of generating scdc read request.
+*/
+   bool read_request;
+};
+
+/**
+ * struct drm_hdmi_info - runtime information about the connected HDMI sink
+ *
+ * Describes if a given display supports advanced HDMI 2.0 features.
+ * This information is available in CEA-861-F extension blocks (like HF-VSDB).
+ */
+struct drm_hdmi_info {
+   struct drm_scdc scdc;
 };
 
 /**
@@ -204,6 +232,11 @@ struct drm_display_info {
 * @cea_rev: CEA revision of the HDMI sink.
 */
u8 cea_rev;
+
+   /**
+* @hdmi: advance features of a HDMI sink.
+*/
+   struct drm_hdmi_info hdmi;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
-- 
1.9.1

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

[PATCH v6 6/6] drm/i915: allow HDMI 2.0 clock rates

[Shashank Sharma]

Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.

V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase

Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
Reviewed-by: Ander Conselvan De Oliveira 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0a1ae03..be25aac 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1209,6 +1209,8 @@ static int intel_hdmi_source_max_tmds_clock(struct 
drm_i915_private *dev_priv)
 {
if (IS_G4X(dev_priv))
return 165000;
+   else if (IS_GEMINILAKE(dev_priv))
+   return 594000;
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return 30;
else
-- 
1.9.1

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

[PATCH v6 5/6] drm/i915: enable scrambling

[Shashank Sharma]

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
  driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
  in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
 - In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

V4: Addressed review comment from Maarten
 - scrambling -> hdmi_scrambling
   high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

V5: Addressed review comments from Ville and Ander
 - Do not modifiy the crtc_state after compute_config. Move all
   scrambling and tmds_clock_ratio calcutations to compute_config.
 - While setting scrambling for source/sink, do not check the
   conditions again, just go by the crtc_state flags. This will
   simplyfy the condition checks.

V6: Addressed review comments from Ville
 - Do not add IS_GLK check in disable/enable function, instead add it
   in compute_config, while setting state flags.
 - Remove unnecessary paranthesis.
 - Simplyfy handle_sink_scrambling function as suggested.
 - Add readout code for scrambling status in get_ddi_config and add a
   check for the same in pipe_config_compare.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  |  7 
 drivers/gpu/drm/i915/intel_ddi.c | 33 
 drivers/gpu/drm/i915/intel_display.c |  5 +++
 drivers/gpu/drm/i915/intel_drv.h | 14 +++
 drivers/gpu/drm/i915/intel_hdmi.c| 74 
 5 files changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4906ce4d..f7891ac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7824,7 +7824,14 @@ enum {
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
+#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE \
+   | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
+   | TRANS_DDI_HDMI_SCRAMBLING)
 
 /* DisplayPort Transport Control */
 #define _DP_TP_CTL_A   0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..d0c6927 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv))
+   temp = intel_hdmi_handle_source_scrambling(
+   intel_encoder,
+   intel_crtc->config, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
 
+   if (IS_GEMINILAKE(dev_priv)) {
+   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+   /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   conn_state->connector,
+   crtc->config, true);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
@@ -1917,6 +1937,14 @@ static void intel_disable_ddi(struct 

[PATCH v6 1/6] drm: Add SCDC helpers

[Shashank Sharma]

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
 - Handle the I2c return values in a better way (dp_dual_mode)
 - Make the macros for SCDC Major/Minor more readable, by adding
   a 'GET' in the macro names
V6: Rebase

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
Reviewed-by: Jose Abreu 
---
 Documentation/gpu/drm-kms-helpers.rst |  12 
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_scdc_helper.c | 123 +++
 include/drm/drm_scdc_helper.h | 132 ++
 4 files changed, 269 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
 
+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
 Rectangle Utilities Reference
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..da5b08c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o
+   drm_simple_kms_helper.o drm_modeset_helper.o \
+   drm_scdc_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..c2dd33f
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+   int ret;
+   struct i2c_msg msgs[2] = {
+   {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = 0,
+

[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM

[bugzilla-daemon]

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

Bjorn Helgaas (bhelg...@google.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #24 from Bjorn Helgaas (bhelg...@google.com) ---
Closing on the assumption that the patch mentioned in comment #23 fixes the
problem.

If the problem still occurs on v4.9 or later, please reopen this and attach the
complete dmesg log.

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

Re: [RFC PATCH 3/3] drm: rcar-du: Register a completion callback with VSP1

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Wednesday 01 Mar 2017 13:12:56 Kieran Bingham wrote:
> Updating the state in a running VSP1 requires two interrupts from the
> VSP. Initially, the updated state will be committed - but only after the
> VSP1 has completed processing it's current frame will the new state be
> taken into account. As such, the committed state will only be 'completed'
> after an extra frame completion interrupt.
> 
> Track this delay, by passing the frame flip event through the VSP
> module; It will be returned only when the frame has completed and can be
> returned to the caller.

I'll check the interrupt sequence logic tomorrow, it's a bit too late now. 
Please see below for additional comments.

> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 +-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +-
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 34 ++-
>  3 files changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 7391dd95c733..0a824633a012
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct
> rcar_du_crtc *rcrtc) bool pending;
> 
>   spin_lock_irqsave(>event_lock, flags);
> - pending = rcrtc->event != NULL;
> + pending = (rcrtc->event != NULL) || (rcrtc->pending != NULL);
>   spin_unlock_irqrestore(>event_lock, flags);
> 
>   return pending;
> @@ -578,6 +578,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
> rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
> 
>   if (status & DSSR_FRM) {
> +
> + if (rcrtc->pending) {
> + trace_printk("VBlank loss due to VSP Overrun\n");
> + return IRQ_HANDLED;
> + }
> +
>   drm_crtc_handle_vblank(>crtc);
>   rcar_du_crtc_finish_page_flip(rcrtc);
>   ret = IRQ_HANDLED;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index a7194812997e..8374a858446a
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -46,6 +46,7 @@ struct rcar_du_crtc {
>   bool started;
> 
>   struct drm_pending_vblank_event *event;
> + struct drm_pending_vblank_event *pending;
>   wait_queue_head_t flip_wait;
> 
>   unsigned int outputs;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 71e70e1e0881..408375aff1a0
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -28,6 +28,26 @@
>  #include "rcar_du_kms.h"
>  #include "rcar_du_vsp.h"
> 
> +static void rcar_du_vsp_complete(void *private, void *data)
> +{
> + struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
> + struct drm_device *dev = crtc->crtc.dev;
> + struct drm_pending_vblank_event *event;
> + bool match;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>event_lock, flags);
> + event = crtc->event;
> + crtc->event = data;
> + match = (crtc->event == crtc->pending);
> + crtc->pending = NULL;
> + spin_unlock_irqrestore(>event_lock, flags);
> +
> + /* Safety checks */
> + WARN(event, "Event lost by VSP completion callback\n");
> + WARN(!match, "Stored pending event, does not match completion\n");

I understand you want to be safe, and I assume these have never been triggered 
in your tests. I'd rather replace them by a mechanism that doesn't require 
passing the event to the VSP driver, and that wouldn't require adding a 
pending field to the rcar_du_crtc structure. Wouldn't adding a WARN_ON(rcrtc-
>event) in rcar_du_crtc_atomic_begin() in the if (crtc->state->event) block do 
the job ?

Would this get in the way of your trace_printk() debugging in 
rcar_du_crtc_irq() ? Could you implement the debugging in a separate patch 
without requiring to pass the event to the VSP driver ?

> +}
> +
>  void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>  {
>   const struct drm_display_mode *mode = >crtc.state-
>adjusted_mode;
> @@ -66,6 +86,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>*/
>   crtc->group->need_restart = true;
> 
> + vsp1_du_register_callback(crtc->vsp->vsp, rcar_du_vsp_complete, crtc);
> +
>   vsp1_du_setup_lif(crtc->vsp->vsp, mode->hdisplay, mode->vdisplay);
>  }
> 
> @@ -81,7 +103,17 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
> 
>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
>  {
> - vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
> + struct drm_device *dev = crtc->crtc.dev;
> + struct drm_pending_vblank_event *event;
> + unsigned long flags;
> +
> + /* Move the event to the VSP, track it locally 

Re: [RFC PATCH 2/3] v4l: vsp1: extend VSP1 module API to allow DRM callback registration

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Wednesday 01 Mar 2017 13:12:55 Kieran Bingham wrote:
> To be able to perform page flips in DRM without flicker we need to be
> able to notify the rcar-du module when the VSP has completed its
> processing.
> 
> To synchronise the page flip events for userspace, we move the required
> event through the VSP to track the data flow. When the frame is
> completed, the event can be returned back to the originator through the
> registered callback.
> 
> We must not have bidirectional dependencies on the two components to
> maintain support for loadable modules, thus we extend the API to allow
> a callback to be registered within the VSP DRM interface.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  2 +-
>  drivers/media/platform/vsp1/vsp1_drm.c | 42 +--
>  drivers/media/platform/vsp1/vsp1_drm.h | 12 -
>  include/media/vsp1.h   |  6 +++-
>  4 files changed, 58 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b5bfbe50bd87..71e70e1e0881
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -81,7 +81,7 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
> 
>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
>  {
> - vsp1_du_atomic_flush(crtc->vsp->vsp);
> + vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
>  }
> 
>  /* Keep the two tables in sync. */
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c index 8e2aa3f8e52f..743cbce48d0c
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -52,6 +52,40 @@ int vsp1_du_init(struct device *dev)
>  EXPORT_SYMBOL_GPL(vsp1_du_init);
> 
>  /**
> + * vsp1_du_register_callback - Register VSP completion notifier callback
> + *
> + * Allow the DRM framework to register a callback with us to notify the end
> of + * processing each frame. This allows synchronisation for page
> flipping. + *
> + * @dev: the VSP device
> + * @callback: the callback function to notify the DU module
> + * @private: private structure data to pass with the callback
> + *
> + */
> +void vsp1_du_register_callback(struct device *dev,
> +void (*callback)(void *, void *),
> +void *private)
> +{
> + struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> +
> + vsp1->drm->du_complete = callback;
> + vsp1->drm->du_private = private;
> +}
> +EXPORT_SYMBOL_GPL(vsp1_du_register_callback);

As they're not supposed to change at runtime while the display is running, how 
about passing the callback and private data pointer to the vsp1_du_setup_lif() 
function ? Feel free to create a structure for all the parameters passed to 
the function if you think we'll have too much (which would, as a side effect, 
made updates to the API easier in the future as changes to the two subsystems 
will be easier to decouple).

> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
> +{
> + struct vsp1_drm *drm = to_vsp1_drm(pipe);
> +
> + if (drm->du_complete && drm->active_data)
> + drm->du_complete(drm->du_private, drm->active_data);
> +
> + /* The pending frame is now active */
> + drm->active_data = drm->pending_data;
> + drm->pending_data = NULL;
> +}

I would move this function to the "Interrupt Handling" section.

> +/**
>   * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
>   * @dev: the VSP device
>   * @width: output frame width in pixels
> @@ -99,7 +133,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> width, }
> 
>   pipe->num_inputs = 0;
> -
> + pipe->frame_end = NULL;

You can drop this if ...

> + vsp1->drm->du_complete = NULL;
>   vsp1_dlm_reset(pipe->output->dlm);
>   vsp1_device_put(vsp1);
> 
> @@ -196,6 +231,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> width, if (ret < 0)
>   return ret;
> 
> + pipe->frame_end = vsp1_du_pipeline_frame_end;
> +

... you move this to vsp1_drm_init().

>   ret = media_entity_pipeline_start(>output->entity.subdev.entity,
> >pipe);
>   if (ret < 0) {
> @@ -420,7 +457,7 @@ static unsigned int rpf_zpos(struct vsp1_device *vsp1,
> struct vsp1_rwpf *rpf) * vsp1_du_atomic_flush - Commit an atomic update
>   * @dev: the VSP device
>   */
> -void vsp1_du_atomic_flush(struct device *dev)
> +void vsp1_du_atomic_flush(struct device *dev, void *data)
>  {
>   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
>   struct vsp1_pipeline *pipe = >drm->pipe;
> @@ -504,6 +541,7 @@ void vsp1_du_atomic_flush(struct device *dev)
> 
>   vsp1_dl_list_commit(pipe->dl);
>   pipe->dl = NULL;
> + 

Re: [RFC PATCH 1/3] v4l: vsp1: Register pipe with output WPF

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Wednesday 01 Mar 2017 13:12:54 Kieran Bingham wrote:
> The DRM object does not register the pipe with the WPF object. This is
> used internally throughout the driver as a means of accessing the pipe.
> As such this breaks operations which require access to the pipe from WPF
> interrupts.
> 
> Register the pipe inside the WPF object after it has been declared as
> the output.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c index cd209dccff1b..8e2aa3f8e52f
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -596,6 +596,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>   pipe->bru = >bru->entity;
>   pipe->lif = >lif->entity;
>   pipe->output = vsp1->wpf[0];
> + pipe->output->pipe = pipe;

The vsp1_irq_handler() function calls vsp1_pipeline_frame_end() with wpf-
>pipe, which is currently NULL. With this patch the function will get a non-
NULL pipeline and will thus proceed to calling vsp1_dlm_irq_frame_end():

void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
{
if (pipe == NULL)
return;

vsp1_dlm_irq_frame_end(pipe->output->dlm);

if (pipe->frame_end)
pipe->frame_end(pipe);

pipe->sequence++;
}

pipe->frame_end is NULL, pipe->sequence doesn't matter, but we now end up 
calling vsp1_dlm_irq_frame_end(). This is a major change regarding display 
list processing, yet it seems to have no effect at all.

The following commit is to blame for skipping the call to 
vsp1_dlm_irq_frame_end().

commit ff7e97c94d9f7f370fe3ce2a72e85361ca22a605
Author: Laurent Pinchart 
Date:   Tue Jan 19 19:16:36 2016 -0200

[media] v4l: vsp1: Store pipeline pointer in rwpf

I've added a few debug print statements to vsp1_dlm_irq_frame_end(), and it 
looks like we only hit the if (dlm->queued) test or none of them at all. It 
looks like we've been lucky that nothing broke.

Restoring the previous behaviour should be safe, but it would be worth it 
inspecting the code very carefully to make sure the logic is still correct. 
I'll do it tomorrow if you don't beat me to it.

In any case, how about adding a

Fixes: ff7e97c94d9f ("[media] v4l: vsp1: Store pipeline pointer in rwpf")

line ?

>   return 0;
>  }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 2/7] arm: dts: Add the burst and esc clock frequency properties for exynos3250 dts

[Andi Shyti]

Hi Hoegeun,

On Thu, Mar 02, 2017 at 07:20:14PM +0900, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. So
> added the burst and esc clock frequency properties to the parent (DSI
> node), taking into account the bisectability problem so that remove
> the OF graph from DSI node.

nitpick:

1. bisectability is not a problem (and for bisectability you
   should not mention it in the commit log, you would confuse
   bisecting people)

2. you should use the imperative form, not "added the burst... "
   but "add the burst..."

Same for the other patches.

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

Re: [PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

[Andi Shyti]

Hi Hoegeun,

> Hoegeun Kwon (7):
>   arm64: dts: exynos: Add the burst and esc clock frequency properties
> for exynos5433 dts
>   arm: dts: Add the burst and esc clock frequency properties for
> exynos3250 dts
>   arm: dts: Add the burst and esc clock frequency properties for
> exynos4412 dts
>   arm: dts: Add the burst and esc clock frequency properties for
> exynos4210 dts
>   drm/exynos: dsi: Fix the parse_dt function
>   arm64: dts: exynos: Remove the OF graph from DSI node
>   arm: dts: Remove the OF graph from DSI node

for all of them:

Reviewed-by: Andi Shyti 

although I would have squashed patch 2, 3 and 4, but no need to
resend, unless someone else agrees.

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu,  2 Mar 2017 16:40:02 +0100
Daniel Vetter  escreveu:

> From: Markus Heiser 
> 
> This patch brings scalable figure, image handling and a concept to
> embed *render* markups:
> 
> * DOT (http://www.graphviz.org)
> * SVG
> 
> For image handling use the 'image' replacement::
> 
> .. kernel-image::  svg_image.svg
>:alt:simple SVG image
> 
> For figure handling use the 'figure' replacement::
> 
> .. kernel-figure::  svg_image.svg
>:alt:simple SVG image
> 
>SVG image example
> 
> Embed *render* markups (or languages) like Graphviz's **DOT** is
> provided by the *render* directive.::
> 
>   .. kernel-render:: DOT
>  :alt: foobar digraph
>  :caption: Embedded **DOT** (Graphviz) code.
> 
>  digraph foo {
>   "bar" -> "baz";
>  }
> 
> The *render* directive is a concept to integrate *render* markups and
> languages, yet supported markups:
> 
> * DOT: render embedded Graphviz's **DOT**
> * SVG: render embedded Scalable Vector Graphics (**SVG**)
> 
> v2: s/DOC/DOT/ in a few places (by Daniel).
> 
> v3: Simplify stuff a bit (by Daniel):
> 
> - Remove path detection and setup/check code for that. In
>   Documentation/media/Makefile we already simply use these tools,
>   better to have one consolidated check if we want/need one. Also
>   remove the convertsvg support, we require ImageMagick's convert
>   already in the doc build, no need for a 2nd fallback.
> 
> - Use sphinx for depency tracking, remove hand-rolled version.
> 
> - Forward stderr from dot and convert, otherwise debugging issues with
>   the diagrams is impossible.
> 
> v4: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
> untested.
> 
> v5: Use an explicit version check (suggested by Laurent).

Found another issue on the patch. The HTML output is pointing to the
wrong place: instead of using a relative patch, it is keeping 
an absolute one.

This is what it produced from Documentation/media/uapi/v4l/dev-subdev.rst:


Image Format Negotiation on 
Pipelines

High quality and high speed pipeline configuration


There, the "src=" is pointing to the full patch, with doesn't work, as
my html server uses a different patch to find the file. It should,
instead, use a patch relative to the place where the html file is
stored, e. g. in this case, either:
./pipeline.svg
or just:
pipeline.svg

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 16:34:22 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu, 2 Mar 2017 20:06:39 +0100
> Markus Heiser  escreveu:
> 
> > Hi Mauro,
> > 
> > > Tested here with the enclosed patch.  
> > 
> > great, big step forward making /media/Makefile smaller ...  thanks a lot
> > 
> > > It crashed:
> > > Exception occurred:
> > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > in dot2format
> > >sys.stderr.write(err)
> > > TypeError: write() argument must be str, not bytes
> > > The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> > > want to report the issue to the developers.
> > > Please also report this if it was a user error, so that a better error 
> > > message can be provided next time.
> > > A bug report can be filed in the tracker at 
> > > . Thanks!
> > > Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> > > make[1]: *** [htmldocs] Error 1
> > > Makefile:1450: recipe for target 'htmldocs' failed
> > > make: *** [htmldocs] Error 2
> > > 
> > > Weird enough, it produced a 
> > > Documentation/output/media/uapi/v4l/pipeline.svg file.  
> > 
> > I guess that the dot command writes something to stderr. This is captured 
> > by the extension and printed to stderr ...
> > 
> > +def dot2format(dot_fname, out_fname):
> > ...
> > +exit_code = 42
> > +with open(out_fname, "w") as out:
> > +p = subprocess.Popen(
> > +cmd, stdout = out, stderr = subprocess.PIPE )
> > +nil, err = p.communicate()
> > +
> > +sys.stderr.write(err)
> > +
> > +exit_code = p.returncode
> > +out.flush()
> > +return bool(exit_code == 0)
> > 
> > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > in dot2format
> > >sys.stderr.write(err)
> > > TypeError: write() argument must be str, not bytes  
> > 
> > Do we need this stderr output? For a first test, uncomment the 
> > "sys.stderr.write(err)“ in line 222. Or, if we really need the
> > stderr, try:
> > 
> > -sys.stderr.write(err)
> > +sys.stderr.write(str(err))
> 
> Yes, this fixed. I actually did:
> 
> -sys.stderr.write(err)
> +sys.stderr.write(str(err))
> +sys.stderr.write("\n")
> 
> It is now printing:
>   b''
> 
> I added the \n print to avoid it to be mixed with the "writing output"
> prints.
> 
> No idea how to make sense from it - but clearly, the error report
> logic require some care ;-)

I'm not a Python programmer, but googling about the right syntax for
p.communicate(), I suspect that the fix should be similar to this code
snippet below.

Without the if, this code:

sys.stderr.write("Error:" + repr(p.communicate()[0]) + "\n")

prints:
Error:None

So, I guess the code below is ok.

Markus, please check. 

Daniel, Feel free to merge it with the original patch if OK.

diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py
index 32eab0f4cfba..b154c5f17752 100644
--- a/Documentation/sphinx/kfigure.py
+++ b/Documentation/sphinx/kfigure.py
@@ -217,11 +217,12 @@ def dot2format(dot_fname, out_fname):
 with open(out_fname, "w") as out:
 p = subprocess.Popen(
 cmd, stdout = out, stderr = subprocess.PIPE )
-nil, err = p.communicate()
-
-sys.stderr.write(err)
 
 exit_code = p.returncode
+
+if exit_code == 0:
+sys.stderr.write("Error:" + repr(p.communicate()[0]) + "\n")
+
 out.flush()
 return bool(exit_code == 0)
 
@@ -239,11 +240,12 @@ def svg2pdf(svg_fname, pdf_fname):
 cmd = [convert_cmd, svg_fname, pdf_fname]
 p = subprocess.Popen(
 cmd, stdout = out, stderr = subprocess.PIPE )
-nil, err = p.communicate()
-
-sys.stderr.write(err)
 
 exit_code = p.returncode
+
+if exit_code == 0:
+sys.stderr.write("Error:" + repr(p.communicate()[0]) + "\n")
+
 return bool(exit_code == 0)
 
 

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

Re: [PATCH v4 6/9] drm: bridge: dw-hdmi: Create PHY operations

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> The HDMI TX controller support different PHYs whose programming
> interface can vary significantly, especially with vendor PHYs that are
> not provided by Synopsys. To support them, create a PHY operation
> structure that can be provided by the platform glue layer. The existing
> PHY handling code (limited to Synopsys PHY support) is refactored into a
> set of default PHY operations that are used automatically when the
> platform glue doesn't provide its own operations.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 91 
> 
>  include/drm/bridge/dw_hdmi.h | 18 +++-
>  2 files changed, 80 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 0aa3ad404f77..cb2703862be2 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -141,8 +141,12 @@ struct dw_hdmi {
>   u8 edid[HDMI_EDID_LEN];
>   bool cable_plugin;
>  
> - const struct dw_hdmi_phy_data *phy;
> - bool phy_enabled;
> + struct {
> + const struct dw_hdmi_phy_ops *ops;
> + const char *name;
> + void *data;
> + bool enabled;
> + } phy;
>  
>   struct drm_display_mode previous_mode;
>  
> @@ -831,6 +835,10 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
> HDMI_VP_CONF);
>  }
>  
> +/* 
> -
> + * Synopsys PHY Handling
> + */
> +
>  static inline void hdmi_phy_test_clear(struct dw_hdmi *hdmi,
>  unsigned char bit)
>  {
> @@ -987,6 +995,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>  
>  static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>  {
> + const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
>   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
> @@ -1019,7 +1028,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   dw_hdmi_phy_power_off(hdmi);
>  
>   /* Leave low power consumption mode by asserting SVSRET. */
> - if (hdmi->phy->has_svsret)
> + if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
>  
>   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> @@ -1057,7 +1066,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   return dw_hdmi_phy_power_on(hdmi);
>  }
>  
> -static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
> +static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
> + struct drm_display_mode *mode)
>  {
>   int i, ret;
>  
> @@ -1071,10 +1081,31 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>   return ret;
>   }
>  
> - hdmi->phy_enabled = true;
>   return 0;
>  }
>  
> +static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
> +{
> + dw_hdmi_phy_power_off(hdmi);
> +}
> +
> +static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +   void *data)
> +{
> + return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> + connector_status_connected : connector_status_disconnected;
> +}
> +
> +static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> + .init = dw_hdmi_phy_init,
> + .disable = dw_hdmi_phy_disable,
> + .read_hpd = dw_hdmi_phy_read_hpd,
> +};
> +
> +/* 
> -
> + * HDMI TX Setup
> + */
> +
>  static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
>  {
>   u8 de;
> @@ -1289,16 +1320,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
>   hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
>  }
>  
> -static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
> -{
> - if (!hdmi->phy_enabled)
> - return;
> -
> - dw_hdmi_phy_power_off(hdmi);
> -
> - hdmi->phy_enabled = false;
> -}
> -
>  /* HDMI Initialization Step B.4 */
>  static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
>  {
> @@ -1431,9 +1452,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   hdmi_av_composer(hdmi, mode);
>  
>   /* HDMI Initializateion Step B.2 */
> - ret = dw_hdmi_phy_init(hdmi);
> + ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data, >previous_mode);
>   if (ret)
>   return ret;
> + hdmi->phy.enabled = true;
>  
>   /* HDMI Initialization Step B.3 */
>   dw_hdmi_enable_video_path(hdmi);
> @@ -1548,7 +1570,11 @@ static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
> 

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 23:15:49 +0100
Markus Heiser  escreveu:

> Hi Daniel, hi Mauro,
> 
> I have to say, that I lost control over our thread ;)
> 
> > v3: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> > Implement Markus suggestion for backwards compatability with earlier
> > releases. Laurent reported this, running sphinx 1.3. Solution entirely
> > untested.  
> 
> I have to come back to a more systematic work, this means;
> I have to test this v3 and consider what Mauro and you 
> already posted.

Yes, you're lost :-) The last patch Daniel Sent was v5. From his last patch:


> v4: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
> untested.
> 
> v5: Use an explicit version check (suggested by Laurent).

https://marc.info/?l=linux-doc=148847115500505=2


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

Re: [PATCH v4 23/23] drm/rockchip: dw-mipi-dsi: add reset control

[Brian Norris]

Oh, one more thing:

On Fri, Feb 24, 2017 at 12:55:06PM +, John Keeping wrote:

> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 0c4bae711e84..30da75667334 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1144,6 +1145,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   of_match_device(dw_mipi_dsi_dt_ids, dev);
>   const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
>   struct platform_device *pdev = to_platform_device(dev);
> + struct reset_control *apb_rst;
>   struct drm_device *drm = data;
>   struct dw_mipi_dsi *dsi;
>   struct resource *res;
> @@ -1182,6 +1184,35 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> + /*
> +  * Note that the reset was not defined in the initial device tree, so
> +  * we have to be prepared for it not being found.
> +  */
> + apb_rst = devm_reset_control_get(dev, "apb");
> + if (IS_ERR(apb_rst)) {
> + ret = PTR_ERR(apb_rst);
> + if (ret == -ENOENT) {
> + apb_rst = NULL;
> + } else {
> + dev_err(dev, "Unable to get reset control: %d\n", ret);

Might want to check for -EPROBE_DEFER before printing an error?

Brian

> + return ret;
> + }
> + }
> +
> + if (apb_rst) {
> + ret = clk_prepare_enable(dsi->pclk);
> + if (ret) {
> + dev_err(dev, "%s: Failed to enable pclk\n", __func__);
> + return ret;
> + }
> +
> + reset_control_assert(apb_rst);
> + usleep_range(10, 20);
> + reset_control_deassert(apb_rst);
> +
> + clk_disable_unprepare(dsi->pclk);
> + }
> +
>   ret = clk_prepare_enable(dsi->pllref_clk);
>   if (ret) {
>   dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 17:04:01 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu, 2 Mar 2017 20:52:59 +0100
> Daniel Vetter  escreveu:
> 
> > On Thu, Mar 02, 2017 at 08:06:39PM +0100, Markus Heiser wrote:  
> > > Hi Mauro,
> > > 
> > > > Tested here with the enclosed patch.
> > > 
> > > great, big step forward making /media/Makefile smaller ...  thanks a 
> > > lot
> > > 
> > > > It crashed:
> > > > Exception occurred:
> > > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > > in dot2format
> > > >sys.stderr.write(err)
> > > > TypeError: write() argument must be str, not bytes
> > > > The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if 
> > > > you want to report the issue to the developers.
> > > > Please also report this if it was a user error, so that a better error 
> > > > message can be provided next time.
> > > > A bug report can be filed in the tracker at 
> > > > . Thanks!
> > > > Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> > > > make[1]: *** [htmldocs] Error 1
> > > > Makefile:1450: recipe for target 'htmldocs' failed
> > > > make: *** [htmldocs] Error 2
> > > > 
> > > > Weird enough, it produced a 
> > > > Documentation/output/media/uapi/v4l/pipeline.svg file.
> > > 
> > > I guess that the dot command writes something to stderr. This is captured 
> > > by the extension and printed to stderr ...
> > > 
> > > +def dot2format(dot_fname, out_fname):
> > > ...
> > > +exit_code = 42
> > > +with open(out_fname, "w") as out:
> > > +p = subprocess.Popen(
> > > +cmd, stdout = out, stderr = subprocess.PIPE )
> > > +nil, err = p.communicate()
> > > +
> > > +sys.stderr.write(err)
> > > +
> > > +exit_code = p.returncode
> > > +out.flush()
> > > +return bool(exit_code == 0)
> > > 
> > > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > > in dot2format
> > > >sys.stderr.write(err)
> > > > TypeError: write() argument must be str, not bytes
> > > 
> > > Do we need this stderr output? For a first test, uncomment the 
> > > "sys.stderr.write(err)“ in line 222. Or, if we really need the
> > > stderr, try:
> > > 
> > > -sys.stderr.write(err)
> > > +sys.stderr.write(str(err))
> > > 
> > > I this fixes, there is another "sys.stderr.write(err)" in 
> > > func svg2pdf(..) which should also fixed ….
> > >  
> > > +def svg2pdf(svg_fname, pdf_fname):
> > > ...
> > > +cmd = [convert_cmd, svg_fname, pdf_fname]
> > > +p = subprocess.Popen(
> > > +cmd, stdout = out, stderr = subprocess.PIPE )
> > > +nil, err = p.communicate()
> > > +
> > > -sys.stderr.write(err)
> > > +sys.stderr.write(str(err))
> > > +
> > > +exit_code = p.returncode
> > > +return bool(exit_code == 0)
> > 
> > Yes, I very much want stderr to be forward.  
> 
> Yes, error report is required.
> 
> > Without that you don't see
> > error output from dot or convert, and that makes it impossible to debug
> > anything. If I want a direct forwarding of the bytes, how should I do this
> > in python? Capturing stderr and then re-dumping it is kinda silly ...  
> 
> Markus or some other Python programmer may help us with that.
> 
> > Note that I copied this pattern from the kernel-doc extension, seems to
> > have worked there.  
> 
> Maybe it is broken there too then, or this is another python API
> that changed over time. Here, I'm testing with:
>   python3-3.5.2-4.fc25.x86_64
> 
> From here:
>   https://docs.python.org/2/library/subprocess.html
> 
> communicate returns a tuple.
> 
> I used repr(p.communicate()[0], on the code snippet I sent, 
> as I copied from an example that I found at:
>   
> https://stackoverflow.com/questions/33295284/python-subprocess-popen-write-to-stderr
> 
> Thanks,
> Mauro

I suspect that the actual fixup would be something like:


commit ddf93ae81af10bb43caa651b9acd355f1d74cebe
Author: Mauro Carvalho Chehab 
Date:   Thu Mar 2 17:11:47 2017 -0300

kfigure.py fixups

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py
index 32eab0f4cfba..19389cb34d6f 100644
--- a/Documentation/sphinx/kfigure.py
+++ b/Documentation/sphinx/kfigure.py
@@ -217,11 +217,13 @@ def dot2format(dot_fname, out_fname):
 with open(out_fname, "w") as out:
 p = subprocess.Popen(
 cmd, stdout = out, stderr = subprocess.PIPE )
-nil, err = p.communicate()
-
-sys.stderr.write(err)
+err = p.communicate()
 
 exit_code = p.returncode
+
+if exit_code == 0:
+sys.stderr.write("Error:" + repr(err[0]) + "\n")
+
 out.flush()
 return bool(exit_code == 0)
 
@@ -239,11 +241,13 @@ def svg2pdf(svg_fname, pdf_fname):
  

Re: [PATCH v4 1/9] drm: bridge: dw-hdmi: Remove unused functions

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> Most of the hdmi_phy_test_*() functions are unused. Remove them.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
>  1 file changed, 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 9a9ec27d9e28..ce7496399ccf 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -837,32 +837,6 @@ static inline void hdmi_phy_test_clear(struct dw_hdmi 
> *hdmi,
> HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
>  }
>  
> -static inline void hdmi_phy_test_enable(struct dw_hdmi *hdmi,
> - unsigned char bit)
> -{
> - hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTEN_OFFSET,
> -   HDMI_PHY_TST0_TSTEN_MASK, HDMI_PHY_TST0);
> -}
> -
> -static inline void hdmi_phy_test_clock(struct dw_hdmi *hdmi,
> -unsigned char bit)
> -{
> - hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLK_OFFSET,
> -   HDMI_PHY_TST0_TSTCLK_MASK, HDMI_PHY_TST0);
> -}
> -
> -static inline void hdmi_phy_test_din(struct dw_hdmi *hdmi,
> -  unsigned char bit)
> -{
> - hdmi_writeb(hdmi, bit, HDMI_PHY_TST1);
> -}
> -
> -static inline void hdmi_phy_test_dout(struct dw_hdmi *hdmi,
> -   unsigned char bit)
> -{
> - hdmi_writeb(hdmi, bit, HDMI_PHY_TST2);
> -}
> -
>  static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
>  {
>   u32 val;

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 17:13:25 +0100
Markus Heiser  escreveu:

> > Am 02.03.2017 um 16:49 schrieb Mauro Carvalho Chehab 
> > :
> >   
> >>> You can test it with virtualenv  
> >>> https://virtualenv.pypa.io/en/stable/userguide/
> >>> 
> >>> In short:
> >>> 
> >>> $ cd kernel-src
> >>> $ virtualenv myenv
> >>> $ source myenv/bin/activate
> >>> $ pip install 'Sphinx==1.3.1'
> >>> $ make 
> >> 
> >> Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
> >> virtualenv is broken:
> >> 
> >> writing output... [ 16%] media/intro   
> >>  
> >> Exception occurred:
> >>  File 
> >> "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
> >>  line 671, in depart_document
> >>assert not self.context, 'len(context) = %s' % len(self.context)
> >> AssertionError: len(context) = 1
> >> The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you 
> >> want to report the issue to the developers.
> >> Please also report this if it was a user error, so that a better error 
> >> message can be provided next time.
> >> A bug report can be filed in the tracker at 
> >> . Thanks!
> >> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> >> make[1]: *** [htmldocs] Error 1
> >> Makefile:1450: recipe for target 'htmldocs' failed
> >> make: *** [htmldocs] Error 2
> >> 
> >> Perhaps it is time for us to move minimal requirements to 1.4?  
> > 
> > Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
> > with 1.5.2 (for htmldocs).
> > 
> > Thanks,
> > Mauro
> > 
> > -
> > 
> > This is the error log with 1.4:
> > 
> > # Sphinx version: 1.4.9  
> 
> >  File 
> > "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
> >  line 187, in walkabout
> >visitor.dispatch_departure(self)
> >  File 
> > "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
> >  line 1895, in dispatch_departure
> >return method(node)
> >  File 
> > "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
> >  line 671, in depart_document
> >assert not self.context, 'len(context) = %s' % len(self.context)
> > AssertionError: len(context) = 1  
> 
> I guess this is a error from newer docutils, so we have to fix docutils 
> version also.
> 
> Sphinx itself specifies "docutils>=0.11"
> 
>   https://github.com/sphinx-doc/sphinx/blob/1.3.1/setup.py#L52
> 
> So I guess it uses a up to date docutils or the ducutils which are already 
> installed system wide.

The system-wide docutils is this one:

python2-docutils-0.13.1-3.fc25.noarch
python3-docutils-0.13.1-3.fc25.noarch

Btw, I tested also with virtualenv-3/pip3 and the same issue happens there.


Manually installing version 0.11 makes it to work again.

Considering that Sphinx require a specific docutils package for it to
work, perhaps it is time for us to consider to use the virtenv
enchantments at make docs targets :-p



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

Re: [PATCH v4 4/9] drm: bridge: dw-hdmi: Fix the PHY power down sequence

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> The PHY requires us to wait for the PHY to switch to low power mode
> after deasserting TXPWRON and before asserting PDDQ in the power down
> sequence, otherwise power down will fail.
>
> The PHY power down can be monitored though the TX_READY bit, available
> through I2C in the PHY registers, or the TX_PHY_LOCK bit, available
> through the HDMI TX registers. As the two are equivalent, let's pick the
> easier solution of polling the TX_PHY_LOCK bit.
>
> The power down code is currently duplicated in multiple places. To avoid
> spreading multiple calls to a TX_PHY_LOCK poll function, we have to
> refactor the power down code and group it all in a single function.
>
> Tests showed that one poll iteration was enough for TX_PHY_LOCK to
> become low, without requiring any additional delay. Retrying the read
> five times with a 1ms to 2ms delay between each attempt should thus be
> more than enough.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 52 
> +---
>  1 file changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index d863b3393aee..85348ba6bb1c 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -116,6 +116,7 @@ struct dw_hdmi_i2c {
>  struct dw_hdmi_phy_data {
>   enum dw_hdmi_phy_type type;
>   const char *name;
> + unsigned int gen;
>   bool has_svsret;
>  };
>  
> @@ -914,6 +915,40 @@ static void dw_hdmi_phy_sel_interface_control(struct 
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
>  
> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> +{
> + const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> + unsigned int i;
> + u16 val;
> +
> + if (phy->gen == 1) {
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_powerdown(hdmi, true);
> + return;
> + }
> +
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> +
> + /*
> +  * Wait for TX_PHY_LOCK to be deasserted to indicate that the PHY went
> +  * to low power mode.
> +  */
> + for (i = 0; i < 5; ++i) {
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
> + if (!(val & HDMI_PHY_TX_PHY_LOCK))
> + break;
> +
> + usleep_range(1000, 2000);
> + }
> +
> + if (val & HDMI_PHY_TX_PHY_LOCK)
> + dev_warn(hdmi->dev, "PHY failed to power down\n");
> + else
> + dev_dbg(hdmi->dev, "PHY powered down in %u iterations\n", i);
> +
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +}
> +
>  static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>  {
>   u8 val, msec;
> @@ -946,11 +981,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   return -EINVAL;
>   }
>  
> - /* gen2 tx power off */
> - dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> -
> - /* gen2 pddq */
> - dw_hdmi_phy_gen2_pddq(hdmi, 1);
> + dw_hdmi_phy_power_off(hdmi);
>  
>   /* Leave low power consumption mode by asserting SVSRET. */
>   if (hdmi->phy->has_svsret)
> @@ -1025,8 +1056,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>   for (i = 0; i < 2; i++) {
>   dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
>   dw_hdmi_phy_sel_interface_control(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_powerdown(hdmi, true);
>  
>   ret = hdmi_phy_configure(hdmi);
>   if (ret)
> @@ -1256,8 +1285,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
>   if (!hdmi->phy_enabled)
>   return;
>  
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_powerdown(hdmi, true);
> + dw_hdmi_phy_power_off(hdmi);
>  
>   hdmi->phy_enabled = false;
>  }
> @@ -1827,23 +1855,29 @@ static const struct dw_hdmi_phy_data dw_hdmi_phys[] = 
> {
>   {
>   .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
>   .name = "DWC HDMI TX PHY",
> + .gen = 1,
>   }, {
>   .type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
>   .name = "DWC MHL PHY + HEAC PHY",
> + .gen = 2,
>   .has_svsret = true,
>   }, {
>   .type = DW_HDMI_PHY_DWC_MHL_PHY,
>   .name = "DWC MHL PHY",
> + .gen = 2,
>   .has_svsret = true,
>   }, {
>   .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
>   .name = "DWC HDMI 3D TX PHY + HEAC PHY",
> + .gen = 2,
>   }, {
>   .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
>   .name = "DWC HDMI 3D TX PHY",
> + .gen = 2,
>   }, {
>   .type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
>

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 16:21:33 +0100
Markus Heiser  escreveu:

> Am 02.03.2017 um 16:11 schrieb Daniel Vetter :
> 
> > On Thu, Mar 02, 2017 at 03:58:36PM +0100, Markus Heiser wrote:  
> >> Hi Daniel, Laurent
> >> 
> >> Am 02.03.2017 um 15:14 schrieb Laurent Pinchart 
> >> :
> >>   
> >>> Hi Daniel,
> >>> 
> >>> On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:  
>  On Thu, Mar 2, 2017 at 1:26 PM, Laurent Pinchart wrote:  
> > Hi Daniel,
> > 
> > Thank you for the patch.
> > 
> > With this applied, I get
> > 
> > make[1]: Entering directory '/home/laurent/src/iob/renesas/linux64'
> > 
> > SPHINX  htmldocs -->
> > file:///home/laurent/src/iob/renesas/linux64/Documentation/output PARSE
> >   include/uapi/linux/videodev2.h
> > 
> > Running Sphinx v1.3.1
> > 
> > Extension error:
> > Could not import extension kfigure (exception: cannot import name 
> > patches)
> > make[2]: ***
> > [/home/laurent/src/iob/renesas/linux/Documentation/Makefile.sphinx:70:
> > htmldocs] Error 1 make[1]: ***
> > [/home/laurent/src/iob/renesas/linux/Makefile:1453: htmldocs] Error 2
> > make[1]: Leaving directory '/home/laurent/src/iob/renesas/linux64' make:
> > *** [Makefile:152: sub-make] Error 2
> > 
> > sphinx.directive.patches got introduced in Sphinx 1.4. If you want to 
> > bump
> > the minimum required version I think a notice is needed.  
>  
>  Ugh. But this also goes completely over my head, no idea whether we
>  must require sphinx 1.4 (it was released Mar 28, 2016), or whether
>  there's some way to work around this ... Halp?  
> >>> 
> >>> I'm not a Sphinx expert so I don't know, but what I can tell is that 
> >>> copying 
> >>> the patches.py from Sphinx 1.4 to Documentation/sphinx/ and modifying 
> >>> kfigure.py to import it from there fixes the build. There's thus no extra 
> >>> depencency on Sphinx 1.4 (or newer).
> >>> 
> >>> I'm not sure we want to set a precedent by copying part of the Sphinx 
> >>> source 
> >>> code to the kernel tree (or inlining the single small function that the 
> >>> module 
> >>> provides), and I'll let someone more knowledgeable than me decide how to 
> >>> proceed.  
> >> 
> >> 
> >> Aargh ... we need virtualenv! For interim something like the following
> >> might help. In file Documentation/sphinx/kfigure.py edit the imports
> >> 
> >> ...
> >> from docutils.parsers.rst.directives import images
> >> try:
> >>from sphinx.directives.patches import Figure
> >> except ImportError:
> >>Figure = images.Figure 
> >> ...
> >> 
> >> And fix the class definition, so it use 'Figure' and no
> >> longer 'patch.Figure'::
> >> 
> >> ...
> >> -class KernelFigure(patches.Figure):
> >> +class KernelFigure(Figure):
> >> ...
> >> 
> >> Sorry that I have not yet the time to send you a decent and tested
> >> patch. Do you like to test my suggestion? / thanks!  
> > 
> > I'll give it a shot at implementing it, but I can't (easily at least) test
> > on sphinx 1.3.  
> 
> You can test it with virtualenv  
> https://virtualenv.pypa.io/en/stable/userguide/
> 
> In short:
> 
> $ cd kernel-src
> $ virtualenv myenv
> $ source myenv/bin/activate
> $ pip install 'Sphinx==1.3.1'
> $ make 

Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
virtualenv is broken:

writing output... [ 16%] media/intro
Exception occurred:
  File 
"/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
 line 671, in depart_document
assert not self.context, 'len(context) = %s' % len(self.context)
AssertionError: len(context) = 1
The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you want to 
report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
make[1]: *** [htmldocs] Error 1
Makefile:1450: recipe for target 'htmldocs' failed
make: *** [htmldocs] Error 2

Perhaps it is time for us to move minimal requirements to 1.4?

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

Re: [PATCH] drm/atmel-hlcdc: Rework the fbdev creation logic

[Richard Genoud]

On 28/11/2016 16:01, Boris Brezillon wrote:
> Now that we wait for DRM panels to be available before registering the
> DRM device (returning -EPROBE_DEFER if the panel has not been probed
> yet), we no longer need to put the fbdev creation code in
> ->output_poll_changed().
> 
> This removes the 10 secs delay between DRM dev registration and fbdev
> creation (polling period = 10 seconds).
> 
> Signed-off-by: Boris Brezillon 
> Reported-by: Alex Vazquez 
Tested-by: Richard Genoud 

Those 10 seconds where a real pain !
Any reason this has not been applied ?

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 5f484310bee9..2325de7c5c6f 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -431,15 +431,8 @@ static void atmel_hlcdc_fb_output_poll_changed(struct 
> drm_device *dev)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
>  
> - if (dc->fbdev) {
> + if (dc->fbdev)
>   drm_fbdev_cma_hotplug_event(dc->fbdev);
> - } else {
> - dc->fbdev = drm_fbdev_cma_init(dev, 24,
> - dev->mode_config.num_crtc,
> - dev->mode_config.num_connector);
> - if (IS_ERR(dc->fbdev))
> - dc->fbdev = NULL;
> - }
>  }
>  
>  struct atmel_hlcdc_dc_commit {
> @@ -652,10 +645,13 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>  
>   platform_set_drvdata(pdev, dev);
>  
> - drm_kms_helper_poll_init(dev);
> + dc->fbdev = drm_fbdev_cma_init(dev, 24,
> + dev->mode_config.num_crtc,
> + dev->mode_config.num_connector);
> + if (IS_ERR(dc->fbdev))
> + dc->fbdev = NULL;
>  
> - /* force connectors detection */
> - drm_helper_hpd_irq_event(dev);
> + drm_kms_helper_poll_init(dev);
>  
>   return 0;
>  
> 

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

Re: [PATCH v4 23/23] drm/rockchip: dw-mipi-dsi: add reset control

[Brian Norris]

+ devicetree

Hi,

On Fri, Feb 24, 2017 at 12:55:06PM +, John Keeping wrote:
> In order to fully reset the state of the MIPI controller we must assert
> this reset.
> 
> This is slightly more complicated than it could be in order to maintain
> compatibility with device trees that do not specify the reset property.
> 
> Signed-off-by: John Keeping 
> Reviewed-by: Chris Zhong 
> ---
> v4:
> - Fix error check for devm_reset_control_get() to use ENOENT
> v3:
> - Add Chris' Reviewed-by
> Unchanged in v2
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 0c4bae711e84..30da75667334 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1144,6 +1145,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   of_match_device(dw_mipi_dsi_dt_ids, dev);
>   const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
>   struct platform_device *pdev = to_platform_device(dev);
> + struct reset_control *apb_rst;
>   struct drm_device *drm = data;
>   struct dw_mipi_dsi *dsi;
>   struct resource *res;
> @@ -1182,6 +1184,35 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> + /*
> +  * Note that the reset was not defined in the initial device tree, so
> +  * we have to be prepared for it not being found.
> +  */
> + apb_rst = devm_reset_control_get(dev, "apb");

Did this reset ever get documented in the device tree bindings? I
couldn't find it. Perhaps a follow-up patch is in order?

[...]

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

Re: [PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Jose Abreu]

Hi Laurent,


On 02-03-2017 13:41, Laurent Pinchart wrote:
>
>> Hmm, this is kind of confusing. Why do you need a phy_ops and
>> then a separate configure_phy function? Can't we just use phy_ops
>> always? If its external phy then it would need to implement all
>> phy_ops functions.
> The phy_ops are indeed meant to support vendor PHYs. The .configure_phy() 
> operation is meant to support Synopsys PHYs that don't comply with the HDMI 
> TX 
> MHL and 3D PHYs I2C register layout and thus need a different configure 
> function, but can share the other operations with the HDMI TX MHL and 3D 
> PHYs. 
> Ideally I'd like to move that code to the dw-hdmi core, but at the moment I 
> don't have enough information to decide whether the register layout 
> corresponds to the standard Synopsys HDMI TX 2.0 PHY or if it has been 
> modified by the vendor. Once we'll have a second SoC using the same PHY we 
> should have more information to consolidate the code. Of course, if you can 
> share the HDMI TX 2.0 PHY datasheet, I won't mind reworking the code now ;-)
>

Well, if I want to keep my job I can't share the datasheet, and I
do want to keep my job :)

As far as I know this shouldn't change much. I already used (it
was like a year ago) the dw-hdmi driver in a HDMI TX 2.0 PHY. But
I am not following your logic here, sorry: You are mentioning a
custom phy, right? If its custom then it should implement its own
phy_ops. And I don't think that phy logic should go into core,
this should all be extracted because I really believe it will
make the code easier to read. Imagine this organization:

Folders/Files:
drm/bridge/dw-hdmi/dw-hdmi-core.c
drm/bridge/dw-hdmi/dw-hdmi-phy-synopsys.c
drm/bridge/dw-hdmi/dw-hdmi-phy-*renesas*.c
drm/bridge/dw-hdmi/dw-hdmi-phy-something.c
Structures:
dw_hdmi_pdata
dw_hdmi_phy_pdata
dw_hdmi_phy_ops

As the phy is interacted using controller we would need to pass
some callbacks to the phy, but ultimately the phy would be a
platform driver which could have its own compatible string that
would be associated with controller (not sure exactly about this
because I only used this in non-dt).

This is just an idea though. I followed this logic in the RX side
and its very easy to add a new phy now, its a matter of creating
a new file, implement ops and associate it with controller. Of
course some phys will be very similar, for that we can use minor
tweaks via id detection.

What do you think?

Best regards,
Jose Miguel Abreu

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 20:06:39 +0100
Markus Heiser  escreveu:

> Hi Mauro,
> 
> > Tested here with the enclosed patch.  
> 
> great, big step forward making /media/Makefile smaller ...  thanks a lot
> 
> > It crashed:
> > Exception occurred:
> >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> > dot2format
> >sys.stderr.write(err)
> > TypeError: write() argument must be str, not bytes
> > The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> > want to report the issue to the developers.
> > Please also report this if it was a user error, so that a better error 
> > message can be provided next time.
> > A bug report can be filed in the tracker at 
> > . Thanks!
> > Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> > make[1]: *** [htmldocs] Error 1
> > Makefile:1450: recipe for target 'htmldocs' failed
> > make: *** [htmldocs] Error 2
> > 
> > Weird enough, it produced a 
> > Documentation/output/media/uapi/v4l/pipeline.svg file.  
> 
> I guess that the dot command writes something to stderr. This is captured 
> by the extension and printed to stderr ...
> 
> +def dot2format(dot_fname, out_fname):
> ...
> +exit_code = 42
> +with open(out_fname, "w") as out:
> +p = subprocess.Popen(
> +cmd, stdout = out, stderr = subprocess.PIPE )
> +nil, err = p.communicate()
> +
> +sys.stderr.write(err)
> +
> +exit_code = p.returncode
> +out.flush()
> +return bool(exit_code == 0)
> 
> >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> > dot2format
> >sys.stderr.write(err)
> > TypeError: write() argument must be str, not bytes  
> 
> Do we need this stderr output? For a first test, uncomment the 
> "sys.stderr.write(err)“ in line 222. Or, if we really need the
> stderr, try:
> 
> -sys.stderr.write(err)
> +sys.stderr.write(str(err))

Yes, this fixed. I actually did:

-sys.stderr.write(err)
+sys.stderr.write(str(err))
+sys.stderr.write("\n")

It is now printing:
b''

I added the \n print to avoid it to be mixed with the "writing output"
prints.

No idea how to make sense from it - but clearly, the error report
logic require some care ;-)

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

[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

[Alexey Brodkin]

Since we cannot always generate exactly requested pixel clock
there's not much sense in checking requested_clock == clk_round_rate().
In that case for quite some modes we'll be getting -EINVAL and no video
output at all.

But given there's some tolerance to real pixel clock in TVs/monitors
we may still give it a try with the clock as close to requested one as
PLL on the board may generate. So we just do a fixup to what current
board may provide.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jose Abreu 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..3f2823c1efc3 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
+static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = >adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
 
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
+   adjusted_mode->clock =
+   clk_round_rate(arcpgu->clk, mode->clock * 1000) / 1000;
 
-   return 0;
+   return true;
 }
 
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -165,8 +163,8 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
+   .mode_fixup = arc_pgu_crtc_mode_fixup,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
-- 
2.7.4

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 12:45:32 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu, 2 Mar 2017 16:21:33 +0100
> Markus Heiser  escreveu:
> 
> > Am 02.03.2017 um 16:11 schrieb Daniel Vetter :
> >   
> > > On Thu, Mar 02, 2017 at 03:58:36PM +0100, Markus Heiser wrote:
> > >> Hi Daniel, Laurent
> > >> 
> > >> Am 02.03.2017 um 15:14 schrieb Laurent Pinchart 
> > >> :
> > >> 
> > >>> Hi Daniel,
> > >>> 
> > >>> On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:
> >  On Thu, Mar 2, 2017 at 1:26 PM, Laurent Pinchart wrote:
> > > Hi Daniel,
> > > 
> > > Thank you for the patch.
> > > 
> > > With this applied, I get
> > > 
> > > make[1]: Entering directory '/home/laurent/src/iob/renesas/linux64'
> > > 
> > > SPHINX  htmldocs -->
> > > file:///home/laurent/src/iob/renesas/linux64/Documentation/output 
> > > PARSE
> > >   include/uapi/linux/videodev2.h
> > > 
> > > Running Sphinx v1.3.1
> > > 
> > > Extension error:
> > > Could not import extension kfigure (exception: cannot import name 
> > > patches)
> > > make[2]: ***
> > > [/home/laurent/src/iob/renesas/linux/Documentation/Makefile.sphinx:70:
> > > htmldocs] Error 1 make[1]: ***
> > > [/home/laurent/src/iob/renesas/linux/Makefile:1453: htmldocs] Error 2
> > > make[1]: Leaving directory '/home/laurent/src/iob/renesas/linux64' 
> > > make:
> > > *** [Makefile:152: sub-make] Error 2
> > > 
> > > sphinx.directive.patches got introduced in Sphinx 1.4. If you want to 
> > > bump
> > > the minimum required version I think a notice is needed.
> >  
> >  Ugh. But this also goes completely over my head, no idea whether we
> >  must require sphinx 1.4 (it was released Mar 28, 2016), or whether
> >  there's some way to work around this ... Halp?
> > >>> 
> > >>> I'm not a Sphinx expert so I don't know, but what I can tell is that 
> > >>> copying 
> > >>> the patches.py from Sphinx 1.4 to Documentation/sphinx/ and modifying 
> > >>> kfigure.py to import it from there fixes the build. There's thus no 
> > >>> extra 
> > >>> depencency on Sphinx 1.4 (or newer).
> > >>> 
> > >>> I'm not sure we want to set a precedent by copying part of the Sphinx 
> > >>> source 
> > >>> code to the kernel tree (or inlining the single small function that the 
> > >>> module 
> > >>> provides), and I'll let someone more knowledgeable than me decide how 
> > >>> to 
> > >>> proceed.
> > >> 
> > >> 
> > >> Aargh ... we need virtualenv! For interim something like the following
> > >> might help. In file Documentation/sphinx/kfigure.py edit the imports
> > >> 
> > >> ...
> > >> from docutils.parsers.rst.directives import images
> > >> try:
> > >>from sphinx.directives.patches import Figure
> > >> except ImportError:
> > >>Figure = images.Figure 
> > >> ...
> > >> 
> > >> And fix the class definition, so it use 'Figure' and no
> > >> longer 'patch.Figure'::
> > >> 
> > >> ...
> > >> -class KernelFigure(patches.Figure):
> > >> +class KernelFigure(Figure):
> > >> ...
> > >> 
> > >> Sorry that I have not yet the time to send you a decent and tested
> > >> patch. Do you like to test my suggestion? / thanks!
> > > 
> > > I'll give it a shot at implementing it, but I can't (easily at least) test
> > > on sphinx 1.3.
> > 
> > You can test it with virtualenv  
> > https://virtualenv.pypa.io/en/stable/userguide/
> > 
> > In short:
> > 
> > $ cd kernel-src
> > $ virtualenv myenv
> > $ source myenv/bin/activate
> > $ pip install 'Sphinx==1.3.1'
> > $ make   
> 
> Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
> virtualenv is broken:
> 
> writing output... [ 16%] media/intro  
>   
> Exception occurred:
>   File 
> "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>  line 671, in depart_document
> assert not self.context, 'len(context) = %s' % len(self.context)
> AssertionError: len(context) = 1
> The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you want 
> to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> make[1]: *** [htmldocs] Error 1
> Makefile:1450: recipe for target 'htmldocs' failed
> make: *** [htmldocs] Error 2
> 
> Perhaps it is time for us to move minimal requirements to 1.4?

Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
with 1.5.2 (for htmldocs).

Thanks,
Mauro

-

This is the error log with 1.4:

# Sphinx version: 1.4.9
# Python version: 2.7.13 (CPython)
# Docutils version: 0.13.1 release
# 

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 18:36:31 -0300
Mauro Carvalho Chehab  escreveu:

> > Found another issue on the patch. The HTML output is pointing to the
> > wrong place: instead of using a relative patch, it is keeping 
> > an absolute one.
> > 
> > This is what it produced from Documentation/media/uapi/v4l/dev-subdev.rst:
> > 
> > 
> >  > src="/d00/kernel/Documentation/output/media/uapi/v4l/pipeline.svg" /> > class="caption">Image Format Negotiation on 
> > Pipelines
> > 
> > High quality and high speed pipeline configuration
> > 
> > 
> > There, the "src=" is pointing to the full patch, with doesn't work, as
> > my html server uses a different patch to find the file. It should,
> > instead, use a patch relative to the place where the html file is
> > stored, e. g. in this case, either:
> > ./pipeline.svg
> > or just:
> > pipeline.svg  
> 
> Btw, PDF conversion is also not working:
> 
> 
>   File "/d00/kernel/Documentation/sphinx/kfigure.py", line 241, in svg2pdf
> cmd = [convert_cmd, svg_fname, pdf_fname]
> 
>   NameError: name 'convert_cmd' is not defined
> 
> And including SVG files for HTML output also seems to be problematic.

Forgot to mention, but I'm using here Sphinx 1.4.9, installed via
pip3 (So, python3).

> 
> I'll post the RFCv2 patch that I'm using to test it.

Patch posted. Hopefully, it will help you to see the problems I'm 
facing on my tests.

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

[PATCH RFC v2] docs-rst: Don't use explicit Makefile rules to build SVG and DOT files

[Mauro Carvalho Chehab]

Now that we have an extension to handle images, use it.

Signed-off-by: Mauro Carvalho Chehab 
---

This patch is based on Daniel Vetter & Markus Heiser's work to support
PNG and SVG via kpicture Sphinx extension:

 [PATCH] docs-rst: automatically convert Graphviz and SVG images

v2: Don't use :caption:, as it doesn't exist on kernel-figure.

Unfortunately, this patch showed severl issues at the original patch.
I'm still sending it, as it could help testing the issues there.

 Documentation/media/Makefile   | 47 +-
 Documentation/media/intro.rst  |  6 +--
 Documentation/media/uapi/dvb/intro.rst |  6 +--
 Documentation/media/uapi/v4l/crop.rst  |  4 +-
 Documentation/media/uapi/v4l/dev-raw-vbi.rst   | 20 +
 Documentation/media/uapi/v4l/dev-subdev.rst| 22 +-
 Documentation/media/uapi/v4l/field-order.rst   | 12 --
 Documentation/media/uapi/v4l/pixfmt-nv12mt.rst |  8 ++--
 Documentation/media/uapi/v4l/selection-api-003.rst |  6 +--
 Documentation/media/uapi/v4l/subdev-formats.rst|  4 +-
 10 files changed, 46 insertions(+), 89 deletions(-)

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 32663602ff25..5bd52ea1eff0 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -1,51 +1,6 @@
-# Rules to convert DOT and SVG to Sphinx images
-
-SRC_DIR=$(srctree)/Documentation/media
-
-DOTS = \
-   uapi/v4l/pipeline.dot \
-
-IMAGES = \
-   typical_media_device.svg \
-   uapi/dvb/dvbstb.svg \
-   uapi/v4l/bayer.svg \
-   uapi/v4l/constraints.svg \
-   uapi/v4l/crop.svg \
-   uapi/v4l/fieldseq_bt.svg \
-   uapi/v4l/fieldseq_tb.svg \
-   uapi/v4l/nv12mt.svg \
-   uapi/v4l/nv12mt_example.svg \
-   uapi/v4l/pipeline.svg \
-   uapi/v4l/selection.svg \
-   uapi/v4l/subdev-image-processing-full.svg \
-   uapi/v4l/subdev-image-processing-scaling-multi-source.svg \
-   uapi/v4l/subdev-image-processing-crop.svg \
-   uapi/v4l/vbi_525.svg \
-   uapi/v4l/vbi_625.svg \
-   uapi/v4l/vbi_hsync.svg \
-
-DOTTGT := $(patsubst %.dot,%.svg,$(DOTS))
-IMGDOT := $(patsubst %,$(SRC_DIR)/%,$(DOTTGT))
-
-IMGTGT := $(patsubst %.svg,%.pdf,$(IMAGES))
-IMGPDF := $(patsubst %,$(SRC_DIR)/%,$(IMGTGT))
-
-cmd = $(echo-cmd) $(cmd_$(1))
-
-quiet_cmd_genpdf = GENPDF  $2
-  cmd_genpdf = convert $2 $3
-
-quiet_cmd_gendot = DOT $2
-  cmd_gendot = dot -Tsvg $2 > $3
-
-%.pdf: %.svg
-   @$(call cmd,genpdf,$<,$@)
-
-%.svg: %.dot
-   @$(call cmd,gendot,$<,$@)
-
 # Rules to convert a .h file to inline RST documentation
 
+SRC_DIR=$(srctree)/Documentation/media
 PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
 UAPI = $(srctree)/include/uapi/linux
 KAPI = $(srctree)/include/linux
diff --git a/Documentation/media/intro.rst b/Documentation/media/intro.rst
index 8f7490c9a8ef..9ce2e23a0236 100644
--- a/Documentation/media/intro.rst
+++ b/Documentation/media/intro.rst
@@ -13,9 +13,9 @@ A typical media device hardware is shown at 
:ref:`typical_media_device`.
 
 .. _typical_media_device:
 
-.. figure::  typical_media_device.*
-:alt:typical_media_device.pdf / typical_media_device.svg
-:align:  center
+.. kernel-figure:: typical_media_device.svg
+:alt:   typical_media_device.svg
+:align: center
 
 Typical Media Device
 
diff --git a/Documentation/media/uapi/dvb/intro.rst 
b/Documentation/media/uapi/dvb/intro.rst
index 2ed5c23102b4..652c4aacd2c6 100644
--- a/Documentation/media/uapi/dvb/intro.rst
+++ b/Documentation/media/uapi/dvb/intro.rst
@@ -55,9 +55,9 @@ Overview
 
 .. _stb_components:
 
-.. figure::  dvbstb.*
-:alt:dvbstb.pdf / dvbstb.svg
-:align:  center
+.. kernel-figure:: dvbstb.svg
+:alt:   dvbstb.svg
+:align: center
 
 Components of a DVB card/STB
 
diff --git a/Documentation/media/uapi/v4l/crop.rst 
b/Documentation/media/uapi/v4l/crop.rst
index be58894c9c89..182565b9ace4 100644
--- a/Documentation/media/uapi/v4l/crop.rst
+++ b/Documentation/media/uapi/v4l/crop.rst
@@ -53,8 +53,8 @@ Cropping Structures
 
 .. _crop-scale:
 
-.. figure::  crop.*
-:alt:crop.pdf / crop.svg
+.. kernel-figure:: crop.svg
+:alt:crop.svg
 :align:  center
 
 Image Cropping, Insertion and Scaling
diff --git a/Documentation/media/uapi/v4l/dev-raw-vbi.rst 
b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
index baf5f2483927..9fcc18dfe3d1 100644
--- a/Documentation/media/uapi/v4l/dev-raw-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
@@ -221,33 +221,31 @@ and always returns default parameters as 
:ref:`VIDIOC_G_FMT ` does
 
 .. _vbi-hsync:
 
-.. figure::  vbi_hsync.*
-:alt:vbi_hsync.pdf / vbi_hsync.svg
-:align:  center
+.. kernel-figure:: vbi_hsync.svg
+:alt:   vbi_hsync.svg
+:align: center
 
 **Figure 4.1. Line synchronization**
 
 
 .. _vbi-525:
 
-.. figure::  vbi_525.*
-:alt:

Re: [PATCH] drm/atmel-hlcdc: Rework the fbdev creation logic

[Richard Genoud]

2017-03-02 17:25 GMT+01:00 Boris Brezillon :
> On Thu, 2 Mar 2017 17:04:51 +0100
> Richard Genoud  wrote:
>
>> On 28/11/2016 16:01, Boris Brezillon wrote:
>> > Now that we wait for DRM panels to be available before registering the
>> > DRM device (returning -EPROBE_DEFER if the panel has not been probed
>> > yet), we no longer need to put the fbdev creation code in
>> > ->output_poll_changed().
>> >
>> > This removes the 10 secs delay between DRM dev registration and fbdev
>> > creation (polling period = 10 seconds).
>> >
>> > Signed-off-by: Boris Brezillon 
>> > Reported-by: Alex Vazquez 
>> Tested-by: Richard Genoud 
>>
>> Those 10 seconds where a real pain !
>> Any reason this has not been applied ?
>
> It should show up in 4.11 (it's already in Linus' tree [1] ;-)).
>
> Regards,
>
> Boris
>
> [1]https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/atmel-hlcdc?id=db02b7614a54bf0bf548db07bc8d3e7518fd9481
Great !

Thanks !

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 20:52:59 +0100
Daniel Vetter  escreveu:

> On Thu, Mar 02, 2017 at 08:06:39PM +0100, Markus Heiser wrote:
> > Hi Mauro,
> >   
> > > Tested here with the enclosed patch.  
> > 
> > great, big step forward making /media/Makefile smaller ...  thanks a lot
> >   
> > > It crashed:
> > > Exception occurred:
> > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > in dot2format
> > >sys.stderr.write(err)
> > > TypeError: write() argument must be str, not bytes
> > > The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> > > want to report the issue to the developers.
> > > Please also report this if it was a user error, so that a better error 
> > > message can be provided next time.
> > > A bug report can be filed in the tracker at 
> > > . Thanks!
> > > Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> > > make[1]: *** [htmldocs] Error 1
> > > Makefile:1450: recipe for target 'htmldocs' failed
> > > make: *** [htmldocs] Error 2
> > > 
> > > Weird enough, it produced a 
> > > Documentation/output/media/uapi/v4l/pipeline.svg file.  
> > 
> > I guess that the dot command writes something to stderr. This is captured 
> > by the extension and printed to stderr ...
> > 
> > +def dot2format(dot_fname, out_fname):
> > ...
> > +exit_code = 42
> > +with open(out_fname, "w") as out:
> > +p = subprocess.Popen(
> > +cmd, stdout = out, stderr = subprocess.PIPE )
> > +nil, err = p.communicate()
> > +
> > +sys.stderr.write(err)
> > +
> > +exit_code = p.returncode
> > +out.flush()
> > +return bool(exit_code == 0)
> >   
> > >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, 
> > > in dot2format
> > >sys.stderr.write(err)
> > > TypeError: write() argument must be str, not bytes  
> > 
> > Do we need this stderr output? For a first test, uncomment the 
> > "sys.stderr.write(err)“ in line 222. Or, if we really need the
> > stderr, try:
> > 
> > -sys.stderr.write(err)
> > +sys.stderr.write(str(err))
> > 
> > I this fixes, there is another "sys.stderr.write(err)" in 
> > func svg2pdf(..) which should also fixed ….
> >  
> > +def svg2pdf(svg_fname, pdf_fname):
> > ...
> > +cmd = [convert_cmd, svg_fname, pdf_fname]
> > +p = subprocess.Popen(
> > +cmd, stdout = out, stderr = subprocess.PIPE )
> > +nil, err = p.communicate()
> > +
> > -sys.stderr.write(err)
> > +sys.stderr.write(str(err))
> > +
> > +exit_code = p.returncode
> > +return bool(exit_code == 0)  
> 
> Yes, I very much want stderr to be forward.

Yes, error report is required.

> Without that you don't see
> error output from dot or convert, and that makes it impossible to debug
> anything. If I want a direct forwarding of the bytes, how should I do this
> in python? Capturing stderr and then re-dumping it is kinda silly ...

Markus or some other Python programmer may help us with that.

> Note that I copied this pattern from the kernel-doc extension, seems to
> have worked there.

Maybe it is broken there too then, or this is another python API
that changed over time. Here, I'm testing with:
python3-3.5.2-4.fc25.x86_64

From here:
https://docs.python.org/2/library/subprocess.html

communicate returns a tuple.

I used repr(p.communicate()[0], on the code snippet I sent, 
as I copied from an example that I found at:

https://stackoverflow.com/questions/33295284/python-subprocess-popen-write-to-stderr

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu,  2 Mar 2017 16:40:02 +0100
Daniel Vetter  escreveu:

> From: Markus Heiser 
> 
> This patch brings scalable figure, image handling and a concept to
> embed *render* markups:
> 
> * DOT (http://www.graphviz.org)
> * SVG
> 
> For image handling use the 'image' replacement::
> 
> .. kernel-image::  svg_image.svg
>:alt:simple SVG image
> 
> For figure handling use the 'figure' replacement::
> 
> .. kernel-figure::  svg_image.svg
>:alt:simple SVG image
> 
>SVG image example
> 
> Embed *render* markups (or languages) like Graphviz's **DOT** is
> provided by the *render* directive.::
> 
>   .. kernel-render:: DOT
>  :alt: foobar digraph
>  :caption: Embedded **DOT** (Graphviz) code.
> 
>  digraph foo {
>   "bar" -> "baz";
>  }
> 
> The *render* directive is a concept to integrate *render* markups and
> languages, yet supported markups:
> 
> * DOT: render embedded Graphviz's **DOT**
> * SVG: render embedded Scalable Vector Graphics (**SVG**)
> 
> v2: s/DOC/DOT/ in a few places (by Daniel).
> 
> v3: Simplify stuff a bit (by Daniel):
> 
> - Remove path detection and setup/check code for that. In
>   Documentation/media/Makefile we already simply use these tools,
>   better to have one consolidated check if we want/need one. Also
>   remove the convertsvg support, we require ImageMagick's convert
>   already in the doc build, no need for a 2nd fallback.
> 
> - Use sphinx for depency tracking, remove hand-rolled version.
> 
> - Forward stderr from dot and convert, otherwise debugging issues with
>   the diagrams is impossible.
> 
> v4: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
> untested.
> 
> v5: Use an explicit version check (suggested by Laurent).

Tested here with the enclosed patch. It crashed:


Exception occurred:
  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
dot2format
sys.stderr.write(err)
TypeError: write() argument must be str, not bytes
The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you want 
to report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
make[1]: *** [htmldocs] Error 1
Makefile:1450: recipe for target 'htmldocs' failed
make: *** [htmldocs] Error 2

Weird enough, it produced a Documentation/output/media/uapi/v4l/pipeline.svg 
file.

Full trace:

Traceback (most recent call last):
  File 
"/home/mchehab/.local/lib/python3.5/site-packages/sphinx/util/parallel.py", 
line 73, in _process
ret = func(arg)
  File 
"/home/mchehab/.local/lib/python3.5/site-packages/sphinx/builders/__init__.py", 
line 380, in write_process
self.write_doc(docname, doctree)
  File 
"/home/mchehab/.local/lib/python3.5/site-packages/sphinx/builders/html.py", 
line 448, in write_doc
self.docwriter.write(doctree, destination)
  File 
"/home/mchehab/.local/lib/python3.5/site-packages/docutils/writers/__init__.py",
 line 80, in write
self.translate()
  File 
"/home/mchehab/.local/lib/python3.5/site-packages/sphinx/writers/html.py", line 
47, in translate
self.document.walkabout(visitor)
  File "/home/mchehab/.local/lib/python3.5/site-packages/docutils/nodes.py", 
line 174, in walkabout
if child.walkabout(visitor):
  File "/home/mchehab/.local/lib/python3.5/site-packages/docutils/nodes.py", 
line 174, in walkabout
if child.walkabout(visitor):
  File "/home/mchehab/.local/lib/python3.5/site-packages/docutils/nodes.py", 
line 174, in walkabout
if child.walkabout(visitor):
  File "/home/mchehab/.local/lib/python3.5/site-packages/docutils/nodes.py", 
line 166, in walkabout
visitor.dispatch_visit(self)
  File "/home/mchehab/.local/lib/python3.5/site-packages/docutils/nodes.py", 
line 1882, in dispatch_visit
return method(node)
  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 302, in 
visit_kernel_figure
convert_image(img_node, self)
  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 193, in 
convert_image
dot2format(src_fname, dst_fname)
  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
dot2format
sys.stderr.write(err)
TypeError: write() argument must be str, not bytes


Thanks,
Mauro

--

[PATCH] docs-rst: Don't use explicit Makefile rules to build SVG and
 DOT files

Now that we have an extension to handle images, use it.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 32663602ff25..5bd52ea1eff0 100644
--- a/Documentation/media/Makefile
+++ 

Re: [PATCH v4 2/9] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> The color space converter isn't part of the PHY, move its configuration
> out of PHY code.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
>  1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index ce7496399ccf..906583beb08b 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -914,7 +914,7 @@ static void dw_hdmi_phy_sel_interface_control(struct 
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
>  
> -static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
> +static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>  {
>   u8 val, msec;
>   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> @@ -946,14 +946,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
> cscon)
>   return -EINVAL;
>   }
>  
> - /* Enable csc path */
> - if (cscon)
> - val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
> - else
> - val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
> -
> - hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
> -
>   /* gen2 tx power off */
>   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>  
> @@ -1028,10 +1020,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
> int cscon)
>  static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>  {
>   int i, ret;
> - bool cscon;
> -
> - /*check csc whether needed activated in HDMI mode */
> - cscon = hdmi->sink_is_hdmi && is_color_space_conversion(hdmi);
>  
>   /* HDMI Phy spec says to do the phy initialization sequence twice */
>   for (i = 0; i < 2; i++) {
> @@ -1040,8 +1028,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
>   dw_hdmi_phy_enable_tmds(hdmi, 0);
>   dw_hdmi_phy_enable_powerdown(hdmi, true);
>  
> - /* Enable CSC */
> - ret = hdmi_phy_configure(hdmi, cscon);
> + ret = hdmi_phy_configure(hdmi);
>   if (ret)
>   return ret;
>   }
> @@ -1303,6 +1290,14 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
> *hdmi)
>   clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
>   hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
>   }
> +
> + /* Enable color space conversion if needed (for HDMI sinks only). */
> + if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
> + hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
> + HDMI_MC_FLOWCTRL);
> + else
> + hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS,
> + HDMI_MC_FLOWCTRL);
>  }
>  
>  static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 21:16:05 +0100
Markus Heiser  escreveu:

> > Am 02.03.2017 um 20:09 schrieb Mauro Carvalho Chehab 
> > :  

> I leaved a comment at sphinx-doc project:
> 
>   https://github.com/sphinx-doc/sphinx/issues/3212#issuecomment-283756374

Thanks!

> > Maybe one way would be to have a sort of "prepare" script that
> > would be network-dependent, and will install whatever needed to
> > build the docs. If called, make *docs will use the virtualenv.
> > Otherwise, it would print a warning message saying that the doc
> > build is not reliable, but would try to use whatever installed
> > on the machine.  
> 
> Could be a workaround. May Jon has continuative ideas, nothing
> we have to solve today ... give Jon some time.

Sure.

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 22:16:49 +0100
Markus Heiser  escreveu:

> > Am 02.03.2017 um 20:34 schrieb Mauro Carvalho Chehab 
> > :
> > 
> > Em Thu, 2 Mar 2017 20:06:39 +0100
> > Markus Heiser  escreveu:
> >   
> >> Hi Mauro,
> >>   
> >>> Tested here with the enclosed patch.
> >> 
> >> great, big step forward making /media/Makefile smaller ...  thanks a 
> >> lot
> >>   
> >>> It crashed:
> >>> Exception occurred:
> >>> File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> >>> dot2format
> >>>   sys.stderr.write(err)
> >>> TypeError: write() argument must be str, not bytes
> >>> The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> >>> want to report the issue to the developers.
> >>> Please also report this if it was a user error, so that a better error 
> >>> message can be provided next time.
> >>> A bug report can be filed in the tracker at 
> >>> . Thanks!
> >>> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> >>> make[1]: *** [htmldocs] Error 1
> >>> Makefile:1450: recipe for target 'htmldocs' failed
> >>> make: *** [htmldocs] Error 2
> >>> 
> >>> Weird enough, it produced a 
> >>> Documentation/output/media/uapi/v4l/pipeline.svg file.
> >> 
> >> I guess that the dot command writes something to stderr. This is captured 
> >> by the extension and printed to stderr ...
> >> 
> >> +def dot2format(dot_fname, out_fname):
> >> ...
> >> +exit_code = 42
> >> +with open(out_fname, "w") as out:
> >> +p = subprocess.Popen(
> >> +cmd, stdout = out, stderr = subprocess.PIPE )
> >> +nil, err = p.communicate()
> >> +
> >> +sys.stderr.write(err)
> >> +
> >> +exit_code = p.returncode
> >> +out.flush()
> >> +return bool(exit_code == 0)
> >>   
> >>> File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> >>> dot2format
> >>>   sys.stderr.write(err)
> >>> TypeError: write() argument must be str, not bytes
> >> 
> >> Do we need this stderr output? For a first test, uncomment the 
> >> "sys.stderr.write(err)“ in line 222. Or, if we really need the
> >> stderr, try:
> >> 
> >> -sys.stderr.write(err)
> >> +sys.stderr.write(str(err))  
> > 
> > Yes, this fixed. I actually did:
> > 
> > -sys.stderr.write(err)
> > +sys.stderr.write(str(err))
> > +sys.stderr.write("\n")
> > 
> > It is now printing:
> > b''
> > 
> > I added the \n print to avoid it to be mixed with the "writing output"
> > prints.
> > No idea how to make sense from it - but clearly, the error report
> > logic require some care ;-)  
> 
> 
> Aargh, I’am a idiot ... I guess 'sys.stderr.write(err)‘ is a artefact
> of my development, simply drop it and the subprocess.PIPE of stderr
> also.
> 
> +with open(out_fname, "w") as out:
> +p = subprocess.Popen(
> -cmd, stdout = out, stderr = subprocess.PIPE )
> +cmd, stdout = out)
> +nil, err = p.communicate()
> -
> -sys.stderr.write(err)
> -
> +exit_code = p.returncode
> +out.flush()
> +return bool(exit_code == 0)
> 
> I can’t test it ATM, but without redirect stderr, the stderr
> of the parent process is inherited.
> 
>   https://docs.python.org/3.6/library/subprocess.html#popen-constructor
> 
> The Popen.communicate() always returns a tuple (stdout_data, stderr_data)
> with above the tuple is always (None, None).
> 
>   
> https://docs.python.org/3.6/library/subprocess.html#subprocess.Popen.communicate
> 
>   """to get anything other than None in the result tuple,
>  you need to give stdout=PIPE and/or stderr=PIPE too."""
> 
> Sorry, that I made all this mistakes, but „here“ I have only mail
> and web, no dev-env and I miss my emacs  ;) 
> 
> If the suggestion above does not work, I have to investigate
> more time next weekend.

Hmm... I would be more verbose on output the error code, printing from
where the error came, e. g. printing a message like:

Error #0 when calling dot for 
'/devel/v4l/patchwork/Documentation/media/uapi/v4l/pipeline.dot': None  


As on this patch:

diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py
index 32eab0f4cfba..a366a89f4f98 100644
--- a/Documentation/sphinx/kfigure.py
+++ b/Documentation/sphinx/kfigure.py
@@ -217,11 +217,13 @@ def dot2format(dot_fname, out_fname):
 with open(out_fname, "w") as out:
 p = subprocess.Popen(
 cmd, stdout = out, stderr = subprocess.PIPE )
-nil, err = p.communicate()
-
-sys.stderr.write(err)
+err = p.communicate()
 
 exit_code = p.returncode
+
+if exit_code != 0:
+sys.stderr.write("Error #%d when calling dot for '%s': %s\n" % 
(exit_code, dot_fname, repr(err[0])))
+
 

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

[Archit Taneja]

Hi Peter,

On 3/1/2017 4:08 PM, Peter Senna Tschudin wrote:

Hi Archit,

Thank you for the review!

On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:



On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:

The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Cc: David Airlie 
Cc: Thierry Reding 
Cc: Thierry Reding 
Cc: Archit Taneja 
Cc: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
Changes from V1:
 - Updated copyright year
 - Fixed blank line issues
 - Updated ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid and
   added a comment to explain the test.
 - Fixed checkpatch strict warnings about continuation lines. In one case
   fixing the warning would cause the continuation line to be over 80 chars and
   that strict warning remains.

 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 411 +
 3 files changed, 423 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..4a937f1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.

+config DRM_MEGACHIPS_STDP_GE_B850V3_FW
+   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridges of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver. You are likely to say N here.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..af0b7cc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
new file mode 100644
index 000..6f82a44
--- /dev/null
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -0,0 +1,411 @@
+/*
+ * Driver for MegaChips STDP4028 with GE B850v3 firmware (LVDS-DP)
+ * Driver for MegaChips STDP2690 with GE B850v3 firmware (DP-DP++)
+
+ * Copyright (c) 2017, Collabora Ltd.
+ * Copyright (c) 2017, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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.
+
+ * You 

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 18:29:39 -0300
Mauro Carvalho Chehab  escreveu:

> Em Thu,  2 Mar 2017 16:40:02 +0100
> Daniel Vetter  escreveu:
> 
> > From: Markus Heiser 
> > 
> > This patch brings scalable figure, image handling and a concept to
> > embed *render* markups:
> > 
> > * DOT (http://www.graphviz.org)
> > * SVG
> > 
> > For image handling use the 'image' replacement::
> > 
> > .. kernel-image::  svg_image.svg
> >:alt:simple SVG image
> > 
> > For figure handling use the 'figure' replacement::
> > 
> > .. kernel-figure::  svg_image.svg
> >:alt:simple SVG image
> > 
> >SVG image example
> > 
> > Embed *render* markups (or languages) like Graphviz's **DOT** is
> > provided by the *render* directive.::
> > 
> >   .. kernel-render:: DOT
> >  :alt: foobar digraph
> >  :caption: Embedded **DOT** (Graphviz) code.
> > 
> >  digraph foo {
> >   "bar" -> "baz";
> >  }
> > 
> > The *render* directive is a concept to integrate *render* markups and
> > languages, yet supported markups:
> > 
> > * DOT: render embedded Graphviz's **DOT**
> > * SVG: render embedded Scalable Vector Graphics (**SVG**)
> > 
> > v2: s/DOC/DOT/ in a few places (by Daniel).
> > 
> > v3: Simplify stuff a bit (by Daniel):
> > 
> > - Remove path detection and setup/check code for that. In
> >   Documentation/media/Makefile we already simply use these tools,
> >   better to have one consolidated check if we want/need one. Also
> >   remove the convertsvg support, we require ImageMagick's convert
> >   already in the doc build, no need for a 2nd fallback.
> > 
> > - Use sphinx for depency tracking, remove hand-rolled version.
> > 
> > - Forward stderr from dot and convert, otherwise debugging issues with
> >   the diagrams is impossible.
> > 
> > v4: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> > Implement Markus suggestion for backwards compatability with earlier
> > releases. Laurent reported this, running sphinx 1.3. Solution entirely
> > untested.
> > 
> > v5: Use an explicit version check (suggested by Laurent).  
> 
> Found another issue on the patch. The HTML output is pointing to the
> wrong place: instead of using a relative patch, it is keeping 
> an absolute one.
> 
> This is what it produced from Documentation/media/uapi/v4l/dev-subdev.rst:
> 
> 
>  src="/d00/kernel/Documentation/output/media/uapi/v4l/pipeline.svg" /> class="caption">Image Format Negotiation on 
> Pipelines
> 
> High quality and high speed pipeline configuration
> 
> 
> There, the "src=" is pointing to the full patch, with doesn't work, as
> my html server uses a different patch to find the file. It should,
> instead, use a patch relative to the place where the html file is
> stored, e. g. in this case, either:
>   ./pipeline.svg
> or just:
>   pipeline.svg

Btw, PDF conversion is also not working:


  File "/d00/kernel/Documentation/sphinx/kfigure.py", line 241, in svg2pdf
cmd = [convert_cmd, svg_fname, pdf_fname]

NameError: name 'convert_cmd' is not defined

And including SVG files for HTML output also seems to be problematic.

I'll post the RFCv2 patch that I'm using to test it.

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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

IRC acked by Harry Wentland


" dhnkrn, the patch for driver-private atomic state object
makes sense to me.  Didn't realize that's the same one from early
February. Feel free to add my Acked-by"


-DK
On Wed, 2017-02-08 at 22:38 -0800, Dhinakaran Pandiyan wrote:
> It is necessary to track states for objects other than connector, crtc
> and plane for atomic modesets. But adding objects like DP MST link
> bandwidth to drm_atomic_state would mean that a non-core object will be
> modified by the core helper functions for swapping and clearing
> it's state. So, lets add void * objects and helper functions that operate
> on void * types to keep these objects and states private to the core.
> Drivers can then implement specific functions to swap and clear states.
> The other advantage having just void * for these objects in
> drm_atomic_state is that objects of different types can be managed in the
> same state array.
> 
> v2: Added docs and new iterator to filter private objects (Daniel)
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_atomic.c| 68 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
>  include/drm/drm_atomic.h| 91 
> +
>  3 files changed, 164 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..1a9ffe8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> drm_atomic_state *state)
>   kfree(state->connectors);
>   kfree(state->crtcs);
>   kfree(state->planes);
> + kfree(state->private_objs);
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_release);
>  
> @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   state->planes[i].ptr = NULL;
>   state->planes[i].state = NULL;
>   }
> +
> + for (i = 0; i < state->num_private_objs; i++) {
> + void *private_obj = state->private_objs[i].obj;
> + void *obj_state = state->private_objs[i].obj_state;
> +
> + if (!private_obj)
> + continue;
> +
> + state->private_objs[i].funcs->destroy_state(obj_state);
> + state->private_objs[i].obj = NULL;
> + state->private_objs[i].obj_state = NULL;
> + state->private_objs[i].funcs = NULL;
> + }
> +
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>  
> @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> drm_printer *p,
>  }
>  
>  /**
> + * drm_atomic_get_private_obj_state - get private object state
> + * @state: global atomic state
> + * @obj: private object to get the state for
> + * @funcs: pointer to the struct of function pointers that identify the 
> object
> + * type
> + *
> + * This function returns the private object state for the given private 
> object,
> + * allocating the state if needed. It does not grab any locks as the caller 
> is
> + * expected to care of any required locking.
> + *
> + * RETURNS:
> + *
> + * Either the allocated state or the error code encoded into a pointer.
> + */
> +void *
> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> +   const struct drm_private_state_funcs *funcs)
> +{
> + int index, num_objs, i;
> + size_t size;
> + struct __drm_private_objs_state *arr;
> +
> + for (i = 0; i < state->num_private_objs; i++)
> + if (obj == state->private_objs[i].obj &&
> + state->private_objs[i].obj_state)
> + return state->private_objs[i].obj_state;
> +
> + num_objs = state->num_private_objs + 1;
> + size = sizeof(*state->private_objs) * num_objs;
> + arr = krealloc(state->private_objs, size, GFP_KERNEL);
> + if (!arr)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs = arr;
> + index = state->num_private_objs;
> + memset(>private_objs[index], 0, sizeof(*state->private_objs));
> +
> + state->private_objs[index].obj_state = funcs->duplicate_state(state, 
> obj);
> + if (!state->private_objs[index].obj_state)
> + return ERR_PTR(-ENOMEM);
> +
> + state->private_objs[index].obj = obj;
> + state->private_objs[index].funcs = funcs;
> + state->num_private_objs = num_objs;
> +
> + DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
> +  state->private_objs[index].obj_state, state);
> +
> + return state->private_objs[index].obj_state;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
> +
> +/**
>   * drm_atomic_get_connector_state - get connector state
>   * @state: global atomic state object
>   * @connector: connector to get state object for
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> 

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 16:53:04 +0100
Daniel Vetter  escreveu:

> On Thu, Mar 2, 2017 at 4:22 PM, Jonathan Corbet  wrote:
> > On Thu, 2 Mar 2017 16:11:08 +0100
> > Daniel Vetter  wrote:
> >  
> >> I'll give it a shot at implementing it, but I can't (easily at least) test
> >> on sphinx 1.3.  
> >
> > Virtualenv makes that kind of thing pretty easy to do.  Maybe we should
> > add a script to create and populate a suitable venv for this kind of
> > thing.  
> 
> Laurent quickly checked v5 of this patch, looks all good now.
> 
> > Meanwhile, I've been seeing only parts 1 and 2 of what's clearly a bigger
> > series.  Do you want me to carry just these two?  
> 
> I submitted the entire series to both linux-doc and dri-devel. 

Sure you sent to linux-doc? I'm not seeing it there.

I'm not seeing it at the mirrors neither:
https://marc.info/?l=linux-doc=1=201703=2
https://www.spinics.net/lists/linux-doc/maillist.html

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Mauro Carvalho Chehab]

Em Thu, 2 Mar 2017 19:16:47 +0100
Markus Heiser  escreveu:

> > Am 02.03.2017 um 17:29 schrieb Mauro Carvalho Chehab 
> > :
> > 
> > Em Thu, 2 Mar 2017 17:13:25 +0100
> > Markus Heiser  escreveu:
> >   
> >>> Am 02.03.2017 um 16:49 schrieb Mauro Carvalho Chehab 
> >>> :
> >>>   
> > You can test it with virtualenv  
> > https://virtualenv.pypa.io/en/stable/userguide/
> > 
> > In short:
> > 
> > $ cd kernel-src
> > $ virtualenv myenv
> > $ source myenv/bin/activate
> > $ pip install 'Sphinx==1.3.1'
> > $ make   
>  
>  Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
>  virtualenv is broken:
>  
>  writing output... [ 16%] media/intro 
> 
>  Exception occurred:
>  File 
>  "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>   line 671, in depart_document
>    assert not self.context, 'len(context) = %s' % len(self.context)
>  AssertionError: len(context) = 1
>  The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you 
>  want to report the issue to the developers.
>  Please also report this if it was a user error, so that a better error 
>  message can be provided next time.
>  A bug report can be filed in the tracker at 
>  . Thanks!
>  Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
>  make[1]: *** [htmldocs] Error 1
>  Makefile:1450: recipe for target 'htmldocs' failed
>  make: *** [htmldocs] Error 2
>  
>  Perhaps it is time for us to move minimal requirements to 1.4?
> >>> 
> >>> Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
> >>> with 1.5.2 (for htmldocs).
> >>> 
> >>> Thanks,
> >>> Mauro
> >>> 
> >>> -
> >>> 
> >>> This is the error log with 1.4:
> >>> 
> >>> # Sphinx version: 1.4.9
> >>   
> >>> File 
> >>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
> >>>  line 187, in walkabout
> >>>   visitor.dispatch_departure(self)
> >>> File 
> >>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
> >>>  line 1895, in dispatch_departure
> >>>   return method(node)
> >>> File 
> >>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
> >>>  line 671, in depart_document
> >>>   assert not self.context, 'len(context) = %s' % len(self.context)
> >>> AssertionError: len(context) = 1
> >> 
> >> I guess this is a error from newer docutils, so we have to fix docutils 
> >> version also.
> >> 
> >> Sphinx itself specifies "docutils>=0.11"
> >> 
> >>  https://github.com/sphinx-doc/sphinx/blob/1.3.1/setup.py#L52
> >> 
> >> So I guess it uses a up to date docutils or the ducutils which are already 
> >> installed system wide.  
> > 
> > The system-wide docutils is this one:
> > 
> > python2-docutils-0.13.1-3.fc25.noarch
> > python3-docutils-0.13.1-3.fc25.noarch  
> 
> Sorry my mistake, in the traceback we see
> 
> File 
> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>  line 671, in depart_document
>   assert not self.context, 'len(context) = %s' % len(self.context)
> 
> ... which means: system wide installation does not matter.
> 
> > Btw, I tested also with virtualenv-3/pip3 and the same issue happens there.
> > 
> > Manually installing version 0.11 makes it to work again.  
> 
> Yes, its only about "docutils>=0.11" in Sphinx 1.3 dependencies. 
> In Sphinx 1.5 the error:
> 
>   https://github.com/sphinx-doc/sphinx/issues/3212
> 
> is fixed:
> 
>   
> https://github.com/tk0miya/sphinx/commit/73663f63672f22304810ce6bb9787490ad250127
> 
> But this will never be fixed downwards.

Crap. This kind of patch should be backported to Sphinx 1.3/1.4,
or Python's PIP repository should be fixed to require docutils
version to be either 0.11 or 0.12, if one installs version 1.3
or 1.4 of Sphinx.

The way it is, PIP repository is broken!

> All this is about semantic versioning. If you want to promise your
> builds, you have to name which versions of dependencies you support.
> I guess this is nothing new for kernel developers ;)

No. At the Kernel, we do everything possible to not break APIs.

If this were not the case, you wouldn't be able to run Sphinx 1.5 
with legacy Kernel versions ;-)

> The problem is, that PEP440 defines not only ONE version scheme
> 
>  """Some hard to read version identifiers are permitted by
> this scheme in order to better accommodate the wide range
> of versioning practices across existing public and private
> Python projects."""
> 
> In practice, the python projects use slightly different schemes
> which not follow one rule like .. 
> From history packaging in 

[PATCH RFC] docs-rst: Don't use explicit Makefile rules to build SVG and DOT files

[Mauro Carvalho Chehab]

Now that we have an extension to handle images, use it.

Signed-off-by: Mauro Carvalho Chehab 
---

This patch is based on Daniel Vetter & Markus Heiser's work to support
PNG and SVG via kpicture Sphinx extension.

PS.: With this RFC patch, I'm getting now some extra warnings:

/devel/v4l/patchwork/Documentation/media/intro.rst:12: WARNING: undefined 
label: typical_media_device (if the link has no caption the label must precede 
a section header)
/devel/v4l/patchwork/Documentation/media/uapi/dvb/intro.rst:95: WARNING: 
undefined label: stb_components (if the link has no caption the label must 
precede a section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/crop.rst:65: WARNING: 
undefined label: vbi-hsync (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-raw-vbi.rst:118: WARNING: 
undefined label: vbi-hsync (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-raw-vbi.rst:138: WARNING: 
undefined label: vbi-525 (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-raw-vbi.rst:138: WARNING: 
undefined label: vbi-625 (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-raw-vbi.rst:298: WARNING: 
undefined label: vbi-525 (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-raw-vbi.rst:298: WARNING: 
undefined label: vbi-625 (if the link has no caption the label must precede a 
section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-subdev.rst:93: WARNING: 
undefined label: pipeline-scaling (if the link has no caption the label must 
precede a section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/dev-subdev.rst:199: WARNING: 
undefined label: pipeline-scaling (if the link has no caption the label must 
precede a section header)
/devel/v4l/patchwork/Documentation/media/uapi/v4l/subdev-formats.rst:1483: 
WARNING: undefined label: bayer-patterns (if the link has no caption the label 
must precede a section header)



 Documentation/media/Makefile   | 47 +-
 Documentation/media/intro.rst  |  9 ++---
 Documentation/media/uapi/dvb/intro.rst |  9 ++---
 Documentation/media/uapi/v4l/crop.rst  |  9 ++---
 Documentation/media/uapi/v4l/dev-raw-vbi.rst   | 25 +---
 Documentation/media/uapi/v4l/dev-subdev.rst| 34 +++-
 Documentation/media/uapi/v4l/field-order.rst   | 14 ---
 Documentation/media/uapi/v4l/pixfmt-nv12mt.rst | 18 -
 Documentation/media/uapi/v4l/selection-api-003.rst |  7 ++--
 Documentation/media/uapi/v4l/subdev-formats.rst|  9 ++---
 10 files changed, 61 insertions(+), 120 deletions(-)

diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
index 32663602ff25..5bd52ea1eff0 100644
--- a/Documentation/media/Makefile
+++ b/Documentation/media/Makefile
@@ -1,51 +1,6 @@
-# Rules to convert DOT and SVG to Sphinx images
-
-SRC_DIR=$(srctree)/Documentation/media
-
-DOTS = \
-   uapi/v4l/pipeline.dot \
-
-IMAGES = \
-   typical_media_device.svg \
-   uapi/dvb/dvbstb.svg \
-   uapi/v4l/bayer.svg \
-   uapi/v4l/constraints.svg \
-   uapi/v4l/crop.svg \
-   uapi/v4l/fieldseq_bt.svg \
-   uapi/v4l/fieldseq_tb.svg \
-   uapi/v4l/nv12mt.svg \
-   uapi/v4l/nv12mt_example.svg \
-   uapi/v4l/pipeline.svg \
-   uapi/v4l/selection.svg \
-   uapi/v4l/subdev-image-processing-full.svg \
-   uapi/v4l/subdev-image-processing-scaling-multi-source.svg \
-   uapi/v4l/subdev-image-processing-crop.svg \
-   uapi/v4l/vbi_525.svg \
-   uapi/v4l/vbi_625.svg \
-   uapi/v4l/vbi_hsync.svg \
-
-DOTTGT := $(patsubst %.dot,%.svg,$(DOTS))
-IMGDOT := $(patsubst %,$(SRC_DIR)/%,$(DOTTGT))
-
-IMGTGT := $(patsubst %.svg,%.pdf,$(IMAGES))
-IMGPDF := $(patsubst %,$(SRC_DIR)/%,$(IMGTGT))
-
-cmd = $(echo-cmd) $(cmd_$(1))
-
-quiet_cmd_genpdf = GENPDF  $2
-  cmd_genpdf = convert $2 $3
-
-quiet_cmd_gendot = DOT $2
-  cmd_gendot = dot -Tsvg $2 > $3
-
-%.pdf: %.svg
-   @$(call cmd,genpdf,$<,$@)
-
-%.svg: %.dot
-   @$(call cmd,gendot,$<,$@)
-
 # Rules to convert a .h file to inline RST documentation
 
+SRC_DIR=$(srctree)/Documentation/media
 PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
 UAPI = $(srctree)/include/uapi/linux
 KAPI = $(srctree)/include/linux
diff --git a/Documentation/media/intro.rst b/Documentation/media/intro.rst
index 8f7490c9a8ef..3c0c218c6d08 100644
--- a/Documentation/media/intro.rst
+++ b/Documentation/media/intro.rst
@@ -13,11 +13,10 @@ A typical media device hardware is shown at 
:ref:`typical_media_device`.
 
 .. _typical_media_device:
 
-.. figure::  

Re: [PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> From: Kieran Bingham 
>
> The DWC HDMI TX controller interfaces with a companion PHY. While
> Synopsys provides multiple standard PHYs, SoC vendors can also integrate
> a custom PHY.
>
> Modularize PHY configuration to support vendor PHYs through platform
> data. The existing PHY configuration code was originally written to
> support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC
> MLP PHY. The HDMI 2.0 PHY will require a separate configuration
> function.
>
> Signed-off-by: Kieran Bingham 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
>
> - Check pdata->phy_configure in hdmi_phy_configure() to avoid
>   dereferencing NULL pointer.
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 109 
> ++-
>  include/drm/bridge/dw_hdmi.h |   7 +++
>  2 files changed, 81 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index cb2703862be2..b835d81bb471 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -118,6 +118,9 @@ struct dw_hdmi_phy_data {
>   const char *name;
>   unsigned int gen;
>   bool has_svsret;
> + int (*configure)(struct dw_hdmi *hdmi,
> +  const struct dw_hdmi_plat_data *pdata,
> +  unsigned long mpixelclock);
>  };
>  
>  struct dw_hdmi {
> @@ -860,8 +863,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, 
> int msec)
>   return true;
>  }
>  
> -static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> -  unsigned char addr)
> +void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> +unsigned char addr)
>  {
>   hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
>   hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
> @@ -873,6 +876,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
> unsigned short data,
>   HDMI_PHY_I2CM_OPERATION_ADDR);
>   hdmi_phy_wait_i2c_done(hdmi, 1000);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>  
>  static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>  {
> @@ -993,37 +997,67 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>   return 0;
>  }
>  
> -static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> +/*
> + * PHY configuration function for the DWC HDMI 3D TX PHY. Based on the 
> available
> + * information the DWC MHL PHY has the same register layout and is thus also
> + * supported by this function.
> + */
> +static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
> + const struct dw_hdmi_plat_data *pdata,
> + unsigned long mpixelclock)
>  {
> - const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> - const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
>   const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
>  
>   /* PLL/MPLL Cfg - always match on final entry */
>   for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
>   break;
>  
>   for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
>   break;
>  
>   for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
>   break;
>  
>   if (mpll_config->mpixelclock == ~0UL ||
>   curr_ctrl->mpixelclock == ~0UL ||
> - phy_config->mpixelclock == ~0UL) {
> - dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + phy_config->mpixelclock == ~0UL)
>   return -EINVAL;
> - }
> +
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
> +   HDMI_3D_TX_PHY_CPCE_CTRL);
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
> +   HDMI_3D_TX_PHY_GMPCTRL);
> + dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
> +   HDMI_3D_TX_PHY_CURRCTRL);
> +
> + dw_hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
> + dw_hdmi_phy_i2c_write(hdmi, 

Re: [RESEND PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph

[Krzysztof Kozlowski]

On Thu, Mar 2, 2017 at 3:44 AM, Hoegeun Kwon  wrote:
> On 02/28/2017 06:58 PM, Krzysztof Kozlowski wrote:
>> Discussions in previous thread lead us to bisectability problem.
>> Bisectability in regular driver changes is one thing but in case of
>> driver + DTS the gap is much bigger. DTS will go through separate tree
>> and branches. How do you want to solve the problem?
>
>
> Sorry for the delay in reply, Mar 1st was the holiday.
> I thought of two solutions.
>
> 1. squash the patches in a single patch

No, for the same reason. DTS code/patches have to go through arm-soc
DTS branch without mixing with any driver changes. Otherwise arm-soc
guys are angry.

> 2. split the dts related patches so that the first part adds the:
> +samsung,burst-clock-frequency = <51200>;
> +samsung,esc-clock-frequency = <1600>;
>
> and the second part at the end removes the 'port' node
> So it consists of 6 patches in total.

That's a solution. The remaining DTS patches would go in next release...

Another solution would be for this release cycle:
if (of_property_does_not_exist(node, "samsung,burst-clock-frequency") {
// Fallback to old parsing mode
node = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
if (!node) {
dev_err(dev, "no burst-clock-frequency nor
output port with endpoint specified\n");
return -EINVAL;
}
}
ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
 >burst_clk_rate);
...

...and in next release the DTS patches would go in. This would give
you also DTB backward compatibility. However still DTS could be
applied later, after driver changes gets into mainline.

Personally I would prefer your solution #2 (with separate DTS patch
adding new properties). Does it sound reasonable for Inki?

Thanks for looking into this problem.

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

Re: [PATCH v4 8/9] drm: bridge: dw-hdmi: Remove device type from platform data

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> From: Kieran Bingham 
>
> The device type isn't used anymore now that workarounds and PHY-specific
> operations are performed based on version information read at runtime.
> Remove it.
>
> Signed-off-by: Kieran Bingham 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
>  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 2 --
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
>  include/drm/bridge/dw_hdmi.h| 7 ---
>  4 files changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index b835d81bb471..132c00685796 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -127,7 +127,6 @@ struct dw_hdmi {
>   struct drm_connector connector;
>   struct drm_bridge bridge;
>  
> - enum dw_hdmi_devtype dev_type;
>   unsigned int version;
>  
>   struct platform_device *audio;
> @@ -2014,7 +2013,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
>  
>   hdmi->plat_data = plat_data;
>   hdmi->dev = dev;
> - hdmi->dev_type = plat_data->dev_type;
>   hdmi->sample_rate = 48000;
>   hdmi->disabled = true;
>   hdmi->rxsense = true;
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index f645275e6e63..f039641070ac 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -175,7 +175,6 @@ static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
>   .mpll_cfg   = imx_mpll_cfg,
>   .cur_ctr= imx_cur_ctr,
>   .phy_config = imx_phy_config,
> - .dev_type   = IMX6Q_HDMI,
>   .mode_valid = imx6q_hdmi_mode_valid,
>  };
>  
> @@ -183,7 +182,6 @@ static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
>   .mpll_cfg = imx_mpll_cfg,
>   .cur_ctr  = imx_cur_ctr,
>   .phy_config = imx_phy_config,
> - .dev_type = IMX6DL_HDMI,
>   .mode_valid = imx6dl_hdmi_mode_valid,
>  };
>  
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index a6d4a0236e8f..d53827413996 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -237,7 +237,6 @@ static const struct dw_hdmi_plat_data 
> rockchip_hdmi_drv_data = {
>   .mpll_cfg   = rockchip_mpll_cfg,
>   .cur_ctr= rockchip_cur_ctr,
>   .phy_config = rockchip_phy_config,
> - .dev_type   = RK3288_HDMI,
>  };
>  
>  static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index dd330259a3dc..545f04fae3b6 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -21,12 +21,6 @@ enum {
>   DW_HDMI_RES_MAX,
>  };
>  
> -enum dw_hdmi_devtype {
> - IMX6Q_HDMI,
> - IMX6DL_HDMI,
> - RK3288_HDMI,
> -};
> -
>  enum dw_hdmi_phy_type {
>   DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
>   DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
> @@ -65,7 +59,6 @@ struct dw_hdmi_phy_ops {
>  };
>  
>  struct dw_hdmi_plat_data {
> - enum dw_hdmi_devtype dev_type;
>   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
>  struct drm_display_mode *mode);
>  

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

Re: [PATCH v4 5/9] drm: bridge: dw-hdmi: Fix the PHY power up sequence

[Jose Abreu]

Hi Laurent,


On 01-03-2017 22:39, Laurent Pinchart wrote:
> When powering the PHY up we need to wait for the PLL to lock. This is
> done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
> (interrupt-based wait could be implemented as well but is likely
> overkill). The bit is asserted when the PLL locks, but the current code
> incorrectly waits for the bit to be deasserted. Fix it, and while at it,
> replace the udelay() with a sleep as the code never runs in
> non-sleepable context.
>
> To be consistent with the power down implementation move the poll loop
> to the power off function.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 65 
> +++-
>  1 file changed, 37 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 85348ba6bb1c..0aa3ad404f77 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -949,9 +949,44 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>   dw_hdmi_phy_gen2_pddq(hdmi, 1);
>  }
>  
> +static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
> +{
> + const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> + unsigned int i;
> + u8 val;
> +
> + if (phy->gen == 1) {
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
> +
> + /* Toggle TMDS enable. */
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_tmds(hdmi, 1);
> + return 0;
> + }
> +
> + dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> + dw_hdmi_phy_gen2_pddq(hdmi, 0);
> +
> + /* Wait for PHY PLL lock */
> + for (i = 0; i < 5; ++i) {
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + if (val)
> + break;
> +
> + usleep_range(1000, 2000);
> + }
> +
> + if (!val) {
> + dev_err(hdmi->dev, "PHY PLL failed to lock\n");
> + return -ETIMEDOUT;
> + }
> +
> + dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
> + return 0;
> +}
> +
>  static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>  {
> - u8 val, msec;
>   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
> @@ -1019,33 +1054,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
>  HDMI_3D_TX_PHY_CKCALCTRL);
>  
> - dw_hdmi_phy_enable_powerdown(hdmi, false);
> -
> - /* toggle TMDS enable */
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 1);
> -
> - /* gen2 tx power on */
> - dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> - dw_hdmi_phy_gen2_pddq(hdmi, 0);
> -
> - /* Wait for PHY PLL lock */
> - msec = 5;
> - do {
> - val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> - if (!val)
> - break;
> -
> - if (msec == 0) {
> - dev_err(hdmi->dev, "PHY PLL not locked\n");
> - return -ETIMEDOUT;
> - }
> -
> - udelay(1000);
> - msec--;
> - } while (1);
> -
> - return 0;
> + return dw_hdmi_phy_power_on(hdmi);
>  }
>  
>  static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)

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

[Bug 98520] System randomly crashes / freezes while playing certain games

[bugzilla-daemon]

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

--- Comment #36 from Filip  ---
Update:
Didn't have the time to test amdgpu-pro on KDE Neon, but freezes have been
reduced in frequency quite a bit starting with linux 4.9.4.

However,
(In reply to Ali Hakkı Demiral from comment #34)
> My problem is almost solved.
> The north bridge of my motherboard is unstable.
> i test rx480 on ubuntu zesty live image, no crash 5+ hours with other
> mainboard. mesa 13.0.2 
> https://community.amd.com/message/2775902#comment-2775902

Turns out I had the similar issue. P35 didn't like the RX460 for some reason,
which has been 100%* stable since I moved it to Gigabyte GA-880GA-UD3H about 20
days ago.

*Except that sometimes I get flickering when (HDMI) monitor wakes from sleep (
solved by switching to TTY and back ), but there were no freezes & nothing of
note in dmesg/xorg logs.

And, like I've mentioned in comment #21, that same P35 board has no issues with
HD6450 which it runs with now.

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

[PATCH 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

[Chris Zhong]

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.

Signed-off-by: Chris Zhong 
---

 .../bindings/display/panel/innolux,p079zca.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..c40c8e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,22 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   _dsi {
+   panel {
+   compatible = "innolux,p079zca";
+   reg = <0>;
+   power-supply = <...>;
+   backlight = <>;
+   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

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

[PATCH 2/2] drm/panel: add innolux,p079zca panel driver

[Chris Zhong]

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Chris Zhong 
---

 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 322 ++
 3 files changed, 334 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_INNOLUX_P079ZCA
+   tristate "Innolux P079ZCA panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..5d16705
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,322 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct innolux_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->enabled)
+   return 0;
+
+   if (innolux->backlight) {
+   innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight_update_status(innolux->backlight);
+   }
+
+   innolux->link->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+   err = mipi_dsi_dcs_set_display_off(innolux->link);
+   if (err < 0)
+   dev_err(panel->dev, "failed to set display off: %d\n", err);
+
+   innolux->enabled = false;
+
+   return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (!innolux->prepared)
+   return 0;
+
+   innolux->link->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+   if (err < 0)
+   dev_err(panel->dev, "failed to enter sleep mode: %d\n", err);
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+   msleep(120);
+
+   regulator_disable(innolux->supply);
+
+   innolux->prepared = false;
+
+   return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+   struct innolux_panel *innolux = to_innolux_panel(panel);
+   int err;
+
+   if (innolux->prepared)
+   return 0;
+
+   gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+   err = regulator_enable(innolux->supply);
+   if (err < 0)
+   return err;
+
+   usleep_range(16000, 17000);
+   gpiod_set_value_cansleep(innolux->enable_gpio, 1);
+   usleep_range(15000, 16000);
+
+   innolux->link->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
+   if (err < 0) {
+   dev_err(panel->dev, "failed to exit sleep mode: %d\n", err);
+   goto poweroff;
+   }
+
+   msleep(120);
+
+   

[Bug 73041] radeon: not responding, "atombios stuck in loop"

[bugzilla-daemon]

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

Bjorn Helgaas (bhelg...@google.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #14 from Bjorn Helgaas (bhelg...@google.com) ---
I'm closing this as obsolete.  If it still happens, please reopen with any
additional information you have.

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

Hi Daniel, hi Mauro,

I have to say, that I lost control over our thread ;)

> v3: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
> untested.

I have to come back to a more systematic work, this means;
I have to test this v3 and consider what Mauro and you 
already posted.

For this, give me some time. I will send a v4 patch this weekend.

Thanks for all for comments and hints.

 -- Markus --



> Am 02.03.2017 um 16:16 schrieb Daniel Vetter :
> 
> From: Markus Heiser 
> 
> This patch brings scalable figure, image handling and a concept to
> embed *render* markups:
> 
> * DOT (http://www.graphviz.org)
> * SVG
> 
> For image handling use the 'image' replacement::
> 
>.. kernel-image::  svg_image.svg
>   :alt:simple SVG image
> 
> For figure handling use the 'figure' replacement::
> 
>.. kernel-figure::  svg_image.svg
>   :alt:simple SVG image
> 
>   SVG image example
> 
> Embed *render* markups (or languages) like Graphviz's **DOT** is
> provided by the *render* directive.::
> 
>  .. kernel-render:: DOT
> :alt: foobar digraph
> :caption: Embedded **DOT** (Graphviz) code.
> 
> digraph foo {
>  "bar" -> "baz";
> }
> 
> The *render* directive is a concept to integrate *render* markups and
> languages, yet supported markups:
> 
> * DOT: render embedded Graphviz's **DOT**
> * SVG: render embedded Scalable Vector Graphics (**SVG**)
> 
> v2: s/DOC/DOT/ in a few places (by Daniel).
> 
> v3: Simplify stuff a bit (by Daniel):
> 
> - Remove path detection and setup/check code for that. In
>  Documentation/media/Makefile we already simply use these tools,
>  better to have one consolidated check if we want/need one. Also
>  remove the convertsvg support, we require ImageMagick's convert
>  already in the doc build, no need for a 2nd fallback.
> 
> - Use sphinx for depency tracking, remove hand-rolled version.
> 
> - Forward stderr from dot and convert, otherwise debugging issues with
>  the diagrams is impossible.
> 
> v3: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
> untested.
> 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Jani Nikula 
> Cc: Mauro Carvalho Chehab 
> Cc: Markus Heiser 
> Cc: Laurent Pinchart 
> Signed-off-by: Markus Heiser  (v1)
> Signed-off-by: Daniel Vetter 
> ---
> Documentation/conf.py |   2 +-
> Documentation/doc-guide/hello.dot |   3 +
> Documentation/doc-guide/sphinx.rst|  90 ++-
> Documentation/doc-guide/svg_image.svg |  10 +
> Documentation/process/changes.rst |   7 +-
> Documentation/sphinx/kfigure.py   | 444 ++
> 6 files changed, 550 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/doc-guide/hello.dot
> create mode 100644 Documentation/doc-guide/svg_image.svg
> create mode 100644 Documentation/sphinx/kfigure.py
> 
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index f6823cf01275..e3f537ce2935 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ from load_config import loadConfig
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
> 'kfigure']
> 
> # The name of the math extension changed on Sphinx 1.4
> if major == 1 and minor > 3:
> diff --git a/Documentation/doc-guide/hello.dot 
> b/Documentation/doc-guide/hello.dot
> new file mode 100644
> index ..504621dfc595
> --- /dev/null
> +++ b/Documentation/doc-guide/hello.dot
> @@ -0,0 +1,3 @@
> +graph G {
> +  Hello -- World
> +}
> diff --git a/Documentation/doc-guide/sphinx.rst 
> b/Documentation/doc-guide/sphinx.rst
> index 532d65b70500..b902744ce7dd 100644
> --- a/Documentation/doc-guide/sphinx.rst
> +++ b/Documentation/doc-guide/sphinx.rst
> @@ -34,8 +34,10 @@ format-specific subdirectories under 
> ``Documentation/output``.
> 
> To generate documentation, Sphinx (``sphinx-build``) must obviously be
> installed. For prettier HTML output, the Read the Docs Sphinx theme
> -(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is 
> also
> -needed. All of these are widely available and packaged in distributions.
> +(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
> +``XeLaTeX`` and CairoSVG 

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

>> Btw, PDF conversion is also not working:
>> 
>> 
>>  File "/d00/kernel/Documentation/sphinx/kfigure.py", line 241, in svg2pdf
>>cmd = [convert_cmd, svg_fname, pdf_fname]
>> 
>>  NameError: name 'convert_cmd' is not defined
>> 
>> And including SVG files for HTML output also seems to be problematic.
> 
> Forgot to mention, but I'm using here Sphinx 1.4.9, installed via
> pip3 (So, python3).

It seems, that Daniel drops some lines from my first RFC, I miss this lines:

+# setup conversion tools and sphinx extension
+# ---
+
+# Graphviz's dot(1) support
+dot_cmd = which('dot')
+
+# ImageMagick' convert(1) support
+convert_cmd = which('convert')

@Daniel: can you take a look at this / Thanks

-- Markus --

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

[RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps

[Laura Abbott]

Practiaclly speaking, most Ion heaps are either going to be available
all the time (system heaps) or found based off of the reserved-memory
node. Parse the CMA and reserved-memory nodes to assign the heaps.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Makefile|  2 +-
 drivers/staging/android/ion/ion_enumerate.c | 89 +
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/android/ion/ion_enumerate.c

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index eef022b..4ebf655 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o ion_enumerate.o
 obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
 obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
 obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
diff --git a/drivers/staging/android/ion/ion_enumerate.c 
b/drivers/staging/android/ion/ion_enumerate.c
new file mode 100644
index 000..21344c7
--- /dev/null
+++ b/drivers/staging/android/ion/ion_enumerate.c
@@ -0,0 +1,89 @@
+#include 
+#include 
+
+#include "ion.h"
+#include "ion_priv.h"
+
+static struct ion_device *internal_dev;
+static int heap_id = 2;
+
+static int ion_add_system_heap(void)
+{
+#ifdef CONFIG_ION_SYSTEM_HEAP
+   struct ion_platform_heap pheap;
+   struct ion_heap *heap;
+
+   pheap.type = ION_HEAP_TYPE_SYSTEM;
+   pheap.id = heap_id++;
+   pheap.name = "ion_system_heap";
+
+   heap = ion_heap_create();
+   if (!heap)
+   return -ENODEV;
+
+   ion_device_add_heap(internal_dev, heap);
+#endif
+   return 0;
+}
+
+static int ion_add_system_contig_heap(void)
+{
+#ifdef CONFIG_ION_SYSTEM_HEAP
+   struct ion_platform_heap pheap;
+   struct ion_heap *heap;
+
+   pheap.type = ION_HEAP_TYPE_SYSTEM_CONTIG;
+   pheap.id = heap_id++;
+   pheap.name = "ion_system_contig_heap";
+
+   heap = ion_heap_create();
+   if (!heap)
+   return -ENODEV;
+
+   ion_device_add_heap(internal_dev, heap);
+#endif
+   return 0;
+}
+
+#ifdef CONFIG_ION_CMA_HEAP
+int __ion_add_cma_heaps(struct cma *cma, void *data)
+{
+   struct ion_heap *heap;
+   struct ion_platform_heap pheap;
+
+   pheap.type = ION_HEAP_TYPE_DMA;
+   pheap.id = heap_id++;
+   pheap.name = cma_get_name(cma);
+   pheap.priv = cma;
+
+   heap = ion_heap_create();
+   if (!heap)
+   return -ENODEV;
+
+   ion_device_add_heap(internal_dev, heap);
+   return 0;
+}
+#endif
+
+
+static int ion_add_cma_heaps(void)
+{
+#ifdef CONFIG_ION_CMA_HEAP
+   cma_for_each_area(__ion_add_cma_heaps, NULL);
+#endif
+   return 0;
+}
+
+int ion_enumerate(void)
+{
+   internal_dev = ion_device_create(NULL);
+   if (IS_ERR(internal_dev))
+   return PTR_ERR(internal_dev);
+
+   ion_add_system_heap();
+   ion_add_system_contig_heap();
+
+   ion_add_cma_heaps();
+   return 0;
+}
+subsys_initcall(ion_enumerate);
-- 
2.7.4

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

[RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

[Laura Abbott]

Currently, all heaps are compiled in all the time. In switching to
a better platform model, let's allow these to be compiled out for good
measure.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Kconfig| 32 
 drivers/staging/android/ion/Makefile   |  8 +++--
 drivers/staging/android/ion/ion_priv.h | 53 --
 3 files changed, 87 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 0c91b2b..2e97990 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,3 +17,35 @@ config ION_TEST
  Choose this option to create a device that can be used to test the
  kernel and device side ION functions.
 
+config ION_SYSTEM_HEAP
+   bool "Ion system heap"
+   depends on ION
+   help
+ Choose this option to enable the Ion system heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+   bool "Ion carveout heap support"
+   depends on ION
+   help
+ Choose this option to enable carveout heaps with Ion. Carveout heaps
+ are backed by memory reserved from the system. Allocation times are
+ typically faster at the cost of memory not being used. Unless you
+ know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+   bool "Ion chunk heap support"
+   depends on ION
+   help
+  Choose this option to enable chunk heaps with Ion. This heap is
+ similar in function the carveout heap but memory is broken down
+ into smaller chunk sizes, typically corresponding to a TLB size.
+ Unless you know your system has these regions, you should say N here.
+
+config ION_CMA_HEAP
+   bool "Ion CMA heap support"
+   depends on ION && CMA
+   help
+ Choose this option to enable CMA heaps with Ion. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 9457090..eef022b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,8 @@
-obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o \
-   ion_page_pool.o ion_system_heap.o \
-   ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 obj-$(CONFIG_ION_TEST) += ion_test.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index b09bc7c..6eafe0d 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
  * heaps as appropriate.
  */
 
+
 struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
 void ion_heap_destroy(struct ion_heap *heap);
+
+#ifdef CONFIG_ION_SYSTEM_HEAP
 struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
 void ion_system_heap_destroy(struct ion_heap *heap);
-
 struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *heap);
 void ion_system_contig_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap * ion_system_heap_create(
+   struct ion_platform_heap *unused)
+{
+   return ERR_PTR(-ENODEV);
+}
+static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
+
+static inline struct ion_heap *ion_system_contig_heap_create(
+   struct ion_platform_heap *heap)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CARVEOUT_HEAP
 struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
 void ion_carveout_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap *ion_carveout_heap_create(
+   struct ion_platform_heap *heap_data)
+{
+   return ERR_PTR(-ENODEV);
+}
+static inline void ion_carveout_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CHUNK_HEAP
 struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
 void ion_chunk_heap_destroy(struct ion_heap *heap);
+#else
+static inline struct ion_heap *ion_chunk_heap_create(
+   struct ion_platform_heap *heap_data)
+{
+   return ERR_PTR(-ENODEV);
+}
+static inline void ion_chunk_heap_destroy(struct ion_heap *heap) { }
+
+#endif
+
+#ifdef CONFIG_ION_CMA_HEAP
 struct ion_heap 

[RFC PATCH 08/12] cma: Store a name in the cma structure

[Laura Abbott]

Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.

Signed-off-by: Laura Abbott 
---
 drivers/base/dma-contiguous.c |  5 +++--
 include/linux/cma.h   |  4 +++-
 mm/cma.c  | 11 +--
 mm/cma.h  |  1 +
 mm/cma_debug.c|  2 +-
 5 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1..4f638ab 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -165,7 +165,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size, 
phys_addr_t base,
 {
int ret;
 
-   ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed, res_cma);
+   ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed,
+   "reserved", res_cma);
if (ret)
return ret;
 
@@ -257,7 +258,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
 
-   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
if (err) {
pr_err("Reserved memory: unable to setup CMA region\n");
return err;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 6f0a91b..49f98ea 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -21,13 +21,15 @@ struct cma;
 extern unsigned long totalcma_pages;
 extern phys_addr_t cma_get_base(const struct cma *cma);
 extern unsigned long cma_get_size(const struct cma *cma);
+extern const char *cma_get_name(const struct cma *cma);
 
 extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
-   bool fixed, struct cma **res_cma);
+   bool fixed, const char *name, struct cma **res_cma);
 extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+   const char *name,
struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align);
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned 
int count);
diff --git a/mm/cma.c b/mm/cma.c
index 94b3460..4a93d2b 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -53,6 +53,11 @@ unsigned long cma_get_size(const struct cma *cma)
return cma->count << PAGE_SHIFT;
 }
 
+const char *cma_get_name(const struct cma *cma)
+{
+   return cma->name ? cma->name : "(undefined)";
+}
+
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
 int align_order)
 {
@@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
  */
 int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 unsigned int order_per_bit,
+const char *name,
 struct cma **res_cma)
 {
struct cma *cma;
@@ -201,6 +207,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
+   cma->name = name;
*res_cma = cma;
cma_area_count++;
totalcma_pages += (size / PAGE_SIZE);
@@ -229,7 +236,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
-   bool fixed, struct cma **res_cma)
+   bool fixed, const char *name, struct cma **res_cma)
 {
phys_addr_t memblock_end = memblock_end_of_DRAM();
phys_addr_t highmem_start;
@@ -335,7 +342,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
base = addr;
}
 
-   ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);
+   ret = cma_init_reserved_mem(base, size, order_per_bit, name, res_cma);
if (ret)
goto err;
 
diff --git a/mm/cma.h b/mm/cma.h
index 17c75a4..4986128 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -11,6 +11,7 @@ struct cma {
struct hlist_head mem_head;
spinlock_t mem_head_lock;
 #endif
+   const char *name;
 };
 
 extern struct cma cma_areas[MAX_CMA_AREAS];
diff --git a/mm/cma_debug.c b/mm/cma_debug.c
index f8e4b60..4742efd 100644
--- a/mm/cma_debug.c
+++ b/mm/cma_debug.c
@@ -167,7 +167,7 @@ static void cma_debugfs_add_one(struct cma *cma, int idx)
char 

[RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also avoids awkward
caching questions.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion_cma_heap.c | 97 --
 1 file changed, 26 insertions(+), 71 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..6838825 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include "ion.h"
 #include "ion_priv.h"
 
 struct ion_cma_heap {
struct ion_heap heap;
-   struct device *dev;
+   struct cma *cma;
 };
 
 #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
 
-struct ion_cma_buffer_info {
-   void *cpu_addr;
-   dma_addr_t handle;
-   struct sg_table *table;
-};
-
 
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
unsigned long flags)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
-   struct device *dev = cma_heap->dev;
-   struct ion_cma_buffer_info *info;
-
-   dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
-   if (buffer->flags & ION_FLAG_CACHED)
-   return -EINVAL;
+   struct sg_table *table;
+   struct page *pages;
+   int ret;
 
-   info = kzalloc(sizeof(*info), GFP_KERNEL);
-   if (!info)
+   pages = cma_alloc(cma_heap->cma, len, 0);
+   if (!pages)
return -ENOMEM;
 
-   info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
-   GFP_HIGHUSER | __GFP_ZERO);
-
-   if (!info->cpu_addr) {
-   dev_err(dev, "Fail to allocate buffer\n");
+   table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!table)
goto err;
-   }
 
-   info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
-   if (!info->table)
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret)
goto free_mem;
 
-   if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
-   len))
-   goto free_table;
-   /* keep this for memory release */
-   buffer->priv_virt = info;
-   buffer->sg_table = info->table;
-   dev_dbg(dev, "Allocate buffer %p\n", buffer);
+   sg_set_page(table->sgl, pages, len, 0);
+
+   buffer->priv_virt = pages;
+   buffer->sg_table = table;
return 0;
 
-free_table:
-   kfree(info->table);
 free_mem:
-   dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+   kfree(table);
 err:
-   kfree(info);
+   cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
 }
 
 static void ion_cma_free(struct ion_buffer *buffer)
 {
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
-   struct device *dev = cma_heap->dev;
-   struct ion_cma_buffer_info *info = buffer->priv_virt;
+   struct page *pages = buffer->priv_virt;
 
-   dev_dbg(dev, "Release buffer %p\n", buffer);
/* release memory */
-   dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
+   cma_release(cma_heap->cma, pages, buffer->size);
/* release sg table */
-   sg_free_table(info->table);
-   kfree(info->table);
-   kfree(info);
-}
-
-static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
-   struct vm_area_struct *vma)
-{
-   struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
-   struct device *dev = cma_heap->dev;
-   struct ion_cma_buffer_info *info = buffer->priv_virt;
-
-   return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
-buffer->size);
-}
-
-static void *ion_cma_map_kernel(struct ion_heap *heap,
-   struct ion_buffer *buffer)
-{
-   struct ion_cma_buffer_info *info = buffer->priv_virt;
-   /* kernel memory mapping has been done at allocation time */
-   return info->cpu_addr;
-}
-
-static void ion_cma_unmap_kernel(struct ion_heap *heap,
-struct ion_buffer *buffer)
-{
+   sg_free_table(buffer->sg_table);
+   kfree(buffer->sg_table);
 }
 
 static struct ion_heap_ops ion_cma_ops = {
.allocate = ion_cma_allocate,
.free = 

[RFC PATCH 09/12] cma: Introduce cma_for_each_area

[Laura Abbott]

Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.

Signed-off-by: Laura Abbott 
---
 include/linux/cma.h |  2 ++
 mm/cma.c| 14 ++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 49f98ea..b521e3c 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -33,4 +33,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align);
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned 
int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void 
*data);
 #endif
diff --git a/mm/cma.c b/mm/cma.c
index 4a93d2b..a430df0 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,3 +464,17 @@ bool cma_release(struct cma *cma, const struct page 
*pages, unsigned int count)
 
return true;
 }
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+   int i;
+
+   for (i = 0; i < cma_area_count; i++) {
+   int ret = it(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4

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

[RFC PATCH 05/12] staging: android: ion: Remove page faulting support

[Laura Abbott]

The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 117 --
 1 file changed, 117 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index a931b30..8eef1d7 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
 #include "ion_priv.h"
 #include "compat_ion.h"
 
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
-   return (buffer->flags & ION_FLAG_CACHED) &&
-   !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
 }
 
-static inline struct page *ion_buffer_page(struct page *page)
-{
-   return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
-   return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
-   *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
 /* this function should only be called while dev->lock is held */
 static void ion_buffer_add(struct ion_device *dev,
   struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   struct scatterlist *sg;
-   int i, j, k = 0;
-
-   buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
-   if (!buffer->pages) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   for_each_sg(table->sgl, sg, table->nents, i) {
-   struct page *page = sg_page(sg);
-
-   for (j = 0; j < sg->length / PAGE_SIZE; j++)
-   buffer->pages[k++] = page++;
-   }
-   }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
@@ -876,69 +831,6 @@ void ion_pages_sync_for_device(struct device *dev, struct 
page *page,
dma_sync_sg_for_device(dev, , 1, dir);
 }
 
-struct ion_vma_list {
-   struct list_head list;
-   struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>lock);
-   ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
-   BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
-   pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
-   ret = vm_insert_pfn(vma, vmf->address, pfn);
-   mutex_unlock(>lock);
-   if (ret)
-   return VM_FAULT_ERROR;
-
-   return VM_FAULT_NOPAGE;
-}
-
-static void ion_vm_open(struct vm_area_struct *vma)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   struct ion_vma_list *vma_list;
-
-   vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
-   if (!vma_list)
-   return;
-   vma_list->vma = vma;
-   mutex_lock(>lock);
-   list_add(_list->list, >vmas);
-   mutex_unlock(>lock);
-   pr_debug("%s: adding %p\n", __func__, vma);
-}
-
-static void ion_vm_close(struct vm_area_struct *vma)
-{
-   struct ion_buffer *buffer = vma->vm_private_data;
-   struct ion_vma_list *vma_list, *tmp;
-
-   pr_debug("%s\n", __func__);
-   mutex_lock(>lock);
-   list_for_each_entry_safe(vma_list, tmp, >vmas, list) {
-   if (vma_list->vma != vma)
-   continue;
-   list_del(_list->list);
-   kfree(vma_list);
-   pr_debug("%s: deleting %p\n", __func__, vma);
-   break;
-   }
-   mutex_unlock(>lock);
-}
-
-static const struct vm_operations_struct ion_vma_ops = {
-   .open = ion_vm_open,
-   .close = ion_vm_close,
-   .fault = ion_vm_fault,
-};
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -950,15 +842,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
-   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
-   VM_DONTDUMP;
-   vma->vm_private_data = buffer;
-   vma->vm_ops = _vma_ops;
-

[RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Laura Abbott]

Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 94a498e..ce4adac 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -799,6 +799,32 @@ static void ion_buffer_sync_for_device(struct ion_buffer 
*buffer,
   struct device *dev,
   enum dma_data_direction direction);
 
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+   struct sg_table *new_table;
+   int ret, i;
+   struct scatterlist *sg, *new_sg;
+
+   new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+   if (!new_table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+   if (ret) {
+   kfree(table);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   new_sg = new_table->sgl;
+   for_each_sg(table->sgl, sg, table->nents, i) {
+   memcpy(new_sg, sg, sizeof(*sg));
+   sg->dma_address = 0;
+   new_sg = sg_next(new_sg);
+   }
+
+   return new_table;
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
@@ -806,13 +832,15 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
 
ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
+   sg_free_table(table);
+   kfree(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-- 
2.7.4

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

[RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laura Abbott]

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  5 
 drivers/staging/android/ion/ion.c   | 40 -
 drivers/staging/android/ion/ion_carveout_heap.c |  6 
 drivers/staging/android/ion/ion_chunk_heap.c|  6 
 drivers/staging/android/ion/ion_page_pool.c |  3 --
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 6 files changed, 65 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..f820d77 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_SYNC:
-   {
-   ret = ion_sync_for_device(client, data.fd.fd);
-   break;
-   }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8eef1d7..c3c316f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
free_duped_table(table);
 }
 
-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-  size_t size, enum dma_data_direction dir)
-{
-   struct scatterlist sg;
-
-   sg_init_table(, 1);
-   sg_set_page(, page, size, 0);
-   /*
-* This is not correct - sg_dma_address needs a dma_addr_t that is valid
-* for the targeted device, but this works on the currently targeted
-* hardware.
-*/
-   sg_dma_address() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct 
ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);
 
-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_buffer *buffer;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   /* if this memory came from ion */
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not sync dmabuf from another exporter\n",
-  __func__);
-   dma_buf_put(dmabuf);
-   return -EINVAL;
-   }
-   buffer = dmabuf->priv;
-
-   dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-  buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-   dma_buf_put(dmabuf);
-   return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer 
*buffer)
 
ion_heap_buffer_zero(buffer);
 
-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, table->sgl, table->nents,
-  DMA_BIDIRECTIONAL);
-
ion_carveout_free(heap, paddr, buffer->size);
sg_free_table(table);
kfree(table);
@@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct 
ion_platform_heap *heap_data)
page = pfn_to_page(PFN_DOWN(heap_data->base));
size = heap_data->size;
 
-   ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
-
ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 8c41889..46e13f6 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -101,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer *buffer)
 
ion_heap_buffer_zero(buffer);
 
-   if (ion_buffer_cached(buffer))
-   dma_sync_sg_for_device(NULL, table->sgl, table->nents,
-  DMA_BIDIRECTIONAL);
-
for_each_sg(table->sgl, sg, table->nents, i) {
gen_pool_free(chunk_heap->pool, 

[RFC PATCH 07/12] staging: android: ion: Remove old platform support

[Laura Abbott]

Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/Kconfig|  35 
 drivers/staging/android/ion/Makefile   |   6 -
 drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
 drivers/staging/android/ion/hisilicon/Makefile |   1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
 drivers/staging/android/ion/ion_dummy_driver.c | 156 -
 drivers/staging/android/ion/ion_of.c   | 184 -
 drivers/staging/android/ion/ion_of.h   |  37 -
 drivers/staging/android/ion/tegra/Makefile |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |  80 -
 10 files changed, 618 deletions(-)
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index c8fb413..0c91b2b 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,38 +17,3 @@ config ION_TEST
  Choose this option to create a device that can be used to test the
  kernel and device side ION functions.
 
-config ION_DUMMY
-   bool "Dummy Ion driver"
-   depends on ION
-   help
- Provides a dummy ION driver that registers the
- /dev/ion device and some basic heaps. This can
- be used for testing the ION infrastructure if
- one doesn't have access to hardware drivers that
- use ION.
-
-config ION_TEGRA
-   tristate "Ion for Tegra"
-   depends on ARCH_TEGRA && ION
-   help
- Choose this option if you wish to use ion on an nVidia Tegra.
-
-config ION_HISI
-   tristate "Ion for Hisilicon"
-   depends on ARCH_HISI && ION
-   select ION_OF
-   help
- Choose this option if you wish to use ion on Hisilicon Platform.
-
-source "drivers/staging/android/ion/hisilicon/Kconfig"
-
-config ION_OF
-   bool "Devicetree support for Ion"
-   depends on ION && OF_ADDRESS
-   help
- Provides base support for defining Ion heaps in devicetree
- and setting them up. Also includes functions for platforms
- to parse the devicetree and expand for their own custom
- extensions
-
- If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 5d630a0..9457090 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,9 +5,3 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
-
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-obj-$(CONFIG_ION_HISI) += hisilicon/
-obj-$(CONFIG_ION_OF) += ion_of.o
-
diff --git a/drivers/staging/android/ion/hisilicon/Kconfig 
b/drivers/staging/android/ion/hisilicon/Kconfig
deleted file mode 100644
index 2b4bd07..000
--- a/drivers/staging/android/ion/hisilicon/Kconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-config HI6220_ION
-bool "Hi6220 ION Driver"
-depends on ARCH_HISI && ION
-help
-  Build the Hisilicon Hi6220 ion driver.
diff --git a/drivers/staging/android/ion/hisilicon/Makefile 
b/drivers/staging/android/ion/hisilicon/Makefile
deleted file mode 100644
index 2a89414..000
--- a/drivers/staging/android/ion/hisilicon/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c 
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
deleted file mode 100644
index 0de7897..000
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/*
- * Hisilicon Hi6220 ION Driver
- *
- * Copyright (c) 2015 Hisilicon Limited.
- *
- * Author: Chen Feng 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#define pr_fmt(fmt) "Ion: " fmt
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "../ion_priv.h"
-#include "../ion.h"
-#include "../ion_of.h"
-
-struct hisi_ion_dev {
-   struct ion_heap **heaps;
-   struct 

[RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion.c | 101 +++---
 1 file changed, 50 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index ce4adac..a931b30 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-  struct device *dev,
-  enum dma_data_direction direction);
-
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
struct sg_table *new_table;
@@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table 
*table)
return new_table;
 }
 
+static void free_duped_table(struct sg_table *table)
+{
+   sg_free_table(table);
+   kfree(table);
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+   struct sg_table *table;
+   int ret;
+
+   /*
+* TODO: Need to sync wrt CPU or device completely owning?
+*/
+
+   table = dup_sg_table(buffer->sg_table);
 
-   ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return dup_sg_table(buffer->sg_table);
+   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+   direction)){
+   ret = -ENOMEM;
+   goto err;
+   }
+
+err:
+   free_duped_table(table);
+   return ERR_PTR(ret);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
-   sg_free_table(table);
-   kfree(table);
+   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   free_duped_table(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -864,38 +881,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
 };
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-  struct device *dev,
-  enum dma_data_direction dir)
-{
-   struct ion_vma_list *vma_list;
-   int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-   int i;
-
-   pr_debug("%s: syncing for device %s\n", __func__,
-dev ? dev_name(dev) : "null");
-
-   if (!ion_buffer_fault_user_mappings(buffer))
-   return;
-
-   mutex_lock(>lock);
-   for (i = 0; i < pages; i++) {
-   struct page *page = buffer->pages[i];
-
-   if (ion_buffer_page_is_dirty(page))
-   ion_pages_sync_for_device(dev, ion_buffer_page(page),
- PAGE_SIZE, dir);
-
-   ion_buffer_page_clean(buffer->pages + i);
-   }
-   list_for_each_entry(vma_list, >vmas, list) {
-   struct vm_area_struct *vma = vma_list->vma;
-
-   zap_page_range(vma, vma->vm_start, vma->vm_end - vma->vm_start);
-   }
-   mutex_unlock(>lock);
-}
-
 static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct ion_buffer *buffer = vma->vm_private_data;
@@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
 
-   if (!buffer->heap->ops->map_kernel) {
-   pr_err("%s: map kernel is not implemented by this heap.\n",
-  __func__);
-   return -ENODEV;
+   /*
+* TODO: Move this elsewhere because we don't always need a vaddr
+*/
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   vaddr = ion_buffer_kmap_get(buffer);
+   mutex_unlock(>lock);
}
 
-   mutex_lock(>lock);
-   vaddr = ion_buffer_kmap_get(buffer);
-   mutex_unlock(>lock);
-   return PTR_ERR_OR_ZERO(vaddr);
+   /*
+* Close enough right now? Flag to skip sync?
+*/
+   if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+DMA_BIDIRECTIONAL))
+   return -ENOMEM;
+
+   return 0;
 }
 
 static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,

[RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt

[Laura Abbott]

The reference counting of dma_map calls was removed. Remove the
associated counter field as well.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion_priv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index 5b3059c..46d3ff5 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -44,7 +44,6 @@
  * @lock:  protects the buffers cnt fields
  * @kmap_cnt:  number of times the buffer is mapped to the kernel
  * @vaddr: the kernel mapping if kmap_cnt is not zero
- * @dmap_cnt:  number of times the buffer is mapped for dma
  * @sg_table:  the sg table for the buffer if dmap_cnt is not zero
  * @pages: flat array of pages in the buffer -- used by fault
  * handler and only valid for buffers that are faulted in
@@ -70,7 +69,6 @@ struct ion_buffer {
struct mutex lock;
int kmap_cnt;
void *vaddr;
-   int dmap_cnt;
struct sg_table *sg_table;
struct page **pages;
struct list_head vmas;
-- 
2.7.4

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

[RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field

[Laura Abbott]

The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.

Signed-off-by: Laura Abbott 
---
 drivers/staging/android/ion/ion-ioctl.c |  1 -
 drivers/staging/android/ion/ion.c   | 14 ++
 drivers/staging/android/ion/ion.h   |  5 +
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +++---
 drivers/staging/android/ion/ion_chunk_heap.c|  9 +++--
 drivers/staging/android/ion/ion_cma_heap.c  |  5 +
 drivers/staging/android/ion/ion_priv.h  |  2 +-
 drivers/staging/android/ion/ion_system_heap.c   |  9 +
 8 files changed, 16 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 9ff815a..5b2e93f 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
struct ion_handle *handle;
 
handle = ion_alloc(client, data.allocation.len,
-   data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9696007..94a498e 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
-   unsigned long align,
unsigned long flags)
 {
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>ref);
 
-   ret = heap->ops->allocate(heap, buffer, len, align, flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
 
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
 
ion_heap_freelist_drain(heap, 0);
-   ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+   ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct 
ion_handle *handle)
 }
 
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-size_t align, unsigned int heap_id_mask,
+unsigned int heap_id_mask,
 unsigned int flags)
 {
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
struct ion_heap *heap;
int ret;
 
-   pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-len, align, heap_id_mask, flags);
+   pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+len, heap_id_mask, flags);
/*
 * traverse the list of heaps available in this system in priority
 * order.  If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
-   buffer = ion_buffer_create(heap, dev, len, align, flags);
+   buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 93dafb4..3b4bff5 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -45,7 +45,6 @@ struct ion_buffer;
  * @name:  used for debug purposes
  * @base:  base address of heap in physical memory if applicable
  * @size:  size of the heap in bytes if applicable
- * @align: required alignment in physical memory if applicable
  * @priv:  private info passed from the board file
  *
  * Provided by the board file.
@@ -93,8 +92,6 @@ void ion_client_destroy(struct ion_client *client);
  * ion_alloc - allocate ion memory
  * @client:the client
  * @len:   size of the 

[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

Hi,

There's been some recent discussions[1] about Ion-like frameworks. There's
apparently interest in just keeping Ion since it works reasonablly well.
This series does what should be the final clean ups for it to possibly be
moved out of staging.

This includes the following:
- Some general clean up and removal of features that never got a lot of use
  as far as I can tell.
- Fixing up the caching. This is the series I proposed back in December[2]
  but never heard any feedback on. It will certainly break existing
  applications that rely on the implicit caching. I'd rather make an effort
  to move to a model that isn't going directly against the establishement
  though.
- Fixing up the platform support. The devicetree approach was never well
  recieved by DT maintainers. The proposal here is to think of Ion less as
  specifying requirements and more of a framework for exposing memory to
  userspace.
- CMA allocations now happen without the need of a dummy device structure.
  This fixes a bunch of the reasons why I attempted to add devicetree
  support before.

I've had problems getting feedback in the past so if I don't hear any major
objections I'm going to send out with the RFC dropped to be picked up.
The only reason there isn't a patch to come out of staging is to discuss any
other changes to the ABI people might want. Once this comes out of staging,
I really don't want to mess with the ABI.

Feedback appreciated.

Thanks,
Laura

[1] https://marc.info/?l=linux-kernel=148699712602105=2
[2] https://marc.info/?l=linaro-mm-sig=148176050802908=2

Laura Abbott (12):
  staging: android: ion: Remove dmap_cnt
  staging: android: ion: Remove alignment from allocation field
  staging: android: ion: Duplicate sg_table
  staging: android: ion: Call dma_map_sg for syncing and mapping
  staging: android: ion: Remove page faulting support
  staging: android: ion: Remove crufty cache support
  staging: android: ion: Remove old platform support
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Make Ion heaps selectable
  staging; android: ion: Enumerate all available heaps

 drivers/base/dma-contiguous.c  |   5 +-
 drivers/staging/android/ion/Kconfig|  51 ++--
 drivers/staging/android/ion/Makefile   |  14 +-
 drivers/staging/android/ion/hisilicon/Kconfig  |   5 -
 drivers/staging/android/ion/hisilicon/Makefile |   1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -
 drivers/staging/android/ion/ion-ioctl.c|   6 -
 drivers/staging/android/ion/ion.c  | 282 ++---
 drivers/staging/android/ion/ion.h  |   5 +-
 drivers/staging/android/ion/ion_carveout_heap.c|  16 +-
 drivers/staging/android/ion/ion_chunk_heap.c   |  15 +-
 drivers/staging/android/ion/ion_cma_heap.c | 102 ++--
 drivers/staging/android/ion/ion_dummy_driver.c | 156 
 drivers/staging/android/ion/ion_enumerate.c|  89 +++
 drivers/staging/android/ion/ion_of.c   | 184 --
 drivers/staging/android/ion/ion_of.h   |  37 ---
 drivers/staging/android/ion/ion_page_pool.c|   3 -
 drivers/staging/android/ion/ion_priv.h |  57 -
 drivers/staging/android/ion/ion_system_heap.c  |  14 +-
 drivers/staging/android/ion/tegra/Makefile |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
 include/linux/cma.h|   6 +-
 mm/cma.c   |  25 +-
 mm/cma.h   |   1 +
 mm/cma_debug.c |   2 +-
 25 files changed, 312 insertions(+), 958 deletions(-)
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 create mode 100644 drivers/staging/android/ion/ion_enumerate.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
2.7.4

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

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

> Am 02.03.2017 um 20:34 schrieb Mauro Carvalho Chehab 
> :
> 
> Em Thu, 2 Mar 2017 20:06:39 +0100
> Markus Heiser  escreveu:
> 
>> Hi Mauro,
>> 
>>> Tested here with the enclosed patch.  
>> 
>> great, big step forward making /media/Makefile smaller ...  thanks a lot
>> 
>>> It crashed:
>>> Exception occurred:
>>> File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
>>> dot2format
>>>   sys.stderr.write(err)
>>> TypeError: write() argument must be str, not bytes
>>> The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
>>> want to report the issue to the developers.
>>> Please also report this if it was a user error, so that a better error 
>>> message can be provided next time.
>>> A bug report can be filed in the tracker at 
>>> . Thanks!
>>> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
>>> make[1]: *** [htmldocs] Error 1
>>> Makefile:1450: recipe for target 'htmldocs' failed
>>> make: *** [htmldocs] Error 2
>>> 
>>> Weird enough, it produced a 
>>> Documentation/output/media/uapi/v4l/pipeline.svg file.  
>> 
>> I guess that the dot command writes something to stderr. This is captured 
>> by the extension and printed to stderr ...
>> 
>> +def dot2format(dot_fname, out_fname):
>> ...
>> +exit_code = 42
>> +with open(out_fname, "w") as out:
>> +p = subprocess.Popen(
>> +cmd, stdout = out, stderr = subprocess.PIPE )
>> +nil, err = p.communicate()
>> +
>> +sys.stderr.write(err)
>> +
>> +exit_code = p.returncode
>> +out.flush()
>> +return bool(exit_code == 0)
>> 
>>> File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
>>> dot2format
>>>   sys.stderr.write(err)
>>> TypeError: write() argument must be str, not bytes  
>> 
>> Do we need this stderr output? For a first test, uncomment the 
>> "sys.stderr.write(err)“ in line 222. Or, if we really need the
>> stderr, try:
>> 
>> -sys.stderr.write(err)
>> +sys.stderr.write(str(err))
> 
> Yes, this fixed. I actually did:
> 
> -sys.stderr.write(err)
> +sys.stderr.write(str(err))
> +sys.stderr.write("\n")
> 
> It is now printing:
>   b''
> 
> I added the \n print to avoid it to be mixed with the "writing output"
> prints.
> No idea how to make sense from it - but clearly, the error report
> logic require some care ;-)


Aargh, I’am a idiot ... I guess 'sys.stderr.write(err)‘ is a artefact
of my development, simply drop it and the subprocess.PIPE of stderr
also.

+with open(out_fname, "w") as out:
+p = subprocess.Popen(
-cmd, stdout = out, stderr = subprocess.PIPE )
+cmd, stdout = out)
+nil, err = p.communicate()
-
-sys.stderr.write(err)
-
+exit_code = p.returncode
+out.flush()
+return bool(exit_code == 0)

I can’t test it ATM, but without redirect stderr, the stderr
of the parent process is inherited.

  https://docs.python.org/3.6/library/subprocess.html#popen-constructor

The Popen.communicate() always returns a tuple (stdout_data, stderr_data)
with above the tuple is always (None, None).

  
https://docs.python.org/3.6/library/subprocess.html#subprocess.Popen.communicate

  """to get anything other than None in the result tuple,
 you need to give stdout=PIPE and/or stderr=PIPE too."""

Sorry, that I made all this mistakes, but „here“ I have only mail
and web, no dev-env and I miss my emacs  ;) 

If the suggestion above does not work, I have to investigate
more time next weekend.

-- Markus --


> 
> Thanks,
> Mauro

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

[Bug 64201] bfgminer OpenCL usage result segmentation fault on r600g with HD6850

[bugzilla-daemon]

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

--- Comment #57 from darkbasic  ---
Can't test right now, I'm reinstalling my desktop with the HD7950.

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

[Bug 64201] bfgminer OpenCL usage result segmentation fault on r600g with HD6850

[bugzilla-daemon]

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

--- Comment #56 from Jan Vesely  ---
this is an old bug. Is this still an issue?

pyrit works OK on my turks as well as carrizo+iceland:
#2: 'OpenCL-Device 'AMD TURKS (DRM 2.48.0 / 4.9.12-200.fc25.x86_64, LLVM
5.0.0)'': 10480.1 PMKs/s (RTT 2.3)

#1: 'OpenCL-Device 'AMD CARRIZO (DRM 3.1.0 / 4.4.0-ROC, LLVM 4.0.0)'': 16205.3
PMKs/s (RTT 1.6)
#2: 'OpenCL-Device 'AMD ICELAND (DRM 3.1.0 / 4.4.0-ROC, LLVM 4.0.0)'': 2072.7
PMKs/s (RTT 1.5)

bfgminer works as well:
OCL0| 20s:106.8 avg:79.71 u:23.09 Mh/s | A:1 R:0+0(none) HW:0/none

OCL0| 20s:184.9 avg:182.3 u:75.27 Mh/s | A:2 R:2+0( 50%) HW:0/none
OCL1| 20s:48.50 avg:47.25 u:37.64 Mh/s | A:1 R:1+0( 50%) HW:0/none

cgminer removed GPU code long time ago

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

> Am 02.03.2017 um 20:09 schrieb Mauro Carvalho Chehab 
> :
...

>> 
>> Yes, its only about "docutils>=0.11" in Sphinx 1.3 dependencies. 
>> In Sphinx 1.5 the error:
>> 
>>  https://github.com/sphinx-doc/sphinx/issues/3212
>> 
>> is fixed:
>> 
>>  
>> https://github.com/tk0miya/sphinx/commit/73663f63672f22304810ce6bb9787490ad250127
>> 
>> But this will never be fixed downwards.
> 
> Crap. This kind of patch should be backported to Sphinx 1.3/1.4,
> or Python's PIP repository should be fixed to require docutils
> version to be either 0.11 or 0.12, if one installs version 1.3
> or 1.4 of Sphinx.
> 
> The way it is, PIP repository is broken!

I leaved a comment at sphinx-doc project:

  https://github.com/sphinx-doc/sphinx/issues/3212#issuecomment-283756374

>> All this is about semantic versioning. If you want to promise your
>> builds, you have to name which versions of dependencies you support.
>> I guess this is nothing new for kernel developers ;)
> 
> No. At the Kernel, we do everything possible to not break APIs.

Sorry I was not precise. I was talking about third tools dependencies
and that this is well handled by the kernel ;)
 
> If this were not the case, you wouldn't be able to run Sphinx 1.5 
> with legacy Kernel versions ;-)

This is what I mean ;)

> 
>> The problem is, that PEP440 defines not only ONE version scheme
>> 
>> """Some hard to read version identifiers are permitted by
>>this scheme in order to better accommodate the wide range
>>of versioning practices across existing public and private
>>Python projects."""
>> 
>> In practice, the python projects use slightly different schemes
>> which not follow one rule like .. 
>> From history packaging in Python is the hell, it becomes better, but
>> the problem with slightly different version schemes still exist.
> 
> IMHO, the way Python and python libraries break compatibility is crazy.
> 
> Good packaging sense says that, if APIs can break on every single new
> release (with seems to be the case of docutils), then a package
> depending on such bad-developed library should require the exact
> version(s) it is known to work.

I can only repeat myself, the main problem is, that PEP440 allows
multiple version schemes. Instead of one scheme 

 ..

Every project use a slightly different scheme and others
do not care about any scheme.

> When we're discussing about the docs toolchain, I mentioned that I
> was afraid that the Python development model would cause this sort
> of issues. Unfortunately, it seems that my concerns were pertinent :-(

Not really ;) .. you are tend to mix at least three parts

1. Python
2. Python packaging
3. Sphinx developers who do not stick there depencies

But you are right, when you say that in all parts some confusion
prevail. E.g.

1. Python 2 to 3 movement has been done reckless
--> in the meantime we have https://pythonhosted.org/six/

2. Python packaging is a mess (setup-tools, distutils, pip, easy_install ..) 
--> in the meantime we have PyPA who brings us more structure 
(https://www.pypa.io/en/latest)

3. Developer using Python
--> we all have a learn curve and making errors all days long. 
But this should not stop us from continue :)


>> I guess this is something we should discuss with Jon, he
>> is also familiar with it virtualenv. 
> 
> Yeah, making kernel build to depend on network can be a problem.
> 
> Maybe one way would be to have a sort of "prepare" script that
> would be network-dependent, and will install whatever needed to
> build the docs. If called, make *docs will use the virtualenv.
> Otherwise, it would print a warning message saying that the doc
> build is not reliable, but would try to use whatever installed
> on the machine.

Could be a workaround. May Jon has continuative ideas, nothing
we have to solve today ... give Jon some time.
 
-- Markus --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

[Daniel Vetter]

On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote:
> Since we cannot always generate exactly requested pixel clock
> there's not much sense in checking requested_clock == clk_round_rate().
> In that case for quite some modes we'll be getting -EINVAL and no video
> output at all.
> 
> But given there's some tolerance to real pixel clock in TVs/monitors
> we may still give it a try with the clock as close to requested one as
> PLL on the board may generate. So we just do a fixup to what current
> board may provide.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jose Abreu 
> ---
>  drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index ad9a95916f1f..3f2823c1efc3 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> ~ARCPGU_CTRL_ENABLE_MASK);
>  }
>  
> -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> -  struct drm_crtc_state *state)
> +static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)

This isn't required at all, see drm_crtc_state.adjusted_mode. Just update
that and you're good - .mode_fixup is the backwards compatibility function
for old kms drivers, atomic_check is strictly more powerful.

Please also make sure the documentation properly explains this, and if
not, please submit a patch to improve it.
-Daniel

>  {
>   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> - struct drm_display_mode *mode = >adjusted_mode;
> - long rate, clk_rate = mode->clock * 1000;
>  
> - rate = clk_round_rate(arcpgu->clk, clk_rate);
> - if (rate != clk_rate)
> - return -EINVAL;
> + adjusted_mode->clock =
> + clk_round_rate(arcpgu->clk, mode->clock * 1000) / 1000;
>  
> - return 0;
> + return true;
>  }
>  
>  static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> @@ -165,8 +163,8 @@ static const struct drm_crtc_helper_funcs 
> arc_pgu_crtc_helper_funcs = {
>   .disable= arc_pgu_crtc_disable,
>   .prepare= arc_pgu_crtc_disable,
>   .commit = arc_pgu_crtc_enable,
> - .atomic_check   = arc_pgu_crtc_atomic_check,
>   .atomic_begin   = arc_pgu_crtc_atomic_begin,
> + .mode_fixup = arc_pgu_crtc_mode_fixup,
>  };
>  
>  static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Daniel Vetter]

On Thu, Mar 02, 2017 at 08:06:39PM +0100, Markus Heiser wrote:
> Hi Mauro,
> 
> > Tested here with the enclosed patch.
> 
> great, big step forward making /media/Makefile smaller ...  thanks a lot
> 
> > It crashed:
> > Exception occurred:
> >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> > dot2format
> >sys.stderr.write(err)
> > TypeError: write() argument must be str, not bytes
> > The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> > want to report the issue to the developers.
> > Please also report this if it was a user error, so that a better error 
> > message can be provided next time.
> > A bug report can be filed in the tracker at 
> > . Thanks!
> > Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> > make[1]: *** [htmldocs] Error 1
> > Makefile:1450: recipe for target 'htmldocs' failed
> > make: *** [htmldocs] Error 2
> > 
> > Weird enough, it produced a 
> > Documentation/output/media/uapi/v4l/pipeline.svg file.
> 
> I guess that the dot command writes something to stderr. This is captured 
> by the extension and printed to stderr ...
> 
> +def dot2format(dot_fname, out_fname):
> ...
> +exit_code = 42
> +with open(out_fname, "w") as out:
> +p = subprocess.Popen(
> +cmd, stdout = out, stderr = subprocess.PIPE )
> +nil, err = p.communicate()
> +
> +sys.stderr.write(err)
> +
> +exit_code = p.returncode
> +out.flush()
> +return bool(exit_code == 0)
> 
> >  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> > dot2format
> >sys.stderr.write(err)
> > TypeError: write() argument must be str, not bytes
> 
> Do we need this stderr output? For a first test, uncomment the 
> "sys.stderr.write(err)“ in line 222. Or, if we really need the
> stderr, try:
> 
> -sys.stderr.write(err)
> +sys.stderr.write(str(err))
> 
> I this fixes, there is another "sys.stderr.write(err)" in 
> func svg2pdf(..) which should also fixed ….
>  
> +def svg2pdf(svg_fname, pdf_fname):
> ...
> +cmd = [convert_cmd, svg_fname, pdf_fname]
> +p = subprocess.Popen(
> +cmd, stdout = out, stderr = subprocess.PIPE )
> +nil, err = p.communicate()
> +
> -sys.stderr.write(err)
> +sys.stderr.write(str(err))
> +
> +exit_code = p.returncode
> +return bool(exit_code == 0)

Yes, I very much want stderr to be forward. Without that you don't see
error output from dot or convert, and that makes it impossible to debug
anything. If I want a direct forwarding of the bytes, how should I do this
in python? Capturing stderr and then re-dumping it is kinda silly ...

Note that I copied this pattern from the kernel-doc extension, seems to
have worked there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:01:36PM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 2 Mar 2017 16:53:04 +0100
> Daniel Vetter  escreveu:
> 
> > On Thu, Mar 2, 2017 at 4:22 PM, Jonathan Corbet  wrote:
> > > On Thu, 2 Mar 2017 16:11:08 +0100
> > > Daniel Vetter  wrote:
> > >  
> > >> I'll give it a shot at implementing it, but I can't (easily at least) 
> > >> test
> > >> on sphinx 1.3.  
> > >
> > > Virtualenv makes that kind of thing pretty easy to do.  Maybe we should
> > > add a script to create and populate a suitable venv for this kind of
> > > thing.  
> > 
> > Laurent quickly checked v5 of this patch, looks all good now.
> > 
> > > Meanwhile, I've been seeing only parts 1 and 2 of what's clearly a bigger
> > > series.  Do you want me to carry just these two?  
> > 
> > I submitted the entire series to both linux-doc and dri-devel. 
> 
> Sure you sent to linux-doc? I'm not seeing it there.
> 
> I'm not seeing it at the mirrors neither:
>   https://marc.info/?l=linux-doc=1=201703=2
>   https://www.spinics.net/lists/linux-doc/maillist.html

First one I spotted:

https://marc.info/?l=linux-doc=148848308304746=2

So maybe just mail server hiccup that's recovering now?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

Hi Mauro,

> Tested here with the enclosed patch.

great, big step forward making /media/Makefile smaller ...  thanks a lot

> It crashed:
> Exception occurred:
>  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> dot2format
>sys.stderr.write(err)
> TypeError: write() argument must be str, not bytes
> The full traceback has been saved in /tmp/sphinx-err-_1vahbmg.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
> make[1]: *** [htmldocs] Error 1
> Makefile:1450: recipe for target 'htmldocs' failed
> make: *** [htmldocs] Error 2
> 
> Weird enough, it produced a Documentation/output/media/uapi/v4l/pipeline.svg 
> file.

I guess that the dot command writes something to stderr. This is captured 
by the extension and printed to stderr ...

+def dot2format(dot_fname, out_fname):
...
+exit_code = 42
+with open(out_fname, "w") as out:
+p = subprocess.Popen(
+cmd, stdout = out, stderr = subprocess.PIPE )
+nil, err = p.communicate()
+
+sys.stderr.write(err)
+
+exit_code = p.returncode
+out.flush()
+return bool(exit_code == 0)

>  File "/devel/v4l/patchwork/Documentation/sphinx/kfigure.py", line 222, in 
> dot2format
>sys.stderr.write(err)
> TypeError: write() argument must be str, not bytes

Do we need this stderr output? For a first test, uncomment the 
"sys.stderr.write(err)“ in line 222. Or, if we really need the
stderr, try:

-sys.stderr.write(err)
+sys.stderr.write(str(err))

I this fixes, there is another "sys.stderr.write(err)" in 
func svg2pdf(..) which should also fixed ….
 
+def svg2pdf(svg_fname, pdf_fname):
...
+cmd = [convert_cmd, svg_fname, pdf_fname]
+p = subprocess.Popen(
+cmd, stdout = out, stderr = subprocess.PIPE )
+nil, err = p.communicate()
+
-sys.stderr.write(err)
+sys.stderr.write(str(err))
+
+exit_code = p.returncode
+return bool(exit_code == 0)

Thanks!

 -- Markus --

> 
> 
> Thanks,
> Mauro
> 
> --
> 
> [PATCH] docs-rst: Don't use explicit Makefile rules to build SVG and
> DOT files
> 
> Now that we have an extension to handle images, use it.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
> index 32663602ff25..5bd52ea1eff0 100644
> --- a/Documentation/media/Makefile
> +++ b/Documentation/media/Makefile
> @@ -1,51 +1,6 @@
> -# Rules to convert DOT and SVG to Sphinx images
> -
> -SRC_DIR=$(srctree)/Documentation/media
> -
> -DOTS = \
> - uapi/v4l/pipeline.dot \
> -
> -IMAGES = \
> - typical_media_device.svg \
> - uapi/dvb/dvbstb.svg \
> - uapi/v4l/bayer.svg \
> - uapi/v4l/constraints.svg \
> - uapi/v4l/crop.svg \
> - uapi/v4l/fieldseq_bt.svg \
> - uapi/v4l/fieldseq_tb.svg \
> - uapi/v4l/nv12mt.svg \
> - uapi/v4l/nv12mt_example.svg \
> - uapi/v4l/pipeline.svg \
> - uapi/v4l/selection.svg \
> - uapi/v4l/subdev-image-processing-full.svg \
> - uapi/v4l/subdev-image-processing-scaling-multi-source.svg \
> - uapi/v4l/subdev-image-processing-crop.svg \
> - uapi/v4l/vbi_525.svg \
> - uapi/v4l/vbi_625.svg \
> - uapi/v4l/vbi_hsync.svg \
> -
> -DOTTGT := $(patsubst %.dot,%.svg,$(DOTS))
> -IMGDOT := $(patsubst %,$(SRC_DIR)/%,$(DOTTGT))
> -
> -IMGTGT := $(patsubst %.svg,%.pdf,$(IMAGES))
> -IMGPDF := $(patsubst %,$(SRC_DIR)/%,$(IMGTGT))
> -
> -cmd = $(echo-cmd) $(cmd_$(1))
> -
> -quiet_cmd_genpdf = GENPDF  $2
> -  cmd_genpdf = convert $2 $3
> -
> -quiet_cmd_gendot = DOT $2
> -  cmd_gendot = dot -Tsvg $2 > $3
> -
> -%.pdf: %.svg
> - @$(call cmd,genpdf,$<,$@)
> -
> -%.svg: %.dot
> - @$(call cmd,gendot,$<,$@)
> -
> # Rules to convert a .h file to inline RST documentation
> 
> +SRC_DIR=$(srctree)/Documentation/media
> PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
> UAPI = $(srctree)/include/uapi/linux
> KAPI = $(srctree)/include/linux
> diff --git a/Documentation/media/intro.rst b/Documentation/media/intro.rst
> index 8f7490c9a8ef..5562fba1d51d 100644
> --- a/Documentation/media/intro.rst
> +++ b/Documentation/media/intro.rst
> @@ -13,8 +13,8 @@ A typical media device hardware is shown at 
> :ref:`typical_media_device`.
> 
> .. _typical_media_device:
> 
> -.. figure::  typical_media_device.*
> -:alt:typical_media_device.pdf / typical_media_device.svg
> +.. kernel-figure::  typical_media_device.svg
> +:alt:typical_media_device.svg
> :align:  center
> 
> Typical Media Device
> diff --git a/Documentation/media/uapi/dvb/intro.rst 
> b/Documentation/media/uapi/dvb/intro.rst
> index 2ed5c23102b4..0e76067a5b58 100644
> --- 

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

> Am 02.03.2017 um 19:20 schrieb Jonathan Corbet :
> 
> On Thu, 2 Mar 2017 19:16:47 +0100
> Markus Heiser  wrote:
> 
>> This is very easy, if we use a requiremts.txt file where we 
>> stick the versions and run the sphinx in this build in a
>> virtualenv which is build up by this requirements.txt.
>> 
>>  https://pip.pypa.io/en/stable/user_guide/#requirements-files
>> 
>> To summarize, I recommend a Makefile.sphinx cmd which does
>> something like:
>> 
>>  virtualenv output/myenv
>>  source output/myenv/bin/activate
>>  pip install -r requirements.txt
>>  sphinx-build ...
>> 
>> I guess this is something we should discuss with Jon, he
>> is also familiar with it virtualenv. 
> 
> That would perhaps make the build more reliable, but it would also make
> the build dependent on net access to PyPI, and that's not an idea I like a
> whole lot.  We should be able to do a build without going out on the
> network.

Right, there are PROS and CONS. Another point is where to place
the virtualenv. In my example above it is placed in output/ with
I’am not really happy.

> I'm kind of pressed for time, but will try to ponder on this more
> shortly…

My recommendation are mostly from a python developer POV, which is
sometimes diametral to what kernel development needs. You now both
POV in deep so I’am hopeful that you find the right conceptual
answers for those open questions ;)

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Jonathan Corbet]

On Thu, 2 Mar 2017 19:16:47 +0100
Markus Heiser  wrote:

> This is very easy, if we use a requiremts.txt file where we 
> stick the versions and run the sphinx in this build in a
> virtualenv which is build up by this requirements.txt.
> 
>   https://pip.pypa.io/en/stable/user_guide/#requirements-files
> 
> To summarize, I recommend a Makefile.sphinx cmd which does
> something like:
> 
>   virtualenv output/myenv
>   source output/myenv/bin/activate
>   pip install -r requirements.txt
>   sphinx-build ...
>   
> I guess this is something we should discuss with Jon, he
> is also familiar with it virtualenv. 

That would perhaps make the build more reliable, but it would also make
the build dependent on net access to PyPI, and that's not an idea I like a
whole lot.  We should be able to do a build without going out on the
network.

I'm kind of pressed for time, but will try to ponder on this more
shortly...

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

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

> Am 02.03.2017 um 17:29 schrieb Mauro Carvalho Chehab 
> :
> 
> Em Thu, 2 Mar 2017 17:13:25 +0100
> Markus Heiser  escreveu:
> 
>>> Am 02.03.2017 um 16:49 schrieb Mauro Carvalho Chehab 
>>> :
>>> 
> You can test it with virtualenv  
> https://virtualenv.pypa.io/en/stable/userguide/
> 
> In short:
> 
> $ cd kernel-src
> $ virtualenv myenv
> $ source myenv/bin/activate
> $ pip install 'Sphinx==1.3.1'
> $ make 
 
 Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
 virtualenv is broken:
 
 writing output... [ 16%] media/intro   
  
 Exception occurred:
 File 
 "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
  line 671, in depart_document
   assert not self.context, 'len(context) = %s' % len(self.context)
 AssertionError: len(context) = 1
 The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you 
 want to report the issue to the developers.
 Please also report this if it was a user error, so that a better error 
 message can be provided next time.
 A bug report can be filed in the tracker at 
 . Thanks!
 Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
 make[1]: *** [htmldocs] Error 1
 Makefile:1450: recipe for target 'htmldocs' failed
 make: *** [htmldocs] Error 2
 
 Perhaps it is time for us to move minimal requirements to 1.4?  
>>> 
>>> Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
>>> with 1.5.2 (for htmldocs).
>>> 
>>> Thanks,
>>> Mauro
>>> 
>>> -
>>> 
>>> This is the error log with 1.4:
>>> 
>>> # Sphinx version: 1.4.9  
>> 
>>> File 
>>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
>>>  line 187, in walkabout
>>>   visitor.dispatch_departure(self)
>>> File 
>>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
>>>  line 1895, in dispatch_departure
>>>   return method(node)
>>> File 
>>> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>>>  line 671, in depart_document
>>>   assert not self.context, 'len(context) = %s' % len(self.context)
>>> AssertionError: len(context) = 1  
>> 
>> I guess this is a error from newer docutils, so we have to fix docutils 
>> version also.
>> 
>> Sphinx itself specifies "docutils>=0.11"
>> 
>>  https://github.com/sphinx-doc/sphinx/blob/1.3.1/setup.py#L52
>> 
>> So I guess it uses a up to date docutils or the ducutils which are already 
>> installed system wide.
> 
> The system-wide docutils is this one:
> 
>   python2-docutils-0.13.1-3.fc25.noarch
>   python3-docutils-0.13.1-3.fc25.noarch

Sorry my mistake, in the traceback we see

File 
"/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
 line 671, in depart_document
  assert not self.context, 'len(context) = %s' % len(self.context)

... which means: system wide installation does not matter.

> Btw, I tested also with virtualenv-3/pip3 and the same issue happens there.
> 
> Manually installing version 0.11 makes it to work again.

Yes, its only about "docutils>=0.11" in Sphinx 1.3 dependencies. 
In Sphinx 1.5 the error:

  https://github.com/sphinx-doc/sphinx/issues/3212

is fixed:

  
https://github.com/tk0miya/sphinx/commit/73663f63672f22304810ce6bb9787490ad250127

But this will never be fixed downwards.

All this is about semantic versioning. If you want to promise your
builds, you have to name which versions of dependencies you support.
I guess this is nothing new for kernel developers ;)

The problem is, that PEP440 defines not only ONE version scheme

 """Some hard to read version identifiers are permitted by
this scheme in order to better accommodate the wide range
of versioning practices across existing public and private
Python projects."""

In practice, the python projects use slightly different schemes
which not follow one rule like .. 
From history packaging in Python is the hell, it becomes better, but
the problem with slightly different version schemes still exist.

How can this info help us? Now we know, that we have to stick Sphinx
and docutils by patch-levels we are willing to support. Or with
your words 

> Considering that Sphinx require a specific docutils package for it to
> work, perhaps it is time for us to consider to use the virtenv
> enchantments at make docs targets :-p


This is very easy, if we use a requiremts.txt file where we 
stick the versions and run the sphinx in this build in a
virtualenv which is build up by this requirements.txt.

  https://pip.pypa.io/en/stable/user_guide/#requirements-files

To summarize, I recommend a Makefile.sphinx cmd which does
something like:

  virtualenv 

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #6 from Jean Delvare (jdelv...@suse.de) ---
OK, let's just revert then. I have just sent a revert patch to stable@.

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

[PATCH 06/11] drm/meson: Add support for HDMI venc modes and settings

[Neil Armstrong]

This patch adds support for the supported HDMI Venc modes and add the VPP mux
value to switch to ENCP encoder.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc.c | 1245 +++-
 drivers/gpu/drm/meson/meson_venc.h |7 +
 drivers/gpu/drm/meson/meson_vpp.h  |2 +
 3 files changed, 1249 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index f7c87017..31dc275 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -30,12 +30,37 @@
  * VENC Handle the pixels encoding to the output formats.
  * We handle the following encodings :
  * - CVBS Encoding via the ENCI encoder and VDAC digital to analog converter
- *
- * What is missing :
  * - TMDS/HDMI Encoding via ENCI_DIV and ENCP
  * - Setup of more clock rates for HDMI modes
+ *
+ * What is missing :
  * - LCD Panel encoding via ENCL
  * - TV Panel encoding via ENCT
+ *
+ * VENC paths :
+ *_   _   
+ * vd1---| |-| | | VENC /-|VDAC
+ * vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
+ * osd1--| |-| | | \  | X--HDMI-TX
+ * osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
+ *   |  | |
+ *   |  \--ENCL---|LVDS
+ *   ||
+ *
+ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC
+ * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI.
+ * The ENCP is designed for Progressive encoding but can also generate
+ * 1080i interlaced pixels, and was initialy desined to encode pixels for
+ * VDAC to output RGB ou YUV analog outputs.
+ * It's output is only used through the ENCP_DVI encoder for HDMI.
+ * The ENCL LVDS encoder is not implemented.
+ *
+ * The ENCI and ENCP encoders needs specially defined parameters for each
+ * supported mode and thus cannot be determined from standard video timings.
+ *
+ * The ENCI end ENCP DVI encoders are more generic and can generate any timings
+ * from the pixel data generated by ENCI or ENCP, so can use the standard video
+ * timings are source for HW parameters.
  */
 
 /* HHI Registers */
@@ -91,6 +116,1219 @@ struct meson_cvbs_enci_mode meson_cvbs_enci_ntsc = {
.analog_sync_adj = 0x9c00,
 };
 
+union meson_hdmi_venc_mode {
+   struct {
+   unsigned int mode_tag;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_even;
+   unsigned int vso_odd;
+   unsigned int macv_max_amp;
+   unsigned int video_prog_mode;
+   unsigned int video_mode;
+   unsigned int sch_adjust;
+   unsigned int yc_delay;
+   unsigned int pixel_start;
+   unsigned int pixel_end;
+   unsigned int top_field_line_start;
+   unsigned int top_field_line_end;
+   unsigned int bottom_field_line_start;
+   unsigned int bottom_field_line_end;
+   } enci;
+   struct {
+   unsigned int dvi_settings;
+   unsigned int video_mode;
+   unsigned int video_mode_adv;
+   unsigned int video_prog_mode;
+   bool video_prog_mode_present;
+   unsigned int video_sync_mode;
+   bool video_sync_mode_present;
+   unsigned int video_yc_dly;
+   bool video_yc_dly_present;
+   unsigned int video_rgb_ctrl;
+   bool video_rgb_ctrl_present;
+   unsigned int video_filt_ctrl;
+   bool video_filt_ctrl_present;
+   unsigned int video_ofld_voav_ofst;
+   bool video_ofld_voav_ofst_present;
+   unsigned int yfp1_htime;
+   unsigned int yfp2_htime;
+   unsigned int max_pxcnt;
+   unsigned int hspuls_begin;
+   unsigned int hspuls_end;
+   unsigned int hspuls_switch;
+   unsigned int vspuls_begin;
+   unsigned int vspuls_end;
+   unsigned int vspuls_bline;
+   unsigned int vspuls_eline;
+   unsigned int eqpuls_begin;
+   bool eqpuls_begin_present;
+   unsigned int eqpuls_end;
+   bool eqpuls_end_present;
+   unsigned int eqpuls_bline;
+   bool eqpuls_bline_present;
+   unsigned int eqpuls_eline;
+   bool eqpuls_eline_present;
+   unsigned int havon_begin;
+   unsigned int havon_end;
+   unsigned int vavon_bline;
+   unsigned int vavon_eline;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_begin;
+   unsigned int vso_end;
+   unsigned int vso_bline;
+

[PATCH] docs-rst: automatically convert Graphviz and SVG images

[Daniel Vetter]

From: Markus Heiser 

This patch brings scalable figure, image handling and a concept to
embed *render* markups:

* DOT (http://www.graphviz.org)
* SVG

For image handling use the 'image' replacement::

.. kernel-image::  svg_image.svg
   :alt:simple SVG image

For figure handling use the 'figure' replacement::

.. kernel-figure::  svg_image.svg
   :alt:simple SVG image

   SVG image example

Embed *render* markups (or languages) like Graphviz's **DOT** is
provided by the *render* directive.::

  .. kernel-render:: DOT
 :alt: foobar digraph
 :caption: Embedded **DOT** (Graphviz) code.

 digraph foo {
  "bar" -> "baz";
 }

The *render* directive is a concept to integrate *render* markups and
languages, yet supported markups:

* DOT: render embedded Graphviz's **DOT**
* SVG: render embedded Scalable Vector Graphics (**SVG**)

v2: s/DOC/DOT/ in a few places (by Daniel).

v3: Simplify stuff a bit (by Daniel):

- Remove path detection and setup/check code for that. In
  Documentation/media/Makefile we already simply use these tools,
  better to have one consolidated check if we want/need one. Also
  remove the convertsvg support, we require ImageMagick's convert
  already in the doc build, no need for a 2nd fallback.

- Use sphinx for depency tracking, remove hand-rolled version.

- Forward stderr from dot and convert, otherwise debugging issues with
  the diagrams is impossible.

v4: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
Implement Markus suggestion for backwards compatability with earlier
releases. Laurent reported this, running sphinx 1.3. Solution entirely
untested.

v5: Use an explicit version check (suggested by Laurent).

Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Cc: Jani Nikula 
Cc: Mauro Carvalho Chehab 
Cc: Markus Heiser 
Cc: Laurent Pinchart 
Acked-by: Markus Heiser 
Tested-by: Laurent Pinchart 
Signed-off-by: Markus Heiser  (v1)
Signed-off-by: Daniel Vetter 
---
 Documentation/conf.py |   2 +-
 Documentation/doc-guide/hello.dot |   3 +
 Documentation/doc-guide/sphinx.rst|  90 ++-
 Documentation/doc-guide/svg_image.svg |  10 +
 Documentation/process/changes.rst |   7 +-
 Documentation/sphinx/kfigure.py   | 450 ++
 6 files changed, 556 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/doc-guide/svg_image.svg
 create mode 100644 Documentation/sphinx/kfigure.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index f6823cf01275..e3f537ce2935 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'kfigure']
 
 # The name of the math extension changed on Sphinx 1.4
 if major == 1 and minor > 3:
diff --git a/Documentation/doc-guide/hello.dot 
b/Documentation/doc-guide/hello.dot
new file mode 100644
index ..504621dfc595
--- /dev/null
+++ b/Documentation/doc-guide/hello.dot
@@ -0,0 +1,3 @@
+graph G {
+  Hello -- World
+}
diff --git a/Documentation/doc-guide/sphinx.rst 
b/Documentation/doc-guide/sphinx.rst
index 532d65b70500..b902744ce7dd 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -34,8 +34,10 @@ format-specific subdirectories under 
``Documentation/output``.
 
 To generate documentation, Sphinx (``sphinx-build``) must obviously be
 installed. For prettier HTML output, the Read the Docs Sphinx theme
-(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is 
also
-needed. All of these are widely available and packaged in distributions.
+(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
+``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively ``convert(1)``
+from ImageMagick (https://www.imagemagick.org). All of these are widely
+available and packaged in distributions.
 
 To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
 variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose
@@ -232,3 +234,87 @@ Rendered as:
   * .. _`last row`:
 
 - column 3
+
+
+Figures & Images
+
+
+If you want to add an image, you should use the ``kernel-figure`` and
+``kernel-image`` directives. E.g. to insert a figure with a scalable
+image format use SVG::
+
+.. kernel-figure::  svg_image.svg
+   

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Either push the revert to stable, or pull the additional fixes back from 4.11.

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

Re: [PATCH] drm/atmel-hlcdc: Rework the fbdev creation logic

[Boris Brezillon]

On Thu, 2 Mar 2017 17:04:51 +0100
Richard Genoud  wrote:

> On 28/11/2016 16:01, Boris Brezillon wrote:
> > Now that we wait for DRM panels to be available before registering the
> > DRM device (returning -EPROBE_DEFER if the panel has not been probed
> > yet), we no longer need to put the fbdev creation code in  
> > ->output_poll_changed().  
> > 
> > This removes the 10 secs delay between DRM dev registration and fbdev
> > creation (polling period = 10 seconds).
> > 
> > Signed-off-by: Boris Brezillon 
> > Reported-by: Alex Vazquez   
> Tested-by: Richard Genoud 
> 
> Those 10 seconds where a real pain !
> Any reason this has not been applied ?

It should show up in 4.11 (it's already in Linus' tree [1] ;-)).

Regards,

Boris

[1]https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/atmel-hlcdc?id=db02b7614a54bf0bf548db07bc8d3e7518fd9481
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
It's just an optimization.

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

Re: [PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Thursday 02 Mar 2017 16:29:32 Neil Armstrong wrote:
> The HDMI TX controller support HPD and RXSENSE signaling from the PHY
> via it's STAT0 PHY interface, but some vendor PHYs can manage these
> signals independently from the controller, thus these STAT0 handling
> should be moved to PHY specific operations and become optional.
> 
> The existing STAT0 HPD and RXSENSE handling code is refactored into
> a supplementaty set of default PHY operations that are used automatically
> when the platform glue doesn't provide its own operations.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 134 +---
>  include/drm/bridge/dw_hdmi.h |   8 +++
>  2 files changed, 104 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 653ecd7..58dcf7d 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1098,10 +1098,50 @@ static enum drm_connector_status
> dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi, connector_status_connected :
> connector_status_disconnected;
>  }
> 
> +static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> +bool force, bool disabled, bool rxsense)
> +{
> + if (force || disabled || !rxsense)
> + hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> + else
> + hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> +}
> +
> +static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* setup HPD and RXSENSE interrupt polarity */
> + hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
> +}
> +
> +static void dw_hdmi_phy_configure_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* enable cable hot plug irq */
> + hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> +}
> +
> +static void dw_hdmi_phy_clear_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Clear Hotplug interrupts */
> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> + HDMI_IH_PHY_STAT0);
> +}
> +
> +static void dw_hdmi_phy_unmute_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Unmute Hotplug interrupts */
> + hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | 
HDMI_IH_PHY_STAT0_RX_SENSE),
> + HDMI_IH_MUTE_PHY_STAT0);
> +}

Do we really need all those new operations ? It looks to me like a bit of 
refactoring could help lowering the number of operations. We essentially need

- an init function called at probe time (or likely rather at runtime PM resume 
time when we'll implement runtime PM) 

- an interrupt enable/disable function roughly equivalent to 
dw_hdmi_update_phy_mask()

- a read function to report the detection results called from 
dw_hdmi_connector_detect()

>  static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
>   .init = dw_hdmi_phy_init,
>   .disable = dw_hdmi_phy_disable,
>   .read_hpd = dw_hdmi_phy_read_hpd,
> + .update_hpd = dw_hdmi_phy_update_hpd,
> + .setup_hpd = dw_hdmi_phy_setup_hpd,
> + .configure_hpd = dw_hdmi_phy_configure_hpd,
> + .clear_hpd = dw_hdmi_phy_clear_hpd,
> + .unmute_hpd = dw_hdmi_phy_unmute_hpd,
>  };
> 
>  /* 
> @@ -1507,11 +1547,12 @@ static int dw_hdmi_fb_registered(struct dw_hdmi
> *hdmi) HDMI_PHY_I2CM_CTLINT_ADDR);
> 
>   /* enable cable hot plug irq */
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (hdmi->phy.ops->configure_hpd)
> + hdmi->phy.ops->configure_hpd(hdmi, hdmi->phy.data);
> 
>   /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> - HDMI_IH_PHY_STAT0);
> + if (hdmi->phy.ops->clear_hpd)
> + hdmi->phy.ops->clear_hpd(hdmi, hdmi->phy.data);

The probe function contains the same code. Let's inline this function into 
probe, group all HPD-related initialization together and extract that into a 
function to keep probe easy to read. I think you can do that in a separate 
patch.

>   return 0;
>  }
> @@ -1622,13 +1663,14 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi) {
>   u8 old_mask = hdmi->phy_mask;
>
> - if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
> - hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> - else
> - hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> + if (hdmi->phy.ops->update_hpd)
> + hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
> +   hdmi->force, hdmi->disabled,
> +   hdmi->rxsense);
> 
> - if (old_mask != hdmi->phy_mask)
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (old_mask != hdmi->phy_mask &&

phy_mask isn't accessible to glue code, so this test will never be true with 

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #4 from Jean Delvare (jdelv...@suse.de) ---
I know both are possible ;-) But I don't know what are the benefits of both
options. I'd go for just reverting one patch because it seems more simple, but
to be honest I have no idea what that patch was trying to achieve, so I don't
know if we lose anything important by reverting it.

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

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

[Neil Armstrong]

On 03/02/2017 04:58 PM, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
>> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
>> in combination with a very custom PHY.
>>
>> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
>> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
>>
>> The Synopsys DesignWare HDMI TX Controller is integrated like :
>>  ___
>> |HDMI TOP   |<= HPD
>> |___|
>> |  ||
>> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
>> |Controller||
>> |___|<=> DDC
>>
>> And uses the following paths for Pixels Encoding :
>>_   _   
>> vd1---| |-| | | VENC /-|VDAC
>> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
>> osd1--| |-| | | \  | X--HDMI-TX
>> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>>   |  | |
>>   |  \--ENCL---|LVDS
>>   ||
>>
>> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
>> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
>> Synopsys DesignWare HDMI TX Controller.
>>
>> In order to support display modes, the ENCI and ENCP encoders needs very
>> specific parameters for *each* display modes, so usage of the CEA VIC
>> identifier is necessary. But the DVI timings are generated from the
>> drm_mode structure in a generic way.
>>
>> To simplify the first push, only the main CEA modes are supported up to
>> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
>> in order to support the Clock Doubling necessary for these modes.
>>
>> Support for more traditional modes like the EDID fallback modes is planned
>> but will need tome additionnal handling along the CEA modes.
>> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
>> for now only the HDMI 1.4 modes are currently available in the drm_edid
>> implementation.
> 
> Btw, with the neat ascii-art stuff here and in comments in your code, did
> you look into assembling all that into a meson driver documentation
> chapter like the one for vc4 that was just merged?
> -Daniel

Hi Daniel,

Yes, I was thinking about that, but was focused to have all the bits working and
in an upstream-able form.

I will certainly push one in the next few days since I already have a lot of 
text
ready in the comments.

Neil

> 
>>
>> This patchset does :
>>  - Fixes the CRTC handling
>>  - Fixes the registers definitions
>>  - Adds support for device components registration along of-graph
>>  - Adds support for HDMI clocks
>>  - Adds support for HDMI VENC video modes
>>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>>  - Adds CMA node to reserve enougth memory for 1080p display
>>  - Adds the HDMI controller et connector modes on selected boards
>>  - Adds a proper dt-bindings for the HDMI controller et connector
>>  - Updates the MAINTAINERS file to track the new files
>>
>> [1] 
>> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
>> [2] 
>> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
>>
>> Neil Armstrong (11):
>>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
>> sync for vsync commit
>>   drm/meson: Add missing HDMI register
>>   drm/meson: Add support for components
>>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>>   drm/meson: add support for HDMI clock support
>>   drm/meson: Add support for HDMI venc modes and settings
>>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>>   ARM64: dts: meson-gx: Add support for HDMI output
>>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>>   MAINTAINERS: update files for Amlogic DRM Driver
>>
>>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>>  MAINTAINERS|1 +
>>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>>  drivers/gpu/drm/meson/Kconfig  |6 +
>>  

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Markus Heiser]

> Am 02.03.2017 um 16:49 schrieb Mauro Carvalho Chehab 
> :
> 
>>> You can test it with virtualenv  
>>> https://virtualenv.pypa.io/en/stable/userguide/
>>> 
>>> In short:
>>> 
>>> $ cd kernel-src
>>> $ virtualenv myenv
>>> $ source myenv/bin/activate
>>> $ pip install 'Sphinx==1.3.1'
>>> $ make   
>> 
>> Hmm... at least here, building docs-next with Sphinx 1.3.1 inside a
>> virtualenv is broken:
>> 
>> writing output... [ 16%] media/intro 
>>
>> Exception occurred:
>>  File 
>> "/devel/v4l/patchwork/myenv-1.3/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>>  line 671, in depart_document
>>assert not self.context, 'len(context) = %s' % len(self.context)
>> AssertionError: len(context) = 1
>> The full traceback has been saved in /tmp/sphinx-err-W7CPtT.log, if you want 
>> to report the issue to the developers.
>> Please also report this if it was a user error, so that a better error 
>> message can be provided next time.
>> A bug report can be filed in the tracker at 
>> . Thanks!
>> Documentation/Makefile.sphinx:69: recipe for target 'htmldocs' failed
>> make[1]: *** [htmldocs] Error 1
>> Makefile:1450: recipe for target 'htmldocs' failed
>> make: *** [htmldocs] Error 2
>> 
>> Perhaps it is time for us to move minimal requirements to 1.4?
> 
> Hmm... the same happened with 1.4.9 inside virtualenv. It built fine
> with 1.5.2 (for htmldocs).
> 
> Thanks,
> Mauro
> 
> -
> 
> This is the error log with 1.4:
> 
> # Sphinx version: 1.4.9

>  File 
> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
>  line 187, in walkabout
>visitor.dispatch_departure(self)
>  File 
> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/nodes.py",
>  line 1895, in dispatch_departure
>return method(node)
>  File 
> "/devel/v4l/patchwork/myenv-1.4/lib/python2.7/site-packages/docutils/writers/_html_base.py",
>  line 671, in depart_document
>assert not self.context, 'len(context) = %s' % len(self.context)
> AssertionError: len(context) = 1

I guess this is a error from newer docutils, so we have to fix docutils version 
also.

Sphinx itself specifies "docutils>=0.11"

  https://github.com/sphinx-doc/sphinx/blob/1.3.1/setup.py#L52

So I guess it uses a up to date docutils or the ducutils which are already 
installed system wide.

— Markus —
 

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

[PATCH 08/11] ARM64: dts: meson-gx: Add shared CMA dma memory pool

[Neil Armstrong]

The HDMI modes needs more CMA memory to be reserved at boot-time.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 0cbe24b..fc03f0e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -71,6 +71,14 @@
reg = <0x0 0x1000 0x0 0x20>;
no-map;
};
+
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x0 0xbc0>;
+   alignment = <0x0 0x40>;
+   linux,cma-default;
+   };
};
 
cpus {
-- 
1.9.1

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

[PULL] topic/designware-baytrail for 4.12 [UPDATED]

[Daniel Vetter]

Hi Dave,

topic/designware-baytrail-2017-03-02:
Baytrail PMIC vs. PMU race fixes from Hans de Goede

This time the right version (v4), with the compile fix.

Updated pull request with new tag, same story as before

Cheers, Daniel


The following changes since commit 64a577196d66b44e37384bc5c4d78c61f59d5b2a:

  lib/Kconfig: make PRIME_NUMBERS not user selectable. (2017-02-24 12:11:21 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/topic/designware-baytrail-2017-03-02

for you to fetch changes up to 264ec1a8221c60f9ccf13f58ac597da21235132d:

  drm/i915: Listen for PMIC bus access notifications (2017-03-02 15:46:37 +0100)


Baytrail PMIC vs. PMU race fixes from Hans de Goede

This time the right version (v4), with the compile fix.


Hans de Goede (12):
  x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access
  x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
  i2c: designware: Rename accessor_flags to flags
  i2c: designware-baytrail: Pass dw_i2c_dev into helper functions
  i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts
  i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while 
holding the punit semaphore
  i2c: designware-baytrail: Fix race when resetting the semaphore
  i2c: designware-baytrail: Add support for cherrytrail
  i2c: designware-baytrail: Acquire P-Unit access on bus acquire
  i2c: designware-baytrail: Call pmic_bus_access_notifier_chain
  drm/i915: Add intel_uncore_suspend / resume functions
  drm/i915: Listen for PMIC bus access notifications

 arch/x86/include/asm/iosf_mbi.h  | 87 
 arch/x86/platform/intel/iosf_mbi.c   | 49 
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/i915_drv.c  |  6 +-
 drivers/gpu/drm/i915/i915_drv.h  |  7 +--
 drivers/gpu/drm/i915/intel_uncore.c  | 53 +++--
 drivers/i2c/busses/i2c-designware-baytrail.c | 83 ++
 drivers/i2c/busses/i2c-designware-core.c | 14 ++---
 drivers/i2c/busses/i2c-designware-core.h | 13 -
 drivers/i2c/busses/i2c-designware-pcidrv.c   | 26 ++---
 drivers/i2c/busses/i2c-designware-platdrv.c  |  8 ++-
 11 files changed, 290 insertions(+), 57 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

[Daniel Vetter]

On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
> 
> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
> 
> The Synopsys DesignWare HDMI TX Controller is integrated like :
>  ___
> |HDMI TOP   |<= HPD
> |___|
> |  ||
> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
> |Controller||
> |___|<=> DDC
> 
> And uses the following paths for Pixels Encoding :
>_   _   
> vd1---| |-| | | VENC /-|VDAC
> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
> osd1--| |-| | | \  | X--HDMI-TX
> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>   |  | |
>   |  \--ENCL---|LVDS
>   ||
> 
> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
> Synopsys DesignWare HDMI TX Controller.
> 
> In order to support display modes, the ENCI and ENCP encoders needs very
> specific parameters for *each* display modes, so usage of the CEA VIC
> identifier is necessary. But the DVI timings are generated from the
> drm_mode structure in a generic way.
> 
> To simplify the first push, only the main CEA modes are supported up to
> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
> in order to support the Clock Doubling necessary for these modes.
> 
> Support for more traditional modes like the EDID fallback modes is planned
> but will need tome additionnal handling along the CEA modes.
> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
> for now only the HDMI 1.4 modes are currently available in the drm_edid
> implementation.

Btw, with the neat ascii-art stuff here and in comments in your code, did
you look into assembling all that into a meson driver documentation
chapter like the one for vc4 that was just merged?
-Daniel

> 
> This patchset does :
>  - Fixes the CRTC handling
>  - Fixes the registers definitions
>  - Adds support for device components registration along of-graph
>  - Adds support for HDMI clocks
>  - Adds support for HDMI VENC video modes
>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>  - Adds CMA node to reserve enougth memory for 1080p display
>  - Adds the HDMI controller et connector modes on selected boards
>  - Adds a proper dt-bindings for the HDMI controller et connector
>  - Updates the MAINTAINERS file to track the new files
> 
> [1] 
> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
> [2] 
> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
> 
> Neil Armstrong (11):
>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
> sync for vsync commit
>   drm/meson: Add missing HDMI register
>   drm/meson: Add support for components
>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>   drm/meson: add support for HDMI clock support
>   drm/meson: Add support for HDMI venc modes and settings
>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>   ARM64: dts: meson-gx: Add support for HDMI output
>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>   MAINTAINERS: update files for Amlogic DRM Driver
> 
>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>  MAINTAINERS|1 +
>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>  drivers/gpu/drm/meson/Kconfig  |6 +
>  drivers/gpu/drm/meson/Makefile |1 +
>  drivers/gpu/drm/meson/meson_crtc.c |   15 +-
>  drivers/gpu/drm/meson/meson_drv.c  |  113 +-
>  drivers/gpu/drm/meson/meson_drv.h  |3 +
>  drivers/gpu/drm/meson/meson_dw_hdmi.c  |  918 +++
>  drivers/gpu/drm/meson/meson_dw_hdmi.h  | 

[PATCH 04/11] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

[Neil Armstrong]

Since this is managed now by the components code, if CVBS is not available
and HDMI neither, the drm driver won't bind anyway.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c 
b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index a2bcc70..a96fcb4 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -248,7 +248,7 @@ int meson_venc_cvbs_create(struct meson_drm *priv)
 
if (!meson_venc_cvbs_connector_is_available(priv)) {
dev_info(drm->dev, "CVBS Output connector not available\n");
-   return -ENODEV;
+   return 0;
}
 
meson_venc_cvbs = devm_kzalloc(priv->dev, sizeof(*meson_venc_cvbs),
-- 
1.9.1

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

[PATCH 01/11] drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable sync for vsync commit

[Neil Armstrong]

Clean the crtc_enable by using the proper crtc_state instead of the state
of the primary plane state data.

Also fix the dependency to commit the plane changes even if enable is called
after the flush.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 0fe49ec..c986eb0 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,11 +82,18 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
 static void meson_crtc_enable(struct drm_crtc *crtc)
 {
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
-   struct drm_plane *plane = meson_crtc->priv->primary_plane;
+   struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
 
+   DRM_DEBUG_DRIVER("\n");
+
+   if (!crtc_state) {
+   DRM_ERROR("Invalid crtc_state\n");
+   return;
+   }
+
/* Enable VPP Postblend */
-   writel(plane->state->crtc_w,
+   writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
 
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
@@ -101,6 +108,7 @@ static void meson_crtc_disable(struct drm_crtc *crtc)
struct meson_drm *priv = meson_crtc->priv;
 
priv->viu.osd1_enabled = false;
+   priv->viu.osd1_commit = false;
 
/* Disable VPP Postblend */
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
@@ -137,8 +145,7 @@ static void meson_crtc_atomic_flush(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
-   if (priv->viu.osd1_enabled)
-   priv->viu.osd1_commit = true;
+   priv->viu.osd1_commit = true;
 }
 
 static const struct drm_crtc_helper_funcs meson_crtc_helper_funcs = {
-- 
1.9.1

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

[PATCH 09/11] ARM64: dts: meson-gx: Add support for HDMI output

[Neil Armstrong]

Add HDMI output and connector nodes.

Signed-off-by: Neil Armstrong 
---
 .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 39 ++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi  | 32 ++
 .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 23 +
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   | 23 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 12 +++
 .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 23 +
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 13 
 .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 23 +
 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |  4 +++
 9 files changed, 192 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..a84e276 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -98,6 +98,27 @@
clocks = <>;
clock-names = "ext_clock";
};
+
+   cvbs-connector {
+   compatible = "composite-video-connector";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
 };
 
 /* This UART is brought out to the DB9 connector */
@@ -188,3 +209,21 @@
  {
status = "okay";
 };
+
+_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+};
+
+_tx {
+   status = "okay";
+   pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc03f0e..ef0b17c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -397,6 +397,38 @@
cvbs_vdac_port: port@0 {
reg = <0>;
};
+
+   /* HDMI-TX output port */
+   hdmi_tx_port: port@1 {
+   reg = <1>;
+
+   hdmi_tx_out: endpoint {
+   remote-endpoint = <_tx_in>;
+   };
+   };
+   };
+
+   hdmi_tx: hdmi-tx@c883a000 {
+   compatible = "amlogic,meson-gx-dw-hdmi";
+   reg = <0x0 0xc883a000 0x0 0x1c>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   /* VPU VENC Input */
+   hdmi_tx_venc_port: port@0 {
+   reg = <0>;
+
+   hdmi_tx_in: endpoint {
+   remote-endpoint = <_tx_out>;
+   };
+   };
+
+   /* TMDS Output */
+   hdmi_tx_tmds_port: port@1 {
+   reg = <1>;
+   };
};
};
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..a2c999f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -152,6 +152,17 @@
};
};
};
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
 };
 
 _AO {
@@ -245,3 +256,15 @@
remote-endpoint = <_connector_in>;
};
 };
+
+_tx {
+   status = "okay";
+   pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..1c96fc8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ 

[PATCH 10/11] dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension

[Neil Armstrong]

This binding describes the Amlogic Meson specific extension to the
Synopsys Designware HDMI Controller.

Signed-off-by: Neil Armstrong 
---
 .../bindings/display/amlogic,meson-dw-hdmi.txt | 111 +
 1 file changed, 111 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt

diff --git 
a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
new file mode 100644
index 000..7f040ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
@@ -0,0 +1,111 @@
+Amlogic specific extensions to the Synopsys Designware HDMI Controller
+==
+
+The Amlogic Meson Synopsys Designware Integration is composed of :
+- A Synopsys DesignWare HDMI Controller IP
+- A TOP control block controlling the Clocks and PHY
+- A custom HDMI PHY in order to convert video to TMDS signal
+ ___
+|HDMI TOP   |<= HPD
+|___|
+|  ||
+|  Synopsys HDMI   |   HDMI PHY |=> TMDS
+|Controller||
+|___|<=> DDC
+
+The HDMI TOP block only supports HPD sensing.
+The Synopsys HDMI Controller interrupt is routed through the
+TOP Block interrupt.
+Communication to the TOP Block and the Synopsys HDMI Controller is done
+via a pair of dedicated addr+read/write registers.
+The HDMI PHY is configured by registers in the HHI register block.
+
+Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux
+selects either the ENCI encoder for the 576i or 480i formats or the ENCP
+encoder for all the other formats including interlaced HD formats.
+
+The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
+DVI timings for the HDMI controller.
+
+Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
+HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
+audio source interfaces.
+
+Required properties:
+- compatible: value should be different for each SoC family as :
+   - GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"
+   - GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"
+   - GXM (S912) : "amlogic,meson-gxm-dw-hdmi"
+   followed by the common "amlogic,meson-gx-dw-hdmi"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The HDMI interrupt number
+- clocks, clock-names : must have the phandles to the HDMI iahb and isfr 
clocks,
+  and the Amlogic Meson venci clocks as described in
+  Documentation/devicetree/bindings/clock/clock-bindings.txt,
+  the clocks are soc specific, the clock-names should be "iahb", "isfr", 
"venci"
+- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
+  resets as described in :
+  Documentation/devicetree/bindings/reset/reset.txt,
+  the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
+
+Required nodes:
+
+The connections to the HDMI ports are modeled using the OF graph
+bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+The following table lists for each supported model the port number
+corresponding to each HDMI output and input.
+
+   Port 0  Port 1
+-
+ S905 (GXBB)   VENC Input  TMDS Output
+ S905X (GXL)   VENC Input  TMDS Output
+ S905D (GXL)   VENC Input  TMDS Output
+ S912 (GXM)VENC Input  TMDS Output
+
+Example:
+
+hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+};
+
+hdmi_tx: hdmi-tx@c883a000 {
+   compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
+   reg = <0x0 0xc883a000 0x0 0x1c>;
+   interrupts = ;
+   resets = < RESET_HDMITX_CAPB3>,
+< RESET_HDMI_SYSTEM_RESET>,
+< RESET_HDMI_TX>;
+   reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
+   clocks = < CLKID_HDMI_PCLK>,
+< CLKID_CLK81>,
+< CLKID_GCLK_VENCI_INT0>;
+   clock-names = "isfr", "iahb", "venci";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* VPU VENC Input */
+   hdmi_tx_venc_port: port@0 {
+   reg = <0>;
+
+   hdmi_tx_in: endpoint {
+   remote-endpoint = <_tx_out>;
+   };
+   };
+
+   /* TMDS Output */
+   hdmi_tx_tmds_port: port@1 {
+   reg = <1>;
+
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+};
-- 
1.9.1

___
dri-devel mailing list

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Daniel Vetter]

On Thu, Mar 2, 2017 at 4:22 PM, Jonathan Corbet  wrote:
> On Thu, 2 Mar 2017 16:11:08 +0100
> Daniel Vetter  wrote:
>
>> I'll give it a shot at implementing it, but I can't (easily at least) test
>> on sphinx 1.3.
>
> Virtualenv makes that kind of thing pretty easy to do.  Maybe we should
> add a script to create and populate a suitable venv for this kind of
> thing.

Laurent quickly checked v5 of this patch, looks all good now.

> Meanwhile, I've been seeing only parts 1 and 2 of what's clearly a bigger
> series.  Do you want me to carry just these two?

I submitted the entire series to both linux-doc and dri-devel. But
yeah, probably best if you just pull in the first 2 and send me a
topic pull for drm so I can apply the drm stuff on top in drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Thursday 02 Mar 2017 16:29:31 Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if
> provided.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 59 ++---
>  include/drm/bridge/dw_hdmi.h |  9 ++
>  2 files changed, 39 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 026a0dc..653ecd7 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -35,12 +35,6 @@
> 
>  #define HDMI_EDID_LEN512
> 
> -#define RGB  0
> -#define YCBCR444 1
> -#define YCBCR422_16BITS  2
> -#define YCBCR422_8BITS   3
> -#define XVYCC444 4
> -
>  enum hdmi_datamap {
>   RGB444_8B = 0x01,
>   RGB444_10B = 0x03,
> @@ -94,8 +88,8 @@ struct hdmi_vmode {
>  };
> 
>  struct hdmi_data_info {
> - unsigned int enc_in_format;
> - unsigned int enc_out_format;
> + enum dw_hdmi_color_enc_format enc_in_format;
> + enum dw_hdmi_color_enc_format enc_out_format;
>   unsigned int enc_color_depth;
>   unsigned int colorimetry;
>   unsigned int pix_repet_factor;
> @@ -569,7 +563,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>   int color_format = 0;
>   u8 val;
> 
> - if (hdmi->hdmi_data.enc_in_format == RGB) {
> + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB) {
>   if (hdmi->hdmi_data.enc_color_depth == 8)
>   color_format = 0x01;
>   else if (hdmi->hdmi_data.enc_color_depth == 10)
> @@ -580,7 +574,7 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>   color_format = 0x07;
>   else
>   return;
> - } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
> + } else if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444) 
{
>   if (hdmi->hdmi_data.enc_color_depth == 8)
>   color_format = 0x09;
>   else if (hdmi->hdmi_data.enc_color_depth == 10)
> @@ -591,7 +585,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>   color_format = 0x0F;
>   else
>   return;
> - } else if (hdmi->hdmi_data.enc_in_format == YCBCR422_8BITS) {
> + } else if (hdmi->hdmi_data.enc_in_format ==
> + DW_HDMI_ENC_FMT_YCBCR422_8BITS) {
>   if (hdmi->hdmi_data.enc_color_depth == 8)
>   color_format = 0x16;
>   else if (hdmi->hdmi_data.enc_color_depth == 10)
> @@ -627,20 +622,20 @@ static int is_color_space_conversion(struct dw_hdmi
> *hdmi)
> 
>  static int is_color_space_decimation(struct dw_hdmi *hdmi)
>  {
> - if (hdmi->hdmi_data.enc_out_format != YCBCR422_8BITS)
> + if (hdmi->hdmi_data.enc_out_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS)
>   return 0;
> - if (hdmi->hdmi_data.enc_in_format == RGB ||
> - hdmi->hdmi_data.enc_in_format == YCBCR444)
> + if (hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_RGB ||
> + hdmi->hdmi_data.enc_in_format == DW_HDMI_ENC_FMT_YCBCR444)
>   return 1;
>   return 0;
>  }
> 
>  static int is_color_space_interpolation(struct dw_hdmi *hdmi)
>  {
> - if (hdmi->hdmi_data.enc_in_format != YCBCR422_8BITS)
> + if (hdmi->hdmi_data.enc_in_format != DW_HDMI_ENC_FMT_YCBCR422_8BITS)
>   return 0;
> - if (hdmi->hdmi_data.enc_out_format == RGB ||
> - hdmi->hdmi_data.enc_out_format == YCBCR444)
> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB ||
> + hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_YCBCR444)
>   return 1;
>   return 0;
>  }
> @@ -652,13 +647,14 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi
> *hdmi) u32 csc_scale = 1;
> 
>   if (is_color_space_conversion(hdmi)) {
> - if (hdmi->hdmi_data.enc_out_format == RGB) {
> + if (hdmi->hdmi_data.enc_out_format == DW_HDMI_ENC_FMT_RGB) {
>   if (hdmi->hdmi_data.colorimetry ==
>   HDMI_COLORIMETRY_ITU_601)
>   csc_coeff = _coeff_rgb_out_eitu601;
>   else
>   csc_coeff = _coeff_rgb_out_eitu709;
> - } else if (hdmi->hdmi_data.enc_in_format == RGB) {
> + } else if (hdmi->hdmi_data.enc_in_format ==
> + DW_HDMI_ENC_FMT_RGB) {
>   if (hdmi->hdmi_data.colorimetry ==
>   HDMI_COLORIMETRY_ITU_601)
>   csc_coeff = _coeff_rgb_in_eitu601;
> @@ -730,8 +726,8 @@ static void 

[PATCH 11/11] MAINTAINERS: update files for Amlogic DRM Driver

[Neil Armstrong]

This patch adds the dw-hdmi bindings to maintained files.

Signed-off-by: Neil Armstrong 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d302c0..3869d7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4255,6 +4255,7 @@ W:http://linux-meson.com/
 S: Supported
 F: drivers/gpu/drm/meson/
 F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+F: Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
 
 DRM DRIVERS FOR EXYNOS
 M: Inki Dae 
-- 
1.9.1

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

[PATCH 07/11] drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY

[Neil Armstrong]

The Amlogic Meson GXBB/GXL/GXM SoCs embeds a Synopsys DesignWare HDMI TX
Controller with a custom Bridge + PHY around the Controller.

This driver makes uses of all the custom PHY plat data callbacks and enables
the compatible HDMI modes to be configured as a drm_encoder instance.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/Kconfig |   6 +
 drivers/gpu/drm/meson/Makefile|   1 +
 drivers/gpu/drm/meson/meson_drv.h |   3 +
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 918 ++
 drivers/gpu/drm/meson/meson_dw_hdmi.h | 146 ++
 5 files changed, 1074 insertions(+)
 create mode 100644 drivers/gpu/drm/meson/meson_dw_hdmi.c
 create mode 100644 drivers/gpu/drm/meson/meson_dw_hdmi.h

diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 99719af..3ce51d8 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -7,3 +7,9 @@ config DRM_MESON
select DRM_GEM_CMA_HELPER
select VIDEOMODE_HELPERS
select REGMAP_MMIO
+
+config DRM_MESON_DW_HDMI
+   tristate "HDMI Synopsys Controller support for Amlogic Meson Display"
+   depends on DRM_MESON
+   default y if DRM_MESON
+   select DRM_DW_HDMI
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 92cf845..c5c4cc3 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -2,3 +2,4 @@ meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o 
meson_venc_cvbs.o
 meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
+obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 6195327..5e8b392 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -47,6 +47,9 @@ struct meson_drm {
 
struct {
unsigned int current_mode;
+   bool hdmi_repeat;
+   bool venc_repeat;
+   bool hdmi_use_enci;
} venc;
 };
 
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
new file mode 100644
index 000..3250140
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -0,0 +1,918 @@
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong 
+ * Copyright (C) 2015 Amlogic, Inc. 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 as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "meson_drv.h"
+#include "meson_venc.h"
+#include "meson_vclk.h"
+#include "meson_dw_hdmi.h"
+#include "meson_registers.h"
+
+#define DRIVER_NAME "meson-dw-hdmi"
+#define DRIVER_DESC "Amlogic Meson HDMI-TX DRM driver"
+
+/*
+ * HDMI Output is composed of :
+ * - A Synopsys DesignWare HDMI Controller IP
+ * - A TOP control block controlling the Clocks and PHY
+ * - A custom HDMI PHY in order convert video to TMDS signal
+ *  ___
+ * |HDMI TOP   |<= HPD
+ * |___|
+ * |  ||
+ * |  Synopsys HDMI   |   HDMI PHY |=> TMDS
+ * |Controller||
+ * |___|<=> DDC
+ *
+ * The HDMI TOP block only supports HPD sensing.
+ * The Synopsys HDMI Controller interrupt is routed
+ * through the TOP Block interrupt.
+ * Communication to the TOP Block and the Synopsys
+ * HDMI Controller is done a pair of addr+read/write
+ * registers.
+ * The HDMI PHY is configured by registers in the
+ * HHI register block.
+ *
+ * Pixel data arrives in 4:4:4 format from the VENC
+ * block and the VPU HDMI mux selects either the ENCI
+ * encoder for the 576i or 480i formats or the ENCP
+ * encoder for all the other formats including
+ * interlaced HD formats.
+ * The VENC uses a DVI encoder on top of the ENCI
+ * or ENCP encoders to generate DVI timings for the
+ * HDMI controller.
+ *
+ * GXBB, GXL and GXM embeds the Synopsys DesignWare
+ * HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
+ * audio source interfaces.
+ *
+ * We handle the following features :
+ * - HPD Rise & Fall interrupt
+ * - HDMI Controller Interrupt
+ * - HDMI