[PATCH v6 05/15] drm/bridge: tc358767: Drop custom tc_write()/tc_read() accessors

[Andrey Smirnov]

A very unfortunate aspect of tc_write()/tc_read() macro helpers is
that they capture quite a bit of context around them and thus require
the caller to have magic variables 'ret' and 'tc' as well as label
'err'. That makes a number of code paths rather counter-intuitive and
somewhat clunky, for example tc_stream_clock_calc() ends up being like
this:

int ret;

tc_write(DP0_VIDMNGEN1, 32768);

return 0;
err:
return ret;

which is rather surprising when you read the code for the first
time. Since those helpers arguably aren't really saving that much code
and there's no way of fixing them without making them too verbose to
be worth it change the driver code to not use them at all.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 383 ++
 1 file changed, 231 insertions(+), 152 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 5b78021d6c5b..6a3e7c7e1189 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -280,20 +280,6 @@ static inline struct tc_data *connector_to_tc(struct 
drm_connector *c)
return container_of(c, struct tc_data, connector);
 }
 
-/* Simple macros to avoid repeated error checks */
-#define tc_write(reg, var) \
-   do {\
-   ret = regmap_write(tc->regmap, reg, var);   \
-   if (ret)\
-   goto err;   \
-   } while (0)
-#define tc_read(reg, var)  \
-   do {\
-   ret = regmap_read(tc->regmap, reg, var);\
-   if (ret)\
-   goto err;   \
-   } while (0)
-
 static inline int tc_poll_timeout(struct tc_data *tc, unsigned int addr,
  unsigned int cond_mask,
  unsigned int cond_value,
@@ -351,7 +337,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
 
ret = tc_aux_wait_busy(tc, 100);
if (ret)
-   goto err;
+   return ret;
 
if (request == DP_AUX_I2C_WRITE || request == DP_AUX_NATIVE_WRITE) {
/* Store data */
@@ -362,7 +348,11 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
tmp = (tmp << 8) | buf[i];
i++;
if (((i % 4) == 0) || (i == size)) {
-   tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
+   ret = regmap_write(tc->regmap,
+  DP0_AUXWDATA((i - 1) >> 2),
+  tmp);
+   if (ret)
+   return ret;
tmp = 0;
}
}
@@ -372,23 +362,32 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
}
 
/* Store address */
-   tc_write(DP0_AUXADDR, msg->address);
+   ret = regmap_write(tc->regmap, DP0_AUXADDR, msg->address);
+   if (ret)
+   return ret;
/* Start transfer */
-   tc_write(DP0_AUXCFG0, ((size - 1) << 8) | request);
+   ret = regmap_write(tc->regmap, DP0_AUXCFG0,
+  ((size - 1) << 8) | request);
+   if (ret)
+   return ret;
 
ret = tc_aux_wait_busy(tc, 100);
if (ret)
-   goto err;
+   return ret;
 
ret = tc_aux_get_status(tc, >reply);
if (ret)
-   goto err;
+   return ret;
 
if (request == DP_AUX_I2C_READ || request == DP_AUX_NATIVE_READ) {
/* Read data */
while (i < size) {
-   if ((i % 4) == 0)
-   tc_read(DP0_AUXRDATA(i >> 2), );
+   if ((i % 4) == 0) {
+   ret = regmap_read(tc->regmap,
+ DP0_AUXRDATA(i >> 2), );
+   if (ret)
+   return ret;
+   }
buf[i] = tmp & 0xff;
tmp = tmp >> 8;
i++;
@@ -396,8 +395,6 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
}
 
return size;
-err:
-   return ret;
 }
 
 static const char * const 

[PATCH v6 13/15] drm/bridge: tc358767: Drop unnecessary 8 byte buffer

[Andrey Smirnov]

tc_get_display_props() never reads more than a byte via AUX, so
there's no need to reserve 8 for that purpose. No function change
intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 7cc26e26f371..f0baf6d7ca80 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -645,8 +645,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
 static int tc_get_display_props(struct tc_data *tc)
 {
int ret;
-   /* temp buffer */
-   u8 tmp[8];
+   u8 reg;
 
/* Read DP Rx Link Capability */
ret = drm_dp_link_probe(>aux, >link.base);
@@ -662,21 +661,21 @@ static int tc_get_display_props(struct tc_data *tc)
tc->link.base.num_lanes = 2;
}
 
-   ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, tmp);
+   ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
if (ret < 0)
goto err_dpcd_read;
-   tc->link.spread = tmp[0] & DP_MAX_DOWNSPREAD_0_5;
+   tc->link.spread = reg & DP_MAX_DOWNSPREAD_0_5;
 
-   ret = drm_dp_dpcd_readb(>aux, DP_MAIN_LINK_CHANNEL_CODING, tmp);
+   ret = drm_dp_dpcd_readb(>aux, DP_MAIN_LINK_CHANNEL_CODING, );
if (ret < 0)
goto err_dpcd_read;
 
tc->link.scrambler_dis = false;
/* read assr */
-   ret = drm_dp_dpcd_readb(>aux, DP_EDP_CONFIGURATION_SET, tmp);
+   ret = drm_dp_dpcd_readb(>aux, DP_EDP_CONFIGURATION_SET, );
if (ret < 0)
goto err_dpcd_read;
-   tc->link.assr = tmp[0] & DP_ALTERNATE_SCRAMBLER_RESET_ENABLE;
+   tc->link.assr = reg & DP_ALTERNATE_SCRAMBLER_RESET_ENABLE;
 
dev_dbg(tc->dev, "DPCD rev: %d.%d, rate: %s, lanes: %d, framing: %s\n",
tc->link.base.revision >> 4, tc->link.base.revision & 0x0f,
-- 
2.21.0

[PATCH v6 10/15] drm/bridge: tc358767: Introduce tc_set_syspllparam()

[Andrey Smirnov]

Move common code converting clock rate to an appropriate constant and
configuring SYS_PLLPARAM register into a separate routine and convert
the rest of the code to use it. No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Chris Healy 
Cc: Cory Tusar 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 46 +++
 1 file changed, 16 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index b01c1c8341e1..7a3a1b2d5c56 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -565,35 +565,40 @@ static int tc_stream_clock_calc(struct tc_data *tc)
return regmap_write(tc->regmap, DP0_VIDMNGEN1, 32768);
 }
 
-static int tc_aux_link_setup(struct tc_data *tc)
+static int tc_set_syspllparam(struct tc_data *tc)
 {
unsigned long rate;
-   u32 dp0_auxcfg1;
-   u32 value;
-   int ret;
+   u32 pllparam = SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
 
rate = clk_get_rate(tc->refclk);
switch (rate) {
case 3840:
-   value = REF_FREQ_38M4;
+   pllparam |= REF_FREQ_38M4;
break;
case 2600:
-   value = REF_FREQ_26M;
+   pllparam |= REF_FREQ_26M;
break;
case 1920:
-   value = REF_FREQ_19M2;
+   pllparam |= REF_FREQ_19M2;
break;
case 1300:
-   value = REF_FREQ_13M;
+   pllparam |= REF_FREQ_13M;
break;
default:
dev_err(tc->dev, "Invalid refclk rate: %lu Hz\n", rate);
return -EINVAL;
}
 
+   return regmap_write(tc->regmap, SYS_PLLPARAM, pllparam);
+}
+
+static int tc_aux_link_setup(struct tc_data *tc)
+{
+   int ret;
+   u32 dp0_auxcfg1;
+
/* Setup DP-PHY / PLL */
-   value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
-   ret = regmap_write(tc->regmap, SYS_PLLPARAM, value);
+   ret = tc_set_syspllparam(tc);
if (ret)
goto err;
 
@@ -852,7 +857,6 @@ static int tc_main_link_enable(struct tc_data *tc)
 {
struct drm_dp_aux *aux = >aux;
struct device *dev = tc->dev;
-   unsigned int rate;
u32 dp_phy_ctrl;
u32 value;
int ret;
@@ -880,25 +884,7 @@ static int tc_main_link_enable(struct tc_data *tc)
if (ret)
return ret;
 
-   rate = clk_get_rate(tc->refclk);
-   switch (rate) {
-   case 3840:
-   value = REF_FREQ_38M4;
-   break;
-   case 2600:
-   value = REF_FREQ_26M;
-   break;
-   case 1920:
-   value = REF_FREQ_19M2;
-   break;
-   case 1300:
-   value = REF_FREQ_13M;
-   break;
-   default:
-   return -EINVAL;
-   }
-   value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
-   ret = regmap_write(tc->regmap, SYS_PLLPARAM, value);
+   ret = tc_set_syspllparam(tc);
if (ret)
return ret;
 
-- 
2.21.0

[PATCH v6 12/15] drm/bridge: tc358767: Simplify tc_aux_wait_busy()

[Andrey Smirnov]

We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so
we may as well hardcode that value and simplify function's signature.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index fe672f6bba73..7cc26e26f371 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -292,10 +292,9 @@ static inline int tc_poll_timeout(struct tc_data *tc, 
unsigned int addr,
sleep_us, timeout_us);
 }
 
-static int tc_aux_wait_busy(struct tc_data *tc, unsigned int timeout_ms)
+static int tc_aux_wait_busy(struct tc_data *tc)
 {
-   return tc_poll_timeout(tc, DP0_AUXSTATUS, AUX_BUSY, 0,
-  1000, 1000 * timeout_ms);
+   return tc_poll_timeout(tc, DP0_AUXSTATUS, AUX_BUSY, 0, 1000, 10);
 }
 
 static int tc_aux_write_data(struct tc_data *tc, const void *data,
@@ -339,7 +338,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (size == 0)
return 0;
 
-   ret = tc_aux_wait_busy(tc, 100);
+   ret = tc_aux_wait_busy(tc);
if (ret)
return ret;
 
@@ -367,7 +366,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (ret)
return ret;
 
-   ret = tc_aux_wait_busy(tc, 100);
+   ret = tc_aux_wait_busy(tc);
if (ret)
return ret;
 
-- 
2.21.0

[PATCH v6 07/15] drm/bridge: tc358767: Simplify AUX data write

[Andrey Smirnov]

Simplify AUX data write by dropping index arithmetic and shifting and
replacing it with a call to a helper function that does two things:

1. Copies user-provided data into a write buffer
2. Transfers contents of the write buffer to up to 4 32-bit
   registers on the chip

Note that separate data endianness fix:

tmp = (tmp << 8) | buf[i];

that was reserved for DP_AUX_I2C_WRITE looks really strange, since it
will place data differently depending on the passed user-data
size. E.g. for a write of 1 byte, data transferred to the chip would
look like:

[byte0] [dummy1] [dummy2] [dummy3]

whereas for a write of 4 bytes we'd get:

[byte3] [byte2] [byte1] [byte0]

Since there's no indication in the datasheet that I2C write buffer
should be treated differently than AUX write buffer and no comment in
the original code explaining why it was done this way, that special
I2C write buffer transformation was dropped in this patch.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 48 +--
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 02f6d907f5c4..a441e8e66287 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -321,6 +321,21 @@ static int tc_aux_get_status(struct tc_data *tc, u8 *reply)
return 0;
 }
 
+static int tc_aux_write_data(struct tc_data *tc, const void *data,
+size_t size)
+{
+   u32 auxwdata[DP_AUX_MAX_PAYLOAD_BYTES / sizeof(u32)] = { 0 };
+   int ret, count = ALIGN(size, sizeof(u32));
+
+   memcpy(auxwdata, data, size);
+
+   ret = regmap_raw_write(tc->regmap, DP0_AUXWDATA(0), auxwdata, count);
+   if (ret)
+   return ret;
+
+   return size;
+}
+
 static int tc_aux_read_data(struct tc_data *tc, void *data, size_t size)
 {
u32 auxrdata[DP_AUX_MAX_PAYLOAD_BYTES / sizeof(u32)];
@@ -341,9 +356,6 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
struct tc_data *tc = aux_to_tc(aux);
size_t size = min_t(size_t, 8, msg->size);
u8 request = msg->request & ~DP_AUX_I2C_MOT;
-   u8 *buf = msg->buffer;
-   u32 tmp = 0;
-   int i = 0;
int ret;
 
if (size == 0)
@@ -353,25 +365,17 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (ret)
return ret;
 
-   if (request == DP_AUX_I2C_WRITE || request == DP_AUX_NATIVE_WRITE) {
-   /* Store data */
-   while (i < size) {
-   if (request == DP_AUX_NATIVE_WRITE)
-   tmp = tmp | (buf[i] << (8 * (i & 0x3)));
-   else
-   tmp = (tmp << 8) | buf[i];
-   i++;
-   if (((i % 4) == 0) || (i == size)) {
-   ret = regmap_write(tc->regmap,
-  DP0_AUXWDATA((i - 1) >> 2),
-  tmp);
-   if (ret)
-   return ret;
-   tmp = 0;
-   }
-   }
-   } else if (request != DP_AUX_I2C_READ &&
-  request != DP_AUX_NATIVE_READ) {
+   switch (request) {
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_I2C_READ:
+   break;
+   case DP_AUX_NATIVE_WRITE:
+   case DP_AUX_I2C_WRITE:
+   ret = tc_aux_write_data(tc, msg->buffer, size);
+   if (ret < 0)
+   return ret;
+   break;
+   default:
return -EINVAL;
}
 
-- 
2.21.0

[PATCH v6 09/15] drm/bridge: tc358767: Use reported AUX transfer size

[Andrey Smirnov]

Don't assume that requested data transfer size is the same as amount
of data that was transferred. Change the code to get that information
from DP0_AUXSTATUS instead.

Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it
will always called after tc_aux_wait_busy()) and there's only one user
of it, inline its code into tc_aux_transfer() instead of trying to
accommodate the change above.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 40 ++-
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index bdbf88057946..b01c1c8341e1 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -152,10 +152,10 @@
 #define DP0_AUXWDATA(i)(0x066c + (i) * 4)
 #define DP0_AUXRDATA(i)(0x067c + (i) * 4)
 #define DP0_AUXSTATUS  0x068c
-#define AUX_STATUS_MASK0xf0
-#define AUX_STATUS_SHIFT   4
-#define AUX_TIMEOUTBIT(1)
-#define AUX_BUSY   BIT(0)
+#define AUX_BYTES  GENMASK(15, 8)
+#define AUX_STATUS GENMASK(7, 4)
+#define AUX_TIMEOUTBIT(1)
+#define AUX_BUSY   BIT(0)
 #define DP0_AUXI2CADR  0x0698
 
 /* Link Training */
@@ -298,29 +298,6 @@ static int tc_aux_wait_busy(struct tc_data *tc, unsigned 
int timeout_ms)
   1000, 1000 * timeout_ms);
 }
 
-static int tc_aux_get_status(struct tc_data *tc, u8 *reply)
-{
-   int ret;
-   u32 value;
-
-   ret = regmap_read(tc->regmap, DP0_AUXSTATUS, );
-   if (ret < 0)
-   return ret;
-
-   if (value & AUX_BUSY) {
-   dev_err(tc->dev, "aux busy!\n");
-   return -EBUSY;
-   }
-
-   if (value & AUX_TIMEOUT) {
-   dev_err(tc->dev, "aux access timeout!\n");
-   return -ETIMEDOUT;
-   }
-
-   *reply = (value & AUX_STATUS_MASK) >> AUX_STATUS_SHIFT;
-   return 0;
-}
-
 static int tc_aux_write_data(struct tc_data *tc, const void *data,
 size_t size)
 {
@@ -356,6 +333,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
struct tc_data *tc = aux_to_tc(aux);
size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size);
u8 request = msg->request & ~DP_AUX_I2C_MOT;
+   u32 auxstatus;
int ret;
 
if (size == 0)
@@ -393,10 +371,16 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (ret)
return ret;
 
-   ret = tc_aux_get_status(tc, >reply);
+   ret = regmap_read(tc->regmap, DP0_AUXSTATUS, );
if (ret)
return ret;
 
+   if (auxstatus & AUX_TIMEOUT)
+   return -ETIMEDOUT;
+
+   size = FIELD_GET(AUX_BYTES, auxstatus);
+   msg->reply = FIELD_GET(AUX_STATUS, auxstatus);
+
switch (request) {
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
-- 
2.21.0

[PATCH v6 08/15] drm/bridge: tc358767: Increase AUX transfer length limit

[Andrey Smirnov]

According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in case of I2C transfers), so limit it
to 15.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index a441e8e66287..bdbf88057946 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -354,7 +354,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
   struct drm_dp_aux_msg *msg)
 {
struct tc_data *tc = aux_to_tc(aux);
-   size_t size = min_t(size_t, 8, msg->size);
+   size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size);
u8 request = msg->request & ~DP_AUX_I2C_MOT;
int ret;
 
-- 
2.21.0

[PATCH v6 11/15] drm/bridge: tc358767: Introduce tc_pllupdate()

[Andrey Smirnov]

tc_wait_pll_lock() is always called as a follow-up for updating
PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
things, merge the two operation into a single helper function
tc_pllupdate() and convert the rest of the code to use it. No
functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 7a3a1b2d5c56..fe672f6bba73 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -427,10 +427,18 @@ static u32 tc_srcctrl(struct tc_data *tc)
return reg;
 }
 
-static void tc_wait_pll_lock(struct tc_data *tc)
+static int tc_pllupdate(struct tc_data *tc, unsigned int pllctrl)
 {
+   int ret;
+
+   ret = regmap_write(tc->regmap, pllctrl, PLLUPDATE | PLLEN);
+   if (ret)
+   return ret;
+
/* Wait for PLL to lock: up to 2.09 ms, depending on refclk */
usleep_range(3000, 6000);
+
+   return 0;
 }
 
 static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
@@ -530,13 +538,7 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, 
u32 pixelclock)
return ret;
 
/* Force PLL parameter update and disable bypass */
-   ret = regmap_write(tc->regmap, PXL_PLLCTRL, PLLUPDATE | PLLEN);
-   if (ret)
-   return ret;
-
-   tc_wait_pll_lock(tc);
-
-   return 0;
+   return tc_pllupdate(tc, PXL_PLLCTRL);
 }
 
 static int tc_pxl_pll_dis(struct tc_data *tc)
@@ -610,15 +612,13 @@ static int tc_aux_link_setup(struct tc_data *tc)
 * Initially PLLs are in bypass. Force PLL parameter update,
 * disable PLL bypass, enable PLL
 */
-   ret = regmap_write(tc->regmap, DP0_PLLCTRL, PLLUPDATE | PLLEN);
+   ret = tc_pllupdate(tc, DP0_PLLCTRL);
if (ret)
goto err;
-   tc_wait_pll_lock(tc);
 
-   ret = regmap_write(tc->regmap, DP1_PLLCTRL, PLLUPDATE | PLLEN);
+   ret = tc_pllupdate(tc, DP1_PLLCTRL);
if (ret)
goto err;
-   tc_wait_pll_lock(tc);
 
ret = tc_poll_timeout(tc, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1, 1000);
if (ret == -ETIMEDOUT) {
@@ -898,15 +898,13 @@ static int tc_main_link_enable(struct tc_data *tc)
return ret;
 
/* PLL setup */
-   ret = regmap_write(tc->regmap, DP0_PLLCTRL, PLLUPDATE | PLLEN);
+   ret = tc_pllupdate(tc, DP0_PLLCTRL);
if (ret)
return ret;
-   tc_wait_pll_lock(tc);
 
-   ret = regmap_write(tc->regmap, DP1_PLLCTRL, PLLUPDATE | PLLEN);
+   ret = tc_pllupdate(tc, DP1_PLLCTRL);
if (ret)
return ret;
-   tc_wait_pll_lock(tc);
 
/* Reset/Enable Main Links */
dp_phy_ctrl |= DP_PHY_RST | PHY_M1_RST | PHY_M0_RST;
-- 
2.21.0

[PATCH v6 14/15] drm/bridge: tc358767: Replace magic number in tc_main_link_enable()

[Andrey Smirnov]

We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be
enough. This also gets rid of a magic number as a bonus.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index f0baf6d7ca80..3f8a15390813 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -858,7 +858,7 @@ static int tc_main_link_enable(struct tc_data *tc)
u32 dp_phy_ctrl;
u32 value;
int ret;
-   u8 tmp[8];
+   u8 tmp[DP_LINK_STATUS_SIZE];
 
dev_dbg(tc->dev, "link enable\n");
 
-- 
2.21.0

[PATCH v6 06/15] drm/bridge: tc358767: Simplify AUX data read

[Andrey Smirnov]

Simplify AUX data read by removing index arithmetic and shifting with
a helper function that does two things:

1. Fetch data from up to 4 32-bit registers from the chip
2. Copy read data into user provided array.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 6a3e7c7e1189..02f6d907f5c4 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -321,6 +321,20 @@ static int tc_aux_get_status(struct tc_data *tc, u8 *reply)
return 0;
 }
 
