Re: [PATCH 1/7] drm/komeda: Add d71_enum_resources and d71_cleanup
On 2019/1/7, 9:41 PM, "Brian Starkey" wrote:
Hi James,
A few minor comments.
On Mon, Dec 24, 2018 at 08:58:46AM +, james qian wang (Arm Technology
China) wrote:
> D71 consists of a number of Register Blocks, every Block controls a
> specific HW function, every block has a common block_header to represent
> its type and pipeline information.
>
> GCU (Global Control Unit) is the first Block which describe the global
> information of D71 HW, Like number of block contained and the number of
> pipeline supported.
>
> So the d71_enum_resources parsed GCU and create pipeline according
> the GCU configuration, and then iterate and detect the blocks that
> indicated by the GCU and block_header.
>
> And this change also added two struct d71_dev/d71_pipeline to extend
> komeda_dev/komeda_pipeline to add some d71 only members.
>
> Signed-off-by: James (Qian) Wang
> ---
-- snip --
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> new file mode 100644
> index ..a43a2410159f
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -0,0 +1,120 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> + * Author: James.Qian.Wang
> + *
> + */
> +#include "d71_dev.h"
> +#include "komeda_kms.h"
> +#include "malidp_io.h"
> +
> +static int d71_layer_init(struct d71_dev *d71,
> + struct block_header *blk, u32 __iomem *reg)
> +{
> + DRM_INFO("Detect D71_Layer.\n");
I think all of these can be DRM_DEBUG.
-- snip --
Will fix it on the next version.
>
> static int d71_enum_resources(struct komeda_dev *mdev)
> {
> - /* TODO add enum resources */
> + struct d71_dev *d71;
> + struct komeda_pipeline *pipe;
> + struct block_header blk;
> + u32 __iomem *blk_base;
> + u32 i, value, offset;
> +
> + d71 = devm_kzalloc(mdev->dev, sizeof(*d71), GFP_KERNEL);
> + if (!d71)
> + return -ENOMEM;
> +
> + mdev->chip_data = d71;
> + d71->mdev = mdev;
> + d71->gcu_addr = mdev->reg_base;
> + d71->periph_addr = mdev->reg_base + (D71_BLOCK_OFFSET_PERIPH >> 2);
> +
> + if (d71_reset(d71)) {
> + DRM_ERROR("Fail to reset d71 device.\n");
> + goto err_cleanup;
> + }
> +
> + /* probe GCU */
> + value = malidp_read32(d71->gcu_addr, GLB_CORE_INFO);
> + d71->num_blocks = value & 0xFF;
> + d71->num_pipelines = (value >> 8) & 0x7;
> +
> + if (d71->num_pipelines > D71_MAX_PIPELINE) {
> + DRM_ERROR("d71 supports %d pipelines, but got: %d.\n",
> + D71_MAX_PIPELINE, d71->num_pipelines);
> + goto err_cleanup;
> + }
> +
> + /* probe PERIPH */
> + value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
> + if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
> + DRM_ERROR("access blk periph but got blk: %d.\n",
> + BLOCK_INFO_BLK_TYPE(value));
> + goto err_cleanup;
> + }
> +
> + value = malidp_read32(d71->periph_addr, PERIPH_CONFIGURATION_ID);
> +
> + d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 : 2048;
> + d71->max_vsize = 4096;
> + d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 1;
> + d71->supports_dual_link = value & PERIPH_SPLIT_EN ? true : false;
> + d71->integrates_tbu = value & PERIPH_TBU_EN ? true : false;
> +
> + for (i = 0; i < d71->num_pipelines; i++) {
> + pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
> +NULL);
> + if (!pipe)
> + goto err_cleanup;
> +
> + d71->pipes[i] = to_d71_pipeline(pipe);
> + }
> +
> + /* loop the register blks and probe */
> + i = 2; /* exclude GCU and PERIPH */
> + offset = D71_BLOCK_SIZE; /* skip GCU */
> + while (i < d71->num_blocks) {
> + blk_base = mdev->reg_base + (offset >> 2);
> +
> + d71_read_block_header(blk_base, &blk);
> + if (BLOCK_INFO_BLK_TYPE(blk.block_info) !=
D71_BLK_TYPE_RESERVED) {
> + if (d71_probe_block(d71, &blk, blk_base))
> + goto err_cleanup;
> + i++;
> + }
> +
> + offset += D71_BLOCK_SIZE;
> + }
> +
> + DRM_INFO("total %d (out of %d) blocks are found.\n",
> + i, d71->num_blocks);
> +
> + return 0;
> +
> +err_cleanup:
> + d71_cleanup(mdev);
> return -1;
-1 isn't a useful error code, and you return -ENOMEM if allocation
fails.
Re: [PATCH v6] gpu: ipu-csi: Swap fields according to input/output field types
Please disregard. This patch can't be submitted stand-alone, I will
re-submit as part of a v6 of "imx-media: Fixes for interlaced capture"
patchset.
Steve
On 12/14/18 3:46 PM, Steve Longerbeam wrote:
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
csi_setup(), suggested by Philipp.
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 126 +++---
drivers/staging/media/imx/imx-media-csi.c | 7 +-
include/video/imx-ipu-v3.h| 5 +-
3 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+ const struct v4l2_mbus_config *mbus_cfg,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
{
int ret;
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
return 0;
}
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ const struct v4l2_mbus_framefmt *infmt,
+ const struct v4l2_mbus_framefmt *outfmt,
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CC
[PATCH] qxl: Use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc21..c8642712412e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -48,8 +48,8 @@ static int qxl_alloc_client_monitors_config(struct qxl_device
*qdev,
}
if (!qdev->client_monitors_config) {
qdev->client_monitors_config = kzalloc(
- sizeof(struct qxl_monitors_config) +
- sizeof(struct qxl_head) * count, GFP_KERNEL);
+ struct_size(qdev->client_monitors_config,
+ heads, count), GFP_KERNEL);
if (!qdev->client_monitors_config)
return -ENOMEM;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/msm/gpu: fix building without debugfs
> Subject: [PATCH 2/2] drm/msm/gpu: fix building without debugfs
>
> When debugfs is disabled, but coredump is turned on, the adreno driver fails
> to
> build:
>
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:4: error: 'struct msm_gpu_funcs'
> has no member named 'show'
>.show = adreno_show,
> ^~~~
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:11: note: (near initialization for
> 'funcs.base')
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:11: error: initialization of 'void
> (*)(struct msm_gpu *, struct msm_gem_submit *, struct msm_file_private *)'
> from incompatible pointer type 'void (*)(struct msm_gpu *, struct
> msm_gpu_state *, struct drm_printer *)' [-Werror=incompatible-pointer-types]
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:11: note: (near initialization for
> 'funcs.base.submit')
> drivers/gpu/drm/msm/adreno/a4xx_gpu.c:546:4: error: 'struct msm_gpu_funcs'
> has no member named 'show'
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:1460:4: error: 'struct
> msm_gpu_funcs' has no member named 'show'
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c:769:4: error: 'struct msm_gpu_funcs'
> has no member named 'show'
> drivers/gpu/drm/msm/msm_gpu.c: In function 'msm_gpu_devcoredump_read':
> drivers/gpu/drm/msm/msm_gpu.c:289:12: error: 'const struct msm_gpu_funcs'
> has no member named 'show'
>
> Adjust the #ifdef to make it build again.
Was this patch picked up by someone? I am asking this since the compile error
can be still seen in 5.0-rc1.
Ioana
>
> Fixes: c0fec7f562ec ("drm/msm/gpu: Capture the GPU state on a GPU hang")
> Signed-off-by: Arnd Bergmann
> ---
> Not sure if this does the right thing, but it does fix the build regression
> ---
> drivers/gpu/drm/msm/msm_gpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h
> b/drivers/gpu/drm/msm/msm_gpu.h
> index 9122ee6e55e4..1fe93920fb25 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -63,7 +63,7 @@ struct msm_gpu_funcs {
> struct msm_ringbuffer *(*active_ring)(struct msm_gpu *gpu);
> void (*recover)(struct msm_gpu *gpu);
> void (*destroy)(struct msm_gpu *gpu);
> -#ifdef CONFIG_DEBUG_FS
> +#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
> /* show GPU status in debugfs: */
> void (*show)(struct msm_gpu *gpu, struct msm_gpu_state *state,
> struct drm_printer *p);
> --
> 2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Require PCI for selecting VGA_ARB.
Dear Maarten, Thank you very much for the quick response. On 01/08/19 16:37, Maarten Lankhorst wrote: > Op 08-01-2019 om 16:07 schreef Paul Menzel: >> Building Linux 5.0-rc1 fails with the errors below. Please find the >> configuration file attached. >> >> ``` >> $ make -j120 >> […] >> drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’: >> drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ >> undeclared (first use in this function); did you mean >> ‘PCI_SUBTRACTIVE_DECODE’? >> flags |= PCI_VGA_STATE_CHANGE_DECODES; >> ^~~~ >> PCI_SUBTRACTIVE_DECODE >> drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is >> reported only once for each function it appears in >> CC [M] net/netfilter/xt_realm.o >> CC drivers/hid/hid-cherry.o >> drivers/gpu/vga/vga_switcheroo.c: In function >> ‘vga_switcheroo_runtime_suspend’: >> drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of >> function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’? >> [-Werror=implicit-function-declaration] >> pci_bus_set_current_state(pdev->bus, PCI_D3cold); >> ^ >> __set_current_state >> drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’ >> undeclared (first use in this function); did you mean >> ‘PCI_VGA_STATE_CHANGE_DECODES’? >> flags |= PCI_VGA_STATE_CHANGE_BRIDGE; >> ^~~ >> PCI_VGA_STATE_CHANGE_DECODES >> CC fs/reiserfs/dir.o >> LD [M] net/tipc/tipc.o >> drivers/gpu/vga/vga_switcheroo.c: In function >> ‘vga_switcheroo_runtime_resume’: >> drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of >> function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’? >> [-Werror=implicit-function-declaration] >> pci_wakeup_bus(pdev->bus); >> ^~ >> __wake_up_bit >> drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function >> ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’? >> [-Werror=implicit-function-declaration] >>pci_set_vga_state(conflict->pdev, false, pci_bits, flags); >>^ >>pci_set_power_state >> CC fs/read_write.o >> CC drivers/hid/hid-chicony.o >> CC drivers/hid/hid-cypress.o >> drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’: >> drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first >> use in this function); did you mean ‘pci_pcie_type’? >> bus_register_notifier(&pci_bus_type, &pci_notifier); >> ^~~~ >> pci_pcie_type >> cc1: some warnings being treated as errors >> make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error 1 >> make[3]: *** Waiting for unfinished jobs >> […] >> ``` > WARNING: unmet direct dependencies detected for VGA_ARB > Depends on [n]: HAS_IOMEM [=y] && PCI [=n] && !S390 > Selected by [y]: > - VGA_SWITCHEROO [=y] && HAS_IOMEM [=y] && X86 [=y] && ACPI [=y] > > So I guess you need to enable PCI, probably not a common config you're using. > :) > > Especially since you selected EXPERT. We have the attached defconfig, which is then integrated using `make olddefconfig`. > Oh well, apply this with git am --scissors? > -8< > When configuring the kernel without PCI we can still enable VGA switcheroo, > which is not possible because VGA_ARB cannot be selected. > > Remove this by depending on PCI for !S390. > > Reported-by: Paul Menzel > Signed-off-by: Maarten Lankhorst > --- > diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig > index b677e5d524e6..ef5671475870 100644 > --- a/drivers/gpu/vga/Kconfig > +++ b/drivers/gpu/vga/Kconfig > @@ -21,6 +21,7 @@ config VGA_SWITCHEROO > bool "Laptop Hybrid Graphics - GPU switching support" > depends on X86 > depends on ACPI > + depends on (PCI && !S390) # For VGA_ARB > select VGA_ARB > help > Many laptops released in 2008/9/10 have two GPUs with a multiplexer Is this an effect of commit eb01d42a (PCI: consolidate PCI config entry in drivers/pci) as the `default y` is missing now? Kind regards, Paul cat >.config <<-EOF CONFIG_LOCALVERSION="$KERNELLOCAL" CONFIG_KERNEL_BZIP2=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_AUDIT=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CGROUPS=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_BLK_CGROUP=y CONFIG_CGROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_HUGETLB=y CONFIG_CPUSETS=y CONFIG_CGROUP_DEVICE=y CONFIG_CG
[PATCH] Build etnaviv on non-ARM architectures
I wanted to test-compile etnaviv on x86 after making a tree-wide change to it. Unfortunately, Kconfig has a bad dependency, so I couldn't. Signed-off-by: Matthew Wilcox diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig index 041a77e400d4..342591a1084e 100644 --- a/drivers/gpu/drm/etnaviv/Kconfig +++ b/drivers/gpu/drm/etnaviv/Kconfig @@ -2,7 +2,7 @@ config DRM_ETNAVIV tristate "ETNAVIV (DRM support for Vivante GPU IP cores)" depends on DRM - depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST) + depends on ARCH_MXC || ARCH_DOVE || ARM || COMPILE_TEST depends on MMU select SHMEM select SYNC_FILE ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] etnaviv mailing list is moderated
Signed-off-by: Matthew Wilcox diff --git a/MAINTAINERS b/MAINTAINERS index 32d76a90..44888eb121d8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5141,7 +5141,7 @@ DRM DRIVERS FOR VIVANTE GPU IP M: Lucas Stach R: Russell King R: Christian Gmeiner -L: etna...@lists.freedesktop.org +L: etna...@lists.freedesktop.org (moderated for non-subscribers) L: dri-devel@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/etnaviv/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH resend] drm/panel: panel-innolux: set display off in innolux_panel_unprepare
Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
to innolux_panel_unprepare(), so they are consistent with
innolux_panel_enable() and innolux_panel_prepare().
This also fixes some mode check and irq timeout issue in MTK dsi code.
Since some dsi code (e.g. mtk_dsi) have following call trace:
1. drm_panel_disable(), which calls innolux_panel_disable()
2. switch to cmd mode
3. drm_panel_unprepare(), which calls innolux_panel_unprepare()
However, mtk_dsi needs to be in cmd mode to be able to send commands
(e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
so we need these functions to be called after the switch to cmd mode happens,
i.e. in innolux_panel_unprepare.
Signed-off-by: Hsin-Yi, Wang
---
Resend for review.
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index ca4ae45dd307..8e5724b63f1f 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -70,18 +70,12 @@ static inline struct innolux_panel *to_innolux_panel(struct
drm_panel *panel)
static int innolux_panel_disable(struct drm_panel *panel)
{
struct innolux_panel *innolux = to_innolux_panel(panel);
- int err;
if (!innolux->enabled)
return 0;
backlight_disable(innolux->backlight);
- err = mipi_dsi_dcs_set_display_off(innolux->link);
- if (err < 0)
- DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
- err);
-
innolux->enabled = false;
return 0;
@@ -95,6 +89,11 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
if (!innolux->prepared)
return 0;
+ err = mipi_dsi_dcs_set_display_off(innolux->link);
+ if (err < 0)
+ DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
if (err < 0) {
DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/12] gpu: ipu-v3: Add planar support to interlaced scan
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be doubled, since a single chroma line
is shared by two luma lines.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
Acked-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-cpmem.c | 26 +++--
drivers/staging/media/imx/imx-ic-prpencvf.c | 3 ++-
drivers/staging/media/imx/imx-media-csi.c | 3 ++-
include/video/imx-ipu-v3.h | 3 ++-
4 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 163fadb8a33a..d047a6867c59 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -277,9 +277,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32
u_off, u32 v_off)
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+ u32 pixelformat)
{
- u32 ilo, sly;
+ u32 ilo, sly, sluv;
if (stride < 0) {
stride = -stride;
@@ -290,9 +291,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch,
int stride)
sly = (stride * 2) - 1;
+ switch (pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ sluv = stride / 2 - 1;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ sluv = stride - 1;
+ break;
+ case V4L2_PIX_FMT_YUV422P:
+ sluv = stride - 1;
+ break;
+ case V4L2_PIX_FMT_NV16:
+ sluv = stride * 2 - 1;
+ break;
+ default:
+ sluv = 0;
+ break;
+ }
+
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
+ if (sluv)
+ ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
};
EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 28f41caba05d..af7224846bd5 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -412,7 +412,8 @@ static int prp_setup_channel(struct prp_priv *priv,
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field) &&
channel == priv->out_ch)
- ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline);
+ ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
+ image.pix.pixelformat);
ret = ipu_ic_task_idma_init(priv->ic, channel,
image.pix.width, image.pix.height,
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index c2a8d9cd31b7..da4808348845 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -512,7 +512,8 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field))
ipu_cpmem_interlaced_scan(priv->idmac_ch,
- image.pix.bytesperline);
+ image.pix.bytesperline,
+ image.pix.pixelformat);
ipu_idmac_set_double_buffer(priv->idmac_ch, true);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index bbc8481f567d..c887f4bee5f8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -258,7 +258,8 @@ void ipu_cpmem_set_stride(struct ipuv3_channel *ch, int
stride);
void ipu_cpmem_set_high_priority(struct ipuv3_channel *ch);
void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int bufnum, dma_addr_t
buf);
void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+ u32 pixelformat);
void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch);
void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
5.0-rc1 fails to build with vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ undeclared
Dear Linux folks, Building Linux 5.0-rc1 fails with the errors below. Please find the configuration file attached. ``` $ make -j120 […] drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’: drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ undeclared (first use in this function); did you mean ‘PCI_SUBTRACTIVE_DECODE’? flags |= PCI_VGA_STATE_CHANGE_DECODES; ^~~~ PCI_SUBTRACTIVE_DECODE drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is reported only once for each function it appears in CC [M] net/netfilter/xt_realm.o CC drivers/hid/hid-cherry.o drivers/gpu/vga/vga_switcheroo.c: In function ‘vga_switcheroo_runtime_suspend’: drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’? [-Werror=implicit-function-declaration] pci_bus_set_current_state(pdev->bus, PCI_D3cold); ^ __set_current_state drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’ undeclared (first use in this function); did you mean ‘PCI_VGA_STATE_CHANGE_DECODES’? flags |= PCI_VGA_STATE_CHANGE_BRIDGE; ^~~ PCI_VGA_STATE_CHANGE_DECODES CC fs/reiserfs/dir.o LD [M] net/tipc/tipc.o drivers/gpu/vga/vga_switcheroo.c: In function ‘vga_switcheroo_runtime_resume’: drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’? [-Werror=implicit-function-declaration] pci_wakeup_bus(pdev->bus); ^~ __wake_up_bit drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’? [-Werror=implicit-function-declaration] pci_set_vga_state(conflict->pdev, false, pci_bits, flags); ^ pci_set_power_state CC fs/read_write.o CC drivers/hid/hid-chicony.o CC drivers/hid/hid-cypress.o drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’: drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first use in this function); did you mean ‘pci_pcie_type’? bus_register_notifier(&pci_bus_type, &pci_notifier); ^~~~ pci_pcie_type cc1: some warnings being treated as errors make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error 1 make[3]: *** Waiting for unfinished jobs […] ``` Kind regards, Paul # # Automatically generated file; DO NOT EDIT. # Linux/x86 5.0.0-rc1 Kernel Configuration # # # Compiler: gcc (GCC) 7.3.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70300 CONFIG_CLANG_VERSION=0 CONFIG_CC_HAS_ASM_GOTO=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION=".mx64.239" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_PSI is not set CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SR
Clang warning in drivers/gpu/drm/i915/i915_debugfs.c
Hi all,
Commit e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for
DSC support/enable") causes a Clang warning:
drivers/gpu/drm/i915/i915_debugfs.c:4961:17: warning: address of array
'intel_dp->dsc_dpcd' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (intel_dp->dsc_dpcd)
~~ ~~^~~~
1 warning generated.
Did you mean to dereference it or should that print statement just
always show? I normally would send a patch myself but since I'm not
familiar with this code, I'd rather not shoot in the dark :) especially
since it's for a trivial logging statement.
Thanks,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] doc: bindings: fix bad reference to ARM CPU bindings
The primecell.txt and cpus.txt files were converted into YAML. This
patch updates old references with new ones.
Fixes: d3c207eeb905 ("dt-bindings: arm: Convert primecell binding to
json-schema")
Fixes: 672951cbd1b7 ("dt-bindings: arm: Convert cpu binding to json-schema")
Signed-off-by: Otto Sabart
---
Documentation/devicetree/bindings/arm/cpu-capacity.txt | 2 +-
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
Documentation/devicetree/bindings/arm/sp810.txt | 2 +-
Documentation/devicetree/bindings/arm/topology.txt | 2 +-
Documentation/devicetree/bindings/display/arm,pl11x.txt | 2 +-
.../devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt
b/Documentation/devicetree/bindings/arm/cpu-capacity.txt
index 84262cdb8d29..96fa46cb133c 100644
--- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt
+++ b/Documentation/devicetree/bindings/arm/cpu-capacity.txt
@@ -235,4 +235,4 @@ cpus {
===
[1] ARM Linux Kernel documentation - CPUs bindings
-Documentation/devicetree/bindings/arm/cpus.txt
+Documentation/devicetree/bindings/arm/cpus.yaml
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index 8f0937db55c5..45730ba60af5 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -684,7 +684,7 @@ cpus {
===
[1] ARM Linux Kernel documentation - CPUs bindings
-Documentation/devicetree/bindings/arm/cpus.txt
+Documentation/devicetree/bindings/arm/cpus.yaml
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.txt
diff --git a/Documentation/devicetree/bindings/arm/sp810.txt
b/Documentation/devicetree/bindings/arm/sp810.txt
index 1b2ab1ff5587..46652bf65147 100644
--- a/Documentation/devicetree/bindings/arm/sp810.txt
+++ b/Documentation/devicetree/bindings/arm/sp810.txt
@@ -4,7 +4,7 @@ SP810 System Controller
Required properties:
- compatible: standard compatible string for a Primecell peripheral,
- see Documentation/devicetree/bindings/arm/primecell.txt
+ see Documentation/devicetree/bindings/arm/primecell.yaml
for more details
should be: "arm,sp810", "arm,primecell"
diff --git a/Documentation/devicetree/bindings/arm/topology.txt
b/Documentation/devicetree/bindings/arm/topology.txt
index de9eb0486630..b0d80c0fb265 100644
--- a/Documentation/devicetree/bindings/arm/topology.txt
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -472,4 +472,4 @@ cpus {
===
[1] ARM Linux kernel documentation
-Documentation/devicetree/bindings/arm/cpus.txt
+Documentation/devicetree/bindings/arm/cpus.yaml
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt
b/Documentation/devicetree/bindings/display/arm,pl11x.txt
index ef89ab46b2c9..572fa2773ec4 100644
--- a/Documentation/devicetree/bindings/display/arm,pl11x.txt
+++ b/Documentation/devicetree/bindings/display/arm,pl11x.txt
@@ -1,6 +1,6 @@
* ARM PrimeCell Color LCD Controller PL110/PL111
-See also Documentation/devicetree/bindings/arm/primecell.txt
+See also Documentation/devicetree/bindings/arm/primecell.yaml
Required properties:
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index b83bb8249074..a3be5298a5eb 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -78,7 +78,7 @@ Sub-nodes:
PPI affinity can be expressed as a single "ppi-partitions" node,
containing a set of sub-nodes, each with the following property:
- affinity: Should be a list of phandles to CPU nodes (as described in
-Documentation/devicetree/bindings/arm/cpus.txt).
+ Documentation/devicetree/bindings/arm/cpus.yaml).
GICv3 has one or more Interrupt Translation Services (ITS) that are
used to route Message Signalled Interrupts (MSI) to the CPUs.
--
2.17.2
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 02/12] gpu: ipu-csi: Swap fields according to input/output field types
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().
Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).
When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
csi_setup(), suggested by Philipp.
Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
drivers/gpu/ipu-v3/ipu-csi.c | 126 +++---
drivers/staging/media/imx/imx-media-csi.c | 7 +-
include/video/imx-ipu-v3.h| 5 +-
3 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
return 0;
}
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+ return (field != V4L2_FIELD_ALTERNATE) ? field :
+ ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
/*
* Fill a CSI bus config struct from mbus_config and mbus_framefmt.
*/
static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+ const struct v4l2_mbus_config *mbus_cfg,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
{
int ret;
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config
*csicfg,
return 0;
}
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+ const struct v4l2_mbus_framefmt *infmt,
+ const struct v4l2_mbus_framefmt *outfmt,
+ v4l2_std_id std)
+{
+ enum v4l2_field infield, outfield;
+ bool swap_fields;
+
+ /* get translated field type of input and output */
+ infield = ipu_csi_translate_field(infmt->field, std);
+ outfield = ipu_csi_translate_field(outfmt->field, std);
+
+ /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+ swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+ V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+ infield != outfield);
+
+ if (!swap_fields) {
+ /*
+* Field0BlankEnd = 110, Field0BlankStart = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd = 111, Field1BlankStart = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+ ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+ } else {
+ dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+ /* same as above but with F-bit inverted */
+ ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+ ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+ }
+
+ ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+ return 0;
+}
+
+
int ipu_csi_init_interface(struct ipu_csi *csi,
- struct v4l2_mbus_config *mbus_cfg,
- struct v4l2_mbus_framefmt *mbus_fmt)
+
[PATCH] drm/atmel-hlcdc: prevent divide by zero
While trying to temporarily hide a plane, one thing that was attempted was to call (from libdrm) drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0, 0, 0, 0, 0, 0, 0, 0, 0); This call causes a pair of "Division by zero in kernel." messages. Kill those messages, but preserve the current behaviour that also happen to make the plane disappear with the above call. Signed-off-by: Peter Rosin --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) Side note, when comparing with drm_atomic_helper_check_plane_state(), I get the feeling that the src rect should be clipped together with the crtc rect if/when clipping is needed. That function calls drm_rect_clip_scaled(), and the equivalent does not seem to happen here. Should clipping be performed on the src rect? Cheers, Peter diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c index 3cc489b870fe..1bdb30dc218c 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -675,10 +675,16 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane *p, state->crtc_y = 0; } - patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w, - state->crtc_w); - patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h, - state->crtc_h); + if (state->crtc_w) + patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w, + state->crtc_w); + else + patched_src_w = 0; + if (state->crtc_h) + patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h, + state->crtc_h); + else + patched_src_h = 0; hsub = drm_format_horz_chroma_subsampling(fb->format->format); vsub = drm_format_vert_chroma_subsampling(fb->format->format); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/12] drm/stm: do not reply on drmP.h from drm_gem_cma_helper.h
Le mar. 8 janv. 2019 à 20:30, Sam Ravnborg a écrit : I just notice the a typo in the title of the commit message reply ->rely ? > > drmP.h was the only header file in the past and a lot > of files rely on that drmP.h defines everything. > The goal is to one day to delete drmP.h and > as a step towards this it will no longer be included in the > headers files in include/drm/ > > To prepare stm/ for this add dependencies that > othwewise was pulled in by drmP.h from drm_gem_cma_helper.h > > Sort the include list when we anyway modify it. > > Signed-off-by: Sam Ravnborg > Acked-by: Noralf Trønnes > Acked-by: Benjamin Gaignard > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Vincent Abriou > Cc: David Airlie > Cc: Daniel Vetter > --- > drivers/gpu/drm/stm/drv.c | 6 +- > drivers/gpu/drm/stm/ltdc.c | 9 - > 2 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > index 8dec001b9d37..9cd6228a18ad 100644 > --- a/drivers/gpu/drm/stm/drv.c > +++ b/drivers/gpu/drm/stm/drv.c > @@ -9,15 +9,19 @@ > */ > > #include > +#include > +#include > #include > > #include > #include > #include > #include > -#include > +#include > #include > #include > +#include > +#include > > #include "ltdc.h" > > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c > index 61dd661aa0ac..5cce6c7f35d4 100644 > --- a/drivers/gpu/drm/stm/ltdc.c > +++ b/drivers/gpu/drm/stm/ltdc.c > @@ -10,17 +10,24 @@ > > #include > #include > +#include > +#include > +#include > #include > #include > +#include > #include > > #include > #include > +#include > #include > +#include > #include > +#include > #include > #include > -#include > +#include > #include > > #include > -- > 2.12.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
Hi Tomi, On 03.01.2019 12:59, Tomi Valkeinen wrote: > Hi, > > We have TC358867 on our board, which I believe is almost identical to > TC358767. We're using it with a DP connector instead of eDP with a fixed > panel. > > I have tested these patches only on TI's 4.14 based kernel, as > unfortunately we don't have all the necessary support in mainline yet. > These patches fix various bugs, but I'm still seeing at least two > issues: > > * Sync with some videomodes is not correct, resulting in a jumping and > skewed display > * Link training fails sometimes > > I would appreciate if someone is able to verify these patches with > TC358767. Do you want to wait for testers or shall I queue this patchset? Regards Andrzej > > Changes in v2: > - Addressed the comments > - Added reviewed bys > > Tomi > > Tomi Valkeinen (7): > drm/bridge: tc358767: add bus flags > drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE > drm/bridge: tc358767: fix single lane configuration > drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value > drm/bridge: tc358767: reject modes which require too much BW > drm/bridge: tc358767: fix output H/V syncs > drm/bridge: tc358767: use DP connector if no panel set > > drivers/gpu/drm/bridge/tc358767.c | 48 --- > 1 file changed, 38 insertions(+), 10 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Drop deprecated load/unload initialization
On Tue, Jan 08, 2019 at 11:59:30AM -0300, Ezequiel Garcia wrote: > Move the code around so the driver is probed the bus > .probe and removed from the bus .remove callbacks. > This commit is just a cleanup and shouldn't affect > functionality. That one works. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qxl: Use struct_size() in kzalloc()
On Tue, Jan 08, 2019 at 10:21:52AM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
Patch queued up.
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
Hi Andrzej, On 09/01/19 10:22, Andrzej Hajda wrote: > Hi Tomi, > > On 03.01.2019 12:59, Tomi Valkeinen wrote: >> Hi, >> >> We have TC358867 on our board, which I believe is almost identical to >> TC358767. We're using it with a DP connector instead of eDP with a fixed >> panel. >> >> I have tested these patches only on TI's 4.14 based kernel, as >> unfortunately we don't have all the necessary support in mainline yet. >> These patches fix various bugs, but I'm still seeing at least two >> issues: >> >> * Sync with some videomodes is not correct, resulting in a jumping and >> skewed display >> * Link training fails sometimes >> >> I would appreciate if someone is able to verify these patches with >> TC358767. > > > Do you want to wait for testers or shall I queue this patchset? I haven't heard from anyone, so I'm ok with pushing these. 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: Armada DRM: bridge with componentized devices
+CC: Rafael J. Wysocki On 08.01.2019 16:07, Russell King - ARM Linux wrote: > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote: >> On 08.01.2019 14:21, Russell King - ARM Linux wrote: >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote: On 08.01.2019 12:38, Russell King - ARM Linux wrote: > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote: >> Issues with device links have nothing to do with hotplugging, they are >> generic - lifetime of the objects (drm_bridge, drm_panel) is just >> slightly different of lifetime of device links, and this is racy even if >> you do not want hotplugging. Moreover since drm_dev is not device (has >> no associated struct device) assuming we can reuse its parent to create >> device link results in circular dependencies. > How about having the device links created depending on whether the > main drm driver wants them or not - that would mean that Exynos > could continue avoiding them, but others that want them can have > the links? That should be OK for Exynos. But regardless of Exynos device_links at the current state will not work correctly with bridges/panels as I described earlier. >>> However, I'm not sure you're correct with your interpretation of the >>> documentation. Firstly, the documentation says: >>> >>>Another example for an inconsistent state would be a device link that >>>represents a driver presence dependency, yet is added from the consumer's >>>->probe callback while the supplier hasn't probed yet: Had the driver >>> core >>>known about the device link earlier, it wouldn't have probed the consumer >>>in the first place. The onus is thus on the consumer to check presence of >>>the supplier after adding the link, and defer probing on non-presence. >>> >>> This is fine - if we add the device link from of_drm_find_bridge(), we >>> will be in the consumer's ->probe function, and the supplier must have >>> been probed for us to find the struct drm_bridge. >> >> Supplier usually is registered in it's probe time, so there is short >> period of time when supplier is available, but the probe is not yet >> finished - quite unsafe, but not impossible, especially if there exists >> some kind of notifications about resource appearance (MIPI-DSI case). > At some point during the supplier probe, the resource becomes available > to consumers. At that point, device links can be setup before the > supplier has finished probing. So any driver that provides resources > to another driver will, at some point during the provider's probe, > make resources available, and therefore be a candidate for device links > to be created _before_ the probe function has returned. > > What is a problem is if the provider publishes resources, and then fails > its probe function, causing the resource to disappear. But creating link to not-probed provider is still incorrect usage from device_links framework PoV, and my tests showed indeed that device link created before end of provider's probe does not work at all - and since it is stated in the documentation I guess it is by design. > > Taking DRM bridge, drm_bridge_add() returns void - it never fails. > Most bridge drivers do drm_bridge_add() as the very last step before > returning zero from their probe function. There are a few exceptions. > > megachips-stdp-ge-b850v3-fw.c is already buggy - it calls > devm_request_threaded_irq(), which if it fails, the bridge is left added > to the global list of bridges. Since this structure was allocated with > devm_kzalloc(), it will be freed when the probe function fails. So, > any failure here (eg a deferred probe because the IRQ controller is not > available) already creates a latent bug just waiting to bite. > > tc358764.c is another case where the bridge is published prior to > initialisation completion, but it looks like that's under the control > of the "host" (consumer) driver. > > mtk_hdmi.c enables clocks for audio after registering the bridge, which > may fail, but are unlikely to. However, moving them prior to > drm_bridge_add() probably won't hurt and avoids the "published > interfaces which then vanish" problem. > > Then we have exynos_drm_mic.c and tda998x_drv.c, but I think the > latter's error path after drm_bridge_add() can be eliminated if we > transitioned to device links instead of the component helper. > > Outside DRM, take regulators - at some point during a regulator > supplier's probe function, the resource will be published, and as soon > as it is, it's available for regulator_get() to find it and setup a > device link before the probe function has finished. > > >From what I can tell, in the situation where a supplier makes resources > available, the consumer binds to the resource, and then the supplier > goes away, the device link will remain, and the consumer will not be > unbound, which leads to an unexpected state. The solution to this
Re: [PATCH AUTOSEL 4.20 034/117] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal
On 2019-01-08 8:25 p.m., Sasha Levin wrote: > From: Nicholas Kazlauskas > > [ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ] > > When variable refresh rate is active [...] Variable refresh rate (FreeSync) support is only landing in 5.0, therefore this fix isn't needed in older kernels. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote: > > +CC: Rafael J. Wysocki > > On 08.01.2019 16:07, Russell King - ARM Linux wrote: > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote: > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote: > >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote: > On 08.01.2019 12:38, Russell King - ARM Linux wrote: > > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote: > >> Issues with device links have nothing to do with hotplugging, they are > >> generic - lifetime of the objects (drm_bridge, drm_panel) is just > >> slightly different of lifetime of device links, and this is racy even > >> if > >> you do not want hotplugging. Moreover since drm_dev is not device (has > >> no associated struct device) assuming we can reuse its parent to create > >> device link results in circular dependencies. > > How about having the device links created depending on whether the > > main drm driver wants them or not - that would mean that Exynos > > could continue avoiding them, but others that want them can have > > the links? > That should be OK for Exynos. But regardless of Exynos device_links at > the current state will not work correctly with bridges/panels as I > described earlier. > >>> However, I'm not sure you're correct with your interpretation of the > >>> documentation. Firstly, the documentation says: > >>> > >>>Another example for an inconsistent state would be a device link that > >>>represents a driver presence dependency, yet is added from the > >>> consumer's > >>>->probe callback while the supplier hasn't probed yet: Had the driver > >>> core > >>>known about the device link earlier, it wouldn't have probed the > >>> consumer > >>>in the first place. The onus is thus on the consumer to check presence > >>> of > >>>the supplier after adding the link, and defer probing on non-presence. > >>> > >>> This is fine - if we add the device link from of_drm_find_bridge(), we > >>> will be in the consumer's ->probe function, and the supplier must have > >>> been probed for us to find the struct drm_bridge. > >> > >> Supplier usually is registered in it's probe time, so there is short > >> period of time when supplier is available, but the probe is not yet > >> finished - quite unsafe, but not impossible, especially if there exists > >> some kind of notifications about resource appearance (MIPI-DSI case). > > At some point during the supplier probe, the resource becomes available > > to consumers. At that point, device links can be setup before the > > supplier has finished probing. So any driver that provides resources > > to another driver will, at some point during the provider's probe, > > make resources available, and therefore be a candidate for device links > > to be created _before_ the probe function has returned. > > > > What is a problem is if the provider publishes resources, and then fails > > its probe function, causing the resource to disappear. > > > But creating link to not-probed provider is still incorrect usage from > device_links framework PoV, and my tests showed indeed that device link > created before end of provider's probe does not work at all - and since > it is stated in the documentation I guess it is by design. Yes, it is. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote: > On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote: > > > > +CC: Rafael J. Wysocki > > > > On 08.01.2019 16:07, Russell King - ARM Linux wrote: > > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote: > > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote: > > >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote: > > On 08.01.2019 12:38, Russell King - ARM Linux wrote: > > > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote: > > >> Issues with device links have nothing to do with hotplugging, they > > >> are > > >> generic - lifetime of the objects (drm_bridge, drm_panel) is just > > >> slightly different of lifetime of device links, and this is racy > > >> even if > > >> you do not want hotplugging. Moreover since drm_dev is not device > > >> (has > > >> no associated struct device) assuming we can reuse its parent to > > >> create > > >> device link results in circular dependencies. > > > How about having the device links created depending on whether the > > > main drm driver wants them or not - that would mean that Exynos > > > could continue avoiding them, but others that want them can have > > > the links? > > That should be OK for Exynos. But regardless of Exynos device_links at > > the current state will not work correctly with bridges/panels as I > > described earlier. > > >>> However, I'm not sure you're correct with your interpretation of the > > >>> documentation. Firstly, the documentation says: > > >>> > > >>>Another example for an inconsistent state would be a device link that > > >>>represents a driver presence dependency, yet is added from the > > >>> consumer's > > >>>->probe callback while the supplier hasn't probed yet: Had the > > >>> driver core > > >>>known about the device link earlier, it wouldn't have probed the > > >>> consumer > > >>>in the first place. The onus is thus on the consumer to check > > >>> presence of > > >>>the supplier after adding the link, and defer probing on > > >>> non-presence. > > >>> > > >>> This is fine - if we add the device link from of_drm_find_bridge(), we > > >>> will be in the consumer's ->probe function, and the supplier must have > > >>> been probed for us to find the struct drm_bridge. > > >> > > >> Supplier usually is registered in it's probe time, so there is short > > >> period of time when supplier is available, but the probe is not yet > > >> finished - quite unsafe, but not impossible, especially if there exists > > >> some kind of notifications about resource appearance (MIPI-DSI case). > > > At some point during the supplier probe, the resource becomes available > > > to consumers. At that point, device links can be setup before the > > > supplier has finished probing. So any driver that provides resources > > > to another driver will, at some point during the provider's probe, > > > make resources available, and therefore be a candidate for device links > > > to be created _before_ the probe function has returned. > > > > > > What is a problem is if the provider publishes resources, and then fails > > > its probe function, causing the resource to disappear. > > > > > > But creating link to not-probed provider is still incorrect usage from > > device_links framework PoV, and my tests showed indeed that device link > > created before end of provider's probe does not work at all - and since > > it is stated in the documentation I guess it is by design. > > Yes, it is. So is the regulator support and the use of it being proposed for the CCF all going against the design of device links? In both those cases, device links _can_ be created while the supplier is still in the probe function by a consumer finding the resource. This seems fragile by design. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 6/6] arm64: dts: sdm845: Add gpu and gmu device nodes
On 1/9/2019 10:50 AM, Doug Anderson wrote: ...but in the meantime Rajendra has had to change his bindings, so you still need to spin this to account for Rajendra's v9 bindings [2]. Specifically you need to make changes like: - compatible = "operating-points-v2-qcom-level"; + compatible = "operating-points-v2-level"; so there's now a v10 [1] and the new compatible is completely dropped and opp-level is now an optional property using the default "operating-points-v2" so the change should be - compatible = "operating-points-v2-qcom-level"; + compatible = "operating-points-v2"; [1] https://lkml.org/lkml/2019/1/9/152 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #12 from Michel Dänzer --- (In reply to tme from comment #9) > Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem. > It does, however, reproduce on 4.17.19. Can you bisect between 4.16.18 and 4.17.19? (I see some HPD filtering related changes between them, Nicholas / Harry maybe you can take a look if anything jumps out?) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/9] phy: dphy: Remove unused header
The videomode.h header inclusion is an artifact from the patches development, remove it. Suggested-by: Sakari Ailus Signed-off-by: Maxime Ripard --- include/linux/phy/phy-mipi-dphy.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h index c08aacc0ac35..9cf97cd1d303 100644 --- a/include/linux/phy/phy-mipi-dphy.h +++ b/include/linux/phy/phy-mipi-dphy.h @@ -6,8 +6,6 @@ #ifndef __PHY_MIPI_DPHY_H_ #define __PHY_MIPI_DPHY_H_ -#include - /** * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set * -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 9/9] drm/bridge: cdns: Convert to phy framework
Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/Kconfig| 1 +-
drivers/gpu/drm/bridge/cdns-dsi.c | 485 +++
drivers/phy/cadence/cdns-dphy.c | 2 +-
3 files changed, 61 insertions(+), 427 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..8840f396a7b6 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -30,6 +30,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
depends on OF
help
Support Cadence DPI to DSI bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 3ac6dd524b6d..7b432257ffbe 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -21,6 +21,9 @@
#include
#include
+#include
+#include
+
#define IP_CONF0x0
#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
@@ -419,44 +422,11 @@
#define DSI_NULL_FRAME_OVERHEAD6
#define DSI_EOT_PKT_SIZE 4
-#define REG_WAKEUP_TIME_NS 800
-#define DPHY_PLL_RATE_HZ 10800
-
-/* DPHY registers */
-#define DPHY_PMA_CMN(reg) (reg)
-#define DPHY_PMA_LCLK(reg) (0x100 + (reg))
-#define DPHY_PMA_LDATA(lane, reg) (0x200 + ((lane) * 0x100) + (reg))
-#define DPHY_PMA_RCLK(reg) (0x600 + (reg))
-#define DPHY_PMA_RDATA(lane, reg) (0x700 + ((lane) * 0x100) + (reg))
-#define DPHY_PCS(reg) (0xb00 + (reg))
-
-#define DPHY_CMN_SSM DPHY_PMA_CMN(0x20)
-#define DPHY_CMN_SSM_ENBIT(0)
-#define DPHY_CMN_TX_MODE_ENBIT(9)
-
-#define DPHY_CMN_PWM DPHY_PMA_CMN(0x40)
-#define DPHY_CMN_PWM_DIV(x)((x) << 20)
-#define DPHY_CMN_PWM_LOW(x)((x) << 10)
-#define DPHY_CMN_PWM_HIGH(x) (x)
-
-#define DPHY_CMN_FBDIV DPHY_PMA_CMN(0x4c)
-#define DPHY_CMN_FBDIV_VAL(low, high) (((high) << 11) | ((low) << 22))
-#define DPHY_CMN_FBDIV_FROM_REG(BIT(10) | BIT(21))
-
-#define DPHY_CMN_OPIPDIV DPHY_PMA_CMN(0x50)
-#define DPHY_CMN_IPDIV_FROM_REGBIT(0)
-#define DPHY_CMN_IPDIV(x) ((x) << 1)
-#define DPHY_CMN_OPDIV_FROM_REGBIT(6)
-#define DPHY_CMN_OPDIV(x) ((x) << 7)
-
-#define DPHY_PSM_CFG DPHY_PCS(0x4)
-#define DPHY_PSM_CFG_FROM_REG BIT(0)
-#define DPHY_PSM_CLK_DIV(x)((x) << 1)
-
struct cdns_dsi_output {
struct mipi_dsi_device *dev;
struct drm_panel *panel;
struct drm_bridge *bridge;
+ union phy_configure_opts phy_opts;
};
enum cdns_dsi_input_id {
@@ -465,14 +435,6 @@ enum cdns_dsi_input_id {
CDNS_DSC_INPUT,
};
-struct cdns_dphy_cfg {
- u8 pll_ipdiv;
- u8 pll_opdiv;
- u16 pll_fbdiv;
- unsigned long lane_bps;
- unsigned int nlanes;
-};
-
struct cdns_dsi_cfg {
unsigned int hfp;
unsigned int hsa;
@@ -481,34 +443,6 @@ struct cdns_dsi_cfg {
unsigned int htotal;
};
-struct cdns_dphy;
-
-enum cdns_dphy_clk_lane_cfg {
- DPHY_CLK_CFG_LEFT_DRIVES_ALL = 0,
- DPHY_CLK_CFG_LEFT_DRIVES_RIGHT = 1,
- DPHY_CLK_CFG_LEFT_DRIVES_LEFT = 2,
- DPHY_CLK_CFG_RIGHT_DRIVES_ALL = 3,
-};
-
-struct cdns_dphy_ops {
- int (*probe)(struct cdns_dphy *dphy);
- void (*remove)(struct cdns_dphy *dphy);
- void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
- void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
-enum cdns_dphy_clk_lane_cfg cfg);
- void (*set_pll_cfg)(struct cdns_dphy *dphy,
- const struct cdns_dphy_cfg *cfg);
- unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
-};
-
-struct cdns_dphy {
- struct cdns_dphy_cfg cfg;
- void __iomem *regs;
- struct clk *psm_clk;
- struct clk *pll_ref_clk;
- const struct cdns_dphy_ops *ops;
-};
-
struct cdns_dsi_input {
enum cdns_dsi_input_id id;
struct drm_bridge bridge;
@@ -526,7 +460,7 @@ struct cdns_dsi {
struct reset_control *dsi_p_rst;
struct clk *dsi_sys_clk;
bool link_initialized;
- struct cdns_dphy *dphy;
+ struct phy *dphy;
};
static inline struct cdns_dsi *input_to_dsi(struct cdns_dsi_input *input)
@@ -550,175 +484,6 @@ static unsigned int mode_to_dpi_hfp(const struct
drm_display_mode *mode)
return mode->crtc_hsync_start - mode->crtc_hdisp
[PATCH v4 3/9] phy: dphy: Clarify lanes parameter documentation
The lanes parameter is not solely about the number of lanes, but it also
carries the fact that those are the first lanes in use during the
transmission.
It was implicit so far, so make sure it's explicit now.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
include/linux/phy/phy-mipi-dphy.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/phy/phy-mipi-dphy.h
b/include/linux/phy/phy-mipi-dphy.h
index 627d28080d3a..a877ffee845d 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -269,7 +269,8 @@ struct phy_configure_opts_mipi_dphy {
/**
* @lanes:
*
-* Number of active data lanes used for the transmissions.
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions.
*/
unsigned char lanes;
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/9] dt-bindings: phy: Move the Cadence D-PHY bindings
The Cadence D-PHY bindings was defined as part of the DSI block so far.
However, since it's now going to be a separate driver, we need to move the
binding to a file of its own.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +---
Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +++-
2 files changed, 20 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
index f5725bb6c61c..525a4bfd8634 100644
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -31,28 +31,7 @@ Required subnodes:
- one subnode per DSI device connected on the DSI bus. Each DSI device should
contain a reg property encoding its virtual channel.
-Cadence DPHY
-
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-
Example:
- dphy0: dphy@fd0e{
- compatible = "cdns,dphy";
- reg = <0x0 0xfd0e 0x0 0x1000>;
- clocks = <&psm_clk>, <&pll_ref_clk>;
- clock-names = "psm", "pll_ref";
- #phy-cells = <0>;
- };
-
dsi0: dsi@fd0c {
compatible = "cdns,dsi";
reg = <0x0 0xfd0c 0x0 0x1000>;
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
new file mode 100644
index ..1095bc4e72d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
@@ -0,0 +1,20 @@
+Cadence DPHY
+
+
+Cadence DPHY block.
+
+Required properties:
+- compatible: should be set to "cdns,dphy".
+- reg: physical base address and length of the DPHY registers.
+- clocks: DPHY reference clocks.
+- clock-names: must contain "psm" and "pll_ref".
+- #phy-cells: must be set to 0.
+
+Example:
+ dphy0: dphy@fd0e{
+ compatible = "cdns,dphy";
+ reg = <0x0 0xfd0e 0x0 0x1000>;
+ clocks = <&psm_clk>, <&pll_ref_clk>;
+ clock-names = "psm", "pll_ref";
+ #phy-cells = <0>;
+ };
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/9] phy: Add configuration interface for MIPI D-PHY devices
Hi, Here is a set of patches to allow the phy framework consumers to test and apply runtime configurations. This is needed to support more phy classes that require tuning based on parameters depending on the current use case of the device, in addition to the power state management already provided by the current functions. A first test bed for that API are the MIPI D-PHY devices. There's a number of solutions that have been used so far to support these phy, most of the time being an ad-hoc driver in the consumer. That approach has a big shortcoming though, which is that this is quite difficult to deal with consumers integrated with multiple variants of phy, of multiple consumers integrated with the same phy. The latter case can be found in the Cadence DSI bridge, and the CSI transceiver and receivers. All of them are integrated with the same phy, or can be integrated with different phy, depending on the implementation. I've looked at all the MIPI DSI drivers I could find, and gathered all the parameters I could find. The interface should be complete, and most of the drivers can be converted in the future. The current set converts two of them: the above mentionned Cadence DSI driver so that the v4l2 drivers can use them, and the Allwinner MIPI-DSI driver. Let me know what you think, Maxime Changes from v3 - Rebased on 5.0-rc1 - Added the fixes suggested by Sakari Changes from v2: - Rebased on next - Changed the interface to accomodate for the new submodes - Changed the timings units from nanoseconds to picoseconds - Added minimum and maximum boundaries to the documentation - Moved the clock enabling to phy_power_on in the Cadence DPHY driver - Exported the phy_configure and phy_validate symbols - Rework the phy pll divider computation in the cadence dphy driver Changes from v1: - Rebased on top of 4.20-rc1 - Removed the bus mode and timings parameters from the MIPI D-PHY parameters, since that shouldn't have any impact on the PHY itself. - Reworked the Cadence DSI and D-PHY drivers to take this into account. - Remove the mode parameter from phy_configure - Added phy_configure and phy_validate stubs - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation is not implemented Maxime Ripard (9): phy: dphy: Remove unused header phy: dphy: Change units of wakeup and init parameters phy: dphy: Clarify lanes parameter documentation sun6i: dsi: Convert to generic phy handling phy: Move Allwinner A31 D-PHY driver to drivers/phy/ drm/bridge: cdns: Separate DSI and D-PHY configuration dt-bindings: phy: Move the Cadence D-PHY bindings phy: Add Cadence D-PHY support drm/bridge: cdns: Convert to phy framework Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- drivers/gpu/drm/bridge/Kconfig| 1 +- drivers/gpu/drm/bridge/cdns-dsi.c | 535 +-- drivers/gpu/drm/sun4i/Kconfig | 3 +- drivers/gpu/drm/sun4i/Makefile| 5 +- drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 + drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 31 +- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 17 +- drivers/phy/allwinner/Kconfig | 12 +- drivers/phy/allwinner/Makefile| 1 +- drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 - drivers/phy/cadence/Kconfig | 13 +- drivers/phy/cadence/Makefile | 1 +- drivers/phy/cadence/cdns-dphy.c | 389 +- drivers/phy/phy-core-mipi-dphy.c | 8 +- include/linux/phy/phy-mipi-dphy.h | 13 +- 17 files changed, 890 insertions(+), 790 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c create mode 100644 drivers/phy/cadence/cdns-dphy.c base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/9] drm/bridge: cdns: Separate DSI and D-PHY configuration
The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c | 96 ++--
1 file changed, 68 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index ce9496d13986..3ac6dd524b6d 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -545,6 +545,11 @@ bridge_to_cdns_dsi_input(struct drm_bridge *bridge)
return container_of(bridge, struct cdns_dsi_input, bridge);
}
+static unsigned int mode_to_dpi_hfp(const struct drm_display_mode *mode)
+{
+ return mode->crtc_hsync_start - mode->crtc_hdisplay;
+}
+
static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
struct cdns_dphy_cfg *cfg,
unsigned int dpi_htotal,
@@ -731,14 +736,12 @@ static unsigned int dpi_to_dsi_timing(unsigned int
dpi_timing,
static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
const struct drm_display_mode *mode,
struct cdns_dsi_cfg *dsi_cfg,
-struct cdns_dphy_cfg *dphy_cfg,
bool mode_valid_check)
{
- unsigned long dsi_htotal = 0, dsi_hss_hsa_hse_hbp = 0;
struct cdns_dsi_output *output = &dsi->output;
- unsigned int dsi_hfp_ext = 0, dpi_hfp, tmp;
+ unsigned int tmp;
bool sync_pulse = false;
- int bpp, nlanes, ret;
+ int bpp, nlanes;
memset(dsi_cfg, 0, sizeof(*dsi_cfg));
@@ -757,8 +760,6 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
mode->crtc_hsync_end : mode->crtc_hsync_start);
dsi_cfg->hbp = dpi_to_dsi_timing(tmp, bpp, DSI_HBP_FRAME_OVERHEAD);
- dsi_htotal += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
- dsi_hss_hsa_hse_hbp += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
if (sync_pulse) {
if (mode_valid_check)
@@ -768,49 +769,90 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
dsi_cfg->hsa = dpi_to_dsi_timing(tmp, bpp,
DSI_HSA_FRAME_OVERHEAD);
- dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
- dsi_hss_hsa_hse_hbp += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
}
dsi_cfg->hact = dpi_to_dsi_timing(mode_valid_check ?
mode->hdisplay : mode->crtc_hdisplay,
bpp, 0);
- dsi_htotal += dsi_cfg->hact;
+ dsi_cfg->hfp = dpi_to_dsi_timing(mode_to_dpi_hfp(mode), bpp,
+DSI_HFP_FRAME_OVERHEAD);
- if (mode_valid_check)
- dpi_hfp = mode->hsync_start - mode->hdisplay;
- else
- dpi_hfp = mode->crtc_hsync_start - mode->crtc_hdisplay;
+ return 0;
+}
+
+static int cdns_dphy_validate(struct cdns_dsi *dsi,
+ struct cdns_dsi_cfg *dsi_cfg,
+ struct cdns_dphy_cfg *dphy_cfg,
+ const struct drm_display_mode *mode,
+ bool mode_valid_check)
+{
+ struct cdns_dsi_output *output = &dsi->output;
+ unsigned long dsi_htotal;
+ unsigned int dsi_hfp_ext = 0;
+
+ int ret;
- dsi_cfg->hfp = dpi_to_dsi_timing(dpi_hfp, bpp, DSI_HFP_FRAME_OVERHEAD);
+ dsi_htotal = dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
+ if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+ dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
+
+ dsi_htotal += dsi_cfg->hact;
dsi_htotal += dsi_cfg->hfp + DSI_HFP_FRAME_OVERHEAD;
if (mode_valid_check)
ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
- mode->htotal, bpp,
+ mode->htotal,
mode->clock * 1000,
- dsi_htotal, nlanes,
+
mipi_dsi_pixel_format_to_bpp(output->dev->format),
+ dsi_htotal,
+ output->dev->lanes,
&dsi_hfp_ext);
else
ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
- mode->crtc_htotal, bpp,
+ mode->crtc_htotal,
+
mipi_dsi_pixel_format_to_bpp(output->dev->format),
mode->crtc_clock * 1000,
-
[PATCH v4 4/9] sun6i: dsi: Convert to generic phy handling
Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 11 +-
drivers/gpu/drm/sun4i/Makefile | 6 +-
drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 164 ++---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 ++---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +---
5 files changed, 126 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index c2c042287c19..2b8db82c4bab 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -45,10 +45,19 @@ config DRM_SUN6I_DSI
default MACH_SUN8I
select CRC_CCITT
select DRM_MIPI_DSI
+ select DRM_SUN6I_DPHY
help
Choose this option if you want have an Allwinner SoC with
MIPI-DSI support. If M is selected the module will be called
- sun6i-dsi
+ sun6i_mipi_dsi.
+
+config DRM_SUN6I_DPHY
+ tristate "Allwinner A31 MIPI D-PHY Support"
+ select GENERIC_PHY_MIPI_DPHY
+ help
+ Choose this option if you have an Allwinner SoC with
+ MIPI-DSI support. If M is selected, the module will be
+ called sun6i_mipi_dphy.
config DRM_SUN8I_DW_HDMI
tristate "Support for Allwinner version of DesignWare HDMI"
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 0eb38ac8e86e..1e2320d824b5 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -24,9 +24,6 @@ sun4i-tcon-y += sun4i_lvds.o
sun4i-tcon-y += sun4i_tcon.o
sun4i-tcon-y += sun4i_rgb.o
-sun6i-dsi-y+= sun6i_mipi_dphy.o
-sun6i-dsi-y+= sun6i_mipi_dsi.o
-
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
@@ -37,7 +34,8 @@ ifdef CONFIG_DRM_SUN4I_BACKEND
obj-$(CONFIG_DRM_SUN4I)+= sun4i-frontend.o
endif
obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
-obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i-dsi.o
+obj-$(CONFIG_DRM_SUN6I_DPHY) += sun6i_mipi_dphy.o
+obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i_mipi_dsi.o
obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
obj-$(CONFIG_DRM_SUN8I_TCON_TOP) += sun8i_tcon_top.o
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
index e4d19431fa0e..79c8af5c7c1d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
@@ -8,11 +8,14 @@
#include
#include
+#include
#include
+#include
#include
#include
-#include "sun6i_mipi_dsi.h"
+#include
+#include
#define SUN6I_DPHY_GCTL_REG0x00
#define SUN6I_DPHY_GCTL_LANE_NUM(n)n) - 1) & 3) << 4)
@@ -81,12 +84,46 @@
#define SUN6I_DPHY_DBG5_REG0xf4
-int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int lanes)
+struct sun6i_dphy {
+ struct clk *bus_clk;
+ struct clk *mod_clk;
+ struct regmap *regs;
+ struct reset_control*reset;
+
+ struct phy *phy;
+ struct phy_configure_opts_mipi_dphy config;
+};
+
+static int sun6i_dphy_init(struct phy *phy)
{
+ struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
reset_control_deassert(dphy->reset);
clk_prepare_enable(dphy->mod_clk);
clk_set_rate_exclusive(dphy->mod_clk, 15000);
+ return 0;
+}
+
+static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts
*opts)
+{
+ struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+ int ret;
+
+ ret = phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+ if (ret)
+ return ret;
+
+ memcpy(&dphy->config, opts, sizeof(dphy->config));
+
+ return 0;
+}
+
+static int sun6i_dphy_power_on(struct phy *phy)
+{
+ struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+ u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
+
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT);
@@ -111,16 +148,9 @@ int sun6i_dphy_init(struct sun6i_dphy *dphy, unsigned int
lanes)
SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(3));
regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG,
-SUN6I_DPHY_GCTL_LANE_NUM(lanes) |
+SUN6I_DPHY_GCTL_LANE_NUM(dphy->config.lanes) |
SUN6I_DPHY_GCTL_EN);
- return 0;
-}
-
-int sun6i_dphy_power_on(struct sun6i_dphy *dphy, unsigned int lanes)
-{
- u8 lanes_mask = GENMASK(lanes - 1, 0);
[PATCH v4 8/9] phy: Add Cadence D-PHY support
Cadence has designed a D-PHY that can be used by the, currently in tree,
DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
Only the DSI driver has an ad-hoc driver for that phy at the moment, while
the v4l2 drivers are completely missing any phy support. In order to make
that phy support available to all these drivers, without having to
duplicate that code three times, let's create a generic phy framework
driver.
Signed-off-by: Maxime Ripard
---
drivers/phy/cadence/Kconfig | 13 +-
drivers/phy/cadence/Makefile| 1 +-
drivers/phy/cadence/cdns-dphy.c | 389 +-
3 files changed, 402 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/cadence/cdns-dphy.c
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
index 2b8c0851ff33..31f18b67dd7c 100644
--- a/drivers/phy/cadence/Kconfig
+++ b/drivers/phy/cadence/Kconfig
@@ -1,6 +1,7 @@
#
# Phy drivers for Cadence PHYs
#
+
config PHY_CADENCE_DP
tristate "Cadence MHDP DisplayPort PHY driver"
depends on OF
@@ -9,9 +10,19 @@ config PHY_CADENCE_DP
help
Support for Cadence MHDP DisplayPort PHY.
+config PHY_CADENCE_DPHY
+ tristate "Cadence D-PHY Support"
+ depends on HAS_IOMEM && OF
+ select GENERIC_PHY
+ select GENERIC_PHY_MIPI_DPHY
+ help
+ Choose this option if you have a Cadence D-PHY in your
+ system. If M is selected, the module will be called
+ cdns-dphy.
+
config PHY_CADENCE_SIERRA
tristate "Cadence Sierra PHY Driver"
depends on OF && HAS_IOMEM && RESET_CONTROLLER
select GENERIC_PHY
help
- Enable this to support the Cadence Sierra PHY driver
\ No newline at end of file
+ Enable this to support the Cadence Sierra PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
index 412349af0492..2f9e3457b954 100644
--- a/drivers/phy/cadence/Makefile
+++ b/drivers/phy/cadence/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_PHY_CADENCE_DP) += phy-cadence-dp.o
+obj-$(CONFIG_PHY_CADENCE_DPHY) += cdns-dphy.o
obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o
diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
new file mode 100644
index ..1d0abba03f37
--- /dev/null
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -0,0 +1,389 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright: 2017-2018 Cadence Design Systems, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define REG_WAKEUP_TIME_NS 800
+#define DPHY_PLL_RATE_HZ 10800
+
+/* DPHY registers */
+#define DPHY_PMA_CMN(reg) (reg)
+#define DPHY_PMA_LCLK(reg) (0x100 + (reg))
+#define DPHY_PMA_LDATA(lane, reg) (0x200 + ((lane) * 0x100) + (reg))
+#define DPHY_PMA_RCLK(reg) (0x600 + (reg))
+#define DPHY_PMA_RDATA(lane, reg) (0x700 + ((lane) * 0x100) + (reg))
+#define DPHY_PCS(reg) (0xb00 + (reg))
+
+#define DPHY_CMN_SSM DPHY_PMA_CMN(0x20)
+#define DPHY_CMN_SSM_ENBIT(0)
+#define DPHY_CMN_TX_MODE_ENBIT(9)
+
+#define DPHY_CMN_PWM DPHY_PMA_CMN(0x40)
+#define DPHY_CMN_PWM_DIV(x)((x) << 20)
+#define DPHY_CMN_PWM_LOW(x)((x) << 10)
+#define DPHY_CMN_PWM_HIGH(x) (x)
+
+#define DPHY_CMN_FBDIV DPHY_PMA_CMN(0x4c)
+#define DPHY_CMN_FBDIV_VAL(low, high) (((high) << 11) | ((low) << 22))
+#define DPHY_CMN_FBDIV_FROM_REG(BIT(10) | BIT(21))
+
+#define DPHY_CMN_OPIPDIV DPHY_PMA_CMN(0x50)
+#define DPHY_CMN_IPDIV_FROM_REGBIT(0)
+#define DPHY_CMN_IPDIV(x) ((x) << 1)
+#define DPHY_CMN_OPDIV_FROM_REGBIT(6)
+#define DPHY_CMN_OPDIV(x) ((x) << 7)
+
+#define DPHY_PSM_CFG DPHY_PCS(0x4)
+#define DPHY_PSM_CFG_FROM_REG BIT(0)
+#define DPHY_PSM_CLK_DIV(x)((x) << 1)
+
+#define DSI_HBP_FRAME_OVERHEAD 12
+#define DSI_HSA_FRAME_OVERHEAD 14
+#define DSI_HFP_FRAME_OVERHEAD 6
+#define DSI_HSS_VSS_VSE_FRAME_OVERHEAD 4
+#define DSI_BLANKING_FRAME_OVERHEAD6
+#define DSI_NULL_FRAME_OVERHEAD6
+#define DSI_EOT_PKT_SIZE 4
+
+struct cdns_dphy_cfg {
+ u8 pll_ipdiv;
+ u8 pll_opdiv;
+ u16 pll_fbdiv;
+ unsigned int nlanes;
+};
+
+enum cdns_dphy_clk_lane_cfg {
+ DPHY_CLK_CFG_LEFT_DRIVES_ALL = 0,
+ DPHY_CLK_CFG_LEFT_DRIVES_RIGHT = 1,
+ DPHY_CLK_CFG_LEFT_DRIVES_LEFT = 2,
+ DPHY_CLK_CFG_RIGHT_DRIVES_ALL = 3,
+};
+
+struct cdns_dphy;
+struct cdns_dphy_ops {
+ int (*probe)(struct cdns_dphy *dphy);
+ void (*remove)(struct cdns_dphy *dphy);
+ void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
+ void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
+
[PATCH v4 2/9] phy: dphy: Change units of wakeup and init parameters
The Init and wakeup D-PHY parameters are in the micro/milliseconds range,
putting the values real close to the types limits if they were in
picoseconds.
Move them to microseconds which should be better fit.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
drivers/phy/phy-core-mipi-dphy.c | 8
include/linux/phy/phy-mipi-dphy.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 465fa1b91a5f..14e0551cd319 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -65,12 +65,12 @@ int phy_mipi_dphy_get_default_config(unsigned long
pixel_clock,
*/
cfg->hs_trail = max(4 * 8 * ui, 6 + 4 * 4 * ui);
- cfg->init = 1;
+ cfg->init = 100;
cfg->lpx = 6;
cfg->ta_get = 5 * cfg->lpx;
cfg->ta_go = 4 * cfg->lpx;
cfg->ta_sure = 2 * cfg->lpx;
- cfg->wakeup = 10;
+ cfg->wakeup = 1000;
cfg->hs_clk_rate = hs_clk_rate;
cfg->lanes = lanes;
@@ -143,7 +143,7 @@ int phy_mipi_dphy_config_validate(struct
phy_configure_opts_mipi_dphy *cfg)
if (cfg->hs_trail < max(8 * ui, 6 + 4 * ui))
return -EINVAL;
- if (cfg->init < 1)
+ if (cfg->init < 100)
return -EINVAL;
if (cfg->lpx < 5)
@@ -158,7 +158,7 @@ int phy_mipi_dphy_config_validate(struct
phy_configure_opts_mipi_dphy *cfg)
if (cfg->ta_sure < cfg->lpx || cfg->ta_sure > (2 * cfg->lpx))
return -EINVAL;
- if (cfg->wakeup < 10)
+ if (cfg->wakeup < 1000)
return -EINVAL;
return 0;
diff --git a/include/linux/phy/phy-mipi-dphy.h
b/include/linux/phy/phy-mipi-dphy.h
index 9cf97cd1d303..627d28080d3a 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -190,10 +190,10 @@ struct phy_configure_opts_mipi_dphy {
/**
* @init:
*
-* Time, in picoseconds for the initialization period to
+* Time, in microseconds for the initialization period to
* complete.
*
-* Minimum value: 1 ps
+* Minimum value: 100 us
*/
unsigned intinit;
@@ -244,11 +244,11 @@ struct phy_configure_opts_mipi_dphy {
/**
* @wakeup:
*
-* Time, in picoseconds, that a transmitter drives a Mark-1
+* Time, in microseconds, that a transmitter drives a Mark-1
* state prior to a Stop state in order to initiate an exit
* from ULPS.
*
-* Minimum value: 10 ps
+* Minimum value: 1000 us
*/
unsigned intwakeup;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/9] phy: Move Allwinner A31 D-PHY driver to drivers/phy/
Now that our MIPI D-PHY driver has been converted to the phy framework, let's move it into the drivers/phy directory. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/Kconfig | 10 +- drivers/gpu/drm/sun4i/Makefile | 1 +- drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 318 +- drivers/phy/allwinner/Kconfig | 12 +- drivers/phy/allwinner/Makefile | 1 +- drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 +- 6 files changed, 332 insertions(+), 328 deletions(-) delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig index 2b8db82c4bab..1dbbc3a1b763 100644 --- a/drivers/gpu/drm/sun4i/Kconfig +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -45,20 +45,12 @@ config DRM_SUN6I_DSI default MACH_SUN8I select CRC_CCITT select DRM_MIPI_DSI - select DRM_SUN6I_DPHY + select PHY_SUN6I_MIPI_DPHY help Choose this option if you want have an Allwinner SoC with MIPI-DSI support. If M is selected the module will be called sun6i_mipi_dsi. -config DRM_SUN6I_DPHY - tristate "Allwinner A31 MIPI D-PHY Support" - select GENERIC_PHY_MIPI_DPHY - help - Choose this option if you have an Allwinner SoC with - MIPI-DSI support. If M is selected, the module will be - called sun6i_mipi_dphy. - config DRM_SUN8I_DW_HDMI tristate "Support for Allwinner version of DesignWare HDMI" depends on DRM_SUN4I diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile index 1e2320d824b5..0d04f2447b01 100644 --- a/drivers/gpu/drm/sun4i/Makefile +++ b/drivers/gpu/drm/sun4i/Makefile @@ -34,7 +34,6 @@ ifdef CONFIG_DRM_SUN4I_BACKEND obj-$(CONFIG_DRM_SUN4I)+= sun4i-frontend.o endif obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o -obj-$(CONFIG_DRM_SUN6I_DPHY) += sun6i_mipi_dphy.o obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i_mipi_dsi.o obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c deleted file mode 100644 index 79c8af5c7c1d.. --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c +++ /dev/null @@ -1,318 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * Copyright (c) 2016 Allwinnertech Co., Ltd. - * Copyright (C) 2017-2018 Bootlin - * - * Maxime Ripard - */ - -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#define SUN6I_DPHY_GCTL_REG0x00 -#define SUN6I_DPHY_GCTL_LANE_NUM(n)n) - 1) & 3) << 4) -#define SUN6I_DPHY_GCTL_EN BIT(0) - -#define SUN6I_DPHY_TX_CTL_REG 0x04 -#define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT BIT(28) - -#define SUN6I_DPHY_TX_TIME0_REG0x10 -#define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24) -#define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n) (((n) & 0xff) << 16) -#define SUN6I_DPHY_TX_TIME0_LP_CLK_DIV(n) ((n) & 0xff) - -#define SUN6I_DPHY_TX_TIME1_REG0x14 -#define SUN6I_DPHY_TX_TIME1_CLK_POST(n)(((n) & 0xff) << 24) -#define SUN6I_DPHY_TX_TIME1_CLK_PRE(n) (((n) & 0xff) << 16) -#define SUN6I_DPHY_TX_TIME1_CLK_ZERO(n)(((n) & 0xff) << 8) -#define SUN6I_DPHY_TX_TIME1_CLK_PREPARE(n) ((n) & 0xff) - -#define SUN6I_DPHY_TX_TIME2_REG0x18 -#define SUN6I_DPHY_TX_TIME2_CLK_TRAIL(n) ((n) & 0xff) - -#define SUN6I_DPHY_TX_TIME3_REG0x1c - -#define SUN6I_DPHY_TX_TIME4_REG0x20 -#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n) (((n) & 0xff) << 8) -#define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n) ((n) & 0xff) - -#define SUN6I_DPHY_ANA0_REG0x4c -#define SUN6I_DPHY_ANA0_REG_PWSBIT(31) -#define SUN6I_DPHY_ANA0_REG_DMPC BIT(28) -#define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24) -#define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12) -#define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8) - -#define SUN6I_DPHY_ANA1_REG0x50 -#define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31) -#define SUN6I_DPHY_ANA1_REG_CSMPS(n) (((n) & 3) << 28) -#define SUN6I_DPHY_ANA1_REG_SVTT(n)(((n) & 0xf) << 24) - -#define SUN6I_DPHY_ANA2_REG0x54 -#define SUN6I_DPHY_ANA2_EN_P2S_CPU(n) (((n) & 0xf) << 24) -#define SUN6I_DPHY_ANA2_EN_P2S_CPU_MASKGENMASK(27, 24) -#define SUN6I_DPHY_ANA2_EN_CK_CPU BIT(4) -#define SUN6I_DPHY_ANA2_REG_ENIB BIT(1) - -#define SUN6I_DPHY_ANA3_REG0x58 -#define SUN6I_DPHY_ANA3_EN_VTTD(n) (((n) & 0xf) << 28) -#define SUN6I_DPHY_ANA3_EN_V
Re: [PATCH] etnaviv mailing list is moderated
Am Dienstag, den 08.01.2019, 12:50 -0800 schrieb Matthew Wilcox: > > Signed-off-by: Matthew Wilcox Thanks, applied to etnaviv/next. Regards, Lucas > diff --git a/MAINTAINERS b/MAINTAINERS > index 32d76a90..44888eb121d8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5141,7 +5141,7 @@ DRM DRIVERS FOR VIVANTE GPU IP > > > M: Lucas Stach > > > R: Russell King > > > R: Christian Gmeiner > -L: etna...@lists.freedesktop.org > > +L: etna...@lists.freedesktop.org (moderated for non-subscribers) > L: dri-devel@lists.freedesktop.org > > S: Maintained > > F: drivers/gpu/drm/etnaviv/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Build etnaviv on non-ARM architectures
Am Dienstag, den 08.01.2019, 12:43 -0800 schrieb Matthew Wilcox: > I wanted to test-compile etnaviv on x86 after making a tree-wide change > to it. Unfortunately, Kconfig has a bad dependency, so I couldn't. > > Signed-off-by: Matthew Wilcox I think we even want to relax this some more in the future, as Vivante GPUs are also found on non ARM SoCs, but that needs some more testing so I applied this patch to etnaviv/next as it's certainly the right thing to do. Regards, Lucas > > diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig > index 041a77e400d4..342591a1084e 100644 > --- a/drivers/gpu/drm/etnaviv/Kconfig > +++ b/drivers/gpu/drm/etnaviv/Kconfig > @@ -2,7 +2,7 @@ > config DRM_ETNAVIV > > tristate "ETNAVIV (DRM support for Vivante GPU IP cores)" > > depends on DRM > > - depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST) > > + depends on ARCH_MXC || ARCH_DOVE || ARM || COMPILE_TEST > > depends on MMU > > select SHMEM > > select SYNC_FILE > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/12] drm/stm: do not reply on drmP.h from drm_gem_cma_helper.h
Hi Benjamin. On Wed, Jan 09, 2019 at 09:21:39AM +0100, Benjamin Gaignard wrote: > Le mar. 8 janv. 2019 à 20:30, Sam Ravnborg a écrit : > I just notice the a typo in the title of the commit message reply ->rely ? Randy already told me this, but I missed that in the update. Will fix in v4 if this set do not get applied. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen: > Hi Andrzej, > > On 09/01/19 10:22, Andrzej Hajda wrote: > > Hi Tomi, > > > > On 03.01.2019 12:59, Tomi Valkeinen wrote: > > > Hi, > > > > > > We have TC358867 on our board, which I believe is almost identical to > > > TC358767. We're using it with a DP connector instead of eDP with a fixed > > > panel. > > > > > > I have tested these patches only on TI's 4.14 based kernel, as > > > unfortunately we don't have all the necessary support in mainline yet. > > > These patches fix various bugs, but I'm still seeing at least two > > > issues: > > > > > > * Sync with some videomodes is not correct, resulting in a jumping and > > > skewed display > > > * Link training fails sometimes > > > > > > I would appreciate if someone is able to verify these patches with > > > TC358767. > > > > > > Do you want to wait for testers or shall I queue this patchset? > > I haven't heard from anyone, so I'm ok with pushing these. For the series: Tested-by: Lucas Stach on a device with TC358767 and a 4.20 based kernel. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/15] drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
On Tue, Jan 08, 2019 at 12:25:07PM +0100, Gerd Hoffmann wrote:
> Conversion to atomic modesetting, step one.
> Add atomic crtc helper callbacks.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index f7e6d1a9b3..2cbd406b1f 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -115,6 +115,29 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
> return 0;
> }
>
> +static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_crtc_state)
> +{
> +}
A patch to make this optional in the helpers would be neat.
-Daniel
> +
> +static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_crtc_state)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_pending_vblank_event *event;
> +
> + if (crtc->state && crtc->state->event) {
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> + event = crtc->state->event;
> + crtc->state->event = NULL;
> + drm_crtc_send_vblank_event(crtc, event);
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> + }
> +}
> +
> +
> /* These provide the minimum set of functions required to handle a CRTC */
> static const struct drm_crtc_funcs bochs_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> @@ -128,6 +151,8 @@ static const struct drm_crtc_helper_funcs
> bochs_helper_funcs = {
> .mode_set_base = bochs_crtc_mode_set_base,
> .prepare = bochs_crtc_prepare,
> .commit = bochs_crtc_commit,
> + .atomic_enable = bochs_crtc_atomic_enable,
> + .atomic_flush = bochs_crtc_atomic_flush,
> };
>
> static const uint32_t bochs_formats[] = {
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 v2 15/15] drm/bochs: reserve bo for pin/unpin
On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote: > The buffer object must be reserved before calling > ttm_bo_validate for pinning/unpinning. > > Signed-off-by: Gerd Hoffmann Seems a bit a bisect fumble in your series here: legacy kms code reserved the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to avoid bisect fail I think you need to have these temporarily in your cleanup/prepare_plane functions too. Looked through the entire series, this here is the only issue I think should be fixed before merging (making atomic_enable optional can be done as a follow-up if you feel like it). With that addressed on the series: Acked-by: Daniel Vetter > --- > drivers/gpu/drm/bochs/bochs_mm.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/bochs/bochs_mm.c > b/drivers/gpu/drm/bochs/bochs_mm.c > index cfe061c25f..970a591908 100644 > --- a/drivers/gpu/drm/bochs/bochs_mm.c > +++ b/drivers/gpu/drm/bochs/bochs_mm.c > @@ -223,7 +223,11 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag) > bochs_ttm_placement(bo, pl_flag); > for (i = 0; i < bo->placement.num_placement; i++) > bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; > + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); > + if (ret) > + return ret; > ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); > + ttm_bo_unreserve(&bo->bo); > if (ret) > return ret; > > @@ -247,7 +251,11 @@ int bochs_bo_unpin(struct bochs_bo *bo) > > for (i = 0; i < bo->placement.num_placement; i++) > bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; > + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); > + if (ret) > + return ret; > ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); > + ttm_bo_unreserve(&bo->bo); > if (ret) > return ret; > > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
On 09.01.2019 10:51, Lucas Stach wrote: > Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen: >> Hi Andrzej, >> >> On 09/01/19 10:22, Andrzej Hajda wrote: >>> Hi Tomi, >>> >>> On 03.01.2019 12:59, Tomi Valkeinen wrote: Hi, We have TC358867 on our board, which I believe is almost identical to TC358767. We're using it with a DP connector instead of eDP with a fixed panel. I have tested these patches only on TI's 4.14 based kernel, as unfortunately we don't have all the necessary support in mainline yet. These patches fix various bugs, but I'm still seeing at least two issues: * Sync with some videomodes is not correct, resulting in a jumping and skewed display * Link training fails sometimes I would appreciate if someone is able to verify these patches with TC358767. >>> >>> Do you want to wait for testers or shall I queue this patchset? >> I haven't heard from anyone, so I'm ok with pushing these. > For the series: > > Tested-by: Lucas Stach > > on a device with TC358767 and a 4.20 based kernel. Already queued :) Regards Andrzej > > Regards, > Lucas > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero
On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote: > While trying to temporarily hide a plane, one thing that was attempted > was to call (from libdrm) > > drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0, > 0, 0, 0, 0, 0, 0, 0, 0); > > This call causes a pair of "Division by zero in kernel." messages. Kill > those messages, but preserve the current behaviour that also happen to > make the plane disappear with the above call. > > Signed-off-by: Peter Rosin > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > Side note, when comparing with drm_atomic_helper_check_plane_state(), I get > the feeling that the src rect should be clipped together with the crtc rect > if/when clipping is needed. That function calls drm_rect_clip_scaled(), and > the equivalent does not seem to happen here. Should clipping be performed > on the src rect? Any reasons atmel can't switch over to that helper? Would compute a nice ->visible state variable for you ... -Daniel > > Cheers, > Peter > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > index 3cc489b870fe..1bdb30dc218c 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > @@ -675,10 +675,16 @@ static int atmel_hlcdc_plane_atomic_check(struct > drm_plane *p, > state->crtc_y = 0; > } > > - patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w, > - state->crtc_w); > - patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h, > - state->crtc_h); > + if (state->crtc_w) > + patched_src_w = DIV_ROUND_CLOSEST(patched_crtc_w * state->src_w, > + state->crtc_w); > + else > + patched_src_w = 0; > + if (state->crtc_h) > + patched_src_h = DIV_ROUND_CLOSEST(patched_crtc_h * state->src_h, > + state->crtc_h); > + else > + patched_src_h = 0; > > hsub = drm_format_horz_chroma_subsampling(fb->format->format); > vsub = drm_format_vert_chroma_subsampling(fb->format->format); > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 v5 1/2] drm/sched: Refactor ring mirror list handling.
Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
On 01/07/2019 09:13 AM, Christian König wrote:
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
On 12/21/2018 01:37 PM, Christian König wrote:
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
v4:
Full restart for all the jobs, not only from guilty ring.
Extract karma increase into standalone function.
v5:
Rework waiting for signaled jobs without relying on the job
struct itself as those might already be freed for non 'guilty'
job's schedulers.
Expose karma increase to drivers.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 +--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 11 +-
drivers/gpu/drm/scheduler/sched_main.c | 188
+++--
drivers/gpu/drm/v3d/v3d_sched.c | 12 +-
include/drm/gpu_scheduler.h | 10 +-
5 files changed, 151 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8a078f4..a4bd2d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3298,12 +3298,10 @@ static int
amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(&ring->sched, job ? &job->base : NULL);
- if (job && job->base.sched != &ring->sched)
- continue;
-
- drm_sched_hw_job_reset(&ring->sched, job ? &job->base :
NULL);
+ if(job)
+ drm_sched_increase_karma(&job->base);
Since we dropped the "job && job->base.sched != &ring->sched" check
above this will now increase the jobs karma multiple times.
Maybe just move that outside of the loop.
/* after all hw jobs are reset, hw fence is
meaningless,
so force_completion */
amdgpu_fence_driver_force_completion(ring);
@@ -3454,14 +3452,10 @@ static void
amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- /* only need recovery sched of the given job's ring
- * or all rings (in the case @job is NULL)
- * after above amdgpu_reset accomplished
- */
- if ((!job || job->base.sched == &ring->sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(&ring->sched);
+ if (!adev->asic_reset_res)
+ drm_sched_resubmit_jobs(&ring->sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(&ring->sched, !adev->asic_reset_res);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..6f1268f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(&gpu->sched, sched_job);
+ drm_sched_stop(&gpu->sched, sched_job);
+
+ if(sched_job)
+ drm_sched_increase_karma(sched_job);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(&gpu->sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(&gpu->sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(&gpu->sched, true);
}
static void etnaviv_sched_free_job(struct drm_sched_job
*sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..b5c5bee 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f,
struct
dma_fence_cb *cb);
-static void drm_sched_expel_job_unlocked(struct
drm_sched_job
*s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -335,6 +333,42 @@ static void drm_sched_job_timedout(struct
work_struct *work)
spin_unlock_irqrestore(&sched->job_list_lock, flags);
}
Kernel doc here would be nice to have.
+void drm_sched_increase_karma(struct drm_sch
Re: [PATCH v6 02/12] gpu: ipu-csi: Swap fields according to input/output field types
On Tue, 2019-01-08 at 16:15 -0800, Steve Longerbeam wrote: > The function ipu_csi_init_interface() was inverting the F-bit for > NTSC case, in the CCIR_CODE_1/2 registers. The result being that > for NTSC bottom-top field order, the CSI would swap fields and > capture in top-bottom order. > > Instead, base field swap on the field order of the input to the CSI, > and the field order of the requested output. If the input/output > fields are sequential but different, swap fields, otherwise do > not swap. This requires passing both the input and output mbus > frame formats to ipu_csi_init_interface(). > > Move this code to a new private function ipu_csi_set_bt_interlaced_codes() > that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and > possibly interlaced BT.1120 in the future). > > When detecting input video standard from the input frame width/height, > make sure to double height if input field type is alternate, since > in that case input height only includes lines for one field. > > Signed-off-by: Steve Longerbeam > Reviewed-by: Philipp Zabel Also Acked-by: Philipp Zabel to be merged via the media tree regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero
On Wed, 9 Jan 2019 11:12:24 +0100 Daniel Vetter wrote: > On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote: > > While trying to temporarily hide a plane, one thing that was attempted > > was to call (from libdrm) > > > > drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0, > > 0, 0, 0, 0, 0, 0, 0, 0); > > > > This call causes a pair of "Division by zero in kernel." messages. Kill > > those messages, but preserve the current behaviour that also happen to > > make the plane disappear with the above call. > > > > Signed-off-by: Peter Rosin > > --- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++ > > 1 file changed, 10 insertions(+), 4 deletions(-) > > > > Side note, when comparing with drm_atomic_helper_check_plane_state(), I get > > the feeling that the src rect should be clipped together with the crtc rect > > if/when clipping is needed. That function calls drm_rect_clip_scaled(), and > > the equivalent does not seem to happen here. Should clipping be performed > > on the src rect? > > Any reasons atmel can't switch over to that helper? Would compute a nice > ->visible state variable for you ... We should definitely use drm_atomic_helper_check_plane_state(). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero
On Wed, 9 Jan 2019 11:37:19 + Peter Rosin wrote: > On 2019-01-09 11:12, Daniel Vetter wrote: > > On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote: > >> While trying to temporarily hide a plane, one thing that was attempted > >> was to call (from libdrm) > >> > >>drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0, > >>0, 0, 0, 0, 0, 0, 0, 0); > >> > >> This call causes a pair of "Division by zero in kernel." messages. Kill > >> those messages, but preserve the current behaviour that also happen to > >> make the plane disappear with the above call. > >> > >> Signed-off-by: Peter Rosin > >> --- > >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++ > >> 1 file changed, 10 insertions(+), 4 deletions(-) > >> > >> Side note, when comparing with drm_atomic_helper_check_plane_state(), I get > >> the feeling that the src rect should be clipped together with the crtc rect > >> if/when clipping is needed. That function calls drm_rect_clip_scaled(), and > >> the equivalent does not seem to happen here. Should clipping be performed > >> on the src rect? > > > > Any reasons atmel can't switch over to that helper? Would compute a nice > > ->visible state variable for you ... > > -Daniel > > I have not researched that, and as stated above, I was not sure if that was > the > correct approach to begin with. Boris, any insights? You can look at vc4_plane.c if you want an example of how this helper can be used to get clipped dimensions of the plane. > Does this code predate the > helper or something? Yes, and I must admit I'm not actively maintaining the driver, so there are probably a few other things we could simplify by using generic helpers. > > Maybe there's some register bit that hides a plane explicitly, matching the > ->visible state variable? I haven't looked at that either... I don't think so, but you can simply disable the plane when ->visible is false. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v4 10/12] drm/i915: Add HLG EOTF
>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, January 9, 2019 1:15 AM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 10/12] drm/i915: Add HLG EOTF
>
>On Tue, Jan 08, 2019 at 02:41:25PM +0530, Uma Shankar wrote:
>> From: Ville Syrjälä
>>
>> ADD HLG EOTF to the list of EOTF transfer functions supported.
>> Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
>> HLG defines a nonlinear transfer function in which the lower half of
>> the signal values use a gamma curve and the upper half of the signal
>> values use a logarithmic curve.
>>
>> v2: Rebase
>>
>> v3: Fixed a warning message
>>
>> v4: Addressed Shashank's review comments
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_edid.c | 4 ++--
>> include/linux/hdmi.h | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>I haven't really looked at this series in depth, but just a quick drive-by
>comment:
>it doesn't look like this patch touches i915, so the "drm/i915:" headline
>prefix
>should probably just be "drm:" and you might want to move it earlier in the
>series
>so that all the core patches come before all the i915 patches.
Sure Matt, will update this as part of next version.
Regards,
Uma Shankar
>
>Matt
>
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index df27012..5592c9b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3850,8 +3850,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
>> return edid_ext[2] &
>> (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>> BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> - BIT(HDMI_EOTF_SMPTE_ST2084));
>> -
>> + BIT(HDMI_EOTF_SMPTE_ST2084) |
>> + BIT(HDMI_EOTF_BT_2100_HLG));
>> }
>>
>> static uint8_t hdr_metadata_type(const u8 *edid_ext) diff --git
>> a/include/linux/hdmi.h b/include/linux/hdmi.h index ce00e1e..b5346c3
>> 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -146,6 +146,7 @@ enum hdmi_eotf {
>> HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
>> HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
>> HDMI_EOTF_SMPTE_ST2084,
>> +HDMI_EOTF_BT_2100_HLG,
>> };
>>
>> struct hdmi_avi_infoframe {
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v6 0/2] Add Colorspace connector property interface
>-Original Message- >From: Brian Starkey [mailto:brian.star...@arm.com] >Sent: Tuesday, January 8, 2019 7:37 PM >To: Shankar, Uma >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >Lankhorst, >Maarten ; Syrjala, Ville >; >Sharma, Shashank ; nd >Subject: Re: [v6 0/2] Add Colorspace connector property interface > >Hi Uma, > >On Thu, Dec 27, 2018 at 11:22:36PM +0530, Uma Shankar wrote: >> This patch series creates a new connector property to program >> colorspace to sink devices. Modern sink devices support more than 1 >> type of colorspace like 601, 709, BT2020 etc. This helps to switch >> based on content type which is to be displayed. The decision lies with >> compositors as to in which scenarios, a particular colorspace will be >> picked. >> >> This will be helpful mostly to switch to higher gamut colorspaces like >> BT2020 when the media content is encoded as BT2020. Thereby giving a >> good visual experience to users. >> >> The expectation from userspace is that it should parse the EDID and >> get supported colorspaces. Use this property and switch to the one >> supported. Kernel will not give the supported colorspaces since this >> is panel dependent and our current property infrastructure is not >> supporting it. >> >> Basically the expectation from userspace is: >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink >>colorspace >> - Set this new property to let the sink know what it >>converted the CRTC output to. >> - This property is just to inform sink what colorspace >>source is trying to drive. > >All the above info is really important/useful stuff, but it's going to get lost >because it's only in the cover letter. This should either find its way into the >commit message of patch 1 or even better, into the kerneldoc for the property. Sure Brian, Will add it to kernel doc as well to commit message so that it's not lost. Regards, Uma Shankar >Cheers, >-Brian > >> >> Have tested this using xrandr by using below command: >> xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" >> >> v2: Addressed Ville and Maarten's review comments. Merged the 2nd and >> 3rd patch into one common logical patch. >> >> v3: Removed Adobe references from enum definitions as per Ville, Hans >> Verkuil and Jonas Karlman suggestions. Changed default to an unset >> state where driver will assign the colorspace when not chosen by user, >> suggested by Ville and Maarten. Addressed other misc review comments >> from Maarten. Split the changes to have separate colorspace property >> for DP and HDMI. >> >> v4: Addressed Chris and Ville's review comments, and created a common >> colorspace property for DP and HDMI, filtered the list based on the >> colorspaces supported by the respective protocol standard. Handled the >> default case more efficiently. >> >> v5: Modified the colorspace property creation helper to take platform >> specific enum list based on the capabilities of the platform as >> suggested by Shashank. With this there is no need for segregation >> between DP and HDMI. >> >> v6: Addressed Shashank's review comments. >> >> Uma Shankar (2): >> drm: Add colorspace connector property >> drm/i915: Attach colorspace property and enable modeset >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ >> drivers/gpu/drm/drm_connector.c| 82 >++ >> drivers/gpu/drm/i915/intel_atomic.c| 1 + >> drivers/gpu/drm/i915/intel_connector.c | 63 ++ >> drivers/gpu/drm/i915/intel_drv.h | 1 + >> drivers/gpu/drm/i915/intel_hdmi.c | 18 >> include/drm/drm_connector.h| 17 +++ >> include/uapi/drm/drm_mode.h| 33 ++ >> 8 files changed, 219 insertions(+) >> >> -- >> 1.9.1 >> >> Uma Shankar (2): >> drm: Add colorspace connector property >> drm/i915: Attach colorspace property and enable modeset >> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ >> drivers/gpu/drm/drm_connector.c| 79 >++ >> drivers/gpu/drm/i915/intel_atomic.c| 1 + >> drivers/gpu/drm/i915/intel_connector.c | 63 +++ >> drivers/gpu/drm/i915/intel_drv.h | 1 + >> drivers/gpu/drm/i915/intel_hdmi.c | 19 >> include/drm/drm_connector.h| 17 >> include/uapi/drm/drm_mode.h| 33 ++ >> 8 files changed, 217 insertions(+) >> >> -- >> 1.9.1 >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v6 1/2] drm: Add colorspace connector property
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:43 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6 1/2] drm: Add colorspace connector property
>
>Hi Uma,
>
>On Thu, Dec 27, 2018 at 11:22:37PM +0530, Uma Shankar wrote:
>> This patch adds a colorspace connector property, enabling userspace to
>> switch to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> Also, added a default option for colorspace.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
>> state where driver will assign the colorspace is not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Made the property creation helper accept enum list based on
>> platform capabilties as suggested by Shashank. Consolidated HDMI and
>> DP property creation in the common helper.
>>
>> v6: Addressed Shashank's review comments.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> drivers/gpu/drm/drm_connector.c | 79
>+++
>> include/drm/drm_connector.h | 17 +
>> include/uapi/drm/drm_mode.h | 33
>> 4 files changed, 133 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index c408898..5e03292 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> return -EINVAL;
>> }
>> state->content_protection = val;
>> +} else if (property == connector->colorspace_property) {
>> +state->colorspace = val;
>> } else if (property == config->writeback_fb_id_property) {
>> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb); @@
>> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->picture_aspect_ratio;
>> } else if (property == config->content_type_property) {
>> *val = state->content_type;
>> +} else if (property == connector->colorspace_property) {
>> +*val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> } else if (property == connector->content_protection_property) {
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 8475396..ad1b862 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
>> drm_display_info *info, };
>> DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
>>
>> +/* List of HDMI Colorspaces supported */ static const struct
>> +drm_prop_enum_list hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +/* List of DP Colorspaces supported */ static const struct
>> +drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default case
Re: [PATCH v4 0/9] phy: Add configuration interface for MIPI D-PHY devices
On Wed, Jan 09, 2019 at 10:33:17AM +0100, Maxime Ripard wrote: > Hi, > > Here is a set of patches to allow the phy framework consumers to test and > apply runtime configurations. > > This is needed to support more phy classes that require tuning based on > parameters depending on the current use case of the device, in addition to > the power state management already provided by the current functions. > > A first test bed for that API are the MIPI D-PHY devices. There's a number > of solutions that have been used so far to support these phy, most of the > time being an ad-hoc driver in the consumer. > > That approach has a big shortcoming though, which is that this is quite > difficult to deal with consumers integrated with multiple variants of phy, > of multiple consumers integrated with the same phy. > > The latter case can be found in the Cadence DSI bridge, and the CSI > transceiver and receivers. All of them are integrated with the same phy, or > can be integrated with different phy, depending on the implementation. > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > parameters I could find. The interface should be complete, and most of the > drivers can be converted in the future. The current set converts two of > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > use them, and the Allwinner MIPI-DSI driver. > > Let me know what you think, > Maxime > > Changes from v3 > - Rebased on 5.0-rc1 > - Added the fixes suggested by Sakari Thanks! For patches 1--3: Acked-by: Sakari Ailus -- Sakari Ailus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/9] dt-bindings: phy: Move the Cadence D-PHY bindings
Hi Maxime,
On Wed, Jan 09, 2019 at 10:33:24AM +0100, Maxime Ripard wrote:
> The Cadence D-PHY bindings was defined as part of the DSI block so far.
> However, since it's now going to be a separate driver, we need to move the
> binding to a file of its own.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Sakari Ailus
Could you also send this to the devicetree list, please?
> ---
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +---
> Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +++-
> 2 files changed, 20 insertions(+), 21 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> index f5725bb6c61c..525a4bfd8634 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> @@ -31,28 +31,7 @@ Required subnodes:
> - one subnode per DSI device connected on the DSI bus. Each DSI device should
>contain a reg property encoding its virtual channel.
>
> -Cadence DPHY
> -
> -
> -Cadence DPHY block.
> -
> -Required properties:
> -- compatible: should be set to "cdns,dphy".
> -- reg: physical base address and length of the DPHY registers.
> -- clocks: DPHY reference clocks.
> -- clock-names: must contain "psm" and "pll_ref".
> -- #phy-cells: must be set to 0.
> -
> -
> Example:
> - dphy0: dphy@fd0e{
> - compatible = "cdns,dphy";
> - reg = <0x0 0xfd0e 0x0 0x1000>;
> - clocks = <&psm_clk>, <&pll_ref_clk>;
> - clock-names = "psm", "pll_ref";
> - #phy-cells = <0>;
> - };
> -
> dsi0: dsi@fd0c {
> compatible = "cdns,dsi";
> reg = <0x0 0xfd0c 0x0 0x1000>;
> diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> new file mode 100644
> index ..1095bc4e72d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
> @@ -0,0 +1,20 @@
> +Cadence DPHY
> +
> +
> +Cadence DPHY block.
> +
> +Required properties:
> +- compatible: should be set to "cdns,dphy".
> +- reg: physical base address and length of the DPHY registers.
> +- clocks: DPHY reference clocks.
> +- clock-names: must contain "psm" and "pll_ref".
> +- #phy-cells: must be set to 0.
> +
> +Example:
> + dphy0: dphy@fd0e{
> + compatible = "cdns,dphy";
> + reg = <0x0 0xfd0e 0x0 0x1000>;
> + clocks = <&psm_clk>, <&pll_ref_clk>;
> + clock-names = "psm", "pll_ref";
> + #phy-cells = <0>;
> + };
> --
> git-series 0.9.1
--
Sakari Ailus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 8/9] phy: Add Cadence D-PHY support
On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote: > Cadence has designed a D-PHY that can be used by the, currently in tree, > DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers. > > Only the DSI driver has an ad-hoc driver for that phy at the moment, while > the v4l2 drivers are completely missing any phy support. In order to make > that phy support available to all these drivers, without having to > duplicate that code three times, let's create a generic phy framework > driver. > > Signed-off-by: Maxime Ripard Reviewed-by: Sakari Ailus -- Sakari Ailus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: Fix atomic mode switching regression
Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.
This commit fixed atomic crtc modesetting but didn't update the display
parameters when changing mode, but only when starting a mode setting after
a crtc disable.
This commit setups the crctc parameter in _begin() and _enable() to
take in account the current ctrc parameters.
Reported-by: Tony McKahan
Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 75d97f1b2e8f..5bb432021caf 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,14 +82,12 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
};
-static void meson_crtc_enable(struct drm_crtc *crtc)
+static void meson_crtc_setup(struct drm_crtc *crtc)
{
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
- DRM_DEBUG_DRIVER("\n");
-
if (!crtc_state) {
DRM_ERROR("Invalid crtc_state\n");
return;
@@ -98,6 +96,16 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
/* Enable VPP Postblend */
writel(crtc_state->mode.hdisplay,
priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
+}
+
+static void meson_crtc_enable(struct drm_crtc *crtc)
+{
+ struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
+ struct meson_drm *priv = meson_crtc->priv;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ meson_crtc_setup(crtc);
/* VD1 Preblend vertical start/end */
writel(FIELD_PREP(GENMASK(11, 0), 2303),
@@ -121,6 +129,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
if (!meson_crtc->enabled)
meson_crtc_enable(crtc);
+ else
+ meson_crtc_setup(crtc);
priv->viu.osd1_enabled = true;
}
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] drm/panel: Add a driver for the TPO TPG110
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is pretty minimalistic right now but can be
extended to handle non-default polarities, gamma correction
etc.
The driver is based on the baked-in code in
drivers/video/fbdev/amba-clcd-nomadik.c which will be
decomissioned once this us upstream.
Acked-by: Sam Ravnborg
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Collected Sam's ACK.
ChangeLog v4->v5:
- Assign proper bus_flags.
- This is now the only remaining patch.
ChangeLog v3->v4:
- Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
ChangeLog v2->v3:
- Rewrite as an SPI child device.
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 511 +++
4 files changed, 529 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 32d76a90..e177473d5417 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4909,6 +4909,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
+DRM DRIVER FOR TPO TPG110 PANELS
+M: Linus Walleij
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
+F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+
DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
M: Dave Airlie
R: Sean Paul
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3f3537719beb..e3821180b6cd 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -204,6 +204,16 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TPO_TPG110
+ tristate "TPO TPG 800x400 panel"
+ depends on OF && SPI && GPIOLIB
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for TPO TPG110
+ 400CH LTPS TFT LCD Single Chip Digital Driver for up to
+ 800x400 LCD panels.
+
config DRM_PANEL_TRULY_NT35597_WQXGA
tristate "Truly WQXGA"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4396658a7996..cd14ca39c6e0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
new file mode 100644
index ..d7c3541fdf28
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
+ * Digital Driver.
+ *
+ * This chip drives a TFT LCD, so it does not know what kind of
+ * display is actually connected to it, so the width and height of that
+ * display needs to be supplied from the machine configuration.
+ *
+ * Author:
+ * Linus Walleij
+ */
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define TPG110_TEST0x00
+#define TPG110_CHIPID 0x01
+#define TPG110_CTRL1 0x02
+#define TPG110_RES_MASKGENMASK(2, 0)
+#define TPG110_RES_800X480 0x07
+#define TPG110_RES_640X480 0x06
+#define TPG110_RES_480X272 0x05
+#define TPG110_RES_480X640 0x04
+#define TPG110_RES_480X272_D 0x01 /* Dual scan: outputs 800x480 */
+#define TPG110_RES_400X240_D 0x00 /* Dual scan: outputs 800x480 */
+#define TPG110_CTRL2 0x03
+#define TPG110_CTRL2_PMBIT(0)
+#define TPG110_CTRL2_RES_PM_CTRL BIT(7)
+
+/**
+ * struct tpg110_panel_mode - lookup struct for the supported modes
+ */
+struct tpg110_panel_mode {
+ /**
+* @name: the name of this panel
+*/
+ const char *name;
+ /**
+* @magic: the magic value from the detection register
+*/
+ u32 magic;
+ /**
+* @mode: the DRM display mode for this panel
+*/
+ struct drm_disp
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #13 from Nicholas Kazlauskas --- (In reply to Michel Dänzer from comment #12) > (In reply to tme from comment #9) > > Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem. > > It does, however, reproduce on 4.17.19. > > Can you bisect between 4.16.18 and 4.17.19? > > (I see some HPD filtering related changes between them, Nicholas / Harry > maybe you can take a look if anything jumps out?) I haven't had a chance to look into the HPD changes yet, but we haven't seen this bug occur with our DPMS tests so I'm guessing that it's monitor specific. A system environment with Ubuntu/Plasma/xf86-video-amdgpu seems pretty standard at least. A bisection point on amd-staging-drm-next would certainly help narrow this down. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin
On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote: > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote: > > The buffer object must be reserved before calling > > ttm_bo_validate for pinning/unpinning. > > > > Signed-off-by: Gerd Hoffmann > > Seems a bit a bisect fumble in your series here: legacy kms code reserved > the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I > think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to > avoid bisect fail I think you need to have these temporarily in your > cleanup/prepare_plane functions too. I think I've sorted that. Have some other changes too, will probably send v3 tomorrow. > Looked through the entire series, this here is the only issue I think > should be fixed before merging (making atomic_enable optional can be done > as a follow-up if you feel like it). With that addressed on the series: > > Acked-by: Daniel Vetter Thanks. While being at it: I'm also looking at dma-buf export and import support for the qemu drivers. Right now both qxl and virtio have gem_prime_get_sg_table and gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return an error. If I understand things correctly it is valid to set all import/export callbacks (prime_handle_to_fd, prime_fd_to_handle, gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not supporting dma-buf import/export and still advertise DRIVER_PRIME to indicate the other prime callbacks are supported (so generic fbdev emulation can use gem_prime_vmap etc). Is that correct? On exporting: TTM_PL_TT should be easy, just pin the buffer, grab the pages list and feed that into drm_prime_pages_to_sg. Didn't try yet though. Is that approach correct? Is it possible to export TTM_PL_VRAM objects (with backing storage being a pci memory bar)? If so, how? On importing: Importing into TTM_PL_TT object looks easy again, at least when the object is actually stored in RAM. What if not? Importing into TTM_PL_VRAM: Impossible I think, without copying over the data. Should that be done? If so, how? Or is it better to just not support import then? thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104362] GPU fault detected on wine-nine Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=104362 nmr changed: What|Removed |Added CC||nnmmrr88...@gmail.com --- Comment #10 from nmr --- Created attachment 143036 --> https://bugs.freedesktop.org/attachment.cgi?id=143036&action=edit UMR dump for PoE/gallium-nine induced AMDGPU hang I am experiencing the same bug, here is the UMR dump. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
On 09/01/19 11:51, Lucas Stach wrote: > For the series: > > Tested-by: Lucas Stach > > on a device with TC358767 and a 4.20 based kernel. Thanks Lucas. Does the device use TC358767 as eDP+panel, or as full DP with an external connector? We have the latter, and I think there are some missing pieces in the driver which I'll be working on some time in the near future. 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
[Bug 104362] GPU fault detected on wine-nine Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #11 from nmr --- Created attachment 143037 --> https://bugs.freedesktop.org/attachment.cgi?id=143037&action=edit dmesg dump for hang -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 0/7] drm/bridge: tc358767: small fixes
Hi Tomi, Am Mittwoch, den 09.01.2019, 16:55 +0200 schrieb Tomi Valkeinen: > On 09/01/19 11:51, Lucas Stach wrote: > > > For the series: > > > > > > Tested-by: Lucas Stach > > > > on a device with TC358767 and a 4.20 based kernel. > > Thanks Lucas. > > Does the device use TC358767 as eDP+panel, or as full DP with an > external connector? We have the latter, and I think there are some > missing pieces in the driver which I'll be working on some time in the > near future. It's eDP + panel. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.
On 01/09/2019 05:22 AM, Christian König wrote:
> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>
>> On 01/07/2019 09:13 AM, Christian König wrote:
>>> Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
>> Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
>>> On 12/21/2018 01:37 PM, Christian König wrote:
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled HW fences
> to complete before rerunning the jobs.
>
> v2: Fix resubmission of guilty job into HW after refactoring.
>
> v4:
> Full restart for all the jobs, not only from guilty ring.
> Extract karma increase into standalone function.
>
> v5:
> Rework waiting for signaled jobs without relying on the job
> struct itself as those might already be freed for non 'guilty'
> job's schedulers.
> Expose karma increase to drivers.
>
> Suggested-by: Christian Koenig
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 +--
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 11 +-
> drivers/gpu/drm/scheduler/sched_main.c | 188
> +++--
> drivers/gpu/drm/v3d/v3d_sched.c | 12 +-
> include/drm/gpu_scheduler.h | 10 +-
> 5 files changed, 151 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 8a078f4..a4bd2d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3298,12 +3298,10 @@ static int
> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
> - kthread_park(ring->sched.thread);
> + drm_sched_stop(&ring->sched, job ? &job->base : NULL);
> - if (job && job->base.sched != &ring->sched)
> - continue;
> -
> - drm_sched_hw_job_reset(&ring->sched, job ? &job->base :
> NULL);
> + if(job)
> + drm_sched_increase_karma(&job->base);
Since we dropped the "job && job->base.sched != &ring->sched"
check
above this will now increase the jobs karma multiple times.
Maybe just move that outside of the loop.
> /* after all hw jobs are reset, hw fence is
> meaningless,
> so force_completion */
> amdgpu_fence_driver_force_completion(ring);
> @@ -3454,14 +3452,10 @@ static void
> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
> - /* only need recovery sched of the given job's
> ring
> - * or all rings (in the case @job is NULL)
> - * after above amdgpu_reset accomplished
> - */
> - if ((!job || job->base.sched == &ring->sched) &&
> !adev->asic_reset_res)
> - drm_sched_job_recovery(&ring->sched);
> + if (!adev->asic_reset_res)
> + drm_sched_resubmit_jobs(&ring->sched);
> - kthread_unpark(ring->sched.thread);
> + drm_sched_start(&ring->sched, !adev->asic_reset_res);
> }
> if (!amdgpu_device_has_dc_support(adev)) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 49a6763..6f1268f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -109,16 +109,19 @@ static void
> etnaviv_sched_timedout_job(struct
> drm_sched_job *sched_job)
> }
> /* block scheduler */
> - kthread_park(gpu->sched.thread);
> - drm_sched_hw_job_reset(&gpu->sched, sched_job);
> + drm_sched_stop(&gpu->sched, sched_job);
> +
> + if(sched_job)
> + drm_sched_increase_karma(sched_job);
> /* get the GPU back into the init state */
> etnaviv_core_dump(gpu);
> etnaviv_gpu_recover_hang(gpu);
> + drm_sched_resubmit_jobs(&gpu->sched);
> +
>
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #11 from Sibren Vasse --- I've been running into this issue multiple times a day. I noticed I hit the OOPS a lot more frequent when my system was under load (e.g. compiling a kernel) and then opening a new tab in Firefox. Don't ask me how, but eventually I figured out I could reproduce the problem reliably on my system by starting many instances of my terminal emulator until I hit the OOM killer. v4.20 (good): OOM Killer kills processes and/or my user session and I can login again. v5.0-rc1 (bad): System hangs with OOPS in dmesg. So I started bisecting, result attached. I have not been able to reproduce after reverting parent merge commit [af7ddd8a627c62a835524b3f5b471edbbbcce025] and these related commits: 06f55fd2d22742ed7e725124dfea68936d12ce40 2e05ea5cdc1ac55d9ef678ed5ea6c38acf7fd2a3 d7076f07840851bbe57cb21ba052d6a4a9b1efa9 4788ba5792cc1368ba4867e1488dc168b4fe97b7 ed6ccf10f24bdfc1955bc8b976ddedc370fc3869 See the full tree here: https://github.com/SibrenVasse/linux/tree/revert Hope this helps! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #10 from Sibren Vasse --- Created attachment 143038 --> https://bugs.freedesktop.org/attachment.cgi?id=143038&action=edit Bisect result -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109234] amdgpu random hangs with 4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #12 from Michel Dänzer --- Looks like this should be reported to Christoph Hellwig and other kernel DMA mapping helper developers then. Please Cc the dri-devel mailing list when doing so. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.
The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148,
v4.4.169, v3.18.131.
v4.20.0: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
v4.19.13: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
v4.14.91: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
4cc4e1b40f3f ("drm/fourcc: Add a alpha field to drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
ce2d54619a10 ("drm/fourcc: Add is_yuv field to drm_format_info to denote if
the format is yuv")
v4.9.148: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
05fc03217e08 ("drm/mm: Some doc polish")
06df8ac682e6 ("drm: kselftest for drm_mm_debug()")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
2bd966d106e3 ("drm: kselftest for drm_mm_replace_node()")
2fba0de0a9ec ("drm: kselftest for drm_mm_insert_node_in_range()")
393b50f30566 ("drm: kselftest for drm_mm_init()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
50f0033d1a0f ("drm: Add some kselftests for the DRM range manager (struct
drm_mm)")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
6259a56ba0e1 ("drm: Add asserts to catch overflow in drm_mm_init() and
drm_mm_init_scan()")
62a0d98a188c ("drm: allow to use mmuless SoC")
72a93e8dd52c ("drm: Take ownership of the dmabuf->obj when exporting")
7886692a5804 ("drm: kselftest for drm_mm_insert_node()")
900537dc3889 ("drm: kselftest for drm_mm_reserve_node()")
940eba2d58a7 ("drm/gem|prime|mm: Use recommened kerneldoc for struct member
refs")
9a71e277888b ("drm: Extract struct drm_mm_scan from struct drm_mm")
9b26f2ed29f8 ("drm: kselftest for drm_mm and alignment")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty
callbacks")
b3ee963fe41d ("drm: Compile time enabling for asserts in drm_mm")
ba004e39b199 ("drm: Fix kerneldoc for drm_mm_scan_remove_block()")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
e6b62714e87c ("drm: Introduce drm_gem_object_{get,put}()")
v4.4.169: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to
.fb_create()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
70c0616d5a84 ("drm/fb_cma_helper: remove duplicate const from
drm_fb_cma_alloc")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty
callbacks")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
ce0c57576810 ("drm/fb_cma_helper: Implement fb_mmap callback")
fdce184609ee ("drm/fb-cma-helper: Use const for drm_framebuffer_funcs
argument")
v3.18.131: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to
.fb_create()")
2a8cb4894540 ("drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c")
2b8376c803c4 ("drm/exynos: remove struct exynos_drm_encoder layer")
39a839f2e651 ("drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c")
421ee18d4e04 ("drm/exynos: fix null pointer dereference issue")
Re: [PATCH v2 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.
The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148,
v4.4.169, v3.18.131.
v4.20.0: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
v4.19.13: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
v4.14.91: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
4cc4e1b40f3f ("drm/fourcc: Add a alpha field to drm_format_info")
9c71a6686bfa ("drm: fourcc: Convert drm_format_info kerneldoc to in-line
member documentation")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
ce2d54619a10 ("drm/fourcc: Add is_yuv field to drm_format_info to denote if
the format is yuv")
v4.9.148: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
05fc03217e08 ("drm/mm: Some doc polish")
06df8ac682e6 ("drm: kselftest for drm_mm_debug()")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
2bd966d106e3 ("drm: kselftest for drm_mm_replace_node()")
2fba0de0a9ec ("drm: kselftest for drm_mm_insert_node_in_range()")
393b50f30566 ("drm: kselftest for drm_mm_init()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
50f0033d1a0f ("drm: Add some kselftests for the DRM range manager (struct
drm_mm)")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
6259a56ba0e1 ("drm: Add asserts to catch overflow in drm_mm_init() and
drm_mm_init_scan()")
62a0d98a188c ("drm: allow to use mmuless SoC")
72a93e8dd52c ("drm: Take ownership of the dmabuf->obj when exporting")
7886692a5804 ("drm: kselftest for drm_mm_insert_node()")
900537dc3889 ("drm: kselftest for drm_mm_reserve_node()")
940eba2d58a7 ("drm/gem|prime|mm: Use recommened kerneldoc for struct member
refs")
9a71e277888b ("drm: Extract struct drm_mm_scan from struct drm_mm")
9b26f2ed29f8 ("drm: kselftest for drm_mm and alignment")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty
callbacks")
b3ee963fe41d ("drm: Compile time enabling for asserts in drm_mm")
ba004e39b199 ("drm: Fix kerneldoc for drm_mm_scan_remove_block()")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
e6b62714e87c ("drm: Introduce drm_gem_object_{get,put}()")
v4.4.169: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to
.fb_create()")
4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
5628648df755 ("drm/fb-cma-helper: Use drm_gem_framebuffer_helper")
70c0616d5a84 ("drm/fb_cma_helper: remove duplicate const from
drm_fb_cma_alloc")
b112481bb327 ("drm/cma-helper: simplify setup for drivers with ->dirty
callbacks")
c76abab59b3c ("drm: Use horizontal and vertical chroma subsampling factor
while calculating offsets in the physical address of framebuffer")
ce0c57576810 ("drm/fb_cma_helper: Implement fb_mmap callback")
fdce184609ee ("drm/fb-cma-helper: Use const for drm_framebuffer_funcs
argument")
v3.18.131: Failed to apply! Possible dependencies:
042bf753842d ("drm/fourcc: Add char_per_block, block_w and block_h in
drm_format_info")
14d7f96f90fb ("drm/fb_cma_helper: Add drm_fb_cma_prepare_fb() helper")
199c77179c87 ("drm/fb-cma-helper: Add fb_deferred_io support")
1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
1eb83451ba55 ("drm: Pass the user drm_mode_fb_cmd2 as const to
.fb_create()")
2a8cb4894540 ("drm/exynos: merge exynos_drm_buf.c to exynos_drm_gem.c")
2b8376c803c4 ("drm/exynos: remove struct exynos_drm_encoder layer")
39a839f2e651 ("drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.c")
421ee18d4e04 ("drm/exynos: fix null pointer dereference issue")
Re: [PATCH v4 2/3] drm/msm/dpu: Integrate interconnect API in MDSS
Hi, On Wed, Jan 9, 2019 at 6:38 AM Georgi Djakov wrote: > > Hi Jayant, > > On 12/21/18 08:20, Jayant Shekhar wrote: > > From: Sravanthi Kollukuduru > > > > The interconnect framework is designed to provide a > > standard kernel interface to control the settings of > > the interconnects on a SoC. > > > > The interconnect API uses a consumer/provider-based model, > > where the providers are the interconnect buses and the > > consumers could be various drivers. > > > > MDSS is one of the interconnect consumers which uses the > > interconnect APIs to get the path between endpoints and > > set its bandwidth/latency/QoS requirements for the given > > Currently we set only bandwidth. > > > interconnected path. > > > > Changes in v2: > > - Remove error log and unnecessary check (Jordan Crouse) > > > > Changes in v3: > > - Code clean involving variable name change, removal > > of extra paranthesis and variables (Matthias Kaehlcke) > > > > Changes in v4: > > - Add comments, spacings, tabs, proper port name > > and icc macro (Georgi Djakov) > > The changes should not be part of the commit text, but should move below > the "---" line. Drive-by comment that (I believe) they actually should be part of the commit text. Convention for changes in the "drm" subsystem appears to be to include the revision log in the commit text. This is unlike the rest of the kernel, but *shrug*. Try, for instance: git log --no-merges v4.19..v5.0-rc1 drivers/gpu/drm/msm | grep 'v[0-9]' -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit
Hi Daniel,
On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
> wrote:
> > During an atomic commit, the HVS is configured with a display list
> > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> > and encoder are also configured for the new setup at that time.
> > While the Pixel Valve and encoder are reconfigured synchronously, the
> > HVS is only reconfigured after the display list address (DISPLIST) has
> > been updated to the current display list address (DISPLACTX), which is
> > the responsibility of the hardware.
> >
> > The time frame during which the HVS is still running on its previous
> > configuration but the CRTC and encoder have been reconfigured already
> > can lead to a number of synchronization issues. They will eventually
> > cause errors reported on the FIFOs, such as underruns.
> >
> > With underrun detection enabled (from Boris Brezillon's series), this
> > leads to unreliable underrun detection with random false positives.
> >
> > To ensure a coherent state, wait for each enabled channel of the HVS
> > to synchronize its current display list address. This fixes the issue
> > of random underrun reporting on commits.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> > drivers/gpu/drm/vc4/vc4_hvs.c | 17 +
> > drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
> > drivers/gpu/drm/vc4/vc4_regs.h | 2 ++
> > 4 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index c24b078f0593..955f157f5ad0 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
> > extern struct platform_driver vc4_hvs_driver;
> > void vc4_hvs_dump_state(struct drm_device *dev);
> > int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
> > +void vc4_hvs_sync_dlist(struct drm_device *dev);
> >
> > /* vc4_kms.c */
> > int vc4_kms_load(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > index 5d8c749c9749..1ba60b8e0c2d 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs
> > *hvs,
> > return 0;
> > }
> >
> > +void vc4_hvs_sync_dlist(struct drm_device *dev)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + unsigned int i;
> > + int ret;
> > +
> > + for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
> > + if (!(HVS_READ(SCALER_DISPCTRLX(i)) &
> > SCALER_DISPCTRLX_ENABLE))
> > + continue;
> > +
> > + ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
> > + HVS_READ(SCALER_DISPLISTX(i)), 1000);
> > + WARN(ret, "Timeout waiting for channel %d display list
> > sync\n",
> > +i);
> > + }
> > +}
> > +
> > static int vc4_hvs_bind(struct device *dev, struct device *master, void
> > *data)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > index 0490edb192a1..2d66a2b57a91 100644
> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state
> > *state)
> >
> > drm_atomic_helper_commit_hw_done(state);
> >
> > + vc4_hvs_sync_dlist(dev);
>
> From your description I'd have guessed you want this between when you
> update the planes and the crtc, so somewhere between commit_planes()
> and commit_modeset_enables(). At least I have no idea how waiting here
> can prevent underruns, by this point there's no further hw programming
> happening.
One thing that I did not mention is that the display list (that
configures the planes) is only set at crtc_enable time (and taken into
account by the hardware later).
However, even calling vc4_hvs_sync_dlist right at the end of
crtc_enable doesn't do either (the old display list just sticks). It
only seems to work after the HDMI encoder enable step and I don't know
any good reason why.
I didn't find any description of when that dlist sync mechanism is
supposed to take place and what particular event triggers it. Perhaps
it is triggered by a signal originating from the encoder? If anyone has
insight on the hardware, feel free to shed some light here :)
Cheers and thanks for the review,
Paul
> Only exception is if you have an IOMMU which can fault, in
> which case the cleanup_planes might remove the buffers prematurely.
> But if that's the problem, then your semantics of the flip_done event
> are wrong - when flip_done is signalled, the hw must have stopped
> scanning out the old planes, since userspace expects to be able to
> start overwriting/reusing them.
[Bug 109235] Using named pixmap of window right after resizing results in garbage content
https://bugs.freedesktop.org/show_bug.cgi?id=109235 Michel Dänzer changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |xorg-t...@lists.x.org |.org| Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org |.org| Product|Mesa|xorg Version|unspecified |git Component|Drivers/Gallium/radeonsi|Driver/AMDgpu --- Comment #2 from Michel Dänzer --- Does https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 fix it? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
Hi Sean, I do recall seeing you at XDC2017, I do not believe I spoke with you at the event. I will not name the name, but I had one developer who strongly asked me to convert to atomic mode setting, but I refused due to the state of the code at the time. Now, the KMS device support is mostly comparable to the existing UMS code path, so I can soon consider implementing universal plane and atomic mode setting. I am okay with the OpenChrome DRM not being activated initially (i.e., Displaying "(Experimental)" status when running menuconfig), but I do want it directly inserted into the DRM tree from day one after the code is pulled in. (i.e., not getting inserted into the "staging" tree) I believe the current code quality is good enough for this arrangement. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com > Sent: Wednesday, June 13, 2018 at 1:07 PM > From: "Sean Paul" > To: kevinbr...@gmx.com > Cc: "Dave Airlie" , dri-devel > , openchrome-de...@lists.freedesktop.org > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree > > I think I was one of those developers asking you to switch to atomic > (iirc, i encouraged you to start working on kms instead of ums). I > know this is a personal project that you've been working on in your > spare time (which is awesome!), so while I still encourage you to > convert the driver, I don't have a problem with you doing the > conversion in mainline. I think hiding under staging until the > conversion is complete is a pretty reasonable compromise. > > Sean > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] drm/mxsfb: Improve the axi clock usage
On 09.01.2019 15:13, Robert Chiras wrote:
> Currently, the enable of the axi clock return status is ignored, causing
> issues when the enable fails then we try to disable it. Therefore, it is
> better to check the return status and disable it only when enable
> succeeded.
> Also, remove the helper functions around clk_axi, since we can directly
> use the clk API function for enable/disable the clock. Those functions
> are already checking for NULL clk and returning 0 if that's the case.
Can we maybe even use the runtime PM system for that (adding two
callbacks for SET_RUNTIME_PM_OPS)?
I suggested it a while ago, but did not looked deeper into it:
https://lkml.org/lkml/2018/8/1/300
Since we basically enable on mxsfb_crtc_enable and disable on
mxsfb_crtc_disable, I think it would be pretty much the same thing.
--
Stefan
>
> Signed-off-by: Robert Chiras
> Acked-by: Leonard Crestez
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 32 +---
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 3 ---
> 3 files changed, 17 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 8d1b6a6..b9437c7 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -411,7 +411,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
> {
> dma_addr_t paddr;
>
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
> writel(0, mxsfb->base + LCDC_CTRL);
> mxsfb_crtc_mode_set_nofb(mxsfb);
>
> @@ -428,7 +428,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
> void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
> {
> mxsfb_disable_controller(mxsfb);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
> }
>
> void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
> @@ -456,9 +456,9 @@ void mxsfb_plane_atomic_update(struct
> mxsfb_drm_private *mxsfb,
>
> paddr = mxsfb_get_fb_paddr(mxsfb);
> if (paddr) {
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
> writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
> }
>
> if (!fb || !old_fb)
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 135b8e1..5e18353 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -103,18 +103,6 @@ drm_pipe_to_mxsfb_drm_private(struct
> drm_simple_display_pipe *pipe)
> return container_of(pipe, struct mxsfb_drm_private, pipe);
> }
>
> -void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
> -{
> - if (mxsfb->clk_axi)
> - clk_prepare_enable(mxsfb->clk_axi);
> -}
> -
> -void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
> -{
> - if (mxsfb->clk_axi)
> - clk_disable_unprepare(mxsfb->clk_axi);
> -}
> -
> /**
> * mxsfb_atomic_helper_check - validate state object
> * @dev: DRM device
> @@ -237,25 +225,31 @@ static void mxsfb_pipe_update(struct
> drm_simple_display_pipe *pipe,
> static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
> {
> struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
> + int ret = 0;
> +
> + ret = clk_prepare_enable(mxsfb->clk_axi);
> + if (ret)
> + return ret;
>
> /* Clear and enable VBLANK IRQ */
> - mxsfb_enable_axi_clk(mxsfb);
> writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
> writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
>
> - return 0;
> + return ret;
> }
>
> static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe *pipe)
> {
> struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>
> + if (clk_prepare_enable(mxsfb->clk_axi))
> + return;
> +
> /* Disable and clear VBLANK IRQ */
> - mxsfb_enable_axi_clk(mxsfb);
> writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
> writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
> - mxsfb_disable_axi_clk(mxsfb);
> + clk_disable_unprepare(mxsfb->clk_axi);
> }
>
> static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
> @@ -440,7 +434,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
> struct mxsfb_drm_private *mxsfb = drm->dev_private;
> u32 reg;
>
> - mxsfb_enable_axi_clk(mxsfb);
> + clk_prepare_enable(mxsfb->clk_axi);
>
> reg = readl(mxsfb->base + LCDC_CTRL1);
>
> @@ -449,7 +443,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
>
> writ
[Bug 108098] Ryzen 7 2700U, amdgpu, graphics freezes on 4.19.0-041900-generic
https://bugs.freedesktop.org/show_bug.cgi?id=108098 --- Comment #9 from Daniel Stone --- (In reply to Michel Dänzer from comment #7) > FWIW, I advise against paying too much attention to fin4478. They are not > involved in driver development and known for making rather questionable > suggestions which are definitely not suitable for everyone. @finn4478: Please stop posting in these bugs asserting which distributions/environments/etc do and don't work. Most of what you say is not factual, and though I'm sure you have good intentions, you are misleading users and frustrating both users and developers. If you do not stop with these interjections, we may have to remove your ability to comment. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin
On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann wrote: > > On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote: > > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote: > > > The buffer object must be reserved before calling > > > ttm_bo_validate for pinning/unpinning. > > > > > > Signed-off-by: Gerd Hoffmann > > > > Seems a bit a bisect fumble in your series here: legacy kms code reserved > > the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I > > think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to > > avoid bisect fail I think you need to have these temporarily in your > > cleanup/prepare_plane functions too. > > I think I've sorted that. Have some other changes too, will probably > send v3 tomorrow. > > > Looked through the entire series, this here is the only issue I think > > should be fixed before merging (making atomic_enable optional can be done > > as a follow-up if you feel like it). With that addressed on the series: > > > > Acked-by: Daniel Vetter > > Thanks. > > While being at it: I'm also looking at dma-buf export and import > support for the qemu drivers. > > Right now both qxl and virtio have gem_prime_get_sg_table and > gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return > an error. > > If I understand things correctly it is valid to set all import/export > callbacks (prime_handle_to_fd, prime_fd_to_handle, > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not > supporting dma-buf import/export and still advertise DRIVER_PRIME to > indicate the other prime callbacks are supported (so generic fbdev > emulation can use gem_prime_vmap etc). Is that correct? I'm not sure how much that's a good idea ... Never thought about it tbh. All the fbdev/dma-buf stuff has plenty of hacks and inconsistencies still, so I guess we can't make it much worse really. > On exporting: > > TTM_PL_TT should be easy, just pin the buffer, grab the pages list and > feed that into drm_prime_pages_to_sg. Didn't try yet though. Is that > approach correct? > > Is it possible to export TTM_PL_VRAM objects (with backing storage being > a pci memory bar)? If so, how? Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO) and then knows the internals so it can do a proper pci peer2peer mapping. Or at least there's been lots of patches floating around to make that happen. I think other drivers migrate the bo out of VRAM. > On importing: > > Importing into TTM_PL_TT object looks easy again, at least when the > object is actually stored in RAM. What if not? They are all supposed to be stored in RAM. Note that all current ttm importers totally break the abstraction, by taking the sg list, throwing the dma mapping away and assuming there's a struct page backing it. Would be good if we could stop spreading that abuse - the dma-buf interfaces have been modelled after the ttm bo interfaces, so shouldn't be too hard to wire this up correctly. > Importing into TTM_PL_VRAM: Impossible I think, without copying over > the data. Should that be done? If so, how? Or is it better to just > not support import then? Hm, since you ask about TTM concepts and not what this means in terms of dma-buf: As long as you upcast to the ttm_bo you can do whatever you want to really. But with plain dma-buf this doesn't work right now (least because ttm assumes it gets system RAM on import, in theory you could put the peer2peer dma mapping into the sg list and it should work). -Daniel > > thanks, > Gerd > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107652] amdgpu couldn't resume after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=107652 Mart Raudsepp changed: What|Removed |Added CC||l...@gentoo.org --- Comment #17 from Mart Raudsepp --- Created attachment 143042 --> https://bugs.freedesktop.org/attachment.cgi?id=143042&action=edit kernel log pre and post suspend I still hit something like this with a 4.20 kernel. Perhaps it gives additional data points to figure it out. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb
Hi, I was really pleased to see that the damage helper had landed. Now I can do framebuffer flushing solely through the display pipe functions. This prepares the ground for the removal of struct tinydrm_device in my next series. Note: The damage helper isn't in drm-misc-next yet, it will show up when -rc1 arrives there. Noralf. Noralf Trønnes (4): drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty() drm/damage-helper: Add drm_atomic_helper_damage_merged() drm/tinydrm: Use struct drm_rect drm/tinydrm: Use damage helper for dirtyfb drivers/gpu/drm/drm_damage_helper.c | 43 ++ drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +- drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 21 +-- .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 + drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 30 drivers/gpu/drm/tinydrm/hx8357d.c | 2 +- drivers/gpu/drm/tinydrm/ili9225.c | 138 +++--- drivers/gpu/drm/tinydrm/ili9341.c | 2 +- drivers/gpu/drm/tinydrm/mi0283qt.c| 2 +- drivers/gpu/drm/tinydrm/mipi-dbi.c| 87 +++ drivers/gpu/drm/tinydrm/repaper.c | 42 +++--- drivers/gpu/drm/tinydrm/st7586.c | 73 - drivers/gpu/drm/tinydrm/st7735r.c | 2 +- include/drm/drm_damage_helper.h | 3 + include/drm/drm_gem_framebuffer_helper.h | 3 + include/drm/tinydrm/mipi-dbi.h| 5 +- include/drm/tinydrm/tinydrm-helpers.h | 20 +-- include/drm/tinydrm/tinydrm.h | 26 18 files changed, 281 insertions(+), 365 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/tinydrm: Use damage helper for dirtyfb
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.
Also enable the damage plane property for all except repaper which can
only do full updates.
ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use it.
Cc: David Lechner
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 21 +---
.../gpu/drm/tinydrm/core/tinydrm-helpers.c| 91 +---
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 30 --
drivers/gpu/drm/tinydrm/hx8357d.c | 2 +-
drivers/gpu/drm/tinydrm/ili9225.c | 101 ++
drivers/gpu/drm/tinydrm/ili9341.c | 2 +-
drivers/gpu/drm/tinydrm/mi0283qt.c| 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c| 72 -
drivers/gpu/drm/tinydrm/repaper.c | 39 ---
drivers/gpu/drm/tinydrm/st7586.c | 50 +
drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
include/drm/tinydrm/mipi-dbi.h| 2 +
include/drm/tinydrm/tinydrm-helpers.h | 11 +-
include/drm/tinydrm/tinydrm.h | 26 -
14 files changed, 138 insertions(+), 313 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 01a6f2d42440..dca0f642fee6 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -36,31 +36,17 @@
* and registers the DRM device using devm_tinydrm_register().
*/
-static struct drm_framebuffer *
-tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- struct tinydrm_device *tdev = drm->dev_private;
-
- return drm_gem_fb_create_with_funcs(drm, file_priv, mode_cmd,
- tdev->fb_funcs);
-}
-
static const struct drm_mode_config_funcs tinydrm_mode_config_funcs = {
- .fb_create = tinydrm_fb_create,
+ .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
- const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
{
struct drm_device *drm;
- mutex_init(&tdev->dirty_lock);
- tdev->fb_funcs = fb_funcs;
-
/*
* We don't embed drm_device, because that prevent us from using
* devm_kzalloc() to allocate tinydrm_device in the driver since
@@ -83,7 +69,6 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
static void tinydrm_fini(struct tinydrm_device *tdev)
{
drm_mode_config_cleanup(tdev->drm);
- mutex_destroy(&tdev->dirty_lock);
tdev->drm->dev_private = NULL;
drm_dev_put(tdev->drm);
}
@@ -97,7 +82,6 @@ static void devm_tinydrm_release(void *data)
* devm_tinydrm_init - Initialize tinydrm device
* @parent: Parent device object
* @tdev: tinydrm device
- * @fb_funcs: Framebuffer functions
* @driver: DRM driver
*
* This function initializes @tdev, the underlying DRM device and it's
@@ -108,12 +92,11 @@ static void devm_tinydrm_release(void *data)
* Zero on success, negative error code on failure.
*/
int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
- const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
{
int ret;
- ret = tinydrm_init(parent, tdev, fb_funcs, driver);
+ ret = tinydrm_init(parent, tdev, driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d0ece6ad4a1c..2737b6fdadc8 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -17,104 +17,15 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
-#include
static unsigned int spi_max;
module_param(spi_max, uint, 0400);
MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
-/**
- * tinydrm_merge_clips - Merge clip rectangles
- * @dst: Destination clip rectangle
- * @src: Source clip rectangle(s)
- * @num_clips: Number of @src clip rectangles
- * @flags: Dirty fb ioctl flags
- * @max_width: Maximum width of @dst
- * @max_height: Maximum height of @dst
- *
- * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
- * @max_width and @min_width is used to set a full @dst clip rectangle.
- *
- * Returns:
- * true if it's a full clip, false otherwise
- */
-bool tinydrm_merge_clips(struct drm_rect *dst,
-struct drm_clip_rect *src, unsigned int num_clips,
-unsigned
[PATCH 1/4] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
This adds a .fb_create helper that sets the .dirty callback to
drm_atomic_helper_dirtyfb().
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
include/drm/drm_gem_framebuffer_helper.h | 3 ++
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index acb466d25afc..4edd0261e507 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
* @mode_cmd: Metadata from the userspace framebuffer creation request
* @funcs: vtable to be used for the new framebuffer object
*
- * This can be used to set &drm_framebuffer_funcs for drivers that need the
- * &drm_framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you don't
- * need to change &drm_framebuffer_funcs.
- * The function does buffer size validation.
+ * This function can be used to set &drm_framebuffer_funcs for drivers that
need
+ * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
+ * change &drm_framebuffer_funcs. The function does buffer size validation.
*
* Returns:
* Pointer to a &drm_framebuffer on success or an error pointer on failure.
@@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs drm_gem_fb_funcs
= {
*
* If your hardware has special alignment or pitch requirements these should be
* checked before calling this function. The function does buffer size
- * validation. Use drm_gem_fb_create_with_funcs() if you need to set
- * &drm_framebuffer_funcs.dirty.
+ * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
+ * flushing.
*
* Drivers can use this as their &drm_mode_config_funcs.fb_create callback.
* The ADDFB2 IOCTL calls into this callback.
@@ -233,6 +233,41 @@ drm_gem_fb_create(struct drm_device *dev, struct drm_file
*file,
}
EXPORT_SYMBOL_GPL(drm_gem_fb_create);
+static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
+};
+
+/**
+ * drm_gem_fb_create_with_dirty() - Helper function for the
+ * &drm_mode_config_funcs.fb_create callback
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function creates a new framebuffer object described by
+ * &drm_mode_fb_cmd2. This description includes handles for the buffer(s)
+ * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
+ * callback giving framebuffer flushing through the atomic machinery. Use
+ * drm_gem_fb_create() if you don't need the dirty callback.
+ * The function does buffer size validation.
+ *
+ * Drivers can use this as their &drm_mode_config_funcs.fb_create callback.
+ * The ADDFB2 IOCTL calls into this callback.
+ *
+ * Returns:
+ * Pointer to a &drm_framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
+ &drm_gem_fb_funcs_dirtyfb);
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+
/**
* drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
* @plane: Plane
diff --git a/include/drm/drm_gem_framebuffer_helper.h
b/include/drm/drm_gem_framebuffer_helper.h
index a38de7eb55b4..7f307e834eef 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct
drm_file *file,
struct drm_framebuffer *
drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd);
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd);
int drm_gem_fb_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *state);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/damage-helper: Add drm_atomic_helper_damage_merged()
Useful for drivers that only care about the combined damage.
Cc: Deepak Rawat
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_damage_helper.c | 43 +
include/drm/drm_damage_helper.h | 3 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index d2a1c7372f36..4ddf1b41a852 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -332,3 +332,46 @@ drm_atomic_helper_damage_iter_next(struct
drm_atomic_helper_damage_iter *iter,
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
+
+/**
+ * drm_atomic_helper_damage_merged - Merged plane damage
+ * @old_state: Old plane state for validation.
+ * @state: Plane state from which to iterate the damage clips.
+ * @rect: Returns the merged damage rectangle
+ *
+ * This function merges any valid plane damage clips into one rectangle and
+ * returns it in @rect. It also clears the plane damage.
+ *
+ * For details see: drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next().
+ *
+ * Returns:
+ * True if there is valid plane damage otherwise false.
+ */
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect)
+{
+ struct drm_atomic_helper_damage_iter iter;
+ struct drm_rect clip;
+ bool valid = false;
+
+ rect->x1 = INT_MAX;
+ rect->y1 = INT_MAX;
+ rect->x2 = 0;
+ rect->y2 = 0;
+
+ drm_atomic_helper_damage_iter_init(&iter, old_state, state);
+ drm_atomic_for_each_plane_damage(&iter, &clip) {
+ rect->x1 = min(rect->x1, clip.x1);
+ rect->y1 = min(rect->y1, clip.y1);
+ rect->x2 = max(rect->x2, clip.x2);
+ rect->y2 = max(rect->y2, clip.y2);
+ valid = true;
+ }
+
+ drm_property_replace_blob(&state->fb_damage_clips, NULL);
+
+ return valid;
+}
+EXPORT_SYMBOL(drm_atomic_helper_damage_merged);
diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
index 4487660b26b8..40c34a5bf149 100644
--- a/include/drm/drm_damage_helper.h
+++ b/include/drm/drm_damage_helper.h
@@ -78,6 +78,9 @@ drm_atomic_helper_damage_iter_init(struct
drm_atomic_helper_damage_iter *iter,
bool
drm_atomic_helper_damage_iter_next(struct drm_atomic_helper_damage_iter *iter,
struct drm_rect *rect);
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect);
/**
* drm_helper_get_plane_damage_clips - Returns damage clips in &drm_rect.
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/tinydrm: Use struct drm_rect
This prepares for the switch to drm_atomic_helper_dirtyfb() in the next
patch. The damage helper returns a drm_rect so switch to that everywhere
including using a pointer in the dirty functions.
This is a non-functional change except for the debug print which looks a
bit different.
Signed-off-by: Noralf Trønnes
---
.../gpu/drm/tinydrm/core/tinydrm-helpers.c| 19
drivers/gpu/drm/tinydrm/ili9225.c | 43 ++-
drivers/gpu/drm/tinydrm/mipi-dbi.c| 21 -
drivers/gpu/drm/tinydrm/repaper.c | 3 +-
drivers/gpu/drm/tinydrm/st7586.c | 27 ++--
include/drm/tinydrm/mipi-dbi.h| 3 +-
include/drm/tinydrm/tinydrm-helpers.h | 11 ++---
7 files changed, 67 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf6bfbc5d412..d0ece6ad4a1c 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -41,7 +42,7 @@ MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer
size");
* Returns:
* true if it's a full clip, false otherwise
*/
-bool tinydrm_merge_clips(struct drm_clip_rect *dst,
+bool tinydrm_merge_clips(struct drm_rect *dst,
struct drm_clip_rect *src, unsigned int num_clips,
unsigned int flags, u32 max_width, u32 max_height)
{
@@ -63,10 +64,10 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
for (i = 0; i < num_clips; i++) {
if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
i++;
- dst->x1 = min(dst->x1, src[i].x1);
- dst->x2 = max(dst->x2, src[i].x2);
- dst->y1 = min(dst->y1, src[i].y1);
- dst->y2 = max(dst->y2, src[i].y2);
+ dst->x1 = min_t(int, dst->x1, src[i].x1);
+ dst->x2 = max_t(int, dst->x2, src[i].x2);
+ dst->y1 = min_t(int, dst->y1, src[i].y1);
+ dst->y2 = max_t(int, dst->y2, src[i].y2);
}
if (dst->x2 > max_width || dst->y2 > max_height ||
@@ -122,7 +123,7 @@ EXPORT_SYMBOL(tinydrm_fb_dirty);
* @clip: Clip rectangle area to copy
*/
void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
- struct drm_clip_rect *clip)
+ struct drm_rect *clip)
{
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
unsigned int pitch = fb->pitches[0];
@@ -146,7 +147,7 @@ EXPORT_SYMBOL(tinydrm_memcpy);
* @clip: Clip rectangle area to copy
*/
void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
- struct drm_clip_rect *clip)
+ struct drm_rect *clip)
{
size_t len = (clip->x2 - clip->x1) * sizeof(u16);
unsigned int x, y;
@@ -186,7 +187,7 @@ EXPORT_SYMBOL(tinydrm_swab16);
*/
void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
- struct drm_clip_rect *clip, bool swap)
+ struct drm_rect *clip, bool swap)
{
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
@@ -235,7 +236,7 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
* ITU BT.601 is used for the RGB -> luma (brightness) conversion.
*/
void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer
*fb,
- struct drm_clip_rect *clip)
+ struct drm_rect *clip)
{
unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 78f7c2d1b449..cea70f9addcf 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -82,7 +83,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
struct tinydrm_device *tdev = fb->dev->dev_private;
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
bool swap = mipi->swap_bytes;
- struct drm_clip_rect clip;
+ struct drm_rect clip;
+ struct drm_rect *rect = &clip;
u16 x_start, y_start;
u16 x1, x2, y1, y2;
int ret = 0;
@@ -95,13 +97,12 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
fb->width, fb->height);
- DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u\n", fb->base.id,
- clip.x1, clip.x2, clip.y1, clip.y2);
+ DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
DRM_RECT_ARG(rect));
if (!mipi->dc || !full || swap |
[v5 0/3] Use interconnect API in MDSS on SDM845
The interconnect API provides an interface for consumer drivers to express their bandwidth needs in the SoC. This data is aggregated and the on-chip interconnect hardware is configured to the appropriate power/performance profile. MDSS is one of the interconnect consumers which uses the interconnect APIs to get the path between endpoints and set its bandwidth requirements for the given interconnected path. Subsequently, there is a clean up patch to remove all the references of the DPU custom bus scaling. There is corresponding DT patch with the source and destination ports defined for display driver which will be sent separately. Changes in v2: - Remove error log and unnecessary check (Jordan Crouse) - Fixed build error due to partial clean up Changes in v3: - Remove common property definitions (Rob Herring) - Code clean up involving variable name change, removal of extra paranthesis and variables (Matthias Kaehlcke) - Condense multiple lines into a single line (Sean Paul) Changes in v4: - Add comments, spacings, tabs, proper port name and icc macro - Use port macros and change port string names (Georgi Djakov) Changes in v5: - Updated commit text and parenthesis alignment (Georgi Djakov) Sravanthi Kollukuduru (3): drm/msm/dpu: clean up references of DPU custom bus scaling drm/msm/dpu: Integrate interconnect API in MDSS dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on SDM845 .../devicetree/bindings/display/msm/dpu.txt| 10 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 174 - drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 13 +- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 47 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 68 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 22 +-- 8 files changed, 144 insertions(+), 243 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 1/3] drm/msm/dpu: clean up references of DPU custom bus scaling
From: Sravanthi Kollukuduru
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (Sean Paul)
Changes in v4:
- None
Changes in v5:
- None
Signed-off-by: Sravanthi Kollukuduru
Signed-off-by: Jayant Shekhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c| 174 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h| 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 13 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 47 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 68 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h| 22 +--
6 files changed, 89 insertions(+), 239 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 22e84b3..c75536e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -84,7 +84,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
struct dpu_core_perf_params *perf)
{
struct dpu_crtc_state *dpu_cstate;
- int i;
if (!kms || !kms->catalog || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
@@ -95,35 +94,24 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
memset(perf, 0, sizeof(struct dpu_core_perf_params));
if (!dpu_cstate->bw_control) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
+ perf->bw_ctl = kms->catalog->perf.max_bw_high *
1000ULL;
- perf->max_per_pipe_ib[i] = perf->bw_ctl[i];
- }
+ perf->max_per_pipe_ib = perf->bw_ctl;
perf->core_clk_rate = kms->perf.max_core_clk_rate;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- perf->bw_ctl[i] = 0;
- perf->max_per_pipe_ib[i] = 0;
- }
+ perf->bw_ctl = 0;
+ perf->max_per_pipe_ib = 0;
perf->core_clk_rate = 0;
} else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED) {
- for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- perf->bw_ctl[i] = kms->perf.fix_core_ab_vote;
- perf->max_per_pipe_ib[i] = kms->perf.fix_core_ib_vote;
- }
+ perf->bw_ctl = kms->perf.fix_core_ab_vote;
+ perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
}
DPU_DEBUG(
- "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu llcc_ib=%llu
llcc_ab=%llu mem_ib=%llu mem_ab=%llu\n",
+ "crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC],
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC],
- perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI],
- perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI]);
+ perf->max_per_pipe_ib, perf->bw_ctl);
}
int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
@@ -136,7 +124,6 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
struct dpu_crtc_state *dpu_cstate;
struct drm_crtc *tmp_crtc;
struct dpu_kms *kms;
- int i;
if (!crtc || !state) {
DPU_ERROR("invalid crtc\n");
@@ -158,31 +145,25 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
/* obtain new values */
_dpu_core_perf_calc_crtc(kms, crtc, state, &dpu_cstate->new_perf);
- for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
- i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
- bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl[i];
- curr_client_type = dpu_crtc_get_client_type(crtc);
+ bw_sum_of_intfs = dpu_cstate->new_perf.bw_ctl;
+ curr_client_type = dpu_crtc_get_client_type(crtc);
- drm_for_each_crtc(tmp_crtc, crtc->dev) {
- if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
- (dpu_crtc_get_client_type(tmp_crtc) ==
- curr_client_type) &&
- (tmp_crtc != crtc)) {
- struct dpu_crtc_state *tmp_cstate =
[v5 2/3] drm/msm/dpu: Integrate interconnect API in MDSS
From: Sravanthi Kollukuduru
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.
MDSS is one of the interconnect consumers which uses the
interconnect APIs to get the path between endpoints and
set its bandwidth requirement for the given interconnected
path.
Changes in v2:
- Remove error log and unnecessary check (Jordan Crouse)
Changes in v3:
- Code clean involving variable name change, removal
of extra paranthesis and variables (Matthias Kaehlcke)
Changes in v4:
- Add comments, spacings, tabs, proper port name
and icc macro (Georgi Djakov)
Changes in v5:
- Commit text and parenthesis alignment (Georgi Djakov)
Signed-off-by: Sravanthi Kollukuduru
Signed-off-by: Jayant Shekhar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 +---
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 38576f8..b8fb197 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -4,11 +4,15 @@
*/
#include "dpu_kms.h"
+#include
#define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
#define HW_INTR_STATUS 0x0010
+/* Max BW defined in KBps */
+#define MAX_BW 680
+
struct dpu_mdss {
struct msm_mdss base;
void __iomem *mmio;
@@ -16,8 +20,30 @@ struct dpu_mdss {
u32 hwversion;
struct dss_module_power mp;
struct dpu_irq_controller irq_controller;
+ struct icc_path *path[2];
+ u32 num_paths;
};
+static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
+ struct dpu_mdss *dpu_mdss)
+{
+ struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
+ struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
+
+ if (IS_ERR(path0))
+ return PTR_ERR(path0);
+
+ dpu_mdss->path[0] = path0;
+ dpu_mdss->num_paths = 1;
+
+ if (!IS_ERR(path1)) {
+ dpu_mdss->path[1] = path1;
+ dpu_mdss->num_paths++;
+ }
+
+ return 0;
+}
+
static irqreturn_t dpu_mdss_irq(int irq, void *arg)
{
struct dpu_mdss *dpu_mdss = arg;
@@ -127,7 +153,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
{
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = &dpu_mdss->mp;
- int ret;
+ int ret, i;
+ u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
+
+ for (i = 0; i < dpu_mdss->num_paths; i++)
+ icc_set(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
if (ret)
@@ -140,12 +170,15 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
{
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = &dpu_mdss->mp;
- int ret;
+ int ret, i;
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (ret)
DPU_ERROR("clock disable failed, ret:%d\n", ret);
+ for (i = 0; i < dpu_mdss->num_paths; i++)
+ icc_set(dpu_mdss->path[i], 0, 0);
+
return ret;
}
@@ -155,6 +188,7 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = &dpu_mdss->mp;
+ int i;
pm_runtime_disable(dev->dev);
_dpu_mdss_irq_domain_fini(dpu_mdss);
@@ -162,6 +196,9 @@ static void dpu_mdss_destroy(struct drm_device *dev)
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(&pdev->dev, mp->clk_config);
+ for (i = 0; i < dpu_mdss->num_paths; i++)
+ icc_put(dpu_mdss->path[i]);
+
if (dpu_mdss->mmio)
devm_iounmap(&pdev->dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
@@ -200,6 +237,10 @@ int dpu_mdss_init(struct drm_device *dev)
}
dpu_mdss->mmio_len = resource_size(res);
+ ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
+ if (ret)
+ return ret;
+
mp = &dpu_mdss->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
@@ -221,14 +262,14 @@ int dpu_mdss_init(struct drm_device *dev)
goto irq_error;
}
+ priv->mdss = &dpu_mdss->base;
+
pm_runtime_enable(dev->dev);
pm_runtime_get_sync(dev->dev);
dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio);
pm_runtime_put_sync(dev->dev);
- priv->mdss = &dpu_mdss->base;
-
return r
[v5 3/3] dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on SDM845
From: Sravanthi Kollukuduru Add interconnect properties such as interconnect provider specifier , the edge source and destination ports which are required by the interconnect API to configure interconnect path for MDSS. Changes in v2: - none Changes in v3: - Remove common property definitions (Rob Herring) Changes in v4: - Use port macros and change port string names (Georgi Djakov) Changes in v5: - None Signed-off-by: Sravanthi Kollukuduru Signed-off-by: Jayant Shekhar --- Documentation/devicetree/bindings/display/msm/dpu.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt index ad2e883..a61dd40 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt @@ -28,6 +28,11 @@ Required properties: - #address-cells: number of address cells for the MDSS children. Should be 1. - #size-cells: Should be 1. - ranges: parent bus address space is the same as the child bus address space. +- interconnects : interconnect path specifier for MDSS according to + Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be + 2 paths corresponding to 2 AXI ports. +- interconnect-names : MDSS will have 2 port names to differentiate between the + 2 interconnect paths defined with interconnect specifier. Optional properties: - assigned-clocks: list of clock specifiers for clocks needing rate assignment @@ -86,6 +91,11 @@ Example: interrupt-controller; #interrupt-cells = <1>; + interconnects = <&rsc_hlos MASTER_MDP0 &rsc_hlos SLAVE_EBI1>, + <&rsc_hlos MASTER_MDP1 &rsc_hlos SLAVE_EBI1>; + + interconnect-names = "mdp0-mem", "mdp1-mem"; + iommus = <&apps_iommu 0>; #address-cells = <2>; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU
Hi Rob, On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse wrote: > > Now that more of the sdm845 bindings are headed upstream this a refresh of > of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes > for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes > interrupt-names from the driver and the existing DT changes per feedback from > Rob Herring. > > This is based on : > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next > > with: > https://lore.kernel.org/patchwork/patch/1018365/ > > This change requires the following dependencies: > > include/dt-bindings/power/qcom-rpmpd.h: > https://patchwork.kernel.org/patch/1079/ > > qcom,smmu-v2 binding: > https://patchwork.kernel.org/patch/10581911/ > > v7: Add patches to remove interrupt-names, add version specific compatible > string for gmu > v6: Update GPU bindings for a6xx and make the examples match the nodes and > vice > versa. Clean up types and rebase on > https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate merging. > v5: Use symbolic names for the RPMH power levels defined in OPP table, > move the opp tables as children of their respective nodes and rename > the iommu device. > v4: Rebase > v3: Split GMU PDC region into two GPU specific sections, fix indentation, > really use qcom,gmu for the phandle name > v2: changed qcom,arc-level to qcom,level following discussion with Viresh; > change gmu phandle to qcom,gmu per Rob > > Jordan Crouse (6): > drm/msm/gpu: Remove hardcoded interrupt name > drm/msm: drop interrupt-names > ARM: dts: qcom: Removed unused interrupt-names from GPU node > arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU > dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings > arm64: dts: sdm845: Add gpu and gmu device nodes I know it's been holidays and everyone (including me) has been on vacation, but just wanted to make sure the current status of this series was explicitly called out. :-) I believe patches #1 and #2 are ready to land and will go through your tree. Patches #3 and #4 should probably go through Andy's tree and are not urgent (they are just cleanup). They can sit on the back burner until patches #1 and #2 have hit mainline. That's a good reason to land #1 and #2 sooner. ;-) I think patch #5 is also ready to land. There's been some bikeshedding about the exact format for the opp table, but none of that bikeshedding affects the bindings that Jordan wrote. If you agree that this is OK to land, it would also be nice to get in. ...then Jordan can spin patch #6 (once Rob H Acks Rajendra's opp bindings) alone at a future date. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb
Hi Noralf. > > I was really pleased to see that the damage helper had landed. Now I can > do framebuffer flushing solely through the display pipe functions. This > prepares the ground for the removal of struct tinydrm_device in my next > series. I browsed through the code - and the code paths I could follow looked good to me. I missed an update of Documentation/gpu/todo.rst as I think we can close a few items with this patch-set. You can add my: Acked-by: Sam Ravnborg to the full series. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/15] drm/bochs: reserve bo for pin/unpin
On Wed, Jan 9, 2019 at 12:36 PM Daniel Vetter wrote: > > On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann wrote: > > > > On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote: > > > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote: > > > > The buffer object must be reserved before calling > > > > ttm_bo_validate for pinning/unpinning. > > > > > > > > Signed-off-by: Gerd Hoffmann > > > > > > Seems a bit a bisect fumble in your series here: legacy kms code reserved > > > the ttm bo before calling boch_bo_pin/unpin, your atomic code doesn't. I > > > think pushing this into bochs_bo_pin/unpin makes sense for atomic, but to > > > avoid bisect fail I think you need to have these temporarily in your > > > cleanup/prepare_plane functions too. > > > > I think I've sorted that. Have some other changes too, will probably > > send v3 tomorrow. > > > > > Looked through the entire series, this here is the only issue I think > > > should be fixed before merging (making atomic_enable optional can be done > > > as a follow-up if you feel like it). With that addressed on the series: > > > > > > Acked-by: Daniel Vetter > > > > Thanks. > > > > While being at it: I'm also looking at dma-buf export and import > > support for the qemu drivers. > > > > Right now both qxl and virtio have gem_prime_get_sg_table and > > gem_prime_import_sg_table handlers which throw a WARN_ONCE() and return > > an error. > > > > If I understand things correctly it is valid to set all import/export > > callbacks (prime_handle_to_fd, prime_fd_to_handle, > > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not > > supporting dma-buf import/export and still advertise DRIVER_PRIME to > > indicate the other prime callbacks are supported (so generic fbdev > > emulation can use gem_prime_vmap etc). Is that correct? > > I'm not sure how much that's a good idea ... Never thought about it > tbh. All the fbdev/dma-buf stuff has plenty of hacks and > inconsistencies still, so I guess we can't make it much worse really. > > > On exporting: > > > > TTM_PL_TT should be easy, just pin the buffer, grab the pages list and > > feed that into drm_prime_pages_to_sg. Didn't try yet though. Is that > > approach correct? > > > > Is it possible to export TTM_PL_VRAM objects (with backing storage being > > a pci memory bar)? If so, how? > > Not really in general. amdgpu upcasts to amdgpu_bo (if it's amgpu BO) > and then knows the internals so it can do a proper pci peer2peer > mapping. Or at least there's been lots of patches floating around to > make that happen. Here's Christian's WIP stuff for adding device memory support to dma-buf: https://cgit.freedesktop.org/~deathsimple/linux/log/?h=p2p Alex > > I think other drivers migrate the bo out of VRAM. > > > On importing: > > > > Importing into TTM_PL_TT object looks easy again, at least when the > > object is actually stored in RAM. What if not? > > They are all supposed to be stored in RAM. Note that all current ttm > importers totally break the abstraction, by taking the sg list, > throwing the dma mapping away and assuming there's a struct page > backing it. Would be good if we could stop spreading that abuse - the > dma-buf interfaces have been modelled after the ttm bo interfaces, so > shouldn't be too hard to wire this up correctly. > > > Importing into TTM_PL_VRAM: Impossible I think, without copying over > > the data. Should that be done? If so, how? Or is it better to just > > not support import then? > > Hm, since you ask about TTM concepts and not what this means in terms > of dma-buf: As long as you upcast to the ttm_bo you can do whatever > you want to really. But with plain dma-buf this doesn't work right now > (least because ttm assumes it gets system RAM on import, in theory you > could put the peer2peer dma mapping into the sg list and it should > work). > -Daniel > > > > > thanks, > > Gerd > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/rockchip: Add reflection properties
From: Daniele Castagna
Add the KMS plane rotation property to the DRM rockchip driver,
for SoCs RK3328, RK3368 and RK3399.
RK3288 only supports rotation at the display level (i.e. CRTC),
but for now we are only interested in plane rotation.
This commit only adds support for the value of reflect-y
and reflect-x (i.e. mirroring).
Note that y-mirroring is not compatible with YUV.
The following modetest commands would test this feature,
where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x.
X mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17
Y mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33
XY mirror:
modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49
Signed-off-by: Daniele Castagna
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 3 ++
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fe800f784c18..5185a31318f5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -88,6 +88,9 @@
#define VOP_WIN_GET(vop, win, name) \
vop_read_reg(vop, win->offset, win->phy->name)
+#define VOP_WIN_HAS_REG(win, name) \
+ !!(win->phy->name.mask)
+
#define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
@@ -711,6 +714,11 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
+ if (fb->format->is_yuv && state->rotation & DRM_MODE_REFLECT_Y) {
+ DRM_ERROR("Invalid Source: Yuv format does not support this
rotation\n");
+ return -EINVAL;
+ }
+
return 0;
}
@@ -789,6 +797,13 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
+ /*
+* For y-mirroring we need to move address
+* to the beginning of the last line.
+*/
+ if (state->rotation & DRM_MODE_REFLECT_Y)
+ dma_addr += (actual_h - 1) * fb->pitches[0];
+
format = vop_convert_format(fb->format->format);
spin_lock(&vop->reg_lock);
@@ -797,6 +812,10 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
+ VOP_WIN_SET(vop, win, y_mir_en,
+ (state->rotation & DRM_MODE_REFLECT_Y) ? 1 : 0);
+ VOP_WIN_SET(vop, win, x_mir_en,
+ (state->rotation & DRM_MODE_REFLECT_X) ? 1 : 0);
if (is_yuv) {
int hsub =
drm_format_horz_chroma_subsampling(fb->format->format);
@@ -1311,6 +1330,18 @@ static irqreturn_t vop_isr(int irq, void *data)
return ret;
}
+static void vop_plane_add_properties(struct drm_plane *plane,
+const struct vop_win_data *win_data)
+{
+ unsigned int flags = 0;
+
+ flags |= VOP_WIN_HAS_REG(win_data, x_mir_en) ? DRM_MODE_REFLECT_X : 0;
+ flags |= VOP_WIN_HAS_REG(win_data, y_mir_en) ? DRM_MODE_REFLECT_Y : 0;
+ if (flags)
+ drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
+ DRM_MODE_ROTATE_0 | flags);
+}
+
static int vop_create_crtc(struct vop *vop)
{
const struct vop_data *vop_data = vop->data;
@@ -1348,6 +1379,7 @@ static int vop_create_crtc(struct vop *vop)
plane = &vop_win->base;
drm_plane_helper_add(plane, &plane_helper_funcs);
+ vop_plane_add_properties(plane, win_data);
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
primary = plane;
else if (plane->type == DRM_PLANE_TYPE_CURSOR)
@@ -1385,6 +1417,7 @@ static int vop_create_crtc(struct vop *vop)
goto err_cleanup_crtc;
}
drm_plane_helper_add(&vop_win->base, &plane_helper_funcs);
+ vop_plane_add_properties(&vop_win->base, win_data);
}
port = of_get_child_by_name(dev->of_node, "port");
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index aed467cd81b9..04ed401d2325 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -146,6 +146,8 @@ struct vop_win_phy {
struct vop_reg uv_mst;
struct vop_reg yrgb_vir;
struct vop_reg uv_vir;
+ struct vop_reg y_mir_en;
+ struct vop_reg x_mir_en;
struct vop_reg dst_alpha_ctl;
struct vop_reg src_alpha_ctl;
diff --git
[PATCH 2/3] drm/rockchip: Separate RK3288 from RK3368 win01 registers
This commit splits the registers for RK3288 from those
for RK3328, RK3368 and RK3399. It seems RK3288 does not
support plane x-y-mirroring, and so in order to support this
for the other SoCs, we need to have separate set of registers
for win0 and win1.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index fe752df4e038..4f7000b5f9ed 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -550,6 +550,25 @@ static const struct vop_intr rk3368_vop_intr = {
.clear = VOP_REG_MASK_SYNC(RK3368_INTR_CLEAR, 0x3fff, 0),
};
+static const struct vop_win_phy rk3368_win01_data = {
+ .scl = &rk3288_win_full_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
+ .act_info = VOP_REG(RK3368_WIN0_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3368_WIN0_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3368_WIN0_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3368_WIN0_YRGB_MST, 0x, 0),
+ .uv_mst = VOP_REG(RK3368_WIN0_CBR_MST, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3368_WIN0_VIR, 0x3fff, 0),
+ .uv_vir = VOP_REG(RK3368_WIN0_VIR, 0x3fff, 16),
+ .src_alpha_ctl = VOP_REG(RK3368_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+ .dst_alpha_ctl = VOP_REG(RK3368_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+ .channel = VOP_REG(RK3368_WIN0_CTRL2, 0xff, 0),
+};
+
static const struct vop_win_phy rk3368_win23_data = {
.data_formats = formats_win_lite,
.nformats = ARRAY_SIZE(formats_win_lite),
@@ -566,9 +585,9 @@ static const struct vop_win_phy rk3368_win23_data = {
};
static const struct vop_win_data rk3368_vop_win_data[] = {
- { .base = 0x00, .phy = &rk3288_win01_data,
+ { .base = 0x00, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
- { .base = 0x40, .phy = &rk3288_win01_data,
+ { .base = 0x40, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_OVERLAY },
{ .base = 0x00, .phy = &rk3368_win23_data,
.type = DRM_PLANE_TYPE_OVERLAY },
@@ -679,7 +698,7 @@ static const struct vop_data rk3399_vop_big = {
};
static const struct vop_win_data rk3399_vop_lit_win_data[] = {
- { .base = 0x00, .phy = &rk3288_win01_data,
+ { .base = 0x00, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = &rk3368_win23_data,
.type = DRM_PLANE_TYPE_CURSOR},
@@ -766,11 +785,11 @@ static const struct vop_intr rk3328_vop_intr = {
};
static const struct vop_win_data rk3328_vop_win_data[] = {
- { .base = 0xd0, .phy = &rk3288_win01_data,
+ { .base = 0xd0, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
- { .base = 0x1d0, .phy = &rk3288_win01_data,
+ { .base = 0x1d0, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_OVERLAY },
- { .base = 0x2d0, .phy = &rk3288_win01_data,
+ { .base = 0x2d0, .phy = &rk3368_win01_data,
.type = DRM_PLANE_TYPE_CURSOR },
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/rockchip: Fix typo in VOP macros argument
Fix a small typo in the macros VOP argument. The macro argument
is currently wrongly named "x", and then never used. The code
built fine almost by accident, as the macros are always used
in a context where a proper "vop" symbol exists.
This fix is almost cosmetic, as the resulting code shouldn't change.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7ad9067b3110..fe800f784c18 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -45,21 +45,21 @@
#include "rockchip_drm_vop.h"
#include "rockchip_rgb.h"
-#define VOP_WIN_SET(x, win, name, v) \
+#define VOP_WIN_SET(vop, win, name, v) \
vop_reg_set(vop, &win->phy->name, win->base, ~0, v, #name)
-#define VOP_SCL_SET(x, win, name, v) \
+#define VOP_SCL_SET(vop, win, name, v) \
vop_reg_set(vop, &win->phy->scl->name, win->base, ~0, v, #name)
-#define VOP_SCL_SET_EXT(x, win, name, v) \
+#define VOP_SCL_SET_EXT(vop, win, name, v) \
vop_reg_set(vop, &win->phy->scl->ext->name, \
win->base, ~0, v, #name)
-#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
+#define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
do { \
if (win_yuv2yuv && win_yuv2yuv->name.mask) \
vop_reg_set(vop, &win_yuv2yuv->name, 0, ~0, v, #name); \
} while (0)
-#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
+#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(vop, win_yuv2yuv, name, v) \
do { \
if (win_yuv2yuv && win_yuv2yuv->phy->name.mask) \
vop_reg_set(vop, &win_yuv2yuv->phy->name,
win_yuv2yuv->base, ~0, v, #name); \
@@ -85,8 +85,8 @@
#define VOP_INTR_GET_TYPE(vop, name, type) \
vop_get_intr_type(vop, &vop->data->intr->name, type)
-#define VOP_WIN_GET(x, win, name) \
- vop_read_reg(x, win->offset, win->phy->name)
+#define VOP_WIN_GET(vop, win, name) \
+ vop_read_reg(vop, win->offset, win->phy->name)
#define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Support reflect-x/y on RK3328, RK3368, and RK3399
Here's a small series supporting plane reflection (aka. mirroring) properties on RK3328, RK3368, and RK3399 SoCs. Note that RK3288 specification doesn't seem to document registers for plane mirroring, but instead it only seems to support mirroring at the display (CRTC) level. A small typo cleanup patch is included, in patch 1. Not related to the rotation stuff. In order to support this feature, patch 2 separates the register set for win0 and win1. Once that's done, patch 3 creates the properties, if supported by each plane/SoC. The following modetest commands would test this feature, where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x. X mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17 Y mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33 XY mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49 This work has been originally by Daniele. I just cleaned up the implementation a it, and ported the code to upstream. This series is based on drm-misc-next plus https://patchwork.kernel.org/patch/10752893/. Daniele Castagna (1): drm/rockchip: Add reflection properties Ezequiel Garcia (2): drm/rockchip: Fix typo in VOP macros argument drm/rockchip: Separate RK3288 from RK3368 win01 registers drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 47 ++--- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 34 --- 3 files changed, 70 insertions(+), 13 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] drm/panel: Add a driver for the TPO TPG110
Hi Linus.
On Wed, Jan 09, 2019 at 02:53:31PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combined with a OSD
> OSD057VA01CT display for WVGA 800x480.
>
> The driver is pretty minimalistic right now but can be
> extended to handle non-default polarities, gamma correction
> etc.
>
> The driver is based on the baked-in code in
> drivers/video/fbdev/amba-clcd-nomadik.c which will be
> decomissioned once this us upstream.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Linus Walleij
While browsing this code again a few things jumped at me.
- we try to kill use of drmP.h
- DRM_DEV_XXX rather than dev_xxx (not all like these, but they are used in
other panels)
- drop videomode - not used anymore.
I went ahead and made a patch. Build tested on top of drm-misc-next
(had to define SPI_3WIRE_HIZ, because we miss a backmerge of -rc1)
Apply what you think is relevant, and sorry for the late feedback.
Sam
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index e3821180b6cd..a71f44191273 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -208,7 +208,6 @@ config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
depends on BACKLIGHT_CLASS_DEVICE
- select VIDEOMODE_HELPERS
help
Say Y here if you want to enable support for TPO TPG110
400CH LTPS TFT LCD Single Chip Digital Driver for up to
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
index d7c3541fdf28..67c7be8eb166 100644
--- a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -10,11 +10,14 @@
* Author:
* Linus Walleij
*/
-#include
+
+#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -22,9 +25,6 @@
#include
#include
-#include
-#include
-
#define TPG110_TEST0x00
#define TPG110_CHIPID 0x01
#define TPG110_CTRL1 0x02
@@ -248,7 +248,7 @@ static u8 tpg110_readwrite_reg(struct tpg110 *tpg, bool
write,
spi_message_add_tail(&t[1], &m);
ret = spi_sync(tpg->spi, &m);
if (ret) {
- dev_err(tpg->dev, "SPI message error %d\n", ret);
+ DRM_DEV_ERROR(tpg->dev, "SPI message error %d\n", ret);
return ret;
}
if (write)
@@ -275,46 +275,46 @@ static int tpg110_startup(struct tpg110 *tpg)
/* De-assert the reset signal */
gpiod_set_value_cansleep(tpg->grestb, 0);
mdelay(1);
- dev_info(tpg->dev, "de-asserted GRESTB\n");
+ DRM_DEV_INFO(tpg->dev, "de-asserted GRESTB\n");
/* Test display communication */
tpg110_write_reg(tpg, TPG110_TEST, 0x55);
val = tpg110_read_reg(tpg, TPG110_TEST);
if (val != 0x55) {
- dev_err(tpg->dev, "failed communication test\n");
+ DRM_DEV_ERROR(tpg->dev, "failed communication test\n");
return -ENODEV;
}
val = tpg110_read_reg(tpg, TPG110_CHIPID);
- dev_info(tpg->dev, "TPG110 chip ID: %d version: %d\n",
-val >> 4, val & 0x0f);
+ DRM_DEV_INFO(tpg->dev, "TPG110 chip ID: %d version: %d\n",
+val >> 4, val & 0x0f);
/* Show display resolution */
val = tpg110_read_reg(tpg, TPG110_CTRL1);
val &= TPG110_RES_MASK;
switch (val) {
case TPG110_RES_400X240_D:
- dev_info(tpg->dev,
-"IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+ DRM_DEV_INFO(tpg->dev,
+"IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
break;
case TPG110_RES_480X272_D:
- dev_info(tpg->dev,
-"IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+ DRM_DEV_INFO(tpg->dev,
+"IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
break;
case TPG110_RES_480X640:
- dev_info(tpg->dev, "480x640 RGB");
+ DRM_DEV_INFO(tpg->dev, "480x640 RGB");
break;
case TPG110_RES_480X272:
- dev_info(tpg->dev, "480x272 RGB");
+ DRM_DEV_INFO(tpg->dev, "480x272 RGB");
break;
case TPG110_RES_640X480:
- dev_info(tpg->dev, "640x480 RGB");
+ DRM_DEV_INFO(tpg->dev, "640x480 RGB");
break;
case TPG110_RES_800X480:
- dev_info(tpg->dev, "800x480 RGB");
+ DRM_DEV_INFO(tpg->dev, "800x480 RGB");
break;
default:
- dev_info(tpg->dev, "ILLEGAL RESOLUTION");
+
Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb
Den 09.01.2019 19.26, skrev Sam Ravnborg: > Hi Noralf. > >> >> I was really pleased to see that the damage helper had landed. Now I can >> do framebuffer flushing solely through the display pipe functions. This >> prepares the ground for the removal of struct tinydrm_device in my next >> series. > > I browsed through the code - and the code paths I could follow looked > good to me. > I missed an update of Documentation/gpu/todo.rst as I think we can > close a few items with this patch-set. > Yeah, you're right, I forgot about that one. I'll add a patch in the next version. > You can add my: > Acked-by: Sam Ravnborg > to the full series. > Thanks, Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] arm64: dts: Add sdm845 GPU/GMU and SMMU
On Wed, Jan 9, 2019 at 1:20 PM Doug Anderson wrote: > > Hi Rob, > > On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse wrote: > > > > Now that more of the sdm845 bindings are headed upstream this a refresh of > > of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes > > for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes > > interrupt-names from the driver and the existing DT changes per feedback > > from > > Rob Herring. > > > > This is based on : > > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next > > > > with: > > https://lore.kernel.org/patchwork/patch/1018365/ > > > > This change requires the following dependencies: > > > > include/dt-bindings/power/qcom-rpmpd.h: > > https://patchwork.kernel.org/patch/1079/ > > > > qcom,smmu-v2 binding: > > https://patchwork.kernel.org/patch/10581911/ > > > > v7: Add patches to remove interrupt-names, add version specific compatible > > string for gmu > > v6: Update GPU bindings for a6xx and make the examples match the nodes and > > vice > > versa. Clean up types and rebase on > > https://lore.kernel.org/patchwork/patch/1018365/ to help facilitate > > merging. > > v5: Use symbolic names for the RPMH power levels defined in OPP table, > > move the opp tables as children of their respective nodes and rename > > the iommu device. > > v4: Rebase > > v3: Split GMU PDC region into two GPU specific sections, fix indentation, > > really use qcom,gmu for the phandle name > > v2: changed qcom,arc-level to qcom,level following discussion with Viresh; > > change gmu phandle to qcom,gmu per Rob > > > > Jordan Crouse (6): > > drm/msm/gpu: Remove hardcoded interrupt name > > drm/msm: drop interrupt-names > > ARM: dts: qcom: Removed unused interrupt-names from GPU node > > arm64: dts: qcom: msm8916: Remove unused interrupt-names from GPU > > dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings > > arm64: dts: sdm845: Add gpu and gmu device nodes > > I know it's been holidays and everyone (including me) has been on > vacation, but just wanted to make sure the current status of this > series was explicitly called out. :-) > > > I believe patches #1 and #2 are ready to land and will go through your tree. > > Patches #3 and #4 should probably go through Andy's tree and are not > urgent (they are just cleanup). They can sit on the back burner until > patches #1 and #2 have hit mainline. That's a good reason to land #1 > and #2 sooner. ;-) > > I think patch #5 is also ready to land. There's been some > bikeshedding about the exact format for the opp table, but none of > that bikeshedding affects the bindings that Jordan wrote. If you > agree that this is OK to land, it would also be nice to get in. > > ...then Jordan can spin patch #6 (once Rob H Acks Rajendra's opp > bindings) alone at a future date. > I've picked up 1+2 and 5.. I assume it makes more sense for agross to pick up the rest? BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit
On Wed, Jan 09, 2019 at 05:52:20PM +0100, Paul Kocialkowski wrote:
> Hi Daniel,
>
> On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> > On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
> > wrote:
> > > During an atomic commit, the HVS is configured with a display list
> > > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> > > and encoder are also configured for the new setup at that time.
> > > While the Pixel Valve and encoder are reconfigured synchronously, the
> > > HVS is only reconfigured after the display list address (DISPLIST) has
> > > been updated to the current display list address (DISPLACTX), which is
> > > the responsibility of the hardware.
> > >
> > > The time frame during which the HVS is still running on its previous
> > > configuration but the CRTC and encoder have been reconfigured already
> > > can lead to a number of synchronization issues. They will eventually
> > > cause errors reported on the FIFOs, such as underruns.
> > >
> > > With underrun detection enabled (from Boris Brezillon's series), this
> > > leads to unreliable underrun detection with random false positives.
> > >
> > > To ensure a coherent state, wait for each enabled channel of the HVS
> > > to synchronize its current display list address. This fixes the issue
> > > of random underrun reporting on commits.
> > >
> > > Signed-off-by: Paul Kocialkowski
> > > ---
> > > drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> > > drivers/gpu/drm/vc4/vc4_hvs.c | 17 +
> > > drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
> > > drivers/gpu/drm/vc4/vc4_regs.h | 2 ++
> > > 4 files changed, 22 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > > index c24b078f0593..955f157f5ad0 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
> > > extern struct platform_driver vc4_hvs_driver;
> > > void vc4_hvs_dump_state(struct drm_device *dev);
> > > int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
> > > +void vc4_hvs_sync_dlist(struct drm_device *dev);
> > >
> > > /* vc4_kms.c */
> > > int vc4_kms_load(struct drm_device *dev);
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > > index 5d8c749c9749..1ba60b8e0c2d 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct
> > > vc4_hvs *hvs,
> > > return 0;
> > > }
> > >
> > > +void vc4_hvs_sync_dlist(struct drm_device *dev)
> > > +{
> > > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > > + unsigned int i;
> > > + int ret;
> > > +
> > > + for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
> > > + if (!(HVS_READ(SCALER_DISPCTRLX(i)) &
> > > SCALER_DISPCTRLX_ENABLE))
> > > + continue;
> > > +
> > > + ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
> > > + HVS_READ(SCALER_DISPLISTX(i)), 1000);
> > > + WARN(ret, "Timeout waiting for channel %d display list
> > > sync\n",
> > > +i);
> > > + }
> > > +}
> > > +
> > > static int vc4_hvs_bind(struct device *dev, struct device *master, void
> > > *data)
> > > {
> > > struct platform_device *pdev = to_platform_device(dev);
> > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > > index 0490edb192a1..2d66a2b57a91 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state
> > > *state)
> > >
> > > drm_atomic_helper_commit_hw_done(state);
> > >
> > > + vc4_hvs_sync_dlist(dev);
> >
> > From your description I'd have guessed you want this between when you
> > update the planes and the crtc, so somewhere between commit_planes()
> > and commit_modeset_enables(). At least I have no idea how waiting here
> > can prevent underruns, by this point there's no further hw programming
> > happening.
>
> One thing that I did not mention is that the display list (that
> configures the planes) is only set at crtc_enable time (and taken into
> account by the hardware later).
>
> However, even calling vc4_hvs_sync_dlist right at the end of
> crtc_enable doesn't do either (the old display list just sticks). It
> only seems to work after the HDMI encoder enable step and I don't know
> any good reason why.
>
> I didn't find any description of when that dlist sync mechanism is
> supposed to take place and what particular event triggers it. Perhaps
> it is triggered by a signal originating from the encoder? If anyone has
> insight on the hardware, feel free to shed some light here :)
Maybe my concern wasn't clear: I have no idea why you need this exactly
and how your hw works. Only thing I meant to highlight is tha
Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
Hi Kevin, On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote: > Hi Sean, > > I do recall seeing you at XDC2017, I do not believe I spoke with you at > the event. I will not name the name, but I had one developer who > strongly asked me to convert to atomic mode setting, but I refused due > to the state of the code at the time. That was at least me and Ben Skeggs. No point playing games, we're doing open discussions here in the gpu subsystem. > Now, the KMS device support is mostly comparable to the existing UMS > code path, so I can soon consider implementing universal plane and > atomic mode setting. I am okay with the OpenChrome DRM not being > activated initially (i.e., > Displaying "(Experimental)" status when running menuconfig), but I do > want it directly inserted into the DRM tree from day one after the code > is pulled in. (i.e., not getting inserted into the "staging" tree) I > believe the current code quality is good enough for this arrangement. Given how much cleaner the atomic helpers are, and how much simpler the resulting drivers tend to be, I still think that's a bad idea. We do have vboxvideo merged into staging, which still a non-atomic driver, but I don't think that's helping anyone. It's definitely hurting refactoring to have a driver outside of drm. And within drm imo a new non-atomic driver doesn't make sense. I've also never seen the code yet on dri-devel, so can't really give more specific advise. Cheers, Daniel > > Regards, > > Kevin Brace > Brace Computer Laboratory blog > https://bracecomputerlab.com > > > > Sent: Wednesday, June 13, 2018 at 1:07 PM > > From: "Sean Paul" > > To: kevinbr...@gmx.com > > Cc: "Dave Airlie" , dri-devel > > , openchrome-de...@lists.freedesktop.org > > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree > > > > I think I was one of those developers asking you to switch to atomic > > (iirc, i encouraged you to start working on kms instead of ums). I > > know this is a personal project that you've been working on in your > > spare time (which is awesome!), so while I still encourage you to > > convert the driver, I don't have a problem with you doing the > > conversion in mainline. I think hiding under staging until the > > conversion is complete is a pretty reasonable compromise. > > > > Sean > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
[pull] amdgpu drm-fixes-5.0
Hi Dave, Daniel, Fixes for 5.0. Highlights: - Powerplay fixes - Virtual display pinning fixes - Golden register updates for vega - Pitch and gem size validation fixes - Fix for error case in sr-iov init - Disable page tables in system memory on RV due to issues with IOMMU reported on some platforms The following changes since commit 74136a3d47f51ae72ee8b9ebc1ec2a29bcf30676: Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-12-31 08:29:54 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-5.0 for you to fetch changes up to 1c1eba86339c8517814863bc7dd21e2661a84e77: drm/amdgpu: disable system memory page tables for now (2019-01-09 15:01:18 -0500) Christian König (1): drm/amdgpu: disable system memory page tables for now Emily Deng (3): drm/amdgpu/virtual_dce: No need to pin the fb's bo drm/amdgpu/virtual_dce: No need to pin the cursor bo drm/amdgpu/sriov:Correct pfvf exchange logic Evan Quan (5): drm/amd/powerplay: support BOOTUP_DEFAULT power profile mode drm/amd/powerplay: update OD support flag for SKU with no OD capabilities drm/amd/powerplay: create pp_od_clk_voltage device file under OD support drm/amd/powerplay: avoid possible buffer overflow drm/amd/powerplay: drop the unnecessary uclk hard min setting Jim Qu (1): drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang Kent Russell (1): drm/amdgpu: Cleanup 2 compiler warnings Likun Gao (1): drm/amdgpu: make gfx9 enter into rlc safe mode when set MGCG Tao Zhou (1): drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20 Tiecheng Zhou (1): drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings test sequence Yu Zhao (2): drm/amdgpu: validate user pitch alignment drm/amdgpu: validate user GEM object size drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 38 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 22 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 -- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 17 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 48 +++--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 --- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 +- drivers/gpu/drm/amd/include/kgd_pp_interface.h | 13 +++--- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 24 ++- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 8 ++-- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 12 +++--- drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 34 ++- drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 2 +- 15 files changed, 156 insertions(+), 96 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
On Wed, Jan 09, 2019 at 06:49:53PM +0100, Noralf Trønnes wrote:
> This adds a .fb_create helper that sets the .dirty callback to
> drm_atomic_helper_dirtyfb().
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
> include/drm/drm_gem_framebuffer_helper.h | 3 ++
> 2 files changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index acb466d25afc..4edd0261e507 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
> * @mode_cmd: Metadata from the userspace framebuffer creation request
> * @funcs: vtable to be used for the new framebuffer object
> *
> - * This can be used to set &drm_framebuffer_funcs for drivers that need the
> - * &drm_framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you
> don't
> - * need to change &drm_framebuffer_funcs.
> - * The function does buffer size validation.
> + * This function can be used to set &drm_framebuffer_funcs for drivers that
> need
> + * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
> + * change &drm_framebuffer_funcs. The function does buffer size validation.
> *
> * Returns:
> * Pointer to a &drm_framebuffer on success or an error pointer on failure.
> @@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs
> drm_gem_fb_funcs = {
> *
> * If your hardware has special alignment or pitch requirements these should
> be
> * checked before calling this function. The function does buffer size
> - * validation. Use drm_gem_fb_create_with_funcs() if you need to set
> - * &drm_framebuffer_funcs.dirty.
> + * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
> + * flushing.
> *
> * Drivers can use this as their &drm_mode_config_funcs.fb_create callback.
> * The ADDFB2 IOCTL calls into this callback.
> @@ -233,6 +233,41 @@ drm_gem_fb_create(struct drm_device *dev, struct
> drm_file *file,
> }
> EXPORT_SYMBOL_GPL(drm_gem_fb_create);
>
> +static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
> + .destroy= drm_gem_fb_destroy,
> + .create_handle = drm_gem_fb_create_handle,
> + .dirty = drm_atomic_helper_dirtyfb,
> +};
> +
> +/**
> + * drm_gem_fb_create_with_dirty() - Helper function for the
> + * &drm_mode_config_funcs.fb_create callback
> + * @dev: DRM device
> + * @file: DRM file that holds the GEM handle(s) backing the framebuffer
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + *
> + * This function creates a new framebuffer object described by
> + * &drm_mode_fb_cmd2. This description includes handles for the buffer(s)
> + * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
> + * callback giving framebuffer flushing through the atomic machinery. Use
> + * drm_gem_fb_create() if you don't need the dirty callback.
> + * The function does buffer size validation.
> + *
> + * Drivers can use this as their &drm_mode_config_funcs.fb_create callback.
> + * The ADDFB2 IOCTL calls into this callback.
I think would be good to add:
"Drivers should also call drm_plane_enable_fb_damage_clips() on all planes
to enable userspace to use damage clips also with the ATOMIC IOCTL."
It's a bit annoying that drivers have to make that separate call too (so
some risk for accidents), but I didn't see a good way to avoid that.
With the documentation nit, on the entire series:
Acked-by: Daniel Vetter
> + *
> + * Returns:
> + * Pointer to a &drm_framebuffer on success or an error pointer on failure.
> + */
> +struct drm_framebuffer *
> +drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
> + &drm_gem_fb_funcs_dirtyfb);
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
> +
> /**
> * drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
> * @plane: Plane
> diff --git a/include/drm/drm_gem_framebuffer_helper.h
> b/include/drm/drm_gem_framebuffer_helper.h
> index a38de7eb55b4..7f307e834eef 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct
> drm_file *file,
> struct drm_framebuffer *
> drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> +struct drm_framebuffer *
> +drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
> +
Re: [PATCH 0/4] drm/tinydrm: Use damage helper for dirtyfb
On Wed, Jan 9, 2019 at 6:50 PM Noralf Trønnes wrote: > > Hi, > > I was really pleased to see that the damage helper had landed. Now I can > do framebuffer flushing solely through the display pipe functions. This > prepares the ground for the removal of struct tinydrm_device in my next > series. Awesome stuff! > Note: > The damage helper isn't in drm-misc-next yet, it will show up when -rc1 > arrives there. Maxime, can you pls do the backmerge for Noralf, with the above reason? $ dim backmerge drm-misc-next drm/drm-next should get the job done. Cheers, Daniel > > Noralf. > > Noralf Trønnes (4): > drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty() > drm/damage-helper: Add drm_atomic_helper_damage_merged() > drm/tinydrm: Use struct drm_rect > drm/tinydrm: Use damage helper for dirtyfb > > drivers/gpu/drm/drm_damage_helper.c | 43 ++ > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +- > drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 21 +-- > .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 + > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 30 > drivers/gpu/drm/tinydrm/hx8357d.c | 2 +- > drivers/gpu/drm/tinydrm/ili9225.c | 138 +++--- > drivers/gpu/drm/tinydrm/ili9341.c | 2 +- > drivers/gpu/drm/tinydrm/mi0283qt.c| 2 +- > drivers/gpu/drm/tinydrm/mipi-dbi.c| 87 +++ > drivers/gpu/drm/tinydrm/repaper.c | 42 +++--- > drivers/gpu/drm/tinydrm/st7586.c | 73 - > drivers/gpu/drm/tinydrm/st7735r.c | 2 +- > include/drm/drm_damage_helper.h | 3 + > include/drm/drm_gem_framebuffer_helper.h | 3 + > include/drm/tinydrm/mipi-dbi.h| 5 +- > include/drm/tinydrm/tinydrm-helpers.h | 20 +-- > include/drm/tinydrm/tinydrm.h | 26 > 18 files changed, 281 insertions(+), 365 deletions(-) > > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
On Wed, Jan 09, 2019 at 09:39:45PM +0100, Daniel Vetter wrote: > Hi Kevin, > > On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote: > > Hi Sean, > > > > I do recall seeing you at XDC2017, I do not believe I spoke with you at > > the event. I will not name the name, but I had one developer who > > strongly asked me to convert to atomic mode setting, but I refused due > > to the state of the code at the time. > > That was at least me and Ben Skeggs. No point playing games, we're doing > open discussions here in the gpu subsystem. > > > Now, the KMS device support is mostly comparable to the existing UMS > > code path, so I can soon consider implementing universal plane and > > atomic mode setting. I am okay with the OpenChrome DRM not being > > activated initially (i.e., > > Displaying "(Experimental)" status when running menuconfig), but I do > > want it directly inserted into the DRM tree from day one after the code > > is pulled in. (i.e., not getting inserted into the "staging" tree) I > > believe the current code quality is good enough for this arrangement. > > Given how much cleaner the atomic helpers are, and how much simpler the > resulting drivers tend to be, I still think that's a bad idea. We do have > vboxvideo merged into staging, which still a non-atomic driver, but I > don't think that's helping anyone. It's definitely hurting refactoring to > have a driver outside of drm. And within drm imo a new non-atomic driver > doesn't make sense. Yeah, given the pain experienced with vboxvideo in the past half-year, I'd like to reverse my statement from June and vote against putting this in staging. We've waited this long for the openchrome stuff, we can probably wait a bit longer until it's at least basically atomic. Sean > > I've also never seen the code yet on dri-devel, so can't really give more > specific advise. > > Cheers, Daniel > > > > > Regards, > > > > Kevin Brace > > Brace Computer Laboratory blog > > https://bracecomputerlab.com > > > > > > > Sent: Wednesday, June 13, 2018 at 1:07 PM > > > From: "Sean Paul" > > > To: kevinbr...@gmx.com > > > Cc: "Dave Airlie" , dri-devel > > > , openchrome-de...@lists.freedesktop.org > > > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree > > > > > > I think I was one of those developers asking you to switch to atomic > > > (iirc, i encouraged you to start working on kms instead of ums). I > > > know this is a personal project that you've been working on in your > > > spare time (which is awesome!), so while I still encourage you to > > > convert the driver, I don't have a problem with you doing the > > > conversion in mainline. I think hiding under staging until the > > > conversion is complete is a pretty reasonable compromise. > > > > > > Sean > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > 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 -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
