.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/be9596c3/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/6d2e4fa7/attachment.html>
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/4dca2ae8/attachment.html>
From: Thierry Reding
Sinks that support SCDC can optionally have the capability to initiate
read requests, which are a mechanism by which a sink can notify its
source that it should read the Update Flags. If either the sink or the
source are not Read Request capable, polling of the Update Flags s
From: Thierry Reding
Sinks compliant with the HDMI 2.0 specification may support SCDC, a
mechanism for the source and the sink to communicate. Sinks advertise
support for this feature in the HDMI Forum Vendor Specific Data Block
as defined in the HDMI 2.0 specification, section 10.4 "Status and
C
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
Signed-off-by: Thierry
Hi Dave,
Not much news in etnaviv land this time around.
- fix dma-buf export path to return correct SG table
- trivially implement direct dma-buf mapping
- allow DRAW_INSTANCED commands in validator
- make the driver work on i.MX6SX, yielding a working 2D/3D stack
together with Mareks MXS DRM dr
t.
--
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/374292f6/attachment.html>
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
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
https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/dd3a6a30/attachment.sig>
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
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 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
--
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>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/f9d07e04/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
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 (
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
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(-
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
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
dri-devel/attachments/20161202/e7d2d9fb/attachment.html>
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
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: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:
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
On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote:
> 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
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
> register four times in the normal case, and once only for IMX6DL ?
(I don't have much ti
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
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
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, 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
org/archives/dri-devel/attachments/20161202/77c81c09/attachment.sig>
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
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
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
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/
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
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
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
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
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
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):
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 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
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
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.
>>
>
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
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 that the platform can
> specify the required quirks for the driver, rather than the d
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 verify that this hardcoded
> value is correct.
>
> Simplify the passing of the data by
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
vmwgfx part: Reviewed-by: Sinclair Yeh
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 compil
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
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 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
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 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.
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 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 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
> -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
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
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
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
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
>
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 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 -
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
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
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
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(+)
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
On Fri, Dec 02, 2016 at 08:00:22AM +0100, Daniel Vetter wrote:
> 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
On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> 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 poss
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>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/46dbbfaa/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
https://bugzilla.kernel.org/show_bug.cgi?id=189451
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Commen
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
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 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
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:
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
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 12/01/2016 06:17 PM, Shuah Khan wrote:
> On 10/19/2016 06:49 AM, Emilio López wrote:
>> Hello everyone,
>>
>> This is a series of tests to exercise the sync kernel infrastructure. It is
>> meant to be a test suite for the work Gustavo has been doing to destage it.
>>
>> These tests were origina
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>
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
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
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: 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
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(+)
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
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
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
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
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
1 - 100 of 117 matches
Mail list logo