+static int tc_aux_read_data(struct tc_data *tc, void *data, size_t size)
+{
+   u32 auxrdata[DP_AUX_MAX_PAYLOAD_BYTES / sizeof(u32)];
+   int ret, count = ALIGN(size, sizeof(u32));
+
+   ret = regmap_raw_read(tc->regmap, DP0_AUXRDATA(0), auxrdata, count);
+   if (ret)
+   return ret;
+
+   memcpy(data, auxrdata, size);
+
+   return size;
+}
+
 static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
   struct drm_dp_aux_msg *msg)
 {
@@ -379,19 +393,10 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (ret)
return ret;
 
-   if (request == DP_AUX_I2C_READ || request == DP_AUX_NATIVE_READ) {
-   /* Read data */
-   while (i < size) {
-   if ((i % 4) == 0) {
-   ret = regmap_read(tc->regmap,
- DP0_AUXRDATA(i >> 2), );
-   if (ret)
-   return ret;
-   }
-   buf[i] = tmp & 0xff;
-   tmp = tmp >> 8;
-   i++;
-   }
+   switch (request) {
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_I2C_READ:
+   return tc_aux_read_data(tc, msg->buffer, size);
}
 
return size;
-- 
2.21.0

[PATCH v6 15/15] drm/bridge: tc358767: Add support for address-only I2C transfers

[Andrey Smirnov]

Transfer size of zero means a request to do an address-only
transfer. Since the HW support this, we probably shouldn't be just
ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
through, since it is supported by the HW as well.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 42 +++
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 3f8a15390813..7b8e19d6cf29 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -145,6 +145,8 @@
 
 /* AUX channel */
 #define DP0_AUXCFG00x0660
+#define DP0_AUXCFG0_BSIZE  GENMASK(11, 8)
+#define DP0_AUXCFG0_ADDR_ONLY  BIT(4)
 #define DP0_AUXCFG10x0664
 #define AUX_RX_FILTER_EN   BIT(16)
 
@@ -326,6 +328,18 @@ static int tc_aux_read_data(struct tc_data *tc, void 
*data, size_t size)
return size;
 }
 
+static u32 tc_auxcfg0(struct drm_dp_aux_msg *msg, size_t size)
+{
+   u32 auxcfg0 = msg->request;
+
+   if (size)
+   auxcfg0 |= FIELD_PREP(DP0_AUXCFG0_BSIZE, size - 1);
+   else
+   auxcfg0 |= DP0_AUXCFG0_ADDR_ONLY;
+
+   return auxcfg0;
+}
+
 static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
   struct drm_dp_aux_msg *msg)
 {
@@ -335,9 +349,6 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
u32 auxstatus;
int ret;
 
-   if (size == 0)
-   return 0;
-
ret = tc_aux_wait_busy(tc);
if (ret)
return ret;
@@ -348,9 +359,11 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
break;
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
-   ret = tc_aux_write_data(tc, msg->buffer, size);
-   if (ret < 0)
-   return ret;
+   if (size) {
+   ret = tc_aux_write_data(tc, msg->buffer, size);
+   if (ret < 0)
+   return ret;
+   }
break;
default:
return -EINVAL;
@@ -361,8 +374,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
if (ret)
return ret;
/* Start transfer */
-   ret = regmap_write(tc->regmap, DP0_AUXCFG0,
-  ((size - 1) << 8) | request);
+   ret = regmap_write(tc->regmap, DP0_AUXCFG0, tc_auxcfg0(msg, size));
if (ret)
return ret;
 
@@ -376,14 +388,22 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
 
if (auxstatus & AUX_TIMEOUT)
return -ETIMEDOUT;
-
-   size = FIELD_GET(AUX_BYTES, auxstatus);
+   /*
+* For some reason address-only DP_AUX_I2C_WRITE (MOT), still
+* reports 1 byte transferred in its status. To deal we that
+* we ignore aux_bytes field if we know that this was an
+* address-only transfer
+*/
+   if (size)
+   size = FIELD_GET(AUX_BYTES, auxstatus);
msg->reply = FIELD_GET(AUX_STATUS, auxstatus);
 
switch (request) {
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
-   return tc_aux_read_data(tc, msg->buffer, size);
+   if (size)
+   return tc_aux_read_data(tc, msg->buffer, size);
+   break;
}
 
return size;
-- 
2.21.0

[PATCH v6 04/15] drm/bridge: tc358767: Simplify tc_set_video_mode()

[Andrey Smirnov]

Simplify tc_set_video_mode() by replacing explicit shifting using
macros from . No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 106 ++
 1 file changed, 78 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 31f5045e7e42..5b78021d6c5b 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -24,6 +24,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,7 @@
 
 /* Video Path */
 #define VPCTRL00x0450
+#define VSDELAYGENMASK(31, 20)
 #define OPXLFMT_RGB666 (0 << 8)
 #define OPXLFMT_RGB888 (1 << 8)
 #define FRMSYNC_DISABLED   (0 << 4) /* Video Timing Gen Disabled */
@@ -63,9 +65,17 @@
 #define MSF_DISABLED   (0 << 0) /* Magic Square FRC disabled */
 #define MSF_ENABLED(1 << 0) /* Magic Square FRC enabled */
 #define HTIM01 0x0454
+#define HPWGENMASK(8, 0)
+#define HBPR   GENMASK(24, 16)
 #define HTIM02 0x0458
+#define HDISPR GENMASK(10, 0)
+#define HFPR   GENMASK(24, 16)
 #define VTIM01 0x045c
+#define VSPR   GENMASK(7, 0)
+#define VBPR   GENMASK(23, 16)
 #define VTIM02 0x0460
+#define VFPR   GENMASK(23, 16)
+#define VDISPR GENMASK(10, 0)
 #define VFUEN0 0x0464
 #define VFUEN  BIT(0)   /* Video Frame Timing Upload */
 
@@ -108,14 +118,28 @@
 /* Main Channel */
 #define DP0_SECSAMPLE  0x0640
 #define DP0_VIDSYNCDELAY   0x0644
+#define VID_SYNC_DLY   GENMASK(15, 0)
+#define THRESH_DLY GENMASK(31, 16)
+
 #define DP0_TOTALVAL   0x0648
+#define H_TOTALGENMASK(15, 0)
+#define V_TOTALGENMASK(31, 16)
 #define DP0_STARTVAL   0x064c
+#define H_STARTGENMASK(15, 0)
+#define V_STARTGENMASK(31, 16)
 #define DP0_ACTIVEVAL  0x0650
+#define H_ACT  GENMASK(15, 0)
+#define V_ACT  GENMASK(31, 16)
+
 #define DP0_SYNCVAL0x0654
+#define VS_WIDTH   GENMASK(30, 16)
+#define HS_WIDTH   GENMASK(14, 0)
 #define SYNCVAL_HS_POL_ACTIVE_LOW  (1 << 15)
 #define SYNCVAL_VS_POL_ACTIVE_LOW  (1 << 31)
 #define DP0_MISC   0x0658
 #define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */
+#define MAX_TU_SYMBOL  GENMASK(28, 23)
+#define TU_SIZEGENMASK(21, 16)
 #define BPC_6  (0 << 5)
 #define BPC_8  (1 << 5)
 
@@ -192,6 +216,12 @@
 
 /* Test & Debug */
 #define TSTCTL 0x0a00
+#define COLOR_RGENMASK(31, 24)
+#define COLOR_GGENMASK(23, 16)
+#define COLOR_BGENMASK(15, 8)
+#define ENI2CFILTERBIT(4)
+#define COLOR_BAR_MODE GENMASK(1, 0)
+#define COLOR_BAR_MODE_BARS2
 #define PLL_DBG0x0a04
 
 static bool tc_test_pattern;
@@ -672,6 +702,7 @@ static int tc_set_video_mode(struct tc_data *tc,
int upper_margin = mode->vtotal - mode->vsync_end;
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
+   u32 dp0_syncval;
 
/*
 * Recommended maximum number of symbols transferred in a transfer unit:
@@ -696,50 +727,69 @@ static int tc_set_video_mode(struct tc_data *tc,
 * assume we do not need any delay when DPI is a source of
 * sync signals
 */
-   tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
+   tc_write(VPCTRL0,
+FIELD_PREP(VSDELAY, 0) |
 OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
-   tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
-(ALIGN(hsync_len, 2) << 0));/* Hsync */
-   tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
-(ALIGN(mode->hdisplay, 2) << 0)); /* width */
-   tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
-(vsync_len << 0)); /* Vsync */
-   tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
-(mode->vdisplay << 0));/* height */
+   tc_write(HTIM01,
+ 

[PATCH v6 03/15] drm/bridge: tc358767: Simplify polling in tc_link_training()

[Andrey Smirnov]

Replace explicit polling in tc_link_training() with equivalent call to
tc_poll_timeout() for simplicity. No functional change intended (not
including slightly altered debug output).

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index f463ef6d4271..31f5045e7e42 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -748,22 +748,19 @@ static int tc_set_video_mode(struct tc_data *tc,
 
 static int tc_wait_link_training(struct tc_data *tc)
 {
-   u32 timeout = 1000;
u32 value;
int ret;
 
-   do {
-   udelay(1);
-   tc_read(DP0_LTSTAT, );
-   } while ((!(value & LT_LOOPDONE)) && (--timeout));
-
-   if (timeout == 0) {
+   ret = tc_poll_timeout(tc, DP0_LTSTAT, LT_LOOPDONE,
+ LT_LOOPDONE, 1, 1000);
+   if (ret) {
dev_err(tc->dev, "Link training timeout waiting for 
LT_LOOPDONE!\n");
-   return -ETIMEDOUT;
+   return ret;
}
 
-   return (value >> 8) & 0x7;
+   tc_read(DP0_LTSTAT, );
 
+   return (value >> 8) & 0x7;
 err:
return ret;
 }
-- 
2.21.0

[PATCH v6 02/15] drm/bridge: tc358767: Simplify polling in tc_main_link_setup()

[Andrey Smirnov]

Replace explicit polling loop with equivalent call to
tc_poll_timeout() for brevity. No functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index fb8a1942ec54..f463ef6d4271 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -774,7 +774,6 @@ static int tc_main_link_enable(struct tc_data *tc)
struct device *dev = tc->dev;
unsigned int rate;
u32 dp_phy_ctrl;
-   int timeout;
u32 value;
int ret;
u8 tmp[8];
@@ -831,15 +830,10 @@ static int tc_main_link_enable(struct tc_data *tc)
dp_phy_ctrl &= ~(DP_PHY_RST | PHY_M1_RST | PHY_M0_RST);
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
 
-   timeout = 1000;
-   do {
-   tc_read(DP_PHY_CTRL, );
-   udelay(1);
-   } while ((!(value & PHY_RDY)) && (--timeout));
-
-   if (timeout == 0) {
+   ret = tc_poll_timeout(tc, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1, 1000);
+   if (ret) {
dev_err(dev, "timeout waiting for phy become ready");
-   return -ETIMEDOUT;
+   return ret;
}
 
/* Set misc: 8 bits per color */
-- 
2.21.0

[PATCH v6 00/15] tc358767 driver improvements

[Andrey Smirnov]

Everyone:

This series contains various improvements (at least in my mind) and
fixes that I made to tc358767 while working with the code of the
driver. Hopefuly each patch is self explanatory.

Feedback is welcome!

Thanks,
Andrey Smirnov

Changes since [v5]:

- Fixed regression in "drm/bridge: tc358767: Add support for
  address-only I2C transfers" that broke EDID reading

- Moved said patch to be the last in case it is still causing
  problems and needs to be dropped

Changes since [v4]:

- tc_pllupdate_pllen() renamed to tc_pllupdate()

- Collected Reviewed-bys from Andrzej for the rest of the series

Changes since [v3]:

- Collected Reviewed-bys from Andrzej

- Dropped explicit check for -ETIMEDOUT in "drm/bridge: tc358767:
  Simplify polling in tc_main_link_setup()" for consistency

- AUX transfer code converted to user regmap_raw_read(),
  regmap_raw_write()

Changes since [v2]:

- Patchset rebased on top of v4 of Tomi's series that recently
  went in (https://patchwork.freedesktop.org/series/58176/#rev5)
  
- AUX transfer code converted to user regmap_bulk_read(),
  regmap_bulk_write()

Changes since [v1]:

- Patchset rebased on top of
  https://patchwork.freedesktop.org/series/58176/
  
- Patches to remove both tc_write() and tc_read() helpers added

- Patches to rework AUX transfer code added

- Both "drm/bridge: tc358767: Simplify polling in
  tc_main_link_setup()" and "drm/bridge: tc358767: Simplify
  polling in tc_link_training()" changed to use tc_poll_timeout()
  instead of regmap_read_poll_timeout()

[v5] lkml.kernel.org/r/20190612083252.15321-1-andrew.smir...@gmail.com
[v4] lkml.kernel.org/r/20190607044550.13361-1-andrew.smir...@gmail.com
[v3] lkml.kernel.org/r/20190605070507.11417-1-andrew.smir...@gmail.com
[v2] lkml.kernel.org/r/20190322032901.12045-1-andrew.smir...@gmail.com
[v1] lkml.kernel.org/r/20190226193609.9862-1-andrew.smir...@gmail.com

Andrey Smirnov (15):
  drm/bridge: tc358767: Simplify tc_poll_timeout()
  drm/bridge: tc358767: Simplify polling in tc_main_link_setup()
  drm/bridge: tc358767: Simplify polling in tc_link_training()
  drm/bridge: tc358767: Simplify tc_set_video_mode()
  drm/bridge: tc358767: Drop custom tc_write()/tc_read() accessors
  drm/bridge: tc358767: Simplify AUX data read
  drm/bridge: tc358767: Simplify AUX data write
  drm/bridge: tc358767: Increase AUX transfer length limit
  drm/bridge: tc358767: Use reported AUX transfer size
  drm/bridge: tc358767: Introduce tc_set_syspllparam()
  drm/bridge: tc358767: Introduce tc_pllupdate()
  drm/bridge: tc358767: Simplify tc_aux_wait_busy()
  drm/bridge: tc358767: Drop unnecessary 8 byte buffer
  drm/bridge: tc358767: Replace magic number in tc_main_link_enable()
  drm/bridge: tc358767: Add support for address-only I2C transfers

 drivers/gpu/drm/bridge/tc358767.c | 651 +-
 1 file changed, 376 insertions(+), 275 deletions(-)

-- 
2.21.0

[PATCH v6 01/15] drm/bridge: tc358767: Simplify tc_poll_timeout()

[Andrey Smirnov]

Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Laurent Pinchart 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 58e3ca0e25af..fb8a1942ec54 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -264,34 +264,21 @@ static inline struct tc_data *connector_to_tc(struct 
drm_connector *c)
goto err;   \
} while (0)
 
-static inline int tc_poll_timeout(struct regmap *map, unsigned int addr,
+static inline int tc_poll_timeout(struct tc_data *tc, unsigned int addr,
  unsigned int cond_mask,
  unsigned int cond_value,
  unsigned long sleep_us, u64 timeout_us)
 {
-   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us);
unsigned int val;
-   int ret;
 
-   for (;;) {
-   ret = regmap_read(map, addr, );
-   if (ret)
-   break;
-   if ((val & cond_mask) == cond_value)
-   break;
-   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) {
-   ret = regmap_read(map, addr, );
-   break;
-   }
-   if (sleep_us)
-   usleep_range((sleep_us >> 2) + 1, sleep_us);
-   }
-   return ret ?: (((val & cond_mask) == cond_value) ? 0 : -ETIMEDOUT);
+   return regmap_read_poll_timeout(tc->regmap, addr, val,
+   (val & cond_mask) == cond_value,
+   sleep_us, timeout_us);
 }
 
 static int tc_aux_wait_busy(struct tc_data *tc, unsigned int timeout_ms)
 {
-   return tc_poll_timeout(tc->regmap, DP0_AUXSTATUS, AUX_BUSY, 0,
+   return tc_poll_timeout(tc, DP0_AUXSTATUS, AUX_BUSY, 0,
   1000, 1000 * timeout_ms);
 }
 
@@ -598,8 +585,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
tc_write(DP1_PLLCTRL, PLLUPDATE | PLLEN);
tc_wait_pll_lock(tc);
 
-   ret = tc_poll_timeout(tc->regmap, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1,
- 1000);
+   ret = tc_poll_timeout(tc, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1, 1000);
if (ret == -ETIMEDOUT) {
dev_err(tc->dev, "Timeout waiting for PHY to become ready");
return ret;
-- 
2.21.0

Re: nouveau: DRM: GPU lockup - switching to software fbcon

[Ilia Mirkin]

On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
 wrote:
>
> On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > dmesg
> >
> >  nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> >  nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> >  nouveau :01:00.0: fifo: runlist 0: scheduled for recovery
> >  nouveau :01:00.0: fifo: channel 5: killed
> >  nouveau :01:00.0: fifo: engine 6: scheduled for recovery
> >  nouveau :01:00.0: fifo: engine 0: scheduled for recovery
> >  nouveau :01:00.0: firefox[476]: channel 5 killed!
> >  nouveau :01:00.0: firefox[476]: failed to idle channel 5 [firefox[476]]
> >
> > It lockups several times a day. Twice in just one hour today.
> > Can we fix this?
>
> Unusable

Are you using a GTX 660 by any chance? You've provided rather minimal
system info.

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

[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn

[bugzilla-daemon]

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

--- Comment #94 from Diego Viola  ---
This bug is still present with mesa 19.1.0-1.

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

Re: [PATCH v5 10/15] drm/bridge: tc358767: Add support for address-only I2C transfers

[Andrey Smirnov]

On Wed, Jun 12, 2019 at 9:22 AM Andrey Smirnov  wrote:
>
> On Wed, Jun 12, 2019 at 5:48 AM Tomi Valkeinen  wrote:
> >
> > Hi,
> >
> > On 12/06/2019 11:32, Andrey Smirnov wrote:
> > > Transfer size of zero means a request to do an address-only
> > > transfer. Since the HW support this, we probably shouldn't be just
> > > ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
> > > through, since it is supported by the HW as well.
> >
> > I bisected the EDID read issue to this patch...
> >
>
> I don't think I've had any problems on my end with this. I'll double
> check. It might be the case that yours is the only setup where the
> problem can be repro'd, though. We can drop this patch if you don't
> have time/would rather not dig into this.
>

Turns out I do have this problem. Just didn't pay enough attention to
notice. Will fix in v6.

Thanks,
Andrey Smirnov

linux-next: manual merge of the drm tree with the kbuild tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/Makefile.header-test

between commit:

  e846f0dc57f4 ("kbuild: add support for ensuring headers are self-contained")

from the kbuild tree and commits:

  112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
  d91e657876a9 ("drm/i915: Introduce struct intel_wakeref")
  aab30b85c97a ("drm/i915: ensure more headers remain self-contained")
  b375d0ef2589 ("drm/i915: extract intel_vdsc.h from intel_drv.h and 
i915_drv.h")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/Makefile.header-test
index 639b596a06a9,3a9663002d4a..
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@@ -2,18 -2,28 +2,28 @@@
  # Copyright © 2019 Intel Corporation
  
  # Test the headers are compilable as standalone units
 -header_test := \
 +header-test-$(CONFIG_DRM_I915_WERROR) := \
i915_active_types.h \
+   i915_debugfs.h \
+   i915_drv.h \
i915_gem_context_types.h \
+   i915_gem_pm.h \
+   i915_irq.h \
+   i915_params.h \
i915_priolist_types.h \
+   i915_reg.h \
i915_scheduler_types.h \
i915_timeline_types.h \
+   i915_utils.h \
+   intel_acpi.h \
+   intel_atomic.h \
intel_atomic_plane.h \
intel_audio.h \
+   intel_bios.h \
intel_cdclk.h \
intel_color.h \
+   intel_combo_phy.h \
intel_connector.h \
-   intel_context_types.h \
intel_crt.h \
intel_csr.h \
intel_ddi.h \
@@@ -31,7 -54,22 +54,12 @@@
intel_pipe_crc.h \
intel_pm.h \
intel_psr.h \
+   intel_quirks.h \
+   intel_runtime_pm.h \
intel_sdvo.h \
+   intel_sideband.h \
intel_sprite.h \
intel_tv.h \
-   intel_workarounds_types.h
+   intel_uncore.h \
+   intel_vdsc.h \
+   intel_wakeref.h
 -
 -quiet_cmd_header_test = HDRTEST $@
 -  cmd_header_test = echo "\#include \"$( $@
 -
 -header_test_%.c: %.h
 -  $(call cmd,header_test)
 -
 -i915-$(CONFIG_DRM_I915_WERROR) += $(foreach h,$(header_test),$(patsubst 
%.h,header_test_%.o,$(h)))
 -
 -clean-files += $(foreach h,$(header_test),$(patsubst 
%.h,header_test_%.c,$(h)))


pgpNBKzPNtkS5.pgp
Description: OpenPGP digital signature

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

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

--- Comment #71 from Richard Thier  ---
Made a similar writeup on this topic too:

http://ballmerpeak.web.elte.hu/devblog/debugging-hyperz-and-fixing-a-radeon-drm-linux-kernel-module.html

Also tried to document all relevant information if it ever helps anyone.

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

[PATCH v2 3/6] firmware: qcom: scm: add OCMEM lock/unlock interface

[Brian Masney]

From: Rob Clark 

Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.

Signed-off-by: Rob Clark 
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney 
Reviewed-by: Bjorn Andersson 
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340711/

Changes since v1:
- None

 drivers/firmware/qcom_scm-32.c | 35 +
 drivers/firmware/qcom_scm-64.c | 12 ++
 drivers/firmware/qcom_scm.c| 40 ++
 drivers/firmware/qcom_scm.h|  9 
 include/linux/qcom_scm.h   | 15 +
 5 files changed, 111 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..4c2514e5e249 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -442,6 +442,41 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }
 
+int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
+ u32 mode)
+{
+   struct ocmem_tz_lock {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+   __le32 mode;
+   } request;
+
+   request.id = cpu_to_le32(id);
+   request.offset = cpu_to_le32(offset);
+   request.size = cpu_to_le32(size);
+   request.mode = cpu_to_le32(mode);
+
+   return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
+{
+   struct ocmem_tz_unlock {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+   } request;
+
+   request.id = cpu_to_le32(id);
+   request.offset = cpu_to_le32(offset);
+   request.size = cpu_to_le32(size);
+
+   return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+, sizeof(request), NULL, 0);
+}
+
 void __qcom_scm_init(void)
 {
 }
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 91d5ad7cf58b..c3a3d9874def 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -241,6 +241,18 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
return ret;
 }
 
+int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size, uint32_t mode)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
+   uint32_t size)
+{
+   return -ENOTSUPP;
+}
+
 void __qcom_scm_init(void)
 {
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..2e12ea56c34c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -190,6 +190,46 @@ bool qcom_scm_pas_supported(u32 peripheral)
 }
 EXPORT_SYMBOL(qcom_scm_pas_supported);
 
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+   return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
+   QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size:   OCMEM size
+ * @mode:   access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
+   u32 mode)
+{
+   return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size:   OCMEM size
+ */
+int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
+{
+   return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
 /**
  * qcom_scm_pas_init_image() - Initialize peripheral authentication service
  *state machine for a given peripheral, using the
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..ef293ee67ec1 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -42,6 +42,15 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
 
 extern void __qcom_scm_init(void);
 
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define QCOM_SCM_OCMEM_LOCK_CMD0x1
+#define 

[PATCH v2 0/6] qcom: add OCMEM support

[Brian Masney]

This patch series adds support for Qualcomm's On Chip MEMory (OCMEM)
that is needed in order to support some A3xx and A4xx based GPUs
upstream. This is based on Rob Clark's patch series that he submitted
in October 2015 and I am resubmitting updated patches with his
permission. See the individual patches for the changelog.

This was tested with the GPU on a LG Nexus 5 (hammerhead) phone and
this will work on other msm8974-based systems. For a summary of what
currently works upstream on the Nexus 5, see my status page at
https://masneyb.github.io/nexus-5-upstream/.

Brian Masney (4):
  dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
  dt-bindings: display: msm: gmu: add optional ocmem property
  soc: qcom: add OCMEM driver
  drm/msm/gpu: add ocmem init/cleanup functions

Rob Clark (2):
  firmware: qcom: scm: add OCMEM lock/unlock interface
  firmware: qcom: scm: add support to restore secure config to
qcm_scm-32

 .../devicetree/bindings/display/msm/gmu.txt   |   4 +
 .../bindings/sram/qcom/qcom,ocmem.yaml|  64 +++
 drivers/firmware/qcom_scm-32.c|  52 ++-
 drivers/firmware/qcom_scm-64.c|  12 +
 drivers/firmware/qcom_scm.c   |  53 +++
 drivers/firmware/qcom_scm.h   |   9 +
 drivers/gpu/drm/msm/Kconfig   |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  33 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h |   3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  30 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  36 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  10 +
 drivers/soc/qcom/Kconfig  |  10 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/ocmem.c  | 433 ++
 include/linux/qcom_scm.h  |  26 ++
 include/soc/qcom/ocmem.h  |  62 +++
 18 files changed, 795 insertions(+), 47 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
 create mode 100644 drivers/soc/qcom/ocmem.c
 create mode 100644 include/soc/qcom/ocmem.h

-- 
2.20.1

[PATCH v2 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings

[Brian Masney]

Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.

Signed-off-by: Brian Masney 
---
Changes since v1:
- Rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- Renamed reg-names to ctrl and mem
- update hardware description
- moved from soc to sram namespace in the device tree bindings

 .../bindings/sram/qcom/qcom,ocmem.yaml| 64 +++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml

diff --git a/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml 
b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
new file mode 100644
index ..1bd15824968e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sram/qcom/qcom,ocmem.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sram/qcom/qcom,ocmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon SoCs.
+
+maintainers:
+  - Brian Masney 
+
+description: |
+  The On Chip Memory (OCMEM) is typically used by the GPU, camera/video, and
+  audio components on some Snapdragon SoCs.
+
+properties:
+  compatible:
+const: qcom,msm8974-ocmem
+
+  reg:
+items:
+  - description: Control registers
+  - description: OCMEM address range
+
+  reg-names:
+items:
+  - const: ctrl
+  - const: mem
+
+  clocks:
+items:
+  - description: Core clock
+  - description: Interface clock
+
+  clock-names:
+items:
+  - const: core
+  - const: iface
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+examples:
+  - |
+  #include 
+  #include 
+
+  ocmem: ocmem@fdd0 {
+compatible = "qcom,msm8974-ocmem";
+
+reg = <0xfdd0 0x2000>,
+  <0xfec0 0x18>;
+reg-names = "ctrl",
+"mem";
+
+clocks = < RPM_SMD_OCMEMGX_CLK>,
+ < OCMEMCX_OCMEMNOC_CLK>;
+clock-names = "core",
+  "iface";
+  };
-- 
2.20.1

[PATCH v2 4/6] firmware: qcom: scm: add support to restore secure config to qcm_scm-32

[Brian Masney]

From: Rob Clark 

Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.

Signed-off-by: Rob Clark 
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
 spare parameter.]
Signed-off-by: Brian Masney 
---
Changes since v1:
- Use existing __qcom_scm_restore_sec_cfg() function stub in
  qcom_scm-32.c that was unimplemented
- Set the cfg.ctx_bank_num to the spare function parameter. It was
  previously set to the device_id.

 drivers/firmware/qcom_scm-32.c | 17 -
 drivers/firmware/qcom_scm.c| 13 +
 include/linux/qcom_scm.h   | 11 +++
 3 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 4c2514e5e249..5d90b7f5ab5a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -617,7 +617,22 @@ int __qcom_scm_assign_mem(struct device *dev, phys_addr_t 
mem_region,
 int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
   u32 spare)
 {
-   return -ENODEV;
+   struct msm_scm_sec_cfg {
+   __le32 id;
+   __le32 ctx_bank_num;
+   } cfg;
+   int ret, scm_ret = 0;
+
+   cfg.id = cpu_to_le32(device_id);
+   cfg.ctx_bank_num = cpu_to_le32(spare);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP, QCOM_SCM_RESTORE_SEC_CFG,
+   , sizeof(cfg), _ret, sizeof(scm_ret));
+
+   if (ret || scm_ret)
+   return ret ? ret : -EINVAL;
+
+   return 0;
 }
 
 int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2e12ea56c34c..54532331ddc1 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -366,6 +366,19 @@ static const struct reset_control_ops 
qcom_scm_pas_reset_ops = {
.deassert = qcom_scm_pas_reset_deassert,
 };
 
+/**
+ * qcom_scm_restore_sec_cfg_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_cfg_available(void)
+{
+   return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
+   QCOM_SCM_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_cfg_available);
+
 int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare)
 {
return __qcom_scm_restore_sec_cfg(__scm->dev, device_id, spare);
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 521b089be1c9..8a24f7eb2588 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -34,6 +34,16 @@ enum qcom_scm_ocmem_client {
QCOM_SCM_OCMEM_DEBUG_ID,
 };
 
+enum qcom_scm_sec_dev_id {
+   QCOM_SCM_MDSS_DEV_ID= 1,
+   QCOM_SCM_OCMEM_DEV_ID   = 5,
+   QCOM_SCM_PCIE0_DEV_ID   = 11,
+   QCOM_SCM_PCIE1_DEV_ID   = 12,
+   QCOM_SCM_GFX_DEV_ID = 18,
+   QCOM_SCM_UFS_DEV_ID = 19,
+   QCOM_SCM_ICE_DEV_ID = 20,
+};
+
 #define QCOM_SCM_VMID_HLOS   0x3
 #define QCOM_SCM_VMID_MSS_MSA0xF
 #define QCOM_SCM_VMID_WLAN   0x18
@@ -69,6 +79,7 @@ extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t 
mem_sz,
 extern void qcom_scm_cpu_power_down(u32 flags);
 extern u32 qcom_scm_get_version(void);
 extern int qcom_scm_set_remote_state(u32 state, u32 id);
+extern bool qcom_scm_restore_sec_cfg_available(void);
 extern int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare);
 extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);
 extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
-- 
2.20.1

[PATCH v2 2/6] dt-bindings: display: msm: gmu: add optional ocmem property

[Brian Masney]

Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.

Signed-off-by: Brian Masney 
---
Changes since v1:
- None

 Documentation/devicetree/bindings/display/msm/gmu.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 90af5b0a56a9..c746b95e95d4 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -31,6 +31,10 @@ Required properties:
 - iommus: phandle to the adreno iommu
 - operating-points-v2: phandle to the OPP operating points
 
+Optional properties:
+- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some 
Snapdragon
+ SoCs. See Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
+
 Example:
 
 / {
-- 
2.20.1

[PATCH v2 5/6] soc: qcom: add OCMEM driver

[Brian Masney]

The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs.

Devices which have OCMEM do not have GMEM inside the GPU core, so the
GPU must instead use OCMEM to be functional. Since currently the GPU
is the only OCMEM user with an upstream driver, this is just a minimal
implementation sufficient for statically allocating to the GPU it's
chunk of OCMEM.

Signed-off-by: Brian Masney 
Co-developed-by: Rob Clark 
Signed-off-by: Rob Clark 
---
Pay attention to qcom_scm_restore_sec_cfg() in the probe function,
specifically the 0 as the third paramter. I'm honestly not sure what
to put here. In the previous version, this function would set the id
and ctx_bank_num to the device_id. The GPU works either way. I couldn't
find this in the downstream MSM kernel sources.

Changes since v1:
- ocmem_allocate(): check for alignment and minimum allocation size.
  The 64K values came from the downstream MSM kernel sources.
- add locking to memory allocations based on the client
- use clk_bulk_*() functions
- rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- rename reg-names to ctrl and mem
- remove ocmem.xml.h file; use FIELD_PREP() instead for some nice cleanups
- add static inline noop versions of public-facing functions when ocmem
  is disabled to remove #ifdefs in adrenu_gpu.c
- use unsigned long for memory addresses
- move ocmem_dev_remove() below _probe() function
- remove error check from platform_get_resource_byname for ctrl resource
- add MODULE_DESCRIPTION() and MODULE_LICENSE()
- add description to top of ocmem.[ch]
- correct thin mode bit in update_ocmem()
- add 'WARN_ON(client != OCMEM_GRAPHICS)' to device_address()
- make of_get_ocmem return error codes via ERR_PTR instead of NULL
- ocmem_{allocate,free} - WARN_ON() if client != OCMEM_GRAPHICS.
  Simplify if statements.
- allow NULL to be passed into ocmem_free
- remove unnecessary initialization of i in update_ocmem()
- add dev_dbg to ocmem_allocate

Changes since Rob's last version of this patch from 2015:
https://patchwork.kernel.org/patch/7379801/
- reformatted driver to allow multiple instances
- updated logging of error paths during device probing
- remove unused psgsc_ctrl
- remove _clk from clock names
- propagate error code from devm_ioremap_resource()
- use device_get_match_data()
- SPDX license tags
- remove QCOM_SMD in Kconfig
- select ARCH_QCOM in Kconfig
- select ARCH_QCOM in Kconfig
- select QCOM_SCM in Kconfig
- longer description in Kconfig

 drivers/soc/qcom/Kconfig  |  10 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/ocmem.c  | 433 ++
 include/soc/qcom/ocmem.h  |  62 ++
 4 files changed, 506 insertions(+)
 create mode 100644 drivers/soc/qcom/ocmem.c
 create mode 100644 include/soc/qcom/ocmem.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a6d1bfb17279..d18eb83b10da 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,16 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
 
+config QCOM_OCMEM
+   tristate "Qualcomm On Chip Memory (OCMEM) driver"
+   depends on ARCH_QCOM
+   select QCOM_SCM
+   help
+  The On Chip Memory (OCMEM) allocator allows various clients to
+  allocate memory from OCMEM based on performance, latency and power
+  requirements. This is typically used by the GPU, camera/video, and
+  audio components on some Snapdragon SoCs.
+
 config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index eeb088beb15f..dfc378014a33 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
 obj-$(CONFIG_QCOM_GSBI)+=  qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += mdt_loader.o
+obj-$(CONFIG_QCOM_OCMEM)   += ocmem.o
 obj-$(CONFIG_QCOM_PM)  +=  spm.o
 obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
 qmi_helpers-y  += qmi_encdec.o qmi_interface.o
diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
new file mode 100644
index ..91256e160b9b
--- /dev/null
+++ b/drivers/soc/qcom/ocmem.c
@@ -0,0 +1,433 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * The On Chip Memory (OCMEM) allocator allows various clients to allocate
+ * memory from OCMEM based on performance, latency and power requirements.
+ * This is typically used by the GPU, camera/video, and audio components on
+ * some Snapdragon SoCs.
+ *
+ * Copyright (C) 2019 Brian Masney 
+ * Copyright (C) 2015 Red Hat. Author: Rob Clark 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum region_mode {
+   WIDE_MODE = 0x0,
+   THIN_MODE,
+   MODE_DEFAULT = WIDE_MODE,
+};
+
+enum ocmem_macro_state {
+

[PATCH v2 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Brian Masney]

The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
now that OCMEM support is upstream.

Signed-off-by: Brian Masney 
---
Changes since v1:
- remove CONFIG_QCOM_OCMEM #ifdefs
- use unsigned long for memory addresses instead of uint32_t
- add 'depends on QCOM_OCMEM || QCOM_OCMEM=n' to Kconfig

 drivers/gpu/drm/msm/Kconfig |  1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 33 ---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  3 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 30 +++--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h   |  3 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +++
 7 files changed, 70 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 9c37e4de5896..b3d3b2172659 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -7,6 +7,7 @@ config DRM_MSM
depends on OF && COMMON_CLK
depends on MMU
depends on INTERCONNECT || !INTERCONNECT
+   depends on QCOM_OCMEM || QCOM_OCMEM=n
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..72720bb2aca1 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,6 @@
  * this program.  If not, see .
  */
 
-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif
-
 #include "a3xx_gpu.h"
 
 #define A3XX_INT0_MASK \
@@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
 
/* Set the OCMEM base address for A330, etc */
-   if (a3xx_gpu->ocmem_hdl) {
+   if (a3xx_gpu->ocmem.hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
-   (unsigned int)(a3xx_gpu->ocmem_base >> 14));
+   (unsigned int)(a3xx_gpu->ocmem.base >> 14));
}
 
/* Turn on performance counters: */
@@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
 
adreno_gpu_cleanup(adreno_gpu);
 
-#ifdef CONFIG_MSM_OCMEM
-   if (a3xx_gpu->ocmem_base)
-   ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif
+   adreno_gpu_ocmem_cleanup(_gpu->ocmem);
 
kfree(a3xx_gpu);
 }
@@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
 
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
-   /* TODO this is different/missing upstream: */
-   struct ocmem_buf *ocmem_hdl =
-   ocmem_allocate(OCMEM_GRAPHICS, 
adreno_gpu->gmem);
-
-   a3xx_gpu->ocmem_hdl = ocmem_hdl;
-   a3xx_gpu->ocmem_base = ocmem_hdl->addr;
-   adreno_gpu->gmem = ocmem_hdl->len;
-   DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
-   a3xx_gpu->ocmem_base);
-#endif
+   ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
+   adreno_gpu, _gpu->ocmem);
+   if (ret)
+   goto fail;
}
 
if (!gpu->aspace) {
@@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
 */
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
ret = -ENXIO;
-   goto fail;
+   goto fail_cleanup_ocmem;
}
 
return gpu;
 
+fail_cleanup_ocmem:
+   adreno_gpu_ocmem_cleanup(_gpu->ocmem);
+
 fail:
if (a3xx_gpu)
a3xx_destroy(_gpu->base.base);
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index ab60dc9e344e..727c34f38f9e 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -30,8 +30,7 @@ struct a3xx_gpu {
struct adreno_gpu base;
 
/* if OCMEM is used for GMEM: */
-   uint32_t ocmem_base;
-   void *ocmem_hdl;
+   struct adreno_ocmem ocmem;
 };
 #define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index ab2b752566d8..b8f825107796 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -2,9 +2,6 @@
 /* Copyright (c) 2014 The Linux Foundation. All rights reserved.
  */
 #include "a4xx_gpu.h"
-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif
 
 #define A4XX_INT0_MASK \
(A4XX_INT0_RBBM_AHB_ERROR |  

Re: [PATCH 07/10] drm/vkms: Dont flush crc worker when we change crc status

[Rodrigo Siqueira]

On 06/07, Daniel Vetter wrote:
> The crc core code can cope with some late crc, the race is kinda
> unavoidable. So no need to flush pending workers, they'll complete in
> time.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_crc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 96806cd35ad4..9d15e5e85830 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -249,9 +249,6 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
> *src_name)
>  
>   ret = vkms_crc_parse_source(src_name, );
>  
> - /* make sure nothing is scheduled on crtc workq */
> - flush_workqueue(out->crc_workq);
> -
>   spin_lock_irq(>lock);
>   out->crc_enabled = enabled;
>   spin_unlock_irq(>lock);
> -- 
> 2.20.1
> 
Hi,

I tried to apply this patch, but git complained about it. I fixed the
problem manually (it was very simple), but I noticed that dim did not
add the tag "Link". Because of this, I decided to check with you before
I apply this patch. Is it ok to fix conflict without dim? Is it ok apply
a patch without the tag Link?

-- 
Rodrigo Siqueira
https://siqueira.tech


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

Re: [PATCH 04/10] drm/vkms: Move format arrays to vkms_plane.c

[Rodrigo Siqueira]

