tps://lists.freedesktop.org/archives/dri-devel/attachments/20161129/608d0f89/attachment.html>
Hi Mike,
On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote:
> On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote:
> > On Friday 25 Nov 2016 10:56:53 Andy Yan wrote:
> >> On 2016å¹´11æ25æ¥ 07:26, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote:
> >
The patch below added regulator supplies to the ADV533 HDMI bridge
on the DB410c, but the corresponding DT binding doc wasn't updated
to list them:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2
The first patch adds the regulato
Maintain a table of regulator names expect by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Signed-off-by: Archit Taneja
---
v3:
- Drop the additional 1.8V supply names
Add the regulator supply properties needed by ADV7511 and ADV7533.
The regulators are specified as optional properties since there can
be boards which have a fixed supply directly routed to the pins, and
these may not be modelled as regulator supplies.
Cc: devicetree at vger.kernel.org
Acked-by:
Hi Archit,
Thank you for the patch.
On Tuesday 29 Nov 2016 11:37:42 Archit Taneja wrote:
> Maintain a table of regulator names expect by ADV7511 and ADV7533.
> Use regulator_bulk_* api to configure these.
>
> Initialize and enable the regulators during probe itself. Controlling
> these dynamical
Hi Archit,
Thank you for the patch.
On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
> Add the regulator supply properties needed by ADV7511 and ADV7533.
>
> The regulators are specified as optional properties since there can
> be boards which have a fixed supply directly routed to the pins,
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:40 John Stultz wrote:
> I was recently seeing issues with EDID probing, where
> the logic to wait for the EDID read bit to be set by the
> IRQ wasn't happening and the code would time out and fail.
>
> Digging deeper, I found this was
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:41 John Stultz wrote:
> In chasing down a previous issue with EDID probing from calling
> drm_helper_hpd_irq_event() from irq context, Laurent noticed
> that the DRM documentation suggests that
> drm_kms_helper_hotplug_event() should b
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/1c8a441d/attachment.html>
||
--
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/20161129/88c35dc6/attachment.html>
On 11/29/2016 12:03 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch.
>
> On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
>> Add the regulator supply properties needed by ADV7511 and ADV7533.
>>
>> The regulators are specified as optional properties since there can
>> be
Hi Rob,
On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> >> Document properties common to several display panels in a central
> >> location that can be referenced by t
Hi Neil,
On Mon, Nov 28, 2016 at 10:34:58AM +0100, Neil Armstrong wrote:
> On 11/28/2016 09:16 AM, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> >> +static void meson_cvbs_encoder_disable(struct drm_encoder *encoder)
> >> +{
> >> + struct meson_cvbs *m
On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote:
> Two warnings are produced by gcc (tested with gcc 6.2.1):
>
> drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
> drivers/gpu/drm/i915/intel_csr.c:400:5: error: âfwâ is used
> uninitialized in this function
On Mon, Nov 28, 2016 at 05:07:52PM -0800, Manasi Navare wrote:
> On Thu, Nov 24, 2016 at 08:51:35AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote:
> > > This is RFC patch for adding a connector link-status property
> > > and making it atomic by adding
Hello,
This patch series replaces the custom external encoders support implementation
in the R-Car DU driver with code based on the DRM bridge API.
While the overall diffstat isn't impressive, the rcar-du-drm driver gets
notably thinner in the process:
9 files changed, 64 insertions(+),
The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
controlled through a power save pin, and requires a power supply.
However, on most boards where the device is used neither the power save
signal nor the power supply are controllable.
To avoid developing a separate device-specifi
Initialize the new drm_bridge::encoder_type field to the right value for
all bridges that model on-SoC IP cores.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
drivers/gpu/drm/sti/sti_dvo.c | 2 ++
3 f
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
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_encoder.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/g
The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS
encoders it can be controlled through a few pins (power down, LVDS
swing, clock edge selection) and requires power supplies. However, on
several boards where the device is used neither the control pins nor the
power supply are control
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
The rcar-du driver contains a manual implementation of HDMI and VGA
bridges. Use DRM bridges to replace it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 6 --
drivers/gpu/drm/rcar-du/Makefile | 5 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 104
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
The drm_bridge object models on- or off-chip hardware encoders and
provide an abstract control API to display drivers. In order to help
display drivers creating the right kind of drm_encoder object, expose
the type of the hardware encoder associated with each bridge.
Signed-off-by: Laurent Pinchar
Set the type of the DRM encoder that models the hardware encoders
(bridges) chain based on the type of the last bridge in the chain
instead of hardcoding encoder compatible strings in the display driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 17 ++---
The LVDS encoder driver is a DRM bridge driver that supports the
parallel to LVDS encoders that don't require any configuration. The
driver thus doesn't interact with the device, but creates an LVDS
connector for the panel and exposes its size and timing based on
information retrieved from DT.
Sig
Initialize the new drm_bridge::encoder_type field to the right value for
all external bridge drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix_d
The DT bindings support parallel to LVDS encoders that don't require any
configuration, similarly to the dumb VGA DAC DT bindings.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../bindings/display/bridge/lvds-transmitter.txt | 64 ++
1 file changed, 64 inserti
On 29/11/2016 08:56, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote:
>> Two warnings are produced by gcc (tested with gcc 6.2.1):
>>
>> drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
>> drivers/gpu/drm/i915/intel_csr.c:400:5: error: â
Hi Archit,
(CC'ing Mark Brown)
On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote:
> On 11/29/2016 12:03 PM, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
> >> Add the regulator supply properties needed by ADV7511 and ADV7533.
> >>
> >> The regulators are spec
Hi Mike,
On Monday 28 Nov 2016 22:27:01 Michael Turquette wrote:
> On Mon, Nov 28, 2016 at 10:04 PM, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote:
> >> On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 10:56:53 Andy Yan wrote
Am Montag, 28. November 2016, 16:42:27 schrieb Brian Norris:
> Hi,
>
> On Fri, Jun 24, 2016 at 10:13:33AM +0800, Shunqian Zheng wrote:
> > From: Simon Xue
> >
> > This patch makes it possible to compile the rockchip-iommu driver on
> > ARM64, so that it can be used with 64-bit SoCs equipped with
On 11/28/16 13:37, Bartosz Golaszewski wrote:
> The DT binding for tildc is not consistent with the driver code: there
> are two options - 'max-width' and 'max-pixelclock' specified in the
> documentation which are parsed as 'ti,max-width' and
> 'ti'max-pixelclock' respectively.
>
> Make the drive
This isn't part of the code snippet anymore ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_lock.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 9059fe3145a1..3551ae31
On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote:
> 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 p
On Tue, Nov 29, 2016 at 11:04:32AM +0200, Laurent Pinchart wrote:
> 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
On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> 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 enc
Hi Daniel,
On Tuesday 29 Nov 2016 10:30:36 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote:
> > 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 t
Hi Daniel,
On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > 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 point
Encoders&planes can't be hotplugged, we dont need looking for this
since it's all single-threaded driver setup/teardown code. CRTCs
already don't grab locks.
While at it I noticed that plane's are missing the
drm_modeset_lock_fini() call, so add it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/
On Tue, Nov 29, 2016 at 11:04:34AM +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
> ---
> drivers/gpu/dr
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/e9e9fe3e/attachment.sig>
On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel an
On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> The drm_bridge object models on- or off-chip hardware encoders and
> provide an abstract control API to display drivers. In order to help
> display drivers creating the right kind of drm_encoder object, expose
> the type of the har
On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> > The drm_bridge object models on- or off-chip hardware encoders and
> > provide an abstract control API to display drivers. In order to help
> > display drivers creating the r
On 28 November 2016 at 22:31, Eric Anholt wrote:
> There was a small window where a userspace program could submit
> a pageflip after receiving a pageflip completion event yet still
> receive EBUSY.
>
> Signed-off-by: Derek Foreman
> Signed-off-by: Eric Anholt
> Reviewed-by: Eric Anholt
Review
On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > > Instead of linking encoders and bridges in every driver (and getting it
> > > wrong ha
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/6651470f/attachment.html>
Hi Dave,
Big thing is that drm-misc is now officially a group maintainer/committer
model thing, with MAINTAINERS suitably updated. Otherwise just the usual
pile of misc things all over, nothing that stands out this time around.
Backmerge would also be great, since I just noticed that
commit 8ae9
Hi Dave,
Final 4.10 updates:
- fine-tune fb flushing and tracking (Chris Wilson)
- refactor state check dumper code for more conciseness (Tvrtko)
- roll out dev_priv all over the place (Tvrkto)
- finally remove __i915__ magic macro (Tvrtko)
- more gvt bugfixes (Zhenyu&team)
- better opregion CADL
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> 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 optiona
On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> > > The drm_bridge object models on- or off-chip hardware encoders and
> > > provide an abstract control A
On 11/29/2016 02:34 PM, 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
> ---
> drivers/gpu/drm/drm_encoder.c |
On 29/11/16 09:45, Daniel Vetter wrote:
> Encoders&planes can't be hotplugged, we dont need looking for this
s/looking/locking/
With that changed:
Reviewed-by: Frank Binns
> since it's all single-threaded driver setup/teardown code. CRTCs
> already don't grab locks.
>
> While at it I noticed th
phics
related mail that's not really relevant so I often skip it. Changing
the subject line would help with that.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/af4fa690/attachment.sig>
Hi Stephen,
drm-misc has slightly moved around, new branches for you to pull in:
git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes
git://anongit.freedesktop.org/drm/drm-misc for-linux-next
It's the same aliasing branch concept as for drm-intel, to avoid
trouble for you around the m
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/171d6d56/attachment-0001.html>
This patchset series adds HDMI video support to the Allwinner
sun8i SoCs which include the display engine 2 (DE2).
The driver contains the code for the A83T and H3 SoCs, and
some H3 boards, but it could be used/extended for other SoCs
(A64, H2, H5) and boards (Banana PIs, Orange PIs).
v7:
Signed-off-by: Jean-Francois Moine
---
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index c0c49dd..9f3e2f8 100644
--- a/arch/arm/
Signed-off-by: Jean-Francois Moine
---
Note 1:
The DE clock is not set in the driver. Instead, it is set at system
startup time by 'assigned-clocks', but there is a problem in sunxi-ng
which uses readl_relaxed_poll_timeout(), and, as noticed by
OndÅej Jirman, this function is not available at
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/sun8i/Kconfig | 7 +
drivers/gpu/drm/sun8i/Makefile | 2 +
drivers/gpu/drm/sun8i/de2_hdmi.c| 440 +++
drivers/gpu/drm/sun8i/de2_hdmi.h| 51 +++
drivers/gpu/drm/sun8i/de2_hdmi_io.c | 843
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/display/sunxi/hdmi.txt | 56 ++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.t
Signed-off-by: Jean-Francois Moine
---
include/dt-bindings/clock/sun8i-h3-ccu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h
b/include/dt-bindings/clock/sun8i-h3-ccu.h
index efb7ba2..7af57b7 100644
--- a/include/dt-bindings/clock/sun8i-h3-ccu.h
+++
Signed-off-by: Jean-Francois Moine
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 047e9e1..7712972 100644
--- a/arch/arm/boot/dts/sun8i-h3-
elevant logs I could gather. Please contact
me for further information/testing.
--
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
his series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 58
arch/arm/boo
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.ph
2016-11-29 11:53 GMT+01:00 Sekhar Nori :
> On Monday 28 November 2016 05:45 PM, Bartosz Golaszewski wrote:
>> Due to memory throughput constraints any display mode for which the
>> pixel clock rate exceeds the recommended value of 37500 KHz must be
>> filtered out.
>
> I think there might be more r
The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:
[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at
add
Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 37 +++--
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/8f438cc2/attachment.html>
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 3 ++-
1 file changed, 2 insertions(+
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i
On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>
> Until commit b1cb1bd29189 ("drm/i915/dsi: update re
On Tue, Nov 29, 2016 at 01:38:58PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
>
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Hans de Goede
> ---
> dri
Hi,
Thanks for the quick reply.
On 29-11-16 13:48, Ville Syrjälä wrote:
> On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
>> Looking at the ADF code from the Android kernel sources for a
>> cherrytrail tablet I noticed that it is calling the
>> MIPI_SEQ_ASSERT_RESET sequence from
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/87a35b78/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/5d23cd2d/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/77e45815/attachment-0001.html>
hris Wilson 2011-02-03 411 __entry->size = size;
db53a302 Chris Wilson 2011-02-03 412 __entry->align =
align;
:: The code at line 409 was first introduced by commit
:: e522ac2324f384e1fafd1a4ae6ebf38095dc6695 drm/i915: Remove surplus
drm_device parameter to i915_gem_evict_something()
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25157 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/366f926a/attachment-0001.gz>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/e93f2b51/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/68d788a3/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161129/778681be/attachment.html>
On Tue, Nov 29, 2016 at 02:06:20PM +0100, Hans de Goede wrote:
> Hi,
>
> Thanks for the quick reply.
>
> On 29-11-16 13:48, Ville Syrjälä wrote:
> > On Tue, Nov 29, 2016 at 01:38:57PM +0100, Hans de Goede wrote:
> >> Looking at the ADF code from the Android kernel sources for a
> >> cherrytrail
On Tue, Nov 29, 2016 at 10:24:40AM +0100, Daniel Vetter wrote:
> This isn't part of the code snippet anymore ...
>
> Signed-off-by: Daniel Vetter
Merged with Rob's irc-ack.
-Daniel
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
On Tue, Nov 29, 2016 at 10:39:03AM +, Frank Binns wrote:
> On 29/11/16 09:45, Daniel Vetter wrote:
> > Encoders&planes can't be hotplugged, we dont need looking for this
>
> s/looking/locking/
>
> With that changed:
> Reviewed-by: Frank Binns
Fixed&applied, thanks for your review.
-Daniel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Widawsky (1):
intel: Add Geminilake PCI IDs
Christian Gmeiner (4):
etnaviv: add API to get drm fd from etna_device
etnaviv: add API to create etna_device from private dup() fd
etnaviv: change get_abs_timeout(..) to use ns.
On Tue, Nov 29, 2016 at 11:47:45AM +0100, Neil Armstrong wrote:
> This a repost of the previous RFC at [1] with fixes, the following patches
> will
> be sent via a PULL Request once the Amlogic maintainer acks and takes the DT
> patches to avoid merges conflicts.
>
> The Amlogic Meson SoCs embeds
2016-11-25 8:59 GMT+09:00 Dave Airlie :
>>No critial patch but it make sure to unmap the region
>>if HDMI probing failed, and it includes two trivial fixups.
>>
>
> I've cherry-picked the hdmi fix, but I think the other two patches
> should go in -next
> at this stage,
Thanks,
Inki Dae
>
On Mon, Nov 28, 2016 at 03:23:54PM +0100, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine
Scrolled around a bit, seemed all reasonable.
Ac
Useful with our branch proliferation to make sure nothing is stuck (we
now also have drm-misc-next/-next-fixes/-fixes).
v2: Gracefully handle if some remotes arent' there.
Acked-by: seanpaul at chromium.org
Signed-off-by: Daniel Vetter
---
dim | 22 ++
dim.rst | 5 +
Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.
But added the dependency as depends on !VIDEO_SAMSUNG_
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (HF-VSDB). This block
contains information about sink's support for HDMI 2.0 compliant
features. These features are:
- Deep color YUV 420 support and BPC
- 3D flags for
- O
On Mon, Nov 28, 2016 at 7:59 PM, Manasi Navare
wrote:
> On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>> > On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>> > wrote:
>> > > This is RFC patch for adding a connector link
On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
>> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> >> Document properties common to several dis
Hi Dave,
Regression fixes for PX and a powerplay fix.
The following changes since commit 9704668e4b7105ede483f38da7f29d71b5bc0165:
Merge branch 'mediatek-drm-fixes-2016-11-24' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes (2016-11-25
14:21:26 +1000)
are available in the
1 - 100 of 208 matches
Mail list logo
