[PATCH 3/3] arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e board

2017-04-13 Thread Hoegeun Kwon
This patch add the panel device tree node for S6E3HA2 edge display
controller to TM2e dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..79f22f7 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <27800>, <4>;
 };
 
+ {
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
-- 
1.9.1

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


[PATCH 0/3] Add support for the S6E3HA2 edge panel on TM2e board

2017-04-13 Thread Hoegeun Kwon
The purpose of this patch is add support for S6E3HA2 edge AMOLED panel
on the TM2e board. The panel has 1600x2560 resolution in 5.65"
physical panel in the TM2e device.

The S6E3HA2 edge panel(5.65") is simliar to the previous S6E3HA2
panel(5.7"), but resolution and some command message are different. So
it can be distinguished as a compatiblitiy string.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e3ha2 edge panel binding
  drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board
  arm64: dts: exynos: Add support for S6E3HA2 edge panel device on TM2e
board

 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 62 +++---
 3 files changed, 96 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

-- 
1.9.1

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


[PATCH 1/3] dt-bindings: Add support for samsung s6e3ha2 edge panel binding

2017-04-13 Thread Hoegeun Kwon
The Samsung s6e3ha2 edge is a 5.65" 1600x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
---
 .../bindings/display/panel/samsung,s6e3ha2-e.txt   | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
new file mode 100644
index 000..09c65f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2-e.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.65" 1600x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2-e"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2-e";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

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


[PATCH 2/3] drm/panel: s6e3ha2: Add support for S6eHEA2 edge panel on TM2e board

2017-04-13 Thread Hoegeun Kwon
This patch considers edge type of panel on TM2e board and The panel
has 1600x2560 resolution in 5.65" physical panel in the TM2e device.

This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for default
compatibility and edge type and select the drm_display_mode of default
and edge type.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 62 ---
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..b4a064a 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
 };
 
+enum s6e3ha2_type {
+   DEFAULT_TYPE,
+   EDGE_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+   const struct drm_display_mode *mode;
+   enum s6e3ha2_type type;
+};
+
 struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+   const struct s6e3ha2_panel_desc *desc;
 };
 
 static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
 static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
 {
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+   if (ctx->desc->type == EDGE_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
-   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
-   0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+   if (ctx->desc->type == DEFAULT_TYPE)
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+   else
+   s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+   0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
 }
 
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
 };
 
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2 = {
+   .mode = _mode,
+   .type = DEFAULT_TYPE,
+};
+
+static const struct drm_display_mode edge_mode = {
+   .clock = 247856,
+   .hdisplay = 1600,
+   .hsync_start = 1600 + 1,
+   .hsync_end = 1600 + 1 + 1,
+   .htotal = 1600 + 1 + 1 + 1,
+   .vdisplay = 2560,
+   .vsync_start = 2560 + 1,
+   .vsync_end = 2560 + 1 + 1,
+   .vtotal = 2560 + 1 + 1 + 15,
+   .vrefresh = 60,
+   .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2_tm2e = {
+   .mode = _mode,
+   .type = EDGE_TYPE,
+};
+
 static int s6e3ha2_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
+   struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(panel->drm, _mode);
+   mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+   ctx->desc->mode->vrefresh);
return -ENOMEM;
}
 
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
 
ctx->dev = dev;
+   ctx->desc = of_device_get_match_data(dev);
 
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
 }
 
 static const struct of_device_id s6e3ha2_of_match[] = {
-   { .compatible = "samsung,s6e3ha2" },
+   { .compatible = "samsung,s6e3ha2",
+ .data = _s6e3ha2_tm2 },
+   { .compatible = "samsung,s6e3ha2-e",
+ .data = _s6e3ha2_tm2e },
{ }
 };
 MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
-- 
1.9.1

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


Re: [PATCH] drm: Document code of conduct

2017-04-13 Thread Gabriel Krisman Bertazi
Daniel Vetter  writes:

> freedesktop.org has adopted a formal code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've already peer-enforced respectful and
> constructive interactions since a long time. But it's good to document
> things properly.
>
> Note: As Daniel Stone mentioned in the announcement fd.o admins
> started chatting with the communities their hosting, which includs the
> X.org foundation board, to figure out how to fan out enforcement and
> allow projects to run things on their own (with fd.o still as the
> fallback).  So the details of enforcement (and appealing decisions)
> might still change, but since this involves the board and lots more
> people it'll take a while to get there. For now this is good enough I
> think.
>
> For the text itself I went with the same blurb as the Wayland project,
> didn't feel creative yet this early in the morning:
>
> https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c
>
> Cc: Daniel Stone 
> Cc: Keith Packard 
> Cc: tfh...@err.no
> Signed-off-by: Daniel Vetter 

Acked-by: Gabriel Krisman Bertazi 

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


drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1953-g4079da1bee73)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed 
(v4.11-rc6-1953-g4079da1bee73)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1953-g4079da1bee73/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1953-g4079da1bee73/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1953-g4079da1bee73
Git Commit: 4079da1bee731e2bf185411abd9ecda25f247890
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 11 unique boards, 4 SoC families, 11 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98604

--- Comment #16 from Michel Dänzer  ---
The patch just disables DRI3 for VDPAU, so it cannot be applied anywhere as is.
It would have to be guarded by an environment variable.

-- 
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 05/22] drm/i915: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
This is a single straightforward conversion from kmap to sg_map.

Signed-off-by: Logan Gunthorpe 
---
 drivers/gpu/drm/i915/i915_gem.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 67b1fc5..1b1b91a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2188,6 +2188,15 @@ static void __i915_gem_object_reset_page_iter(struct 
drm_i915_gem_object *obj)
radix_tree_delete(>mm.get_page.radix, iter.index);
 }
 
+static void i915_gem_object_unmap(const struct drm_i915_gem_object *obj,
+ void *ptr)
+{
+   if (is_vmalloc_addr(ptr))
+   vunmap(ptr);
+   else
+   sg_unmap(obj->mm.pages->sgl, ptr, SG_KMAP);
+}
+
 void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
 enum i915_mm_subclass subclass)
 {
@@ -2215,10 +2224,7 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
void *ptr;
 
ptr = ptr_mask_bits(obj->mm.mapping);
-   if (is_vmalloc_addr(ptr))
-   vunmap(ptr);
-   else
-   kunmap(kmap_to_page(ptr));
+   i915_gem_object_unmap(obj, ptr);
 
obj->mm.mapping = NULL;
}
@@ -2475,8 +2481,11 @@ static void *i915_gem_object_map(const struct 
drm_i915_gem_object *obj,
void *addr;
 
/* A single page can always be kmapped */
-   if (n_pages == 1 && type == I915_MAP_WB)
-   return kmap(sg_page(sgt->sgl));
+   if (n_pages == 1 && type == I915_MAP_WB) {
+   addr = sg_map(sgt->sgl, SG_KMAP);
+   if (IS_ERR(addr))
+   return NULL;
+   }
 
if (n_pages > ARRAY_SIZE(stack_pages)) {
/* Too big for stack -- allocate temporary array instead */
@@ -2543,11 +2552,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
goto err_unpin;
}
 
-   if (is_vmalloc_addr(ptr))
-   vunmap(ptr);
-   else
-   kunmap(kmap_to_page(ptr));
-
+   i915_gem_object_unmap(obj, ptr);
ptr = obj->mm.mapping = NULL;
}
 
-- 
2.1.4

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


[PATCH 18/22] mmc: spi: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
We use the sg_map helper but it's slightly more complicated
as we only check for the error when the mapping actually gets used.
Such that if the mapping failed but wasn't needed then no
error occurs.

Signed-off-by: Logan Gunthorpe 
---
 drivers/mmc/host/mmc_spi.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index e77d79c..82f786d 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -676,9 +676,15 @@ mmc_spi_writeblock(struct mmc_spi_host *host, struct 
spi_transfer *t,
struct scratch  *scratch = host->data;
u32 pattern;
 
-   if (host->mmc->use_spi_crc)
+   if (host->mmc->use_spi_crc) {
+   if (IS_ERR(t->tx_buf))
+   return PTR_ERR(t->tx_buf);
+
scratch->crc_val = cpu_to_be16(
crc_itu_t(0, t->tx_buf, t->len));
+   t->tx_buf += t->len;
+   }
+
if (host->dma_dev)
dma_sync_single_for_device(host->dma_dev,
host->data_dma, sizeof(*scratch),
@@ -743,7 +749,6 @@ mmc_spi_writeblock(struct mmc_spi_host *host, struct 
spi_transfer *t,
return status;
}
 
-   t->tx_buf += t->len;
if (host->dma_dev)
t->tx_dma += t->len;
 
@@ -809,6 +814,11 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct 
spi_transfer *t,
}
leftover = status << 1;
 
+   if (bitshift || host->mmc->use_spi_crc) {
+   if (IS_ERR(t->rx_buf))
+   return PTR_ERR(t->rx_buf);
+   }
+
if (host->dma_dev) {
dma_sync_single_for_device(host->dma_dev,
host->data_dma, sizeof(*scratch),
@@ -860,9 +870,10 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct 
spi_transfer *t,
scratch->crc_val, crc, t->len);
return -EILSEQ;
}
+
+   t->rx_buf += t->len;
}
 
-   t->rx_buf += t->len;
if (host->dma_dev)
t->rx_dma += t->len;
 
@@ -936,11 +947,11 @@ mmc_spi_data_do(struct mmc_spi_host *host, struct 
mmc_command *cmd,
}
 
/* allow pio too; we don't allow highmem */
-   kmap_addr = kmap(sg_page(sg));
+   kmap_addr = sg_map(sg, SG_KMAP);
if (direction == DMA_TO_DEVICE)
-   t->tx_buf = kmap_addr + sg->offset;
+   t->tx_buf = kmap_addr;
else
-   t->rx_buf = kmap_addr + sg->offset;
+   t->rx_buf = kmap_addr;
 