On 06/07, Daniel Vetter wrote:
> No need to have them multiple times.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.h   | 8 
>  drivers/gpu/drm/vkms/vkms_plane.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 43d3f98289fe..2a35299bfb89 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -20,14 +20,6 @@
>  
>  extern bool enable_cursor;
>  
> -static const u32 vkms_formats[] = {
> - DRM_FORMAT_XRGB,
> -};
> -
> -static const u32 vkms_cursor_formats[] = {
> - DRM_FORMAT_ARGB,
> -};
> -
>  struct vkms_crc_data {
>   struct drm_framebuffer fb;
>   struct drm_rect src, dst;
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 0e67d2d42f0c..0fceb6258422 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -6,6 +6,14 @@
>  #include 
>  #include 
>  
> +static const u32 vkms_formats[] = {
> + DRM_FORMAT_XRGB,
> +};
> +
> +static const u32 vkms_cursor_formats[] = {
> + DRM_FORMAT_ARGB,
> +};
> +
>  static struct drm_plane_state *
>  vkms_plane_duplicate_state(struct drm_plane *plane)
>  {
> -- 
> 2.20.1
> 

Applied to the drm-misc-next branch.

Thanks.

-- 
Rodrigo Siqueira
https://siqueira.tech


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

Re: [PATCH 3/3] drm/vkms: add crc sources list

[Rodrigo Siqueira]

On 06/13, Oleg Vasilev wrote:
> Other drivers are able to list crc sources when accessing
> /sys/kernel/debug/dri/.../crtc-0/crc/control
> 
> Even though VKMS now supports only 'auto' mode, it is more consistent to
> have the list available to the userspace.
> 
> Signed-off-by: Oleg Vasilev 
> ---
>  drivers/gpu/drm/vkms/vkms_crc.c  | 9 +
>  drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
>  drivers/gpu/drm/vkms/vkms_drv.h  | 2 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index bc717ab5..819313ef80b6 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -220,6 +220,15 @@ void vkms_crc_work_handle(struct work_struct *work)
>   spin_unlock_irqrestore(>state_lock, flags);
>  }
>  
> +static const char * const pipe_crc_sources[] = {"auto"};
> +
> +const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
> + size_t *count)
> +{
> + *count = ARRAY_SIZE(pipe_crc_sources);
> + return pipe_crc_sources;
> +}
> +
>  static int vkms_crc_parse_source(const char *src_name, bool *enabled)
>  {
>   int ret = 0;
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 1bbe099b7db8..4d11292bc6f3 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -147,6 +147,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>   .atomic_destroy_state   = vkms_atomic_crtc_destroy_state,
>   .enable_vblank  = vkms_enable_vblank,
>   .disable_vblank = vkms_disable_vblank,
> + .get_crc_sources= vkms_get_crc_sources,
>   .set_crc_source = vkms_set_crc_source,
>   .verify_crc_source  = vkms_verify_crc_source,
>  };
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 81f1cfbeb936..891f2d63d74f 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -136,6 +136,8 @@ int vkms_gem_vmap(struct drm_gem_object *obj);
>  void vkms_gem_vunmap(struct drm_gem_object *obj);
>  
>  /* CRC Support */
> +const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
> + size_t *count);
>  int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name);
>  int vkms_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
>  size_t *values_cnt);
> -- 
> 2.21.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Applied to drm-misc-next.

Thanks

-- 
Rodrigo Siqueira
https://siqueira.tech


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

[PATCH V4] drm/drm_vblank: Change EINVAL by the correct errno

[Rodrigo Siqueira]

For historical reason, the function drm_wait_vblank_ioctl always return
-EINVAL if something gets wrong. This scenario limits the flexibility
for the userspace make detailed verification of the problem and take
some action. In particular, the validation of “if (!dev->irq_enabled)”
in the drm_wait_vblank_ioctl is responsible for checking if the driver
support vblank or not. If the driver does not support VBlank, the
function drm_wait_vblank_ioctl returns EINVAL which does not represent
the real issue; this patch changes this behavior by return EOPNOTSUPP.
Additionally, some operations are unsupported by this function, and
returns EINVAL; this patch also changes the return value to EOPNOTSUPP
in this case. Lastly, the function drm_wait_vblank_ioctl is invoked by
libdrm, which is used by many compositors; because of this, it is
important to check if this change breaks any compositor. In this sense,
the following projects were examined:

* Drm-hwcomposer
* Kwin
* Sway
* Wlroots
* Wayland-core
* Weston
* Xorg (67 different drivers)

For each repository the verification happened in three steps:

* Update the main branch
* Look for any occurrence "drmWaitVBlank" with the command:
  git grep -n "drmWaitVBlank"
* Look in the git history of the project with the command:
  git log -SdrmWaitVBlank

Finally, none of the above projects validate the use of EINVAL which
make safe, at least for these projects, to change the return values.

Change since V3:
 - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel)

Change since V2:
 Daniel Vetter and Chris Wilson
 - Replace ENOTTY by EOPNOTSUPP
 - Return EINVAL if the parameters are wrong

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/drm_vblank.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 603ab105125d..bed233361614 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1582,7 +1582,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void 
*data,
unsigned int flags, pipe, high_pipe;
 
if (!dev->irq_enabled)
-   return -EINVAL;
+   return -EOPNOTSUPP;
 
if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
return -EINVAL;
-- 
2.21.0

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

[Kuehling, Felix]

On 2019-06-18 1:37, Christoph Hellwig wrote:
> On Mon, Jun 17, 2019 at 09:45:09PM -0300, Jason Gunthorpe wrote:
>> Am I looking at the wrong thing? Looks like it calls it through a work
>> queue should should be OK..
> Yes, it calls it through a work queue.  I guess that is fine because
> it needs to take the lock again.
>
>> Though very strange that amdgpu only destroys the mirror via release,
>> that cannot be right.
> As said the whole things looks rather odd to me.

This code is derived from our old MMU notifier code. Before HMM we used 
to register a single MMU notifier per mm_struct and look up virtual 
address ranges that had been registered for mirroring via driver API 
calls. The idea was to reuse a single MMU notifier for the life time of 
the process. It would remain registered until we got a notifier_release.

hmm_mirror took the place of that when we converted the code to HMM.

I suppose we could destroy the mirror earlier, when we have no more 
registered virtual address ranges, and create a new one if needed later.

Regards,
   Felix


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

Re: [PATCH 00/10] drm/vkms: rework crc worker

[Daniel Vetter]

On Wed, Jun 19, 2019 at 12:25 AM Rodrigo Siqueira
 wrote:
>
> On Tue, Jun 18, 2019 at 7:08 PM Daniel Vetter  wrote:
> >
> > On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter  wrote:
> > >
> > > On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> > >  wrote:
> > > > Finally, not related with this patchset, can I apply the patch
> > > > “drm/drm_vblank: Change EINVAL by the correct errno” [1] or do I need
> > > > more SoB? I’ll also apply Oleg patch (drm/vkms: add crc sources list).
> > > >
> > > > 1. https://patchwork.freedesktop.org/patch/310006/?series=50697=4
> > >
> > > If you want get some acks from igt maintainers (those patches landed
> > > now, right), but this is good enough.
> >
> > Oh wait correction: My review is conditional on you changing that one
> > thing. So needs another version. Since this is a functional change imo
> > too much to fix up while applying.
>
> In your comment you said:
>
>   >   if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
>   > - return -EINVAL;
>   > + return -EOPNOTSUPP;
>
>   Not sure we want EINVAL here, that's kinda a "parameters are wrong"
>   version too. With that changed:
>
> I think I did not got your point here, sorry for that... so, do you
> want that I change EOPNOTSUPP by EINVAL in the above code?

Oops, that was wrong. I meant to say that I don't see why we should
use EOPNOTSUPP here, the EINVAL indicating a wrong argument seems more
fitting to me. It's been pretty much forever (if we every supported
this) that vblank signal worked on linux. Ok, did a quick check, it
died in 2009. That's before the kms stuff landed, there's definitely
no userspace around anymore that ever expected this to work :-) Hence
why I think EINVAL is more fitting ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_edid-load: Fix a missing-check bug in drivers/gpu/drm/drm_edid_load.c

[Tyler Hicks]

On 2019-05-22 17:55:35, Jani Nikula wrote:
> On Wed, 22 May 2019, Gen Zhang  wrote:
> > In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
> > is dereferenced in the following codes. However, memory allocation 
> > functions such as kstrdup() may fail and returns NULL. Dereferencing 
> > this null pointer may cause the kernel go wrong. Thus we should check 
> > this kstrdup() operation.
> > Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to
> > the caller site.
> 
> strsep() handles the NULL pointer just fine, so there won't be a NULL
> dereference. However this patch seems like the right thing to do anyway.

I came across this thread while triaging CVE-2019-12382. I agree that
the code before was fine but more complex than necessary. There's no
real security impact here since a NULL pointer dereference was not
possible. I've requested that MITRE reject CVE-2019-12382.

This change is a nice improvement, though.

Tyler

> 
> Reviewed-by: Jani Nikula 
> 
> >
> > Signed-off-by: Gen Zhang 
> >
> > ---
> > diff --git a/drivers/gpu/drm/drm_edid_load.c 
> > b/drivers/gpu/drm/drm_edid_load.c
> > index a491509..a0e107a 100644
> > --- a/drivers/gpu/drm/drm_edid_load.c
> > +++ b/drivers/gpu/drm/drm_edid_load.c
> > @@ -290,6 +290,8 @@ struct edid *drm_load_edid_firmware(struct 
> > drm_connector *connector)
> >  * the last one found one as a fallback.
> >  */
> > fwstr = kstrdup(edid_firmware, GFP_KERNEL);
> > +   if (!fwstr)
> > +   return ERR_PTR(-ENOMEM);
> > edidstr = fwstr;
> >  
> > while ((edidname = strsep(, ","))) {
> > ---
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 00/10] drm/vkms: rework crc worker

[Rodrigo Siqueira]

