[Bug 90217] Counter Strike Global Offensive: GPU fault after a while

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90217

--- Comment #2 from Christoph Haag  ---
Created attachment 115456
  --> https://bugs.freedesktop.org/attachment.cgi?id=115456=edit
dmesg with graphical output hang

It can also have more severe consequences and require a reboot, see dmesg.

I'll use R600_DEBUG=ps,vs,gs next time. It can take quite a while to trigger
it, I hope it won't produce too much data.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/ed955017/attachment.html>


[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90056

Tom Stellard  changed:

   What|Removed |Added

 Attachment #115423|0   |1
is obsolete||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/5f21d81a/attachment.html>


[PATCH] drm/radeon: add a GPU reset counter queryable by userspace

2015-04-29 Thread Marek Olšák
From: Marek Olšák 

Userspace will be able to tell whether a GPU reset occured by comparing
an old referece value of the counter with a new value.

Signed-off-by: Marek Olšák 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 2 ++
 drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
 drivers/gpu/drm/radeon/radeon_kms.c| 3 +++
 include/uapi/drm/radeon_drm.h  | 1 +
 5 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d2abe48..c2b345a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2436,6 +2436,7 @@ struct radeon_device {
atomic64_t  vram_usage;
atomic64_t  gtt_usage;
atomic64_t  num_bytes_moved;
+   atomic_tgpu_reset_counter;
/* ACPI interface */
struct radeon_atif  atif;
struct radeon_atcs  atcs;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b7ca4c5..13e207e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1725,6 +1725,8 @@ int radeon_gpu_reset(struct radeon_device *rdev)
return 0;
}

+   atomic_inc(>gpu_reset_counter);
+
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 7d620d4..5751446 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -90,9 +90,10 @@
  *CS to GPU on >= r600
  *   2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command parsing 
support
  *   2.42.0 - Add VCE/VUI (Video Usability Information) support
+ *   2.43.0 - RADEON_INFO_GPU_RESET_COUNTER
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   42
+#define KMS_DRIVER_MINOR   43
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 7b2a733..9632e88 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -576,6 +576,9 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (radeon_get_allowed_info_register(rdev, *value, value))
return -EINVAL;
break;
+   case RADEON_INFO_GPU_RESET_COUNTER:
+   *value = atomic_read(>gpu_reset_counter);
+   break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 871e73f..573cb86 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -1038,6 +1038,7 @@ struct drm_radeon_cs {
 #define RADEON_INFO_CURRENT_GPU_SCLK   0x22
 #define RADEON_INFO_CURRENT_GPU_MCLK   0x23
 #define RADEON_INFO_READ_REG   0x24
+#define RADEON_INFO_GPU_RESET_COUNTER  0x25

 struct drm_radeon_info {
uint32_trequest;
-- 
2.1.0



[PATCH 8/8] drm/i915: Backlight control using CRC PMIC based PWM driver

2015-04-29 Thread Shobhit Kumar
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks

v2: Modify to use pwm_config callback

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_drv.h   |  5 +++
 drivers/gpu/drm/i915/intel_dsi.c   |  6 +++
 drivers/gpu/drm/i915/intel_panel.c | 92 +++---
 3 files changed, 98 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 897f17d..b4ebe3b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,7 +182,12 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+
+   /* PWM chip */
+   struct pwm_device *pwm;
+
struct backlight_device *device;
+
} backlight;

void (*backlight_power)(struct intel_connector *, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index be55ffa..83c4540 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)

intel_dsi_port_enable(encoder);
}
+
+   intel_panel_enable_backlight(intel_dsi->attached_connector);
 }

 static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder)

DRM_DEBUG_KMS("\n");

+   intel_panel_disable_backlight(intel_dsi->attached_connector);
+
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi->ports)
@@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
}

intel_panel_init(_connector->panel, fixed_mode, NULL);
+   intel_panel_setup_backlight(connector,
+   (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A: PIPE_B);

return;

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 08532d4..5700f6f 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,8 +32,12 @@

 #include 
 #include 
+#include 
 #include "intel_drv.h"

+#define CRC_PMIC_PWM_PERIOD_NS 21333
+#define CRC_PMIC_PWM_STEPS 255
+
 void
 intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
   struct drm_display_mode *adjusted_mode)
@@ -536,6 +540,15 @@ static u32 vlv_get_backlight(struct intel_connector 
*connector)
return _vlv_get_backlight(dev, pipe);
 }

+static u32 vlv_get_mipi_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+   int duty_ns;
+
+   duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
+   return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
+}
+
 static u32 intel_panel_get_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
@@ -616,6 +629,14 @@ static void vlv_set_backlight(struct intel_connector 
*connector, u32 level)
I915_WRITE(VLV_BLC_PWM_CTL(pipe), tmp | level);
 }

+static void vlv_set_mipi_backlight(struct intel_connector *connector, u32 
level)
+{
+   struct intel_panel *panel = >panel;
+   int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+   pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+}
+
 static void
 intel_panel_actually_set_backlight(struct intel_connector *connector, u32 
level)
 {
@@ -741,6 +762,16 @@ static void vlv_disable_backlight(struct intel_connector 
*connector)
I915_WRITE(VLV_BLC_PWM_CTL2(pipe), tmp & ~BLM_PWM_ENABLE);
 }

+static void vlv_disable_mipi_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+
+   /* Disable the backlight */
+   pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
+   usleep_range(2000, 3000);
+   pwm_disable(panel->backlight.pwm);
+}
+
 void intel_panel_disable_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
@@ -947,6 +978,16 @@ static void vlv_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(VLV_BLC_PWM_CTL2(pipe), ctl2 | BLM_PWM_ENABLE);
 }

+static void vlv_enable_mipi_backlight(struct intel_connector *connector)
+{
+   struct intel_panel *panel = >panel;
+   int duty_ns = DIV_ROUND_UP(
+   panel->backlight.level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+   pwm_enable(panel->backlight.pwm);
+   pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
+}
+
 void intel_panel_enable_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
@@ -1299,6 +1340,34 @@ static int 

[PATCH 7/8] drm/i915: Use the CRC gpio for panel enable/disable

2015-04-29 Thread Shobhit Kumar
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.

v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code (Ville)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_dsi.c | 32 ++--
 drivers/gpu/drm/i915/intel_dsi.h |  6 ++
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5196642..be55ffa 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "i915_drv.h"
 #include "intel_drv.h"
 #include "intel_dsi.h"
@@ -415,6 +416,12 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)

DRM_DEBUG_KMS("\n");

+   /* Panel Enable over CRC PMIC */
+   if (intel_dsi->gpio_panel)
+   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
+
+   msleep(intel_dsi->panel_on_delay);
+
/* Disable DPOunit clock gating, can stall pipe
 * and we need DPLL REFA always enabled */
tmp = I915_READ(DPLL(pipe));
@@ -432,8 +439,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
/* put device in ready state */
intel_dsi_device_ready(encoder);

-   msleep(intel_dsi->panel_on_delay);
-
drm_panel_prepare(intel_dsi->panel);

for_each_dsi_port(port, intel_dsi->ports)
@@ -576,6 +581,10 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)

msleep(intel_dsi->panel_off_delay);
msleep(intel_dsi->panel_pwr_cycle_delay);
+
+   /* Panel Disable over CRC PMIC */
+   if (intel_dsi->gpio_panel)
+   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
 }

 static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
@@ -955,6 +964,11 @@ static void intel_dsi_encoder_destroy(struct drm_encoder 
*encoder)
/* XXX: Logically this call belongs in the panel driver. */
drm_panel_remove(intel_dsi->panel);
}
+
+   /* dispose of the gpios */
+   if (intel_dsi->gpio_panel)
+   gpiod_put(intel_dsi->gpio_panel);
+
intel_encoder_destroy(encoder);
 }

@@ -1071,6 +1085,20 @@ void intel_dsi_init(struct drm_device *dev)
goto err;
}

+   /*
+* In case of BYT with CRC PMIC, we need to use GPIO for
+* Panel control.
+*/
+   if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+   intel_dsi->gpio_panel =
+   gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
+
+   if (IS_ERR(intel_dsi->gpio_panel)) {
+   DRM_ERROR("Failed to own gpio for panel control\n");
+   intel_dsi->gpio_panel = NULL;
+   }
+   }
+
intel_encoder->type = INTEL_OUTPUT_DSI;
intel_encoder->cloneable = 0;
drm_connector_init(dev, connector, _dsi_connector_funcs,
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 2784ac4..bf1bade 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -29,6 +29,9 @@
 #include 
 #include "intel_drv.h"

+#define PPS_BLC_PMIC   0
+#define PPS_BLC_SOC1
+
 /* Dual Link support */
 #define DSI_DUAL_LINK_NONE 0
 #define DSI_DUAL_LINK_FRONT_BACK   1
@@ -42,6 +45,9 @@ struct intel_dsi {
struct drm_panel *panel;
struct intel_dsi_host *dsi_hosts[I915_MAX_PORTS];

+   /* GPIO Desc for CRC based Panel control */
+   struct gpio_desc *gpio_panel;
+
struct intel_connector *attached_connector;

/* bit mask of ports being driven */
-- 
2.1.0



[PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

2015-04-29 Thread Shobhit Kumar
The Crystalcove PMIC controls PWM signals and this driver exports that
capability as a PWM chip driver. This is platform device implementtaion
of the drivers/mfd cell device for CRC PMIC

v2: Use the existing config callback with duty_ns and period_ns(Thierry)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/pwm/Kconfig   |   7 +++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-crc.c | 171 ++
 3 files changed, 179 insertions(+)
 create mode 100644 drivers/pwm/pwm-crc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f4..954da3e 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -183,6 +183,13 @@ config PWM_LPC32XX
  To compile this driver as a module, choose M here: the module
  will be called pwm-lpc32xx.

+config PWM_CRC
+   bool "Intel Crystalcove (CRC) PWM support"
+   depends on X86 && INTEL_SOC_PMIC
+   help
+ Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
+ control.
+
 config PWM_LPSS
tristate "Intel LPSS PWM support"
depends on X86
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index ec50eb5..3d38fed 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
 obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)  += pwm-twl-led.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
+obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
new file mode 100644
index 000..987f3b4
--- /dev/null
+++ b/drivers/pwm/pwm-crc.c
@@ -0,0 +1,171 @@
+/*
+ * pwm-crc.c - Intel Crystal Cove PWM Driver
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Shobhit Kumar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PWM0_CLK_DIV   0x4B
+#define  PWM_OUTPUT_ENABLE (1<<7)
+#define  PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
+#define  PWM_DIV_CLK_100   0x63 /* DIVIDECLK = BASECLK/100 */
+#define  PWM_DIV_CLK_128   0x7F /* DIVIDECLK = BASECLK/128 */
+
+#define PWM0_DUTY_CYCLE0x4E
+#define BACKLIGHT_EN   0x51
+
+#define PWM_MAX_LEVEL  0xFF
+
+#define PWM_BASE_CLK   6000/* 6 MHz */
+#define PWM_MAX_PERIOD_NS  21333 /* 46.875KHz */
+
+/**
+ * struct crystalcove_pwm - Crystal Cove PWM controller
+ * @chip: the abstract pwm_chip structure.
+ * @regmap: the regmap from the parent device.
+ */
+struct crystalcove_pwm {
+   struct pwm_chip chip;
+   struct platform_device *pdev;
+   struct regmap *regmap;
+};
+
+static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
+{
+   return container_of(pc, struct crystalcove_pwm, chip);
+}
+
+static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
+
+   return 0;
+}
+
+static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+
+   regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
+}
+
+static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+   struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
+   struct device *dev = _pwm->pdev->dev;
+   int level, percent;
+
+   if (period_ns > PWM_MAX_PERIOD_NS) {
+   dev_err(dev, "un-supported period_ns\n");
+   return -1;
+   }
+
+   if (pwm->period != period_ns) {
+   int clk_div;
+
+   /* changing the clk divisor, need to disable fisrt */
+   crc_pwm_disable(c, pwm);
+   clk_div = PWM_BASE_CLK * period_ns / 100;
+
+   regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
+   clk_div | PWM_OUTPUT_ENABLE);
+
+   /* enable back */
+   crc_pwm_enable(c, pwm);
+   }
+
+   if (duty_ns > period_ns) {
+   dev_err(dev, "duty cycle cannot be greater than cycle 
period\n");
+   return -1;
+   }
+
+   /* change the pwm duty cycle */
+   percent = duty_ns * 100 / period_ns;
+   level = percent * PWM_MAX_LEVEL / 100;
+   regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
+
+   return 0;

[PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM

2015-04-29 Thread Shobhit Kumar
On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)

v2: Remove the lookup table on driver unload (Thierry)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index f3d918e..a00ddd9 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

 /* Lookup table for the Panel Enable/Disable line as GPIO signals */
@@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
},
 };

+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup crc_pwm_lookup[] = {
+   PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
PWM_POLARITY_NORMAL),
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
/* Add lookup table binding for Panel Control to the GPIO Chip */
gpiod_add_lookup_table(_gpio_table);

+   /* Add lookup table for crc-pwm */
+   pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)
/* Remove lookup table for Panel Control from the GPIO Chip */
gpiod_remove_lookup_table(_gpio_table);

+   /* remove crc-pwm lookup table */
+   pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
+
mfd_remove_devices(>dev);

return 0;
-- 
2.1.0



[PATCH 4/8] drivers/mfd: Add PWM cell device for Crystalcove PMIC

2015-04-29 Thread Shobhit Kumar
Needed for PWM control suuported by the PMIC

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_crc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 4cc1b32..8839e25 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = "crystal_cove_pmic",
},
+   {
+   .name = "crystal_cove_pwm",
+   },
 };

 static const struct regmap_config crystal_cove_regmap_config = {
-- 
2.1.0



[PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal

2015-04-29 Thread Shobhit Kumar
On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load

v2: Make the lookup table static (Thierry)
Remove the lookup table during driver remove (Thierry)

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_core.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_core.c 
b/drivers/mfd/intel_soc_pmic_core.c
index 7b50b6b..f3d918e 100644
--- a/drivers/mfd/intel_soc_pmic_core.c
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -24,8 +24,19 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_soc_pmic_core.h"

+/* Lookup table for the Panel Enable/Disable line as GPIO signals */
+static struct gpiod_lookup_table panel_gpio_table = {
+   /* Intel GFX is consumer */
+   .dev_id = ":00:02.0",
+   .table = {
+   /* Panel EN/DISABLE */
+   GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
+   },
+};
+
 static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 {
struct gpio_desc *desc;
@@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
if (ret)
dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);

+   /* Add lookup table binding for Panel Control to the GPIO Chip */
+   gpiod_add_lookup_table(_gpio_table);
+
ret = mfd_add_devices(dev, -1, config->cell_dev,
  config->n_cell_devs, NULL, 0,
  regmap_irq_get_domain(pmic->irq_chip_data));
@@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client *i2c)

regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);

+   /* Remove lookup table for Panel Control from the GPIO Chip */
+   gpiod_remove_lookup_table(_gpio_table);
+
mfd_remove_devices(>dev);

return 0;
-- 
2.1.0



[PATCH 2/8] drivers/pwm/core: Add support to remove registered consumer lookup tables

2015-04-29 Thread Shobhit Kumar
In case some drivers are unloading, they can remove lookup tables which
they would have registered during their load time to avoid redundant
entries if loaded again

v2: Ccing maintainers

