Re: [PATCH] drm/amdgpu/display: remove trailing semicolon in macro definition
Am 27.11.20 um 17:26 schrieb t...@redhat.com: From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index f9c81bc21ba4..301e93c9e72a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -1213,7 +1213,7 @@ int emu_soc_asic_init(struct amdgpu_device *adev); #define amdgpu_asic_update_umd_stable_pstate(adev, enter) \ ((adev)->asic_funcs->update_umd_stable_pstate ? (adev)->asic_funcs->update_umd_stable_pstate((adev), (enter)) : 0) -#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)); +#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)) /* Common functions */ bool amdgpu_device_has_job_running(struct amdgpu_device *adev); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/3] drm/mipi-dbi: Type B bus support, drm/tiny: MRB2801
From: Mikhail Durnev Hi All, This patch series is aiming at extending the mipi-dbi bus driver to support Intel 8080 type parallel bus (Type B) over GPIO and adding a new driver for ILI9341 display panels with 8- or 16-bit parallel interface. It was tested with the MRB2801 display module [1] that had a connector compatible with the ALIENTEK STM32 development board. The module was connected to Raspberry Pi 3 via GPIO pins. The parallel bus is implemented partially. It supports only write operations from the host to the display. Read operations would require switching GPIO mode between input and output back and forth. But this implementation is very simple, and GPIO mode can be set for all used pins to output once at initialization. The RD pin of the display has to always receive the logic high signal to make sure the data bus pins from the dislay side are always in the high impedance state. Otherwise the display module as well as the GPIO controller of the host can be damaged. To be on the safe side I recommend using protective resistors for all GPIO pins conneced to DB pins of the display. Resistors of 10 kOhms are just fine for RPi 3. The WR and DC pins may not work well with 10K resistors. Although there is no need to protect them, you can try using 1K resistors if you want. Bit banging is used to transmit data over the parallel bus from host to display. There are two numbers that contol timings. They should be defined in the device tree via the wr-up-down-delays property. The first number is related to the write control pulse duration, and the second number is related to the write cycle duration. For ILI9341, the write pulse cannot be shorter than 15 ns, and the write duration cannot be shorter than 66 ns. Delays of 10 and 51 ns respectively allow to meet the specifications on RPi 3. Faster machines may need values closer to 15 and 66. [1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801 Mikhail Durnev (3): drm/mipi-dbi: Add support for Type B drm/tiny: Add driver for ili9341 with parallel bus dt-bindings: panel: Add bindings for MRB2801 .../devicetree/bindings/display/ronbo,mrb2801.txt | 42 +++ drivers/gpu/drm/drm_mipi_dbi.c | 116 - drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9341_gpio.c| 290 + include/drm/drm_mipi_dbi.h | 30 ++- 6 files changed, 490 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] misc: xilinx-ai-engine: add request and release tiles
Add request/release and related clock gating functions to AI engine
driver:
* scanning when the partition is being requested to know which tiles
are in use.
* check if a tile is gated or not
* tiles requesting and releasing ioctl so that user application can
enable/disable tiles at runtime.
Signed-off-by: Wendy Liang
Reviewed-by: Hyun Kwon
---
drivers/misc/xilinx-ai-engine/Makefile | 1 +
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 225 +++
drivers/misc/xilinx-ai-engine/ai-engine-clock.c| 245 +
drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 19 +-
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 34 +++
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 32 +++
drivers/misc/xilinx-ai-engine/ai-engine-res.c | 51 +
include/uapi/linux/xlnx-ai-engine.h| 31 +++
8 files changed, 631 insertions(+), 7 deletions(-)
create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-clock.c
diff --git a/drivers/misc/xilinx-ai-engine/Makefile
b/drivers/misc/xilinx-ai-engine/Makefile
index 1b743fa..2e67b25 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_XILINX_AIE) += xilinx-aie.o
xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
+ ai-engine-clock.o \
ai-engine-dev.o \
ai-engine-dma.o \
ai-engine-mem.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index ac95aff..ff721b3 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -41,6 +41,9 @@
#define AIE_SHIMPL_SHIMRST_MASK0x1U
#define AIE_SHIMPL_COLRST_MASK 0x1U
#define AIE_SHIMPL_CLKCNTR_COLBUF_MASK 0x1U
+#define AIE_SHIMPL_CLKCNTR_NEXTCLK_MASKBIT(1)
+#define AIE_TILE_CLKCNTR_COLBUF_MASK BIT(0)
+#define AIE_TILE_CLKCNTR_NEXTCLK_MASK BIT(1)
/*
* AI engine SHIM reset ID.
@@ -221,10 +224,232 @@ static int aie_reset_shim(struct aie_device *adev,
struct aie_range *range)
return 0;
}
+static int aie_init_part_clk_state(struct aie_partition *apart)
+{
+ int ret, num_tiles;
+
+ num_tiles = apart->range.size.col * (apart->range.size.row - 1);
+
+ ret = aie_resource_initialize(&apart->cores_clk_state, num_tiles);
+ if (ret) {
+ dev_err(&apart->dev,
+ "failed to initialize cores clock state resource.\n");
+ return ret;
+ }
+
+ ret = aie_resource_initialize(&apart->tiles_inuse, num_tiles);
+ if (ret) {
+ dev_err(&apart->dev,
+ "failed to initialize tiles in use resource.\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int aie_scan_part_clocks(struct aie_partition *apart)
+{
+ struct aie_device *adev = apart->adev;
+ struct aie_range *range = &apart->range;
+ struct aie_location loc;
+
+ /* Clear the bitmap of cores and memories clock state */
+ aie_resource_put_region(&apart->cores_clk_state, 0,
+ apart->cores_clk_state.total);
+
+ for (loc.col = range->start.col;
+loc.col < range->start.col + range->size.col;
+loc.col++) {
+ for (loc.row = range->start.row;
+loc.row < range->start.row + range->size.row - 1;
+loc.row++) {
+ void __iomem *va;
+ u32 val, nbitpos;
+
+ /*
+* Reading registers of the current tile to see the next
+* tile is clock gated.
+*/
+ nbitpos = loc.col * (range->size.row - 1) + loc.row;
+
+ if (aie_get_tile_type(&loc) != AIE_TILE_TYPE_TILE) {
+ /* Checks shim tile for next core tile */
+ va = adev->base +
+aie_cal_regoff(adev, loc,
+ AIE_SHIMPL_CLKCNTR_REGOFF);
+ val = ioread32(va);
+
+ /*
+* check if the clock buffer and the next clock
+* tile is set, if one of them is not set, the
+* tiles of the column are clock gated.
+*/
+ if (!(val & AIE_SHIMPL_CLKCNTR_COLBUF_MASK) ||
+ !(val & AIE_SHIMPL_CLKCNTR_NEXTCLK_MASK))
+ break;
+
+ /* Set next tile in the row clock state on */
+
[PATCH v3 9/9] misc: xilinx-ai-engine: Add support for servicing error interrupts
From: Nishad Saraf
AI engine errors events can be routed to generate interrupt. The
errors events routing will be done during AI engine configuration.
At runtime, Linux kernel AI engine driver monitors the interrupt and
backtracks errors events.
As error events from 400 AIE tiles and 50 shim tiles are channeled on
a single interrupt line, backtracking the source the interrupt to an
AIE module is required. To keep the top-half interrupt short,
backtracking is deferred to bottom half by scheduling a task in shared
workqueue.
Signed-off-by: Nishad Saraf
Signed-off-by: Wendy Liang
---
drivers/misc/xilinx-ai-engine/Makefile | 1 +
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 121
drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 14 +
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 144 +
.../misc/xilinx-ai-engine/ai-engine-interrupt.c| 659 +
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 44 ++
drivers/misc/xilinx-ai-engine/ai-engine-res.c | 54 ++
7 files changed, 1037 insertions(+)
create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-interrupt.c
diff --git a/drivers/misc/xilinx-ai-engine/Makefile
b/drivers/misc/xilinx-ai-engine/Makefile
index 2e67b25..9607ecb 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -9,6 +9,7 @@ xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
ai-engine-clock.o \
ai-engine-dev.o \
ai-engine-dma.o \
+ ai-engine-interrupt.o \
ai-engine-mem.o \
ai-engine-part.o \
ai-engine-res.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index ff721b3..af0f997 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -33,7 +33,10 @@
#define AIE_SHIMPL_CLKCNTR_REGOFF 0x00036040U
#define AIE_SHIMPL_COLRESET_REGOFF 0x00036048U
#define AIE_SHIMPL_RESET_REGOFF0x0003604cU
+#define AIE_SHIMPL_GROUP_ERROR_REGOFF 0x0003450cU
#define AIE_TILE_CORE_CLKCNTR_REGOFF 0x00036040U
+#define AIE_TILE_CORE_GROUP_ERROR_REGOFF 0x00034510U
+#define AIE_TILE_MEM_GROUP_ERROR_REGOFF0x00014514U
/*
* Register masks
@@ -93,11 +96,27 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
.soff = AIE_SHIMPL_CLKCNTR_REGOFF,
.eoff = AIE_SHIMPL_CLKCNTR_REGOFF,
},
+ /* SHIM group error enable */
+ {.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
+ AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_SHIMPL_GROUP_ERROR_REGOFF,
+.eoff = AIE_SHIMPL_GROUP_ERROR_REGOFF,
+ },
/* Tile clock control */
{.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
.soff = AIE_TILE_CORE_CLKCNTR_REGOFF,
.eoff = AIE_TILE_CORE_CLKCNTR_REGOFF,
},
+ /* Tile group error for core module */
+ {.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_TILE_CORE_GROUP_ERROR_REGOFF,
+.eoff = AIE_TILE_CORE_GROUP_ERROR_REGOFF,
+ },
+ /* Tile group error for memory module */
+ {.attribute = AIE_TILE_TYPE_TILE << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_TILE_MEM_GROUP_ERROR_REGOFF,
+.eoff = AIE_TILE_MEM_GROUP_ERROR_REGOFF,
+ },
};
static const struct aie_single_reg_field aie_col_rst = {
@@ -128,6 +147,103 @@ static const struct aie_dma_attr aie_shimdma = {
.bd_len = 0x14U,
};
+static const struct aie_event_attr aie_pl_event = {
+ .bc_event = {
+ .mask = GENMASK(6, 0),
+ .regoff = 0x0U,
+ },
+ .group_error = {
+ .mask = GENMASK(10, 0),
+ .regoff = 0xcU,
+ },
+ .bc_regoff = 0x34010U,
+ .status_regoff = 0x34200U,
+ .group_regoff = 0x34500U,
+ .base_error_event = 62U,
+ .num_broadcasts = 16U,
+ .base_bc_event = 107U,
+ .num_events = 128U,
+};
+
+static const struct aie_event_attr aie_mem_event = {
+ .bc_event = {
+ .mask = GENMASK(6, 0),
+ .regoff = 0x0U,
+ },
+ .group_error = {
+ .mask = GENMASK(13, 0),
+ .regoff = 0x14U,
+ },
+ .bc_regoff = 0x14010U,
+ .status_regoff = 0x14200U,
+ .group_regoff = 0x14500U,
+ .base_error_event = 87U,
+ .num_broadcasts = 16U,
+ .base_bc_event = 107U,
+ .num_events = 128U,
+};
+
+static const struct aie_event_attr aie_core_event = {
+ .bc_event = {
+ .mask = GENMASK(6, 0),
+ .regoff = 0x0U,
+ },
+ .group_erro
[PATCH v3 5/9] misc: xilinx-ai-engine: add setting shim dma bd operation
Add operation to set SHIM DMA buffer descriptor.
The following operations are added to set the buffer descriptors:
* attach DMA buffer which enables AI engine device to access the DMA
buffer memory
* detach DMA buffer which disables AI engine device to access the DMA
buffer memory
* set DMA buffer descriptor, which takes buffer descriptor contents
pointer, the dmabuf fd, and the offset to the start of dmabuf as
as argument. It validates the dmabuf and the offset and size of the
buffer. And then it calculates the DMA address of the buffer and set
the buffer descriptor content to the hardware DMA buffer descriptor.
The main logic to control what's go into the buffer descriptor and which
buffer descriptor to use is in the userspace AI engine library.
Signed-off-by: Wendy Liang
Reviewed-by: Hyun Kwon
---
drivers/misc/xilinx-ai-engine/Makefile | 1 +
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 19 +
drivers/misc/xilinx-ai-engine/ai-engine-dma.c | 481 +
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 45 ++
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 17 +
include/uapi/linux/xlnx-ai-engine.h| 44 ++
6 files changed, 607 insertions(+)
create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dma.c
diff --git a/drivers/misc/xilinx-ai-engine/Makefile
b/drivers/misc/xilinx-ai-engine/Makefile
index 2dbed42..1b743fa 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
ai-engine-dev.o \
+ ai-engine-dma.o \
ai-engine-mem.o \
ai-engine-part.o \
ai-engine-res.o \
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 7fce2f00..ac95aff 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -107,6 +107,24 @@ static const struct aie_single_reg_field aie_col_clkbuf = {
.regoff = AIE_SHIMPL_CLKCNTR_REGOFF,
};
+static const struct aie_dma_attr aie_shimdma = {
+ .laddr = {
+ .mask = 0xU,
+ .regoff = 0U,
+ },
+ .haddr = {
+ .mask = 0xU,
+ .regoff = 0x8U,
+ },
+ .buflen = {
+ .mask = 0xU,
+ .regoff = 0x4U,
+ },
+ .bd_regoff = 0x0001d000U,
+ .num_bds = 16,
+ .bd_len = 0x14U,
+};
+
static u32 aie_get_tile_type(struct aie_location *loc)
{
if (loc->row)
@@ -232,6 +250,7 @@ int aie_device_init(struct aie_device *adev)
adev->kernel_regs = aie_kernel_regs;
adev->col_rst = &aie_col_rst;
adev->col_clkbuf = &aie_col_clkbuf;
+ adev->shim_dma = &aie_shimdma;
/* Get the columns resource */
/* Get number of columns from AI engine memory resource */
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-dma.c
b/drivers/misc/xilinx-ai-engine/ai-engine-dma.c
new file mode 100644
index 000..863790b
--- /dev/null
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-dma.c
@@ -0,0 +1,481 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx AI Engine driver DMA implementation
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#include "ai-engine-internal.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct aie_dmabuf - AI engine dmabuf information
+ * @attach: dmabuf attachment pointer
+ * @sgt: scatter/gather table
+ * @refs: refcount of the attached aie_dmabuf
+ * @node: list node
+ */
+struct aie_dmabuf {
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ refcount_t refs;
+ struct list_head node;
+};
+
+/**
+ * aie_part_find_dmabuf() - find a attached dmabuf
+ * @apart: AI engine partition
+ * @dmabuf: pointer to dmabuf
+ * @return: pointer to AI engine dmabuf struct of the found dmabuf, if dmabuf
+ * is not found, returns NULL.
+ *
+ * This function scans all the attached dmabufs to see the input dmabuf is
+ * in the list. if it is attached, return the corresponding struct aie_dmabuf
+ * pointer.
+ */
+static struct aie_dmabuf *
+aie_part_find_dmabuf(struct aie_partition *apart, struct dma_buf *dmabuf)
+{
+ struct aie_dmabuf *adbuf;
+
+ list_for_each_entry(adbuf, &apart->dbufs, node) {
+ if (dmabuf == adbuf->attach->dmabuf)
+ return adbuf;
+ }
+
+ return NULL;
+}
+
+/**
+ * aie_part_get_dmabuf_da_from_off() - get DMA address from offset to a dmabuf
+ * @apart: AI engine partition
+ * @dmabuf_fd: dmabuf file descriptor
+ * @off: offset to the start of a dmabuf
+ * @len: memory length
+ * @return: dma address, or 0 if @off or @len is
[PATCH v1 1/3] drm/mipi-dbi: Add support for Type B
From: Mikhail Durnev
Intel 8080 type (Type B) parallel bus over GPIO.
The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
It is enough to support only write operations to initialize displays
and output video data. The bus driver returns EOPNOTSUPP for all read
operations requested through a display driver.
Bit banging is used to transmit data over the parallel bus from host
to display. There are two numbers that contol timings: wr_up_delay
and wr_down_delay. They should be provided by the display driver.
The first number is related to the write control pulse duration, and
the second number is related to the write cycle duration that can
be found in the specification of the display.
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/drm_mipi_dbi.c | 116 -
include/drm/drm_mipi_dbi.h | 30 ++-
2 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd..5dedc59 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -61,7 +61,7 @@
*3. 8-bit with the Data/Command signal as a separate D/CX pin
*
* Currently mipi_dbi only supports Type C options 1 and 3 with
- * mipi_dbi_spi_init().
+ * mipi_dbi_spi_init() and Type B with mipi_dbi_gpio_init().
*/
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
@@ -1158,6 +1158,120 @@ EXPORT_SYMBOL(mipi_dbi_spi_transfer);
#endif /* CONFIG_SPI */
+/*
+ * This function implements data transfer only from host to display.
+ */
+static void mipi_dbi_gpio_transfer(struct mipi_dbi *dbi, u16 data)
+{
+ unsigned long ldata = data;
+
+ /*
+* Set W/R to low to start transfer.
+* Set DB bits with provided data when W/R is low.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 0);
+ gpiod_set_array_value_cansleep(dbi->db->ndescs, dbi->db->desc,
+ dbi->db->info, &ldata);
+
+ /*
+* The bus usually needs additional delay.
+*/
+ ndelay(dbi->wr_up_delay);
+
+ /*
+* Set W/R to high to indicate that DB lines are set.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 1);
+
+ /*
+* The connected display needs some time to read the data.
+*/
+ ndelay(dbi->wr_down_delay);
+}
+
+static int mipi_dbi_gpio_command(struct mipi_dbi *dbi, u8 *cmd,
+ u8 *par, size_t num)
+{
+ int i;
+
+ /*
+* Read commands are not currently supported.
+*/
+ if (mipi_dbi_command_is_read(dbi, *cmd))
+ return -EOPNOTSUPP;
+
+ MIPI_DBI_DEBUG_COMMAND(*cmd, par, num);
+
+ gpiod_set_value_cansleep(dbi->dc, 0);
+ mipi_dbi_gpio_transfer(dbi, (u16)*cmd);
+ gpiod_set_value_cansleep(dbi->dc, 1);
+
+ if (dbi->db->ndescs == 16 &&
+ (*cmd == MIPI_DCS_WRITE_MEMORY_START ||
+*cmd == MIPI_DCS_WRITE_MEMORY_CONTINUE)) {
+ /*
+* Only a couple of commands supports 16-bit transfer.
+*/
+ for (i = 0; i < num; i += 2) {
+ u16 data = *(u16 *)&par[i];
+
+ if (dbi->swap_bytes)
+ data = (data >> 8) | (data << 8);
+
+ mipi_dbi_gpio_transfer(dbi, data);
+ }
+ } else {
+ for (i = 0; i < num; i++) {
+ /*
+* Other commands ignore most significant bits.
+*/
+ mipi_dbi_gpio_transfer(dbi, (u16)par[i]);
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface implemented via
GPIO
+ * @dbi: MIPI DBI structure to initialize
+ * @dc: D/C gpio
+ * @wr: W/R gpio
+ * @db: DB gpios
+ * @wr_up_delay: Delay after setting DB and before changing W/R from low to
high
+ * @wr_down_delay: Delay after changing W/R from low to high
+ *
+ * This function sets &mipi_dbi->command, enables &mipi_dbi->read_commands for
the
+ * usual read commands. It should be followed by a call to mipi_dbi_dev_init()
or
+ * a driver-specific init.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_gpio_init(struct mipi_dbi *dbi, struct gpio_desc *dc,
+ struct gpio_desc *wr, struct gpio_descs *db,
+ unsigned long wr_up_delay, unsigned long wr_down_delay)
+{
+ dbi->spi = NULL; /* Type B uses GPIO lines rather than SPI */
+
+ dbi->read_commands = mipi_dbi_dcs_read_commands;
+ dbi->command = mipi_dbi_gpio_command;
+
+ dbi->dc = dc;
+ db
[PATCH v3 1/9] dt-binding: soc: xilinx: ai-engine: Add AI engine binding
Xilinx AI engine array can be partitioned statically for different
applications. In the device tree, there will be device node for the AI
engine device, and device nodes for the statically configured AI engine
partitions. Each of the statically configured partition has a partition
ID in the system.
Signed-off-by: Wendy Liang
---
.../bindings/soc/xilinx/xlnx,ai-engine.yaml| 126 +
1 file changed, 126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
new file mode 100644
index 000..1de5623
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/xilinx/xlnx,ai-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx AI Engine
+
+maintainers:
+ - Wendy Liang
+
+description: |+
+ The Xilinx AI Engine is a tile processor with many cores (up to 400) that
+ can run in parallel. The data routing between cores is configured through
+ internal switches, and shim tiles interface with external interconnect, such
+ as memory or PL.
+
+properties:
+ compatible:
+const: xlnx,ai-engine-v1.0
+
+ reg:
+description: |
+ Physical base address and length of the device registers.
+ The AI engine address space assigned to Linux is defined by Xilinx
+ platform design tool.
+
+ '#address-cells':
+enum: [2]
+description: |
+ size of cell to describe AI engine range of tiles address.
+ It is the location of the starting tile of the range.
+ As the AI engine tiles are 2D array, the location of a tile
+ is presented as (column, row), the address cell is 2.
+
+ '#size-cells':
+enum: [2]
+description: |
+ size of cell to describe AI engine range of tiles size.
+ As the AI engine tiles are 2D array, the size cell is 2.
+
+ power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+ interrupts:
+maxItems: 3
+
+ interrupt-names:
+description: |
+ Should be "interrupt1", "interrupt2" or "interrupt3".
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - power-domains
+ - interrupt-parent
+ - interrupts
+ - interrupt-names
+
+patternProperties:
+ "^aie_partition@[0-9]+$":
+type: object
+description: |
+ AI engine partition which is a group of column based tiles of the AI
+ engine device. Each AI engine partition is isolated from the other
+ AI engine partitions. An AI engine partition is defined by Xilinx
+ platform design tools. Each partition has a SHIM row and core tiles rows.
+ A SHIM row contains SHIM tiles which are the interface to external
+ components. AXI master can access AI engine registers, push data to and
+ fetch data from AI engine through the SHIM tiles. Core tiles are the
+ compute tiles.
+
+properties:
+ reg:
+description: |
+ It describes the group of tiles of the AI engine partition. It needs
+ to include the SHIM row. The format is defined by the parent AI
engine
+ device node's '#address-cells' and '#size-cells' properties. e.g. a
v1
+ AI engine device has 2D tiles array, the first row is SHIM row. A
+ partition which has 50 columns and 8 rows of core tiles and 1 row of
+ SHIM tiles will be presented as <0 0 50 9>.
+
+ label:
+maxItems: 1
+
+ xlnx,partition-id:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ AI engine partition ID, which is defined by Xilinx platform design
+ tool to identify the AI engine partition in the system.
+
+required:
+ - reg
+ - xlnx,partition-id
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ai_engine: ai-engine@200 {
+compatible = "xlnx,ai-engine-v1.0";
+reg = <0x200 0x0 0x1 0x0>;
+#address-cells = <2>;
+#size-cells = <2>;
+power-domains = <&versal_firmware 0x18224072>;
+interrupt-parent = <&gic>;
+interrupts = <0x0 0x94 0x4>,
+ <0x0 0x95 0x4>,
+ <0x0 0x96 0x4>;
+interrupt-names = "interrupt1", "interrupt2", "interrupt3";
+
+aie_partition0: aie_partition@0 {
+/* 50 columns and 8 core tile rows + 1 SHIM row */
+reg = <0 0 50 9>;
+xlnx,partition-id = <1>;
+};
+ };
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-dev
[PATCH v1 3/3] dt-bindings: panel: Add bindings for MRB2801
From: Mikhail Durnev
Add binding for Ronbo MRB2801 display module.
This binding is for display panels using an Ilitek ILI9341 controller in
parallel mode.
Signed-off-by: Mikhail Durnev
---
.../devicetree/bindings/display/ronbo,mrb2801.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
diff --git a/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
new file mode 100644
index 000..db1a861e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
@@ -0,0 +1,42 @@
+MRB2801 display panel
+
+This binding is for display panels using an Ilitek ILI9341 controller in
+parallel mode.
+
+Required properties:
+- compatible: "ronbo,mrb2801"
+- dc-gpios:D/C pin
+- wr-gpios:W/R pin
+- db-gpios:8 or 16 DB pins
+- reset-gpios: Reset pin
+- wr-up-down-delays: Delays in ns for changing W/R from down to up and from
up to down
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ mrb2801{
+ compatible = "ronbo,mrb2801";
+ db-gpios = <&gpio 17 0>, /* DB0 */
+ <&gpio 18 0>, /* DB1 */
+ <&gpio 27 0>, /* DB2 */
+ <&gpio 22 0>, /* DB3 */
+ <&gpio 23 0>, /* DB4 */
+ <&gpio 24 0>, /* DB5 */
+ <&gpio 25 0>, /* DB6 */
+ <&gpio 4 0>, /* DB7 */
+ <&gpio 14 0>, /* DB8 */
+ <&gpio 15 0>, /* DB9 */
+ <&gpio 5 0>, /* DB10 */
+ <&gpio 6 0>, /* DB11 */
+ <&gpio 13 0>, /* DB12 */
+ <&gpio 19 0>, /* DB13 */
+ <&gpio 26 0>, /* DB14 */
+ <&gpio 12 0>; /* DB15 */
+ dc-gpios = <&gpio 16 0>; /* D/C */
+ wr-gpios = <&gpio 20 0>; /* W/R */
+ wr-up-down-delays = <10 51>;
+ reset-gpios = <&gpio 21 0>; /* RST */
+ backlight = <&backlight>;
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500: Fix error return code in psb_driver_load()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Reported-by: Hulk Robot
Signed-off-by: Jialin Zhang
---
drivers/gpu/drm/gma500/psb_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 34b4aae9a15e..074f403d7ca0 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -313,6 +313,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto out_err;
+ ret = -ENOMEM;
+
dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
if (!dev_priv->mmu)
goto out_err;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] Xilinx AI engine kernel driver
AI engine is the acceleration engine provided by Xilinx. These engines provide high compute density for vector-based algorithms, and flexible custom compute and data movement. It has core tiles for compute and shim tiles to interface the FPGA fabric. You can check the AI engine architecture document for more hardware details: https://www.xilinx.com/support/documentation/architecture-manuals/am009-versal-ai-engine.pdf This patch series adds a Linux kernel driver to manage the Xilinx AI engine array device and AI engine partitions (groups of AI engine tiles dedicated to an application). v3: * unlock AIE dev mutex after failed to gain the partition lock in errors handing * replace pointer with __u64 and enum with __u32 in ioctl v2: * Fix dtschema check errors * Fix test bot warning on interrupt implementation. Removed set but unused varaible. * Fix compilation unused function warning of firmware change in case ZynqMP firmware is not configured * There are other warning on ZynqMP firmware reported from testbot which is not introduced by this patch set. "[PATCH] firmware: xlnx-zynqmp: fix compilation warning" is submitted for those fixes. Izhar Ameer Shaikh (1): firmware: xilinx: Add IOCTL support for AIE ISR Clear Nishad Saraf (2): misc: xilinx-ai-engine: Add support to request device management services misc: xilinx-ai-engine: Add support for servicing error interrupts Wendy Liang (6): dt-binding: soc: xilinx: ai-engine: Add AI engine binding misc: Add Xilinx AI engine device driver misc: xilinx-ai-engine: Implement AI engine cleanup sequence misc: xilinx-ai-engine: expose AI engine tile memories to userspace misc: xilinx-ai-engine: add setting shim dma bd operation misc: xilinx-ai-engine: add request and release tiles .../bindings/soc/xilinx/xlnx,ai-engine.yaml| 126 MAINTAINERS| 8 + drivers/firmware/xilinx/zynqmp.c | 14 + drivers/misc/Kconfig | 12 + drivers/misc/Makefile | 1 + drivers/misc/xilinx-ai-engine/Makefile | 16 + drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 608 +++ drivers/misc/xilinx-ai-engine/ai-engine-clock.c| 245 drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 496 drivers/misc/xilinx-ai-engine/ai-engine-dma.c | 481 +++ drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 519 .../misc/xilinx-ai-engine/ai-engine-interrupt.c| 659 + drivers/misc/xilinx-ai-engine/ai-engine-mem.c | 275 + drivers/misc/xilinx-ai-engine/ai-engine-part.c | 635 drivers/misc/xilinx-ai-engine/ai-engine-res.c | 219 +++ drivers/misc/xilinx-ai-engine/ai-engine-reset.c| 159 + include/linux/firmware/xlnx-zynqmp.h | 8 + include/uapi/linux/xlnx-ai-engine.h| 238 18 files changed, 4719 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml create mode 100644 drivers/misc/xilinx-ai-engine/Makefile create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-aie.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-clock.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dev.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dma.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-internal.h create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-interrupt.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-mem.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-part.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-res.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-reset.c create mode 100644 include/uapi/linux/xlnx-ai-engine.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] firmware: xilinx: Add IOCTL support for AIE ISR Clear
From: Izhar Ameer Shaikh
Latching of AIE NPI Interrupts is present in Versal ES1 Silicon Rev,
however it has been removed from ES2 rev.
As a result on ES1, in order to use the interrupt, a client needs to
request PMC to clear/ack the interrupt.
Provide an EEMI IOCTL to serve the same purpose. Note that, this will
only be applicable for ES1 rev. For ES2 and other non-silicon platforms,
this call will essentially be a NOP in the firmware.
Signed-off-by: Izhar Ameer Shaikh
Signed-off-by: Wendy Liang
---
drivers/firmware/xilinx/zynqmp.c | 14 ++
include/linux/firmware/xlnx-zynqmp.h | 8
2 files changed, 22 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index d08ac82..23e58cc 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -729,6 +729,20 @@ int zynqmp_pm_set_boot_health_status(u32 value)
}
/**
+ * zynqmp_pm_clear_aie_npi_isr - Clear AI engine NPI interrupt status register
+ * @node: AI engine node id
+ * @irq_mask: Mask of AI engine NPI interrupt bit to clear
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask)
+{
+ return zynqmp_pm_invoke_fn(PM_IOCTL, node, IOCTL_AIE_ISR_CLEAR,
+ irq_mask, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_clear_aie_npi_isr);
+
+/**
* zynqmp_pm_reset_assert - Request setting of reset (1 - assert, 0 - release)
* @reset: Reset to be configured
* @assert_flag: Flag stating should reset be asserted (1) or
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 83ac9ec..defa4ea 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -114,6 +114,8 @@ enum pm_ioctl_id {
IOCTL_READ_PGGS = 15,
/* Set healthy bit value */
IOCTL_SET_BOOT_HEALTH_STATUS = 17,
+ /* AI engine NPI ISR clear */
+ IOCTL_AIE_ISR_CLEAR = 24,
};
enum pm_query_id {
@@ -355,6 +357,7 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
int zynqmp_pm_read_pggs(u32 index, u32 *value);
int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask);
#else
static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
{
@@ -505,6 +508,11 @@ static inline int zynqmp_pm_set_boot_health_status(u32
value)
{
return -ENODEV;
}
+
+static inline int zynqmp_pm_clear_aie_npi_isr(u32 node, u32 irq_mask)
+{
+ return -ENODEV;
+}
#endif
#endif /* __FIRMWARE_ZYNQMP_H__ */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] misc: xilinx-ai-engine: Implement AI engine cleanup sequence
When AI engine partition is released, that is if no one is using the AI
engine partition, by default, it will cleanup the partition by doing the
following:
* reset the columns
* reset the SHIMs
* clear data and program memory
* gate all the tiles
If user doesn't want the partition is reset when the partition is
released, user can set the control flag to indicate not to reset the
partition when the user requests the partition.
If partition the not to reset partition control flag is set, it will
not execute the above cleanup sequence when the partition is released.
Signed-off-by: Wendy Liang
Reviewed-by: Hyun Kwon
---
drivers/misc/xilinx-ai-engine/Makefile | 3 +-
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 92
drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 2 +
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 34 ++
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 7 +-
drivers/misc/xilinx-ai-engine/ai-engine-reset.c| 121 +
include/uapi/linux/xlnx-ai-engine.h| 6 +
7 files changed, 259 insertions(+), 6 deletions(-)
create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-reset.c
diff --git a/drivers/misc/xilinx-ai-engine/Makefile
b/drivers/misc/xilinx-ai-engine/Makefile
index 7827a0a..39bec61 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -8,4 +8,5 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
ai-engine-dev.o \
ai-engine-part.o \
- ai-engine-res.o
+ ai-engine-res.o \
+ ai-engine-reset.o
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 319260f..36127f0 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -5,6 +5,9 @@
* Copyright (C) 2020 Xilinx, Inc.
*/
+#include
+#include
+#include
#include
#include "ai-engine-internal.h"
@@ -24,9 +27,25 @@
#define AIE_SHIMPL_L1INTR_MASK_A_REGOFF0x00035000U
#define AIE_SHIMPL_L1INTR_BLOCK_NORTH_B_REGOFF 0x00035050U
#define AIE_SHIMPL_CLKCNTR_REGOFF 0x00036040U
+#define AIE_SHIMPL_COLRESET_REGOFF 0x00036048U
#define AIE_SHIMPL_RESET_REGOFF0x0003604cU
#define AIE_TILE_CORE_CLKCNTR_REGOFF 0x00036040U
+/*
+ * Register masks
+ */
+#define AIE_SHIMPL_SHIMRST_MASK0x1U
+#define AIE_SHIMPL_COLRST_MASK 0x1U
+#define AIE_SHIMPL_CLKCNTR_COLBUF_MASK 0x1U
+
+/*
+ * AI engine SHIM reset ID.
+ * TODO: it should follow the Linux reset framework. The ID should be in the
+ * device tree. However, as versal resets is not ready, we hardcode it in the
+ * driver.
+ */
+#define VERSAL_PM_RST_AIE_SHIM_ID 0xc10405fU
+
static const struct aie_tile_regs aie_kernel_regs[] = {
/* SHIM AXI MM Config */
{.attribute = AIE_TILE_TYPE_SHIMNOC << AIE_REGS_ATTR_TILE_TYPE_SHIFT,
@@ -49,6 +68,12 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
.soff = AIE_SHIMPL_L1INTR_MASK_A_REGOFF,
.eoff = AIE_SHIMPL_L1INTR_BLOCK_NORTH_B_REGOFF,
},
+ /* SHIM column reset */
+ {.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
+ AIE_REGS_ATTR_TILE_TYPE_SHIFT,
+.soff = AIE_SHIMPL_COLRESET_REGOFF,
+.eoff = AIE_SHIMPL_COLRESET_REGOFF,
+ },
/* SHIM reset Enable */
{.attribute = (AIE_TILE_TYPE_SHIMPL | AIE_TILE_TYPE_SHIMNOC) <<
AIE_REGS_ATTR_TILE_TYPE_SHIFT,
@@ -68,6 +93,16 @@ static const struct aie_tile_regs aie_kernel_regs[] = {
},
};
+static const struct aie_single_reg_field aie_col_rst = {
+ .mask = AIE_SHIMPL_COLRST_MASK,
+ .regoff = AIE_SHIMPL_COLRESET_REGOFF,
+};
+
+static const struct aie_single_reg_field aie_col_clkbuf = {
+ .mask = AIE_SHIMPL_CLKCNTR_COLBUF_MASK,
+ .regoff = AIE_SHIMPL_CLKCNTR_REGOFF,
+};
+
static u32 aie_get_tile_type(struct aie_location *loc)
{
if (loc->row)
@@ -79,8 +114,63 @@ static u32 aie_get_tile_type(struct aie_location *loc)
return AIE_TILE_TYPE_SHIMNOC;
}
+/**
+ * aie_set_shim_reset() - Set AI engine SHIM reset
+ * @adev: AI engine device
+ * @range: range of AI engine tiles
+ * @assert: true to set reset, false to unset reset
+ */
+static void aie_set_shim_reset(struct aie_device *adev,
+ struct aie_range *range, bool assert)
+{
+ u32 c;
+ u32 val;
+ struct aie_location loc;
+
+ val = FIELD_PREP(AIE_SHIMPL_SHIMRST_MASK, (assert ? 1 : 0));
+ loc.row = 0;
+ for (c = range->start.col; c < range->start.col + range->size.col;
+c++) {
+
[PATCH v3 7/9] misc: xilinx-ai-engine: Add support to request device management services
From: Nishad Saraf
Platform management services like device control, resets, power
management, etc. are provided by Platform, Loader and Manager(PLM)
through firmware driver APIs. For requesting some of these services,
this change reads AI Engine platform management node ID from DT node.
Some other features like clearing interrupts in the NoC interconnect
might only be valid for particular silicon revisions. For supporting
such silicon specific features, AI Engine driver will query and store
this information in device instance. While at it, this change makes
EEMI operations accessible to all the other source files in the
driver.
Signed-off-by: Nishad Saraf
Signed-off-by: Wendy Liang
---
drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 25 +-
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 6 ++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
b/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
index 43f4933..51c3a4f 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-dev.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,7 +27,8 @@
#include "ai-engine-internal.h"
-#define AIE_DEV_MAX(MINORMASK + 1)
+#define AIE_DEV_MAX(MINORMASK + 1)
+#define VERSAL_SILICON_REV_MASKGENMASK(31, 28)
static dev_t aie_major;
struct class *aie_class;
@@ -322,6 +324,7 @@ static int xilinx_ai_engine_probe(struct platform_device
*pdev)
{
struct aie_device *adev;
struct device *dev;
+ u32 idcode, version, pm_reg[2];
int ret;
adev = devm_kzalloc(&pdev->dev, sizeof(*adev), GFP_KERNEL);
@@ -349,6 +352,26 @@ static int xilinx_ai_engine_probe(struct platform_device
*pdev)
return ret;
}
+ /*
+* AI Engine platform management node ID is required for requesting
+* services from firmware driver.
+*/
+ ret = of_property_read_u32_array(pdev->dev.of_node, "power-domains",
+pm_reg, ARRAY_SIZE(pm_reg));
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "Failed to read power management information\n");
+ return ret;
+ }
+ adev->pm_node_id = pm_reg[1];
+
+ ret = zynqmp_pm_get_chipid(&idcode, &version);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get chip ID\n");
+ return ret;
+ }
+ adev->version = FIELD_GET(VERSAL_SILICON_REV_MASK, idcode);
+
dev = &adev->dev;
device_initialize(dev);
dev->class = aie_class;
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
index 131d22a..b21b7025 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
@@ -41,6 +41,10 @@
#define AIE_REGS_ATTR_PERM_MASKGENMASK(15, \
AIE_REGS_ATTR_PERM_SHIFT)
+/* Silicon Engineering Sample(ES) revision ID */
+#define VERSAL_ES1_REV_ID 0x0
+#define VERSAL_ES2_REV_ID 0x1
+
/**
* struct aie_tile_regs - contiguous range of AI engine register
* within an AI engine tile
@@ -173,6 +177,7 @@ struct aie_resource {
* while columns are occupied by partitions.
* @num_kernel_regs: number of kernel only registers range
* @version: AI engine device version
+ * @pm_node_id: AI Engine platform management node ID
*/
struct aie_device {
struct list_head partitions;
@@ -193,6 +198,7 @@ struct aie_device {
u32 row_shift;
u32 num_kernel_regs;
int version;
+ u32 pm_node_id;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] misc: Add Xilinx AI engine device driver
Create AI engine device/partition hierarchical structure. Each AI engine device can have multiple logical partitions(groups of AI engine tiles). Each partition is column based and has its own node ID in the system. AI engine device driver manages its partitions. Applications can access AI engine partition through the AI engine partition driver instance. AI engine registers write is moved to kernel as there are registers in the AI engine array needs privilege permission. Signed-off-by: Wendy Liang Signed-off-by: Hyun Kwon --- MAINTAINERS| 8 + drivers/misc/Kconfig | 12 + drivers/misc/Makefile | 1 + drivers/misc/xilinx-ai-engine/Makefile | 11 + drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 115 + drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 452 +++ drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 226 ++ drivers/misc/xilinx-ai-engine/ai-engine-part.c | 498 + drivers/misc/xilinx-ai-engine/ai-engine-res.c | 114 + include/uapi/linux/xlnx-ai-engine.h| 107 + 10 files changed, 1544 insertions(+) create mode 100644 drivers/misc/xilinx-ai-engine/Makefile create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-aie.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-dev.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-internal.h create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-part.c create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-res.c create mode 100644 include/uapi/linux/xlnx-ai-engine.h diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee..1e36294 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19287,6 +19287,14 @@ T: git https://github.com/Xilinx/linux-xlnx.git F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml F: drivers/phy/xilinx/phy-zynqmp.c +XILINX AI ENGINE DRIVER +M: Wendy Liang +S: Supported +F: Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml +F: drivers/misc/xilinx-ai-engine/ +F: include/linux/xlnx-ai-engine.h +F: include/uapi/linux/xlnx-ai-engine.h + XILLYBUS DRIVER M: Eli Billauer L: linux-ker...@vger.kernel.org diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index fafa8b0..0b8ce4d 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -444,6 +444,18 @@ config XILINX_SDFEC If unsure, say N. +config XILINX_AIE + tristate "Xilinx AI engine" + depends on ARM64 || COMPILE_TEST + help + This option enables support for the Xilinx AI engine driver. + One Xilinx AI engine device can have multiple partitions (groups of + AI engine tiles). Xilinx AI engine device driver instance manages + AI engine partitions. User application access its partitions through + AI engine partition instance file operations. + + If unsure, say N + config MISC_RTSX tristate default MISC_RTSX_PCI || MISC_RTSX_USB diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index d23231e..2176b18 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI) += habanalabs/ obj-$(CONFIG_UACCE)+= uacce/ obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o +obj-$(CONFIG_XILINX_AIE) += xilinx-ai-engine/ diff --git a/drivers/misc/xilinx-ai-engine/Makefile b/drivers/misc/xilinx-ai-engine/Makefile new file mode 100644 index 000..7827a0a --- /dev/null +++ b/drivers/misc/xilinx-ai-engine/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Makefile for Xilinx AI engine device driver +# + +obj-$(CONFIG_XILINX_AIE) += xilinx-aie.o + +xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \ + ai-engine-dev.o \ + ai-engine-part.o \ + ai-engine-res.o diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c new file mode 100644 index 000..319260f --- /dev/null +++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c @@ -0,0 +1,115 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Xilinx AI Engine driver AIE device specific implementation + * + * Copyright (C) 2020 Xilinx, Inc. + */ + +#include + +#include "ai-engine-internal.h" + +#define AIE_ARRAY_SHIFT30U +#define AIE_COL_SHIFT 23U +#define AIE_ROW_SHIFT 18U + +/* + * Registers offsets + */ +#define AIE_SHIMNOC_L2INTR_MASK_REGOFF 0x00015000U +#define AIE_SHIMNOC_L2INTR_INTR_REGOFF 0x00015010U +#define AIE_SHIMNOC_DMA_BD0_ADDRLOW_REGOFF 0x0001d000U +#define AIE_SHIMNOC_DMA_BD15_PACKET_REGOFF 0x0001d13cU +#define AIE_SHIMNOC_AXIMM_REGOFF 0x0001e020U +#define AIE_SHIMPL
[PATCH v1 2/3] drm/tiny: Add driver for ili9341 with parallel bus
From: Mikhail Durnev
MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.
It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.
[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/tiny/Kconfig| 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9341_gpio.c | 290
3 files changed, 304 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
If M is selected the module will be called ili9341.
+config TINYDRM_ILI9341_GPIO
+ tristate "DRM support for ILI9341 display panels with parallel bus
interface over GPIO"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..de8a63b8
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+ mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+ mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+ mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+ mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+ mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+ /* Memory
[PATCH v3 4/9] misc: xilinx-ai-engine: expose AI engine tile memories to userspace
There is no concern to have userspace to directly access AI engine
program and data memories. It will be much faster to directly copy
data to and from these memories from userspace.
We choose to use DMA buf for the data and program memory because of the
DMA buf features. DMA buf can share the DMA memory between applications
and different devices, which can benefit on how to share data with AI
engine device in future.
There is one DMA buf per type of memory in an AI engine partition. e.g.
There is one DMA buf for all the tile core program memories in an AI
engine partition. There is another DMA buf for all the tile data
memories in an AI engine partition.
Signed-off-by: Wendy Liang
Reviewed-by: Hyun Kwon
---
drivers/misc/xilinx-ai-engine/Makefile | 1 +
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 36 +++
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 30 +++
drivers/misc/xilinx-ai-engine/ai-engine-mem.c | 275 +
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 47
drivers/misc/xilinx-ai-engine/ai-engine-reset.c| 38 +++
include/uapi/linux/xlnx-ai-engine.h| 50
7 files changed, 477 insertions(+)
create mode 100644 drivers/misc/xilinx-ai-engine/ai-engine-mem.c
diff --git a/drivers/misc/xilinx-ai-engine/Makefile
b/drivers/misc/xilinx-ai-engine/Makefile
index 39bec61..2dbed42 100644
--- a/drivers/misc/xilinx-ai-engine/Makefile
+++ b/drivers/misc/xilinx-ai-engine/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_XILINX_AIE)+= xilinx-aie.o
xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
ai-engine-dev.o \
+ ai-engine-mem.o \
ai-engine-part.o \
ai-engine-res.o \
ai-engine-reset.o
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
index 36127f0..7fce2f00 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
@@ -12,10 +12,14 @@
#include "ai-engine-internal.h"
+#define KBYTES(n) ((n) * 1024)
+
#define AIE_ARRAY_SHIFT30U
#define AIE_COL_SHIFT 23U
#define AIE_ROW_SHIFT 18U
+#define NUM_MEMS_PER_TILE 2U
+
/*
* Registers offsets
*/
@@ -114,6 +118,37 @@ static u32 aie_get_tile_type(struct aie_location *loc)
return AIE_TILE_TYPE_SHIMNOC;
}
+static unsigned int aie_get_mem_info(struct aie_range *range,
+struct aie_part_mem *pmem)
+{
+ unsigned int i;
+
+ if (range->start.row + range->size.row <= 1) {
+ /* SHIM row only, no memories in this range */
+ return 0;
+ }
+ if (!pmem)
+ return NUM_MEMS_PER_TILE;
+
+ for (i = 0; i < NUM_MEMS_PER_TILE; i++) {
+ struct aie_mem *mem = &pmem[i].mem;
+
+ memcpy(&mem->range, range, sizeof(*range));
+ if (!mem->range.start.row) {
+ mem->range.start.row = 1;
+ mem->range.size.row--;
+ }
+ }
+ /* Setup tile data memory information */
+ pmem[0].mem.offset = 0;
+ pmem[0].mem.size = KBYTES(32);
+ /* Setup program memory information */
+ pmem[1].mem.offset = 0x2;
+ pmem[1].mem.size = KBYTES(16);
+
+ return NUM_MEMS_PER_TILE;
+}
+
/**
* aie_set_shim_reset() - Set AI engine SHIM reset
* @adev: AI engine device
@@ -170,6 +205,7 @@ static int aie_reset_shim(struct aie_device *adev, struct
aie_range *range)
static const struct aie_tile_operations aie_ops = {
.get_tile_type = aie_get_tile_type,
+ .get_mem_info = aie_get_mem_info,
.reset_shim = aie_reset_shim,
};
diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
index 2acd34f..e84610b 100644
--- a/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
+++ b/drivers/misc/xilinx-ai-engine/ai-engine-internal.h
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -67,8 +69,30 @@ struct aie_device;
struct aie_partition;
/**
+ * struct aie_part_mem - AI engine partition memory information structure
+ * @apart: AI engine partition
+ * @dbuf: dmabuf pointer associated with the memory
+ * @mem: memory information of a type of memory
+ * @size: size of the total memories in the partition
+ *
+ * This structure is to keep the information of a type of memory in a
+ * partition. The memory information will be stored in @mem property.
+ * The following information will be keep:
+ * * memory start address offset within a tile
+ * * memory size
+ * * what tiles contain this type of memory
+ */
+struct aie_part_mem {
+ struct aie_partition *apart;
+ struct dma_buf *dbuf;
+ struct aie_m
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
Hi Dmitry, The v5.10-rc6 was released from linus git tree. Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer after releasing the v5.1-rc7 for the integration test on linux-pm.git. The icc patches in this patch have not yet merged. If these patches are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches for v5.12-rc1. Best Regards, Chanwoo Choi On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > This series brings initial support for memory interconnect to Tegra20, > Tegra30 and Tegra124 SoCs. > > For the starter only display controllers and devfreq devices are getting > interconnect API support, others could be supported later on. The display > controllers have the biggest demand for interconnect API right now because > dynamic memory frequency scaling can't be done safely without taking into > account bandwidth requirement from the displays. In particular this series > fixes distorted display output on T30 Ouya and T124 TK1 devices. > > Changelog: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. > > v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into > patch "tegra30: Support interconnect framework". > Suggested by Krzysztof Kozlowski. > > - Improved Kconfig in the patch "memory: tegra124-emc: Make driver > modular" > by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes > to look a bit more cleaner. Suggested by Krzysztof Kozlowski. > > - Dropped voltage regulator support from ICC and DT patches for now > because there is a new discussion about using a power domain abstraction > for controlling the regulator, which is likely to happen. > > - Replaced direct "operating-points-v2" property checking in EMC drivers > with checking of a returned error code from dev_pm_opp_of_add_table(). > Note that I haven't touched T20 EMC driver because it's very likely > that we'll replace that code with a common helper soon anyways. > Suggested by Viresh Kumar. > > - The T30 DT patches now include EMC OPP changes for Ouya board, which > is available now in linux-next. > > Dmitry Osipenko (19): > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > memory: tegra30: Support interconnect framework > memory: tegra124-emc: Make driver modular > memory: tegra124-emc: Continue probing if timings are missing in > device-tree > memory: tegra124: Support interconnect framework > drm/tegra: dc: Support memory bandwidth management > drm/tegra: dc: Extend debug stats with total number of events > PM / devfreq: tegra30: Support interconnect and OPPs from device-tree > PM / devfreq: tegra30: Separate configurations per-SoC generation > PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver > ARM: tegra: Correct EMC registers size in Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra30 device-tree > ARM: tegra: Add interconnect properties to Tegra124 device-tree > ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC > device-tree > ARM: tegra: Add EMC OPP properties to Tegra20 device-trees > ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON > device-tree nodes > ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON > device-tree nodes > > .../memory-controllers/nvidia,tegra20-emc.txt | 6 + > MAINTAINERS | 1 - > arch/arm/boot/dts/tegra124-apalis-emc.dtsi| 8 + > .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 8 + > arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi | 10 + > .../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 + > .../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++ > arch/arm/boot/dts/tegra124.dtsi | 31 ++ > .../boot/dts/tegra20-acer-a500-picasso.dts| 5 + > arch/arm/boot/dts/tegra20-colibri.dtsi| 4 + > arch/arm/boot/dts/tegra20-paz00.dts | 4 + > .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 109 + > arch/arm/boot/dts/tegra20.dtsi| 33 +- > ...30-asus-nexus7-grouper-memory-timings.dtsi | 12 + > arch/arm/boot/dts/tegra30
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: > Hi Dmitry, > > The v5.10-rc6 was released from linus git tree. > Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer > after releasing the v5.1-rc7 for the integration test on linux-pm.git. > > The icc patches in this patch have not yet merged. If these patches > are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches > for v5.12-rc1. None of the patches here are going to be merged to Linus' in the current cycle. They will only go to the next so if there is dependency, everything will be broken and non-bisectable. However no such dependencies or merging requirements were mention in the cover letter. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On 11/30/20 5:36 PM, Krzysztof Kozlowski wrote: > On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: >> Hi Dmitry, >> >> The v5.10-rc6 was released from linus git tree. >> Generally, I will send the pull-quest about devfreq to linux-pm.git >> maintainer >> after releasing the v5.1-rc7 for the integration test on linux-pm.git. >> >> The icc patches in this patch have not yet merged. If these patches >> are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches >> for v5.12-rc1. > > None of the patches here are going to be merged to Linus' in the current > cycle. They will only go to the next so if there is dependency, > everything will be broken and non-bisectable. > > However no such dependencies or merging requirements were mention in the > cover letter. Thanks for reply. The devfreq patch depends on the icc changes. I'll apply the devfreq patches on next time (v5.12-rc1). Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/28] video: fbdev: aty: Delete unused variable in radeon_monitor
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix warning about variable that is asssigned a value but never used.
The variable was indeed never used so delete it.
Keep the call to radeon_probe_i2c_connector() as it may have
side-effects. It is unlikely but I could not verify that is was safe to
drop the call.
Signed-off-by: Sam Ravnborg
Cc: Benjamin Herrenschmidt
Cc: linux-fb...@vger.kernel.org
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/aty/radeon_monitor.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_monitor.c
b/drivers/video/fbdev/aty/radeon_monitor.c
index 9966c58aa26c..df55e23b7a5a 100644
--- a/drivers/video/fbdev/aty/radeon_monitor.c
+++ b/drivers/video/fbdev/aty/radeon_monitor.c
@@ -488,12 +488,10 @@ void radeon_probe_screens(struct radeonfb_info *rinfo,
#if defined(DEBUG) && defined(CONFIG_FB_RADEON_I2C)
{
u8 *EDIDs[4] = { NULL, NULL, NULL, NULL };
- int mon_types[4] = {MT_NONE, MT_NONE, MT_NONE, MT_NONE};
int i;
for (i = 0; i < 4; i++)
- mon_types[i] = radeon_probe_i2c_connector(rinfo,
- i+1,
&EDIDs[i]);
+ radeon_probe_i2c_connector(rinfo, i + 1,
&EDIDs[i]);
}
#endif /* DEBUG */
/*
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
On Mon, Nov 30, 2020 at 08:56:45AM +0100, Sam Ravnborg wrote: > Please just keep up the good work cleaning up fbcon and related stuff. > This is an area that needs some love and care and there is work for many > long nights yet to do. Thanks! I will see what I can do, Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/28] video: fbdev: aty: Fix set but not used warnings
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix W=1 warnings about variables assigned but never used.
- Drop variables that was set but never used
s/that was/that were
- Make variable definition conditional om ATARI
s/om/on
v2:
- Fix m68k build error (kernel test robot)
- Improve subject (Lee Jones)
Signed-off-by: Sam Ravnborg
Reported-by: kernel test robot # m68k build fix
Cc: Lee Jones
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Joe Perches
Cc: Vaibhav Gupta
Cc: Jason Yan
Cc: Randy Dunlap
Cc: Jani Nikula
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/aty/atyfb_base.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index c8feff0ee8da..83c8e809955a 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2353,6 +2353,9 @@ static int aty_init(struct fb_info *info)
int gtb_memsize, has_var = 0;
struct fb_var_screeninfo var;
int ret;
+#ifdef CONFIG_ATARI
+ u8 dac_type;
+#endif
init_waitqueue_head(&par->vblank.wait);
spin_lock_init(&par->int_lock);
@@ -2360,13 +2363,12 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_FB_ATY_GX
if (!M64_HAS(INTEGRATED)) {
u32 stat0;
- u8 dac_type, dac_subtype, clk_type;
+ u8 dac_subtype, clk_type;
stat0 = aty_ld_le32(CNFG_STAT0, par);
par->bus_type = (stat0 >> 0) & 0x07;
par->ram_type = (stat0 >> 3) & 0x07;
ramname = aty_gx_ram[par->ram_type];
/* FIXME: clockchip/RAMDAC probing? */
- dac_type = (aty_ld_le32(DAC_CNTL, par) >> 16) & 0x07;
#ifdef CONFIG_ATARI
clk_type = CLK_ATI18818_1;
dac_type = (stat0 >> 9) & 0x07;
@@ -2375,7 +2377,6 @@ static int aty_init(struct fb_info *info)
else
dac_subtype = (aty_ld_8(SCRATCH_REG1 + 1, par) & 0xF0)
| dac_type;
#else
- dac_type = DAC_IBMRGB514;
dac_subtype = DAC_IBMRGB514;
clk_type = CLK_IBMRGB514;
#endif
@@ -3062,7 +3063,6 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct
fb_info *info,
if (dp == of_console_device) {
struct fb_var_screeninfo *var = &default_var;
unsigned int N, P, Q, M, T, R;
- u32 v_total, h_total;
struct crtc crtc;
u8 pll_regs[16];
u8 clock_cntl;
@@ -3078,9 +3078,6 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct
fb_info *info,
crtc.gen_cntl = aty_ld_le32(CRTC_GEN_CNTL, par);
aty_crtc_to_var(&crtc, var);
- h_total = var->xres + var->right_margin + var->hsync_len + var->left_margin;
- v_total = var->yres + var->lower_margin + var->vsync_len +
var->upper_margin;
-
/*
* Read the PLL to figure actual Refresh Rate.
*/
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/3] drm/tiny: Add driver for ili9341 with parallel bus
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6
next-20201127]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201130-142812
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
09162bc32c880a791c6c0668ce0745cf7958f576
config: arm64-randconfig-r024-20201130 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/5883e05578f8008b00a270e8f4ebe9cb7e06a6b6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201130-142812
git checkout 5883e05578f8008b00a270e8f4ebe9cb7e06a6b6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_mipi_dbi.c: In function 'mipi_dbi_gpio_init':
>> drivers/gpu/drm/drm_mipi_dbi.c:1266:6: error: implicit declaration of
>> function 'mipi_dbi_machine_little_endian'
>> [-Werror=implicit-function-declaration]
1266 | if (mipi_dbi_machine_little_endian())
| ^~
cc1: some warnings being treated as errors
vim +/mipi_dbi_machine_little_endian +1266 drivers/gpu/drm/drm_mipi_dbi.c
12265315ac41a3e Mikhail Durnev 2020-11-30 1234
12265315ac41a3e Mikhail Durnev 2020-11-30 1235 /**
12265315ac41a3e Mikhail Durnev 2020-11-30 1236 * mipi_dbi_gpio_init -
Initialize MIPI DBI Type B interface implemented via GPIO
12265315ac41a3e Mikhail Durnev 2020-11-30 1237 * @dbi: MIPI DBI structure to
initialize
12265315ac41a3e Mikhail Durnev 2020-11-30 1238 * @dc: D/C gpio
12265315ac41a3e Mikhail Durnev 2020-11-30 1239 * @wr: W/R gpio
12265315ac41a3e Mikhail Durnev 2020-11-30 1240 * @db: DB gpios
12265315ac41a3e Mikhail Durnev 2020-11-30 1241 * @wr_up_delay: Delay after
setting DB and before changing W/R from low to high
12265315ac41a3e Mikhail Durnev 2020-11-30 1242 * @wr_down_delay: Delay after
changing W/R from low to high
12265315ac41a3e Mikhail Durnev 2020-11-30 1243 *
12265315ac41a3e Mikhail Durnev 2020-11-30 1244 * This function sets
&mipi_dbi->command, enables &mipi_dbi->read_commands for the
12265315ac41a3e Mikhail Durnev 2020-11-30 1245 * usual read commands. It
should be followed by a call to mipi_dbi_dev_init() or
12265315ac41a3e Mikhail Durnev 2020-11-30 1246 * a driver-specific init.
12265315ac41a3e Mikhail Durnev 2020-11-30 1247 *
12265315ac41a3e Mikhail Durnev 2020-11-30 1248 * Returns:
12265315ac41a3e Mikhail Durnev 2020-11-30 1249 * Zero on success, negative
error code on failure.
12265315ac41a3e Mikhail Durnev 2020-11-30 1250 */
12265315ac41a3e Mikhail Durnev 2020-11-30 1251 int mipi_dbi_gpio_init(struct
mipi_dbi *dbi, struct gpio_desc *dc,
12265315ac41a3e Mikhail Durnev 2020-11-30 1252 struct
gpio_desc *wr, struct gpio_descs *db,
12265315ac41a3e Mikhail Durnev 2020-11-30 1253 unsigned
long wr_up_delay, unsigned long wr_down_delay)
12265315ac41a3e Mikhail Durnev 2020-11-30 1254 {
12265315ac41a3e Mikhail Durnev 2020-11-30 1255 dbi->spi = NULL; /*
Type B uses GPIO lines rather than SPI */
12265315ac41a3e Mikhail Durnev 2020-11-30 1256
12265315ac41a3e Mikhail Durnev 2020-11-30 1257 dbi->read_commands =
mipi_dbi_dcs_read_commands;
12265315ac41a3e Mikhail Durnev 2020-11-30 1258 dbi->command =
mipi_dbi_gpio_command;
12265315ac41a3e Mikhail Durnev 2020-11-30 1259
12265315ac41a3e Mikhail Durnev 2020-11-30 1260 dbi->dc = dc;
12265315ac41a3e Mikhail Durnev 2020-11-30 1261 dbi->wr = wr;
12265315ac41a3e Mikhail Durnev 2020-11-30 1262 dbi->db = db;
12265315ac41a3e Mikhail Durnev 2020-11-30 1263 dbi->wr_up_delay =
wr_up_delay;
12265315ac41a3e Mikhail Durnev 2020-11-30 1264 dbi->wr_down_delay =
wr_down_delay;
12265315ac41a3e Mikhail Durnev 2020-11-30 1265
12265315ac41a3e Mikhail Durnev 2020-11-30 @1266 if
(mipi_dbi_machine_little_endian())
12265315ac41a3e Mikhail Durnev 2
Re: [PATCH v2 06/28] video: fbdev: aty: Fix set but not used warnings in mach64_ct
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix W=1 warnings about variables assigned but never used.
- One variable is only used when CONFIG_FB_ATY_GENERIC_LCD is defined
Fix so variable is only defined with CONFIG_FB_ATY_GENERIC_LCD
- Several variables was only assigned by a call to aty_ld_le32().
Drop the variables but keep the call to aty_ld_le32() as it may
have unexpected side-effects.
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/aty/mach64_ct.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/aty/mach64_ct.c
b/drivers/video/fbdev/aty/mach64_ct.c
index f87cc81f4fa2..011b07e44e0d 100644
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -281,10 +281,13 @@ static u32 aty_pll_to_var_ct(const struct fb_info *info,
const union aty_pll *pl
void aty_set_pll_ct(const struct fb_info *info, const union aty_pll *pll)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
- u32 crtc_gen_cntl, lcd_gen_cntrl;
+ u32 crtc_gen_cntl;
u8 tmp, tmp2;
- lcd_gen_cntrl = 0;
+#ifdef CONFIG_FB_ATY_GENERIC_LCD
+ u32 lcd_gen_cntrl = 0;
+#endif
+
#ifdef DEBUG
printk("atyfb(%s): about to program:\n"
"pll_ext_cntl=0x%02x pll_gen_cntl=0x%02x
pll_vclk_cntl=0x%02x\n",
@@ -402,7 +405,7 @@ static int aty_init_pll_ct(const struct fb_info *info,
union aty_pll *pll)
struct atyfb_par *par = (struct atyfb_par *) info->par;
u8 mpost_div, xpost_div, sclk_post_div_real;
u32 q, memcntl, trp;
- u32 dsp_config, dsp_on_off, vga_dsp_config, vga_dsp_on_off;
+ u32 dsp_config;
#ifdef DEBUG
int pllmclk, pllsclk;
#endif
@@ -488,9 +491,9 @@ static int aty_init_pll_ct(const struct fb_info *info,
union aty_pll *pll)
/* Allow BIOS to override */
dsp_config = aty_ld_le32(DSP_CONFIG, par);
- dsp_on_off = aty_ld_le32(DSP_ON_OFF, par);
- vga_dsp_config = aty_ld_le32(VGA_DSP_CONFIG, par);
- vga_dsp_on_off = aty_ld_le32(VGA_DSP_ON_OFF, par);
+ aty_ld_le32(DSP_ON_OFF, par);
+ aty_ld_le32(VGA_DSP_CONFIG, par);
+ aty_ld_le32(VGA_DSP_ON_OFF, par);
if (dsp_config)
pll->ct.dsp_loop_latency = (dsp_config & DSP_LOOP_LATENCY) >>
16;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/28] video: fbdev: sis: Fix defined but not used warnings
Am 28.11.20 um 23:40 schrieb Sam Ravnborg: init.h define static symbols, so should only be included s/define/defines s/so should/so it should once. Drop the include from sis.h as it is not needed. This fixes a lot of warnings seen with a W=1 build. v2: - Update subject (Lee) Signed-off-by: Sam Ravnborg Cc: Thomas Winischhofer Cc: Lee Jones Acked-by: Thomas Zimmermann --- drivers/video/fbdev/sis/sis.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/sis/sis.h b/drivers/video/fbdev/sis/sis.h index 9f4c3093ccb3..d632f096083b 100644 --- a/drivers/video/fbdev/sis/sis.h +++ b/drivers/video/fbdev/sis/sis.h @@ -15,7 +15,6 @@ #include "vgatypes.h" #include "vstruct.h" -#include "init.h" #define VER_MAJOR 1 #define VER_MINOR 8 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: document that user-space should force-probe connectors
It seems like we can't have nice things, so let's just document the
disappointing behaviour instead.
Signed-off-by: Simon Ser
Fixes: 2ac5ef3b2362 ("drm: document drm_mode_get_connector")
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ville Syrjala
---
include/uapi/drm/drm_mode.h | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b49fbf2bdc40..2e99f29d7f81 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -414,15 +414,10 @@ enum drm_mode_subconnector {
*
* If the @count_modes field is set to zero, the kernel will perform a forced
* probe on the connector to refresh the connector status, modes and EDID.
- * A forced-probe can be slow and the ioctl will block. A force-probe can cause
- * flickering and temporary freezes, so it should not be performed
- * automatically.
+ * A forced-probe can be slow and the ioctl will block.
*
- * User-space shouldn't need to force-probe connectors in general: the kernel
- * will automatically take care of probing connectors that don't support
- * hot-plug detection when appropriate. However, user-space may force-probe
- * connectors on user request (e.g. clicking a "Scan connectors" button, or
- * opening a UI to manage screens).
+ * User-space needs to force-probe connectors to ensure their metadata is
+ * up-to-date.
*/
struct drm_mode_get_connector {
/** @encoders_ptr: Pointer to ``__u32`` array of object IDs. */
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/28] video: fbdev: sis: Fix defined but not used warning of SiS_TVDelay
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix W=1 warning by commenting unused SiS_TVDelay* variables.
The SiS_TVDelay* variables seem to contain some magic numbers
so looks like data worth keeping around but not as code we build.
I would remove it. sisfb is broken beyond repair and no one's going to
try to use it anyway. In any case
Acked-by: Thomas Zimemrmann
v2:
- Update subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
Cc: Lee Jones
---
drivers/video/fbdev/sis/oem310.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/sis/oem310.h b/drivers/video/fbdev/sis/oem310.h
index 8fce56e4482c..ed28755715ce 100644
--- a/drivers/video/fbdev/sis/oem310.h
+++ b/drivers/video/fbdev/sis/oem310.h
@@ -200,6 +200,7 @@ static const unsigned char
SiS310_TVDelayCompensation_651302LV[] = /* M650, 651,
0x33,0x33
};
+#if 0 /* Not used */
static const unsigned char SiS_TVDelay661_301[] = /* 661,
301 */
{
0x44,0x44,
@@ -219,6 +220,7 @@ static const unsigned char SiS_TVDelay661_301B[] =
/* 661, 301B et al */
0x44,0x44,
0x44,0x44
};
+#endif
static const unsigned char SiS310_TVDelayCompensation_LVDS[] = /* LVDS */
{
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/28] video: fbdev: sis: Fix set but not used warnings in init.c
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix set bit not used warnings by removing the code the assign the
s/bit/but
Actually, I think the correct way of writing this would be with dashes:
Fix set-but-not-used warnings
In the current sentence, you're setting a 'but not used variable.'
variables and the definition of the variables.
A register read is kept as it may have unknown side-effects.
This removes a lot of unused code - which is always a good thing to do.
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/sis/init.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index fde27feae5d0..b77ea1a8825a 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -2648,7 +2648,7 @@ static void
SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
unsigned short ModeIdIndex, unsigned short RRTI)
{
- unsigned short data, infoflag = 0, modeflag, resindex;
+ unsigned short data, infoflag = 0, modeflag;
#ifdef CONFIG_FB_SIS_315
unsigned char *ROMAddr = SiS_Pr->VirtualRomBase;
unsigned short data2, data3;
@@ -2659,7 +2659,7 @@ SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned
short ModeNo,
if(SiS_Pr->UseCustomMode) {
infoflag = SiS_Pr->CInfoFlag;
} else {
- resindex = SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
+ SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
if(ModeNo > 0x13) {
infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag;
}
@@ -3538,17 +3538,13 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
struct fb_var_screeninfo *var, bool writeres
)
{
- unsigned short HRE, HBE, HRS, HBS, HDE, HT;
- unsigned short VRE, VBE, VRS, VBS, VDE, VT;
- unsigned char sr_data, cr_data, cr_data2;
- intA, B, C, D, E, F, temp;
+ unsigned short HRE, HBE, HRS, HDE;
+ unsigned short VRE, VBE, VRS, VDE;
+ unsigned char sr_data, cr_data;
+ intB, C, D, E, F, temp;
sr_data = crdata[14];
- /* Horizontal total */
- HT = crdata[0] | ((unsigned short)(sr_data & 0x03) << 8);
- A = HT + 5;
-
/* Horizontal display enable end */
HDE = crdata[1] | ((unsigned short)(sr_data & 0x0C) << 6);
E = HDE + 1;
@@ -3557,9 +3553,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
HRS = crdata[4] | ((unsigned short)(sr_data & 0xC0) << 2);
F = HRS - E - 3;
- /* Horizontal blank start */
- HBS = crdata[2] | ((unsigned short)(sr_data & 0x30) << 4);
-
sr_data = crdata[15];
cr_data = crdata[5];
@@ -3588,13 +3581,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr, unsigned char *crdata,
sr_data = crdata[13];
cr_data = crdata[7];
- /* Vertical total */
- VT = crdata[6] |
-((unsigned short)(cr_data & 0x01) << 8) |
-((unsigned short)(cr_data & 0x20) << 4) |
-((unsigned short)(sr_data & 0x01) << 10);
- A = VT + 2;
-
/* Vertical display enable end */
VDE = crdata[10] |
((unsigned short)(cr_data & 0x02) << 7) |
@@ -3609,14 +3595,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
((unsigned short)(sr_data & 0x08) << 7);
F = VRS + 1 - E;
- cr_data2 = (crdata[16] & 0x01) << 5;
-
- /* Vertical blank start */
- VBS = crdata[11] |
-((unsigned short)(cr_data & 0x08) << 5) |
-((unsigned short)(cr_data2 & 0x20) << 4) |
-((unsigned short)(sr_data & 0x04) << 8);
-
/* Vertical blank end */
VBE = crdata[12] | ((unsigned short)(sr_data & 0x10) << 4);
temp = VBE - ((E - 1) & 511);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: bridge: Propagate the bus flags from bridge->timings
Hi Nikhil, Thank you for the patch. On Thu, Nov 19, 2020 at 09:31:29PM +0530, Nikhil Devshatwar wrote: > bus_flags can be specified by a bridge in the timings. > If the bridge provides it, Override the bus_flags when propagating > from next bridge. > > Signed-off-by: Nikhil Devshatwar > Reviewed-by: Tomi Valkeinen > --- > > Notes: > changes from v2: > * update comment > changes from v1: > * Check for timings > * Prioritize timings flags over next bridge's flags > > drivers/gpu/drm/drm_bridge.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 64f0effb52ac..13b67fc0dad3 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -975,6 +975,14 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge > *bridge, >* duplicate the "dummy propagation" logic. >*/ > bridge_state->input_bus_cfg.flags = output_flags; > + > + /* > + * If legacy bus flags are provided in bridge->timings, use those as > + * input flags instead of propagating the output flags. > + */ > + if (bridge->timings && bridge->timings->input_bus_flags) > + bridge_state->input_bus_cfg.flags = > + bridge->timings->input_bus_flags; Hasn't Boris commented in his review of v1 that bus flags should be set in atomic_check, even when they're static ? We're moving towards removing timings->input_bus_flags, so this patch goes in the wrong direction :-S > } > > /** -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/6] drm/bridge: tfp410: Support format negotiation hooks
Hi Nikhil,
Thank you for the patch.
On Thu, Nov 19, 2020 at 09:31:30PM +0530, Nikhil Devshatwar wrote:
> With new connector model, tfp410 will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
>
> Support format negotiations hooks in the drm_bridge_funcs.
> Use helper functions for state management.
>
> Output format is expected to be MEDIA_BUS_FMT_FIXED
> Input format is the one selected by the bridge from DT properties.
>
> Signed-off-by: Nikhil Devshatwar
> Reviewed-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
>
> Notes:
> changes from v1:
> * Use only MEDIA_BUS_FMT_FIXED for output
>
> drivers/gpu/drm/bridge/ti-tfp410.c | 33 ++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index ba3fa2a9b8a4..3def9acba86b 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -204,12 +204,45 @@ static enum drm_mode_status tfp410_mode_valid(struct
> drm_bridge *bridge,
> return MODE_OK;
> }
>
> +static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + u32 output_fmt,
> + unsigned int *num_input_fmts)
> +{
> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
> + u32 *input_fmts;
> +
> + *num_input_fmts = 0;
> +
> + /*
> + * Output of tfp410 is DVI, which is TMDS.
> + * There is no media format defined for this.
> + * Using MEDIA_BUS_FMT_FIXED for now.
> + */
> + if (output_fmt != MEDIA_BUS_FMT_FIXED)
> + return NULL;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = dvi->bus_format;
> + return input_fmts;
> +}
> +
> static const struct drm_bridge_funcs tfp410_bridge_funcs = {
> .attach = tfp410_attach,
> .detach = tfp410_detach,
> .enable = tfp410_enable,
> .disable= tfp410_disable,
> .mode_valid = tfp410_mode_valid,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
> };
>
> static const struct drm_bridge_timings tfp410_default_timings = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm/tidss: Set bus_format correctly from bridge/connector
Hi Nikhil,
Thank you for the patch.
On Thu, Nov 19, 2020 at 09:31:32PM +0530, Nikhil Devshatwar wrote:
> Remove the old code to iterate over the bridge chain, as this is
> already done by the framework.
> The bridge state should have the negotiated bus format and flags.
> Use these from the bridge's state.
> If the bridge does not support format negotiation, error out
> and fail.
>
> Signed-off-by: Nikhil Devshatwar
> Reviewed-by: Tomi Valkeinen
> ---
>
> Notes:
> changes from v2:
> * Remove the old code and use the flags from the bridge state
>
> drivers/gpu/drm/tidss/tidss_encoder.c | 36 +++
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
> b/drivers/gpu/drm/tidss/tidss_encoder.c
> index e278a9c89476..08d5083c5508 100644
> --- a/drivers/gpu/drm/tidss/tidss_encoder.c
> +++ b/drivers/gpu/drm/tidss/tidss_encoder.c
> @@ -21,37 +21,29 @@ static int tidss_encoder_atomic_check(struct drm_encoder
> *encoder,
> {
> struct drm_device *ddev = encoder->dev;
> struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
> - struct drm_display_info *di = &conn_state->connector->display_info;
> + struct drm_bridge_state *bstate;
> struct drm_bridge *bridge;
> - bool bus_flags_set = false;
>
> dev_dbg(ddev->dev, "%s\n", __func__);
>
> - /*
> - * Take the bus_flags from the first bridge that defines
> - * bridge timings, or from the connector's display_info if no
> - * bridge defines the timings.
> - */
> - drm_for_each_bridge_in_chain(encoder, bridge) {
> - if (!bridge->timings)
> - continue;
> -
> - tcrtc_state->bus_flags = bridge->timings->input_bus_flags;
> - bus_flags_set = true;
> - break;
> + /* Copy the bus_format and flags from the first bridge's state */
> + bridge = drm_bridge_chain_get_first_bridge(encoder);
> + bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
> + if (bstate) {
> + tcrtc_state->bus_format = bstate->input_bus_cfg.format;
> + tcrtc_state->bus_flags = bstate->input_bus_cfg.flags;
> + } else {
> + dev_err(ddev->dev, "Could not get the bridge state\n");
> + return -EINVAL;
> }
I'd write this
bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
if (!bstate) {
dev_err(ddev->dev, "Could not get the bridge state\n");
return -EINVAL;
}
tcrtc_state->bus_format = bstate->input_bus_cfg.format;
tcrtc_state->bus_flags = bstate->input_bus_cfg.flags;
>
> - if (!di->bus_formats || di->num_bus_formats == 0) {
> - dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
> - __func__);
> + if (tcrtc_state->bus_format == 0 ||
> + tcrtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> +
> + dev_err(ddev->dev, "Bridge connected to the encoder did not
> specify media bus format\n");
> return -EINVAL;
> }
>
> - // XXX any cleaner way to set bus format and flags?
> - tcrtc_state->bus_format = di->bus_formats[0];
> - if (!bus_flags_set)
> - tcrtc_state->bus_flags = di->bus_flags;
> -
> return 0;
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm/tidss: Set bus_format correctly from bridge/connector
Hi Nikhil, On Mon, Nov 30, 2020 at 12:05:03PM +0530, Nikhil Devshatwar wrote: > On 14:51-20201125, Tomi Valkeinen wrote: > > On 19/11/2020 18:01, Nikhil Devshatwar wrote: > > > Remove the old code to iterate over the bridge chain, as this is > > > already done by the framework. > > > The bridge state should have the negotiated bus format and flags. > > > Use these from the bridge's state. > > > If the bridge does not support format negotiation, error out > > > and fail. > > > > > > Signed-off-by: Nikhil Devshatwar > > > Reviewed-by: Tomi Valkeinen > > > --- > > > > > > Notes: > > > changes from v2: > > > * Remove the old code and use the flags from the bridge state > > > > > > drivers/gpu/drm/tidss/tidss_encoder.c | 36 +++ > > > 1 file changed, 14 insertions(+), 22 deletions(-) > > > > If a first bridge (after the crtc) supports two bus formats as input, how > > does tidss choose between > > those? This patch just picks bstate->input_bus_cfg.format, and it's not > > clear to me which one that > > is (the first one?). Also, we don't check if tidss actually supports the > > bus format. > > The selection is done by the framework in > select_bus_fmt_recursive at drivers/gpu/drm/drm_bridge.c:810 > > My understanding is that currently, the format negotiation logic does > not negotiate all the way till encoder, it stops only at the > first_bridge. Should we then implement a bridge in the tidss driver to model the internal encoder, in order to support format negotiation all the way to the tidss ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: bridge: Propagate the bus flags from bridge->timings
Hi Tomi, On Mon, Nov 30, 2020 at 11:46:31AM +0200, Tomi Valkeinen wrote: > On 30/11/2020 11:36, Laurent Pinchart wrote: > > On Thu, Nov 19, 2020 at 09:31:29PM +0530, Nikhil Devshatwar wrote: > >> bus_flags can be specified by a bridge in the timings. > >> If the bridge provides it, Override the bus_flags when propagating > >> from next bridge. > >> > >> Signed-off-by: Nikhil Devshatwar > >> Reviewed-by: Tomi Valkeinen > >> --- > >> > >> Notes: > >> changes from v2: > >> * update comment > >> changes from v1: > >> * Check for timings > >> * Prioritize timings flags over next bridge's flags > >> > >> drivers/gpu/drm/drm_bridge.c | 8 > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > >> index 64f0effb52ac..13b67fc0dad3 100644 > >> --- a/drivers/gpu/drm/drm_bridge.c > >> +++ b/drivers/gpu/drm/drm_bridge.c > >> @@ -975,6 +975,14 @@ drm_atomic_bridge_propagate_bus_flags(struct > >> drm_bridge *bridge, > >> * duplicate the "dummy propagation" logic. > >> */ > >>bridge_state->input_bus_cfg.flags = output_flags; > >> + > >> + /* > >> + * If legacy bus flags are provided in bridge->timings, use those as > >> + * input flags instead of propagating the output flags. > >> + */ > >> + if (bridge->timings && bridge->timings->input_bus_flags) > >> + bridge_state->input_bus_cfg.flags = > >> + bridge->timings->input_bus_flags; > > > > Hasn't Boris commented in his review of v1 that bus flags should be set > > in atomic_check, even when they're static ? We're moving towards > > removing timings->input_bus_flags, so this patch goes in the wrong > > direction :-S > > We have atomic_check only if the bridge has implemented atomic funcs. And > even if there's > atomic_check, not all bridges set the bus_flags there. So we need to either > 1) fix the issue for now > as in this patch, or 2) convert all bridges to use atomic funcs and fix all > the bridges to set the > bus_flags. The second option is what we'd like to achieve. Wouldn't it be best to already start going in that direction ? We don't need to convert all bridge drivers in one go here, just the ones that are used by tidss. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 55/80] drm/panel: panel-dsi-cm: use MIPI_DCS_GET_ERROR_COUNT_ON_DSI
Hi Tomi, Thank you for the patch. On Tue, Nov 24, 2020 at 02:45:13PM +0200, Tomi Valkeinen wrote: > Use the common MIPI_DCS_GET_ERROR_COUNT_ON_DSI define instead of > driver's own. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/panel/panel-dsi-cm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c > b/drivers/gpu/drm/panel/panel-dsi-cm.c > index 35a0c7da1974..cb0d27a38555 100644 > --- a/drivers/gpu/drm/panel/panel-dsi-cm.c > +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c > @@ -27,7 +27,6 @@ > #include > #include > > -#define DCS_READ_NUM_ERRORS 0x05 > #define DCS_GET_ID1 0xda > #define DCS_GET_ID2 0xdb > #define DCS_GET_ID3 0xdc > @@ -225,7 +224,7 @@ static ssize_t num_dsi_errors_show(struct device *dev, > mutex_lock(&ddata->lock); > > if (ddata->enabled) > - r = dsicm_dcs_read_1(ddata, DCS_READ_NUM_ERRORS, &errors); > + r = dsicm_dcs_read_1(ddata, MIPI_DCS_GET_ERROR_COUNT_ON_DSI, > &errors); > > mutex_unlock(&ddata->lock); > -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 56/80] drm/panel: panel-dsi-cm: cleanup tear enable
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:14PM +0200, Tomi Valkeinen wrote:
> Simplify the code by moving code from _dsicm_enable_te() into
> dsicm_power_on().
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-dsi-cm.c | 23 ---
> 1 file changed, 4 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index cb0d27a38555..59e8e6b18e97 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -69,8 +69,6 @@ static inline struct panel_drv_data *panel_to_ddata(struct
> drm_panel *panel)
> return container_of(panel, struct panel_drv_data, panel);
> }
>
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
> -
> static void dsicm_bl_power(struct panel_drv_data *ddata, bool enable)
> {
> struct backlight_device *backlight;
> @@ -314,10 +312,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
> if (r)
> goto err;
>
> - r = _dsicm_enable_te(ddata, true);
> + r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> if (r)
> goto err;
>
> + /* possible panel bug */
> + msleep(100);
> +
> ddata->enabled = true;
>
> if (!ddata->intro_printed) {
> @@ -418,22 +419,6 @@ static int dsicm_disable(struct drm_panel *panel)
> return r;
> }
>
> -static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable)
> -{
> - struct mipi_dsi_device *dsi = ddata->dsi;
> - int r;
> -
> - if (enable)
> - r = mipi_dsi_dcs_set_tear_on(dsi,
> MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> - else
> - r = mipi_dsi_dcs_set_tear_off(dsi);
> -
> - /* possible panel bug */
> - msleep(100);
> -
> - return r;
> -}
> -
> static int dsicm_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 57/80] ARM: dts: omap5: add address-cells & size-cells to dsi
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:15PM +0200, Tomi Valkeinen wrote:
> Add address-cells & size-cells to DSI nodes so that board files do not
> need to define them.
How about adding ports too, while at it ?
It would also be nice to convert the DT bindings to YAML :-)
> Signed-off-by: Tomi Valkeinen
> Cc: Tony Lindgren
> ---
> arch/arm/boot/dts/omap5.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 2bf2e5839a7f..e6f6947965ef 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -517,6 +517,9 @@ dsi1: encoder@0 {
> clocks = <&dss_clkctrl
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl
> OMAP5_DSS_CORE_CLKCTRL 10>;
> clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> };
> };
>
> @@ -549,6 +552,9 @@ dsi2: encoder@0 {
> clocks = <&dss_clkctrl
> OMAP5_DSS_CORE_CLKCTRL 8>,
><&dss_clkctrl
> OMAP5_DSS_CORE_CLKCTRL 10>;
> clock-names = "fck", "sys_clk";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> };
> };
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 58/80] drm/omap: pll: fix iteration loop check
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:16PM +0200, Tomi Valkeinen wrote:
> If the PLL calc function is given bad parameters, n_start/m_start may be
> higher than n_stop/m_stop, which leads to the loops iterating through
> the whole u32 number space.
>
> Fix this by failing early on such cases.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/pll.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c
> b/drivers/gpu/drm/omapdrm/dss/pll.c
> index 1212f3cc52d1..12926218c436 100644
> --- a/drivers/gpu/drm/omapdrm/dss/pll.c
> +++ b/drivers/gpu/drm/omapdrm/dss/pll.c
> @@ -222,6 +222,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned
> long clkin,
> n_stop = min((unsigned)(clkin / fint_hw_min), hw->n_max);
> n_inc = 1;
>
> + if (n_start > n_stop)
> + return false;
> +
> if (hw->errata_i886) {
> swap(n_start, n_stop);
> n_inc = -1;
> @@ -239,6 +242,9 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned
> long clkin,
> hw->m_max);
> m_inc = 1;
>
> + if (m_start > m_stop)
> + continue;
> +
> if (hw->errata_i886) {
> swap(m_start, m_stop);
> m_inc = -1;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 59/80] drm/omap: dsi: set trans_mode according to client mode_flags
Hi Tomi, Thank you for the patch. On Tue, Nov 24, 2020 at 02:45:17PM +0200, Tomi Valkeinen wrote: > The DSI host driver currently ignores the video mode flags in > client->mode_flags. Add the code to take the transfer mode from client's > mode_flags. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c > b/drivers/gpu/drm/omapdrm/dss/dsi.c > index c3592c6db977..7fee9cf8782d 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c > @@ -5140,6 +5140,13 @@ static int omap_dsi_host_attach(struct mipi_dsi_host > *host, > dsi->config.lp_clk_min = 700; // TODO: get from client? > dsi->config.lp_clk_max = client->lp_rate; > > + if (client->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) > + dsi->config.trans_mode = OMAP_DSS_DSI_BURST_MODE; > + else if (client->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) > + dsi->config.trans_mode = OMAP_DSS_DSI_PULSE_MODE; > + else > + dsi->config.trans_mode = OMAP_DSS_DSI_EVENT_MODE; > + > dsi->ulps_auto_idle = false; > > return 0; > -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 60/80] drm/panel: panel-dsi-cm: set column & page at setup
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:18PM +0200, Tomi Valkeinen wrote:
> Set the column & page address once during setup, instead of relying the
> DSI host driver to set those.
>
> Signed-off-by: Tomi Valkeinen
With Sam's comments addressed,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-dsi-cm.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index 59e8e6b18e97..1e7f73340736 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -171,6 +171,26 @@ static int dsicm_get_id(struct panel_drv_data *ddata, u8
> *id1, u8 *id2, u8 *id3)
> return 0;
> }
>
> +static int dsicm_set_update_window(struct panel_drv_data *ddata)
> +{
> + struct mipi_dsi_device *dsi = ddata->dsi;
> + int r;
> + u16 x1 = 0;
> + u16 x2 = ddata->mode.hdisplay - 1;
> + u16 y1 = 0;
> + u16 y2 = ddata->mode.vdisplay - 1;
> +
> + r = mipi_dsi_dcs_set_column_address(dsi, x1, x2);
> + if (r < 0)
> + return r;
> +
> + r = mipi_dsi_dcs_set_page_address(dsi, y1, y2);
> + if (r < 0)
> + return r;
> +
> + return 0;
> +}
> +
> static int dsicm_bl_update_status(struct backlight_device *dev)
> {
> struct panel_drv_data *ddata = dev_get_drvdata(&dev->dev);
> @@ -308,6 +328,10 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
> if (r)
> goto err;
>
> + r = dsicm_set_update_window(ddata);
> + if (r)
> + goto err;
> +
> r = mipi_dsi_dcs_set_display_on(ddata->dsi);
> if (r)
> goto err;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 61/80] drm/omap: dsi: send nop instead of page & column
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:19PM +0200, Tomi Valkeinen wrote:
> The OMAP DSI command mode panel driver used to send page & column
> address before each frame update, and this code was moved into the DSI
> host driver when converting it to the DRM bridge model.
>
> However, it's not really required to send the page & column address
> before each frame. It's also something that doesn't really belong to the
> DSI host driver, so we should drop the code.
>
> That said, frame updates break if we don't send _something_ between the
> frames. A NOP command does the trick.
>
> It is not clear if this behavior is as expected from a DSI command mode
> frame transfer, or is it a feature/issue with OMAP DSI driver, or a
> feature/issue in the command mode panel used. So this probably needs to
> be revisited later.
This is important information, could you capture it in a comment in the
code ?
Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 41 +--
> 1 file changed, 12 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 7fee9cf8782d..746c2149fbbd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3884,35 +3884,19 @@ static int _dsi_update(struct dsi_data *dsi)
> return 0;
> }
>
> -static int _dsi_update_window(struct dsi_data *dsi, int channel,
> - int x, int y, int w, int h)
> -{
> - int x1 = x, x2 = (x + w - 1);
> - int y1 = y, y2 = (y + h - 1);
> - u8 payloadX[5] = { MIPI_DCS_SET_COLUMN_ADDRESS,
> -x1 >> 8, x1 & 0xff, x2 >> 8, x2 & 0xff };
> - u8 payloadY[5] = { MIPI_DCS_SET_PAGE_ADDRESS,
> -y1 >> 8, y1 & 0xff, y2 >> 8, y2 & 0xff };
> - struct mipi_dsi_msg msgX = { 0 }, msgY = { 0 };
> - int ret;
> +static int _dsi_send_nop(struct dsi_data *dsi, int channel)
> +{
> + const u8 payload[] = { MIPI_DCS_NOP };
> + const struct mipi_dsi_msg msg = {
> + .channel = channel,
> + .type = MIPI_DSI_DCS_SHORT_WRITE,
> + .tx_len = 1,
> + .tx_buf = payload,
> + };
>
> WARN_ON(!dsi_bus_is_locked(dsi));
>
> - msgX.type = MIPI_DSI_DCS_LONG_WRITE;
> - msgX.channel = channel;
> - msgX.tx_buf = payloadX;
> - msgX.tx_len = sizeof(payloadX);
> -
> - msgY.type = MIPI_DSI_DCS_LONG_WRITE;
> - msgY.channel = channel;
> - msgY.tx_buf = payloadY;
> - msgY.tx_len = sizeof(payloadY);
> -
> - ret = _omap_dsi_host_transfer(dsi, &msgX);
> - if (ret != 0)
> - return ret;
> -
> - return _omap_dsi_host_transfer(dsi, &msgY);
> + return _omap_dsi_host_transfer(dsi, &msg);
> }
>
> static int dsi_update_channel(struct omap_dss_device *dssdev, int channel)
> @@ -3944,10 +3928,9 @@ static int dsi_update_channel(struct omap_dss_device
> *dssdev, int channel)
>
> dsi_set_ulps_auto(dsi, false);
>
> - r = _dsi_update_window(dsi, channel, 0, 0, dsi->vm.hactive,
> -dsi->vm.vactive);
> + r = _dsi_send_nop(dsi, channel);
> if (r < 0) {
> - DSSWARN("window update error: %d\n", r);
> + DSSWARN("failed to send nop between frames: %d\n", r);
> goto err;
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
On Fri, 27 Nov 2020, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
>> Hi Daniel, Jani,
>>
>> is it ok to merge this patch along with 2/2 via the i915 tree?
>
> Ack from mesa (userspace in general, but mesa is kinda mandatory) is
> missing I think. With that
>
> Acked-by: Daniel Vetter
With the same conditions,
Acked-by: Jani Nikula
>
>>
>> --Imre
>>
>> On Mon, Nov 23, 2020 at 08:26:30PM +0200, Imre Deak wrote:
>> > From: Radhakrishna Sripada
>> >
>> > Gen12 display can decompress surfaces compressed by render engine with
>> > Clear Color, add a new modifier as the driver needs to know the surface
>> > was compressed by render engine.
>> >
>> > V2: Description changes as suggested by Rafael.
>> > V3: Mention the Clear Color size of 64 bits in the comments(DK)
>> > v4: Fix trailing whitespaces
>> > v5: Explain Clear Color in the documentation.
>> > v6: Documentation Nitpicks(Nanley)
>> >
>> > Cc: Ville Syrjala
>> > Cc: Dhinakaran Pandiyan
>> > Cc: Kalyan Kondapally
>> > Cc: Rafael Antognolli
>> > Cc: Nanley Chery
>> > Signed-off-by: Radhakrishna Sripada
>> > Signed-off-by: Imre Deak
>> > ---
>> > include/uapi/drm/drm_fourcc.h | 19 +++
>> > 1 file changed, 19 insertions(+)
>> >
>> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> > index ca48ed0e6bc1..0a1b2c4c4bee 100644
>> > --- a/include/uapi/drm/drm_fourcc.h
>> > +++ b/include/uapi/drm/drm_fourcc.h
>> > @@ -527,6 +527,25 @@ extern "C" {
>> > */
>> > #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
>> >
>> > +/*
>> > + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
>> > + * compression.
>> > + *
>> > + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
>> > linear
>> > + * and at index 1. The clear color is stored at index 2, and the pitch
>> > should
>> > + * be ignored. The clear color structure is 256 bits. The first 128 bits
>> > + * represents Raw Clear Color Red, Green, Blue and Alpha color each
>> > represented
>> > + * by 32 bits. The raw clear color is consumed by the 3d engine and
>> > generates
>> > + * the converted clear color of size 64 bits. The first 32 bits store the
>> > Lower
>> > + * Converted Clear Color value and the next 32 bits store the Higher
>> > Converted
>> > + * Clear Color value when applicable. The Converted Clear Color values are
>> > + * consumed by the DE. The last 64 bits are used to store Color Discard
>> > Enable
>> > + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache
>> > line
>> > + * corresponds to an area of 4x1 tiles in the main surface. The main
>> > surface
>> > + * pitch is required to be a multiple of 4 tile widths.
>> > + */
>> > +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
>> > +
>> > /*
>> > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>> > *
>> > --
>> > 2.25.1
>> >
>> > ___
>> > Intel-gfx mailing list
>> > intel-...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 62/80] drm/omap: dsi: simplify VC handling
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 02:45:20PM +0200, Tomi Valkeinen wrote:
> The VC handling has gotten quite tangled up. As the first step to clean
> it up, lets define that we only support a single DSI peripheral (which
> was really already the case), and we always use VC0 (define VC_DEFAULT
> 0) register block to send data to the peripheral.
>
> We can thus have a single mipi_dsi_device pointer and remove the for
s/the for/the need for/ ?
> loops which made passes over all the four VCs (just the first one was
> ever used).
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 49 ---
> 1 file changed, 13 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 746c2149fbbd..63338324c564 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -360,9 +360,10 @@ struct dsi_data {
> bool vdds_dsi_enabled;
> struct regulator *vdds_dsi_reg;
>
> + struct mipi_dsi_device *dsidev;
> +
> struct {
> enum dsi_vc_source source;
> - struct mipi_dsi_device *dest;
> enum fifo_size tx_fifo_size;
> enum fifo_size rx_fifo_size;
> } vc[4];
> @@ -452,6 +453,8 @@ static bool dsi_perf;
> module_param(dsi_perf, bool, 0644);
> #endif
>
> +#define VC_DEFAULT 0
> +
> #define drm_bridge_to_dsi(bridge) \
> container_of(bridge, struct dsi_data, bridge)
>
> @@ -3716,16 +3719,11 @@ static void dsi_disable_video_output(struct
> omap_dss_device *dssdev, int channel
> static void dsi_disable_video_outputs(struct omap_dss_device *dssdev)
> {
> struct dsi_data *dsi = to_dsi_data(dssdev);
> - unsigned int i;
>
> dsi_bus_lock(dsi);
> dsi->video_enabled = false;
>
> - for (i = 0; i < 4; i++) {
> - if (!dsi->vc[i].dest)
> - continue;
> - dsi_disable_video_output(dssdev, i);
> - }
> + dsi_disable_video_output(dssdev, VC_DEFAULT);
>
> dsi_display_disable(dssdev);
>
> @@ -3914,11 +3912,6 @@ static int dsi_update_channel(struct omap_dss_device
> *dssdev, int channel)
> goto err;
> }
>
> - if (!dsi->vc[channel].dest) {
> - r = -ENODEV;
> - goto err;
> - }
> -
> if (dsi->vm.hactive == 0 || dsi->vm.vactive == 0) {
> r = -EINVAL;
> goto err;
> @@ -3954,16 +3947,7 @@ static int dsi_update_channel(struct omap_dss_device
> *dssdev, int channel)
>
> static int dsi_update_all(struct omap_dss_device *dssdev)
> {
> - unsigned int i;
> - int r;
> -
> - for (i = 0; i < 4; i++) {
> - r = dsi_update_channel(dssdev, i);
> - if (r && r != -ENODEV)
> - return r;
> - }
> -
> - return r;
> + return dsi_update_channel(dssdev, VC_DEFAULT);
> }
>
> /* Display funcs */
> @@ -4191,17 +4175,12 @@ static void dsi_display_enable(struct omap_dss_device
> *dssdev)
> static void dsi_enable_video_outputs(struct omap_dss_device *dssdev)
> {
> struct dsi_data *dsi = to_dsi_data(dssdev);
> - unsigned int i;
>
> dsi_bus_lock(dsi);
>
> dsi_display_enable(dssdev);
>
> - for (i = 0; i < 4; i++) {
> - if (!dsi->vc[i].dest)
> - continue;
> - dsi_enable_video_output(dssdev, i);
> - }
> + dsi_enable_video_output(dssdev, VC_DEFAULT);
>
> dsi->video_enabled = true;
>
> @@ -5090,8 +5069,8 @@ static int omap_dsi_host_attach(struct mipi_dsi_host
> *host,
> if (channel > 3)
> return -EINVAL;
>
> - if (dsi->vc[channel].dest) {
> - DSSERR("cannot get VC for display %s", dev_name(&client->dev));
> + if (dsi->dsidev) {
> + DSSERR("dsi client already attached\n");
> return -EBUSY;
> }
>
> @@ -5112,7 +5091,7 @@ static int omap_dsi_host_attach(struct mipi_dsi_host
> *host,
> dsi->mode = OMAP_DSS_DSI_CMD_MODE;
> }
>
> - dsi->vc[channel].dest = client;
> + dsi->dsidev = client;
> dsi->pix_fmt = client->format;
>
> INIT_DEFERRABLE_WORK(&dsi->ulps_work,
> @@ -5144,11 +5123,11 @@ static int omap_dsi_host_detach(struct mipi_dsi_host
> *host,
> if (channel > 3)
> return -EINVAL;
>
> - if (dsi->vc[channel].dest != client)
> + if (WARN_ON(dsi->dsidev != client))
> return -EINVAL;
>
> omap_dsi_unregister_te_irq(dsi);
> - dsi->vc[channel].dest = NULL;
> + dsi->dsidev = NULL;
> return 0;
> }
>
> @@ -5680,10 +5659,8 @@ static int dsi_probe(struct platform_device *pdev)
> }
>
> /* DSI VCs initialization */
> - for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
> + for (i = 0; i < ARRAY_SIZE(dsi->vc); i++)
> dsi->vc[i].source = D
Re: [PATCH RESEND v3 1/2] dt-bindings: dp-connector: add binding for DisplayPort connector
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 09:11:54AM +0200, Tomi Valkeinen wrote:
> Add binding for DisplayPort connector. A few notes:
>
> * Similar to hdmi-connector, it has hpd-gpios as an optional property,
> as the HPD could also be handled by, e.g., the DP bridge.
>
> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
> is not strictly required: standard DP cables do not even have the pin
> connected.
>
> * Connector type. Full size and mini connectors are identical except for
> the connector size and form, so I believe there is no functional need
> for this property. But similar to 'label' property, it might be used
> to present information about the connector to the userspace.
>
> * No eDP. There's really no "eDP connector", as it's always a custom
> made connection between the DP and the DP panel, although the eDP spec
> does offer a few suggested pin setups. So possibly there is no need for
> edp-connector binding, but even if there is, I don't want to guess what
> it could look like, and could it be part of the dp-connector binding.
>
> * No DP++. I'm not familiar with DP++. DP++ might need an i2c bus added
> to the bindings.
>
> Signed-off-by: Tomi Valkeinen
> Cc: Rob Herring
> ---
> .../display/connector/dp-connector.yaml | 55 +++
> 1 file changed, 55 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/connector/dp-connector.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> new file mode 100644
> index ..b5fc3e52899e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DisplayPort Connector
> +
> +maintainers:
> + - Tomi Valkeinen
> +
> +properties:
> + compatible:
> +const: dp-connector
> +
> + label: true
> +
> + type:
> +enum:
> + - full-size
> + - mini
I wonder if "full" would be better than "full-size" to match "mini". Up
to you.
> +
> + hpd-gpios:
> +description: A GPIO line connected to HPD
> +maxItems: 1
> +
> + dp-pwr-supply:
> +description: Power supply for the DP_PWR pin
> +maxItems: 1
> +
> + port:
> +description: Connection to controller providing DP signals
Now that the OF graph schema has landed, could you add the corresponding
$ref ?
Reviewed-by: Laurent Pinchart
> +
> +required:
> + - compatible
> + - type
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +connector {
> +compatible = "dp-connector";
> +label = "dp0";
> +type = "full-size";
> +
> +port {
> +dp_connector_in: endpoint {
> +remote-endpoint = <&dp_out>;
> +};
> +};
> +};
> +
> +...
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/28] video: fbdev: sis: Fix set but not used warnings in sis_main
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix warnings by dropping unused variable and the
unused assignments.
v2:
- Update subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/sis/sis_main.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index 03c736f6f3d0..266a5582f94d 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -5029,7 +5029,6 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
static const u8 cs168[8] = {
0x48, 0x78, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00
};
- u8 reg;
u8 v1;
u8 v2;
u8 v3;
@@ -5037,9 +5036,9 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
SiS_SetReg(SISCR, 0xb0, 0x80); /* DDR2 dual frequency mode */
SiS_SetReg(SISCR, 0x82, 0x77);
SiS_SetReg(SISCR, 0x86, 0x00);
- reg = SiS_GetReg(SISCR, 0x86);
+ SiS_GetReg(SISCR, 0x86);
SiS_SetReg(SISCR, 0x86, 0x88);
- reg = SiS_GetReg(SISCR, 0x86);
+ SiS_GetReg(SISCR, 0x86);
v1 = cs168[regb]; v2 = cs160[regb]; v3 = cs158[regb];
if (ivideo->haveXGIROM) {
v1 = bios[regb + 0x168];
@@ -5049,9 +5048,9 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
SiS_SetReg(SISCR, 0x86, v1);
SiS_SetReg(SISCR, 0x82, 0x77);
SiS_SetReg(SISCR, 0x85, 0x00);
- reg = SiS_GetReg(SISCR, 0x85);
+ SiS_GetReg(SISCR, 0x85);
SiS_SetReg(SISCR, 0x85, 0x88);
- reg = SiS_GetReg(SISCR, 0x85);
+ SiS_GetReg(SISCR, 0x85);
SiS_SetReg(SISCR, 0x85, v2);
SiS_SetReg(SISCR, 0x82, v3);
SiS_SetReg(SISCR, 0x98, 0x01);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 096/162] drm/i915: setup the LMEM region
On Fri, 27 Nov 2020, Matthew Auld wrote: > + /* Enables Local Memory functionality in GAM */ > + I915_WRITE(GEN12_LMEM_CFG_ADDR, I915_READ(GEN12_LMEM_CFG_ADDR) | > LMEM_ENABLE); Please use intel_uncore_read/write and intel_de_read/write throughout the series. We don't want any new users of I915_READ/I915_WRITE in the driver. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 119/162] drm/i915/dg1: Read OPROM via SPI controller
On Fri, 27 Nov 2020, Matthew Auld wrote:
> + DRM_DEBUG_KMS("Found valid VBT in SPI flash\n");
Please use drm_dbg_kms() and friends throughout the series. We don't
want new users of DRM_DEBUG* in the driver.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v3 2/2] drm/bridge: display-connector: add DP support
Hi Tomi,
Thank you for the patch.
On Tue, Nov 24, 2020 at 09:11:55AM +0200, Tomi Valkeinen wrote:
> Add DP support to display-connector driver. The driver will support HPD
> via a GPIO and DP PWR.
>
> DP PWR will be enabled at probe, which is not optimal, but I'm not sure
> what would be a good place to enable and disable DP PWR. Perhaps
> attach/detach, but I don't know if enabling HW is something that attach
> is supposed to do.
>
> In any case, I don't think there's much difference in power consumption
> between the version in this patch and enabling the regulator later: if
> the driver probes, supposedly it will attach very soon afterwards, and
> we need to enable the DP PWR as soon as possible.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/display-connector.c | 46 +-
> 1 file changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c
> b/drivers/gpu/drm/bridge/display-connector.c
> index 4d278573cdb9..04362feccd75 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -20,6 +21,8 @@ struct display_connector {
>
> struct gpio_desc*hpd_gpio;
> int hpd_irq;
> +
> + struct regulator*dp_pwr;
> };
>
> static inline struct display_connector *
> @@ -172,11 +175,12 @@ static int display_connector_probe(struct
> platform_device *pdev)
> of_property_read_string(pdev->dev.of_node, "label", &label);
>
> /*
> - * Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> + * Get the HPD GPIO for DVI, HDMI and DP connectors. If the GPIO can
> provide
>* edge interrupts, register an interrupt handler.
>*/
> if (type == DRM_MODE_CONNECTOR_DVII ||
> - type == DRM_MODE_CONNECTOR_HDMIA) {
> + type == DRM_MODE_CONNECTOR_HDMIA ||
> + type == DRM_MODE_CONNECTOR_DisplayPort) {
> conn->hpd_gpio = devm_gpiod_get_optional(&pdev->dev, "hpd",
>GPIOD_IN);
> if (IS_ERR(conn->hpd_gpio)) {
> @@ -223,6 +227,38 @@ static int display_connector_probe(struct
> platform_device *pdev)
> }
> }
>
> + /* Get the DP PWR for DP connector */
s/connector/connector./
> + if (type == DRM_MODE_CONNECTOR_DisplayPort) {
> + int r;
The driver uses "ret".
Reviewed-by: Laurent Pinchart
> +
> + conn->dp_pwr = devm_regulator_get_optional(&pdev->dev,
> "dp-pwr");
> +
> + if (IS_ERR(conn->dp_pwr)) {
> + r = PTR_ERR(conn->dp_pwr);
> +
> + switch (r) {
> + case -ENODEV:
> + conn->dp_pwr = NULL;
> + break;
> +
> + case -EPROBE_DEFER:
> + return -EPROBE_DEFER;
> +
> + default:
> + dev_err(&pdev->dev, "failed to get DP PWR
> regulator: %d\n", r);
> + return r;
> + }
> + }
> +
> + if (conn->dp_pwr) {
> + r = regulator_enable(conn->dp_pwr);
> + if (r) {
> + dev_err(&pdev->dev, "failed to enable DP PWR
> regulator: %d\n", r);
> + return r;
> + }
> + }
> + }
> +
> conn->bridge.funcs = &display_connector_bridge_funcs;
> conn->bridge.of_node = pdev->dev.of_node;
>
> @@ -251,6 +287,9 @@ static int display_connector_remove(struct
> platform_device *pdev)
> {
> struct display_connector *conn = platform_get_drvdata(pdev);
>
> + if (conn->dp_pwr)
> + regulator_disable(conn->dp_pwr);
> +
> drm_bridge_remove(&conn->bridge);
>
> if (!IS_ERR(conn->bridge.ddc))
> @@ -275,6 +314,9 @@ static const struct of_device_id
> display_connector_match[] = {
> }, {
> .compatible = "vga-connector",
> .data = (void *)DRM_MODE_CONNECTOR_VGA,
> + }, {
> + .compatible = "dp-connector",
> + .data = (void *)DRM_MODE_CONNECTOR_DisplayPort,
> },
> {},
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
On Monday, November 30, 2020 2:03 AM, Leandro Ribeiro wrote: > In userspace we can use drmGetConnector() or drmGetConnectorCurrent() in > order to retrieve connector information. The difference between both is > that the former retrieves the complete set of modes and encoders > associated with the connector, while the latter only retrieves the > currently known set of modes and encoders - but is much faster. > > This performance improvement is the reason why userspace applications > may prefer to use drmGetConnectorCurrent() when they need to retrieve > information from a device. We discussed with Daniel Vetter and it turns out user-space should always use drmGetConnector(). See [1]. [1]: https://lists.freedesktop.org/archives/dri-devel/2020-November/289506.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 120/162] drm/i915/oprom: Basic sanitization
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: Anshuman Gupta
>
> Sanitize OPROM header, CPD signature and OPROM PCI version.
> OPROM_HEADER, EXPANSION_ROM_HEADER and OPROM_MEU_BLOB structures
> and PCI struct offsets are provided by GSC counterparts.
> These are yet to be Documented in B.Spec.
> After successful sanitization, extract VBT from opregion
> image.
Comments inline.
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Uma Shankar
> Cc: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 49 +++--
> drivers/gpu/drm/i915/display/intel_opregion.c | 169 ++
> drivers/gpu/drm/i915/display/intel_opregion.h | 31 +++-
> 3 files changed, 221 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 91044fc52acb..358576bc0be2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2088,37 +2088,36 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
> size)
>
> static struct vbt_header *spi_oprom_get_vbt(struct drm_i915_private
> *dev_priv)
> {
> - u32 count, data, found, store = 0;
> - u32 static_region, oprom_offset;
> - u32 oprom_size = 0x20;
> - u16 vbt_size;
> - u32 *vbt;
> -
> - static_region = I915_READ(SPI_STATIC_REGIONS);
> - static_region &= OPTIONROM_SPI_REGIONID_MASK;
> - I915_WRITE(PRIMARY_SPI_REGIONID, static_region);
> + u32 count, found;
> + u32 *vbt, *oprom_opreg = NULL;
> + u16 vbt_size, opreg_size;
> + u8 *parse_ptr;
>
> - oprom_offset = I915_READ(OROM_OFFSET);
> - oprom_offset &= OROM_OFFSET_MASK;
> + if (intel_oprom_verify_signature(&oprom_opreg, &opreg_size, dev_priv)) {
> + drm_err(&dev_priv->drm, "oprom signature verification
> failed\n");
> + goto err_not_found;
> + }
Kind of silly that the previous patch adds all the reading here, and
then it gets moved into a function called "verify signature". Which
looks like it verifies the signature, but it actually reads the
SPI. Very confusing.
>
> - for (count = 0; count < oprom_size; count += 4) {
> - I915_WRITE(PRIMARY_SPI_ADDRESS, oprom_offset + count);
> - data = I915_READ(PRIMARY_SPI_TRIGGER);
> + if (!oprom_opreg) {
> + drm_err(&dev_priv->drm, "opregion not found\n");
> + goto err_not_found;
> + }
>
> - if (data == *((const u32 *)"$VBT")) {
> - found = oprom_offset + count;
> + for (count = 0; count < opreg_size; count += 4) {
> + if (oprom_opreg[count / 4] == *((const u32 *)"$VBT")) {
> + found = count;
> break;
> }
> }
>
> - if (count >= oprom_size)
> + if (count >= opreg_size) {
> + drm_err(&dev_priv->drm, "VBT not found in opregion\n");
> goto err_not_found;
> + }
>
> /* Get VBT size and allocate space for the VBT */
> - I915_WRITE(PRIMARY_SPI_ADDRESS, found +
> -offsetof(struct vbt_header, vbt_size));
> - vbt_size = I915_READ(PRIMARY_SPI_TRIGGER);
> - vbt_size &= 0x;
> + parse_ptr = (u8 *)oprom_opreg + found;
> + vbt_size = ((struct vbt_header *)parse_ptr)->vbt_size;
>
> vbt = kzalloc(vbt_size, GFP_KERNEL);
> if (!vbt) {
> @@ -2127,16 +2126,12 @@ static struct vbt_header *spi_oprom_get_vbt(struct
> drm_i915_private *dev_priv)
> goto err_not_found;
> }
>
> - for (count = 0; count < vbt_size; count += 4) {
> - I915_WRITE(PRIMARY_SPI_ADDRESS, found + count);
> - data = I915_READ(PRIMARY_SPI_TRIGGER);
> - *(vbt + store++) = data;
> - }
> -
> + memcpy(vbt, parse_ptr, vbt_size);
> if (!intel_bios_is_valid_vbt(vbt, vbt_size))
> goto err_free_vbt;
>
> DRM_DEBUG_KMS("Found valid VBT in SPI flash\n");
> + kfree(oprom_opreg);
>
> return (struct vbt_header *)vbt;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 4f77cf849171..81e5946393dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -983,6 +983,175 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> return err;
> }
>
> +static int oprom_image_parse_helper(u8 *parse_ptr, u8 *last_img, u8
> *code_type,
> + struct drm_i915_private *i915)
> +{
> + u8 size_512_bytes;
> +
> + if (((union oprom_header *)parse_ptr)->signature != OPROM_IMAGE_MAGIC) {
> + drm_err(&i915->drm, "Wrong OPROM header signature.\n");
> + return -EINVAL;
> + }
> +
> + size_512_bytes = parse_ptr[((struct expansion_rom_header
> *)parse_ptr)->pcistructoffset + PCI_IMAGE_LENGTH_OFFSET];
> + *co
Re: [RESEND PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
On 17-11-20, 07:14, Chun-Kuang Hu wrote: > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's > more suitable to place a phy driver into phy driver folder, so move > mtk_mipi_dsi_phy driver into phy driver folder. Acked-By: Vinod Koul I am thinking this would go thru drm-tree, if not let me know I would apply this -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm/tidss: Set bus_format correctly from bridge/connector
On 14:51-20201125, Tomi Valkeinen wrote: > Hi Nikhil, > > On 19/11/2020 18:01, Nikhil Devshatwar wrote: > > Remove the old code to iterate over the bridge chain, as this is > > already done by the framework. > > The bridge state should have the negotiated bus format and flags. > > Use these from the bridge's state. > > If the bridge does not support format negotiation, error out > > and fail. > > > > Signed-off-by: Nikhil Devshatwar > > Reviewed-by: Tomi Valkeinen > > --- > > > > Notes: > > changes from v2: > > * Remove the old code and use the flags from the bridge state > > > > drivers/gpu/drm/tidss/tidss_encoder.c | 36 +++ > > 1 file changed, 14 insertions(+), 22 deletions(-) > > If a first bridge (after the crtc) supports two bus formats as input, how > does tidss choose between > those? This patch just picks bstate->input_bus_cfg.format, and it's not clear > to me which one that > is (the first one?). Also, we don't check if tidss actually supports the bus > format. The selection is done by the framework in select_bus_fmt_recursive at drivers/gpu/drm/drm_bridge.c:810 My understanding is that currently, the format negotiation logic does not negotiate all the way till encoder, it stops only at the first_bridge. Nikhil Devshatwar > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 157/162] drm/i915: Improve accuracy of eviction stats
On 27/11/2020 14:40, Chris Wilson wrote: Quoting Matthew Auld (2020-11-27 12:07:13) From: Tvrtko Ursulin Current code uses jiffie time to do the accounting and then does: diff = jiffies - start; msec = diff * 1000 / HZ; ... atomic_long_add(msec, &i915->time_swap_out_ms); If we assume jiffie can be as non-granular as 10ms and that the current accounting records all evictions faster than one jiffie as infinite speed, we can end up over-estimating the reported eviction throughput. Fix this by accumulating ktime_t and only dividing to more user friendly granularity at presentation time (debugfs read). At the same time consolidate the code a bit and convert from multiple atomics to single seqlock per stat. Signed-off-by: Tvrtko Ursulin Cc: CQ Tang Cc: Sudeep Dutt Cc: Mika Kuoppala A lot of effort to fix up patches after the fact, might as well make it a real PMU interface. It did cross my mind and should be easy to add on top if deemed useful or interesting. More importantly, it is okay with me to incorporate this patch into the earlier one(s) which first added statistics. Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm: add legacy support for using degamma for gamma
Hi Tomi,
Thank you for the patch.
On Tue, Nov 03, 2020 at 10:03:06AM +0200, Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we have either:
>
> degamma -> ctm -> gamma -> out
>
> or
>
> ctm -> gamma -> out
>
> However, if the HW has gamma table before ctm, the atomic property
> should be DEGAMMA_LUT, and thus we have:
>
> degamma -> ctm -> out
>
> This is fine for userspace which sets gamma table using the properties,
> as the userspace can check for the existence of gamma & degamma, but the
> legacy gamma-set ioctl does not work.
>
> This patch adds a new helper, drm_atomic_helper_legacy_degamma_set(),
> which can be used instead of drm_atomic_helper_legacy_gamma_set() when
> the DEGAMMA_LUT is the underlying property that needs to be set.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Pekka Paalanen
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 81 ++---
> include/drm/drm_atomic_helper.h | 4 ++
> 2 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ddd0e3239150..23cbed541dc7 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3499,24 +3499,11 @@ int drm_atomic_helper_page_flip_target(struct
> drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>
> -/**
> - * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction table
> - * @crtc: CRTC object
> - * @red: red correction table
> - * @green: green correction table
> - * @blue: green correction table
> - * @size: size of the tables
> - * @ctx: lock acquire context
> - *
> - * Implements support for legacy gamma correction table for drivers
> - * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> - * 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,
> -uint32_t size,
> -struct drm_modeset_acquire_ctx *ctx)
> +static int legacy_gamma_degamma_set(struct drm_crtc *crtc,
> + u16 *red, u16 *green, u16 *blue,
> + uint32_t size,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool use_degamma)
> {
> struct drm_device *dev = crtc->dev;
> struct drm_atomic_state *state;
> @@ -3555,9 +3542,11 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> }
>
> /* Reset DEGAMMA_LUT and CTM properties. */
> - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
> + use_degamma ? blob : NULL);
> replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
> + use_degamma ? NULL : blob);
> crtc_state->color_mgmt_changed |= replaced;
>
> ret = drm_atomic_commit(state);
> @@ -3567,8 +3556,60 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> drm_property_blob_put(blob);
> return ret;
> }
> +
> +/**
> + * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction
> table using gamma_lut
> + * @crtc: CRTC object
> + * @red: red correction table
> + * @green: green correction table
> + * @blue: green correction table
> + * @size: size of the tables
> + * @ctx: lock acquire context
> + *
> + * Implements support for legacy gamma correction table for drivers
> + * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> + * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> for
> + * how the atomic color management and gamma tables work.
> + *
> + * This function uses GAMMA_LUT property for the gamma table. This function
s/uses/uses the/
s/This function$/It/
Same below.
> + * can be used when the driver exposes either only GAMMA_LUT or both
> GAMMA_LUT
> + * and DEGAMMA_LUT.
> + */
> +int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> +u16 *red, u16 *green, u16 *blue,
> +uint32_t size,
> +struct drm_modeset_acquire_ctx *ctx)
> +{
> + return legacy_gamma_degamma_set(crtc, red, green, blue, size, ctx,
> false);
> +}
I wonder, would
Re: [PATCH v2 2/5] drm/omap: use degamma property for gamma table
Hi Tomi,
Thank you for the patch.
On Tue, Nov 03, 2020 at 10:03:07AM +0200, Tomi Valkeinen wrote:
> omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
> is:
>
> gamma -> ctm -> out
>
> instead of what the model DRM framework uses:
>
> ctm -> gamma -> out
>
> As the following patches add CTM support for omapdrm, lets first fix the
> gamma.
>
> This patch changes the property from GAMMA_LUT to DEGAMMA_LUT, and uses
> drm_atomic_helper_legacy_degamma_set for gamma_set helper. Thus we will
> have:
>
> degamma -> ctm -> out
>
> and the legacy ioctl will continue working as before.
>
> Signed-off-by: Tomi Valkeinen
> Reviewed-by: Pekka Paalanen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index d7442aa55f89..d40220b2f312 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -575,8 +575,8 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> crtc);
> struct drm_plane_state *pri_state;
>
> - if (crtc_state->color_mgmt_changed && crtc_state->gamma_lut) {
> - unsigned int length = crtc_state->gamma_lut->length /
> + if (crtc_state->color_mgmt_changed && crtc_state->degamma_lut) {
> + unsigned int length = crtc_state->degamma_lut->length /
> sizeof(struct drm_color_lut);
>
> if (length < 2)
> @@ -617,10 +617,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> *crtc,
> struct drm_color_lut *lut = NULL;
> unsigned int length = 0;
>
> - if (crtc->state->gamma_lut) {
> + if (crtc->state->degamma_lut) {
> lut = (struct drm_color_lut *)
> - crtc->state->gamma_lut->data;
> - length = crtc->state->gamma_lut->length /
> + crtc->state->degamma_lut->data;
> + length = crtc->state->degamma_lut->length /
> sizeof(*lut);
> }
> priv->dispc_ops->mgr_set_gamma(priv->dispc, omap_crtc->channel,
> @@ -741,7 +741,7 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .destroy = omap_crtc_destroy,
> .page_flip = drm_atomic_helper_page_flip,
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
> + .gamma_set = drm_atomic_helper_legacy_degamma_set,
> .atomic_duplicate_state = omap_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .atomic_set_property = omap_crtc_atomic_set_property,
> @@ -842,7 +842,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
> unsigned int gamma_lut_size = 256;
>
> - drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
> + drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
> drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
> }
>
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
Hi Tomi and Jyri,
Thank you for the patch.
On Tue, Nov 03, 2020 at 10:03:08AM +0200, Tomi Valkeinen wrote:
> From: Jyri Sarha
>
> Implement CTM color management property for OMAP CRTC using DSS
> overlay manager's Color Phase Rotation matrix. The CPR matrix does not
> exactly match the CTM property documentation. On DSS the CPR matrix is
> applied after gamma table look up. However, it seems stupid to add a
> custom property just for that.
Should this be updated now that the driver has switched to using degamma
?
> Signed-off-by: Jyri Sarha
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index d40220b2f312..b2c251a8b404 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -391,6 +391,33 @@ static void omap_crtc_manual_display_update(struct
> work_struct *data)
> }
> }
>
> +static s16 omap_crtc_s31_32_to_s2_8(s64 coef)
> +{
> + u64 sign_bit = 1ULL << 63;
> + u64 cbits = (u64)coef;
> +
> + s16 ret = clamp_val(((cbits & ~sign_bit) >> 24), 0, 0x1ff);
> +
> + if (cbits & sign_bit)
> + ret = -ret;
> +
> + return ret;
> +}
> +
> +static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
> + struct omap_dss_cpr_coefs *cpr)
> +{
> + cpr->rr = omap_crtc_s31_32_to_s2_8(ctm->matrix[0]);
> + cpr->rg = omap_crtc_s31_32_to_s2_8(ctm->matrix[1]);
> + cpr->rb = omap_crtc_s31_32_to_s2_8(ctm->matrix[2]);
> + cpr->gr = omap_crtc_s31_32_to_s2_8(ctm->matrix[3]);
> + cpr->gg = omap_crtc_s31_32_to_s2_8(ctm->matrix[4]);
> + cpr->gb = omap_crtc_s31_32_to_s2_8(ctm->matrix[5]);
> + cpr->br = omap_crtc_s31_32_to_s2_8(ctm->matrix[6]);
> + cpr->bg = omap_crtc_s31_32_to_s2_8(ctm->matrix[7]);
> + cpr->bb = omap_crtc_s31_32_to_s2_8(ctm->matrix[8]);
> +}
> +
> static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
> {
> struct omap_drm_private *priv = crtc->dev->dev_private;
> @@ -402,7 +429,15 @@ static void omap_crtc_write_crtc_properties(struct
> drm_crtc *crtc)
> info.default_color = 0x00;
> info.trans_enabled = false;
> info.partial_alpha_enabled = false;
> - info.cpr_enable = false;
> +
> + if (crtc->state->ctm) {
> + struct drm_color_ctm *ctm = crtc->state->ctm->data;
> +
> + info.cpr_enable = true;
> + omap_crtc_cpr_coefs_from_ctm(ctm, &info.cpr_coefs);
> + } else {
> + info.cpr_enable = false;
> + }
>
> priv->dispc_ops->mgr_setup(priv->dispc, omap_crtc->channel, &info);
> }
> @@ -842,7 +877,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
> unsigned int gamma_lut_size = 256;
>
> - drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
> + drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, true, 0);
> drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
> }
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/omap: rearrange includes in omapdss.h
Hi Tomi, Thank you for the patch. On Tue, Nov 03, 2020 at 10:03:09AM +0200, Tomi Valkeinen wrote: > Drop "uapi/" and rearrange alphabetically. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h > b/drivers/gpu/drm/omapdrm/dss/omapdss.h > index ab19d4af8de7..8e9a2019f173 100644 > --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h > +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h > @@ -7,13 +7,13 @@ > #ifndef __OMAP_DRM_DSS_H > #define __OMAP_DRM_DSS_H > > -#include > +#include > +#include > #include > #include > -#include > +#include > #include > -#include > -#include > +#include > > #define DISPC_IRQ_FRAMEDONE (1 << 0) > #define DISPC_IRQ_VSYNC (1 << 1) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Hi Tomi and Jyri,
Thank you for the patch.
On Tue, Nov 03, 2020 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> From: Jyri Sarha
>
> Adds support for COLOR_ENCODING and COLOR_RANGE properties to
> omap_plane.c and dispc.c. The supported encodings and ranges are
> presets are:
>
> For COLOR_ENCODING:
> - YCbCr BT.601 (default)
> - YCbCr BT.709
>
> For COLOR_RANGE:
> - YCbCr limited range
> - YCbCr full range (default)
>
> Signed-off-by: Jyri Sarha
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 104 --
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
> drivers/gpu/drm/omapdrm/omap_plane.c | 30
> 3 files changed, 97 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 48593932bddf..bf0c9d293077 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -874,50 +874,67 @@ static void dispc_ovl_write_color_conv_coef(struct
> dispc_device *dispc,
> #undef CVAL
> }
>
> -static void dispc_wb_write_color_conv_coef(struct dispc_device *dispc,
> -const struct csc_coef_rgb2yuv *ct)
> -{
> - const enum omap_plane_id plane = OMAP_DSS_WB;
> -
> -#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> +/* YUV -> RGB, ITU-R BT.601, full range */
> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
> + 256, 0, 358, /* ry, rcb, rcr |1.000 0.000 1.402|*/
> + 256, -88, -182, /* gy, gcb, gcr |1.000 -0.344 -0.714|*/
> + 256, 452,0, /* by, bcb, bcr |1.000 1.772 0.000|*/
> + true, /* full range */
> +};
>
> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,
> ct->yr));
> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr,
> ct->yb));
> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb,
> ct->crg));
> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg,
> ct->cbr));
> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
> +/* YUV -> RGB, ITU-R BT.601, limited range */
> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> + 298,0, 409,/* ry, rcb, rcr |1.164 0.000 1.596|*/
> + 298, -100, -208,/* gy, gcb, gcr |1.164 -0.392 -0.813|*/
> + 298, 516,0,/* by, bcb, bcr |1.164 2.017 0.000|*/
> + false, /* limited range */
> +};
>
> - REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
> +/* YUV -> RGB, ITU-R BT.709, full range */
> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_full = {
> + 256,0, 402,/* ry, rcb, rcr |1.000 0.000 1.570|*/
> + 256, -48, -120,/* gy, gcb, gcr |1.000 -0.187 -0.467|*/
> + 256, 475,0,/* by, bcb, bcr |1.000 1.856 0.000|*/
> + true, /* full range */
> +};
>
> -#undef CVAL
> -}
> +/* YUV -> RGB, ITU-R BT.709, limited range */
> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_lim = {
> + 298,0, 459,/* ry, rcb, rcr |1.164 0.000 1.793|*/
> + 298, -55, -136,/* gy, gcb, gcr |1.164 -0.213 -0.533|*/
> + 298, 541,0,/* by, bcb, bcr |1.164 2.112 0.000|*/
> + false, /* limited range */
> +};
>
> -static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
> +static int dispc_ovl_set_csc(struct dispc_device *dispc,
> + enum omap_plane_id plane,
> + enum drm_color_encoding color_encoding,
> + enum drm_color_range color_range)
> {
> - int i;
> - int num_ovl = dispc_get_num_ovls(dispc);
> -
> - /* YUV -> RGB, ITU-R BT.601, limited range */
> - const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> - 298,0, 409,/* ry, rcb, rcr */
> - 298, -100, -208,/* gy, gcb, gcr */
> - 298, 516,0,/* by, bcb, bcr */
> - false, /* limited range */
> - };
> + const struct csc_coef_yuv2rgb *csc;
>
> - /* RGB -> YUV, ITU-R BT.601, limited range */
> - const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
> - 66, 129, 25, /* yr, yg, yb */
> - -38, -74, 112, /* cbr, cbg, cbb */
> - 112, -94, -18, /* crr, crg, crb */
> - false, /* limited range */
> - };
> + switch (color_encoding) {
> + case DRM_COLOR_YCBCR_BT601:
> + if (color_range == DRM_COLOR_YCBCR_FULL_RANGE)
> + csc = &coefs_yuv2rgb_bt601_full;
> + else
> + csc = &coefs_yuv2rgb_bt601_lim;
> + break;
> + case DRM_COLOR_YCBCR_BT709:
> + if (color_range
Re: [Intel-gfx] [RFC PATCH 118/162] drm/i915/dg1: Reserve first 1MB of local memory
On 27/11/2020 13:52, Chris Wilson wrote:
Quoting Matthew Auld (2020-11-27 12:06:34)
From: Imre Deak
On DG1 A0/B0 steppings the first 1MB of local memory must be reserved.
One reason for this is that the 0xA-0xB range is not accessible
by the display, probably since this region is redirected to another
memory location for legacy VGA compatibility.
BSpec: 50586
Testcase: igt/kms_big_fb/linear-64bpp-rotate-0
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_region_lmem.c | 52
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
index 939cf0d195a5..eafef7034680 100644
--- a/drivers/gpu/drm/i915/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/intel_region_lmem.c
@@ -137,6 +137,48 @@ intel_setup_fake_lmem(struct drm_i915_private *i915)
return mem;
}
+static void get_legacy_lowmem_region(struct intel_uncore *uncore,
+u64 *start, u32 *size)
+{
+ *start = 0;
+ *size = 0;
+
+ if (!IS_DG1_REVID(uncore->i915, DG1_REVID_A0, DG1_REVID_B0))
+ return;
+
+ *size = SZ_1M;
+
+ DRM_DEBUG_DRIVER("LMEM: reserved legacy low-memory [0x%llx-0x%llx]\n",
+*start, *start + *size);
+}
+
+static int reserve_lowmem_region(struct intel_uncore *uncore,
+struct intel_memory_region *mem)
+{
+ u64 reserve_start;
+ u64 reserve_end;
+ u64 region_start;
+ u32 region_size;
+ int ret;
+
+ get_legacy_lowmem_region(uncore, ®ion_start, ®ion_size);
+ reserve_start = region_start;
+ reserve_end = region_start + region_size;
+
+ if (!reserve_end)
+ return 0;
+
+ DRM_INFO("LMEM: reserving low-memory region [0x%llx-0x%llx]\n",
+reserve_start, reserve_end);
+ ret = i915_buddy_alloc_range(&mem->mm, &mem->reserved,
+reserve_start,
+reserve_end - reserve_start);
Isn't this now relative to the stolen offset? Should this be reserved,
or excluded like stolen?
AFAIK stolen is just snipped off at the end of lmem, so I don't think it
really matters if we exclude or reserve. But for this if we exclude then
the region.start might have "strange" alignment, which is annoying since
alloc(some_power_of_two) might not give us the expected alignment,
whereas if we reserve then the allocator is aware, and so we should get
the proper alignment. Maybe you have better ideas with how to handle
this, but I think keeping the alignment property is nice.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
On Mon, 30 Nov 2020 10:23:04 + Simon Ser wrote: > On Monday, November 30, 2020 2:03 AM, Leandro Ribeiro > wrote: > > > In userspace we can use drmGetConnector() or drmGetConnectorCurrent() in > > order to retrieve connector information. The difference between both is > > that the former retrieves the complete set of modes and encoders > > associated with the connector, while the latter only retrieves the > > currently known set of modes and encoders - but is much faster. > > > > This performance improvement is the reason why userspace applications > > may prefer to use drmGetConnectorCurrent() when they need to retrieve > > information from a device. > > We discussed with Daniel Vetter and it turns out user-space should > always use drmGetConnector(). See [1]. Hi, where is the discussion? > [1]: > https://lists.freedesktop.org/archives/dri-devel/2020-November/289506.html Please record the justitication for that patch in its commit message. "Can't" does not explain anything. Thanks, pq pgpe6Gacis55n.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
On Monday, November 30, 2020 12:13 PM, Pekka Paalanen wrote: > where is the discussion? https://dri.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&date=2020-11-26 > Please record the justitication for that patch in its commit message. > "Can't" does not explain anything. Yeah, sorry about that. I'm just annoyed by all of this get_connector uAPI, so I don't really want to spend a lot of time documenting why it's so gross. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 107/162] drm/i915: setup GPU device lmem region
Quoting Matthew Auld (2020-11-27 12:06:23)
> From: CQ Tang
>
> The lmem region needs to remove the stolen part.
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Chris P Wilson
> Cc: Balestrieri, Francesco
> Cc: Niranjana Vishwanathapura
> Cc: Venkata S Dhanalakota
> Cc: Neel Desai
> Cc: Matthew Brost
> Cc: Sudeep Dutt
> Signed-off-by: CQ Tang
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_region_lmem.c | 11 +++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1af1966ac461..0e01ea0cb0a4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -12066,6 +12066,8 @@ enum skl_power_gate {
> #define GEN12_LMEM_CFG_ADDR_MMIO(0xcf58)
> #define LMEM_ENABLE (1 << 31)
>
> +#define GEN12_GSMBASE _MMIO(0x108100)
> +
> /* gamt regs */
> #define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
> #define GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW 0x67F1427F /* max/min for
> LRA1/2 */
> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
> b/drivers/gpu/drm/i915/intel_region_lmem.c
> index e98582c76de1..7f2b31d469b0 100644
> --- a/drivers/gpu/drm/i915/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> @@ -140,20 +140,23 @@ intel_setup_fake_lmem(struct drm_i915_private *i915)
> static struct intel_memory_region *
> setup_lmem(struct drm_i915_private *dev_priv)
Am I wrong in thinking lmem should be under gt?
> {
> + struct intel_uncore *uncore = &dev_priv->uncore;
> struct pci_dev *pdev = dev_priv->drm.pdev;
> struct intel_memory_region *mem;
> resource_size_t io_start;
> - resource_size_t size;
> + resource_size_t lmem_size;
>
> /* Enables Local Memory functionality in GAM */
> I915_WRITE(GEN12_LMEM_CFG_ADDR, I915_READ(GEN12_LMEM_CFG_ADDR) |
> LMEM_ENABLE);
>
> + /* Stolen starts from GSMBASE on DG1 */
> + lmem_size = intel_uncore_read64(uncore, GEN12_GSMBASE);
> +
> io_start = pci_resource_start(pdev, 2);
> - size = pci_resource_len(pdev, 2);
Sanitycheck the two.
size = min(size, lmem_size);
>
> mem = intel_memory_region_create(dev_priv,
> 0,
> -size,
> +lmem_size,
Ok, stolen is at tail not start.
> I915_GTT_PAGE_SIZE_4K,
> io_start,
> &intel_region_lmem_ops);
> @@ -162,7 +165,7 @@ setup_lmem(struct drm_i915_private *dev_priv)
> DRM_INFO("Intel graphics LMEM IO start: %llx\n",
> (u64)mem->io_start);
> DRM_INFO("Intel graphics LMEM size: %llx\n",
> -(u64)size);
> +(u64)lmem_size);
Use the correct printf-formats, %pa.
> }
>
> return mem;
> --
> 2.26.2
>
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 118/162] drm/i915/dg1: Reserve first 1MB of local memory
Quoting Matthew Auld (2020-11-30 11:09:57)
> On 27/11/2020 13:52, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-11-27 12:06:34)
> >> From: Imre Deak
> >>
> >> On DG1 A0/B0 steppings the first 1MB of local memory must be reserved.
> >> One reason for this is that the 0xA-0xB range is not accessible
> >> by the display, probably since this region is redirected to another
> >> memory location for legacy VGA compatibility.
> >>
> >> BSpec: 50586
> >> Testcase: igt/kms_big_fb/linear-64bpp-rotate-0
> >> Signed-off-by: Imre Deak
> >> ---
> >> drivers/gpu/drm/i915/intel_region_lmem.c | 52
> >> 1 file changed, 52 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
> >> b/drivers/gpu/drm/i915/intel_region_lmem.c
> >> index 939cf0d195a5..eafef7034680 100644
> >> --- a/drivers/gpu/drm/i915/intel_region_lmem.c
> >> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> >> @@ -137,6 +137,48 @@ intel_setup_fake_lmem(struct drm_i915_private *i915)
> >> return mem;
> >> }
> >>
> >> +static void get_legacy_lowmem_region(struct intel_uncore *uncore,
> >> +u64 *start, u32 *size)
> >> +{
> >> + *start = 0;
> >> + *size = 0;
> >> +
> >> + if (!IS_DG1_REVID(uncore->i915, DG1_REVID_A0, DG1_REVID_B0))
> >> + return;
> >> +
> >> + *size = SZ_1M;
> >> +
> >> + DRM_DEBUG_DRIVER("LMEM: reserved legacy low-memory
> >> [0x%llx-0x%llx]\n",
> >> +*start, *start + *size);
> >> +}
> >> +
> >> +static int reserve_lowmem_region(struct intel_uncore *uncore,
> >> +struct intel_memory_region *mem)
> >> +{
> >> + u64 reserve_start;
> >> + u64 reserve_end;
> >> + u64 region_start;
> >> + u32 region_size;
> >> + int ret;
> >> +
> >> + get_legacy_lowmem_region(uncore, ®ion_start, ®ion_size);
> >> + reserve_start = region_start;
> >> + reserve_end = region_start + region_size;
> >> +
> >> + if (!reserve_end)
> >> + return 0;
> >> +
> >> + DRM_INFO("LMEM: reserving low-memory region [0x%llx-0x%llx]\n",
> >> +reserve_start, reserve_end);
> >> + ret = i915_buddy_alloc_range(&mem->mm, &mem->reserved,
> >> +reserve_start,
> >> +reserve_end - reserve_start);
> >
> > Isn't this now relative to the stolen offset? Should this be reserved,
> > or excluded like stolen?
>
> AFAIK stolen is just snipped off at the end of lmem, so I don't think it
> really matters if we exclude or reserve.
Right, misread, thought it was moving the start point.
> But for this if we exclude then
> the region.start might have "strange" alignment, which is annoying since
> alloc(some_power_of_two) might not give us the expected alignment,
> whereas if we reserve then the allocator is aware, and so we should get
> the proper alignment. Maybe you have better ideas with how to handle
> this, but I think keeping the alignment property is nice.
The only tweak I would look at is making this reservation be the
property of the VGA decode. But if this promises not to live into
production, kiss.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
On Mon, 30 Nov 2020 11:16:56 + Simon Ser wrote: > On Monday, November 30, 2020 12:13 PM, Pekka Paalanen > wrote: > > > where is the discussion? > > https://dri.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&date=2020-11-26 Thanks, I read that. > > Please record the justitication for that patch in its commit message. > > "Can't" does not explain anything. > > Yeah, sorry about that. I'm just annoyed by all of this get_connector > uAPI, so I don't really want to spend a lot of time documenting why > it's so gross. But I still don't understand why the kernel cannot be fixed to do the right thing that most of us assumed it should be doing: probe automatically so userspace never needs to. Thanks, pq pgpBsZ5pZ0vx2.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] etnaviv-next for 5.11
Hi Dave, hi Daniel, please pull the following etnaviv updates for 5.11. Again, nothing big this time. Mostly a new performance counter from Christian, some more lockdep annotations from Guido and removal of functionality that duplicates driver core from Robin. Regards, Lucas The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 4612bad5701e158f3c40951f2c7aa8e64b3445eb: drm/etnaviv: Add lockdep annotations for context lock (2020-10-30 15:33:59 +0100) Christian Gmeiner (4): drm/etnaviv: rename pipe_reg_read(..) drm/etnaviv: call perf_reg_read(..) drm/etnaviv: add total hi bandwidth perfcounter drm/etnaviv: add pipe_select(..) helper Guido Günther (1): drm/etnaviv: Add lockdep annotations for context lock Robin Murphy (1): drm/etnaviv: Drop local dma_parms drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 -- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 4 +++ drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 78 --- 4 files changed, 59 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] drm/vram-helper: Lock GEM BOs while they are mapped
GEM VRAM helpers used to pin the BO in their implementation of vmap, so that they could not be relocated. In a recent discussion, [1] it became clear that this is incorrect and that vmap should rather repend on the reservation lock to prevent relocation. This patchset addresses the issue. Besides the vram helpers, this affects ast, vboxvideo and the generic fbdev emulation. Patch 1 adds a few more rules to vmap internfaces. With VRAM, it is necessary to keep the BO evictable, which requires soem care when mapping the memory. Patch 2 changes ast's cursor code accordingly. Patch 3 adds vram helpers that acquires the reservation lock and vmap the memory buffer. Same for vunmap in reverse. Patches 4 and 5 convert ast and vboxvideo to the new helper. Patch 6 removes pinning and locking from VRAM helper's vmap and vunmap. The affected users in ast and fbdev emulation acquire the reservation locks of the GEM objects before vmapping BOs. VRAM helpers don't support to export the buffer, so there are no other users of these functions. The the pinning and locking removed, vmap can be simplified as done in patches 7 and 8. Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev change does not interfere with GEM SHMEM. Thomas Zimmermann (8): drm/gem: Write down some rules for vmap usage drm/ast: Only map cursor BOs during updates drm/vram-helper: Provide drm_gem_vram_vmap_unlocked() drm/ast: Use drm_gem_vram_vmap_unlocked() in ast_cursor_show() drm/vboxvideo: Use drm_gem_vram_vmap_unlocked() in cursor update drm/vram-helper: Remove pinning and locking from drm_gem_vram_vmap() drm/vram-helper: Remove vmap reference counting drm/vram-helper: Simplify vmap implementation drivers/gpu/drm/ast/ast_cursor.c | 63 +--- drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/drm_client.c | 31 drivers/gpu/drm/drm_fb_helper.c | 10 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 101 +- drivers/gpu/drm/drm_prime.c | 6 ++ drivers/gpu/drm/vboxvideo/vbox_mode.c | 7 +- include/drm/drm_client.h | 2 + include/drm/drm_gem.h | 16 include/drm/drm_gem_vram_helper.h | 21 ++ 10 files changed, 159 insertions(+), 100 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] drm/gem: Write down some rules for vmap usage
Mapping a GEM object's buffer into kernel address space prevents the
buffer from being evicted from VRAM, which in turn may result in
out-of-memory errors. It's therefore required to only vmap GEM BOs for
short periods of time; unless the GEM implementation provides additional
guarantees.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_prime.c | 6 ++
include/drm/drm_gem.h | 16
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7db55fce35d8..9c9ece9833e0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -669,6 +669,12 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
* callback. Calls into &drm_gem_object_funcs.vmap for device specific
handling.
* The kernel virtual address is returned in map.
*
+ * To prevent the GEM object from being relocated, callers must hold the GEM
+ * object's reservation lock from when calling this function until releasing
the
+ * mapping. Holding onto a mapping and the associated reservation lock for an
+ * unbound time may result in out-of-memory errors. Calls to
drm_gem_dmabuf_vmap()
+ * should therefore be accompanied by a call to drm_gem_dmabuf_vunmap().
+ *
* Returns 0 on success or a negative errno code otherwise.
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5e6daa1c982f..7c34cd5ec261 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -137,7 +137,21 @@ struct drm_gem_object_funcs {
* Returns a virtual address for the buffer. Used by the
* drm_gem_dmabuf_vmap() helper.
*
+* Notes to implementors:
+*
+* - Implementations must expect pairs of @vmap and @vunmap to be
+* called frequently and should optimize for this case.
+*
+* - Implemenations may expect the caller to hold the GEM object's
+* reservation lock to protect against concurrent calls and relocation
+* of the GEM object.
+*
+* - Implementations may provide additional guarantees (e.g., working
+* without holding the reservation lock).
+*
* This callback is optional.
+*
+* See also drm_gem_dmabuf_vmap()
*/
int (*vmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
@@ -148,6 +162,8 @@ struct drm_gem_object_funcs {
* drm_gem_dmabuf_vunmap() helper.
*
* This callback is optional.
+*
+* See also @vmap.
*/
void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] drm/ast: Only map cursor BOs during updates
The HW cursor's BO used to be mapped permanently into the kernel's
address space. GEM's vmap operation will be protected by locks, and
we don't want to lock the BO's for an undefinate period of time.
Change the cursor code to map the HW BOs only during updates. The
vmap operation in VRAM helpers is cheap, as a once estabished mapping
is being reused until the BO actually moves. As the HW cursor BOs are
pinned, they never move at all.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 59 +---
drivers/gpu/drm/ast/ast_drv.h| 2 --
2 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 742d43a7edf4..c5892827b220 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
gbo = ast->cursor.gbo[i];
- drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void
*ptr)
}
/*
- * Allocate cursor BOs and pins them at the end of VRAM.
+ * Allocate cursor BOs and pin them at the end of VRAM.
*/
int ast_cursor_init(struct ast_private *ast)
{
struct drm_device *dev = &ast->base;
size_t size, i;
struct drm_gem_vram_object *gbo;
- struct dma_buf_map map;
int ret;
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
@@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_put(gbo);
goto err_drm_gem_vram_put;
}
- ret = drm_gem_vram_vmap(gbo, &map);
- if (ret) {
- drm_gem_vram_unpin(gbo);
- drm_gem_vram_put(gbo);
- goto err_drm_gem_vram_put;
- }
-
ast->cursor.gbo[i] = gbo;
- ast->cursor.map[i] = map;
}
return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
@@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast)
while (i) {
--i;
gbo = ast->cursor.gbo[i];
- drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -168,38 +157,43 @@ static void update_cursor_image(u8 __iomem *dst, const u8
*src, int width, int h
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
{
struct drm_device *dev = &ast->base;
- struct drm_gem_vram_object *gbo;
- struct dma_buf_map map;
- int ret;
- void *src;
+ struct drm_gem_vram_object *dst_gbo =
ast->cursor.gbo[ast->cursor.next_index];
+ struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ struct dma_buf_map src_map, dst_map;
void __iomem *dst;
+ void *src;
+ int ret;
if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
- gbo = drm_gem_vram_of_gem(fb->obj[0]);
-
- ret = drm_gem_vram_pin(gbo, 0);
+ ret = drm_gem_vram_pin(src_gbo, 0);
if (ret)
return ret;
- ret = drm_gem_vram_vmap(gbo, &map);
+ ret = drm_gem_vram_vmap(src_gbo, &src_map);
if (ret)
- goto err_drm_gem_vram_unpin;
- src = map.vaddr; /* TODO: Use mapping abstraction properly */
+ goto err_drm_gem_vram_unpin_src;
+ src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
- dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
+ ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
+ if (ret)
+ goto err_drm_gem_vram_vunmap_src;
+ dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
- drm_gem_vram_vunmap(gbo, &map);
- drm_gem_vram_unpin(gbo);
+ drm_gem_vram_vunmap(dst_gbo, &dst_map);
+ drm_gem_vram_vunmap(src_gbo, &src_map);
+ drm_gem_vram_unpin(src_gbo);
return 0;
-err_drm_gem_vram_unpin:
- drm_gem_vram_unpin(gbo);
+err_drm_gem_vram_vunmap_src:
+ drm_gem_vram_vunmap(src_gbo, &src_map);
+err_drm_gem_vram_unpin_src:
+ drm_gem_vram_unpin(src_gbo);
return ret;
}
@@ -251,17 +245,26 @@ static void ast_cursor_set_location(struct ast_private
*ast, u16 x, u16 y,
void ast_cursor_show(struct ast_private *ast, int x, int y,
unsigned int offset_x, unsigned int offset_y)
{
+ struct drm_device *dev = &ast->base;
+ struct d
[PATCH 4/8] drm/ast: Use drm_gem_vram_vmap_unlocked() in ast_cursor_show()
This change avoids to pin the source BO when showing the cursor, and
instead acquires the BO's reservation lock. Prevents concurrent access
during the buffer update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index c5892827b220..7a56838fb703 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -254,8 +254,8 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
u8 jreg;
int ret;
- ret = drm_gem_vram_vmap(gbo, &map);
- if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n",
ret))
+ ret = drm_gem_vram_vmap_unlocked(gbo, &map, NULL);
+ if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap_unlocked() failed,
ret=%d\n", ret))
return;
dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
@@ -263,7 +263,7 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
writel(x, sig + AST_HWC_SIGNATURE_X);
writel(y, sig + AST_HWC_SIGNATURE_Y);
- drm_gem_vram_vunmap(gbo, &map);
+ drm_gem_vram_vunmap_unlocked(gbo, &map);
if (x < 0) {
x_offset = (-x) + offset_x;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/vram-helper: Remove pinning and locking from drm_gem_vram_vmap()
BO pinning was never meant to be part of a GEM object's vmap operation.
Remove it from the related code in VRAM helpers. Pinning requires a
locking operation in the vmap code, which we also remove. Callers of
drm_gem_vram_vmap()/_vunmap() are now responsible for acquiring the GEM
object's reservation lock around their vmap/vunmap blocks.
The two remaining callers are fb helpers and ast cursor updates. The
fbdev helpers now call an explicit lock/unlock in their damage worker
to prevent the BO from being evicted.
The ast cursor code acquires the reservation locks of the cursor's HW BO
and the cursor plane's framebuffer BO. Once acquired, it vmaps both BOs
and updates the HW BO from the plane's BO.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 18 +--
drivers/gpu/drm/drm_client.c | 31 +
drivers/gpu/drm/drm_fb_helper.c | 10 ++--
drivers/gpu/drm/drm_gem_vram_helper.c | 33 +++
include/drm/drm_client.h | 2 ++
5 files changed, 55 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 7a56838fb703..9273276d278a 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -159,6 +159,8 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *dst_gbo =
ast->cursor.gbo[ast->cursor.next_index];
struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ struct drm_gem_object *objs[] = {&src_gbo->bo.base, &dst_gbo->bo.base};
+ struct ww_acquire_ctx ctx;
struct dma_buf_map src_map, dst_map;
void __iomem *dst;
void *src;
@@ -168,17 +170,18 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
- ret = drm_gem_vram_pin(src_gbo, 0);
+ ret = drm_gem_lock_reservations(objs, ARRAY_SIZE(objs), &ctx);
if (ret)
return ret;
+
ret = drm_gem_vram_vmap(src_gbo, &src_map);
if (ret)
- goto err_drm_gem_vram_unpin_src;
+ goto err_drm_gem_unlock_reservations;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
if (ret)
- goto err_drm_gem_vram_vunmap_src;
+ goto err_drm_gem_vram_vunmap;
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
/* do data transfer to cursor BO */
@@ -186,14 +189,15 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
drm_gem_vram_vunmap(dst_gbo, &dst_map);
drm_gem_vram_vunmap(src_gbo, &src_map);
- drm_gem_vram_unpin(src_gbo);
+
+ drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return 0;
-err_drm_gem_vram_vunmap_src:
+err_drm_gem_vram_vunmap:
drm_gem_vram_vunmap(src_gbo, &src_map);
-err_drm_gem_vram_unpin_src:
- drm_gem_vram_unpin(src_gbo);
+err_drm_gem_unlock_reservations:
+ drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return ret;
}
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ce45e380f4a2..82453ca0b3ec 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
return ERR_PTR(ret);
}
+/**
+ * drm_client_buffer_lock - Locks the DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function locks the client buffer by acquiring the buffer
+ * object's reservation lock.
+ *
+ * Unlock the buffer with drm_client_buffer_unlock().
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_lock(struct drm_client_buffer *buffer)
+{
+ return dma_resv_lock(buffer->gem->resv, NULL);
+}
+EXPORT_SYMBOL(drm_client_buffer_lock);
+
+/**
+ * drm_client_buffer_unlock - Unlock DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * Unlocks a client buffer. See drm_client_buffer_lock().
+ */
+void drm_client_buffer_unlock(struct drm_client_buffer *buffer)
+{
+ dma_resv_unlock(buffer->gem->resv);
+}
+EXPORT_SYMBOL(drm_client_buffer_unlock);
+
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4b8119510687..97856d9194de 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -411,16 +411,22 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper
*fb_helper,
*/
mutex_lock(&fb_helper->lock);
+ ret = drm_client_buffer_lock(buffer);
+ if (ret)
+ goto ou
[PATCH 7/8] drm/vram-helper: Remove vmap reference counting
Overlapping or nested mappings of the same BO are not allowed by the
semantics of the GEM vmap/vunmap operations. Concurent access to the
GEM object is prevented by reservation locks.
So we don't need the reference counter in the GEM VRAM object. Remove
it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 19 ---
include/drm/drm_gem_vram_helper.h | 17 +++--
2 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index ac0fa9da1c83..a44718dd66cb 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -113,7 +113,6 @@ static void drm_gem_vram_cleanup(struct drm_gem_vram_object
*gbo)
* up; only release the GEM object.
*/
- WARN_ON(gbo->vmap_use_count);
WARN_ON(dma_buf_map_is_set(&gbo->map));
drm_gem_object_release(&gbo->bo.base);
@@ -384,15 +383,10 @@ static int drm_gem_vram_kmap_locked(struct
drm_gem_vram_object *gbo,
{
int ret;
- if (gbo->vmap_use_count > 0)
- goto out;
-
ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
if (ret)
return ret;
-out:
- ++gbo->vmap_use_count;
*map = gbo->map;
return 0;
@@ -403,15 +397,9 @@ static void drm_gem_vram_kunmap_locked(struct
drm_gem_vram_object *gbo,
{
struct drm_device *dev = gbo->bo.base.dev;
- if (drm_WARN_ON_ONCE(dev, !gbo->vmap_use_count))
- return;
-
if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
return; /* BUG: map not mapped from this BO */
- if (--gbo->vmap_use_count > 0)
- return;
-
/*
* Permanently mapping and unmapping buffers adds overhead from
* updating the page tables and creates debugging output. Therefore,
@@ -596,12 +584,13 @@ static void drm_gem_vram_bo_driver_move_notify(struct
drm_gem_vram_object *gbo,
struct ttm_resource *new_mem)
{
struct ttm_buffer_object *bo = &gbo->bo;
- struct drm_device *dev = bo->base.dev;
+ struct dma_buf_map *map = &gbo->map;
- if (drm_WARN_ON_ONCE(dev, gbo->vmap_use_count))
+ if (dma_buf_map_is_null(map))
return;
- ttm_bo_vunmap(bo, &gbo->map);
+ ttm_bo_vunmap(bo, map);
+ dma_buf_map_clear(map);
}
static int drm_gem_vram_bo_driver_move(struct drm_gem_vram_object *gbo,
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 2d22888b5754..b679349bbfb2 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -42,25 +42,14 @@ struct ww_acquire_ctx;
* dedicated memory. The buffer object can be evicted to system memory if
* video memory becomes scarce.
*
- * GEM VRAM objects perform reference counting for pin and mapping
- * operations. So a buffer object that has been pinned N times with
- * drm_gem_vram_pin() must be unpinned N times with
- * drm_gem_vram_unpin(). The same applies to pairs of
- * drm_gem_vram_kmap() and drm_gem_vram_kunmap(), as well as pairs of
- * drm_gem_vram_vmap() and drm_gem_vram_vunmap().
+ * GEM VRAM objects perform reference counting for pin operations. So a
+ * buffer object that has been pinned N times with drm_gem_vram_pin() must
+ * be unpinned N times with drm_gem_vram_unpin().
*/
struct drm_gem_vram_object {
struct ttm_buffer_object bo;
struct dma_buf_map map;
- /**
-* @vmap_use_count:
-*
-* Reference count on the virtual address.
-* The address are un-mapped when the count reaches zero.
-*/
- unsigned int vmap_use_count;
-
/* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
struct ttm_placement placement;
struct ttm_place placements[2];
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/vram-helper: Simplify vmap implementation
After removing the pinning operations, the vmap/vunmap code as been
reduced to what used to be an internal helper. Inline the helper to
simplify the implementation.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 57 +++
1 file changed, 23 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index a44718dd66cb..10d89c01990f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -378,36 +378,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static int drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- struct dma_buf_map *map)
-{
- int ret;
-
- ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
- if (ret)
- return ret;
-
- *map = gbo->map;
-
- return 0;
-}
-
-static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo,
- struct dma_buf_map *map)
-{
- struct drm_device *dev = gbo->bo.base.dev;
-
- if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
- return; /* BUG: map not mapped from this BO */
-
- /*
-* Permanently mapping and unmapping buffers adds overhead from
-* updating the page tables and creates debugging output. Therefore,
-* we delay the actual unmap operation until the BO gets evicted
-* from memory. See drm_gem_vram_bo_driver_move_notify().
-*/
-}
-
/**
* drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
* space
@@ -426,9 +396,17 @@ static void drm_gem_vram_kunmap_locked(struct
drm_gem_vram_object *gbo,
*/
int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map *map)
{
+ int ret;
+
dma_resv_assert_held(gbo->bo.base.resv);
- return drm_gem_vram_kmap_locked(gbo, map);
+ ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
+ if (ret)
+ return ret;
+
+ *map = gbo->map;
+
+ return 0;
}
EXPORT_SYMBOL(drm_gem_vram_vmap);
@@ -442,8 +420,19 @@ EXPORT_SYMBOL(drm_gem_vram_vmap);
*/
void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
*map)
{
+ struct drm_device *dev = gbo->bo.base.dev;
+
dma_resv_assert_held(gbo->bo.base.resv);
- drm_gem_vram_kunmap_locked(gbo, map);
+
+ if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
+ return; /* BUG: map not mapped from this BO */
+
+ /*
+* Permanently mapping and unmapping buffers adds overhead from
+* updating the page tables and creates debugging output. Therefore,
+* we delay the actual unmap operation until the BO gets evicted
+* from memory. See drm_gem_vram_bo_driver_move_notify().
+*/
}
EXPORT_SYMBOL(drm_gem_vram_vunmap);
@@ -471,7 +460,7 @@ int drm_gem_vram_vmap_unlocked(struct drm_gem_vram_object
*gbo, struct dma_buf_m
if (ret)
return ret;
- ret = drm_gem_vram_kmap_locked(gbo, map);
+ ret = drm_gem_vram_vmap(gbo, map);
if (ret)
goto err_ttm_bo_unreserve;
@@ -494,7 +483,7 @@ EXPORT_SYMBOL(drm_gem_vram_vmap_unlocked);
*/
void drm_gem_vram_vunmap_unlocked(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map)
{
- drm_gem_vram_kunmap_locked(gbo, map);
+ drm_gem_vram_vunmap(gbo, map);
ttm_bo_unreserve(&gbo->bo);
}
EXPORT_SYMBOL(drm_gem_vram_vunmap_unlocked);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/vboxvideo: Use drm_gem_vram_vmap_unlocked() in cursor update
This change avoids to pin the source BO and instead acquires the BO's
reservations lock. Prevents concurrent access during the buffer update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index dbc0dd53c69e..cd3001fa209f 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -401,11 +401,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
vbox_crtc->cursor_enabled = true;
- ret = drm_gem_vram_vmap(gbo, &map);
+ ret = drm_gem_vram_vmap_unlocked(gbo, &map, NULL);
if (ret) {
- /*
-* BUG: we should have pinned the BO in prepare_fb().
-*/
mutex_unlock(&vbox->hw_mutex);
DRM_WARN("Could not map cursor bo, skipping update\n");
return;
@@ -421,7 +418,7 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
data_size = width * height * 4 + mask_size;
copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
- drm_gem_vram_vunmap(gbo, &map);
+ drm_gem_vram_vunmap_unlocked(gbo, &map);
flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
VBOX_MOUSE_POINTER_ALPHA;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/vram-helper: Provide drm_gem_vram_vmap_unlocked()
The new interface drm_gem_vram_vmap_unlocked() acquires a GEM object's
reservation lock and vmaps the buffer into the kernel address space. In
contract to the existing vmap implementation, it does not pin the buffer.
The function will be helpful for code that needs to vmap and vunmap
single GEM objects.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 52 +++
include/drm/drm_gem_vram_helper.h | 4 +++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 02ca22e90290..af54cb52423b 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -486,6 +486,58 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
struct dma_buf_map *ma
}
EXPORT_SYMBOL(drm_gem_vram_vunmap);
+/**
+ * drm_gem_vram_vmap_unlocked() - Locks a GEM VRAM object and maps it into
+ *kernel address space
+ * @gbo: The GEM VRAM object to map
+ * @map: Returns the kernel virtual address of the VRAM GEM object's backing
+ * store.
+ * @ctx: The locking context.
+ *
+ * This vmap function locks a GEM VRAM object and maps its buffer into kernel
+ * address space. Call drm_gem_vram_vunmap_unlocked() with the returned address
+ * to unmap and unlock the GEM VRAM object.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_gem_vram_vmap_unlocked(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map,
+ struct ww_acquire_ctx *ctx)
+{
+ int ret;
+
+ ret = ttm_bo_reserve(&gbo->bo, true, false, ctx);
+ if (ret)
+ return ret;
+
+ ret = drm_gem_vram_kmap_locked(gbo, map);
+ if (ret)
+ goto err_ttm_bo_unreserve;
+
+ return 0;
+
+err_ttm_bo_unreserve:
+ ttm_bo_unreserve(&gbo->bo);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vram_vmap_unlocked);
+
+/**
+ * drm_gem_vram_vunmap_unlocked() - Unmaps and unlocks a GEM VRAM object
+ * @gbo: The GEM VRAM object to unmap
+ * @map: Kernel virtual address where the VRAM GEM object was mapped
+ *
+ * A call to drm_gem_vram_vunmap_unlocked() unmaps and unlocks a GEM VRAM
+ * buffer object. See the documentation for drm_gem_vram_vmap_unlocked()
+ * for more information.
+ */
+void drm_gem_vram_vunmap_unlocked(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map)
+{
+ drm_gem_vram_kunmap_locked(gbo, map);
+ ttm_bo_unreserve(&gbo->bo);
+}
+EXPORT_SYMBOL(drm_gem_vram_vunmap_unlocked);
+
/**
* drm_gem_vram_fill_create_dumb() - \
Helper for implementing &struct drm_driver.dumb_create
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index a4bac02249c2..2d22888b5754 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -19,6 +19,7 @@ struct drm_plane_state;
struct drm_simple_display_pipe;
struct filp;
struct vm_area_struct;
+struct ww_acquire_ctx;
#define DRM_GEM_VRAM_PL_FLAG_SYSTEM(1 << 0)
#define DRM_GEM_VRAM_PL_FLAG_VRAM (1 << 1)
@@ -99,6 +100,9 @@ int drm_gem_vram_pin(struct drm_gem_vram_object *gbo,
unsigned long pl_flag);
int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo);
int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
*map);
void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
*map);
+int drm_gem_vram_vmap_unlocked(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map,
+ struct ww_acquire_ctx *ctx);
+void drm_gem_vram_vunmap_unlocked(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map);
int drm_gem_vram_fill_create_dumb(struct drm_file *file,
struct drm_device *dev,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/28] video: fbdev: via: Fix set but not used warning for mode_crt_table
Am 28.11.20 um 23:40 schrieb Sam Ravnborg: Fix warning by deleting the variable. The function call viafb_get_best_mode() were verified to have no side-effects, s/were/was and thus could be dropped too. v2: - Update subject (Lee) Signed-off-by: Sam Ravnborg Cc: Florian Tobias Schandinat Cc: linux-fb...@vger.kernel.org Cc: Lee Jones Acked-by: Thomas Zimmermann --- drivers/video/fbdev/via/lcd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/via/lcd.c b/drivers/video/fbdev/via/lcd.c index 4a869402d120..088b962076b5 100644 --- a/drivers/video/fbdev/via/lcd.c +++ b/drivers/video/fbdev/via/lcd.c @@ -537,11 +537,9 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres, u32 clock; struct via_display_timing timing; struct fb_var_screeninfo panel_var; - const struct fb_videomode *mode_crt_table, *panel_crt_table; + const struct fb_videomode *panel_crt_table; DEBUG_MSG(KERN_INFO "viafb_lcd_set_mode!!\n"); - /* Get mode table */ - mode_crt_table = viafb_get_best_mode(set_hres, set_vres, 60); /* Get panel table Pointer */ panel_crt_table = viafb_get_best_mode(panel_hres, panel_vres, 60); viafb_fill_var_timing_info(&panel_var, panel_crt_table); -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/28] video: fbdev: tdfx: Fix set but not used warning in att_outb()
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
The tmp variable were assigned but the result was never used,
s/were/was
so delete the tmp variable.
v2:
- Update subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Arnd Bergmann
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/tdfxfb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index f056d80f6359..67e37a62b07c 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -206,9 +206,7 @@ static inline u8 crt_inb(struct tdfx_par *par, u32 idx)
static inline void att_outb(struct tdfx_par *par, u32 idx, u8 val)
{
- unsigned char tmp;
-
- tmp = vga_inb(par, IS1_R);
+ vga_inb(par, IS1_R);
It resets the attribute register's state. Hopefully, this doesn't get
optimized away.
vga_outb(par, ATT_IW, idx);
vga_outb(par, ATT_IW, val);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/28] video: fbdev: riva: Fix kernel-doc and set but not used warnings
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused variables/code
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
---
drivers/video/fbdev/riva/fbdev.c | 9 -
drivers/video/fbdev/riva/riva_hw.c | 28
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index ce55b9d2e862..4b0433cb 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -464,7 +464,7 @@ static inline void reverse_order(u32 *l)
/**
* rivafb_load_cursor_image - load cursor image to hardware
- * @data: address to monochrome bitmap (1 = foreground color, 0 = background)
+ * @data8: address to monochrome bitmap (1 = foreground color, 0 = background)
* @par: pointer to private data
* @w:width of cursor image in pixels
* @h:height of cursor image in scanlines
@@ -843,9 +843,9 @@ static void riva_update_var(struct fb_var_screeninfo *var,
/**
* rivafb_do_maximize -
* @info: pointer to fb_info object containing info for current riva board
- * @var:
- * @nom:
- * @den:
+ * @var: standard kernel fb changeable data
+ * @nom: nom
+ * @den: den
Well, it fixes the warning ;)
Acked-by: Thomas Zimmermann
*
* DESCRIPTION:
* .
@@ -1214,7 +1214,6 @@ static int rivafb_set_par(struct fb_info *info)
/**
* rivafb_pan_display
* @var: standard kernel fb changeable data
- * @con: TODO
* @info: pointer to fb_info object containing info for current riva board
*
* DESCRIPTION:
diff --git a/drivers/video/fbdev/riva/riva_hw.c
b/drivers/video/fbdev/riva/riva_hw.c
index bcf9c4b4de31..8b829b720064 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -836,17 +836,17 @@ static void nv10CalcArbitration
nv10_sim_state *arb
)
{
-int data, pagemiss, cas,width, video_enable, bpp;
-int nvclks, mclks, pclks, vpagemiss, crtpagemiss, vbs;
-int nvclk_fill, us_extra;
+int data, pagemiss, width, video_enable, bpp;
+int nvclks, mclks, pclks, vpagemiss, crtpagemiss;
+int nvclk_fill;
int found, mclk_extra, mclk_loop, cbs, m1;
int mclk_freq, pclk_freq, nvclk_freq, mp_enable;
-int us_m, us_m_min, us_n, us_p, video_drain_rate, crtc_drain_rate;
-int vus_m, vus_n, vus_p;
-int vpm_us, us_video, vlwm, cpm_us, us_crt,clwm;
+int us_m, us_m_min, us_n, us_p, crtc_drain_rate;
+int vus_m;
+int vpm_us, us_video, cpm_us, us_crt,clwm;
int clwm_rnd_down;
-int craw, m2us, us_pipe, us_pipe_min, vus_pipe, p1clk, p2;
-int pclks_2_top_fifo, min_mclk_extra;
+int m2us, us_pipe_min, p1clk, p2;
+int min_mclk_extra;
int us_min_mclk_extra;
fifo->valid = 1;
@@ -854,16 +854,13 @@ static void nv10CalcArbitration
mclk_freq = arb->mclk_khz;
nvclk_freq = arb->nvclk_khz;
pagemiss = arb->mem_page_miss;
-cas = arb->mem_latency;
width = arb->memory_width/64;
video_enable = arb->enable_video;
bpp = arb->pix_bpp;
mp_enable = arb->enable_mp;
clwm = 0;
-vlwm = 1024;
cbs = 512;
-vbs = 512;
pclks = 4; /* lwm detect. */
@@ -924,17 +921,11 @@ static void nv10CalcArbitration
us_min_mclk_extra = min_mclk_extra *1000*1000 / mclk_freq;
us_n = nvclks*1000*1000 / nvclk_freq;/* nvclk latency in us */
us_p = pclks*1000*1000 / pclk_freq;/* nvclk latency in us */
- us_pipe = us_m + us_n + us_p;
us_pipe_min = us_m_min + us_n + us_p;
- us_extra = 0;
vus_m = mclk_loop *1000*1000 / mclk_freq; /* Mclk latency in us */
- vus_n = (4)*1000*1000 / nvclk_freq;/* nvclk latency in us */
- vus_p = 0*1000*1000 / pclk_freq;/* pclk latency in us */
- vus_pipe = vus_m + vus_n + vus_p;
if(video_enable) {
-video_drain_rate = pclk_freq * 4; /* MB/s */
crtc_drain_rate = pclk_freq * bpp/8; /* MB/s */
vpagemiss = 1; /* self generating page miss */
@@ -993,7 +984,6 @@ static void nv10CalcArbitration
else if(crtc_drain_rate * 100 >= nvclk_fill * 98) {
clwm = 1024;
cbs = 512;
- us_extra = (cbs * 1000 * 1000)/ (8*width)/mclk_freq ;
}
}
}
@@ -1010,7 +1000,6 @@ static void nv10CalcArbitration
m1 = clwm + cbs - 1024; /* Amount of overfill */
m2us = us_pipe_min + us_min_mclk_extra;
- pclks_2_top_fifo = (1024-clwm)/(8*width);
/* pclk cycles to drain */
p1clk = m2us * pclk_freq/(1000*1000);
@@ -1038,7 +1027,6 @@ static void nv10CalcArbitration
min_mclk_extra--;
}
}
- craw = clwm;
if(clwm < (1024-cbs+8)) clwm = 1024-cbs+8;
data = (int)(clwm);
--
Thomas Zimmermann
Graphics Driver Deve
Re: [PATCH v2 14/28] video: fbdev: pm2fb: Fix kernel-doc warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fixed a few kernel-doc issues to fix the warnings.
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Randy Dunlap
Cc: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz
Cc: Jani Nikula
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/pm2fb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..c68725eebee3 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -1508,8 +1508,8 @@ static const struct fb_ops pm2fb_ops = {
*
* Initialise and allocate resource for PCI device.
*
- * @param pdevPCI device.
- * @param id PCI device ID.
+ * @pdev: PCI device.
+ * @id:PCI device ID.
*/
static int pm2fb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
@@ -1715,7 +1715,7 @@ static int pm2fb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
*
* Release all device resources.
*
- * @param pdevPCI device to clean up.
+ * @pdev: PCI device to clean up.
*/
static void pm2fb_remove(struct pci_dev *pdev)
{
@@ -1756,7 +1756,7 @@ MODULE_DEVICE_TABLE(pci, pm2fb_id_table);
#ifndef MODULE
-/**
+/*
* Parse user specified options.
*
* This is, comma-separated options following `video=pm2fb:'.
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/28] video: fbdev: neofb: Fix set but not used warning for CursorMem
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix W=1 warnings by removing unused code
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Andrew Morton
Cc: Evgeny Novikov
Cc: Jani Nikula
Cc: Mike Rapoport
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/neofb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c
index 09a20d4ab35f..c0f4f402da3f 100644
--- a/drivers/video/fbdev/neofb.c
+++ b/drivers/video/fbdev/neofb.c
@@ -1843,7 +1843,6 @@ static int neo_init_hw(struct fb_info *info)
struct neofb_par *par = info->par;
int videoRam = 896;
int maxClock = 65000;
- int CursorMem = 1024;
int CursorOff = 0x100;
DBG("neo_init_hw");
@@ -1895,19 +1894,16 @@ static int neo_init_hw(struct fb_info *info)
case FB_ACCEL_NEOMAGIC_NM2070:
case FB_ACCEL_NEOMAGIC_NM2090:
case FB_ACCEL_NEOMAGIC_NM2093:
- CursorMem = 2048;
CursorOff = 0x100;
break;
case FB_ACCEL_NEOMAGIC_NM2097:
case FB_ACCEL_NEOMAGIC_NM2160:
- CursorMem = 1024;
CursorOff = 0x100;
break;
case FB_ACCEL_NEOMAGIC_NM2200:
case FB_ACCEL_NEOMAGIC_NM2230:
case FB_ACCEL_NEOMAGIC_NM2360:
case FB_ACCEL_NEOMAGIC_NM2380:
- CursorMem = 1024;
CursorOff = 0x1000;
par->neo2200 = (Neo2200 __iomem *) par->mmio_vbase;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
CC Daniel and Ville On Monday, November 30, 2020 12:24 PM, Pekka Paalanen wrote: > > > Please record the justitication for that patch in its commit message. > > > "Can't" does not explain anything. > > > > Yeah, sorry about that. I'm just annoyed by all of this get_connector > > uAPI, so I don't really want to spend a lot of time documenting why > > it's so gross. > > But I still don't understand why the kernel cannot be fixed to do the > right thing that most of us assumed it should be doing: probe > automatically so userspace never needs to. My understanding is that it could maybe be implemented this way, but that it's not the way it works right now. So someone would need to go through all DRM drivers and implement the better behavior, then could restore this doc section. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 131/162] drm/i915/dg1: Add enable_eviction modparam
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: CQ Tang
>
> enable_eviction is used to tune if eviction is enabled (default) or not.
>
> Signed-off-by: Sudeep Dutt
> Signed-off-by: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_region.c | 5 +
> drivers/gpu/drm/i915/i915_params.c | 3 +++
> drivers/gpu/drm/i915/i915_params.h | 1 +
> drivers/gpu/drm/i915/intel_memory_region.c | 2 +-
> 5 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 7cb5f137522f..46d0f8731db0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -293,6 +293,7 @@ static void i915_gem_free_object(struct drm_gem_object
> *gem_obj)
>* If object had been swapped out, free the hidden object.
>*/
> if (obj->swapto) {
> + GEM_BUG_ON(!i915->params.enable_eviction);
> i915_gem_object_put(obj->swapto);
> obj->swapto = NULL;
> }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
> b/drivers/gpu/drm/i915/gem/i915_gem_region.c
> index a437538cd872..e1793c5f8d8c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
> @@ -21,6 +21,7 @@ i915_gem_object_swapout_pages(struct drm_i915_gem_object
> *obj,
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
> GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
> GEM_BUG_ON(obj->mm.region->type != INTEL_MEMORY_LOCAL);
> + GEM_BUG_ON(!i915->params.enable_eviction);
>
> assert_object_held(obj);
>
> @@ -70,6 +71,7 @@ static int
> i915_gem_object_swapin_pages(struct drm_i915_gem_object *obj,
>struct sg_table *pages, unsigned int sizes)
> {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct drm_i915_gem_object *dst, *src;
> int err;
>
> @@ -77,6 +79,7 @@ i915_gem_object_swapin_pages(struct drm_i915_gem_object
> *obj,
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
> GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
> GEM_BUG_ON(obj->mm.region->type != INTEL_MEMORY_LOCAL);
> + GEM_BUG_ON(!i915->params.enable_eviction);
>
> assert_object_held(obj);
>
> @@ -146,6 +149,7 @@ i915_gem_object_put_pages_buddy(struct
> drm_i915_gem_object *obj,
> int
> i915_gem_object_get_pages_buddy(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct intel_memory_region *mem = obj->mm.region;
> struct list_head *blocks = &obj->mm.blocks;
> resource_size_t size = obj->base.size;
> @@ -222,6 +226,7 @@ i915_gem_object_get_pages_buddy(struct
> drm_i915_gem_object *obj)
> /* if we saved the page contents, swap them in */
> if (obj->swapto) {
> GEM_BUG_ON(i915_gem_object_is_volatile(obj));
> + GEM_BUG_ON(!i915->params.enable_eviction);
>
> ret = i915_gem_object_swapin_pages(obj, st,
> sg_page_sizes);
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 7f139ea4a90b..bb1ebb6ece95 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -197,6 +197,9 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
> "Fake LMEM start offset (default: 0)");
> #endif
>
> +i915_param_named_unsafe(enable_eviction, bool, 0600,
> + "Enable memcpy based eviction which does not rely on DMA resv
> refactoring)");
Does the module parameter actually need to be writable? Should be
modified via debugfs as a device specific parameter?
BR,
Jani.
> +
> static __always_inline void _print_param(struct drm_printer *p,
>const char *name,
>const char *type,
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 330c03e2b4f7..87df407d9afb 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -72,6 +72,7 @@ struct drm_printer;
> param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
> param(unsigned long, fake_lmem_start, 0, 0400) \
> /* leave bools at the end to not create holes */ \
> + param(bool, enable_eviction, true, 0600) \
> param(bool, enable_hangcheck, true, 0600) \
> param(bool, load_detect_test, false, 0600) \
> param(bool, force_reset_modeset_test, false, 0600) \
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> b/drivers/gpu/drm/i915/intel_memory_region.c
> index afcd6fe6eaff..57f01ef16628 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -175,7 +175,7 @@ static int intel_memory_region_evict(struct
>
Re: [PATCH 0/8] drm/vram-helper: Lock GEM BOs while they are mapped
Am 30.11.20 um 13:04 schrieb Thomas Zimmermann: GEM VRAM helpers used to pin the BO in their implementation of vmap, so that they could not be relocated. In a recent discussion, [1] it became clear that this is incorrect and that vmap should rather repend on the reservation lock to prevent relocation. This patchset addresses the issue. Besides the vram helpers, this affects ast, vboxvideo and the generic fbdev emulation. Patch 1 adds a few more rules to vmap internfaces. With VRAM, it is necessary to keep the BO evictable, which requires soem care when mapping the memory. Patch 2 changes ast's cursor code accordingly. Patch 3 adds vram helpers that acquires the reservation lock and vmap the memory buffer. Same for vunmap in reverse. Patches 4 and 5 convert ast and vboxvideo to the new helper. Patch 6 removes pinning and locking from VRAM helper's vmap and vunmap. The affected users in ast and fbdev emulation acquire the reservation locks of the GEM objects before vmapping BOs. VRAM helpers don't support to export the buffer, so there are no other users of these functions. The the pinning and locking removed, vmap can be simplified as done in patches 7 and 8. Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev change does not interfere with GEM SHMEM. Acked-by: Christian König for the series. Thomas Zimmermann (8): drm/gem: Write down some rules for vmap usage drm/ast: Only map cursor BOs during updates drm/vram-helper: Provide drm_gem_vram_vmap_unlocked() drm/ast: Use drm_gem_vram_vmap_unlocked() in ast_cursor_show() drm/vboxvideo: Use drm_gem_vram_vmap_unlocked() in cursor update drm/vram-helper: Remove pinning and locking from drm_gem_vram_vmap() drm/vram-helper: Remove vmap reference counting drm/vram-helper: Simplify vmap implementation drivers/gpu/drm/ast/ast_cursor.c | 63 +--- drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/drm_client.c | 31 drivers/gpu/drm/drm_fb_helper.c | 10 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 101 +- drivers/gpu/drm/drm_prime.c | 6 ++ drivers/gpu/drm/vboxvideo/vbox_mode.c | 7 +- include/drm/drm_client.h | 2 + include/drm/drm_gem.h | 16 include/drm/drm_gem_vram_helper.h | 21 ++ 10 files changed, 159 insertions(+), 100 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/vram-helper: Lock GEM BOs while they are mapped
Hi Am 30.11.20 um 13:04 schrieb Thomas Zimmermann: GEM VRAM helpers used to pin the BO in their implementation of vmap, so that they could not be relocated. In a recent discussion, [1] it became [1] was supposed to point to the discussion at https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1 clear that this is incorrect and that vmap should rather repend on the reservation lock to prevent relocation. This patchset addresses the issue. Besides the vram helpers, this affects ast, vboxvideo and the generic fbdev emulation. Patch 1 adds a few more rules to vmap internfaces. With VRAM, it is necessary to keep the BO evictable, which requires soem care when mapping the memory. Patch 2 changes ast's cursor code accordingly. Patch 3 adds vram helpers that acquires the reservation lock and vmap the memory buffer. Same for vunmap in reverse. Patches 4 and 5 convert ast and vboxvideo to the new helper. Patch 6 removes pinning and locking from VRAM helper's vmap and vunmap. The affected users in ast and fbdev emulation acquire the reservation locks of the GEM objects before vmapping BOs. VRAM helpers don't support to export the buffer, so there are no other users of these functions. The the pinning and locking removed, vmap can be simplified as done in patches 7 and 8. Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev change does not interfere with GEM SHMEM. Thomas Zimmermann (8): drm/gem: Write down some rules for vmap usage drm/ast: Only map cursor BOs during updates drm/vram-helper: Provide drm_gem_vram_vmap_unlocked() drm/ast: Use drm_gem_vram_vmap_unlocked() in ast_cursor_show() drm/vboxvideo: Use drm_gem_vram_vmap_unlocked() in cursor update drm/vram-helper: Remove pinning and locking from drm_gem_vram_vmap() drm/vram-helper: Remove vmap reference counting drm/vram-helper: Simplify vmap implementation drivers/gpu/drm/ast/ast_cursor.c | 63 +--- drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/drm_client.c | 31 drivers/gpu/drm/drm_fb_helper.c | 10 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 101 +- drivers/gpu/drm/drm_prime.c | 6 ++ drivers/gpu/drm/vboxvideo/vbox_mode.c | 7 +- include/drm/drm_client.h | 2 + include/drm/drm_gem.h | 16 include/drm/drm_gem_vram_helper.h | 21 ++ 10 files changed, 159 insertions(+), 100 deletions(-) -- 2.29.2 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: Remove udlfb driver
Udlfb has been superseded by DRM's udl. The DRM driver is better by any means and actively maintained. Remove udlfb. Signed-off-by: Thomas Zimmermann --- CREDITS |5 + Documentation/fb/index.rst |1 - Documentation/fb/udlfb.rst | 162 --- MAINTAINERS |9 - drivers/video/fbdev/Kconfig | 17 +- drivers/video/fbdev/Makefile |1 - drivers/video/fbdev/udlfb.c | 1994 -- 7 files changed, 6 insertions(+), 2183 deletions(-) delete mode 100644 Documentation/fb/udlfb.rst delete mode 100644 drivers/video/fbdev/udlfb.c diff --git a/CREDITS b/CREDITS index 748301954ab7..fed3518c4dd8 100644 --- a/CREDITS +++ b/CREDITS @@ -3620,6 +3620,11 @@ S: 145 Howard St. S: Northborough, MA 01532 S: USA +N: Bernie Thompson +E: ber...@plugable.com +W: http://plugable.com/category/projects/udlfb/ +D: DisplayLink USB 2.0 framebuffer driver + N: Doug Thompson E: dougthomp...@xmission.com D: EDAC diff --git a/Documentation/fb/index.rst b/Documentation/fb/index.rst index baf02393d8ee..8136c84328e2 100644 --- a/Documentation/fb/index.rst +++ b/Documentation/fb/index.rst @@ -36,7 +36,6 @@ Frame Buffer sstfb tgafb tridentfb -udlfb uvesafb vesafb viafb diff --git a/Documentation/fb/udlfb.rst b/Documentation/fb/udlfb.rst deleted file mode 100644 index 732b37db3504.. --- a/Documentation/fb/udlfb.rst +++ /dev/null @@ -1,162 +0,0 @@ -== -What is udlfb? -== - -This is a driver for DisplayLink USB 2.0 era graphics chips. - -DisplayLink chips provide simple hline/blit operations with some compression, -pairing that with a hardware framebuffer (16MB) on the other end of the -USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI -monitor with no CPU involvement until a pixel has to change. - -The CPU or other local resource does all the rendering; optionally compares the -result with a local shadow of the remote hardware framebuffer to identify -the minimal set of pixels that have changed; and compresses and sends those -pixels line-by-line via USB bulk transfers. - -Because of the efficiency of bulk transfers and a protocol on top that -does not require any acks - the effect is very low latency that -can support surprisingly high resolutions with good performance for -non-gaming and non-video applications. - -Mode setting, EDID read, etc are other bulk or control transfers. Mode -setting is very flexible - able to set nearly arbitrary modes from any timing. - -Advantages of USB graphics in general: - - * Ability to add a nearly arbitrary number of displays to any USB 2.0 - capable system. On Linux, number of displays is limited by fbdev interface - (FB_MAX is currently 32). Of course, all USB devices on the same - host controller share the same 480Mbs USB 2.0 interface. - -Advantages of supporting DisplayLink chips with kernel framebuffer interface: - - * The actual hardware functionality of DisplayLink chips matches nearly - one-to-one with the fbdev interface, making the driver quite small and - tight relative to the functionality it provides. - * X servers and other applications can use the standard fbdev interface - from user mode to talk to the device, without needing to know anything - about USB or DisplayLink's protocol at all. A "displaylink" X driver - and a slightly modified "fbdev" X driver are among those that already do. - -Disadvantages: - - * Fbdev's mmap interface assumes a real hardware framebuffer is mapped. - In the case of USB graphics, it is just an allocated (virtual) buffer. - Writes need to be detected and encoded into USB bulk transfers by the CPU. - Accurate damage/changed area notifications work around this problem. - In the future, hopefully fbdev will be enhanced with an small standard - interface to allow mmap clients to report damage, for the benefit - of virtual or remote framebuffers. - * Fbdev does not arbitrate client ownership of the framebuffer well. - * Fbcon assumes the first framebuffer it finds should be consumed for console. - * It's not clear what the future of fbdev is, given the rise of KMS/DRM. - -How to use it? -== - -Udlfb, when loaded as a module, will match against all USB 2.0 generation -DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID -of the monitor, and set the best common mode between the DisplayLink device -and the monitor's capabilities. - -If the DisplayLink device is successful, it will paint a "green screen" which -means that from a hardware and fbdev software perspective, everything is good. - -At that point, a /dev/fb? interface will be present for user-mode applications -to open and begin writing to the framebuffer of the DisplayLink device using -standard fbdev calls. Note that if mmap() is used, by default the user mode -application must send down damage notifications to trigger repaints of the -changed regions. Alte
Re: [PATCH v2 17/28] video: fbdev: tgafb: Fix kernel-doc and set but not used warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg: Fix W=1 warnings: - Fix kernel-doc - Drop unused code v2: - Updated subject (Lee) Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Jani Nikula Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Arnd Bergmann Cc: Joe Perches Cc: Lee Jones Acked-by: Thomas Zimmermann --- drivers/video/fbdev/tgafb.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/tgafb.c b/drivers/video/fbdev/tgafb.c index 666fbe2f671c..ae0cf5540636 100644 --- a/drivers/video/fbdev/tgafb.c +++ b/drivers/video/fbdev/tgafb.c @@ -555,7 +555,7 @@ tgafb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue, /** * tgafb_blank - Optional function. Blanks the display. - * @blank_mode: the blank mode we want. + * @blank: the blank mode we want. * @info: frame buffer structure that represents a single frame buffer */ static int @@ -837,7 +837,7 @@ tgafb_clut_imageblit(struct fb_info *info, const struct fb_image *image) u32 *palette = ((u32 *)info->pseudo_palette); unsigned long pos, line_length, i, j; const unsigned char *data; - void __iomem *regs_base, *fb_base; + void __iomem *fb_base; dx = image->dx; dy = image->dy; @@ -855,7 +855,6 @@ tgafb_clut_imageblit(struct fb_info *info, const struct fb_image *image) if (dy + height > vyres) height = vyres - dy; - regs_base = par->tga_regs_base; fb_base = par->tga_fb_base; pos = dy * line_length + (dx * 4); @@ -1034,7 +1033,7 @@ tgafb_fillrect(struct fb_info *info, const struct fb_fillrect *rect) regs_base + TGA_MODE_REG); } -/** +/* * tgafb_copyarea - REQUIRED function. Can use generic routines if * non acclerated hardware and packed pixel based. * Copies on area of the screen to another area. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 18/28] video: fbdev: mx3fb: Fix kernel-doc, set but not used and string warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused code/variables
- Use memcpy to copy a string without zero-termination
strncpy() generates a warning
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Xiaofei Tan
Cc: Arnd Bergmann
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/mx3fb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index 894617ddabcb..fabb271337ed 100644
--- a/drivers/video/fbdev/mx3fb.c
+++ b/drivers/video/fbdev/mx3fb.c
@@ -445,7 +445,6 @@ static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
static void sdc_disable_channel(struct mx3fb_info *mx3_fbi)
{
struct mx3fb_data *mx3fb = mx3_fbi->mx3fb;
- uint32_t enabled;
unsigned long flags;
if (mx3_fbi->txd == NULL)
@@ -453,7 +452,7 @@ static void sdc_disable_channel(struct mx3fb_info *mx3_fbi)
spin_lock_irqsave(&mx3fb->lock, flags);
- enabled = sdc_fb_uninit(mx3_fbi);
+ sdc_fb_uninit(mx3_fbi);
spin_unlock_irqrestore(&mx3fb->lock, flags);
@@ -732,7 +731,7 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi);
/**
* mx3fb_set_fix() - set fixed framebuffer parameters from variable settings.
- * @info: framebuffer information pointer
+ * @fbi: framebuffer information pointer
* @return: 0 on success or negative error code on failure.
*/
static int mx3fb_set_fix(struct fb_info *fbi)
@@ -740,7 +739,7 @@ static int mx3fb_set_fix(struct fb_info *fbi)
struct fb_fix_screeninfo *fix = &fbi->fix;
struct fb_var_screeninfo *var = &fbi->var;
- strncpy(fix->id, "DISP3 BG", 8);
+ memcpy(fix->id, "DISP3 BG", 8);
fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
@@ -1105,6 +1104,8 @@ static void __blank(int blank, struct fb_info *fbi)
/**
* mx3fb_blank() - blank the display.
+ * @blank: blank value for the panel
+ * @fbi: framebuffer information pointer
*/
static int mx3fb_blank(int blank, struct fb_info *fbi)
{
@@ -1126,7 +1127,7 @@ static int mx3fb_blank(int blank, struct fb_info *fbi)
/**
* mx3fb_pan_display() - pan or wrap the display
* @var: variable screen buffer information.
- * @info: framebuffer information pointer.
+ * @fbi: framebuffer information pointer.
*
* We look only at xoffset, yoffset and the FB_VMODE_YWRAP flag
*/
@@ -1387,6 +1388,8 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi)
/**
* mx3fb_init_fbinfo() - initialize framebuffer information object.
+ * @dev: the device
+ * @ops: framebuffer device operations
* @return: initialized framebuffer structure.
*/
static struct fb_info *mx3fb_init_fbinfo(struct device *dev,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: sdi: fix bridge enable/disable
On 28/11/2020 19:45, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Nov 27, 2020 at 10:52:41AM +0200, Tomi Valkeinen wrote:
>> When the SDI output was converted to DRM bridge, the atomic versions of
>> enable and disable funcs were used. This was not intended, as that would
>> require implementing other atomic funcs too. This leads to:
>>
>> WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708
>> drm_atomic_helper_commit_modeset_enables+0x134/0x268
>>
>> and display not working.
>>
>> Fix this by using the legacy enable/disable funcs.
>>
>> Signed-off-by: Tomi Valkeinen
>> Reported-by: Aaro Koskinen
>> Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a
>> drm_bridge")
>> Cc: sta...@vger.kernel.org # v5.7+
>> Tested-by: Ivaylo Dimitrov
>
> Tested-by: Aaro Koskinen
Thanks! I pushed this to drm-misc-fixes. Hopefully with this and Sebastian's
patch N900 display now
works.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 81/80] drm/omap: dsi: allow DSI commands to be sent early
Panel drivers can send DSI commands in panel's prepare(), which happens
before the bridge's enable() is called. The OMAP DSI driver currently
only sets up the DSI interface at bridge's enable(), so prepare() cannot
be used to send DSI commands.
This patch fixes the issue by making it possible to enable the DSI
interface any time a command is about to be sent. Disabling the
interface is be done via delayed work.
Signed-off-by: Tomi Valkeinen
---
One more patch. With this video mode panels seem to work cleanly (tested
by me on omap5 uevm + custom panel and Nikolaus on pyra).
drivers/gpu/drm/omapdrm/dss/dsi.c | 49 +++
drivers/gpu/drm/omapdrm/dss/dsi.h | 3 ++
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index d52bef0c7aa2..ae504ab122b4 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -3498,6 +3498,9 @@ static void dsi_enable(struct dsi_data *dsi)
WARN_ON(!dsi_bus_is_locked(dsi));
+ if (WARN_ON(dsi->iface_enabled))
+ return;
+
mutex_lock(&dsi->lock);
r = dsi_runtime_get(dsi);
@@ -3510,6 +3513,8 @@ static void dsi_enable(struct dsi_data *dsi)
if (r)
goto err_init_dsi;
+ dsi->iface_enabled = true;
+
mutex_unlock(&dsi->lock);
return;
@@ -3525,6 +3530,9 @@ static void dsi_disable(struct dsi_data *dsi)
{
WARN_ON(!dsi_bus_is_locked(dsi));
+ if (WARN_ON(!dsi->iface_enabled))
+ return;
+
mutex_lock(&dsi->lock);
dsi_sync_vc(dsi, 0);
@@ -3536,6 +3544,8 @@ static void dsi_disable(struct dsi_data *dsi)
dsi_runtime_put(dsi);
+ dsi->iface_enabled = false;
+
mutex_unlock(&dsi->lock);
}
@@ -4224,10 +4234,12 @@ static ssize_t omap_dsi_host_transfer(struct
mipi_dsi_host *host,
dsi_bus_lock(dsi);
- if (dsi->video_enabled)
- r = _omap_dsi_host_transfer(dsi, vc, msg);
- else
- r = -EIO;
+ if (!dsi->iface_enabled) {
+ dsi_enable(dsi);
+ schedule_delayed_work(&dsi->dsi_disable_work,
msecs_to_jiffies(2000));
+ }
+
+ r = _omap_dsi_host_transfer(dsi, vc, msg);
dsi_bus_unlock(dsi);
@@ -4392,6 +4404,14 @@ static int omap_dsi_host_detach(struct mipi_dsi_host
*host,
if (WARN_ON(dsi->dsidev != client))
return -EINVAL;
+ cancel_delayed_work_sync(&dsi->dsi_disable_work);
+
+ if (dsi->iface_enabled) {
+ dsi_bus_lock(dsi);
+ dsi_disable(dsi);
+ dsi_bus_unlock(dsi);
+ }
+
omap_dsi_unregister_te_irq(dsi);
dsi->dsidev = NULL;
return 0;
@@ -4627,9 +4647,12 @@ static void dsi_bridge_enable(struct drm_bridge *bridge)
struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
struct omap_dss_device *dssdev = &dsi->output;
+ cancel_delayed_work_sync(&dsi->dsi_disable_work);
+
dsi_bus_lock(dsi);
- dsi_enable(dsi);
+ if (!dsi->iface_enabled)
+ dsi_enable(dsi);
dsi_enable_video_output(dssdev, VC_VIDEO);
@@ -4643,6 +4666,8 @@ static void dsi_bridge_disable(struct drm_bridge *bridge)
struct dsi_data *dsi = drm_bridge_to_dsi(bridge);
struct omap_dss_device *dssdev = &dsi->output;
+ cancel_delayed_work_sync(&dsi->dsi_disable_work);
+
dsi_bus_lock(dsi);
dsi->video_enabled = false;
@@ -4835,6 +4860,18 @@ static const struct soc_device_attribute
dsi_soc_devices[] = {
{ /* sentinel */ }
};
+static void omap_dsi_disable_work_callback(struct work_struct *work)
+{
+ struct dsi_data *dsi = container_of(work, struct dsi_data,
dsi_disable_work.work);
+
+ dsi_bus_lock(dsi);
+
+ if (dsi->iface_enabled && !dsi->video_enabled)
+ dsi_disable(dsi);
+
+ dsi_bus_unlock(dsi);
+}
+
static int dsi_probe(struct platform_device *pdev)
{
const struct soc_device_attribute *soc;
@@ -4868,6 +4905,8 @@ static int dsi_probe(struct platform_device *pdev)
INIT_DEFERRABLE_WORK(&dsi->framedone_timeout_work,
dsi_framedone_timeout_work_callback);
+ INIT_DEFERRABLE_WORK(&dsi->dsi_disable_work,
omap_dsi_disable_work_callback);
+
#ifdef DSI_CATCH_MISSING_TE
timer_setup(&dsi->te_timer, dsi_te_timeout, 0);
#endif
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.h
b/drivers/gpu/drm/omapdrm/dss/dsi.h
index 452cee3279db..805f9073d9a5 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.h
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.h
@@ -391,6 +391,7 @@ struct dsi_data {
atomic_t do_ext_te_update;
bool te_enabled;
+ bool iface_enabled;
bool video_enabled;
struct delayed_work framedone_timeout_work;
@@ -440,6 +441,8 @@ struct dsi_data {
struct omap_dss_device output;
struct drm_bridge b
Re: [PATCH v3 1/6] drm: bridge: Propagate the bus flags from bridge->timings
On 30/11/2020 11:36, Laurent Pinchart wrote: > Hi Nikhil, > > Thank you for the patch. > > On Thu, Nov 19, 2020 at 09:31:29PM +0530, Nikhil Devshatwar wrote: >> bus_flags can be specified by a bridge in the timings. >> If the bridge provides it, Override the bus_flags when propagating >> from next bridge. >> >> Signed-off-by: Nikhil Devshatwar >> Reviewed-by: Tomi Valkeinen >> --- >> >> Notes: >> changes from v2: >> * update comment >> changes from v1: >> * Check for timings >> * Prioritize timings flags over next bridge's flags >> >> drivers/gpu/drm/drm_bridge.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c >> index 64f0effb52ac..13b67fc0dad3 100644 >> --- a/drivers/gpu/drm/drm_bridge.c >> +++ b/drivers/gpu/drm/drm_bridge.c >> @@ -975,6 +975,14 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge >> *bridge, >> * duplicate the "dummy propagation" logic. >> */ >> bridge_state->input_bus_cfg.flags = output_flags; >> + >> +/* >> + * If legacy bus flags are provided in bridge->timings, use those as >> + * input flags instead of propagating the output flags. >> + */ >> +if (bridge->timings && bridge->timings->input_bus_flags) >> +bridge_state->input_bus_cfg.flags = >> +bridge->timings->input_bus_flags; > > Hasn't Boris commented in his review of v1 that bus flags should be set > in atomic_check, even when they're static ? We're moving towards > removing timings->input_bus_flags, so this patch goes in the wrong > direction :-S We have atomic_check only if the bridge has implemented atomic funcs. And even if there's atomic_check, not all bridges set the bus_flags there. So we need to either 1) fix the issue for now as in this patch, or 2) convert all bridges to use atomic funcs and fix all the bridges to set the bus_flags. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: bridge: Propagate the bus flags from bridge->timings
On 30/11/2020 11:47, Laurent Pinchart wrote: >>> Hasn't Boris commented in his review of v1 that bus flags should be set >>> in atomic_check, even when they're static ? We're moving towards >>> removing timings->input_bus_flags, so this patch goes in the wrong >>> direction :-S >> >> We have atomic_check only if the bridge has implemented atomic funcs. And >> even if there's >> atomic_check, not all bridges set the bus_flags there. So we need to either >> 1) fix the issue for now >> as in this patch, or 2) convert all bridges to use atomic funcs and fix all >> the bridges to set the >> bus_flags. > > The second option is what we'd like to achieve. Wouldn't it be best to > already start going in that direction ? We don't need to convert all > bridge drivers in one go here, just the ones that are used by tidss. I think that sounds fine, except that this is blocking the DisplayPort support for J7. We have everything in for DP except dts changes (can be added only when the drivers work), and the connector stuff. The connector stuff includes this series (so that tidss supports the new connector model), and "[PATCH RESEND v3 0/2] drm: add DisplayPort connector", which adds the connector driver. The bridges currently used (that I know of) with tidss are cdns-mhdp, tfp410 and sii9022. I don't expect converting those would be a huge job, but I'd still really like to get the DP working in upstream without starting to expand the scope of the patches we need to enable it. That said, we missed 5.11 so perhaps we have the time. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: bridge: Propagate the bus flags from bridge->timings
On 30/11/2020 12:02, Tomi Valkeinen wrote: > On 30/11/2020 11:47, Laurent Pinchart wrote: > Hasn't Boris commented in his review of v1 that bus flags should be set in atomic_check, even when they're static ? We're moving towards removing timings->input_bus_flags, so this patch goes in the wrong direction :-S >>> >>> We have atomic_check only if the bridge has implemented atomic funcs. And >>> even if there's >>> atomic_check, not all bridges set the bus_flags there. So we need to either >>> 1) fix the issue for now >>> as in this patch, or 2) convert all bridges to use atomic funcs and fix all >>> the bridges to set the >>> bus_flags. >> >> The second option is what we'd like to achieve. Wouldn't it be best to >> already start going in that direction ? We don't need to convert all >> bridge drivers in one go here, just the ones that are used by tidss. > > I think that sounds fine, except that this is blocking the DisplayPort > support for J7. We have > everything in for DP except dts changes (can be added only when the drivers > work), and the connector > stuff. > > The connector stuff includes this series (so that tidss supports the new > connector model), and > "[PATCH RESEND v3 0/2] drm: add DisplayPort connector", which adds the > connector driver. > > The bridges currently used (that I know of) with tidss are cdns-mhdp, tfp410 > and sii9022. I don't > expect converting those would be a huge job, but I'd still really like to get > the DP working in > upstream without starting to expand the scope of the patches we need to > enable it. > > That said, we missed 5.11 so perhaps we have the time. Looks like Boris was missing from Cc in this series. Adding him. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm: add legacy support for using degamma for gamma
On Mon, Nov 30, 2020 at 02:12:39PM +0200, Tomi Valkeinen wrote:
> On 30/11/2020 12:38, Laurent Pinchart wrote:
>
> >> + * can be used when the driver exposes either only GAMMA_LUT or both
> >> GAMMA_LUT
> >> + * and DEGAMMA_LUT.
> >> + */
> >> +int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >> + u16 *red, u16 *green, u16 *blue,
> >> + uint32_t size,
> >> + struct drm_modeset_acquire_ctx *ctx)
> >> +{
> >> + return legacy_gamma_degamma_set(crtc, red, green, blue, size, ctx,
> >> false);
> >> +}
> >
> > I wonder, would it make sense to make this automatic by setting the
> > degamma LUT when only the DEGAMMA_LUT property exists, and the gamma LUT
> > otherwise ? Are there use cases for drm_atomic_helper_legacy_degamma_set
> > for drivers that support both gamma and degamma ?
>
> Yes, I think drm_atomic_helper_legacy_gamma_set() could do that.
>
> But if you look at the second patch, the driver deals with
> crtc_state->degamma_lut. Having
> .gamma_set = drm_atomic_helper_legacy_degamma_set makes it bit more explicit
> and clear what the
> driver is doing.
>
> That said, documenting what drm_atomic_helper_legacy_gamma_set does if
> there's only degamma should
> also be clear enough, so... I don't have strong feelings either way =).
The thing is, the legacy helpers should be able to pull off what userspace
needs to do when it's using atomic anyway. Hard-coding information in the
kernel means we have a gap here. Hence imo legacy helpers doing the right
thing in all reasonable cases is imo better.
In many cases I think we should even go further, and ditch driver ability
to overwrite legacy helper hooks like this. I thought we'd need that
flexibility for legacy userspace being incompatible in awkward ways, but
wasn't ever really needed. Worse, many drivers forget to wire up the
compat hooks.
tldr, imo right thing to do here:
- move legacy gamma function from helpers into core code
- call it unconditionally for all atomic drivers (if there's no legacy
drivers using the hook left then we can outright remove it)
- make sure it dtrt in all cases
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On Fri, Nov 27, 2020 at 11:04:55AM -0500, Andrey Grodzovsky wrote: > > On 11/27/20 9:59 AM, Daniel Vetter wrote: > > On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote: > > > On 11/25/20 11:36 AM, Daniel Vetter wrote: > > > > On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote: > > > > > Am 25.11.20 um 11:40 schrieb Daniel Vetter: > > > > > > On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König wrote: > > > > > > > Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky: > > > > > > > > On 11/24/20 2:41 AM, Christian König wrote: > > > > > > > > > Am 23.11.20 um 22:08 schrieb Andrey Grodzovsky: > > > > > > > > > > On 11/23/20 3:41 PM, Christian König wrote: > > > > > > > > > > > Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky: > > > > > > > > > > > > On 11/23/20 3:20 PM, Christian König wrote: > > > > > > > > > > > > > Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: > > > > > > > > > > > > > > On 11/25/20 5:42 AM, Christian König wrote: > > > > > > > > > > > > > > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: > > > > > > > > > > > > > > > > It's needed to drop iommu backed pages on > > > > > > > > > > > > > > > > device unplug > > > > > > > > > > > > > > > > before device's IOMMU group is released. > > > > > > > > > > > > > > > It would be cleaner if we could do the whole > > > > > > > > > > > > > > > handling in TTM. I also need to double check > > > > > > > > > > > > > > > what you are doing with this function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > > > > > > > Check patch "drm/amdgpu: Register IOMMU topology > > > > > > > > > > > > > > notifier per device." to see > > > > > > > > > > > > > > how i use it. I don't see why this should go > > > > > > > > > > > > > > into TTM mid-layer - the stuff I do inside > > > > > > > > > > > > > > is vendor specific and also I don't think TTM is > > > > > > > > > > > > > > explicitly aware of IOMMU ? > > > > > > > > > > > > > > Do you mean you prefer the IOMMU notifier to be > > > > > > > > > > > > > > registered from within TTM > > > > > > > > > > > > > > and then use a hook to call into vendor specific > > > > > > > > > > > > > > handler ? > > > > > > > > > > > > > No, that is really vendor specific. > > > > > > > > > > > > > > > > > > > > > > > > > > What I meant is to have a function like > > > > > > > > > > > > > ttm_resource_manager_evict_all() which you only need > > > > > > > > > > > > > to call and all tt objects are unpopulated. > > > > > > > > > > > > So instead of this BO list i create and later iterate in > > > > > > > > > > > > amdgpu from the IOMMU patch you just want to do it > > > > > > > > > > > > within > > > > > > > > > > > > TTM with a single function ? Makes much more sense. > > > > > > > > > > > Yes, exactly. > > > > > > > > > > > > > > > > > > > > > > The list_empty() checks we have in TTM for the LRU are > > > > > > > > > > > actually not the best idea, we should now check the > > > > > > > > > > > pin_count instead. This way we could also have a list of > > > > > > > > > > > the > > > > > > > > > > > pinned BOs in TTM. > > > > > > > > > > So from my IOMMU topology handler I will iterate the TTM > > > > > > > > > > LRU for > > > > > > > > > > the unpinned BOs and this new function for the pinned ones > > > > > > > > > > ? > > > > > > > > > > It's probably a good idea to combine both iterations into > > > > > > > > > > this > > > > > > > > > > new function to cover all the BOs allocated on the device. > > > > > > > > > Yes, that's what I had in my mind as well. > > > > > > > > > > > > > > > > > > > > BTW: Have you thought about what happens when we > > > > > > > > > > > unpopulate > > > > > > > > > > > a BO while we still try to use a kernel mapping for it? > > > > > > > > > > > That > > > > > > > > > > > could have unforeseen consequences. > > > > > > > > > > Are you asking what happens to kmap or vmap style mapped CPU > > > > > > > > > > accesses once we drop all the DMA backing pages for a > > > > > > > > > > particular > > > > > > > > > > BO ? Because for user mappings > > > > > > > > > > (mmap) we took care of this with dummy page reroute but > > > > > > > > > > indeed > > > > > > > > > > nothing was done for in kernel CPU mappings. > > > > > > > > > Yes exactly that. > > > > > > > > > > > > > > > > > > In other words what happens if we free the ring buffer while > > > > > > > > > the > > > > > > > > > kernel still writes to it? > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > While we can't control user application accesses to the mapped > > > > > > > > buffers > > > > > > > > explicitly and hence we use page fault rerouting > > > > > > > > I am thinking that in this case we may be able to sprinkle > > > > > > > > drm_dev_enter/exit in any such sensitive place were we might > > > > > > > > CPU access a DMA buffer from the kernel ? > > > > > > > Yes, I fear we are going to need that. > > > > > > Uh ... problem is that dma_buf_vmap a
Re: [PATCH v2 5/5] drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Hi Tomi,
On Mon, Nov 30, 2020 at 01:53:25PM +0200, Tomi Valkeinen wrote:
> On 30/11/2020 12:50, Laurent Pinchart wrote:
> > On Tue, Nov 03, 2020 at 10:03:10AM +0200, Tomi Valkeinen wrote:
> >> From: Jyri Sarha
> >>
> >> Adds support for COLOR_ENCODING and COLOR_RANGE properties to
> >> omap_plane.c and dispc.c. The supported encodings and ranges are
> >> presets are:
> >>
> >> For COLOR_ENCODING:
> >> - YCbCr BT.601 (default)
> >> - YCbCr BT.709
> >>
> >> For COLOR_RANGE:
> >> - YCbCr limited range
> >> - YCbCr full range (default)
> >>
> >> Signed-off-by: Jyri Sarha
> >> Signed-off-by: Tomi Valkeinen
> >> ---
> >> drivers/gpu/drm/omapdrm/dss/dispc.c | 104 --
> >> drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
> >> drivers/gpu/drm/omapdrm/omap_plane.c | 30
> >> 3 files changed, 97 insertions(+), 41 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> index 48593932bddf..bf0c9d293077 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> @@ -874,50 +874,67 @@ static void dispc_ovl_write_color_conv_coef(struct
> >> dispc_device *dispc,
> >> #undef CVAL
> >> }
> >>
> >> -static void dispc_wb_write_color_conv_coef(struct dispc_device *dispc,
> >> - const struct csc_coef_rgb2yuv *ct)
> >> -{
> >> - const enum omap_plane_id plane = OMAP_DSS_WB;
> >> -
> >> -#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> >> +/* YUV -> RGB, ITU-R BT.601, full range */
> >> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
> >> + 256, 0, 358, /* ry, rcb, rcr |1.000 0.000 1.402|*/
> >> + 256, -88, -182, /* gy, gcb, gcr |1.000 -0.344 -0.714|*/
> >> + 256, 452,0, /* by, bcb, bcr |1.000 1.772 0.000|*/
> >> + true, /* full range */
> >> +};
> >>
> >> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct->yg,
> >> ct->yr));
> >> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct->crr,
> >> ct->yb));
> >> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct->crb,
> >> ct->crg));
> >> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct->cbg,
> >> ct->cbr));
> >> - dispc_write_reg(dispc, DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct->cbb));
> >> +/* YUV -> RGB, ITU-R BT.601, limited range */
> >> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> >> + 298,0, 409,/* ry, rcb, rcr |1.164 0.000 1.596|*/
> >> + 298, -100, -208,/* gy, gcb, gcr |1.164 -0.392 -0.813|*/
> >> + 298, 516,0,/* by, bcb, bcr |1.164 2.017 0.000|*/
> >> + false, /* limited range */
> >> +};
> >>
> >> - REG_FLD_MOD(dispc, DISPC_OVL_ATTRIBUTES(plane), ct->full_range, 11, 11);
> >> +/* YUV -> RGB, ITU-R BT.709, full range */
> >> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_full = {
> >> + 256,0, 402,/* ry, rcb, rcr |1.000 0.000 1.570|*/
> >> + 256, -48, -120,/* gy, gcb, gcr |1.000 -0.187 -0.467|*/
> >> + 256, 475,0,/* by, bcb, bcr |1.000 1.856 0.000|*/
> >> + true, /* full range */
> >> +};
> >>
> >> -#undef CVAL
> >> -}
> >> +/* YUV -> RGB, ITU-R BT.709, limited range */
> >> +static const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_lim = {
> >> + 298,0, 459,/* ry, rcb, rcr |1.164 0.000 1.793|*/
> >> + 298, -55, -136,/* gy, gcb, gcr |1.164 -0.213 -0.533|*/
> >> + 298, 541,0,/* by, bcb, bcr |1.164 2.112 0.000|*/
> >> + false, /* limited range */
> >> +};
> >>
> >> -static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
> >> +static int dispc_ovl_set_csc(struct dispc_device *dispc,
> >> + enum omap_plane_id plane,
> >> + enum drm_color_encoding color_encoding,
> >> + enum drm_color_range color_range)
> >> {
> >> - int i;
> >> - int num_ovl = dispc_get_num_ovls(dispc);
> >> -
> >> - /* YUV -> RGB, ITU-R BT.601, limited range */
> >> - const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
> >> - 298,0, 409,/* ry, rcb, rcr */
> >> - 298, -100, -208,/* gy, gcb, gcr */
> >> - 298, 516,0,/* by, bcb, bcr */
> >> - false, /* limited range */
> >> - };
> >> + const struct csc_coef_yuv2rgb *csc;
> >>
> >> - /* RGB -> YUV, ITU-R BT.601, limited range */
> >> - const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
> >> - 66, 129, 25, /* yr, yg, yb */
> >> - -38, -74, 112, /* cbr, cbg, cbb */
> >> - 112, -94, -18, /* crr, crg, crb */
> >> - false, /* limited range */
> >> - };
> >> + switch (color_encoding) {
> >> + case DRM_COLOR_YCBCR_BT601:
> >> + if (col
Re: [PATCH v2 19/28] video: fbdev: sstfb: Updated logging to fix set but not used warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix set but not used warnings by introducing no_printk variants
for the internal logging system for this driver.
Fix a new warning that popped up now that logging was checked for
correct printf format strings.
A more invasive fix had been to replace all the internal logging with
standard logging primitives - thats for another day.
v2:
- Update subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz
Cc: Alex Dewar
Cc: Jani Nikula
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/sstfb.c | 2 +-
include/video/sstfb.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
index c05cdabeb11c..27d4b0ace2d6 100644
--- a/drivers/video/fbdev/sstfb.c
+++ b/drivers/video/fbdev/sstfb.c
@@ -1390,7 +1390,7 @@ static int sstfb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
fix->smem_start, info->screen_base,
fix->smem_len >> 20);
- f_ddprintk("regbase_virt: %#lx\n", par->mmio_vbase);
+ f_ddprintk("regbase_virt: %p\n", par->mmio_vbase);
f_ddprintk("membase_phys: %#lx\n", fix->smem_start);
f_ddprintk("fbbase_virt: %p\n", info->screen_base);
diff --git a/include/video/sstfb.h b/include/video/sstfb.h
index 28384f354773..d4a5e41d1173 100644
--- a/include/video/sstfb.h
+++ b/include/video/sstfb.h
@@ -23,7 +23,7 @@
# define SST_DEBUG_FUNC 1
# define SST_DEBUG_VAR 1
#else
-# define dprintk(X...)
+# define dprintk(X...)no_printk(X)
# define SST_DEBUG_REG 0
# define SST_DEBUG_FUNC 0
# define SST_DEBUG_VAR 0
@@ -48,7 +48,7 @@
#if (SST_DEBUG_FUNC > 1)
# define f_ddprintk(X...)dprintk(" " X)
#else
-# define f_ddprintk(X...)
+# define f_ddprintk(X...) no_printk(X)
#endif
#if (SST_DEBUG_FUNC > 2)
# define f_dddprintk(X...) dprintk(" " X)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn
So I guess kvm platforms that don't set KVM_ARCH_WANT_MMU_NOTIFIER exist, and at least on powerpc they're consistent with KVM_CAP_SYNC_MMU signalling that the guest pagetables stays in sync automatically with any updates. So for that case I guess we could use unsafe_follow_pfn. But on s390 this seems different: No mmu notifier, but KVM_CAP_SYNC_MMU is set. So I guess there's some hardware magic on s390 that I don't know about. Not sure what to do with this now here ... -Daniel On Sat, Nov 28, 2020 at 03:10:40AM +0800, kernel test robot wrote: > Hi Daniel, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linuxtv-media/master] > [also build test ERROR on char-misc/char-misc-testing v5.10-rc5] > [cannot apply to hnaz-linux-mm/master next-20201127] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 > base: git://linuxtv.org/media_tree.git master > config: s390-randconfig-r032-20201127 (attached as .config) > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project > f095ac11a9550530a4a54298debb8b04b36422be) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install s390 cross compiling tool for clang build > # apt-get install binutils-s390x-linux-gnu > # > https://github.com/0day-ci/linux/commit/d76a3489433ce67d45da86aa12953385427f0ac9 > git remote add linux-review https://github.com/0day-ci/linux > git fetch --no-tags linux-review > Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 > git checkout d76a3489433ce67d45da86aa12953385427f0ac9 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >In file included from arch/s390/include/asm/kvm_para.h:25: >In file included from arch/s390/include/asm/diag.h:12: >In file included from include/linux/if_ether.h:19: >In file included from include/linux/skbuff.h:31: >In file included from include/linux/dma-mapping.h:10: >In file included from include/linux/scatterlist.h:9: >In file included from arch/s390/include/asm/io.h:80: >include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on > a null pointer has undefined behavior [-Wnull-pointer-arithmetic] >val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + > addr)); >~~ ^ >include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro > '__le32_to_cpu' >#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) > ^ >include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' >___constant_swab32(x) : \ > ^ >include/uapi/linux/swab.h:21:12: note: expanded from macro > '___constant_swab32' >(((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ > ^ >In file included from arch/s390/kvm/../../../virt/kvm/kvm_main.c:18: >In file included from include/linux/kvm_host.h:32: >In file included from include/linux/kvm_para.h:5: >In file included from include/uapi/linux/kvm_para.h:36: >In file included from arch/s390/include/asm/kvm_para.h:25: >In file included from arch/s390/include/asm/diag.h:12: >In file included from include/linux/if_ether.h:19: >In file included from include/linux/skbuff.h:31: >In file included from include/linux/dma-mapping.h:10: >In file included from include/linux/scatterlist.h:9: >In file included from arch/s390/include/asm/io.h:80: >include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on > a null pointer has undefined behavior [-Wnull-pointer-arithmetic] >val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + > addr)); >~~ ^ >include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro > '__le32_to_cpu' >#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) > ^ >include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' >___constant_swab32(x) : \ > ^ >include/uapi/linux/swab.h:22:12: note: expanded from macro > '___constant_swab32'
Re: [PATCH] fbdev: Remove udlfb driver
On Mon, 30 Nov 2020, Thomas Zimmermann wrote: > Udlfb has been superseded by DRM's udl. The DRM driver is better by > any means and actively maintained. Remove udlfb. Hi I am using udlfb and it's definitely better than the DRM driver. The DRM driver will crash the kernel if you unplug the device while Xorg is running. The framebuffer driver doesn't crash in this case. (I have a cat and the cat sometimes unplugs cables and I don't want to reboot the system because of it :-) The framebuffer driver is faster, it keeps back buffer and updates only data that differ between the front and back buffer. The DRM driver doesn't have such optimization, it will update everything in a given rectangle - this increases USB traffic and makes video playback more jerky. The framebuffer driver supports programs running full-screen directly on the framebuffer console, such as web browser "links -g", image viewer "fbi", postscript+pdf viewer "fbgs", ZX Spectrum emulator "fuse-sdl", movie player "mplayer -vo fbdev". The DRM driver doesn't run them. If you seach for someone to maintain the framebuffer driver, I can do it. Mikulas > Signed-off-by: Thomas Zimmermann > --- > CREDITS |5 + > Documentation/fb/index.rst |1 - > Documentation/fb/udlfb.rst | 162 --- > MAINTAINERS |9 - > drivers/video/fbdev/Kconfig | 17 +- > drivers/video/fbdev/Makefile |1 - > drivers/video/fbdev/udlfb.c | 1994 -- > 7 files changed, 6 insertions(+), 2183 deletions(-) > delete mode 100644 Documentation/fb/udlfb.rst > delete mode 100644 drivers/video/fbdev/udlfb.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Fix error return code in psb_driver_load()
On Mon, Nov 30, 2020 at 10:02:16AM +0800, Jialin Zhang wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
> Reported-by: Hulk Robot
> Signed-off-by: Jialin Zhang
Out of curiosity, what is hulk robot matching here? This is a really
interesting bug for automated checkers to find!
Thanks for the patch, applied to drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 34b4aae9a15e..074f403d7ca0 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -313,6 +313,8 @@ static int psb_driver_load(struct drm_device *dev,
> unsigned long flags)
> if (ret)
> goto out_err;
>
> + ret = -ENOMEM;
> +
> dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
> if (!dev_priv->mmu)
> goto out_err;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings
On Mon, Nov 2, 2020 at 3:19 AM Paul Cercueil wrote: > > > > Le dim. 1 nov. 2020 à 13:29, Sam Ravnborg a écrit : > > On Sun, Nov 01, 2020 at 09:31:48AM +, Paul Cercueil wrote: > >> The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" 320x480 > >> 24-bit IPS LCD panel. Its particularity is that it has non-square > >> pixels > >> (as it is 4:3 for a resolution of 320x480), and that it requires odd > >> lines to be sent as RGB and even lines to be sent as GRB on its > >> 8-bit > >> bus. > >> > >> Signed-off-by: Paul Cercueil > >> --- > >> .../display/panel/abt,y030xx067a.yaml | 54 > >> +++ > >> 1 file changed, 54 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml > >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml > >> new file mode 100644 > >> index ..6407e8bf45fa > >> --- /dev/null > >> +++ > >> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml > >> @@ -0,0 +1,54 @@ > >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: > >> http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD > >> panel > >> + > >> +description: | > >> + The panel must obey the rules for a SPI slave device as > >> specified in > >> + spi/spi-controller.yaml > >> + > >> +maintainers: > >> + - Paul Cercueil > >> + > >> +allOf: > >> + - $ref: panel-common.yaml# > >> + > >> +properties: > >> + compatible: > >> +const: abt,y030xx067a > >> + > >> + backlight: true > >> + port: true > >> + power-supply: true > >> + reg: true > >> + reset-gpios: true > > > > The binding is missing: > > required: > > - compatible > > - reg > > - power-supply > > - reset-gpios > > - ... > > > > additionalProperties: false > > > > So r-b only with these added. > > Stupid mistake, sorry about that. > > I'll V2. I don't have any V2 in my inbox, but looks like it is in linux-next now: /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.example.dt.yaml: panel@0: 'spi-max-frequency' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 20/28] video: fbdev: nvidia: Fix set but not used warnings
Hi
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix warnings by deleting unused code. The register reads are
kept as it is unknown if there are any hidden side-effects.
v2:
- Update subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
Cc: Lee Jones
---
drivers/video/fbdev/nvidia/nv_setup.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c
b/drivers/video/fbdev/nvidia/nv_setup.c
index 2fa68669613a..5404017e6957 100644
--- a/drivers/video/fbdev/nvidia/nv_setup.c
+++ b/drivers/video/fbdev/nvidia/nv_setup.c
@@ -89,9 +89,8 @@ u8 NVReadSeq(struct nvidia_par *par, u8 index)
}
void NVWriteAttr(struct nvidia_par *par, u8 index, u8 value)
{
- volatile u8 tmp;
- tmp = VGA_RD08(par->PCIO, par->IOBase + 0x0a);
+ VGA_RD08(par->PCIO, par->IOBase + 0x0a);
This again looks like it sets up the attribute register. I hope this
isn't optimized away now.
Acked-by: Thomas Zimmermann
if (par->paletteEnabled)
index &= ~0x20;
else
@@ -101,9 +100,7 @@ void NVWriteAttr(struct nvidia_par *par, u8 index, u8 value)
}
u8 NVReadAttr(struct nvidia_par *par, u8 index)
{
- volatile u8 tmp;
-
- tmp = VGA_RD08(par->PCIO, par->IOBase + 0x0a);
+ VGA_RD08(par->PCIO, par->IOBase + 0x0a);
if (par->paletteEnabled)
index &= ~0x20;
else
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 21/28] video: fbdev: tmiofb: Fix set but not used warnings
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix W=1 warnings by avoiding local variables and use direct references.
What's the bug here?
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Lee Jones
---
drivers/video/fbdev/tmiofb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/tmiofb.c b/drivers/video/fbdev/tmiofb.c
index 50111966c981..b70faa3850f2 100644
--- a/drivers/video/fbdev/tmiofb.c
+++ b/drivers/video/fbdev/tmiofb.c
@@ -802,10 +802,8 @@ static int tmiofb_remove(struct platform_device *dev)
const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
- struct tmiofb_par *par;
if (info) {
- par = info->par;
unregister_framebuffer(info);
tmiofb_hw_stop(dev);
@@ -816,8 +814,8 @@ static int tmiofb_remove(struct platform_device *dev)
free_irq(irq, info);
iounmap(info->screen_base);
- iounmap(par->lcr);
- iounmap(par->ccr);
+ iounmap(((struct tmiofb_par *)info->par)->lcr);
+ iounmap(((struct tmiofb_par *)info->par)->ccr);
framebuffer_release(info);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