/* transfer each block, and update request status */
while (length) {
@@ -970,7 +981,8 @@ mmc_spi_data_do(struct mmc_spi_host *host, struct 
mmc_command *cmd,
/* discard mappings */
if (direction == DMA_FROM_DEVICE)
flush_kernel_dcache_page(sg_page(sg));
-   kunmap(sg_page(sg));
+   if (!IS_ERR(kmap_addr))
+   sg_unmap(sg, kmap_addr, SG_KMAP);
if (dma_dev)
dma_unmap_page(dma_dev, dma_addr, PAGE_SIZE, dir);
 
-- 
2.1.4

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


[PATCH 04/22] target: Make use of the new sg_map function at 16 call sites

2017-04-13 Thread Logan Gunthorpe
Fairly straightforward conversions in all spots. In a couple of cases
any error gets propogated up should sg_map fail. In other
cases a warning is issued if the kmap fails seeing there's no
clear error path. This should not be an issue until someone tries to
use unmappable memory in the sgl with this driver.

Signed-off-by: Logan Gunthorpe 
---
 drivers/target/iscsi/iscsi_target.c|  27 +---
 drivers/target/target_core_rd.c|   3 +-
 drivers/target/target_core_sbc.c   | 122 +++--
 drivers/target/target_core_transport.c |  18 +++--
 drivers/target/target_core_user.c  |  43 
 include/target/target_core_backend.h   |   4 +-
 6 files changed, 149 insertions(+), 68 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target.c 
b/drivers/target/iscsi/iscsi_target.c
index a918024..e3e0d8f 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -579,7 +579,7 @@ iscsit_xmit_nondatain_pdu(struct iscsi_conn *conn, struct 
iscsi_cmd *cmd,
 }
 
 static int iscsit_map_iovec(struct iscsi_cmd *, struct kvec *, u32, u32);
-static void iscsit_unmap_iovec(struct iscsi_cmd *);
+static void iscsit_unmap_iovec(struct iscsi_cmd *, struct kvec *);
 static u32 iscsit_do_crypto_hash_sg(struct ahash_request *, struct iscsi_cmd *,
u32, u32, u32, u8 *);
 static int
@@ -646,7 +646,7 @@ iscsit_xmit_datain_pdu(struct iscsi_conn *conn, struct 
iscsi_cmd *cmd,
 
ret = iscsit_fe_sendpage_sg(cmd, conn);
 
-   iscsit_unmap_iovec(cmd);
+   iscsit_unmap_iovec(cmd, >iov_data[1]);
 
if (ret < 0) {
iscsit_tx_thread_wait_for_tcp(conn);
@@ -925,7 +925,10 @@ static int iscsit_map_iovec(
while (data_length) {
u32 cur_len = min_t(u32, data_length, sg->length - page_off);
 
-   iov[i].iov_base = kmap(sg_page(sg)) + sg->offset + page_off;
+   iov[i].iov_base = sg_map_offset(sg, page_off, SG_KMAP);
+   if (IS_ERR(iov[i].iov_base))
+   goto map_err;
+
iov[i].iov_len = cur_len;
 
data_length -= cur_len;
@@ -937,17 +940,25 @@ static int iscsit_map_iovec(
cmd->kmapped_nents = i;
 
return i;
+
+map_err:
+   cmd->kmapped_nents = i - 1;
+   iscsit_unmap_iovec(cmd, iov);
+   return -1;
 }
 
-static void iscsit_unmap_iovec(struct iscsi_cmd *cmd)
+static void iscsit_unmap_iovec(struct iscsi_cmd *cmd, struct kvec *iov)
 {
u32 i;
struct scatterlist *sg;
+   unsigned int page_off = cmd->first_data_sg_off;
 
sg = cmd->first_data_sg;
 
-   for (i = 0; i < cmd->kmapped_nents; i++)
-   kunmap(sg_page([i]));
+   for (i = 0; i < cmd->kmapped_nents; i++) {
+   sg_unmap_offset([i], iov[i].iov_base, page_off, SG_KMAP);
+   page_off = 0;
+   }
 }
 
 static void iscsit_ack_from_expstatsn(struct iscsi_conn *conn, u32 exp_statsn)
@@ -1610,7 +1621,7 @@ iscsit_get_dataout(struct iscsi_conn *conn, struct 
iscsi_cmd *cmd,
 
rx_got = rx_data(conn, >iov_data[0], iov_count, rx_size);
 
-   iscsit_unmap_iovec(cmd);
+   iscsit_unmap_iovec(cmd, iov);
 
if (rx_got != rx_size)
return -1;
@@ -2626,7 +2637,7 @@ static int iscsit_handle_immediate_data(
 
rx_got = rx_data(conn, >iov_data[0], iov_count, rx_size);
 
-   iscsit_unmap_iovec(cmd);
+   iscsit_unmap_iovec(cmd, cmd->iov_data);
 
if (rx_got != rx_size) {
iscsit_rx_thread_wait_for_tcp(conn);
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index ddc216c..22c5ad5 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -431,7 +431,8 @@ static sense_reason_t rd_do_prot_rw(struct se_cmd *cmd, 
bool is_read)
cmd->t_prot_sg, 0);
 
if (!rc)
-   sbc_dif_copy_prot(cmd, sectors, is_read, prot_sg, prot_offset);
+   rc = sbc_dif_copy_prot(cmd, sectors, is_read, prot_sg,
+  prot_offset);
 
return rc;
 }
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index c194063..67cb420 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -420,17 +420,17 @@ static sense_reason_t xdreadwrite_callback(struct se_cmd 
*cmd, bool success,
 
offset = 0;
for_each_sg(cmd->t_bidi_data_sg, sg, cmd->t_bidi_data_nents, count) {
-   addr = kmap_atomic(sg_page(sg));
-   if (!addr) {
+   addr = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(addr)) {
ret = TCM_OUT_OF_RESOURCES;
goto out;
}
 
for (i = 0; i < sg->length; i++)
-   *(addr + sg->offset + i) ^= *(buf + offset + i);
+   

[PATCH 06/22] crypto: hifn_795x: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Conversion of a couple kmap_atomic instances to the sg_map helper
function.

However, it looks like there was a bug in the original code: the source
scatter lists offset (t->offset) was passed to ablkcipher_get which
added it to the destination address. This doesn't make a lot of
sense, but t->offset is likely always zero anyway. So, this patch cleans
that brokeness up.

Also, a change to the error path: if ablkcipher_get failed, everything
seemed to proceed as if it hadn't. Setting 'error' should hopefully
clear that up.

Signed-off-by: Logan Gunthorpe 
---
 drivers/crypto/hifn_795x.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index e09d405..8e2c6a9 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -1619,7 +1619,7 @@ static int hifn_start_device(struct hifn_device *dev)
return 0;
 }
 
-static int ablkcipher_get(void *saddr, unsigned int *srestp, unsigned int 
offset,
+static int ablkcipher_get(void *saddr, unsigned int *srestp,
struct scatterlist *dst, unsigned int size, unsigned int 
*nbytesp)
 {
unsigned int srest = *srestp, nbytes = *nbytesp, copy;
@@ -1632,15 +1632,17 @@ static int ablkcipher_get(void *saddr, unsigned int 
*srestp, unsigned int offset
while (size) {
copy = min3(srest, dst->length, size);
 
-   daddr = kmap_atomic(sg_page(dst));
-   memcpy(daddr + dst->offset + offset, saddr, copy);
-   kunmap_atomic(daddr);
+   daddr = sg_map(dst, SG_KMAP_ATOMIC);
+   if (IS_ERR(daddr))
+   return PTR_ERR(daddr);
+
+   memcpy(daddr, saddr, copy);
+   sg_unmap(dst, daddr, SG_KMAP_ATOMIC);
 
nbytes -= copy;
size -= copy;
srest -= copy;
saddr += copy;
-   offset = 0;
 
pr_debug("%s: copy: %u, size: %u, srest: %u, nbytes: %u.\n",
 __func__, copy, size, srest, nbytes);
@@ -1671,11 +1673,12 @@ static inline void hifn_complete_sa(struct hifn_device 
*dev, int i)
 
 static void hifn_process_ready(struct ablkcipher_request *req, int error)
 {
+   int err;
struct hifn_request_context *rctx = ablkcipher_request_ctx(req);
 
if (rctx->walk.flags & ASYNC_FLAGS_MISALIGNED) {
unsigned int nbytes = req->nbytes;
-   int idx = 0, err;
+   int idx = 0;
struct scatterlist *dst, *t;
void *saddr;
 
@@ -1695,17 +1698,24 @@ static void hifn_process_ready(struct 
ablkcipher_request *req, int error)
continue;
}
 
-   saddr = kmap_atomic(sg_page(t));
+   saddr = sg_map(t, SG_KMAP_ATOMIC);
+   if (IS_ERR(saddr)) {
+   if (!error)
+   error = PTR_ERR(saddr);
+   break;
+   }
+
+   err = ablkcipher_get(saddr, >length,
+dst, nbytes, );
+   sg_unmap(t, saddr, SG_KMAP_ATOMIC);
 
-   err = ablkcipher_get(saddr, >length, t->offset,
-   dst, nbytes, );
if (err < 0) {
-   kunmap_atomic(saddr);
+   if (!error)
+   error = err;
break;
}
 
idx += err;
-   kunmap_atomic(saddr);
}
 
hifn_cipher_walk_exit(>walk);
-- 
2.1.4

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


[PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion to the new function.

Signed-off-by: Logan Gunthorpe 
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 0ce92c8..2d8c8bc 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -842,7 +842,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct 
scsi_cmnd *scsicmd)
struct scatterlist *sg;
unsigned int i;
char *this_page;
-   char *this_page_orig;
int bufind = 0;
struct visordisk_info *vdisk;
struct visorhba_devdata *devdata;
@@ -869,11 +868,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct 
scsi_cmnd *scsicmd)
 
sg = scsi_sglist(scsicmd);
for (i = 0; i < scsi_sg_count(scsicmd); i++) {
-   this_page_orig = kmap_atomic(sg_page(sg + i));
-   this_page = (void *)((unsigned long)this_page_orig |
-sg[i].offset);
+   this_page = sg_map(sg + i, SG_KMAP_ATOMIC);
+   if (IS_ERR(this_page)) {
+   scsicmd->result = DID_ERROR << 16;
+   return;
+   }
+
memcpy(this_page, buf + bufind, sg[i].length);
-   kunmap_atomic(this_page_orig);
+   sg_unmap(sg + i, this_page, SG_KMAP_ATOMIC);
}
} else {
devdata = (struct visorhba_devdata *)scsidev->host->hostdata;
-- 
2.1.4

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


[PATCH 20/22] mmc: sdricoh_cs: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
This is a straightforward conversion to the new function.

Signed-off-by: Logan Gunthorpe 
---
 drivers/mmc/host/sdricoh_cs.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c
index 5ff26ab..7eeed23 100644
--- a/drivers/mmc/host/sdricoh_cs.c
+++ b/drivers/mmc/host/sdricoh_cs.c
@@ -319,16 +319,20 @@ static void sdricoh_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
for (i = 0; i < data->blocks; i++) {
size_t len = data->blksz;
u8 *buf;
-   struct page *page;
int result;
-   page = sg_page(data->sg);
 
-   buf = kmap(page) + data->sg->offset + (len * i);
+   buf = sg_map_offset(data->sg, (len * i), SG_KMAP);
+   if (IS_ERR(buf)) {
+   cmd->error = PTR_ERR(buf);
+   break;
+   }
+
result =
sdricoh_blockio(host,
data->flags & MMC_DATA_READ, buf, len);
-   kunmap(page);
-   flush_dcache_page(page);
+   sg_unmap_offset(data->sg, buf, (len * i), SG_KMAP);
+
+   flush_dcache_page(sg_page(data->sg));
if (result) {
dev_err(dev, "sdricoh_request: cmd %i "
"block transfer failed\n", cmd->opcode);
-- 
2.1.4

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


[PATCH 11/22] RDS: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion except there's no error path, so we WARN if
the sg_map fails.

Signed-off-by: Logan Gunthorpe 
---
 net/rds/ib_recv.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index e10624a..7f8fa99 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -801,9 +801,20 @@ static void rds_ib_cong_recv(struct rds_connection *conn,
to_copy = min(RDS_FRAG_SIZE - frag_off, PAGE_SIZE - map_off);
BUG_ON(to_copy & 7); /* Must be 64bit aligned. */
 
-   addr = kmap_atomic(sg_page(>f_sg));
+   addr = sg_map(>f_sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(addr)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return;
+   }
 
-   src = addr + frag->f_sg.offset + frag_off;
+   src = addr + frag_off;
dst = (void *)map->m_page_addrs[map_page] + map_off;
for (k = 0; k < to_copy; k += 8) {
/* Record ports that became uncongested, ie
@@ -811,7 +822,7 @@ static void rds_ib_cong_recv(struct rds_connection *conn,
uncongested |= ~(*src) & *dst;
*dst++ = *src++;
}
-   kunmap_atomic(addr);
+   sg_unmap(>f_sg, addr, SG_KMAP_ATOMIC);
 
copied += to_copy;
 
-- 
2.1.4

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


[PATCH 01/22] scatterlist: Introduce sg_map helper functions

2017-04-13 Thread Logan Gunthorpe
This patch introduces functions which kmap the pages inside an sgl. Two
variants are provided: one if an offset is required and one if the
offset is zero. These functions replace a common pattern of
kmap(sg_page(sg)) that is used in about 50 places within the kernel.

The motivation for this work is to eventually safely support sgls that
contain io memory. In order for that to work, any access to the contents
of an iomem SGL will need to be done with iomemcpy or hit some warning.
(The exact details of how this will work have yet to be worked out.)
Having all the kmaps in one place is just a first step in that
direction. Additionally, seeing this helps cut down the users of sg_page,
it should make any effort to go to struct-page-less DMAs a little
easier (should that idea ever swing back into favour again).

A flags option is added to select between a regular or atomic mapping so
these functions can replace kmap(sg_page or kmap_atomic(sg_page.
Future work may expand this to have flags for using page_address or
vmap. Much further in the future, there may be a flag to allocate memory
and copy the data from/to iomem.

We also add the semantic that sg_map can fail to create a mapping,
despite the fact that the current code this is replacing is assumed to
never fail and the current version of these functions cannot fail. This
is to support iomem which either have to fail to create the mapping or
allocate memory as a bounce buffer which itself can fail.

Also, in terms of cleanup, a few of the existing kmap(sg_page) users
play things a bit loose in terms of whether they apply sg->offset
so using these helper functions should help avoid such issues.

Signed-off-by: Logan Gunthorpe 
---
 drivers/dma-buf/dma-buf.c   |  3 ++
 include/linux/scatterlist.h | 97 +
 2 files changed, 100 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0007b79..b95934b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -37,6 +37,9 @@
 
 #include 
 
+/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */
+#undef kunmap_atomic
+
 static inline int is_dma_buf_file(struct file *);
 
 struct dma_buf_list {
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe..acd4d73 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct scatterlist {
@@ -126,6 +127,102 @@ static inline struct page *sg_page(struct scatterlist *sg)
return (struct page *)((sg)->page_link & ~0x3);
 }
 
+#define SG_KMAP(1 << 0)/* create a mapping with kmap */
+#define SG_KMAP_ATOMIC (1 << 1)/* create a mapping with kmap_atomic */
+
+/**
+ * sg_map_offset - kmap a page inside an sgl
+ * @sg:SG entry
+ * @offset:Offset into entry
+ * @flags: Flags for creating the mapping
+ *
+ * Description:
+ *   Use this function to map a page in the scatterlist at the specified
+ *   offset. sg->offset is already added for you. Note: the semantics of
+ *   this function are that it may fail. Thus, its output should be checked
+ *   with IS_ERR and PTR_ERR. Otherwise, a pointer to the specified offset
+ *   in the mapped page is returned.
+ *
+ *   Flags can be any of:
+ * * SG_KMAP- Use kmap to create the mapping
+ * * SG_KMAP_ATOMIC - Use kmap_atomic to map the page atommically.
+ *Thus, the rules of that function apply: the cpu
+ *may not sleep until it is unmaped.
+ *
+ *   Also, consider carefully whether this function is appropriate. It is
+ *   largely not recommended for new code and if the sgl came from another
+ *   subsystem and you don't know what kind of memory might be in the list
+ *   then you definitely should not call it. Non-mappable memory may be in
+ *   the sgl and thus this function may fail unexpectedly.
+ **/
+static inline void *sg_map_offset(struct scatterlist *sg, size_t offset,
+  int flags)
+{
+   struct page *pg;
+   unsigned int pg_off;
+
+   offset += sg->offset;
+   pg = nth_page(sg_page(sg), offset >> PAGE_SHIFT);
+   pg_off = offset_in_page(offset);
+
+   if (flags & SG_KMAP_ATOMIC)
+   return kmap_atomic(pg) + pg_off;
+   else
+   return kmap(pg) + pg_off;
+}
+
+/**
+ * sg_unkmap_offset - unmap a page that was mapped with sg_map_offset
+ * @sg:SG entry
+ * @addr:  address returned by sg_map_offset
+ * @offset:Offset into entry (same as specified for sg_map_offset)
+ * @flags: Flags, which are the same specified for sg_map_offset
+ *
+ * Description:
+ *   Unmap the page that was mapped with sg_map_offset
+ *
+ **/
+static inline void sg_unmap_offset(struct scatterlist *sg, void *addr,
+   size_t offset, int flags)
+{
+   

[PATCH 02/22] nvmet: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
This is a straight forward conversion in two places. Should kmap fail,
the code will return an INVALD_DATA error in the completion.

Signed-off-by: Logan Gunthorpe 
---
 drivers/nvme/target/fabrics-cmd.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/nvme/target/fabrics-cmd.c 
b/drivers/nvme/target/fabrics-cmd.c
index 8bd022af..f62a634 100644
--- a/drivers/nvme/target/fabrics-cmd.c
+++ b/drivers/nvme/target/fabrics-cmd.c
@@ -122,7 +122,11 @@ static void nvmet_execute_admin_connect(struct nvmet_req 
*req)
struct nvmet_ctrl *ctrl = NULL;
u16 status = 0;
 
-   d = kmap(sg_page(req->sg)) + req->sg->offset;
+   d = sg_map(req->sg, SG_KMAP);
+   if (IS_ERR(d)) {
+   status = NVME_SC_SGL_INVALID_DATA;
+   goto out;
+   }
 
/* zero out initial completion result, assign values as needed */
req->rsp->result.u32 = 0;
@@ -158,7 +162,7 @@ static void nvmet_execute_admin_connect(struct nvmet_req 
*req)
req->rsp->result.u16 = cpu_to_le16(ctrl->cntlid);
 
 out:
-   kunmap(sg_page(req->sg));
+   sg_unmap(req->sg, d, SG_KMAP);
nvmet_req_complete(req, status);
 }
 
@@ -170,7 +174,11 @@ static void nvmet_execute_io_connect(struct nvmet_req *req)
u16 qid = le16_to_cpu(c->qid);
u16 status = 0;
 
-   d = kmap(sg_page(req->sg)) + req->sg->offset;
+   d = sg_map(req->sg, SG_KMAP);
+   if (IS_ERR(d)) {
+   status = NVME_SC_SGL_INVALID_DATA;
+   goto out;
+   }
 
/* zero out initial completion result, assign values as needed */
req->rsp->result.u32 = 0;
@@ -205,7 +213,7 @@ static void nvmet_execute_io_connect(struct nvmet_req *req)
pr_info("adding queue %d to ctrl %d.\n", qid, ctrl->cntlid);
 
 out:
-   kunmap(sg_page(req->sg));
+   sg_unmap(req->sg, d, SG_KMAP);
nvmet_req_complete(req, status);
return;
 
-- 
2.1.4

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


[PATCH 00/22] Introduce common scatterlist map function

2017-04-13 Thread Logan Gunthorpe
Hi Everyone,

As part of my effort to enable P2P DMA transactions with PCI cards,
we've identified the need to be able to safely put IO memory into
scatterlists (and eventually other spots). This probably involves a
conversion from struct page to pfn_t but that migration is a ways off
and those decisions are yet to be made.

As an initial step in that direction, I've started cleaning up some of the
scatterlist code by trying to carve out a better defined layer between it
and it's users. The longer term goal would be to remove sg_page or replace
it with something that can potentially fail.

This patchset is the first step in that effort. I've introduced
a common function to map scatterlist memory and converted all the common
kmap(sg_page()) cases. This removes about 66 sg_page calls (of ~331).

Seeing this is a fairly large cleanup set that touches a wide swath of
the kernel I have limited the people I've sent this to. I'd suggest we look
toward merging the first patch and then I can send the individual subsystem
patches on to their respective maintainers and get them merged
independantly. (This is to avoid the conflicts I created with my last
cleanup set... Sorry) Though, I'm certainly open to other suggestions to get
it merged.

The patchset is based on v4.11-rc6 and can be found in the sg_map
branch from this git tree:

https://github.com/sbates130272/linux-p2pmem.git

Thanks,

Logan


Logan Gunthorpe (22):
  scatterlist: Introduce sg_map helper functions
  nvmet: Make use of the new sg_map helper function
  libiscsi: Make use of new the sg_map helper function
  target: Make use of the new sg_map function at 16 call sites
  drm/i915: Make use of the new sg_map helper function
  crypto: hifn_795x: Make use of the new sg_map helper function
  crypto: shash, caam: Make use of the new sg_map helper function
  crypto: chcr: Make use of the new sg_map helper function
  dm-crypt: Make use of the new sg_map helper in 4 call sites
  staging: unisys: visorbus: Make use of the new sg_map helper function
  RDS: Make use of the new sg_map helper function
  scsi: ipr, pmcraid, isci: Make use of the new sg_map helper in 4 call
sites
  scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper
function
  scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper
function
  scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers
  xen-blkfront: Make use of the new sg_map helper function
  mmc: sdhci: Make use of the new sg_map helper function
  mmc: spi: Make use of the new sg_map helper function
  mmc: tmio: Make use of the new sg_map helper function
  mmc: sdricoh_cs: Make use of the new sg_map helper function
  mmc: tifm_sd: Make use of the new sg_map helper function
  memstick: Make use of the new sg_map helper function

 crypto/shash.c  |   9 +-
 drivers/block/xen-blkfront.c|  33 +--
 drivers/crypto/caam/caamalg.c   |   8 +-
 drivers/crypto/chelsio/chcr_algo.c  |  28 +++---
 drivers/crypto/hifn_795x.c  |  32 ---
 drivers/dma-buf/dma-buf.c   |   3 +
 drivers/gpu/drm/i915/i915_gem.c |  27 +++---
 drivers/md/dm-crypt.c   |  38 +---
 drivers/memstick/host/jmb38x_ms.c   |  23 -
 drivers/memstick/host/tifm_ms.c |  22 -
 drivers/mmc/host/mmc_spi.c  |  26 +++--
 drivers/mmc/host/sdhci.c|  35 ++-
 drivers/mmc/host/sdricoh_cs.c   |  14 ++-
 drivers/mmc/host/tifm_sd.c  |  88 +
 drivers/mmc/host/tmio_mmc.h |  12 ++-
 drivers/mmc/host/tmio_mmc_dma.c |   5 +
 drivers/mmc/host/tmio_mmc_pio.c |  24 +
 drivers/nvme/target/fabrics-cmd.c   |  16 +++-
 drivers/scsi/arcmsr/arcmsr_hba.c|  16 +++-
 drivers/scsi/csiostor/csio_scsi.c   |  54 +--
 drivers/scsi/cxgbi/libcxgbi.c   |   5 +
 drivers/scsi/gdth.c |   9 +-
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c  |  14 ++-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c  |  13 ++-
 drivers/scsi/ipr.c  |  27 +++---
 drivers/scsi/ips.c  |   8 +-
 drivers/scsi/isci/request.c |  42 
 drivers/scsi/libfc/fc_libfc.c   |  49 ++
 drivers/scsi/libiscsi_tcp.c |  32 ---
 drivers/scsi/megaraid.c |   9 +-
 drivers/scsi/mvsas/mv_sas.c |  10 +-
 drivers/scsi/pmcraid.c  |  19 ++--
 drivers/staging/unisys/visorhba/visorhba_main.c |  12 ++-
 drivers/target/iscsi/iscsi_target.c |  27 --
 drivers/target/target_core_rd.c |   3 +-
 drivers/target/target_core_sbc.c| 122 +---
 

[PATCH 13/22] scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Very straightforward conversion of three scsi drivers.

Signed-off-by: Logan Gunthorpe 
---
 drivers/scsi/gdth.c|  9 +++--
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 +-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 +
 drivers/scsi/mvsas/mv_sas.c| 10 +-
 4 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index d020a13..82c9fba 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -2301,10 +2301,15 @@ static void gdth_copy_internal_data(gdth_ha_str *ha, 
Scsi_Cmnd *scp,
 return;
 }
 local_irq_save(flags);
-address = kmap_atomic(sg_page(sl)) + sl->offset;
+address = sg_map(sl, SG_KMAP_ATOMIC);
+if (IS_ERR(address)) {
+scp->result = DID_ERROR << 16;
+return;
+   }
+
 memcpy(address, buffer, cpnow);
 flush_dcache_page(sg_page(sl));
-kunmap_atomic(address);
+sg_unmap(sl, address, SG_KMAP_ATOMIC);
 local_irq_restore(flags);
 if (cpsum == cpcount)
 break;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 854fbea..30408f8 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1377,18 +1377,22 @@ static int slot_complete_v1_hw(struct hisi_hba 
*hisi_hba,
void *to;
struct scatterlist *sg_resp = >smp_task.smp_resp;
 
-   ts->stat = SAM_STAT_GOOD;
-   to = kmap_atomic(sg_page(sg_resp));
+   to = sg_map(sg_resp, SG_KMAP_ATOMIC);
+   if (IS_ERR(to)) {
+   dev_err(dev, "slot complete: error mapping memory");
+   ts->stat = SAS_SG_ERR;
+   break;
+   }
 
+   ts->stat = SAM_STAT_GOOD;
dma_unmap_sg(dev, >smp_task.smp_resp, 1,
 DMA_FROM_DEVICE);
dma_unmap_sg(dev, >smp_task.smp_req, 1,
 DMA_TO_DEVICE);
-   memcpy(to + sg_resp->offset,
-  slot->status_buffer +
+   memcpy(to, slot->status_buffer +
   sizeof(struct hisi_sas_err_record),
   sg_dma_len(sg_resp));
-   kunmap_atomic(to);
+   sg_unmap(sg_resp, to, SG_KMAP_ATOMIC);
break;
}
case SAS_PROTOCOL_SATA:
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 1b21445..0907947 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1796,18 +1796,23 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba, struct 
hisi_sas_slot *slot,
struct scatterlist *sg_resp = >smp_task.smp_resp;
void *to;
 
+   to = sg_map(sg_resp, SG_KMAP_ATOMIC);
+   if (IS_ERR(to)) {
+   dev_err(dev, "slot complete: error mapping memory");
+   ts->stat = SAS_SG_ERR;
+   break;
+   }
+
ts->stat = SAM_STAT_GOOD;
-   to = kmap_atomic(sg_page(sg_resp));
 
dma_unmap_sg(dev, >smp_task.smp_resp, 1,
 DMA_FROM_DEVICE);
dma_unmap_sg(dev, >smp_task.smp_req, 1,
 DMA_TO_DEVICE);
-   memcpy(to + sg_resp->offset,
-  slot->status_buffer +
+   memcpy(to, slot->status_buffer +
   sizeof(struct hisi_sas_err_record),
   sg_dma_len(sg_resp));
-   kunmap_atomic(to);
+   sg_unmap(sg_resp, to, SG_KMAP_ATOMIC);
break;
}
case SAS_PROTOCOL_SATA:
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..374d0e0 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -1798,11 +1798,11 @@ int mvs_slot_complete(struct mvs_info *mvi, u32 
rx_desc, u32 flags)
case SAS_PROTOCOL_SMP: {
struct scatterlist *sg_resp = >smp_task.smp_resp;
tstat->stat = SAM_STAT_GOOD;
-   to = kmap_atomic(sg_page(sg_resp));
-   memcpy(to + sg_resp->offset,
-   slot->response + sizeof(struct mvs_err_info),
-   sg_dma_len(sg_resp));
-   kunmap_atomic(to);
+   to = sg_map(sg_resp, SG_KMAP_ATOMIC);
+   memcpy(to,
+  slot->response + sizeof(struct mvs_err_info),
+  sg_dma_len(sg_resp));
+   sg_unmap(sg_resp, to, SG_KMAP_ATOMIC);
  

[PATCH 03/22] libiscsi: Make use of new the sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Convert the kmap and kmap_atomic uses to the sg_map function. We now
store the flags for the kmap instead of a boolean to indicate
atomicitiy. We also propogate a possible kmap error down and create
a new ISCSI_TCP_INTERNAL_ERR error type for this.

Signed-off-by: Logan Gunthorpe 
---
 drivers/scsi/cxgbi/libcxgbi.c |  5 +
 drivers/scsi/libiscsi_tcp.c   | 32 
 include/scsi/libiscsi_tcp.h   |  3 ++-
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index bd7d39e..e38d0c1 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1556,6 +1556,11 @@ static inline int read_pdu_skb(struct iscsi_conn *conn,
 */
iscsi_conn_printk(KERN_ERR, conn, "Invalid pdu or skb.");
return -EFAULT;
+   case ISCSI_TCP_INTERNAL_ERR:
+   pr_info("skb 0x%p, off %u, %d, TCP_INTERNAL_ERR.\n",
+   skb, offset, offloaded);
+   iscsi_conn_printk(KERN_ERR, conn, "Internal error.");
+   return -EFAULT;
case ISCSI_TCP_SEGMENT_DONE:
log_debug(1 << CXGBI_DBG_PDU_RX,
"skb 0x%p, off %u, %d, TCP_SEG_DONE, rc %d.\n",
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
index 63a1d69..a2427699 100644
--- a/drivers/scsi/libiscsi_tcp.c
+++ b/drivers/scsi/libiscsi_tcp.c
@@ -133,25 +133,23 @@ static void iscsi_tcp_segment_map(struct iscsi_segment 
*segment, int recv)
if (page_count(sg_page(sg)) >= 1 && !recv)
return;
 
-   if (recv) {
-   segment->atomic_mapped = true;
-   segment->sg_mapped = kmap_atomic(sg_page(sg));
-   } else {
-   segment->atomic_mapped = false;
-   /* the xmit path can sleep with the page mapped so use kmap */
-   segment->sg_mapped = kmap(sg_page(sg));
+   /* the xmit path can sleep with the page mapped so don't use atomic */
+   segment->sg_map_flags = recv ? SG_KMAP_ATOMIC : SG_KMAP;
+   segment->sg_mapped = sg_map(sg, segment->sg_map_flags);
+
+   if (IS_ERR(segment->sg_mapped)) {
+   segment->sg_mapped = NULL;
+   return;
}
 
-   segment->data = segment->sg_mapped + sg->offset + segment->sg_offset;
+   segment->data = segment->sg_mapped + segment->sg_offset;
 }
 
 void iscsi_tcp_segment_unmap(struct iscsi_segment *segment)
 {
if (segment->sg_mapped) {
-   if (segment->atomic_mapped)
-   kunmap_atomic(segment->sg_mapped);
-   else
-   kunmap(sg_page(segment->sg));
+   sg_unmap(segment->sg, segment->sg_mapped,
+ segment->sg_map_flags);
segment->sg_mapped = NULL;
segment->data = NULL;
}
@@ -304,6 +302,9 @@ iscsi_tcp_segment_recv(struct iscsi_tcp_conn *tcp_conn,
break;
}
 
+   if (segment->data)
+   return -EFAULT;
+
copy = min(len - copied, segment->size - segment->copied);
ISCSI_DBG_TCP(tcp_conn->iscsi_conn, "copying %d\n", copy);
memcpy(segment->data + segment->copied, ptr + copied, copy);
@@ -927,6 +928,13 @@ int iscsi_tcp_recv_skb(struct iscsi_conn *conn, struct 
sk_buff *skb,
  avail);
rc = iscsi_tcp_segment_recv(tcp_conn, segment, ptr, avail);
BUG_ON(rc == 0);
+   if (rc < 0) {
+   ISCSI_DBG_TCP(conn, "memory fault. Consumed %d\n",
+ consumed);
+   *status = ISCSI_TCP_INTERNAL_ERR;
+   goto skb_done;
+   }
+
consumed += rc;
 
if (segment->total_copied >= segment->total_size) {
diff --git a/include/scsi/libiscsi_tcp.h b/include/scsi/libiscsi_tcp.h
index 30520d5..58c79af 100644
--- a/include/scsi/libiscsi_tcp.h
+++ b/include/scsi/libiscsi_tcp.h
@@ -47,7 +47,7 @@ struct iscsi_segment {
struct scatterlist  *sg;
void*sg_mapped;
unsigned intsg_offset;
-   boolatomic_mapped;
+   int sg_map_flags;
 
iscsi_segment_done_fn_t *done;
 };
@@ -92,6 +92,7 @@ enum {
ISCSI_TCP_SKB_DONE, /* skb is out of data */
ISCSI_TCP_CONN_ERR, /* iscsi layer has fired a conn err */
ISCSI_TCP_SUSPENDED,/* conn is suspended */
+   ISCSI_TCP_INTERNAL_ERR, /* an internal error occurred */
 };
 
 extern void iscsi_tcp_hdr_recv_prep(struct iscsi_tcp_conn *tcp_conn);
-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [Nouveau] [PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Karol Herbst
Also your series got a little messed up, there are two 1/4 patches,
and both are different.

2017-04-13 11:07 GMT+02:00 Oscar Salvador :
> Hi again,
>
> I've split the patches as Karol Herbst suggested.
> I hope now it's fine.
>
> This series of patches introduce the new hwmon_device_register_with_info
> and gets rid of the old hwmon_device_register.
>
> This patch adds the default sensors with their possible config values.
> Just to prepare for the next patches
>
>
> --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
> 19:18:09.638073562 +0200
> +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
> 19:19:44.244797202 +0200
> @@ -692,6 +692,78 @@ static const struct attribute_group hwmo
>  static const struct attribute_group hwmon_power_caps_attrgroup = {
> .attrs = hwmon_power_caps_attributes,
>  };
> +
> +static const u32 nouveau_config_chip[] = {
> +   HWMON_C_UPDATE_INTERVAL,
> +   0
> +};
> +
> +static const u32 nouveau_config_in[] = {
> +   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
> +   0
> +};
> +
> +static const u32 nouveau_config_temp[] = {
> +   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
> +   HWMON_T_EMERGENCY_HYST,
> +   0
> +};
> +
> +static const u32 nouveau_config_fan[] = {
> +   HWMON_F_INPUT,
> +   0
> +};
> +
> +static const u32 nouveau_config_pwm[] = {
> +   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
> +   0
> +};
> +
> +static const u32 nouveau_config_power[] = {
> +   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
> +   0
> +};
> +
> +static const struct hwmon_channel_info nouveau_chip = {
> +   .type = hwmon_chip,
> +   .config = nouveau_config_chip,
> +};
> +
> +static const struct hwmon_channel_info nouveau_temp = {
> +   .type = hwmon_temp,
> +   .config = nouveau_config_temp,
> +};
> +
> +static const struct hwmon_channel_info nouveau_fan = {
> +   .type = hwmon_fan,
> +   .config = nouveau_config_fan,
> +};
> +
> +static const struct hwmon_channel_info nouveau_in = {
> +   .type = hwmon_in,
> +   .config = nouveau_config_in,
> +};
> +
> +static const struct hwmon_channel_info nouveau_pwm = {
> +   .type = hwmon_pwm,
> +   .config = nouveau_config_pwm,
> +};
> +
> +static const struct hwmon_channel_info nouveau_power = {
> +   .type = hwmon_power,
> +   .config = nouveau_config_power,
> +};
> +
> +static const struct hwmon_channel_info *nouveau_info[] = {
> +   _chip,
> +   _temp,
> +   _fan,
> +   _in,
> +   _pwm,
> +   _power,
> +   NULL
> +};
>  #endif
>
>  int
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 12/22] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper in 4 call sites

2017-04-13 Thread Logan Gunthorpe
Very straightforward conversion of three scsi drivers.

Signed-off-by: Logan Gunthorpe 
---
 drivers/scsi/ipr.c  | 27 ++-
 drivers/scsi/isci/request.c | 42 +-
 drivers/scsi/pmcraid.c  | 19 ---
 3 files changed, 51 insertions(+), 37 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index b29afaf..f98f251 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -3853,7 +3853,7 @@ static void ipr_free_ucode_buffer(struct ipr_sglist 
*sglist)
 static int ipr_copy_ucode_buffer(struct ipr_sglist *sglist,
 u8 *buffer, u32 len)
 {
-   int bsize_elem, i, result = 0;
+   int bsize_elem, i;
struct scatterlist *scatterlist;
void *kaddr;
 
@@ -3863,32 +3863,33 @@ static int ipr_copy_ucode_buffer(struct ipr_sglist 
*sglist,
scatterlist = sglist->scatterlist;
 
for (i = 0; i < (len / bsize_elem); i++, buffer += bsize_elem) {
-   struct page *page = sg_page([i]);
+   kaddr = sg_map([i], SG_KMAP);
+   if (IS_ERR(kaddr)) {
+   ipr_trace;
+   return PTR_ERR(kaddr);
+   }
 
-   kaddr = kmap(page);
memcpy(kaddr, buffer, bsize_elem);
-   kunmap(page);
+   sg_unmap([i], kaddr, SG_KMAP);
 
scatterlist[i].length = bsize_elem;
-
-   if (result != 0) {
-   ipr_trace;
-   return result;
-   }
}
 
if (len % bsize_elem) {
-   struct page *page = sg_page([i]);
+   kaddr = sg_map([i], SG_KMAP);
+   if (IS_ERR(kaddr)) {
+   ipr_trace;
+   return PTR_ERR(kaddr);
+   }
 
-   kaddr = kmap(page);
memcpy(kaddr, buffer, len % bsize_elem);
-   kunmap(page);
+   sg_unmap([i], kaddr, SG_KMAP);
 
scatterlist[i].length = len % bsize_elem;
}
 
sglist->buffer_len = len;
-   return result;
+   return 0;
 }
 
 /**
diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index 47f66e9..66d6596 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -1424,12 +1424,14 @@ sci_stp_request_pio_data_in_copy_data_buffer(struct 
isci_stp_request *stp_req,
sg = task->scatter;
 
while (total_len > 0) {
-   struct page *page = sg_page(sg);
-
copy_len = min_t(int, total_len, sg_dma_len(sg));
-   kaddr = kmap_atomic(page);
-   memcpy(kaddr + sg->offset, src_addr, copy_len);
-   kunmap_atomic(kaddr);
+   kaddr = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(kaddr))
+   return SCI_FAILURE;
+
+   memcpy(kaddr, src_addr, copy_len);
+   sg_unmap(sg, kaddr, SG_KMAP_ATOMIC);
+
total_len -= copy_len;
src_addr += copy_len;
sg = sg_next(sg);
@@ -1771,14 +1773,16 @@ sci_io_request_frame_handler(struct isci_request *ireq,
case SCI_REQ_SMP_WAIT_RESP: {
struct sas_task *task = isci_request_access_task(ireq);
struct scatterlist *sg = >smp_task.smp_resp;
-   void *frame_header, *kaddr;
+   void *frame_header;
u8 *rsp;
 
sci_unsolicited_frame_control_get_header(>uf_control,
 frame_index,
 _header);
-   kaddr = kmap_atomic(sg_page(sg));
-   rsp = kaddr + sg->offset;
+   rsp = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(rsp))
+   return SCI_FAILURE;
+
sci_swab32_cpy(rsp, frame_header, 1);
 
if (rsp[0] == SMP_RESPONSE) {
@@ -1814,7 +1818,7 @@ sci_io_request_frame_handler(struct isci_request *ireq,
ireq->sci_status = 
SCI_FAILURE_CONTROLLER_SPECIFIC_IO_ERR;
sci_change_state(>sm, SCI_REQ_COMPLETED);
}
-   kunmap_atomic(kaddr);
+   sg_unmap(sg, rsp, SG_KMAP_ATOMIC);
 
sci_controller_release_frame(ihost, frame_index);
 
@@ -2919,15 +2923,18 @@ static void isci_request_io_request_complete(struct 
isci_host *ihost,
case SAS_PROTOCOL_SMP: {
struct scatterlist *sg = >smp_task.smp_req;
struct smp_req *smp_req;
-   void *kaddr;
 
dma_unmap_sg(>pdev->dev, sg, 1, DMA_TO_DEVICE);
 
/* need to swab it back in case the command buffer is re-used */
-   

[PATCH 07/22] crypto: shash, caam: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Very straightforward conversion to the new function in two crypto
drivers.

Signed-off-by: Logan Gunthorpe 
---
 crypto/shash.c| 9 ++---
 drivers/crypto/caam/caamalg.c | 8 +++-
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/crypto/shash.c b/crypto/shash.c
index 5e31c8d..2b7de94 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, struct 
shash_desc *desc)
if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
void *data;
 
-   data = kmap_atomic(sg_page(sg));
-   err = crypto_shash_digest(desc, data + offset, nbytes,
+   data = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(data))
+   return PTR_ERR(data);
+
+   err = crypto_shash_digest(desc, data, nbytes,
  req->result);
-   kunmap_atomic(data);
+   sg_unmap(sg, data, SG_KMAP_ATOMIC);
crypto_yield(desc->flags);
} else
err = crypto_shash_init(desc) ?:
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 9bc80eb..76b97de 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -89,7 +89,6 @@ static void dbg_dump_sg(const char *level, const char 
*prefix_str,
struct scatterlist *sg, size_t tlen, bool ascii)
 {
struct scatterlist *it;
-   void *it_page;
size_t len;
void *buf;
 
@@ -98,19 +97,18 @@ static void dbg_dump_sg(const char *level, const char 
*prefix_str,
 * make sure the scatterlist's page
 * has a valid virtual memory mapping
 */
-   it_page = kmap_atomic(sg_page(it));
-   if (unlikely(!it_page)) {
+   buf = sg_map(it, SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
printk(KERN_ERR "dbg_dump_sg: kmap failed\n");
return;
}
 
-   buf = it_page + it->offset;
len = min_t(size_t, tlen, it->length);
print_hex_dump(level, prefix_str, prefix_type, rowsize,
   groupsize, buf, len, ascii);
tlen -= len;
 
-   kunmap_atomic(it_page);
+   sg_unmap(it, buf, SG_KMAP_ATOMIC);
}
 }
 #endif
-- 
2.1.4

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


[PATCH 14/22] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Very straightforward conversion of three scsi drivers

Signed-off-by: Logan Gunthorpe 
---
 drivers/scsi/arcmsr/arcmsr_hba.c | 16 
 drivers/scsi/ips.c   |  8 
 drivers/scsi/megaraid.c  |  9 +++--
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index af032c4..3cd485c 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2306,7 +2306,10 @@ static int arcmsr_iop_message_xfer(struct 
AdapterControlBlock *acb,
 
use_sg = scsi_sg_count(cmd);
sg = scsi_sglist(cmd);
-   buffer = kmap_atomic(sg_page(sg)) + sg->offset;
+   buffer = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(buffer))
+   return ARCMSR_MESSAGE_FAIL;
+
if (use_sg > 1) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
@@ -2539,7 +2542,7 @@ static int arcmsr_iop_message_xfer(struct 
AdapterControlBlock *acb,
 message_out:
if (use_sg) {
struct scatterlist *sg = scsi_sglist(cmd);
-   kunmap_atomic(buffer - sg->offset);
+   sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
}
return retvalue;
 }
@@ -2590,11 +2593,16 @@ static void arcmsr_handle_virtual_command(struct 
AdapterControlBlock *acb,
strncpy([32], "R001", 4); /* Product Revision */
 
sg = scsi_sglist(cmd);
-   buffer = kmap_atomic(sg_page(sg)) + sg->offset;
+   buffer = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(buffer)) {
+   cmd->result = (DID_ERROR << 16);
+   cmd->scsi_done(cmd);
+   return;
+   }
 
memcpy(buffer, inqdata, sizeof(inqdata));
sg = scsi_sglist(cmd);
-   kunmap_atomic(buffer - sg->offset);
+   sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
 
cmd->scsi_done(cmd);
}
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 3419e1b..a44291d 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -1506,14 +1506,14 @@ static int ips_is_passthru(struct scsi_cmnd *SC)
 /* kmap_atomic() ensures addressability of the user buffer.*/
 /* local_irq_save() protects the KM_IRQ0 address slot. */
 local_irq_save(flags);
-buffer = kmap_atomic(sg_page(sg)) + sg->offset;
-if (buffer && buffer[0] == 'C' && buffer[1] == 'O' &&
+buffer = sg_map(sg, SG_KMAP_ATOMIC);
+if (!IS_ERR(buffer) && buffer[0] == 'C' && buffer[1] == 'O' &&
 buffer[2] == 'P' && buffer[3] == 'P') {
-kunmap_atomic(buffer - sg->offset);
+sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
 local_irq_restore(flags);
 return 1;
 }
-kunmap_atomic(buffer - sg->offset);
+sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
 local_irq_restore(flags);
}
return 0;
diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 3c63c29..0b66e50 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -663,10 +663,15 @@ mega_build_cmd(adapter_t *adapter, Scsi_Cmnd *cmd, int 
*busy)
struct scatterlist *sg;
 
sg = scsi_sglist(cmd);
-   buf = kmap_atomic(sg_page(sg)) + sg->offset;
+   buf = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
+cmd->result = (DID_ERROR << 16);
+   cmd->scsi_done(cmd);
+   return NULL;
+   }
 
memset(buf, 0, cmd->cmnd[4]);
-   kunmap_atomic(buf - sg->offset);
+   sg_unmap(sg, buf, SG_KMAP_ATOMIC);
 
cmd->result = (DID_OK << 16);
cmd->scsi_done(cmd);
-- 
2.1.4

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


[PATCH 15/22] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

2017-04-13 Thread Logan Gunthorpe
These two drivers appear to duplicate the functionality of
sg_copy_buffer. So we clean them up to use the common code.

This helps us remove a couple of instances that would otherwise be
slightly tricky sg_map usages.

Signed-off-by: Logan Gunthorpe 
---
 drivers/scsi/csiostor/csio_scsi.c | 54 +++
 drivers/scsi/libfc/fc_libfc.c | 49 ---
 2 files changed, 14 insertions(+), 89 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..bd9d062 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -1489,60 +1489,14 @@ static inline uint32_t
 csio_scsi_copy_to_sgl(struct csio_hw *hw, struct csio_ioreq *req)
 {
struct scsi_cmnd *scmnd  = (struct scsi_cmnd *)csio_scsi_cmnd(req);
-   struct scatterlist *sg;
-   uint32_t bytes_left;
-   uint32_t bytes_copy;
-   uint32_t buf_off = 0;
-   uint32_t start_off = 0;
-   uint32_t sg_off = 0;
-   void *sg_addr;
-   void *buf_addr;
struct csio_dma_buf *dma_buf;
+   size_t copied;
 
-   bytes_left = scsi_bufflen(scmnd);
-   sg = scsi_sglist(scmnd);
dma_buf = (struct csio_dma_buf *)csio_list_next(>gen_list);
+   copied = sg_copy_from_buffer(scsi_sglist(scmnd), scsi_sg_count(scmnd),
+dma_buf->vaddr, scsi_bufflen(scmnd));
 
-   /* Copy data from driver buffer to SGs of SCSI CMD */
-   while (bytes_left > 0 && sg && dma_buf) {
-   if (buf_off >= dma_buf->len) {
-   buf_off = 0;
-   dma_buf = (struct csio_dma_buf *)
-   csio_list_next(dma_buf);
-   continue;
-   }
-
-   if (start_off >= sg->length) {
-   start_off -= sg->length;
-   sg = sg_next(sg);
-   continue;
-   }
-
-   buf_addr = dma_buf->vaddr + buf_off;
-   sg_off = sg->offset + start_off;
-   bytes_copy = min((dma_buf->len - buf_off),
-   sg->length - start_off);
-   bytes_copy = min((uint32_t)(PAGE_SIZE - (sg_off & ~PAGE_MASK)),
-bytes_copy);
-
-   sg_addr = kmap_atomic(sg_page(sg) + (sg_off >> PAGE_SHIFT));
-   if (!sg_addr) {
-   csio_err(hw, "failed to kmap sg:%p of ioreq:%p\n",
-   sg, req);
-   break;
-   }
-
-   csio_dbg(hw, "copy_to_sgl:sg_addr %p sg_off %d buf %p len %d\n",
-   sg_addr, sg_off, buf_addr, bytes_copy);
-   memcpy(sg_addr + (sg_off & ~PAGE_MASK), buf_addr, bytes_copy);
-   kunmap_atomic(sg_addr);
-
-   start_off +=  bytes_copy;
-   buf_off += bytes_copy;
-   bytes_left -= bytes_copy;
-   }
-
-   if (bytes_left > 0)
+   if (copied != scsi_bufflen(scmnd))
return DID_ERROR;
else
return DID_OK;
diff --git a/drivers/scsi/libfc/fc_libfc.c b/drivers/scsi/libfc/fc_libfc.c
index d623d08..ce0805a 100644
--- a/drivers/scsi/libfc/fc_libfc.c
+++ b/drivers/scsi/libfc/fc_libfc.c
@@ -113,45 +113,16 @@ u32 fc_copy_buffer_to_sglist(void *buf, size_t len,
 u32 *nents, size_t *offset,
 u32 *crc)
 {
-   size_t remaining = len;
-   u32 copy_len = 0;
-
-   while (remaining > 0 && sg) {
-   size_t off, sg_bytes;
-   void *page_addr;
-
-   if (*offset >= sg->length) {
-   /*
-* Check for end and drop resources
-* from the last iteration.
-*/
-   if (!(*nents))
-   break;
-   --(*nents);
-   *offset -= sg->length;
-   sg = sg_next(sg);
-   continue;
-   }
-   sg_bytes = min(remaining, sg->length - *offset);
-
-   /*
-* The scatterlist item may be bigger than PAGE_SIZE,
-* but we are limited to mapping PAGE_SIZE at a time.
-*/
-   off = *offset + sg->offset;
-   sg_bytes = min(sg_bytes,
-  (size_t)(PAGE_SIZE - (off & ~PAGE_MASK)));
-   page_addr = kmap_atomic(sg_page(sg) + (off >> PAGE_SHIFT));
-   if (crc)
-   *crc = crc32(*crc, buf, sg_bytes);
-   memcpy((char *)page_addr + (off & ~PAGE_MASK), buf, sg_bytes);
-   kunmap_atomic(page_addr);
-   buf += sg_bytes;
-   *offset += sg_bytes;
-   remaining -= sg_bytes;
-   

[PATCH 22/22] memstick: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion, but we have to WARN if unmappable
memory finds its way into the sgl.

Signed-off-by: Logan Gunthorpe 
---
 drivers/memstick/host/jmb38x_ms.c | 23 ++-
 drivers/memstick/host/tifm_ms.c   | 22 +-
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/memstick/host/jmb38x_ms.c 
b/drivers/memstick/host/jmb38x_ms.c
index 48db922..256cf41 100644
--- a/drivers/memstick/host/jmb38x_ms.c
+++ b/drivers/memstick/host/jmb38x_ms.c
@@ -303,7 +303,6 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host 
*host)
unsigned int off;
unsigned int t_size, p_cnt;
unsigned char *buf;
-   struct page *pg;
unsigned long flags = 0;
 
if (host->req->long_data) {
@@ -318,14 +317,26 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host 
*host)
unsigned int uninitialized_var(p_off);
 
if (host->req->long_data) {
-   pg = nth_page(sg_page(>req->sg),
- off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, length);
 
local_irq_save(flags);
-   buf = kmap_atomic(pg) + p_off;
+   buf = sg_map_offset(>req->sg,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   break;
+   }
+
} else {
buf = host->req->data + host->block_pos;
p_cnt = host->req->data_len - host->block_pos;
@@ -341,7 +352,9 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host 
*host)
 : jmb38x_ms_read_reg_data(host, buf, p_cnt);
 
if (host->req->long_data) {
-   kunmap_atomic(buf - p_off);
+   sg_unmap_offset(>req->sg, buf,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC);
local_irq_restore(flags);
}
 
diff --git a/drivers/memstick/host/tifm_ms.c b/drivers/memstick/host/tifm_ms.c
index 7bafa72..c0bc40e 100644
--- a/drivers/memstick/host/tifm_ms.c
+++ b/drivers/memstick/host/tifm_ms.c
@@ -186,7 +186,6 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms 
*host)
unsigned int off;
unsigned int t_size, p_cnt;
unsigned char *buf;
-   struct page *pg;
unsigned long flags = 0;
 
if (host->req->long_data) {
@@ -203,14 +202,25 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms 
*host)
unsigned int uninitialized_var(p_off);
 
if (host->req->long_data) {
-   pg = nth_page(sg_page(>req->sg),
- off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, length);
 
local_irq_save(flags);
-   buf = kmap_atomic(pg) + p_off;
+   buf = sg_map_offset(>req->sg,
+off - host->req->sg.offset,
+SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   break;
+   }
} else {
buf = host->req->data + host->block_pos;
p_cnt = host->req->data_len - host->block_pos;
@@ -221,7 +231,9 @@ static unsigned int tifm_ms_transfer_data(struct tifm_ms 
*host)
 : tifm_ms_read_data(host, buf, p_cnt);
 
if 

[PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

2017-04-13 Thread Logan Gunthorpe
Very straightforward conversion to the new function in all four spots.

Signed-off-by: Logan Gunthorpe 
---
 drivers/md/dm-crypt.c | 38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 389a363..6bd0ffc 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -589,9 +589,12 @@ static int crypt_iv_lmk_gen(struct crypt_config *cc, u8 
*iv,
int r = 0;
 
if (bio_data_dir(dmreq->ctx->bio_in) == WRITE) {
-   src = kmap_atomic(sg_page(>sg_in));
-   r = crypt_iv_lmk_one(cc, iv, dmreq, src + dmreq->sg_in.offset);
-   kunmap_atomic(src);
+   src = sg_map(>sg_in, SG_KMAP_ATOMIC);
+   if (IS_ERR(src))
+   return PTR_ERR(src);
+
+   r = crypt_iv_lmk_one(cc, iv, dmreq, src);
+   sg_unmap(>sg_in, src, SG_KMAP_ATOMIC);
} else
memset(iv, 0, cc->iv_size);
 
@@ -607,14 +610,17 @@ static int crypt_iv_lmk_post(struct crypt_config *cc, u8 
*iv,
if (bio_data_dir(dmreq->ctx->bio_in) == WRITE)
return 0;
 
-   dst = kmap_atomic(sg_page(>sg_out));
-   r = crypt_iv_lmk_one(cc, iv, dmreq, dst + dmreq->sg_out.offset);
+   dst = sg_map(>sg_out, SG_KMAP_ATOMIC);
+   if (IS_ERR(dst))
+   return PTR_ERR(dst);
+
+   r = crypt_iv_lmk_one(cc, iv, dmreq, dst);
 
/* Tweak the first block of plaintext sector */
if (!r)
-   crypto_xor(dst + dmreq->sg_out.offset, iv, cc->iv_size);
+   crypto_xor(dst, iv, cc->iv_size);
 
-   kunmap_atomic(dst);
+   sg_unmap(>sg_out, dst, SG_KMAP_ATOMIC);
return r;
 }
 
@@ -731,9 +737,12 @@ static int crypt_iv_tcw_gen(struct crypt_config *cc, u8 
*iv,
 
/* Remove whitening from ciphertext */
if (bio_data_dir(dmreq->ctx->bio_in) != WRITE) {
-   src = kmap_atomic(sg_page(>sg_in));
-   r = crypt_iv_tcw_whitening(cc, dmreq, src + 
dmreq->sg_in.offset);
-   kunmap_atomic(src);
+   src = sg_map(>sg_in, SG_KMAP_ATOMIC);
+   if (IS_ERR(src))
+   return PTR_ERR(src);
+
+   r = crypt_iv_tcw_whitening(cc, dmreq, src);
+   sg_unmap(>sg_in, src, SG_KMAP_ATOMIC);
}
 
/* Calculate IV */
@@ -755,9 +764,12 @@ static int crypt_iv_tcw_post(struct crypt_config *cc, u8 
*iv,
return 0;
 
/* Apply whitening on ciphertext */
-   dst = kmap_atomic(sg_page(>sg_out));
-   r = crypt_iv_tcw_whitening(cc, dmreq, dst + dmreq->sg_out.offset);
-   kunmap_atomic(dst);
+   dst = sg_map(>sg_out, SG_KMAP_ATOMIC);
+   if (IS_ERR(dst))
+   return PTR_ERR(dst);
+
+   r = crypt_iv_tcw_whitening(cc, dmreq, dst);
+   sg_unmap(>sg_out, dst, SG_KMAP_ATOMIC);
 
return r;
 }
-- 
2.1.4

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


Re: [Nouveau] [PATCH 1/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Karol Herbst
2017-04-13 11:08 GMT+02:00 Oscar Salvador :
> This patch introduces the structure "struct hwmon_ops"  and sets up the  
> ".visible" operation.
> Is also a preparation for the next patch where all work is being done.
>
> --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
> 19:22:29.070573187 +0200
> +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
> 19:21:32.391338011 +0200
> @@ -764,6 +764,166 @@ static const struct hwmon_channel_info *
> _power,
> NULL
>  };
> +
> +static umode_t
> +nouveau_chip_is_visible(const void *data, u32 attr, int channel)
> +{
> +   switch (attr) {
> +   case hwmon_chip_update_interval:
> +   return 0444;
> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_power_is_visible(const void *data, u32 attr, int channel)
> +{
> +   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> +   struct nvkm_iccsense *iccsense = nvxx_iccsense(>client.device);
> +
> +   switch (attr) {
> +   case hwmon_power_input:
> +   if (iccsense && iccsense->data_valid &&
> +   !list_empty(>rails))
> +   return 0444;

no fallthrough here.

> +   case hwmon_power_max:
> +   case hwmon_power_crit:
> +   if (iccsense->power_w_max && iccsense->power_w_crit)
> +   return 0444;

it makes sense to split those

> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_temp_is_visible(const void *data, u32 attr, int channel)
> +{
> +   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> +   struct nvkm_therm *therm = nvxx_therm(>client.device);
> +
> +   if (therm && therm->attr_get && therm->attr_set)
> +   if (nvkm_therm_temp_get(therm) < 0)
> +   return 0;

I think you can merge those if statements

> +
> +   switch (attr) {
> +   case hwmon_temp_input:
> +   return 0444;
> +   case hwmon_temp_max:
> +   case hwmon_temp_max_hyst:
> +   case hwmon_temp_crit:
> +   case hwmon_temp_crit_hyst:
> +   case hwmon_temp_emergency:
> +   case hwmon_temp_emergency_hyst:
> +   return 0644;

I doubt we ever want to support changing those, please leave them as read only

> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
> +{
> +   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> +   struct nvkm_therm *therm = nvxx_therm(>client.device);
> +
> +   if (therm && therm->attr_get)
> +   if (therm->fan_get && therm->fan_get(therm) < 0)
> +   return 0;

merge the ifs

> +
> +   switch (attr) {
> +   case hwmon_pwm_enable:
> +   case hwmon_pwm_input:
> +   return 0644;
> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_input_is_visible(const void *data, u32 attr, int channel)
> +{
> +   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> +   struct nvkm_volt *volt = nvxx_volt(>client.device);
> +
> +   if (!volt || nvkm_volt_get(volt) < 0)
> +   return 0;
> +
> +   switch (attr) {
> +   case hwmon_in_input:
> +   case hwmon_in_label:
> +   case hwmon_in_min:
> +   case hwmon_in_max:
> +   return 0444;
> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_fan_is_visible(const void *data, u32 attr, int channel)
> +{
> +   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
> +   struct nvkm_therm *therm = nvxx_therm(>client.device);
> +
> +   if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
> +   return 0;
> +
> +   switch (attr) {
> +   case hwmon_fan_input:
> +   return 0444;
> +   default:
> +   return 0;
> +   }
> +}
> +
> +static umode_t
> +nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
> +   int channel)

Indentation

> +{
> +   switch (type) {
> +   case hwmon_chip:
> +   return nouveau_chip_is_visible(data, attr, channel);
> +   case hwmon_temp:
> +   return nouveau_temp_is_visible(data, attr, channel);
> +   case hwmon_fan:
> +   return nouveau_fan_is_visible(data, attr, channel);
> +   case hwmon_in:
> +   return nouveau_input_is_visible(data, attr, channel);
> +   case hwmon_pwm:
> +   return nouveau_pwm_is_visible(data, attr, channel);
> +   case hwmon_power:
> +   return nouveau_power_is_visible(data, attr, channel);
> +   default:
> +   return 0;
> +   }
> +}
> 

[PATCH 21/22] mmc: tifm_sd: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
This conversion is a bit complicated. We modiy the read_fifo,
write_fifo and copy_page functions to take a scatterlist instead of a
page. Thus we can use sg_map instead of kmap_atomic. There's a bit of
accounting that needed to be done for the offset for this to work.
(Seeing sg_map takes care of the offset but it's already added and
used earlier in the code.

There's also no error path, so if unmappable memory finds its way into
the sgl we can only WARN.

Signed-off-by: Logan Gunthorpe 
---
 drivers/mmc/host/tifm_sd.c | 88 +++---
 1 file changed, 67 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/tifm_sd.c b/drivers/mmc/host/tifm_sd.c
index 93c4b40..75b0d74 100644
--- a/drivers/mmc/host/tifm_sd.c
+++ b/drivers/mmc/host/tifm_sd.c
@@ -111,14 +111,26 @@ struct tifm_sd {
 };
 
 /* for some reason, host won't respond correctly to readw/writew */
-static void tifm_sd_read_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_read_fifo(struct tifm_sd *host, struct scatterlist *sg,
  unsigned int off, unsigned int cnt)
 {
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
 
-   buf = kmap_atomic(pg) + off;
+   buf = sg_map_offset(sg, off - sg->offset, SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return;
+   }
+
if (host->cmd_flags & DATA_CARRY) {
buf[pos++] = host->bounce_buf_data[0];
host->cmd_flags &= ~DATA_CARRY;
@@ -134,17 +146,29 @@ static void tifm_sd_read_fifo(struct tifm_sd *host, 
struct page *pg,
}
buf[pos++] = (val >> 8) & 0xff;
}
-   kunmap_atomic(buf - off);
+   sg_unmap_offset(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
 }
 
-static void tifm_sd_write_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_write_fifo(struct tifm_sd *host, struct scatterlist *sg,
   unsigned int off, unsigned int cnt)
 {
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
 
-   buf = kmap_atomic(pg) + off;
+   buf = sg_map_offset(sg, off - sg->offset, SG_KMAP_ATOMIC);
+   if (IS_ERR(buf)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return;
+   }
+
if (host->cmd_flags & DATA_CARRY) {
val = host->bounce_buf_data[0] | ((buf[pos++] << 8) & 0xff00);
writel(val, sock->addr + SOCK_MMCSD_DATA);
@@ -161,7 +185,7 @@ static void tifm_sd_write_fifo(struct tifm_sd *host, struct 
page *pg,
val |= (buf[pos++] << 8) & 0xff00;
writel(val, sock->addr + SOCK_MMCSD_DATA);
}
-   kunmap_atomic(buf - off);
+   sg_unmap_offset(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
 }
 
 static void tifm_sd_transfer_data(struct tifm_sd *host)
@@ -170,7 +194,6 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
struct scatterlist *sg = r_data->sg;
unsigned int off, cnt, t_size = TIFM_MMCSD_FIFO_SIZE * 2;
unsigned int p_off, p_cnt;
-   struct page *pg;
 
if (host->sg_pos == host->sg_len)
return;
@@ -192,33 +215,57 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
}
off = sg[host->sg_pos].offset + host->block_pos;
 
-   pg = nth_page(sg_page([host->sg_pos]), off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, cnt);
p_cnt = min(p_cnt, t_size);
 
if (r_data->flags & MMC_DATA_READ)
-   tifm_sd_read_fifo(host, pg, p_off, p_cnt);
+   tifm_sd_read_fifo(host, [host->sg_pos], p_off,
+ p_cnt);
else if (r_data->flags & MMC_DATA_WRITE)
-   tifm_sd_write_fifo(host, pg, p_off, p_cnt);
+   tifm_sd_write_fifo(host, [host->sg_pos], p_off,
+  p_cnt);
 
t_size -= p_cnt;
host->block_pos += p_cnt;
}
 }
 
-static void tifm_sd_copy_page(struct page 

[PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion to the new helper, except due to
the lack of error path, we have to warn if unmapable memory
is ever present in the sgl.

Signed-off-by: Logan Gunthorpe 
---
 drivers/block/xen-blkfront.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5067a0a..7dcf41d 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
BUG_ON(sg->offset + sg->length > PAGE_SIZE);
 
if (setup.need_copy) {
-   setup.bvec_off = sg->offset;
-   setup.bvec_data = kmap_atomic(sg_page(sg));
+   setup.bvec_off = 0;
+   setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(setup.bvec_data)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there is a
+* questionable error path out of here,
+* we WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return 1;
+   }
}
 
gnttab_foreach_grant_in_range(sg_page(sg),
@@ -818,7 +829,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
blkfront_ring_info *ri
  );
 
if (setup.need_copy)
-   kunmap_atomic(setup.bvec_data);
+   sg_unmap(sg, setup.bvec_data, SG_KMAP_ATOMIC);
}
if (setup.segments)
kunmap_atomic(setup.segments);
@@ -1468,8 +1479,18 @@ static bool blkif_completion(unsigned long *id,
for_each_sg(s->sg, sg, num_sg, i) {
BUG_ON(sg->offset + sg->length > PAGE_SIZE);
 
-   data.bvec_offset = sg->offset;
-   data.bvec_data = kmap_atomic(sg_page(sg));
+   data.bvec_offset = 0;
+   data.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(data.bvec_data)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there is no
+* clear error path, we WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return 1;
+   }
 
gnttab_foreach_grant_in_range(sg_page(sg),
  sg->offset,
@@ -1477,7 +1498,7 @@ static bool blkif_completion(unsigned long *id,
  blkif_copy_from_grant,
  );
 
-   kunmap_atomic(data.bvec_data);
+   sg_unmap(sg, data.bvec_data, SG_KMAP_ATOMIC);
}
}
/* Add the persistent grant into the list of free grants */
-- 
2.1.4

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


[PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
The get_page in this area looks *highly* suspect due to there being no
corresponding put_page. However, I've left that as is to avoid breaking
things.

I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead
code that dates back to when it was first committed...

Signed-off-by: Logan Gunthorpe 
---
 drivers/crypto/chelsio/chcr_algo.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
index 41bc7f4..a993d1d 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -1489,22 +1489,21 @@ static struct sk_buff *create_authenc_wr(struct 
aead_request *req,
return ERR_PTR(-EINVAL);
 }
 
-static void aes_gcm_empty_pld_pad(struct scatterlist *sg,
- unsigned short offset)
+static int aes_gcm_empty_pld_pad(struct scatterlist *sg,
+unsigned short offset)
 {
-   struct page *spage;
unsigned char *addr;
 
-   spage = sg_page(sg);
-   get_page(spage); /* so that it is not freed by NIC */
-#ifdef KMAP_ATOMIC_ARGS
-   addr = kmap_atomic(spage, KM_SOFTIRQ0);
-#else
-   addr = kmap_atomic(spage);
-#endif
-   memset(addr + sg->offset, 0, offset + 1);
+   get_page(sg_page(sg)); /* so that it is not freed by NIC */
+
+   addr = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(addr))
+   return PTR_ERR(addr);
+
+   memset(addr, 0, offset + 1);
+   sg_unmap(sg, addr, SG_KMAP_ATOMIC);
 
-   kunmap_atomic(addr);
+   return 0;
 }
 
 static int set_msg_len(u8 *block, unsigned int msglen, int csize)
@@ -1940,7 +1939,10 @@ static struct sk_buff *create_gcm_wr(struct aead_request 
*req,
if (req->cryptlen) {
write_sg_to_skb(skb, , src, req->cryptlen);
} else {
-   aes_gcm_empty_pld_pad(req->dst, authsize - 1);
+   err = aes_gcm_empty_pld_pad(req->dst, authsize - 1);
+   if (err)
+   goto dstmap_fail;
+
write_sg_to_skb(skb, , reqctx->dst, crypt_len);
 
}
-- 
2.1.4

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


Re: [Nouveau] [PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Karol Herbst
Hi Oscar,

this is a cover letter, there should be no patch attached to it, but a
stat of the following patches and an explenation what the series is
doing.

2017-04-13 11:07 GMT+02:00 Oscar Salvador :
> Hi again,
>
> I've split the patches as Karol Herbst suggested.
> I hope now it's fine.
>
> This series of patches introduce the new hwmon_device_register_with_info
> and gets rid of the old hwmon_device_register.
>
> This patch adds the default sensors with their possible config values.
> Just to prepare for the next patches
>
>
> --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
> 19:18:09.638073562 +0200
> +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
> 19:19:44.244797202 +0200
> @@ -692,6 +692,78 @@ static const struct attribute_group hwmo
>  static const struct attribute_group hwmon_power_caps_attrgroup = {
> .attrs = hwmon_power_caps_attributes,
>  };
> +
> +static const u32 nouveau_config_chip[] = {
> +   HWMON_C_UPDATE_INTERVAL,
> +   0
> +};
> +
> +static const u32 nouveau_config_in[] = {
> +   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
> +   0
> +};
> +
> +static const u32 nouveau_config_temp[] = {
> +   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
> +   HWMON_T_EMERGENCY_HYST,
> +   0
> +};
> +
> +static const u32 nouveau_config_fan[] = {
> +   HWMON_F_INPUT,
> +   0
> +};
> +
> +static const u32 nouveau_config_pwm[] = {
> +   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
> +   0
> +};
> +
> +static const u32 nouveau_config_power[] = {
> +   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
> +   0
> +};
> +
> +static const struct hwmon_channel_info nouveau_chip = {
> +   .type = hwmon_chip,
> +   .config = nouveau_config_chip,
> +};
> +
> +static const struct hwmon_channel_info nouveau_temp = {
> +   .type = hwmon_temp,
> +   .config = nouveau_config_temp,
> +};
> +
> +static const struct hwmon_channel_info nouveau_fan = {
> +   .type = hwmon_fan,
> +   .config = nouveau_config_fan,
> +};
> +
> +static const struct hwmon_channel_info nouveau_in = {
> +   .type = hwmon_in,
> +   .config = nouveau_config_in,
> +};
> +
> +static const struct hwmon_channel_info nouveau_pwm = {
> +   .type = hwmon_pwm,
> +   .config = nouveau_config_pwm,
> +};
> +
> +static const struct hwmon_channel_info nouveau_power = {
> +   .type = hwmon_power,
> +   .config = nouveau_config_power,
> +};
> +
> +static const struct hwmon_channel_info *nouveau_info[] = {
> +   _chip,
> +   _temp,
> +   _fan,
> +   _in,
> +   _pwm,
> +   _power,
> +   NULL
> +};
>  #endif
>
>  int
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 17/22] mmc: sdhci: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion, except due to the lack of error path we
have to WARN if the memory in the SGL is not mappable.

Signed-off-by: Logan Gunthorpe 
---
 drivers/mmc/host/sdhci.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 63bc33a..af0c107 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -497,15 +497,34 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
return sg_count;
 }
 
+/*
+ * Note this function may return PTR_ERR and must be checked.
+ */
 static char *sdhci_kmap_atomic(struct scatterlist *sg, unsigned long *flags)
 {
+   void *ret;
+
local_irq_save(*flags);
-   return kmap_atomic(sg_page(sg)) + sg->offset;
+
+   ret = sg_map(sg, SG_KMAP_ATOMIC);
+   if (IS_ERR(ret)) {
+   /*
+* This should really never happen unless the code is changed
+* to use memory that is not mappable in the sg. Seeing there
+* doesn't seem to be any error path out of here, we can only
+* WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   local_irq_restore(*flags);
+   }
+
+   return ret;
 }
 
-static void sdhci_kunmap_atomic(void *buffer, unsigned long *flags)
+static void sdhci_kunmap_atomic(struct scatterlist *sg, void *buffer,
+   unsigned long *flags)
 {
-   kunmap_atomic(buffer);
+   sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
 }
 
@@ -568,8 +587,11 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
if (offset) {
if (data->flags & MMC_DATA_WRITE) {
buffer = sdhci_kmap_atomic(sg, );
+   if (IS_ERR(buffer))
+   return;
+
memcpy(align, buffer, offset);
-   sdhci_kunmap_atomic(buffer, );
+   sdhci_kunmap_atomic(sg, buffer, );
}
 
/* tran, valid */
@@ -646,8 +668,11 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
   (sg_dma_address(sg) & 
SDHCI_ADMA2_MASK);
 
buffer = sdhci_kmap_atomic(sg, );
+   if (IS_ERR(buffer))
+   return;
+
memcpy(buffer, align, size);
-   sdhci_kunmap_atomic(buffer, );
+   sdhci_kunmap_atomic(sg, buffer, );
 
align += SDHCI_ADMA2_ALIGN;
}
-- 
2.1.4

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


[PATCH 19/22] mmc: tmio: Make use of the new sg_map helper function

2017-04-13 Thread Logan Gunthorpe
Straightforward conversion to sg_map helper. A couple paths will
WARN if the memory does not end up being mappable.

Signed-off-by: Logan Gunthorpe 
---
 drivers/mmc/host/tmio_mmc.h | 12 ++--
 drivers/mmc/host/tmio_mmc_dma.c |  5 +
 drivers/mmc/host/tmio_mmc_pio.c | 24 
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 2b349d4..ba68c9fed 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -198,17 +198,25 @@ void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host, 
u32 i);
 void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i);
 irqreturn_t tmio_mmc_irq(int irq, void *devid);
 
+/* Note: this function may return PTR_ERR and must be checked! */
 static inline char *tmio_mmc_kmap_atomic(struct scatterlist *sg,
 unsigned long *flags)
 {
+   void *ret;
+
local_irq_save(*flags);
-   return kmap_atomic(sg_page(sg)) + sg->offset;
+   ret = sg_map(sg, SG_KMAP_ATOMIC);
+
+   if (IS_ERR(ret))
+   local_irq_restore(*flags);
+
+   return ret;
 }
 
 static inline void tmio_mmc_kunmap_atomic(struct scatterlist *sg,
  unsigned long *flags, void *virt)
 {
-   kunmap_atomic(virt - sg->offset);
+   sg_unmap(sg, virt, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
 }
 
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index fa8a936..07531f7 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -149,6 +149,11 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host 
*host)
if (!aligned) {
unsigned long flags;
void *sg_vaddr = tmio_mmc_kmap_atomic(sg, );
+   if (IS_ERR(sg_vaddr)) {
+   ret = PTR_ERR(sg_vaddr);
+   goto pio;
+   }
+
sg_init_one(>bounce_sg, host->bounce_buf, sg->length);
memcpy(host->bounce_buf, sg_vaddr, host->bounce_sg.length);
tmio_mmc_kunmap_atomic(sg, , sg_vaddr);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 6b789a7..d6fdbf6 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -479,6 +479,18 @@ static void tmio_mmc_pio_irq(struct tmio_mmc_host *host)
}
 
sg_virt = tmio_mmc_kmap_atomic(host->sg_ptr, );
+   if (IS_ERR(sg_virt)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return;
+   }
+
buf = (unsigned short *)(sg_virt + host->sg_off);
 
count = host->sg_ptr->length - host->sg_off;
@@ -506,6 +518,18 @@ static void tmio_mmc_check_bounce_buffer(struct 
tmio_mmc_host *host)
if (host->sg_ptr == >bounce_sg) {
unsigned long flags;
void *sg_vaddr = tmio_mmc_kmap_atomic(host->sg_orig, );
+   if (IS_ERR(sg_vaddr)) {
+   /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+   WARN(1, "Non-mappable memory used in sg!");
+   return;
+   }
+
memcpy(sg_vaddr, host->bounce_buf, host->bounce_sg.length);
tmio_mmc_kunmap_atomic(host->sg_orig, , sg_vaddr);
}
-- 
2.1.4

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


drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1952-g0a54b7fee9ec)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed 
(v4.11-rc6-1952-g0a54b7fee9ec)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1952-g0a54b7fee9ec
Git Commit: 0a54b7fee9ecda9257d34e5c3ac8de6516a60a90
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 11 unique boards, 4 SoC families, 11 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1953-g4079da1bee73)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc6-1953-g4079da1bee73)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1953-g4079da1bee73/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1953-g4079da1bee73
Git Commit: 4079da1bee731e2bf185411abd9ecda25f247890
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
redefinition of 'nv137_chipset'

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #6 from Alex Deucher  ---
(In reply to Andy Furniss from comment #5)
> (In reply to Alex Deucher from comment #4)
> > Should be fixed by:
> > 
> > commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
> > Author: Daniel Vetter 
> > Date:   Mon Apr 10 13:54:45 2017 +0200
> > 
> > drm: Fix get_property logic fumble
> > 
> > Yet again I've proven that I can't negate conditions :(
> > 
> > Testcase: igt/kms_properties/get_property-sanity
> > Reviewed-by: Maarten Lankhorst 
> > Reviewed-by: Sean Paul 
> > Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> > ioctl")
> 
> Ok, but it doesn't seem to be anywhere in your tree.

It hasn't been pulled into drm-next yet.

-- 
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 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #5 from Andy Furniss  ---
(In reply to Alex Deucher from comment #4)
> Should be fixed by:
> 
> commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
> Author: Daniel Vetter 
> Date:   Mon Apr 10 13:54:45 2017 +0200
> 
> drm: Fix get_property logic fumble
> 
> Yet again I've proven that I can't negate conditions :(
> 
> Testcase: igt/kms_properties/get_property-sanity
> Reviewed-by: Maarten Lankhorst 
> Reviewed-by: Sean Paul 
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> ioctl")

Ok, but it doesn't seem to be anywhere in your tree.

-- 
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] drm/i915: uninitialized value on error path

2017-04-13 Thread Dan Carpenter
True.  I'll resend.

regards,
dan carpenter

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


Re: [PATCH] drm: Fix get_property logic fumble

2017-04-13 Thread Andres Rodriguez



On 2017-04-10 08:40 AM, Maarten Lankhorst wrote:

Op 10-04-17 om 13:54 schreef Daniel Vetter:

Yet again I've proven that I can't negate conditions :(

Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Reported-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_property.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 3feef0659940..3e88fa24eab3 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, >enum_list, head) {
enum_count++;
-   if (out_resp->count_enum_blobs <= enum_count)
+   if (out_resp->count_enum_blobs < enum_count)
continue;

if (copy_to_user(_ptr[copied].value,


Neither can I, glanced over it while looking why the bisect pointed at this 
commit.


Same.

Tested-by: Andres Rodriguez 

Fixes segfaults on xorg-video-amdgpu-1.1.2



Reviewed-by: Maarten Lankhorst 

___
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


drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1952-g0a54b7fee9ec)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc6-1952-g0a54b7fee9ec)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1952-g0a54b7fee9ec
Git Commit: 0a54b7fee9ecda9257d34e5c3ac8de6516a60a90
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
redefinition of 'nv137_chipset'

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #4 from Alex Deucher  ---
Should be fixed by:

commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
Author: Daniel Vetter 
Date:   Mon Apr 10 13:54:45 2017 +0200

drm: Fix get_property logic fumble

Yet again I've proven that I can't negate conditions :(

Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Sean Paul 
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
ioctl")

-- 
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] drm/i915: uninitialized value on error path

2017-04-13 Thread Chris Wilson
On Thu, Apr 13, 2017 at 10:53:11PM +0300, Dan Carpenter wrote:
> "ret" isn't initialized on this error path.  It doesn't really cause
> any problems unless it's randomly set to -EDEADLK which is not likely.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 48a546210d8b..d0e9578952d5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9563,6 +9563,7 @@ int intel_get_load_detect_pipe(struct drm_connector 
> *connector,
>*/
>   if (!crtc) {
>   DRM_DEBUG_KMS("no pipe available for load-detect\n");
> + ret = -ENODEV;
>   goto fail;
>   }

Looks like we need

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8ffeda9d349b..4d0b3d80ed24 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9618,6 +9618,7 @@ int intel_get_load_detect_pipe(struct drm_connector 
*connector,
DRM_DEBUG_KMS("reusing fbdev for load-detection framebuffer\n");
if (IS_ERR(fb)) {
DRM_DEBUG_KMS("failed to allocate framebuffer for 
load-detection\n");
+   ret = PTR_ERR(fb);
goto fail;
}
 
as well.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915: checking for NULL instead of IS_ERR() in mock selftests

2017-04-13 Thread Chris Wilson
On Thu, Apr 13, 2017 at 10:52:17PM +0300, Dan Carpenter wrote:
> i915_gem_request_alloc() uses error pointers.  It never returns NULLs.
> 
> Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Chris Wilson 

Thanks for the catch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [PATCH 06/15] drm: Drop modeset_lock_all from the getproperty ioctl

2017-04-13 Thread Chris Wilson
On Thu, Apr 13, 2017 at 04:03:16PM -0400, Alex Deucher wrote:
> On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter  wrote:
> > Properties, i.e. the struct drm_property specifying the type and value
> > range of a property, not the instantiation on a given object, are
> > invariant over the lifetime of a driver.
> >
> > Hence no locking at all is needed, we can just remove it.
> >
> > While at it give the function some love and simplify it, to get it
> > under the 80 char limit:
> > - Straighten the loops to reduce the nesting.
> > - use u64_to_user_ptr casting helper
> > - use put_user for fixed u64 copies.
> >
> > Note there's a small behavioural change in that we now copy parts of
> > the values to userspace if the arrays are a bit too small. Since
> > userspace will immediately retry anyway, this doesn't matter.
> >
> > Signed-off-by: Daniel Vetter 
> 
> This causes a segfault in our ddx:
> https://bugs.freedesktop.org/show_bug.cgi?id=100673

Should be fixed by:

commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
Author: Daniel Vetter 
Date:   Mon Apr 10 13:54:45 2017 +0200

drm: Fix get_property logic fumble

Yet again I've proven that I can't negate conditions :(

Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Sean Paul 
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty 
ioctl")

Does that help?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gdf0abb111336)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed 
(v4.11-rc6-1950-gdf0abb111336)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1950-gdf0abb111336
Git Commit: df0abb1113368aa0af16907c769116ff6273812f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 11 unique boards, 4 SoC families, 11 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 06/15] drm: Drop modeset_lock_all from the getproperty ioctl

2017-04-13 Thread Alex Deucher
On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter  wrote:
> Properties, i.e. the struct drm_property specifying the type and value
> range of a property, not the instantiation on a given object, are
> invariant over the lifetime of a driver.
>
> Hence no locking at all is needed, we can just remove it.
>
> While at it give the function some love and simplify it, to get it
> under the 80 char limit:
> - Straighten the loops to reduce the nesting.
> - use u64_to_user_ptr casting helper
> - use put_user for fixed u64 copies.
>
> Note there's a small behavioural change in that we now copy parts of
> the values to userspace if the arrays are a bit too small. Since
> userspace will immediately retry anyway, this doesn't matter.
>
> Signed-off-by: Daniel Vetter 

This causes a segfault in our ddx:
https://bugs.freedesktop.org/show_bug.cgi?id=100673

Alex


> ---
>  drivers/gpu/drm/drm_property.c | 72 
> +-
>  1 file changed, 29 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index b17959c3e099..3feef0659940 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -442,8 +442,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> struct drm_property *property;
> int enum_count = 0;
> int value_count = 0;
> -   int ret = 0, i;
> -   int copied;
> +   int i, copied;
> struct drm_property_enum *prop_enum;
> struct drm_mode_property_enum __user *enum_ptr;
> uint64_t __user *values_ptr;
> @@ -451,55 +450,43 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EINVAL;
>
> -   drm_modeset_lock_all(dev);
> property = drm_property_find(dev, out_resp->prop_id);
> -   if (!property) {
> -   ret = -ENOENT;
> -   goto done;
> -   }
> -
> -   if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
> -   drm_property_type_is(property, 
> DRM_MODE_PROP_BITMASK)) {
> -   list_for_each_entry(prop_enum, >enum_list, head)
> -   enum_count++;
> -   }
> -
> -   value_count = property->num_values;
> +   if (!property)
> +   return -ENOENT;
>
> strncpy(out_resp->name, property->name, DRM_PROP_NAME_LEN);
> out_resp->name[DRM_PROP_NAME_LEN-1] = 0;
> out_resp->flags = property->flags;
>
> -   if ((out_resp->count_values >= value_count) && value_count) {
> -   values_ptr = (uint64_t __user *)(unsigned 
> long)out_resp->values_ptr;
> -   for (i = 0; i < value_count; i++) {
> -   if (copy_to_user(values_ptr + i, 
> >values[i], sizeof(uint64_t))) {
> -   ret = -EFAULT;
> -   goto done;
> -   }
> +   value_count = property->num_values;
> +   values_ptr = u64_to_user_ptr(out_resp->values_ptr);
> +
> +   for (i = 0; i < value_count; i++) {
> +   if (i < out_resp->count_values &&
> +   put_user(property->values[i], values_ptr + i)) {
> +   return -EFAULT;
> }
> }
> out_resp->count_values = value_count;
>
> +   copied = 0;
> +   enum_ptr = u64_to_user_ptr(out_resp->enum_blob_ptr);
> +
> if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
> -   drm_property_type_is(property, 
> DRM_MODE_PROP_BITMASK)) {
> -   if ((out_resp->count_enum_blobs >= enum_count) && enum_count) 
> {
> -   copied = 0;
> -   enum_ptr = (struct drm_mode_property_enum __user 
> *)(unsigned long)out_resp->enum_blob_ptr;
> -   list_for_each_entry(prop_enum, >enum_list, 
> head) {
> -
> -   if (copy_to_user(_ptr[copied].value, 
> _enum->value, sizeof(uint64_t))) {
> -   ret = -EFAULT;
> -   goto done;
> -   }
> -
> -   if (copy_to_user(_ptr[copied].name,
> -_enum->name, 
> DRM_PROP_NAME_LEN)) {
> -   ret = -EFAULT;
> -   goto done;
> -   }
> -   copied++;
> -   }
> +   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
> +   list_for_each_entry(prop_enum, >enum_list, head) {
> +   enum_count++;
> +   if (out_resp->count_enum_blobs <= enum_count)
> +   continue;
> +
> +   if (copy_to_user(_ptr[copied].value,
> +

[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #3 from Andres Rodriguez  ---
Reverting the following commit fixes this branch for me:
eb8eb02 drm: Drop modeset_lock_all from the getproperty ioctl

Let me check if I can make a quick fix for it.

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


[Bug 100675] No signal on DisplayPort [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100675

Bug ID: 100675
   Summary: No signal on DisplayPort [drm:radeon_dp_link_train
[radeon]] *ERROR* displayport link status failed
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: oleg.hoefl...@gmail.com

Created attachment 130835
  --> https://bugs.freedesktop.org/attachment.cgi?id=130835=edit
dmesg log

First of all, this is the first bug reported by me, so I apologize in advance
if I assigned it to a wrong category. I have a monitor, a DisplayPort cable and
two notebooks. When the monitor is connected to the first notebook (Lenovo
T440), everything works fine, so the cable seems is working fine. Now, when the
monitor is connected to the second notebook, it shows "no signal is detected"
and switches into sleep mode. Here is what dmesg outputs (I will attach the
complete dmesg log):

[   12.064503] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link
status failed
[   12.064517] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
failed

Of course, after logging into the X session, the monitor remains black,
although Xorg does not report any errors in log:

$ grep -n EE /var/log/Xorg.0.log
16: (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

System:

Linux msi_gx70 4.10.9-gentoo #2 SMP Thu Apr 13 21:30:04 CEST 2017 x86_64 AMD
A10-5750M APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux

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


[PATCH] drm/i915: checking for NULL instead of IS_ERR() in mock selftests

2017-04-13 Thread Dan Carpenter
i915_gem_request_alloc() uses error pointers.  It never returns NULLs.

Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/selftests/mock_request.c 
b/drivers/gpu/drm/i915/selftests/mock_request.c
index 0e8d2e7f8c70..8097e3693ec4 100644
--- a/drivers/gpu/drm/i915/selftests/mock_request.c
+++ b/drivers/gpu/drm/i915/selftests/mock_request.c
@@ -35,7 +35,7 @@ mock_request(struct intel_engine_cs *engine,
 
/* NB the i915->requests slab cache is enlarged to fit mock_request */
request = i915_gem_request_alloc(engine, context);
-   if (!request)
+   if (IS_ERR(request))
return NULL;
 
mock = container_of(request, typeof(*mock), base);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: uninitialized value on error path

2017-04-13 Thread Dan Carpenter
"ret" isn't initialized on this error path.  It doesn't really cause
any problems unless it's randomly set to -EDEADLK which is not likely.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 48a546210d8b..d0e9578952d5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9563,6 +9563,7 @@ int intel_get_load_detect_pipe(struct drm_connector 
*connector,
 */
if (!crtc) {
DRM_DEBUG_KMS("no pipe available for load-detect\n");
+   ret = -ENODEV;
goto fail;
}
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [drm-tip:drm-tip 1/7] drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset'

2017-04-13 Thread Jani Nikula
On Thu, 13 Apr 2017, kbuild test robot  wrote:
> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head:   f1faf571d9530365a34fe33a3efa3fb224661692
> commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking 
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-randconfig-i0-201715 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> git checkout 15b670ebb1bb7309b60c23b3fa1479d31cd79122
> # save the attached .config to linux build tree
> make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>>> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
>>> redefinition of 'nv137_chipset'
> nv137_chipset = {
> ^
>drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2290:1: note: previous 
> definition of 'nv137_chipset' was here
> nv137_chipset = {
> ^

Blergh, this is probably due to me messing up a conflict resolution for
drm-tip.

BR,
Jani.

>
> vim +/nv137_chipset +2347 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
>
> fa1dbc49 Alexandre Courbot 2017-03-29  2331   .imem = gk20a_instmem_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2332   .ltc = gp100_ltc_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2333   .mc = gp10b_mc_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2334   .mmu = gf100_mmu_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2335   .secboot = gp10b_secboot_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2336   .pmu = gm20b_pmu_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2337   .timer = gk20a_timer_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2338   .top = gk104_top_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2339   .ce[2] = gp102_ce_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2340   .dma = gf119_dma_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2341   .fifo = gp10b_fifo_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2342   .gr = gp10b_gr_new,
> fa1dbc49 Alexandre Courbot 2017-03-29  2343   .sw = gf100_sw_new,
> 1fe487d7 Ben Skeggs2016-12-09  2344  };
> 1fe487d7 Ben Skeggs2016-12-09  2345  
> da2ba564 Ben Skeggs2017-04-06  2346  static const struct 
> nvkm_device_chip
> da2ba564 Ben Skeggs2017-04-06 @2347  nv137_chipset = {
> da2ba564 Ben Skeggs2017-04-06  2348   .name = "GP107",
> da2ba564 Ben Skeggs2017-04-06  2349   .bar = gf100_bar_new,
> da2ba564 Ben Skeggs2017-04-06  2350   .bios = nvkm_bios_new,
> da2ba564 Ben Skeggs2017-04-06  2351   .bus = gf100_bus_new,
> da2ba564 Ben Skeggs2017-04-06  2352   .devinit = gm200_devinit_new,
> da2ba564 Ben Skeggs2017-04-06  2353   .fb = gp102_fb_new,
> da2ba564 Ben Skeggs2017-04-06  2354   .fuse = gm107_fuse_new,
> da2ba564 Ben Skeggs2017-04-06  2355   .gpio = gk104_gpio_new,
>
> :: The code at line 2347 was first introduced by commit
> :: da2ba564a6dcf46df4f828624ff55531ff11d5b0 drm/nouveau: initial support 
> (display-only) for GP107
>
> :: TO: Ben Skeggs 
> :: CC: Ben Skeggs 
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH v2 5/5] drm/vc4: Expose dma-buf fences for V3D rendering.

2017-04-13 Thread Eric Anholt
Daniel Vetter  writes:

> On Wed, Apr 12, 2017 at 12:12:02PM -0700, Eric Anholt wrote:
>> This is needed for proper synchronization with display on another DRM
>> device (pl111 or tinydrm) with buffers produced by vc4 V3D.  Fixes the
>> new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
>> desktop tests on pl111+vc4.
>> 
>> This doesn't yet introduce waits on other device's fences before vc4's
>> rendering/display, because I don't have testcases for them.
>> 
>> v2: Reuse dma_fence_free(), retitle commit message to clarify that
>> it's not a full dma-buf fencing implementation yet.
>> 
>> Signed-off-by: Eric Anholt 
>
> Double-checked a few things in your ww_mutex scheme, seems are correct.
> And testing with CONFIG_DEBUG_WW_MUTEX_SLOWPATH should catch any kind of
> fumbles in your error paths. I didnt do a full review, so just
>
> Acked-by: Daniel Vetter 

The two other most likely reviewers (ickle and padovan) have at least
glanced at it, so I've pushed it now.


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


Re: [PATCH] drm/doc: Interlink color manager docs better

2017-04-13 Thread Lionel Landwerlin

I have a tiny suggestion down there. Regardless this is :

Reviewed-by: Lionel Landwerlin 

On 12/04/17 08:20, Daniel Vetter wrote:

Motivated by a request from Eric.

Cc: Eric Anholt 
Cc: Lionel Landwerlin 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/drm_atomic_helper.c |  3 ++-
  drivers/gpu/drm/drm_color_mgmt.c|  9 ++---
  include/drm/drm_crtc.h  | 31 +--
  3 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c3403edd0285..442724a80010 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3518,7 +3518,8 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_destroy_state);
   *
   * Implements support for legacy gamma correction table for drivers
   * that support color management through the DEGAMMA_LUT/GAMMA_LUT
- * properties.
+ * properties. See drm_crtc_enable_color_mgmt() and the containing chapter for
+ * how the atomic color management and gamma tables work.
   */
  int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
   u16 *red, u16 *green, u16 *blue,
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 533f3a3e6877..3eda500fc005 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -43,7 +43,8 @@
   *
   *Setting this to NULL (blob property value set to 0) means a
   *linear/pass-thru gamma table should be used. This is generally the
- * driver boot-up state too.
+ * driver boot-up state too. Drivers can access this blob through
+ * _crtc_state.degamma_lut.
   *
   * “DEGAMMA_LUT_SIZE”:
   *Unsinged range property to give the size of the lookup table to be set
@@ -60,7 +61,8 @@
   *
   *Setting this to NULL (blob property value set to 0) means a
   *unit/pass-thru matrix should be used. This is generally the driver
- * boot-up state too.
+ * boot-up state too. Drivers can access the blob for the color conversion
+ * matrix through _crtc_state.ctm.
   *
   * “GAMMA_LUT”:
   *Blob property to set the gamma lookup table (LUT) mapping pixel data
@@ -72,7 +74,8 @@
   *
   *Setting this to NULL (blob property value set to 0) means a
   *linear/pass-thru gamma table should be used. This is generally the
- * driver boot-up state too.
+ * driver boot-up state too. Drivers can access this blob through
+ * _crtc_state.gamma_lut.
   *
   * “GAMMA_LUT_SIZE”:
   *Unsigned range property to give the size of the lookup table to be set
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a8176a836e25..60b128a9e723 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -93,11 +93,6 @@ struct drm_plane_helper_funcs;
   * @adjusted_mode: for use by helpers and drivers to compute adjusted mode 
timings
   * @mode: current mode timings
   * @mode_blob: _property_blob for @mode
- * @degamma_lut: Lookup table for converting framebuffer pixel data
- * before apply the conversion matrix
- * @ctm: Transformation matrix
- * @gamma_lut: Lookup table for converting pixel data after the
- * conversion matrix
   * @state: backpointer to global drm_atomic_state
   *
   * Note that the distinction between @enable and @active is rather subtile:
@@ -144,9 +139,27 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
  
-	/* blob property to expose color management to userspace */

+   /**
+* @degamma_lut:
+*
+* Lookup table for converting framebuffer pixel data before apply the
+* color conversion matrix @ctm. See drm_crtc_enable_color_mgmt().


Maybe you can add that the blob is either NULL or an array of drm_color_lut.


+*/
struct drm_property_blob *degamma_lut;
+
+   /**
+* @ctm:
+*
+* Color transformation matrix. See drm_crtc_enable_color_mgmt().


Here is blob is drm_color_ctm.


+*/
struct drm_property_blob *ctm;
+
+   /**
+* @gamma_lut:
+*
+* Lookup table for converting pixel data after the color conversion
+* matrix @ctm.  See drm_crtc_enable_color_mgmt().


Here again NULL or an array of drm_color_lut.


+*/
struct drm_property_blob *gamma_lut;
  
  	/**

@@ -313,6 +326,12 @@ struct drm_crtc_funcs {
 *
 * This callback is optional.
 *
+* Atomic drivers who want to support gamma tables should implement the
+* atomic color management support, enabled by calling
+* drm_crtc_enable_color_mgmt(), which then supports the legacy gamma
+* interface through the drm_atomic_helper_legacy_gamma_set()
+* compatibility implementation.
+ 

Re: KMS question

2017-04-13 Thread Boszormenyi Zoltan

2017-04-13 18:20 keltezéssel, Ville Syrjälä írta:

On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote:

On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher  wrote:

On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan  wrote:

2017-04-13 16:05 keltezéssel, Alex Deucher írta:


On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:


Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.



I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.


Can you enable it via randr?


I think the video= based disable forces the connector to be disabled
irrevocably.


# echo detect > /sys/class/drm//status



Thanks, that worked.

I had to regenerate my initramfs to actually include the gma500 driver
so KMS can kick in early. Before that the text mode plugin was used in
plymouth and that doesn't switch dimensions when fbdev took over.

The plymouth boot splash now looks good on the primary screen with
the secondary display disabled from the kernel command line and I can
enable the secondary screen from a boot script before X (a DM) starts
which causes both screens to flash but it's good for me now.

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


Re: [PATCH v2 5/5] drm/vc4: Expose dma-buf fences for V3D rendering.

2017-04-13 Thread Eric Anholt
Daniel Vetter  writes:

> On Wed, Apr 12, 2017 at 12:12:02PM -0700, Eric Anholt wrote:
>> This is needed for proper synchronization with display on another DRM
>> device (pl111 or tinydrm) with buffers produced by vc4 V3D.  Fixes the
>> new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
>> desktop tests on pl111+vc4.
>> 
>> This doesn't yet introduce waits on other device's fences before vc4's
>> rendering/display, because I don't have testcases for them.
>> 
>> v2: Reuse dma_fence_free(), retitle commit message to clarify that
>> it's not a full dma-buf fencing implementation yet.
>> 
>> Signed-off-by: Eric Anholt 
>
> Double-checked a few things in your ww_mutex scheme, seems are correct.
> And testing with CONFIG_DEBUG_WW_MUTEX_SLOWPATH should catch any kind of
> fumbles in your error paths. I didnt do a full review, so just

Yeah, the lockdep and WW debug options were incredibly useful (and I
should probably go turn them off now).


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


drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gdf0abb111336)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc6-1950-gdf0abb111336)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1950-gdf0abb111336
Git Commit: df0abb1113368aa0af16907c769116ff6273812f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
redefinition of 'nv137_chipset'

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gf1faf571d953)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed 
(v4.11-rc6-1950-gf1faf571d953)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1950-gf1faf571d953
Git Commit: f1faf571d9530365a34fe33a3efa3fb224661692
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 11 unique boards, 4 SoC families, 11 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: KMS question

2017-04-13 Thread Ville Syrjälä
On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote:
> On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher  wrote:
> > On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan  wrote:
> >> 2017-04-13 16:05 keltezéssel, Alex Deucher írta:
> >>>
> >>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:
> 
>  Hi,
> 
>  how can I disable the behaviour in the KMS drivers
>  that enables all outputs at once?
> 
>  It is very annoying that on a POS machine with an
>  1024x768 LVDS and a 800x480 secondary monitor (both built-in)
>  the KMS driver wakes up both. Then the framebuffer console
>  and plymouth use both screens, making the primary output
>  very odd with only the top-left part used by the boot splash.
> 
>  I would like the boot splash to be shown only on the primary
>  output at its full resolution instead of on all outputs using
>  the smallest common rectangle.
> 
>  Is there a kernel command line configuration that achieves this?
> 
>  The device in question uses the gma500 kernel driver but the same
>  behaviour is observed with the i915 and radeon drivers.
> 
> >>>
> >>> The problem is fbdev is not multi-head aware.  The fbdev emulation in
> >>> the KMS drivers attempts to light up all monitors so that something
> >>> shows up on all heads.  If you really want different per head
> >>> configurations, you need to use the KMS API directly.  As a
> >>> workaround, you can use the kernel command line to disable the output
> >>> you don't want to be lit up.  See:
> >>> https://wiki.archlinux.org/index.php/kernel_mode_setting
> >>> for more info.  basically add video=TV-1:d to disable the output in
> >>> question.  Replace TV-1 with whatever connector you want to disable.
> >>
> >>
> >> I tried adding video=DVI-D-1:d to the kernel command line.
> >>
> >> The effect is while the second output is indeed disabled, the
> >> framebuffer console still takes the second output's resolution
> >> into account and the boot splash is still using only the top-left
> >> 800x480 part of the 1024x768 primary screen.
> >>
> >> Also, the secondary screen got disabled also in X which is not desired.
> >> Can I wake it up under X somehow? This device is using the modesetting
> >> DDX driver.
> >
> > Can you enable it via randr?
> 
> I think the video= based disable forces the connector to be disabled
> irrevocably.

# echo detect > /sys/class/drm//status

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1949-g74e7a6859913)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed 
(v4.11-rc6-1949-g74e7a6859913)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1949-g74e7a6859913
Git Commit: 74e7a68599131906746cd65229beb772697e50f0
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 11 unique boards, 4 SoC families, 11 builds out of 207

Boot Failures Detected:

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH libdrm] Header: Add rotation property fields

2017-04-13 Thread Robert Foss
From: Sean Paul 

From drm_crtc.h, for use with the plane "rotation" property.

Signed-off-by: Sean Paul 
Signed-off-by: Robert Foss 
---
 include/drm/drm.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 1e7a4bc7a505..656c90045161 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -74,6 +74,14 @@ extern "C" {
 #define _DRM_LOCK_IS_CONT(lock)   ((lock) & _DRM_LOCK_CONT)
 #define _DRM_LOCKING_CONTEXT(lock) ((lock) & ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
 
+/* Rotation property bits */
+#define DRM_ROTATE_0   0
+#define DRM_ROTATE_90  1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X  4
+#define DRM_REFLECT_Y  5
+
 typedef unsigned int drm_context_t;
 typedef unsigned int drm_drawable_t;
 typedef unsigned int drm_magic_t;
-- 
2.11.0.453.g787f75f05

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


[Bug 100618] Dead Island crash after starting a new game

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100618

--- Comment #12 from at...@t-online.de ---
Created attachment 130831
  --> https://bugs.freedesktop.org/attachment.cgi?id=130831=edit
valgrind logfile

An absolute path was the key. Logfile from valgrind is attached.

-- 
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: [GIT PULL] mediatek-drm-next for 4.12

2017-04-13 Thread CK Hu
Hi, Dave:

Sorry for my mistake, I would remember to add Signed-off-by me.

Regards,
CK

On Thu, 2017-04-13 at 06:19 +1000, Dave Airlie wrote:
> On 8 April 2017 at 02:42, CK Hu  wrote:
> > Hi, Dave:
> >
> > This series is MT2701 DRM support.
> 
> Just FYI, I failed to notice this, but Stephen pointed it out,
> 
> please make sure you add a Signed-off-by line if you are committing
> other people's patch to a tree, As the maintainer you must add these,
> not Acked-by.
> 
> Acked-by are for non-maintainers.
> 
> In this case I can't go back and undo things at this stage, they have
> an Signed-off-by from a mediatek employee anyways which should leave
> them in good standing.
> 
> Dave.


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


[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98604

--- Comment #15 from Dieter Nützel  ---
Michel and Christian,

can we have this patch in 17.1 (final)?
I have to apply it by hand on every build.

Any further logs/debug needed?

-- 
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: KMS question

2017-04-13 Thread Boszormenyi Zoltan

2017-04-13 17:36 keltezéssel, Alex Deucher írta:

On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan  wrote:

2017-04-13 16:05 keltezéssel, Alex Deucher írta:


On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:


Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.



I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.


Can you enable it via randr?


No, "xrandr --output DVI-D-1 --auto" does nothing.



Alex



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


[drm-tip:drm-tip 1/7] drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset'

2017-04-13 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   f1faf571d9530365a34fe33a3efa3fb224661692
commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking 
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-randconfig-i0-201715 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 15b670ebb1bb7309b60c23b3fa1479d31cd79122
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
>> redefinition of 'nv137_chipset'
nv137_chipset = {
^
   drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2290:1: note: previous 
definition of 'nv137_chipset' was here
nv137_chipset = {
^

vim +/nv137_chipset +2347 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c

fa1dbc49 Alexandre Courbot 2017-03-29  2331 .imem = gk20a_instmem_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2332 .ltc = gp100_ltc_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2333 .mc = gp10b_mc_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2334 .mmu = gf100_mmu_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2335 .secboot = gp10b_secboot_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2336 .pmu = gm20b_pmu_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2337 .timer = gk20a_timer_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2338 .top = gk104_top_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2339 .ce[2] = gp102_ce_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2340 .dma = gf119_dma_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2341 .fifo = gp10b_fifo_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2342 .gr = gp10b_gr_new,
fa1dbc49 Alexandre Courbot 2017-03-29  2343 .sw = gf100_sw_new,
1fe487d7 Ben Skeggs2016-12-09  2344  };
1fe487d7 Ben Skeggs2016-12-09  2345  
da2ba564 Ben Skeggs2017-04-06  2346  static const struct 
nvkm_device_chip
da2ba564 Ben Skeggs2017-04-06 @2347  nv137_chipset = {
da2ba564 Ben Skeggs2017-04-06  2348 .name = "GP107",
da2ba564 Ben Skeggs2017-04-06  2349 .bar = gf100_bar_new,
da2ba564 Ben Skeggs2017-04-06  2350 .bios = nvkm_bios_new,
da2ba564 Ben Skeggs2017-04-06  2351 .bus = gf100_bus_new,
da2ba564 Ben Skeggs2017-04-06  2352 .devinit = gm200_devinit_new,
da2ba564 Ben Skeggs2017-04-06  2353 .fb = gp102_fb_new,
da2ba564 Ben Skeggs2017-04-06  2354 .fuse = gm107_fuse_new,
da2ba564 Ben Skeggs2017-04-06  2355 .gpio = gk104_gpio_new,

:: The code at line 2347 was first introduced by commit
:: da2ba564a6dcf46df4f828624ff55531ff11d5b0 drm/nouveau: initial support 
(display-only) for GP107

:: TO: Ben Skeggs 
:: CC: Ben Skeggs 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: KMS question

2017-04-13 Thread Ilia Mirkin
On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher  wrote:
> On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan  wrote:
>> 2017-04-13 16:05 keltezéssel, Alex Deucher írta:
>>>
>>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:

 Hi,

 how can I disable the behaviour in the KMS drivers
 that enables all outputs at once?

 It is very annoying that on a POS machine with an
 1024x768 LVDS and a 800x480 secondary monitor (both built-in)
 the KMS driver wakes up both. Then the framebuffer console
 and plymouth use both screens, making the primary output
 very odd with only the top-left part used by the boot splash.

 I would like the boot splash to be shown only on the primary
 output at its full resolution instead of on all outputs using
 the smallest common rectangle.

 Is there a kernel command line configuration that achieves this?

 The device in question uses the gma500 kernel driver but the same
 behaviour is observed with the i915 and radeon drivers.

>>>
>>> The problem is fbdev is not multi-head aware.  The fbdev emulation in
>>> the KMS drivers attempts to light up all monitors so that something
>>> shows up on all heads.  If you really want different per head
>>> configurations, you need to use the KMS API directly.  As a
>>> workaround, you can use the kernel command line to disable the output
>>> you don't want to be lit up.  See:
>>> https://wiki.archlinux.org/index.php/kernel_mode_setting
>>> for more info.  basically add video=TV-1:d to disable the output in
>>> question.  Replace TV-1 with whatever connector you want to disable.
>>
>>
>> I tried adding video=DVI-D-1:d to the kernel command line.
>>
>> The effect is while the second output is indeed disabled, the
>> framebuffer console still takes the second output's resolution
>> into account and the boot splash is still using only the top-left
>> 800x480 part of the 1024x768 primary screen.
>>
>> Also, the secondary screen got disabled also in X which is not desired.
>> Can I wake it up under X somehow? This device is using the modesetting
>> DDX driver.
>
> Can you enable it via randr?

I think the video= based disable forces the connector to be disabled
irrevocably.

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


Re: KMS question

2017-04-13 Thread Alex Deucher
On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan  wrote:
> 2017-04-13 16:05 keltezéssel, Alex Deucher írta:
>>
>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:
>>>
>>> Hi,
>>>
>>> how can I disable the behaviour in the KMS drivers
>>> that enables all outputs at once?
>>>
>>> It is very annoying that on a POS machine with an
>>> 1024x768 LVDS and a 800x480 secondary monitor (both built-in)
>>> the KMS driver wakes up both. Then the framebuffer console
>>> and plymouth use both screens, making the primary output
>>> very odd with only the top-left part used by the boot splash.
>>>
>>> I would like the boot splash to be shown only on the primary
>>> output at its full resolution instead of on all outputs using
>>> the smallest common rectangle.
>>>
>>> Is there a kernel command line configuration that achieves this?
>>>
>>> The device in question uses the gma500 kernel driver but the same
>>> behaviour is observed with the i915 and radeon drivers.
>>>
>>
>> The problem is fbdev is not multi-head aware.  The fbdev emulation in
>> the KMS drivers attempts to light up all monitors so that something
>> shows up on all heads.  If you really want different per head
>> configurations, you need to use the KMS API directly.  As a
>> workaround, you can use the kernel command line to disable the output
>> you don't want to be lit up.  See:
>> https://wiki.archlinux.org/index.php/kernel_mode_setting
>> for more info.  basically add video=TV-1:d to disable the output in
>> question.  Replace TV-1 with whatever connector you want to disable.
>
>
> I tried adding video=DVI-D-1:d to the kernel command line.
>
> The effect is while the second output is indeed disabled, the
> framebuffer console still takes the second output's resolution
> into account and the boot splash is still using only the top-left
> 800x480 part of the 1024x768 primary screen.
>
> Also, the secondary screen got disabled also in X which is not desired.
> Can I wake it up under X somehow? This device is using the modesetting
> DDX driver.

Can you enable it via randr?

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


[RFC v3.1 05/14] vb2: Anticipate queue specific DMA attributes for USERPTR buffers

2017-04-13 Thread Sakari Ailus
The DMA attributes were available for the memop implementation for MMAP
buffers but not for USERPTR buffers. Do the same for USERPTR. This patch
makes no functional changes.

Signed-off-by: Sakari Ailus 
---
since RFC v1:

- Add missing q->dma_attrs argument to call_ptr_memop(vb, get_userptr...

 drivers/media/v4l2-core/videobuf2-core.c   | 2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 3 ++-
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 3 ++-
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 3 ++-
 include/media/videobuf2-core.h | 3 ++-
 5 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e866115..c659b64 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1025,7 +1025,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
void *pb)
mem_priv = call_ptr_memop(vb, get_userptr,
q->alloc_devs[plane] ? : q->dev,
planes[plane].m.userptr,
-   planes[plane].length, dma_dir);
+   planes[plane].length, dma_dir, q->dma_attrs);
if (IS_ERR(mem_priv)) {
dprintk(1, "failed acquiring userspace memory for plane 
%d\n",
plane);
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index d29a07f..30082a4 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -475,7 +475,8 @@ static inline dma_addr_t vb2_dc_pfn_to_dma(struct device 
*dev, unsigned long pfn
 #endif
 
 static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr,
-   unsigned long size, enum dma_data_direction dma_dir)
+   unsigned long size, enum dma_data_direction dma_dir,
+   unsigned long attrs)
 {
struct vb2_dc_buf *buf;
struct frame_vector *vec;
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 29fde1a..102ddb2 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -220,7 +220,8 @@ static void vb2_dma_sg_finish(void *buf_priv)
 
 static void *vb2_dma_sg_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size,
-   enum dma_data_direction dma_dir)
+   enum dma_data_direction dma_dir,
+   unsigned long dma_attrs)
 {
struct vb2_dma_sg_buf *buf;
struct sg_table *sgt;
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index f83253a..a4914fc 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -73,7 +73,8 @@ static void vb2_vmalloc_put(void *buf_priv)
 
 static void *vb2_vmalloc_get_userptr(struct device *dev, unsigned long vaddr,
 unsigned long size,
-enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir,
+unsigned long dma_attrs)
 {
struct vb2_vmalloc_buf *buf;
struct frame_vector *vec;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c22..4172f6e 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -122,7 +122,8 @@ struct vb2_mem_ops {
 
void*(*get_userptr)(struct device *dev, unsigned long vaddr,
unsigned long size,
-   enum dma_data_direction dma_dir);
+   enum dma_data_direction dma_dir,
+   unsigned long dma_attrs);
void(*put_userptr)(void *buf_priv);
 
void(*prepare)(void *buf_priv);
-- 
2.7.4

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


[Bug 87738] [OpenCL] Please add Image support

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87738

--- Comment #3 from Vedran Miletić  ---
funfunctor has also worked on it a bit:
https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=clover-image-support
https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=clover-image-support-enabled

-- 
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: KMS question

2017-04-13 Thread Boszormenyi Zoltan

2017-04-13 16:05 keltezéssel, Alex Deucher írta:

On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:

Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.



The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.


I tried adding video=DVI-D-1:d to the kernel command line.

The effect is while the second output is indeed disabled, the
framebuffer console still takes the second output's resolution
into account and the boot splash is still using only the top-left
800x480 part of the 1024x768 primary screen.

Also, the secondary screen got disabled also in X which is not desired.
Can I wake it up under X somehow? This device is using the modesetting
DDX driver.

Thanks,
Zoltán



Alex



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


[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99553

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||6


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=6
[Bug 6] GPU fault detected on luxmark the Room test with AMD Tahiti
-- 
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 88886] GPU fault detected on luxmark the Room test with AMD Tahiti

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=6

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||99553

--- Comment #8 from Vedran Miletić  ---
Does this bug still occur?


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
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 87738] [OpenCL] Please add Image support

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=87738

--- Comment #2 from Vedran Miletić  ---
In case anyone works on it, I have saved Zoltan Gillian's patches here:
https://github.com/vedranmiletic/mesa/tree/r600-image-support

-- 
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 0/5] omapdrm: fences and zpos

2017-04-13 Thread Laurent Pinchart
Hi Tomi,

On Wednesday 05 Apr 2017 09:52:36 Tomi Valkeinen wrote:
> On 03/01/17 14:06, Tomi Valkeinen wrote:
> > I got this with your series. AM5 EVM, dual display, I run "kmstest --flip"
> > and then exit by pressing enter, which is when I see the warning. It
> > happens only sometimes, but having lots of cpu load (I used "stress -c
> > 4") makes the driver spam the warning.
> > 
> > [   67.207223] [ cut here ]
> > [   67.211937] WARNING: CPU: 1 PID: 324 at
> > drivers/gpu/drm/omapdrm/omap_gem.c:1085 omap_gem_free_object+0x270/0x2d4
> > [omapdrm] [   67.223138] Modules linked in: omapdrm drm_kms_helper drm
> > panel_dsi_cm panel_dpi connector_analog_tv connector_dvi connector_hdmi
> > encoder_tp d12s015 encoder_tfp410 omapdss cfbfillrect cfbimgblt
> > cfbcopyarea [last unloaded: omapdss] [   67.243953] CPU: 1 PID: 324 Comm:
> > kmstest Not tainted 4.9.0-rc8-00163-g55f4a6c2d775 #135
>
> After rebasing to latest drm-next, I no longer see this, but the kms++
> test script hangs when exiting it. And then I get BUGs from the kernel.
> Do you know if all the dependencies are in drm-next?

I've just rebased the patches on top of drm-next and I can't reproduce any of 
these two issues. I've ran kmstest --flip for 250 frames in a loop for half an 
hour, with and without CPU load (with 'stress -c 4') and everything works 
fine. I'll repost the rebased patches now.

-- 
Regards,

Laurent Pinchart

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


Re: KMS question

2017-04-13 Thread Alex Deucher
On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan  wrote:
> Hi,
>
> how can I disable the behaviour in the KMS drivers
> that enables all outputs at once?
>
> It is very annoying that on a POS machine with an
> 1024x768 LVDS and a 800x480 secondary monitor (both built-in)
> the KMS driver wakes up both. Then the framebuffer console
> and plymouth use both screens, making the primary output
> very odd with only the top-left part used by the boot splash.
>
> I would like the boot splash to be shown only on the primary
> output at its full resolution instead of on all outputs using
> the smallest common rectangle.
>
> Is there a kernel command line configuration that achieves this?
>
> The device in question uses the gma500 kernel driver but the same
> behaviour is observed with the i915 and radeon drivers.
>

The problem is fbdev is not multi-head aware.  The fbdev emulation in
the KMS drivers attempts to light up all monitors so that something
shows up on all heads.  If you really want different per head
configurations, you need to use the KMS API directly.  As a
workaround, you can use the kernel command line to disable the output
you don't want to be lit up.  See:
https://wiki.archlinux.org/index.php/kernel_mode_setting
for more info.  basically add video=TV-1:d to disable the output in
question.  Replace TV-1 with whatever connector you want to disable.

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


[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #2 from Alex Deucher  ---
(In reply to Andy Furniss from comment #1)
> Created attachment 130830 [details]
> dmesg with lots of warnings on startx (older kernel)

This was fixed here:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.12-wip=53552d5df6694f68f276b2e86f8162d0ef7cad93

-- 
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


KMS question

2017-04-13 Thread Boszormenyi Zoltan

Hi,

how can I disable the behaviour in the KMS drivers
that enables all outputs at once?

It is very annoying that on a POS machine with an
1024x768 LVDS and a 800x480 secondary monitor (both built-in)
the KMS driver wakes up both. Then the framebuffer console
and plymouth use both screens, making the primary output
very odd with only the top-left part used by the boot splash.

I would like the boot splash to be shown only on the primary
output at its full resolution instead of on all outputs using
the smallest common rectangle.

Is there a kernel command line configuration that achieves this?

The device in question uses the gma500 kernel driver but the same
behaviour is observed with the i915 and radeon drivers.

Thanks in advance,
Zoltán Böszörmenyi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gf1faf571d953)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc6-1950-gf1faf571d953)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1950-gf1faf571d953
Git Commit: f1faf571d9530365a34fe33a3efa3fb224661692
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
redefinition of 'nv137_chipset'

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1949-g74e7a6859913)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 
warnings (v4.11-rc6-1949-g74e7a6859913)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1949-g74e7a6859913
Git Commit: 74e7a68599131906746cd65229beb772697e50f0
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failures Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: FAIL
defconfig: FAIL
defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL
defconfig+CONFIG_KASAN=y: FAIL
defconfig+CONFIG_LKDTM=y: FAIL
defconfig+CONFIG_OF_UNITTEST=y: FAIL
defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y: FAIL
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL
multi_v7_defconfig+CONFIG_LKDTM=y: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL
multi_v7_defconfig+CONFIG_SMP=n: FAIL
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL
tegra_defconfig: FAIL

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: FAIL
allmodconfig+CONFIG_OF=n: FAIL

Errors and Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

allmodconfig: 1 error
defconfig: 1 error
defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error
defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error
defconfig+CONFIG_KASAN=y: 1 error, 4 warnings
defconfig+CONFIG_LKDTM=y: 1 error
defconfig+CONFIG_OF_UNITTEST=y: 1 error
defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 
error, 4 warnings
tegra_defconfig: 1 error

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 error
allmodconfig+CONFIG_OF=n: 1 error
defconfig+CONFIG_KASAN=y: 5 warnings

Errors summary:

 20  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: 
redefinition of 'nv137_chipset'

Warnings summary:

  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


drm-tip/drm-tip boot: 117 boots: 4 failed, 112 passed with 1 offline (v4.11-rc6-1945-g6184edce6665)

2017-04-13 Thread kernelci . org bot
drm-tip/drm-tip boot: 117 boots: 4 failed, 112 passed with 1 offline 
(v4.11-rc6-1945-g6184edce6665)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1945-g6184edce6665/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1945-g6184edce6665/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc6-1945-g6184edce6665
Git Commit: 6184edce6665aee9c9131149a7b9314a1313eaf9
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 15 unique boards, 8 SoC families, 23 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

--- Comment #1 from Andy Furniss  ---
Created attachment 130830
  --> https://bugs.freedesktop.org/attachment.cgi?id=130830=edit
dmesg with lots of warnings on startx (older kernel)

-- 
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 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx

2017-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100673

Bug ID: 100673
   Summary: Tonga agd5f drm-next-4.12-wip xorg segfault on startx
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: adf.li...@gmail.com

Created attachment 130829
  --> https://bugs.freedesktop.org/attachment.cgi?id=130829=edit
xorg log with segfault

With current agd5f  drm-next-4.12-wip I get a segfault on startx (xserver
1.19.3, git ddx,mesa,llvm. Log attached.

On the previous incarnation of the same kernel I can startx, but there are a
lot of warnings in dmesg every time the screen is turned on - ie. startx or
coming out of dpms. dmesg attached.

Don't know when I'll get time to bisect, so just getting these reported now.

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


[RFC v3 14/14] vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP

2017-04-13 Thread Sakari Ailus
The alloc() and put() ops are for MMAP buffers only. Document it.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 include/media/videobuf2-core.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 08f1d0e..dd67ae6 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -46,16 +46,16 @@ struct vb2_threadio_data;
 
 /**
  * struct vb2_mem_ops - memory handling/memory allocator operations
- * @alloc: allocate video memory and, optionally, allocator private data,
- * return ERR_PTR() on failure or a pointer to allocator private,
- * per-buffer data on success; the returned private structure
- * will then be passed as @buf_priv argument to other ops in this
- * structure. Additional gfp_flags to use when allocating the
- * are also passed to this operation. These flags are from the
- * gfp_flags field of vb2_queue.
- * @put:   inform the allocator that the buffer will no longer be used;
- * usually will result in the allocator freeing the buffer (if
- * no other users of this buffer are present); the @buf_priv
+ * @alloc: allocate video memory for an MMAP buffer and, optionally,
+ * allocator private data, return ERR_PTR() on failure or a pointer
+ * to allocator private, per-buffer data on success; the returned
+ * private structure will then be passed as @buf_priv argument to
+ * other ops in this structure. Additional gfp_flags to use when
+ * allocating the memory are also passed to this operation. These
+ * flags are from the gfp_flags field of vb2_queue.
+ * @put:   inform the allocator that the MMAP buffer will no longer be
+ * used; usually will result in the allocator freeing the buffer
+ * (if no other users of this buffer are present); the @buf_priv
  * argument is the allocator private per-buffer structure
  * previously returned from the alloc callback.
  * @get_dmabuf: acquire userspace memory for a hardware operation; used for
-- 
2.7.4

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


[PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Oscar Salvador
Hi again,

I've split the patches as Karol Herbst suggested.
I hope now it's fine.

This series of patches introduce the new hwmon_device_register_with_info
and gets rid of the old hwmon_device_register.

This patch adds the default sensors with their possible config values.
Just to prepare for the next patches


--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
19:18:09.638073562 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
19:19:44.244797202 +0200
@@ -692,6 +692,78 @@ static const struct attribute_group hwmo
 static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
 };
+
+static const u32 nouveau_config_chip[] = {
+   HWMON_C_UPDATE_INTERVAL,
+   0
+};
+
+static const u32 nouveau_config_in[] = {
+   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+   0
+};
+
+static const u32 nouveau_config_temp[] = {
+   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+   HWMON_T_EMERGENCY_HYST,
+   0
+};
+
+static const u32 nouveau_config_fan[] = {
+   HWMON_F_INPUT,
+   0
+};
+
+static const u32 nouveau_config_pwm[] = {
+   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+   0
+};
+
+static const u32 nouveau_config_power[] = {
+   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+   0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+   .type = hwmon_chip,
+   .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+   .type = hwmon_temp,
+   .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+   .type = hwmon_fan,
+   .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+   .type = hwmon_in,
+   .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+   .type = hwmon_pwm,
+   .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+   .type = hwmon_power,
+   .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+   _chip,
+   _temp,
+   _fan,
+   _in,
+   _pwm,
+   _power,
+   NULL
+};
 #endif
 
 int
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC v3 00/14] vb2: Handle user cache hints, allow drivers to choose cache coherency

2017-04-13 Thread Sakari Ailus
Hello,

This is a rebased and partially reworked version of the vb2 cache hints
support patch series posted by Laurent more three months ago. The patches
have been modified as needed by the upstream changes. There are a number
of other changes as well. Since then, patch ccc66e73 ("ARM: 8508/2:
videobuf2-dc: Let drivers specify DMA attrs") that supposedly added DMA
attribute support for videobuf2-dma-contig has been merged. For dma-contig
memory type, this patchset addresses issues in that patch instead of
providing support for the feature from scratch. It also adds support for
USERPTR buffer type and makes necessary changes to dma-sg memory type as
well. Details below.

I'm still posting this patchset as RFC as the dma-sg patch hasn't been
tested apart from compiling it. Otherwise the subject line would have
PATCH instead of RFC. Testing especially on a device using dma-sg would be
beneficial.


The videobuf2 memory managers use the DMA mapping API to handle cache
synchronization on systems that require them transparently for drivers. As
cache operations are expensive, system performances can be impacted. Cache
synchronization can't be skipped altogether if we want to retain correct
behaviour, but optimizations are possible in cases related to buffer sharing
between multiple devices without CPU access to the memory.

The first optimization covers cases where the memory never needs to be
accessed by the CPU (neither in kernelspace nor in userspace). In those cases,
as no CPU memory mappings exist, cache synchronization can be skipped. The
situation could be detected in the kernel as we have enough information to
determine whether CPU mappings for kernelspace or userspace exist (in the
first case because drivers should request them explicitly, in the second case
because the mmap() handler hasn't been invoked). This optimization is not
implemented currently but should at least be prototyped as it could improve
performances automatically in a large number of cases.

The second class of optimizations cover cases where the memory sometimes needs
to be accessed by the CPU. In those cases memory mapping must be created and
cache handled, but cache synchronization could be skipped for buffer that are
not touched by the CPU.

By default the following cache synchronization operations need to be performed
related to the buffer management ioctls. For simplicity means of QBUF below
apply to buf VIDIOC_QBUF and VIDIOC_PREPARE_BUF.

| QBUF  | DQBUF

CAPTURE | Invalidate| Invalidate (*)
OUTPUT  | Clean | -

(*) for systems using speculative pre-fetching only

The following cases can be optimized.

1. CAPTURE, the CPU has not written to the buffer before QBUF

   Cache invalidation can be skipped at QBUF time, but becomes required at
   DQBUF time on all systems, regardless of whether they use speculative
   prefetching.

2. CAPTURE, the CPU will not read from the buffer after DQBUF

   Cache invalidation can be skipped at DQBUF time.

3. CAPTURE, combination of (1) and (2)

   Cache invalidation can be skipped at both QBUF and DQBUF time.

4. OUTPUT, the CPU has not written to the buffer before QBUF

   Cache clean can be skipped at QBUF time.


The kernel can't detect thoses situations automatically and thus requires
hints from userspace to decide whether cache synchronization can be skipped.
It should be noted that those hints might not be honoured. In particular, if
userspace hints that it hasn't touched the buffer with the CPU, drivers might
need to perform memory accesses themselves (adding JPEG or MPEG headers to
buffers is a common case where CPU access could be needed in the kernel), in
which case the userspace hints will be ignored.

Getting the hints wrong will result in data corruption. Userspace applications
are allowed to shoot themselves in the foot, but driver are responsible for
deciding whether data corruption can pose a risk to the system in general. For
instance if the device could be made to crash, or behave in a way that would
jeopardize system security, reliability or performances, when fed with invalid
data, cache synchronization shall not be skipped solely due to possibly
incorrect userspace hints.

The V4L2 API defines two flags, V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and
V4L2_BUF_FLAG_NO_CACHE_SYNC, that can be used to provide cache-related hints
to the kernel. However, no kernel has ever implemented support for those flags
that are thus most likely unused.

A single flag is enough to cover all the optimization cases described above,
provided we keep track of the flag being set at QBUF time to force cache
invalidation at DQBUF time for case (1) if the  flag isn't set at DQBUF time.
This patch series thus cleans up the userspace API and merges both flags into
a single one.

One potential issue with case (1) is that cache invalidation at DQBUF time for
CAPTURE buffers isn't fully under the control of 

[RFC v3 08/14] vb2: dma-contig: Don't warn on failure in obtaining scatterlist

2017-04-13 Thread Sakari Ailus
vb2_dc_get_base_sgt() which obtains the scatterlist already prints
information on why the scatterlist could not be obtained.

Also, remove the useless warning of a failed kmalloc().

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index ddbbcf0..22636cd 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -370,10 +370,8 @@ static struct sg_table *vb2_dc_get_base_sgt(struct 
vb2_dc_buf *buf)
struct sg_table *sgt;
 
sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
-   if (!sgt) {
-   dev_err(buf->dev, "failed to alloc sg table\n");
+   if (!sgt)
return NULL;
-   }
 
ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
buf->size, buf->attrs);
@@ -400,7 +398,7 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, 
unsigned long flags)
if (!buf->dma_sgt)
buf->dma_sgt = vb2_dc_get_base_sgt(buf);
 
-   if (WARN_ON(!buf->dma_sgt))
+   if (!buf->dma_sgt)
return NULL;
 
dbuf = dma_buf_export(_info);
-- 
2.7.4

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


[RFC v3 06/14] vb2: dma-contig: Assign DMA attrs for a buffer unconditionally

2017-04-13 Thread Sakari Ailus
attrs used to be a pointer and the caller of vb2_dc_alloc() could
optionally provide it, or NULL. This was when struct dma_attrs was used
to describe DMA attributes rather than an unsigned long value. There is no
longer a need to maintain the condition, assign the value unconditionally.
There is no functional difference because the memory was initialised to
zero anyway.

Fixes: 00085f1e ("dma-mapping: use unsigned long for dma_attrs")
Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 30082a4..a8a46a8 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -149,8 +149,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long 
attrs,
if (!buf)
return ERR_PTR(-ENOMEM);
 
-   if (attrs)
-   buf->attrs = attrs;
+   buf->attrs = attrs;
buf->cookie = dma_alloc_attrs(dev, size, >dma_addr,
GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
-- 
2.7.4

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


Re: [PATCH v9] drm: Unplug drm device when unregistering it

2017-04-13 Thread jeffy

Hi Sean,

On 04/12/2017 11:03 PM, Sean Paul wrote:

On Wed, Apr 12, 2017 at 04:56:21PM +0800, Jeffy Chen wrote:

After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.

We're using an unplugged state to prevent something like that, so let's
reuse it here.

Also drop drm_unplug_dev, because it would be unused after other changes.

Signed-off-by: Jeffy Chen 

Changes in v9:
Move drm_device_set_plug_state into drm_drv.c .

Changes in v8:
Fix hang when unregistering drm dev with open_count 0.

Changes in v7:
Add drm_device_set_plug_state helper.

Changes in v6:
Reuse unplug status.

Changes in v5:
Fix wrong git account.

Changes in v2:
Fix some commit messages.



Hi Jeffy,
A couple bookkeeping notes:

- Please end the commit message with your Signed-off-by tag
- No need to send cover letters for one patch. All info should be in the commit
   message. Include superfluous information (such as tested on 4.4 kernel) after
   ---
hmm...i'm using u-boot's patman tool to send patches. and the changelogs 
would be formated by the tool.


i'll switch changelogs to drm style.



---
  drivers/gpu/drm/drm_drv.c | 26 ++
  drivers/gpu/drm/udl/udl_drv.c |  2 +-
  include/drm/drmP.h|  6 --
  include/drm/drm_drv.h |  1 -
  4 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb4..e1da4d1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -355,22 +355,6 @@ void drm_put_dev(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_put_dev);

-void drm_unplug_dev(struct drm_device *dev)
-{
-   /* for a USB device */
-   drm_dev_unregister(dev);
-
-   mutex_lock(_global_mutex);
-
-   drm_device_set_unplugged(dev);
-
-   if (dev->open_count == 0) {
-   drm_put_dev(dev);
-   }
-   mutex_unlock(_global_mutex);
-}
-EXPORT_SYMBOL(drm_unplug_dev);
-
  /*
   * DRM internal mount
   * We want to be able to allocate our own "struct address_space" to control
@@ -733,6 +717,13 @@ static void remove_compat_control_link(struct drm_device 
*dev)
kfree(name);
  }

+static inline void drm_device_set_plug_state(struct drm_device *dev,
+bool plugged)
+{
+   smp_wmb();
+   atomic_set(>unplugged, !plugged);
+}
+
  /**
   * drm_dev_register - Register DRM device
   * @dev: Device to register
@@ -787,6 +778,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);

+   drm_device_set_plug_state(dev, true);
+
ret = 0;

DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -826,6 +819,7 @@ void drm_dev_unregister(struct drm_device *dev)
drm_lastclose(dev);

dev->registered = false;
+   drm_device_set_plug_state(dev, false);

if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index cd8b017..5dbd916 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -108,7 +108,7 @@ static void udl_usb_disconnect(struct usb_interface 
*interface)
drm_kms_helper_poll_disable(dev);
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
-   drm_unplug_dev(dev);
+   drm_dev_unregister(dev);


I think you need drm_dev_unref here as well.

right, will do.


Sean


  }

  /*
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3bfafcd..980a204 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct 
drm_device *dev,
return ((dev->driver->driver_features & feature) ? 1 : 0);
  }

-static inline void drm_device_set_unplugged(struct drm_device *dev)
-{
-   smp_wmb();
-   atomic_set(>unplugged, 1);
-}
-
  static inline int drm_device_is_unplugged(struct drm_device *dev)
  {
int ret = atomic_read(>unplugged);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0fefc3f..eb63078 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -544,7 +544,6 @@ void drm_dev_unregister(struct drm_device *dev);
  void drm_dev_ref(struct drm_device *dev);
  void drm_dev_unref(struct drm_device *dev);
  void drm_put_dev(struct drm_device *dev);
-void drm_unplug_dev(struct drm_device *dev);

  int drm_dev_set_unique(struct drm_device *dev, const char *name);

--
2.1.4






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


[RFC v3 04/14] v4l: Unify cache management hint buffer flags

2017-04-13 Thread Sakari Ailus
The V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and V4L2_BUF_FLAG_NO_CACHE_CLEAN
buffer flags are currently not used by the kernel. Replace the definitions
by a single V4L2_BUF_FLAG_NO_CACHE_SYNC flag to be used by further
patches.

Different cache architectures should not be visible to the user space
which can make no meaningful use of the differences anyway. In case a
device can make use of non-coherent memory accesses, the necessary cache
operations depend on the CPU architecture and the buffer type, not the
requests of the user. The cache operation itself may be skipped on the
user's request which was the purpose of the two flags.

On ARM the invalidate and clean are separate operations whereas on
x86(-64) the two are a single operation (flush). Whether the hardware uses
the buffer for reading (V4L2_BUF_TYPE_*_OUTPUT*) or writing
(V4L2_BUF_TYPE_*CAPTURE*) already defines the required cache operation
(clean and invalidate, respectively). No user input is required.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/buffer.rst| 24 --
 .../media/uapi/v4l/vidioc-prepare-buf.rst  |  5 ++---
 include/trace/events/v4l2.h|  3 +--
 include/uapi/linux/videodev2.h |  7 +--
 4 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ac58966..601c3e9 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -437,23 +437,17 @@ Buffer Flags
:ref:`VIDIOC_PREPARE_BUF `,
:ref:`VIDIOC_QBUF` or
:ref:`VIDIOC_DQBUF ` ioctl is called.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`:
+* .. _`V4L2-BUF-FLAG-NO-CACHE-SYNC`:
 
-  - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE``
+  - ``V4L2_BUF_FLAG_NO_CACHE_SYNC``
   - 0x0800
-  - Caches do not have to be invalidated for this buffer. Typically
-   applications shall use this flag if the data captured in the
-   buffer is not going to be touched by the CPU, instead the buffer
-   will, probably, be passed on to a DMA-capable hardware unit for
-   further processing or output.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
-
-  - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
-  - 0x1000
-  - Caches do not have to be cleaned for this buffer. Typically
-   applications shall use this flag for output buffers if the data in
-   this buffer has not been created by the CPU but by some
-   DMA-capable unit, in which case caches have not been used.
+  - Do not perform CPU cache synchronisation operations when the buffer is
+   queued or dequeued. The user is responsible for the correct use of
+   this flag. It should be only used when the buffer is not accessed
+   using the CPU, e.g. the buffer is written to by a hardware block and
+   then read by another one, in which case the flag should be set in both
+   :ref:`VIDIOC_QBUF` and :ref:`VIDIOC_DQBUF` ioctls. The flag has no
+   effect on some devices / architectures.
 * .. _`V4L2-BUF-FLAG-LAST`:
 
   - ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst 
b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
index bdcfd9f..80aeb7e 100644
--- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
@@ -36,9 +36,8 @@ pass ownership of the buffer to the driver before actually 
enqueuing it,
 using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such
 preparations may include cache invalidation or cleaning. Performing them
 in advance saves time during the actual I/O. In case such cache
-operations are not required, the application can use one of
-``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` and
-``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` flags to skip the respective step.
+operations are not required, the application can use the
+``V4L2_BUF_FLAG_NO_CACHE_SYNC`` flag to skip the cache synchronization step.
 
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index ee7754c..fb9ad7b 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -80,8 +80,7 @@ SHOW_FIELD
{ V4L2_BUF_FLAG_ERROR,   "ERROR" },   \
{ V4L2_BUF_FLAG_TIMECODE,"TIMECODE" },\
{ V4L2_BUF_FLAG_PREPARED,"PREPARED" },\
-   { V4L2_BUF_FLAG_NO_CACHE_INVALIDATE, "NO_CACHE_INVALIDATE" }, \
-   { V4L2_BUF_FLAG_NO_CACHE_CLEAN,  "NO_CACHE_CLEAN" },  \
+   { V4L2_BUF_FLAG_NO_CACHE_SYNC,   "NO_CACHE_SYNC" },   \
{ V4L2_BUF_FLAG_TIMESTAMP_MASK,  "TIMESTAMP_MASK" },  \
{ 

[PATCH 1/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Oscar Salvador
This patch introduces the structure "struct hwmon_ops"  and sets up the  
".visible" operation.
Is also a preparation for the next patch.

--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
19:18:09.638073562 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
19:19:44.244797202 +0200
@@ -692,6 +692,78 @@ static const struct attribute_group hwmo
 static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
 };
+
+static const u32 nouveau_config_chip[] = {
+   HWMON_C_UPDATE_INTERVAL,
+   0
+};
+
+static const u32 nouveau_config_in[] = {
+   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+   0
+};
+
+static const u32 nouveau_config_temp[] = {
+   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+   HWMON_T_EMERGENCY_HYST,
+   0
+};
+
+static const u32 nouveau_config_fan[] = {
+   HWMON_F_INPUT,
+   0
+};
+
+static const u32 nouveau_config_pwm[] = {
+   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+   0
+};
+
+static const u32 nouveau_config_power[] = {
+   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+   0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+   .type = hwmon_chip,
+   .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+   .type = hwmon_temp,
+   .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+   .type = hwmon_fan,
+   .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+   .type = hwmon_in,
+   .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+   .type = hwmon_pwm,
+   .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+   .type = hwmon_power,
+   .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+   _chip,
+   _temp,
+   _fan,
+   _in,
+   _pwm,
+   _power,
+   NULL
+};
 #endif
 
 int
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC v3 12/14] vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs

2017-04-13 Thread Sakari Ailus
The desirable DMA attributes are not generic for all devices using
Videobuf2 scatter-gather DMA ops. Let the drivers decide.

As a result, also the DMA-BUF exporter must provide ops for synchronising
the cache. This adds begin_cpu_access and end_cpu_access ops to
vb2_dc_dmabuf_ops.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 81 +++---
 1 file changed, 62 insertions(+), 19 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 102ddb2..5662f00 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -38,6 +38,7 @@ struct vb2_dma_sg_buf {
struct frame_vector *vec;
int offset;
enum dma_data_direction dma_dir;
+   unsigned long   dma_attrs;
struct sg_table sg_table;
/*
 * This will point to sg_table when used with the MMAP or USERPTR
@@ -114,6 +115,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned 
long dma_attrs,
 
buf->vaddr = NULL;
buf->dma_dir = dma_dir;
+   buf->dma_attrs = dma_attrs;
buf->offset = 0;
buf->size = size;
/* size is already page aligned */
@@ -143,7 +145,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned 
long dma_attrs,
 * prepare() memop is called.
 */
sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_dir, dma_attrs);
if (!sgt->nents)
goto fail_map;
 
@@ -181,7 +183,7 @@ static void vb2_dma_sg_put(void *buf_priv)
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
-  buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+  buf->dma_dir, buf->dma_attrs);
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
@@ -198,12 +200,13 @@ static void vb2_dma_sg_prepare(void *buf_priv)
struct vb2_dma_sg_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (buf->db_attach)
-   return;
-
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
-  buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->dma_attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+  buf->dma_dir);
 }
 
 static void vb2_dma_sg_finish(void *buf_priv)
@@ -211,11 +214,13 @@ static void vb2_dma_sg_finish(void *buf_priv)
struct vb2_dma_sg_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (buf->db_attach)
-   return;
-
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->dma_attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
+   buf->dma_dir);
 }
 
 static void *vb2_dma_sg_get_userptr(struct device *dev, unsigned long vaddr,
@@ -237,6 +242,7 @@ static void *vb2_dma_sg_get_userptr(struct device *dev, 
unsigned long vaddr,
buf->vaddr = NULL;
buf->dev = dev;
buf->dma_dir = dma_dir;
+   buf->dma_attrs = dma_attrs;
buf->offset = vaddr & ~PAGE_MASK;
buf->size = size;
buf->dma_sgt = >sg_table;
@@ -260,7 +266,7 @@ static void *vb2_dma_sg_get_userptr(struct device *dev, 
unsigned long vaddr,
 * prepare() memop is called.
 */
sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_dir, dma_attrs);
if (!sgt->nents)
goto userptr_fail_map;
 
@@ -288,7 +294,7 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
dprintk(1, "%s: Releasing userspace buffer of %d pages\n",
   __func__, buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir,
-  DMA_ATTR_SKIP_CPU_SYNC);
+  buf->dma_attrs);
if 

[RFC v3 02/14] vb2: Move buffer cache synchronisation to prepare from queue

2017-04-13 Thread Sakari Ailus
The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.

Mmap buffers do not need cache synchronisation since they are always
coherent.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 8df680d..8bf3369 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1227,23 +1227,19 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
const void *pb)
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
-   unsigned int plane;
 
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
trace_vb2_buf_queue(q, vb);
 
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
-
call_void_vb_qop(vb, buf_queue, vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;
int ret;
 
if (q->error) {
@@ -1268,11 +1264,19 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
ret = -EINVAL;
}
 
-   if (ret)
+   if (ret) {
dprintk(1, "buffer preparation failed: %d\n", ret);
-   vb->state = ret ? VB2_BUF_STATE_DEQUEUED : VB2_BUF_STATE_PREPARED;
+   vb->state = VB2_BUF_STATE_DEQUEUED;
+   return ret;
+   }
 
-   return ret;
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+
+   vb->state = VB2_BUF_STATE_PREPARED;
+
+   return 0;
 }
 
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
-- 
2.7.4

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


[RFC v3 09/14] vb2: dma-contig: Move vb2_dc_get_base_sgt() up

2017-04-13 Thread Sakari Ailus
Just move the function up. It'll be soon needed earlier than previously.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 40 +-
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 22636cd..8ea9ab9 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -63,6 +63,26 @@ static unsigned long vb2_dc_get_contiguous_size(struct 
sg_table *sgt)
return size;
 }
 
+static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
+{
+   int ret;
+   struct sg_table *sgt;
+
+   sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
+   if (!sgt)
+   return NULL;
+
+   ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
+   buf->size, buf->attrs);
+   if (ret < 0) {
+   dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
+   kfree(sgt);
+   return NULL;
+   }
+
+   return sgt;
+}
+
 /*/
 /* callbacks for all buffers */
 /*/
@@ -364,26 +384,6 @@ static struct dma_buf_ops vb2_dc_dmabuf_ops = {
.release = vb2_dc_dmabuf_ops_release,
 };
 
-static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
-{
-   int ret;
-   struct sg_table *sgt;
-
-   sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
-   if (!sgt)
-   return NULL;
-
-   ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
-   buf->size, buf->attrs);
-   if (ret < 0) {
-   dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
-   kfree(sgt);
-   return NULL;
-   }
-
-   return sgt;
-}
-
 static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, unsigned long flags)
 {
struct vb2_dc_buf *buf = buf_priv;
-- 
2.7.4

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


[PATCH 1/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Oscar Salvador
This patch introduces the structure "struct hwmon_ops"  and sets up the  
".visible" operation.
Is also a preparation for the next patch where all work is being done.

--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
19:22:29.070573187 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
19:21:32.391338011 +0200
@@ -764,6 +764,166 @@ static const struct hwmon_channel_info *
_power,
NULL
 };
+
+static umode_t
+nouveau_chip_is_visible(const void *data, u32 attr, int channel)
+{
+   switch (attr) {
+   case hwmon_chip_update_interval:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_power_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_iccsense *iccsense = nvxx_iccsense(>client.device);
+
+   switch (attr) {
+   case hwmon_power_input:
+   if (iccsense && iccsense->data_valid &&
+   !list_empty(>rails))
+   return 0444;
+   case hwmon_power_max:
+   case hwmon_power_crit:
+   if (iccsense->power_w_max && iccsense->power_w_crit)
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_temp_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (therm && therm->attr_get && therm->attr_set)
+   if (nvkm_therm_temp_get(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_temp_input:
+   return 0444;
+   case hwmon_temp_max:
+   case hwmon_temp_max_hyst:
+   case hwmon_temp_crit:
+   case hwmon_temp_crit_hyst:
+   case hwmon_temp_emergency:
+   case hwmon_temp_emergency_hyst:
+   return 0644;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (therm && therm->attr_get)
+   if (therm->fan_get && therm->fan_get(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_pwm_enable:
+   case hwmon_pwm_input:
+   return 0644;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_input_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_volt *volt = nvxx_volt(>client.device);
+
+   if (!volt || nvkm_volt_get(volt) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_in_input:
+   case hwmon_in_label:
+   case hwmon_in_min:
+   case hwmon_in_max:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_fan_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_fan_input:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
+   int channel)
+{
+   switch (type) {
+   case hwmon_chip:
+   return nouveau_chip_is_visible(data, attr, channel);
+   case hwmon_temp:
+   return nouveau_temp_is_visible(data, attr, channel);
+   case hwmon_fan:
+   return nouveau_fan_is_visible(data, attr, channel);
+   case hwmon_in:
+   return nouveau_input_is_visible(data, attr, channel);
+   case hwmon_pwm:
+   return nouveau_pwm_is_visible(data, attr, channel);
+   case hwmon_power:
+   return nouveau_power_is_visible(data, attr, channel);
+   default:
+   return 0;
+   }
+}
+
+static char *input_label = "GPU core";
+
+static int
+nouveau_read_string(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+   int channel, char **buf)
+{
+   if (type == hwmon_in && attr == hwmon_in_label) {
+   *buf = input_label;
+   return 0;
+   }
+
+   return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops nouveau_hwmon_ops = {
+   .is_visible = nouveau_is_visible,
+   .read = NULL,
+   .read_string = nouveau_read_string,
+   .write = NULL,
+};
+

[RFC v3 13/14] vb2: Don't sync cache for a buffer if so requested

2017-04-13 Thread Sakari Ailus
From: Samu Onkalo 

The user may request to the driver (vb2) to skip the cache maintenance
operations in case the buffer does not need cache synchronisation, e.g. in
cases where the buffer is passed between hardware blocks without it being
touched by the CPU.

Also document that the prepare and finish vb2_mem_ops might not get called
every time the buffer ownership changes between the kernel and the user
space.

Signed-off-by: Samu Onkalo 
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-core.c | 101 +--
 drivers/media/v4l2-core/videobuf2-v4l2.c |  14 -
 include/media/videobuf2-core.h   |  23 ---
 3 files changed, 97 insertions(+), 41 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e866115..7f21acd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -189,6 +189,28 @@ static void __vb2_queue_cancel(struct vb2_queue *q);
 static void __enqueue_in_driver(struct vb2_buffer *vb);
 
 /**
+ * __mem_prepare_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_prepare_planes(struct vb2_buffer *vb)
+{
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+}
+
+/**
+ * __mem_finish_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_finish_planes(struct vb2_buffer *vb)
+{
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+}
+
+/**
  * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
  */
 static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
@@ -953,20 +975,29 @@ EXPORT_SYMBOL_GPL(vb2_discard_done);
 /**
  * __prepare_mmap() - prepare an MMAP buffer
  */
-static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb,
+ bool no_cache_sync)
 {
-   int ret = 0;
+   int ret;
 
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, vb->planes);
-   return ret ? ret : call_vb_qop(vb, buf_prepare, vb);
+   if (ret)
+   return ret;
+   }
+
+   if (!no_cache_sync)
+   __mem_prepare_planes(vb);
+
+   return call_vb_qop(vb, buf_prepare, vb);
 }
 
 /**
  * __prepare_userptr() - prepare a USERPTR buffer
  */
-static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1057,6 +1088,11 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
const void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+   /* This is new buffer memory --- always synchronise cache. */
+   __mem_prepare_planes(vb);
+   } else if (!no_cache_sync) {
+   __mem_prepare_planes(vb);
}
 
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1084,7 +1120,8 @@ static int __prepare_userptr(struct vb2_buffer *vb, const 
void *pb)
 /**
  * __prepare_dmabuf() - prepare a DMABUF buffer
  */
-static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb,
+   bool no_cache_sync)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1199,6 +1236,11 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const 
void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+   /* This is new buffer memory --- always synchronise cache. */
+   __mem_prepare_planes(vb);
+   } else if (!no_cache_sync) {
+   __mem_prepare_planes(vb);
}
 
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1231,10 +1273,10 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
call_void_vb_qop(vb, buf_queue, vb);
 }
 
-static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
+static int __buf_prepare(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
 {
struct vb2_queue *q = vb->vb2_queue;
-   unsigned int plane;
int ret;
 
if (q->error) {
@@ -1246,13 +1288,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
 
switch (q->memory) {
case 

[PATCH 4/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Oscar Salvador
This patch replaces symbolic permissions with the numeric ones and adds me to 
the authors too.

--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-13 
10:18:37.471129756 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-13 
10:19:58.182025638 +0200
@@ -1,5 +1,6 @@
 /*
- * Copyright 2010 Red Hat Inc.
+ * Copyright 2010 Red Hat Inc. (Ben Skeggs)
+ * Copyright 2017 Oscar Salvador
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -19,7 +20,6 @@
  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
  *
- * Authors: Ben Skeggs
  */
 
 #ifdef CONFIG_ACPI
@@ -56,7 +56,7 @@ nouveau_hwmon_show_temp1_auto_point1_pwm
 {
return snprintf(buf, PAGE_SIZE, "%d\n", 100);
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, S_IRUGO,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444,
  nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0);
 
 static ssize_t
@@ -88,7 +88,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp
 
return count;
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, 0644,
  nouveau_hwmon_temp1_auto_point1_temp,
  nouveau_hwmon_set_temp1_auto_point1_temp, 0);
 
@@ -121,7 +121,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp
 
return count;
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 0644,
  nouveau_hwmon_temp1_auto_point1_temp_hyst,
  nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
 
@@ -313,7 +313,7 @@ nouveau_hwmon_set_pwm1_min(struct device
return count;
 }
 
-static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_min, 0644,
  nouveau_hwmon_get_pwm1_min,
  nouveau_hwmon_set_pwm1_min, 0);
 
@@ -353,7 +353,7 @@ nouveau_hwmon_set_pwm1_max(struct device
return count;
 }
 
-static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_max, 0644,
  nouveau_hwmon_get_pwm1_max,
  nouveau_hwmon_set_pwm1_max, 0);
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC v3 10/14] vb2: dma-contig: Fix DMA attribute and cache management

2017-04-13 Thread Sakari Ailus
Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
attrs") added support for driver specific DMA attributes to
videobuf2-dma-contig but it had several issues in it.

In particular,

- cache operations were only performed on USERPTR buffers,

- DMA attributes were set only for MMAP buffers and

- it did not provide begin_cpu_access() and end_cpu_access() dma_buf_ops
  callbacks for cache syncronisation on exported MMAP buffers.

This patch corrects these issues.

Also arrange the header files alphabetically.

Fixes: ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA attrs")
Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 90 --
 1 file changed, 69 insertions(+), 21 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 8ea9ab9..6a707d3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -11,12 +11,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -116,12 +116,13 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (!buf->vec)
-   return;
-
-   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
-  buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+  buf->dma_dir);
 }
 
 static void vb2_dc_finish(void *buf_priv)
@@ -129,11 +130,13 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
 
-   /* DMABUF exporter will flush the cache for us */
-   if (!buf->vec)
-   return;
-
-   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
+   buf->dma_dir);
 }
 
 /*/
@@ -172,9 +175,9 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long 
attrs,
 
buf->attrs = attrs;
buf->cookie = dma_alloc_attrs(dev, size, >dma_addr,
-   GFP_KERNEL | gfp_flags, buf->attrs);
+ GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
-   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
+   dev_err(dev, "dma_alloc_attrs of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
@@ -187,6 +190,14 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
long attrs,
buf->size = size;
buf->dma_dir = dma_dir;
 
+   buf->dma_sgt = vb2_dc_get_base_sgt(buf);
+   if (!buf->dma_sgt) {
+   dma_free_attrs(dev, size, buf->cookie, buf->dma_addr,
+  buf->attrs);
+   put_device(dev);
+   return ERR_PTR(-ENOMEM);
+   }
+
buf->handler.refcount = >refcount;
buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
@@ -359,6 +370,40 @@ static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, 
unsigned long pgnum)
return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
 }
 
+static int vb2_dc_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf,
+ enum dma_data_direction direction)
+{
+   struct vb2_dc_buf *buf = dbuf->priv;
+   struct sg_table *sgt = buf->dma_sgt;
+
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents,
+   buf->dma_dir);
+
+   return 0;
+}
+
+static int vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf,
+   enum dma_data_direction direction)
+{
+   struct vb2_dc_buf *buf = dbuf->priv;
+   struct sg_table *sgt = buf->dma_sgt;
+
+   /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+   

[RFC v3 11/14] vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs

2017-04-13 Thread Sakari Ailus
The scatterlist should always be present when the cache would need to be
flushed. Each buffer type has its own means to provide that. Add
WARN_ON_ONCE() to check the scatterist exists.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 6a707d3..2847fbf 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -120,7 +120,7 @@ static void vb2_dc_prepare(void *buf_priv)
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
   buf->dma_dir);
 }
@@ -134,7 +134,7 @@ static void vb2_dc_finish(void *buf_priv)
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
buf->dma_dir);
 }
@@ -380,7 +380,7 @@ static int vb2_dc_dmabuf_ops_begin_cpu_access(struct 
dma_buf *dbuf,
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents,
buf->dma_dir);
 
@@ -397,7 +397,7 @@ static int vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf 
*dbuf,
 * DMABUF exporter will flush the cache for us; only USERPTR
 * and MMAP buffers with non-coherent memory will be flushed.
 */
-   if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+   if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt))
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents,
   buf->dma_dir);
 
-- 
2.7.4

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


[RFC v3 01/14] vb2: Rename confusingly named internal buffer preparation functions

2017-04-13 Thread Sakari Ailus
Rename __qbuf_*() functions which are specific to a buffer type as
__prepare_*() which matches with what they do. The naming was there for
historical reasons; the purpose of the functions was changed without
renaming them.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/videobuf2-core.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 94afbbf9..8df680d 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -956,9 +956,9 @@ void vb2_discard_done(struct vb2_queue *q)
 EXPORT_SYMBOL_GPL(vb2_discard_done);
 
 /**
- * __qbuf_mmap() - handle qbuf of an MMAP buffer
+ * __prepare_mmap() - prepare an MMAP buffer
  */
-static int __qbuf_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
 {
int ret = 0;
 
@@ -969,9 +969,9 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const void 
*pb)
 }
 
 /**
- * __qbuf_userptr() - handle qbuf of a USERPTR buffer
+ * __prepare_userptr() - prepare a USERPTR buffer
  */
-static int __qbuf_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1087,9 +1087,9 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const 
void *pb)
 }
 
 /**
- * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
+ * __prepare_dmabuf() - prepare a DMABUF buffer
  */
-static int __qbuf_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
 {
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1255,13 +1255,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
 
switch (q->memory) {
case VB2_MEMORY_MMAP:
-   ret = __qbuf_mmap(vb, pb);
+   ret = __prepare_mmap(vb, pb);
break;
case VB2_MEMORY_USERPTR:
-   ret = __qbuf_userptr(vb, pb);
+   ret = __prepare_userptr(vb, pb);
break;
case VB2_MEMORY_DMABUF:
-   ret = __qbuf_dmabuf(vb, pb);
+   ret = __prepare_dmabuf(vb, pb);
break;
default:
WARN(1, "Invalid queue type\n");
-- 
2.7.4

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


[RFC v3 07/14] vb2: dma-contig: Remove redundant sgt_base field

2017-04-13 Thread Sakari Ailus
The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
by USERPTR.

Unify the two, leaving dma_sgt.

MMAP buffers do not need cache flushing since they have been allocated
using dma_alloc_coherent().

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a8a46a8..ddbbcf0 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -31,12 +31,13 @@ struct vb2_dc_buf {
unsigned long   attrs;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
-   struct frame_vector *vec;
 
/* MMAP related */
struct vb2_vmarea_handler   handler;
refcount_t  refcount;
-   struct sg_table *sgt_base;
+
+   /* USERPTR related */
+   struct frame_vector *vec;
 
/* DMABUF related */
struct dma_buf_attachment   *db_attach;
@@ -96,7 +97,7 @@ static void vb2_dc_prepare(void *buf_priv)
struct sg_table *sgt = buf->dma_sgt;
 
/* DMABUF exporter will flush the cache for us */
-   if (!sgt || buf->db_attach)
+   if (!buf->vec)
return;
 
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
@@ -109,7 +110,7 @@ static void vb2_dc_finish(void *buf_priv)
struct sg_table *sgt = buf->dma_sgt;
 
/* DMABUF exporter will flush the cache for us */
-   if (!sgt || buf->db_attach)
+   if (!buf->vec)
return;
 
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
@@ -126,9 +127,9 @@ static void vb2_dc_put(void *buf_priv)
if (!refcount_dec_and_test(>refcount))
return;
 
-   if (buf->sgt_base) {
-   sg_free_table(buf->sgt_base);
-   kfree(buf->sgt_base);
+   if (buf->dma_sgt) {
+   sg_free_table(buf->dma_sgt);
+   kfree(buf->dma_sgt);
}
dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
   buf->attrs);
@@ -239,13 +240,13 @@ static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, 
struct device *dev,
/* Copy the buf->base_sgt scatter list to the attachment, as we can't
 * map the same scatter list to multiple attachments at the same time.
 */
-   ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
+   ret = sg_alloc_table(sgt, buf->dma_sgt->orig_nents, GFP_KERNEL);
if (ret) {
kfree(attach);
return -ENOMEM;
}
 
-   rd = buf->sgt_base->sgl;
+   rd = buf->dma_sgt->sgl;
wr = sgt->sgl;
for (i = 0; i < sgt->orig_nents; ++i) {
sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
@@ -396,10 +397,10 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, 
unsigned long flags)
exp_info.flags = flags;
exp_info.priv = buf;
 
-   if (!buf->sgt_base)
-   buf->sgt_base = vb2_dc_get_base_sgt(buf);
+   if (!buf->dma_sgt)
+   buf->dma_sgt = vb2_dc_get_base_sgt(buf);
 
-   if (WARN_ON(!buf->sgt_base))
+   if (WARN_ON(!buf->dma_sgt))
return NULL;
 
dbuf = dma_buf_export(_info);
-- 
2.7.4

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


  1   2   >