[PATCH v4 3/5] drm: add SimpleDRM driver

Den 23.08.2016 08:17, skrev Daniel Vetter: > On Mon, Aug 22, 2016 at 10:25:23PM +0200, Noralf Trønnes wrote: >> The SimpleDRM driver binds to simple-framebuffer devices and provides a >> DRM/KMS API. It provides only a single CRTC+encoder+connector combination >> plus one initial mode. >> >>

[PATCH] drm/nouveau/acpi: use DSM if bridge does not support D3cold

Even if PR3 support is available on the bridge, it will not be used if the PCI layer considers it unavailable (i.e. on all laptops from 2013 and 2014). Ensure that this condition is checked to allow a fallback to the Optimus DSM for device poweroff. Initially I wanted to call pci_d3cold_enable

[Bug 97477] i915g: gl_FragCoord is always (0.0, max_y)

https://bugs.freedesktop.org/show_bug.cgi?id=97477 --- Comment #1 from Nicholas Bishop --- Posted the patch to the mailing list with a somewhat clearer commit message: https://lists.freedesktop.org/archives/mesa-dev/2016-August/127065.html FWIW, the process of submitting a patch via the mailing

[RFC] drm: implement generic firmware eviction

Provide a generic DRM helper that evicts all conflicting firmware framebuffers, devices, and drivers. The new helper is called drm_evict_firmware(), and takes a flagset controlling which firmware to kick out. This is meant to be used by drivers in their ->probe() callbacks of their parent bus,

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

Hi David, > Lets move forward and hide the remaining DRI1 drivers behind a config > option, so we have a central place to disable them all. Furthermore, we > can provide a clear warning to anyone enabling them. > > Signed-off-by: David Herrmann > --- > drivers/gpu/drm/Kconfig | 135 >

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

Hi Kevin, On 26 August 2016 at 01:19, Kevin Brace wrote: > I do not want to be seen as stopping progress, but there are still people who > use less than current hardware (myself and countless others) or non Big 3 x86 > graphics (NVIDIA, AMD, and Intel) for things like thin clients. [snip] >

[PATCH 2/2] drm/hisilicon: Make it compile again

