Hi Chris,
Thank you for the patch.
On Thursday 08 Dec 2016 08:18:40 Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> mo
Hi Daniel,
On Tuesday 13 Dec 2016 22:48:50 Daniel Vetter wrote:
> On Tue, Dec 13, 2016 at 11:41:09PM +0200, Laurent Pinchart wrote:
> > On Tuesday 13 Dec 2016 22:21:10 Daniel Vetter wrote:
> >> On Tue, Dec 13, 2016 at 05:21:43PM +0200, Laurent Pinchart wrote:
> >>> +
> >>> + /* Allocate and initia
Hi all,
I finally clued up about connector_list locking and here is a fix for that
little issue that's not totally horribly nightmare fuel. As usual I ended up
reading too much other code, so there's a few random bits in here too. Some of
the earlier randomness I submitted already and it's in drm-
This is not driver interface stuff.
Fixes: 6559c901cb48 ("drm/atomic: add debugfs file to dump out atomic state")
Cc: Rob Clark
Cc: Sean Paul
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 6 ++
drivers/gpu/drm/drm_debugfs.c
Only static connectors should be left at this point, and we should be
able to clean them out by simply dropping that last reference still
around from drm_connector_init.
If that leaves anything behind then we have a driver bug.
Doing the final cleanup this way also allows us to use
drm_connector_
- Modeset state needs mode_config->connection mutex, that covers
figuring out the encoder, and reading properties (since in the
atomic case those need to look at connector->state).
- Don't hold any locks for stuff that's invariant (i.e. possible
connectors).
- Same for connector lookup and
While at it also try to reduce the locking a bit to what's really just
needed instead of everything that we could possibly lock.
Added a new for_each_intel_connector_iter which includes the cast to
intel_connector.
Otherwise just plain transformation with nothing special going on.
Signed-off-by:
The list walk will shortcircuit anyway.
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 6 ++
drivers/gpu/drm/radeon/radeon_irq_kms.c | 12
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
Nothing special, just rote conversion.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hotplug.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 3d546
Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.
I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Signed-off-by: Daniel Vetter
---
drive
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.
v2: Also update the kerneldoc for @registered!
Cc: Chris Wilson
Reported-by: Chris Wilson
S
This is single-threaded setup code, no need for locks. And anyway,
all properties need to be set up before the driver is registered
anyway, they can't be hot-added.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing
The requirements for connector_list locking are a bit tricky:
- We need to be able to jump over zombie conectors (i.e. with refcount
== 0, but not yet removed from the list). If instead we require that
there's no zombies on the list then the final kref_put must happen
under the list protectio
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Signed-o
One case where I nuked a now unecessary locking, otherwise all just
boring stuff.
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/
Hello,
The omapdss/omapdrm initialization code is quite a mess. The physical devices
are instantiated from DT, but two virtual devices named omapdrm and omapdss
are instanciated from platform code to pass various pieces of platform data to
the drivers.
The omapdrm and omapdss platform devices sho
The revision is passed from platform code to the omapdrm driver through
the omapdrm platform device's platform data. This is the last reason to
create a virtual omapdrm platform device that we have otherwise no need
for. By passing the revision through the omapdss platform data we will
be able to r
The omapdrm platform device is a virtual device created for the sole
purpose of handling the omapdss/omapdrm driver split. It should
eventually be removed. As a first step to ease refactoring move its
registration from platform code to driver code.
The omapdrm driver name must be changed internall
The omapdrm platform data are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
---
include/linux/platform_data/omap_drm.h | 53 --
1 file changed, 53 deletions(-)
delete mode 100644 include/linux/platform_data/omap_drm.h
diff --git a/include/linux/
The omapdrm platform data isn't used anymore, remove it.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/drm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 44fef961bb70..06fd40c92b96 100644
--- a/arch/arm/mach-omap2
The OMAP revision is currently passed through omapdrm platform data. To
prepare for removal of omapdrm platform data, get it from the omapdss.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c| 8
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 +
drivers/gpu/drm/omap
The omapdss platform data OMAP revision field will be used by the
omapdss driver, populate it.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8fa01c0ecdb2..6
The omapdrm platform device is unused, as a replacement is now
registered in the omapdss driver. Remove it.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/display.c | 7 ---
arch/arm/mach-omap2/display.h | 1 -
arch/arm/mach-omap2/drm.c |
Hi Tomi,
On Tuesday 13 Dec 2016 10:15:35 Tomi Valkeinen wrote:
> On 13/12/16 01:07, Laurent Pinchart wrote:
> > On Tuesday 20 Sep 2016 16:57:59 Tomi Valkeinen wrote:
> >> On 19/09/16 15:27, Laurent Pinchart wrote:
> >>> The omapdrm DSS manager enable/disable operations check the DSS manager
> >>>
Hi Maarten,
On Tuesday 13 Dec 2016 15:13:54 Maarten Lankhorst wrote:
> Op 09-12-16 om 09:25 schreef Daniel Vetter:
> > On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
> >> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> >>> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarte
Hello,
Here's the fourth version of my current stack of pending patches for the
omapdrm driver.
All comments received for v3 have been considered and patches updated where
applicable. Patches 21/22 and 22/22 have been added, individual changelogs are
available in all the patches when they have be
Instead of going through a complicated registration mechanism, just
call the OCP error IRQ handler directly from the main IRQ handler.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Rename IRQ handler to omap_irq_ocp_error_handler()
- Replace hex error value with "OCP error" message
---
Don't print userspace parameters validation failures as error messages
to avoid giving userspace the ability to flood the kernel log.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-
The only multi-planar format supported by the driver is NV12, there will
thus never be more than two planes per framebuffer.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
Merge the single-user objects_lookup inline function into its caller,
allowing reuse of the error code path.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.h | 25 -
drivers/gpu/drm/omapdrm/omap_fb.c | 29 +++
Instead of conditioning planes update based on the DSS manager hardware
state, use the enabled field newly added to the omap_crtc structure.
This reduces the dependency from the DRM layer to the DSS layer.
The enabled field is a transitory measure, the implementation should use
the CRTC atomic sta
Instead of going through a complicated registration mechanism, just
expose the CRTC error IRQ function and call it directly from the main
IRQ handler.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 12 ++--
drivers/gpu/drm/omapdrm/o
The CRTC pending flag will need to be accessed atomically in the vblank
interrupt handler, memory barriers won't be enough to protect it. Use a
spinlock instead.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v3:
- Reworded commit message
---
drivers/gpu/drm/oma
The IRQ registration functions are not used outside of their compilation
unit, make them static. As the __omap_irq_(un)register() functions are
only called by their omap_irq_(un)register() counterparts, merge them
together.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Split the omap_d
Instead of going through a complicated private IRQ registration
mechanism, handle the vblank interrupt activation with the standard
drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let
the DRM core keep the vblank interrupt enabled as long as needed to
update the frame counter.
The only omap_drm_irq handler doesn't use the irqstatus parameter passed
to the function. Remove it.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- New patch
---
drivers/gpu/drm/omapdrm/omap_drv.h | 2 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 4 ++--
2 files changed, 3 insertions(+), 3
The IRQ wait functions are called from the DSS enable and disable
operations only, where the DISPC is guaranteed to be enabled. There's no
need for manual DISPC power management there.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_irq.c | 4
1 file changed, 4 deletions(-)
The vblank interrupt is disabled after one occurrence, preventing the
atomic update event from being processed twice. However, this also
prevents the software frame counter from being updated correctly that
would require vblank interrupts to be kept enabled while the CRTC is
active.
In preparation
The function is only used in omap_irq.c and is just a wrapper around
dispc_mgr_get_vsync_irq(). Remove it and call the dispc function
directly.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Removed the pipe2vbl function completely
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ---
d
The driver stores in a custom structure named format several pieces of
information about the format that are available in the DRM core. Remove
them and get the information from the DRM core instead.
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Fix subsampling computation by checking t
By linking the sizeof to a variable type the code will be less prone to
bugs due to future type changes of variables.
Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 2 +-
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 3 +--
d
Now that the IRQ list is used for IRQ wait only we can merge
omap_drm_irq and omap_irq_wait and simplify the implementation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 17 +--
drivers/gpu/drm/omapdrm/omap_irq.c | 94 ++
2 file
Move the list of pending IRQ wait instances to the omap_drm_private
structure and the wait queue head to the IRQ wait structure.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++-
drivers/gpu/drm/omapdrm/omap_irq.c | 42 --
2 file
The omapdrm DSS manager enable/disable operations check the DSS manager
state to avoid double enabling/disabling. Check the CRTC software state
instead to decrease the dependency of the DRM layer to the DSS layer.
The dispc_mgr_is_enabled() function then be turned into a static
function, but needs
The DRM core supports skipping plane update for inactive CRTCs for
hardware that don't need it or can't cope with it. That's our case, and
the driver already skips flushing planes on inactice CRTCs.
We can't remove the check from the driver, as active CRTCs are disabled
at the hardware level when
As the FIFO underflow IRQ handler just prints an error message to the
kernel log, simplify the code by not registering one IRQ handler per
plane but print the messages directly from the main IRQ handler.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v3:
- Renamed
The hardware requires all planes to have an identical pitch in number of
pixels. Given that all supported formats use the same number of bytes
per pixel in all planes, framebuffer creation checks can be simplified.
The implementations assumes that no format use more than two planes
which is true wi
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the rem
On 13/12/16 09:59 PM, Daniel Vetter wrote:
> On Tue, Dec 13, 2016 at 12:22:59PM +, Daniel Stone wrote:
>> Hi Harry,
>> I've been loathe to jump in here, not least because both cop roles
>> seem to be taken, but ...
>>
>> On 13 December 2016 at 01:49, Harry Wentland
>> wrote:
>>> On 2016-12-11
The OMAP implementation of the set_min_bus_tput() API is a no-op.
There's no point in forwarding the driver calls to the platform code.
Remove the use of the related platform data callback, but keep the
internal function as a reminder that the feature will need to be
implemented when the OMAP platf
The DSI pin muxing platform callbacks are unused, remove them.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/display.c | 60 ---
1 file changed, 60 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index b81
The omapdss set_min_bus_tput platform data callback is unused. Remove
it.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-omap2/display.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5bb5f848a2
The omapdss platform data callbacks and the default display name fields
are unused. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c| 2 --
include/linux/platform_data/omapdss.h | 4
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm
Don't rely on callback functions provided by the platform, but access
the syscon internally to mux the DSI pins.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/core.c | 20 --
drivers/gpu/drm/omapdrm/dss/dsi.c | 82 --
drivers/gpu/drm
å¨ 2016å¹´12æ13æ¥ 04:22, Stéphane Marchesin åé:
> On Wed, Dec 7, 2016 at 11:26 PM, Caesar Wang wrote:
>> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
>> TFT's as an active switching devices. It can be supported by the
>> simple-panel driver.
>>
>> Read the pane
On 12/13/2016 07:22 PM, Maarten Lankhorst wrote:
> Op 13-12-16 om 14:01 schreef Archit Taneja:
>> Hi,
>>
>> On 12/12/2016 4:04 PM, Maarten Lankhorst wrote:
>>> Do something similar to vc4, only allow updating the cursor state
>>> in-place through a fastpath when the watermarks are unaffected. Thi
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
Signed-off-by: Caesar Wang
---
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++
1 file changed, 7 insertions(+)
create mode 100644
Documentation/devicetree/binding
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Read the panel default edid information:
EDID MODE DETAILS
name =
pixel_clock = 71900
lvd
Hi Taro Yamada,
On 13 December 2016 at 11:18, wrote:
> From: Taro Yamada
>
> The string written to the buffer by read() is not null-terminated,
> but currently drmParsePciBusInfo() places null character only at the end of
> the buffer, not at the end of the
> string.
> As a result, the string
Hi,
On 12/12/2016 08:28 PM, Sean Paul wrote:
> On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote:
>> Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host
>> device, that will cause the panel hang on the startup display.
>> The root cause we use the fast link mode during enter
Hi,
On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC. Add DT bindings for this chip.
Queued to drm-misc-next
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Laurent Pinchart
> Acked-by: Rob Herring
> ---
> .../bindings/display/bridge/ti,ths8135.tx
On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC, but no configuration is actually
> necessary to make it work.
>
> For now use the dumb-vga-dac driver to support it.
Queued to drm-misc-next
Archit
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: L
MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Hoegeun Kwon (1):
drm/panel: Add support for S6E3HA2 panel driver on TM2 boa
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e3ha2.txt |
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 +++
On 13/12/16 10:09 PM, Emil Velikov wrote:
> Just set the rules automatically rather than asking each contributor to
> update thing locally.
>
> Signed-off-by: Emil Velikov
> ---
> autogen.sh | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/autogen.sh b/autogen.sh
> index c896097..
On 12/14/2016 12:23 PM, Emil Velikov wrote:
> Did you see this causing issues in practise ?
>
> We use a combination of strstr to strip any unwanted starting data,
> and sscanf which [should] trim any trailing garbage.
> That aside, your patch provides an extra bit of robustness which is
> always n
nts/20161214/577e5de5/attachment.html>
This patch fixes memory leak in error path of exynos_bo_create().
Signed-off-by: Seung-Woo Kim
---
libkms/exynos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libkms/exynos.c b/libkms/exynos.c
index 5de2e5a..0e97fb5 100644
--- a/libkms/exynos.c
+++ b/libkms/exynos.
goto err_reg;
> }
>
> +#if IS_ENABLED(CONFIG_DRM_OMAP)
> + r = platform_device_register(&omap_drm_device);
> + if (r)
> + goto err_reg;
> +#endif
Where is the unregister?
Tomi
-- next part --
A non-text attachm
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
kerneldoc speaks of forward-order, so better update that.
> after drm_mm_scan_add_block() we can further simplify the list
> manipulations when generating the temporary sc
On Wed, Dec 14, 2016 at 12:08:06AM +0100, Daniel Vetter wrote:
> The requirements for connector_list locking are a bit tricky:
> - We need to be able to jump over zombie conectors (i.e. with refcount
> == 0, but not yet removed from the list). If instead we require that
> there's no zombies on
Set up the PULSE_EATER register (0x0010C) in etnaviv_gpu_hw_init. This
ports three mostly undocumented model/revision-specific register
overrides from the Vivante kernel driver.
This is relevant as at least the "disable internal DFS" for revisions >
0x5420 has shown to have a huge impact on shader
ute_fifo_thresholds() does that tuning if
"manual_update" parameter is set on OMAP3.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.f
819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/794f0591/attachment-0001.sig>
- Add PS.INST_ADDR and VS.INST_ADDR: GC3000 loads shader code from these
addresses if ICACHE
is enabled.
- Add new NFE vertex stream addresses.
---
drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
b/
Hi Tomi,
On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote:
> On 13/12/16 19:35, Laurent Pinchart wrote:
> > On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote:
> >> This is a workaround for a hardware bug occuring
> >> on OMAP3 with manually updated panels.
> >
> > Could you please exp
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that if we request bottom-up allocation from drm_mm_insert_node()
> we receive the next available hole from the bottom.
>
> Signed-off-by: Chris Wilson
> @@ -1304,6 +1304,95 @@ static int igt_topdown(void *ignored)
> > Â return re
art of that series.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/28163ca5/attachment.sig>
On 13 December 2016 at 23:08, Daniel Vetter wrote:
> This is single-threaded setup code, no need for locks. And anyway,
> all properties need to be set up before the driver is registered
> anyway, they can't be hot-added.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
cation/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/d7838da1/attachment.sig>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Exercise drm_mm_reserve_node(), check that we can't reserve an already
> occupied range and that the lists are correct after reserving/removing.
>
> Signed-off-by: Chris Wilson
> @@ -105,6 +108,135 @@ static int igt_debug(void *ignored)
quot;;
> reg = <0x213000 0x1000>;
> interrupts = <52>;
>
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/c170611c/attachment-0001.sig>
On Tue, 13 Dec 2016, "Cheng, Tony" wrote:
> I am struggling with that these comminty contributions to DC would be.
>
> Us AMD developer has access to HW docs and designer and we are still
> spending 50% of our time figuring out why our HW doesn't work right. I
> can't image community doing much
Hello,
This patch series is a respin of the DRM bridge attach/detach cleanup patches
that were previously part of "[PATCH v3 00/13] R-Car DU: Use drm bridge API".
As patches 1/5 and 3/5 touch a large number of drivers and are thus painful to
rebase, I'd like to get them merged soon without waiting
Instead of detaching only the bridge directly connected to the encoder,
detach all bridges in the chain.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_encoder.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu
Most drivers that use bridges forgot to detach them at cleanup time.
Instead of fixing them one by one, detach the bridge in the core
drm_encoder_cleanup() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_bridge.c| 13 ++---
drivers/gpu/drm/drm_crtc_internal.
The drm_crtc_mask() function used in is a static
inline defined in . If the first header is included in a
compilation unit without the second one, the following compilation
warning will be issued.
In file included from /drivers/gpu/drm/drm_bridge.c:29:0:
/include/drm/drm_encoder.h:192:95: warning
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the cal
used to define most of the in-kernel KMS API. It has
now been split into separate files for each object type, but still
includes most other KMS headers to avoid breaking driver compilation.
As a step towards fixing that problem, remove the inclusion of
from and include it instead where
appropri
On Wed, Dec 14, 2016 at 12:03 AM, Archit Taneja
wrote:
> Hi,
>
> On 12/12/2016 08:28 PM, Sean Paul wrote:
>>
>> On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote:
>>>
>>> Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host
>>> device, that will cause the panel hang on the st
einen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/7345c99f/attachment-0001.sig>
Hi,
> So I would be interested to know whether anyone else has thought about
> this problem, and possibly even about an interface to let the compositor
> pass the information. If not, would people be open to the idea? I
> would much rather have something generally agreed on than hack someth
On Wed, Dec 14, 2016 at 11:59:09AM +0200, Laurent Pinchart wrote:
> Most drivers that use bridges forgot to detach them at cleanup time.
> Instead of fixing them one by one, detach the bridge in the core
> drm_encoder_cleanup() function.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Ve
On Wed, Dec 14, 2016 at 11:59:10AM +0200, Laurent Pinchart wrote:
> Instead of detaching only the bridge directly connected to the encoder,
> detach all bridges in the chain.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_encoder.c | 12 ++--
> 1 file changed, 10 inserti
e initial setup, and
then there's no need for locking.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/bcdf4738/attachment.sig>
error_handler->irqmask = DISPC_IRQ_OCP_ERR;
> -
> - /* for now ignore DISPC_IRQ_SYNC_LOST_DIGIT.. really I think
> - * we just need to ignore it while enabling tv-out
> - */
> - error_handler->irqmask &= ~DISPC_IRQ_SYNC_LOST_DIGIT;
> -
> - oma
rg/archives/dri-devel/attachments/20161214/435e9cb3/attachment.sig>
1 - 100 of 237 matches
Mail list logo