On Tue, Jun 18, 2019 at 7:08 PM Daniel Vetter  wrote:
>
> On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter  wrote:
> >
> > On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> >  wrote:
> > >
> > > On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter  wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > > > > On 06/12, Daniel Vetter wrote:
> > > > > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote:
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > First of all, thank you very much for your patchset.
> > > > > > >
> > > > > > > I tried to make a detailed review of your series, and you can see 
> > > > > > > my
> > > > > > > comments in each patch. You’ll notice that I asked many things 
> > > > > > > related
> > > > > > > to the DRM subsystem with the hope that I could learn a little bit
> > > > > > > more about DRM from your comments.
> > > > > > >
> > > > > > > Before you go through the review, I would like to start a 
> > > > > > > discussion
> > > > > > > about the vkms race conditions. First, I have to admit that I did 
> > > > > > > not
> > > > > > > understand the race conditions that you described before because I
> > > > > > > couldn’t reproduce them. Now, I'm suspecting that I could not
> > > > > > > experience the problem because I'm using QEMU with KVM; with this 
> > > > > > > idea
> > > > > > > in mind, I suppose that we have two scenarios for using vkms in a
> > > > > > > virtual machine:
> > > > > > >
> > > > > > > * Scenario 1: The user has hardware virtualization support; in 
> > > > > > > this
> > > > > > > case, it is a little bit harder to experience race conditions with
> > > > > > > vkms.
> > > > > > >
> > > > > > > * Scenario 2: Without hardware virtualization support, it is much
> > > > > > > easier to experience race conditions.
> > > > > > >
> > > > > > > With these two scenarios in mind, I conducted a bunch of 
> > > > > > > experiments
> > > > > > > for trying to shed light on this issue. I did:
> > > > > > >
> > > > > > > 1. Enabled lockdep
> > > > > > >
> > > > > > > 2. Defined two different environments for testing both using QEMU 
> > > > > > > with
> > > > > > > and without kvm. See below the QEMU hardware options:
> > > > > > >
> > > > > > > * env_kvm: -enable-kvm -daemonize -m 1G -smp cores=2,cpus=2
> > > > > > > * env_no_kvm: -daemonize -m 2G -smp cores=4,cpus=4
> > > > > > >
> > > > > > > 3. My test protocol: I) turn on the vm, II) clean /proc/lock_stat,
> > > > > > > III) execute kms_cursor_crc, III) save the lock_stat file, and IV)
> > > > > > > turn off the vm.
> > > > > > >
> > > > > > > 4. From the lockdep_stat, I just highlighted the row related to 
> > > > > > > vkms
> > > > > > > and the columns holdtime-total and holdtime-avg
> > > > > > >
> > > > > > > I would like to highlight that the following data does not have 
> > > > > > > any
> > > > > > > statistical approach, and its intention is solely to assist our
> > > > > > > discussion. See below the summary of the collected data:
> > > > > > >
> > > > > > > Summary of the experiment results:
> > > > > > >
> > > > > > > ++++
> > > > > > > || env_kvm|   env_no_kvm   |
> > > > > > > ++++
> > > > > > > | Test   | Before | After | Before | After |
> > > > > > > +++---++---+
> > > > > > > | kms_cursor_crc |   S1   |   S2  |   M1   |   M2  |
> > > > > > > +++---++---+
> > > > > > >
> > > > > > > * Before: before apply this patchset
> > > > > > > * After: after apply this patchset
> > > > > > >
> > > > > > > -+--+---
> > > > > > > S1: Without this patchset and with kvm   | holdtime-total | 
> > > > > > > holdtime-avg
> > > > > > > -++-
> > > > > > > &(_out->lock)->rlock:   |  21983.52  |  6.21
> > > > > > > (work_completion)(_state->crc_wo:   |  20.47 |  20.47
> > > > > > > (wq_completion)vkms_crc_workq:   |  3999507.87|  
> > > > > > > 3352.48
> > > > > > > &(_out->state_lock)->rlock: |  378.47|  0.30
> > > > > > > (work_completion)(_state->crc_#2:   |  3999066.30|  
> > > > > > > 2848.34
> > > > > > > -++-
> > > > > > > S2: With this patchset and with kvm  ||
> > > > > > > -++-
> > > > > > > &(_out->lock)->rlock:   |  23262.83  |  6.34
> > > > > > > (work_completion)(_state->crc_wo:   |  8.98  |  8.98
> > > > > > > &(_out->crc_lock)->rlock:   |  307.28|  0.32
> > > > > > > (wq_completion)vkms_crc_workq:   |  6567727.05|  
> > > > > > > 12345.35
> > > > > > > 

Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT

[Heiko Stübner]

Am Mittwoch, 19. Juni 2019, 00:09:57 CEST schrieb Ezequiel Garcia:
> On Tue, 2019-06-18 at 17:47 -0400, Ilia Mirkin wrote:
> > On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia  
> > wrote:
> > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > This is currently enabled via a separate address resource,
> > > which needs to be specified in the devicetree.
> > > 
> > > The address resource is required because on some SoCs, such as
> > > RK3288, the LUT address is after the MMU address, and the latter
> > > is supported by a different driver. This prevents the DRM driver
> > > from requesting an entire register space.
> > > 
> > > The current implementation works for RGB 10-bit tables, as that
> > > is what seems to work on RK3288.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > > Changes from RFC:
> > > * Request (an optional) address resource for the LUT.
> > > * Drop support for RK3399, which doesn't seem to work
> > >   out of the box and needs more research.
> > > * Support pass-thru setting when GAMMA_LUT is NULL.
> > > * Add a check for the gamma size, as suggested by Ilia.
> > > * Move gamma setting to atomic_commit_tail, as pointed
> > >   out by Jacopo/Laurent, is the correct way.
> > > ---
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > index 12ed5265a90b..5b6edbe2673f 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > > +  struct drm_crtc_state *old_state)
> > > +{
> > > +   int idle, ret, i;
> > > +
> > > +   spin_lock(>reg_lock);
> > > +   VOP_REG_SET(vop, common, dsp_lut_en, 0);
> > > +   vop_cfg_done(vop);
> > > +   spin_unlock(>reg_lock);
> > > +
> > > +   ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> > > +  idle, !idle, 5, 30 * 1000);
> > > +   if (ret)
> > > +   return;
> > > +
> > > +   spin_lock(>reg_lock);
> > > +
> > > +   if (crtc->state->gamma_lut) {
> > > +   if (!old_state->gamma_lut || 
> > > (crtc->state->gamma_lut->base.id !=
> > > + 
> > > old_state->gamma_lut->base.id))
> > > +   vop_crtc_write_gamma_lut(vop, crtc);
> > > +   } else {
> > > +   for (i = 0; i < crtc->gamma_size; i++) {
> > > +   u32 word;
> > > +
> > > +   word = (i << 20) | (i << 10) | i;
> > > +   writel(word, vop->lut_regs + i * 4);
> > > +   }
> > 
> > Note - I'm not in any way familiar with the hardware, so take with a
> > grain of salt --
> > 
> > Could you just leave dsp_lut_en turned off in this case?
> > 
> 
> That was the first thing I tried :-)
> 
> It seems dsp_lut_en is not to enable the CRTC gamma LUT stage,
> but to enable writing the gamma LUT to the internal RAM.

I guess that warants a code comment stating this, so we don't end
up with well-meant cleanup patches in the future :-) .


> 
> And the specs list no register to enable/disable the gamma LUT.
> 
> Thanks!
> Eze
> 
> 

Re: [PATCH V2 5/5] drm/vkms: Add support for writeback

[Rodrigo Siqueira]

On Tue, Jun 18, 2019 at 6:34 AM Daniel Vetter  wrote:
>
> On Mon, Jun 17, 2019 at 11:45:55PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change in V2:
> > - Rework signal completion (Brian)
> > - Integrates writeback with active_planes (Daniel)
> > - Compose cursor (Daniel)
>
> Not quite what I had in mind ... my idea was to reuse the crc worker
> (hence renaming all that stuff to vkms_composer). The problem here is that
> now we have the blend/compose code duplicated, at least parts of it. Plus
> if you enable both crc and writeback, then we compose 2x, which is a bit
> too much.
>
> Rough sketch of an implementation:
>
> - add writeback_pending, like we have crc_pending already. Difference is
>   that writeback is one-shot, i.e. set it in atomic_check somewhere, clear
>   it in the crc_worker (well, composer_worker now). vblank hrtimer will
>   not re-enable that one (unlike crc_pending).
>
> - in the crc worker, if writeback_pending is set, then compose everything
>   into the writeback buffer instead of into our private crc buffer. Except
>   that we use different memory, crc computation will be done exactly the
>   same. For subsequent frames with the same crtc_state we will again use
>   the normal crc buffer to compose & compute the crc.
>
> The benefit here is that we'll only have one place in vkms that does
> composing, so if we add lots more features in the future, it'll be much
> easier to maintain. Also since this guarantees that the crc will match
> exactly what we've written back, we can use the crc to help validate our
> writeback code.

Thanks for your review and comments, I think that I understood all of
them. I’ll prepare a V3.

> Cheers, Daniel
>
> >
> > Signed-off-by: Rodrigo Siqueira 
> > ---
> >  drivers/gpu/drm/vkms/Makefile |   3 +-
> >  drivers/gpu/drm/vkms/vkms_drv.c   |   7 ++
> >  drivers/gpu/drm/vkms/vkms_drv.h   |   6 +
> >  drivers/gpu/drm/vkms/vkms_output.c|   6 +
> >  drivers/gpu/drm/vkms/vkms_writeback.c | 166 ++
> >  5 files changed, 187 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> >
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index b4c040854bd6..091e6fa643d1 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -6,6 +6,7 @@ vkms-y := \
> >   vkms_crtc.o \
> >   vkms_gem.o \
> >   vkms_composer.o \
> > - vkms_crc.o
> > + vkms_crc.o \
> > + vkms_writeback.o
> >
> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 966b3d653189..d870779abf9d 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -30,6 +30,10 @@ bool enable_cursor;
> >  module_param_named(enable_cursor, enable_cursor, bool, 0444);
> >  MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
> >
> > +bool enable_writeback;
> > +module_param_named(enable_writeback, enable_writeback, bool, 0444);
> > +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
> > +
> >  static const struct file_operations vkms_driver_fops = {
> >   .owner  = THIS_MODULE,
> >   .open   = drm_open,
> > @@ -158,6 +162,9 @@ static int __init vkms_init(void)
> >   goto out_fini;
> >   }
> >
> > + if (enable_writeback)
> > + DRM_INFO("Writeback connector enabled");
> > +
> >   ret = vkms_modeset_init(vkms_device);
> >   if (ret)
> >   goto out_fini;
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h 
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index ad63dbe5e994..bf3fa737b3d7 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -7,6 +7,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #define XRES_MIN20
> > @@ -19,6 +20,7 @@
> >  #define YRES_MAX  8192
> >
> >  extern bool enable_cursor;
> > +extern bool enable_writeback;
> >
> >  struct vkms_data {
> >   struct drm_framebuffer fb;
> > @@ -63,6 +65,7 @@ struct vkms_output {
> >   struct drm_crtc crtc;
> >   struct drm_encoder encoder;
> >   struct drm_connector connector;
> > + struct drm_writeback_connector wb_connector;
> >   struct hrtimer vblank_hrtimer;
> >   ktime_t period_ns;
> >   struct drm_pending_vblank_event *event;
> > @@ -143,4 +146,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
> > char *source_name,
> >  size_t *values_cnt);
> >  void vkms_crc_work_handle(struct work_struct *work);
> >
> > +/* Writeback */
> > +int enable_writeback_connector(struct vkms_device *vkmsdev);
> > +
> >  #endif /* _VKMS_DRV_H_ */
> > diff 

[PATCH 5/5 v3] drm/msm/mdp5: Use the interconnect API

[Rob Clark]

From: Georgi Djakov 

The interconnect API provides an interface for consumer drivers to
express their bandwidth needs in the SoC. This data is aggregated
and the on-chip interconnect hardware is configured to the most
appropriate power/performance profile.

Use the API to configure the interconnects and request bandwidth
between DDR and the display hardware (MDP port(s) and rotator
downscaler).

v2: update the path names to be consistent with dpu, handle the NULL
path case, updated commit msg from Georgi.
v3: split out icc setup into it's own function, and rework logic
slightly so no interconnect paths is not fatal.

Signed-off-by: Georgi Djakov 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 38 
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..1c55401956c4 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 
 #include "msm_drv.h"
@@ -1048,9 +1049,46 @@ static const struct component_ops mdp5_ops = {
.unbind = mdp5_unbind,
 };
 
+static int mdp5_setup_interconnect(struct platform_device *pdev)
+{
+   struct icc_path *path0 = of_icc_get(>dev, "mdp0-mem");
+   struct icc_path *path1 = of_icc_get(>dev, "mdp1-mem");
+   struct icc_path *path_rot = of_icc_get(>dev, "rotator-mem");
+
+   if (IS_ERR(path0))
+   return PTR_ERR(path0);
+
+   if (!path0) {
+   /* no interconnect support is not necessarily a fatal
+* condition, the platform may simply not have an
+* interconnect driver yet.  But warn about it in case
+* bootloader didn't setup bus clocks high enough for
+* scanout.
+*/
+   dev_warn(>dev, "No interconnect support may cause display 
underflows!\n");
+   return 0;
+   }
+
+   icc_set_bw(path0, 0, MBps_to_icc(6400));
+
+   if (!IS_ERR_OR_NULL(path1))
+   icc_set_bw(path1, 0, MBps_to_icc(6400));
+   if (!IS_ERR_OR_NULL(path_rot))
+   icc_set_bw(path_rot, 0, MBps_to_icc(6400));
+
+   return 0;
+}
+
 static int mdp5_dev_probe(struct platform_device *pdev)
 {
+   int ret;
+
DBG("");
+
+   ret = mdp5_setup_interconnect(pdev);
+   if (ret)
+   return ret;
+
return component_add(>dev, _ops);
 }
 
-- 
2.20.1

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

Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT

[Ezequiel Garcia]

On Tue, 2019-06-18 at 17:47 -0400, Ilia Mirkin wrote:
> On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia  
> wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which needs to be specified in the devicetree.
> > 
> > The address resource is required because on some SoCs, such as
> > RK3288, the LUT address is after the MMU address, and the latter
> > is supported by a different driver. This prevents the DRM driver
> > from requesting an entire register space.
> > 
> > The current implementation works for RGB 10-bit tables, as that
> > is what seems to work on RK3288.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> > Changes from RFC:
> > * Request (an optional) address resource for the LUT.
> > * Drop support for RK3399, which doesn't seem to work
> >   out of the box and needs more research.
> > * Support pass-thru setting when GAMMA_LUT is NULL.
> > * Add a check for the gamma size, as suggested by Ilia.
> > * Move gamma setting to atomic_commit_tail, as pointed
> >   out by Jacopo/Laurent, is the correct way.
> > ---
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index 12ed5265a90b..5b6edbe2673f 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > +  struct drm_crtc_state *old_state)
> > +{
> > +   int idle, ret, i;
> > +
> > +   spin_lock(>reg_lock);
> > +   VOP_REG_SET(vop, common, dsp_lut_en, 0);
> > +   vop_cfg_done(vop);
> > +   spin_unlock(>reg_lock);
> > +
> > +   ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> > +  idle, !idle, 5, 30 * 1000);
> > +   if (ret)
> > +   return;
> > +
> > +   spin_lock(>reg_lock);
> > +
> > +   if (crtc->state->gamma_lut) {
> > +   if (!old_state->gamma_lut || 
> > (crtc->state->gamma_lut->base.id !=
> > + 
> > old_state->gamma_lut->base.id))
> > +   vop_crtc_write_gamma_lut(vop, crtc);
> > +   } else {
> > +   for (i = 0; i < crtc->gamma_size; i++) {
> > +   u32 word;
> > +
> > +   word = (i << 20) | (i << 10) | i;
> > +   writel(word, vop->lut_regs + i * 4);
> > +   }
> 
> Note - I'm not in any way familiar with the hardware, so take with a
> grain of salt --
> 
> Could you just leave dsp_lut_en turned off in this case?
> 

That was the first thing I tried :-)

It seems dsp_lut_en is not to enable the CRTC gamma LUT stage,
but to enable writing the gamma LUT to the internal RAM.

And the specs list no register to enable/disable the gamma LUT.

Thanks!
Eze

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

Re: [PATCH 00/10] drm/vkms: rework crc worker

[Daniel Vetter]

On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter  wrote:
>
> On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
>  wrote:
> >
> > On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter  wrote:
> > >
> > > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > > > On 06/12, Daniel Vetter wrote:
> > > > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote:
> > > > > > Hi Daniel,
> > > > > >
> > > > > > First of all, thank you very much for your patchset.
> > > > > >
> > > > > > I tried to make a detailed review of your series, and you can see my
> > > > > > comments in each patch. You’ll notice that I asked many things 
> > > > > > related
> > > > > > to the DRM subsystem with the hope that I could learn a little bit
> > > > > > more about DRM from your comments.
> > > > > >
> > > > > > Before you go through the review, I would like to start a discussion
> > > > > > about the vkms race conditions. First, I have to admit that I did 
> > > > > > not
> > > > > > understand the race conditions that you described before because I
> > > > > > couldn’t reproduce them. Now, I'm suspecting that I could not
> > > > > > experience the problem because I'm using QEMU with KVM; with this 
> > > > > > idea
> > > > > > in mind, I suppose that we have two scenarios for using vkms in a
> > > > > > virtual machine:
> > > > > >
> > > > > > * Scenario 1: The user has hardware virtualization support; in this
> > > > > > case, it is a little bit harder to experience race conditions with
> > > > > > vkms.
> > > > > >
> > > > > > * Scenario 2: Without hardware virtualization support, it is much
> > > > > > easier to experience race conditions.
> > > > > >
> > > > > > With these two scenarios in mind, I conducted a bunch of experiments
> > > > > > for trying to shed light on this issue. I did:
> > > > > >
> > > > > > 1. Enabled lockdep
> > > > > >
> > > > > > 2. Defined two different environments for testing both using QEMU 
> > > > > > with
> > > > > > and without kvm. See below the QEMU hardware options:
> > > > > >
> > > > > > * env_kvm: -enable-kvm -daemonize -m 1G -smp cores=2,cpus=2
> > > > > > * env_no_kvm: -daemonize -m 2G -smp cores=4,cpus=4
> > > > > >
> > > > > > 3. My test protocol: I) turn on the vm, II) clean /proc/lock_stat,
> > > > > > III) execute kms_cursor_crc, III) save the lock_stat file, and IV)
> > > > > > turn off the vm.
> > > > > >
> > > > > > 4. From the lockdep_stat, I just highlighted the row related to vkms
> > > > > > and the columns holdtime-total and holdtime-avg
> > > > > >
> > > > > > I would like to highlight that the following data does not have any
> > > > > > statistical approach, and its intention is solely to assist our
> > > > > > discussion. See below the summary of the collected data:
> > > > > >
> > > > > > Summary of the experiment results:
> > > > > >
> > > > > > ++++
> > > > > > || env_kvm|   env_no_kvm   |
> > > > > > ++++
> > > > > > | Test   | Before | After | Before | After |
> > > > > > +++---++---+
> > > > > > | kms_cursor_crc |   S1   |   S2  |   M1   |   M2  |
> > > > > > +++---++---+
> > > > > >
> > > > > > * Before: before apply this patchset
> > > > > > * After: after apply this patchset
> > > > > >
> > > > > > -+--+---
> > > > > > S1: Without this patchset and with kvm   | holdtime-total | 
> > > > > > holdtime-avg
> > > > > > -++-
> > > > > > &(_out->lock)->rlock:   |  21983.52  |  6.21
> > > > > > (work_completion)(_state->crc_wo:   |  20.47 |  20.47
> > > > > > (wq_completion)vkms_crc_workq:   |  3999507.87|  3352.48
> > > > > > &(_out->state_lock)->rlock: |  378.47|  0.30
> > > > > > (work_completion)(_state->crc_#2:   |  3999066.30|  2848.34
> > > > > > -++-
> > > > > > S2: With this patchset and with kvm  ||
> > > > > > -++-
> > > > > > &(_out->lock)->rlock:   |  23262.83  |  6.34
> > > > > > (work_completion)(_state->crc_wo:   |  8.98  |  8.98
> > > > > > &(_out->crc_lock)->rlock:   |  307.28|  0.32
> > > > > > (wq_completion)vkms_crc_workq:   |  6567727.05|  
> > > > > > 12345.35
> > > > > > (work_completion)(_state->crc_#2:   |  6567135.15|  4488.81
> > > > > > -++-
> > > > > > M1: Without this patchset and without kvm||
> > > > > > -++-
> > > > > > &(_out->state_lock)->rlock: |  4994.72   | 

Re: [PATCH 00/10] drm/vkms: rework crc worker

[Daniel Vetter]

On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
 wrote:
>
> On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter  wrote:
> >
> > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > > On 06/12, Daniel Vetter wrote:
> > > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote:
> > > > > Hi Daniel,
> > > > >
> > > > > First of all, thank you very much for your patchset.
> > > > >
> > > > > I tried to make a detailed review of your series, and you can see my
> > > > > comments in each patch. You’ll notice that I asked many things related
> > > > > to the DRM subsystem with the hope that I could learn a little bit
> > > > > more about DRM from your comments.
> > > > >
> > > > > Before you go through the review, I would like to start a discussion
> > > > > about the vkms race conditions. First, I have to admit that I did not
> > > > > understand the race conditions that you described before because I
> > > > > couldn’t reproduce them. Now, I'm suspecting that I could not
> > > > > experience the problem because I'm using QEMU with KVM; with this idea
> > > > > in mind, I suppose that we have two scenarios for using vkms in a
> > > > > virtual machine:
> > > > >
> > > > > * Scenario 1: The user has hardware virtualization support; in this
> > > > > case, it is a little bit harder to experience race conditions with
> > > > > vkms.
> > > > >
> > > > > * Scenario 2: Without hardware virtualization support, it is much
> > > > > easier to experience race conditions.
> > > > >
> > > > > With these two scenarios in mind, I conducted a bunch of experiments
> > > > > for trying to shed light on this issue. I did:
> > > > >
> > > > > 1. Enabled lockdep
> > > > >
> > > > > 2. Defined two different environments for testing both using QEMU with
> > > > > and without kvm. See below the QEMU hardware options:
> > > > >
> > > > > * env_kvm: -enable-kvm -daemonize -m 1G -smp cores=2,cpus=2
> > > > > * env_no_kvm: -daemonize -m 2G -smp cores=4,cpus=4
> > > > >
> > > > > 3. My test protocol: I) turn on the vm, II) clean /proc/lock_stat,
> > > > > III) execute kms_cursor_crc, III) save the lock_stat file, and IV)
> > > > > turn off the vm.
> > > > >
> > > > > 4. From the lockdep_stat, I just highlighted the row related to vkms
> > > > > and the columns holdtime-total and holdtime-avg
> > > > >
> > > > > I would like to highlight that the following data does not have any
> > > > > statistical approach, and its intention is solely to assist our
> > > > > discussion. See below the summary of the collected data:
> > > > >
> > > > > Summary of the experiment results:
> > > > >
> > > > > ++++
> > > > > || env_kvm|   env_no_kvm   |
> > > > > ++++
> > > > > | Test   | Before | After | Before | After |
> > > > > +++---++---+
> > > > > | kms_cursor_crc |   S1   |   S2  |   M1   |   M2  |
> > > > > +++---++---+
> > > > >
> > > > > * Before: before apply this patchset
> > > > > * After: after apply this patchset
> > > > >
> > > > > -+--+---
> > > > > S1: Without this patchset and with kvm   | holdtime-total | 
> > > > > holdtime-avg
> > > > > -++-
> > > > > &(_out->lock)->rlock:   |  21983.52  |  6.21
> > > > > (work_completion)(_state->crc_wo:   |  20.47 |  20.47
> > > > > (wq_completion)vkms_crc_workq:   |  3999507.87|  3352.48
> > > > > &(_out->state_lock)->rlock: |  378.47|  0.30
> > > > > (work_completion)(_state->crc_#2:   |  3999066.30|  2848.34
> > > > > -++-
> > > > > S2: With this patchset and with kvm  ||
> > > > > -++-
> > > > > &(_out->lock)->rlock:   |  23262.83  |  6.34
> > > > > (work_completion)(_state->crc_wo:   |  8.98  |  8.98
> > > > > &(_out->crc_lock)->rlock:   |  307.28|  0.32
> > > > > (wq_completion)vkms_crc_workq:   |  6567727.05|  12345.35
> > > > > (work_completion)(_state->crc_#2:   |  6567135.15|  4488.81
> > > > > -++-
> > > > > M1: Without this patchset and without kvm||
> > > > > -++-
> > > > > &(_out->state_lock)->rlock: |  4994.72   |  1.61
> > > > > &(_out->lock)->rlock:   |  247190.04 |  39.39
> > > > > (work_completion)(_state->crc_wo:   |  31.32 |  31.32
> > > > > (wq_completion)vkms_crc_workq:   |  20991073.78   |  13525.18
> > > > > (work_completion)(_state->crc_#2:   |  20988347.18   |  

Re: [PATCH 00/10] drm/vkms: rework crc worker

[Rodrigo Siqueira]

On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter  wrote:
>
> On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > On 06/12, Daniel Vetter wrote:
> > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote:
> > > > Hi Daniel,
> > > >
> > > > First of all, thank you very much for your patchset.
> > > >
> > > > I tried to make a detailed review of your series, and you can see my
> > > > comments in each patch. You’ll notice that I asked many things related
> > > > to the DRM subsystem with the hope that I could learn a little bit
> > > > more about DRM from your comments.
> > > >
> > > > Before you go through the review, I would like to start a discussion
> > > > about the vkms race conditions. First, I have to admit that I did not
> > > > understand the race conditions that you described before because I
> > > > couldn’t reproduce them. Now, I'm suspecting that I could not
> > > > experience the problem because I'm using QEMU with KVM; with this idea
> > > > in mind, I suppose that we have two scenarios for using vkms in a
> > > > virtual machine:
> > > >
> > > > * Scenario 1: The user has hardware virtualization support; in this
> > > > case, it is a little bit harder to experience race conditions with
> > > > vkms.
> > > >
> > > > * Scenario 2: Without hardware virtualization support, it is much
> > > > easier to experience race conditions.
> > > >
> > > > With these two scenarios in mind, I conducted a bunch of experiments
> > > > for trying to shed light on this issue. I did:
> > > >
> > > > 1. Enabled lockdep
> > > >
> > > > 2. Defined two different environments for testing both using QEMU with
> > > > and without kvm. See below the QEMU hardware options:
> > > >
> > > > * env_kvm: -enable-kvm -daemonize -m 1G -smp cores=2,cpus=2
> > > > * env_no_kvm: -daemonize -m 2G -smp cores=4,cpus=4
> > > >
> > > > 3. My test protocol: I) turn on the vm, II) clean /proc/lock_stat,
> > > > III) execute kms_cursor_crc, III) save the lock_stat file, and IV)
> > > > turn off the vm.
> > > >
> > > > 4. From the lockdep_stat, I just highlighted the row related to vkms
> > > > and the columns holdtime-total and holdtime-avg
> > > >
> > > > I would like to highlight that the following data does not have any
> > > > statistical approach, and its intention is solely to assist our
> > > > discussion. See below the summary of the collected data:
> > > >
> > > > Summary of the experiment results:
> > > >
> > > > ++++
> > > > || env_kvm|   env_no_kvm   |
> > > > ++++
> > > > | Test   | Before | After | Before | After |
> > > > +++---++---+
> > > > | kms_cursor_crc |   S1   |   S2  |   M1   |   M2  |
> > > > +++---++---+
> > > >
> > > > * Before: before apply this patchset
> > > > * After: after apply this patchset
> > > >
> > > > -+--+---
> > > > S1: Without this patchset and with kvm   | holdtime-total | holdtime-avg
> > > > -++-
> > > > &(_out->lock)->rlock:   |  21983.52  |  6.21
> > > > (work_completion)(_state->crc_wo:   |  20.47 |  20.47
> > > > (wq_completion)vkms_crc_workq:   |  3999507.87|  3352.48
> > > > &(_out->state_lock)->rlock: |  378.47|  0.30
> > > > (work_completion)(_state->crc_#2:   |  3999066.30|  2848.34
> > > > -++-
> > > > S2: With this patchset and with kvm  ||
> > > > -++-
> > > > &(_out->lock)->rlock:   |  23262.83  |  6.34
> > > > (work_completion)(_state->crc_wo:   |  8.98  |  8.98
> > > > &(_out->crc_lock)->rlock:   |  307.28|  0.32
> > > > (wq_completion)vkms_crc_workq:   |  6567727.05|  12345.35
> > > > (work_completion)(_state->crc_#2:   |  6567135.15|  4488.81
> > > > -++-
> > > > M1: Without this patchset and without kvm||
> > > > -++-
> > > > &(_out->state_lock)->rlock: |  4994.72   |  1.61
> > > > &(_out->lock)->rlock:   |  247190.04 |  39.39
> > > > (work_completion)(_state->crc_wo:   |  31.32 |  31.32
> > > > (wq_completion)vkms_crc_workq:   |  20991073.78   |  13525.18
> > > > (work_completion)(_state->crc_#2:   |  20988347.18   |  11904.90
> > > > -++-
> > > > M2: With this patchset and without kvm   ||
> > > > -++-
> > > > 

Re: [PATCH 1/2] drm/vkms: Use index instead of 0 in possible crtc

[Rodrigo Siqueira]

On Tue, Jun 18, 2019 at 2:18 AM Simon Ser  wrote:
>
> On Tuesday, June 18, 2019 5:19 AM, Rodrigo Siqueira 
>  wrote:
> > I made the patch, but when I started to write the commit message, I just
> > realized that I did not understand why possible_crtcs should not be
> > equal zero. Why can we not use zero?
>
> Hi,
>
> possible_crtcs is a bitfield. If it's zero, it means the plane cannot
> be attached to any CRTC, which makes it rather useless.

Hi,

Thank you very much for your explanation. I'll try to finish the patch.

> Thanks,
>
> Simon



-- 

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

Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT

[Ilia Mirkin]

On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia  wrote:
>
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some SoCs, such as
> RK3288, the LUT address is after the MMU address, and the latter
> is supported by a different driver. This prevents the DRM driver
> from requesting an entire register space.
>
> The current implementation works for RGB 10-bit tables, as that
> is what seems to work on RK3288.
>
> Signed-off-by: Ezequiel Garcia 
> ---
> Changes from RFC:
> * Request (an optional) address resource for the LUT.
> * Drop support for RK3399, which doesn't seem to work
>   out of the box and needs more research.
> * Support pass-thru setting when GAMMA_LUT is NULL.
> * Add a check for the gamma size, as suggested by Ilia.
> * Move gamma setting to atomic_commit_tail, as pointed
>   out by Jacopo/Laurent, is the correct way.
> ---
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 12ed5265a90b..5b6edbe2673f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> +  struct drm_crtc_state *old_state)
> +{
> +   int idle, ret, i;
> +
> +   spin_lock(>reg_lock);
> +   VOP_REG_SET(vop, common, dsp_lut_en, 0);
> +   vop_cfg_done(vop);
> +   spin_unlock(>reg_lock);
> +
> +   ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> +  idle, !idle, 5, 30 * 1000);
> +   if (ret)
> +   return;
> +
> +   spin_lock(>reg_lock);
> +
> +   if (crtc->state->gamma_lut) {
> +   if (!old_state->gamma_lut || (crtc->state->gamma_lut->base.id 
> !=
> + old_state->gamma_lut->base.id))
> +   vop_crtc_write_gamma_lut(vop, crtc);
> +   } else {
> +   for (i = 0; i < crtc->gamma_size; i++) {
> +   u32 word;
> +
> +   word = (i << 20) | (i << 10) | i;
> +   writel(word, vop->lut_regs + i * 4);
> +   }

Note - I'm not in any way familiar with the hardware, so take with a
grain of salt --

Could you just leave dsp_lut_en turned off in this case?

Cheers,

  -ilia

> +   }
> +
> +   VOP_REG_SET(vop, common, dsp_lut_en, 1);
> +   vop_cfg_done(vop);
> +   spin_unlock(>reg_lock);
> +}

Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)

[Daniel Vetter]

On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> >  wrote:
> > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > > these drivers, which would solve this issue, but in a more "non-drm"
> > > > way.  Is it worth to just do that instead of overthinking the whole
> > > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> > >
> > > An example of "open coding" this is the patch below for the sor.c
> > > driver.
> > 
> > I think open-coding is the way to go here. One of the todos is to
> > extend debugfs support for crtc/connectors, but looking at the
> > open-coded version we really don't need a drm-flavoured midlayer here.
> 
> There already is debugfs support in the code for crtc/connectors, these
> files are "hanging" off of those locations already.  I'll keep that, but
> indent it one more directory so that there's no namespace collisions.

The todo was to have some drm wrappers here for the boilerplate, but after
looking at your version that's not a good idea. So not just making sure
crtcs/connectors have a debugfs directory made for them, but more.

Wrt adding a new directory: debugfs isnt uapi, but there's usually a
massive pile of script relying on them, so it's not nice to shuffle paths
around. Plus the lifetimes match anyway (at least if you don't hotplug
connectors, which tegra doesn't do).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT

[Ezequiel Garcia]

Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.

The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.

The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.

Signed-off-by: Ezequiel Garcia 
---
Changes from RFC:
* Request (an optional) address resource for the LUT.
* Drop support for RK3399, which doesn't seem to work
  out of the box and needs more research.
* Support pass-thru setting when GAMMA_LUT is NULL.
* Add a check for the gamma size, as suggested by Ilia.
* Move gamma setting to atomic_commit_tail, as pointed
  out by Jacopo/Laurent, is the correct way.
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 106 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   7 ++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
 4 files changed, 118 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 1c69066b6894..bf9ad6240971 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -16,6 +16,7 @@
 #include "rockchip_drm_fb.h"
 #include "rockchip_drm_gem.h"
 #include "rockchip_drm_psr.h"
+#include "rockchip_drm_vop.h"
 
 static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
 struct drm_file *file,
@@ -128,6 +129,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct 
drm_atomic_state *old_state)
 
drm_atomic_helper_commit_modeset_disables(dev, old_state);
 
+   rockchip_drm_vop_gamma_set(old_state);
+
drm_atomic_helper_commit_modeset_enables(dev, old_state);
 
drm_atomic_helper_commit_planes(dev, old_state,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 12ed5265a90b..5b6edbe2673f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -137,6 +137,7 @@ struct vop {
 
uint32_t *regsbak;
void __iomem *regs;
+   void __iomem *lut_regs;
 
/* physical map length of vop register */
uint32_t len;
@@ -1153,6 +1154,94 @@ static void vop_wait_for_irq_handler(struct vop *vop)
synchronize_irq(vop->irq);
 }
 
+static bool vop_dsp_lut_is_enable(struct vop *vop)
+{
+   return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
+}
+
+static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
+{
+   struct drm_color_lut *lut = crtc->state->gamma_lut->data;
+   int i;
+
+   for (i = 0; i < crtc->gamma_size; i++) {
+   u32 word;
+
+   word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
+  (drm_color_lut_extract(lut[i].green, 10) << 10) |
+   drm_color_lut_extract(lut[i].blue, 10);
+   writel(word, vop->lut_regs + i * 4);
+   }
+}
+
+static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
+  struct drm_crtc_state *old_state)
+{
+   int idle, ret, i;
+
+   spin_lock(>reg_lock);
+   VOP_REG_SET(vop, common, dsp_lut_en, 0);
+   vop_cfg_done(vop);
+   spin_unlock(>reg_lock);
+
+   ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
+  idle, !idle, 5, 30 * 1000);
+   if (ret)
+   return;
+
+   spin_lock(>reg_lock);
+
+   if (crtc->state->gamma_lut) {
+   if (!old_state->gamma_lut || (crtc->state->gamma_lut->base.id !=
+ old_state->gamma_lut->base.id))
+   vop_crtc_write_gamma_lut(vop, crtc);
+   } else {
+   for (i = 0; i < crtc->gamma_size; i++) {
+   u32 word;
+
+   word = (i << 20) | (i << 10) | i;
+   writel(word, vop->lut_regs + i * 4);
+   }
+   }
+
+   VOP_REG_SET(vop, common, dsp_lut_en, 1);
+   vop_cfg_done(vop);
+   spin_unlock(>reg_lock);
+}
+
+static int vop_crtc_atomic_check(struct drm_crtc *crtc,
+  struct drm_crtc_state *crtc_state)
+{
+   struct vop *vop = to_vop(crtc);
+
+   if (vop->lut_regs && crtc_state->color_mgmt_changed &&
+   crtc_state->gamma_lut) {
+   int len;
+
+   len = drm_color_lut_size(crtc_state->gamma_lut);
+   if (len != crtc->gamma_size) {
+   DRM_DEBUG_KMS("Invalid LUT size; got %d, expected %d\n",
+ len, crtc->gamma_size);
+   return -EINVAL;
+   }
+   }
+   return 0;

[PATCH 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address

[Ezequiel Garcia]

Add the register specifier description for an
optional gamma LUT address.

Signed-off-by: Ezequiel Garcia 
---
 .../bindings/display/rockchip/rockchip-vop.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 4f58c5a2d195..97ad78cc7e03 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -20,6 +20,13 @@ Required properties:
"rockchip,rk3228-vop";
"rockchip,rk3328-vop";
 
+- reg: Must contain one entry corresponding to the base address and length
+   of the register space. Can optionally contain a second entry
+   corresponding to the CRTC gamma LUT address.
+
+- reg-names: "base" for the base register space. If present, the CRTC
+   gamma LUT name should be "lut".
+
 - interrupts: should contain a list of all VOP IP block interrupts in the
 order: VSYNC, LCD_SYSTEM. The interrupt specifier
 format depends on the interrupt controller used.
@@ -48,7 +55,8 @@ Example:
 SoC specific DT entry:
vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
-   reg = <0xff93 0x19c>;
+   reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
+   reg-names = "base", "lut";
interrupts = ;
clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
-- 
2.20.1

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

[PATCH 3/3] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address

[Ezequiel Garcia]

RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.

Signed-off-by: Ezequiel Garcia 
---
 arch/arm/boot/dts/rk3288.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index aa017abf4f42..dd40c189b1f0 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1025,7 +1025,8 @@
 
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
-   reg = <0x0 0xff93 0x0 0x19c>;
+   reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
+   reg-names = "base", "lut";
interrupts = ;
clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
@@ -1075,7 +1076,8 @@
 
vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
-   reg = <0x0 0xff94 0x0 0x19c>;
+   reg = <0x0 0xff94 0x0 0x19c>, <0x0 0xff941000 0x0 0x1000>;
+   reg-names = "base", "lut";
interrupts = ;
clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
-- 
2.20.1

[PATCH 0/3] RK3288 Gamma LUT

[Ezequiel Garcia]

Let's support Gamma LUT configuration on RK3288 SoCs.

In order to do so, this series adds a new and optional
address resource.

A separate address resource is required because on this RK3288,
the LUT address is after the MMU address, which is requested
by the iommu driver. This prevents the DRM driver
from requesting an entire register space.

The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.

This has been tested on Rock2 Square board, using
a hacked 'modetest' tool, with legacy and atomic APIs. 

Thanks,
Eze

Changes from RFC:
* Request (an optional) address resource for the LUT.
* Add devicetree changes.
* Drop support for RK3399, which doesn't seem to work
  out of the box and needs more research.
* Support pass-thru setting when GAMMA_LUT is NULL.
* Add a check for the gamma size, as suggested by Ilia.
* Move gamma setting to atomic_commit_tail, as pointed
  out by Jacopo/Laurent, is the correct way.

Ezequiel Garcia (3):
  dt-bindings: display: rockchip: document VOP gamma LUT address
  drm/rockchip: Add optional support for CRTC gamma LUT
  ARM: dts: rockchip: Add RK3288 VOP gamma LUT address

 .../display/rockchip/rockchip-vop.txt |  10 +-
 arch/arm/boot/dts/rk3288.dtsi |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 106 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   7 ++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |   2 +
 6 files changed, 131 insertions(+), 3 deletions(-)

-- 
2.20.1

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

Re: [Freedreno] [PATCH 5/5] drm/msm/mdp5: Use the interconnect API

[Rob Clark]

On Tue, Jun 18, 2019 at 1:44 PM Jeffrey Hugo  wrote:
>
> On Tue, Jun 18, 2019 at 2:25 PM Rob Clark  wrote:
> >
> > From: Georgi Djakov 
> >
> > The interconnect API provides an interface for consumer drivers to
> > express their bandwidth needs in the SoC. This data is aggregated
> > and the on-chip interconnect hardware is configured to the most
> > appropriate power/performance profile.
> >
> > Use the API to configure the interconnects and request bandwidth
> > between DDR and the display hardware (MDP port(s) and rotator
> > downscaler).
> >
> > v2: update the path names to be consistent with dpu, handle the NULL
> > path case, updated commit msg from Georgi.
> >
> > Signed-off-by: Georgi Djakov 
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > index 97179bec8902..eeac429acf40 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > @@ -16,6 +16,7 @@
> >   * this program.  If not, see .
> >   */
> >
> > +#include 
> >  #include 
> >
> >  #include "msm_drv.h"
> > @@ -1050,6 +1051,19 @@ static const struct component_ops mdp5_ops = {
> >
> >  static int mdp5_dev_probe(struct platform_device *pdev)
> >  {
> > +   struct icc_path *path0 = of_icc_get(>dev, "mdp0-mem");
> > +   struct icc_path *path1 = of_icc_get(>dev, "mdp1-mem");
> > +   struct icc_path *path_rot = of_icc_get(>dev, "rotator-mem");
> > +
> > +   if (IS_ERR_OR_NULL(path0))
> > +   return PTR_ERR_OR_ZERO(path0);
>
> Umm, am I misunderstanding something?  It seems like of_icc_get()
> returns NULL if the property doesn't exist.  Won't this be backwards
> incompatible?  Existing DTs won't specify the property, and I don't
> believe the property is supported on all targets.  Seems like we'll
> break things by not calling the below component_add() if the
> interconnect is not supported, specified, or the interconnect driver
> is not compiled.

hmm, right, I guess I should test this w/out the dts patch.. probably
should just revert back to the previous logic..

BR,
-R

> > +   icc_set_bw(path0, 0, MBps_to_icc(6400));
> > +
> > +   if (!IS_ERR_OR_NULL(path1))
> > +   icc_set_bw(path1, 0, MBps_to_icc(6400));
> > +   if (!IS_ERR_OR_NULL(path_rot))
> > +   icc_set_bw(path_rot, 0, MBps_to_icc(6400));
> > +
> > DBG("");
> > return component_add(>dev, _ops);
> >  }
> > --
> > 2.20.1
> >
> > ___
> > Freedreno mailing list
> > freedr...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno

[Bug 110803] Coruption and flickering on polaris with mesa 19.0.5

[bugzilla-daemon]

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

diplosa...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from diplosa...@gmail.com ---


*** This bug has been marked as a duplicate of bug 110721 ***

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

[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris

[bugzilla-daemon]

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

diplosa...@gmail.com changed:

   What|Removed |Added

 CC||diplosa...@gmail.com

--- Comment #21 from diplosa...@gmail.com ---
*** Bug 110803 has been marked as a duplicate of this bug. ***

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

[PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst

[Mauro Carvalho Chehab]

Those files are actually at ReST format. Ok, currently, they
don't belong to any place yet at the organized book series,
but we don't want patches to break them as ReST files. So,
rename them and add a :orphan: in order to shut up warning
messages like those:

...
Documentation/svga.rst: WARNING: document isn't included in any toctree
Documentation/switchtec.rst: WARNING: document isn't included in any toctree
...

Later patches will move them to a better place and remove the
:orphan: markup.

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

I had to remove the long list of maintainers got by
getpatch.pl, as it was too long. I opted to keep only the
mailing lists.

 Documentation/ABI/removed/sysfs-class-rfkill  |  2 +-
 Documentation/ABI/stable/sysfs-class-rfkill   |  2 +-
 Documentation/ABI/stable/sysfs-devices-node   |  2 +-
 Documentation/ABI/testing/procfs-diskstats|  2 +-
 Documentation/ABI/testing/sysfs-block |  2 +-
 .../ABI/testing/sysfs-class-switchtec |  2 +-
 .../ABI/testing/sysfs-devices-system-cpu  |  4 +-
 .../{DMA-API-HOWTO.txt => DMA-API-HOWTO.rst}  |  2 +
 Documentation/{DMA-API.txt => DMA-API.rst}|  8 ++-
 .../{DMA-ISA-LPC.txt => DMA-ISA-LPC.rst}  |  4 +-
 ...{DMA-attributes.txt => DMA-attributes.rst} |  2 +
 Documentation/{IPMI.txt => IPMI.rst}  |  2 +
 .../{IRQ-affinity.txt => IRQ-affinity.rst}|  2 +
 .../{IRQ-domain.txt => IRQ-domain.rst}|  2 +
 Documentation/{IRQ.txt => IRQ.rst}|  2 +
 .../{Intel-IOMMU.txt => Intel-IOMMU.rst}  |  2 +
 Documentation/PCI/pci.rst |  8 +--
 Documentation/{SAK.txt => SAK.rst}|  3 +-
 Documentation/{SM501.txt => SM501.rst}|  2 +
 Documentation/admin-guide/hw-vuln/l1tf.rst|  2 +-
 .../admin-guide/kernel-parameters.txt |  4 +-
 .../{atomic_bitops.txt => atomic_bitops.rst}  |  3 +-
 Documentation/block/biodoc.txt|  2 +-
 .../{bt8xxgpio.txt => bt8xxgpio.rst}  |  3 +-
 Documentation/{btmrvl.txt => btmrvl.rst}  |  2 +
 ...-mapping.txt => bus-virt-phys-mapping.rst} | 54 +-
 ...g-warn-once.txt => clearing-warn-once.rst} |  2 +
 Documentation/{cpu-load.txt => cpu-load.rst}  |  2 +
 .../{cputopology.txt => cputopology.rst}  |  2 +
 Documentation/{crc32.txt => crc32.rst}|  2 +
 Documentation/{dcdbas.txt => dcdbas.rst}  |  2 +
 ...ging-modules.txt => debugging-modules.rst} |  2 +
 ...hci1394.txt => debugging-via-ohci1394.rst} |  2 +
 Documentation/{dell_rbu.txt => dell_rbu.rst}  |  3 +-
 Documentation/device-mapper/statistics.rst|  4 +-
 .../devicetree/bindings/phy/phy-bindings.txt  |  2 +-
 Documentation/{digsig.txt => digsig.rst}  |  2 +
 Documentation/driver-api/usb/dma.rst  |  6 +-
 Documentation/driver-model/device.rst |  2 +-
 Documentation/{efi-stub.txt => efi-stub.rst}  |  2 +
 Documentation/{eisa.txt => eisa.rst}  |  2 +
 Documentation/fb/vesafb.rst   |  2 +-
 Documentation/filesystems/sysfs.txt   |  2 +-
 ...ex-requeue-pi.txt => futex-requeue-pi.rst} |  2 +
 .../{gcc-plugins.txt => gcc-plugins.rst}  |  2 +
 Documentation/gpu/drm-mm.rst  |  2 +-
 Documentation/{highuid.txt => highuid.rst}|  4 +-
 .../{hw_random.txt => hw_random.rst}  |  2 +
 .../{hwspinlock.txt => hwspinlock.rst}|  2 +
 Documentation/ia64/irq-redir.rst  |  2 +-
 .../{intel_txt.txt => intel_txt.rst}  |  2 +
 .../{io-mapping.txt => io-mapping.rst}|  2 +
 .../{io_ordering.txt => io_ordering.rst}  |  2 +
 Documentation/{iostats.txt => iostats.rst}|  2 +
 ...flags-tracing.txt => irqflags-tracing.rst} |  3 +-
 Documentation/{isa.txt => isa.rst}|  2 +
 Documentation/{isapnp.txt => isapnp.rst}  |  2 +
 ...hreads.txt => kernel-per-CPU-kthreads.rst} |  4 +-
 Documentation/{kobject.txt => kobject.rst}|  6 +-
 Documentation/{kprobes.txt => kprobes.rst}|  3 +-
 Documentation/{kref.txt => kref.rst}  |  2 +
 Documentation/laptops/thinkpad-acpi.rst   |  6 +-
 Documentation/{ldm.txt => ldm.rst}|  5 +-
 Documentation/locking/rt-mutex.rst|  2 +-
 ...kup-watchdogs.txt => lockup-watchdogs.rst} |  2 +
 Documentation/{lsm.txt => lsm.rst}|  2 +
 Documentation/{lzo.txt => lzo.rst}|  2 +
 Documentation/{mailbox.txt => mailbox.rst}|  2 +
 Documentation/memory-barriers.txt |  6 +-
 ...hameleon-bus.txt => men-chameleon-bus.rst} |  2 +
 Documentation/networking/scaling.rst  |  4 +-
 .../{nommu-mmap.txt => nommu-mmap.rst}|  2 +
 Documentation/{ntb.txt => ntb.rst}|  2 +
 Documentation/{numastat.txt => numastat.rst}  |  3 +-
 Documentation/{padata.txt => padata.rst}  |  2 +
 ...port-lowlevel.txt => parport-lowlevel.rst} |  2 +
 ...-semaphore.txt => percpu-rw-semaphore.rst} |  2 +
 Documentation/{phy.txt => phy.rst}|  2 +
 Documentation/{pi-futex.txt => pi-futex.rst}  |  2 +
 

[PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Mauro Carvalho Chehab]

Those files belong to the driver-api guide. Add them to the
driver-api book.

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