CC: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Signed-off-by: Shobhit Kumar 
---
 drivers/pwm/core.c  | 17 +
 include/linux/pwm.h |  5 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ba34c7d..d2fe7c8d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -586,6 +586,23 @@ void pwm_add_table(struct pwm_lookup *table, size_t num)
 }

 /**
+ * pwm_remove_table() - un-register PWM device consumers
+ * @table: array of consumers to un-register
+ * @num: number of consumers in table
+ */
+void pwm_remove_table(struct pwm_lookup *table, size_t num)
+{
+   mutex_lock(_lookup_lock);
+
+   while (num--) {
+   list_del(>list);
+   table++;
+   }
+
+   mutex_unlock(_lookup_lock);
+}
+
+/**
  * pwm_get() - look up and request a PWM device
  * @dev: device for PWM consumer
  * @con_id: consumer name
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index e90628c..cfe2d8d 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -290,10 +290,15 @@ struct pwm_lookup {

 #if IS_ENABLED(CONFIG_PWM)
 void pwm_add_table(struct pwm_lookup *table, size_t num);
+void pwm_remove_table(struct pwm_lookup *table, size_t num);
 #else
 static inline void pwm_add_table(struct pwm_lookup *table, size_t num)
 {
 }
+
+static inline void pwm_remove_table(struct pwm_lookup *table, size_t num)
+{
+}
 #endif

 #ifdef CONFIG_PWM_SYSFS
-- 
2.1.0



[PATCH 1/8] drivers/gpio/gpiolib: Add support for removing registered consumer lookup table

2015-04-29 Thread Shobhit Kumar
In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload

v2: Ccing maintainers

Cc: Samuel Ortiz 
Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: Thierry Reding 
Reviewed-by: Alexandre Courbot 
Signed-off-by: Shobhit Kumar 
---
 drivers/gpio/gpiolib.c   | 13 +
 include/linux/gpio/machine.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 59eaa23..2420af9 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
*table)
mutex_unlock(_lookup_lock);
 }

+/**
+ * gpiod_remove_lookup_table() - unregister GPIO device consumers
+ * @table: table of consumers to unregister
+ */
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
+{
+   mutex_lock(_lookup_lock);
+
+   list_del(>list);
+
+   mutex_unlock(_lookup_lock);
+}
+
 static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
  unsigned int idx,
  enum gpio_lookup_flags *flags)
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index e270614..c0d712d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -57,5 +57,6 @@ struct gpiod_lookup_table {
 }

 void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);

 #endif /* __LINUX_GPIO_MACHINE_H */
-- 
2.1.0



[PATCH 0/8] Crystalcove (CRC) PMIC based panel and pwm control

2015-04-29 Thread Shobhit Kumar
Hi All,
On some of the BYT devices, for DSI panels, the panel enable/disable signals
and backlight control are done using the Crystalcove PMIC. This series provides
support for the same and has been reviewed earlier on - 
http://lists.freedesktop.org/archives/intel-gfx/2015-March/061908.html

This series addresses the review comments with two of the patches already merged
in linux-next as - 

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e189ca56d91bbf1d3fe2f88ab6858bf919d42adf
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c264f1110d27185f8531602f5fce400a6bbce946

Basically following are implemented - 

1. GPIO control for panel enable/disable with GFX device as consumer
2. New PWM chip driver added for CRC PMIC based backlight control
3. i915 is modified to use the CRC gpio chip and the CRC PWM chip to do 
   backlight control. This is now added in the generic panel backlight
   control infrastructure

All these patches have been tested on AsusT100 and working fine using 
/sys/class/backlight/intel_backlight interface.

Patches are also verified on android-x86 tree for AsusT100.

Regards
Shobhit

Shobhit Kumar (8):
  drivers/gpio/gpiolib: Add support for removing registered consumer
lookup table
  drivers/pwm/core: Add support to remove registered consumer lookup
tables
  drivers/mfd: Add lookup table for Panel Control as GPIO signal
  drivers/mfd: Add PWM cell device for Crystalcove PMIC
  drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM
  drivers/pwm: Add Crystalcove (CRC) PWM driver
  drm/i915: Use the CRC gpio for panel enable/disable
  drm/i915: Backlight control using CRC PMIC based PWM driver

 drivers/gpio/gpiolib.c |  13 +++
 drivers/gpu/drm/i915/intel_drv.h   |   5 ++
 drivers/gpu/drm/i915/intel_dsi.c   |  38 -
 drivers/gpu/drm/i915/intel_dsi.h   |   6 ++
 drivers/gpu/drm/i915/intel_panel.c |  92 ++--
 drivers/mfd/intel_soc_pmic_core.c  |  29 +++
 drivers/mfd/intel_soc_pmic_crc.c   |   3 +
 drivers/pwm/Kconfig|   7 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/core.c |  17 
 drivers/pwm/pwm-crc.c  | 171 +
 include/linux/gpio/machine.h   |   1 +
 include/linux/pwm.h|   5 ++
 13 files changed, 381 insertions(+), 7 deletions(-)
 create mode 100644 drivers/pwm/pwm-crc.c

-- 
2.1.0



[PATCH 1/4] drm: consolidate common list implementations

2015-04-29 Thread Emil Velikov
On 24/04/15 15:13, Alex Deucher wrote:
> This is used by radeon and freedreno and will be used
> by amdgpu.  I looked at switching to libdrm_lists.h,
> but it's pretty horrible.  E.g., DRMLISTFOREACHENTRYSAFE.
> 
It does have one advantage though - it's typeless. Thus it allows
nouveau and intel to have their custom list implementations. For example
 - struct nouveau_list (plain double list)
 - struct {mem_,}block (double list with some extra bookkeeping)

This change might cause small issues with Jerome's bof replay tool
(joujou), although I should have it merged with libdrm as this lands (or
shortly after).

With the comments sent out earlier for 3/4 (v4) and 4/4(v2), feel free
to add Reviewed-by: Emil Velikov , fwiw.

Thanks
Emil



[pull] radeon drm-fixes-4.1

2015-04-29 Thread Alex Deucher
Hi Dave,

Fixes for 4.1 for radeon all destined for stable:
- fix fallout from the audio rework
- VM fixes
- other assorted bug fixes

The following changes since commit 59fd7e4b0b0769638b5162e56c28bbb027a118d3:

  Merge tag 'drm-intel-next-fixes-2015-04-25' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-04-27 10:35:15 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.1

for you to fetch changes up to 9fb2bcf928ed5c664affaeb7edf9cc19f590b9f3:

  drm/radeon: fix userptr return value checking (v2) (2015-04-27 11:38:28 -0400)


Alex Deucher (7):
  drm/radeon: fix ordering of AVI packet setup
  drm/radeon: drop dce6_dp_enable
  drm/radeon/audio: don't enable packets until the end
  drm/radeon: only mark audio as connected if the monitor supports it (v3)
  drm/radeon: only enable audio streams if the monitor supports it
  drm/radeon: adjust pll when audio is not enabled
  drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5

Christian König (4):
  drm/radeon: fix lockup when BOs aren't part of the VM on release
  drm/radeon: reset BOs address after clearing it.
  drm/radeon: check new address before removing old one
  drm/radeon: fix userptr return value checking (v2)

Michel Dänzer (1):
  drm/radeon: Use drm_calloc_ab for CS relocs

 drivers/gpu/drm/radeon/atombios_crtc.c |  3 ++
 drivers/gpu/drm/radeon/atombios_encoders.c |  6 ++--
 drivers/gpu/drm/radeon/dce6_afmt.c | 25 --
 drivers/gpu/drm/radeon/evergreen_hdmi.c| 53 +++---
 drivers/gpu/drm/radeon/r600_hdmi.c |  9 ++---
 drivers/gpu/drm/radeon/radeon_audio.c  | 30 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  8 +++--
 drivers/gpu/drm/radeon/radeon_cs.c |  4 +--
 drivers/gpu/drm/radeon/radeon_mn.c | 10 +++---
 drivers/gpu/drm/radeon/radeon_vm.c | 36 +++-
 drivers/gpu/drm/radeon/si_dpm.c|  1 +
 11 files changed, 95 insertions(+), 90 deletions(-)


[Bug 90218] Kerbal Space Program crashes with Souther Islands

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90218

--- Comment #2 from Lucas  ---
I am starting to believe the problem is hardware overheat: had a relatively
long session with the PC case open and no incident. Can it be considered a bug?
Is overheat prevention a tractable issue in software?

Anyway, I tried to run with R600_DEBUG=ps,vs,gs, but I am not sure how to
retrieve the information you need. I have the game from Steam, I ran it by
typing in the terminal:

$ export R600_DEBUG=ps,vs,gs
$ steam -applaunch 220200

And it output to the terminal the usual, nothing specific to Mesa.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/eea04dcc/attachment.html>


[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76130

--- Comment #12 from Jim  ---
I just realized that another performance issue I had is actually caused by this
bug.  This occurs with kernel 3.10.0-229.1.2.el7.centos.plus (and probably all
kernels).  After I suspend/resume scrolling in gnome-terminal is very slow. 
For example if I 'cat /var/log/messages' then scrolling in gnome-terminal is
very jerky.  Likewise scrolling from within vi or less (/var/log/messages is a
good way to test) is also painfully slow.  Booting with "radeon.dpm=0" also
solves this gnome-terminal scroll problem for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/cdafd0cf/attachment.html>


[PATCH] devicetree: Add vendor prefix for Shelly, Inc.

2015-04-29 Thread Nicolas Ferre
Le 24/03/2015 17:12, Nicolas Ferre a écrit :
> Signed-off-by: Nicolas Ferre 

Ping?

> ---
> Thierry,
> 
> Here it is ;-)
> 
> Bye,
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index a9eeaa0c5867..1b0f5b797cd5 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -165,6 +165,7 @@ sbs   Smart Battery System
>  schindlerSchindler
>  seagate  Seagate Technology PLC
>  semtech  Semtech Corporation
> +shelly   Shelly, Inc.
>  sil  Silicon Image
>  silabs   Silicon Laboratories
>  siliconmitus Silicon Mitus, Inc.
> 


-- 
Nicolas Ferre


[PATCH] devicetree: Add vendor prefix for Foxlink Group

2015-04-29 Thread Nicolas Ferre
Le 24/03/2015 17:12, Nicolas Ferre a écrit :
> Signed-off-by: Nicolas Ferre 
> ---
> Thierry,
> 
> Boris added the support for a Foxlink panel in this commit: 102932b0e474
> (drm/panel: add support for Foxlink FL500WVR00-A0T panel). Here is the vendor
> prefix.

Ping?

> 
> Bye,
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 1b0f5b797cd5..e9fca088ba1a 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -73,6 +73,7 @@ everspinEverspin Technologies, Inc.
>  excito   Excito
>  fcs  Fairchild Semiconductor
>  firefly  Firefly
> +foxlink  Foxlink Group
>  fsl  Freescale Semiconductor
>  GEFanuc  GE Fanuc Intelligent Platforms Embedded Systems, Inc.
>  gef  GE Fanuc Intelligent Platforms Embedded Systems, Inc.
> 


-- 
Nicolas Ferre


[PATCH libdrm 0/5] modetest: fix misc when terminates modetest

2015-04-29 Thread Emil Velikov
On 22/04/15 02:05, Joonyoung Shim wrote:
> Hi Emil,
> 
> On 04/22/2015 05:16 AM, Emil Velikov wrote:
>> Hi Joonyoung,
>>
>> On 13/04/15 08:31, Joonyoung Shim wrote:
>>> Hi all,
>>>
>>> This patchset is to fix properly about buffer and framebuffer resources
>>> when terminates modetest of libdrm.
>>>
>> The series looks great (incl. the MAKE_RGB_INFO fix) and barring any
>> objections I'll push it by the end of the week. Just a small sidenote -
>> some of the commit messages are a bit hard to read. Hope you don't mind
>> if I change them slightly before pushing.
> 
> It's ok, i guess i should thank you.
> 
In case you've missed it - I corrected the value for invalid fb_id.
According to the kernel and other users - 0 should be used, as (unsigned
int)-1 (used in the series) is valid one, albeit hard to hit.

Thanks again for the fixes.

