[PATCH v6 00/14] drm/exynos: support LCD I80 interface display

On 2014? 07? 17? 18:01, YoungJun Cho wrote: > Hi, > > This series adds LCD I80 interface display support for Exynos DRM driver. > The FIMD(display controller) specification describes it as "LCD I80 interface" > and the DSI specification describes it as "Command mode interface". > > This is based

[PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three

On 2014? 07? 03? 22:10, Andrzej Hajda wrote: > This set of independent patches contains various improvement and fixes > for exynos_drm ipp framework. > The patchset is based on exynos-drm-next branch. Applied. Thanks, Inki Dae > > Regards > Andrzej > > > Andrzej Hajda (12): >

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #11 from Alex Deucher --- You can leave the radeon driver as a module and just not unload it. There's generally no reason to. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Andrea Patern? changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

Hi Varka, On 07/22/2014 08:14 PM, Varka Bhadram wrote: > On 07/22/2014 04:40 PM, YoungJun Cho wrote: >> Hi Varka, >> >> This irq handler should be registered in attach() and unregistered in >> detach(). >> >> The devm_* APIs are released(freed) in remove(), right? >> >> Logically the panel could

[PATCH] drm: shmobile: fix warnings

On 22 July 2014 18:52, Russell King - ARM Linux wrote: > On Sun, Jul 13, 2014 at 12:19:03PM +0100, Russell King wrote: >> drivers/gpu/drm/shmobile/shmob_drm_drv.c:300:5: warning: "CONFIG_PM_SLEEP" >> is not defined [-Wundef] >> >> Always use #ifdef with CONFIG symbols, never just bare #if >> >>

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

Hi Varka, This irq handler should be registered in attach() and unregistered in detach(). The devm_* APIs are released(freed) in remove(), right? Logically the panel could be attached and detached several times after dsi is probed and not removed. So I don't use devm_* APIs. Thank you. Best

[PATCH v4 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver

On Tuesday 22 July 2014 06:41 PM, Boris BREZILLON wrote: > The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12, > at91sam9x5 family or sama5d3 family) provide a PWM device. > > The DT bindings used for this PWM device is following the default 3 cells > bindings described in

[PATCH v4 02/11] mfd: add documentation for atmel-hlcdc DT bindings

On Tuesday 22 July 2014 06:41 PM, Boris BREZILLON wrote: > The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 > family or sama5d3 family) exposes 2 subdevices: > - a display controller (controlled by a DRM driver) > - a PWM chip > > This patch adds documentation for

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

This is a temporary solution and should be made by more generic way. To support LCD I80 interface, the DSI host should register TE interrupt handler from the TE GPIO of attached panel. So the panel generates a tearing effect synchronization signal then the DSI host calls the CRTC device manager

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

Hi Andrzej, On 07/22/2014 07:12 PM, Andrzej Hajda wrote: > On 07/22/2014 03:23 AM, Inki Dae wrote: >> On 2014? 07? 21? 23:01, Andrzej Hajda wrote: >>> On 07/17/2014 11:01 AM, YoungJun Cho wrote: To support LCD I80 interface, the DSI host should register TE interrupt handler from the TE

[PATCH v6 10/14] drm/panel: add S6E3FA0 driver

Hi Thierry, On 07/22/2014 04:49 PM, Thierry Reding wrote: > On Tue, Jul 22, 2014 at 12:41:21PM +0900, YoungJun Cho wrote: >> On 07/21/2014 08:18 PM, Andrzej Hajda wrote: >>> On 07/21/2014 11:19 AM, Thierry Reding wrote: On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote: > On

[PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

On 21/07/2014 17:16, Bjorn Helgaas wrote: > [+cc Jingoo] > > On Fri, Jul 18, 2014 at 12:50 PM, James Bottomley > > Anyway, it's PCI code ... let the PCI maintainer decide. However, if he > > does want this do it as one big bang patch via either the PCI or Trivial > > tree (latter because Ji??

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 6:39 PM, Christian K?nig wrote: >> Maybe I've mixed things up a bit in my description. There is >> fence_signal which the implementor/exporter of a fence must call when >> the fence is completed. If the exporter has an ->enable_signaling >> callback it can delay that call

[PATCH 1/4] drm/dsi: Make mipi_dsi_dcs_write() return ssize_t

Hi, On 07/22/2014 04:28 PM, Andrzej Hajda wrote: > Hi Thierry, > > Thanks for the patch. > > On 07/22/2014 09:12 AM, Thierry Reding wrote: >> From: Thierry Reding >> >> This function returns the value of the struct mipi_dsi_host_ops' >> .transfer() so make sure the return types are consistent.

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 6:21 PM, Daniel Vetter wrote: > But like I've said fence->signaled is optional so you don't need this > necessarily, as long as radeon eventually calls fence_signaled once > the fence has completed. Actually I've chatted a bit with Maarten about the different ways we

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #9 from Andrea Patern? --- That is.. well. I feel quite dumb, because it totally makes sense. It totally works when the card is powered up: both lspci and radeontop work like a charm! Now I only have to figure out what may cause the

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

> Maybe I've mixed things up a bit in my description. There is > fence_signal which the implementor/exporter of a fence must call when > the fence is completed. If the exporter has an ->enable_signaling > callback it can delay that call to fence_signal for as long as it > wishes as long as

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #8 from Alex Deucher --- (In reply to Andrea Patern? from comment #7) > Makes sense! Nonetheless, the "unknown header type 7f" problem remains, as > well as the unloading problem. I managed to capture the journal log of the > system

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 5:59 PM, Christian K?nig wrote: > Am 22.07.2014 17:42, schrieb Daniel Vetter: > >> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig >> wrote: >>> >>> Drivers exporting fences need to provide a fence->signaled and a >>> fence->wait >>> function, everything else like

[PATCH 4/4] drm/radeon: remove visible vram size limit on bo allocation (v3)

On 19.07.2014 00:09, Alex Deucher wrote: > Now that fallback to gtt is fixed for cpu access, we can > remove this limit. > > bug: > https://bugs.freedesktop.org/show_bug.cgi?id=78717 > > v2: use new gart_pin_size to accurately track available gtt. > v3: fix comment [...] > @@ -55,10 +55,14 @@

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #7 from Andrea Patern? --- Created attachment 143941 --> https://bugzilla.kernel.org/attachment.cgi?id=143941=edit System Journal log after module unloading Makes sense! Nonetheless, the "unknown header type 7f" problem remains, as

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 5:42 PM, Alex Deucher wrote: >> Fence-based syncing between userspace queues submitted stuff through >> doorbells and anything submitted by the general simply wont work. >> Which is why I think the doorbell is a stupid interface since I just >> don't see cameras and v4l

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig wrote: > Drivers exporting fences need to provide a fence->signaled and a fence->wait > function, everything else like fence->enable_signaling or calling > fence_signaled() from the driver is optional. > > Drivers wanting to use exported fences

[PATCH] drm/radeon: add trace_radeon_vm_flush

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_trace.h | 18 ++ drivers/gpu/drm/radeon/radeon_vm.c| 1 + 2 files changed, 19 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_trace.h

[PATCH] drm/radeon: fix R600_PTE_GART handling

From: Christian K?nig That didn't worked correctly any more and opened up a security problem. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik_sdma.c | 3 +-- drivers/gpu/drm/radeon/radeon.h | 6 +++--- drivers/gpu/drm/radeon/si_dma.c | 3 +-- 3

[PATCH] drm/crtc-helper: use drm_framebuffer flags

Adding LKML and David in diffusion list to get an opinion on this patch 2014-07-10 10:01 GMT+02:00 Fabien DESSENNE : > Hi, > Can anyone review this patch ? > Thanks for your time. > Fabien > >> -Original Message- >> From: Fabien DESSENNE [mailto:fabien.dessenne at st.com] >> Sent: mardi 1

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig > wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >>

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

On 07/22/2014 05:23 PM, YoungJun Cho wrote: > Hi Varka, > > On 07/22/2014 08:14 PM, Varka Bhadram wrote: >> On 07/22/2014 04:40 PM, YoungJun Cho wrote: >>> Hi Varka, >>> >>> This irq handler should be registered in attach() and unregistered in >>> detach(). >>> >>> The devm_* APIs are

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 4:39 PM, Christian K?nig wrote: > Am 22.07.2014 16:27, schrieb Maarten Lankhorst: > >> op 22-07-14 16:24, Christian K?nig schreef: No, you really shouldn't be doing much in the check anyway, it's meant to be a lightweight check. If you're not ready yet

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Hey, op 22-07-14 17:02, Christian K?nig schreef: > Am 22.07.2014 16:44, schrieb Maarten Lankhorst: >> op 22-07-14 15:45, Christian K?nig schreef: >>> Am 22.07.2014 15:26, schrieb Daniel Vetter: On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: > Am 22.07.2014 13:57,

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig wrote: >> Would that be something you can agree to? > > > No, the whole enable_signaling stuff should go away. No callback from the > driver into the fence code, only the other way around. > > fence->signaled as well as fence->wait should become

[PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 16:47, schrieb Maarten Lankhorst: > op 22-07-14 16:39, Christian K?nig schreef: >> Am 22.07.2014 16:27, schrieb Maarten Lankhorst: >>> op 22-07-14 16:24, Christian K?nig schreef: > No, you really shouldn't be doing much in the check anyway, it's meant to > be a lightweight

[Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)

2014-06-05 1:01 GMT-03:00 Dave Airlie : > From: Dave Airlie > > This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: [

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 16:44, schrieb Maarten Lankhorst: > op 22-07-14 15:45, Christian K?nig schreef: >> Am 22.07.2014 15:26, schrieb Daniel Vetter: >>> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: Am 22.07.2014 13:57, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at

[PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 16:39, Christian K?nig schreef: > Am 22.07.2014 16:27, schrieb Maarten Lankhorst: >> op 22-07-14 16:24, Christian K?nig schreef: No, you really shouldn't be doing much in the check anyway, it's meant to be a lightweight check. If you're not ready yet because of a lockup

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

On 07/22/2014 04:40 PM, YoungJun Cho wrote: > Hi Varka, > > This irq handler should be registered in attach() and unregistered in > detach(). > > The devm_* APIs are released(freed) in remove(), right? > > Logically the panel could be attached and detached several times after > dsi is probed and

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 15:45, Christian K?nig schreef: > Am 22.07.2014 15:26, schrieb Daniel Vetter: >> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: >>> Am 22.07.2014 13:57, schrieb Daniel Vetter: On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > On Tue, Jul 22,

[PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 16:27, schrieb Maarten Lankhorst: > op 22-07-14 16:24, Christian K?nig schreef: >>> No, you really shouldn't be doing much in the check anyway, it's meant to >>> be a lightweight check. If you're not ready yet because of a lockup simply >>> return not signaled yet. >> It's not only

Looking for a start point for fixing a bug

it now P.P.S. And thanks for your hard work! --- [1] https://bugs.freedesktop.org/show_bug.cgi?id=79806 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140

[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface

On 07/22/2014 04:19 PM, YoungJun Cho wrote: (...) > + ret = gpio_request_one(dsi->te_gpio, GPIOF_IN, "te_gpio"); devm_* APIs..? > + if (ret) { > + dev_err(dsi->dev, "gpio request failed with %d\n", ret); > + goto out; > + } > + > + /* > + * This TE

[PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 16:24, Christian K?nig schreef: >> No, you really shouldn't be doing much in the check anyway, it's meant to be >> a lightweight check. If you're not ready yet because of a lockup simply >> return not signaled yet. > It's not only the lockup case from radeon I have in mind here. For

[PATCH 09/17] drm/radeon: use common fence implementation for fences

> No, you really shouldn't be doing much in the check anyway, it's meant to be > a lightweight check. If you're not ready yet because of a lockup simply > return not signaled yet. It's not only the lockup case from radeon I have in mind here. For userspace queues it might be necessary to call

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #6 from Alex Deucher --- (In reply to Andrea Patern? from comment #4) > It does. > > gandalf at the_shire ~ ? LIBGL_DEBUG=1 DRI_PRIME=1 glxinfo | grep "renderer > string" > libGL: Can't open configuration file /home/gandalf/.drirc:

[PATCH 09/17] drm/radeon: use common fence implementation for fences

op 22-07-14 14:19, Christian K?nig schreef: > Am 22.07.2014 13:57, schrieb Daniel Vetter: >> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: >>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: Am 22.07.2014 06:05, schrieb Dave Airlie: > On 9 July 2014

[Bug 81644] Random crashes on RadeonSI with Chromium.

|high -- 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/20140722/5ba01c21/attachment.html>

[Bug 81644] New: Random crashes on RadeonSI with Chromium.

, but apparently a different bug. -- 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/20140722/0433eac4/attachment.html>

[Bug 77876] Performance degredation shown when running glmark2

|--- |FIXED -- 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/20140722/74ac72fe/attachment.html>

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 15:26, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: >> Am 22.07.2014 13:57, schrieb Daniel Vetter: >>> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: > Am 22.07.2014 13:57, schrieb Daniel Vetter: > >On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > >>On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > >>>Am 22.07.2014 06:05, schrieb Dave Airlie: >

[PATCH v4 11/11] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

Enable LCD related nodes. Signed-off-by: Boris BREZILLON --- arch/arm/boot/dts/sama5d31ek.dts | 20 arch/arm/boot/dts/sama5d33ek.dts | 20 arch/arm/boot/dts/sama5d34ek.dts | 20 arch/arm/boot/dts/sama5d36ek.dts | 20

[PATCH v4 10/11] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi

Add LCD panel related nodes (backlight, regulators and panel) to sama5d3 Display Module dtsi. Reference LCD pin muxing used by sama5d3xek boards. Signed-off-by: Boris BREZILLON --- arch/arm/boot/dts/sama5d3xdm.dtsi | 58 +++ 1 file changed, 58 insertions(+)

[PATCH v4 09/11] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs

Define the HLCDC (HLCD Controller) IP available on some sama5d3 SoCs (i.e. sama5d31, sama5d33, sama5d34 and sama5d36) in sama5d3 dtsi file. Signed-off-by: Boris BREZILLON --- arch/arm/boot/dts/sama5d3_lcd.dtsi | 28 1 file changed, 28 insertions(+) diff --git

[PATCH v4 08/11] ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins

Define alternative pin muxing for the LCDC pins. Signed-off-by: Boris BREZILLON --- arch/arm/boot/dts/sama5d3_lcd.dtsi | 50 ++ 1 file changed, 50 insertions(+) diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi b/arch/arm/boot/dts/sama5d3_lcd.dtsi index

[PATCH v4 07/11] ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

The HLCDC (HLCD Controller) IP supports 4 different output mode (RGB444, RGB565, RGB666 and RGB888) and the pin muxing will depend on the chosen RGB mode. Split pin definitions to be able to set pin config according to the selected mode. Signed-off-by: Boris BREZILLON ---

[PATCH v4 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. The HLCDC block provides a single RGB output port, and only supports LCD panels connection to LCD panels for now. The atmel,panel

[PATCH v4 05/11] drm: add Atmel HLCDC Display Controller support

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display controller device. This display controller supports at least one primary plane and might provide several overlays and an hardware cursor depending on the IP

[PATCH v4 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provide a PWM device. The DT bindings used for this PWM device is following the default 3 cells bindings described in Documentation/devicetree/bindings/pwm/pwm.txt. Signed-off-by: Boris

[PATCH v4 03/11] pwm: add support for atmel-hlcdc-pwm device

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) provide a PWM device. This driver add support for a PWM chip exposing a single PWM device (which will most likely be used to drive a backlight device). Signed-off-by: Boris BREZILLON ---

[PATCH v4 02/11] mfd: add documentation for atmel-hlcdc DT bindings

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) exposes 2 subdevices: - a display controller (controlled by a DRM driver) - a PWM chip This patch adds documentation for atmel-hlcdc DT bindings. Signed-off-by: Boris BREZILLON ---

[PATCH v4 01/11] mfd: add atmel-hlcdc driver

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family) exposes 2 subdevices: - a display controller (controlled by a DRM driver) - a PWM chip The MFD device provides a regmap and several clocks (those connected to this hardware block) to its subdevices.

[PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller

Hello, This patch series adds support for Atmel HLCDC (HLCD Controller) available on some Atmel SoCs (i.e. the sama5d3 family). The HLCDC actually provides a Display Controller and a PWM device, hence I decided to declare an MFD device exposing 2 subdevices: a display controller and a PWM chip.

[PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages

On 22 July 2014 14:21, Alexandre Courbot wrote: > DRM maintainers, could I have a comment about this patch? A bunch of > Nouveau changes depend on it. I'm not sure we really have anyone who is in a great position to comment, my major issue would be its allocate a large chunk of RAM that might

[PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages

On Tue, Jul 22, 2014 at 2:07 PM, Dave Airlie wrote: > On 22 July 2014 14:21, Alexandre Courbot wrote: >> DRM maintainers, could I have a comment about this patch? A bunch of >> Nouveau changes depend on it. > > I'm not sure we really have anyone who is in a great position to comment, > > my

[Bug 79980] Random radeonsi crashes

s 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/20140722/137c6c65/attachment.html>

[Bug 79980] Random radeonsi crashes

port? Would it be the Cinnamon back end, or glamour? -- 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/20140722/ecae35a4/attachment.html>

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #5 from Andrea Patern? --- Created attachment 143931 --> https://bugzilla.kernel.org/attachment.cgi?id=143931=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #4 from Andrea Patern? --- It does. gandalf at the_shire ~ ? LIBGL_DEBUG=1 DRI_PRIME=1 glxinfo | grep "renderer string" libGL: Can't open configuration file /home/gandalf/.drirc: No such file or directory. libGL: Can't open

No information on valleyview

After doing some research I didn't find any information on valley view. I am wondering valleyview_get_display_clock_speed what this should return as I can't find any information on it? Nick

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3

[PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel

Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris BREZILLON --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 42fd6d1..f1e49fd 100644 ---

[PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval

Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris BREZILLON --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info

Add bus_formats and nbus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw

[PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats

Add RGB444 format using a 12 bits bus and RGB565 using a 16 bits bus. These formats will later be used by atmel-hlcdc driver. Signed-off-by: Boris BREZILLON --- include/uapi/linux/v4l2-mediabus.h| 2 ++ include/uapi/linux/video-bus-format.h | 4 +++- 2 files changed, 5 insertions(+), 1

[PATCH 1/5] video: move mediabus format definition to a more standard place

Rename mediabus formats and move the enum into a separate header file so that it can be used by DRM/KMS subsystem without any reference to the V4L2 subsystem. Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_ definitions. Signed-off-by: Boris BREZILLON ---

[PATCH 0/5] video: describe data bus formats

Hello, This patch series is a proposal to describe the different data formats used by HW components to connect with each other. This is just a copy of the existing V4L2_MBUS_FMT defintions with a neutral name so that it can be used by V4L2 and DRM/KMS subsystem. This series also makes use of

[PATCH 09/17] drm/radeon: use common fence implementation for fences

Am 22.07.2014 13:57, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: >> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: >>> Am 22.07.2014 06:05, schrieb Dave Airlie: On 9 July 2014 22:29, Maarten Lankhorst >>> canonical.com> wrote:

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Andrea Patern? changed: What|Removed |Added Attachment #143921|application/octet-stream|text/plain mime type|

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On 9 July 2014 22:29, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/radeon/radeon.h| 15 +- > drivers/gpu/drm/radeon/radeon_device.c | 60 - > drivers/gpu/drm/radeon/radeon_fence.c | 223 > ++-- > 3 files

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Andrea Patern? changed: What|Removed |Added Attachment #143911|application/octet-stream|text/plain mime type|

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Andrea Patern? changed: What|Removed |Added Attachment #143901|application/octet-stream|text/plain mime type|

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #2 from Andrea Patern? --- Created attachment 143921 --> https://bugzilla.kernel.org/attachment.cgi?id=143921=edit Kernel config -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 80901] [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 --- Comment #1 from Andrea Patern? --- Created attachment 143911 --> https://bugzilla.kernel.org/attachment.cgi?id=143911=edit System Journal log System log on failure -- You are receiving this mail because: You are watching the assignee of

[Bug 80901] New: [radeon] loading corrupts lspci entry + unloading crashes kernel

https://bugzilla.kernel.org/show_bug.cgi?id=80901 Bug ID: 80901 Summary: [radeon] loading corrupts lspci entry + unloading crashes kernel Product: Drivers Version: 2.5 Kernel Version: 3.16.0 Hardware: IA-64

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > > Am 22.07.2014 06:05, schrieb Dave Airlie: > > >On 9 July 2014 22:29, Maarten Lankhorst > >canonical.com> wrote: > > >>Signed-off-by: Maarten Lankhorst > > >>--- >

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > > Am 22.07.2014 06:05, schrieb Dave Airlie: > > >On 9 July 2014 22:29, Maarten Lankhorst > >canonical.com> wrote: > > >>Signed-off-by: Maarten Lankhorst > > >>--- >

[PATCH 09/17] drm/radeon: use common fence implementation for fences

Hey, op 22-07-14 06:05, Dave Airlie schreef: > On 9 July 2014 22:29, Maarten Lankhorst > wrote: >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/radeon/radeon.h| 15 +- >> drivers/gpu/drm/radeon/radeon_device.c | 60 - >> drivers/gpu/drm/radeon/radeon_fence.c

[PATCH 09/17] drm/radeon: use common fence implementation for fences

On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > Am 22.07.2014 06:05, schrieb Dave Airlie: > >On 9 July 2014 22:29, Maarten Lankhorst > >wrote: > >>Signed-off-by: Maarten Lankhorst > >>--- > >> drivers/gpu/drm/radeon/radeon.h| 15 +- > >>

[PATCH 4/4] ARM: tegra: roth: add display DT node

On Tue, Jul 22, 2014 at 7:51 AM, Mark Brown wrote: > On Mon, Jul 21, 2014 at 11:16:32PM +0200, Thierry Reding wrote: >> On Mon, Jul 21, 2014 at 09:35:27AM -0600, Stephen Warren wrote: > >> > > vdd-2v8-display needs to remain always-on however. Here we may hit a >> > > limitation of the

[PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages

DRM maintainers, could I have a comment about this patch? A bunch of Nouveau changes depend on it. Thanks, Alex. On Tue, Jul 15, 2014 at 11:10 AM, Alexandre Courbot wrote: > Pages allocated using the DMA API have a coherent memory mapping. Make > this mapping visible to drivers so they can

[PATCH 3/4] drm/dsi: Make mipi_dsi_dcs_{read, write}() symmetrical

On Tue, Jul 22, 2014 at 09:12:20AM +0200, Thierry Reding wrote: > From: Thierry Reding > > Currently the mipi_dsi_dcs_write() function requires the DCS command > byte to be embedded within the write buffer whereas mipi_dsi_dcs_read() > has a separate parameter. Make them more symmetrical by

[PATCH v2 00/25] AMDKFD kernel driver

On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote: > On 22/07/14 12:21, Daniel Vetter wrote: > >On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay wrote: > >>>Exactly, just prevent userspace from submitting more. And if you have > >>>misbehaving userspace that submits too much, reset the gpu

[PATCH v6 10/14] drm/panel: add S6E3FA0 driver

Hi Thierry, Now I understand what you mean. I'll implement common DSI helper functions. Thank you. Best regards YJ On 07/21/2014 06:35 PM, Thierry Reding wrote: > On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote: >> Hi Thierry, >> >> Thank you a lot for kind comments. >> >> On

[PATCH v2 00/25] AMDKFD kernel driver

On 22/07/14 12:21, Daniel Vetter wrote: > On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay wrote: >>> Exactly, just prevent userspace from submitting more. And if you have >>> misbehaving userspace that submits too much, reset the gpu and tell it >>> that you're sorry but won't schedule any more

[PATCH v6 10/14] drm/panel: add S6E3FA0 driver

Hi, On 07/21/2014 08:18 PM, Andrzej Hajda wrote: > On 07/21/2014 11:19 AM, Thierry Reding wrote: >> On Mon, Jul 21, 2014 at 10:56:08AM +0200, Andrzej Hajda wrote: >>> On 07/18/2014 03:49 AM, YoungJun Cho wrote: Hi Thierry, Thank you a lot for kind comments. On 07/17/2014

[PATCH 4/4] drm/radeon: remove visible vram size limit on bo allocation (v3)

On Tue, Jul 22, 2014 at 5:14 AM, Michel D?nzer wrote: > On 19.07.2014 00:09, Alex Deucher wrote: >> Now that fallback to gtt is fixed for cpu access, we can >> remove this limit. >> >> bug: >> https://bugs.freedesktop.org/show_bug.cgi?id=78717 >> >> v2: use new gart_pin_size to accurately track

[PATCH] drm/radeon: fix R600_PTE_GART handling

On Tue, Jul 22, 2014 at 11:42 AM, Christian K?nig wrote: > From: Christian K?nig > > That didn't worked correctly any more and opened up a security problem. > > Signed-off-by: Christian K?nig Applied to my 3.17 tree. Alex > --- > drivers/gpu/drm/radeon/cik_sdma.c | 3 +-- >

[PATCH] drm/radeon: add trace_radeon_vm_flush

On Tue, Jul 22, 2014 at 11:42 AM, Christian K?nig wrote: > From: Christian K?nig > > Signed-off-by: Christian K?nig Applied to my 3.17 tree. Alex > --- > drivers/gpu/drm/radeon/radeon_trace.h | 18 ++ > drivers/gpu/drm/radeon/radeon_vm.c| 1 + > 2 files changed, 19

[PATCH 1/4] drm/dsi: Make mipi_dsi_dcs_write() return ssize_t

Hi Thierry, YoungJun's comment refreshed my memory about mipi_dsi_dcs_write return value. It should be rather int than ssize_t. Why? .transfer() returns the number of read bytes or error, but in case of dcs write no bytes are read, so it in fact returns error or 0. This is why return value was

  1   2   >