Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Detect the PHY type and use it to handle the PHY type-specific SVSRET
> signal.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 68
> ++--
> include/drm/bridge/dw_hdmi.
Hi Shashank,
On 20-12-2016 13:47, Shashank Sharma wrote:
> This patch creates a new structure drm_hdmi_info (inspired from
> drm_display_info). Driver will parse HDMI sink's advance capabilities
> from HF-VSDB and populate this structure. This structure will be kept
> and used as a sub-class with
The ast driver configures a window to enable access into BMC memory space
in order to read some configuration registers. If this window is
disabled, which it can be from the BMC side, the ast driver can't
function. Closing this window is a necessity for security if a machine's
host side and BMC s
On Sun, Dec 18, 2016 at 10:53 PM, Alexander Stein
wrote:
> Hello Kees,
>
> While understanding what your patches (I've seen the other ones as well) do
> themself, I still don't get what your intention is, e.g. why you need this?
> Apart from a better readability.
>
> On Friday 16 December 2016 16:
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Use the device version queried at runtime instead of the device type
> provided through platform data to handle the overflow workaround. This
> will make support of other SoCs integrating the same HDMI TX controller
> version easier.
>
>
we already have that included in 4.10
2016-12-12 12:26 GMT+01:00 Chris Chiu :
> Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it
> only gives VGA resolution on screen. Use the same chipset as nv134
> then it shows FullHD. This commit copies fields from nv134_chipset
> to nv136_c
Hi Russell,
On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>> Instead of spreading version-dependent PHY power handling code around,
>> group it in two functions to power the PHY on and off and use them
>> through the drive
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> The DWC HDMI TX can be recognized by the two product identification
> registers. If the registers don't read as expect the IP will be very
> different than what the driver has been designed for, or will be
> misconfigured in a way that ma
Hi Laurent,
On 20-12-2016 13:11, Laurent Pinchart wrote:
> Hi Jose,
>
> On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
>> On 20-12-2016 01:33, Laurent Pinchart wrote:
>>> Detect the PHY type and use it to handle the PHY type-specific SVSRET
>>> signal.
>>>
>>> Signed-off-by: Laurent Pinchart
>
On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> Instead of spreading version-dependent PHY power handling code around,
> group it in two functions to power the PHY on and off and use them
> through the driver.
>
> Powering off the PHY at the beginning of the setup phase is curr
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> The bit is documented in a Rockchip BSP as
>
> #define m_SVSRET_SIG (1 << 5) /* depend on PHY_MHL_COMB0=1 */
>
> This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
> the RK3288. Rename the bit accordingly.
>
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
atomic_commit. drm_object_property_get_value() does not read the correct
value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
the driver uses atomic modeset is a better check instead as the property
values
101 - 112 of 112 matches
Mail list logo
