[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #7 from Ilia Mirkin (imir...@alum.mit.edu) --- You could try loading nouveau... or removing the configuration that is preventing it from loading... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #6 from acollie...@gmail.com --- Anything else I can try to do? On Sat, Feb 9, 2019 at 12:57 PM wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=202533 > > --- Comment #5 from Ilia Mirkin (imir...@alum.mit.edu) --- > Doesn't seem like nouveau is loaded at all. Probably related to not being > able > to get anything to come up on those screens... > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108854] [polaris11] - GPU Hang - ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #12 from Tom Seewald --- (In reply to Alex Deucher from comment #11) > The reset was actually successful. The problem is, userspace components > need to be aware of the reset and recreate their contexts. As a workaround, > you can kill the problematic app or restart X. Hmm, but then why will the machine not restart unless I use sysrq keys? I would think a userspace issue wouldn't cause hung kernel tasks like that. I'm also curious regarding why this program is causing the GPU to reset to begin with, I have not seen others reporting issues on other platforms with this program. Is this ring gfx timeout purely a problem with userspace? e.g. [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=32203, emitted seq=32205 -- 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
[drm-tip:drm-tip 2/8] drivers/gpu/drm//arm/display/komeda/komeda_dev.c:27:3: error: implicit declaration of function 'DRM_ERROR'; did you mean 'DRM_IOR'?
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: d4794b009ccd1ef8816e15c833f07ab696911a8d
commit: bd6ee5d2d2032416ba36ec6c24bf513f4ff0d338 [2/8] Merge remote-tracking
branch 'drm-misc/drm-misc-next' into drm-tip
config: x86_64-randconfig-s5-02041749 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
git checkout bd6ee5d2d2032416ba36ec6c24bf513f4ff0d338
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm//arm/display/komeda/komeda_dev.c: In function
'komeda_parse_pipe_dt':
>> drivers/gpu/drm//arm/display/komeda/komeda_dev.c:27:3: error: implicit
>> declaration of function 'DRM_ERROR'; did you mean 'DRM_IOR'?
>> [-Werror=implicit-function-declaration]
DRM_ERROR("get aclk for pipeline %d failed!\n", pipe_id);
^
DRM_IOR
drivers/gpu/drm//arm/display/komeda/komeda_dev.c: In function
'komeda_dev_create':
>> drivers/gpu/drm//arm/display/komeda/komeda_dev.c:127:2: error: implicit
>> declaration of function 'DRM_INFO'; did you mean 'DRM_IO'?
>> [-Werror=implicit-function-declaration]
DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
^~~~
DRM_IO
drivers/gpu/drm//arm/display/komeda/komeda_dev.c: In function
'komeda_dev_destroy':
drivers/gpu/drm//arm/display/komeda/komeda_dev.c:170:3: error: implicit
declaration of function 'devm_iounmap'; did you mean 'pci_iounmap'?
[-Werror=implicit-function-declaration]
devm_iounmap(dev, mdev->reg_base);
^~~~
pci_iounmap
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
Cyclomatic Complexity 2 include/linux/of.h:of_property_read_u32_array
Cyclomatic Complexity 1 include/linux/of.h:of_property_read_u32
Cyclomatic Complexity 3 include/linux/clk.h:clk_prepare_enable
Cyclomatic Complexity 1 include/linux/clk.h:clk_disable_unprepare
Cyclomatic Complexity 1
drivers/gpu/drm//arm/display/komeda/komeda_dev.h:komeda_product_match
Cyclomatic Complexity 5
drivers/gpu/drm//arm/display/komeda/komeda_dev.c:komeda_parse_pipe_dt
Cyclomatic Complexity 5
drivers/gpu/drm//arm/display/komeda/komeda_dev.c:komeda_parse_dt
Cyclomatic Complexity 7
drivers/gpu/drm//arm/display/komeda/komeda_dev.c:komeda_dev_destroy
Cyclomatic Complexity 9
drivers/gpu/drm//arm/display/komeda/komeda_dev.c:komeda_dev_create
cc1: some warnings being treated as errors
--
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c: In function
'komeda_pipeline_add':
>> drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:18:3: error: implicit
>> declaration of function 'DRM_ERROR'; did you mean 'DRM_IOR'?
>> [-Werror=implicit-function-declaration]
DRM_ERROR("Exceed max support %d pipelines.\n",
^
DRM_IOR
Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
Cyclomatic Complexity 4
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_pipeline_add
Cyclomatic Complexity 9
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_pipeline_get_component_pos
Cyclomatic Complexity 2
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_pipeline_get_component
Cyclomatic Complexity 12
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_component_add
Cyclomatic Complexity 1
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_component_destroy
Cyclomatic Complexity 2
drivers/gpu/drm//arm/display/komeda/komeda_pipeline.c:komeda_pipeline_destroy
cc1: some warnings being treated as errors
--
drivers/gpu/drm//arm/display/komeda/komeda_kms.c:32:15: error: variable
'komeda_kms_driver' has initializer but incomplete type
static struct drm_driver komeda_kms_driver = {
^~
drivers/gpu/drm//arm/display/komeda/komeda_kms.c:33:3: error: 'struct
drm_driver' has no member named 'driver_features'
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
^~~
drivers/gpu/drm//arm/display/komeda/komeda_kms.c:33:21: error: 'DRIVER_GEM'
undeclared here (not in a function)
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
^~
drivers/gpu/drm//arm/display/komeda/komeda_kms.c:33:34: error:
'DRIVER_MODESET' undeclared here (not in a function); did you mean
'HRTIMER_MODE_SOFT'?
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
^~
HRTIMER_MODE_SOFT
>> drivers/gpu/drm//arm/display/komeda/komeda_kms.c:33:51: error:
>> 'DRIVER_ATOMIC' undeclared here (not in a function); did you mean
>> 'DRM_UT_ATOMIC'?
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #72 from castor_fou --- I tried comment 64 suggestion: ivrs_ioapic[4]=00:14.0 ivrs_ioapic[5]=00:00.2 After 2 days without any hang, I've just got one. I am desperate about this problem, it has happened only since 18.04 upgrade. I had no issue for 4 years with 16.04 and previous versions. My mitigation is to cron a restart of display-manager twice a day. What a pity solution. 0 12,19 * * * /bin/systemctl restart display-manager -- 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 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #34 from quirin.blae...@freenet.de --- git pull failed. drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c: needs merge drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c: needs merge drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c: needs merge drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h: needs merge drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c: needs merge drivers/gpu/drm/amd/amdgpu/soc15.c: needs merge drivers/gpu/drm/amd/amdkfd/kfd_crat.c: needs merge drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c: needs merge ... I suggest you to fix repository. Meanwhile I'll switch to mainline. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #5 from Ilia Mirkin (imir...@alum.mit.edu) --- Doesn't seem like nouveau is loaded at all. Probably related to not being able to get anything to come up on those screens... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #33 from quirin.blae...@freenet.de --- Bug is still alive. amd-staging-drm-next 8202c53d8f8e1045b8d1ec2db9401618b8889614 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 49/49] drm/omap: Remove panel-dpi driver
Hi,
On Fri, Jan 11, 2019 at 05:51:20AM +0200, Laurent Pinchart wrote:
> Panels are now supported through the drm_panel infrastructure, remove
> the omapdrm-specific driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
Tested-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/Kconfig | 6 -
> drivers/gpu/drm/omapdrm/displays/Makefile | 1 -
> drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 199 --
> .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 1 -
> 4 files changed, 207 deletions(-)
> delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-dpi.c
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
> b/drivers/gpu/drm/omapdrm/displays/Kconfig
> index 38d066ac966e..7b0bcb494b5c 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
> @@ -22,12 +22,6 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
> help
> Driver for a generic analog TV connector.
>
> -config DRM_OMAP_PANEL_DPI
> - tristate "Generic DPI panel"
> - depends on BACKLIGHT_CLASS_DEVICE
> - help
> - Driver for generic DPI panels.
> -
> config DRM_OMAP_PANEL_DSI_CM
> tristate "Generic DSI Command Mode Panel"
> depends on BACKLIGHT_CLASS_DEVICE
> diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile
> b/drivers/gpu/drm/omapdrm/displays/Makefile
> index da1d5321ef50..1db34d4fed64 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Makefile
> +++ b/drivers/gpu/drm/omapdrm/displays/Makefile
> @@ -3,7 +3,6 @@ obj-$(CONFIG_DRM_OMAP_ENCODER_OPA362) += encoder-opa362.o
> obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
> obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
> obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
> -obj-$(CONFIG_DRM_OMAP_PANEL_DPI) += panel-dpi.o
> obj-$(CONFIG_DRM_OMAP_PANEL_DSI_CM) += panel-dsi-cm.o
> obj-$(CONFIG_DRM_OMAP_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> obj-$(CONFIG_DRM_OMAP_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> deleted file mode 100644
> index 389ae2821222..
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> +++ /dev/null
> @@ -1,199 +0,0 @@
> -/*
> - * Generic MIPI DPI Panel Driver
> - *
> - * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> - * Author: Tomi Valkeinen
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published
> by
> - * the Free Software Foundation.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include "../dss/omapdss.h"
> -
> -struct panel_drv_data {
> - struct omap_dss_device dssdev;
> -
> - struct videomode vm;
> -
> - struct backlight_device *backlight;
> -
> - struct gpio_desc *enable_gpio;
> - struct regulator *vcc_supply;
> -};
> -
> -#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> -
> -static int panel_dpi_connect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> - return 0;
> -}
> -
> -static void panel_dpi_disconnect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> -}
> -
> -static void panel_dpi_enable(struct omap_dss_device *dssdev)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> - int r;
> -
> - r = regulator_enable(ddata->vcc_supply);
> - if (r)
> - return;
> -
> - gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> - backlight_enable(ddata->backlight);
> -}
> -
> -static void panel_dpi_disable(struct omap_dss_device *dssdev)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> -
> - backlight_disable(ddata->backlight);
> -
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> - regulator_disable(ddata->vcc_supply);
> -}
> -
> -static int panel_dpi_get_modes(struct omap_dss_device *dssdev,
> -struct drm_connector *connector)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> -
> - return omapdss_display_get_modes(connector, >vm);
> -}
> -
> -static const struct omap_dss_device_ops panel_dpi_ops = {
> - .connect= panel_dpi_connect,
> - .disconnect = panel_dpi_disconnect,
> -
> - .enable = panel_dpi_enable,
> - .disable= panel_dpi_disable,
> -
> - .get_modes = panel_dpi_get_modes,
> -};
> -
> -static int panel_dpi_probe_of(struct platform_device *pdev)
> -{
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> - struct device_node *node = pdev->dev.of_node;
> - int r;
> - struct display_timing timing;
> - struct gpio_desc *gpio;
> -
> - gpio =
Re: [PATCH v2 04/49] drm/omap: dsi: Hack-fix DSI bus flags
Hi,
On Fri, Jan 11, 2019 at 05:50:35AM +0200, Laurent Pinchart wrote:
> From: Tomi Valkeinen
>
> Since commit b4935e3a3cfa ("drm/omap: Store bus flags in the
> omap_dss_device structure") video mode flags are managed by the omapdss
> (and later omapdrm) core based on bus flags stored in omap_dss_device.
> This works fine for all devices whose video modes are set by the omapdss
> and omapdrm core, but breaks DSI operation as the DSI still uses legacy
> code paths and sets the DISPC timings manually.
>
> To fix the problem properly we should move the DSI encoder to the new
> encoder model. This will however require a considerable amount of work.
> Restore DSI operation by adding back video mode flags handling in the
> DSI encoder driver as a hack in the meantime.
>
> Fixes: b4935e3a3cfa ("drm/omap: Store bus flags in the omap_dss_device
> structure")
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dsi.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index b5685018d830..64fb788b6647 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4751,6 +4751,17 @@ static int dsi_set_config(struct omap_dss_device
> *dssdev,
> dsi->vm.flags |= DISPLAY_FLAGS_HSYNC_HIGH;
> dsi->vm.flags &= ~DISPLAY_FLAGS_VSYNC_LOW;
> dsi->vm.flags |= DISPLAY_FLAGS_VSYNC_HIGH;
> + /*
> + * HACK: These flags should be handled through the omap_dss_device bus
> + * flags, but this will only be possible when the DSI encoder will be
> + * converted to the omapdrm-managed encoder model.
> + */
> + dsi->vm.flags &= ~DISPLAY_FLAGS_PIXDATA_NEGEDGE;
> + dsi->vm.flags |= DISPLAY_FLAGS_PIXDATA_POSEDGE;
> + dsi->vm.flags &= ~DISPLAY_FLAGS_DE_LOW;
> + dsi->vm.flags |= DISPLAY_FLAGS_DE_HIGH;
> + dsi->vm.flags &= ~DISPLAY_FLAGS_SYNC_POSEDGE;
> + dsi->vm.flags |= DISPLAY_FLAGS_SYNC_NEGEDGE;
>
> dss_mgr_set_timings(>output, >vm);
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 45/49] drm/omap: Add support for drm_bridge
Hi,
On Fri, Jan 11, 2019 at 05:51:16AM +0200, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_dss_device and drm_bridge.
>
> Connector creation is skipped when using a drm_bridge, as the bridge
> creates the connector internally. This creates issues with systems that
> split connector operations (such as modes retrieval and hot-plug
> detection) across different bridges. These systems can't be supported
> using drm_bridge for now (their support through the omap_dss_device
> infrastructure is not affected), this will be fixed in subsequent
> changes.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
Tested-by: Sebastian Reichel
-- Sebastian
> Changes since v1:
>
> - Fix typo in function name (updata -> update)
> ---
> drivers/gpu/drm/omapdrm/dss/base.c | 27 --
> drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 +
> drivers/gpu/drm/omapdrm/dss/output.c | 21 +---
> drivers/gpu/drm/omapdrm/omap_connector.c | 16 --
> drivers/gpu/drm/omapdrm/omap_connector.h | 1 -
> drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 69 +---
> drivers/gpu/drm/omapdrm/omap_encoder.c | 69 ++--
> 8 files changed, 145 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 81ea0f55cd75..09c9f2971aa2 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dss.h"
> #include "omapdss.h"
> @@ -156,7 +157,7 @@ struct omap_dss_device *omapdss_device_next_output(struct
> omap_dss_device *from)
> goto done;
> }
>
> - if (dssdev->id && dssdev->next)
> + if (dssdev->id && (dssdev->next || dssdev->bridge))
> goto done;
> }
>
> @@ -184,7 +185,18 @@ int omapdss_device_connect(struct dss_device *dss,
> {
> int ret;
>
> - dev_dbg(dst->dev, "connect\n");
> + dev_dbg(>pdev->dev, "connect(%s, %s)\n",
> + src ? dev_name(src->dev) : "NULL",
> + dst ? dev_name(dst->dev) : "NULL");
> +
> + if (!dst) {
> + /*
> + * The destination is NULL when the source is connected to a
> + * bridge instead of a DSS device. Stop here, we will attach the
> + * bridge later when we will have a DRM encoder.
> + */
> + return src && src->bridge ? 0 : -EINVAL;
> + }
>
> if (omapdss_device_is_connected(dst))
> return -EBUSY;
> @@ -204,7 +216,16 @@ EXPORT_SYMBOL_GPL(omapdss_device_connect);
> void omapdss_device_disconnect(struct omap_dss_device *src,
> struct omap_dss_device *dst)
> {
> - dev_dbg(dst->dev, "disconnect\n");
> + struct dss_device *dss = src ? src->dss : dst->dss;
> +
> + dev_dbg(>pdev->dev, "disconnect(%s, %s)\n",
> + src ? dev_name(src->dev) : "NULL",
> + dst ? dev_name(dst->dev) : "NULL");
> +
> + if (!dst) {
> + WARN_ON(!src->bridge);
> + return;
> + }
>
> if (!dst->id && !omapdss_device_is_connected(dst)) {
> WARN_ON(!dst->display);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index ab5467a1e92c..f47e9b94288f 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -410,6 +410,7 @@ struct omap_dss_device {
>
> struct dss_device *dss;
> struct omap_dss_device *next;
> + struct drm_bridge *bridge;
>
> struct list_head list;
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index f25ecfd26534..2a53025c2fde 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -20,25 +20,34 @@
> #include
> #include
> #include
> +#include
>
> #include "dss.h"
> #include "omapdss.h"
>
> int omapdss_device_init_output(struct omap_dss_device *out)
> {
> - out->next = omapdss_of_find_connected_device(out->dev->of_node, 0);
> - if (IS_ERR(out->next)) {
> - if (PTR_ERR(out->next) != -EPROBE_DEFER)
> - dev_err(out->dev, "failed to find video sink\n");
> - return PTR_ERR(out->next);
> + struct device_node *remote_node;
> +
> + remote_node = of_graph_get_remote_node(out->dev->of_node, 0, 0);
> + if (!remote_node) {
> + dev_dbg(out->dev, "failed to find video sink\n");
> + return 0;
> }
>
> + out->next = omapdss_find_device_by_node(remote_node);
> +
Re: [PATCH v2 03/49] drm/omap: dsi: Fix OF platform depopulate
Hi,
On Fri, Jan 11, 2019 at 05:50:34AM +0200, Laurent Pinchart wrote:
> From: Tomi Valkeinen
>
> Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> bind to probe") moved the of_platform_populate() call from dsi_bind() to
> dsi_probe(), but failed to move the corresponding
> of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results
> in OF child devices being potentially removed multiple times. Fix it by
> placing the of_platform_depopulate() call where it belongs.
>
> Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind
> to probe")
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 277f9dd2ec8c..b5685018d830 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5104,8 +5104,6 @@ static void dsi_unbind(struct device *dev, struct
> device *master, void *data)
> dss_debugfs_remove_file(dsi->debugfs.irqs);
> dss_debugfs_remove_file(dsi->debugfs.regs);
>
> - of_platform_depopulate(dev);
> -
> WARN_ON(dsi->scp_clk_refcount > 0);
>
> dss_pll_unregister(>pll);
> @@ -5457,6 +5455,8 @@ static int dsi_remove(struct platform_device *pdev)
>
> dsi_uninit_output(dsi);
>
> + of_platform_depopulate(>dev);
> +
> pm_runtime_disable(>dev);
>
> if (dsi->vdds_dsi_reg != NULL && dsi->vdds_dsi_enabled) {
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] omapdrm: drm_bridge and drm_panel support
Hi, On Fri, Jan 11, 2019 at 03:34:19AM +0200, Laurent Pinchart wrote: > Hi Sebastian, > > On Thursday, 20 December 2018 14:17:27 EET Sebastian Reichel wrote: > > Hi, > > > > On Mon, Dec 10, 2018 at 03:06:17AM +0200, Laurent Pinchart wrote: > > > This patch series hooks up support for drm_bridge and drm_panel in the > > > omapdrm driver. > > > > > > [...] > > > > The series is > > > > Reviewed-by: Sebastian Reichel > > > > At the same time it is tested to break display on Droid 4. I don't > > know the exact reason yet. Debugging this is annoyingly hard, since > > the patches for manual display update still have not been merged > > making the testing process cumbersome. > > Is it this series that breaks display on Droid 4, or was it broken already ? > I've pushed all pending omapdrm patches to > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/next > > with the three fixes from Tomi at the bottom of the branch, and this series > at > the top. > > I think the omapdrm/dss drivers are now in a shape that can let us consider > upstreaming DSI support. The real challenge will be to do so in a way > compatible with drm_bridge and drm_panel. The main issue was the removal of pipe->display in this patchset. I suggest to remove the entry to avoid accidental usage. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 48/49] drm/omap: Remove TFP410 and DVI connector drivers
Hi,
On Fri, Jan 11, 2019 at 05:51:19AM +0200, Laurent Pinchart wrote:
> Those components are supported by the drm_bridge infrastructure, remove
> the omapdrm-specific driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
Tested-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/displays/Kconfig | 11 -
> drivers/gpu/drm/omapdrm/displays/Makefile | 2 -
> .../gpu/drm/omapdrm/displays/connector-dvi.c | 293 --
> .../gpu/drm/omapdrm/displays/encoder-tfp410.c | 140 -
> .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 2 -
> 5 files changed, 448 deletions(-)
> delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/Kconfig
> b/drivers/gpu/drm/omapdrm/displays/Kconfig
> index a349cb61961e..38d066ac966e 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
> @@ -6,23 +6,12 @@ config DRM_OMAP_ENCODER_OPA362
> Driver for OPA362 external analog TV amplifier controlled
> through a GPIO.
>
> -config DRM_OMAP_ENCODER_TFP410
> -tristate "TFP410 DPI to DVI Encoder"
> - help
> - Driver for TFP410 DPI to DVI encoder.
> -
> config DRM_OMAP_ENCODER_TPD12S015
> tristate "TPD12S015 HDMI ESD protection and level shifter"
> help
> Driver for TPD12S015, which offers HDMI ESD protection and level
> shifting.
>
> -config DRM_OMAP_CONNECTOR_DVI
> -tristate "DVI Connector"
> - depends on I2C
> - help
> - Driver for a generic DVI connector.
> -
> config DRM_OMAP_CONNECTOR_HDMI
> tristate "HDMI Connector"
> help
> diff --git a/drivers/gpu/drm/omapdrm/displays/Makefile
> b/drivers/gpu/drm/omapdrm/displays/Makefile
> index d99659e1381b..da1d5321ef50 100644
> --- a/drivers/gpu/drm/omapdrm/displays/Makefile
> +++ b/drivers/gpu/drm/omapdrm/displays/Makefile
> @@ -1,8 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_DRM_OMAP_ENCODER_OPA362) += encoder-opa362.o
> -obj-$(CONFIG_DRM_OMAP_ENCODER_TFP410) += encoder-tfp410.o
> obj-$(CONFIG_DRM_OMAP_ENCODER_TPD12S015) += encoder-tpd12s015.o
> -obj-$(CONFIG_DRM_OMAP_CONNECTOR_DVI) += connector-dvi.o
> obj-$(CONFIG_DRM_OMAP_CONNECTOR_HDMI) += connector-hdmi.o
> obj-$(CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
> obj-$(CONFIG_DRM_OMAP_PANEL_DPI) += panel-dpi.o
> diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> deleted file mode 100644
> index fa3a69bf8a04..
> --- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
> +++ /dev/null
> @@ -1,293 +0,0 @@
> -/*
> - * Generic DVI Connector driver
> - *
> - * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> - * Author: Tomi Valkeinen
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published
> by
> - * the Free Software Foundation.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include "../dss/omapdss.h"
> -
> -struct panel_drv_data {
> - struct omap_dss_device dssdev;
> -
> - struct i2c_adapter *i2c_adapter;
> -
> - struct gpio_desc *hpd_gpio;
> -
> - void (*hpd_cb)(void *cb_data, enum drm_connector_status status);
> - void *hpd_cb_data;
> - bool hpd_enabled;
> - /* mutex for hpd fields above */
> - struct mutex hpd_lock;
> -};
> -
> -#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
> -
> -static int dvic_connect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> - return 0;
> -}
> -
> -static void dvic_disconnect(struct omap_dss_device *src,
> - struct omap_dss_device *dst)
> -{
> -}
> -
> -static int dvic_ddc_read(struct i2c_adapter *adapter,
> - unsigned char *buf, u16 count, u8 offset)
> -{
> - int r, retries;
> -
> - for (retries = 3; retries > 0; retries--) {
> - struct i2c_msg msgs[] = {
> - {
> - .addr = DDC_ADDR,
> - .flags = 0,
> - .len= 1,
> - .buf= ,
> - }, {
> - .addr = DDC_ADDR,
> - .flags = I2C_M_RD,
> - .len= count,
> - .buf= buf,
> - }
> - };
> -
> - r = i2c_transfer(adapter, msgs, 2);
> - if (r == 2)
> - return 0;
> -
> - if (r != -EAGAIN)
> - break;
> - }
> -
> - return r < 0 ? r : -EIO;
> -}
> -
> -static int
Re: [PATCH v2 47/49] drm/omap: Whitelist DT nodes to fixup with omapdss, prefix
Hi,
On Fri, Jan 11, 2019 at 05:51:18AM +0200, Laurent Pinchart wrote:
> The omapdss driver patches DT at runtime to prepend an "omapdss," prefix
> to the compatible string of all encoders, panels and connectors. This
> mechanism ensures they get bound to the omapdss-specific drivers instead
> of generic drivers.
>
> Now that we have drm_bridge support in omapdrm, we need to selectively
> disable this mechanism. Add a whitelist of compatible strings to patch,
> and fill it with all the devices we support. They will be removed one by
> one once corresponding drm_bridge drivers become available and get
> successfully tested with omapdrm.
>
> The omapdss components load check code is updated accordingly to ignore
> devices managed by external bridge drivers.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
Tested-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c| 20 +++---
> .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 21 ++-
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 3c088cd2ceab..f8dad99013e8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -303,6 +303,7 @@ struct omapdss_comp_node {
> struct list_head list;
> struct device_node *node;
> bool dss_core_component;
> + const char *compat;
> };
>
> static bool omapdss_list_contains(const struct device_node *node)
> @@ -320,13 +321,20 @@ static bool omapdss_list_contains(const struct
> device_node *node)
> static void omapdss_walk_device(struct device *dev, struct device_node *node,
> bool dss_core)
> {
> + struct omapdss_comp_node *comp;
> struct device_node *n;
> - struct omapdss_comp_node *comp = devm_kzalloc(dev, sizeof(*comp),
> - GFP_KERNEL);
> + const char *compat;
> + int ret;
> +
> + ret = of_property_read_string(node, "compatible", );
> + if (ret < 0)
> + return;
>
> + comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
> if (comp) {
> comp->node = node;
> comp->dss_core_component = dss_core;
> + comp->compat = compat;
> list_add(>list, _comp_list);
> }
>
> @@ -366,12 +374,8 @@ void omapdss_gather_components(struct device *dev)
>
> omapdss_walk_device(dev, dev->of_node, true);
>
> - for_each_available_child_of_node(dev->of_node, child) {
> - if (!of_find_property(child, "compatible", NULL))
> - continue;
> -
> + for_each_available_child_of_node(dev->of_node, child)
> omapdss_walk_device(dev, child, true);
> - }
> }
> EXPORT_SYMBOL(omapdss_gather_components);
>
> @@ -379,6 +383,8 @@ static bool omapdss_component_is_loaded(struct
> omapdss_comp_node *comp)
> {
> if (comp->dss_core_component)
> return true;
> + if (!strstarts(comp->compat, "omapdss,"))
> + return true;
> if (omapdss_device_is_registered(comp->node))
> return true;
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> index 3bfb95d230e0..309b7b453e98 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
> @@ -184,6 +184,25 @@ static const struct of_device_id omapdss_of_match[]
> __initconst = {
> {},
> };
>
> +static const struct of_device_id omapdss_of_fixups_whitelist[] __initconst =
> {
> + { .compatible = "composite-video-connector" },
> + { .compatible = "dvi-connector" },
> + { .compatible = "hdmi-connector" },
> + { .compatible = "lgphilips,lb035q02" },
> + { .compatible = "nec,nl8048hl11" },
> + { .compatible = "panel-dpi" },
> + { .compatible = "panel-dsi-cm" },
> + { .compatible = "sharp,ls037v7dw01" },
> + { .compatible = "sony,acx565akm" },
> + { .compatible = "svideo-connector" },
> + { .compatible = "ti,opa362" },
> + { .compatible = "ti,tfp410" },
> + { .compatible = "ti,tpd12s015" },
> + { .compatible = "toppoly,td028ttec1" },
> + { .compatible = "tpo,td028ttec1" },
> + { .compatible = "tpo,td043mtea1" },
> +};
> +
> static int __init omapdss_boot_init(void)
> {
> struct device_node *dss, *child;
> @@ -210,7 +229,7 @@ static int __init omapdss_boot_init(void)
> n = list_first_entry(_conv_list, struct dss_conv_node,
> list);
>
> - if (!n->root)
> + if (of_match_node(omapdss_of_fixups_whitelist, n->node))
> omapdss_omapify_node(n->node);
>
> list_del(>list);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
>
Re: [PATCH v2 01/49] drm/atomic: Constify mode argument to mode_valid_path()
Hi,
On Fri, Jan 11, 2019 at 05:50:32AM +0200, Laurent Pinchart wrote:
> The mode_valid_path() function validates the mode it receives without
> ever modifying it. Constify the mode pointer argument to make that
> explicit.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Ville Syrjälä
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 54e2ae614dcc..d4ebec2c9f15 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -489,7 +489,7 @@ mode_fixup(struct drm_atomic_state *state)
> static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
> struct drm_encoder *encoder,
> struct drm_crtc *crtc,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> enum drm_mode_status ret;
>
> @@ -528,7 +528,7 @@ mode_valid(struct drm_atomic_state *state)
> struct drm_crtc *crtc = conn_state->crtc;
> struct drm_crtc_state *crtc_state;
> enum drm_mode_status mode_status;
> - struct drm_display_mode *mode;
> + const struct drm_display_mode *mode;
>
> if (!crtc || !encoder)
> continue;
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 46/49] drm/omap: Add support for drm_panel
Hi,
On Fri, Jan 11, 2019 at 05:51:17AM +0200, Laurent Pinchart wrote:
> Hook up drm_panel support in the omapdrm driver. The change is
> relatively simply as the way has been paved by drm_bridge support
> already. In addition to looking up, attaching to and detaching from the
> panel, we only need to add panel support in the connector .get_modes()
> handler, take connector bus flags (set by the panel) into account, and
> enable/disable the panel in the encoder enable/disable operations
> handlers.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sebastian Reichel
> ---
Tested-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/base.c | 12 ---
> drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 +
> drivers/gpu/drm/omapdrm/dss/output.c | 7 +++-
> drivers/gpu/drm/omapdrm/omap_connector.c | 9 ++
> drivers/gpu/drm/omapdrm/omap_drv.c | 15 -
> drivers/gpu/drm/omapdrm/omap_encoder.c | 41
> 6 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
> b/drivers/gpu/drm/omapdrm/dss/base.c
> index 09c9f2971aa2..3c088cd2ceab 100644
> --- a/drivers/gpu/drm/omapdrm/dss/base.c
> +++ b/drivers/gpu/drm/omapdrm/dss/base.c
> @@ -157,7 +157,8 @@ struct omap_dss_device *omapdss_device_next_output(struct
> omap_dss_device *from)
> goto done;
> }
>
> - if (dssdev->id && (dssdev->next || dssdev->bridge))
> + if (dssdev->id &&
> + (dssdev->next || dssdev->bridge || dssdev->panel))
> goto done;
> }
>
> @@ -192,10 +193,11 @@ int omapdss_device_connect(struct dss_device *dss,
> if (!dst) {
> /*
>* The destination is NULL when the source is connected to a
> - * bridge instead of a DSS device. Stop here, we will attach the
> - * bridge later when we will have a DRM encoder.
> + * bridge or panel instead of a DSS device. Stop here, we will
> + * attach the bridge or panel later when we will have a DRM
> + * encoder.
>*/
> - return src && src->bridge ? 0 : -EINVAL;
> + return src && (src->bridge || src->panel) ? 0 : -EINVAL;
> }
>
> if (omapdss_device_is_connected(dst))
> @@ -223,7 +225,7 @@ void omapdss_device_disconnect(struct omap_dss_device
> *src,
> dst ? dev_name(dst->dev) : "NULL");
>
> if (!dst) {
> - WARN_ON(!src->bridge);
> + WARN_ON(!src->bridge && !src->panel);
> return;
> }
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index f47e9b94288f..0c734d1f89e1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -411,6 +411,7 @@ struct omap_dss_device {
> struct dss_device *dss;
> struct omap_dss_device *next;
> struct drm_bridge *bridge;
> + struct drm_panel *panel;
>
> struct list_head list;
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index 2a53025c2fde..10a9ee5cdc61 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -22,6 +22,8 @@
> #include
> #include
>
> +#include
> +
> #include "dss.h"
> #include "omapdss.h"
>
> @@ -37,6 +39,9 @@ int omapdss_device_init_output(struct omap_dss_device *out)
>
> out->next = omapdss_find_device_by_node(remote_node);
> out->bridge = of_drm_find_bridge(remote_node);
> + out->panel = of_drm_find_panel(remote_node);
> + if (IS_ERR(out->panel))
> + out->panel = NULL;
>
> of_node_put(remote_node);
>
> @@ -47,7 +52,7 @@ int omapdss_device_init_output(struct omap_dss_device *out)
> return -EINVAL;
> }
>
> - return out->next || out->bridge ? 0 : -EPROBE_DEFER;
> + return out->next || out->bridge || out->panel ? 0 : -EPROBE_DEFER;
> }
> EXPORT_SYMBOL(omapdss_device_init_output);
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index f528baa80114..2da16f00cfae 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "omap_drv.h"
>
> @@ -211,6 +212,7 @@ static int omap_connector_get_modes_edid(struct
> drm_connector *connector,
>
> static int omap_connector_get_modes(struct drm_connector *connector)
> {
> + struct omap_connector *omap_connector = to_omap_connector(connector);
> struct omap_dss_device *dssdev;
>
> DBG("%s", connector->name);
> @@ -233,6 +235,13 @@ static int omap_connector_get_modes(struct drm_connector
> *connector)
> if (dssdev)
> return dssdev->ops->get_modes(dssdev,
Re: [PATCH v2 29/49] drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()
Hi,
On Fri, Jan 11, 2019 at 05:51:00AM +0200, Laurent Pinchart wrote:
> The omap_dss_device .check_timings() and .set_timings() operations
> operate on struct videomode, while the DRM API operates on struct
> drm_display_mode. This forces conversion from to videomode in the
> callers. While that's not a problem per se, it creates a difference with
> the drm_bridge API.
>
> Replace the videomode parameter to the .check_timings() and
> .set_timings() operations with a drm_display_mode. This pushed the
> conversion to videomode down to the DSS devices in some cases. If needed
> they will be converted to operate on drm_display_mode natively.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Sebastian Reichel
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> .../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 8 +++---
> drivers/gpu/drm/omapdrm/dss/dpi.c | 16 +--
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 6 ++--
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 6 ++--
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +--
> drivers/gpu/drm/omapdrm/dss/sdi.c | 17 +--
> drivers/gpu/drm/omapdrm/dss/venc.c| 28 +--
> drivers/gpu/drm/omapdrm/omap_connector.c | 7 ++---
> drivers/gpu/drm/omapdrm/omap_encoder.c| 2 +-
> 9 files changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index ce812094177c..d9f10f41ddfb 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -1127,20 +1127,20 @@ static int dsicm_get_modes(struct omap_dss_device
> *dssdev,
> }
>
> static int dsicm_check_timings(struct omap_dss_device *dssdev,
> -struct videomode *vm)
> +struct drm_display_mode *mode)
> {
> struct panel_drv_data *ddata = to_panel_data(dssdev);
> int ret = 0;
>
> - if (vm->hactive != ddata->vm.hactive)
> + if (mode->hdisplay != ddata->vm.hactive)
> ret = -EINVAL;
>
> - if (vm->vactive != ddata->vm.vactive)
> + if (mode->vdisplay != ddata->vm.vactive)
> ret = -EINVAL;
>
> if (ret) {
> dev_warn(dssdev->dev, "wrong resolution: %d x %d",
> - vm->hactive, vm->vactive);
> + mode->hdisplay, mode->vdisplay);
> dev_warn(dssdev->dev, "panel resolution: %d x %d",
>ddata->vm.hactive, ddata->vm.vactive);
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
> b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 0db01cadf09f..0cb3cb72f15f 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -459,7 +459,7 @@ static void dpi_display_disable(struct omap_dss_device
> *dssdev)
> }
>
> static void dpi_set_timings(struct omap_dss_device *dssdev,
> - const struct videomode *vm)
> + const struct drm_display_mode *mode)
> {
> struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
>
> @@ -467,13 +467,13 @@ static void dpi_set_timings(struct omap_dss_device
> *dssdev,
>
> mutex_lock(>lock);
>
> - dpi->vm = *vm;
> + drm_display_mode_to_videomode(mode, >vm);
>
> mutex_unlock(>lock);
> }
>
> static int dpi_check_timings(struct omap_dss_device *dssdev,
> - struct videomode *vm)
> + struct drm_display_mode *mode)
> {
> struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
> int lck_div, pck_div;
> @@ -482,20 +482,20 @@ static int dpi_check_timings(struct omap_dss_device
> *dssdev,
> struct dpi_clk_calc_ctx ctx;
> bool ok;
>
> - if (vm->hactive % 8 != 0)
> + if (mode->hdisplay % 8 != 0)
> return -EINVAL;
>
> - if (vm->pixelclock == 0)
> + if (mode->clock == 0)
> return -EINVAL;
>
> if (dpi->pll) {
> - ok = dpi_pll_clk_calc(dpi, vm->pixelclock, );
> + ok = dpi_pll_clk_calc(dpi, mode->clock * 1000, );
> if (!ok)
> return -EINVAL;
>
> fck = ctx.pll_cinfo.clkout[ctx.clkout_idx];
> } else {
> - ok = dpi_dss_clk_calc(dpi, vm->pixelclock, );
> + ok = dpi_dss_clk_calc(dpi, mode->clock * 1000, );
> if (!ok)
> return -EINVAL;
>
> @@ -507,7 +507,7 @@ static int dpi_check_timings(struct omap_dss_device
> *dssdev,
>
> pck = fck / lck_div / pck_div;
>
> - vm->pixelclock = pck;
> + mode->clock = pck / 1000;
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 60792981a33f..4337380b1bf7 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++
Re: [PATCH v2 45/49] drm/omap: Add support for drm_bridge
Hi, On Fri, Jan 11, 2019 at 05:51:16AM +0200, Laurent Pinchart wrote: > Hook up drm_bridge support in the omapdrm driver. Despite the recent > extensive preparation work, this is a rather intrusive change, as the > management of outputs needs to be adapted through the driver to handle > both omap_dss_device and drm_bridge. > > Connector creation is skipped when using a drm_bridge, as the bridge > creates the connector internally. This creates issues with systems that > split connector operations (such as modes retrieval and hot-plug > detection) across different bridges. These systems can't be supported > using drm_bridge for now (their support through the omap_dss_device > infrastructure is not affected), this will be fixed in subsequent > changes. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > --- > Changes since v1: > > - Fix typo in function name (updata -> update) > --- This patch drops all usage of pipe->display. It should probably also remove the struct entry to simplify things and avoid stupid mistakes when somebody rebases patches (*cough*). -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/49] omapdrm: drm_bridge and drm_panel support
Hi, On Fri, Jan 11, 2019 at 05:50:31AM +0200, Laurent Pinchart wrote: > Hello, > > This patch series consolidates the three pending series for the omapdrm and > tfp410 drivers that all together implement drm_bridge and drm_panel support > for omapdrm. > > The series starts with four patches not posted before as part of this work. > The first patch (01/49) has been sitting in my tree as a base for the omapdrm > rework for such a long time that I have included it here. The next three > patches (02/49 to 04/49) have been written by Tomi to fix DSI regression > introduced by previous omapdrm rework, and are included here to start with a > cleaner base. > > The following 30 patches (05/49 to 34/49) have previously been posted as part > of "[PATCH 00/29] omapdrm: Last large refactoring for drm_bridge transition" > [1]. They complete the extensive rework of the omapdrm and omapdss drivers to > prepare for the transition to drm_bridge. > > The next 7 patches (35/49 to 41/49) have been previously posted as part of > "[PATCH v2 0/2] Clarify display info PIXDATA bus flags" [2] and > "[PATCH 0/5] drm: ti-tfp410 improvements" [3]. They improve the ti-tfp410 > driver with new features required by omapdrm and currently implemented in the > omapdrm custom tfp410 driver. > > The next 2 patches (42/49 and 43/49) are new and add missing DT bindings for > the panel used by the TI AM57xx EVM. > > The last 6 patches (44/49 to 49/49) have previously been posted as part of > "[PATCH 0/6] omapdrm: drm_bridge and drm_panel support" [4]. They hook up > support for drm_bridge and drm_panel in the omapdrm driver, and remove the > omapdrm-specific tfp410 and panel-dpi drivers. > > All patches have been rebased on top of v5.0-rc1 and review comments have been > incorporated. Please see individual patches for changelogs. The whole series > is available from > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/next > > [1] https://www.spinics.net/lists/dri-devel/msg198993.html > [2] https://lists.freedesktop.org/archives/dri-devel/2018-December/199204.html > [3] https://www.spinics.net/lists/dri-devel/msg199245.html > [4] https://www.spinics.net/lists/dri-devel/msg199524.html I rebased the series to 5.0-rc5, (which contains some DSI fixes). This worked without any manual merge conflicts :). I also rebased rebased the DSI command mode patchset on top of it. Everything seems to work fine on Droid 4, so the series is Tested-by: Sebastian Reichel I pushed out the rebased branch with DSI support here: git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git omapdrm/bridge/next-with-dsi -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 05/16] drm/bridge: tc358767: fix single lane configuration
From: Tomi Valkeinen
[ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ]
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index e697c7c6ca52..acac2c1769ad 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -541,6 +541,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
unsigned long rate;
u32 value;
int ret;
+ u32 dp_phy_ctrl;
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -565,7 +566,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
+ tc_write(DP_PHY_CTRL, dp_phy_ctrl);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -858,7 +862,9 @@ static int tc_main_link_setup(struct tc_data *tc)
tc_write(SYS_PLLPARAM, value);
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 07/12] drm/bridge: tc358767: fix output H/V syncs
From: Tomi Valkeinen [ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 16fa42984c50..fa3f2f039a74 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -96,6 +96,8 @@ #define DP0_STARTVAL 0x064c #define DP0_ACTIVEVAL 0x0650 #define DP0_SYNCVAL0x0654 +#define SYNCVAL_HS_POL_ACTIVE_LOW (1 << 15) +#define SYNCVAL_VS_POL_ACTIVE_LOW (1 << 31) #define DP0_MISC 0x0658 #define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */ #define BPC_6 (0 << 5) @@ -724,7 +726,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | +((mode->flags & DRM_MODE_FLAG_NHSYNC) ? SYNCVAL_HS_POL_ACTIVE_LOW : 0) | +((mode->flags & DRM_MODE_FLAG_NVSYNC) ? SYNCVAL_VS_POL_ACTIVE_LOW : 0)); tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 25/28] drm/nouveau: Don't disable polling in fallback mode
From: Takashi Iwai
[ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ]
When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling. Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.
Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan
control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
Reported-by: Thomas Blume
Signed-off-by: Takashi Iwai
Reviewed-by: Martin Peres
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 3695cde669f8..07914e36939e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -132,11 +132,12 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
duty = nvkm_therm_update_linear(therm);
break;
case NVBIOS_THERM_FAN_OTHER:
- if (therm->cstate)
+ if (therm->cstate) {
duty = therm->cstate;
- else
+ poll = false;
+ } else {
duty = nvkm_therm_update_linear_fallback(therm);
- poll = false;
+ }
break;
}
immd = false;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 26/28] drm/nouveau/falcon: avoid touching registers if engine is off
From: Ilia Mirkin
[ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
index 816ccaedfc73..8675613e142b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
@@ -107,8 +108,10 @@ nvkm_falcon_fini(struct nvkm_engine *engine, bool suspend)
}
}
- nvkm_mask(device, base + 0x048, 0x0003, 0x);
- nvkm_wr32(device, base + 0x014, 0x);
+ if (nvkm_mc_enabled(device, engine->subdev.index)) {
+ nvkm_mask(device, base + 0x048, 0x0003, 0x);
+ nvkm_wr32(device, base + 0x014, 0x);
+ }
return 0;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 12/28] drm/bridge: tc358767: reject modes which require too much BW
From: Tomi Valkeinen
[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ]
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index ab299f4debfa..a1f3dd2afbb1 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1114,10 +1114,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
*bridge,
static enum drm_mode_status tc_connector_mode_valid(struct drm_connector
*connector,
struct drm_display_mode *mode)
{
+ struct tc_data *tc = connector_to_tc(connector);
+ u32 req, avail;
+ u32 bits_per_pixel = 24;
+
/* DPI interface clock limitation: upto 154 MHz */
if (mode->clock > 154000)
return MODE_CLOCK_HIGH;
+ req = mode->clock * bits_per_pixel / 8;
+ avail = tc->link.base.num_lanes * tc->link.base.rate;
+
+ if (req > avail)
+ return MODE_BAD;
+
return MODE_OK;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 06/12] drm/bridge: tc358767: reject modes which require too much BW
From: Tomi Valkeinen
[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ]
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index dbe403ea130d..16fa42984c50 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1118,10 +1118,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
*bridge,
static int tc_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct tc_data *tc = connector_to_tc(connector);
+ u32 req, avail;
+ u32 bits_per_pixel = 24;
+
/* DPI interface clock limitation: upto 154 MHz */
if (mode->clock > 154000)
return MODE_CLOCK_HIGH;
+ req = mode->clock * bits_per_pixel / 8;
+ avail = tc->link.base.num_lanes * tc->link.base.rate;
+
+ if (req > avail)
+ return MODE_BAD;
+
return MODE_OK;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 04/16] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
From: Tomi Valkeinen
[ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ]
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 8636e7eeb731..e697c7c6ca52 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -140,6 +140,8 @@
#define DP0_LTLOOPCTRL 0x06d8
#define DP0_SNKLTCTRL 0x06e4
+#define DP1_SRCCTRL0x07a0
+
/* PHY */
#define DP_PHY_CTRL0x0800
#define DP_PHY_RST BIT(28) /* DP PHY Global Soft Reset */
@@ -148,6 +150,7 @@
#define PHY_M1_RST BIT(12) /* Reset PHY1 Main Channel */
#define PHY_RDYBIT(16) /* PHY Main Channels
Ready */
#define PHY_M0_RST BIT(8) /* Reset PHY0 Main Channel */
+#define PHY_2LANE BIT(2) /* PHY Enable 2 lanes */
#define PHY_A0_EN BIT(1) /* PHY Aux Channel0 Enable */
#define PHY_M0_EN BIT(0) /* PHY Main Channel0 Enable */
@@ -562,7 +565,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
+ tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -832,7 +835,7 @@ static int tc_main_link_setup(struct tc_data *tc)
DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
/* from excel file - DP1_SrcCtrl */
- tc_write(0x07a0, 0x3083);
+ tc_write(DP1_SRCCTRL, 0x3083);
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -853,8 +856,9 @@ static int tc_main_link_setup(struct tc_data *tc)
}
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
+
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 13/28] drm/bridge: tc358767: fix output H/V syncs
From: Tomi Valkeinen [ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index a1f3dd2afbb1..391547358756 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -98,6 +98,8 @@ #define DP0_STARTVAL 0x064c #define DP0_ACTIVEVAL 0x0650 #define DP0_SYNCVAL0x0654 +#define SYNCVAL_HS_POL_ACTIVE_LOW (1 << 15) +#define SYNCVAL_VS_POL_ACTIVE_LOW (1 << 31) #define DP0_MISC 0x0658 #define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */ #define BPC_6 (0 << 5) @@ -726,7 +728,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | +((mode->flags & DRM_MODE_FLAG_NHSYNC) ? SYNCVAL_HS_POL_ACTIVE_LOW : 0) | +((mode->flags & DRM_MODE_FLAG_NVSYNC) ? SYNCVAL_VS_POL_ACTIVE_LOW : 0)); tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 18/28] drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang
From: Jim Qu
[ Upstream commit 0c6c8125582714e1fd3544983eba3d750db0f5b8 ]
effect asics: VEGA10 and VEGA12
Signed-off-by: Jim Qu
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 7c3b634d8d5f..de5a689e1925 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -71,7 +71,6 @@ static const struct soc15_reg_golden golden_settings_sdma_4[]
= {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL,
0xfff0, 0x00403000),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff,
0x03c0),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc00,
0x),
- SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831f07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CLK_CTRL, 0x,
0x3f000100),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GFX_IB_CNTL, 0x800f0100,
0x0100),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GFX_RB_WPTR_POLL_CNTL,
0xfff0, 0x00403000),
@@ -89,6 +88,7 @@ static const struct soc15_reg_golden golden_settings_sdma_4[]
= {
static const struct soc15_reg_golden golden_settings_sdma_vg10[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG, 0x0018773f,
0x00104002),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104002),
+ SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831d07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG, 0x0018773f,
0x00104002),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104002)
};
@@ -96,6 +96,7 @@ static const struct soc15_reg_golden
golden_settings_sdma_vg10[] = {
static const struct soc15_reg_golden golden_settings_sdma_vg12[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG, 0x0018773f,
0x00104001),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104001),
+ SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831d07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG, 0x0018773f,
0x00104001),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104001)
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 05/12] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
From: Tomi Valkeinen
[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ]
Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
This patch changes the configuration as follows:
Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.
DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 8098297c5fe5..dbe403ea130d 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -834,12 +834,11 @@ static int tc_main_link_setup(struct tc_data *tc)
if (!tc->mode)
return -EINVAL;
- /* from excel file - DP0_SrcCtrl */
- tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
-DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
-DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
- /* from excel file - DP1_SrcCtrl */
- tc_write(DP1_SRCCTRL, 0x3083);
+ tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
+ /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
+ tc_write(DP1_SRCCTRL,
+(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
+((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 07/16] drm/bridge: tc358767: reject modes which require too much BW
From: Tomi Valkeinen
[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ]
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 24bb6bfa36f3..792a2548d3bb 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1112,10 +1112,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
*bridge,
static int tc_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct tc_data *tc = connector_to_tc(connector);
+ u32 req, avail;
+ u32 bits_per_pixel = 24;
+
/* DPI interface clock limitation: upto 154 MHz */
if (mode->clock > 154000)
return MODE_CLOCK_HIGH;
+ req = mode->clock * bits_per_pixel / 8;
+ avail = tc->link.base.num_lanes * tc->link.base.rate;
+
+ if (req > avail)
+ return MODE_BAD;
+
return MODE_OK;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 08/16] drm/bridge: tc358767: fix output H/V syncs
From: Tomi Valkeinen [ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 792a2548d3bb..6eebd8ad0c52 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -96,6 +96,8 @@ #define DP0_STARTVAL 0x064c #define DP0_ACTIVEVAL 0x0650 #define DP0_SYNCVAL0x0654 +#define SYNCVAL_HS_POL_ACTIVE_LOW (1 << 15) +#define SYNCVAL_VS_POL_ACTIVE_LOW (1 << 31) #define DP0_MISC 0x0658 #define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */ #define BPC_6 (0 << 5) @@ -724,7 +726,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | +((mode->flags & DRM_MODE_FLAG_NHSYNC) ? SYNCVAL_HS_POL_ACTIVE_LOW : 0) | +((mode->flags & DRM_MODE_FLAG_NVSYNC) ? SYNCVAL_VS_POL_ACTIVE_LOW : 0)); tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 03/12] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
From: Tomi Valkeinen
[ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ]
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index f64f35cdc2ff..e67b163a8ce8 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -140,6 +140,8 @@
#define DP0_LTLOOPCTRL 0x06d8
#define DP0_SNKLTCTRL 0x06e4
+#define DP1_SRCCTRL0x07a0
+
/* PHY */
#define DP_PHY_CTRL0x0800
#define DP_PHY_RST BIT(28) /* DP PHY Global Soft Reset */
@@ -148,6 +150,7 @@
#define PHY_M1_RST BIT(12) /* Reset PHY1 Main Channel */
#define PHY_RDYBIT(16) /* PHY Main Channels
Ready */
#define PHY_M0_RST BIT(8) /* Reset PHY0 Main Channel */
+#define PHY_2LANE BIT(2) /* PHY Enable 2 lanes */
#define PHY_A0_EN BIT(1) /* PHY Aux Channel0 Enable */
#define PHY_M0_EN BIT(0) /* PHY Main Channel0 Enable */
@@ -562,7 +565,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
+ tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -832,7 +835,7 @@ static int tc_main_link_setup(struct tc_data *tc)
DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
/* from excel file - DP1_SrcCtrl */
- tc_write(0x07a0, 0x3083);
+ tc_write(DP1_SRCCTRL, 0x3083);
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -853,8 +856,9 @@ static int tc_main_link_setup(struct tc_data *tc)
}
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
+
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 14/16] drm/nouveau: Don't disable polling in fallback mode
From: Takashi Iwai
[ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ]
When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling. Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.
Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan
control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
Reported-by: Thomas Blume
Signed-off-by: Takashi Iwai
Reviewed-by: Martin Peres
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 952a7cb0a59a..692d4d96766a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -131,11 +131,12 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
duty = nvkm_therm_update_linear(therm);
break;
case NVBIOS_THERM_FAN_OTHER:
- if (therm->cstate)
+ if (therm->cstate) {
duty = therm->cstate;
- else
+ poll = false;
+ } else {
duty = nvkm_therm_update_linear_fallback(therm);
- poll = false;
+ }
break;
}
immd = false;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 15/16] drm/nouveau/falcon: avoid touching registers if engine is off
From: Ilia Mirkin
[ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
index 2e7b4e2105ef..62cb376e2c01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
@@ -107,8 +108,10 @@ nvkm_falcon_fini(struct nvkm_engine *engine, bool suspend)
}
}
- nvkm_mask(device, base + 0x048, 0x0003, 0x);
- nvkm_wr32(device, base + 0x014, 0x);
+ if (nvkm_mc_enabled(device, engine->subdev.index)) {
+ nvkm_mask(device, base + 0x048, 0x0003, 0x);
+ nvkm_wr32(device, base + 0x014, 0x);
+ }
return 0;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 04/12] drm/bridge: tc358767: fix single lane configuration
From: Tomi Valkeinen
[ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ]
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index e67b163a8ce8..8098297c5fe5 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -541,6 +541,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
unsigned long rate;
u32 value;
int ret;
+ u32 dp_phy_ctrl;
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -565,7 +566,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
+ tc_write(DP_PHY_CTRL, dp_phy_ctrl);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -858,7 +862,9 @@ static int tc_main_link_setup(struct tc_data *tc)
tc_write(SYS_PLLPARAM, value);
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 06/16] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
From: Tomi Valkeinen
[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ]
Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
This patch changes the configuration as follows:
Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.
DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index acac2c1769ad..24bb6bfa36f3 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -834,12 +834,11 @@ static int tc_main_link_setup(struct tc_data *tc)
if (!tc->mode)
return -EINVAL;
- /* from excel file - DP0_SrcCtrl */
- tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
-DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
-DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
- /* from excel file - DP1_SrcCtrl */
- tc_write(DP1_SRCCTRL, 0x3083);
+ tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
+ /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
+ tc_write(DP1_SRCCTRL,
+(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
+((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 10/28] drm/bridge: tc358767: fix single lane configuration
From: Tomi Valkeinen
[ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ]
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5f0a666db2fd..fee53422c31f 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -543,6 +543,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
unsigned long rate;
u32 value;
int ret;
+ u32 dp_phy_ctrl;
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -567,7 +568,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
+ tc_write(DP_PHY_CTRL, dp_phy_ctrl);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -860,7 +864,9 @@ static int tc_main_link_setup(struct tc_data *tc)
tc_write(SYS_PLLPARAM, value);
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 16/42] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
From: Tomi Valkeinen
[ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ]
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 29a7e33e8ae0..5f0a666db2fd 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -142,6 +142,8 @@
#define DP0_LTLOOPCTRL 0x06d8
#define DP0_SNKLTCTRL 0x06e4
+#define DP1_SRCCTRL0x07a0
+
/* PHY */
#define DP_PHY_CTRL0x0800
#define DP_PHY_RST BIT(28) /* DP PHY Global Soft Reset */
@@ -150,6 +152,7 @@
#define PHY_M1_RST BIT(12) /* Reset PHY1 Main Channel */
#define PHY_RDYBIT(16) /* PHY Main Channels
Ready */
#define PHY_M0_RST BIT(8) /* Reset PHY0 Main Channel */
+#define PHY_2LANE BIT(2) /* PHY Enable 2 lanes */
#define PHY_A0_EN BIT(1) /* PHY Aux Channel0 Enable */
#define PHY_M0_EN BIT(0) /* PHY Main Channel0 Enable */
@@ -564,7 +567,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
+ tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -834,7 +837,7 @@ static int tc_main_link_setup(struct tc_data *tc)
DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
/* from excel file - DP1_SrcCtrl */
- tc_write(0x07a0, 0x3083);
+ tc_write(DP1_SRCCTRL, 0x3083);
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -855,8 +858,9 @@ static int tc_main_link_setup(struct tc_data *tc)
}
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
+
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 11/28] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
From: Tomi Valkeinen
[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ]
Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
This patch changes the configuration as follows:
Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.
DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index fee53422c31f..ab299f4debfa 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -836,12 +836,11 @@ static int tc_main_link_setup(struct tc_data *tc)
if (!tc->mode)
return -EINVAL;
- /* from excel file - DP0_SrcCtrl */
- tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
-DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
-DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
- /* from excel file - DP1_SrcCtrl */
- tc_write(DP1_SRCCTRL, 0x3083);
+ tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
+ /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
+ tc_write(DP1_SRCCTRL,
+(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
+((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 01/28] drm/amdgpu/sriov:Correct pfvf exchange logic
From: Emily Deng
[ Upstream commit b8cf66182eddb22e9c7539821ed6eecdb4f86d1a ]
The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu
reset.
Signed-off-by: Emily Deng
Reviewed-By: Xiangliang Yu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 39bf2ce548c6..7f6af421d3e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1653,8 +1653,10 @@ static int amdgpu_device_ip_init(struct amdgpu_device
*adev)
amdgpu_amdkfd_device_init(adev);
- if (amdgpu_sriov_vf(adev))
+ if (amdgpu_sriov_vf(adev)) {
+ amdgpu_virt_init_data_exchange(adev);
amdgpu_virt_release_full_gpu(adev, true);
+ }
return 0;
}
@@ -2555,9 +2557,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
goto failed;
}
- if (amdgpu_sriov_vf(adev))
- amdgpu_virt_init_data_exchange(adev);
-
amdgpu_fbdev_init(adev);
r = amdgpu_pm_sysfs_init(adev);
@@ -3269,6 +3268,7 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device
*adev,
r = amdgpu_ib_ring_tests(adev);
error:
+ amdgpu_virt_init_data_exchange(adev);
amdgpu_virt_release_full_gpu(adev, true);
if (!r && adev->virt.gim_feature & AMDGIM_FEATURE_GIM_FLR_VRAMLOST) {
atomic_inc(>vram_lost_counter);
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
index 078f70faedcb..d06332be59d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -174,7 +174,7 @@ static int xgpu_ai_send_access_requests(struct
amdgpu_device *adev,
return r;
}
/* Retrieve checksum from mailbox2 */
- if (req == IDH_REQ_GPU_INIT_ACCESS) {
+ if (req == IDH_REQ_GPU_INIT_ACCESS || req ==
IDH_REQ_GPU_RESET_ACCESS) {
adev->virt.fw_reserve.checksum_key =
RREG32_NO_KIQ(SOC15_REG_OFFSET(NBIO, 0,
mmBIF_BX_PF0_MAILBOX_MSGBUF_RCV_DW2));
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 19/42] drm/bridge: tc358767: reject modes which require too much BW
From: Tomi Valkeinen
[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ]
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index ab299f4debfa..a1f3dd2afbb1 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1114,10 +1114,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
*bridge,
static enum drm_mode_status tc_connector_mode_valid(struct drm_connector
*connector,
struct drm_display_mode *mode)
{
+ struct tc_data *tc = connector_to_tc(connector);
+ u32 req, avail;
+ u32 bits_per_pixel = 24;
+
/* DPI interface clock limitation: upto 154 MHz */
if (mode->clock > 154000)
return MODE_CLOCK_HIGH;
+ req = mode->clock * bits_per_pixel / 8;
+ avail = tc->link.base.num_lanes * tc->link.base.rate;
+
+ if (req > avail)
+ return MODE_BAD;
+
return MODE_OK;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 20/42] drm/bridge: tc358767: fix output H/V syncs
From: Tomi Valkeinen [ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ] The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index a1f3dd2afbb1..391547358756 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -98,6 +98,8 @@ #define DP0_STARTVAL 0x064c #define DP0_ACTIVEVAL 0x0650 #define DP0_SYNCVAL0x0654 +#define SYNCVAL_HS_POL_ACTIVE_LOW (1 << 15) +#define SYNCVAL_VS_POL_ACTIVE_LOW (1 << 31) #define DP0_MISC 0x0658 #define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */ #define BPC_6 (0 << 5) @@ -726,7 +728,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | +((mode->flags & DRM_MODE_FLAG_NHSYNC) ? SYNCVAL_HS_POL_ACTIVE_LOW : 0) | +((mode->flags & DRM_MODE_FLAG_NVSYNC) ? SYNCVAL_VS_POL_ACTIVE_LOW : 0)); tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 15/42] drm/bridge: tc358767: add bus flags
From: Tomi Valkeinen [ Upstream commit 4842379cbe6e851de914a7132f76f4e200b9a98b ] tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-2-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 8e28e738cb52..29a7e33e8ae0 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1195,6 +1195,10 @@ static int tc_bridge_attach(struct drm_bridge *bridge) drm_display_info_set_bus_formats(>connector.display_info, _format, 1); + tc->connector.display_info.bus_flags = + DRM_BUS_FLAG_DE_HIGH | + DRM_BUS_FLAG_PIXDATA_NEGEDGE | + DRM_BUS_FLAG_SYNC_NEGEDGE; drm_connector_attach_encoder(>connector, tc->bridge.encoder); return 0; -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 27/42] drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang
From: Jim Qu
[ Upstream commit 0c6c8125582714e1fd3544983eba3d750db0f5b8 ]
effect asics: VEGA10 and VEGA12
Signed-off-by: Jim Qu
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 7a8c9172d30a..86d5dc5f8887 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -73,7 +73,6 @@ static const struct soc15_reg_golden golden_settings_sdma_4[]
= {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL,
0xfff0, 0x00403000),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff,
0x03c0),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc00,
0x),
- SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831f07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CLK_CTRL, 0x,
0x3f000100),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GFX_IB_CNTL, 0x800f0100,
0x0100),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GFX_RB_WPTR_POLL_CNTL,
0xfff0, 0x00403000),
@@ -91,6 +90,7 @@ static const struct soc15_reg_golden golden_settings_sdma_4[]
= {
static const struct soc15_reg_golden golden_settings_sdma_vg10[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG, 0x0018773f,
0x00104002),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104002),
+ SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831d07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG, 0x0018773f,
0x00104002),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104002)
};
@@ -98,6 +98,7 @@ static const struct soc15_reg_golden
golden_settings_sdma_vg10[] = {
static const struct soc15_reg_golden golden_settings_sdma_vg12[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG, 0x0018773f,
0x00104001),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104001),
+ SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_CHICKEN_BITS, 0xfe931f07,
0x02831d07),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG, 0x0018773f,
0x00104001),
SOC15_REG_GOLDEN_VALUE(SDMA1, 0, mmSDMA1_GB_ADDR_CONFIG_READ,
0x0018773f, 0x00104001)
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 26/42] drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20
From: Tao Zhou [ Upstream commit 3e958fe67720b37d04ab8ef81b9d507a56a09bbc ] Fix CPDMA hang in PRT mode for both VEGA10 and VEGA20 Signed-off-by: Tao Zhou Tested-by: Yukun.Li Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index 21363b2b2ee5..88ed064b3585 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c @@ -112,7 +112,10 @@ static const struct soc15_reg_golden golden_settings_gc_9_0[] = SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CHAN_STEER_HI, 0x, 0x4a2c0e68), SOC15_REG_GOLDEN_VALUE(GC, 0, mmTCP_CHAN_STEER_LO, 0x, 0xb5d3f197), SOC15_REG_GOLDEN_VALUE(GC, 0, mmVGT_CACHE_INVALIDATION, 0x3fff3af3, 0x1920), - SOC15_REG_GOLDEN_VALUE(GC, 0, mmVGT_GS_MAX_WAVE_ID, 0x0fff, 0x03ff) + SOC15_REG_GOLDEN_VALUE(GC, 0, mmVGT_GS_MAX_WAVE_ID, 0x0fff, 0x03ff), + SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_MEC1_F32_INT_DIS, 0x, 0x0800), + SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_MEC2_F32_INT_DIS, 0x, 0x0800), + SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_DEBUG, 0x, 0x8000) }; static const struct soc15_reg_golden golden_settings_gc_9_0_vg10[] = @@ -134,10 +137,7 @@ static const struct soc15_reg_golden golden_settings_gc_9_0_vg10[] = SOC15_REG_GOLDEN_VALUE(GC, 0, mmRMI_UTCL1_CNTL2, 0x0003, 0x0002), SOC15_REG_GOLDEN_VALUE(GC, 0, mmSPI_CONFIG_CNTL_1, 0x000f, 0x01000107), SOC15_REG_GOLDEN_VALUE(GC, 0, mmTD_CNTL, 0x1800, 0x0800), - SOC15_REG_GOLDEN_VALUE(GC, 0, mmWD_UTCL1_CNTL, 0x0800, 0x0880), - SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_MEC1_F32_INT_DIS, 0x, 0x0800), - SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_MEC2_F32_INT_DIS, 0x, 0x0800), - SOC15_REG_GOLDEN_VALUE(GC, 0, mmCP_DEBUG, 0x, 0x8000) + SOC15_REG_GOLDEN_VALUE(GC, 0, mmWD_UTCL1_CNTL, 0x0800, 0x0880) }; static const struct soc15_reg_golden golden_settings_gc_9_0_vg20[] = -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 08/28] drm/bridge: tc358767: add bus flags
From: Tomi Valkeinen [ Upstream commit 4842379cbe6e851de914a7132f76f4e200b9a98b ] tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by: Tomi Valkeinen Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-2-tomi.valkei...@ti.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358767.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 8e28e738cb52..29a7e33e8ae0 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1195,6 +1195,10 @@ static int tc_bridge_attach(struct drm_bridge *bridge) drm_display_info_set_bus_formats(>connector.display_info, _format, 1); + tc->connector.display_info.bus_flags = + DRM_BUS_FLAG_DE_HIGH | + DRM_BUS_FLAG_PIXDATA_NEGEDGE | + DRM_BUS_FLAG_SYNC_NEGEDGE; drm_connector_attach_encoder(>connector, tc->bridge.encoder); return 0; -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 37/42] drm/nouveau/falcon: avoid touching registers if engine is off
From: Ilia Mirkin
[ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
index 816ccaedfc73..8675613e142b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
@@ -107,8 +108,10 @@ nvkm_falcon_fini(struct nvkm_engine *engine, bool suspend)
}
}
- nvkm_mask(device, base + 0x048, 0x0003, 0x);
- nvkm_wr32(device, base + 0x014, 0x);
+ if (nvkm_mc_enabled(device, engine->subdev.index)) {
+ nvkm_mask(device, base + 0x048, 0x0003, 0x);
+ nvkm_wr32(device, base + 0x014, 0x);
+ }
return 0;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 28/42] drm/amdgpu: disable system memory page tables for now
From: Christian König [ Upstream commit 1c1eba86339c8517814863bc7dd21e2661a84e77 ] We hit a problem with IOMMU with that. Disable until we have time to debug further. Signed-off-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 0877ff9a9594..8c9abaa7601a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -850,9 +850,6 @@ static void amdgpu_vm_bo_param(struct amdgpu_device *adev, struct amdgpu_vm *vm, bp->size = amdgpu_vm_bo_size(adev, level); bp->byte_align = AMDGPU_GPU_PAGE_SIZE; bp->domain = AMDGPU_GEM_DOMAIN_VRAM; - if (bp->size <= PAGE_SIZE && adev->asic_type >= CHIP_VEGA10 && - adev->flags & AMD_IS_APU) - bp->domain |= AMDGPU_GEM_DOMAIN_GTT; bp->domain = amdgpu_bo_get_preferred_pin_domain(adev, bp->domain); bp->flags = AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS | AMDGPU_GEM_CREATE_CPU_GTT_USWC; -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 36/42] drm/nouveau: Don't disable polling in fallback mode
From: Takashi Iwai
[ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ]
When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling. Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.
Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan
control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
Reported-by: Thomas Blume
Signed-off-by: Takashi Iwai
Reviewed-by: Martin Peres
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index 3695cde669f8..07914e36939e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -132,11 +132,12 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
duty = nvkm_therm_update_linear(therm);
break;
case NVBIOS_THERM_FAN_OTHER:
- if (therm->cstate)
+ if (therm->cstate) {
duty = therm->cstate;
- else
+ poll = false;
+ } else {
duty = nvkm_therm_update_linear_fallback(therm);
- poll = false;
+ }
break;
}
immd = false;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 09/28] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
From: Tomi Valkeinen
[ Upstream commit adf4109896bbee27fd2ac3b48d22d6a0062fe517 ]
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-3-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 29a7e33e8ae0..5f0a666db2fd 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -142,6 +142,8 @@
#define DP0_LTLOOPCTRL 0x06d8
#define DP0_SNKLTCTRL 0x06e4
+#define DP1_SRCCTRL0x07a0
+
/* PHY */
#define DP_PHY_CTRL0x0800
#define DP_PHY_RST BIT(28) /* DP PHY Global Soft Reset */
@@ -150,6 +152,7 @@
#define PHY_M1_RST BIT(12) /* Reset PHY1 Main Channel */
#define PHY_RDYBIT(16) /* PHY Main Channels
Ready */
#define PHY_M0_RST BIT(8) /* Reset PHY0 Main Channel */
+#define PHY_2LANE BIT(2) /* PHY Enable 2 lanes */
#define PHY_A0_EN BIT(1) /* PHY Aux Channel0 Enable */
#define PHY_M0_EN BIT(0) /* PHY Main Channel0 Enable */
@@ -564,7 +567,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
+ tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -834,7 +837,7 @@ static int tc_main_link_setup(struct tc_data *tc)
DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
/* from excel file - DP1_SrcCtrl */
- tc_write(0x07a0, 0x3083);
+ tc_write(DP1_SRCCTRL, 0x3083);
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -855,8 +858,9 @@ static int tc_main_link_setup(struct tc_data *tc)
}
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
+
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 17/42] drm/bridge: tc358767: fix single lane configuration
From: Tomi Valkeinen
[ Upstream commit 4d9d54a730434cc068dd3515ba6116697196f77b ]
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-4-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5f0a666db2fd..fee53422c31f 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -543,6 +543,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
unsigned long rate;
u32 value;
int ret;
+ u32 dp_phy_ctrl;
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -567,7 +568,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
+ tc_write(DP_PHY_CTRL, dp_phy_ctrl);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -860,7 +864,9 @@ static int tc_main_link_setup(struct tc_data *tc)
tc_write(SYS_PLLPARAM, value);
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.20 18/42] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
From: Tomi Valkeinen
[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ]
Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
This patch changes the configuration as follows:
Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.
DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkei...@ti.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index fee53422c31f..ab299f4debfa 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -836,12 +836,11 @@ static int tc_main_link_setup(struct tc_data *tc)
if (!tc->mode)
return -EINVAL;
- /* from excel file - DP0_SrcCtrl */
- tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
-DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
-DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
- /* from excel file - DP1_SrcCtrl */
- tc_write(DP1_SRCCTRL, 0x3083);
+ tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
+ /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
+ tc_write(DP1_SRCCTRL,
+(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
+((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #4 from acollie...@gmail.com --- Attached the logs, hopefully those help! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #3 from acollie...@gmail.com --- Created attachment 281083 --> https://bugzilla.kernel.org/attachment.cgi?id=281083=edit dmesg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202533] DVI Monitors blank in 4.20-6 kernel
https://bugzilla.kernel.org/show_bug.cgi?id=202533 --- Comment #2 from acollie...@gmail.com --- Created attachment 281081 --> https://bugzilla.kernel.org/attachment.cgi?id=281081=edit xorg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v12 24/38] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> Request ME FW to start the HDCP2.2 session for an intel port.
> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
> to ME FW.
>
> On Success, ME FW will start a HDCP2.2 session for the port and provides the
> content for HDCP2.2 AKE_Init message.
>
> v2: Rebased.
> v3:
> cldev is add as a separate parameter [Tomas]
> Redundant comment and typecast are removed [Tomas]
> v4:
> %zd is used for size [Alexander]
> %s/return -1/return -EIO [Alexander]
> Spellings in commit msg is fixed [Uma]
> v5: Rebased.
> v6:
> Collected the rb-ed by.
> Realigning the patches in the series.
> v7:
> Adjust to the new mei interface.
> Fix for kdoc.
> v8:
> K-Doc Addition.
> memcpy for const length.
> v9:
> s/mei_hdcp_ddi/mei_fw_ddi
> s/i915_port/mei_i915_port [Tomas]
> renamed func as mei_hdcp_* [Tomas]
> Instead of macro, inline func for ddi index is used. [Tomas]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> Acked-by: Tomas Winkler
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 89
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 23 +++
> 2 files changed, 112 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index 8df069c1b0cc..56d3ac1e6831 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,95 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +
> +#include "mei_hdcp.h"
> +
> +static inline u8 mei_get_ddi_index(short int port) {
> + enum mei_i915_port i915_port = (enum mei_i915_port)port;
> +
> + return (u8)(i915_port == PORT_A ? MEI_DDI_A : i915_port); }
> +
Still the same code I haven't Acked that patch.
Thanks
Tomas
> +/**
> + * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in
> +ME FW
> + * @dev: device corresponding to the mei_cl_device
> + * @hdcp_data: Intel HW specific hdcp data
> + * @ake_data: AKE_Init msg output.
> + *
> + * Return: 0 on Success, <0 on Failure.
> + */
> +static int
> +mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> + struct hdcp2_ake_init *ake_data)
> +{
> + struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
> + struct wired_cmd_initiate_hdcp2_session_out
> + session_init_out = { { 0 } };
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !data || !ake_data)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + session_init_in.header.api_version = HDCP_API_VERSION;
> + session_init_in.header.command_id =
> WIRED_INITIATE_HDCP2_SESSION;
> + session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
> + session_init_in.header.buffer_len =
> +
> WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> +
> + session_init_in.port.integrated_port_type = data->port_type;
> + session_init_in.port.physical_port = mei_get_ddi_index(data->port);
> + session_init_in.protocol = data->protocol;
> +
> + byte = mei_cldev_send(cldev, (u8 *)_init_in,
> + sizeof(session_init_in));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + byte = mei_cldev_recv(cldev, (u8 *)_init_out,
> + sizeof(session_init_out));
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> + dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> + WIRED_INITIATE_HDCP2_SESSION,
> + session_init_out.header.status);
> + return -EIO;
> + }
> +
> + ake_data->msg_id = HDCP_2_2_AKE_INIT;
> + ake_data->tx_caps = session_init_out.tx_caps;
> + memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
> +
> + return 0;
> +}
> +
> +static __attribute__((unused))
> +struct i915_hdcp_component_ops mei_hdcp_ops = {
> + .owner = THIS_MODULE,
> + .initiate_hdcp2_session = mei_hdcp_initiate_session,
> + .verify_receiver_cert_prepare_km = NULL,
> + .verify_hprime = NULL,
> + .store_pairing_info = NULL,
> + .initiate_locality_check = NULL,
> + .verify_lprime = NULL,
> + .get_session_key = NULL,
> + .repeater_check_flow_prepare_ack = NULL,
> + .verify_mprime = NULL,
> + .enable_hdcp_authentication = NULL,
> + .close_hdcp_session = NULL,
> +};
>
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id) diff --git
> a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
> index 582a7e27ae29..28686f2ae88c 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.h
> +++
Re: [PATCH v3 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
On 2/8/19 4:20 PM, Tim Harvey wrote: On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam wrote: if (inf == outf) params = _csc_identity; else if (inf == IPUV3_COLORSPACE_YUV) - params = _csc_ycbcr2rgb_bt601; + params = _csc_ycbcr2rgb; Steve, compile issue... params = params_yuv2rgb; else - params = _csc_rgb2ycbcr_bt601; + params = _csc_rgb2ycbcr; params = params_rgb2yuv; Wow, did I not even compile test that? Must be my head cold :-/ Sending v4. But, I'm still failing when using the mem2mem element (gst-launch-1.0 v4l2src device=/dev/video4 ! v4l2video8convert output-io-mode=dmabuf-import ! fbdevsink) with 'Unsupported YCbCr encoding' because of inf=IPU_COLORSPACE_YCBCR outf=IPU_COLORSPACE_RGB and a seemingly unset encoding being passed in. It looks like maybe something in the mem2mem driver isn't defaulting encoding. The call path is (v4l2_m2m_streamon -> device_run -> ipu_image_convert_queue -> convert_start -> ipu_ic_task_init_rsc -> init_csc). Looking at v7 of the mem2mem driver, it will set ycbcr_enc at the output side to V4L2_YCBCR_ENC_DEFAULT if colorspace is default. So colorspace will need to be set to something non-default in addition to setting ycbcr_enc, at the output side. I don't know whether gstreamer v4l2videoNconvertelement will do this, but you could hack the driver for now to get around it, and let Philipp know this may need a workaround in mem2mem for v8. Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
* Tomi Valkeinen [190208 09:11]: > Looks fine to me and works on panda. I'll queue this to the next merge > window (I presume no rush to get this into the current -rcs, it's a bit > late). OK good to hear panda works too, my panda is in my rack.. This one has been broken for a long time and nobody noticed, so next is just fine with me. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 3ef61f0b509b..e459615a49a1 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -244,16 +244,12 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
- if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
+ if (inf == outf)
+ params = _csc_identity;
+ else if (inf == IPUV3_COLORSPACE_YUV)
params = _csc_ycbcr2rgb_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
+ else
params = _csc_rgb2ycbcr_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_identity;
- else {
- dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
- return -EINVAL;
- }
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
since if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
---
drivers/gpu/ipu-v3/ipu-ic.c | 71 +++--
drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
include/video/imx-ipu-v3.h | 5 +-
4 files changed, 71 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index e459615a49a1..0d57ca7ba18e 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -212,6 +212,23 @@ static const struct ic_csc_params ic_csc_identity = {
.scale = 2,
};
+/*
+ * BT.709 encoding from RGB full range to YUV limited range:
+ *
+ * Y = R * .2126 + G * .7152 + B * .0722;
+ * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
+ * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
+ */
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
+ .coeff = {
+ { 54, 183, 18 },
+ { 483, 413, 128 },
+ { 128, 396, 500 },
+ },
+ .offset = { 0, 512, 512 },
+ .scale = 1,
+};
+
/*
* Inverse BT.601 encoding from YUV limited range to RGB full range:
*
@@ -229,12 +246,31 @@ static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601
= {
.scale = 2,
};
+/*
+ * Inverse BT.709 encoding from YUV limited range to RGB full range:
+ *
+ * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
+ * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
+ * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
+ */
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
+ .coeff = {
+ { 128, 0, 202 },
+ { 128, 488, 452 },
+ { 128, 238, 0 },
+ },
+ .offset = { -435, 136, -507 },
+ .scale = 2,
+};
+
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
+ const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
const struct ic_csc_params *params;
u32 __iomem *base;
const u16 (*c)[3];
@@ -244,12 +280,30 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
+ switch (encoding) {
+ case V4L2_YCBCR_ENC_601:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt601;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt709;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt709;
+ break;
+ default:
+ if (inf != outf) {
+ dev_err(priv->ipu->dev,
+ "Unsupported YCbCr encoding\n");
+ return -EINVAL;
+ }
+ break;
+ }
+
if (inf == outf)
params = _csc_identity;
else if (inf == IPUV3_COLORSPACE_YUV)
- params = _csc_ycbcr2rgb_bt601;
+ params = _csc_ycbcr2rgb;
else
- params = _csc_rgb2ycbcr_bt601;
+ params = _csc_rgb2ycbcr;
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
@@ -390,6 +444,7 @@ EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
int ipu_ic_task_graphics_init(struct ipu_ic *ic,
enum ipu_color_space in_g_cs,
+ enum v4l2_ycbcr_encoding encoding,
bool galpha_en, u32 galpha,
bool colorkey_en, u32 colorkey)
{
@@ -408,7 +463,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
if (!(ic_conf & ic->bit->ic_conf_csc1_en)) {
/* need transparent CSC1 conversion */
ret = init_csc(ic, IPUV3_COLORSPACE_RGB,
- IPUV3_COLORSPACE_RGB, 0);
+ IPUV3_COLORSPACE_RGB, encoding, 0);
if (ret)
goto unlock;
}
@@ -416,7 +471,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
ic->g_in_cs = in_g_cs;
if (ic->g_in_cs != ic->out_cs) {
- ret = init_csc(ic, ic->g_in_cs, ic->out_cs, 1);
+ ret = init_csc(ic, ic->g_in_cs, ic->out_cs, encoding, 1);
if (ret)
goto unlock;
}
@@ -450,6 +505,7 @@ int ipu_ic_task_init_rsc(struct ipu_ic *ic,
int out_width, int out_height,
enum
Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel
On Tue, Dec 11, 2018 at 9:02 AM Anton Ivanov
wrote:
>
>
> On 12/11/18 2:41 PM, Steven Rostedt wrote:
> > On Tue, 11 Dec 2018 15:09:26 +0100
> > Petr Mladek wrote:
> >
> >>> We have liburcu already, which is good. The main sticking points are:
> >>>
> >>> - printk has started adding a lot of %pX enhancements which printf
> >>> obviously doesn't know about.
> >> I wonder how big problem it is and if it is worth using another
> >> approach.
> > No, please do not change the %pX approach.
> >
> >> An alternative would be to replace them with helper functions
> >> the would produce the same string. The meaning would be easier
> >> to understand. But concatenating with the surrounding text
> >> would be less elegant. People might start using pr_cont()
> >> that is problematic (mixed lines).
> >>
> >> Also the %pX formats are mostly used to print context of some
> >> structures. Even the helper functions would need some maintenance
> >> to keep them compatible.
> >>
> >> BTW: The printk() feature has been introduced 10 years ago by
> >> the commit 4d8a743cdd2690c0bc8 ("vsprintf: add infrastructure
> >> support for extended '%p' specifiers").
> > trace-cmd and perf know about most of the %pX data and how to read it.
> > Perhaps we can extend the libtraceevent library to export a generic way
> > to read data from printk() output for other tools to use.
>
> Going back for a second to using UML for this. UML console at present is
> interrupt driven - it emulates serial IO using several different
> back-ends (file descriptors, xterm or actual tty/ptys). Epoll events on
> the host side are used to trigger the UML interrupts - both read and write.
>
> This works OK for normal use, but may result in all kinds of interesting
> false positives/false negatives when UML is used to run unit tests
> against a change which changes interrupt behavior.
>
> IMO it may be useful to consider some alternatives specifically for unit
> test coverage purposes where printk and/or the whole console output
> altogether bypass some of the IRQ driven semantics.
Whoops, sorry, didn't see your comment before I went on vacation.
I completely agree. It is also annoying when trying to test other
really low level parts of the kernel. I would really like to get KUnit
to the point where it does not have any dependencies on anything in
the kernel, but that is very challenging for many reasons. This
loosely relates to what Luis, myself, and others have talked about in
other threads about having a stricter notion of code dependencies in
the kernel. Thinking about it now, I suspect it might be easier to
limit KUnit's dependency on kernel infrastructure first; that could
kind of motivate the later work.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 14/19] Documentation: kunit: add documentation for KUnit
On Thu, Dec 6, 2018 at 4:16 AM Kieran Bingham wrote: > > Hi Brendan, > > On 03/12/2018 23:53, Brendan Higgins wrote: > > On Thu, Nov 29, 2018 at 7:45 PM Luis Chamberlain wrote: > >> > >> On Thu, Nov 29, 2018 at 01:56:37PM +, Kieran Bingham wrote: > >>> Hi Brendan, > >>> > >>> Please excuse the top posting, but I'm replying here as I'm following > >>> the section "Creating a kunitconfig" in Documentation/kunit/start.rst. > >>> > >>> Could the three line kunitconfig file live under say > >>>arch/um/configs/kunit_defconfig? > > > Further consideration to this topic - I mentioned putting it in > arch/um/configs > > - but I think this is wrong. > > We now have a location for config-fragments, which is essentially what > this is, under kernel/configs > > So perhaps an addition as : > > kernel/configs/kunit.config > > Would be more appropriate - and less (UM) architecture specific. Sorry for the long radio silence. I just got around to doing this and I found that there are some configs that are desirable to have when running KUnit under x86 in a VM, but not UML. So should we have one that goes in with config-fragments and others that go into architectures? Another idea, it would be nice to have a KUnit config that runs all known tests (this probably won't work in practice once we start testing mutually exclusive things or things with lots of ifdeffery, but it probably something we should try to maintain as best as we can?); this probably shouldn't go in with the fragments, right? I will be sending another revision out soon, but I figured I might be able to catch you before I did so. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 3ef61f0b509b..e459615a49a1 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -244,16 +244,12 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
- if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
+ if (inf == outf)
+ params = _csc_identity;
+ else if (inf == IPUV3_COLORSPACE_YUV)
params = _csc_ycbcr2rgb_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
+ else
params = _csc_rgb2ycbcr_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_identity;
- else {
- dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
- return -EINVAL;
- }
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
From: Steve Longerbeam
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
since if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
---
drivers/gpu/ipu-v3/ipu-ic.c | 71 +++--
drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
include/video/imx-ipu-v3.h | 5 +-
4 files changed, 71 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index e459615a49a1..0d57ca7ba18e 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -212,6 +212,23 @@ static const struct ic_csc_params ic_csc_identity = {
.scale = 2,
};
+/*
+ * BT.709 encoding from RGB full range to YUV limited range:
+ *
+ * Y = R * .2126 + G * .7152 + B * .0722;
+ * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
+ * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
+ */
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
+ .coeff = {
+ { 54, 183, 18 },
+ { 483, 413, 128 },
+ { 128, 396, 500 },
+ },
+ .offset = { 0, 512, 512 },
+ .scale = 1,
+};
+
/*
* Inverse BT.601 encoding from YUV limited range to RGB full range:
*
@@ -229,12 +246,31 @@ static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601
= {
.scale = 2,
};
+/*
+ * Inverse BT.709 encoding from YUV limited range to RGB full range:
+ *
+ * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
+ * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
+ * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
+ */
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
+ .coeff = {
+ { 128, 0, 202 },
+ { 128, 488, 452 },
+ { 128, 238, 0 },
+ },
+ .offset = { -435, 136, -507 },
+ .scale = 2,
+};
+
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
+ const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
const struct ic_csc_params *params;
u32 __iomem *base;
const u16 (*c)[3];
@@ -244,12 +280,30 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
+ switch (encoding) {
+ case V4L2_YCBCR_ENC_601:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt601;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt709;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt709;
+ break;
+ default:
+ if (inf != outf) {
+ dev_err(priv->ipu->dev,
+ "Unsupported YCbCr encoding\n");
+ return -EINVAL;
+ }
+ break;
+ }
+
if (inf == outf)
params = _csc_identity;
else if (inf == IPUV3_COLORSPACE_YUV)
- params = _csc_ycbcr2rgb_bt601;
+ params = _csc_ycbcr2rgb;
else
- params = _csc_rgb2ycbcr_bt601;
+ params = _csc_rgb2ycbcr;
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
@@ -390,6 +444,7 @@ EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
int ipu_ic_task_graphics_init(struct ipu_ic *ic,
enum ipu_color_space in_g_cs,
+ enum v4l2_ycbcr_encoding encoding,
bool galpha_en, u32 galpha,
bool colorkey_en, u32 colorkey)
{
@@ -408,7 +463,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
if (!(ic_conf & ic->bit->ic_conf_csc1_en)) {
/* need transparent CSC1 conversion */
ret = init_csc(ic, IPUV3_COLORSPACE_RGB,
- IPUV3_COLORSPACE_RGB, 0);
+ IPUV3_COLORSPACE_RGB, encoding, 0);
if (ret)
goto unlock;
}
@@ -416,7 +471,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
ic->g_in_cs = in_g_cs;
if (ic->g_in_cs != ic->out_cs) {
- ret = init_csc(ic, ic->g_in_cs, ic->out_cs, 1);
+ ret = init_csc(ic, ic->g_in_cs, ic->out_cs, encoding, 1);
if (ret)
goto unlock;
}
@@ -450,6 +505,7 @@ int ipu_ic_task_init_rsc(struct ipu_ic *ic,
int out_width, int out_height,
[PATCH v2 1/4] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
From: Steve Longerbeam
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
matrix, so rename to ic_csc_identity. No functional changes.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
---
drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 594c3cbc8291..3ef61f0b509b 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -183,11 +183,13 @@ struct ic_csc_params {
};
/*
+ * BT.601 encoding from RGB full range to YUV limited range:
+ *
* Y = R * .299 + G * .587 + B * .114;
* U = R * -.169 + G * -.332 + B * .500 + 128.;
* V = R * .500 + G * -.419 + B * -.0813 + 128.;
*/
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 = {
.coeff = {
{ 77, 150, 29 },
{ 469, 427, 128 },
@@ -197,8 +199,11 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr = {
.scale = 1,
};
-/* transparent RGB->RGB matrix for graphics combining */
-static const struct ic_csc_params ic_csc_rgb2rgb = {
+/*
+ * identity matrix, used for transparent RGB->RGB graphics
+ * combining.
+ */
+static const struct ic_csc_params ic_csc_identity = {
.coeff = {
{ 128, 0, 0 },
{ 0, 128, 0 },
@@ -208,11 +213,13 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
};
/*
+ * Inverse BT.601 encoding from YUV limited range to RGB full range:
+ *
* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
* G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
* B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
*/
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601 = {
.coeff = {
{ 149, 0, 204 },
{ 149, 462, 408 },
@@ -238,11 +245,11 @@ static int init_csc(struct ipu_ic *ic,
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb;
+ params = _csc_ycbcr2rgb_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr;
+ params = _csc_rgb2ycbcr_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_rgb2rgb;
+ params = _csc_identity;
else {
dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
return -EINVAL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
matrix, so rename to ic_csc_identity. No functional changes.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
---
drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 594c3cbc8291..3ef61f0b509b 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -183,11 +183,13 @@ struct ic_csc_params {
};
/*
+ * BT.601 encoding from RGB full range to YUV limited range:
+ *
* Y = R * .299 + G * .587 + B * .114;
* U = R * -.169 + G * -.332 + B * .500 + 128.;
* V = R * .500 + G * -.419 + B * -.0813 + 128.;
*/
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 = {
.coeff = {
{ 77, 150, 29 },
{ 469, 427, 128 },
@@ -197,8 +199,11 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr = {
.scale = 1,
};
-/* transparent RGB->RGB matrix for graphics combining */
-static const struct ic_csc_params ic_csc_rgb2rgb = {
+/*
+ * identity matrix, used for transparent RGB->RGB graphics
+ * combining.
+ */
+static const struct ic_csc_params ic_csc_identity = {
.coeff = {
{ 128, 0, 0 },
{ 0, 128, 0 },
@@ -208,11 +213,13 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
};
/*
+ * Inverse BT.601 encoding from YUV limited range to RGB full range:
+ *
* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
* G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
* B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
*/
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601 = {
.coeff = {
{ 149, 0, 204 },
{ 149, 462, 408 },
@@ -238,11 +245,11 @@ static int init_csc(struct ipu_ic *ic,
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb;
+ params = _csc_ycbcr2rgb_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr;
+ params = _csc_rgb2ycbcr_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_rgb2rgb;
+ params = _csc_identity;
else {
dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
return -EINVAL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
since if inf == outf, the identity matrix can be used. Reported
by Tim Harvey.
---
drivers/gpu/ipu-v3/ipu-ic.c | 71 +++--
drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
include/video/imx-ipu-v3.h | 5 +-
4 files changed, 71 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index e459615a49a1..c5f83d7e357f 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -212,6 +212,23 @@ static const struct ic_csc_params ic_csc_identity = {
.scale = 2,
};
+/*
+ * BT.709 encoding from RGB full range to YUV limited range:
+ *
+ * Y = R * .2126 + G * .7152 + B * .0722;
+ * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
+ * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
+ */
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
+ .coeff = {
+ { 54, 183, 18 },
+ { 483, 413, 128 },
+ { 128, 396, 500 },
+ },
+ .offset = { 0, 512, 512 },
+ .scale = 1,
+};
+
/*
* Inverse BT.601 encoding from YUV limited range to RGB full range:
*
@@ -229,12 +246,31 @@ static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601
= {
.scale = 2,
};
+/*
+ * Inverse BT.709 encoding from YUV limited range to RGB full range:
+ *
+ * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
+ * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
+ * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
+ */
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
+ .coeff = {
+ { 128, 0, 202 },
+ { 128, 488, 452 },
+ { 128, 238, 0 },
+ },
+ .offset = { -435, 136, -507 },
+ .scale = 2,
+};
+
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
+ const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
const struct ic_csc_params *params;
u32 __iomem *base;
const u16 (*c)[3];
@@ -244,12 +280,30 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
+ switch (encoding) {
+ case V4L2_YCBCR_ENC_601:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt601;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt709;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt709;
+ break;
+ default:
+ if (inf != outf) {
+ dev_err(priv->ipu->dev,
+ "Unsupported YCbCr encoding\n");
+ return -EINVAL;
+ }
+ break;
+ }
+
if (inf == outf)
params = _csc_identity;
else if (inf == IPUV3_COLORSPACE_YUV)
- params = _csc_ycbcr2rgb_bt601;
+ params = params_yuv2rgb;
else
- params = _csc_rgb2ycbcr_bt601;
+ params = params_rgb2yuv;
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
@@ -390,6 +444,7 @@ EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
int ipu_ic_task_graphics_init(struct ipu_ic *ic,
enum ipu_color_space in_g_cs,
+ enum v4l2_ycbcr_encoding encoding,
bool galpha_en, u32 galpha,
bool colorkey_en, u32 colorkey)
{
@@ -408,7 +463,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
if (!(ic_conf & ic->bit->ic_conf_csc1_en)) {
/* need transparent CSC1 conversion */
ret = init_csc(ic, IPUV3_COLORSPACE_RGB,
- IPUV3_COLORSPACE_RGB, 0);
+ IPUV3_COLORSPACE_RGB, encoding, 0);
if (ret)
goto unlock;
}
@@ -416,7 +471,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
ic->g_in_cs = in_g_cs;
if (ic->g_in_cs != ic->out_cs) {
- ret = init_csc(ic, ic->g_in_cs, ic->out_cs, 1);
+ ret = init_csc(ic, ic->g_in_cs, ic->out_cs, encoding, 1);
if (ret)
goto unlock;
}
@@ -450,6 +505,7 @@ int ipu_ic_task_init_rsc(struct ipu_ic *ic,
int
Re: [PATCH 2/3] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
On 2/8/19 8:24 AM, Tim Harvey wrote:
On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam wrote:
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 67 ++---
drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
include/video/imx-ipu-v3.h | 5 +-
4 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 35ae86ff0585..63362b4fff81 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -199,6 +199,23 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 =
{
.scale = 1,
};
+/*
+ * BT.709 encoding from RGB full range to YUV limited range:
+ *
+ * Y = R * .2126 + G * .7152 + B * .0722;
+ * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
+ * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
+ */
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
+ .coeff = {
+ { 54, 183, 18 },
+ { 483, 413, 128 },
+ { 128, 396, 500 },
+ },
+ .offset = { 0, 512, 512 },
+ .scale = 1,
+};
+
/* transparent RGB->RGB matrix for graphics combining */
static const struct ic_csc_params ic_csc_rgb2rgb = {
.coeff = {
@@ -226,12 +243,31 @@ static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601
= {
.scale = 2,
};
+/*
+ * Inverse BT.709 encoding from YUV limited range to RGB full range:
+ *
+ * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
+ * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
+ * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
+ */
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
+ .coeff = {
+ { 128, 0, 202 },
+ { 128, 488, 452 },
+ { 128, 238, 0 },
+ },
+ .offset = { -435, 136, -507 },
+ .scale = 2,
+};
+
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
+ const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
const struct ic_csc_params *params;
u32 __iomem *base;
const u16 (*c)[3];
@@ -241,10 +277,24 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
+ switch (encoding) {
+ case V4L2_YCBCR_ENC_601:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt601;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt709;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt709;
+ break;
+ default:
+ dev_err(priv->ipu->dev, "Unsupported YCbCr encoding\n");
+ return -EINVAL;
+ }
+
Steve,
This will fail for RGB to RGB with 'Unsupported YCbCr encoding. We
need to account for the RGB->RGB case.
How about something like:
Thanks for reporting Tim
I rather keep the check for supported encoding, and instead get rid of
"Unsupported color space conversion" error, because that is the YUV->YUV
case which can be allowed using the identity matrix.
Steve
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
- const struct ic_csc_params *params;
+ const struct ic_csc_params *params = NULL;
u32 __iomem *base;
const u16 (*c)[3];
const u16 *a;
@@ -241,13 +276,18 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
- if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr_bt601;
+ if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB) {
+ params = (encoding == V4L2_YCBCR_ENC_601) ?
+ _csc_ycbcr2rgb_bt601 : _csc_ycbcr2rgb_bt709;
+ }
+ else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV) {
+ params = (encoding == V4L2_YCBCR_ENC_601) ?
+ _csc_rgb2ycbcr_bt601 : _csc_rgb2ycbcr_bt709;
+ }
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
params =
Re: [PATCH v2 3/3] phy: Add driver for mixel dphy found on imx8
Hi Guido On Vi, 2019-02-08 at 12:40 +0100, Guido Günther wrote: > Hi Robert, > On Wed, Feb 06, 2019 at 03:28:07PM +, Robert Chiras wrote: > > > > Hi Guido, > > > > Thanks for picking this up. It's interesting to see that a lot has > > changed in the PHY API and the phy can be now configured through > > the > > API instead of exported function as I did in the NXP tree. > > > > I was going through your implementation and I noticed you also > > added > > the phy_ref clock to this driver too. This is good, since the DPHY > > needs this clock, but I have a question related to the other > > clocks: > > According to the Northwest Logic reference manual (the DSI host > > that > > uses this DPHY), the host relies on the TX clock in order to > > configure > > the DPHY. Is this driver relying on it's user to also enable the TX > > clock? > Yes, I think that would be best. In fact due to lack of reference > manuals for nwl and mixel I didn't even know exactly which clocks > needed > to be on already so I currently set for enabling this after the nwl > clocks. Are these manuals available publicly somewhere, I couldn't > find > them? That's OK, I guess. Regarding the manuals: we have them from the vendor so I can't share them. > > > > > Also: did you test this driver? Because I have a version of the > > patches > > from NXP tree rebased on top of latest linux-next and I have a > > working > Hmm...could you (maybe off list) send the boot output with DEBUG 1 > at the top of the driver and drm.debug=0x2f on the kernel command > line? > Maybe I can spot something. Eventually I got it working. On i.MX8MQ there is a System Reset Controller that controls the clocks on each individual block. For some reason, before asserting the MIPI clock domain in this SRC, a delay is needed (right now, the hack is a sleep). Probably there is a component that is not ready yet. Right now I am trying to figure out which one is it and how can I wait for it. > > > > > version of eLCDIF with Raydium RM67191 DSI panel on mScale850D > > (i.MX8MQ). And I tried using this driver but there is no signal on > > the > > screen, even through the register values are all identical. Next, > > I'll > > try to debug why isn't this working on my setup. > I'm testing this on the Librem 5 devkit with a rockchip panel atm > using > DCSS not eLCDIF though. My plan is to move to the NXP evk in the not > so > far future to make this easier to reproduce. Good to know. Currently I am working on the eLCDIF pipeline on 850D to make it ready for upstream. Since you took my DPHY driver and submitted upstream in a better shape, I will make use of it. > > > > > Other than the above questions, I have some suggestions inline. > > > > Best regards, > > Robert > > > > > > On Vi, 2019-02-01 at 09:49 +0100, Guido Günther wrote: > > > > > > This adds support for the Mixel DPHY as found on i.MX8 CPUs but > > > since > > > this is an IP core it will likely be found on others in the > > > future. > > > So > > > instead of adding this to the nwl host driver make it a generic > > > PHY > > > driver. > > > > > > The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP > > > can > > > be > > > added once the necessary system controller bits are in via > > > mixel_dphy_devdata. > > > > > > Signed-off-by: Guido Günther > > > --- > > > drivers/phy/freescale/Kconfig | 9 + > > > drivers/phy/freescale/Makefile| 1 + > > > .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 494 > > > ++ > > > 3 files changed, 504 insertions(+) > > > create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi- > > > dphy.c > > > > > > diff --git a/drivers/phy/freescale/Kconfig > > > b/drivers/phy/freescale/Kconfig > > > index 832670b4952b..43a5ca25d44b 100644 > > > --- a/drivers/phy/freescale/Kconfig > > > +++ b/drivers/phy/freescale/Kconfig > > > @@ -3,3 +3,12 @@ config PHY_FSL_IMX8MQ_USB > > > depends on OF && HAS_IOMEM > > > select GENERIC_PHY > > > default ARCH_MXC && ARM64 > > > + > > > +config PHY_MIXEL_MIPI_DPHY > > > + tristate "Mixel MIPI DSI PHY support" > > > + depends on OF > > > + select GENERIC_PHY > > > + select GENERIC_PHY_MIPI_DPHY > > > + help > > > + Enable this to add support for the Mixel DSI PHY as > > > found > > > + on NXP's i.MX8 family of SOCs. > > > diff --git a/drivers/phy/freescale/Makefile > > > b/drivers/phy/freescale/Makefile > > > index dc2b3f1f2f80..07491c926a2c 100644 > > > --- a/drivers/phy/freescale/Makefile > > > +++ b/drivers/phy/freescale/Makefile > > > @@ -1 +1,2 @@ > > > obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o > > > +obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi- > > > dphy.o > > > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c > > > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c > > > new file mode 100644 > > > index ..4b182f2eaa6e > > > --- /dev/null > > > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c > > >
Re: [PATCH v2] lib/scatterlist: Provide a DMA page iterator
On Thu, Feb 07, 2019 at 03:26:47PM -0700, Jason Gunthorpe wrote:
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 31786b200afc47..e84f6aaee778f0 100644
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -311,7 +311,13 @@ static dma_addr_t __vmw_piter_dma_addr(struct vmw_piter
> *viter)
>
> static dma_addr_t __vmw_piter_sg_addr(struct vmw_piter *viter)
> {
> - return sg_page_iter_dma_address(>iter);
> + /*
> + * FIXME: This driver wrongly mixes DMA and CPU SG list iteration and
> + * needs revision. See
> + * https://lore.kernel.org/lkml/20190104223531.ga1...@ziepe.ca/
> + */
> + return sg_page_iter_dma_address(
> + (struct sg_dma_page_iter *)>iter);
Occured to me this would be better written as:
return sg_page_iter_dma_address(
container_of(>iter, struct sg_dma_page_iter, base));
Since I think we are done with this now I'll fix it when I apply this
patch
Thanks for all the acks everyone
Regards,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
matrix, so rename to ic_csc_identity. No functional changes.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- rename ic_csc_rgb2rgb matrix to ic_csc_identity.
---
drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 594c3cbc8291..3ef61f0b509b 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -183,11 +183,13 @@ struct ic_csc_params {
};
/*
+ * BT.601 encoding from RGB full range to YUV limited range:
+ *
* Y = R * .299 + G * .587 + B * .114;
* U = R * -.169 + G * -.332 + B * .500 + 128.;
* V = R * .500 + G * -.419 + B * -.0813 + 128.;
*/
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 = {
.coeff = {
{ 77, 150, 29 },
{ 469, 427, 128 },
@@ -197,8 +199,11 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr = {
.scale = 1,
};
-/* transparent RGB->RGB matrix for graphics combining */
-static const struct ic_csc_params ic_csc_rgb2rgb = {
+/*
+ * identity matrix, used for transparent RGB->RGB graphics
+ * combining.
+ */
+static const struct ic_csc_params ic_csc_identity = {
.coeff = {
{ 128, 0, 0 },
{ 0, 128, 0 },
@@ -208,11 +213,13 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
};
/*
+ * Inverse BT.601 encoding from YUV limited range to RGB full range:
+ *
* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
* G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
* B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
*/
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601 = {
.coeff = {
{ 149, 0, 204 },
{ 149, 462, 408 },
@@ -238,11 +245,11 @@ static int init_csc(struct ipu_ic *ic,
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb;
+ params = _csc_ycbcr2rgb_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr;
+ params = _csc_rgb2ycbcr_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_rgb2rgb;
+ params = _csc_identity;
else {
dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
return -EINVAL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix
Simplify the selection of the Y'CbCr encoding matrices in init_csc().
A side-effect of this change is that init_csc() now allows YUV->YUV
using the identity matrix, intead of returning error.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 3ef61f0b509b..e459615a49a1 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -244,16 +244,12 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
- if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
+ if (inf == outf)
+ params = _csc_identity;
+ else if (inf == IPUV3_COLORSPACE_YUV)
params = _csc_ycbcr2rgb_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
+ else
params = _csc_rgb2ycbcr_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_identity;
- else {
- dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
- return -EINVAL;
- }
/* Cast to unsigned */
c = (const u16 (*)[3])params->coeff;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip
https://bugzilla.kernel.org/show_bug.cgi?id=202537 --- Comment #1 from Bernd Steinhauser (li...@bernd-steinhauser.de) --- Created attachment 281077 --> https://bugzilla.kernel.org/attachment.cgi?id=281077=edit kernel messages -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202537] New: amdgpu/DC failed to reserve new abo buffer before flip
https://bugzilla.kernel.org/show_bug.cgi?id=202537 Bug ID: 202537 Summary: amdgpu/DC failed to reserve new abo buffer before flip Product: Drivers Version: 2.5 Kernel Version: 4.20 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: li...@bernd-steinhauser.de Regression: No I've been using amdgpu for a long time on my Kaveri (A7800) now and it works fine. In the recent kernel versions (I think since 4.15), I've been trying it with the DC activated and apart from some initial issue with the HDMI connection it works fine and on 4.19 it's rock-stable. However, when I tried 4.20 (all versions from 4.20.1 to 4.20.6), I'm experiencing a regression. Initially, everything works fine, but at some point especially video-related things stop working properly. vaapi seems more affected than vdpau, but at some point they both fail to setup the hw decoding. (btw, vdpau for some reason can only run for one video at the time, while vaapi can do multiple ones, but that's an unrelated issue. It used to be different a year ago or even earlier on) I think the problems start when I see a lot of messages like this: [drm:amdgpu_display_crtc_page_flip_target] *ERROR* failed to reserve new abo buffer before flip However, after that I can continue for a bit, possibly with the restriction of not being able to use vaapi but vdpau. At some point, the system will fail due to a memory leak, at least the OOM is starting to kill stuff until it ends up killing the window manager and X11. Before that I get these messages: [drm:amdgpu_cs_ioctl] *ERROR* amdgpu_vm_validate_pt_bos() failed. [drm:amdgpu_cs_ioctl] *ERROR* Not enough memory for command submission! [drm:amdgpu_cs_ioctl] *ERROR* amdgpu_cs_list_validate(validated) failed. [drm:amdgpu_cs_ioctl] *ERROR* Not enough memory for command submission! [drm:amdgpu_cs_ioctl] *ERROR* amdgpu_vm_validate_pt_bos() failed. [drm:amdgpu_cs_ioctl] *ERROR* Not enough memory for command submission! --- snip --- (lots of oom activity) and finally: [TTM] Out of kernel memory [TTM] Out of kernel memory [TTM] Out of kernel memory [TTM] Out of kernel memory [TTM] Out of kernel memory [TTM] Out of kernel memory [TTM] Out of kernel memory amdgpu :00:01.0: (-12) failed to allocate kernel bo [drm:amdgpu_uvd_free_handles] *ERROR* Error destroying UVD -12! The latter one – I think – actually being the solution to the OOM problem, but I'm certainly not an expert. CPU/GPU is: vendor_id : AuthenticAMD cpu family : 21 model : 48 model name : AMD A10-7800 Radeon R7, 12 Compute Cores 4C+8G stepping: 1 microcode : 0x6003106 cpu MHz : 1592.730 cache size : 2048 KB Back to 4.19 for now since that runs beautifully. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109598] New Account
https://bugs.freedesktop.org/show_bug.cgi?id=109598 --- Comment #2 from Sam Ravnborg --- The command "gpg --keyserver subkeys.pgp.net --send-keys xxx" failed. Will try again later and update this bug when it succeeds -- 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 109598] New Account
https://bugs.freedesktop.org/show_bug.cgi?id=109598 --- Comment #1 from Sam Ravnborg --- Created attachment 143349 --> https://bugs.freedesktop.org/attachment.cgi?id=143349=edit ssh public key for s...@ravnborg.org -- 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 109598] New Account
https://bugs.freedesktop.org/show_bug.cgi?id=109598 Bug ID: 109598 Summary: New Account Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: s...@ravnborg.org Created attachment 143348 --> https://bugs.freedesktop.org/attachment.cgi?id=143348=edit gpg public key for s...@ravnborg.org Request for account that allows me in the end to get commit rights to drm-misc. Name: Sam Ravnborg Mail: s...@ravnborg.org preferred account name(s): sam, sam.ravnborg, samravnborg -- 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 46711] Monitor not turning on after DisplayPort re-plug in Xorg
https://bugs.freedesktop.org/show_bug.cgi?id=46711 --- Comment #24 from Luca --- I have the problem each time I turn off my monitor and then later turn it back on. The desktop does not come back. The monitor is a samsung Samsung S34J55W. # xrandr Screen 0: minimum 320 x 200, current 3440 x 1440, maximum 16384 x 16384 DisplayPort-0 connected primary 3440x1440+0+0 (normal left inverted right x axis y axis) 797mm x 333mm 3440x1440 59.97*+ 74.98 2560x1440 59.95 2560x1080 60.0059.94 1920x1080 60.0050.0059.94 1680x1050 59.95 1600x900 60.00 1280x1024 75.0260.02 1440x900 59.89 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0370.0760.00 832x624 74.55 800x600 72.1975.0060.3256.25 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 DisplayPort-1 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) # inxi -Fx System:Host: luca-pc Kernel: 4.19.16-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.2.1 Desktop: KDE Plasma 5.14.5 Distro: Manjaro Linux Machine: Type: Desktop Mobo: ASRock model: Z370 Extreme4 serial: UEFI: American Megatrends v: P1.80 date: 03/20/2018 CPU: Topology: 6-Core model: Intel Core i7-8700K bits: 64 type: MT MCP arch: Kaby Lake rev: A L2 cache: 12.0 MiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 88728 Speed: 800 MHz min/max: 800/4700 MHz Core speeds (MHz): 1: 799 2: 800 3: 800 4: 800 5: 801 6: 800 7: 801 8: 800 9: 800 10: 800 11: 800 12: 800 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Pitcairn XT [Radeon HD 7870 GHz Edition] vendor: Gigabyte driver: radeon v: kernel bus ID: 01:00.0 Display: x11 server: X.Org 1.20.3 driver: ati,radeon unloaded: modesetting resolution: 3440x1440~60Hz OpenGL: renderer: AMD PITCAIRN (DRM 2.50.0 4.19.16-1-MANJARO LLVM 7.0.1) v: 4.5 Mesa 18.3.2 direct render: Yes Audio: Device-1: Intel 200 Series PCH HD Audio vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:1f.3 Device-2: AMD Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] vendor: Gigabyte driver: snd_hda_intel v: kernel bus ID: 01:00.1 Device-3: Logitech Webcam C210 type: USB driver: snd-usb-audio,uvcvideo bus ID: 1-8:3 Sound Server: ALSA v: k4.19.16-1-MANJARO Network: Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: 3.2.6-k port: f000 bus ID: 00:1f.6 IF: enp0s31f6 state: up speed: 100 Mbps duplex: half mac: Drives:Local Storage: total: 1.14 TiB used: 408.99 GiB (35.1%) ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 960 EVO 250GB size: 232.89 GiB ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 960 EVO 500GB size: 465.76 GiB ID-3: /dev/sda vendor: Samsung model: HD103SJ size: 931.51 GiB Partition: ID-1: / size: 193.99 GiB used: 85.41 GiB (44.0%) fs: ext4 dev: /dev/nvme0n1p2 ID-2: swap-1 size: 34.49 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p3 Sensors: System Temperatures: cpu: 30.0 C mobo: 30.0 C gpu: radeon temp: 37 C Fan Speeds (RPM): fan-1: 580 fan-2: 825 fan-3: 0 fan-4: 562 fan-5: 577 Voltages: 12v: N/A 5v: N/A 3.3v: 3.28 vbat: 3.18 Info: Processes: 259 Uptime: 26m Memory: 31.35 GiB used: 2.24 GiB (7.1%) Init: systemd Compilers: gcc: 8.2.1 clang: 7.0.1 Shell: fish v: 3.0.0 inxi: 3.0.30 -- 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 v12 21/38] mei: me: add ice lake point device id.
> > On Sat, Feb 09, 2019 at 12:42:50PM +0530, Ramalingam C wrote: > > From: Tomas Winkler > > > > Add icelake mei device id. > > > > Cc: > > Signed-off-by: Tomas Winkler > > Signed-off-by: Greg Kroah-Hartman > > Cherry-picked from > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > char-misc-linus > > --- > > drivers/misc/mei/hw-me-regs.h | 2 ++ > > drivers/misc/mei/pci-me.c | 2 ++ > > 2 files changed, 4 insertions(+) > > Why are you sending us patches that are already applied? They're unslinging it for GFX CI so they need it in their queue, it was not merged into the master branch at the time. Thanks Tomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