-Emil


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #29 from Dieter Nützel  ---
(In reply to Dieter Nützel from comment #28)
> NO, no "git bisect..."
> 
> git checkout -b v3.19|v4.0|4.1-rc1   (checkout a branch)

git checkout BRANCHNAME

> and then
> git revert xxx
> 
> https://www.atlassian.com/git/tutorials/undoing-changes
> http://landley.net/writing/git-bisect-howto.html

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


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #28 from Dieter Nützel  ---
NO, no "git bisect..."

git checkout -b v3.19|v4.0|4.1-rc1   (checkout a branch)
and then
git revert xxx

https://www.atlassian.com/git/tutorials/undoing-changes
http://landley.net/writing/git-bisect-howto.html

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


[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76130

--- Comment #11 from Jim  ---
I can duplicate this problem with CentOS 7.1.

When I run kernel 3.10.0-229.1.2.el7.centos.plus I don't see (or at least
notice) the performance issue after resuming from suspend, however I do receive
the same errors.  Additionally X will randomly hang (maybe 5% of the time) when
I resume, I suspect this may be related to my video card (since those are the
only errors I ever see when resuming).

When I run kernel 4.0.0-1.el7.elrepo.x86_64 I do have the performance issue
after resuming from suspend (and receive the same errors).  For me I see the
huge graphics performance hit when I connect to a Windows 7 PC with xfreerdp. 
It's so slow it's unusable.  However if I perform the same xfreerdp connection
before I ever suspend/resume my PC it's very fast and responsive.

I found a work around which is to use the "radeon.dpm=0" kernel boot option.  I
did this by following these steps:
vi /etc/default/grub
-Append "radeon.dpm=0" to the end of the "GRUB_CMDLINE_LINUX" option:
grub2-mkconfig -o /boot/grub2/grub.cfg

Booting with "radeon.dpm=0" switched me to the "profile" pm method as shown
with this command:
cat /sys/class/drm/card0/device/power_method
profile

With "radeon.dpm=0" I no longer get any error messages and I no longer have any
performance issues after resuming from suspend.  Time will tell if it fixes my
random hang issue.  I haven't checked yet if there's any noticeable power draw
difference.

Below I've pasted some relevant hardware and log info.

My hardware:
Motherboard = GA-790FXTA-UD5/GA-790FXTA-UD5, BIOS F3j
CPU = AMD Phenom II X4 910e Deneb Quad-Core 2.6GHz Socket AM3 65W Desktop
Processor 
Video card = Gigabyte Radeon HD 4550 512 MB DDR3 (AMD RV710)

Two pages with useful information related to radeon power management:
https://wiki.archlinux.org/index.php/ATI#Dynamic_power_management
http://www.x.org/wiki/RadeonFeature/#index3h2

grep -i rv7 /var/log/messages
//With kernel 3.10.0-229.1.2.el7.centos.plus
Apr 29 08:18:58 black kernel: [drm:rv730_stop_dpm] *ERROR* Could not force DPM
to low
Apr 29 08:18:58 black kernel: [drm:rv770_dpm_set_power_state] *ERROR*
rv770_set_sw_state failed
//With kernel 4.0.0-1.el7.elrepo.x86_64, note that the error messages have
slightly changed (added "[radeon]")
Apr 29 09:21:49 black kernel: [drm:rv730_stop_dpm [radeon]] *ERROR* Could not
force DPM to low
Apr 29 09:22:40 black kernel: [drm:rv770_dpm_set_power_state [radeon]] *ERROR*
rv770_set_sw_state failed

glxinfo |grep "OpenGL renderer"
OpenGL renderer string: Gallium 0.4 on AMD RV710

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/0acfd9a3/attachment-0001.html>


[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76130

--- Comment #10 from Jim  ---
Ardien at https://bugzilla.kernel.org/show_bug.cgi?id=71891 they state
"...found in the kernel source file drivers/gpu/drm/radeon/rv770.c. Despite the
name this function is used for RV710, RV730 (yours) and RV770.".  So my
uneducated guess is that the patch does apply to you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/6d9e0741/attachment.html>


[PATCH] libgencec: Add userspace library for the generic CEC kernel interface

2015-04-29 Thread Emil Velikov
Hi Kamil,

Allow me to put a few suggestions:

On 29 April 2015 at 11:02, Kamil Debski  wrote:
> This is the first version of the libGenCEC library. It was designed to
> act as an interface between the generic CEC kernel API and userspace
> applications. It provides a simple interface for applications and an
> example application that can be used to test the CEC functionality.
>
> signed-off-by: Kamil Debski 
> ---
>  AUTHORS  |1 +
>  INSTALL  |9 +
>  LICENSE  |  202 
>  Makefile.am  |4 +
>  README   |   22 ++
>  configure.ac |   24 ++
>  doc/index.html   |  345 +++
>  examples/Makefile.am |4 +
>  examples/cectest.c   |  631 
> ++
>  include/gencec.h |  255 
>  src/Makefile.am  |4 +
>  src/gencec.c |  445 +++
>  12 files changed, 1946 insertions(+)
>  create mode 100644 AUTHORS
>  create mode 100644 INSTALL
>  create mode 100644 LICENSE
>  create mode 100644 Makefile.am
>  create mode 100644 README
>  create mode 100644 configure.ac
>  create mode 100644 doc/index.html
>  create mode 100644 examples/Makefile.am
>  create mode 100644 examples/cectest.c
>  create mode 100644 include/gencec.h
>  create mode 100644 m4/.gitkeep
>  create mode 100644 src/Makefile.am
>  create mode 100644 src/gencec.c
>
> diff --git a/AUTHORS b/AUTHORS
> new file mode 100644
> index 000..e4b7117
> --- /dev/null
> +++ b/AUTHORS
> @@ -0,0 +1 @@
> +Kamil Debski 
> diff --git a/INSTALL b/INSTALL
> new file mode 100644
> index 000..aac6101
> --- /dev/null
> +++ b/INSTALL
> @@ -0,0 +1,9 @@
> +To install libgencec run following commands:
> +
> +autoreconf -i
You might want add --force in here, otherwise the files will stay
as-is if you update libtool and friends "mid-flight".
Many projects include autogen.sh like the following. Feel free to add
it to libgencec.

$cat autogen.sh
#! /bin/sh

srcdir=`dirname "$0"`
test -z "$srcdir" && srcdir=.

ORIGDIR=`pwd`
cd "$srcdir"

autoreconf --force --verbose --install || exit 1
cd "$ORIGDIR" || exit $?

if test -z "$NOCONFIGURE"; then
"$srcdir"/configure "$@"
fi



> --- /dev/null
> +++ b/configure.ac
> @@ -0,0 +1,24 @@

You can save yourself some headaches if you restrict old and/or buggy
autoconf versions which don't work with the project.
If I have to guess 2.60 should be ok.
AC_PREREQ([XXX])

> +AC_INIT([libgencec], [0.1], [k.debski at samsung.com])
> +AM_INIT_AUTOMAKE([-Wall -Werror foreign])
> +
> +AC_PROG_CC
> +AM_PROG_AR
> +AC_CONFIG_MACRO_DIR([m4])
> +AC_DEFINE([_GNU_SOURCE], [], [Use GNU extensions])
> +

Same for libtool - 2.2 perhaps ?
LT_PREREQ([XXX])

> +LT_INIT
> +
> +# Checks for typedefs, structures, and compiler characteristics.
> +AC_C_INLINE
> +AC_TYPE_SIZE_T
> +AC_TYPE_UINT16_T
> +AC_TYPE_UINT32_T
> +AC_TYPE_UINT8_T
> +
> +#AC_CHECK_LIB([c], [malloc])
> +# Checks for library functions.
> +#AC_FUNC_MALLOC
> +
> +AC_CONFIG_FILES([Makefile src/Makefile examples/Makefile])
Would be nice if the library provides libgencec.pc file. This way any
users can avoid the explicit header/library check, amongst other
useful bits.

> --- /dev/null
> +++ b/examples/Makefile.am
> @@ -0,0 +1,4 @@
> +bin_PROGRAMS = cectest
> +cectest_SOURCES = cectest.c
> +AM_CPPFLAGS=-I$(top_srcdir)/include/
> +AM_LDFLAGS=-L../src/ -lgencec
The following seems more common (in the projects I've seen at least)
cectest_LDADD = $(top_builddir)/src/libgencec.la

> diff --git a/m4/.gitkeep b/m4/.gitkeep
> new file mode 100644
> index 000..e69de29
Haven't seen any projects doing this. Curious what the benefits of
keeping and empty folder might be ?

> diff --git a/src/Makefile.am b/src/Makefile.am
> new file mode 100644
> index 000..cb024f0
> --- /dev/null
> +++ b/src/Makefile.am
> @@ -0,0 +1,4 @@
> +lib_LTLIBRARIES = libgencec.la
> +libgencec_la_SOURCES = gencec.c
> +libgencec_la_LDFLAGS = -version-info 0:1:0
You might want to add -no-undefined in order to prevent having a
library with unresolved symbols.

Hope you find the above useful :-)

Cheers
Emil


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #27 from George Cheban  ---
Thank you, Sir! :)
Sorry, how can I choose a kernel version? By "git bisect good v4.0" and then
revert 1a81*  and make?

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


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #26 from Dieter Nützel  ---
(In reply to George Cheban from comment #25)
> Sorry, I'm noob :)

Your are NO noob, your are learning (on a big, big piece of code)!

> Do I need to do next steps? :
> 
> /*After "bisect"*/
> $ cd /linux
> $ git bisect reset
> $ git revert 1a81b94
> $ make oldconfig
> # make -3j && make modules_install && make install

Exactly.

> Will the latest kernel compile from from the cloned repo from
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git? 

It should, but 'latest stuff' could brake, so better use a 'release' (4.1-rc1,
etc.).

> Correct me, if I'm wrong, please.

You are on a good way.

-Dieter

PS I'm German, so not nativ, too.

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


[PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal

2015-04-29 Thread Lee Jones
By the way, your subject lines are messed up.

They should adhere to the conventions laid down by the Maintainers.

`git log --oneline -- drivers/`

> On some Intel SoC platforms, the panel enable/disable signals are
> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
> table for gpio-crystalcove chip during CRC driver load
> 
> v2: Make the lookup table static (Thierry)
> Remove the lookup table during driver remove (Thierry)
> 
> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/mfd/intel_soc_pmic_core.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
> b/drivers/mfd/intel_soc_pmic_core.c
> index 7b50b6b..f3d918e 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -24,8 +24,19 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_soc_pmic_core.h"
>  
> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
> +static struct gpiod_lookup_table panel_gpio_table = {
> + /* Intel GFX is consumer */
> + .dev_id = ":00:02.0",
> + .table = {
> + /* Panel EN/DISABLE */
> + GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
> + },
> +};
> +
>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>  {
>   struct gpio_desc *desc;
> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>   if (ret)
>   dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>  
> + /* Add lookup table binding for Panel Control to the GPIO Chip */
> + gpiod_add_lookup_table(_gpio_table);
> +
>   ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
> *i2c)
>  
>   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>  
> + /* Remove lookup table for Panel Control from the GPIO Chip */
> + gpiod_remove_lookup_table(_gpio_table);
> +
>   mfd_remove_devices(>dev);
>  
>   return 0;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal

2015-04-29 Thread Lee Jones
On Wed, 29 Apr 2015, Shobhit Kumar wrote:

> On some Intel SoC platforms, the panel enable/disable signals are
> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
> table for gpio-crystalcove chip during CRC driver load
> 
> v2: Make the lookup table static (Thierry)
> Remove the lookup table during driver remove (Thierry)
> 
> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/mfd/intel_soc_pmic_core.c | 17 +
>  1 file changed, 17 insertions(+)

I have no idea what this stuff is, but it looks plausible.

For my own reference:
  Acked-by: Lee Jones 

> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
> b/drivers/mfd/intel_soc_pmic_core.c
> index 7b50b6b..f3d918e 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -24,8 +24,19 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_soc_pmic_core.h"
>  
> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
> +static struct gpiod_lookup_table panel_gpio_table = {
> + /* Intel GFX is consumer */
> + .dev_id = ":00:02.0",
> + .table = {
> + /* Panel EN/DISABLE */
> + GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
> + },
> +};
> +
>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>  {
>   struct gpio_desc *desc;
> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>   if (ret)
>   dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>  
> + /* Add lookup table binding for Panel Control to the GPIO Chip */
> + gpiod_add_lookup_table(_gpio_table);
> +
>   ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
> *i2c)
>  
>   regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>  
> + /* Remove lookup table for Panel Control from the GPIO Chip */
> + gpiod_remove_lookup_table(_gpio_table);
> +
>   mfd_remove_devices(>dev);
>  
>   return 0;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH 4/8] drivers/mfd: Add PWM cell device for Crystalcove PMIC

2015-04-29 Thread Lee Jones
On Wed, 29 Apr 2015, Shobhit Kumar wrote:

> Needed for PWM control suuported by the PMIC
> 
> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/mfd/intel_soc_pmic_crc.c | 3 +++
>  1 file changed, 3 insertions(+)

For my own reference:
  Acked-by: Lee Jones 

> diff --git a/drivers/mfd/intel_soc_pmic_crc.c 
> b/drivers/mfd/intel_soc_pmic_crc.c
> index 4cc1b32..8839e25 100644
> --- a/drivers/mfd/intel_soc_pmic_crc.c
> +++ b/drivers/mfd/intel_soc_pmic_crc.c
> @@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
>   {
>   .name = "crystal_cove_pmic",
>   },
> + {
> + .name = "crystal_cove_pwm",
> + },
>  };
>  
>  static const struct regmap_config crystal_cove_regmap_config = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH 5/8] drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM

2015-04-29 Thread Lee Jones
On Wed, 29 Apr 2015, Shobhit Kumar wrote:

> On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> entry for the same to be used by the consumer (Intel GFX)
> 
> v2: Remove the lookup table on driver unload (Thierry)
> 
> CC: Samuel Ortiz 
> Cc: Linus Walleij 
> Cc: Alexandre Courbot 
> Cc: Thierry Reding 
> Signed-off-by: Shobhit Kumar 
> ---
>  drivers/mfd/intel_soc_pmic_core.c | 12 
>  1 file changed, 12 insertions(+)

How do you expect this set to be managed?

Acked-by: Lee Jones 

> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
> b/drivers/mfd/intel_soc_pmic_core.c
> index f3d918e..a00ddd9 100644
> --- a/drivers/mfd/intel_soc_pmic_core.c
> +++ b/drivers/mfd/intel_soc_pmic_core.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_soc_pmic_core.h"
>  
>  /* Lookup table for the Panel Enable/Disable line as GPIO signals */
> @@ -37,6 +38,11 @@ static struct gpiod_lookup_table panel_gpio_table = {
>   },
>  };
>  
> +/* PWM consumed by the Intel GFX */
> +static struct pwm_lookup crc_pwm_lookup[] = {
> + PWM_LOOKUP("crystal_cove_pwm", 0, ":00:02.0", "pwm_backlight", 0, 
> PWM_POLARITY_NORMAL),
> +};
> +
>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>  {
>   struct gpio_desc *desc;
> @@ -99,6 +105,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>   /* Add lookup table binding for Panel Control to the GPIO Chip */
>   gpiod_add_lookup_table(_gpio_table);
>  
> + /* Add lookup table for crc-pwm */
> + pwm_add_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> +
>   ret = mfd_add_devices(dev, -1, config->cell_dev,
> config->n_cell_devs, NULL, 0,
> regmap_irq_get_domain(pmic->irq_chip_data));
> @@ -121,6 +130,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
> *i2c)
>   /* Remove lookup table for Panel Control from the GPIO Chip */
>   gpiod_remove_lookup_table(_gpio_table);
>  
> + /* remove crc-pwm lookup table */
> + pwm_remove_table(crc_pwm_lookup, ARRAY_SIZE(crc_pwm_lookup));
> +
>   mfd_remove_devices(>dev);
>  
>   return 0;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH libdrm 3/3] xf86drm: simplify drmMalloc/drmFree

2015-04-29 Thread Emil Velikov
On 28 April 2015 at 18:02, Alex Deucher  wrote:
> On Tue, Apr 28, 2015 at 10:09 AM, Emil Velikov  
> wrote:
>> Signed-off-by: Emil Velikov 
>
> For the series:
> Reviewed-by: Alex Deucher 
>
Thank you. I'll give it another day or two before pushing (just in case).

-Emil


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #25 from George Cheban  ---
Sorry, I'm noob :)
Do I need to do next steps? :

/*After "bisect"*/
$ cd /linux
$ git bisect reset
$ git revert 1a81b94
$ make oldconfig
# make -3j && make modules_install && make install

Will the latest kernel compile from from the cloned repo from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git? 

Correct me, if I'm wrong, please.

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


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #24 from Dieter Nützel  ---
(In reply to George Cheban from comment #23)
> > But have you tried running any 'newer' kernel with
> > 
> > git revert 1a81b94   (c6x: remove unused parameter in Kconfig)?
> 
> Please, can you write a more detailed instruction what to do?

Sure, I hope...;-)

But really, if one get a good/real 'first bad commit', you can try to revert
it.

Grep latest kernel (your 3.16 or maybe 4.0).
Try to revert the bad commit, in this case:

git revert 1a81b94(the first 7 digits are enough)

configure and build kernel.

Cross your fingers...

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


[PATCH 3/4] drm: add libdrm_amdgpu (v4)

2015-04-29 Thread Emil Velikov
Hi Alex,

On 24 April 2015 at 16:23, Alex Deucher  wrote:
> This is the new ioctl wrapper used by the new admgpu driver.
> It's primarily used by xf86-video-amdgpu and mesa.
>
> v2: fix amdgpu_drm.h install
> v3: Integrate some of the sugestions from Emil:
> clean up Makefile.am, configure.ac
> capitalize header guards
> fix _FILE_OFFSET_BITS with config.h
> use drm_mmap/drm_munmap
> Remove unused ARRAY_SIZE macro
> use shared list implementation
> use shared math implementation
> use drmGetNodeTypeFromFd helper
Huge thanks for picking my suggestions. There are a couple which got
lost considering the size of the patch. Do let me know if I have
missed the plot and some of them are not applicable.

> v4: remove unused tiling defines
>
> Signed-off-by: Alex Deucher 
> ---
>  Makefile.am|5 +
>  Makefile.sources   |1 +
>  amdgpu/Makefile.am |   53 ++
>  amdgpu/amdgpu.h| 1276 
> 
>  amdgpu/amdgpu_bo.c |  626 ++
>  amdgpu/amdgpu_cs.c |  981 ++
>  amdgpu/amdgpu_device.c |  241 +
>  amdgpu/amdgpu_gpu_info.c   |  275 ++
>  amdgpu/amdgpu_internal.h   |  208 
>  amdgpu/amdgpu_vamgr.c  |  169 ++
>  amdgpu/libdrm_amdgpu.pc.in |   10 +
>  amdgpu/util_hash.c |  382 +
>  amdgpu/util_hash.h |   99 
>  amdgpu/util_hash_table.c   |  257 +
>  amdgpu/util_hash_table.h   |   65 +++
>  configure.ac   |   19 +
>  include/drm/amdgpu_drm.h   |  580 
>  17 files changed, 5247 insertions(+)
>  create mode 100644 amdgpu/Makefile.am
>  create mode 100644 amdgpu/amdgpu.h
>  create mode 100644 amdgpu/amdgpu_bo.c
>  create mode 100644 amdgpu/amdgpu_cs.c
>  create mode 100644 amdgpu/amdgpu_device.c
>  create mode 100644 amdgpu/amdgpu_gpu_info.c
>  create mode 100644 amdgpu/amdgpu_internal.h
>  create mode 100644 amdgpu/amdgpu_vamgr.c
>  create mode 100644 amdgpu/libdrm_amdgpu.pc.in
>  create mode 100644 amdgpu/util_hash.c
>  create mode 100644 amdgpu/util_hash.h
>  create mode 100644 amdgpu/util_hash_table.c
>  create mode 100644 amdgpu/util_hash_table.h
>  create mode 100644 include/drm/amdgpu_drm.h
>

> --- /dev/null
> +++ b/amdgpu/amdgpu_device.c

> +#define RENDERNODE_MINOR_MASK 0xff7f
> +
You can drop this if you go for my suggestions below.

