Re: [Freedreno] [PATCH 2/2] drm/scheduler: Add a start_timeout_notify() backend function
On 11/2/2018 7:07 PM, Koenig, Christian wrote:
Am 02.11.18 um 14:25 schrieb Sharat Masetty:
On 11/2/2018 4:09 PM, Koenig, Christian wrote:
Am 02.11.18 um 11:31 schrieb Sharat Masetty:
Add an optional backend function op which will let the scheduler
clients
know when the timeout got scheduled on the scheduler instance. This
will
help drivers with multiple schedulers(one per ring) measure time
spent on
the ring accurately, eventually helping with better timeout detection.
Signed-off-by: Sharat Masetty
Well, NAK. drm_sched_start_timeout() is called whenever the timer needs
to run, but that doesn't mean that the timer is started (e.g. it can
already be running).
So the callback would be called multiple times and not reflect the
actual job run time.
Additional to that it can be racy, e.g. we can complete multiple jobs at
a time before the timer is started again.
If you want to accurately count how much time you spend on each job/ring
you need to do this by measuring the time inside your driver instead.
E.g. for amdgpu I would get the time first in amdgpu_job_run() and then
again in amdgpu_job_free_cb() and calculate the difference.
Hi Christian,
Thank you for the comments and apologies if this was confusing. All I
want to determine(more accurately) is that when the scheduler instance
timer of say 500 ms goes off, is if the ring(associated with the
scheduler instance) actually spent 500 ms on the hardware - and for
this I need to know in the driver space when the timer actually started.
In msm hardware we have ring preemption support enabled and the kernel
driver triggers a preemption switch to a higher priority ring if there
is work available on that ring for the GPU to work on. So in the
presence of preemption it is possible that a lower priority ring did
not actually get to spend the full 500 ms and this is what I am trying
to catch with this callback.
I am *not* trying to profile per job time consumption with this.
Well, NAK. drm_sched_start_timeout() is called whenever the timer needs
to run, but that doesn't mean that the timer is started (e.g. it can
already be running).
Regarding the case where the timer may already be running - good
point, but it should be easy to address the scenario. I will check the
output
of schedule_delayed_work() and only call the callback(new proposed) if
the timer was really scheduled.
Yeah, that should work.
In summary, when this timedout_job() callback is called, it is assumed
that the job actually did time out from the POV of the scheduler, but
this will not hold true with preemption switching and that is what I
am trying to better address with this patch.
Mhm, so what you actually need is to suspend the timeout when the lower
priority ring is preempted and resume it when it is started again? I
wonder if that wouldn't be simpler.
We have support for ring preemption as well, but not implemented yet. So
it would be nice to have something that works for everybody.
But on the other hand a callback to notify the driver that the timer
started isn't so bad either.
Hi Christian,
Yes something like a suspend timeout would be simpler for the drivers,
but I could not find anything which does this for the delayed work or
even for the general timers. All I could find was cancel/delete.
In lieu of this, I chose this approach. If you like it this way(proposed
patch), then I will address the review comments and re-spin... please
let me know.
Sharat
Regards,
Christian.
Sharat
Regards,
Christian.
---
Here is an example of how I plan to use this new function callback.
[1] https://patchwork.freedesktop.org/patch/254227/
drivers/gpu/drm/scheduler/sched_main.c | 7 ++-
include/drm/gpu_scheduler.h | 6 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index c993d10..afd461e 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -192,8 +192,13 @@ bool drm_sched_dependency_optimized(struct
dma_fence* fence,
static void drm_sched_start_timeout(struct drm_gpu_scheduler *sched)
{
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
- !list_empty(>ring_mirror_list))
+ !list_empty(>ring_mirror_list)) {
+
schedule_delayed_work(>work_tdr, sched->timeout);
+
+ if (sched->ops->start_timeout_notify)
+ sched->ops->start_timeout_notify(sched);
+ }
}
/* job_finish is called after hw fence signaled
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index d87b268..faf28b4 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -239,6 +239,12 @@ struct drm_sched_backend_ops {
* and it's time to clean it up.
*/
void (*free_job)(struct drm_sched_job *sched_job);
+
+ /*
+ * (Optional) Called to let the driver know that a timeout
detection
+ * timer has
[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU
https://bugs.freedesktop.org/show_bug.cgi?id=108652 Bug ID: 108652 Summary: I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 142364 --> https://bugs.freedesktop.org/attachment.cgi?id=142364=edit shining LEDs (now in 4K scenarios) I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU I remember that earlier in the GPU bound scenarios all LED are shining. Now I have never seen more than two LEDs shining at the same time even when GPU is 100% loaded (I see this by HUD monitoring) I even forgot when I heard last time when turbine roared. >From the point of view of audio comfort, this is all great, but the feeling that video card was became weaker does not leave me, and it upsets. Unfortunately, I have nothing to compare I don't like use old kernels because they have a lot of not fixed old bugs. -- 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 201439] Amdgpu: system freeze when waking up from monitor sleep
https://bugzilla.kernel.org/show_bug.cgi?id=201439 fin4...@hotmail.com changed: What|Removed |Added Kernel Version|drm-next-4.21-wip |4.20-rc1, ||drm-next-4.21-wip, Regression|No |Yes Summary|Amdgpu: general protection |Amdgpu: system freeze when |fault at dce110_vblank_set |waking up from monitor |in display resume |sleep --- Comment #10 from fin4...@hotmail.com --- The mainline kernel 4.19.0 from kernel.org is the best, no system freeze when waking up from monitor sleep. Latest mainline kernel 4.20-rc1 from kernel.org and AMD drm-next-4.21-wip compiled at Saturday do freeze the system when waking up from monitor sleep after 10 minutes and more. There is ^@^@^@ garbage strings in the /var/log/messages file when the system freezes. My computer is always on, only my Samsung 24" S24F350H hdmi monitor sleeps. I have ASUS Radeon RX 570 4GB Expedition OC now. System: Host: ryzenpc Kernel: 4.19.0 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux buster/sid Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x serial: UEFI: American Megatrends v: 4023 date: 08/20/2018 CPU: 6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2807 MHz Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.19.0 LLVM 7.0.0) v: 4.5 Mesa 18.3.0-devel (git-9007c0e 2018-10-29 bionic-oibaf-ppa) Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Device-2: Huawei type: USB driver: cdc_ether,usb-storage Drives: Local Storage: total: 476.95 GiB used: 250.43 GiB (52.5%) Info: Processes: 242 Uptime: 9m Memory: 7.79 GiB used: 637.4 MiB (8.0%) Shell: bash inxi: 3.0.27 -- 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] drm/msm/dpu: Don't use devm for component devices
On 02.11.2018 19:25, Jordan Crouse wrote:
> Devices that are bound as components should not use devm since
> device managed memory is not freed when the component is
> unbound.
>
> In particular this is an issue if the compoent bind fails
> due to an -EPROBE_DEFER. In this case the bind would try again
> later and any devm managed meory allocated during the former
> aborted attempt would be leaked until the device itself was
> destroyed. Therefore, all the memory allocated during a bind
> should be freed during an unbind (or bind error case) and there
> isn't any reason to use devm for resources that have a explicit
> teardown step.
It does not look correct, component framework should properly free devm
resources, ie if devm resource was allocated in bind callback, it should
be released after unbind or failed bind.
See comments inside component_bind[1]. If it does not work it should be
fixed in components.
[1]:
https://elixir.bootlin.com/linux/latest/source/drivers/base/component.c#L464
Regards
Andrzej
>
> This doesn't remove devm for all resources - in particular
> msm_ioremap() still uses devm_ioremap() but thats a more
> generic condition that can easily be addressed as a cleanup
> later and the unbind code already does the requisite devm
> calls to unmap it.
>
> v2: free mp->clk_config on failure
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 6 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c| 8 +---
> 4 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 82c55efb500f..287d4c3e58c3 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2220,14 +2220,14 @@ struct drm_encoder *dpu_encoder_init(struct
> drm_device *dev,
> struct dpu_encoder_virt *dpu_enc = NULL;
> int rc = 0;
>
> - dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
> + dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);
> if (!dpu_enc)
> return ERR_PTR(ENOMEM);
>
> rc = drm_encoder_init(dev, _enc->base, _encoder_funcs,
> drm_enc_mode, NULL);
> if (rc) {
> - devm_kfree(dev->dev, dpu_enc);
> + kfree(dpu_enc);
> return ERR_PTR(rc);
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> index 89ee4b36beff..14fecf00e032 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> @@ -155,9 +155,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
> return 0;
> }
>
> - mp->clk_config = devm_kzalloc(>dev,
> - sizeof(struct dss_clk) * num_clk,
> - GFP_KERNEL);
> + mp->clk_config = kcalloc(num_clk, sizeof(struct dss_clk), GFP_KERNEL);
> if (!mp->clk_config)
> return -ENOMEM;
>
> @@ -201,5 +199,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
>
> err:
> msm_dss_put_clk(mp->clk_config, num_clk);
> + kfree(mp->clk_config);
> + mp->clk_config = NULL;
> return rc;
> }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 985c855796ae..5ac3c3f3b08d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1086,13 +1086,14 @@ static int dpu_bind(struct device *dev, struct device
> *master, void *data)
> struct dss_module_power *mp;
> int ret = 0;
>
> - dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), GFP_KERNEL);
> + dpu_kms = kzalloc(sizeof(*dpu_kms), GFP_KERNEL);
> if (!dpu_kms)
> return -ENOMEM;
>
> mp = _kms->mp;
> ret = msm_dss_parse_clock(pdev, mp);
> if (ret) {
> + kfree(dpu_kms);
> DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
> return ret;
> }
> @@ -1109,7 +1110,7 @@ static int dpu_bind(struct device *dev, struct device
> *master, void *data)
> dpu_kms->rpm_enabled = true;
>
> priv->kms = _kms->base;
> - return ret;
> + return 0;
> }
>
> static void dpu_unbind(struct device *dev, struct device *master, void *data)
> @@ -1120,11 +1121,12 @@ static void dpu_unbind(struct device *dev, struct
> device *master, void *data)
>
> dpu_power_resource_deinit(pdev, _kms->phandle);
> msm_dss_put_clk(mp->clk_config, mp->num_clk);
> - devm_kfree(>dev, mp->clk_config);
> - mp->num_clk = 0;
> + kfree(mp->clk_config);
>
> if (dpu_kms->rpm_enabled)
> pm_runtime_disable(>dev);
> +
> + kfree(dpu_kms);
> }
>
> static
Re: [PATCH 1/5] drm/virtio: add virtio_gpu_alloc_fence()
> > On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote: > > > > > > From: Gustavo Padovan > > > > > > Refactor fence creation to remove the potential allocation failure from > > > the cmd_submit and atomic_commit paths. Now the fence should be allocated > > > first and just after we should proceed with the rest of the execution. > > > > > > > Commit does a bit more that what the above says: > > - dummy, factor out fence creation/destruction > > - use per virtio_gpu_framebuffer fence > > > > Personally I'd keep the two separate patches and elaborate on the latter. > > Obviously in that case, one will need to add 3 lines worth of > > virtio_gpu_fence_alloc() in virtio_gpu_cursor_plane_update which will be > > nuked > > with the next patch. > > > > Not a big deal, but it's up-to the maintainer to make the final call if it's > > worth splitting or not. > > Agreed, I'll hold off with this change until then. No need to split this, but a bit more verbose commit message would be good. cheers, Gerd ___ 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 #8 from quirin.blae...@freenet.de --- I have replaced HDMI-cable by displayport about 2 weeks ago. No bug visible. (Firmware update about 1 week ago). Maybe HDMI is broken or implementation in monitors/graphics board is bad or cables are bad or implementation in amdgpu is bad. HDMI with old monitor and old cable worked well for about 2 years with radeon and APU. -- 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 09/10] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Hi Jagan.
Reading through the driver triggered a few comments.
Read and decide what is usefull.
Sam
> Add panel driver for it.
>
> Signed-off-by: Jagan Teki
> ---
> Note: init sequence is referenced from
> https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/drivers/video/sunxi/disp2/disp/lcd/mb709_mipi.c
This note should perferably be part of the commit message or maybe included
in the code so it is easie to track back.
> +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
> +/*
> + * Copyright (C) 2018 Amarula Solutions
> + * Author: Jagan Teki
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
I cannot see this include is used anywhere in this .c file.
The few MIPI_ constants originates from
and I think the include can be dropped.
> +struct fy07024di26a30d {
> + struct drm_panelpanel;
> + struct mipi_dsi_device *dsi;
> +
> + struct backlight_device *backlight;
> + struct regulator*dvdd;
> + struct regulator*avdd;
> + struct gpio_desc*reset;
> +
> + boolis_enabled;
> + boolis_prepared;
> +};
Maybe bikeshedding a little here.
But the use of names like fy07024di26a30d does not help readability.
Just name it feiyang like for example we see in panel-innolux-p079zca.c
where this drives is somehow inspired from. (Here the name is innolux).
> +
> +static inline struct fy07024di26a30d *panel_to_fy07024di26a30d(struct
> drm_panel *panel)
> +{
> + return container_of(panel, struct fy07024di26a30d, panel);
> +}
> +
> +struct fy07024di26a30d_init_cmd {
> + size_t len;
> + const char *data;
> +};
> +
> +#define FY07024DI26A30D(...) { \
> + .len = sizeof((char[]){__VA_ARGS__}), \
> + .data = (char[]){__VA_ARGS__} }
> +
> +static const struct fy07024di26a30d_init_cmd fy07024di26a30d_init_cmds[] = {
> + FY07024DI26A30D(0x80, 0x58),
> + FY07024DI26A30D(0x81, 0x47),
> + FY07024DI26A30D(0x82, 0xD4),
> + FY07024DI26A30D(0x83, 0x88),
> + FY07024DI26A30D(0x84, 0xA9),
> + FY07024DI26A30D(0x85, 0xC3),
> + FY07024DI26A30D(0x86, 0x82),
> +};
> +
> +static int fy07024di26a30d_prepare(struct drm_panel *panel)
> +{
> + struct fy07024di26a30d *ctx = panel_to_fy07024di26a30d(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + unsigned int i;
> + int ret;
> +
> + if (ctx->is_prepared)
> + return 0;
> +
> + gpiod_set_value(ctx->reset, 1);
> + msleep(50);
> +
> + gpiod_set_value(ctx->reset, 0);
> + msleep(20);
> +
> + gpiod_set_value(ctx->reset, 1);
> + msleep(200);
> +
> + for (i = 0; i < ARRAY_SIZE(fy07024di26a30d_init_cmds); i++) {
> + const struct fy07024di26a30d_init_cmd *cmd =
> + _init_cmds[i];
> +
> + ret = mipi_dsi_dcs_write_buffer(dsi, cmd->data, cmd->len);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret < 0) {
> + dev_err(panel->dev, "failed to set display on: %d\n", ret);
> + return ret;
> + }
General comment.
Consider using DRM_DEV_ERROR(...) to be consistent with
what is used in many other drm drivers.
> +static int fy07024di26a30d_enable(struct drm_panel *panel)
> +{
> + struct fy07024di26a30d *ctx = panel_to_fy07024di26a30d(panel);
> +
> + if (ctx->is_enabled)
> + return 0;
> +
> + msleep(120);
This msleep() looks unjustified, as no other statement preceed it.
If prepare() requires a delay then maybe the delay should be there?
> +
> +static int fy07024di26a30d_unprepare(struct drm_panel *panel)
> +{
> + struct fy07024di26a30d *ctx = panel_to_fy07024di26a30d(panel);
> + int ret;
> +
> + if (!ctx->is_prepared)
> + return 0;
> +
> + ret = mipi_dsi_dcs_set_display_off(ctx->dsi);
> + if (ret < 0)
> + dev_err(panel->dev, "failed to set display off: %d\n", ret);
> +
> + ret = mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> + if (ret < 0)
> + dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
> +
> + msleep(100);
> +
> + regulator_disable(ctx->avdd);
> +
> + regulator_disable(ctx->dvdd);
> +
> + gpiod_set_value(ctx->reset, 0);
> +
> + gpiod_set_value(ctx->reset, 1);
> +
> + gpiod_set_value(ctx->reset, 0);
In prepare() there are dealys around asserting reset and releasing again.
Consider using a small helper function and be consistent with the
delays.
> +
> + ctx->is_prepared = false;
> +
> + return 0;
> +}
> +
> +static const struct drm_display_mode fy07024di26a30d_default_mode = {
> + .clock = 55000,
> + .vrefresh = 60,
> +
> + .hdisplay = 1024,
> + .hsync_start = 1024 + 396,
> +
[PATCH v3 11/28] drm/sun4i: Disable unused DE2 sub-engines
Some sub-engines are unused. Disable them explicitly. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 8 drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 6769ec08c0d3..ec2c264f9481 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -462,6 +462,14 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, /* Reset the registers */ for (i = 0; i < DE2_MIXER_UNIT_SIZE; i += 4) regmap_write(mixer->engine.regs, i, 0); + /* Disable unused sub-engines */ + regmap_write(mixer->engine.regs, SUN8I_MIXER_FCE_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_BWS_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_LTI_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_PEAK_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_ASE_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_FCC_EN, 0); + regmap_write(mixer->engine.regs, SUN8I_MIXER_DCSC_EN, 0); /* Enable the mixer */ regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_CTL, diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 09e0f4428c1e..a4175b993e0d 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -101,8 +101,8 @@ #define SUN8I_MIXER_FBFMT_YUV411 14 /* - * These sub-engines are still unknown now, the EN registers are here only to - * be used to disable these sub-engines. + * Sub-engines listed bellow are unused for now. The EN registers are here only + * to be used to disable these sub-engines. */ #define SUN8I_MIXER_FCE_EN 0xa #define SUN8I_MIXER_BWS_EN 0xa2000 -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 19/28] drm/sun4i: Add support for H6 DW HDMI controller
H6 has DW HDMI 2.0b controller v2.12a.
It supports 4K at 60 Hz and HDCP 2.2.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 99b878e380e1..445cca8d9a26 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -44,6 +44,17 @@ sun8i_dw_hdmi_mode_valid_a83t(struct drm_connector
*connector,
return MODE_OK;
}
+static enum drm_mode_status
+sun8i_dw_hdmi_mode_valid_h6(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ /* This is max for HDMI 2.0b (4K@60Hz) */
+ if (mode->clock > 594000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
{
return IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
@@ -239,11 +250,19 @@ static const struct sun8i_dw_hdmi_quirks
sun8i_a83t_quirks = {
.set_rate = true,
};
+static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
+ .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
+};
+
static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
{
.compatible = "allwinner,sun8i-a83t-dw-hdmi",
.data = _a83t_quirks,
},
+ {
+ .compatible = "allwinner,sun50i-h6-dw-hdmi",
+ .data = _h6_quirks,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] ARM: dts: imx6sx: Add DISPLAY power domain support
On 10/31/2018 5:06 PM, Lorenzo Pieralisi wrote: > On Wed, Oct 31, 2018 at 12:17:50PM +, Leonard Crestez wrote: >> On 10/31/2018 8:12 AM, Shawn Guo wrote: >>> On Mon, Oct 08, 2018 at 06:06:23PM +, Leonard Crestez wrote: This was implemented in the driver but not actually defined and referenced in dts. This makes it always on. From reference manual in section "10.4.1.4.1 Power Distribution": "Display domain - The DISPLAY domain contains GIS, CSI, PXP, LCDIF, PCIe, DCIC, and LDB. It is supplied by internal regulator." The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is actually inside the DISPLAY domain. Handle this by adding the pcie node in both power domains. Signed-off-by: Leonard Crestez >>> >>> Applied, thanks. >> >> As mentioned in the cover letter this requires multi-PD support in >> imx-pci to be implemented, specifically PATCH 3/4 of this series: >> >> Unless that also gets merged soon via pci I expect issues in linux-next. > > I do not know what you mean by "issues in linux-next" (I assume you mean > when Shawn sends the patches to linux-next in preparation for v4.21); we > have not planned any other PCI pull request for v4.20-rc1 material. Yes my concern is linux-next for 4.21 >> The patch already has reviewed-by tags so "merging it soon" is not >> unreasonable. > > I can ACK it if Shawn wants to pull it, it may take a while to see it > in -next if it has to go through the PCI tree, I think it is better > to queue the series without splitting the patches across multiple > channels though. This sounds great to me, merging the whole series through Shawn's imx tree would prevent issues in linux-next or possible bisect failures in 4.21. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/28] drm/sun4i: dw-hdmi: Make mode_valid function configurable
Since it is not possible to access sun8i-dw-hdmi driver private data
inside mode_valid function, make it configurable. That way different
versions of HDMI controllers can set different function, depending on
it's limitations.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 18 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 6 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index ed2983770e9c..ec122136ee9d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
@@ -33,8 +34,8 @@ static const struct drm_encoder_funcs
sun8i_dw_hdmi_encoder_funcs = {
};
static enum drm_mode_status
-sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
-const struct drm_display_mode *mode)
+sun8i_dw_hdmi_mode_valid_a83t(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
{
if (mode->clock > 297000)
return MODE_CLOCK_HIGH;
@@ -102,6 +103,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
hdmi->dev = >dev;
encoder = >encoder;
+ hdmi->quirks = of_device_get_match_data(dev);
+
encoder->possible_crtcs =
sun8i_dw_hdmi_find_possible_crtcs(drm, dev->of_node);
/*
@@ -168,7 +171,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
sun8i_hdmi_phy_init(hdmi->phy);
- plat_data->mode_valid = _dw_hdmi_mode_valid;
+ plat_data->mode_valid = hdmi->quirks->mode_valid;
plat_data->phy_ops = sun8i_hdmi_phy_get_ops();
plat_data->phy_name = "sun8i_dw_hdmi_phy";
plat_data->phy_data = hdmi->phy;
@@ -230,8 +233,15 @@ static int sun8i_dw_hdmi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
+ .mode_valid = sun8i_dw_hdmi_mode_valid_a83t,
+};
+
static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
- { .compatible = "allwinner,sun8i-a83t-dw-hdmi" },
+ {
+ .compatible = "allwinner,sun8i-a83t-dw-hdmi",
+ .data = _a83t_quirks,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 7fdc1ecd2892..a645b8bc9f58 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -170,6 +170,11 @@ struct sun8i_hdmi_phy {
struct sun8i_hdmi_phy_variant *variant;
};
+struct sun8i_dw_hdmi_quirks {
+ enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
+ const struct drm_display_mode *mode);
+};
+
struct sun8i_dw_hdmi {
struct clk *clk_tmds;
struct device *dev;
@@ -178,6 +183,7 @@ struct sun8i_dw_hdmi {
struct sun8i_hdmi_phy *phy;
struct dw_hdmi_plat_dataplat_data;
struct regulator*regulator;
+ const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control*rst_ctrl;
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 20/28] drm/sun4i: dw-hdmi-phy: Reorder quirks by family
Currently, quirks and compatibles are sorted alphabetically. However,
they should be sorted by family release date and then alphabetically.
Fix that by moving A64 quirks and compatible to bottom. No functional
change is made.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 365cb5a9fb77..adc3ba7df7e3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -403,13 +403,6 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config =
{
.name = "phy"
};
-static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
- .has_phy_clk = true,
- .phy_init = _hdmi_phy_init_h3,
- .phy_disable = _hdmi_phy_disable_h3,
- .phy_config = _hdmi_phy_config_h3,
-};
-
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
.phy_init = _hdmi_phy_init_a83t,
.phy_disable = _hdmi_phy_disable_a83t,
@@ -431,11 +424,14 @@ static const struct sun8i_hdmi_phy_variant
sun8i_r40_hdmi_phy = {
.phy_config = _hdmi_phy_config_h3,
};
+static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
+ .has_phy_clk = true,
+ .phy_init = _hdmi_phy_init_h3,
+ .phy_disable = _hdmi_phy_disable_h3,
+ .phy_config = _hdmi_phy_config_h3,
+};
+
static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
- {
- .compatible = "allwinner,sun50i-a64-hdmi-phy",
- .data = _a64_hdmi_phy,
- },
{
.compatible = "allwinner,sun8i-a83t-hdmi-phy",
.data = _a83t_hdmi_phy,
@@ -448,6 +444,10 @@ static const struct of_device_id sun8i_hdmi_phy_of_table[]
= {
.compatible = "allwinner,sun8i-r40-hdmi-phy",
.data = _r40_hdmi_phy,
},
+ {
+ .compatible = "allwinner,sun50i-a64-hdmi-phy",
+ .data = _a64_hdmi_phy,
+ },
{ /* sentinel */ }
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay
On Sat, Nov 3, 2018 at 8:53 PM Sergey Suloev wrote:
>
> Hi, Jagan,
>
> On 11/3/18 1:08 PM, Jagan Teki wrote:
> > Loop N1 instruction delay for burst mode lcd panel are
> > computed as per BSP code.
> >
> > Reference code is available in BSP
> > (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
> > (panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
> > => (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) -
> > 50;
> >
> > So use the similar computation for loop N1 delay.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 86430efd9054..da152c21ec62 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -394,7 +394,14 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi
> > *dsi,
> > static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
> > struct drm_display_mode *mode)
> > {
> > - u16 delay = 50 - 1;
> > + struct mipi_dsi_device *device = dsi->device;
> > + u16 delay;
> > +
> > + if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST)
> > + delay = (((mode->htotal - mode->hdisplay) * 150) /
> > + ((mode->clock / 1000) * 8)) - 50;
> > + else
> > + delay = 50 - 1;
> >
> > regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
> >SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
>
>
> is this patch series comes in addition to the previous MIPI DSI series
> or in its stead?
Yes, all changes were added on top of previous MIPI DSI series(ie what
I mentioned in cover-letter) since it require clock patches from
previous version.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 27/28] arm64: dts: allwinner: h6: Add HDMI pipeline
This commit adds all entries needed for HDMI to function properly.
Signed-off-by: Jernej Skrabec
[added DE3 bus]
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 201 +++
1 file changed, 201 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 040828d2e2c0..59dda8f89d23 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -6,8 +6,11 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -86,12 +89,63 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ de: display-engine {
+ compatible = "allwinner,sun50i-h6-display-engine";
+ allwinner,pipelines = <>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ de3@100 {
+ compatible = "allwinner,sun50i-h6-de3",
+"allwinner,sun50i-a64-de2";
+ reg = <0x100 0x40>;
+ allwinner,sram = <_sram 1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x100 0x40>;
+
+ display_clocks: clock@0 {
+ compatible = "allwinner,sun50i-h6-de3-clk";
+ reg = <0x0 0x1>;
+ clocks = < CLK_DE>,
+< CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = < RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@10 {
+ compatible = "allwinner,sun50i-h6-de3-mixer-0";
+ reg = <0x10 0x10>;
+ clocks = <_clocks CLK_BUS_MIXER0>,
+<_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ reg = <1>;
+
+ mixer0_out_tcon_top_mixer0:
endpoint {
+ remote-endpoint =
<_top_mixer0_in_mixer0>;
+ };
+ };
+ };
+ };
+ };
+
syscon: syscon@300 {
compatible = "allwinner,sun50i-h6-system-control",
"allwinner,sun50i-a64-system-control";
@@ -149,6 +203,11 @@
interrupt-controller;
#interrupt-cells = <3>;
+ hdmi_pins: hdmi-pins {
+ pins = "PH8", "PH9", "PH10";
+ function = "hdmi";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
@@ -258,6 +317,148 @@
status = "disabled";
};
+ hdmi: hdmi@600 {
+ compatible = "allwinner,sun50i-h6-dw-hdmi";
+ reg = <0x0600 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = < CLK_BUS_HDMI>, < CLK_HDMI_SLOW>,
+< CLK_HDMI>, < CLK_HDMI_CEC>,
+< CLK_HDCP>, < CLK_BUS_HDCP>;
+ clock-names = "iahb", "isfr", "tmds", "cec", "hdcp",
+ "hdcp-bus";
+ resets = < RST_BUS_HDMI_SUB>, < RST_BUS_HDCP>;
+ reset-names = "ctrl", "hdcp";
+ phys = <_phy>;
+ phy-names = "hdmi-phy";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+
[PATCH v3 26/28] drm: sun4i: add support for H6 TCON TOP
From: Icenowy Zheng
The TCON TOP on Allwinner H6 SoC is a cut down version of the R40 TCON
TOP, which dropped TCON_TV1 and DSI (which do not exist on H6).
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index e94e3fb1736b..fc36e0c10a37 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -273,12 +273,20 @@ const struct sun8i_tcon_top_quirks
sun8i_r40_tcon_top_quirks = {
.has_dsi= true,
};
+const struct sun8i_tcon_top_quirks sun50i_h6_tcon_top_quirks = {
+ /* Nothing special */
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON TOP */
const struct of_device_id sun8i_tcon_top_of_table[] = {
{
.compatible = "allwinner,sun8i-r40-tcon-top",
.data = _r40_tcon_top_quirks
},
+ {
+ .compatible = "allwinner,sun50i-h6-tcon-top",
+ .data = _h6_tcon_top_quirks
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/28] drm/sun4i: dw-hdmi: Add quirk for setting TMDS clock
It turns out that H6 HDMI BSP kernel driver doesn't change TMDS rate at
all. At this point it is not clear whether it is just not necessary or
it would cause some kind of issues.
Add a quirk for it.
Acked-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 4 +++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index ec122136ee9d..99b878e380e1 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -21,7 +21,8 @@ static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder
*encoder,
{
struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
- clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
+ if (hdmi->quirks->set_rate)
+ clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
}
static const struct drm_encoder_helper_funcs
@@ -235,6 +236,7 @@ static int sun8i_dw_hdmi_remove(struct platform_device
*pdev)
static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
.mode_valid = sun8i_dw_hdmi_mode_valid_a83t,
+ .set_rate = true,
};
static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index a645b8bc9f58..49c9e80c46ea 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -173,6 +173,7 @@ struct sun8i_hdmi_phy {
struct sun8i_dw_hdmi_quirks {
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
+ unsigned int set_rate : 1;
};
struct sun8i_dw_hdmi {
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/28] drm/sun4i: Add compatible for H6 display engine
H6 is first Allwinner SoC which supports 10 bit colors, HDR and AFBC.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 1e41c3f5fd6d..1ca7b70cbbfa 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -406,6 +406,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ .compatible = "allwinner,sun9i-a80-display-engine" },
{ .compatible = "allwinner,sun50i-a64-display-engine" },
+ { .compatible = "allwinner,sun50i-h6-display-engine" },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/28] clk: sunxi-ng: Add support for H6 DE3 clocks
Support for mixer0, mixer1, writeback and rotation units is added.
Signed-off-by: Jernej Skrabec
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 71 ++--
drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 4 +-
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
index bae5ee67a797..1c9ae0a319c1 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -31,6 +31,8 @@ static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1",
"bus-de",
0x04, BIT(1), 0);
static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
0x04, BIT(2), 0);
+static SUNXI_CCU_GATE(bus_rot_clk, "bus-rot", "bus-de",
+ 0x04, BIT(3), 0);
static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
0x00, BIT(0), CLK_SET_RATE_PARENT);
@@ -38,6 +40,8 @@ static SUNXI_CCU_GATE(mixer1_clk, "mixer1",
"mixer1-div",
0x00, BIT(1), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
0x00, BIT(2), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(rot_clk, "rot", "rot-div",
+ 0x00, BIT(3), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
CLK_SET_RATE_PARENT);
@@ -45,6 +49,8 @@ static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c,
4, 4,
CLK_SET_RATE_PARENT);
static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(rot_div_clk, "rot-div", "de", 0x0c, 0x0c, 4,
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M(mixer0_div_a83_clk, "mixer0-div", "pll-de", 0x0c, 0, 4,
CLK_SET_RATE_PARENT);
@@ -53,6 +59,24 @@ static SUNXI_CCU_M(mixer1_div_a83_clk, "mixer1-div",
"pll-de", 0x0c, 4, 4,
static SUNXI_CCU_M(wb_div_a83_clk, "wb-div", "pll-de", 0x0c, 8, 4,
CLK_SET_RATE_PARENT);
+static struct ccu_common *sun50i_h6_de3_clks[] = {
+ _clk.common,
+ _clk.common,
+ _clk.common,
+
+ _mixer0_clk.common,
+ _mixer1_clk.common,
+ _wb_clk.common,
+
+ _div_clk.common,
+ _div_clk.common,
+ _div_clk.common,
+
+ _rot_clk.common,
+ _clk.common,
+ _div_clk.common,
+};
+
static struct ccu_common *sun8i_a83t_de2_clks[] = {
_clk.common,
_clk.common,
@@ -106,7 +130,7 @@ static struct clk_hw_onecell_data sun8i_a83t_de2_hw_clks = {
[CLK_MIXER1_DIV]= _div_a83_clk.common.hw,
[CLK_WB_DIV]= _div_a83_clk.common.hw,
},
- .num= CLK_NUMBER,
+ .num= CLK_NUMBER_WITHOUT_ROT,
};
static struct clk_hw_onecell_data sun8i_h3_de2_hw_clks = {
@@ -123,7 +147,7 @@ static struct clk_hw_onecell_data sun8i_h3_de2_hw_clks = {
[CLK_MIXER1_DIV]= _div_clk.common.hw,
[CLK_WB_DIV]= _div_clk.common.hw,
},
- .num= CLK_NUMBER,
+ .num= CLK_NUMBER_WITHOUT_ROT,
};
static struct clk_hw_onecell_data sun8i_v3s_de2_hw_clks = {
@@ -137,7 +161,27 @@ static struct clk_hw_onecell_data sun8i_v3s_de2_hw_clks = {
[CLK_MIXER0_DIV]= _div_clk.common.hw,
[CLK_WB_DIV]= _div_clk.common.hw,
},
- .num= CLK_NUMBER,
+ .num= CLK_NUMBER_WITHOUT_ROT,
+};
+
+static struct clk_hw_onecell_data sun50i_h6_de3_hw_clks = {
+ .hws= {
+ [CLK_MIXER0]= _clk.common.hw,
+ [CLK_MIXER1]= _clk.common.hw,
+ [CLK_WB]= _clk.common.hw,
+ [CLK_ROT] = _clk.common.hw,
+
+ [CLK_BUS_MIXER0]= _mixer0_clk.common.hw,
+ [CLK_BUS_MIXER1]= _mixer1_clk.common.hw,
+ [CLK_BUS_WB]= _wb_clk.common.hw,
+ [CLK_BUS_ROT] = _rot_clk.common.hw,
+
+ [CLK_MIXER0_DIV]= _div_clk.common.hw,
+ [CLK_MIXER1_DIV]= _div_clk.common.hw,
+ [CLK_WB_DIV]= _div_clk.common.hw,
+ [CLK_ROT_DIV] = _div_clk.common.hw,
+ },
+ .num= CLK_NUMBER_WITH_ROT,
};
static struct ccu_reset_map sun8i_a83t_de2_resets[] = {
@@ -156,6 +200,13 @@ static struct ccu_reset_map sun50i_a64_de2_resets[] = {
[RST_WB]= { 0x08, BIT(2) },
};
+static struct ccu_reset_map sun50i_h6_de3_resets[] = {
+ [RST_MIXER0]= { 0x08, BIT(0) },
+ [RST_MIXER1]= { 0x08, BIT(1) },
+ [RST_WB]= { 0x08, BIT(2) },
+ [RST_ROT] = { 0x08, BIT(3) },
+};
+
static const struct sunxi_ccu_desc sun8i_a83t_de2_clk_desc = {
.ccu_clks =
Re: [linux-sunxi] [PATCH 01/10] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay
On Sat, Nov 03, 2018 at 03:38:51PM +0530, Jagan Teki wrote:
> Loop N1 instruction delay for burst mode lcd panel are
> computed as per BSP code.
>
> Reference code is available in BSP
> (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
> (panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
> => (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) -
> 50;
>
> So use the similar computation for loop N1 delay.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 86430efd9054..da152c21ec62 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -394,7 +394,14 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> - u16 delay = 50 - 1;
> + struct mipi_dsi_device *device = dsi->device;
> + u16 delay;
> +
> + if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST)
This looks fishy, as mode_flags is supposedly bitfield.
I guess you actually want mode_flags & MIPI_DSI_MODE_VIDEO_BURST. Other
patches are also affected by this.
> + delay = (((mode->htotal - mode->hdisplay) * 150) /
> + ((mode->clock / 1000) * 8)) - 50;
> + else
> + delay = 50 - 1;
>
> regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
>SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
> --
> 2.18.0.321.gffc6fa0e3
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/28] drm/sun4i: Add basic support for DE3
Display Engine 3 is an upgrade of DE2 with new features like support for
10 bit color formats and support for AFBC.
Most of DE2 code works with DE3, except some small details.
Implement basic support for DE3. Support for 10 bit colort formats and
AFBC, among others missing features, will be added later.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 83 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 38 +++
drivers/gpu/drm/sun4i/sun8i_mixer.h | 34 +-
drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 10 ++-
drivers/gpu/drm/sun4i/sun8i_ui_scaler.h | 1 +
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 8 +++
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 2 +
drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 19 +-
drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 23 +++
9 files changed, 202 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
index b14925b40ccf..e7608a72f26f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.c
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -34,6 +34,41 @@ static const u32 yvu2rgb[] = {
0x04A8, 0x, 0x0813, 0xFFFBAC4A,
};
+/*
+ * DE3 has a bit different CSC units. Factors are in two's complement format.
+ * First three factors in a row are multiplication factors which have 17 bits
+ * for fractional part. Fourth value in a row is comprised of two factors.
+ * Upper 16 bits represents difference, which is subtracted from the input
+ * value before multiplication and lower 16 bits represents constant, which
+ * is addes at the end.
+ *
+ * x' = c00 * (x + d0) + c01 * (y + d1) + c02 * (z + d2) + const0
+ * y' = c10 * (x + d0) + c11 * (y + d1) + c12 * (z + d2) + const1
+ * z' = c20 * (x + d0) + c21 * (y + d1) + c22 * (z + d2) + const2
+ *
+ * Please note that above formula is true only for Blender CSC. Other DE3 CSC
+ * units takes only positive value for difference. From what can be deducted
+ * from BSP driver code, those units probably automatically assume that
+ * difference has to be subtracted.
+ *
+ * Layout of factors in table:
+ * c00 c01 c02 [d0 const0]
+ * c10 c11 c12 [d1 const1]
+ * c20 c21 c22 [d2 const2]
+ */
+
+static const u32 yuv2rgb_de3[] = {
+ 0x0002542a, 0x, 0x0003312a, 0xffc0,
+ 0x0002542a, 0x376b, 0xfffe5fc3, 0xfe00,
+ 0x0002542a, 0x000408d3, 0x, 0xfe00,
+};
+
+static const u32 yvu2rgb_de3[] = {
+ 0x0002542a, 0x0003312a, 0x, 0xffc0,
+ 0x0002542a, 0xfffe5fc3, 0x376b, 0xfe00,
+ 0x0002542a, 0x, 0x000408d3, 0xfe00,
+};
+
static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
enum sun8i_csc_mode mode)
{
@@ -61,6 +96,28 @@ static void sun8i_csc_set_coefficients(struct regmap *map,
u32 base,
}
}
+static void sun8i_de3_ccsc_set_coefficients(struct regmap *map, int layer,
+ enum sun8i_csc_mode mode)
+{
+ const u32 *table;
+ u32 base_reg;
+
+ switch (mode) {
+ case SUN8I_CSC_MODE_YUV2RGB:
+ table = yuv2rgb_de3;
+ break;
+ case SUN8I_CSC_MODE_YVU2RGB:
+ table = yvu2rgb_de3;
+ break;
+ default:
+ DRM_WARN("Wrong CSC mode specified.\n");
+ return;
+ }
+
+ base_reg = SUN50I_MIXER_BLEND_CSC_COEFF(DE3_BLD_BASE, layer, 0, 0);
+ regmap_bulk_write(map, base_reg, table, 12);
+}
+
static void sun8i_csc_enable(struct regmap *map, u32 base, bool enable)
{
u32 val;
@@ -73,11 +130,32 @@ static void sun8i_csc_enable(struct regmap *map, u32 base,
bool enable)
regmap_update_bits(map, SUN8I_CSC_CTRL(base), SUN8I_CSC_CTRL_EN, val);
}
+static void sun8i_de3_ccsc_enable(struct regmap *map, int layer, bool enable)
+{
+ u32 val, mask;
+
+ mask = SUN50I_MIXER_BLEND_CSC_CTL_EN(layer);
+
+ if (enable)
+ val = mask;
+ else
+ val = 0;
+
+ regmap_update_bits(map, SUN50I_MIXER_BLEND_CSC_CTL(DE3_BLD_BASE),
+ mask, val);
+}
+
void sun8i_csc_set_ccsc_coefficients(struct sun8i_mixer *mixer, int layer,
enum sun8i_csc_mode mode)
{
u32 base;
+ if (mixer->cfg->is_de3) {
+ sun8i_de3_ccsc_set_coefficients(mixer->engine.regs,
+ layer, mode);
+ return;
+ }
+
base = ccsc_base[mixer->cfg->ccsc][layer];
sun8i_csc_set_coefficients(mixer->engine.regs, base, mode);
@@ -87,6 +165,11 @@ void sun8i_csc_enable_ccsc(struct sun8i_mixer *mixer, int
layer, bool enable)
{
u32 base;
+ if (mixer->cfg->is_de3) {
+ sun8i_de3_ccsc_enable(mixer->engine.regs, layer, enable);
+ return;
+ }
+
base = ccsc_base[mixer->cfg->ccsc][layer];
[PATCH v3 00/28] Allwinner H6 DE3 and HDMI support
This series adds support for Display Engine 3.0 and HDMI 2.0a, which can be found on H6 SoC. Display Engine 3.0 in comparison to 2.0 mostly adds features needed for displaying and processing 10-bit and AFBC formats, which are not yet supported by this series. H6 is also the first SoC which supports IOMMU, but support for it is not yet added. This series is based on linux-next at next-20181102. I suggest all patches go through allwinner tree, except DRM patches, which should go through drm-misc tree. Last detail, PineH64 model A schematic has DDC_EN signal, which enables DDC voltage level shifter. TL Lim, PINE64 founder, said that this signal is not actually present on PineH64 model A board. It is, however present on PineH64 model B engineering samples, but it will be removed in production version. Because of that, I didn't include any code for it. Please take a look. Best regards, Jernej Changes from v2: - Collected tags - Removed patch which renames all DE2 macros - Converted bool struct members in header files to unsigned int bitfield. This issue was reported by checkpatch.pl --strict. - Fixed code style in tcon top driver and removed unnecessary initialization - Moved set_rate quirk check in dw-hdmi driver to more appropriate place - Fixed compatible for H6 DE3 bus compatible Changes from v1: - Collected tags - Reworked some commit messages and titles - Remove two patches which were already merged - Added new patches (10, 11, 12, 21) - Lowered max. supported HDMI pixel clock to 594 MHz - Reordered compatibles and quirks by family name - Fixed kbuild test robot warnings - renamed CLK_NUMBER to CLK_NUMBER_WITHOUT_ROT and introduced CLK_NUMBER_WITH_ROT - removed "inline" from functions in c file - used regmap_bulk_write() for writing DE3 CSC table - DE3 specific macros have "DE3_" prefix now - reworked DE2/3 mixer registers initialization - removed writing to edge detection registers because functionality is not used Icenowy Zheng (5): dt-bindings: bus: add H6 DE3 bus binding dt-bindings: display: sunxi: add DT binding for Allwinner H6 DW HDMI drm: sun4i: add quirks for TCON TOP dt-bindings: display: sun4i-drm: document H6 TCON TOP drm: sun4i: add support for H6 TCON TOP Jernej Skrabec (23): clk: sunxi-ng: Adjust MP clock parent rate when allowed clk: sunxi-ng: Use u64 for calculation of NM rate clk: sunxi-ng: h6: Set video PLLs limits dt-bindings: clock: sun8i-de2: Add H6 DE3 clock description clk: sunxi-ng: Add support for H6 DE3 clocks dt-bindings: display: sun4i-drm: Add H6 display engine compatibles drm/sun4i: Add compatible for H6 display engine drm/sun4i: Rework DE2 register defines drm/sun4i: Fix DE2 mixer size drm/sun4i: Disable unused DE2 sub-engines drm/sun4i: Add basic support for DE3 drm/sun4i: Add support for H6 DE3 mixer 0 drm/bridge/synopsys: dw-hdmi: Enable workaround for v2.12a drm/sun4i: Not all DW HDMI controllers has scrambled addresses drm/sun4i: dw-hdmi: Make mode_valid function configurable drm/sun4i: dw-hdmi: Add quirk for setting TMDS clock drm/sun4i: Add support for H6 DW HDMI controller drm/sun4i: dw-hdmi-phy: Reorder quirks by family drm/sun4i: Add support for Synopsys HDMI PHY drm/sun4i: Add support for H6 HDMI PHY drm/sun4i: Initialize registers in tcon-top driver arm64: dts: allwinner: h6: Add HDMI pipeline arm64: dts: allwinner: h6: Enable HDMI output on Pine H64 board .../bindings/bus/sun50i-de2-bus.txt | 9 +- .../devicetree/bindings/clock/sun8i-de2.txt | 5 +- .../bindings/display/sunxi/sun4i-drm.txt | 30 ++- .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 25 +++ arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 201 ++ drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 4 + drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 71 ++- drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 4 +- drivers/clk/sunxi-ng/ccu_mp.c | 64 +- drivers/clk/sunxi-ng/ccu_nm.c | 18 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + drivers/gpu/drm/sun4i/sun8i_csc.c | 83 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 45 +++- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 14 +- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c| 201 -- drivers/gpu/drm/sun4i/sun8i_mixer.c | 57 - drivers/gpu/drm/sun4i/sun8i_mixer.h | 80 +-- drivers/gpu/drm/sun4i/sun8i_tcon_top.c| 52 - drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 47 ++-- drivers/gpu/drm/sun4i/sun8i_ui_layer.h| 37 ++-- drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 47 ++-- drivers/gpu/drm/sun4i/sun8i_ui_scaler.h | 28 +-- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 55 +++-- drivers/gpu/drm/sun4i/sun8i_vi_layer.h| 25 ++- drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 70 --
[PATCH v3 01/28] dt-bindings: bus: add H6 DE3 bus binding
From: Icenowy Zheng The Allwinner H6 DE3 bus is similar to the A64 DE2 one. Add its compatible string with the A64 string as fallback to the binding. Some description of the binding is modified to make it more generic. Reviewed-by: Rob Herring Signed-off-by: Icenowy Zheng [Fixed compatible name] Signed-off-by: Jernej Skrabec --- Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt b/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt index 87dfb33fb3be..b9d533717dff 100644 --- a/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt +++ b/Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt @@ -1,11 +1,14 @@ -Device tree bindings for Allwinner A64 DE2 bus +Device tree bindings for Allwinner DE2/3 bus The Allwinner A64 DE2 is on a special bus, which needs a SRAM region (SRAM C) -to be claimed for enabling the access. +to be claimed for enabling the access. The DE3 on Allwinner H6 is at the same +situation, and the binding also applies. Required properties: - - compatible: Should contain "allwinner,sun50i-a64-de2" + - compatible: Should be one of: + - "allwinner,sun50i-a64-de2" + - "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2" - reg:A resource specifier for the register space - #address-cells: Must be set to 1 - #size-cells:Must be set to 1 -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/28] drm/sun4i: Not all DW HDMI controllers has scrambled addresses
Currently supported Allwinner SoCs with DW HDMI controller have
scrambled addresses and read lock. However, that is not true in general.
For example, A80 and H6 have normal addresses and normal read access.
Move code for unscrambling addresses and unlocking read access to it's
own function and call it from init function.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 471993097ced..365cb5a9fb77 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -279,8 +279,21 @@ static const struct dw_hdmi_phy_ops sun8i_hdmi_phy_ops = {
.setup_hpd = _hdmi_phy_setup_hpd,
};
+static void sun8i_hdmi_phy_unlock(struct sun8i_hdmi_phy *phy)
+{
+ /* enable read access to HDMI controller */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_READ_EN_REG,
+SUN8I_HDMI_PHY_READ_EN_MAGIC);
+
+ /* unscramble register offsets */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_UNSCRAMBLE_REG,
+SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC);
+}
+
static void sun8i_hdmi_phy_init_a83t(struct sun8i_hdmi_phy *phy)
{
+ sun8i_hdmi_phy_unlock(phy);
+
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK,
SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK);
@@ -298,6 +311,8 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy
*phy)
{
unsigned int val;
+ sun8i_hdmi_phy_unlock(phy);
+
regmap_write(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG, 0);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
SUN8I_HDMI_PHY_ANA_CFG1_ENBI,
@@ -372,14 +387,6 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy
*phy)
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy)
{
- /* enable read access to HDMI controller */
- regmap_write(phy->regs, SUN8I_HDMI_PHY_READ_EN_REG,
-SUN8I_HDMI_PHY_READ_EN_MAGIC);
-
- /* unscramble register offsets */
- regmap_write(phy->regs, SUN8I_HDMI_PHY_UNSCRAMBLE_REG,
-SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC);
-
phy->variant->phy_init(phy);
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/28] drm/bridge/synopsys: dw-hdmi: Enable workaround for v2.12a
It turns out that even new DW HDMI controllers exhibits same magenta line issues as older versions. Enable workaround for v2.12a. Reviewed-by: Chen-Yu Tsai Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 5971976284bf..df1c7a2d6961 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1664,6 +1664,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi) case 0x131a: case 0x132a: case 0x201a: + case 0x212a: count = 1; break; default: -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/28] drm/sun4i: Fix DE2 mixer size
DE2 mixer is always 0x6000 bytes in size on all known SoCs. While at it, introduce a macro for that. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +- drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 6129c350f7bd..6769ec08c0d3 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -460,7 +460,7 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, base = sun8i_blender_base(mixer); /* Reset the registers */ - for (i = 0x0; i < 0x2; i += 4) + for (i = 0; i < DE2_MIXER_UNIT_SIZE; i += 4) regmap_write(mixer->engine.regs, i, 0); /* Enable the mixer */ diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 025550a1f539..09e0f4428c1e 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -29,6 +29,8 @@ #define SUN8I_MIXER_GLOBAL_DBUFF_ENABLEBIT(0) +#define DE2_MIXER_UNIT_SIZE0x6000 + #define DE2_BLD_BASE 0x1000 #define DE2_CH_BASE0x2000 #define DE2_CH_SIZE0x1000 -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 25/28] dt-bindings: display: sun4i-drm: document H6 TCON TOP
From: Icenowy Zheng Allwinner H6 SoC has a cut down version of TCON TOP. Add binding documentation for it. Reviewed-by: Rob Herring Signed-off-by: Icenowy Zheng [expanded description] Signed-off-by: Jernej Skrabec --- .../bindings/display/sunxi/sun4i-drm.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 478b288eebd9..f426bdb42f18 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -228,24 +228,26 @@ It allows display pipeline to be configured in very different ways: \ [3] TCON-TV1 [1] - TVE1/RGB Note that both TCON TOP references same physical unit. Both mixers can be -connected to any TCON. +connected to any TCON. Not all TCON TOP variants support all features. Required properties: - compatible: value must be one of: * allwinner,sun8i-r40-tcon-top +* allwinner,sun50i-h6-tcon-top - reg: base address and size of the memory-mapped region. - clocks: phandle to the clocks feeding the TCON TOP * bus: TCON TOP interface clock * tcon-tv0: TCON TV0 clock -* tve0: TVE0 clock -* tcon-tv1: TCON TV1 clock -* tve1: TVE0 clock -* dsi: MIPI DSI clock +* tve0: TVE0 clock (R40 only) +* tcon-tv1: TCON TV1 clock (R40 only) +* tve1: TVE0 clock (R40 only) +* dsi: MIPI DSI clock (R40 only) - clock-names: clock name mentioned above - resets: phandle to the reset line driving the TCON TOP - #clock-cells : must contain 1 - clock-output-names: Names of clocks created for TCON TV0 channel clock, -TCON TV1 channel clock and DSI channel clock, in that order. +TCON TV1 channel clock (R40 only) and DSI channel clock (R40 only), in +that order. - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. 6 ports should -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon vs radeonfb Mobility quirks (Thinkpad X32)
My Thinkpad X32 (r100, Mobility M6) can't suspend or hibernate
with KMS using the "radeon" driver. "radeonfb" and the VESA
fallback (no KMS) are both fine.
It seems to be the same bug as:
https://bugs.freedesktop.org/show_bug.cgi?id=38554
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583120
The problem manifests in the console and inside X11,
and with 0 or 3 in /proc/sys/kernel/acpi_video_flags.
"radeontool light off" to disable the backlight doesn't
help, either (no VGA plugged in)
Looking at drivers/video/fbdev/aty/radeon_pm.c, I notice it sets
a D2 sleep mode for my X32:
BUGFIX("IBM Thinkpad X31/X32",
PCI_VENDOR_ID_IBM, 0x052f,
radeon_pm_d2, NULL),
Which I suspect is what allows "radeonfb" to work for me
But I can't find the corresponding quirk in drivers/gpu/drm/radeon/,
so I now believe a missing quirk is the cause of this problem
with the "radeon" driver.
I poked around but couldn't figure out what changes to make to
the "radeon" driver to enable the corresponding, but I'm willing
to test patches.
Setting "dynpm" in /sys/**/power_method didn't seem to change
things, either.
Help greatly appreaciated. Thanks
I've mainly been using the X32 as a server this decade so didn't
use suspend/hibernate so I didn't investigate until recently
(because my netbook died).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 22/28] drm/sun4i: Add support for H6 HDMI PHY
H6 has Synopsys DWC HDMI 2.0 TX PHY.
There is no freely available documentation for it, only code found in
BSP kernel. However, judging by the code, PHY is very similar to older
Synopsys HDMI PHY described in i.MX6 documentation. Most registers seem
to be the same.
According to i.MX6 documentation, mpll settings are based on pixel clock
and are not specific to each SoC. Because of that, mpll table in this
commit is based on that documentation and not on BSP code. Other PHY
settings were derived from BSP PHY driver code.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 137 +
1 file changed, 137 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 635825b55648..66ea3a902e36 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -14,6 +14,122 @@
*/
#define I2C_ADDR 0x69
+static const struct dw_hdmi_mpll_config sun50i_h6_mpll_cfg[] = {
+ {
+ 30666000, {
+ { 0x00b3, 0x },
+ { 0x2153, 0x },
+ { 0x40f3, 0x },
+ },
+ }, {
+ 3680, {
+ { 0x00b3, 0x },
+ { 0x2153, 0x },
+ { 0x40a2, 0x0001 },
+ },
+ }, {
+ 4600, {
+ { 0x00b3, 0x },
+ { 0x2142, 0x0001 },
+ { 0x40a2, 0x0001 },
+ },
+ }, {
+ 61333000, {
+ { 0x0072, 0x0001 },
+ { 0x2142, 0x0001 },
+ { 0x40a2, 0x0001 },
+ },
+ }, {
+ 7360, {
+ { 0x0072, 0x0001 },
+ { 0x2142, 0x0001 },
+ { 0x4061, 0x0002 },
+ },
+ }, {
+ 9200, {
+ { 0x0072, 0x0001 },
+ { 0x2145, 0x0002 },
+ { 0x4061, 0x0002 },
+ },
+ }, {
+ 122666000, {
+ { 0x0051, 0x0002 },
+ { 0x2145, 0x0002 },
+ { 0x4061, 0x0002 },
+ },
+ }, {
+ 14720, {
+ { 0x0051, 0x0002 },
+ { 0x2145, 0x0002 },
+ { 0x4064, 0x0003 },
+ },
+ }, {
+ 18400, {
+ { 0x0051, 0x0002 },
+ { 0x214c, 0x0003 },
+ { 0x4064, 0x0003 },
+ },
+ }, {
+ 22000, {
+ { 0x0040, 0x0003 },
+ { 0x214c, 0x0003 },
+ { 0x4064, 0x0003 },
+ },
+ }, {
+ 27200, {
+ { 0x0040, 0x0003 },
+ { 0x214c, 0x0003 },
+ { 0x5a64, 0x0003 },
+ },
+ }, {
+ 34000, {
+ { 0x0040, 0x0003 },
+ { 0x3b4c, 0x0003 },
+ { 0x5a64, 0x0003 },
+ },
+ }, {
+ 59400, {
+ { 0x1a40, 0x0003 },
+ { 0x3b4c, 0x0003 },
+ { 0x5a64, 0x0003 },
+ },
+ }, {
+ ~0UL, {
+ { 0x, 0x },
+ { 0x, 0x },
+ { 0x, 0x },
+ },
+ }
+};
+
+static const struct dw_hdmi_curr_ctrl sun50i_h6_cur_ctr[] = {
+ /* pixelclkbpp8bpp10 bpp12 */
+ { 25175000, { 0x, 0x, 0x }, },
+ { 2700, { 0x0012, 0x, 0x }, },
+ { 5940, { 0x0008, 0x0008, 0x0008 }, },
+ { 7200, { 0x0008, 0x0008, 0x001b }, },
+ { 7425, { 0x0013, 0x0013, 0x0013 }, },
+ { 9000, { 0x0008, 0x001a, 0x001b }, },
+ { 11880, { 0x001b, 0x001a, 0x001b }, },
+ { 14400, { 0x001b, 0x001a, 0x0034 }, },
+ { 18000, { 0x001b, 0x0033, 0x0034 }, },
+ { 21600, { 0x0036, 0x0033, 0x0034 }, },
+ { 23760, { 0x0036, 0x0033, 0x001b }, },
+ { 28800, { 0x0036, 0x001b, 0x001b }, },
+ { 29700, { 0x0019, 0x001b, 0x0019 }, },
+ { 33000, { 0x0036, 0x001b, 0x001b }, },
+ { 59400, { 0x003f, 0x001b, 0x001b }, },
+ { ~0UL, { 0x, 0x, 0x }, }
+};
+
+static const struct dw_hdmi_phy_config sun50i_h6_phy_config[] = {
+ /*pixelclk symbol term vlev*/
+ { 7425, 0x8009, 0x0004, 0x0232},
+ { 14850, 0x8029, 0x0004, 0x0273},
+ { 59400, 0x8039, 0x0004, 0x014a},
+ { ~0UL, 0x, 0x, 0x}
+};
+
static int
[PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
Currently MP clocks don't consider adjusting parent rate even if they
are allowed to do so. Such behaviour considerably lowers amount of
possible rates, which is very inconvenient when such clock is used for
pixel clock, for example.
In order to improve the situation, adjusting parent rate is considered
when allowed.
This code is inspired by clk_divider_bestdiv() function, which does
basically the same thing for different clock type.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_mp.c | 64 +--
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index 5d0af4051737..0357349eb767 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -40,6 +40,61 @@ static void ccu_mp_find_best(unsigned long parent, unsigned
long rate,
*p = best_p;
}
+static unsigned long ccu_mp_find_best_with_parent_adj(struct clk_hw *hw,
+ unsigned long *parent,
+ unsigned long rate,
+ unsigned int max_m,
+ unsigned int max_p)
+{
+ unsigned long parent_rate_saved;
+ unsigned long parent_rate, now;
+ unsigned long best_rate = 0;
+ unsigned int _m, _p, div;
+ unsigned long maxdiv;
+
+ parent_rate_saved = *parent;
+
+ /*
+* The maximum divider we can use without overflowing
+* unsigned long in rate * m * p below
+*/
+ maxdiv = max_m * max_p;
+ maxdiv = min(ULONG_MAX / rate, maxdiv);
+
+ for (_p = 1; _p <= max_p; _p <<= 1) {
+ for (_m = 1; _m <= max_m; _m++) {
+ div = _m * _p;
+
+ if (div > maxdiv)
+ break;
+
+ if (rate * div == parent_rate_saved) {
+ /*
+* It's the most ideal case if the requested
+* rate can be divided from parent clock without
+* needing to change parent rate, so return the
+* divider immediately.
+*/
+ *parent = parent_rate_saved;
+ return rate;
+ }
+
+ parent_rate = clk_hw_round_rate(hw, rate * div);
+ now = parent_rate / div;
+
+ if (now <= rate && now > best_rate) {
+ best_rate = now;
+ *parent = parent_rate;
+
+ if (now == rate)
+ return rate;
+ }
+ }
+ }
+
+ return best_rate;
+}
+
static unsigned long ccu_mp_round_rate(struct ccu_mux_internal *mux,
struct clk_hw *hw,
unsigned long *parent_rate,
@@ -56,8 +111,13 @@ static unsigned long ccu_mp_round_rate(struct
ccu_mux_internal *mux,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
- ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
- rate = *parent_rate / p / m;
+ if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
+ ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
+ rate = *parent_rate / p / m;
+ } else {
+ rate = ccu_mp_find_best_with_parent_adj(hw, parent_rate, rate,
+ max_m, max_p);
+ }
if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate /= cmp->fixed_post_div;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/28] drm/sun4i: Rework DE2 register defines
Most, if not all, registers found in DE2 still exists in DE3. However, units are on different base addresses. To prepare for addition of DE3 support, registers macros are reworked so they take base address as parameter. Signed-off-by: Jernej Skrabec [rebased] Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun8i_mixer.c | 14 --- drivers/gpu/drm/sun4i/sun8i_mixer.h | 44 +--- drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 47 ++ drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 37 + drivers/gpu/drm/sun4i/sun8i_ui_scaler.c | 41 +++ drivers/gpu/drm/sun4i/sun8i_ui_scaler.h | 27 + drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 47 ++ drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 23 ++- drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 53 +++-- drivers/gpu/drm/sun4i/sun8i_vi_scaler.h | 45 ++--- 10 files changed, 219 insertions(+), 159 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 8b3d02b146b7..6129c350f7bd 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c @@ -368,6 +368,7 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, struct sun8i_mixer *mixer; struct resource *res; void __iomem *regs; + unsigned int base; int plane_cnt; int i, ret; @@ -456,6 +457,8 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, list_add_tail(>engine.list, >engine_list); + base = sun8i_blender_base(mixer); + /* Reset the registers */ for (i = 0x0; i < 0x2; i += 4) regmap_write(mixer->engine.regs, i, 0); @@ -465,24 +468,25 @@ static int sun8i_mixer_bind(struct device *dev, struct device *master, SUN8I_MIXER_GLOBAL_CTL_RT_EN); /* Set background color to black */ - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR, + regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR(base), SUN8I_MIXER_BLEND_COLOR_BLACK); /* * Set fill color of bottom plane to black. Generally not needed * except when VI plane is at bottom (zpos = 0) and enabled. */ - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL, + regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base), SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0)); - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0), + regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(base, 0), SUN8I_MIXER_BLEND_COLOR_BLACK); plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num; for (i = 0; i < plane_cnt; i++) - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(i), + regmap_write(mixer->engine.regs, +SUN8I_MIXER_BLEND_MODE(base, i), SUN8I_MIXER_BLEND_MODE_DEF); - regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL, + regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base), SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 0); return 0; diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 406c42e752d7..025550a1f539 100644 --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h @@ -29,20 +29,24 @@ #define SUN8I_MIXER_GLOBAL_DBUFF_ENABLEBIT(0) -#define SUN8I_MIXER_BLEND_PIPE_CTL 0x1000 -#define SUN8I_MIXER_BLEND_ATTR_FCOLOR(x) (0x1004 + 0x10 * (x) + 0x0) -#define SUN8I_MIXER_BLEND_ATTR_INSIZE(x) (0x1004 + 0x10 * (x) + 0x4) -#define SUN8I_MIXER_BLEND_ATTR_COORD(x)(0x1004 + 0x10 * (x) + 0x8) -#define SUN8I_MIXER_BLEND_ROUTE0x1080 -#define SUN8I_MIXER_BLEND_PREMULTIPLY 0x1084 -#define SUN8I_MIXER_BLEND_BKCOLOR 0x1088 -#define SUN8I_MIXER_BLEND_OUTSIZE 0x108c -#define SUN8I_MIXER_BLEND_MODE(x) (0x1090 + 0x04 * (x)) -#define SUN8I_MIXER_BLEND_CK_CTL 0x10b0 -#define SUN8I_MIXER_BLEND_CK_CFG 0x10b4 -#define SUN8I_MIXER_BLEND_CK_MAX(x)(0x10c0 + 0x04 * (x)) -#define SUN8I_MIXER_BLEND_CK_MIN(x)(0x10e0 + 0x04 * (x)) -#define SUN8I_MIXER_BLEND_OUTCTL 0x10fc +#define DE2_BLD_BASE 0x1000 +#define DE2_CH_BASE0x2000 +#define DE2_CH_SIZE0x1000 + +#define SUN8I_MIXER_BLEND_PIPE_CTL(base) ((base) + 0) +#define SUN8I_MIXER_BLEND_ATTR_FCOLOR(base, x) ((base) + 0x4 + 0x10 * (x)) +#define SUN8I_MIXER_BLEND_ATTR_INSIZE(base, x) ((base) + 0x8 + 0x10 * (x)) +#define SUN8I_MIXER_BLEND_ATTR_COORD(base, x) ((base) + 0xc + 0x10 *
[PATCH v3 04/28] clk: sunxi-ng: h6: Set video PLLs limits
Video PLL factors can be set in a way that final PLL rate is outside
stable range. H6 user manual specifically says that N factor should not
be below 12. While it doesn't says anything about maximum stable rate, it
is clear that PLL doesn't work at 6.096 GHz (254 * 24 MHz).
Set minimum allowed PLL video rate to 288 MHz (12 * 24 MHz) and maximum
to 2.4 GHz, which is maximum in BSP driver.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
index 2193e1495086..19ff09f610e4 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
@@ -120,6 +120,8 @@ static struct ccu_nm pll_video0_clk = {
.n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
.m = _SUNXI_CCU_DIV(1, 1), /* input divider */
.fixed_post_div = 4,
+ .min_rate = 28800,
+ .max_rate = 24UL,
.common = {
.reg= 0x040,
.features = CCU_FEATURE_FIXED_POSTDIV,
@@ -136,6 +138,8 @@ static struct ccu_nm pll_video1_clk = {
.n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
.m = _SUNXI_CCU_DIV(1, 1), /* input divider */
.fixed_post_div = 4,
+ .min_rate = 28800,
+ .max_rate = 24UL,
.common = {
.reg= 0x048,
.features = CCU_FEATURE_FIXED_POSTDIV,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/sun4i: sun6i_mipi_dsi: Compute burst mode loop N1 instruction delay
Hi, Jagan,
On 11/3/18 1:08 PM, Jagan Teki wrote:
Loop N1 instruction delay for burst mode lcd panel are
computed as per BSP code.
Reference code is available in BSP
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_dev[sel]->dsi_inst_loop_num.bits.loop_n1=
(panel->lcd_ht-panel->lcd_x)*(150)/(panel->lcd_dclk_freq*8) - 50;
=> (((mode->htotal - mode->hdisplay) * 150) / ((mode->clock / 1000) * 8)) - 50;
So use the similar computation for loop N1 delay.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 86430efd9054..da152c21ec62 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -394,7 +394,14 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
- u16 delay = 50 - 1;
+ struct mipi_dsi_device *device = dsi->device;
+ u16 delay;
+
+ if (device->mode_flags == MIPI_DSI_MODE_VIDEO_BURST)
+ delay = (((mode->htotal - mode->hdisplay) * 150) /
+ ((mode->clock / 1000) * 8)) - 50;
+ else
+ delay = 50 - 1;
regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_NUM_REG(0),
SUN6I_DSI_INST_LOOP_NUM_N0(50 - 1) |
is this patch series comes in addition to the previous MIPI DSI series
or in its stead?
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/28] clk: sunxi-ng: Use u64 for calculation of NM rate
Allwinner H6 SoC has multiplier N range between 1 and 254. Since parent
rate is 24MHz, intermediate result when calculating final rate easily
overflows 32 bit variable.
Because of that, introduce function for calculating clock rate which
uses 64 bit variable for intermediate result.
Fixes: 6174a1e24b0d ("clk: sunxi-ng: Add N-M-factor clock support")
Fixes: ee28648cb2b4 ("clk: sunxi-ng: Remove the use of rational computations")
CC:
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nm.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
index 6fe3c14f7b2d..424d8635b053 100644
--- a/drivers/clk/sunxi-ng/ccu_nm.c
+++ b/drivers/clk/sunxi-ng/ccu_nm.c
@@ -19,6 +19,17 @@ struct _ccu_nm {
unsigned long m, min_m, max_m;
};
+static unsigned long ccu_nm_calc_rate(unsigned long parent,
+ unsigned long n, unsigned long m)
+{
+ u64 rate = parent;
+
+ rate *= n;
+ do_div(rate, m);
+
+ return rate;
+}
+
static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
struct _ccu_nm *nm)
{
@@ -28,7 +39,8 @@ static void ccu_nm_find_best(unsigned long parent, unsigned
long rate,
for (_n = nm->min_n; _n <= nm->max_n; _n++) {
for (_m = nm->min_m; _m <= nm->max_m; _m++) {
- unsigned long tmp_rate = parent * _n / _m;
+ unsigned long tmp_rate = ccu_nm_calc_rate(parent,
+ _n, _m);
if (tmp_rate > rate)
continue;
@@ -100,7 +112,7 @@ static unsigned long ccu_nm_recalc_rate(struct clk_hw *hw,
if (ccu_sdm_helper_is_enabled(>common, >sdm))
rate = ccu_sdm_helper_read_rate(>common, >sdm, m, n);
else
- rate = parent_rate * n / m;
+ rate = ccu_nm_calc_rate(parent_rate, n, m);
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate /= nm->fixed_post_div;
@@ -149,7 +161,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned
long rate,
_nm.max_m = nm->m.max ?: 1 << nm->m.width;
ccu_nm_find_best(*parent_rate, rate, &_nm);
- rate = *parent_rate * _nm.n / _nm.m;
+ rate = ccu_nm_calc_rate(*parent_rate, _nm.n, _nm.m);
if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
rate /= nm->fixed_post_div;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/28] dt-bindings: clock: sun8i-de2: Add H6 DE3 clock description
This commit adds necessary description and dt includes for H6 DE3 clock. It is very similar to others, but memory region has some additional registers not found in DE2. Reviewed-by: Rob Herring Signed-off-by: Jernej Skrabec --- Documentation/devicetree/bindings/clock/sun8i-de2.txt | 5 +++-- include/dt-bindings/clock/sun8i-de2.h | 3 +++ include/dt-bindings/reset/sun8i-de2.h | 1 + 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt index e94582e8b8a9..41a52c2acffd 100644 --- a/Documentation/devicetree/bindings/clock/sun8i-de2.txt +++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt @@ -1,5 +1,5 @@ -Allwinner Display Engine 2.0 Clock Control Binding --- +Allwinner Display Engine 2.0/3.0 Clock Control Binding +-- Required properties : - compatible: must contain one of the following compatibles: @@ -8,6 +8,7 @@ Required properties : - "allwinner,sun8i-v3s-de2-clk" - "allwinner,sun50i-a64-de2-clk" - "allwinner,sun50i-h5-de2-clk" + - "allwinner,sun50i-h6-de3-clk" - reg: Must contain the registers base address and length - clocks: phandle to the clocks feeding the display engine subsystem. diff --git a/include/dt-bindings/clock/sun8i-de2.h b/include/dt-bindings/clock/sun8i-de2.h index 3bed63b524aa..7768f73b051e 100644 --- a/include/dt-bindings/clock/sun8i-de2.h +++ b/include/dt-bindings/clock/sun8i-de2.h @@ -15,4 +15,7 @@ #define CLK_MIXER1 7 #define CLK_WB 8 +#define CLK_BUS_ROT9 +#define CLK_ROT10 + #endif /* _DT_BINDINGS_CLOCK_SUN8I_DE2_H_ */ diff --git a/include/dt-bindings/reset/sun8i-de2.h b/include/dt-bindings/reset/sun8i-de2.h index 9526017432f0..1c36a6ac86d6 100644 --- a/include/dt-bindings/reset/sun8i-de2.h +++ b/include/dt-bindings/reset/sun8i-de2.h @@ -10,5 +10,6 @@ #define RST_MIXER0 0 #define RST_MIXER1 1 #define RST_WB 2 +#define RST_ROT3 #endif /* _DT_BINDINGS_RESET_SUN8I_DE2_H_ */ -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 21/28] drm/sun4i: Add support for Synopsys HDMI PHY
Currently sun8i-hdmi-phy driver supports only custom PHYs connected to
DW HDMI controller. Since newest Allwinner SoCs have unmodified Synopsys
PHY, driver has to be reorganized to support them.
Variant structure is expanded to allow differentiation between custom
and Sysnopsys PHYs and to hold Synopsys PHY settings.
Since DW HDMI bridge platform data has different fields for custom and
Sysnopsys PHY, function sun8i_hdmi_phy_get_ops() is replaced with
sun8i_hdmi_phy_set_ops().
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 4 +---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 7 ++-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 19 +--
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 445cca8d9a26..dc47720c99ba 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -184,9 +184,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
sun8i_hdmi_phy_init(hdmi->phy);
plat_data->mode_valid = hdmi->quirks->mode_valid;
- plat_data->phy_ops = sun8i_hdmi_phy_get_ops();
- plat_data->phy_name = "sun8i_dw_hdmi_phy";
- plat_data->phy_data = hdmi->phy;
+ sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
platform_set_drvdata(pdev, hdmi);
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 49c9e80c46ea..720c5aa8adc1 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -150,6 +150,10 @@ struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
bool has_phy_clk;
bool has_second_pll;
+ unsigned int is_custom_phy : 1;
+ const struct dw_hdmi_curr_ctrl *cur_ctr;
+ const struct dw_hdmi_mpll_config *mpll_cfg;
+ const struct dw_hdmi_phy_config *phy_cfg;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -198,7 +202,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct
device_node *node);
void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
-const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
+void sun8i_hdmi_phy_set_ops(struct sun8i_hdmi_phy *phy,
+ struct dw_hdmi_plat_data *plat_data);
int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
bool second_parent);
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index adc3ba7df7e3..635825b55648 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -390,9 +390,20 @@ void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy)
phy->variant->phy_init(phy);
}
-const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void)
+void sun8i_hdmi_phy_set_ops(struct sun8i_hdmi_phy *phy,
+ struct dw_hdmi_plat_data *plat_data)
{
- return _hdmi_phy_ops;
+ struct sun8i_hdmi_phy_variant *variant = phy->variant;
+
+ if (variant->is_custom_phy) {
+ plat_data->phy_ops = _hdmi_phy_ops;
+ plat_data->phy_name = "sun8i_dw_hdmi_phy";
+ plat_data->phy_data = phy;
+ } else {
+ plat_data->mpll_cfg = variant->mpll_cfg;
+ plat_data->cur_ctr = variant->cur_ctr;
+ plat_data->phy_config = variant->phy_cfg;
+ }
}
static struct regmap_config sun8i_hdmi_phy_regmap_config = {
@@ -404,6 +415,7 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
};
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
+ .is_custom_phy = true,
.phy_init = _hdmi_phy_init_a83t,
.phy_disable = _hdmi_phy_disable_a83t,
.phy_config = _hdmi_phy_config_a83t,
@@ -411,6 +423,7 @@ static const struct sun8i_hdmi_phy_variant
sun8i_a83t_hdmi_phy = {
static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
.has_phy_clk = true,
+ .is_custom_phy = true,
.phy_init = _hdmi_phy_init_h3,
.phy_disable = _hdmi_phy_disable_h3,
.phy_config = _hdmi_phy_config_h3,
@@ -419,6 +432,7 @@ static const struct sun8i_hdmi_phy_variant
sun8i_h3_hdmi_phy = {
static const struct sun8i_hdmi_phy_variant sun8i_r40_hdmi_phy = {
.has_phy_clk = true,
.has_second_pll = true,
+ .is_custom_phy = true,
.phy_init = _hdmi_phy_init_h3,
.phy_disable = _hdmi_phy_disable_h3,
.phy_config = _hdmi_phy_config_h3,
@@ -426,6 +440,7 @@ static const struct sun8i_hdmi_phy_variant
sun8i_r40_hdmi_phy = {
static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
.has_phy_clk = true,
+ .is_custom_phy = true,
.phy_init = _hdmi_phy_init_h3,
Re: [PATCH v3] drm/cma-helper: Fix crash in fbdev error path
To be exact, the issue does not happen in case I use default kernel
config but only with the custom one.
On 10/2/18 2:14 PM, Noralf Trønnes wrote:
Den 01.10.2018 21.45, skrev Noralf Trønnes:
Sergey Suloev reported a crash happening in drm_client_dev_hotplug()
when fbdev had failed to register.
[ 9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create
component debugfs directory
[ 9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <->
3f902000.hdmi mapping ok
[ 9.155184] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
[ 9.166544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops
[vc4])
[ 9.173840] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops
[vc4])
[ 9.181029] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops
[vc4])
[ 9.188519] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops
[vc4])
[ 9.195690] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.203523] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.215032] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.274785] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops
[vc4])
[ 9.290246] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on
minor 0
[ 9.297464] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[ 9.304600] [drm] Driver supports precise vblank timestamp query.
[ 9.382856] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup
[drm_kms_helper]] *ERROR* Failed to set fbdev configuration
[ 10.404937] Unable to handle kernel paging request at virtual
address 00330a656369768a
[ 10.441620] [00330a656369768a] address between user and kernel
address ranges
[ 10.449087] Internal error: Oops: 9604 [#1] PREEMPT SMP
[ 10.454762] Modules linked in: brcmfmac vc4 drm_kms_helper
cfg80211 drm rfkill smsc95xx brcmutil usbnet
drm_panel_orientation_quirks raspberrypi_hwmon bcm2835_dma crc32_ce
pwm_bcm2835 bcm2835_rng virt_dma rng_core i2c_bcm2835 ip_tables
x_tables ipv6
[ 10.477296] CPU: 2 PID: 45 Comm: kworker/2:1 Not tainted
4.19.0-rc5 #3
[ 10.483934] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 10.489966] Workqueue: events output_poll_execute [drm_kms_helper]
[ 10.596515] Process kworker/2:1 (pid: 45, stack limit =
0x7e8924dc)
[ 10.603590] Call trace:
[ 10.606259] drm_client_dev_hotplug+0x5c/0xb0 [drm]
[ 10.611303] drm_kms_helper_hotplug_event+0x30/0x40 [drm_kms_helper]
[ 10.617849] output_poll_execute+0xc4/0x1e0 [drm_kms_helper]
[ 10.623616] process_one_work+0x1c8/0x318
[ 10.627695] worker_thread+0x48/0x428
[ 10.631420] kthread+0xf8/0x128
[ 10.634615] ret_from_fork+0x10/0x18
[ 10.638255] Code: 54000220 f9401261 aa1303e0 b4000141 (f9400c21)
[ 10.644456] ---[ end trace c75b4a4b0e141908 ]---
The reason for this is that drm_fbdev_cma_init() removes the drm_client
when fbdev registration fails, but it doesn't remove the client from the
drm_device client list. So the client list now has a pointer that points
into the unknown and we have a 'use after free' situation.
Split drm_client_new() into drm_client_init() and drm_client_add() to
fix
removal in the error path.
Fixes: 894a677f4b3e ("drm/cma-helper: Use the generic fbdev emulation")
Reported-by: Sergey Suloev
Cc: Stefan Wahren
Cc: Eric Anholt
Cc: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Applied to drm-misc-fixes, thanks for the review.
Noralf.
Changes since version 2:
- Fix drm_client_new() ref in docs (Daniel)
- Expand drm_client_add() docs (Daniel)
Changes since version 1:
- Split drm_client_new() instead of letting drm_client hang around
(Daniel)
drivers/gpu/drm/drm_client.c | 35
++-
drivers/gpu/drm/drm_fb_cma_helper.c | 4 +++-
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
include/drm/drm_client.h | 5 +++--
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 17d9a64e885e..fc03d26fcacc 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -63,20 +63,21 @@ static void drm_client_close(struct
drm_client_dev *client)
EXPORT_SYMBOL(drm_client_close);
/**
- * drm_client_new - Create a DRM client
+ * drm_client_init - Initialise a DRM client
* @dev: DRM device
* @client: DRM client
* @name: Client name
* @funcs: DRM client functions (optional)
*
+ * This initialises the client and opens a _file. Use
drm_client_add() to complete the process.
* The caller needs to hold a reference on @dev before calling this
function.
* The client is freed when the _device is unregistered. See
drm_client_release().
*
* Returns:
* Zero on success or negative error code on failure.
*/
-int drm_client_new(struct drm_device *dev, struct drm_client_dev
*client,
- const char *name, const struct drm_client_funcs *funcs)
+int
Re: [PATCH v3] drm/cma-helper: Fix crash in fbdev error path
This doesn't seem to fix the initially reported issue. The problem still
exists with 4.19.
On 10/2/18 2:14 PM, Noralf Trønnes wrote:
Den 01.10.2018 21.45, skrev Noralf Trønnes:
Sergey Suloev reported a crash happening in drm_client_dev_hotplug()
when fbdev had failed to register.
[ 9.124598] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create
component debugfs directory
[ 9.147667] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <->
3f902000.hdmi mapping ok
[ 9.155184] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
[ 9.166544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops
[vc4])
[ 9.173840] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops
[vc4])
[ 9.181029] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops
[vc4])
[ 9.188519] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops
[vc4])
[ 9.195690] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.203523] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.215032] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 9.274785] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops
[vc4])
[ 9.290246] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on
minor 0
[ 9.297464] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[ 9.304600] [drm] Driver supports precise vblank timestamp query.
[ 9.382856] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup
[drm_kms_helper]] *ERROR* Failed to set fbdev configuration
[ 10.404937] Unable to handle kernel paging request at virtual
address 00330a656369768a
[ 10.441620] [00330a656369768a] address between user and kernel
address ranges
[ 10.449087] Internal error: Oops: 9604 [#1] PREEMPT SMP
[ 10.454762] Modules linked in: brcmfmac vc4 drm_kms_helper
cfg80211 drm rfkill smsc95xx brcmutil usbnet
drm_panel_orientation_quirks raspberrypi_hwmon bcm2835_dma crc32_ce
pwm_bcm2835 bcm2835_rng virt_dma rng_core i2c_bcm2835 ip_tables
x_tables ipv6
[ 10.477296] CPU: 2 PID: 45 Comm: kworker/2:1 Not tainted
4.19.0-rc5 #3
[ 10.483934] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 10.489966] Workqueue: events output_poll_execute [drm_kms_helper]
[ 10.596515] Process kworker/2:1 (pid: 45, stack limit =
0x7e8924dc)
[ 10.603590] Call trace:
[ 10.606259] drm_client_dev_hotplug+0x5c/0xb0 [drm]
[ 10.611303] drm_kms_helper_hotplug_event+0x30/0x40 [drm_kms_helper]
[ 10.617849] output_poll_execute+0xc4/0x1e0 [drm_kms_helper]
[ 10.623616] process_one_work+0x1c8/0x318
[ 10.627695] worker_thread+0x48/0x428
[ 10.631420] kthread+0xf8/0x128
[ 10.634615] ret_from_fork+0x10/0x18
[ 10.638255] Code: 54000220 f9401261 aa1303e0 b4000141 (f9400c21)
[ 10.644456] ---[ end trace c75b4a4b0e141908 ]---
The reason for this is that drm_fbdev_cma_init() removes the drm_client
when fbdev registration fails, but it doesn't remove the client from the
drm_device client list. So the client list now has a pointer that points
into the unknown and we have a 'use after free' situation.
Split drm_client_new() into drm_client_init() and drm_client_add() to
fix
removal in the error path.
Fixes: 894a677f4b3e ("drm/cma-helper: Use the generic fbdev emulation")
Reported-by: Sergey Suloev
Cc: Stefan Wahren
Cc: Eric Anholt
Cc: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Applied to drm-misc-fixes, thanks for the review.
Noralf.
Changes since version 2:
- Fix drm_client_new() ref in docs (Daniel)
- Expand drm_client_add() docs (Daniel)
Changes since version 1:
- Split drm_client_new() instead of letting drm_client hang around
(Daniel)
drivers/gpu/drm/drm_client.c | 35
++-
drivers/gpu/drm/drm_fb_cma_helper.c | 4 +++-
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
include/drm/drm_client.h | 5 +++--
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 17d9a64e885e..fc03d26fcacc 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -63,20 +63,21 @@ static void drm_client_close(struct
drm_client_dev *client)
EXPORT_SYMBOL(drm_client_close);
/**
- * drm_client_new - Create a DRM client
+ * drm_client_init - Initialise a DRM client
* @dev: DRM device
* @client: DRM client
* @name: Client name
* @funcs: DRM client functions (optional)
*
+ * This initialises the client and opens a _file. Use
drm_client_add() to complete the process.
* The caller needs to hold a reference on @dev before calling this
function.
* The client is freed when the _device is unregistered. See
drm_client_release().
*
* Returns:
* Zero on success or negative error code on failure.
*/
-int drm_client_new(struct drm_device *dev, struct drm_client_dev
*client,
- const char *name, const struct drm_client_funcs *funcs)
+int drm_client_init(struct drm_device
[PATCH v3 13/28] drm/sun4i: Add support for H6 DE3 mixer 0
Mixer 0 has 1 VI and 3 UI planes, scaler on all planes and can output
4K image @60Hz. It also support 10 bit colors, which are not yet
implemented.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index ca402cf0f5ba..44a9ba7d8433 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -613,6 +613,15 @@ static const struct sun8i_mixer_cfg sun50i_a64_mixer1_cfg
= {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun50i_h6_mixer0_cfg = {
+ .ccsc = 0,
+ .is_de3 = true,
+ .mod_rate = 6,
+ .scaler_mask= 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
static const struct of_device_id sun8i_mixer_of_table[] = {
{
.compatible = "allwinner,sun8i-a83t-de2-mixer-0",
@@ -646,6 +655,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun50i-a64-de2-mixer-1",
.data = _a64_mixer1_cfg,
},
+ {
+ .compatible = "allwinner,sun50i-h6-de3-mixer-0",
+ .data = _h6_mixer0_cfg,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/28] dt-bindings: display: sunxi: add DT binding for Allwinner H6 DW HDMI
From: Icenowy Zheng The Allwinner H6 SoC uses a v2.12a DesignWare HDMI controller, with dedicated CEC and HDCP clocks added; the PHY connected is a standard DesignWare HDMI PHY. Add binding for it. Reviewed-by: Rob Herring Signed-off-by: Icenowy Zheng [added HDCP clock and reset] Signed-off-by: Jernej Skrabec --- .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 62c83b351344..478b288eebd9 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -79,6 +79,7 @@ Required properties: - compatible: value must be one of: * "allwinner,sun8i-a83t-dw-hdmi" * "allwinner,sun50i-a64-dw-hdmi", "allwinner,sun8i-a83t-dw-hdmi" +* "allwinner,sun50i-h6-dw-hdmi" - reg: base address and size of memory-mapped region - reg-io-width: See dw_hdmi.txt. Shall be 1. - interrupts: HDMI interrupt number @@ -86,9 +87,14 @@ Required properties: * iahb: the HDMI bus clock * isfr: the HDMI register clock * tmds: TMDS clock +* cec: HDMI CEC clock (H6 only) +* hdcp: HDCP clock (H6 only) +* hdcp-bus: HDCP bus clock (H6 only) - clock-names: the clock names mentioned above - - resets: phandle to the reset controller - - reset-names: must be "ctrl" + - resets: +* ctrl: HDMI controller reset +* hdcp: HDCP reset (H6 only) + - reset-names: reset names mentioned above - phys: phandle to the DWC HDMI PHY - phy-names: must be "phy" @@ -109,6 +115,7 @@ Required properties: * allwinner,sun8i-h3-hdmi-phy * allwinner,sun8i-r40-hdmi-phy * allwinner,sun50i-a64-hdmi-phy +* allwinner,sun50i-h6-hdmi-phy - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the HDMI PHY * bus: the HDMI PHY interface clock -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 23/28] drm/sun4i: Initialize registers in tcon-top driver
It turns out that TCON TOP registers in H6 SoC have non-zero reset value. This may cause issues if bits are not changed during configuration. To prevent that, initialize registers to 0. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c index 3040a79f298f..37158548b447 100644 --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c @@ -167,6 +167,13 @@ static int sun8i_tcon_top_bind(struct device *dev, struct device *master, goto err_assert_reset; } + /* +* At least on H6, some registers have some bits set by default +* which may cause issues. Clear them here. +*/ + writel(0, regs + TCON_TOP_PORT_SEL_REG); + writel(0, regs + TCON_TOP_GATE_SRC_REG); + /* * TCON TOP has two muxes, which select parent clock for each TCON TV * channel clock. Parent could be either TCON TV or TVE clock. For now -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/28] dt-bindings: display: sun4i-drm: Add H6 display engine compatibles
This commit adds compatibles used in H6 display pipeline, namely for display engine, mixer and TV TCON. H6 display engine is somewhat similar to R40, just less TCONs and mixer support more features. Reviewed-by: Rob Herring Reviewed-by: Chen-Yu Tsai Signed-off-by: Jernej Skrabec --- .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 7854fff4fc16..62c83b351344 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -158,6 +158,7 @@ Required properties: * allwinner,sun9i-a80-tcon-tv * "allwinner,sun50i-a64-tcon-lcd", "allwinner,sun8i-a83t-tcon-lcd" * "allwinner,sun50i-a64-tcon-tv", "allwinner,sun8i-a83t-tcon-tv" + * allwinner,sun50i-h6-tcon-tv, allwinner,sun8i-r40-tcon-tv - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. @@ -381,6 +382,7 @@ Required properties: * allwinner,sun8i-v3s-de2-mixer * allwinner,sun50i-a64-de2-mixer-0 * allwinner,sun50i-a64-de2-mixer-1 +* allwinner,sun50i-h6-de3-mixer-0 - reg: base address and size of the memory-mapped region. - clocks: phandles to the clocks feeding the mixer * bus: the mixer interface clock @@ -415,9 +417,10 @@ Required properties: * allwinner,sun8i-v3s-display-engine * allwinner,sun9i-a80-display-engine * allwinner,sun50i-a64-display-engine +* allwinner,sun50i-h6-display-engine - allwinner,pipelines: list of phandle to the display engine -frontends (DE 1.0) or mixers (DE 2.0) available. +frontends (DE 1.0) or mixers (DE 2.0/3.0) available. Example: -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 24/28] drm: sun4i: add quirks for TCON TOP
From: Icenowy Zheng
Some SoCs, such as H6, doesn't have a full-featured TCON TOP.
Add quirks support for TCON TOP.
Currently the presence of TCON_TV1 and DSI is controlled via the quirks
structure.
Acked-by: Maxime Ripard
Signed-off-by: Icenowy Zheng
[Fixed code style and removed unnecessary initialization]
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 37 +++---
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index 37158548b447..e94e3fb1736b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -9,11 +9,17 @@
#include
#include
#include
+#include
#include
#include
#include "sun8i_tcon_top.h"
+struct sun8i_tcon_top_quirks {
+ bool has_tcon_tv1;
+ bool has_dsi;
+};
+
static bool sun8i_tcon_top_node_is_tcon_top(struct device_node *node)
{
return !!of_match_node(sun8i_tcon_top_of_table, node);
@@ -121,10 +127,13 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
struct platform_device *pdev = to_platform_device(dev);
struct clk_hw_onecell_data *clk_data;
struct sun8i_tcon_top *tcon_top;
+ const struct sun8i_tcon_top_quirks *quirks;
struct resource *res;
void __iomem *regs;
int ret, i;
+ quirks = of_device_get_match_data(>dev);
+
tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
if (!tcon_top)
return -ENOMEM;
@@ -187,15 +196,17 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
_top->reg_lock,
TCON_TOP_TCON_TV0_GATE, 0);
- clk_data->hws[CLK_TCON_TOP_TV1] =
- sun8i_tcon_top_register_gate(dev, "tcon-tv1", regs,
-_top->reg_lock,
-TCON_TOP_TCON_TV1_GATE, 1);
+ if (quirks->has_tcon_tv1)
+ clk_data->hws[CLK_TCON_TOP_TV1] =
+ sun8i_tcon_top_register_gate(dev, "tcon-tv1", regs,
+_top->reg_lock,
+TCON_TOP_TCON_TV1_GATE, 1);
- clk_data->hws[CLK_TCON_TOP_DSI] =
- sun8i_tcon_top_register_gate(dev, "dsi", regs,
-_top->reg_lock,
-TCON_TOP_TCON_DSI_GATE, 2);
+ if (quirks->has_dsi)
+ clk_data->hws[CLK_TCON_TOP_DSI] =
+ sun8i_tcon_top_register_gate(dev, "dsi", regs,
+_top->reg_lock,
+TCON_TOP_TCON_DSI_GATE, 2);
for (i = 0; i < CLK_NUM; i++)
if (IS_ERR(clk_data->hws[i])) {
@@ -257,9 +268,17 @@ static int sun8i_tcon_top_remove(struct platform_device
*pdev)
return 0;
}
+const struct sun8i_tcon_top_quirks sun8i_r40_tcon_top_quirks = {
+ .has_tcon_tv1 = true,
+ .has_dsi= true,
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON TOP */
const struct of_device_id sun8i_tcon_top_of_table[] = {
- { .compatible = "allwinner,sun8i-r40-tcon-top" },
+ {
+ .compatible = "allwinner,sun8i-r40-tcon-top",
+ .data = _r40_tcon_top_quirks
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 28/28] arm64: dts: allwinner: h6: Enable HDMI output on Pine H64 board
Pine H64 board has HDMI type A connector.
Signed-off-by: Jernej Skrabec
---
.../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index 48daec7f78ba..36db21314996 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -21,6 +21,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -41,6 +52,20 @@
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
https://bugzilla.kernel.org/show_bug.cgi?id=200645 --- Comment #9 from Duncan (1i5t5.dun...@cox.net) --- Regression still alive on 4.19.0-12838-g71e560281 (which I believe is a day before 4.20-rc1). -- 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 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 --- Comment #9 from Alex Deucher --- (In reply to Carsten Haitzler from comment #8) > Actually no ogl client has even started. this is just the xserver being > started by slim (login manager) and that doesn't use OGL. it's really basic > xlib stuff. so it is basically a raw xserver... perhaps its the glamor accel > stuff... but... no OGL clients. :) never got that far. Yeah, it would be GL via glamor in that case. -- 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 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version onwards 3.13
https://bugs.freedesktop.org/show_bug.cgi?id=108514 --- Comment #10 from Werner Lueckel --- (In reply to Alex Deucher from comment #1) > Any chance you can narrow down when the regression occurred and bisect it > using git? Please attach your dmesg output and xorg log (if using X). ... sorry, by comments are not below, but "above" ... -- 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 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version onwards 3.13
https://bugs.freedesktop.org/show_bug.cgi?id=108514 --- Comment #9 from Werner Lueckel --- (In reply to Alex Deucher from comment #1) > Any chance you can narrow down when the regression occurred and bisect it > using git? Please attach your dmesg output and xorg log (if using X). I tried to narrow down the flickering issue making several tests; see my comments below. -- 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 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version onwards 3.13
https://bugs.freedesktop.org/show_bug.cgi?id=108514 --- Comment #8 from Werner Lueckel --- more tests with flickering screen: - check modelines "xvidtune -show -display :0" 14.04 trusty (NO flickering) "1680x1050" 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync 18.04.1 LTS (Flickering screen) "1680x1050" 122.00 1680 1712 1776 1904 1050 1051 1054 1066 -hsync -vsync -> exactly the same - on 18.04.1 LTS (1) with flickering grafic screen: repeatedly switch the screen-mode (xrandr): to 1440x900 and back to 1680x1050 -> typically after 2...5 repetitions the screen is o.k. and stops flickering (2) BUT: when the screen awakes from "sleep" -> the flickering starts again! switch to text-console (F1) -> flickers too! switch back to grafic (F7) -> flickering continues the I may continue with (1) OR (frustrated): BOOT 14.04 trusty; which still works fine; excellent grafic; never flickers; ... and start working! - BUT: what can I do when support for "14.04 trusty" ends? -- 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 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 --- Comment #8 from Carsten Haitzler --- Actually no ogl client has even started. this is just the xserver being started by slim (login manager) and that doesn't use OGL. it's really basic xlib stuff. so it is basically a raw xserver... perhaps its the glamor accel stuff... but... no OGL clients. :) never got that far. -- 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 108641] Interlaced dark lines in XCOM2 (UE3.5) on Aruba and Turks
https://bugs.freedesktop.org/show_bug.cgi?id=108641 --- Comment #1 from steelwin...@gmail.com --- If it's of any help, I have managed to narrow down the first output appearance of these interlacing lines between events glDispatchCompute(80, 45, 1) and second call of glDrawElementsBaseVertex(48). -- 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 v1 0/4] ARM: dts: ccimx6ulsbcpro: Add 10" AUO/Goodix LVDS panel accessory kit
On Thu, Oct 25, 2018 at 05:09:29PM +0200, Alex Gonzalez wrote: > Alex Gonzalez (4): > drm/panel: simple: Add AUO G101EVN010 panel support > ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel > ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX > ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller It looks good to me. Ping me when the patch #1 gets accepted and I will apply the test then. Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108649] On Vega GPU Project CARS 2 Demo cause broke fonts in gnome-shell
https://bugs.freedesktop.org/show_bug.cgi?id=108649 --- Comment #2 from mikhail.v.gavri...@gmail.com --- Link to game: https://store.steampowered.com/app/737770/ -- 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 108649] On Vega GPU Project CARS 2 Demo cause broke fonts in gnome-shell
https://bugs.freedesktop.org/show_bug.cgi?id=108649 Bug ID: 108649 Summary: On Vega GPU Project CARS 2 Demo cause broke fonts in gnome-shell Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 142360 --> https://bugs.freedesktop.org/attachment.cgi?id=142360=edit screenshot 1 $ inxi -bM System:Host: localhost.localdomain Kernel: 4.19.0-1.fc30.x86_64 x86_64 bits: 64 Desktop: Gnome 3.30.1 Distro: Fedora release 30 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 0901 date: 07/23/2018 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 2217 MHz min/max: 2200/4000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 1.20.2 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.27.0 4.19.0-1.fc30.x86_64 LLVM 7.0.0) v: 4.5 Mesa 18.2.2 Network: Device-1: Intel I211 Gigabit Network driver: igb Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.36 TiB used: 5.85 TiB (51.5%) Info: Processes: 508 Uptime: 3d 17h 42m Memory: 31.34 GiB used: 21.41 GiB (68.3%) Shell: bash inxi: 3.0.27 -- 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 108649] On Vega GPU Project CARS 2 Demo cause broke fonts in gnome-shell
https://bugs.freedesktop.org/show_bug.cgi?id=108649 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 142361 --> https://bugs.freedesktop.org/attachment.cgi?id=142361=edit screenshot 2 -- 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 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #34 from Alan W. Irwin --- I have discovered this box became significantly less stable when there were two users displaying X directly on it (one with startx , one with startx -- :1) and using ctrl-alt-F1 and ctrl-alt-F2 to switch between the two local X servers that were displaying two different XFCE desktops via the RX 550 graphics card. After moving to that mode of operation we got the following results for uptimes before lockups: 1 day, 2 times 2 days, 1 time 3 days, 1 time For each of these 4 lockups I could not spot any relevant messages in the log files. But the substantially shorter uptimes for this method of using this box does appear to confirm there are still issues with the graphics stack for the RX550. But the graphics content being displayed by the two users is roughly similar so I don't understand why this mode of operation is so much less stable then if just one user is using the RX 550 while the other is using an X-terminal. (None of these lockups occurred anywhere near the times we switched between the two local X servers, but I suppose it is possible that switching sets up a condition that results in a lockup much later.) Anyhow, because of the increased instability I gave up on the two local X servers approach and went back to the one local X server and one X-terminal approach, and with that approach we got an uptime of a week before the system locked up. That lockup occurred tonight, and I have attached a tarball containing log files that show many NMI error messages associated with that lockup (but with no reference to the e1000e module this time). @Michel Dänzer: Could you please take a look at these log files and let me know if this is the best place to report the present lockup? -- 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