On 17 August 2016 at 19:11, Daniel Vetter wrote: > On Wed, Aug 17, 2016 at 07:02:01PM +0800, Xinliang Liu wrote: >> Hi, >> >> On 17 August 2016 at 18:17, Daniel Vetter wrote: >> > I just broke the build :( >> > >> > Note that the cleanup function is a bit confused: ade_data was never >> > set as

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

On 4 August 2016 at 18:06, David Herrmann wrote: > The legacy DRI1 drivers expose highly broken interfaces to user-space. No > modern system should enable them, or you will effectively allow user-space > to circumvent most of your kernel security measures. The DRI1 kernel APIs > are simply

[PATCH] drm/amdgpu: Add amdkfd softdep

On 26/08/16 02:10 AM, Michal Marek wrote: > amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that > userspace knows that amdgpu needs amdkfd in the initrd. > > Reported-and-tested-by: Martin Jambor > Signed-off-by: Michal Marek > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1

[PATCH 3/3] drm/rockchip: Reduce psr flush time to 100ms

Sean, On 08/19/2016 07:34 AM, Sean Paul wrote: > 3 seconds is a bit too conservative, drop this to 100ms for > better power savings. > > Signed-off-by: Sean Paul Reviewed-by: Yakir Yang > --- > drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1

[PATCH 2/3] drm/rockchip: Don't key off vblank for psr

Sean, Thanks for this good fix. On 08/19/2016 07:34 AM, Sean Paul wrote: > Instead of keying off vblank for psr, just flush every time > we get an atomic update. This ensures that cursor updates > will properly disable psr (without turning vblank on/off), > and unifies the paths between fb_dirty

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

Hi Emil, > Hi Kevin, > > On 26 August 2016 at 01:19, Kevin Brace wrote: > > > I do not want to be seen as stopping progress, but there are still people > > who use less than current hardware (myself and countless others) or non Big > > 3 x86 graphics (NVIDIA, AMD, and Intel) for things like

[PATCH 3/9] drm: Extract drm_mode_object.[hc]

On 08/26/2016 01:10 AM, Daniel Vetter wrote: > On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote: >> On 08/18/2016 02:26 AM, Daniel Vetter wrote: >>> +void drm_mode_object_unregister(struct drm_device *dev, >>> + struct drm_mode_object *object); >> >>

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

Hi Connor, > > r128 is 90% the same as early radeons so it would make sense to add > > support to radeon. > > > > Alex > > Ccing Kevin Brace. > > The drivers were removed from mesa and "you won't have to freeze your > kernel or anything" was one of the justifications given at the time for > why

[PATCH v2 22/25] dt-bindings: msm/dsi: Remove unused properties

Hi Rob, On 06/23/2016 07:43 PM, Archit Taneja wrote: > Remove the DSI index properties from the DSI host and PHY binding > documentation. The indices aren't a valid property and shouldn't > be a part of the DT binding. > Can I get an Ack on this? Thanks, Archit > Signed-off-by: Archit Taneja

[PATCH v2 23/25] dt-bindings: display/msm: Remove power domain property from encoder nodes

Hi Rob, On 06/23/2016 07:43 PM, Archit Taneja wrote: > Remove the power-domain property from the DSI, HDMI and eDP dt-binding > docs. The power domain only needs to be specified in the parent MDSS > device node (that too only for SoCs which contain MDSS). Can I get an Ack on this? Thanks,

[PATCH v2 24/25] arm64: dts: msm8916: Add display support

Hi Rob, On 06/23/2016 07:43 PM, Archit Taneja wrote: > The MSM8916 SoC contains a MDP5 based display block, and one DSI output. > Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children > sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's > input port. > >

[PATCH v2 25/25] arm64: dts: apq8016-sbc: Add HDMI display support

On 06/23/2016 07:43 PM, Archit Taneja wrote: > The APQ8016-sbc provides a HDMI output. The APQ8016 display block only > provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI > encoder chip that sits between the DSI PHY output and the HDMI > connector. > > Add the ADV7533 DT node

How to resume drm-openchrome development

Hi, I am sending this posting to dri-devel mailing list and Dave Airlie. This is sort of a summary of where OpenChrome and drm-openchrome is now. https://lists.freedesktop.org/archives/dri-devel/2016-August/116736.html I know that drm-openchrome is still not mainlined, and I am not the original

[RFC] drm: implement generic firmware eviction

On Fri, Aug 26, 2016 at 2:00 AM, David Herrmann wrote: > Provide a generic DRM helper that evicts all conflicting firmware > framebuffers, devices, and drivers. The new helper is called > drm_evict_firmware(), and takes a flagset controlling which firmware to > kick out. > > This is meant to be

drm/mediatek: fixed the calc method of data rate per lane

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this signal will cause h-time larger than normal and reduce FPS. Need to multiply a coefficient to offset the extra signal's effect. coefficient =

[PATCH v4 0/7] drm/imx: Add active plane reconfiguration support

This patch adds active plane reconfiguration support for imx-drm. This may fixes some mode setting failure issues which were introduced by imx-drm atomic conversion patch set. The main idea is to disable the plane in question in CRTC's atomic_disable operation and then the drm atomic core will

[PATCH v4 1/7] drm/atomic-helper: Add atomic_disable CRTC helper callback

Some display controllers need plane(s) to be disabled together with the relevant CRTC, e.g., the IPUv3 display controller for imx-drm. This patch adds atomic_disable CRTC helper callback so that old_crtc_state(as a parameter of the callback) could be used to get the active plane(s) of the old CRTC

[PATCH v4 5/7] drm/imx: ipuv3-crtc: Use the callback ->atomic_disable instead of ->disable

Now that the drm atomic core supports the callback ->atomic_disable, we may replace the legacy one ->disable with it. Cc: Philipp Zabel Cc: David Airlie Cc: Russell King Cc: Daniel Vetter Cc: Peter Senna Tschudin Cc: Lucas Stach Signed-off-by: Liu Ying --- v3->v4: * None. v3: * Newly

[PATCH v4 6/7] drm/imx: Use DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag

The IPUv3 display controller behind imx-drm needs all planes of a CRTC be disabled when the CRTC is disabled. The DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODESET flag reflects this hardware requirement. Let's use the flag for imx-drm. Suggested-by: Daniel Vetter Cc: Philipp Zabel Cc: David Airlie

[PATCH v4 3/7] drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter of the helper drm_atomic_helper_commit_planes() if the relevant display controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes when the CRTC is disabled. The helper would skip the ->atomic_disable call for

[PATCH v4 7/7] drm/imx: Add active plane reconfiguration support

We don't support configuring active plane on-the-fly for imx-drm. The relevant CRTC should be disabled before the plane configuration. Of course, the plane itself should be disabled as well. This patch adds active plane reconfiguration support by forcing CRTC mode change in plane's ->atomic_check

[RFC] drm: implement generic firmware eviction

Hi, On 26-08-16 02:00, David Herrmann wrote: > Provide a generic DRM helper that evicts all conflicting firmware > framebuffers, devices, and drivers. The new helper is called > drm_evict_firmware(), and takes a flagset controlling which firmware to > kick out. > > This is meant to be used by

[RFC] drm: implement generic firmware eviction

Hi On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede wrote: > Hi, > > On 26-08-16 02:00, David Herrmann wrote: >> >> Provide a generic DRM helper that evicts all conflicting firmware >> framebuffers, devices, and drivers. The new helper is called >> drm_evict_firmware(), and takes a flagset

[PATCH v4 2/7] drm/atomic-helper: Disable appropriate planes in disable_planes_on_crtc()

Currently, the helper drm_atomic_helper_disable_planes_on_crtc() calls ->atomic_disable for all planes _to be_ enabled on a particular CRTC. This is obviously wrong for those planes which are not scanning out frames when the helper is called. Instead, it's sane to disable active planes of

[PATCH v4 4/7] gpu: ipu-v3: Do not wait for DMFC FIFO to clear when disabling DMFC channel

According to basic tests, it looks there is no issue if we don't wait for DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that, either. This patch is needed to avoid the annoying warning caused by a timeout on waiting for the FIFO to clear after we add the new

[RFC] drm: implement generic firmware eviction

Hi, On 26-08-16 10:01, David Herrmann wrote: > Hi > > On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede wrote: >> Hi, >> >> On 26-08-16 02:00, David Herrmann wrote: >>> >>> Provide a generic DRM helper that evicts all conflicting firmware >>> framebuffers, devices, and drivers. The new helper is

[RFC] drm: implement generic firmware eviction

hat it can reclaim. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/050147aa/attachment.sig>

[RFC] drm: implement generic firmware eviction

Hi, On 26-08-16 10:58, Maxime Ripard wrote: > Hi, > > On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote: I'm not sure we would want to remove the device at all, we certainly should not be removing the dt_node from the devicetree IMHO. Having that around to see how the

[PATCH] drm/amdgpu: Add amdkfd softdep

On 2016-08-26 04:20, Michel Dänzer wrote: > On 26/08/16 02:10 AM, Michal Marek wrote: >> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that >> userspace knows that amdgpu needs amdkfd in the initrd. >> >> Reported-and-tested-by: Martin Jambor >> Signed-off-by: Michal Marek >>

Plan to support Rockchip VPU in DRM, is it a good idea

Hi Randi, On 08/26/2016 04:13 AM, Randy Li wrote: > Hello, >We always use some kind of hack work to make our Video Process > Unit(Multi-format Video Encoder/Decoder) work in kernel. From a > customize driver(vpu service) to the customize V4L2 driver. The V4L2 > subsystem is really not

[PATCH v2 25/25] arm64: dts: apq8016-sbc: Add HDMI display support

On Thu, Jun 23, 2016 at 07:43:30PM +0530, Archit Taneja wrote: > The APQ8016-sbc provides a HDMI output. The APQ8016 display block only > provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI > encoder chip that sits between the DSI PHY output and the HDMI > connector. > > Add the

RE: [PATCH v7 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

> base on dfi result, we do ddr frequency scaling, register > dmc driver to devfreq framework, and use simple-ondemand > policy. > > Signed-off-by: Lin Huang > Reviewed-by: Chanwoo Choi > --- Thanks. LGTM. Signed-off-by: MyungJoo Ham Cheers, MyungJoo.

RE: [PATCH v7 5/8] PM / devfreq: event: support rockchip dfi controller

> on rk3399 platform, there is dfi conroller can monitor > ddr load, base on this result, we can do ddr freqency > scaling. > > Signed-off-by: Lin Huang > Acked-by: Chanwoo Choi LGTM Signed-off-by: MyungJoo Ham

Plan to support Rockchip VPU in DRM, is it a good idea

Hello, We always use some kind of hack work to make our Video Process Unit(Multi-format Video Encoder/Decoder) work in kernel. From a customize driver(vpu service) to the customize V4L2 driver. The V4L2 subsystem is really not suitable for the stateless Video process or it could make driver

[PATCH v3 2/3] dt-bindings: Add jdi lt070me05000 panel bindings

Add documentation for lt070me05000 panel Cc: Archit Taneja Cc: John Stultz Cc: Thierry Reding Cc: Sumit Semwal Signed-off-by: Vinay Simha BN Acked-by: Rob Herring --- v2: * incorporated rob herring and thierry reviews gpio to gpios, gpio to regulator using fixed regulators and pwm

[PATCH v10 3/3] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

Add support for the JDI LT070ME05000 WUXGA DSI panel used in Nexus 7 2013 devices. Programming sequence for the panel is was originally found in the android-msm-flo-3.4-lollipop-release branch from: https://android.googlesource.com/kernel/msm.git And video mode setting is from

[PATCH v2 24/25] arm64: dts: msm8916: Add display support

On Thu, Jun 23, 2016 at 07:43:29PM +0530, Archit Taneja wrote: > The MSM8916 SoC contains a MDP5 based display block, and one DSI output. > Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children > sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's > input

[PATCH] drm/tegra: dc: Apply clipping to the overlay plane

Overlay plane should be clipped, otherwise overlay output gets distorted once plane crosses display boundary. As a "side effect" this patch also adds a sanity check for the primary plane, insuring that it covers whole display area. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/dc.c |

[PATCH v2] i2c: move locking operations to their own struct

This makes it trivial to constify them, so do that. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_dp_helper.c | 10 +++--- drivers/i2c/i2c-core.c | 13 - drivers/i2c/i2c-mux.c | 25 - include/linux/i2c.h | 25

[RFC] drm: implement generic firmware eviction

On Fri, 26 Aug 2016, David Herrmann wrote: > Provide a generic DRM helper that evicts all conflicting firmware > framebuffers, devices, and drivers. The new helper is called > drm_evict_firmware(), and takes a flagset controlling which firmware to > kick out. Reading the subject, I thought this

[PATCH v2] drm/fsl-dcu: Fix endian issue when using clk_register_divider

While clk_register_divider will write register as little endian, Modified the param "shift" from 0 to 24 since DCU is big endian. Or reg "DCU_DIV_RATIO" will be seted as a incorrect value which will cause vblank timing issue etc. Signed-off-by: Meng Yi --- Changes in V2: -check the soc name to

Plan to support Rockchip VPU in DRM, is it a good idea

On 08/26/2016 05:34 PM, Hans Verkuil wrote: > Hi Randi, > > On 08/26/2016 04:13 AM, Randy Li wrote: >> Hello, >>We always use some kind of hack work to make our Video Process >> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a >> customize driver(vpu service) to the customize

[PATCH] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Make sure the request PSR state could effect in analogix_dp_send_psr_spd() function, or printing the error Sink PSR state if we failed to effect the request PSR setting. Signed-off-by: Yakir Yang --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++---

[Bug 97492] Occasional harmless [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* ttm_eu_reserve_buffers failed.

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/70bed549/attachment-0001.html>

Plan to support Rockchip VPU in DRM, is it a good idea

On 08/26/2016 12:05 PM, Randy Li wrote: > > > On 08/26/2016 05:34 PM, Hans Verkuil wrote: >> Hi Randi, >> >> On 08/26/2016 04:13 AM, Randy Li wrote: >>> Hello, >>>We always use some kind of hack work to make our Video Process >>> Unit(Multi-format Video Encoder/Decoder) work in kernel. From

[Bug 97494] Tonga vce perf regression since drm/amdgpu: add vce bypass mode for tonga.

/to ram. omx 8 seconds -> 35 vaapi 12 seconds -> 51 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826

Plan to support Rockchip VPU in DRM, is it a good idea

On 08/26/2016 06:56 PM, Hans Verkuil wrote: > On 08/26/2016 12:05 PM, Randy Li wrote: >> >> On 08/26/2016 05:34 PM, Hans Verkuil wrote: >>> Hi Randi, >>> >>> On 08/26/2016 04:13 AM, Randy Li wrote: Hello, We always use some kind of hack work to make our Video Process

[PATCH v2 24/25] arm64: dts: msm8916: Add display support

On Thu, Aug 25, 2016 at 11:57 PM, Archit Taneja wrote: > Hi Rob, > > On 06/23/2016 07:43 PM, Archit Taneja wrote: >> >> The MSM8916 SoC contains a MDP5 based display block, and one DSI output. >> Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children >> sub-blocks. Establish the

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

On 26 August 2016 at 04:04, Kevin Brace wrote: > Hi Emil, > >> Hi Kevin, >> >> On 26 August 2016 at 01:19, Kevin Brace wrote: >> >> > I do not want to be seen as stopping progress, but there are still people >> > who use less than current hardware (myself and countless others) or non >> > Big

[RFC] drm: implement generic firmware eviction

On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann wrote: > Provide a generic DRM helper that evicts all conflicting firmware > framebuffers, devices, and drivers. The new helper is called > drm_evict_firmware(), and takes a flagset controlling which firmware to > kick out. > > This is meant to be

[PATCH v2 2/7] drm/tilcdc: Add blue-and-red-crossed devicetree property

On Thu, Aug 25, 2016 at 7:03 AM, Jyri Sarha wrote: > Add "blue-and-red-crossed"-device tree property and update devicetree > binding document. The red and blue components are reversed between 24 > and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the > red and blue wires has to be

[RFC] drm: implement generic firmware eviction

the > >kernel. That way, the kernel will know that it's actual ram that it > >can reclaim. > > So when would the kernel reclaim the RAM then? When we kickout the framebuffer driver? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/eb2e27e0/attachment.sig>

[RFC] drm: implement generic firmware eviction

Hi, On 26-08-16 14:52, Maxime Ripard wrote: > On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote: >> Hi, >> >> On 26-08-16 10:58, Maxime Ripard wrote: >>> Hi, >>> >>> On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote: >> I'm not sure we would want to remove the device

Skylake graphics regression: projector failure with 4.8-rc3

Security Summit. James -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log Type: text/x-log Size: 27983 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/0eaf894a/attachment-0001.bin> -

Skylake graphics regression: projector failure with 4.8-rc3

On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > We seem to have an xrandr regression with skylake now. What's > happening is that I can get output on to a projector, but the system > is losing video when I change the xrandr sessions (like going from a > --above b to a --same-as b).

[RFC] drm: implement generic firmware eviction

Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments

[RFC] drm: implement generic firmware eviction

ckout the framebuffer driver? > > Yes that is when we _want_ it to reclaim the RAM, my question was when > it will _actually_ happen ? I'm not familiar with the reserved-memory > implementation. Does your answer mean that some driver must make an > explicit call to get the memory reclaimed ? The reserved-memory implementation is relying on memblock. I don't think there is a function yet to remove a reserved memory region, but its implementation would use memblock_free I guess. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/dc244320/attachment.sig>

[PATCH] drm/etnaviv: Always init gpu->memory_base

Am Freitag, den 26.08.2016, 16:25 +0200 schrieb Marek Vasut: > The content of gpu->memory_base should point to start of RAM, not zero. > > Signed-off-by: Marek Vasut > Cc: Lucas Stach > Cc: Christian Gmeiner > Cc: Russell King NACK. This will cause memory

[PATCH v4 3/5] drm: add SimpleDRM driver

On Fri, Aug 26, 2016 at 12:11 AM, Noralf Trønnes wrote: > I'm really walking in the dark here. I have deleted drm_driver.gem_vm_ops > and used this function: > > int sdrm_drm_mmap(struct file *filp, struct vm_area_struct *vma) > { > struct drm_file *priv = filp->private_data; > struct

[PATCH] modetest: Adding amdgpu to module list

From: satsahu Signed-off-by: Alex Deucher --- tests/util/kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/util/kms.c b/tests/util/kms.c index 650b23b..c20134e 100644 --- a/tests/util/kms.c +++ b/tests/util/kms.c @@ -127,6 +127,7 @@ const char

[PATCH v8 00/18] Add support for FDMA DMA controller and slim core rproc found on STi chipsets

Hi Vinod, Bjorn, Patrice, This patchset adds support for the Flexible Direct Memory Access (FDMA) core found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU with a dedicated firmware. It is a general purpose DMA controller supporting 16 independent channels and data can be

[PATCH v8 13/18] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node

This patch adds the dt node for the internal audio codec IP. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-family.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi

[PATCH v8 14/18] ARM: STi: DT: STiH407: Add uniperif player dt nodes

This patch adds the DT nodes for the uniperif player IP blocks found on STiH407 family silicon. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-family.dtsi | 76 +++ 1 file changed, 76 insertions(+) diff --git

[PATCH v8 16/18] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card

This patch enables the uniperif players 2 & 3 for b2120 boards and also adds the "simple-audio-card" device node to interconnect the SoC sound device and the codec. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stihxxx-b2120.dtsi | 45

[RFC][PATCH 2/4] drm/bridge: adv7511: Add Audio support.

Few Minor comments below.. On 23/08/16 06:50, John Stultz wrote: > This patch adds support to Audio for both adv7511 and adv7533 > bridge chips. > > This patch was originally from [1] by Lars-Peter Clausen > and was adapted by Archit Taneja and > Srinivas Kandagatla . > > Then I heavily

[PATCH] drm/doc: Document uapi requirements in DRM

Reviewed-by: Sinclair Yeh On Fri, Aug 19, 2016 at 10:50:38PM +0200, Daniel Vetter wrote: > Everyone knows them, except all the new folks joining from the ARM > side haven't lived through all the pain of the past years and are > entirely surprised when I raise this. Definitely time to document >

[PATCH] drm/etnaviv: Always init gpu->memory_base

The content of gpu->memory_base should point to start of RAM, not zero. Signed-off-by: Marek Vasut Cc: Lucas Stach Cc: Christian Gmeiner Cc: Russell King --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] drm/panel: simple: Fix bus flags for ortustech com43h4m85ulc

This display expects DE pin to be active high, add the necessary flag. Signed-off-by: Marek Vasut Cc: Philipp Zabel Cc: Thierry Reding --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c

[PATCH 2/2] drm: Add new driver for MXSFB controller

Add new driver for the MXSFB controller found in i.MX23/28/6SX . The MXSFB controller is a simple framebuffer controller with one parallel LCD output. Unlike the MXSFB fbdev driver that is used on these systems now, this driver uses the DRM/KMS framework. Signed-off-by: Marek Vasut Cc: Lucas

[PATCH 1/2] dt-bindings: mxsfb: Add bindings for the MXSFB KMS/DRM driver

Add DT bindings for new MXSFB driver using the DRM framework. The old MXSFB fbdev driver bindings are preserved in mxsfb.txt . Signed-off-by: Marek Vasut Cc: devicetree at vger.kernel.org Cc: Rob Herring Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo ---

[PATCH] drm/etnaviv: Always init gpu->memory_base

On 08/26/2016 04:35 PM, Lucas Stach wrote: > Am Freitag, den 26.08.2016, 16:25 +0200 schrieb Marek Vasut: >> The content of gpu->memory_base should point to start of RAM, not zero. >> >> Signed-off-by: Marek Vasut >> Cc: Lucas Stach >> Cc: Christian Gmeiner >> Cc: Russell King

[PATCH v8 02/18] MAINTAINERS: Add st slim core rproc driver to STi section.

This patch adds the slim core rproc driver to the STi section of the MAINTAINERS file. Signed-off-by: Peter Griffin --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0bbe4b1..5dd3b24 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1749,6

[PATCH v8 03/18] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

This patch adds the DT binding documentation for the FDMA constroller found on STi based chipsets from STMicroelectronics. Signed-off-by: Ludovic Barre Signed-off-by: Peter Griffin Acked-by: Rob Herring --- Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++ 1 file

[PATCH v8 05/18] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

This patch adds support for the Flexible Direct Memory Access (FDMA) core driver. The FDMA is a slim core CPU with a dedicated firmware. It is a general purpose DMA controller capable of supporting 16 independent DMA channels. Data moves maybe from memory to memory or between memory and paced

[PATCH v8 07/18] MAINTAINERS: Add FDMA driver files to STi section.

This patch adds the FDMA driver files to the STi section of the maintainers file. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5dd3b24..d21a7b5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@

[PATCH v8 11/18] ARM: DT: STiH407: Add i2s_in pinctrl configuration

This patch adds the pinctrl config for the i2s_in pins used by the uniperif reader IP. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 1 file changed, 24 insertions(+) diff --git

[PATCH v8 12/18] ARM: DT: STiH407: Add spdif_out pinctrl config

This patch adds the pinctrl config for the spidf out pins used by the sasg codec IP. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi

[PATCH v8 17/18] drm/virtio: kconfig: Fix recursive dependency.

[..] drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to

[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

Fixes runtime error: [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port at 1/endpoint [8.842812] CPU: 1 PID: 1494 Comm: systemd-udevd Not tainted 4.8.0-rc1-letux-custom #17 [8.842815] Hardware name: Generic OMAP5 (Flattened Device Tree) [8.842831] []

[PATCH -next] drm/sun4i: Remove redundant dev_err call in sun4i_tcon_init_regmap()

From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

[PATCH v8 01/18] remoteproc: st_slim_rproc: add a slimcore rproc driver

slim core is used as a basis for many IPs in the STi chipsets such as fdma and demux. To avoid duplicating the elf loading code in each device driver a slim rproc driver has been created. This driver is designed to be used by other device drivers such as fdma, or demux whose IP is based around a

[PATCH v8 06/18] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

These nodes are required to get the fdma driver working on STiH407 based silicon. Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-family.dtsi | 52 +++ 1 file changed, 52 insertions(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi

[PATCH v8 10/18] ARM: DT: STiH407: Add i2s_out pinctrl configuration

This patch adds the pinctrl config for the i2s_out pins used by the uniperif player IP. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++ 1 file changed, 23 insertions(+) diff --git

[RFC][PATCH 0/4] Audio support for adv7511 hdmi bridge

Hi John, On 23/08/16 06:50, John Stultz wrote: > This is an initial swing at getting the adv7511 hdmi bridge > audio support reviewed. > > I've taken the core audio work done by Lars-Peter Clausen, and > adapted by Srinivas Kandagatla and Archit Taneja, and tried to > rework it to use the

[PATCH v8 04/18] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

This header file will also be used by the dma xbar driver in the future. Signed-off-by: Ludovic Barre Signed-off-by: Peter Griffin --- drivers/dma/st_fdma.h | 244 ++ 1 file changed, 244 insertions(+) create mode 100644 drivers/dma/st_fdma.h

[PATCH v8 08/18] ARM: multi_v7_defconfig: Enable STi FDMA driver

This DMA controller is found on all STi chipsets. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index ea23250..998578a

[PATCH v8 09/18] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.

This patch enables the STi ALSA drivers found on STi platforms as well as the simple-card driver which is a dependency to have working sound. Signed-off-by: Peter Griffin Cc: arnaud.pouliquen at st.com Cc: broonie at kernel.org --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3

[PATCH v8 15/18] ARM: STi: DT: STiH407: Add uniperif reader dt nodes

This patch adds the DT node for the uniperif reader IP block found on STiH407 family silicon. Signed-off-by: Arnaud Pouliquen Signed-off-by: Peter Griffin --- arch/arm/boot/dts/stih407-family.dtsi | 26 ++ 1 file changed, 26 insertions(+) diff --git

[PATCH v8 18/18] drm/virtio: kconfig: Fixup white space.

Use tabs instead of spaces. Signed-off-by: Peter Griffin --- drivers/gpu/drm/virtio/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index 90357d9..2d83932 100644 ---

[Bug 97500] Cannot unbind GPU from AMDGPU

r the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160826/e096949b/attachment.html>

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

The devicetree documentation states that those are required properties, so the driver should refuse to probe if those are absent to be consistent. This will also allow to drop some error checking from the clock enable/disable paths. Signed-off-by: Lucas Stach ---

[PATCH 1/2] net: fec: don't ack masked interrupt events

The FEC doesn't have a real interrupt status register, that takes into account the mask status of the IRQ. The driver reads the raw interrupt event register, which also reports events for masked IRQs. The driver needs to apply the current mask itself, to avoid acking IRQs that are currently

[PATCH 2/2] net: fec: optimize IRQ handler

fep->work_rx and fep->work_tx are both non-zero, as long as the NAPI softirq hasn't finished its work. So if the current IRQ does not signal any RX or TX completion, but some unrelated event, the path to schedule the NAPI context is still entered. The handler works correctly as in this case

[PATCH 1/2] net: fec: don't ack masked interrupt events

Sorry, please ignore the FEC patches. Those are test patches still residing in my to-send folder. Sorry for the noise. Am Freitag, den 26.08.2016, 17:49 +0200 schrieb Lucas Stach: > The FEC doesn't have a real interrupt status register, that takes > into account the mask status of the IRQ. The

  1   2   >