> +static unsigned fd_hash(void *key)
> +{
> +   int fd = PTR_TO_UINT(key);
> +   struct stat stat;
> +   fstat(fd, );
> +
> +   if (!S_ISCHR(stat.st_mode))
Afaict this cannot/should not happen - might as well drop it ?

> +   return stat.st_dev ^ stat.st_ino;
> +   else
> +   return stat.st_dev ^ (stat.st_rdev & RENDERNODE_MINOR_MASK);
One cannot get the render/primary node relation by masking/oring the 7th bit.

You can get the primary device name (via drmGetPrimaryDeviceNameFromFd
) and fstat it.

> +}
> +
> +static int fd_compare(void *key1, void *key2)
> +{
> +   int fd1 = PTR_TO_UINT(key1);
> +   int fd2 = PTR_TO_UINT(key2);
> +   struct stat stat1, stat2;
> +   fstat(fd1, );
> +   fstat(fd2, );
> +
> +   if (!S_ISCHR(stat1.st_mode) || !S_ISCHR(stat2.st_mode))
As above.

> +   return stat1.st_dev != stat2.st_dev ||
> +   stat1.st_ino != stat2.st_ino;
> +else
> +   return major(stat1.st_rdev) != major(stat2.st_rdev) ||
> +   (minor(stat1.st_rdev) & RENDERNODE_MINOR_MASK) !=
> +   (minor(stat2.st_rdev) & RENDERNODE_MINOR_MASK);
Similar to above - please compare the primary device name for both fds.

> +}
> +

> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> new file mode 100644
> index 000..477cfd8
> --- /dev/null
> +++ b/include/drm/amdgpu_drm.h


> +struct drm_amdgpu_ctx_in {
> +   uint32_top;
> +   uint32_tflags;
> +   uint32_tctx_id;
> +   uint32_tpad;
> +};
> +

> +/** The same structure is shared for input/output */
> +struct drm_amdgpu_gem_metadata {
> +   uint32_thandle; /* GEM Object handle */
> +   uint32_top; /** Do we want get or set metadata */
> +   struct {
> +   uint64_tflags;
> +   uint64_ttiling_info; /* family specific tiling info */
> +   uint32_tdata_size_bytes;
Considering that this is fed directly into the kernel we should
pad/align it - similar to drm_amdgpu_ctx_in above.

> +   uint32_tdata[64];
> +   } data;
> +};
> +
> +struct drm_amdgpu_gem_mmap_in {
> +   uint32_t handle;/** the GEM object handle */
Ditto.

> +};
> +

> +struct drm_amdgpu_wait_cs_in {
> +   uint64_t handle;
> +   uint64_t timeout;
> +   uint32_t ip_type;
> +   uint32_t ip_instance;
> +   uint32_t ring;

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #23 from George Cheban  ---

> But have you tried running any 'newer' kernel with
> 
> git revert 1a81b94   (c6x: remove unused parameter in Kconfig)?

Please, can you write a more detailed instruction what to do?

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


[Bug 89534] GPU lockup with wine

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89534

--- Comment #14 from Tom Stellard  ---
Can you run the program with the environment variable R600_DEBUG=ps,gs,vs and
post the output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/f1a3b017/attachment.html>


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

Dieter Nützel  changed:

   What|Removed |Added

 CC||Dieter at nuetzel-hh.de

--- Comment #22 from Dieter Nützel  ---
(In reply to George Cheban from comment #21)
> Made a bisect, it took me about 10 day for it wooh... :)
> You can see show HEAD and log in attachment.

Good job!

But have you tried running any 'newer' kernel with

git revert 1a81b94   (c6x: remove unused parameter in Kconfig)?

When it works, there is a real starting point.

Hang in there!

Greetings,
   Dieter

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


[Bug 90217] Counter Strike Global Offensive: GPU fault after a while

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90217

--- Comment #1 from Tom Stellard  ---
Can you run the program with the environment variable R600_DEBUG=ps,vs,gs and
post the output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/19af61b8/attachment.html>


[PATCH] drm: add tests/amdgpu (v3)

2015-04-29 Thread Alex Deucher
This adds some basic unit tests for the new amdgpu driver.

v2: use common util_math.h
v3: implement suggestions from Emil
replace malloc/memset with calloc
make header guards all caps
use posix_memalign rather than mem_align
replace malloc with calloc for pm4 allocations
make CU_SuiteInfo static
fix Makefile.am
fix fd numbering
use drmGetVersion/drmFreeVersion rather than open coding it
close fd, clean up CU registry on error

Signed-off-by: Alex Deucher 
---
 configure.ac|  23 ++
 tests/Makefile.am   |   6 +
 tests/amdgpu/Makefile.am|  26 ++
 tests/amdgpu/amdgpu_test.c  | 220 
 tests/amdgpu/amdgpu_test.h  | 119 +++
 tests/amdgpu/basic_tests.c  | 669 
 tests/amdgpu/bo_tests.c | 151 
 tests/amdgpu/cs_tests.c | 319 +
 tests/amdgpu/uvd_messages.h | 813 
 tests/kmstest/main.c|   1 +
 10 files changed, 2347 insertions(+)
 create mode 100644 tests/amdgpu/Makefile.am
 create mode 100644 tests/amdgpu/amdgpu_test.c
 create mode 100644 tests/amdgpu/amdgpu_test.h
 create mode 100644 tests/amdgpu/basic_tests.c
 create mode 100644 tests/amdgpu/bo_tests.c
 create mode 100644 tests/amdgpu/cs_tests.c
 create mode 100644 tests/amdgpu/uvd_messages.h

diff --git a/configure.ac b/configure.ac
index a8997c6..8bd12ea 100644
--- a/configure.ac
+++ b/configure.ac
@@ -350,6 +350,28 @@ fi
 AM_CONDITIONAL(HAVE_AMDGPU, [test "x$AMDGPU" = xyes])
 if test "x$AMDGPU" = xyes; then
AC_DEFINE(HAVE_AMDGPU, 1, [Have amdgpu support])
+
+   # Detect cunit library
+   PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes], 
[have_cunit=no])
+
+   # If pkg-config does not find cunit, check it using AC_CHECK_LIB.  We
+   # do this because Debian (Ubuntu) lacks pkg-config file for cunit.
+   if test "x${have_cunit}" = "xno"; then
+   AC_CHECK_LIB([cunit], [CU_initialize_registry], 
[have_cunit=yes], [have_cunit=no])
+   if test "x${have_cunit}" = "xyes"; then
+   CUNIT_LIBS="-lcunit"
+   CUNIT_CFLAGS=""
+   AC_SUBST([CUNIT_LIBS])
+   AC_SUBST([CUNIT_CFLAGS])
+   fi
+   fi
+
+   AM_CONDITIONAL(HAVE_CUNIT, [test "x$have_cunit" != "xno"])
+   AC_DEFINE(HAVE_CUNIT, [test "x$have_cunit" != "xno"], [Enable CUNIT 
Have amdgpu support])
+
+   if test "x$have_cunit" = "xno"; then
+   AC_MSG_WARN([Could not find cunit library. Disabling amdgpu 
tests])
+   fi
 fi

 AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes])
@@ -466,6 +488,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/proptest/Makefile
tests/radeon/Makefile
+   tests/amdgpu/Makefile
tests/vbltest/Makefile
tests/exynos/Makefile
tests/tegra/Makefile
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 069285f..a980b3d 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -8,6 +8,12 @@ if HAVE_RADEON
 SUBDIRS += radeon
 endif

+if HAVE_AMDGPU
+if HAVE_CUNIT
+SUBDIRS += amdgpu
+endif
+endif
+
 if HAVE_EXYNOS
 SUBDIRS += exynos
 endif
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
new file mode 100644
index 000..6840131
--- /dev/null
+++ b/tests/amdgpu/Makefile.am
@@ -0,0 +1,26 @@
+AM_CFLAGS = \
+   -I $(top_srcdir)/include/drm \
+   -I $(top_srcdir)/amdgpu \
+   -I $(top_srcdir)
+
+LDADD = $(top_builddir)/libdrm.la \
+   $(top_builddir)/amdgpu/libdrm_amdgpu.la \
+   $(CUNIT_LIBS)
+
+if HAVE_INSTALL_TESTS
+bin_PROGRAMS = \
+   amdgpu_test
+else
+noinst_PROGRAMS = \
+   amdgpu_test
+endif
+
+amdgpu_test_CPPFLAGS = $(CUNIT_CFLAGS)
+
+amdgpu_test_SOURCES = \
+   amdgpu_test.c \
+   amdgpu_test.h \
+   basic_tests.c \
+   bo_tests.c \
+   cs_tests.c \
+   uvd_messages.h
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
new file mode 100644
index 000..c8432fa
--- /dev/null
+++ b/tests/amdgpu/amdgpu_test.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * 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, sublicense,
+ * 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 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 

[PATCH 01/10] drm: rcar-du: Document the rcar_du_crtc structure

2015-04-29 Thread Laurent Pinchart
Hi Sergei,

Thank you for the review.

