[PATCH 00/29] drm/exynos: clean up + atomic phases 1 and 2
Hi, 2014-12-18 22:58 GMT+09:00 Gustavo Padovan : > From: Gustavo Padovan > > Hi, > > In this series: > > - fix to FIMD pageflips, only finish pageflips if START == START_S. > > - remove struct exynos_drm_overlay and struct exynos_drm_manager. > exynos_drm_overlay was merged with exynos_drm_plane and exynos_drm_manager > with exynos_drm_crtc removing two extra and unnecessary abstractions levels > from the exynos code. It also makes understanding of the code easier since > now we talk using known names like CRTC and Planes instead of manager and > overlay. > > - remove DPMS operations from places where it is not need, e.g., updating > planes. Only full modesets should use DPMS operations. > > - unify plane update on exynos_update_plane(). Now all pieces of code that > wants to update a plane should be using this function. > > - atomic phase 1 and 2: set all the helpers and new callbacks needed to port > drm-exynos to atomic. pahse 3 is a work in progress. > > There are also some smalls fixes and clean ups. > > This is rebased on dri-devel/drm-next to benefit from the lastests atomic > changes. Merged only cleanup parts - 2 through 21 - to exynos-drm-next. I will have pull request within a week after testing. p.s. please keep that patch series has consistency of previous ones from next time. Thanks, Inki Dae > > Gustavo > > --- > The following changes since commit 4e0cd68115620bc3236ff4e58e4c073948629b41: > > drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/padovan/drm-exynos.git > for-drm-next > > for you to fetch changes up to 26d5e29b5613fb466b3cb04ddbdef371aa3f1596: > > drm/exynos: atomic phase 2: keep track of framebuffer pointer (2014-12-18 > 11:30:16 -0200) > > Daniel Kurtz (1): > drm/exynos/fimd: only finish pageflip if START == START_S > > Gustavo Padovan (28): > drm/exynos: move to_exynos_crtc() macro to main header > drm/exynos: expose struct exynos_drm_crtc > drm/exynos: remove exynos_drm_crtc_plane_* wrappers > drm/exynos: remove struct exynos_drm_overlay > drm/exynos/fimd: don't initialize 'ret' variable in fimd_probe() > drm/exynos/vidi: remove useless ops->commit() > drm/exynos: Don't touch DPMS when updating overlay planes > drm/exynos: don't do any DPMS operation while updating planes > drm/exynos: remove exynos_plane_commit() wrapper > drm/exynos: unify plane update on exynos_update_plane() > drm/exynos: call exynos_update_plane() directly on page flips > drm/exynos: remove exynos_drm_crtc_mode_set_commit() > drm/exynos: rename base object of struct exynos_drm_crtc to 'base' > drm/exynos: add pipe param to exynos_drm_crtc_create() > drm/exynos: remove pipe member of struct exynos_drm_manager > drm/exynos: move 'type' from manager to crtc struct > drm/exynos: remove drm_dev from struct exynos_drm_manager > drm/exynos: remove struct exynos_drm_manager > drm/exynos: don't duplicate drm_display_mode in fimd context > drm/exynos: remove mode_set() ops from exynos_crtc > drm/exynos: create exynos_check_plane() > drm/exynos: atomic phase 1: use drm_plane_helper_update() > drm/exynos: make exynos_plane_mode_set() static > drm/exynos: atomic phase 1: use drm_plane_helper_disable() > drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush() > drm/exynos: atomic phase 1: add .mode_set_nofb() callback > drm/exynos: atomic phase 2: wire up state reset(), duplicate() and > destroy() > drm/exynos: atomic phase 2: keep track of framebuffer pointer > > drivers/gpu/drm/bridge/ptn3460.c | 4 + > drivers/gpu/drm/exynos/exynos_dp_core.c | 4 + > drivers/gpu/drm/exynos/exynos_drm_connector.c | 4 + > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 273 > ++ > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 8 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 + > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 87 +--- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 + > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 263 ++--- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 196 ++ > drivers/gpu/drm/exynos/exynos_drm_plane.h | 12 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 139 ++--- > drivers/gpu/drm/exynos/exynos_hdmi.c | 4 + > drivers/gpu/drm/exynos/exynos_mixer.c | 159 --- > include/video/samsung_fimd.h | 1 + > 17 files changed, 601 insertions(+), 565 deletions(-) > > -- > 1.9.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: nouveau: nvif: device: Remove unused function
On Sun, Jan 11, 2015 at 11:53 PM, Rickard Strandqvist
wrote:
Hey Rickard,
> Remove the function nvif_device_new() that is not used anywhere.
It's used, just not by the kernel. All the code under core/ and nvif/
is also built into a userspace library (not in the kernel tree,
obviously) and used by tools / testing apps.
I'll pick up the rest of your nouveau patches though, aside from the
one Samuel is taking care of.
Thanks,
Ben.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/nouveau/nvif/device.c | 18 --
> drivers/gpu/drm/nouveau/nvif/device.h |2 --
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvif/device.c
> b/drivers/gpu/drm/nouveau/nvif/device.c
> index f477579..8522aa9 100644
> --- a/drivers/gpu/drm/nouveau/nvif/device.c
> +++ b/drivers/gpu/drm/nouveau/nvif/device.c
> @@ -53,24 +53,6 @@ nvif_device_del(struct nvif_device *device)
> kfree(device);
> }
>
> -int
> -nvif_device_new(struct nvif_object *parent, u32 handle, u32 oclass,
> - void *data, u32 size, struct nvif_device **pdevice)
> -{
> - struct nvif_device *device = kzalloc(sizeof(*device), GFP_KERNEL);
> - if (device) {
> - int ret = nvif_device_init(parent, nvif_device_del, handle,
> - oclass, data, size, device);
> - if (ret) {
> - kfree(device);
> - device = NULL;
> - }
> - *pdevice = device;
> - return ret;
> - }
> - return -ENOMEM;
> -}
> -
> void
> nvif_device_ref(struct nvif_device *device, struct nvif_device **pdevice)
> {
> diff --git a/drivers/gpu/drm/nouveau/nvif/device.h
> b/drivers/gpu/drm/nouveau/nvif/device.h
> index 43180f9..8440848 100644
> --- a/drivers/gpu/drm/nouveau/nvif/device.h
> +++ b/drivers/gpu/drm/nouveau/nvif/device.h
> @@ -22,8 +22,6 @@ int nvif_device_init(struct nvif_object *, void
> (*dtor)(struct nvif_device *),
> u32 handle, u32 oclass, void *, u32,
> struct nvif_device *);
> void nvif_device_fini(struct nvif_device *);
> -int nvif_device_new(struct nvif_object *, u32 handle, u32 oclass,
> -void *, u32, struct nvif_device **);
> void nvif_device_ref(struct nvif_device *, struct nvif_device **);
>
> /*XXX*/
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 88227] Radeonsi: High GTT usage in Prison Architect large map
https://bugs.freedesktop.org/show_bug.cgi?id=88227 --- Comment #11 from James Harvey --- Hello Marek, My memory info: [1.879493] [drm] radeon: 2048M of VRAM memory ready [1.879494] [drm] radeon: 2048M of GTT memory ready. I also have 8gb of system memory. I patched radeon_drm_winsys.c as per your suggestion. This seemed to work well: - (ws->info.vram_size + ws->info.gart_size) / 8); + (ws->info.vram_size + ws->info.gart_size) / 2); I tried changing the divisor to 4, but that didn't help much. Divisor at 3 was better but still had some fps drops to zero and trouble getting above about 40fps. Divisor at 2 was much better, fps drops only when waiting for data to load in memory. (such as suddenly zooming out or saving/loading game). While testing, the maximum GTT usage I saw was 1.82gb, with typical usage around 1-1.5gb depending on how closely the map was zoomed in. Vram usage is pretty flat, usually around 450mb. -- 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/20150112/f178efc9/attachment.html>
[PATCH] drm/exynos: fix reset codes for memory mapped hdmi phy
This fixes reset codes to support memory mapped hdmi phy as well as hdmi
phy dedicated i2c lines.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5765a16..98051e8 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,7 +1669,6 @@ static void hdmi_mode_apply(struct hdmi_context *hdata)
static void hdmiphy_conf_reset(struct hdmi_context *hdata)
{
- u8 buffer[2];
u32 reg;
clk_disable_unprepare(hdata->res.sclk_hdmi);
@@ -1677,11 +1676,8 @@ static void hdmiphy_conf_reset(struct hdmi_context
*hdata)
clk_prepare_enable(hdata->res.sclk_hdmi);
/* operation mode */
- buffer[0] = 0x1f;
- buffer[1] = 0x00;
-
- if (hdata->hdmiphy_port)
- i2c_master_send(hdata->hdmiphy_port, buffer, 2);
+ hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
+ HDMI_PHY_ENABLE_MODE_SET);
if (hdata->type == HDMI_TYPE13)
reg = HDMI_V13_PHY_RSTOUT;
--
1.9.1
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #7 from Arthur Marsh --- Created attachment 112109 --> https://bugs.freedesktop.org/attachment.cgi?id=112109&action=edit 2015011216dmesg.txt - dmesg output with 3.19.0-rc4+ problem further reduced but not eliminated. -- 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/20150112/876f005b/attachment.html>
[PATCH] drm/rockchip: Only alloc a kmap for fbdev gem object
In general, the data in drm/rockchip GEM objects is never accessed by
the kernel. The objects are either accessed by a GPU, by display
controller DMA, or by mmap'ing them to user space. Thus, these
buffers need not be mapped into kernel address space.
The only exception is the fbdev framebuffer(s), which may be written
in-kernel by fbcon.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 -
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 3 ++-
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index a5d889a8..17d1954 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -71,7 +71,7 @@ static int rockchip_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- rk_obj = rockchip_gem_create_object(dev, size);
+ rk_obj = rockchip_gem_create_object(dev, size, true);
if (IS_ERR(rk_obj))
return -ENOMEM;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index bc98a22..2899385 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -22,7 +22,8 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj)
+static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+ bool alloc_kmap)
{
struct drm_gem_object *obj = &rk_obj->base;
struct drm_device *drm = obj->dev;
@@ -30,7 +31,9 @@ static int rockchip_gem_alloc_buf(struct rockchip_gem_object
*rk_obj)
init_dma_attrs(&rk_obj->dma_attrs);
dma_set_attr(DMA_ATTR_WRITE_COMBINE, &rk_obj->dma_attrs);
- /* TODO(djkurtz): Use DMA_ATTR_NO_KERNEL_MAPPING except for fbdev */
+ if (!alloc_kmap)
+ dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &rk_obj->dma_attrs);
+
rk_obj->kvaddr = dma_alloc_attrs(drm->dev, obj->size,
&rk_obj->dma_addr, GFP_KERNEL,
&rk_obj->dma_attrs);
@@ -106,7 +109,8 @@ int rockchip_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
}
struct rockchip_gem_object *
- rockchip_gem_create_object(struct drm_device *drm, unsigned int size)
+ rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
+ bool alloc_kmap)
{
struct rockchip_gem_object *rk_obj;
struct drm_gem_object *obj;
@@ -122,7 +126,7 @@ struct rockchip_gem_object *
drm_gem_private_object_init(drm, obj, size);
- ret = rockchip_gem_alloc_buf(rk_obj);
+ ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
if (ret)
goto err_free_rk_obj;
@@ -166,7 +170,7 @@ rockchip_gem_create_with_handle(struct drm_file *file_priv,
struct drm_gem_object *obj;
int ret;
- rk_obj = rockchip_gem_create_object(drm, size);
+ rk_obj = rockchip_gem_create_object(drm, size, false);
if (IS_ERR(rk_obj))
return ERR_CAST(rk_obj);
@@ -285,6 +289,9 @@ void *rockchip_gem_prime_vmap(struct drm_gem_object *obj)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
+ if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, &rk_obj->dma_attrs))
+ return NULL;
+
return rk_obj->kvaddr;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index 67bcebe..ad22618 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -41,7 +41,8 @@ int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
struct vm_area_struct *vma);
struct rockchip_gem_object *
- rockchip_gem_create_object(struct drm_device *drm, unsigned int size);
+ rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
+ bool alloc_kmap);
void rockchip_gem_free_object(struct drm_gem_object *obj);
--
2.2.0.rc0.207.ga3a616c
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
Am Freitag, den 09.01.2015, 20:01 + schrieb Russell King - ARM
Linux:
[...]
> Neither; we know that there are TDA998x devices which allow SPDIF to be
> input via two separate pins, but only one to be active at any one time.
> Given that the hardware is flexible in that regard, a binding which
> artificially restricts that flexibility would seem unwise.
>
> If we were to come across a setup which did route two SPDIF streams to
> the TDA998x, and we had to make the decision at run time which to route
> to the HDMI sink, we'd have to rework the binding, and we'd have to
> support the new binding and the old binding in the driver.
>
> Can you please look at Documentation/devicetree/bindings/graph.txt ?
>
> I think we may be able to use something like this:
>
> tda998x: hdmi-encoder {
> compatible = "nxp,tda998x";
> reg = <0x70>;
> video-ports = <0x234501>;
>
> port {
> tda998x_video: endpoint {
> remote-endpoint = <&lcd0_rgb>;
> };
> };
>
> port {
> #address-cells = <1>;
> #size-cells = <0>;
>
> tda998x_spdif0: endpoint at 02 {
> reg = <0x02>;
> remote-endpoint = <&spdif0>;
> };
>
> tda998x_spdif1: endpoint at 04 {
> reg = <0x04>;
> remote-endpoint = <&spdif0>;
> };
>
> tda998x_i2s: endpoint at 03 {
> reg = <0x03>;
> remote-endpoint = <&i2s>;
> };
> };
> };
>
> I'm adding Philipp Zabel for comment. The issue I see with this is that
> we have two ports here which are not mutually exclusive, and it's not
> obvious how they are dealt with.
Jean-Francois' reply already reflects this, but the 'port' nodes should
correspond to physical ports of the device if possible. If you can
configure the device to have dedicated input pins for I2S, SPDIF0, and
SPDIF1 at the same time, they should appear in the device tree as
separate ports:
tda998x: hdmi-encoder {
port at 0 { /* pixel data according to video-ports */
reg = <0x00>;
};
port at 1 { /* AP1: SPDIF0 */
reg = <0x01>;
};
port at 2 { /* AP2: SPDIF1 */
reg = <0x02>;
};
port at 3 { /* AP3: I2S */
reg = <0x03>;
};
};
The tda998x binding would define how the ports are numbered, some
correspondence to the AP pin numbers would be good.
regards
Philipp
[PATCH 1/3] ARM: dts: add fimd device support for exynos3250-rinato
On 2015ë
01ì 12ì¼ 18:12, Kukjin Kim wrote:
> On 01/03/15 15:50, Inki Dae wrote:
>> On 2014ë
11ì 28ì¼ 20:39, Inki Dae wrote:
>>> This patch adds fimd device node which is a display controller
>>> for Exynos3250 Rinato board.
>>
>> Hi Kukjin,
>>
>> Please, ping~
>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Inki Dae
>>> Acked-by: Kyungmin Park
>>> ---
>>> arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
>>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>>> index 80aa8b4..79aa916 100644
>>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>>> @@ -125,6 +125,17 @@
>>> };
>>> };
>>>
>>> +&fimd {
>>> + status = "okay";
>>> +
>>> + i80-if-timings {
>>> + cs-setup = <0>;
>>> + wr-setup = <0>;
>>> + wr-act = <1>;
>>> + wr-hold = <0>;
>>> + };
>>> +};
>>> +
>>> &i2c_0 {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>
> Applied this and 3rd one.
> BTW, I can't see the "samsung,s6e63j0x03" support yet?
I sent it with a separated patch Ccing you. You can refer to below link,
http://www.spinics.net/lists/linux-samsung-soc/msg39756.html
Thanks,
Inki Dae
>
> - Kukjin
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH] drm/i915: fix inconsistent brightness after resume
On Sat, 10 Jan 2015, Jeremiah Mahler wrote:
> Commit 6dda730e55f4 introduced a bug which resulted in inconsistent
> brightness levels on different machines. If a suspended was entered
> with the screen off some machines would resume with the screen
> at minimum brightness and others at maximum brightness.
>
> The following commands can be used to produce this behavior.
>
> xset dpms force off
> sleep 1
> sudo systemctl suspend
> (resume ...)
>
> The root cause of this problem is a comparison which checks to see if
> the backlight level is zero when the panel is enabled. If it is zero,
> it is set to the maximum level. Unfortunately, not all machines have a
> minimum level of zero. On those machines the level is left at the
> minimum instead of begin set to the maximum.
Good catch!
I think part of the problem is that the userspace sets brightness to
minimum before suspend, but apparently does not restore it after
resume. The dmesg would confirm this. But I guess it doesn't matter,
since we're pretty much stuck with having to do this anyway.
> Fix the bug by updating the comparison to check for the minimum
> backlight level instead of zero.
>
> Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
> Signed-off-by: Jeremiah Mahler
> ---
> drivers/gpu/drm/i915/intel_panel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 4d63839..4ef4d66 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -962,7 +962,7 @@ void intel_panel_enable_backlight(struct intel_connector
> *connector)
>
> WARN_ON(panel->backlight.max == 0);
>
> - if (panel->backlight.level == 0) {
> + if (panel->backlight.level == panel->backlight.min) {
Perhaps <= instead of == would be safest?
BR,
Jani.
> panel->backlight.level = panel->backlight.max;
> if (panel->backlight.device)
> panel->backlight.device->props.brightness =
> --
> 2.1.4
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCHv3 0/3] hdmi: add unpack and logging functions
Hi Thierry, On 12/19/2014 01:14 PM, Hans Verkuil wrote: > This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and > adds unpacking and logging functions to hdmi.c. It also uses those > in the V4L2 adv7842 driver (and they will be used in other HDMI drivers > once this functionality is merged). > > Changes since v2: > - Applied most comments from Thierry's review > - Renamed HDMI_AUDIO_CODING_TYPE_EXT_STREAM as per Thierry's suggestion. > > Thierry, if this OK, then please give your Ack and I'll post a pull > request for 3.20 for the media git tree. Can you Ack this patch series? Thanks! Hans > > Regards, > > Hans > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[RFC 1/6] cec: add new driver for cec support.
On 12/23/2014 03:32 PM, Kamil Debski wrote: > From: Hans Verkuil > > Add the CEC framework. > > Signed-off-by: Hans Verkuil > [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] > [k.debski at samsung.com: Merged Update author commit by Hans Verkuil] > [k.debski at samsung.com: change kthread handling when setting logical > address] > [k.debski at samsung.com: code cleanup] > Signed-off-by: Kamil Debski > --- > cec-rfc.txt | 319 ++ > cec.txt | 40 ++ A note regarding these text files: cec-rfc.txt should go to Documentation/cec.txt. I'm not sure if it is up to date (Kamil, did you check?). The cec.txt file is basically a bunch of notes to myself when I was working on this. It contains some of the not-so-obvious CEC protocol specifications. It should either be deleted for the final version of this patch series, or it should be merged with cec-rfc.txt. Regards, Hans
[RFC 1/6] cec: add new driver for cec support.
On 12/23/2014 03:32 PM, Kamil Debski wrote:
> From: Hans Verkuil
>
> Add the CEC framework.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
> [k.debski at samsung.com: change kthread handling when setting logical
> address]
> [k.debski at samsung.com: code cleanup]
> Signed-off-by: Kamil Debski
> ---
> cec-rfc.txt | 319 ++
> cec.txt | 40 ++
> drivers/media/Kconfig|5 +
> drivers/media/Makefile |2 +
> drivers/media/cec.c | 1048
> ++
> include/media/cec.h | 129 ++
> include/uapi/linux/cec.h | 222 ++
> 7 files changed, 1765 insertions(+)
> create mode 100644 cec-rfc.txt
> create mode 100644 cec.txt
> create mode 100644 drivers/media/cec.c
> create mode 100644 include/media/cec.h
> create mode 100644 include/uapi/linux/cec.h
>
...
> diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
> new file mode 100644
> index 000..a2c78d7
> --- /dev/null
> +++ b/include/uapi/linux/cec.h
> @@ -0,0 +1,222 @@
> +#ifndef _CEC_H
> +#define _CEC_H
> +
> +#include
> +
> +struct cec_msg {
> + __u32 len;
> + __u8 msg[16];
> + __u32 status;
> + /* If non-zero, then wait for a reply with this opcode.
> +If there was an error when sending the msg or FeatureAbort
> +was returned, then reply is set to 0.
> +If reply is non-zero upon return, then len/msg are set to
> +the received message.
> +If reply is zero upon return and status has the
> CEC_TX_STATUS_FEATURE_ABORT
> +bit set, then len/msg are set to the received feature abort message.
> +If reply is zero upon return and status has the
> CEC_TX_STATUS_REPLY_TIMEOUT
> +bit set, then no reply was seen at all.
> +This field is ignored with CEC_RECEIVE.
> +If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
> +then -EINVAL is returned.
> +if reply is non-zero, then timeout is set to 1000 (the required
> maximum
> +response time).
> + */
> + __u8 reply;
> + /* timeout (in ms) is used to timeout CEC_RECEIVE.
> +Set to 0 if you want to wait forever. */
> + __u32 timeout;
> + struct timespec ts;
> +};
> +
> +static inline __u8 cec_msg_initiator(const struct cec_msg *msg)
> +{
> + return msg->msg[0] >> 4;
> +}
> +
> +static inline __u8 cec_msg_destination(const struct cec_msg *msg)
> +{
> + return msg->msg[0] & 0xf;
> +}
> +
> +static inline bool cec_msg_is_broadcast(const struct cec_msg *msg)
> +{
> + return (msg->msg[0] & 0xf) == 0xf;
> +}
> +
> +/* cec status field */
> +#define CEC_TX_STATUS_OK(0)
> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> +#define CEC_TX_STATUS_RETRY_TIMEOUT (1 << 1)
> +#define CEC_TX_STATUS_FEATURE_ABORT (1 << 2)
> +#define CEC_TX_STATUS_REPLY_TIMEOUT (1 << 3)
> +#define CEC_RX_STATUS_READY (0)
> +
> +#define CEC_LOG_ADDR_INVALID 0xff
> +
> +// The maximum number of logical addresses one device can be assigned to.
> +// The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
> +// Analog Devices CEC hardware supports 3. So let's go wild and go for 4.
> +#define CEC_MAX_LOG_ADDRS 4
> +
> +// "You are in a maze of twisty little defines, all alike"
> +// What were they thinking of when they came up with this mess...
> +
> +// The "Primary Device Type"
> +#define CEC_PRIM_DEVTYPE_TV 0
> +#define CEC_PRIM_DEVTYPE_RECORD 1
> +#define CEC_PRIM_DEVTYPE_TUNER 3
> +#define CEC_PRIM_DEVTYPE_PLAYBACK4
> +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5
> +#define CEC_PRIM_DEVTYPE_SWITCH 6
> +#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
> +
> +// The "All Device Types" flags (CEC 2.0)
> +#define CEC_FL_ALL_DEVTYPE_TV(1 << 7)
> +#define CEC_FL_ALL_DEVTYPE_RECORD(1 << 6)
> +#define CEC_FL_ALL_DEVTYPE_TUNER (1 << 5)
> +#define CEC_FL_ALL_DEVTYPE_PLAYBACK (1 << 4)
> +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
> +#define CEC_FL_ALL_DEVTYPE_SWITCH(1 << 2)
> +// And if you wondering what happened to VIDEOPROC devices: those should
> +// be mapped to a SWITCH.
> +
> +// The logical address types that the CEC device wants to claim
> +#define CEC_LOG_ADDR_TYPE_TV 0
> +#define CEC_LOG_ADDR_TYPE_RECORD 1
> +#define CEC_LOG_ADDR_TYPE_TUNER 2
> +#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
> +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM4
> +#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
> +#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
> +// Switches should use UNREGISTERED.
> +// Video processors should use SPECIFIC.
> +
> +// The CEC version
> +#define CEC_VERSION_1_4B 5
> +#define CEC_VERSION_2_0 6
> +
> +struct cec_event {
> + __u32 event;
> + struct ti
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Mon, Jan 12, 2015 at 10:25:28AM +0100, Philipp Zabel wrote:
> Jean-Francois' reply already reflects this, but the 'port' nodes should
> correspond to physical ports of the device if possible. If you can
> configure the device to have dedicated input pins for I2S, SPDIF0, and
> SPDIF1 at the same time, they should appear in the device tree as
> separate ports:
>
> tda998x: hdmi-encoder {
> port at 0 { /* pixel data according to video-ports */
> reg = <0x00>;
> };
> port at 1 { /* AP1: SPDIF0 */
> reg = <0x01>;
> };
> port at 2 { /* AP2: SPDIF1 */
> reg = <0x02>;
> };
> port at 3 { /* AP3: I2S */
> reg = <0x03>;
> };
> };
>
> The tda998x binding would define how the ports are numbered, some
> correspondence to the AP pin numbers would be good.
It's not quite that simple, because the SPDIF AP pins are multiplexed
with the I2S pins - and there is variation between chip models and
packages.
So, it's probably best if port at 0 is the video port, and then port at 1..n
can describe the audio inputs, including a property which specifies
whether they are I2S or SPDIF, and the value to be programmed into
the AP enable register (which is a bit field of the AP pins which
should be unmasked.) I guess we can re-use the reg= property for that
value, since video will always be zero.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[Bug 84835] GL_PRIMITIVE_RESTART_FIXED_INDEX uses glPrimitiveRestartIndex value and not fixed value
https://bugs.freedesktop.org/show_bug.cgi?id=84835 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marek Olšák --- Fixed with eaae92a349af1fd6641c4bdd4bfd1185b1b6fe. Closing. -- 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/20150112/7d53d51d/attachment.html>
[PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote: > Changes various calls in the functions,send_pkg_prepare and send_pkg_done > for mdelay to msleep. These changes are needed due to use working with > various sleep modes supported by this hardware and thus needing to sleep > for a small duration instead of using the respectful delay function due > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles > on the system that could be used to handle other tasks. > > Signed-off-by: Nicholas Krause NAK Like every other TODO you've been mucking with at random this one is there for a reason. We can't sleep at this point.
[PATCH] drm/i915: fix build for CONFIG_BUG=n
If CONFIG_BUG=n __WARN_printf won't be defined leading to the below
build failure. The double underscores should have told us to steer clear
of it anyway.
drivers/gpu/drm/i915/intel_display.c: In function âassert_pllâ:
drivers/gpu/drm/i915/intel_display.c:1027:2: error: implicit declaration
of function â__WARN_printfâ [-Werror=implicit-function-declaration]
I915_STATE_WARN(cur_state != state,
Use WARN(1, ...) instead. It handles CONFIG_BUG=n gracefully and, with
the constant condition, a sane compiler should reduce it to
__WARN_printf.
This is a regression introduced by
commit e2c719b75c8c186deb86570d8466df9e9eff919b
Author: Rob Clark
Date: Mon Dec 15 13:56:32 2014 -0500
drm/i915: tame the chattermouth (v2)
Reported-by: Jim Davis
Reference:
http://mid.gmane.org/CA+r1ZhgHTi7bS2irhtuSUs9aO=Br1dumN8=oAOeaMJDZ_ZhwBw at
mail.gmail.com
Cc: Rob Clark
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e008fa0c58da..66f0c607dbef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -83,7 +83,7 @@
int __ret_warn_on = !!(condition); \
if (unlikely(__ret_warn_on)) { \
if (i915.verbose_state_checks) \
- __WARN_printf(format); \
+ WARN(1, format);\
else\
DRM_ERROR(format); \
} \
@@ -94,7 +94,7 @@
int __ret_warn_on = !!(condition); \
if (unlikely(__ret_warn_on)) { \
if (i915.verbose_state_checks) \
- __WARN_printf("WARN_ON(" #condition ")\n"); \
+ WARN(1, "WARN_ON(" #condition ")\n"); \
else\
DRM_ERROR("WARN_ON(" #condition ")\n"); \
} \
--
2.1.4
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
Am Montag, den 12.01.2015, 12:25 + schrieb Russell King - ARM Linux:
> On Mon, Jan 12, 2015 at 10:25:28AM +0100, Philipp Zabel wrote:
> > Jean-Francois' reply already reflects this, but the 'port' nodes should
> > correspond to physical ports of the device if possible. If you can
> > configure the device to have dedicated input pins for I2S, SPDIF0, and
> > SPDIF1 at the same time, they should appear in the device tree as
> > separate ports:
> >
> > tda998x: hdmi-encoder {
> > port at 0 { /* pixel data according to video-ports */
> > reg = <0x00>;
> > };
> > port at 1 { /* AP1: SPDIF0 */
> > reg = <0x01>;
> > };
> > port at 2 { /* AP2: SPDIF1 */
> > reg = <0x02>;
> > };
> > port at 3 { /* AP3: I2S */
> > reg = <0x03>;
> > };
> > };
> >
> > The tda998x binding would define how the ports are numbered, some
> > correspondence to the AP pin numbers would be good.
>
> It's not quite that simple, because the SPDIF AP pins are multiplexed
> with the I2S pins - and there is variation between chip models and
> packages.
>
> So, it's probably best if port at 0 is the video port, and then port at 1..n
> can describe the audio inputs, including a property which specifies
> whether they are I2S or SPDIF, and the value to be programmed into
> the AP enable register (which is a bit field of the AP pins which
> should be unmasked.) I guess we can re-use the reg= property for that
> value, since video will always be zero.
Note that of_graph_parse_endpoint interprets the port node's reg
property as port id. And the unit address part of the node name should
match the first address in the reg property.
regards
Philipp
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote: > Am Montag, den 12.01.2015, 12:25 + schrieb Russell King - ARM Linux: > > It's not quite that simple, because the SPDIF AP pins are multiplexed > > with the I2S pins - and there is variation between chip models and > > packages. > > > > So, it's probably best if port at 0 is the video port, and then port at 1..n > > can describe the audio inputs, including a property which specifies > > whether they are I2S or SPDIF, and the value to be programmed into > > the AP enable register (which is a bit field of the AP pins which > > should be unmasked.) I guess we can re-use the reg= property for that > > value, since video will always be zero. > > Note that of_graph_parse_endpoint interprets the port node's reg > property as port id. And the unit address part of the node name should > match the first address in the reg property. So that's not going to work very well... because the AP register is a bitmask. I guess we could specify a node unit and reg, which the code otherwise ignores, and specify a philipps,ap-mask = property for the audio ports instead. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #8 from Arthur Marsh --- previous 2015011216dmesg.txt was inadvertantly with 3.19.0-rc3+ When playing the same video under kernel 3.19.0-rc4+ it played for longer before locking up. -- 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/20150112/d592c9d6/attachment.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #9 from Arthur Marsh --- Created attachment 112129 --> https://bugs.freedesktop.org/attachment.cgi?id=112129&action=edit 20150113dmesg.txt - video run under kernel 3.19.0-rc4+ -- 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/20150112/da499cc4/attachment.html>
[PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote: > On Mon, Jan 12, 2015 at 01:29:27PM +, Alan Cox wrote: > > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote: > > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done > > > for mdelay to msleep. These changes are needed due to use working with > > > various sleep modes supported by this hardware and thus needing to sleep > > > for a small duration instead of using the respectful delay function due > > > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles > > > on the system that could be used to handle other tasks. > > > > > > Signed-off-by: Nicholas Krause > > > > NAK > > > > Like every other TODO you've been mucking with at random this one is > > there for a reason. > > > > We can't sleep at this point. > > From a quick look it seems like the only reason why we can't sleep is > because sender->lock is a spinlock. But it would seem that it could > simply be a mutex, in which case the delays could become sleeps. > > Do you happen to remember if there were specific reasons to make this a > spinlock rather than a mutex? I don't remember the full details and since I don't currently have a test platform for it, and its obsolete I don't want to touch it. If someone else does fine, but they need to verify it on real hardware. Alan
[Bug 90851] radeonsi on pitcairn: nine and skyrim - unable to handle kernel paging request
https://bugzilla.kernel.org/show_bug.cgi?id=90851 --- Comment #3 from Christoph Haag --- Hm, interesting. I compiled 3.19-rc4 with debug symbols. I'm also testing Tom Stellard's VGPR register spilling llvm and mesa branches. After a while of playing skyrim I got the familiar hang where skyrim just freezes, but I did NOT get "BUG: unable to handle kernel paging request" in the system log. Instead I got this in the terminal from which I started skyrim: radeon: mmap failed, errno: 12 radeon: mmap failed, errno: 12 radeon: mmap failed, errno: 12 radeon: mmap failed, errno: 12 I'm not very good with the wine debugger... Attaching to the TESV.exe process and then getting a backtrace shows: Wine-dbg>bt Backtrace: =>0 0xf7702bee __kernel_vsyscall+0xe() in [vdso].so (0x7eada510) 1 0xf7514e02 __lll_lock_wait+0x21() in libpthread.so.0 (0x7eada510) 2 0xf750f5ae __GI___pthread_mutex_lock+0x8d() in libpthread.so.0 (0x7eada510) 3 0xed73ba1d in d3dadapter9.so.1 (+0x128a1c) (0x7eada510) 4 0x0069df9c in tesv (+0x29df9b) (0x7eada510) 5 0xfff0e400 (0x526077e9) I would try to find out where exactly in d3dadapter9.so.1 this happens but I don't get how to properly attach winedbg --gdb and addr2linux didn't give a line with code, so I probably used it wrong. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Mon, 12 Jan 2015 14:04:56 +
Russell King - ARM Linux wrote:
> On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote:
> > Am Montag, den 12.01.2015, 12:25 + schrieb Russell King - ARM Linux:
> > > It's not quite that simple, because the SPDIF AP pins are multiplexed
> > > with the I2S pins - and there is variation between chip models and
> > > packages.
> > >
> > > So, it's probably best if port at 0 is the video port, and then port at
> > > 1..n
> > > can describe the audio inputs, including a property which specifies
> > > whether they are I2S or SPDIF, and the value to be programmed into
> > > the AP enable register (which is a bit field of the AP pins which
> > > should be unmasked.) I guess we can re-use the reg= property for that
> > > value, since video will always be zero.
> >
> > Note that of_graph_parse_endpoint interprets the port node's reg
> > property as port id. And the unit address part of the node name should
> > match the first address in the reg property.
This is not the case in vexpress-v2p-ca15_a7.dts.
> So that's not going to work very well... because the AP register is a
> bitmask.
>
> I guess we could specify a node unit and reg, which the code otherwise
> ignores, and specify a philipps,ap-mask = property for the audio ports
> instead.
Also, the video and audio ports must be distinguished. They could be
defined in different port groups.
Example from the Cubox:
video-ports: ports at 0 {
port {
tda998x_video: endpoint {
remote-endpoint = <&lcd0_0>;
nxp,video-port = <0x230145>;
};
};
};
audio-ports: ports at 1 {
port at 0 { /* AP1 = I2S */
tda998x_i2s: endpoint at 0 {
remote-endpoint = <&audio1_i2s>;
nxp,audio-port = <0x03>;
};
};
port at 1 { /* AP2 = S/PDIF */
tda998x_spdif: endpoint at 1 {
remote-endpoint = <&audio1_spdif1>;
nxp,audio-port = <0x04>;
};
};
};
The port type is identified by the bit AP0.
--
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Mon, Jan 12, 2015 at 06:13:41PM +0100, Jean-Francois Moine wrote:
> On Mon, 12 Jan 2015 14:04:56 +
> Russell King - ARM Linux wrote:
> > On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote:
> > > Note that of_graph_parse_endpoint interprets the port node's reg
> > > property as port id. And the unit address part of the node name should
> > > match the first address in the reg property.
>
> This is not the case in vexpress-v2p-ca15_a7.dts.
Hmm... as the DT binding doc doesn't specify this restriction, and we
have a DT file which violates what Philipp has said, I think we ought
to document that reg vs unit node name does not need to match each
other, thereby making that official.
> > So that's not going to work very well... because the AP register is a
> > bitmask.
> >
> > I guess we could specify a node unit and reg, which the code otherwise
> > ignores, and specify a philipps,ap-mask = property for the audio ports
> > instead.
>
> Also, the video and audio ports must be distinguished. They could be
> defined in different port groups.
>
> Example from the Cubox:
>
> video-ports: ports at 0 {
> port {
> tda998x_video: endpoint {
> remote-endpoint = <&lcd0_0>;
> nxp,video-port = <0x230145>;
> };
> };
> };
> audio-ports: ports at 1 {
> port at 0 { /* AP1 = I2S */
> tda998x_i2s: endpoint at 0 {
> remote-endpoint = <&audio1_i2s>;
> nxp,audio-port = <0x03>;
> };
> };
> port at 1 { /* AP2 = S/PDIF */
> tda998x_spdif: endpoint at 1 {
> remote-endpoint = <&audio1_spdif1>;
> nxp,audio-port = <0x04>;
> };
> };
> };
>
> The port type is identified by the bit AP0.
I don't particularly like that - that makes the assumption that AP0
always means I2S. What if a future chip decides to allow SPDIF on
AP0? Why should we need to re-invent the binding?
IMHO, it would be much better to make this explicit.
Note that the "video-ports" and "audio-ports" are just labels in the
DT file; they aren't carried through to the resulting DT binary file,
so they don't have any meaning to the kernel.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[PATCH 1/2] drm/exynos: remove leftover code using event_list
From: Gustavo Padovan
The drm_file event_list hasn't been used anymore by exynos, so we don't
need any code to clean it.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 25ba362..b60fd9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -256,11 +256,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
}
- /* Release all events handled by page flip handler but not freed. */
- list_for_each_entry_safe(e, et, &file->event_list, link) {
- list_del(&e->link);
- e->destroy(e);
- }
spin_unlock_irqrestore(&dev->event_lock, flags);
kfree(file->driver_priv);
--
1.9.3
[PATCH 2/2] drm/exynos: track vblank events on a per crtc basis
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.
Signed-off-by: Mandeep Singh Baines
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 39
drivers/gpu/drm/exynos/exynos_drm_drv.c | 19
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++---
3 files changed, 12 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a85c451..b1f1b25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
- !atomic_read(&exynos_crtc->pending_flip),
- HZ/20))
- atomic_set(&exynos_crtc->pending_flip, 0);
+ (exynos_crtc->event == NULL), HZ/20))
+ exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}
@@ -166,7 +165,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
uint32_t page_flip_flags)
{
struct drm_device *dev = crtc->dev;
- struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
@@ -194,12 +192,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}
- spin_lock_irq(&dev->event_lock);
- list_add_tail(&event->base.link,
- &dev_priv->pageflip_event_list);
- atomic_set(&exynos_crtc->pending_flip, 1);
- spin_unlock_irq(&dev->event_lock);
-
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
@@ -209,14 +201,12 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
*crtc,
if (ret) {
crtc->primary->fb = old_fb;
- spin_lock_irq(&dev->event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
- list_del(&event->base.link);
- atomic_set(&exynos_crtc->pending_flip, 0);
- spin_unlock_irq(&dev->event_lock);
goto out;
}
+
+ exynos_crtc->event = event;
}
out:
mutex_unlock(&dev->struct_mutex);
@@ -315,7 +305,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);
init_waitqueue_head(&exynos_crtc->pending_flip_queue);
- atomic_set(&exynos_crtc->pending_flip, 0);
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
exynos_crtc->pipe = pipe;
@@ -382,27 +371,19 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int pipe)
void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
{
struct exynos_drm_private *dev_priv = dev->dev_private;
- struct drm_pending_vblank_event *e, *t;
struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
- unsigned long flags;
- spin_lock_irqsave(&dev->event_lock, flags);
+ if (exynos_crtc->event) {
- list_for_each_entry_safe(e, t, &dev_priv->pageflip_event_list,
- base.link) {
- /* if event's pipe isn't same as crtc then ignore it. */
- if (pipe != e->pipe)
- continue;
-
- list_del(&e->base.link);
- drm_send_vblank_event(dev, -1, e);
+ spin_lock_irq(&dev->event_lock);
+ drm_send_vblank_event(dev, -1, exynos_crtc->event);
drm_vblank_put(dev, pipe);
- atomic_set(&exynos_crtc->pending_flip, 0);
wake_up(&exynos_crtc->pending_flip_queue);
- }
+ spin_unlock_irq(&dev->event_lock);
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ exynos_crtc->event = NULL;
+ }
}
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_dr
[PATCH 1/3] nouveau: Do not BUG_ON(!spin_is_locked()) on UP
Hi Greg, stable team,
Please apply this patch to stable (3.18 and 3.17).
It is commit ff4c0d5213b015e60aa87c1352604f10ba9c3e12 in linus's tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff4c0d5213b015e60aa87c1352604f10ba9c3e12
Thanks,
Bruno
On Sun, 21 December 2014 Bruno Prémont wrote:
> On !SMP systems spinlocks do not exist. Thus checking of they
> are active will always fail.
>
> Use
> assert_spin_locked(lock);
> instead of
> BUG_ON(!spin_is_locked(lock));
> to not BUG() on all UP systems.
>
> Signed-off-by: Bruno Prémont
> ---
> See also fdo bug #87552
>
> drivers/gpu/drm/nouveau/core/core/event.c | 4 ++--
> drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
> b/drivers/gpu/drm/nouveau/core/core/event.c
> index ff2b434..760947e 100644
> --- a/drivers/gpu/drm/nouveau/core/core/event.c
> +++ b/drivers/gpu/drm/nouveau/core/core/event.c
> @@ -26,7 +26,7 @@
> void
> nvkm_event_put(struct nvkm_event *event, u32 types, int index)
> {
> - BUG_ON(!spin_is_locked(&event->refs_lock));
> + assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (--event->refs[index * event->types_nr + type] == 0) {
> @@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int
> index)
> void
> nvkm_event_get(struct nvkm_event *event, u32 types, int index)
> {
> - BUG_ON(!spin_is_locked(&event->refs_lock));
> + assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (++event->refs[index * event->types_nr + type] == 1) {
> diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c
> b/drivers/gpu/drm/nouveau/core/core/notify.c
> index d1bcde5..839a325 100644
> --- a/drivers/gpu/drm/nouveau/core/core/notify.c
> +++ b/drivers/gpu/drm/nouveau/core/core/notify.c
> @@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data,
> u32 size)
> struct nvkm_event *event = notify->event;
> unsigned long flags;
>
> - BUG_ON(!spin_is_locked(&event->list_lock));
> + assert_spin_locked(&event->list_lock);
> BUG_ON(size != notify->size);
>
> spin_lock_irqsave(&event->refs_lock, flags);
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Mon, 12 Jan 2015 17:57:06 + Russell King - ARM Linux wrote: > I don't particularly like that - that makes the assumption that AP0 > always means I2S. What if a future chip decides to allow SPDIF on > AP0? Why should we need to re-invent the binding? > > IMHO, it would be much better to make this explicit. OK. > Note that the "video-ports" and "audio-ports" are just labels in the > DT file; they aren't carried through to the resulting DT binary file, > so they don't have any meaning to the kernel. Right, so, either the port type must be explicitly defined, or the name of the property giving the port value also gives the port type (nxp,video-port / nxp,audio-port). -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 88263] Civilization Beyond Earth crashes on r600
https://bugs.freedesktop.org/show_bug.cgi?id=88263 --- Comment #1 from Joti Papadopoulos --- Same issue here and i'm also using git(67208.e28f9d0 to be precise, but this issue has been present since the games release). This is also an issue with 10.3.2 and 10.3.5, but i havent tested any other official releases. Also of note is when the game crashes i initially get a black screen for about 10secs and then the screen turns white. After a crash the kernel seems unresponsive as magic keys don't work. System: Arch Linux 64bit CPU: AMD Phenom2 X3 720 GPU: AMD HD5850( Mesa git 67208.e28f9d0) RAM: 8GB DE: KDE4 Kernel 3.17.6-1-ARCH Xorg 1.16 DPM is enabled Let me know if any more info is needed -- 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/20150112/db7492c3/attachment.html>
[PATCH v2 2/2] video: Drop superfluous "select VT_HW_CONSOLE_BINDING"
commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
VT_HW_CONSOLE_BINDING, but forgot to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split in two (drm and video) patches.
---
drivers/video/fbdev/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4916c97216f880fc..f2c3fb7d03992ad1 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2151,7 +2151,6 @@ config FB_PS3
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
---help---
Include support for the virtual frame buffer in the PS3 platform.
--
1.9.1
[PATCH v2 1/2] drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
commit 765d5b9c2b72f5b9 ("fbdev: fbcon: select VT_HW_CONSOLE_BINDING")
made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot
to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Remove it, also from new drivers.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split in two (drm and video) patches,
- Fix recently added rockchip.
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/rockchip/Kconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9e9b7e7992..c072999b7e0345c6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -6,7 +6,6 @@ config DRM_EXYNOS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ca9f085efa922982..8652dad82009e3ce 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,6 @@ config DRM_ROCKCHIP
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Rockchip soc chipset.
--
1.9.1
[PATCH 01/29] drm/exynos/fimd: only finish pageflip if START == START_S
2014-12-30 Inki Dae :
> On 2014ë
12ì 18ì¼ 22:58, Gustavo Padovan wrote:
> > From: Daniel Kurtz
> >
> > A framebuffer gets committed to FIMD's default window like this:
> > exynos_drm_crtc_update()
> > exynos_plane_commit()
> >fimd_win_commit()
> >
> > fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
> > copies the value from BUF_START to BUF_START_S (BUF_START's shadow
> > register), starts scanning out from BUF_START_S, and asserts its irq.
> >
> > This irq is handled by fimd_irq_handler(), which calls
> > exynos_drm_crtc_finish_pageflip() to free the old buffer that FIMD just
> > finished scanning out, and potentially commit the next pending flip.
> >
> > There is a race, however, if fimd_win_commit() programs BUF_START(0)
> > between the actual vblank irq, and its corresponding fimd_irq_handler().
> >
> > => FIMD vblank: BUF_START_S[0] := BUF_START[0], and irq asserted
> > | => fimd_win_commit(0) writes new BUF_START[0]
> > |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> > => fimd_irq_handler()
> > exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> > and unmaps "old" fb
> > ==> but, since BUF_START_S[0] still points to that "old" fb...
> > ==> FIMD iommu fault
> >
> > This patch ensures that fimd_irq_handler() only calls
> > exynos_drm_crtc_finish_pageflip() if any previously scheduled flip
> > has really completed.
> >
> > This works because exynos_drm_crtc's flip fifo ensures that
> > fimd_win_commit() is never called more than once per
> > exynos_drm_crtc_finish_pageflip().
> >
> > Signed-off-by: Daniel Kurtz
> > Reviewed-by: Sean Paul
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 ++
> > include/video/samsung_fimd.h | 1 +
> > 2 files changed, 23 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index e5810d1..b379182 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -55,6 +55,7 @@
> > #define VIDOSD_D(win) (VIDOSD_BASE + 0x0C + (win) * 16)
> >
> > #define VIDWx_BUF_START(win, buf) (VIDW_BUF_START(buf) + (win) * 8)
> > +#define VIDWx_BUF_START_S(win, buf) (VIDW_BUF_START_S(buf) + (win) * 8)
> > #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 8)
> > #define VIDWx_BUF_SIZE(win, buf) (VIDW_BUF_SIZE(buf) + (win) * 4)
> >
> > @@ -1039,6 +1040,7 @@ static irqreturn_t fimd_irq_handler(int irq, void
> > *dev_id)
> > {
> > struct fimd_context *ctx = (struct fimd_context *)dev_id;
> > u32 val, clear_bit;
> > + u32 start, start_s;
> >
> > val = readl(ctx->regs + VIDINTCON1);
> >
> > @@ -1050,15 +1052,31 @@ static irqreturn_t fimd_irq_handler(int irq, void
> > *dev_id)
> > if (ctx->pipe < 0 || !ctx->drm_dev)
> > goto out;
> >
> > - if (ctx->i80_if) {
> > + if (!ctx->i80_if)
> > + drm_handle_vblank(ctx->drm_dev, ctx->pipe);
> > +
> > + /*
> > +* Ensure finish_pageflip is called iff a pending flip has completed.
>
> Maybe s/iff/if
>
> > +* This works around a race between a page_flip request and the latency
> > +* between vblank interrupt and this irq_handler:
> > +* => FIMD vblank: BUF_START_S[0] := BUF_START[0], and asserts irq
> > +* | => fimd_win_commit(0) writes new BUF_START[0]
> > +* |exynos_drm_crtc_try_do_flip() marks exynos_fb as prepared
> > +* => fimd_irq_handler()
> > +* exynos_drm_crtc_finish_pageflip() sees prepared exynos_fb,
> > +* and unmaps "old" fb
> > +* ==> but, since BUF_START_S[0] still points to that "old" fb...
> > +* ==> FIMD iommu fault
> > +*/
> > + start = readl(ctx->regs + VIDWx_BUF_START(0, 0));
> > + start_s = readl(ctx->regs + VIDWx_BUF_START_S(0, 0));
> > + if (start == start_s)
> > exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
>
> As I already mentioned before, above codes should be called only in case
> of RGB mode until checked for i80 mode. Have you ever tested above codes
> on i80 mode?
I haven't tested it as I don't have any hardware that does i80 mode.
Let's keep this check only for !i80 then.
>
> And what if 'start_s' has a value different from one of 'start'? Is it
> ok to skip finish_pageflip request this time? Shouldn't it ensure to
> wait for that until 'start_s' has a value same as one of 'start'?
I think it is okay to skip finish_pageflip, but we could return directly
if they are different, so we keep the wait_vsync_queue running until the next
irq happens or it timeouts. How does this look to you?
Gustavo
[PATCH 0/9] drm/amdkfd: initial support for VI APU
On Thu, Jan 8, 2015 at 11:15 AM, Oded Gabbay wrote: > This patch-set starts to prepare amdkfd so it could support VI APU. > > 1. As newer H/W will be handled by amdgpu, we need to eliminate amdkfd's >include of radeon header files. > > 2. MQDs are different between CI and VI, so we need to split the MQD manager >module to CI-specific and VI-specific. > > 3. Some new fields and enums need to be added to different structures. > > Note: there is no change in the IOCTLs. Series is: Reviewed-by: Alex Deucher > > Oded > > Ben Goz (5): > drm/amd: Put cik structures in a common place > drm/amdkfd: Add new VI-specific queue properties > drm/amdkfd: Make KFD_MQD_TYPE enum types H/W agnostic > drm/amdkfd: Add asic property to kfd_device_info > drm/amdkfd: Change MQD manager to be H/W specific > > Oded Gabbay (4): > drm/radeon: Don't use relative paths in #include > drm/radeon: Use new cik_structs.h file > drm/amdkfd: Don't include header files from radeon > MAINTAINERS: Update amdkfd files > > MAINTAINERS| 2 + > drivers/gpu/drm/amd/amdkfd/Makefile| 1 + > drivers/gpu/drm/amd/amdkfd/cik_regs.h | 13 + > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 31 +- > drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 +- > .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 15 +- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 435 +--- > drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 454 > + > drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c| 33 ++ > drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 23 +- > drivers/gpu/drm/amd/include/cik_structs.h | 293 + > drivers/gpu/drm/radeon/Makefile| 2 +- > drivers/gpu/drm/radeon/cik_reg.h | 264 > drivers/gpu/drm/radeon/radeon_kfd.c| 1 + > drivers/gpu/drm/radeon/radeon_kfd.h| 2 +- > 16 files changed, 871 insertions(+), 710 deletions(-) > create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c > create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c > create mode 100644 drivers/gpu/drm/amd/include/cik_structs.h > > -- > 1.9.1 >
Softlockup on boot with Cape Verde XT on many kernels
On Sun, Jan 11, 2015 at 3:27 PM, Federico wrote: > Ubuntu 14.10 (kernel is 3.16.0) with nomodeset also boots. But it seems to > be using the a generic driver Right. As I mentioned, using nomodeset disables the gfx driver and you end up with fw drivers (vesa of efifb). Do you still have the issue even with nomodeset as you previously stated? Alex > > cat /var/log/kern.log | grep ERROR > Jan 11 20:07:56 ubuntu kernel: [6.174086] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > Jan 11 20:07:56 ubuntu kernel: [ 54.093686] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > Jan 11 20:08:10 ubuntu kernel: [ 94.983647] [drm:radeon_init] *ERROR* No > UMS support in radeon module! > > glxinfo | grep Open > OpenGL vendor string: VMware, Inc. > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) > OpenGL version string: 3.0 Mesa 10.3.0 > OpenGL shading language version string: 1.30 > OpenGL context flags: (none) > OpenGL extensions: > > > 2015-01-11 19:44 GMT+00:00 Federico : >> >> >> >> 2015-01-11 14:19 GMT-03:00 Alex Deucher : >>> >>> Booting with nomodeset disables the graphics drivers so if you are >>> still getting problems, it may a hardware problem. Can you attach >>> your full dmesg and lspci output? Are you disabling the onboard >>> graphics when enabling the external dGPU? >>> >>> Alex >> >> >> I attached those outputs to >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 >> I wasn't sure if you meant attaching to this response. >> >> I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a >> graphic log in screen, but I also get some errors in the kernel log >> >> [drm:radeon_init] *ERROR* No UMS support in radeon module! >> >> Which seems by design so I assume the VESA driver was in use. >> >> I will try to boot Ubuntu 14.10 live image with nomodeset to see if I can >> get some error messages there. > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #5 from Alex Deucher --- Does forcing the GPU clocks to high help? E.g., as root: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #28 from Alex Deucher --- Created attachment 112144 --> https://bugs.freedesktop.org/attachment.cgi?id=112144&action=edit temporary workaround The attached patch adds a temporary workaround until I sort out what's wrong with the higher mclk. -- 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/20150112/aee6bce9/attachment-0001.html>
[PULL] topic/i915-hda-componentized
Hi Takashi, So here's the stable tag with Imre's i915/hda componentized refactoring, based upon 3.19-rc4. I'll pull in the same tag into drm-intel-next. Cheers, Daniel The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/i915-hda-componentized-2015-01-12 for you to fetch changes up to fcf3aac5fc307f0cae429f5844ddc25761662858: drm/i915: remove unused power_well/get_cdclk_freq api (2015-01-12 02:48:24 +0100) Imre Deak (6): drm/i915: add dev_to_i915 helper drm/i915: add component support ALSA: hda: export struct hda_intel ALSA: hda: pass intel_hda to all i915 interface functions ALSA: hda: add component support drm/i915: remove unused power_well/get_cdclk_freq api drivers/gpu/drm/i915/i915_dma.c | 4 + drivers/gpu/drm/i915/i915_drv.c | 9 +- drivers/gpu/drm/i915/i915_drv.h | 8 ++ drivers/gpu/drm/i915/intel_audio.c | 110 +++ drivers/gpu/drm/i915/intel_drv.h| 2 + drivers/gpu/drm/i915/intel_runtime_pm.c | 56 include/drm/i915_component.h| 38 include/drm/i915_powerwell.h| 37 sound/pci/hda/hda_i915.c| 154 ++-- sound/pci/hda/hda_i915.h| 37 sound/pci/hda/hda_intel.c | 60 - sound/pci/hda/hda_intel.h | 71 +++ 12 files changed, 361 insertions(+), 225 deletions(-) create mode 100644 include/drm/i915_component.h delete mode 100644 include/drm/i915_powerwell.h delete mode 100644 sound/pci/hda/hda_i915.h create mode 100644 sound/pci/hda/hda_intel.h -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/2] drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
On Mon, Jan 12, 2015 at 09:10:12PM +0100, Geert Uytterhoeven wrote:
> commit 765d5b9c2b72f5b9 ("fbdev: fbcon: select VT_HW_CONSOLE_BINDING")
> made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot
> to remove
>
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
>
> Remove it, also from new drivers.
>
> Signed-off-by: Geert Uytterhoeven
Merged into my drm misc branch, thanks.
-Daniel
> ---
> v2:
> - Split in two (drm and video) patches,
> - Fix recently added rockchip.
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 -
> drivers/gpu/drm/rockchip/Kconfig | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9e9b7e7992..c072999b7e0345c6 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -6,7 +6,6 @@ config DRM_EXYNOS
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> select VIDEOMODE_HELPERS
> help
>Choose this option if you have a Samsung SoC EXYNOS chipset.
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index ca9f085efa922982..8652dad82009e3ce 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -7,7 +7,6 @@ config DRM_ROCKCHIP
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> select VIDEOMODE_HELPERS
> help
>Choose this option if you have a Rockchip soc chipset.
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Softlockup on boot with Cape Verde XT on many kernels
No, with nomodeset I don't have the softlockup and I can boot, but Xorg does not load the radeon driver. The kernel logs some radeon errors $ dmesg | grep drm [6.139753] [drm] Initialized drm 1.1.0 20060810 [6.173103] [drm] VGACON disable radeon kernel modesetting. [6.173153] [drm:radeon_init] *ERROR* No UMS support in radeon module! [ 50.032476] [drm] VGACON disable radeon kernel modesetting. [ 50.032494] [drm:radeon_init] *ERROR* No UMS support in radeon module! [ 89.408520] [drm] VGACON disable radeon kernel modesetting. [ 89.408526] [drm:radeon_init] *ERROR* No UMS support in radeon module! Here's Xorg.log. It tries to load radeon, but then in unloads it. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4296840/+files/Xorg.0.log I also checked the bios and yes, the IGP is disabled and the setting is set to start from the PCI Express slot. 2015-01-12 21:48 GMT+00:00 Alex Deucher : > On Sun, Jan 11, 2015 at 3:27 PM, Federico wrote: > > Ubuntu 14.10 (kernel is 3.16.0) with nomodeset also boots. But it seems > to > > be using the a generic driver > > Right. As I mentioned, using nomodeset disables the gfx driver and > you end up with fw drivers (vesa of efifb). Do you still have the > issue even with nomodeset as you previously stated? > > Alex > > > > > cat /var/log/kern.log | grep ERROR > > Jan 11 20:07:56 ubuntu kernel: [6.174086] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > Jan 11 20:07:56 ubuntu kernel: [ 54.093686] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > Jan 11 20:08:10 ubuntu kernel: [ 94.983647] [drm:radeon_init] *ERROR* > No > > UMS support in radeon module! > > > > glxinfo | grep Open > > OpenGL vendor string: VMware, Inc. > > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) > > OpenGL version string: 3.0 Mesa 10.3.0 > > OpenGL shading language version string: 1.30 > > OpenGL context flags: (none) > > OpenGL extensions: > > > > > > 2015-01-11 19:44 GMT+00:00 Federico : > >> > >> > >> > >> 2015-01-11 14:19 GMT-03:00 Alex Deucher : > >>> > >>> Booting with nomodeset disables the graphics drivers so if you are > >>> still getting problems, it may a hardware problem. Can you attach > >>> your full dmesg and lspci output? Are you disabling the onboard > >>> graphics when enabling the external dGPU? > >>> > >>> Alex > >> > >> > >> I attached those outputs to > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973 > >> I wasn't sure if you meant attaching to this response. > >> > >> I was able to boot with nomodeset into Ubuntu 15.04's image. I get to a > >> graphic log in screen, but I also get some errors in the kernel log > >> > >> [drm:radeon_init] *ERROR* No UMS support in radeon module! > >> > >> Which seems by design so I assume the VESA driver was in use. > >> > >> I will try to boot Ubuntu 14.10 live image with nomodeset to see if I > can > >> get some error messages there. > > > > > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150112/7cc0f763/attachment.html>
[PATCH 1/3] ARM: dts: add fimd device support for exynos3250-rinato
On 01/03/15 15:50, Inki Dae wrote:
> On 2014ë
11ì 28ì¼ 20:39, Inki Dae wrote:
>> This patch adds fimd device node which is a display controller
>> for Exynos3250 Rinato board.
>
> Hi Kukjin,
>
> Please, ping~
>
> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> arch/arm/boot/dts/exynos3250-rinato.dts | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>> index 80aa8b4..79aa916 100644
>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>> @@ -125,6 +125,17 @@
>> };
>> };
>>
>> +&fimd {
>> +status = "okay";
>> +
>> +i80-if-timings {
>> +cs-setup = <0>;
>> +wr-setup = <0>;
>> +wr-act = <1>;
>> +wr-hold = <0>;
>> +};
>> +};
>> +
>> &i2c_0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
Applied this and 3rd one.
BTW, I can't see the "samsung,s6e63j0x03" support yet?
- Kukjin
[PATCH] drm: Add support to find drm_panel by name
For scenarios where OF is not available, we can use panel identification by
name.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/drm_panel.c | 18 ++
include/drm/drm_panel.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..e1cb8cf 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -95,6 +95,24 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
EXPORT_SYMBOL(of_drm_find_panel);
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name)
+{
+ struct drm_panel *panel;
+
+ mutex_lock(&panel_lock);
+
+ list_for_each_entry(panel, &panel_list, list) {
+ if (strcmp(panel->name, name) == 0) {
+ mutex_unlock(&panel_lock);
+ return panel;
+ }
+ }
+
+ mutex_unlock(&panel_lock);
+ return NULL;
+}
+EXPORT_SYMBOL(drm_find_panel_by_name);
+
MODULE_AUTHOR("Thierry Reding ");
MODULE_DESCRIPTION("DRM panel infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..1ef9ff3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -74,6 +74,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+ char name[NAME_MAX];
const struct drm_panel_funcs *funcs;
@@ -137,4 +138,6 @@ static inline struct drm_panel *of_drm_find_panel(struct
device_node *np)
}
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name);
+
#endif
--
1.9.1
[PATCH] gpu:drm:Change calls to mdelay to msleep in the functions,send_pkg_prepare and send_pkg_done for the file,mdfld_dsi_pkg_sender.c
On Mon, Jan 12, 2015 at 01:29:27PM +, Alan Cox wrote: > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote: > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done > > for mdelay to msleep. These changes are needed due to use working with > > various sleep modes supported by this hardware and thus needing to sleep > > for a small duration instead of using the respectful delay function due > > to the need to sleep rather then busy loop the CPU(s) and waste CPU cycles > > on the system that could be used to handle other tasks. > > > > Signed-off-by: Nicholas Krause > > NAK > > Like every other TODO you've been mucking with at random this one is > there for a reason. > > We can't sleep at this point.
[PATCH] drm/i915: fix inconsistent brightness after resume
Jani,
On Mon, Jan 12, 2015 at 12:31:09PM +0200, Jani Nikula wrote:
> On Sat, 10 Jan 2015, Jeremiah Mahler wrote:
[...]
>
> I think part of the problem is that the userspace sets brightness to
> minimum before suspend, but apparently does not restore it after
> resume. The dmesg would confirm this. But I guess it doesn't matter,
> since we're pretty much stuck with having to do this anyway.
>
I did notice it doing this. There were several calls to *_update_status
as it was entering suspend which set it to the minimum.
I am not familiar with the intricate details of this system but it seems
like there must be a way to fix this. If the backlight can be powered
off and back on with the correct level it seems like it should be
possible when a suspend/resume is involved.
[...]
> > - if (panel->backlight.level == 0) {
> > + if (panel->backlight.level == panel->backlight.min) {
>
> Perhaps <= instead of == would be safest?
>
We could do that too in case that corner case ever arises.
[...]
I will fix it up in v2.
--
- Jeremiah Mahler
[PATCH v2] drm/i915: fix inconsistent brightness after resume
Commit 6dda730e55f4 introduced a bug which resulted in inconsistent
brightness levels on different machines. If a suspended was entered
with the screen off some machines would resume with the screen
at minimum brightness and others at maximum brightness.
The following commands can be used to produce this behavior.
xset dpms force off
sleep 1
sudo systemctl suspend
(resume ...)
The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled. If it is zero,
it is set to the maximum level. Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.
Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero. Also, expand the comparison for
the possible case when the level is less than the minimum.
Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler
---
Notes:
Changes in v2:
- Expand the comparision for the possible case when
the level is less than the minimum.
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 4d63839..dfb783a 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -962,7 +962,7 @@ void intel_panel_enable_backlight(struct intel_connector
*connector)
WARN_ON(panel->backlight.max == 0);
- if (panel->backlight.level == 0) {
+ if (panel->backlight.level <= panel->backlight.min) {
panel->backlight.level = panel->backlight.max;
if (panel->backlight.device)
panel->backlight.device->props.brightness =
--
2.1.4
[PATCH] next: drm/atomic: Use copy_from_user to copy 64 bit data from user space
Copying 64 bit data from user space using get_user is not supported
on all architectures, and may result in the following build error.
ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
Avoid the problem by using copy_from_user.
Fixes: d34f20d6e2f2 ("drm: Atomic modeset ioctl")
Cc: Rob Clark
Signed-off-by: Guenter Roeck
---
Compile tested only.
drivers/gpu/drm/drm_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1e38dfc..af3f3df 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1259,7 +1259,9 @@ retry:
goto fail;
}
- if (get_user(prop_value, prop_values_ptr +
copied_props)) {
+ if (copy_from_user(&prop_value,
+ prop_values_ptr + copied_props,
+ sizeof(prop_value))) {
ret = -EFAULT;
goto fail;
}
--
2.1.0