I had to remove the long list of maintainers got by
getpatch.pl, as it was too long. I opted to keep only the
mailing lists.

 Documentation/ABI/removed/sysfs-class-rfkill  |  2 +-
 Documentation/ABI/stable/sysfs-class-rfkill   |  2 +-
 .../ABI/testing/sysfs-class-switchtec |  2 +-
 Documentation/PCI/pci.rst |  2 +-
 Documentation/admin-guide/hw-vuln/l1tf.rst|  2 +-
 .../admin-guide/kernel-parameters.txt |  4 +-
 .../admin-guide/kernel-per-cpu-kthreads.rst   |  2 +-
 .../{ => driver-api}/atomic_bitops.rst|  2 -
 Documentation/{ => driver-api}/bt8xxgpio.rst  |  2 -
 .../bus-virt-phys-mapping.rst |  2 -
 .../{connector => driver-api}/connector.rst   |  2 -
 .../{console => driver-api}/console.rst   |  2 -
 Documentation/{ => driver-api}/crc32.rst  |  2 -
 Documentation/{ => driver-api}/dcdbas.rst |  2 -
 .../{ => driver-api}/debugging-modules.rst|  2 -
 .../debugging-via-ohci1394.rst|  2 -
 Documentation/{ => driver-api}/dell_rbu.rst   |  2 -
 Documentation/{ => driver-api}/digsig.rst |  2 -
 .../{EDID/howto.rst => driver-api/edid.rst}   |  2 -
 Documentation/{ => driver-api}/eisa.rst   |  2 -
 .../{ => driver-api}/futex-requeue-pi.rst |  2 -
 .../{ => driver-api}/gcc-plugins.rst  |  2 -
 Documentation/{ => driver-api}/hwspinlock.rst |  2 -
 Documentation/driver-api/index.rst| 66 +++
 Documentation/{ => driver-api}/io-mapping.rst |  2 -
 .../{ => driver-api}/io_ordering.rst  |  2 -
 .../{IPMI.rst => driver-api/ipmi.rst} |  2 -
 .../irq-affinity.rst} |  2 -
 .../irq-domain.rst}   |  2 -
 Documentation/{IRQ.rst => driver-api/irq.rst} |  2 -
 .../{ => driver-api}/irqflags-tracing.rst |  2 -
 Documentation/{ => driver-api}/isa.rst|  2 -
 Documentation/{ => driver-api}/isapnp.rst |  2 -
 Documentation/{ => driver-api}/kobject.rst|  4 +-
 Documentation/{ => driver-api}/kprobes.rst|  2 -
 Documentation/{ => driver-api}/kref.rst   |  2 -
 .../pblk.txt => driver-api/lightnvm-pblk.rst} |  0
 Documentation/{ => driver-api}/lzo.rst|  2 -
 Documentation/{ => driver-api}/mailbox.rst|  2 -
 .../{ => driver-api}/men-chameleon-bus.rst|  2 -
 Documentation/{ => driver-api}/nommu-mmap.rst |  2 -
 Documentation/{ => driver-api}/ntb.rst|  2 -
 Documentation/{nvmem => driver-api}/nvmem.rst |  2 -
 Documentation/{ => driver-api}/padata.rst |  2 -
 .../{ => driver-api}/parport-lowlevel.rst |  2 -
 .../{ => driver-api}/percpu-rw-semaphore.rst  |  2 -
 Documentation/{ => driver-api}/pi-futex.rst   |  2 -
 Documentation/driver-api/pps.rst  |  2 -
 .../{ => driver-api}/preempt-locking.rst  |  2 -
 .../{pti => driver-api}/pti_intel_mid.rst |  2 -
 Documentation/driver-api/ptp.rst  |  2 -
 Documentation/{ => driver-api}/pwm.rst|  2 -
 Documentation/{ => driver-api}/rbtree.rst |  2 -
 Documentation/{ => driver-api}/remoteproc.rst |  4 +-
 Documentation/{ => driver-api}/rfkill.rst |  2 -
 .../{ => driver-api}/robust-futex-ABI.rst |  2 -
 .../{ => driver-api}/robust-futexes.rst   |  2 -
 Documentation/{ => driver-api}/rpmsg.rst  |  2 -
 Documentation/{ => driver-api}/sgi-ioc4.rst   |  2 -
 .../{SM501.rst => driver-api/sm501.rst}   |  2 -
 .../{ => driver-api}/smsc_ece1099.rst |  2 -
 .../{ => driver-api}/speculation.rst  |  8 +--
 .../{ => driver-api}/static-keys.rst  |  2 -
 Documentation/{ => driver-api}/switchtec.rst  |  4 +-
 Documentation/{ => driver-api}/sync_file.rst  |  2 -
 Documentation/{ => driver-api}/tee.rst|  2 -
 .../{ => driver-api}/this_cpu_ops.rst |  2 -
 .../unaligned-memory-access.rst   |  2 -
 .../{ => driver-api}/vfio-mediated-device.rst |  4 +-
 Documentation/{ => driver-api}/vfio.rst   |  2 -
 Documentation/{ => driver-api}/xillybus.rst   |  2 -
 Documentation/{ => driver-api}/xz.rst |  2 -
 Documentation/{ => driver-api}/zorro.rst  |  2 -
 Documentation/driver-model/device.rst |  2 +-
 Documentation/fb/fbcon.rst|  4 +-
 Documentation/filesystems/sysfs.txt   |  2 +-
 Documentation/gpu/drm-mm.rst  |  2 +-
 Documentation/ia64/irq-redir.rst  |  2 +-
 Documentation/laptops/thinkpad-acpi.rst   |  6 +-
 Documentation/locking/rt-mutex.rst|  2 +-
 Documentation/networking/scaling.rst  |  4 +-
 Documentation/s390/vfio-ccw.rst   |  6 +-
 Documentation/sysctl/kernel.rst   |  2 +-
 Documentation/sysctl/vm.rst   |  2 +-
 Documentation/trace/kprobetrace.rst   |  2 +-
 Documentation/translations/zh_CN/IRQ.txt  |  4 +-
 .../translations/zh_CN/filesystems/sysfs.txt  |  2 +-
 

[PATCH v1 11/22] docs: admin-guide: add .rst files from the main dir

[Mauro Carvalho Chehab]

Those files belong to the admin guide. Add them to the
admin-guide book.

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

I had to remove the long list of maintainers got by
getpatch.pl, as it was too long. I opted to keep only the
mailing lists.

 Documentation/ABI/stable/sysfs-devices-node   |  2 +-
 Documentation/ABI/testing/procfs-diskstats|  2 +-
 Documentation/ABI/testing/sysfs-block |  2 +-
 .../ABI/testing/sysfs-devices-system-cpu  |  4 ++--
 Documentation/{ => admin-guide}/aoe/aoe.rst   |  4 ++--
 .../{ => admin-guide}/aoe/autoload.sh |  1 -
 .../{ => admin-guide}/aoe/examples.rst|  0
 Documentation/{ => admin-guide}/aoe/index.rst |  2 --
 Documentation/{ => admin-guide}/aoe/status.sh |  0
 Documentation/{ => admin-guide}/aoe/todo.rst  |  0
 .../{ => admin-guide}/aoe/udev-install.sh |  4 ++--
 Documentation/{ => admin-guide}/aoe/udev.txt  |  8 +++
 Documentation/{ => admin-guide}/btmrvl.rst|  2 --
 .../cgroup-v1/blkio-controller.rst|  0
 .../{ => admin-guide}/cgroup-v1/cgroups.rst   |  4 ++--
 .../{ => admin-guide}/cgroup-v1/cpuacct.rst   |  0
 .../{ => admin-guide}/cgroup-v1/cpusets.rst   |  2 +-
 .../{ => admin-guide}/cgroup-v1/devices.rst   |  0
 .../cgroup-v1/freezer-subsystem.rst   |  0
 .../{ => admin-guide}/cgroup-v1/hugetlb.rst   |  0
 .../{ => admin-guide}/cgroup-v1/index.rst |  2 --
 .../cgroup-v1/memcg_test.rst  |  4 ++--
 .../{ => admin-guide}/cgroup-v1/memory.rst|  0
 .../{ => admin-guide}/cgroup-v1/net_cls.rst   |  0
 .../{ => admin-guide}/cgroup-v1/net_prio.rst  |  0
 .../{ => admin-guide}/cgroup-v1/pids.rst  |  0
 .../{ => admin-guide}/cgroup-v1/rdma.rst  |  0
 Documentation/admin-guide/cgroup-v2.rst   |  2 +-
 .../{ => admin-guide}/clearing-warn-once.rst  |  2 --
 Documentation/{ => admin-guide}/cpu-load.rst  |  2 --
 .../{ => admin-guide}/cputopology.rst |  2 --
 Documentation/{ => admin-guide}/efi-stub.rst  |  2 --
 Documentation/{ => admin-guide}/highuid.rst   |  2 --
 Documentation/admin-guide/hw-vuln/l1tf.rst|  2 +-
 Documentation/{ => admin-guide}/hw_random.rst |  2 --
 Documentation/admin-guide/index.rst   | 23 +++
 Documentation/{ => admin-guide}/iostats.rst   |  2 --
 .../admin-guide/kernel-parameters.txt |  6 ++---
 .../kernel-per-cpu-kthreads.rst}  |  4 +---
 .../lcd-panel-cgram.rst   |  2 --
 Documentation/{ => admin-guide}/ldm.rst   |  2 --
 .../{ => admin-guide}/lockup-watchdogs.rst|  2 --
 .../mm/cma_debugfs.rst}   |  2 --
 .../admin-guide/mm/numa_memory_policy.rst |  2 +-
 Documentation/{ => admin-guide}/numastat.rst  |  4 +---
 Documentation/{ => admin-guide}/pnp.rst   |  2 --
 Documentation/{ => admin-guide}/rtc.rst   |  2 --
 Documentation/{ => admin-guide}/svga.rst  |  2 --
 .../{ => admin-guide}/video-output.rst|  2 --
 Documentation/block/bfq-iosched.rst   |  2 +-
 Documentation/device-mapper/statistics.rst|  4 ++--
 Documentation/driver-api/index.rst|  2 +-
 Documentation/fb/vesafb.rst   |  2 +-
 Documentation/filesystems/tmpfs.txt   |  2 +-
 Documentation/scheduler/sched-deadline.rst|  2 +-
 Documentation/scheduler/sched-design-CFS.rst  |  2 +-
 Documentation/scheduler/sched-rt-group.rst|  2 +-
 Documentation/sysctl/kernel.rst   |  2 +-
 Documentation/vm/numa.rst |  4 ++--
 Documentation/vm/page_migration.rst   |  2 +-
 Documentation/vm/unevictable-lru.rst  |  2 +-
 Documentation/x86/topology.rst|  2 +-
 .../x86/x86_64/fake-numa-for-cpusets.rst  |  4 ++--
 MAINTAINERS   | 18 +++
 arch/arm/Kconfig  |  2 +-
 arch/parisc/Kconfig   |  2 +-
 arch/sh/Kconfig   |  2 +-
 arch/sparc/Kconfig|  2 +-
 arch/x86/Kconfig  |  4 ++--
 block/Kconfig |  2 +-
 block/partitions/Kconfig  |  2 +-
 drivers/char/Kconfig  |  4 ++--
 drivers/char/hw_random/core.c |  2 +-
 include/linux/cgroup-defs.h   |  2 +-
 include/linux/hw_random.h |  2 +-
 include/uapi/linux/bpf.h  |  2 +-
 init/Kconfig  |  4 ++--
 kernel/cgroup/cpuset.c|  2 +-
 security/device_cgroup.c  |  2 +-
 tools/include/uapi/linux/bpf.h|  2 +-
 80 files changed, 94 insertions(+), 112 deletions(-)
 rename Documentation/{ => admin-guide}/aoe/aoe.rst (97%)
 rename Documentation/{ => admin-guide}/aoe/autoload.sh (99%)
 rename Documentation/{ => admin-guide}/aoe/examples.rst (100%)
 rename Documentation/{ => admin-guide}/aoe/index.rst (95%)
 rename Documentation/{ => 

[PATCH v1 03/22] docs: ioctl: convert to ReST

[Mauro Carvalho Chehab]

Rename the iio documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.

The cdrom.txt and hdio.txt have their own particular syntax.
In order to speedup the conversion, I used a small ancillary
perl script:

my $d;
$d .= $_ while(<>);
$d =~ s/(\nCDROM\S+)\s+(\w[^\n]*)/$1\n\t$2\n/g;
$d =~ s/(\nHDIO\S+)\s+(\w[^\n]*)/$1\n\t$2\n/g;
$d =~ s/(\n\s*usage:)[\s\n]*(\w[^\n]*)/$1:\n\n\t  $2\n/g;
$d =~ s/(\n\s*)(E\w+[\s\n]*\w[^\n]*)/$1- $2/g;
$d =~ s/(\n\s*)(inputs|outputs|notes):\s*(\w[^\n]*)/$1$2:\n\t\t$3\n/g;
print $d;

It basically add blank lines on a few interesting places. The
script is not perfect: still several things require manual work,
but it saved quite some time doing some obvious stuff.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab 
---
 ...g-up-ioctls.txt => botching-up-ioctls.rst} |   1 +
 Documentation/ioctl/{cdrom.txt => cdrom.rst}  | 908 +++---
 Documentation/ioctl/{hdio.txt => hdio.rst}| 835 ++--
 Documentation/ioctl/index.rst |  16 +
 ...{ioctl-decoding.txt => ioctl-decoding.rst} |  13 +-
 drivers/gpu/drm/drm_ioctl.c   |   2 +-
 6 files changed, 1168 insertions(+), 607 deletions(-)
 rename Documentation/ioctl/{botching-up-ioctls.txt => botching-up-ioctls.rst} 
(99%)
 rename Documentation/ioctl/{cdrom.txt => cdrom.rst} (39%)
 rename Documentation/ioctl/{hdio.txt => hdio.rst} (54%)
 create mode 100644 Documentation/ioctl/index.rst
 rename Documentation/ioctl/{ioctl-decoding.txt => ioctl-decoding.rst} (54%)

diff --git a/Documentation/ioctl/botching-up-ioctls.txt 
b/Documentation/ioctl/botching-up-ioctls.rst
similarity index 99%
rename from Documentation/ioctl/botching-up-ioctls.txt
rename to Documentation/ioctl/botching-up-ioctls.rst
index 883fb034bd04..ac697fef3545 100644
--- a/Documentation/ioctl/botching-up-ioctls.txt
+++ b/Documentation/ioctl/botching-up-ioctls.rst
@@ -1,3 +1,4 @@
+=
 (How to avoid) Botching up ioctls
 =
 
diff --git a/Documentation/ioctl/cdrom.txt b/Documentation/ioctl/cdrom.rst
similarity index 39%
rename from Documentation/ioctl/cdrom.txt
rename to Documentation/ioctl/cdrom.rst
index a4d62a9d6771..3b4c0506de46 100644
--- a/Documentation/ioctl/cdrom.txt
+++ b/Documentation/ioctl/cdrom.rst
@@ -1,9 +1,10 @@
-   Summary of CDROM ioctl calls.
-   
+
+Summary of CDROM ioctl calls
+
 
-   Edward A. Falk 
+- Edward A. Falk 
 
-   November, 2004
+November, 2004
 
 This document attempts to describe the ioctl(2) calls supported by
 the CDROM layer.  These are by-and-large implemented (as of Linux 2.6)
@@ -12,6 +13,7 @@ in drivers/cdrom/cdrom.c and drivers/block/scsi_ioctl.c
 ioctl values are listed in .  As of this writing, they
 are as follows:
 
+   ==  ===
CDROMPAUSE  Pause Audio Operation
CDROMRESUME Resume paused Audio Operation
CDROMPLAYMSFPlay Audio MSF (struct cdrom_msf)
@@ -24,22 +26,22 @@ are as follows:
CDROMVOLCTRLControl output volume (struct cdrom_volctrl)
CDROMSUBCHNLRead subchannel data (struct cdrom_subchnl)
CDROMREADMODE2  Read CDROM mode 2 data (2336 Bytes)
-  (struct cdrom_read)
+   (struct cdrom_read)
CDROMREADMODE1  Read CDROM mode 1 data (2048 Bytes)
-  (struct cdrom_read)
+   (struct cdrom_read)
CDROMREADAUDIO  (struct cdrom_read_audio)
CDROMEJECT_SW   enable(1)/disable(0) auto-ejecting
CDROMMULTISESSION   Obtain the start-of-last-session
- address of multi session disks
- (struct cdrom_multisession)
+   address of multi session disks
+   (struct cdrom_multisession)
CDROM_GET_MCN   Obtain the "Universal Product Code"
-  if available (struct cdrom_mcn)
+   if available (struct cdrom_mcn)
CDROM_GET_UPC   Deprecated, use CDROM_GET_MCN instead.
CDROMRESET  hard-reset the drive
CDROMVOLREADGet the drive's volume setting
- (struct cdrom_volctrl)
+   (struct cdrom_volctrl)
CDROMREADRAWread data in raw mode (2352 Bytes)
-   

[PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Mauro Carvalho Chehab]

Those files belong to the driver-api guide. Add them to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ABI/removed/sysfs-class-rfkill  |  2 +-
 Documentation/ABI/stable/sysfs-class-rfkill   |  2 +-
 .../ABI/testing/sysfs-class-switchtec |  2 +-
 Documentation/PCI/pci.rst |  2 +-
 Documentation/admin-guide/hw-vuln/l1tf.rst|  2 +-
 .../admin-guide/kernel-parameters.txt |  4 +-
 .../admin-guide/kernel-per-cpu-kthreads.rst   |  2 +-
 .../{ => driver-api}/atomic_bitops.rst|  2 -
 Documentation/{ => driver-api}/bt8xxgpio.rst  |  2 -
 .../bus-virt-phys-mapping.rst |  2 -
 .../{connector => driver-api}/connector.rst   |  2 -
 .../{console => driver-api}/console.rst   |  2 -
 Documentation/{ => driver-api}/crc32.rst  |  2 -
 Documentation/{ => driver-api}/dcdbas.rst |  2 -
 .../{ => driver-api}/debugging-modules.rst|  2 -
 .../debugging-via-ohci1394.rst|  2 -
 Documentation/{ => driver-api}/dell_rbu.rst   |  2 -
 Documentation/{ => driver-api}/digsig.rst |  2 -
 .../{EDID/howto.rst => driver-api/edid.rst}   |  2 -
 Documentation/{ => driver-api}/eisa.rst   |  2 -
 .../{ => driver-api}/futex-requeue-pi.rst |  2 -
 .../{ => driver-api}/gcc-plugins.rst  |  2 -
 Documentation/{ => driver-api}/hwspinlock.rst |  2 -
 Documentation/driver-api/index.rst| 66 +++
 Documentation/{ => driver-api}/io-mapping.rst |  2 -
 .../{ => driver-api}/io_ordering.rst  |  2 -
 .../{IPMI.rst => driver-api/ipmi.rst} |  2 -
 .../irq-affinity.rst} |  2 -
 .../irq-domain.rst}   |  2 -
 Documentation/{IRQ.rst => driver-api/irq.rst} |  2 -
 .../{ => driver-api}/irqflags-tracing.rst |  2 -
 Documentation/{ => driver-api}/isa.rst|  2 -
 Documentation/{ => driver-api}/isapnp.rst |  2 -
 Documentation/{ => driver-api}/kobject.rst|  4 +-
 Documentation/{ => driver-api}/kprobes.rst|  2 -
 Documentation/{ => driver-api}/kref.rst   |  2 -
 .../pblk.txt => driver-api/lightnvm-pblk.rst} |  0
 Documentation/{ => driver-api}/lzo.rst|  2 -
 Documentation/{ => driver-api}/mailbox.rst|  2 -
 .../{ => driver-api}/men-chameleon-bus.rst|  2 -
 Documentation/{ => driver-api}/nommu-mmap.rst |  2 -
 Documentation/{ => driver-api}/ntb.rst|  2 -
 Documentation/{nvmem => driver-api}/nvmem.rst |  2 -
 Documentation/{ => driver-api}/padata.rst |  2 -
 .../{ => driver-api}/parport-lowlevel.rst |  2 -
 .../{ => driver-api}/percpu-rw-semaphore.rst  |  2 -
 Documentation/{ => driver-api}/pi-futex.rst   |  2 -
 Documentation/driver-api/pps.rst  |  2 -
 .../{ => driver-api}/preempt-locking.rst  |  2 -
 .../{pti => driver-api}/pti_intel_mid.rst |  2 -
 Documentation/driver-api/ptp.rst  |  2 -
 Documentation/{ => driver-api}/pwm.rst|  2 -
 Documentation/{ => driver-api}/rbtree.rst |  2 -
 Documentation/{ => driver-api}/remoteproc.rst |  4 +-
 Documentation/{ => driver-api}/rfkill.rst |  2 -
 .../{ => driver-api}/robust-futex-ABI.rst |  2 -
 .../{ => driver-api}/robust-futexes.rst   |  2 -
 Documentation/{ => driver-api}/rpmsg.rst  |  2 -
 Documentation/{ => driver-api}/sgi-ioc4.rst   |  2 -
 .../{SM501.rst => driver-api/sm501.rst}   |  2 -
 .../{ => driver-api}/smsc_ece1099.rst |  2 -
 .../{ => driver-api}/speculation.rst  |  8 +--
 .../{ => driver-api}/static-keys.rst  |  2 -
 Documentation/{ => driver-api}/switchtec.rst  |  4 +-
 Documentation/{ => driver-api}/sync_file.rst  |  2 -
 Documentation/{ => driver-api}/tee.rst|  2 -
 .../{ => driver-api}/this_cpu_ops.rst |  2 -
 .../unaligned-memory-access.rst   |  2 -
 .../{ => driver-api}/vfio-mediated-device.rst |  4 +-
 Documentation/{ => driver-api}/vfio.rst   |  2 -
 Documentation/{ => driver-api}/xillybus.rst   |  2 -
 Documentation/{ => driver-api}/xz.rst |  2 -
 Documentation/{ => driver-api}/zorro.rst  |  2 -
 Documentation/driver-model/device.rst |  2 +-
 Documentation/fb/fbcon.rst|  4 +-
 Documentation/filesystems/sysfs.txt   |  2 +-
 Documentation/gpu/drm-mm.rst  |  2 +-
 Documentation/ia64/irq-redir.rst  |  2 +-
 Documentation/laptops/thinkpad-acpi.rst   |  6 +-
 Documentation/locking/rt-mutex.rst|  2 +-
 Documentation/networking/scaling.rst  |  4 +-
 Documentation/s390/vfio-ccw.rst   |  6 +-
 Documentation/sysctl/kernel.rst   |  2 +-
 Documentation/sysctl/vm.rst   |  2 +-
 Documentation/trace/kprobetrace.rst   |  2 +-
 Documentation/translations/zh_CN/IRQ.txt  |  4 +-
 .../translations/zh_CN/filesystems/sysfs.txt  |  2 +-
 .../translations/zh_CN/io_ordering.txt|  4 +-
 Documentation/w1/w1.netlink   |  2 +-
 

[PATCH v2 06/29] docs: console.txt: convert docs to ReST and rename to *.rst

[Mauro Carvalho Chehab]

Convert this small file to ReST in preparation for adding it to
the driver-api book.

While this is not part of the driver-api book, mark it as
:orphan:, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../console/{console.txt => console.rst}  | 63 ++-
 Documentation/fb/fbcon.rst|  4 +-
 drivers/tty/Kconfig   |  2 +-
 3 files changed, 38 insertions(+), 31 deletions(-)
 rename Documentation/console/{console.txt => console.rst} (80%)

diff --git a/Documentation/console/console.txt 
b/Documentation/console/console.rst
similarity index 80%
rename from Documentation/console/console.txt
rename to Documentation/console/console.rst
index d73c2ab4beda..b374141b027e 100644
--- a/Documentation/console/console.txt
+++ b/Documentation/console/console.rst
@@ -1,3 +1,6 @@
+:orphan:
+
+===
 Console Drivers
 ===
 
@@ -17,25 +20,26 @@ of driver occupying the consoles.) They can only take over 
the console that is
 occupied by the system driver. In the same token, if the modular driver is
 released by the console, the system driver will take over.
 
-Modular drivers, from the programmer's point of view, have to call:
+Modular drivers, from the programmer's point of view, have to call::
 
 do_take_over_console() - load and bind driver to console layer
 give_up_console() - unload driver; it will only work if driver
 is fully unbound
 
-In newer kernels, the following are also available:
+In newer kernels, the following are also available::
 
 do_register_con_driver()
 do_unregister_con_driver()
 
 If sysfs is enabled, the contents of /sys/class/vtconsole can be
 examined. This shows the console backends currently registered by the
-system which are named vtcon where  is an integer from 0 to 15. Thus:
+system which are named vtcon where  is an integer from 0 to 15.
+Thus::
 
ls /sys/class/vtconsole
.  ..  vtcon0  vtcon1
 
-Each directory in /sys/class/vtconsole has 3 files:
+Each directory in /sys/class/vtconsole has 3 files::
 
  ls /sys/class/vtconsole/vtcon0
  .  ..  bind  name  uevent
@@ -46,27 +50,29 @@ What do these files signify?
 read, or acts to bind or unbind the driver to the virtual consoles
 when written to. The possible values are:
 
-   0 - means the driver is not bound and if echo'ed, commands the driver
+   0
+ - means the driver is not bound and if echo'ed, commands the driver
to unbind
 
-1 - means the driver is bound and if echo'ed, commands the driver to
+1
+ - means the driver is bound and if echo'ed, commands the driver to
bind
 
- 2. name - read-only file. Shows the name of the driver in this format:
+ 2. name - read-only file. Shows the name of the driver in this format::
 
-   cat /sys/class/vtconsole/vtcon0/name
-   (S) VGA+
+ cat /sys/class/vtconsole/vtcon0/name
+ (S) VGA+
 
-   '(S)' stands for a (S)ystem driver, i.e., it cannot be directly
-   commanded to bind or unbind
+ '(S)' stands for a (S)ystem driver, i.e., it cannot be directly
+ commanded to bind or unbind
 
-   'VGA+' is the name of the driver
+ 'VGA+' is the name of the driver
 
-   cat /sys/class/vtconsole/vtcon1/name
-   (M) frame buffer device
+ cat /sys/class/vtconsole/vtcon1/name
+ (M) frame buffer device
 
-   In this case, '(M)' stands for a (M)odular driver, one that can be
-   directly commanded to bind or unbind.
+ In this case, '(M)' stands for a (M)odular driver, one that can be
+ directly commanded to bind or unbind.
 
  3. uevent - ignore this file
 
@@ -75,14 +81,17 @@ driver takes over the consoles vacated by the driver. 
Binding, on the other
 hand, will bind the driver to the consoles that are currently occupied by a
 system driver.
 
-NOTE1: Binding and unbinding must be selected in Kconfig. It's under:
+NOTE1:
+  Binding and unbinding must be selected in Kconfig. It's under::
 
-Device Drivers -> Character devices -> Support for binding and unbinding
-console drivers
+Device Drivers ->
+   Character devices ->
+   Support for binding and unbinding console drivers
 
-NOTE2: If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
-unbinding will not succeed. An example of an application that sets the console
-to KD_GRAPHICS is X.
+NOTE2:
+  If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
+  unbinding will not succeed. An example of an application that sets the
+  console to KD_GRAPHICS is X.
 
 How useful is this feature? This is very useful for console driver
 developers. By unbinding the driver from the console layer, one can unload the
@@ -92,10 +101,10 @@ framebuffer console to VGA console and vice versa, this 
feature 

Re: [Freedreno] [PATCH 5/5] drm/msm/mdp5: Use the interconnect API

[Jeffrey Hugo]

On Tue, Jun 18, 2019 at 2:25 PM Rob Clark  wrote:
>
> From: Georgi Djakov 
>
> The interconnect API provides an interface for consumer drivers to
> express their bandwidth needs in the SoC. This data is aggregated
> and the on-chip interconnect hardware is configured to the most
> appropriate power/performance profile.
>
> Use the API to configure the interconnects and request bandwidth
> between DDR and the display hardware (MDP port(s) and rotator
> downscaler).
>
> v2: update the path names to be consistent with dpu, handle the NULL
> path case, updated commit msg from Georgi.
>
> Signed-off-by: Georgi Djakov 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 97179bec8902..eeac429acf40 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>
> +#include 
>  #include 
>
>  #include "msm_drv.h"
> @@ -1050,6 +1051,19 @@ static const struct component_ops mdp5_ops = {
>
>  static int mdp5_dev_probe(struct platform_device *pdev)
>  {
> +   struct icc_path *path0 = of_icc_get(>dev, "mdp0-mem");
> +   struct icc_path *path1 = of_icc_get(>dev, "mdp1-mem");
> +   struct icc_path *path_rot = of_icc_get(>dev, "rotator-mem");
> +
> +   if (IS_ERR_OR_NULL(path0))
> +   return PTR_ERR_OR_ZERO(path0);

Umm, am I misunderstanding something?  It seems like of_icc_get()
returns NULL if the property doesn't exist.  Won't this be backwards
incompatible?  Existing DTs won't specify the property, and I don't
believe the property is supported on all targets.  Seems like we'll
break things by not calling the below component_add() if the
interconnect is not supported, specified, or the interconnect driver
is not compiled.

> +   icc_set_bw(path0, 0, MBps_to_icc(6400));
> +
> +   if (!IS_ERR_OR_NULL(path1))
> +   icc_set_bw(path1, 0, MBps_to_icc(6400));
> +   if (!IS_ERR_OR_NULL(path_rot))
> +   icc_set_bw(path_rot, 0, MBps_to_icc(6400));
> +
> DBG("");
> return component_add(>dev, _ops);
>  }
> --
> 2.20.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [PATCH 2/5] drm/msm/dpu: Integrate interconnect API in MDSS

[Sean Paul]

On Tue, Jun 18, 2019 at 01:24:10PM -0700, Rob Clark wrote:
> From: Jayant Shekhar 
> 
> The interconnect framework is designed to provide a
> standard kernel interface to control the settings of
> the interconnects on a SoC.
> 
> The interconnect API uses a consumer/provider-based model,
> where the providers are the interconnect buses and the
> consumers could be various drivers.
> 
> MDSS is one of the interconnect consumers which uses the
> interconnect APIs to get the path between endpoints and
> set its bandwidth requirement for the given interconnected
> path.
> 
> Changes in v2:
>   - Remove error log and unnecessary check (Jordan Crouse)
> 
> Changes in v3:
>   - Code clean involving variable name change, removal
> of extra paranthesis and variables (Matthias Kaehlcke)
> 
> Changes in v4:
>   - Add comments, spacings, tabs, proper port name
> and icc macro (Georgi Djakov)
> 
> Changes in v5:
>   - Commit text and parenthesis alignment (Georgi Djakov)
> 
> Changes in v6:
>   - Change to new icc_set API's (Doug Anderson)
> 
> Changes in v7:
>   - Fixed a typo
> 
> Changes in v8:
>   - Handle the of_icc_get() returning NULL case.  In practice
> icc_set_bw() will gracefully handle the case of a NULL path,
> but it's probably best for clarity to keep num_paths=0 in
> this case.
> 
> Signed-off-by: Sravanthi Kollukuduru 
> Signed-off-by: Jayant Shekhar 
> Signed-off-by: Rob Clark 
> Acked-by: Georgi Djakov 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 ++--
>  1 file changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> index 7316b4ab1b85..b1d0437ac7b6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -4,11 +4,15 @@
>   */
>  
>  #include "dpu_kms.h"
> +#include 
>  
>  #define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
>  
>  #define HW_INTR_STATUS   0x0010
>  
> +/* Max BW defined in KBps */
> +#define MAX_BW   680
> +
>  struct dpu_irq_controller {
>   unsigned long enabled_mask;
>   struct irq_domain *domain;
> @@ -21,8 +25,30 @@ struct dpu_mdss {
>   u32 hwversion;
>   struct dss_module_power mp;
>   struct dpu_irq_controller irq_controller;
> + struct icc_path *path[2];
> + u32 num_paths;
>  };
>  
> +static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
> + struct dpu_mdss *dpu_mdss)
> +{
> + struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
> + struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
> +
> + if (IS_ERR_OR_NULL(path0))
> + return PTR_ERR_OR_ZERO(path0);
> +
> + dpu_mdss->path[0] = path0;
> + dpu_mdss->num_paths = 1;
> +
> + if (!IS_ERR_OR_NULL(path1)) {
> + dpu_mdss->path[1] = path1;
> + dpu_mdss->num_paths++;
> + }
> +
> + return 0;
> +}
> +
>  static void dpu_mdss_irq(struct irq_desc *desc)
>  {
>   struct dpu_mdss *dpu_mdss = irq_desc_get_handler_data(desc);
> @@ -134,7 +160,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
>  {
>   struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
>   struct dss_module_power *mp = _mdss->mp;
> - int ret;
> + int ret, i;
> + u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
> +
> + for (i = 0; i < dpu_mdss->num_paths; i++)
> + icc_set_bw(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
>  
>   ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
>   if (ret)
> @@ -147,12 +177,15 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
>  {
>   struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
>   struct dss_module_power *mp = _mdss->mp;
> - int ret;
> + int ret, i;
>  
>   ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
>   if (ret)
>   DPU_ERROR("clock disable failed, ret:%d\n", ret);
>  
> + for (i = 0; i < dpu_mdss->num_paths; i++)
> + icc_set_bw(dpu_mdss->path[i], 0, 0);
> +
>   return ret;
>  }
>  
> @@ -163,6 +196,7 @@ static void dpu_mdss_destroy(struct drm_device *dev)
>   struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
>   struct dss_module_power *mp = _mdss->mp;
>   int irq;
> + int i;
>  
>   pm_runtime_suspend(dev->dev);
>   pm_runtime_disable(dev->dev);
> @@ -172,6 +206,9 @@ static void dpu_mdss_destroy(struct drm_device *dev)
>   msm_dss_put_clk(mp->clk_config, mp->num_clk);
>   devm_kfree(>dev, mp->clk_config);
>  
> + for (i = 0; i < dpu_mdss->num_paths; i++)
> + icc_put(dpu_mdss->path[i]);
> +
>   if (dpu_mdss->mmio)
>   devm_iounmap(>dev, dpu_mdss->mmio);
>   dpu_mdss->mmio = NULL;
> @@ -211,6 +248,10 @@ int 

Re: [PATCH 1/5] drm/msm/dpu: clean up references of DPU custom bus scaling

[Sean Paul]

On Tue, Jun 18, 2019 at 01:24:09PM -0700, Rob Clark wrote:
> From: Jayant Shekhar 
> 
> Since the upstream interconnect bus framework has landed
> upstream, the existing references of custom bus scaling
> needs to be cleaned up.
> 
> Changes in v2:
>   - Fixed build error due to partial clean up
> 
> Changes in v3:
>   - Condense multiple lines into a single line (Sean Paul)
> 
> Changes in v4-v7:
>   - None
> 
> Signed-off-by: Sravanthi Kollukuduru 
> Signed-off-by: Jayant Shekhar 
> Signed-off-by: Rob Clark 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 174 +++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |   4 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  11 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |  22 +--
>  4 files changed, 80 insertions(+), 131 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 9f20f397f77d..e231c37a9dbb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -77,7 +77,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
>   struct dpu_core_perf_params *perf)
>  {
>   struct dpu_crtc_state *dpu_cstate;
> - int i;
>  
>   if (!kms || !kms->catalog || !crtc || !state || !perf) {
>   DPU_ERROR("invalid parameters\n");
> @@ -88,35 +87,24 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
>   memset(perf, 0, sizeof(struct dpu_core_perf_params));
>  
>   if (!dpu_cstate->bw_control) {
> - for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
> - perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
> + perf->bw_ctl = kms->catalog->perf.max_bw_high *
>   1000ULL;
> - perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
> - }
> + perf->max_per_pipe_ib = perf->bw_ctl;
>   perf->core_clk_rate = kms->perf.max_core_clk_rate;
>   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
> - for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
> - perf->bw_ctl[i] = 0;
> - perf->max_per_pipe_ib[i] = 0;
> - }
> + perf->bw_ctl = 0;
> + perf->max_per_pipe_ib = 0;
>   perf->core_clk_rate = 0;
>   } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
> - for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
> - perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
> - perf->max_per_pipe_ib[i] = kms->perf.fix_core_ib_vote;
> - }
> + perf->bw_ctl = kms->perf.fix_core_ab_vote;
> + perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
>   perf->core_clk_rate = kms->perf.fix_core_clk_rate;
>   }
>  
>   DPU_DEBUG(
> - "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu llcc_ib=%llu 
> llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
> + "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
>   crtc->base.id, perf->core_clk_rate,
> - perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
> - perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
> - perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
> - perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
> - perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_EBI],
> - perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_EBI]);
> + perf->max_per_pipe_ib, perf->bw_ctl);
>  }
>  
>  int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
> @@ -129,7 +117,6 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
>   struct dpu_crtc_state *dpu_cstate;
>   struct drm_crtc *tmp_crtc;
>   struct dpu_kms *kms;
> - int i;
>  
>   if (!crtc || !state) {
>   DPU_ERROR("invalid crtc\n");
> @@ -151,31 +138,25 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
>   /* obtain new values */
>   _dpu_core_perf_calc_crtc(kms, crtc, state, _cstate->new_perf);
>  
> - for (i = DPU_CORE_PERF_DATA_BUS_ID_MNOC;
> - i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
> - bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
> - curr_client_type = dpu_crtc_get_client_type(crtc);
> + bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl;
> + curr_client_type = dpu_crtc_get_client_type(crtc);
>  
> - drm_for_each_crtc(tmp_crtc, crtc->dev) {
> - if (tmp_crtc->enabled &&
> - (dpu_crtc_get_client_type(tmp_crtc) ==
> - curr_client_type) &&
> - (tmp_crtc != crtc)) {
> - struct dpu_crtc_state 

[PATCH 5/5] drm/msm/mdp5: Use the interconnect API

[Rob Clark]

From: Georgi Djakov 

The interconnect API provides an interface for consumer drivers to
express their bandwidth needs in the SoC. This data is aggregated
and the on-chip interconnect hardware is configured to the most
appropriate power/performance profile.

Use the API to configure the interconnects and request bandwidth
between DDR and the display hardware (MDP port(s) and rotator
downscaler).

v2: update the path names to be consistent with dpu, handle the NULL
path case, updated commit msg from Georgi.

Signed-off-by: Georgi Djakov 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..eeac429acf40 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 
 #include "msm_drv.h"
@@ -1050,6 +1051,19 @@ static const struct component_ops mdp5_ops = {
 
 static int mdp5_dev_probe(struct platform_device *pdev)
 {
+   struct icc_path *path0 = of_icc_get(>dev, "mdp0-mem");
+   struct icc_path *path1 = of_icc_get(>dev, "mdp1-mem");
+   struct icc_path *path_rot = of_icc_get(>dev, "rotator-mem");
+
+   if (IS_ERR_OR_NULL(path0))
+   return PTR_ERR_OR_ZERO(path0);
+   icc_set_bw(path0, 0, MBps_to_icc(6400));
+
+   if (!IS_ERR_OR_NULL(path1))
+   icc_set_bw(path1, 0, MBps_to_icc(6400));
+   if (!IS_ERR_OR_NULL(path_rot))
+   icc_set_bw(path_rot, 0, MBps_to_icc(6400));
+
DBG("");
return component_add(>dev, _ops);
 }
-- 
2.20.1

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

[PATCH 1/5] drm/msm/dpu: clean up references of DPU custom bus scaling

[Rob Clark]

From: Jayant Shekhar 

Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.

Changes in v2:
- Fixed build error due to partial clean up

Changes in v3:
- Condense multiple lines into a single line (Sean Paul)

Changes in v4-v7:
- None

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 174 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  11 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |  22 +--
 4 files changed, 80 insertions(+), 131 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 9f20f397f77d..e231c37a9dbb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -77,7 +77,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
struct dpu_core_perf_params *perf)
 {
struct dpu_crtc_state *dpu_cstate;
-   int i;
 
if (!kms || !kms->catalog || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
@@ -88,35 +87,24 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
memset(perf, 0, sizeof(struct dpu_core_perf_params));
 
if (!dpu_cstate->bw_control) {
-   for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
+   perf->bw_ctl = kms->catalog->perf.max_bw_high *
1000ULL;
-   perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
-   }
+   perf->max_per_pipe_ib = perf->bw_ctl;
perf->core_clk_rate = kms->perf.max_core_clk_rate;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-   for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = 0;
-   perf->max_per_pipe_ib[i] = 0;
-   }
+   perf->bw_ctl = 0;
+   perf->max_per_pipe_ib = 0;
perf->core_clk_rate = 0;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
-   for (i = 0; i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
-   perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
-   perf->max_per_pipe_ib[i] = kms->perf.fix_core_ib_vote;
-   }
+   perf->bw_ctl = kms->perf.fix_core_ab_vote;
+   perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
}
 
DPU_DEBUG(
-   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu llcc_ib=%llu 
llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
+   "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
-   perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
-   perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_MNOC],
-   perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
-   perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_LLCC],
-   perf->max_per_pipe_ib[DPU_CORE_PERF_DATA_BUS_ID_EBI],
-   perf->bw_ctl[DPU_CORE_PERF_DATA_BUS_ID_EBI]);
+   perf->max_per_pipe_ib, perf->bw_ctl);
 }
 
 int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -129,7 +117,6 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
struct dpu_crtc_state *dpu_cstate;
struct drm_crtc *tmp_crtc;
struct dpu_kms *kms;
-   int i;
 
if (!crtc || !state) {
DPU_ERROR("invalid crtc\n");
@@ -151,31 +138,25 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
/* obtain new values */
_dpu_core_perf_calc_crtc(kms, crtc, state, _cstate->new_perf);
 
-   for (i = DPU_CORE_PERF_DATA_BUS_ID_MNOC;
-   i < DPU_CORE_PERF_DATA_BUS_ID_MAX; i++) {
-   bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
-   curr_client_type = dpu_crtc_get_client_type(crtc);
+   bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl;
+   curr_client_type = dpu_crtc_get_client_type(crtc);
 
-   drm_for_each_crtc(tmp_crtc, crtc->dev) {
-   if (tmp_crtc->enabled &&
-   (dpu_crtc_get_client_type(tmp_crtc) ==
-   curr_client_type) &&
-   (tmp_crtc != crtc)) {
-   struct dpu_crtc_state *tmp_cstate =
-   to_dpu_crtc_state(tmp_crtc->state);
-
-   DPU_DEBUG("crtc:%d bw:%llu ctrl:%d\n",
-

[PATCH 4/5] drm/msm/dpu: add icc voting in dpu_mdss_init

[Rob Clark]

From: Abhinav Kumar 

dpu_mdss_destroy() can get called not just from
msm_drm_uninit() but also from msm_drm_bind() in case
of any failures.

dpu_mdss_destroy() removes the icc voting by calling
icc_put. This could accidentally remove the voting
done by pm_runtime_enable.

To make the voting balanced add a minimum vote in
dpu_mdss_init() to avoid any unclocked access.

This change depends on the following patch which
introduces interconnect binding to MDSS driver:

https://patchwork.codeaurora.org/patch/708155/

Signed-off-by: Abhinav Kumar 
Reviewed-by: Sean Paul 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index b1d0437ac7b6..986915bbbc02 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -49,6 +49,16 @@ static int dpu_mdss_parse_data_bus_icc_path(struct 
drm_device *dev,
return 0;
 }
 
+static void dpu_mdss_icc_request_bw(struct msm_mdss *mdss)
+{
+   struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
+   int i;
+   u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
+
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_set_bw(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
+}
+
 static void dpu_mdss_irq(struct irq_desc *desc)
 {
struct dpu_mdss *dpu_mdss = irq_desc_get_handler_data(desc);
@@ -160,11 +170,9 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
 {
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
-   int ret, i;
-   u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
+   int ret;
 
-   for (i = 0; i < dpu_mdss->num_paths; i++)
-   icc_set_bw(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
+   dpu_mdss_icc_request_bw(mdss);
 
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
if (ret)
@@ -277,6 +285,8 @@ int dpu_mdss_init(struct drm_device *dev)
 
pm_runtime_enable(dev->dev);
 
+   dpu_mdss_icc_request_bw(priv->mdss);
+
pm_runtime_get_sync(dev->dev);
dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio);
pm_runtime_put_sync(dev->dev);
-- 
2.20.1

[PATCH 2/5] drm/msm/dpu: Integrate interconnect API in MDSS

[Rob Clark]

From: Jayant Shekhar 

The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.

The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.

MDSS is one of the interconnect consumers which uses the
interconnect APIs to get the path between endpoints and
set its bandwidth requirement for the given interconnected
path.

Changes in v2:
- Remove error log and unnecessary check (Jordan Crouse)

Changes in v3:
- Code clean involving variable name change, removal
  of extra paranthesis and variables (Matthias Kaehlcke)

Changes in v4:
- Add comments, spacings, tabs, proper port name
  and icc macro (Georgi Djakov)

Changes in v5:
- Commit text and parenthesis alignment (Georgi Djakov)

Changes in v6:
- Change to new icc_set API's (Doug Anderson)

Changes in v7:
- Fixed a typo

Changes in v8:
- Handle the of_icc_get() returning NULL case.  In practice
  icc_set_bw() will gracefully handle the case of a NULL path,
  but it's probably best for clarity to keep num_paths=0 in
  this case.

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
Signed-off-by: Rob Clark 
Acked-by: Georgi Djakov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 ++--
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 7316b4ab1b85..b1d0437ac7b6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -4,11 +4,15 @@
  */
 
 #include "dpu_kms.h"
+#include 
 
 #define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
 
 #define HW_INTR_STATUS 0x0010
 
+/* Max BW defined in KBps */
+#define MAX_BW 680
+
 struct dpu_irq_controller {
unsigned long enabled_mask;
struct irq_domain *domain;
@@ -21,8 +25,30 @@ struct dpu_mdss {
u32 hwversion;
struct dss_module_power mp;
struct dpu_irq_controller irq_controller;
+   struct icc_path *path[2];
+   u32 num_paths;
 };
 
+static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
+   struct dpu_mdss *dpu_mdss)
+{
+   struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
+   struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
+
+   if (IS_ERR_OR_NULL(path0))
+   return PTR_ERR_OR_ZERO(path0);
+
+   dpu_mdss->path[0] = path0;
+   dpu_mdss->num_paths = 1;
+
+   if (!IS_ERR_OR_NULL(path1)) {
+   dpu_mdss->path[1] = path1;
+   dpu_mdss->num_paths++;
+   }
+
+   return 0;
+}
+
 static void dpu_mdss_irq(struct irq_desc *desc)
 {
struct dpu_mdss *dpu_mdss = irq_desc_get_handler_data(desc);
@@ -134,7 +160,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
 {
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
-   int ret;
+   int ret, i;
+   u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
+
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_set_bw(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
 
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
if (ret)
@@ -147,12 +177,15 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
 {
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
-   int ret;
+   int ret, i;
 
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (ret)
DPU_ERROR("clock disable failed, ret:%d\n", ret);
 
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_set_bw(dpu_mdss->path[i], 0, 0);
+
return ret;
 }
 
@@ -163,6 +196,7 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = _mdss->mp;
int irq;
+   int i;
 
pm_runtime_suspend(dev->dev);
pm_runtime_disable(dev->dev);
@@ -172,6 +206,9 @@ static void dpu_mdss_destroy(struct drm_device *dev)
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
 
+   for (i = 0; i < dpu_mdss->num_paths; i++)
+   icc_put(dpu_mdss->path[i]);
+
if (dpu_mdss->mmio)
devm_iounmap(>dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
@@ -211,6 +248,10 @@ int dpu_mdss_init(struct drm_device *dev)
}
dpu_mdss->mmio_len = resource_size(res);
 
+   ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
+   if (ret)
+   return ret;
+
mp = _mdss->mp;
ret = msm_dss_parse_clock(pdev, mp);
  

[PATCH 3/5] dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on SDM845

[Rob Clark]

From: Jayant Shekhar 

Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.

Changes in v2:
- None

Changes in v3:
- Remove common property definitions (Rob Herring)

Changes in v4:
- Use port macros and change port string names (Georgi Djakov)

Changes in v5-v7:
- None

Signed-off-by: Sravanthi Kollukuduru 
Signed-off-by: Jayant Shekhar 
Reviewed-by: Rob Herring 
Signed-off-by: Rob Clark 
---
 Documentation/devicetree/bindings/display/msm/dpu.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index ad2e8830324e..a61dd40f3792 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -28,6 +28,11 @@ Required properties:
 - #address-cells: number of address cells for the MDSS children. Should be 1.
 - #size-cells: Should be 1.
 - ranges: parent bus address space is the same as the child bus address space.
+- interconnects : interconnect path specifier for MDSS according to
+  Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be
+  2 paths corresponding to 2 AXI ports.
+- interconnect-names : MDSS will have 2 port names to differentiate between the
+  2 interconnect paths defined with interconnect specifier.
 
 Optional properties:
 - assigned-clocks: list of clock specifiers for clocks needing rate assignment
@@ -86,6 +91,11 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
 
+   interconnects = <_hlos MASTER_MDP0 _hlos SLAVE_EBI1>,
+   <_hlos MASTER_MDP1 _hlos SLAVE_EBI1>;
+
+   interconnect-names = "mdp0-mem", "mdp1-mem";
+
iommus = <_iommu 0>;
 
#address-cells = <2>;
-- 
2.20.1

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

[PATCH 0/5] drm/msm: mdp5+dpu interconnect support

[Rob Clark]

From: Rob Clark 

Most of this is a resend of things that have already been posted to
list.  I've rebased the DPU patches, which was somewhat conflicty due to
other changes and refactoring in the DPU code.

Abhinav Kumar (1):
  drm/msm/dpu: add icc voting in dpu_mdss_init

Georgi Djakov (1):
  drm/msm/mdp5: Use the interconnect API

Jayant Shekhar (3):
  drm/msm/dpu: clean up references of DPU custom bus scaling
  drm/msm/dpu: Integrate interconnect API in MDSS
  dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on
SDM845

 .../devicetree/bindings/display/msm/dpu.txt   |  10 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 174 +++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  11 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  |  57 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |  22 +--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  14 ++
 7 files changed, 158 insertions(+), 134 deletions(-)

-- 
2.20.1

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

Re: [PATCH] drm: Permit video-buffers writecombine mapping for MIPS

[Sean Paul]

On Mon, Jun 17, 2019 at 04:47:30PM +0300, Serge Semin wrote:
> Hello folks,
> 
> Any updates of this patch status? It has been here for about two months.
> 

Sorry for the mixup, looks like this one just fell through the cracks. I've
applied it to drm-misc-next with the attached Ack and Review.

Sean


> Regards,
> -Sergey
> 
> On Tue, Apr 23, 2019 at 03:31:22PM +0300, Serge Semin wrote:
> > Since commit 4b050ba7a66c ("MIPS: pgtable.h: Implement the
> > pgprot_writecombine function for MIPS") and commit c4687b15a848 ("MIPS: Fix
> > definition of pgprot_writecombine()") write-combine vma mapping is
> > available to be used by kernel subsystems for MIPS. In particular the
> > uncached accelerated attribute is requested to be set by ioremap_wc()
> > method and by generic PCI memory pages/ranges mapping methods. The same
> > is done by the drm_io_prot()/ttm_io_prot() functions in case if
> > write-combine flag is set for vma's passed for mapping. But for some
> > reason the pgprot_writecombine() method calling is ifdefed to be a
> > platform-specific with MIPS system being marked as lacking of one. At the
> > very least it doesn't reflect the current MIPS platform implementation.
> > So in order to improve the DRM subsystem performance on MIPS with UCA
> > mapping enabled, we need to have pgprot_writecombine() called for buffers,
> > which need store operations being combined. In case if particular MIPS
> > chip doesn't support the UCA attribute, the mapping will fall back to
> > noncached.
> > 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: James Hogan 
> > Signed-off-by: Vadim V. Vlasov 
> > Signed-off-by: Serge Semin 
> > ---
> >  drivers/gpu/drm/drm_vm.c  | 5 +++--
> >  drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> > index c3301046dfaa..50178dc64060 100644
> > --- a/drivers/gpu/drm/drm_vm.c
> > +++ b/drivers/gpu/drm/drm_vm.c
> > @@ -62,7 +62,8 @@ static pgprot_t drm_io_prot(struct drm_local_map *map,
> > /* We don't want graphics memory to be mapped encrypted */
> > tmp = pgprot_decrypted(tmp);
> >  
> > -#if defined(__i386__) || defined(__x86_64__) || defined(__powerpc__)
> > +#if defined(__i386__) || defined(__x86_64__) || defined(__powerpc__) || \
> > +defined(__mips__)
> > if (map->type == _DRM_REGISTERS && !(map->flags & _DRM_WRITE_COMBINING))
> > tmp = pgprot_noncached(tmp);
> > else
> > @@ -73,7 +74,7 @@ static pgprot_t drm_io_prot(struct drm_local_map *map,
> > tmp = pgprot_writecombine(tmp);
> > else
> > tmp = pgprot_noncached(tmp);
> > -#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
> > +#elif defined(__sparc__) || defined(__arm__)
> > tmp = pgprot_noncached(tmp);
> >  #endif
> > return tmp;
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > index 895d77d799e4..9f918b992f7e 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -539,13 +539,13 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
> > tmp)
> > tmp = pgprot_noncached(tmp);
> >  #endif
> >  #if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \
> > -defined(__powerpc__)
> > +defined(__powerpc__) || defined(__mips__)
> > if (caching_flags & TTM_PL_FLAG_WC)
> > tmp = pgprot_writecombine(tmp);
> > else
> > tmp = pgprot_noncached(tmp);
> >  #endif
> > -#if defined(__sparc__) || defined(__mips__)
> > +#if defined(__sparc__)
> > tmp = pgprot_noncached(tmp);
> >  #endif
> > return tmp;
> > -- 
> > 2.21.0
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: dev_pagemap related cleanups v2

[Dan Williams]

On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig  wrote:
>
> Hi Dan, Jérôme and Jason,
>
> below is a series that cleans up the dev_pagemap interface so that
> it is more easily usable, which removes the need to wrap it in hmm
> and thus allowing to kill a lot of code
>
> Note: this series is on top of the rdma/hmm branch + the dev_pagemap
> releas fix series from Dan that went into 5.2-rc5.
>
> Git tree:
>
> git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2
>
> Gitweb:
>
> 
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devmem-cleanup.2
>
> Changes since v1:
>  - rebase
>  - also switch p2pdma to the internal refcount
>  - add type checking for pgmap->type
>  - rename the migrate method to migrate_to_ram
>  - cleanup the altmap_valid flag
>  - various tidbits from the reviews

Attached is my incremental fixups on top of this series, with those
integrated you can add:

Tested-by: Dan Williams 

...to the patches that touch kernel/memremap.c, drivers/dax, and drivers/nvdimm.

You can also add:

Reviewed-by: Dan Williams 

...for the series.
diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index a9d7c90ecf1e..1af823b2fe6b 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -428,6 +428,7 @@ int dev_dax_probe(struct device *dev)
 		return -EBUSY;
 	}
 
+	dev_dax->pgmap.type = MEMORY_DEVICE_DEVDAX;
 	addr = devm_memremap_pages(dev, _dax->pgmap);
 	if (IS_ERR(addr))
 		return PTR_ERR(addr);
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 54500798f23a..57d3a6c3ac70 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -118,4 +118,15 @@ config NVDIMM_KEYS
 	depends on ENCRYPTED_KEYS
 	depends on (LIBNVDIMM=ENCRYPTED_KEYS) || LIBNVDIMM=m
 
+config NVDIMM_TEST_BUILD
+	bool "Build the unit test core"
+	depends on COMPILE_TEST
+	default COMPILE_TEST
+	help
+	  Build the core of the unit test infrastructure.  The result of
+	  this build is non-functional for unit test execution, but it
+	  otherwise helps catch build errors induced by changes to the
+	  core devm_memremap_pages() implementation and other
+	  infrastructure.
+
 endif
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 6f2a088afad6..40080c120363 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -28,3 +28,7 @@ libnvdimm-$(CONFIG_BTT) += btt_devs.o
 libnvdimm-$(CONFIG_NVDIMM_PFN) += pfn_devs.o
 libnvdimm-$(CONFIG_NVDIMM_DAX) += dax_devs.o
 libnvdimm-$(CONFIG_NVDIMM_KEYS) += security.o
+
+TOOLS := ../../tools
+TEST_SRC := $(TOOLS)/testing/nvdimm/test
+obj-$(CONFIG_NVDIMM_TEST_BUILD) := $(TEST_SRC)/iomap.o
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 7e0f072ddce7..470de68dabd6 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -55,12 +55,19 @@ struct vmem_altmap {
  * MEMORY_DEVICE_PCI_P2PDMA:
  * Device memory residing in a PCI BAR intended for use with Peer-to-Peer
  * transactions.
+ *
+ * MEMORY_DEVICE_DEVDAX:
+ * Host memory that has similar access semantics as System RAM i.e. DMA
+ * coherent and supports page pinning. In contrast to
+ * MEMORY_DEVICE_FS_DAX, this memory is access via a device-dax
+ * character device.
  */
 enum memory_type {
 	MEMORY_DEVICE_PRIVATE = 1,
 	MEMORY_DEVICE_PUBLIC,
 	MEMORY_DEVICE_FS_DAX,
 	MEMORY_DEVICE_PCI_P2PDMA,
+	MEMORY_DEVICE_DEVDAX,
 };
 
 struct dev_pagemap_ops {
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 60693a1e8e92..52b4968e62cd 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -173,6 +173,7 @@ void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 	};
 	pgprot_t pgprot = PAGE_KERNEL;
 	int error, nid, is_ram;
+	bool get_ops = true;
 
 	switch (pgmap->type) {
 	case MEMORY_DEVICE_PRIVATE:
@@ -199,6 +200,8 @@ void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 		}
 		break;
 	case MEMORY_DEVICE_PCI_P2PDMA:
+	case MEMORY_DEVICE_DEVDAX:
+		get_ops = false;
 		break;
 	default:
 		WARN(1, "Invalid pgmap type %d\n", pgmap->type);
@@ -222,7 +225,7 @@ void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 		}
 	}
 
-	if (pgmap->type != MEMORY_DEVICE_PCI_P2PDMA) {
+	if (get_ops) {
 		error = dev_pagemap_get_ops(dev, pgmap);
 		if (error)
 			return ERR_PTR(error);
diff --git a/tools/testing/nvdimm/test/iomap.c b/tools/testing/nvdimm/test/iomap.c
index 8cd9b9873a7f..9019dd8afbc1 100644
--- a/tools/testing/nvdimm/test/iomap.c
+++ b/tools/testing/nvdimm/test/iomap.c
@@ -106,7 +106,7 @@ EXPORT_SYMBOL(__wrap_devm_memremap);
 
 static void nfit_test_kill(void *_pgmap)
 {
-	WARN_ON(!pgmap || !pgmap->ref)
+	struct dev_pagemap *pgmap = _pgmap;
 
 	if (pgmap->ops && pgmap->ops->kill)
 		pgmap->ops->kill(pgmap);
@@ -121,20 +121,45 @@ static void nfit_test_kill(void *_pgmap)
 	}
 }
 
+static void dev_pagemap_percpu_release(struct percpu_ref *ref)
+{
+	struct dev_pagemap *pgmap =
+		container_of(ref, struct dev_pagemap, internal_ref);
+
+	complete(>done);
+}
+
 void 

Re: [PATCH 15/25] device-dax: use the dev_pagemap internal refcount

[Dan Williams]

On Mon, Jun 17, 2019 at 5:28 AM Christoph Hellwig  wrote:
>
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/dax/dax-private.h |  4 
>  drivers/dax/device.c  | 43 ---
>  2 files changed, 47 deletions(-)

This needs the mock devm_memremap_pages() to setup the common
percpu_ref. Incremental patch attached:
From 875e71489c8485448a5b7df2d8a8b2ed77d2b555 Mon Sep 17 00:00:00 2001
From: Dan Williams 
Date: Tue, 18 Jun 2019 11:58:24 -0700
Subject: [PATCH] tools/testing/nvdimm: Support the 'internal' ref of
 dev_pagemap

For users of the common percpu-ref implementation, like device-dax,
arrange for nfit_test to initialize the common parameters.

Signed-off-by: Dan Williams 
---
 tools/testing/nvdimm/test/iomap.c | 41 ---
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/tools/testing/nvdimm/test/iomap.c b/tools/testing/nvdimm/test/iomap.c
index 3bc1c16c4ef9..9019dd8afbc1 100644
--- a/tools/testing/nvdimm/test/iomap.c
+++ b/tools/testing/nvdimm/test/iomap.c
@@ -108,8 +108,6 @@ static void nfit_test_kill(void *_pgmap)
 {
 	struct dev_pagemap *pgmap = _pgmap;
 
-	WARN_ON(!pgmap || !pgmap->ref);
-
 	if (pgmap->ops && pgmap->ops->kill)
 		pgmap->ops->kill(pgmap);
 	else
@@ -123,20 +121,45 @@ static void nfit_test_kill(void *_pgmap)
 	}
 }
 
+static void dev_pagemap_percpu_release(struct percpu_ref *ref)
+{
+	struct dev_pagemap *pgmap =
+		container_of(ref, struct dev_pagemap, internal_ref);
+
+	complete(>done);
+}
+
 void *__wrap_devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 {
+	int error;
 	resource_size_t offset = pgmap->res.start;
 	struct nfit_test_resource *nfit_res = get_nfit_res(offset);
 
-	if (nfit_res) {
-		int rc;
+	if (!nfit_res)
+		return devm_memremap_pages(dev, pgmap);
 
-		rc = devm_add_action_or_reset(dev, nfit_test_kill, pgmap);
-		if (rc)
-			return ERR_PTR(rc);
-		return nfit_res->buf + offset - nfit_res->res.start;
+	pgmap->dev = dev;
+	if (!pgmap->ref) {
+		if (pgmap->ops && (pgmap->ops->kill || pgmap->ops->cleanup))
+			return ERR_PTR(-EINVAL);
+
+		init_completion(>done);
+		error = percpu_ref_init(>internal_ref,
+dev_pagemap_percpu_release, 0, GFP_KERNEL);
+		if (error)
+			return ERR_PTR(error);
+		pgmap->ref = >internal_ref;
+	} else {
+		if (!pgmap->ops || !pgmap->ops->kill || !pgmap->ops->cleanup) {
+			WARN(1, "Missing reference count teardown definition\n");
+			return ERR_PTR(-EINVAL);
+		}
 	}
-	return devm_memremap_pages(dev, pgmap);
+
+	error = devm_add_action_or_reset(dev, nfit_test_kill, pgmap);
+	if (error)
+		return ERR_PTR(error);
+	return nfit_res->buf + offset - nfit_res->res.start;
 }
 EXPORT_SYMBOL_GPL(__wrap_devm_memremap_pages);
 
-- 
2.20.1

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

Re: [PATCH v2] drm/edid: parse CEA blocks embedded in DisplayID

[Dave Airlie]

On Fri, 14 Jun 2019 at 03:52, Andres Rodriguez  wrote:
>
> DisplayID blocks allow embedding of CEA blocks. The payloads are
> identical to traditional top level CEA extension blocks, but the header
> is slightly different.
>
> This change allows the CEA parser to find a CEA block inside a DisplayID
> block. Additionally, it adds support for parsing the embedded CTA
> header. No further changes are necessary due to payload parity.
>
> This change enables audio support for the Valve Index HMD.
>
> Signed-off-by: Andres Rodriguez 
> ---
>
> v2: Review feedback from Jani.
>
>  drivers/gpu/drm/drm_edid.c  | 75 +
>  include/drm/drm_displayid.h | 10 +
>  2 files changed, 77 insertions(+), 8 deletions(-)

I think this is fine, since you might want to cc stable apart from the
comment below.

however a follow up patch to use for_each_displayid_db in a few more
places might be good.

>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 649cfd8b4200..8ecd7f70825d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1339,6 +1339,8 @@ MODULE_PARM_DESC(edid_fixup,
>
>  static void drm_get_displayid(struct drm_connector *connector,
>   struct edid *edid);
> +static u8 *drm_find_displayid_extension(const struct edid *edid);

Instead of adding that here, i think you can move
drm_find_cea_extension down below it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3

[Krzysztof Kozlowski]

On Tue, 18 Jun 2019 at 19:42, Joseph Kogut  wrote:
> > >
> > > > > + reg = <0x1180 0x5000>;
> > > > > + interrupts = ,
> > > > > +  ,
> > > > > +  ;
> > > > > + interrupt-names = "job", "mmu", "gpu";
> > > > > + clocks = < CLK_G3D>;
> > > > > + mali-supply = <_reg>;
> > > >
> > > > Please check if always-on property could be removed from buck4.
> > >
> > > I've checked, and this property can be removed safely.
> > >
> > > > Also, what about LDO27? It should be used as well (maybe through
> > > > vendor-specific properties which would justify the need of new vendor
> > > > compatible).
> > > >
> > >
> > > I'm unsure how LDO27 is used, can you elaborate?
> >
> > It is supplying the VDD_G3DS (with a note "SRAM power"). I do not have
> > any more data on it. However I did not check in vendor kernel for it.
> >
>
> After checking (a fork of) the vendor sources [1], it seems to me that
> this regulator is used for memory voltage related to Samsung's
> Adaptive Supply Voltage, for which there is a pending patchset [2].
>
> This seems to me to be out of the scope of this patchset, could you confirm?
>
> [1] 
> https://github.com/kumajaya/android_kernel_samsung_universal5422/blob/ad41104d43e6470f8d4880d65b259dc7b903cc0d/arch/arm/mach-exynos/asv-exynos5422.c#L1052
> [2] https://lwn.net/Articles/784958/

Hi,

Indeed the vendor sources suggest that voltage scaling of this
regulator depends on ASV, not on frequency. However still the
regulator is there in the hardware so it should be in the bindings as
well (specific to Exynos). I guess the driver should also enable it
but this is separate topic (adding per-platform quirks to Panfrost
driver). Putting it to bindings also follows advice from line 12:
https://elixir.bootlin.com/linux/v5.2-rc5/source/Documentation/devicetree/bindings/writing-bindings.txt#L12

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

[RFT 09/10] ARM: exynos_defconfig: Enable Panfrost and LIMA drivers

[Krzysztof Kozlowski]

Enable support for Mali GPU with Panfrost and LIMA drivers.  Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/exynos_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 8d08eed99aa1..f140532ddca7 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -212,6 +212,8 @@ CONFIG_DRM_NXP_PTN3460=y
 CONFIG_DRM_PARADE_PS8622=y
 CONFIG_DRM_SII9234=y
 CONFIG_DRM_TOSHIBA_TC358764=y
+CONFIG_DRM_LIMA=y
+CONFIG_DRM_PANFROST=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_PWM=y
@@ -284,7 +286,6 @@ CONFIG_CROS_EC_SPI=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_COMMON_CLK_S2MPS11=y
 CONFIG_EXYNOS_IOMMU=y
-CONFIG_PM_DEVFREQ=y
 CONFIG_DEVFREQ_GOV_PERFORMANCE=y
 CONFIG_DEVFREQ_GOV_POWERSAVE=y
 CONFIG_DEVFREQ_GOV_USERSPACE=y
-- 
2.17.1

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

[RFT 08/10] ARM: multi_v7_defconfig: Enable Panfrost and LIMA drivers

[Krzysztof Kozlowski]

Enable support for Mali GPU with Panfrost and LIMA drivers.  Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).

As Mali GPU is quite popular among ARM vendors, other platforms will
benefit as well.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/configs/multi_v7_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 6b748f214eae..268161911fc9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -656,6 +656,8 @@ CONFIG_DRM_VC4=m
 CONFIG_DRM_ETNAVIV=m
 CONFIG_DRM_MXSFB=m
 CONFIG_DRM_PL111=m
+CONFIG_DRM_LIMA=m
+CONFIG_DRM_PANFROST=m
 CONFIG_FB_EFI=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SH_MOBILE_LCDC=y
@@ -940,7 +942,6 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_PM_DEVFREQ=y
 CONFIG_ARM_TEGRA_DEVFREQ=m
 CONFIG_TI_AEMIF=y
 CONFIG_IIO=y
-- 
2.17.1

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

[RFT 05/10] ARM: dts: exynos: Add GPU/Mali 400 node to Exynos4

[Krzysztof Kozlowski]

Add nodes for GPU (Mali 400) to Exynos4210 and Exynos4412.  Describe the
GPU as much as possible however still few elements are missing:
1. Exynos4210 bus clock is not described in hardware manual therefore
   the IP gate clock was provided,
2. Exynos4412: Not sure what to do with CLK_G3D clock responsible for
   gating entire IP block (it is now being disabled as unused),
3. Regulator supplies on Trats board.

Limited testing on Odroid U3 (Exynos4412).

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi| 29 +
 arch/arm/boot/dts/exynos4210-origen.dts   |  5 +++
 arch/arm/boot/dts/exynos4210-trats.dts|  4 +++
 .../boot/dts/exynos4210-universal_c210.dts|  5 +++
 arch/arm/boot/dts/exynos4210.dtsi | 28 
 .../boot/dts/exynos4412-itop-scp-core.dtsi|  5 +++
 arch/arm/boot/dts/exynos4412-midas.dtsi   |  5 +++
 .../boot/dts/exynos4412-odroid-common.dtsi|  5 +++
 arch/arm/boot/dts/exynos4412.dtsi | 32 +++
 9 files changed, 118 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 36ccf227434d..112a4fb8e5dd 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -51,6 +51,35 @@
serial3 = _3;
};
 
+   gpu: gpu@1300 {
+   compatible = "samsung,exynos3250-mali", "arm,mali-400";
+   reg = <0x1300 0x1>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "gp",
+ "gpmmu",
+ "pp0",
+ "ppmmu0",
+ "pp1",
+ "ppmmu1",
+ "pp2",
+ "ppmmu2",
+ "pp3",
+ "ppmmu3",
+ "pmu";
+   power-domains = <_g3d>;
+   status = "disabled";
+   };
+
pmu: pmu {
compatible = "arm,cortex-a9-pmu";
interrupt-parent = <>;
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index 36b1edea254a..0d1e1a9c2f6e 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -132,6 +132,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
  {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 6882480dbaf7..7c39dd1c4d3a 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -239,6 +239,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index bf092e97e14f..82a8b5449978 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -262,6 +262,11 @@
};
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
  {
hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index ea0e043cd2b4..3a1cd4be9ca1 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -449,6 +449,34 @@
samsung,lcd-wb;
 };
 
+ {
+   /*
+* CLK_G3D is not actually bus clock but a IP-level clock.
+* The bus clock is not described in hardware manual.
+*/
+   clocks = < CLK_G3D>,
+< CLK_SCLK_G3D>;
+   clock-names = "bus", "core";
+   operating-points-v2 = <_opp_table>;
+
+   gpu_opp_table: opp_table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <95>;
+   };
+   opp-26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <105>;
+   };
+   opp-33000 {
+   opp-hz = /bits/ 64 <33000>;
+   opp-microvolt = <110>;
+   };
+   };
+};
+
  {
power-domains = <_lcd0>;
 };
diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi 

[RFT 10/10] arm64: defconfig: Enable Panfrost driver

[Krzysztof Kozlowski]

Enable support for Mali GPU with Panfrost driver, e.g. for Exynos5433
and Exynos7 (having Mali T760).

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/configs/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6b4f5cf23324..972b17239f13 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -517,6 +517,7 @@ CONFIG_DRM_HISI_HIBMC=m
 CONFIG_DRM_HISI_KIRIN=m
 CONFIG_DRM_MESON=m
 CONFIG_DRM_PL111=m
+CONFIG_DRM_PANFROST=m
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_BACKLIGHT_GENERIC=m
@@ -717,7 +718,6 @@ CONFIG_ARCH_TEGRA_194_SOC=y
 CONFIG_ARCH_K3_AM6_SOC=y
 CONFIG_SOC_TI=y
 CONFIG_TI_SCI_PM_DOMAINS=y
-CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
 CONFIG_EXTCON_USB_GPIO=y
 CONFIG_EXTCON_USBC_CROS_EC=y
 CONFIG_MEMORY=y
-- 
2.17.1

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

[RFT 07/10] arm64: dts: exynos: Add GPU/Mali T760 node to Exynos7

[Krzysztof Kozlowski]

Add nodes for GPU (Mali T760) to Exynos7.  Current support for Exynos7
misses a lot, including proper clocks, power domains, frequency and
voltage scaling and cooling.  However this still can provide basic GPU
description.  Not tested on HW.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  5 +
 arch/arm64/boot/dts/exynos/exynos7.dtsi | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 00dd89b92b42..080e0f56e108 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -59,6 +59,11 @@
clock-frequency = <2400>;
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
 _2 {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 077d23478901..bcb9d8cee267 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -78,6 +78,17 @@
};
};
 
+   gpu: gpu@14ac {
+   compatible = "samsung,exynos5433-mali", "arm,mali-t760";
+   reg = <0x14ac 0x5000>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   status = "disabled";
+   /* TODO: operating points for DVFS, cooling device */
+   };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
-- 
2.17.1

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

[RFT 06/10] arm64: dts: exynos: Add GPU/Mali T760 node to Exynos5433

[Krzysztof Kozlowski]

Add nodes for GPU (Mali T760) to Exynos5433.  Missing element is the
cooling device.  Not tested on HW.

Signed-off-by: Krzysztof Kozlowski 
---
 .../dts/exynos/exynos5433-tm2-common.dtsi |  5 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 51 +++
 2 files changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index d2de16645e10..6f90b0e62cba 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -350,6 +350,11 @@
pinctrl-0 = <_irq>;
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
  {
hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
status = "okay";
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index d29d13f4694f..a76f620f7f35 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -249,6 +249,57 @@
};
};
 
+   gpu: gpu@14ac {
+   compatible = "samsung,exynos5433-mali", "arm,mali-t760";
+   reg = <0x14ac 0x5000>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   clocks = <_g3d CLK_ACLK_G3D>;
+   clock-names = "core";
+   power-domains = <_g3d>;
+   operating-points-v2 = <_opp_table>;
+   status = "disabled";
+
+   gpu_opp_table: opp_table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <100>;
+   };
+   opp-26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <100>;
+   };
+   opp-35000 {
+   opp-hz = /bits/ 64 <35000>;
+   opp-microvolt = <1025000>;
+   };
+   opp-42000 {
+   opp-hz = /bits/ 64 <42000>;
+   opp-microvolt = <1025000>;
+   };
+   opp-5 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <1075000>;
+   };
+   opp-55000 {
+   opp-hz = /bits/ 64 <55000>;
+   opp-microvolt = <1125000>;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <115>;
+   };
+   opp-7 {
+   opp-hz = /bits/ 64 <7>;
+   opp-microvolt = <115>;
+   };
+   };
+   };
+
psci {
compatible = "arm,psci";
method = "smc";
-- 
2.17.1

[RFT 02/10] clk: samsung: Add bus clock for GPU/G3D on Exynos4412

[Krzysztof Kozlowski]

Add ID and gate for bus clock for GPU (Mali 400) on Exynos4412.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/clk/samsung/clk-exynos4.c   | 1 +
 include/dt-bindings/clock/exynos4.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index d2a68a792a21..ed4af7da9c4f 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -961,6 +961,7 @@ static const struct samsung_gate_clock 
exynos4210_gate_clks[] __initconst = {
 
 /* list of gate clocks supported in exynos4x12 soc */
 static const struct samsung_gate_clock exynos4x12_gate_clks[] __initconst = {
+   GATE(CLK_ASYNC_G3D, "async_g3d", "aclk200", GATE_IP_LEFTBUS, 6, 0, 0),
GATE(CLK_AUDSS, "audss", "sclk_epll", E4X12_GATE_IP_MAUDIO, 0, 0, 0),
GATE(CLK_MDNIE0, "mdnie0", "aclk160", GATE_IP_LCD0, 2, 0, 0),
GATE(CLK_ROTATOR, "rotator", "aclk200", E4X12_GATE_IP_IMAGE, 1, 0, 0),
diff --git a/include/dt-bindings/clock/exynos4.h 
b/include/dt-bindings/clock/exynos4.h
index a0439ce8e8d3..88ec3968b90a 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -187,6 +187,7 @@
 #define CLK_MIPI_HSI   349 /* Exynos4210 only */
 #define CLK_PIXELASYNCM0   351
 #define CLK_PIXELASYNCM1   352
+#define CLK_ASYNC_G3D  353 /* Exynos4x12 only */
 #define CLK_PWM_ISP_SCLK   379 /* Exynos4x12 only */
 #define CLK_SPI0_ISP_SCLK  380 /* Exynos4x12 only */
 #define CLK_SPI1_ISP_SCLK  381 /* Exynos4x12 only */
-- 
2.17.1

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

[RFT 01/10] dt-bindings: gpu: mali: Add Samsung compatibles for Midgard and Utgard

[Krzysztof Kozlowski]

Add vendor compatibles for specific implementation of Mali Utgard
(Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index e5ad3b2afe17..9b298edec5b2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -17,6 +17,7 @@ Required properties:
   * which must be preceded by one of the following vendor specifics:
 + "allwinner,sun50i-h6-mali"
 + "amlogic,meson-gxm-mali"
++ "samsung,exynos5433-mali"
 + "rockchip,rk3288-mali"
 + "rockchip,rk3399-mali"
 
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index ae63f09fda7d..519018cb860b 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -17,6 +17,7 @@ Required properties:
   + amlogic,meson8b-mali
   + amlogic,meson-gxbb-mali
   + amlogic,meson-gxl-mali
+  + samsung,exynos3250-mali
   + rockchip,rk3036-mali
   + rockchip,rk3066-mali
   + rockchip,rk3188-mali
-- 
2.17.1

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

[RFT 00/10] ARM/arm64: dts: exynos: Add support for Mali

[Krzysztof Kozlowski]

Hi,

Inspired by patch from Joseph Kogut [1], let's add support for Mali GPUs
to most of other boards.  However it was tested only on Odroid U3
(Exynos4412) and not fully because requirement of special Mesa drivers
with Lima support.

Even without tests it brings full description of hardware and replaces
some out-of-tree downstream code (e.g. in Tizen).

Comments and tests are welcomed.

[1] https://patchwork.kernel.org/patch/10996887/

Best regards,
Krzysztof


Krzysztof Kozlowski (10):
  dt-bindings: gpu: mali: Add Samsung compatibles for Midgard and Utgard
  clk: samsung: Add bus clock for GPU/G3D on Exynos4412
  ARM: dts: exynos: Fix language typo and indentation
  ARM: dts: exynos: Add GPU/Mali 400 node to Exynos3250
  ARM: dts: exynos: Add GPU/Mali 400 node to Exynos4
  arm64: dts: exynos: Add GPU/Mali T760 node to Exynos5433
  arm64: dts: exynos: Add GPU/Mali T760 node to Exynos7
  ARM: multi_v7_defconfig: Enable Panfrost and LIMA drivers
  ARM: exynos_defconfig: Enable Panfrost and LIMA drivers
  arm64: defconfig: Enable Panfrost driver

 .../bindings/gpu/arm,mali-midgard.txt |  1 +
 .../bindings/gpu/arm,mali-utgard.txt  |  1 +
 arch/arm/boot/dts/exynos3250-artik5.dtsi  |  5 ++
 arch/arm/boot/dts/exynos3250-monk.dts |  5 ++
 arch/arm/boot/dts/exynos3250-rinato.dts   |  5 ++
 arch/arm/boot/dts/exynos3250.dtsi | 33 
 arch/arm/boot/dts/exynos4.dtsi| 29 +++
 arch/arm/boot/dts/exynos4210-origen.dts   |  5 ++
 arch/arm/boot/dts/exynos4210-trats.dts|  4 ++
 .../boot/dts/exynos4210-universal_c210.dts|  5 ++
 arch/arm/boot/dts/exynos4210.dtsi | 36 +++--
 .../boot/dts/exynos4412-itop-scp-core.dtsi|  5 ++
 arch/arm/boot/dts/exynos4412-midas.dtsi   |  5 ++
 .../boot/dts/exynos4412-odroid-common.dtsi|  5 ++
 arch/arm/boot/dts/exynos4412.dtsi | 32 
 arch/arm/configs/exynos_defconfig |  3 +-
 arch/arm/configs/multi_v7_defconfig   |  3 +-
 .../dts/exynos/exynos5433-tm2-common.dtsi |  5 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 51 +++
 .../boot/dts/exynos/exynos7-espresso.dts  |  5 ++
 arch/arm64/boot/dts/exynos/exynos7.dtsi   | 11 
 arch/arm64/configs/defconfig  |  2 +-
 drivers/clk/samsung/clk-exynos4.c |  1 +
 include/dt-bindings/clock/exynos4.h   |  1 +
 24 files changed, 251 insertions(+), 7 deletions(-)

-- 
2.17.1

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

[RFT 03/10] ARM: dts: exynos: Fix language typo and indentation

[Krzysztof Kozlowski]

Correct language typo and wrong indentation.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index b491c345b2e8..ea0e043cd2b4 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -8,7 +8,7 @@
  * www.linaro.org
  *
  * Samsung's Exynos4210 SoC device nodes are listed in this file. Exynos4210
- * based board files can include this file and provide values for board specfic
+ * based board files can include this file and provide values for board 
specific
  * bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
@@ -381,13 +381,13 @@
 
trips {
cpu_alert0: cpu-alert-0 {
-   temperature = <85000>; /* millicelsius */
+   temperature = <85000>; /* millicelsius 
*/
};
cpu_alert1: cpu-alert-1 {
-   temperature = <10>; /* millicelsius */
+   temperature = <10>; /* millicelsius 
*/
};
cpu_alert2: cpu-alert-2 {
-   temperature = <11>; /* millicelsius */
+   temperature = <11>; /* millicelsius 
*/
};
};
};
-- 
2.17.1

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

[RFT 04/10] ARM: dts: exynos: Add GPU/Mali 400 node to Exynos3250

[Krzysztof Kozlowski]

Add nodes for GPU (Mali 400) to Exynos3250.  This is still limited and
not tested:
1. No dynamic voltage and frequency scaling,
2. Not sure what to do with CLK_G3D clock responsible for gating entire
   IP block (it is now being disabled as unused).

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-artik5.dtsi |  5 
 arch/arm/boot/dts/exynos3250-monk.dts|  5 
 arch/arm/boot/dts/exynos3250-rinato.dts  |  5 
 arch/arm/boot/dts/exynos3250.dtsi| 33 
 4 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-artik5.dtsi 
b/arch/arm/boot/dts/exynos3250-artik5.dtsi
index ace50e194a45..dee35e3a5c4b 100644
--- a/arch/arm/boot/dts/exynos3250-artik5.dtsi
+++ b/arch/arm/boot/dts/exynos3250-artik5.dtsi
@@ -59,6 +59,11 @@
cpu0-supply = <_reg>;
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
 _0 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index e25765500e99..248bd372fe70 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -172,6 +172,11 @@
status = "okay";
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
  {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 7479993755da..86c26a4edfd7 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -244,6 +244,11 @@
};
 };
 
+ {
+   mali-supply = <_reg>;
+   status = "okay";
+};
+
 _0 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 8ce3a7786b19..c5f37618f329 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -126,6 +126,39 @@
};
};
 
+   gpu: gpu@1300 {
+   compatible = "samsung,exynos3250-mali", "arm,mali-400";
+   reg = <0x1300 0x1>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "gp",
+ "gpmmu",
+ "pp0",
+ "ppmmu0",
+ "pp1",
+ "ppmmu1",
+ "pp2",
+ "ppmmu2",
+ "pp3",
+ "ppmmu3",
+ "pmu";
+   clocks = < CLK_ASYNC_G3D>,
+< CLK_SCLK_G3D>;
+   clock-names = "bus", "core";
+   power-domains = <_g3d>;
+   status = "disabled";
+   /* TODO: operating points for DVFS */
+   };
+
pmu {
compatible = "arm,cortex-a7-pmu";
interrupts = ,
-- 
2.17.1

[PATCH 2/3] drm/lima: Reduce the amount of logs on deferred probe

[Krzysztof Kozlowski]

There is no point to print deferred probe (and its failures to get
resources) as an error.  For example getting a regulator causes three
unneeded error messages:

lima 1300.gpu: failed to get regulator: -517
lima 1300.gpu: regulator init fail -517
lima 1300.gpu: Fatal error during GPU init

Also do not print clock rates before the initialization finishes
because they will be duplicated after deferral.  Each probe step already
prints error so remove the final error message "Fatal error during GPU
init".

In case of multiple probe tries this would pollute the dmesg.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/lima/lima_device.c | 17 ++---
 drivers/gpu/drm/lima/lima_drv.c|  4 +---
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_device.c 
b/drivers/gpu/drm/lima/lima_device.c
index 570d0e93f9a9..bb2eaa4f370e 100644
--- a/drivers/gpu/drm/lima/lima_device.c
+++ b/drivers/gpu/drm/lima/lima_device.c
@@ -80,7 +80,6 @@ const char *lima_ip_name(struct lima_ip *ip)
 static int lima_clk_init(struct lima_device *dev)
 {
int err;
-   unsigned long bus_rate, gpu_rate;
 
dev->clk_bus = devm_clk_get(dev->dev, "bus");
if (IS_ERR(dev->clk_bus)) {
@@ -94,12 +93,6 @@ static int lima_clk_init(struct lima_device *dev)
return PTR_ERR(dev->clk_gpu);
}
 
-   bus_rate = clk_get_rate(dev->clk_bus);
-   dev_info(dev->dev, "bus rate = %lu\n", bus_rate);
-
-   gpu_rate = clk_get_rate(dev->clk_gpu);
-   dev_info(dev->dev, "mod rate = %lu", gpu_rate);
-
err = clk_prepare_enable(dev->clk_bus);
if (err)
return err;
@@ -145,7 +138,8 @@ static int lima_regulator_init(struct lima_device *dev)
dev->regulator = NULL;
if (ret == -ENODEV)
return 0;
-   dev_err(dev->dev, "failed to get regulator: %d\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev->dev, "failed to get regulator: %d\n", ret);
return ret;
}
 
@@ -297,10 +291,8 @@ int lima_device_init(struct lima_device *ldev)
}
 
err = lima_regulator_init(ldev);
-   if (err) {
-   dev_err(ldev->dev, "regulator init fail %d\n", err);
+   if (err)
goto err_out0;
-   }
 
ldev->empty_vm = lima_vm_create(ldev);
if (!ldev->empty_vm) {
@@ -343,6 +335,9 @@ int lima_device_init(struct lima_device *ldev)
if (err)
goto err_out5;
 
+   dev_info(ldev->dev, "bus rate = %lu\n", clk_get_rate(ldev->clk_bus));
+   dev_info(ldev->dev, "mod rate = %lu", clk_get_rate(ldev->clk_gpu));
+
return 0;
 
 err_out5:
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index b29c26cd13b2..cebc44592e47 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -307,10 +307,8 @@ static int lima_pdev_probe(struct platform_device *pdev)
ldev->ddev = ddev;
 
err = lima_device_init(ldev);
-   if (err) {
-   dev_err(>dev, "Fatal error during GPU init\n");
+   if (err)
goto err_out1;
-   }
 
/*
 * Register the DRM device with the core and the connectors with
-- 
2.17.1

[PATCH 3/3] drm/panfrost: Reduce the amount of logs on deferred probe

[Krzysztof Kozlowski]

There is no point to print deferred probe (and its failures to get
resources) as an error.

In case of multiple probe tries this would pollute the dmesg.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index ccb8eb2a518c..858582a60090 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -95,7 +95,9 @@ static int panfrost_regulator_init(struct panfrost_device 
*pfdev)
pfdev->regulator = NULL;
if (ret == -ENODEV)
return 0;
-   dev_err(pfdev->dev, "failed to get regulator: %d\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(pfdev->dev, "failed to get regulator: %d\n",
+   ret);
return ret;
}
 
-- 
2.17.1

[PATCH 1/3] drm/lima: Mark 64-bit number as ULL to silence Smatch warning

[Krzysztof Kozlowski]

Mark long numbers with ULL to silence the Smatch warning:

drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 is 
so big it is long long

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/lima/lima_vm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_vm.h b/drivers/gpu/drm/lima/lima_vm.h
index caee2f8a29b4..e0bdedcf14dd 100644
--- a/drivers/gpu/drm/lima/lima_vm.h
+++ b/drivers/gpu/drm/lima/lima_vm.h
@@ -15,9 +15,9 @@
 #define LIMA_VM_NUM_PT_PER_BT (1 << LIMA_VM_NUM_PT_PER_BT_SHIFT)
 #define LIMA_VM_NUM_BT (LIMA_PAGE_ENT_NUM >> LIMA_VM_NUM_PT_PER_BT_SHIFT)
 
-#define LIMA_VA_RESERVE_START  0xFFF0
+#define LIMA_VA_RESERVE_START  0x0FFF0ULL
 #define LIMA_VA_RESERVE_DLBU   LIMA_VA_RESERVE_START
-#define LIMA_VA_RESERVE_END0x1
+#define LIMA_VA_RESERVE_END0x1ULL
 
 struct lima_device;
 
-- 
2.17.1

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

Re: [RFC/WIP] drm/rockchip: Support CRTC gamma LUT

[Ezequiel Garcia]

On Tue, 2019-06-18 at 02:15 -0300, Ezequiel Garcia wrote:
> On Mon, 2019-06-17 at 12:06 +0200, Jacopo Mondi wrote:
> > Hi Ezequiel,
> >one small question, as I'm working on supporting gamma LUT for
> > rcar-du as well, and there's one point not totally clear to me
> > 
> > 
> > On Thu, Jun 13, 2019 at 04:22:44PM -0300, Ezequiel Garcia wrote:
> > > Add CRTC gamma LUT configuration on RK3288 and RK3399.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > > This patch seems to work well on RK3288, but produces
> > > a distorted output on RK3399. I was hoping
> > > someone could have any idea, so we can support both
> > > platforms.
> > > 
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 87 +
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  2 +
> > >  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +
> > >  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
> > >  4 files changed, 94 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > index 12ed5265a90b..8381679c1045 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > @@ -38,6 +38,8 @@
> > >  #include "rockchip_drm_vop.h"
> > >  #include "rockchip_rgb.h"
> > > 
> > > +#define VOP_GAMMA_LUT_SIZE 1024
> > > +
> > >  #define VOP_WIN_SET(vop, win, name, v) \
> > >   vop_reg_set(vop, >phy->name, win->base, ~0, v, #name)
> > >  #define VOP_SCL_SET(vop, win, name, v) \
> > > @@ -137,6 +139,7 @@ struct vop {
> > > 
> > >   uint32_t *regsbak;
> > >   void __iomem *regs;
> > > + void __iomem *lut_regs;
> > > 
> > >   /* physical map length of vop register */
> > >   uint32_t len;
> > > @@ -1153,6 +1156,46 @@ static void vop_wait_for_irq_handler(struct vop 
> > > *vop)
> > >   synchronize_irq(vop->irq);
> > >  }
> > > 
> > > +static bool vop_dsp_lut_is_enable(struct vop *vop)
> > > +{
> > > + return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
> > > +}
> > > +
> > > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > > +struct drm_crtc_state *state)
> > > +{
> > > + struct drm_color_lut *lut;
> > > + int i, idle, ret;
> > > +
> > > + if (!state->gamma_lut)
> > > + return;
> > > + lut = state->gamma_lut->data;
> > > +
> > > + spin_lock(>reg_lock);
> > > + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> > > + vop_cfg_done(vop);
> > > + spin_unlock(>reg_lock);
> > > +
> > > + ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> > > +idle, !idle, 5, 10 * 3);
> > > + if (ret)
> > > + return;
> > > +
> > > + spin_lock(>reg_lock);
> > > + for (i = 0; i < crtc->gamma_size; i++) {
> > > + u32 word;
> > > +
> > > + word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
> > > +(drm_color_lut_extract(lut[i].green, 10) << 10) |
> > > + drm_color_lut_extract(lut[i].blue, 10);
> > > + writel(word, vop->lut_regs + i * 4);
> > > + }
> > > +
> > > + VOP_REG_SET(vop, common, dsp_lut_en, 1);
> > > + vop_cfg_done(vop);
> > > + spin_unlock(>reg_lock);
> > > +}
> > > +
> > >  static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> > > struct drm_crtc_state *old_crtc_state)
> > >  {
> > > @@ -1201,6 +1244,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc 
> > > *crtc,
> > >   drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
> > >   set_bit(VOP_PENDING_FB_UNREF, >pending);
> > >   }
> > > +
> > > + if (vop->lut_regs && crtc->state->color_mgmt_changed)
> > > + vop_crtc_gamma_set(vop, crtc, crtc->state);
> > 
> > Which one is the right point when to call LUT update functions?
> > 
> > I initially added my callback in atomic_flush as you did here, mostly
> > because I've found examples in other drivers in drm and went in
> > cargo cult mode. I've been then suggested by Laurent that atomic_flush()
> > might not be the right place where to do so, as it gets called after
> > the plane updates (iirc, the DRM atomic API is not something I'm that
> > familiar with yet).
> > 
> > So I moved my LUT update function in the atomic_commit_tail callback,
> > which is meant to actually commit a CRTC to the hw.
> > 
> > What's your opinion on this?
> > 
> 
> I have to admit this is not exactly clear to me either.
> 
> Let me make sure I understand the issue. You are concerned about
> getting some tearing if the CRTC gamma LUT is affected
> in the atomic_flush?
> 
> If that's the case, it shouldn't be too hard to confirm (I think).
> 

As we suspected, indeed setting the gamma lut in atomic_flush
is exposed to tearing, if the atomic API is used.

As Laurent suggested you, setting from atomic_commit_tail seems correct,
as an example you can see the malidp driver.

I'm preparing a v2 patch.

Thanks,
Ezequiel

___
dri-devel mailing list

Re: [PATCH] drm/todo: Update drm_gem_object_funcs todo even more

[Eric Engestrom]

On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
> 
> Let's try again.
> 
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Thomas Zimmermann 
> Cc: Gerd Hoffmann 
> Cc: Rob Herring 
> Cc: Noralf Trønnes 
> Cc: Eric Anholt 
> Cc: Gerd Hoffmann 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 25878dd048fd..66c123737c3d 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -212,9 +212,11 @@ struct drm_gem_object_funcs
>  GEM objects can now have a function table instead of having the callbacks on 
> the
>  DRM driver struct. This is now the preferred way and drivers can be moved 
> over.
>  
> -Unfortunately some of the recently added GEM helpers are going in the wrong
> -direction by adding OPS macros that use the old, deprecated hooks. See
> -DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and 
> DRM_GEM_VRAM_DRIVER_PRIME.
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, 
> but
> +DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligend with the 
> previous

s/aligend/aligned/

> +two. We also need a 2nd version of the CMA define that doesn't require the
> +vmapping to be present (different hook for prime importing). Plus this needs 
> to
> +be rolled out to all drivers using their own implementations, too.
>  
>  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
>  -
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)