On Wednesday 29 April 2015 14:33:31 Sergei Shtylyov wrote:
> On 4/29/2015 3:37 AM, Laurent Pinchart wrote:
> > Document the structure fields using kerneldoc.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >   drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 14 ++
> >   1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index 5d9aa9b33769..e72f15c8c706
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -22,6 +22,20 @@
> > 
> >   struct rcar_du_group;
> > 
> > +/*
> 
> Kerneldoc needs /** at the start of comment.

I have mixed feelings about that when documenting a driver, as generating 
documentation for the driver internals might not be very useful. On the other 
hand, the kernel documentation generation process doesn't include drivers 
randomly, so I suppose it can't hurt. I'll change it.

> > + * rcar_du_crtc - the CRTC, representing a DU superposition processor
> 
> Kerneldoc needs *struct* before the name.

Oops, my bad, I'll fix that.

Same for patch 02/10.

-- 
Regards,

Laurent Pinchart



[PATCH 02/10] drm: rcar-du: Document the rcar_du_plane_state structure

2015-04-29 Thread Sergei Shtylyov
On 4/29/2015 3:37 AM, Laurent Pinchart wrote:

> Document the structure fields using kerneldoc.

> Signed-off-by: Laurent Pinchart 
> ---
>   drivers/gpu/drm/rcar-du/rcar_du_plane.h | 11 ++-
>   1 file changed, 10 insertions(+), 1 deletion(-)

> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> index abff0ebeb195..5d2b764919d8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -46,11 +46,20 @@ struct rcar_du_planes {
>   struct drm_property *zpos;
>   };
>
> +/*
> + * rcar_du_plane_state - Driver-specific plane state

Same comments as for the previous patch.

[...]

WBR, Sergei



[PATCH 01/10] drm: rcar-du: Document the rcar_du_crtc structure

2015-04-29 Thread Sergei Shtylyov
Hello.

On 4/29/2015 3:37 AM, Laurent Pinchart wrote:

> Document the structure fields using kerneldoc.

> Signed-off-by: Laurent Pinchart 
> ---
>   drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 14 ++
>   1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 5d9aa9b33769..e72f15c8c706 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -22,6 +22,20 @@
>
>   struct rcar_du_group;
>
> +/*

Kerneldoc needs /** at the start of comment.

> + * rcar_du_crtc - the CRTC, representing a DU superposition processor

Kerneldoc needs *struct* before the name.

[...]

WBR, Sergei



[PATCH 4/4] drm: add tests/amdgpu (v2)

2015-04-29 Thread Emil Velikov
Hi Alex,

On 24 April 2015 at 16:13, Alex Deucher  wrote:
> This adds some basic unit tests for the new amdgpu driver.
>
> v2: use common util_math.h
>
Can I put forward a few suggestions:
 - Can we use calloc over malloc. It will likely save you/others some
headaches in the future.
 - Use capital letters for header guards
 - Annotate the CU_SuiteInfo/CU_TestInfo as static.

> Signed-off-by: Alex Deucher 
> ---
>  configure.ac|  23 ++
>  tests/Makefile.am   |   6 +
>  tests/amdgpu/Makefile.am|  24 ++
>  tests/amdgpu/amdgpu_test.c  | 241 +
>  tests/amdgpu/amdgpu_test.h  | 119 +++
>  tests/amdgpu/basic_tests.c  | 676 
>  tests/amdgpu/bo_tests.c | 151 
>  tests/amdgpu/cs_tests.c | 319 +
>  tests/amdgpu/uvd_messages.h | 813 
> 
>  tests/kmstest/main.c|   1 +
>  10 files changed, 2373 insertions(+)
>  create mode 100644 tests/amdgpu/Makefile.am
>  create mode 100644 tests/amdgpu/amdgpu_test.c
>  create mode 100644 tests/amdgpu/amdgpu_test.h
>  create mode 100644 tests/amdgpu/basic_tests.c
>  create mode 100644 tests/amdgpu/bo_tests.c
>  create mode 100644 tests/amdgpu/cs_tests.c
>  create mode 100644 tests/amdgpu/uvd_messages.h
>

> diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
> new file mode 100644
> index 000..ba7339d
> --- /dev/null
> +++ b/tests/amdgpu/Makefile.am
> @@ -0,0 +1,24 @@

> +LDADD = $(top_builddir)/libdrm.la \
> +   $(top_builddir)/amdgpu/libdrm_amdgpu.la
> +
...
> +amdgpu_test_LDFLAGS  = $(CUNIT_LIBS)
LDFLAGS should not be used for LIBS (normally) - please fold it with
LDADD above;

amdgpu_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/amdgpu/libdrm_amdgpu.la \
$(CUNIT_LIBS)

> +amdgpu_test_SOURCES = \
> +   amdgpu_test.c \
> +   basic_tests.c \
> +   bo_tests.c \
> +   cs_tests.c
Please add the headers in the list.
amdgpu_test.h
uvd_messages.h

> diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
> new file mode 100644
> index 000..fc14b70
> --- /dev/null
> +++ b/tests/amdgpu/amdgpu_test.c
> @@ -0,0 +1,241 @@

> +int drm_amdgpu[MAX_CARDS_SUPPORTED];
We're using only a single one in the tests. Why the array ?

> +int main(int argc, char **argv)
> +{

> +   for (i = 0; i < MAX_CARDS_SUPPORTED; i++)
> +   drm_amdgpu[i] = 0;
0 is a valid fd number.

> +   /* Try to open all possible radeon connections
> +* Right now: Open only the 0.
> +*/
> +   printf("Try to open the card 0..\n");
> +   drm_amdgpu[0] = open("/dev/dri/card0", O_RDWR | O_CLOEXEC);
> +
> +   if (drm_amdgpu[0] == 1) {
1 is a valid fd number. Perhaps < 0 ?

> +   /** Display version of DRM driver */
> +   drmVersionPtr retval;
> +   drm_version_t *version = drmMalloc(sizeof(*version));
> +
> +   version->name_len= 0;
> +   version->name= NULL;
> +   version->date_len= 0;
> +   version->date= NULL;
> +   version->desc_len= 0;
> +   version->desc= NULL;
> +
> +   if (drmIoctl(drm_amdgpu[0], DRM_IOCTL_VERSION, version)) {
> +   perror("Could not get DRM driver version\n");
> +   drmFree(version);
> +   exit(EXIT_FAILURE);
> +   }
> +
> +   if (version->name_len)
> +   version->name= drmMalloc(version->name_len + 1);
> +   if (version->date_len)
> +   version->date= drmMalloc(version->date_len + 1);
> +   if (version->desc_len)
> +   version->desc= drmMalloc(version->desc_len + 1);
> +
> +   if (drmIoctl(drm_amdgpu[0], DRM_IOCTL_VERSION, version)) {
> +   perror("Could not get information about DRM driver");
> +   drmFree(version);
> +   exit(EXIT_FAILURE);
> +   }
> +
> +   /* The results might not be null-terminated strings. Add zero */
> +   if (version->name_len)
> +   version->name[version->name_len] = '\0';
> +   if (version->date_len)
> +   version->date[version->date_len] = '\0';
> +   if (version->desc_len)
> +   version->desc[version->desc_len] = '\0';
> +
> +   printf("DRM Driver: Name: [%s] : Date [%s] : Description [%s]\n",
> +   version->name, version->date, version->desc);
> +
Please use drmGetVersion/drmFreeVersion rather than open coding it.
This implementation leaks memory.

> +   drmFree(version);
> +
> +   /* Initialize test suites to run */
> +
> +   /* initialize the CUnit test registry */
> +   if (CUE_SUCCESS != CU_initialize_registry())
Swap CUE_SUCCESS and CU_initialize_registry() ?

> +   return CU_get_error();
Close the fd before return/exit(). The rest of the could use it as well.

> +
> +   /* Register suites. */
> +   if (CU_register_suites(suites) != CUE_SUCCESS) {
> +   

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #21 from George Cheban  ---
Made a bisect, it took me about 10 day for it wooh... :)
You can see show HEAD and log in attachment.

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


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #20 from George Cheban  ---
Created attachment 175241
  --> https://bugzilla.kernel.org/attachment.cgi?id=175241=edit
bisect log

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


[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-29 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #19 from George Cheban  ---
Created attachment 175231
  --> https://bugzilla.kernel.org/attachment.cgi?id=175231=edit
Head v2

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


[PATCH] libgencec: Add userspace library for the generic CEC kernel interface

2015-04-29 Thread Kamil Debski
This is the first version of the libGenCEC library. It was designed to
act as an interface between the generic CEC kernel API and userspace
applications. It provides a simple interface for applications and an
example application that can be used to test the CEC functionality.

signed-off-by: Kamil Debski 
---
 AUTHORS  |1 +
 INSTALL  |9 +
 LICENSE  |  202 
 Makefile.am  |4 +
 README   |   22 ++
 configure.ac |   24 ++
 doc/index.html   |  345 +++
 examples/Makefile.am |4 +
 examples/cectest.c   |  631 ++
 include/gencec.h |  255 
 src/Makefile.am  |4 +
 src/gencec.c |  445 +++
 12 files changed, 1946 insertions(+)
 create mode 100644 AUTHORS
 create mode 100644 INSTALL
 create mode 100644 LICENSE
 create mode 100644 Makefile.am
 create mode 100644 README
 create mode 100644 configure.ac
 create mode 100644 doc/index.html
 create mode 100644 examples/Makefile.am
 create mode 100644 examples/cectest.c
 create mode 100644 include/gencec.h
 create mode 100644 m4/.gitkeep
 create mode 100644 src/Makefile.am
 create mode 100644 src/gencec.c

diff --git a/AUTHORS b/AUTHORS
new file mode 100644
index 000..e4b7117
--- /dev/null
+++ b/AUTHORS
@@ -0,0 +1 @@
+Kamil Debski 
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 000..aac6101
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,9 @@
+To install libgencec run following commands:
+
+autoreconf -i
+./configure
+make
+make install
+
+A cross compilation example for ARM:
+CFLAGS=-I ./configure --host=arm-linux-gnueabi 
--prefix=
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 000..d645695
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf 

[PATCH v5 11/11] DocBook/media: add CEC documentation

2015-04-29 Thread Kamil Debski
From: Hans Verkuil 

Add DocBook documentation for the CEC API.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: add documentation for passthrough mode]
[k.debski at samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: Kamil Debski 
---
 Documentation/DocBook/media/Makefile   |4 +-
 Documentation/DocBook/media/v4l/biblio.xml |   10 +
 Documentation/DocBook/media/v4l/cec-api.xml|   74 ++
 Documentation/DocBook/media/v4l/cec-func-close.xml |   59 +
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |   73 ++
 Documentation/DocBook/media/v4l/cec-func-open.xml  |   94 +++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |   89 +++
 .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml |  275 
 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |   78 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |   87 +++
 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml |  167 
 .../DocBook/media/v4l/cec-ioc-g-event.xml  |  142 ++
 .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |   70 +
 .../DocBook/media/v4l/cec-ioc-receive.xml  |  185 +
 Documentation/DocBook/media_api.tmpl   |6 +-
 15 files changed, 1410 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 8bf7c61..9650332 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -64,6 +64,7 @@ IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
VIDIOC_SUBDEV_G_FRAME_INTERVAL \
VIDIOC_SUBDEV_S_FRAME_INTERVAL \
@@ -98,6 +99,7 @@ STRUCTS = \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-mediabus.h)

@@ -300,7 +302,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: 
$(MEDIA_OBJ_DIR)/v4l2.xml
@(  \
for ident in $(IOCTLS) ; do \
  entity=`echo $$ident | tr _ -` ;  \
- id=`grep "$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml 
$(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
+ id=`grep "$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml 
$(MEDIA_OBJ_DIR)/media-ioc-*.xml $(MEDIA_OBJ_DIR)/cec-ioc-*.xml | sed -r 
s,"^.*/(.*).xml.*","\1",` ; \
  echo "$$ident\">" \
  >>$@ ;\
diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index fdee6b3..bed940b 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -324,6 +324,16 @@ in the frequency range from 87,5 to 108,0 MHz
   Specification Version 1.4a
 

+
+  HDMI2
+  
+   HDMI Licensing LLC
+(http://www.hdmi.org;>http://www.hdmi.org)
+  
+  

[PATCH v5 10/11] cec: s5p-cec: Add s5p-cec driver

2015-04-29 Thread Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski 
---
 .../devicetree/bindings/media/s5p-cec.txt  |   33 +++
 drivers/media/platform/Kconfig |   10 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 ++
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  283 
 drivers/media/platform/s5p-cec/s5p_cec.h   |   76 ++
 9 files changed, 748 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..97ca664
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,33 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be follwoing
+   "samsung,s5p-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+  - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec at 100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "okay";
+};
+
+
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 421f531..203bc06 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -157,6 +157,16 @@ config VIDEO_MEM2MEM_DEINTERLACE
help
Generic deinterlacing V4L2 driver.

+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on CEC && VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS)
+   default n
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8f85561..f96c9a3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..7f84226
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
+
+
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * 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

[PATCH v5 09/11] cec: adv7511: add cec support.

2015-04-29 Thread Kamil Debski
From: Hans Verkuil 

Add CEC support to the adv7511 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7511.c |  347 ++-
 include/media/adv7511.h |6 +-
 2 files changed, 343 insertions(+), 10 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 12d9320..d56e110 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -91,6 +92,12 @@ struct adv7511_state {
int chip_revision;
uint8_t i2c_edid_addr;
uint8_t i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
@@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client 
*client,
return ret;
 }

-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, 
uint8_t *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
 {
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -237,6 +244,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
uint16_t len, uint8_t
v4l2_err(sd, "%s: i2c read error\n", __func__);
 }

+static inline int cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+
+   return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+   int ret;
+   int i;
+
+   for (i = 0; i < 3; i++) {
+   ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+   if (ret == 0)
+   return 0;
+   }
+   v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+   return ret;
+}
+
+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+}
+
 static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd)
 {
return adv7511_rd(sd, 0x42) & MASK_ADV7511_HPD_DETECT;
@@ -381,16 +416,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
 #ifdef CONFIG_VIDEO_ADV_DEBUG
 static void adv7511_inv_register(struct v4l2_subdev *sd)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+   if (state->i2c_cec)
+   v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
 }

 static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register 
*reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   reg->val = cec_read(sd, reg->reg & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -401,10 +448,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *

 static int adv7511_s_register(struct v4l2_subdev *sd, const struct 
v4l2_dbg_register *reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg->reg >> 8) {
case 0:
adv7511_wr(sd, reg->reg & 0xff, reg->val & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   cec_write(sd, reg->reg & 0xff, reg->val & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -418,6 +473,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
 {
struct adv7511_state *state = get_adv7511_state(sd);
struct adv7511_state_edid *edid = >edid;
+   int i;

static const char * const states[] = {
"in reset",
@@ -486,7 +542,21 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
else
v4l2_info(sd, "no timings set\n");
v4l2_info(sd, "i2c edid addr: 0x%x\n", state->i2c_edid_addr);
+
+   if (state->i2c_cec == NULL)
+   return 0;
+
v4l2_info(sd, "i2c cec addr: 0x%x\n", state->i2c_cec_addr);
+
+   if (cec_read(sd, 0x4e) & 0x01) {
+   

[PATCH v5 08/11] cec: adv7604: add cec support.

2015-04-29 Thread Kamil Debski
From: Hans Verkuil 

Add CEC support to the adv7604 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in added functions]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7604.c |  207 ++-
 1 file changed, 206 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 60ffcf0..4921276 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -38,6 +38,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,8 @@ MODULE_LICENSE("GPL");

 #define ADV76XX_OP_SWAP_CB_CR  (1 << 0)

+#define ADV76XX_MAX_ADDRS (3)
+
 enum adv76xx_type {
ADV7604,
ADV7611,
@@ -159,6 +162,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+   u8   cec_addr[ADV76XX_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -424,7 +431,15 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val);
 }

-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int io_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+   return io_write(sd, reg, (io_read(sd, reg) & mask) | val);
+}
+
+
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
 {
return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
 }
@@ -457,6 +472,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 
reg, u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val);
 }

+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+}
+
 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
 {
struct adv76xx_state *state = to_state(sd);
@@ -1865,6 +1886,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
 }

+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+   if ((cec_read(sd, 0x11) & 0x01) == 0) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+   return;
+   }
+
+   if (tx_raw_status & 0x02) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n",
+__func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_ARB_LOST);
+   return;
+   }
+   if (tx_raw_status & 0x04) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+   return;
+   }
+   if (tx_raw_status & 0x01) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_OK);
+   return;
+   }
+}
+
+static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+   struct cec_msg msg;
+   u8 cec_irq;
+
+   /* cec controller */
+   cec_irq = io_read(sd, 0x4d) & 0x0f;
+   if (!cec_irq)
+   return;
+
+   v4l2_dbg(1, debug, sd, "%s: cec: irq 0x%x\n", __func__, cec_irq);
+   adv76xx_cec_tx_raw_status(sd, cec_irq);
+   if (cec_irq & 0x08) {
+   msg.len = cec_read(sd, 0x25) & 0x1f;
+   if (msg.len > 16)
+   msg.len = 16;
+
+   if (msg.len) {
+   u8 i;
+
+   for (i = 0; i < msg.len; i++)
+   msg.msg[i] = cec_read(sd, i + 0x15);
+   cec_write(sd, 0x26, 0x01); /* re-enable rx */
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, );
+   }
+   }
+
+   /* note: the bit order is swapped between 0x4d and 0x4e */
+   cec_irq = ((cec_irq & 0x08) >> 3) | ((cec_irq & 0x04) >> 1) |
+ ((cec_irq & 0x02) << 1) | ((cec_irq & 0x01) << 3);
+   io_write(sd, 0x4e, cec_irq);
+
+   if (handled)
+   *handled = true;
+}
+
+static int adv76xx_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv76xx_state *state = to_state(sd);
+

[PATCH v5 07/11] v4l2-subdev: add HDMI CEC ops

2015-04-29 Thread Kamil Debski
From: Hans Verkuil 

Add callbacks to the v4l2_subdev_video_ops.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 include/media/v4l2-subdev.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 2f0a345..9323e10 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,9 @@
 #define V4L2_SUBDEV_IR_TX_NOTIFY   _IOW('v', 1, u32)
 #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001

+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg)
+
 struct v4l2_device;
 struct v4l2_ctrl_handler;
 struct v4l2_event_subscription;
@@ -48,6 +51,7 @@ struct v4l2_subdev;
 struct v4l2_subdev_fh;
 struct tuner_setup;
 struct v4l2_mbus_frame_desc;
+struct cec_msg;

 /* decode_vbi_line */
 struct v4l2_decode_vbi_line {
@@ -352,6 +356,10 @@ struct v4l2_subdev_video_ops {
 const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
   unsigned int *size);
+   int (*cec_enable)(struct v4l2_subdev *sd, bool enable);
+   int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+   int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg);
+   void (*cec_transmit_timed_out)(struct v4l2_subdev *sd);
 };

 /*
-- 
1.7.9.5



[PATCH v5 06/11] cec: add HDMI CEC framework

2015-04-29 Thread Kamil Debski
From: Hans Verkuil 

The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com: code cleanup and fixes]
[k.debski at samsung.com: add missing CEC commands to match spec]
[k.debski at samsung.com: add RC framework support]
[k.debski at samsung.com: move and edit documentation]
[k.debski at samsung.com: add vendor id reporting]
[k.debski at samsung.com: add possibility to clear assigned logical
addresses]
[k.debski at samsung.com: documentation fixes, clenaup and expansion]
[k.debski at samsung.com: reorder of API structs and add reserved fields]
[k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
problem]
[k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild]
[k.debski at samsung.com: add sequence number handling]
[k.debski at samsung.com: add passthrough mode]
[k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
[k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with
minor additions]
Signed-off-by: Kamil Debski 
---
 Documentation/cec.txt |  396 +++
 drivers/media/Kconfig |6 +
 drivers/media/Makefile|2 +
 drivers/media/cec.c   | 1200 +
 include/media/cec.h   |  142 ++
 include/uapi/linux/Kbuild |1 +
 include/uapi/linux/cec.h  |  337 +
 7 files changed, 2084 insertions(+)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..2b6c08a
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,396 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables consumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physical address is determined by the physical
+connection between devices.
+
+The protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adapter
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The "Primary Device Type" */
+#define CEC_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK  4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM   5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV  (1 << 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD  (1 << 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER   (1 << 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH  (1 << 2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV   0
+#define CEC_LOG_ADDR_TYPE_RECORD   1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM  4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B   5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+   /* internal fields removed */
+
+   u16 phys_addr;
+   u32 capabilities;
+   u8 version;
+   u8 num_log_addrs;
+   u8 prim_device[CEC_MAX_LOG_ADDRS];
+   u8 log_addr_type[CEC_MAX_LOG_ADDRS];

[PATCH v5 05/11] rc: Add HDMI CEC protoctol handling

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

Signed-off-by: Kamil Debski 
---
 drivers/media/rc/keymaps/Makefile |1 +
 drivers/media/rc/keymaps/rc-cec.c |  144 +
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-core.h   |1 +
 include/media/rc-map.h|5 +-
 5 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+   rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c 
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..cc5b318
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,144 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * 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 
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be 
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+   { 0x00, KEY_OK },
+   { 0x01, KEY_UP },
+   { 0x02, KEY_DOWN },
+   { 0x03, KEY_LEFT },
+   { 0x04, KEY_RIGHT },
+   { 0x05, KEY_RIGHT_UP },
+   { 0x06, KEY_RIGHT_DOWN },
+   { 0x07, KEY_LEFT_UP },
+   { 0x08, KEY_LEFT_DOWN },
+   { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+   /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+   { 0x0a, KEY_SETUP },
+   { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+   { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+   { 0x0d, KEY_EXIT },
+   /* 0x0e-0x1f: Reserved */
+   /* 0x20-0x29: Keys 0 to 9 */
+   { 0x20, KEY_NUMERIC_0 },
+   { 0x21, KEY_NUMERIC_1 },
+   { 0x22, KEY_NUMERIC_2 },
+   { 0x23, KEY_NUMERIC_3 },
+   { 0x24, KEY_NUMERIC_4 },
+   { 0x25, KEY_NUMERIC_5 },
+   { 0x26, KEY_NUMERIC_6 },
+   { 0x27, KEY_NUMERIC_7 },
+   { 0x28, KEY_NUMERIC_8 },
+   { 0x29, KEY_NUMERIC_9 },
+   { 0x2a, KEY_DOT },
+   { 0x2b, KEY_ENTER },
+   { 0x2c, KEY_CLEAR },
+   /* 0x2d-0x2e: Reserved */
+   { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+   { 0x30, KEY_CHANNELUP },
+   { 0x31, KEY_CHANNELDOWN },
+   { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+   { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+   { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+   { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+   { 0x36, KEY_HELP },
+   { 0x37, KEY_PAGEUP },
+   { 0x38, KEY_PAGEDOWN },
+   /* 0x39-0x3f: Reserved */
+   { 0x40, KEY_POWER },
+   { 0x41, KEY_VOLUMEUP },
+   { 0x42, KEY_VOLUMEDOWN },
+   { 0x43, KEY_MUTE },
+   { 0x44, KEY_PLAY },
+   { 0x45, KEY_STOP },
+   { 0x46, KEY_PAUSE },
+   { 0x47, KEY_RECORD },
+   { 0x48, KEY_REWIND },
+   { 0x49, KEY_FASTFORWARD },
+   { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+   { 0x4b, KEY_FORWARD },
+   { 0x4c, KEY_BACK },
+   { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+   { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+   /* 0x4f: Reserved */
+   { 0x50, KEY_ANGLE },
+   { 0x51, KEY_TV2 },
+   { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+   { 0x53, KEY_EPG },
+   { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+   { 0x55, KEY_CONFIG },
+   /* 0x56-0x5f: Reserved */
+   { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */
+   { 0x6024, KEY_PLAY },
+   { 0x6020, KEY_PAUSE },
+   { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */
+   { 0x62, KEY_RECORD }, /* Spec: Record Function */
+   { 0x63, KEY_PAUSE }, /* CEC Spec: Pause-Record Function */
+   

[PATCH v5 04/11] HID: add HDMI CEC specific keycodes

2015-04-29 Thread Kamil Debski
Add HDMI CEC specific keycodes to the keycodes definition.

Signed-off-by: Kamil Debski 
---
 include/uapi/linux/input.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..7430a3f 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,18 @@ struct input_keymap_entry {
 #define KEY_KBDINPUTASSIST_ACCEPT  0x264
 #define KEY_KBDINPUTASSIST_CANCEL  0x265

+#define KEY_RIGHT_UP   0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP0x268
+#define KEY_LEFT_DOWN  0x269
+
+#define KEY_NEXT_FAVORITE  0x270
+#define KEY_STOP_RECORD0x271
+#define KEY_PAUSE_RECORD   0x272
+#define KEY_VOD0x273
+#define KEY_UNMUTE 0x274
+#define KEY_DVB0x275
+
 #define BTN_TRIGGER_HAPPY  0x2c0
 #define BTN_TRIGGER_HAPPY1 0x2c0
 #define BTN_TRIGGER_HAPPY2 0x2c1
-- 
1.7.9.5



[PATCH v5 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device

2015-04-29 Thread Kamil Debski
Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8de12af..e50862d 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -469,6 +469,10 @@
status = "okay";
};

+   cec at 100B {
+   status = "okay";
+   };
+
hdmi_ddc: i2c at 1388 {
status = "okay";
pinctrl-names = "default";
-- 
1.7.9.5



[PATCH v5 02/11] dts: exynos4: add node for the HDMI CEC device

2015-04-29 Thread Kamil Debski
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc2..8776db9 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -704,6 +704,18 @@
status = "disabled";
};

+   hdmicec: cec at 100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "disabled";
+   };
+
mixer: mixer at 12C1 {
compatible = "samsung,exynos4210-mixer";
interrupts = <0 91 0>;
-- 
1.7.9.5



[PATCH v5 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl

2015-04-29 Thread Kamil Debski
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c2128..9331c62 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -820,6 +820,13 @@
samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
};

pinctrl at 0386 {
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index c141931..875464e 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -885,6 +885,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
};

pinctrl at 0386 {
-- 
1.7.9.5



[PATCH v5 00/11] HDMI CEC framework

2015-04-29 Thread Kamil Debski
Hi,

This is the fifth version of the HDMI CEC framework patches. All the
previous version have spun many discussions and quite a few changes.
Hopefully, in this version, the code of the framework matured and got
closer to meeting our requirements.

Again, thank you so much for all the discussion and comments. With your
help the code of the framework improved.

The major change is an introduction of a new special mode - the passthrough
mode. It might look that it is similar to the long gone promiscuous mode,
however its purpose is different. After the comment by Lars Op den Kamp,
we decided that it is necessary to introduce the passthrough mode. In this
mode the framework takes minimal part in handling CEC messages.

Why this mode is necessary? It turns out that handling of CEC communication
is very vendor specific. The libCEC library handles most of these vendor quirks
however it requires low level access to the messages on the CEC bus. In the
passthrough mode the messages are forwarded to the userspace with very little
handling by the kernel CEC framework.

Without passthrough enabled the kernel handles message replies etc. as defined
in the spec. This should work well with well-mannered systems that follow the
spec and have little vendor specific quirks.

Comments are welcome.

Best wishes,
Kamil Debski

Changes since v4

- add sequence numbering to transmitted messages
- add sequence number handling to event hanlding
- add passthrough mode
- change reserved field sizes
- fixed CEC version defines and addec CEC 2.0 commands
- add DocBook documentation

Changes since v3

- remove the promiscuous mode
- rewrite the devicetree patches
- fixes, expansion and partial rewrite of the documentation
- reorder of API structures and addition of reserved fields
- use own struct to report time (32/64 bit safe)
- fix of handling events
- add cec.h to include/uapi/linux/Kbuild
- fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx)
- cleanup of debug messages in s5p-cec driver
- remove non necessary claiming of a gpio in the s5p-cec driver
- cleanup headers of the s5p-cec driver

Changes since v2
===-
- added promiscuous mode
- added new key codes to the input framework
- add vendor ID reporting
- add the possibility to clear assigned logical addresses
- cleanup of the rc cec map

Changes since v1

- documentation edited and moved to the Documentation folder
- added key up/down message handling
- add missing CEC commands to the cec.h file

Background
==

The work on a common CEC framework was started over three years ago by Hans
Verkuil. Unfortunately the work has stalled. As I have received the task of
creating a driver for the CEC interface module present on the Exynos range of
SoCs, I got in touch with Hans. He replied that the work stalled due to his
lack of time.

Original RFC by Hans Verkuil/Martin Bugge
=
https://www.mail-archive.com/linux-media at vger.kernel.org/msg28735.html


Hans Verkuil (5):
  cec: add HDMI CEC framework
  v4l2-subdev: add HDMI CEC ops
  cec: adv7604: add cec support.
  cec: adv7511: add cec support.
  DocBook/media: add CEC documentation

Kamil Debski (6):
  dts: exynos4*: add HDMI CEC pin definition to pinctrl
  dts: exynos4: add node for the HDMI CEC device
  dts: exynos4412-odroid*: enable the HDMI CEC device
  HID: add HDMI CEC specific keycodes
  rc: Add HDMI CEC protoctol handling
  cec: s5p-cec: Add s5p-cec driver

 Documentation/DocBook/media/Makefile   |4 +-
 Documentation/DocBook/media/v4l/biblio.xml |   10 +
 Documentation/DocBook/media/v4l/cec-api.xml|   74 ++
 Documentation/DocBook/media/v4l/cec-func-close.xml |   59 +
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |   73 ++
 Documentation/DocBook/media/v4l/cec-func-open.xml  |   94 ++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |   89 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml |  275 +
 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |   78 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |   87 ++
 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml |  167 +++
 .../DocBook/media/v4l/cec-ioc-g-event.xml  |  142 +++
 .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |   70 ++
 .../DocBook/media/v4l/cec-ioc-receive.xml  |  185 +++
 Documentation/DocBook/media_api.tmpl   |6 +-
 Documentation/cec.txt  |  396 +++
 .../devicetree/bindings/media/s5p-cec.txt  |   33 +
 arch/arm/boot/dts/exynos4.dtsi |   12 +
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi  |7 +
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 +
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi  |7 +
 drivers/media/Kconfig  |6 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c 

linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1799: possible missing break ?

2015-04-29 Thread Hai Li
Yes, this is a bug in DSI driver. I have sent a patch to fix it.
http://lists.freedesktop.org/archives/dri-devel/2015-April/081893.html

Sorry for any inconvenience it caused.

Hai


-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
David Binderman
Sent: Monday, April 27, 2015 1:59 AM
To: airlied at linux.ie; dri-devel at lists.freedesktop.org
Subject: linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1799: possible 
missing break ?

Hello there,

[linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1799] -> 
[linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1802]: (warning) Variable 
'ret' is reassigned a value before the old one has been used. 'break;' missing?

switch (cmd) {
case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
pr_err("%s: rx ACK_ERR_PACLAGE\n", __func__);
ret = 0;
case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
ret = dsi_short_read1_resp(buf, msg);
break;

Regards

David Binderman


___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[PATCH 2/2] drm/msm/dsi: Simplify the code to get the number of read byte

2015-04-29 Thread Hai Li
During cmd rx, only new versions of H/W provide register to read back
the real number of byte returned by panel. For the old versions, reading
this register will not get the right number. In fact, we only need to
assume the returned data is the same size as we expected, because later
we will check the data type to detect error.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 473d417..72d4d5f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1093,7 +1093,6 @@ static int dsi_cmd_dma_rx(struct msm_dsi_host *msm_host,
 {
u32 *lp, *temp, data;
int i, j = 0, cnt;
-   bool ack_error = false;
u32 read_cnt;
u8 reg[16];
int repeated_bytes = 0;
@@ -1105,15 +1104,10 @@ static int dsi_cmd_dma_rx(struct msm_dsi_host *msm_host,
if (cnt > 4)
cnt = 4; /* 4 x 32 bits registers only */

-   /* Calculate real read data count */
-   read_cnt = dsi_read(msm_host, 0x1d4) >> 16;
-
-   ack_error = (rx_byte == 4) ?
-   (read_cnt == 8) : /* short pkt + 4-byte error pkt */
-   (read_cnt == (pkt_size + 6 + 4)); /* long pkt+4-byte error pkt*/
-
-   if (ack_error)
-   read_cnt -= 4; /* Remove 4 byte error pkt */
+   if (rx_byte == 4)
+   read_cnt = 4;
+   else
+   read_cnt = pkt_size + 6;

/*
 * In case of multiple reads from the panel, after the first read, there
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



[PATCH 1/2] drm/msm/dsi: Fixup missing *break* statement during cmd rx

2015-04-29 Thread Hai Li
Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index fdc54e3..473d417 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1797,6 +1797,7 @@ int msm_dsi_host_cmd_rx(struct mipi_dsi_host *host,
case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
pr_err("%s: rx ACK_ERR_PACLAGE\n", __func__);
ret = 0;
+   break;
case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
ret = dsi_short_read1_resp(buf, msg);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



[PATCH 0/2] drm/msm/dsi: Fix issues during cmd rx

2015-04-29 Thread Hai Li
These 2 patches are to fix the issues during DSI command rx.

Hai Li (2):
  drm/msm/dsi: Fixup missing *break* statement during cmd rx
  drm/msm/dsi: Simplify the code to get the number of read byte

 drivers/gpu/drm/msm/dsi/dsi_host.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

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



linux-next: manual merge of the drm-intel tree with Linus' tree

2015-04-29 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_drv.c between commit 5df0582bf036
("drm/i915/vlv: remove wait for previous GFX clk disable request") from
Linus' tree and commit 85250ddff7a6 ("drm/i915/chv: Remove Wait for a
previous gfx force-off") from the drm-intel tree (which also appeared as
commit c9c52e24194a in Linus' tree before v4.0).

I fixed it up (I used the version from Linus' tree) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/35620da0/attachment.sig>


[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-29 Thread Kevin Hilman
Krzysztof Kozlowski  writes:

> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
>
> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
> This clock is required by Display Port and is enabled by bootloader.
> However when FIMD driver probing was deferred, the display power domain
> was turned off. This effectively reset the value of DP clock enable
> register.
>
> When exynos-dp is later probed, the clock is not enabled and display is
> not properly configured:
>
> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
> exynos-dp 145b.dp-controller: unable to config video
>
> Signed-off-by: Krzysztof Kozlowski 
> Reported-by: Javier Martinez Canillas 
> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
> Cc: 
>
> ---
>
> This should fix issue reported by Javier [1][2].
>
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> especially on other Exynos 5xxx products.

I hoped to try this on my exynos5 boards, but it doesn't seem to apply
to linux-next or to Linus' master branch.

Are there some other dependencies here?

Kevin


[PATCH] devicetree: Add vendor prefix for Foxlink Group

2015-04-29 Thread Rob Herring
On Wed, Apr 29, 2015 at 10:16 AM, Nicolas Ferre  
wrote:
> Le 24/03/2015 17:12, Nicolas Ferre a écrit :
>> Signed-off-by: Nicolas Ferre 
>> ---
>> Thierry,
>>
>> Boris added the support for a Foxlink panel in this commit: 102932b0e474
>> (drm/panel: add support for Foxlink FL500WVR00-A0T panel). Here is the vendor
>> prefix.
>
> Ping?

Acked-by: Rob Herring 

>
>>
>> Bye,
>>
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1b0f5b797cd5..e9fca088ba1a 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -73,6 +73,7 @@ everspinEverspin Technologies, Inc.
>>  excito   Excito
>>  fcs  Fairchild Semiconductor
>>  firefly  Firefly
>> +foxlink  Foxlink Group
>>  fsl  Freescale Semiconductor
>>  GEFanuc  GE Fanuc Intelligent Platforms Embedded Systems, Inc.
>>  gef  GE Fanuc Intelligent Platforms Embedded Systems, Inc.
>>
>
>
> --
> Nicolas Ferre


[PATCH] devicetree: Add vendor prefix for Shelly, Inc.

2015-04-29 Thread Rob Herring
On Wed, Apr 29, 2015 at 10:17 AM, Nicolas Ferre  
wrote:
> Le 24/03/2015 17:12, Nicolas Ferre a écrit :
>> Signed-off-by: Nicolas Ferre 
>
> Ping?

Acked-by: Rob Herring 

>
>> ---
>> Thierry,
>>
>> Here it is ;-)
>>
>> Bye,
>>
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index a9eeaa0c5867..1b0f5b797cd5 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -165,6 +165,7 @@ sbs   Smart Battery System
>>  schindlerSchindler
>>  seagate  Seagate Technology PLC
>>  semtech  Semtech Corporation
>> +shelly   Shelly, Inc.
>>  sil  Silicon Image
>>  silabs   Silicon Laboratories
>>  siliconmitus Silicon Mitus, Inc.
>>
>
>
> --
> Nicolas Ferre


[PATCH] drmPrime*: initialize output args to 0

2015-04-29 Thread Guillaume Desmottes
Fix Valgrind errors because those memory was uninitialized.

https://bugs.freedesktop.org/show_bug.cgi?id=90194
Signed-off-by: Guillaume Desmottes 
---
 xf86drm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..01c398e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2724,6 +2724,7 @@ int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t 
flags, int *prime_fd)
struct drm_prime_handle args;
int ret;

+   args.fd = -1;
args.handle = handle;
args.flags = flags;
ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
@@ -2739,6 +2740,7 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t 
*handle)
struct drm_prime_handle args;
int ret;

+   args.handle = 0;
args.fd = prime_fd;
args.flags = 0;
ret = drmIoctl(fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
-- 
2.1.0



[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90056

--- Comment #13 from Andy Furniss  ---
(In reply to Tom Stellard from comment #12)
> (In reply to Andy Furniss from comment #10)
> > (In reply to Grigori Goronzy from comment #9)
> > > Created attachment 115409 [details] [review] [review] [review]
> > > Full shader
> > > 
> > > That does not help either. Seems to break the SSA somehow. Full shader 
> > > that
> > > triggers the bug attached.
> > > 
> > > The patch I posted earlier help with the the reduced testcase, but not 
> > > with
> > > the full shader. Both undef incoming values in phi nodes and undef branch
> > > conditions cause problems in different ways.
> > 
> > With the second patch + valley I get -
> > 
> > valley_x64: LiveVariables.cpp:114: void
> > llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo &,
> > llvm::MachineBasicBlock *, llvm::MachineBasicBlock *,
> > std::vector &): Assertion `MBB != >front() &&
> > "Can't find reaching def for virtreg"' failed.
> 
> Did test with only the patch from comment #8 or did you test with both
> patches?

Just #8 but I just tried with both and get the same fail.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/3ae07209/attachment.html>


[Bug 90194] Fix Valgrind error in drmPrimeHandleToFD

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90194

Guillaume Desmottes  changed:

   What|Removed |Added

 Attachment #115403|0   |1
is obsolete||

--- Comment #5 from Guillaume Desmottes  ---
Created attachment 115430
  --> https://bugs.freedesktop.org/attachment.cgi?id=115430=edit
drmPrime*: initialize output args to 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/74c78f84/attachment-0001.html>


[PATCH 10/10] drm: rcar-du: Split planes pre-association 4/4 between CRTCs

2015-04-29 Thread Laurent Pinchart
If we have more than one CRTCs in a group pre-associate planes 0-3 with
CRTC 0 and planes 4-7 with CRTC 1 to minimize flicker occurring when the
association is changed. The pre-association could be controlled by a
module parameter if needed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 ---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 7 ---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 620a2c51185c..e6a32c4e4040 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -257,9 +257,6 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
 * resulting in visible flicker. To mitigate the issue only update the
 * association if needed by enabled planes. Planes being disabled will
 * keep their current association.
-*
-* To mitigate the issue further we could pre-associate planes with
-* CRTCs, either with a fixed 4/4 split, or through a module parameter.
 */
mutex_lock(>group->lock);

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index fec5f4d794da..20859aae882e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -765,10 +765,11 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
rgrp->index = i;
rgrp->num_crtcs = min(rcdu->num_crtcs - 2 * i, 2U);

-   /* Pre-associate all hardware planes with the first CRTC in the
-* group.
+   /* If we have more than one CRTCs in this group pre-associate
+* planes 0-3 with CRTC 0 and planes 4-7 with CRTC 1 to minimize
+* flicker occurring when the association is changed.
 */
-   rgrp->dptsr_planes = 0;
+   rgrp->dptsr_planes = rgrp->num_crtcs > 1 ? 0xf0 : 0;

ret = rcar_du_planes_init(rgrp);
if (ret < 0)
-- 
2.0.5



[PATCH 09/10] drm: rcar-du: Store the number of CRTCs per group in the group structure

2015-04-29 Thread Laurent Pinchart
The number of CRTCs in a group is only used to implement plane
initialization for now, but is also needed to implement pre-association
of planes to CRTCs. Store it in the group structure instead of computing
it on demand.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 1 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h 
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index 4f6c37c8d336..7b414b31c3be 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -25,6 +25,7 @@ struct rcar_du_device;
  * @dev: the DU device
  * @mmio_offset: registers offset in the device memory map
  * @index: group index
+ * @num_crtcs: number of CRTCs in this group (1 or 2)
  * @use_count: number of users of the group (rcar_du_group_(get|put))
  * @used_crtcs: number of CRTCs currently in use
  * @lock: protects the dptsr_planes field and the DPTSR register
@@ -36,6 +37,7 @@ struct rcar_du_group {
unsigned int mmio_offset;
unsigned int index;

+   unsigned int num_crtcs;
unsigned int use_count;
unsigned int used_crtcs;

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 2c6cf691d163..fec5f4d794da 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -763,6 +763,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
rgrp->dev = rcdu;
rgrp->mmio_offset = mmio_offsets[i];
rgrp->index = i;
+   rgrp->num_crtcs = min(rcdu->num_crtcs - 2 * i, 2U);

/* Pre-associate all hardware planes with the first CRTC in the
 * group.
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index d3ed528fa56d..3e30d84b798f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -391,7 +391,6 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
 {
struct rcar_du_device *rcdu = rgrp->dev;
unsigned int num_planes;
-   unsigned int num_crtcs;
unsigned int crtcs;
unsigned int i;
int ret;
@@ -399,13 +398,12 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
 /* Create one primary plane per CRTC in this group and seven overlay
  * planes.
  */
-   num_crtcs = min(rcdu->num_crtcs - 2 * rgrp->index, 2U);
-   num_planes = num_crtcs + 7;
+   num_planes = rgrp->num_crtcs + 7;

crtcs = ((1 << rcdu->num_crtcs) - 1) & (3 << (2 * rgrp->index));

for (i = 0; i < num_planes; ++i) {
-   enum drm_plane_type type = i < num_crtcs
+   enum drm_plane_type type = i < rgrp->num_crtcs
 ? DRM_PLANE_TYPE_PRIMARY
 : DRM_PLANE_TYPE_OVERLAY;
struct rcar_du_plane *plane = >planes[i];
-- 
2.0.5



[PATCH 08/10] drm: rcar-du: Consider plane to CRTC associations in the plane allocator

2015-04-29 Thread Laurent Pinchart
Hardware planes are driven by the timing generator of the CRTC they are
associated to. Changing the association requires restarting the CRTC
group that the plane belongs to, resulting in flicker on the other CRTC.

To avoid flicker as much as possible, try to allocate planes first from
the free planes already associated with the target CRTC. If allocation
fails then fall back to allocation from all free planes.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ade135008e98..2c6cf691d163 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -383,6 +383,8 @@ static int rcar_du_atomic_check(struct drm_device *dev,
for (i = 0; i < dev->mode_config.num_total_plane; ++i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
+   unsigned int crtc_planes;
+   unsigned int free;
int idx;

if (!state->planes[i])
@@ -401,8 +403,21 @@ static int rcar_du_atomic_check(struct drm_device *dev,
!rcar_du_plane_needs_realloc(plane, plane_state))
continue;

+   /* Try to allocate the plane from the free planes currently
+* associated with the target CRTC to avoid restarting the CRTC
+* group and thus minimize flicker. If it fails fall back to
+* allocating from all free planes.
+*/
+   crtc_planes = to_rcar_crtc(plane_state->state.crtc)->index % 2
+   ? plane->group->dptsr_planes
+   : ~plane->group->dptsr_planes;
+   free = group_free_planes[plane->group->index];
+
idx = rcar_du_plane_hwalloc(plane_state->format->planes,
-   group_free_planes[plane->group->index]);
+   free & crtc_planes);
+   if (idx < 0)
+   idx = rcar_du_plane_hwalloc(plane_state->format->planes,
+   free);
if (idx < 0) {
dev_dbg(rcdu->dev, "%s: no available hardware plane\n",
__func__);
@@ -749,6 +764,11 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
rgrp->mmio_offset = mmio_offsets[i];
rgrp->index = i;

+   /* Pre-associate all hardware planes with the first CRTC in the
+* group.
+*/
+   rgrp->dptsr_planes = 0;
+
ret = rcar_du_planes_init(rgrp);
if (ret < 0)
return ret;
-- 
2.0.5



[PATCH 07/10] drm: rcar-du: Keep plane to CRTC associations when disabling a plane

2015-04-29 Thread Laurent Pinchart
Changing the plane to CRTC associations requires restarting the CRTC
group, creating visible flicker. Mitigate the issue by changing plane
association only when a plane becomes enabled, not when it get disabled.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 48 +++--
 drivers/gpu/drm/rcar-du/rcar_du_group.c |  6 +
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  4 ++-
 3 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15f8d145a133..620a2c51185c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -208,9 +208,10 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
 {
struct rcar_du_plane *planes[RCAR_DU_NUM_HW_PLANES];
unsigned int num_planes = 0;
+   unsigned int dptsr_planes;
+   unsigned int hwplanes = 0;
unsigned int prio = 0;
unsigned int i;
-   u32 dptsr = 0;
u32 dspr = 0;

for (i = 0; i < ARRAY_SIZE(rcrtc->group->planes); ++i) {
@@ -238,37 +239,44 @@ static void rcar_du_crtc_update_planes(struct 
rcar_du_crtc *rcrtc)

prio -= 4;
dspr |= (index + 1) << prio;
-   dptsr |= DPTSR_PnDK(index) |  DPTSR_PnTS(index);
+   hwplanes |= 1 << index;

if (plane_format(plane)->planes == 2) {
index = (index + 1) % 8;

prio -= 4;
dspr |= (index + 1) << prio;
-   dptsr |= DPTSR_PnDK(index) |  DPTSR_PnTS(index);
+   hwplanes |= 1 << index;
}
}

-   /* Select display timing and dot clock generator 2 for planes associated
-* with superposition controller 2.
+   /* Update the planes to display timing and dot clock generator
+* associations.
+*
+* Updating the DPTSR register requires restarting the CRTC group,
+* resulting in visible flicker. To mitigate the issue only update the
+* association if needed by enabled planes. Planes being disabled will
+* keep their current association.
+*
+* To mitigate the issue further we could pre-associate planes with
+* CRTCs, either with a fixed 4/4 split, or through a module parameter.
 */
-   if (rcrtc->index % 2) {
-   /* The DPTSR register is updated when the display controller is
-* stopped. We thus need to restart the DU. Once again, sorry
-* for the flicker. One way to mitigate the issue would be to
-* pre-associate planes with CRTCs (either with a fixed 4/4
-* split, or through a module parameter). Flicker would then
-* occur only if we need to break the pre-association.
-*/
-   mutex_lock(>group->lock);
-   if (rcar_du_group_read(rcrtc->group, DPTSR) != dptsr) {
-   rcar_du_group_write(rcrtc->group, DPTSR, dptsr);
-   if (rcrtc->group->used_crtcs)
-   rcar_du_group_restart(rcrtc->group);
-   }
-   mutex_unlock(>group->lock);
+   mutex_lock(>group->lock);
+
+   dptsr_planes = rcrtc->index % 2 ? rcrtc->group->dptsr_planes | hwplanes
+: rcrtc->group->dptsr_planes & ~hwplanes;
+
+   if (dptsr_planes != rcrtc->group->dptsr_planes) {
+   rcar_du_group_write(rcrtc->group, DPTSR,
+   (dptsr_planes << 16) | dptsr_planes);
+   rcrtc->group->dptsr_planes = dptsr_planes;
+
+   if (rcrtc->group->used_crtcs)
+   rcar_du_group_restart(rcrtc->group);
}

+   mutex_unlock(>group->lock);
+
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR,
dspr);
 }
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 1bdc0ee0c248..7fd39a7d91c8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -85,6 +85,12 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
 * superposition 0 to DU0 pins. DU1 pins will be configured dynamically.
 */
rcar_du_group_write(rgrp, DORCR, DORCR_PG1D_DS1 | DORCR_DPRS);
+
+   /* Apply planes to CRTCs association. */
+   mutex_lock(>lock);
+   rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
+   rgrp->dptsr_planes);
+   mutex_unlock(>lock);
 }

 /*
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h 
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index ea02bb02f3e1..4f6c37c8d336 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h

[PATCH 06/10] drm: rcar-du: Add plane allocation debugging

2015-04-29 Thread Laurent Pinchart
Plane allocation is a complex process, add debugging statements to help
finding out what could might wrong.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 38 ++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 14d457047c40..ade135008e98 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -286,11 +286,16 @@ static int rcar_du_atomic_check(struct drm_device *dev,
plane = to_rcar_plane(state->planes[i]);
plane_state = to_rcar_plane_state(state->plane_states[i]);

+   dev_dbg(rcdu->dev, "%s: checking plane (%u,%u)\n", __func__,
+   plane->group->index, plane - plane->group->planes);
+
/* If the plane is being disabled we don't need to go through
 * the full reallocation procedure. Just mark the hardware
 * plane(s) as freed.
 */
if (!plane_state->format) {
+   dev_dbg(rcdu->dev, "%s: plane is being disabled\n",
+   __func__);
index = plane - plane->group->planes;
group_freed_planes[plane->group->index] |= 1 << index;
plane_state->hwindex = -1;
@@ -301,6 +306,8 @@ static int rcar_du_atomic_check(struct drm_device *dev,
 * mark the hardware plane(s) as free.
 */
if (rcar_du_plane_needs_realloc(plane, plane_state)) {
+   dev_dbg(rcdu->dev, "%s: plane needs reallocation\n",
+   __func__);
groups |= 1 << plane->group->index;
needs_realloc = true;

@@ -326,6 +333,9 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_group *group = >groups[index];
unsigned int used_planes = 0;

+   dev_dbg(rcdu->dev, "%s: finding free planes for group %u\n",
+   __func__, index);
+
for (i = 0; i < RCAR_DU_NUM_KMS_PLANES; ++i) {
struct rcar_du_plane *plane = >planes[i];
struct rcar_du_plane_state *plane_state;
@@ -342,15 +352,31 @@ static int rcar_du_atomic_check(struct drm_device *dev,
 * above. Use the local freed planes list to check for
 * that condition instead.
 */
-   if (group_freed_planes[index] & (1 << i))
+   if (group_freed_planes[index] & (1 << i)) {
+   dev_dbg(rcdu->dev,
+   "%s: plane (%u,%u) has been freed, 
skipping\n",
+   __func__, plane->group->index,
+   plane - plane->group->planes);
continue;
+   }

plane_state = to_rcar_plane_state(plane->plane.state);
used_planes |= rcar_du_plane_hwmask(plane_state);
+
+   dev_dbg(rcdu->dev,
+   "%s: plane (%u,%u) uses %u hwplanes (index 
%d)\n",
+   __func__, plane->group->index,
+   plane - plane->group->planes,
+   plane_state->format ?
+   plane_state->format->planes : 0,
+   plane_state->hwindex);
}

group_free_planes[index] = 0xff & ~used_planes;
groups &= ~(1 << index);
+
+   dev_dbg(rcdu->dev, "%s: group %u free planes mask 0x%02x\n",
+   __func__, index, group_free_planes[index]);
}

/* Reallocate hardware planes for each plane that needs it. */
@@ -365,6 +391,9 @@ static int rcar_du_atomic_check(struct drm_device *dev,
plane = to_rcar_plane(state->planes[i]);
plane_state = to_rcar_plane_state(state->plane_states[i]);

+   dev_dbg(rcdu->dev, "%s: allocating plane (%u,%u)\n", __func__,
+   plane->group->index, plane - plane->group->planes);
+
/* Skip planes that are being disabled or don't need to be
 * reallocated.
 */
@@ -380,10 +409,17 @@ static int rcar_du_atomic_check(struct drm_device *dev,
return idx;
}

+   dev_dbg(rcdu->dev, "%s: allocated %u hwplanes (index %u)\n",
+   __func__, plane_state->format->planes, idx);
+
plane_state->hwindex = idx;

group_free_planes[plane->group->index] &=

[PATCH 04/10] drm: rcar-du: Embed rcar_du_planes structure into rcar_du_group

2015-04-29 Thread Laurent Pinchart
The rcar_du_planes structure contains a single field and is only
instantiated in the rcar_du_group structure. Embed it directly and
remove the rcar_du_planes structure.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 10 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.h |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  6 +++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  3 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7d0b8ef9bea2..b5f66b78cbb2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -213,8 +213,8 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
u32 dptsr = 0;
u32 dspr = 0;

-   for (i = 0; i < ARRAY_SIZE(rcrtc->group->planes.planes); ++i) {
-   struct rcar_du_plane *plane = >group->planes.planes[i];
+   for (i = 0; i < ARRAY_SIZE(rcrtc->group->planes); ++i) {
+   struct rcar_du_plane *plane = >group->planes[i];
unsigned int j;

if (plane->plane.state->crtc != >crtc)
@@ -427,8 +427,8 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc)
rcar_du_crtc_start(rcrtc);

/* Commit the planes state. */
-   for (i = 0; i < ARRAY_SIZE(rcrtc->group->planes.planes); ++i) {
-   struct rcar_du_plane *plane = >group->planes.planes[i];
+   for (i = 0; i < ARRAY_SIZE(rcrtc->group->planes); ++i) {
+   struct rcar_du_plane *plane = >group->planes[i];

if (plane->plane.state->crtc != >crtc)
continue;
@@ -592,7 +592,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
rcrtc->enabled = false;

ret = drm_crtc_init_with_planes(rcdu->ddev, crtc,
-   >planes.planes[index % 2].plane,
+   >planes[index % 2].plane,
NULL, _funcs);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h 
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index ed36433fbe84..ea02bb02f3e1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -40,7 +40,7 @@ struct rcar_du_group {

struct mutex lock;

-   struct rcar_du_planes planes;
+   struct rcar_du_plane planes[RCAR_DU_NUM_KMS_PLANES];
 };

 u32 rcar_du_group_read(struct rcar_du_group *rgrp, u32 reg);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 5fd6f8c07ec2..4012afacab5f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -291,7 +291,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
 * plane(s) as freed.
 */
if (!plane_state->format) {
-   index = plane - plane->group->planes.planes;
+   index = plane - plane->group->planes;
group_freed_planes[plane->group->index] |= 1 << index;
plane_state->hwindex = -1;
continue;
@@ -304,7 +304,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
groups |= 1 << plane->group->index;
needs_realloc = true;

-   index = plane - plane->group->planes.planes;
+   index = plane - plane->group->planes;
group_freed_planes[plane->group->index] |= 1 << index;
plane_state->hwindex = -1;
}
@@ -327,7 +327,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
unsigned int used_planes = 0;

for (i = 0; i < RCAR_DU_NUM_KMS_PLANES; ++i) {
-   struct rcar_du_plane *plane = >planes.planes[i];
+   struct rcar_du_plane *plane = >planes[i];
struct rcar_du_plane_state *plane_state;
struct drm_plane_state *s;

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index b5565417f673..99fefcaf6597 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -389,7 +389,6 @@ static const uint32_t formats[] = {

 int rcar_du_planes_init(struct rcar_du_group *rgrp)
 {
-   struct rcar_du_planes *planes = >planes;
struct rcar_du_device *rcdu = rgrp->dev;
unsigned int num_planes;
unsigned int num_crtcs;
@@ -409,7 +408,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
enum drm_plane_type type = i < num_crtcs
 ? DRM_PLANE_TYPE_PRIMARY
  

[PATCH 03/10] drm: rcar-du: Move properties from rcar_du_planes to rcar_du_device

2015-04-29 Thread Laurent Pinchart
The plane property objects are instantiated once per CRTC group, while
they should be instantiated once globally for the device. Fix this and
move them to the rcar_du_device structure.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  6 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 29 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 46 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 ---
 4 files changed, 47 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index c7c538dd2e68..9f34fc86436a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -83,6 +83,12 @@ struct rcar_du_device {

struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];

+   struct {
+   struct drm_property *alpha;
+   struct drm_property *colorkey;
+   struct drm_property *zpos;
+   } props;
+
unsigned int dpad0_source;
struct rcar_du_lvdsenc *lvds[RCAR_DU_MAX_LVDS];

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 93117f159a3b..5fd6f8c07ec2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -648,6 +648,31 @@ static int rcar_du_encoders_init(struct rcar_du_device 
*rcdu)
return num_encoders;
 }

+static int rcar_du_properties_init(struct rcar_du_device *rcdu)
+{
+   rcdu->props.alpha =
+   drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
+   if (rcdu->props.alpha == NULL)
+   return -ENOMEM;
+
+   /* The color key is expressed as an RGB888 triplet stored in a 32-bit
+* integer in XRGB format. Bit 24 is used as a flag to disable (0)
+* or enable source color keying (1).
+*/
+   rcdu->props.colorkey =
+   drm_property_create_range(rcdu->ddev, 0, "colorkey",
+ 0, 0x01ff);
+   if (rcdu->props.colorkey == NULL)
+   return -ENOMEM;
+
+   rcdu->props.zpos =
+   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
+   if (rcdu->props.zpos == NULL)
+   return -ENOMEM;
+
+   return 0;
+}
+
 int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 {
static const unsigned int mmio_offsets[] = {
@@ -672,6 +697,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)

rcdu->num_crtcs = rcdu->info->num_crtcs;

+   ret = rcar_du_properties_init(rcdu);
+   if (ret < 0)
+   return ret;
+
/* Initialize the groups. */
num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 210e5c3fd982..b5565417f673 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -328,14 +328,13 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
 uint64_t val)
 {
struct rcar_du_plane_state *rstate = to_rcar_du_plane_state(state);
-   struct rcar_du_plane *rplane = to_rcar_plane(plane);
-   struct rcar_du_group *rgrp = rplane->group;
+   struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;

-   if (property == rgrp->planes.alpha)
+   if (property == rcdu->props.alpha)
rstate->alpha = val;
-   else if (property == rgrp->planes.colorkey)
+   else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rgrp->planes.zpos)
+   else if (property == rcdu->props.zpos)
rstate->zpos = val;
else
return -EINVAL;
@@ -349,14 +348,13 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
 {
const struct rcar_du_plane_state *rstate =
container_of(state, const struct rcar_du_plane_state, state);
-   struct rcar_du_plane *rplane = to_rcar_plane(plane);
-   struct rcar_du_group *rgrp = rplane->group;
+   struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;

-   if (property == rgrp->planes.alpha)
+   if (property == rcdu->props.alpha)
*val = rstate->alpha;
-   else if (property == rgrp->planes.colorkey)
+   else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rgrp->planes.zpos)
+   else if (property == rcdu->props.zpos)
*val = rstate->zpos;
else
return -EINVAL;
@@ -399,27 +397,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
unsigned int i;
int ret;

-   planes->alpha =
-   drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
-   if (planes->alpha == 

[PATCH 02/10] drm: rcar-du: Document the rcar_du_plane_state structure

2015-04-29 Thread Laurent Pinchart
Document the structure fields using kerneldoc.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index abff0ebeb195..5d2b764919d8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -46,11 +46,20 @@ struct rcar_du_planes {
struct drm_property *zpos;
 };

+/*
+ * rcar_du_plane_state - Driver-specific plane state
+ * @state: base DRM plane state
+ * @format: information about the pixel format used by the plane
+ * @hwindex: 0-based hardware plane index, -1 means unused
+ * @alpha: value of the plane alpha property
+ * @colorkey: value of the plane colorkey property
+ * @zpos: value of the plane zpos property
+ */
 struct rcar_du_plane_state {
struct drm_plane_state state;

const struct rcar_du_format_info *format;
-   int hwindex;/* 0-based, -1 means unused */
+   int hwindex;

unsigned int alpha;
unsigned int colorkey;
-- 
2.0.5



[PATCH 01/10] drm: rcar-du: Document the rcar_du_crtc structure

2015-04-29 Thread Laurent Pinchart
Document the structure fields using kerneldoc.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 5d9aa9b33769..e72f15c8c706 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -22,6 +22,20 @@

 struct rcar_du_group;

+/*
+ * rcar_du_crtc - the CRTC, representing a DU superposition processor
+ * @crtc: base DRM CRTC
+ * @clock: the CRTC functional clock
+ * @extclock: external pixel dot clock (optional)
+ * @mmio_offset: offset of the CRTC registers in the DU MMIO block
+ * @index: CRTC software and hardware index
+ * @started: whether the CRTC has been started and is running
+ * @event: event to post when the pending page flip completes
+ * @flip_wait: wait queue used to signal page flip completion
+ * @outputs: bitmask of the outputs (enum rcar_du_output) driven by this CRTC
+ * @enabled: whether the CRTC is enabled, used to control system resume
+ * @group: CRTC group this CRTC belongs to
+ */
 struct rcar_du_crtc {
struct drm_crtc crtc;

-- 
2.0.5



[PATCH 00/10] R-Car DU: Fix flicker due to hardware plane reassociations

2015-04-29 Thread Laurent Pinchart
Hello,

This patch set attempts to get rid of flicker caused by hardware plane
reassociations.

The 8 DU hardware planes are shared by two CRTCs and can be associated with
any of them. However, when association needs to change, for instance because
a currently unused planes that was associated with the first CRTC is getting
used by the second CRTC, the hardware architecture requires both CRTCs to be
restarted, causing flicker on both CRTCs.

To mitigate the problem this patch set avoids changing associations when a
plane is being disabled (07/10), teach the plane allocator to allocate
preferably from free planes already associated with the right CRTC (08/10) and
creates a split 4/4 pre-associations of planes to CRTCs (10/10). The other
patches include a bit of refactoring to make this possible (01/10 to 05/10 and
09/10) and handy debugging (06/10).

Flicker still occurs on the other CRTC when a CRTC in the group is enabled,
but this seems unrelated to plane associations. I'll investigate it
separately.

Laurent Pinchart (10):
  drm: rcar-du: Document the rcar_du_crtc structure
  drm: rcar-du: Document the rcar_du_plane_state structure
  drm: rcar-du: Move properties from rcar_du_planes to rcar_du_device
  drm: rcar-du: Embed rcar_du_planes structure into rcar_du_group
  drm: rcar-du: Rename to_rcar_du_plane_state to to_rcar_plane_state
  drm: rcar-du: Add plane allocation debugging
  drm: rcar-du: Keep plane to CRTC associations when disabling a plane
  drm: rcar-du: Consider plane to CRTC associations in the plane
allocator
  drm: rcar-du: Store the number of CRTCs per group in the group
structure
  drm: rcar-du: Split planes pre-association 4/4 between CRTCs

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  61 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  14 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   6 ++
 drivers/gpu/drm/rcar-du/rcar_du_group.c |   6 ++
 drivers/gpu/drm/rcar-du/rcar_du_group.h |   8 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 105 +---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  71 +++--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  21 ---
 8 files changed, 195 insertions(+), 97 deletions(-)

-- 
Regards,

Laurent Pinchart



[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90056

--- Comment #12 from Tom Stellard  ---
(In reply to Andy Furniss from comment #10)
> (In reply to Grigori Goronzy from comment #9)
> > Created attachment 115409 [details] [review] [review]
> > Full shader
> > 
> > That does not help either. Seems to break the SSA somehow. Full shader that
> > triggers the bug attached.
> > 
> > The patch I posted earlier help with the the reduced testcase, but not with
> > the full shader. Both undef incoming values in phi nodes and undef branch
> > conditions cause problems in different ways.
> 
> With the second patch + valley I get -
> 
> valley_x64: LiveVariables.cpp:114: void
> llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo &,
> llvm::MachineBasicBlock *, llvm::MachineBasicBlock *,
> std::vector &): Assertion `MBB != >front() &&
> "Can't find reaching def for virtreg"' failed.

Did test with only the patch from comment #8 or did you test with both patches?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/11659f30/attachment.html>


[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90056

--- Comment #11 from Tom Stellard  ---
Created attachment 115423
  --> https://bugs.freedesktop.org/attachment.cgi?id=115423=edit
Reduced test case

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/ed3e5819/attachment.html>


[Bug 90218] Kerbal Space Program crashes with Souther Islands

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90218

--- Comment #1 from Tom Stellard  ---
Can you run the game with the environment variable R600_DEBUG=ps,vs,gs and post
the output?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/d1c7005c/attachment.html>


[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89685

--- Comment #17 from Tom Stellard  ---
Created attachment 115421
  --> https://bugs.freedesktop.org/attachment.cgi?id=115421=edit
Possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/82cb31a6/attachment.html>


[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89685

--- Comment #16 from Kevin  ---
Created attachment 115420
  --> https://bugs.freedesktop.org/attachment.cgi?id=115420=edit
All output when running Dota

Arch Linux 64-bit with kernel 4.0.0-rc7-gf22e6e8 and mesa 10.5.4
I ran these commands
export R600_DEBUG=ps,vs,gs
steam steam://rungameid/570 >~/Desktop/steamlog--2015-04-28.txt

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/1105de88/attachment.html>


[PATCH/RFC] i915: fix screen flickering

2015-04-29 Thread Thomas Gummerer
Thomas Gummerer  writes:

> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)") fixes a null pointer dereference.
> Setting the primary and cursor panes to false in
> ilk_compute_wm_parameters to false does however give the following
> errors in the kernel log and causes the screen to flicker.
>
> [  101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
> *ERROR* uncleared fifo underrun on pipe A
> [  101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
>
> Always setting the panes to enabled fixes this error.
>
> Signed-off-by: Thomas Gummerer 
> ---
> Hi,
>
> I've noticed the regression in v4.1-rc1.  I'm not sure this is the best
> solution, but it's the best I could come up with in the time I had
> available.

I forgot to mention, the bug only occurs after suspending the system and
waking it up again.  In that case, moving the mouse pointer around on
the build in laptop screen triggers the flickering, while the external
monitor works just fine.

Might be unrelated, but I only managed to trigger the bug when the
system is suspended after the synergy server has started.

>  drivers/gpu/drm/i915/intel_pm.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fa4ccb3..377df60 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc 
> *crtc,
>   p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
>   p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
>  
> - if (crtc->primary->state->fb) {
> - p->pri.enabled = true;
> + if (crtc->primary->state->fb)
>   p->pri.bytes_per_pixel =
>   crtc->primary->state->fb->bits_per_pixel / 8;
> - } else {
> - p->pri.enabled = false;
> + else
>   p->pri.bytes_per_pixel = 0;
> - }
>  
> - if (crtc->cursor->state->fb) {
> - p->cur.enabled = true;
> - p->cur.bytes_per_pixel = 4;
> - } else {
> - p->cur.enabled = false;
> - p->cur.bytes_per_pixel = 0;
> - }
> + p->cur.bytes_per_pixel = 4;
> + /*
> +  * TODO: for now, assume primary and cursor planes are always enabled.
> +  * Setting them to false makes the screen flicker.
> +  */
> + p->pri.enabled = true;
> + p->cur.enabled = true;
> +
>   p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
>   p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
>  
> -- 
> 2.1.0.264.g0463184.dirty


[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89685

--- Comment #15 from Kevin  ---
I'm assuming that this patch
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d64adc3a79e419062432cfa8d1cbc437676a3fbd
has been incorporated to mesa by 10.5.4 and I can report that I still have the
same issue. I also built mesa from git in Arch Linux using the AUR mesa-git and
lib32-mesa-git tarballs, installed, and tried Dota with no success.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150429/e3ab82ce/attachment.html>


[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76130

--- Comment #9 from Adrien Prost-Boucle  ---
I forgot to mention the OS I'm using:

ArchLinux x86-64
Linux 4.0 from testing repo (also happens with the kernel from core repo)
mesa 10.5.4 from stock core repo
xf86-video-ati 1:7.5 from stock core repo

No patch, no personal kernel boot options, basically zero config.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 



[Bug 76130] Radeon HD 4570 set dpm state fails after suspend

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76130

--- Comment #8 from Adrien Prost-Boucle  ---
Hi,

I also experience this problem with my laptop at resume from sleep. 

About log messages, there does not seem to be a message when entering sleep.
When resuming from sleep, I can briefly see this message printed on the screen:

kernel: [drm:rv730_stop_dpm [radeon]] *ERROR* Could not force DPM to low

However at boot time, I see this in the log:

kernel: [drm] initializing kernel modesetting (RV710 0x1002:0x9553
0x1179:0xFF00).

I see a switch from rv710 to rv730, is this normal?
Previously, Thaddäus Tintenfisch reported a switch from rv730 to rv770...

If useful, the lspci command says:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV710/M92 [Mobility Radeon HD 4530/4570/545v]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI
Audio [Radeon HD 4000 series]

The patch proposed just before seems to be explicitely related to rv770, which
does not seem to be my case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 



[Bug 90221] Triangle boundary artifact on Shadow Warrior game

2015-04-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90221

Bug ID: 90221
   Summary: Triangle boundary artifact on Shadow Warrior game
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: lvella at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 115419
  --> https://bugs.freedesktop.org/attachment.cgi?id=115419=edit
Wall with light effect triggering the artifact.

On game Shawdow Warrior, with Southern Island chip, drivers from this PPA:
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Experienced both on Ubuntu 14.10 and, after upgrade, on Ubuntu 15.04.

Some special effects trigger a visible artifact on triangle primitive
boundaries, probably, see screenshot attached. With fglrx, the issue is not
present.

It seems the problem is on some post-processing shader, because, as can be seen
in the screenshot, the visible triangles does not respect the boundary of scene
objects, and if I move the mouse, they are fixed relative to the screen.

Running with the following env var (otherwise the game is unplayable slow on
current video settings):
R600_DEBUG=sb

Relevant info from glxinfo:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel
(git-7f5a8ac 2015-04-25 utopic-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: