[Bug 64661] New: udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 Bug ID: 64661 Summary: udl causes blank screen Product: Drivers Version: 2.5 Kernel Version: 3.11.6+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: jason at schulz.name Regression: No Using the modesetting driver for X, udl no longer outputs a video signal. This behavior is present in at least 3.11.6, and 3.12.0. The last known version the behavior was what I would normally expect was 3.10.17. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 --- Comment #1 from Jason Schulz --- Created attachment 114021 --> https://bugzilla.kernel.org/attachment.cgi?id=114021&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 --- Comment #2 from Jason Schulz --- Created attachment 114031 --> https://bugzilla.kernel.org/attachment.cgi?id=114031&action=edit xrandr --verbose -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64661] udl causes blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=64661 --- Comment #3 from Jason Schulz --- Comment on attachment 114031 --> https://bugzilla.kernel.org/attachment.cgi?id=114031 xrandr --verbose the udl driver maps to DVI-0 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #1 from Vladimir Ysikov --- ArchLinux x32; kernel 3.12; llvm - svn; mesa - git; xorg-server 1.14.4; Radeon HD 7950 qvdpautest 0.5.2 AMD Phenom(tm) 9550 Quad-Core Processor Unknown GPU VDPAU API version : 1 VDPAU implementation : G3DVL VDPAU Driver Shared Library version 1.0 MPEG DECODING (1920x1080): 19 frames/s MPEG DECODING (1280x720): 19 frames/s H264 DECODING (1920x1080): 15 frames/s H264 DECODING (1280x720): 16 frames/s MPEG4 DECODING (1920x1080): 15 frames/s MIXER WEAVE (1920x1080): 3293 frames/s MIXER BOB (1920x1080): 3878 fields/s MIXER TEMPORAL (1920x1080): 3884 fields/s MIXER TEMPORAL + IVTC (1920x1080): 3881 fields/s MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 3895 fields/s MIXER TEMPORAL_SPATIAL (1920x1080): 3881 fields/s MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 3885 fields/s MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 3888 fields/s MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 3439 fields/s MULTITHREADED MPEG DECODING (1920x1080): 76 frames/s MULTITHREADED MIXER TEMPORAL (1920x1080): 3930 fields/s -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/711d5536/attachment-0001.html>
[PATCH v3 11/32] drm/exynos: Use unsigned long for possible_crtcs
On Tuesday 29 of October 2013 12:12:57 Sean Paul wrote: > Change all instances of possible_crtcs in the exynos drm driver to be > unsigned long. This matches the type used in the drm layer. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.h | 2 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[PATCH v3 10/32] drm/exynos: Don't keep dpms state in encoder
On Tuesday 29 of October 2013 12:12:56 Sean Paul wrote: > This patch removes the dpms state tracking in encoder. This > state is at best confusing and at worst incorrect since the display > drivers can turn on and off without propagating the value. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 17 - > 1 file changed, 17 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448
--- Comment #3 from Mike Lothian ---
I'm not sure if it's related but make sure your xserver is patched to work with
the latest mesa fd1b24a93e ("glx: Add support for the new DRI")
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/92890fd3/attachment.html>
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #2 from Alex Deucher --- Make sure dpm is enabled. add radeon.dpm=1 to the kernel command line in grub. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/19851bd3/attachment.html>
[Bug 64721] New: Radeon HD6450 fails on all distro's out of box.
https://bugzilla.kernel.org/show_bug.cgi?id=64721 Bug ID: 64721 Summary: Radeon HD6450 fails on all distro's out of box. Product: Drivers Version: 2.5 Kernel Version: Linux 3.2.04-amd64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: ichapman at videotron.ca Regression: No I think I'm at the right place to report video card frustrations. Radeon HD450 fails to work out of the box with any Linux. With Debian Wheezy I need to edit the grub line starting with linux and add vga=791 to do anything. vga=771 fails With Knoppix 7.0 I need vga=771 and that's okay, but vga=791 the left half of screen is on right and right on left. The cursor moves to right falls off the screen and re-appears on left side. Very strange. With DebianMint I need vga=771 or 791 to get it to work. On my Acer Aspire laptop with a Radeon HD6310 I do not need any of this vga= stuff. I am sure that this is not a driver problem. All the vga=xxx does is kick it somewhere so that I loads the driver. My Motherboard is M2V-Mx from Asus and once the /etc/default/grub is fixed with GRUB_CMDLINE_LINUX="vga=791" or 771 it's okay. (sudo update-grub of course) I recently junked my Nvidia 8500GT video because the driver for that became sick, the worst feature was not being able to display the layout of the pcb tool unless I disabled the driver and used cpu sw rendering on the video but that's an other story. Ian. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 15/32] drm/exynos: Use drm_mode_copy to copy modes
Hi Sean, On Tuesday 29 of October 2013 12:13:01 Sean Paul wrote: > This patch changes the manual copying of mode to adjusted_mode in > mode_fixup to use drm_mode_copy instead of handling things manually. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 71431] radeon graphics stopped working since kernel 3.10 on AMD a4-3300
https://bugs.freedesktop.org/show_bug.cgi?id=71431 --- Comment #4 from Alex Deucher --- (In reply to comment #1) > X11 doesn't work on my dual-graphics AMD laptop with kernels 3.10.X - > 3.12.X, on 3.9.X and earlier kernels does. Can you bisect with git? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/6607bc79/attachment.html>
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #10 from Ilya Tumaykin --- I've just had another suck lockup on 3.12 vanilla kernel without specifying aspm option to the driver. What should I test now? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 16/32] drm/exynos: Disable unused crtc planes from crtc
On Tuesday 29 of October 2013 12:13:02 Sean Paul wrote: > This patch moves the code which disables unused crtc planes from the > encoder to the crtc. Since there is a 1:1 encoder/crtc mapping in > exynos, the only valid crtc change the pre-existing code could catch is > disconnecting an active crtc from the encoder. Thus it is functionally > equivalent to just disable all planes attached to a crtc when the crtc > is disabled. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_crtc.c| 13 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 65 > ++--- > 2 files changed, 15 insertions(+), 63 deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #37 from david --- you have the same graphic card than me (ati hd 7480D, but my cpu is the 5300) I have tested the patch, but it doesnt fix our problem :( -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/58d2b8d0/attachment.html>
[PATCH v3 18/32] drm/exynos: Implement mode_fixup manager operation
On Tuesday 29 of October 2013 12:13:04 Sean Paul wrote: > This patch adds a new manager callback for mode_fixup and pipes it > through exynos_drm_crtc. Patch description lacking explanation what this change is for. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ++- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 > 2 files changed, 10 insertions(+), 1 deletion(-) Otherwise the code looks fine. Best regards, Tomasz
[PATCH v3 14/32] drm/exynos: Remove exynos_drm_hdmi shim
Hi Sean,
On Tuesday 29 of October 2013 12:13:00 Sean Paul wrote:
> This patch trims exynos_drm_hdmi out of the driver. The reason it
> existed in the first place was to make up for the mixture of
> display/overlay/manager ops being spread across hdmi and mixer. With
> that code now rationalized, mixer and hdmi map directly to
> exynos_drm_crtc and exynos_drm_encoder, respectively. Since there is a
> 1:1 mapping, we no longer need this layer.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - hdmi/mixer ops now take display/manager instead of context
> Changes in v3:
> - Moved removal of exynos_drm_hdmi.c file here
>
> drivers/gpu/drm/exynos/Makefile | 3 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 -
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 416
> ---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 69 -
> drivers/gpu/drm/exynos/exynos_hdmi.c | 162 +++-
> drivers/gpu/drm/exynos/exynos_mixer.c| 204 ---
> drivers/gpu/drm/exynos/exynos_mixer.h| 20 ++
> 7 files changed, 222 insertions(+), 665 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> create mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index e106309..9e12fb7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
[snip]
> +static struct exynos_drm_display hdmi_display = {
> + .type = EXYNOS_DISPLAY_TYPE_HDMI,
> + .ops = &hdmi_display_ops,
> +};
> +
> static irqreturn_t hdmi_irq_thread(int irq, void *arg)
> {
> - struct exynos_drm_hdmi_context *ctx = arg;
> - struct hdmi_context *hdata = ctx->ctx;
> + struct hdmi_context *hdata = arg;
>
> mutex_lock(&hdata->hdmi_mutex);
> hdata->hpd = gpio_get_value(hdata->hpd_gpio);
> @@ -1887,7 +1944,6 @@ static struct of_device_id hdmi_match_types[] = {
> static int hdmi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct exynos_drm_hdmi_context *drm_hdmi_ctx;
> struct hdmi_context *hdata;
> struct s5p_hdmi_platform_data *pdata;
> struct resource *res;
> @@ -1902,20 +1958,13 @@ static int hdmi_probe(struct platform_device *pdev)
> if (!pdata)
> return -EINVAL;
>
> - drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx), GFP_KERNEL);
> - if (!drm_hdmi_ctx)
> - return -ENOMEM;
> -
> hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
> if (!hdata)
> return -ENOMEM;
>
> mutex_init(&hdata->hdmi_mutex);
>
> - drm_hdmi_ctx->ctx = (void *)hdata;
> - hdata->parent_ctx = (void *)drm_hdmi_ctx;
> -
> - platform_set_drvdata(pdev, drm_hdmi_ctx);
> + platform_set_drvdata(pdev, &hdmi_display);
This looks like a step backwards. Originally the driver had kind of per
instance data, while now it has a single global struct, making it harder
to properly support multiple HDMI instances, what is not unlikely to show
up in future SoCs.
So instead, I would embed an exynos_drm_display struct inside struct
hdmi_context and initialize it at runtime and use it to get access to
hdata, using container_of.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 60935c4..39aed3e 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
[snip]
> @@ -1184,21 +1190,17 @@ static struct of_device_id mixer_match_types[] = {
> static int mixer_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct exynos_drm_hdmi_context *drm_hdmi_ctx;
> struct mixer_context *ctx;
> struct mixer_drv_data *drv;
> int ret;
>
> dev_info(dev, "probe start\n");
>
> - drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx),
> - GFP_KERNEL);
> - if (!drm_hdmi_ctx)
> - return -ENOMEM;
> -
> - ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> - if (!ctx)
> + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx) {
> + DRM_ERROR("failed to alloc mixer context.\n");
> return -ENOMEM;
> + }
>
> mutex_init(&ctx->mixer_mutex);
>
> @@ -1211,18 +1213,14 @@ static int mixer_probe(struct platform_device *pdev)
> platform_get_device_id(pdev)->driver_data;
> }
>
> - ctx->dev = dev;
> - ctx->parent_ctx = (void *)drm_hdmi_ctx;
> - drm_hdmi_ctx->ctx = (void *)ctx;
> + ctx->dev = &pdev->dev;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> DRM_INIT_WAITQUEUE(&ctx->wait_vsync_queue);
> atomic_set(&ctx->wait_vsync_event, 0);
>
> - platfo
[GIT PULL] gma500-next
Hi Dave, Here are the patches for SDVO on the Minnowboard. Thanks Patrik The following changes since commit 91915260ea5ed9d9b19bfb75d53c989c8ada2ab0: Merge tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-11-08 16:34:39 +1000) are available in the git repository at: git://github.com/patjak/drm-gma500 gma500-next for you to fetch changes up to cd3fdbe853c47c5890d5362363b59504c2e5fb5f: drm/gma500/mrst: Add SDVO to output init (2013-11-08 16:23:19 +0100) Patrik Jakobsson (12): drm/gma500: Add Minnowboard to the IS_MRST() macro drm/gma500: Add chip specific sdvo masks drm/gma500: Add support for aux pci vdc device drm/gma500: Add aux device support for gmbus drm/gma500/mrst: Add SDVO clock calculation drm/gma500/mrst: Add aux register writes when programming pipe drm/gma500/mrst: Properly route oaktrail hdmi hooks drm/gma500/mrst: Add aux register writes to SDVO drm/gma500/mrst: Replace WMs and chickenbits with values from EMGD drm/gma500/mrst: Setup GMBUS for oaktrail/mrst drm/gma500/mrst: Don't blindly guess a mode for LVDS drm/gma500/mrst: Add SDVO to output init drivers/gpu/drm/gma500/cdv_device.c | 1 + drivers/gpu/drm/gma500/framebuffer.c | 2 +- drivers/gpu/drm/gma500/intel_gmbus.c | 90 --- drivers/gpu/drm/gma500/oaktrail_crtc.c | 433 +++ drivers/gpu/drm/gma500/oaktrail_device.c | 6 + drivers/gpu/drm/gma500/oaktrail_lvds.c | 30 +-- drivers/gpu/drm/gma500/psb_device.c | 1 + drivers/gpu/drm/gma500/psb_drv.c | 32 ++- drivers/gpu/drm/gma500/psb_drv.h | 51 +++- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 59 +++-- 10 files changed, 448 insertions(+), 257 deletions(-)
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
Hi Sean, On Tuesday 29 of October 2013 12:12:58 Sean Paul wrote: > This patch splits display and manager from subdrv. The result is that > crtc functions can directly call into manager callbacks and encoder > functions can directly call into display callbacks. This will allow > us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp > with common code. > > Signed-off-by: Sean Paul > --- > > Changes in v2: > - Pass display into display_ops instead of context > Changes in v3: > - Changed vidi args to exynos_drm_display instead of void > - Moved exynos_drm_hdmi.c removal into next patch > > drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++--- > drivers/gpu/drm/exynos/exynos_drm_core.c | 181 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +--- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +-- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++ > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258 > -- > drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161 > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 211 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 + > drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 129 ++--- > 14 files changed, 615 insertions(+), 684 deletions(-) This patch is really heavy, making it very hard to review. I wonder if it couldn't really be split into several smaller patches... Anyway, please see my comments below, for the points I haven't overlooked due to the complexity of this patch. > diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c > b/drivers/gpu/drm/exynos/exynos_drm_core.c > index 08ca4f9..e76098d 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_core.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c > @@ -16,11 +16,14 @@ > #include > #include Huh? Including a specific bridge chip inside a generic Exynos DRM core? I know this is not a part of this patch, but... this is _broken_. You may want to support multiple bridge chips in Exynos DRM core and you may also want to support PTN3460 in other DRM cores. It can't be done this way. This series is very nice, but the whole effect is destroyed by basing it on top of such insanity... Please rebase it on top of something more reasonable (preferably Inki's next branch directly). Otherwise, this patch seems reasonable (except its size). Best regards, Tomasz
[Bug 71448] [UVD] qvdpautest is very slow on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=71448 --- Comment #4 from Alex Deucher --- (In reply to comment #0) > http://bpaste.net/show/148239/ In the future, please attach the output rather than referring to an external site that may go away at some point. > > kernel is 3.13 (~agd5f drm-next-3.13). > The whole graphic stack is from git except xorg-server which is 1.14.3. from your log: FATAL: get_bits failed : No backend implementation could be loaded.!! There's some problem with your build. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131110/81702ecf/attachment.html>
[PATCH v3 17/32] drm/exynos: Add mode_set manager operation
Hi Sean, On Tuesday 29 of October 2013 12:13:03 Sean Paul wrote: > This patch adds a mode_set callback to the manager operations which > sets the crtc's current mode to the manager driver. To allow/fix/improve/extend... Patch description should say why such change is good to have. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 > drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++ > 2 files changed, 7 insertions(+) Otherwise the patch looks fine. Best regards, Tomasz
[pull] radeon drm-next-3.13
2013/11/10 Alex Deucher : > On Sat, Nov 9, 2013 at 3:20 AM, Rafa? Mi?ecki wrote: >> 2013/11/8 Alex Deucher : >>> Revert "drm/radeon/audio: don't set speaker allocation on DCE4+" >> >> What about that hangs people reported? Has anything changed meanwhile? >> Did you fix them with some another commit? > > No one actually pointed to this commit as a problem, but it seemed > like the safe thing to do for 3.12 considering the problems caused by > the same functionality for DCE3.2 parts. That said, a number of > people have tested this patch successfully without problems, and it's > necessary for the alsa driver to work correctly so I figured it was > worth trying again for 3.13. Nice to hear that. My short-hanging case appeared to be eDP related (disabling eDP takes few seconds for some reason, will debug it some day).
[PATCH v3 19/32] drm/exynos: Use mode_set to configure fimd
Hi Sean,
On Tuesday 29 of October 2013 12:13:05 Sean Paul wrote:
> This patch uses the mode passed into mode_set to configure fimd instead
> of directly using the panel from context. This will allow us to move
> the exynos_drm_display implementation from fimd into the DP driver
> where it belongs.
Remember that DP is not the only possible way to connect a display driven
by FIMD. You also have the direct (RGB and i80) and DSI interfaces.
Also, please see my comments inline.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2: None
> Changes in v3: None
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 159
> ++-
> 1 file changed, 91 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index d2b8ccb..f69d6e5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -104,6 +104,20 @@ struct fimd_win_data {
> boolresume;
> };
>
> +struct fimd_mode_data {
> + unsignedvtotal;
For consistency with rest of the code, unsigned int would prefered.
However, I'm not sure what is this struct for, since it does not store
neither raw register values (1 needs to be subtracted from them) nor
any values hard to compute at commit time (maybe except clkdiv, but still
how often commit would be called?).
> + unsignedvdisplay;
> + unsignedvsync_len;
> + unsignedvbpd;
> + unsignedvfpd;
> + unsignedhtotal;
> + unsignedhdisplay;
> + unsignedhsync_len;
> + unsignedhbpd;
> + unsignedhfpd;
> + u32 clkdiv;
> +};
> +
> struct fimd_context {
> struct device *dev;
> struct drm_device *drm_dev;
> @@ -112,8 +126,8 @@ struct fimd_context {
> struct clk *bus_clk;
> struct clk *lcd_clk;
> void __iomem*regs;
> + struct fimd_mode_data mode;
> struct fimd_win_datawin_data[WINDOWS_NR];
> - unsigned intclkdiv;
> unsigned intdefault_win;
> unsigned long irq_flags;
> u32 vidcon0;
> @@ -560,11 +574,56 @@ static void fimd_dpms(struct exynos_drm_manager *mgr,
> int mode)
> mutex_unlock(&ctx->lock);
> }
>
> +static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
> + const struct drm_display_mode *mode)
> +{
> + unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
> + u32 clkdiv;
> +
> + /* Find the clock divider value that gets us closest to ideal_clk */
> + clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(ctx->lcd_clk), ideal_clk);
This is a functional change unrelated to $subject. Before this patch,
DIV_ROUND_UP() had been used.
> +
> + return (clkdiv < 0x100) ? clkdiv : 0xff;
> +}
> +
> +static bool fimd_mode_fixup(struct exynos_drm_manager *mgr,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + if (adjusted_mode->vrefresh == 0)
> + adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
> +
> + return true;
> +}
> +
> +static void fimd_mode_set(struct exynos_drm_manager *mgr,
> + const struct drm_display_mode *in_mode)
> +{
> + struct fimd_context *ctx = mgr->ctx;
> + struct fimd_mode_data *mode = &ctx->mode;
> + int hblank, vblank;
> +
> + vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
> + mode->vtotal = in_mode->crtc_vtotal;
> + mode->vdisplay = in_mode->crtc_vdisplay;
> + mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
> + mode->vbpd = (vblank - mode->vsync_len) / 2;
> + mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
> +
> + hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
> + mode->htotal = in_mode->crtc_htotal;
> + mode->hdisplay = in_mode->crtc_hdisplay;
> + mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
> + mode->hbpd = (hblank - mode->hsync_len) / 2;
> + mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
> +
> + mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
What about simply copying contents of in_mode to driver context
and then calculating clkdiv at commit time? You could get rid
of the fimd_mode_data struct and most of this function.
Otherwise, the patch looks fine.
Best regards,
Tomasz
[PATCH v3 13/32] drm/exynos: hdmi: remove the i2c drivers and use devtree
Hi Sean, Daniel,
Please see my comments inline.
On Tuesday 29 of October 2013 12:12:59 Sean Paul wrote:
> From: Daniel Kurtz
>
> The i2c client was previously being passed into the hdmi driver via a
> dedicated i2c driver, and then a global variable. This patch removes all
> of that and just uses the device tree to get the i2c_client. This patch
> also properly references the client so we don't lose it before we're
> done with it.
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Change include to linux/i2c.h instead of linux/of_i2c.h
> Changes in v3: None
>
> drivers/gpu/drm/exynos/Makefile | 1 -
> drivers/gpu/drm/exynos/exynos_ddc.c | 63
> drivers/gpu/drm/exynos/exynos_hdmi.c| 59 ++
> drivers/gpu/drm/exynos/exynos_hdmi.h| 23
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 65
> -
> 5 files changed, 27 insertions(+), 184 deletions(-)
> delete mode 100644 drivers/gpu/drm/exynos/exynos_ddc.c
> delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h
> delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c
I hope this patch does not alter the existing Exynos HDMI bindings.
This would have to be reflected in respective documentation otherwise
and of course done in a backwards compatible way.
Well, let's see...
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index d35ab2a..e106309 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
[snip]
> @@ -1957,21 +1943,30 @@ static int hdmi_probe(struct platform_device *pdev)
> }
>
> /* DDC i2c driver */
> - if (i2c_add_driver(&ddc_driver)) {
> - DRM_ERROR("failed to register ddc i2c driver\n");
> - return -ENOENT;
> + ddc_node = of_find_node_by_name(NULL, "hdmiddc");
This is wrong. You shall not reference a device tree node by its name,
except some very specific well-defined cases, such as cpus or memory
nodes.
A solution closest to yours, but correct, would be to use the same match
table as in the I2C driver you are removing and call
of_find_matching_node().
> + if (!ddc_node) {
> + DRM_ERROR("Failed to find ddc node in device tree\n");
> + return -ENODEV;
> + }
> + hdata->ddc_port = of_find_i2c_device_by_node(ddc_node);
> + if (!hdata->ddc_port) {
> + DRM_ERROR("Failed to get ddc i2c client by node\n");
> + return -ENODEV;
> }
In general, this looks like a better approach, without using a fake
driver. However you should check how this will play together with runtime
PM of the I2C adapter, as I'm not sure about it.
Both this comment and the comment above apply as well to the hdmiphy
handling.
Best regards,
Tomasz
[pull] radeon drm-next-3.13
On Sat, Nov 9, 2013 at 3:20 AM, Rafa? Mi?ecki wrote: > 2013/11/8 Alex Deucher : >> Revert "drm/radeon/audio: don't set speaker allocation on DCE4+" > > What about that hangs people reported? Has anything changed meanwhile? > Did you fix them with some another commit? No one actually pointed to this commit as a problem, but it seemed like the safe thing to do for 3.12 considering the problems caused by the same functionality for DCE3.2 parts. That said, a number of people have tested this patch successfully without problems, and it's necessary for the alsa driver to work correctly so I figured it was worth trying again for 3.13. Alex > > 2013/10/28 Deucher, Alexander : >>> Did you get any reports about that? Or is that based only on mine comment: >> >> Yes, I had some reports of hangs on newer chips for some people as well. >> I'm not sure if it was directly correlated, but seemed like the safe thing >> to at this point in the kernel cycle.
[PATCH] Input: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
On Wed, Nov 06, 2013 at 03:54:32PM +0800, Duan Jiong wrote: > This patch fixes coccinelle error regarding usage of IS_ERR and > PTR_ERR instead of PTR_ERR_OR_ZERO. > > Signed-off-by: Duan Jiong Applied, thank you. > --- > drivers/input/touchscreen/cyttsp4_spi.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/input/touchscreen/cyttsp4_spi.c > b/drivers/input/touchscreen/cyttsp4_spi.c > index a71e114..b19434c 100644 > --- a/drivers/input/touchscreen/cyttsp4_spi.c > +++ b/drivers/input/touchscreen/cyttsp4_spi.c > @@ -171,10 +171,7 @@ static int cyttsp4_spi_probe(struct spi_device *spi) > ts = cyttsp4_probe(&cyttsp_spi_bus_ops, &spi->dev, spi->irq, > CY_SPI_DATA_BUF_SIZE); > > - if (IS_ERR(ts)) > - return PTR_ERR(ts); > - > - return 0; > + return PTR_ERR_OR_ZERO(ts); > } > > static int cyttsp4_spi_remove(struct spi_device *spi) > -- > 1.8.3.1 > -- Dmitry