[Greg Kroah-Hartman]

On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
>  wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already, but maybe he won't do everything ...
> > > >
> > > > Cc: Greg Kroah-Hartman 
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  Documentation/gpu/todo.rst | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > > index 9717540ee28f..026e55c517e1 100644
> > > > --- a/Documentation/gpu/todo.rst
> > > > +++ b/Documentation/gpu/todo.rst
> > > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > > >this (together with the drm_minor->drm_device move) would allow us 
> > > > to remove
> > > >debugfs_init.
> > > >
> > > > +- Drop the return code and error checking from all debugfs functions. 
> > > > Greg KH is
> > > > +  working on this already.
> > >
> > >
> > > Part of this work was to try to delete drm_debugfs_remove_files().
> > >
> > > There are only 4 files that currently still call this function:
> > >   drivers/gpu/drm/tegra/dc.c
> > >   drivers/gpu/drm/tegra/dsi.c
> > >   drivers/gpu/drm/tegra/hdmi.c
> > >   drivers/gpu/drm/tegra/sor.c
> > >
> > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > > debugfs directory.  Which is fine, but it has to do some special memory
> > > allocation to get the debugfs callback to point not to the struct
> > > drm_minor pointer, but rather the drm_crtc structure.
> 
> There's already a todo to switch the drm_minor debugfs stuff over to
> drm_device. drm_minor is essentially different uapi flavours (/dev/
> minor nodes, hence the name) sitting on top of the same drm_device.
> Last time I checked all the debugfs files want the drm_device, not the
> minor. I think we even discussed to only register the debugfs files
> for the first minor, and create the other ones as symlinks to the
> first one. But haven't yet gotten around to typing that.
> 
> drm_crtc/connector are parts of drm_device with modesetting support,
> so the drm_minor is even worse choice really.

Heh, ok, so the existing code is working around that choice right now,
but that wasn't a good choice, so I'll ignore it :)

> Not exactly sure why we went with this, but probably dates back to the
> *bsd compat layer and a lot of these files hanging out in procfs too
> (we've fixed those mistakes a few years ago, yay!).
> 
> > > So, to remove this call, I need to remove this special memory allocation
> > > and to do that, I need to somehow be able to cast from drm_minor back to
> > > the drm_crtc structure being used in this driver.  And I can't figure
> > > how they are related at all.
> > >
> > > Any pointers here (pun intended) would be appreciated.
> > >
> > > For the other 3 files, the situation is much the same, but I need to get
> > > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
> 
> Ditch the drm_minor, there's no no way to get from that to something
> like drm_connector/crtc, since it's a n:m relationship.

Ok, will do.

> 
> > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > these drivers, which would solve this issue, but in a more "non-drm"
> > > way.  Is it worth to just do that instead of overthinking the whole
> > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> >
> > An example of "open coding" this is the patch below for the sor.c
> > driver.
> 
> I think open-coding is the way to go here. One of the todos is to
> extend debugfs support for crtc/connectors, but looking at the
> open-coded version we really don't need a drm-flavoured midlayer here.

There already is debugfs support in the code for crtc/connectors, these
files are "hanging" off of those locations already.  I'll keep that, but
indent it one more directory so that there's no namespace collisions.

> > Totally untested, not even built, but you should get the idea here.
> >
> > thanks,
> >
> > greg k-h
> >
> > ---
> >
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index 5be5a0817dfe..3216221c77c4 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -414,7 +414,8 @@ struct tegra_sor {
> >
> > struct drm_dp_aux *aux;
> >
> > -   struct drm_info_list *debugfs_files;
> > +   struct dentry *debugfs_root;
> > +   struct drm_device *drm;
> >
> > const struct tegra_sor_ops *ops;
> > enum tegra_io_pad pad;
> > @@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor, 
> > unsigned long timeout)
> >
> >  static int tegra_sor_show_crc(struct seq_file *s, void *data)
> >  {
> > -   struct drm_info_node *node = s->private;
> > -   struct tegra_sor *sor = node->info_ent->data;
> > +   

Re: [PATCH v5 07/12] drm/modes: Allow to specify rotation and reflection on the commandline

[Noralf Trønnes]

Den 17.06.2019 16.51, skrev Maxime Ripard:
> Rotations and reflections setup are needed in some scenarios to initialise
> properly the initial framebuffer. Some drivers already had a bunch of
> quirks to deal with this, such as either a private kernel command line
> parameter (omapdss) or on the device tree (various panels).
> 
> In order to accomodate this, let's create a video mode parameter to deal
> with the rotation and reflexion.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/fb/modedb.rst  |  11 +++-
>  drivers/gpu/drm/drm_client_modeset.c |  30 +++-
>  drivers/gpu/drm/drm_modes.c  | 114 +++-
>  include/drm/drm_connector.h  |  10 ++-
>  4 files changed, 145 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
> index 3c2397293977..3e8a6f79dcd7 100644
> --- a/Documentation/fb/modedb.rst
> +++ b/Documentation/fb/modedb.rst
> @@ -53,6 +53,17 @@ Specifying the option multiple times for different ports 
> is possible, e.g.::
>  
>  video=LVDS-1:d video=HDMI-1:D
>  
> +Options can also be passed after the mode, using commas as separator.
> +
> +   Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 
> degrees
> +
> +Valid options are:
> +
> +  - reflect_x (boolean): Perform an axial symetry on the X axis
> +  - reflect_y (boolean): Perform an axial symetry on the Y axis

2x s/symetry/symmetry/

Reviewed-by: Noralf Trønnes 

> +  - rotate (integer): Rotate the initial framebuffer by x
> +degrees. Valid values are 0, 90, 180 and 270.
> +
>  -
>  
>  What is the VESA(TM) Coordinated Video Timings (CVT)?
> diff --git a/drivers/gpu/drm/drm_client_modeset.c 
> b/drivers/gpu/drm/drm_client_modeset.c
> index 33d4988f22ae..e95fceac8f8b 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -824,6 +824,7 @@ bool drm_client_rotation(struct drm_mode_set *modeset, 
> unsigned int *rotation)
>  {
>   struct drm_connector *connector = modeset->connectors[0];
>   struct drm_plane *plane = modeset->crtc->primary;
> + struct drm_cmdline_mode *cmdline;
>   u64 valid_mask = 0;
>   unsigned int i;
>  
> @@ -844,6 +845,35 @@ bool drm_client_rotation(struct drm_mode_set *modeset, 
> unsigned int *rotation)
>   *rotation = DRM_MODE_ROTATE_0;
>   }
>  
> + /**
> +  * The panel already defined the default rotation
> +  * through its orientation. Whatever has been provided
> +  * on the command line needs to be added to that.
> +  *
> +  * Unfortunately, the rotations are at different bit
> +  * indices, so the math to add them up are not as
> +  * trivial as they could.
> +  *
> +  * Reflections on the other hand are pretty trivial to deal with, a
> +  * simple XOR between the two handle the addition nicely.
> +  */
> + cmdline = >cmdline_mode;
> + if (cmdline->specified) {
> + unsigned int cmdline_rest, panel_rest;
> + unsigned int cmdline_rot, panel_rot;
> + unsigned int sum_rot, sum_rest;
> +
> + panel_rot = ilog2(*rotation & DRM_MODE_ROTATE_MASK);
> + cmdline_rot = ilog2(cmdline->rotation_reflection & 
> DRM_MODE_ROTATE_MASK);
> + sum_rot = (panel_rot + cmdline_rot) % 4;
> +
> + panel_rest = *rotation & ~DRM_MODE_ROTATE_MASK;
> + cmdline_rest = cmdline->rotation_reflection & 
> ~DRM_MODE_ROTATE_MASK;
> + sum_rest = panel_rest ^ cmdline_rest;
> +
> + *rotation = (1 << sum_rot) | sum_rest;
> + }
> +
>   /*
>* TODO: support 90 / 270 degree hardware rotation,
>* depending on the hardware this may require the framebuffer
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 429d3be17800..dc6d11292685 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1554,6 +1554,71 @@ static int drm_mode_parse_cmdline_res_mode(const char 
> *str, unsigned int length,
>   return 0;
>  }
>  
> +static int drm_mode_parse_cmdline_options(char *str, size_t len,
> +   struct drm_connector *connector,
> +   struct drm_cmdline_mode *mode)
> +{
> + unsigned int rotation = 0;
> + char *sep = str;
> +
> + while ((sep = strchr(sep, ','))) {
> + char *delim, *option;
> +
> + option = sep + 1;
> + delim = strchr(option, '=');
> + if (!delim) {
> + delim = strchr(option, ',');
> +
> + if (!delim)
> + delim = str + len;
> + }
> +
> + if (!strncmp(option, "rotate", delim - option)) {
> + const char *value = delim + 1;
> + unsigned int deg;
> +
> +  

[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0

[bugzilla-daemon]

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

Sean Birkholz (supas...@hotmail.com) changed:

   What|Removed |Added

 CC||supas...@hotmail.com

--- Comment #18 from Sean Birkholz (supas...@hotmail.com) ---
I am not a kernel developer and haven't done much programming as of late, so I
am not really in a position to actually test this hypothesis.  However - from
the bit of research I've done trying to figure this problem out for myself I
believe the following explains the overheating and burst of fan speed instead
of proper cooling behavior.

Here is my sensors bit from kernel 4.18.x - I have the R9-290.

amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:   N/A  
fan1:   0 RPM
temp1:+65.0°C  (crit = +120.0°C, hyst = +90.0°C)

Take note that this displays the proper critical and hysteresis values for my
card.  If you look at the post on comment 14 which is how sensors display the
crit/hyst value for kernels beyond 4.18.x you notice the critical value is
about 19x the temperature of the surface of the sun and the hyst value is
absolute zero.  These values are hard coded into kernel source code in some
file, forgive me as I do not recall where I saw the code snippet.  But I
strongly believe that correcting the values in the file or changing it to
detect proper crit/hyst values based on card will correct this issue.  I simply
do not have the means to do this, nor do I know how to submit kernel bug fixes
and hope someone with more experience could give it a shot and see if the
resulting kernel functions properly.

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

Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)

[Daniel Vetter]

On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
 wrote:
> On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > Greg is busy already, but maybe he won't do everything ...
> > >
> > > Cc: Greg Kroah-Hartman 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  Documentation/gpu/todo.rst | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > index 9717540ee28f..026e55c517e1 100644
> > > --- a/Documentation/gpu/todo.rst
> > > +++ b/Documentation/gpu/todo.rst
> > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > >this (together with the drm_minor->drm_device move) would allow us to 
> > > remove
> > >debugfs_init.
> > >
> > > +- Drop the return code and error checking from all debugfs functions. 
> > > Greg KH is
> > > +  working on this already.
> >
> >
> > Part of this work was to try to delete drm_debugfs_remove_files().
> >
> > There are only 4 files that currently still call this function:
> >   drivers/gpu/drm/tegra/dc.c
> >   drivers/gpu/drm/tegra/dsi.c
> >   drivers/gpu/drm/tegra/hdmi.c
> >   drivers/gpu/drm/tegra/sor.c
> >
> > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > debugfs directory.  Which is fine, but it has to do some special memory
> > allocation to get the debugfs callback to point not to the struct
> > drm_minor pointer, but rather the drm_crtc structure.

There's already a todo to switch the drm_minor debugfs stuff over to
drm_device. drm_minor is essentially different uapi flavours (/dev/
minor nodes, hence the name) sitting on top of the same drm_device.
Last time I checked all the debugfs files want the drm_device, not the
minor. I think we even discussed to only register the debugfs files
for the first minor, and create the other ones as symlinks to the
first one. But haven't yet gotten around to typing that.

drm_crtc/connector are parts of drm_device with modesetting support,
so the drm_minor is even worse choice really.

Not exactly sure why we went with this, but probably dates back to the
*bsd compat layer and a lot of these files hanging out in procfs too
(we've fixed those mistakes a few years ago, yay!).

> > So, to remove this call, I need to remove this special memory allocation
> > and to do that, I need to somehow be able to cast from drm_minor back to
> > the drm_crtc structure being used in this driver.  And I can't figure
> > how they are related at all.
> >
> > Any pointers here (pun intended) would be appreciated.
> >
> > For the other 3 files, the situation is much the same, but I need to get
> > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.

Ditch the drm_minor, there's no no way to get from that to something
like drm_connector/crtc, since it's a n:m relationship.

> > I could just "open code" a bunch of calls to debugfs_create_file() for
> > these drivers, which would solve this issue, but in a more "non-drm"
> > way.  Is it worth to just do that instead of overthinking the whole
> > thing and trying to squish it into the drm "model" of drm debugfs calls?
>
> An example of "open coding" this is the patch below for the sor.c
> driver.

I think open-coding is the way to go here. One of the todos is to
extend debugfs support for crtc/connectors, but looking at the
open-coded version we really don't need a drm-flavoured midlayer here.

> Totally untested, not even built, but you should get the idea here.
>
> thanks,
>
> greg k-h
>
> ---
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 5be5a0817dfe..3216221c77c4 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -414,7 +414,8 @@ struct tegra_sor {
>
> struct drm_dp_aux *aux;
>
> -   struct drm_info_list *debugfs_files;
> +   struct dentry *debugfs_root;
> +   struct drm_device *drm;
>
> const struct tegra_sor_ops *ops;
> enum tegra_io_pad pad;
> @@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor, 
> unsigned long timeout)
>
>  static int tegra_sor_show_crc(struct seq_file *s, void *data)
>  {
> -   struct drm_info_node *node = s->private;
> -   struct tegra_sor *sor = node->info_ent->data;
> +   struct tegra_sor *sor = s->private;
> struct drm_crtc *crtc = sor->output.encoder.crtc;
> -   struct drm_device *drm = node->minor->dev;
> +   struct drm_device *drm = sor->drm;
> int err = 0;
> u32 value;
>
> @@ -1302,6 +1302,20 @@ static int tegra_sor_show_crc(struct seq_file *s, void 
> *data)
> return err;
>  }
>
> +static int crc_open(struct inode *inode, struct file *file)
> +{
> +   struct tegra_sor *sor = inode->i_private;
> +   return single_open(file, tegra_sor_show_crc, sor);
> +}
> +
> +static const struct file_operations crc_fops = {
> +   .owner = THIS_MODULE,

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Handle audio for more clock rates

[Jernej Škrabec]

Hi!

Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> Let's add some better support for HDMI audio to dw_hdmi.
> Specifically:
> 
> 1. For 44.1 kHz audio the old code made the assumption that an N of
> 6272 was right most of the time.  That wasn't true and the new table
> should give better 44.1 kHz audio for many more rates.
> 
> 2. The new table has values from the HDMI spec for 297 MHz and 594
> MHz.
> 
> 3. There is now code to try to come up with a more idea N/CTS for
> clock rates that aren't in the table.  This code is a bit slow because
> it iterates over every possible value of N and picks the best one, but
> it should make a good fallback.
> 
> 4. The new code allows for platforms that know they make a clock rate
> slightly differently to pick different N/CTS values.  For instance on
> rk3288 we can make 25,176,471 Hz instead of 25,174,825.1748... Hz
> (25.2 MHz / 1.001).  A future patch to the rk3288 platform code could
> enable support for this clock rate and specify the N/CTS that would be
> ideal.
> 
> NOTE: the oddest part of this patch comes about because computing the
> ideal N/CTS means knowing the _exact_ clock rate, not a rounded
> version of it.  The drm framework makes this harder by rounding rates
> to kHz, but even if it didn't there might be cases where the ideal
> rate could only be calculated if we knew the real (non-integral) rate.
> This means that in cases where we know (or believe) that the true rate
> is something other than the rate we are told by drm.
> 
> Signed-off-by: Douglas Anderson 

Which bus is used for audio transfer on your device? If it is I2S, which is 
commonly used, then please be aware of this patch:
https://lists.freedesktop.org/archives/dri-devel/2019-June/221539.html

It avoids exact N/CTS calculation by enabling auto detection. It is well 
tested on multiple SoCs from Allwinner, Amlogic and Rockchip.

Best regards,
Jernej

Re: [PATCH] drm: rcar-du: Replace drm_driver GEM ops with GEM object functions

[Noralf Trønnes]

Den 18.06.2019 18.35, skrev Laurent Pinchart:
> Hi Noralf,
> 
> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
>> Den 18.06.2019 15.13, skrev Laurent Pinchart:
>>> The recommended way to specify GEM object functions is to provide a
>>> drm_gem_object_funcs structure instance and set the GEM object to point
>>> to it. The drm_cma_gem_create_object_default_funcs() function provided
>>> by the GEM CMA helper does so when creating the GEM object, simplifying
>>> the driver implementation. Switch to it, and remove the then unneeded
>>> GEM-related opertions from rcar_du_driver.
>>
>> s/opertions/operations/
> 
> Oops, will fix.
> 
>>> Suggested-by: Daniel Vetter 
>>> Signed-off-by: Laurent Pinchart 
>>> ---
>>>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 8 +---
>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>
>>> Daniel, is this what you had in mind ?
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
>>> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>> index 3e5e835ea2b6..4cbb82009931 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>> @@ -445,16 +445,10 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>>>  static struct drm_driver rcar_du_driver = {
>>> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
>>> | DRIVER_ATOMIC,
>>> -   .gem_free_object_unlocked = drm_gem_cma_free_object,
>>> -   .gem_vm_ops = _gem_cma_vm_ops,
>>> +   .gem_create_object  = drm_cma_gem_create_object_default_funcs,
>>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>>> -   .gem_prime_import   = drm_gem_prime_import,
>>> -   .gem_prime_export   = drm_gem_prime_export,
>>> -   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>>> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>>> -   .gem_prime_vmap = drm_gem_cma_prime_vmap,
>>> -   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
>>> .gem_prime_mmap = drm_gem_cma_prime_mmap,
>>
>> If you want to pick up yet another recommendation, you can use
>> drm_gem_prime_mmap here.
> 
> I compared the two call stacks and they appear similar, even if
> drm_gem_prime_mmap() leads to a more convoluted code flow. For my
> information, what's the advantage in using it ?

It's part of Daniels quest to remove the drm_driver gem callbacks. AFAIU
drm_gem_prime_mmap() is a stop gap on the way to remove
drm_driver.gem_prime_mmap. I saw it documented in his recent series:
[03/59] drm/prime: Update docs
https://patchwork.freedesktop.org/patch/310608/

+/**
+ * drm_gem_dmabuf_mmap - dma_buf mmap implementation for GEM
+ * @dma_buf: buffer to be mapped
+ * @vma: virtual address range
+ *
+ * Provides memory mapping for the buffer. This can be used as the
+ * _buf_ops.mmap callback. It just forwards to
_driver.gem_prime_mmap,
+ * which should be set to drm_gem_prime_mmap().
+ *
+ * FIXME: There's really no point to this wrapper, drivers which need
anything
+ * else but drm_gem_prime_mmap can roll their own _buf_ops.mmap
callback.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */

Noralf.

> 
>> Either way:
>>
>> Reviewed-by: Noralf Trønnes 
>>
>>> .dumb_create= rcar_du_dumb_create,
>>> .fops   = _du_fops,
> 

Re: [PATCH v3 00/10] drm: rcar-du: Rework CRTC and groups for atomic commits

[Kieran Bingham]

Hi Laurent,

On 17/06/2019 22:09, Laurent Pinchart wrote:
> Hello everybody,
> 
> This patch series refactors atomic commit tail handling in the R-Car DU
> driver to simplify the code flow, and open the door to further
> optimisations. It takes over Kieran's "[PATCH v2 0/6] drm: rcar-du:
> Rework CRTC and groups for atomic commits" and "[RFC PATCH 0/3] VSP1/DU
> atomic interface changes" series.

Thanks for getting this series ready for integration.

For the changes made to patches originally authored by me:
  Reviewed-by: Kieran Bingham 

For your new patches, see those patches directly.
 (One is reviewed, and one is not fully reviewed yet).


For the whole series:
  Tested-by: Kieran Bingham 

Including testing specifically against a previously reported modetest
failure from the test teams which is now functioning correctly.
Interestingly my connector id's seem to have incremented. I'm not sure
why yet...

As discussed, it could be due to the group changes.

--
Kieran


> The R-Car DU is a bit of a strange beast, with support for up to four
> CRTCs that share resources in groups of two CRTCs. Depending on the
> generation, planes can be shared (on Gen 1 and Gen 2), and output
> routing configuration is also handled at the group level to some extent.
> Furthermore, many configuration parameters, especially those related to
> routing or clock handling, require the whole group to be restarted to
> take effect, even when the parameter itself affects a single CRTC only.
> 
> This hardware architecture is difficult to handle properly on the
> software side, and has resulted in group usage being reference-counted
> while CRTC usage only tracks the enabled state. Calls are then
> unbalanced and difficult to trace, especially for the configuration of
> output routing, and implementation of new shared resources is hindered.
> This patch series aims at solving this problem.
> 
> The series starts with 4 patches that touch the API between the DU and
> VSP drivers. It became apparent that we need to split the configuration
> of the VSP to allow fine grain control of setting the mode configuration
> and enabling/disabling of the pipeline. To support the cross-component
> API, the new interface is added in patch 01/10, including an
> implementation of vsp1_du_setup_lif() to support the transition. Patch
> 02/10 prepares for the new call flow that will call the atomic flush
> handler before enabling the pipeline. The DRM usage is adapted in patch
> 03/10, before the call is removed entirely in patch 04/10.
> 
> The next two patches convert CRTC clock handling and initial setup,
> potentially called from both the CRTC .atomic_begin() and
> .atomic_enable() operations, to a simpler code flow controlled by the
> commit tail handler. Patch 05/10 takes the CRTCs out of standby and put
> them back in standby respectively at the beginning and end of the commit
> tail handler, based on the CRTC atomic state instead of state
> information stored in the custom rcar_du_crtc structure. Patch 06/10
> then performs a similar change for the CRTC mode setting configuration.
> 
> Finally, the last four patches introduce a DRM private object for the
> CRTC groups, along with an associated state. Patch 07/10 adds a helper
> macro to easily iterate over CRTC groups, and patch 08/10 adds the group
> private objects and empty states. Patches 09/10 and 10/10 respectively
> move the group setup and routing configuration under control of the
> commit tail handler, simplifying the configuration and moving state
> information from driver structures to state structures.
> 
> More refactoring is expected, with plane assignment being moved to group
> states, and group restart being optimised to avoid flickering. Better
> configuration of pixel clocks could also be implemented on top of this
> series.
> 
> The whole series has been tested on M3-N and D3 boards with the DU test
> suite (http://git.ideasonboard.com/renesas/kms-tests.git). Additional
> tests have been developed and bugs in existing tests fixed, with patches
> being posted to the linux-renesas-...@vger.kernel.org mailing list that
> will be integrated in the near future. All individual commits have been
> tested on M3-N, while only key points (after patch 04/10 and patch
> 10/10) have been tested on D3. No failure or change in behaviour has
> been noticed.
> 
> Kieran Bingham (8):
>   media: vsp1: drm: Split vsp1_du_setup_lif()
>   drm: rcar-du: Convert to the new VSP atomic API
>   media: vsp1: drm: Remove vsp1_du_setup_lif()
>   drm: rcar-du: Handle CRTC standby from commit tail handler
>   drm: rcar-du: Handle CRTC configuration from commit tail handler
>   drm: rcar-du: Provide for_each_group helper
>   drm: rcar-du: Create a group state object
>   drm: rcar-du: Perform group setup from the atomic tail handler
> 
> Laurent Pinchart (2):
>   media: vsp1: drm: Don't configure hardware when the pipeline is
> disabled
>   drm: rcar-du: Centralise routing configuration in commit tail 

Re: [PATCH v2] drm: return -EFAULT if copy_to_user() fails

[Sean Paul]

On Tue, Jun 18, 2019 at 04:18:43PM +0300, Dan Carpenter wrote:
> The copy_from_user() function returns the number of bytes remaining
> to be copied but we want to return a negative error code.  Otherwise
> the callers treat it as a successful copy.
> 
> Signed-off-by: Dan Carpenter 

Thanks Dan, I've applied this to drm-misc-fixes.

Sean

> ---
> v2: The first version was missing a chunk
> 
>  drivers/gpu/drm/drm_bufs.c  | 5 -
>  drivers/gpu/drm/drm_ioc32.c | 5 -
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 68dacf8422c6..8ce9d73fab4f 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -1351,7 +1351,10 @@ static int copy_one_buf(void *data, int count, struct 
> drm_buf_entry *from)
>.size = from->buf_size,
>.low_mark = from->low_mark,
>.high_mark = from->high_mark};
> - return copy_to_user(to, , offsetof(struct drm_buf_desc, flags));
> +
> + if (copy_to_user(to, , offsetof(struct drm_buf_desc, flags)))
> + return -EFAULT;
> + return 0;
>  }
>  
>  int drm_legacy_infobufs(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 586aa28024c5..a16b6dc2fa47 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -378,7 +378,10 @@ static int copy_one_buf32(void *data, int count, struct 
> drm_buf_entry *from)
> .size = from->buf_size,
> .low_mark = from->low_mark,
> .high_mark = from->high_mark};
> - return copy_to_user(to + count, , offsetof(drm_buf_desc32_t, flags));
> +
> + if (copy_to_user(to + count, , offsetof(drm_buf_desc32_t, flags)))
> + return -EFAULT;
> + return 0;
>  }
>  
>  static int drm_legacy_infobufs32(struct drm_device *dev, void *data,
> -- 
> 2.20.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/WIP] drm/rockchip: Support CRTC gamma LUT

[Ilia Mirkin]

On Tue, Jun 18, 2019 at 9:36 AM Ezequiel Garcia  wrote:
>
> On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> > Note that userspace may provide any size of gamma lut. Have a look at
> > i915/intel_color.c:intel_color_check which filters out only the
> > allowed sizes. Consider having a special allowance for 256-sized LUTs
> > since that's what most legacy userspace will set, and it seems like a
> > waste to create a 10-bit LUT for RGBA8 color.
> >
>
> Right. I will add a check for the gamma lut size.
>
> Unfortunately, this hardware seems to only support 10-bit, 1024-sized LUTs.
>
> The spec does mention a support 8-bit, 256-entries, but it's not at all
> clear how configure that.

It's up to you, and the more experienced drm reviewers, but even if
you can't figure out how to bend the hardware to your will (which is
worth a bit of exploration), you can still emulate it by just
repeating all the values 4x. IMHO 256-sized LUTs are worth supporting
when possible.

Cheers,

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

Re: [PATCH] drm/rcar-du: Fix error check when retrieving crtc state

[Sean Paul]

On Tue, Jun 18, 2019 at 10:26:52AM +0300, Laurent Pinchart wrote:
> Hi Sean,
> 
> Thank you for the patch.
> 
> On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> > From: Sean Paul 
> > 
> > drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> > the null check is doing nothing here.
> > 
> > Credit to 0-day/Dan Carpenter for reporting this.
> > 
> > Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to 
> > accept drm_atomic_state")
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: Ben Skeggs 
> > Cc: Laurent Pinchart 
> > Cc: Kieran Bingham 
> > Cc: Eric Anholt 
> > Cc: Laurent Pinchart  [for rcar lvds]
> > Cc: Sean Paul 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: Lyude Paul 
> > Cc: Karol Herbst 
> > Cc: Ilia Mirkin 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Reported-by: kbuild test robot 
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Sean Paul 
> 
> Reviewed-by: Laurent Pinchart 
> 
> I have no pending conflicting changes for rcar_lvds.c. Do you plan to
> merge this through drm-misc ?

Thanks for your review!

Yeah, since the bug is only in drm-misc-next, this will also go there. Speaking
of which, I just applied it :-)

Sean

> 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index f2a5d4d997073..1c62578590f46 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -115,8 +115,8 @@ static int rcar_lvds_connector_atomic_check(struct 
> > drm_connector *connector,
> >  
> > /* We're not allowed to modify the resolution. */
> > crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> > -   if (!crtc_state)
> > -   return -EINVAL;
> > +   if (IS_ERR(crtc_state))
> > +   return PTR_ERR(crtc_state);
> >  
> > if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> > crtc_state->mode.vdisplay != panel_mode->vdisplay)
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] dt-bindings: display: renesas: Add r8a774a1 support

[Laurent Pinchart]

Hi Fabrizio,

Thank you for the patch.

On Tue, Jun 18, 2019 at 04:18:37PM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (R8A774A1) SoC bindings.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Laurent Pinchart 

I don't have pending changes for this file for this kernel release. As
your series contains DT changes, I'm fine if this patch gets merged
through the ARM SoC tree along with the rest. Otherwise please let me
know if I should handle it myself.

> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> index a41d280..db68041 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> @@ -12,10 +12,12 @@ following device-specific properties.
>  Required properties:
>  
>  - compatible : Shall contain one or more of
> +  - "renesas,r8a774a1-hdmi" for R8A774A1 (RZ/G2M) compatible HDMI TX
>- "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
>- "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
>- "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
> -  - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX
> +  - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
> +  HDMI TX
>  
>  When compatible with generic versions, nodes must list the SoC-specific
>  version corresponding to the platform first, followed by the

-- 
Regards,

Laurent Pinchart