ev_priv->drm.struct_mutex);
0c5664e4 Dave Gordon2016-09-12 783
guc_interrupts_release(dev_priv);
beffa517 Dave Gordon2016-06-10 784
i915_guc_submission_disable(dev_priv);
beffa517 Dave Gordon2016-06-10 785
i915_guc_submission_fini(dev_priv);
bac427f8 Alex Dai 2015-08-12 786
33a732f4 Alex Dai 2015-08-12 787 if (guc_fw->guc_fw_obj)
:: The code at line 779 was first introduced by commit
:: 33a732f407fed464df687370d7bb4d64533f9920 drm/i915: GuC-specific firmware
loader
:: TO: Alex Dai
:: CC: Daniel Vetter
---
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: 6425 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/be873276/attachment.gz>
Hi Daniel,
On Thu, 01 Dec 2016 11:02:26 + Daniel Stone
wrote:
>
> On Nov 30 2016, at 10:49 pm, Rob Clark wrote:
>
> > yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
> git urls for folks who have push access work fine).. although it has
> worked for me a coup
Hello,
This patch series implements support for the HDMI output on Renesas R-Car Gen3
SoCs, and more specifically on the R-Car H3.
R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The
series thus starts with 13 cleanup or feature patches for the dw-hdmi driver.
Patches 01
From: Kieran Bingham
The 'prep' parameter passed to hdmi_phy_configure() is useless. It is
hardcoded as 0, and if set, simply prevents the configure function from
executing.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 7 ++--
The master argument isn't used. The data argument, a void pointer, is
used by the bind function only where it's cast to a drm_device pointer,
which can easily be obtained from the encoder argument instead. Remove
them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c
The latter is just an int wrapper around the former void function that
unconditionally returns 0. As the return value is never checked, merge
the two functions into one.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
1 file changed, 1 insertion(+), 8 deletion
There's no need to duplicate identical code in multiple drivers (two at
the moment, one more to come soon). Move it to the dw-hdmi core where it
can be shared. If resource allocation ever becomes device-specific later
we'll always have the option of splitting it out again.
While it at pass the pla
Hotplug events should only be forwarded to the DRM core by the interrupt
handler when the bridge has been attached, otherwise the DRM device
pointer will be NULL, resulting in a crash.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 3 ++-
1 file changed, 2 insertions(+),
From: Kieran Bingham
Platforms implement the dw-hdmi with a separate PHY entity. It is
configured over it's own I2C bus. To allow for different PHY's to be
configured from the dw-hdmi driver, abstract the actual programming of
the PHY to its own functions, as configured by the platform.
Signed-o
The field isn't needed, remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 2c85b6c07a80..ef10bb866b2f 100644
--- a/d
The DRM device is not guaranteed by the bridge API to be available
before the attach callback. The driver performs properly at the moment
as it doesn't use the drm_bridge_add() registration method. As this will
be changed later, move connector creation to attach time to ensure
compatibility with th
From: Kieran Bingham
The dw-hdmi driver declares a dev_type to distinguish platform specific
changes. Replace this with a quirk field, so that the platform can
specify the required quirks for the driver, rather than the driver
becoming conditional on multiple platforms.
As part of this, we renam
The drm_bridge instance is always needed, there's no point in allocating
it separately.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridg
From: Ulrich Hecht
Add DT nodes for the two HDMI encoders in disabled state.
Based on work by Koji Matsuoka.
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 50
1 file changed, 50 insertions(+)
diff
From: Koji Matsuoka
The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support
them with a platform driver to provide platform glue data to the dw-hdmi
driver.
The driver is a complete rewrite of code coming from the Renesas BSP,
save for the values in the PHY parameters table.
Signe
When a DT node connected to a DU output is disabled no bridge will ever
be instantiated for it. Skip the output in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/di
From: Koji Matsuoka
Instantiate the HDMI connectors and enable the encoders.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 50 ++
1 file changed, 50 insertions(+)
diff --g
From: Kieran Bingham
The current code hard codes the call of hdmi_phy_configure() to be 8bpp
and provides extraneous error checking to verify that this hardcoded
value is correct.
Simplify the passing of the data by setting the parameter to be of the
enum type it represents rather than convertin
The DU1 and DU2 external dot clocks are fixed frequency clock generators
running at 33MHz.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 23 ++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvat
From: Koji Matsuoka
The implementation hardcodes a workaround for the H3 ES1.x SoC
regardless of the SoC revision, as the workaround can be safely applied
on all devices in the Gen3 family without any side effect.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent
The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
corresponding device tree bindings based on the DWC HDMI TX bindings
model.
Signed-off-by: Laurent Pinchart
---
.../bindings/display/bridge/renesas,dw-hdmi.txt| 75 ++
MAINTAINERS
The next commit will reference structures and functions in a way that
currently requires forward declarations. Reorder the functions to avoid
that. No functional change to the code is performed.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 72 ---
As an option for drivers not based on the component framework, register
the bridge with the DRM core with the DRM bridge API. Existing drivers
based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those
functions are preserved with their current behaviour.
Signed-off-by: Laurent Pinchar
From: Koji Matsuoka
Update the device description with the two available HDMI outputs.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 12 ++--
2 files changed, 13 insertions(+)
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/175e1946/attachment.html>
We should use dma_pool_zalloc instead of dma_pool_alloc/memset
Signed-off-by: Souptick joarder
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.
||
--
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/20161202/792d40fe/attachment.html>
Hi,
On 12/02/2016 08:02 AM, zain wang wrote:
> We will ignored PSR setting if panel not support it. So, in this case, we
> should
> return from analogix_dp_enable/disable_psr() without any error code.
> Let's retrun 0 instead of -EINVAL when panel not support PSR in
> analogix_dp_enable/disable_p
20]/bestvideo[fps>30])[tbr<13000]+(bestaudio[acodec=opus]/bestaudio)/best
--
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/attachm
On 12/01/2016 10:02 PM, Michal Nazarewicz wrote:
> On Thu, Dec 01 2016, Michal Hocko wrote:
>> I am not familiar with this code so I cannot really argue but a quick
>> look at rmem_cma_setup doesn't suggest any speicific placing or
>> anything...
>
> early_cma parses âcmaâ command line argument
On 01.12.2016 16:12, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
>> On 01.12.2016 08:18, Daniel Vetter wrote:
>>> On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
On 30.11.2016 14:09, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 01:
On Thu, Dec 01, 2016 at 03:09:40PM -0800, Sinclair Yeh wrote:
> One defect below otherwise: Reviewed-by: Sinclair Yeh
>
> On Wed, Nov 30, 2016 at 06:00:04PM +0100, Daniel Vetter wrote:
> > Surprisingly few changes needed to make it happen. Compile-tested
> > only. The idea is that this replaces
Surprisingly few changes needed to make it happen. Compile-tested
only. The idea is that this replaces the 2 patches from Ville's big
fb->format patch series as a prep patch. Only impact to later patches
should be the one instace added in this patch where we look at
fb->pixel_format (instead of fb-
On Thu, Dec 01, 2016 at 09:09:25PM +0100, Boris Brezillon wrote:
> List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better
> represented with enums.
>
> Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum.
>
> Signed-off-by: Boris Brezillon
> Suggested-by: Daniel Vetter
Yeah, this i
We will ignored PSR setting if panel not support it. So, in this case, we should
return from analogix_dp_enable/disable_psr() without any error code.
Let's retrun 0 instead of -EINVAL when panel not support PSR in
analogix_dp_enable/disable_psr().
Signed-off-by: zain wang
---
drivers/gpu/drm/bri
Hi all,
This series adds support for the Tianma TM070JDHG30 7" display (1280x800).
http://usa.tianma.com/products-technology/product/tm070jdhg30-00
https://boundarydevices.com/product/bd070lic2/
The first patch adds Tianma as a new vendor prefix whereas the second patch
adds the display to the si
Tianma Micro-electronics Co., Ltd. (Tianma) specializes in providing
display solutions and efficient support services worldwide.
More info:
http://en.tianma.com/about.shtml
Signed-off-by: Gary Bisson
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
The Tianma TM070JDHG30 is a 7" LVDS display with a resolution of
1280x800.
http://usa.tianma.com/products-technology/product/tm070jdhg30-00
You can also find this product along with a FT5x06 touch controller
from Boundary Devices:
https://boundarydevices.com/product/bd070lic2/
Signed-off-by: Gary
https://bugzilla.kernel.org/show_bug.cgi?id=189451
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Commen
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/46dbbfaa/attachment.html>
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/20161202/6461598c/attachment-0001.html>
On Fri, Dec 02, 2016 at 08:07:40AM +0100, Daniel Vetter wrote:
> Surprisingly few changes needed to make it happen. Compile-tested
> only. The idea is that this replaces the 2 patches from Ville's big
> fb->format patch series as a prep patch. Only impact to later patches
> should be the one instac
The primary consumer of the lpss pwm is the i915 kms driver, but
currently that driver cannot get the pwm because i915 platforms are
not using devicetree and pwm-lpss does not call pwm_add_table.
Another problem is that i915 does not support get_pwm returning
-EPROBE_DEFER and i915's init is very
Add a get_state callback so that the initial state correctly reflects
the actual hardware state.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index b4d8835
Am Donnerstag, den 01.12.2016, 15:11 +0100 schrieb Michal Hocko:
> Let's also CC Marek
>
> On Thu 01-12-16 08:43:40, Vlastimil Babka wrote:
> > On 12/01/2016 08:21 AM, Michal Hocko wrote:
> > > Forgot to CC Joonsoo. The email thread starts more or less here
> > > http://lkml.kernel.org/r/201611300
On Thu, 01 Dec 2016, Hans de Goede wrote:
> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
> not fine grained enough to abstract all the different steps we need to
> take (and VBT sequences we need to exec) properly. So simply remove the
> panel _enable/disable and prepare/
On Thu, 01 Dec 2016, Hans de Goede wrote:
> Document the DSI panel enable / disable sequences from the spec,
> for easy comparison between the code and the spec.
>
> Signed-off-by: Hans de Goede
I haven't done a proper review, but patches 1-8 are
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm
The dumper is only a debugging aid so we don't want to invoke the OOM
killer if buffer for the potentially large GPU state can't be vmalloced.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
On Fri, 02 Dec 2016, Hans de Goede wrote:
> The primary consumer of the lpss pwm is the i915 kms driver, but
> currently that driver cannot get the pwm because i915 platforms are
> not using devicetree and pwm-lpss does not call pwm_add_table.
>
> Another problem is that i915 does not support get_
On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
linear window has to be moved for the GPU to work at all. This doesn't
mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
window offset into account and will corrupt memory when used with a
non-zero offset.
> -Original Message-
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Thursday, December 1, 2016 4:15 PM
> To: Lofstedt, Marta
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] drm: allow changing DPMS mode for non-CRTC displays
>
> On Thu, Dec 01, 2016 at
On Thursday, 2016-12-01 14:15:05 +, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:30:01PM +0200, Marta Lofstedt wrote:
> > For non-CRTC displays,
>
> A connector not attached to a CRTC works. It is the active connectors
> that were broken.
>
> > the drm_atomic_helper_connector_dpms
> > wil
On Thu, Dec 01, 2016 at 09:29:08PM +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 Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> Once the i915 driver has successfully loaded, the panel can be disabled /
> enabled
Hi Laurent,
On 01-12-2016 23:43, Laurent Pinchart wrote:
> Hello,
>
> This patch series implements support for the HDMI output on Renesas R-Car Gen3
> SoCs, and more specifically on the R-Car H3.
>
> R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The
> series thus start
On 12/02/2016 12:29 PM, Lucas Stach wrote:
> On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
> linear window has to be moved for the GPU to work at all. This doesn't
> mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
> window offset into account and wi
Hi Laurent,
On 01-12-2016 23:43, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> Platforms implement the dw-hdmi with a separate PHY entity. It is
> configured over it's own I2C bus. To allow for different PHY's to be
> configured from the dw-hdmi driver, abstract the actual programming of
>
Philipp Zabel writes:
> I had already (accidentally) fixed this with 3fd8b292ae6b ("drm/imx:
> ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update").
Thanks, I've merged your pza/imx-drm/next and it now works.
--
Krzysztof Halasa
Industrial Research Institute for Automation and Mea
Hi,
On 02-12-16 13:40, Ville Syrjälä wrote:
> On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
>> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
>> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
>> Once the i915 driver has succes
Hi,
On 02-12-16 13:37, Ville Syrjälä wrote:
> On Thu, Dec 01, 2016 at 09:29:08PM +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.
>>
>
On Fri, Dec 02, 2016 at 02:27:43PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02-12-16 13:40, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> >> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> >> i915 at boot 1 out of every 3 b
Hi,
On 02-12-16 11:31, Jani Nikula wrote:
> On Thu, 01 Dec 2016, Hans de Goede wrote:
>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
>> not fine grained enough to abstract all the different steps we need to
>> take (and VBT sequences we need to exec) properly. So simply
On Fri, Dec 02, 2016 at 02:34:01PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02-12-16 13:37, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
> >> Looking at the ADF code from the Android kernel sources for a
> >> cherrytrail tablet I noticed that it is call
Sorry for the noise, but I forgot to Cc the DT maintainers.
Here is the 2nd version of the VC4/VEC series.
We still miss the two clock patches mentioned by Eric in the first
version to make the encoder work no matter the setting applied by the
bootloader.
Regards,
Boris
Boris Brezillon (7):
Some generic TV connector properties are exposed in drm_mode_config, but
they are currently handled independently in each DRM encoder driver.
Extend the drm_connector_state to store TV related states, and modify the
drm_atomic_connector_{set,get}_property() helpers to fill the connector
state acco
The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_debugfs.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
drivers/gpu/drm/vc4
List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better
represented with enums.
Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum.
Signed-off-by: Boris Brezillon
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
include/uapi/drm/drm_mode.h | 18 ++
1 file
PV_CONTROL_CLK_SELECT_VEC is actually 2 and not 0. Fix the definition and
rework the vc4_set_crtc_possible_masks() to cover the full range of the
PV_CONTROL_CLK_SELECT field.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_crtc.c | 38 +++---
drivers/gp
Document the DT binding for the VEC (Video EnCoder) IP.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/de
Add the VEC (Video EnCoder) node definition in bcm283x.dtsi.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/bcm283x.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d894a44..44a9c0539437 100644
--- a
Enable the VEC IP on all RaspberryPi boards.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index e9b47b2bbc33..8893240da5f6 100644
--- a/arch/
On Fri, 02 Dec 2016, Hans de Goede wrote:
> Hi,
>
> On 02-12-16 11:31, Jani Nikula wrote:
>> On Thu, 01 Dec 2016, Hans de Goede wrote:
>>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
>>> not fine grained enough to abstract all the different steps we need to
>>> take (an
drm_universal_plane_init() and drm_plane_init() take "unsigned long
possible_crtcs" parameter, but then stuff it into uint32_t. Change the
parameter to uint32_t.
Signed-off-by: Tomi Valkeinen
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 4 ++--
include/drm/drm_plane.h | 4 ++--
2 f
We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
which is fine as the HW planes can be used fro all crtcs. However, when
we're doing that, we are still incrementing 'num_crtcs', and we'll end
up with bad possible_crtcs, preventing the use of the primary planes.
This patch p
Hi Jose,
On Friday 02 Dec 2016 11:15:19 Jose Abreu wrote:
> On 01-12-2016 23:43, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > Platforms implement the dw-hdmi with a separate PHY entity. It is
> > configured over it's own I2C bus. To allow for different PHY's to be
> > configured from
Hi Tomi,
Thank you for the patch.
On Friday 02 Dec 2016 16:07:10 Tomi Valkeinen wrote:
> drm_universal_plane_init() and drm_plane_init() take "unsigned long
> possible_crtcs" parameter, but then stuff it into uint32_t. Change the
> parameter to uint32_t.
>
> Signed-off-by: Tomi Valkeinen
> Cc:
On Fri, Dec 02, 2016 at 04:07:10PM +0200, Tomi Valkeinen wrote:
> drm_universal_plane_init() and drm_plane_init() take "unsigned long
> possible_crtcs" parameter, but then stuff it into uint32_t. Change the
> parameter to uint32_t.
>
> Signed-off-by: Tomi Valkeinen
> Cc: Ville Syrjälä
Reviewe
Hi Tomi,
Thank you for the patch.
On Friday 02 Dec 2016 16:07:11 Tomi Valkeinen wrote:
> We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
> which is fine as the HW planes can be used fro all crtcs. However, when
> we're doing that, we are still incrementing 'num_crtcs', an
iv-num_crtcs tells the amount of crtcs in priv->crtcs. If we set
priv->num_crtcs before actually creating those crtcs, I fear we could
easily create a bug. The crtc+plane creation code is not the shortest
one, so even if we wouldn't have a bug right now, I imagine it could be
easy to wr
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_d
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 Fri, Dec 02, 2016 at 11:26:02AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 01.12.2016, 15:11 +0100 schrieb Michal Hocko:
> > Let's also CC Marek
> >
> > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote:
> > > On 12/01/2016 08:21 AM, Michal Hocko wrote:
> > > > Forgot to CC Joonsoo. The email
Hi Tomi,
On Friday 02 Dec 2016 16:22:18 Tomi Valkeinen wrote:
> On 02/12/16 16:16, Laurent Pinchart wrote:
> > On Friday 02 Dec 2016 16:07:11 Tomi Valkeinen wrote:
> >> We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
> >> which is fine as the HW planes can be used fro all
Hi Russell,
On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The dw-hdmi driver declares a dev_type to distinguish platform specific
> > changes. Replace this with a quirk field, so
Hi Russell,
On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> > and provides extraneous error checking to ve
https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/dd3a6a30/attachment.sig>
Hi Tomi,
On Friday 02 Dec 2016 17:55:10 Tomi Valkeinen wrote:
> On 02/12/16 17:42, Laurent Pinchart wrote:
> > I can understand that (even if I'm not sure it's really an issue, and we
> > should really clean up the CRTC creation code at some point), but how
> > about adding a possible_crtcs field
On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja
wrote:
> Hi,
>
> On 12/02/2016 08:02 AM, zain wang wrote:
>>
>> We will ignored PSR setting if panel not support it. So, in this case, we
>> should
>> return from analogix_dp_enable/disable_psr() without any error code.
>> Let's retrun 0 instead of -
dri-devel/attachments/20161202/e7d2d9fb/attachment.html>
On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the l
https://bugzilla.kernel.org/show_bug.cgi?id=189451
--- Comment #2 from Raffaele ---
HI,
I don't know if it worked. I didn't really used linux until recentely
The PC boots and work as expected.
But i think it slows down boot time (I discovered it while trying to reduce
boot time) and I cannot us
From: Emil Velikov
Be consistent with drmParsePciBusInfo() and use solely the device
major/minor pair.
Cc: Jonathan Gray
Signed-off-by: Emil Velikov
---
Jonathan, please respin your patches on top of this series.
---
xf86drm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-
From: Emil Velikov
Up-to recently (patch should land in 4.10) the kernel did not expose the
PCI device revision field as a separate sysfs file.
Thus one needed too parse the config file to retrieve it. This in
itself wakes up the device, which in some cases can be quite slow.
To avoid that, jus
From: Emil Velikov
Will be used with the drmGetDevice[s]2 API.
Cc: Michel Dänzer
Cc: Nicolai Hähnle
Cc: Mauro Santos
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov
---
xf86drm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
From: Emil Velikov
Pass along DRM_DEVICE_GET_PCI_REVISION only when the individual nodes
are opened and update the printed messages accordingly.
v2: Attribute for the flag rename, call drmGetDevices2 w/o the flag.
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer
---
tests/drmdevice.c
From: Emil Velikov
Relative to the original version, here one can provide a flags bitmask.
Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported.
Implementation detail:
If it's set, we will only parse the separate sysfs files and we won't
touch the config one. The latter awakes the device (
Hi Russell,
On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote:
> > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that.
> >
> > Do you know why this function needs to write to the HDMI_FC_INVIDCONF
> > regi
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/f9d07e04/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/20161202/24332e18/attachment.html>
1 - 100 of 117 matches
Mail list logo
