Thank you for your test. I'm happy if it could have it.
>
> Mark, Thierry, Daniel
> I wonder who can be maintainer for this patch ??
>
> Best regards
> ---
> Kuninori Morimoto
Tested-by: Jose Abreu
Best regards,
Jose Miguel Abreu
Hi,
On 03-08-2016 12:48, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 04:26:24PM +0530, Shashank Sharma wrote:
>> This patch series adds 4 patches.
>> - The first two patches add aspect ratio support in DRM layes
>> - Next two patches add new aspect ratios defined in CEA-861-F
>> supported fo
vel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Jose Abreu (3):
drm: bridge/dw-hdmi: Add support for DWC Phy
drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets
drm: bridge/dw-hdmi: Move edid reading to .detect() callback
drivers/gpu/drm/bridge/dw-hdmi.c
validated. This is specific to Synopsys Phy.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Archit Taneja
Cc: David Airlie
Cc: Russell King
Cc: Fabio Estevam
Cc: Daniel Vetter
Cc: Takashi Iwai
Cc: Vladimir Zapolskiy
Cc: Thierry Reding
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel
Currently ISCR and ACP packets are not being sent causing
HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
With this pacth the mentioned packets are activated when
needed.
Verified using HDMI compliance equipment.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Archit Taneja
Cc
and
> sending the flagless modeset back to libdrm.
Do you mean Xserver, the X driver that I am using (which is
modesetting), the xrandr or all of them? I guess that if they
don't touch the flags field and return the mode exactly the same
as it was probed to DRM then it will work as ex
Hi Russell,
On 04-08-2016 15:31, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>> I am not sure if this is a bug in DRM or a bad implementation of
>> dw-hdmi. I've seen at least two more drivers th
On 04-08-2016 15:29, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 8/4/2016 7:46 PM, Jose Abreu wrote:
>> Hi Sharma,
>>
>>
>> On 03-08-2016 16:47, Sharma, Shashank wrote:
>>> Hello Joes,
>>>> I've also seen this befor
Hi Russell,
On 04-08-2016 16:32, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
>> Currently ISCR and ACP packets are not being sent causing
>> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
> Hmm. Reading the HDMI sp
When running HDMI compliance tests we noticed that sometimes
the edid changes but the get_modes() function is not called
so the edid is not updated. Moving the edid reading to the
detect() callback ensures that the edid is correctly updated
after an hotplug.
Signed-off-by: Jose Abreu
Cc: Carlos
Hi Russell,
On 04-08-2016 11:47, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:51AM +0100, Jose Abreu wrote:
>> When running HDMI compliance tests we noticed that sometimes
>> the edid changes but the get_modes() function is not called
>> so the edid is no
Hi Russell,
On 04-08-2016 16:04, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
>> Hmm, I am not debugging it right now but I remember that
>> drm_fb_helper_probe_connector_modes() was not being called at the
>> time I set
Hi,
Currently I am working on some HDMI 2.0 features using the DRM
infrastructure. I am mainly working in parsing the newly
introduced EDID blocks such as HDMI Forum Vendor Specific Data
Block, YCBCR 420 Video Data Block and YCBCR Capability Map Data
Block. The new blocks require some changes in t
Hi,
On 05-08-2016 09:13, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
>>>> Hi Russe
Hi Sharma,
On 05-08-2016 04:37, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 8/4/2016 9:39 PM, Daniel Vetter wrote:
>> On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
>>> On 4 August 2016 at 14:15, Sharma, Shashank
>>> wrote:
On 8/4/2016 5:04 PM, Emil Velikov wrote:
Adds parsing for HDMI 2.0 'HDMI Forum Vendor
Specific Data Block'. This block is present in
some HDMI 2.0 EDID's and gives information about
scrambling support, SCDC, 3D Views, and others.
Parsed parameters are stored in drm_connector
structure.
Signed-off-by: Jose Abreu
Cc: Carl
Hi Ville,
On 12-08-2016 14:46, Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 04:29:21PM +0100, Jose Abreu wrote:
>> Adds parsing for HDMI 2.0 'HDMI Forum Vendor
>> Specific Data Block'. This block is present in
>> some HDMI 2.0 EDID's and gives informati
Hi Russell,
On 17-08-2016 12:21, Russell King - ARM Linux wrote:
> On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>> When using driver dw-hdmi in any other colorspace than RGB the
>> Y1, Y0 and YCC values are not correct. I confirme
Hi Russell,
When using driver dw-hdmi in any other colorspace than RGB the
Y1, Y0 and YCC values are not correct. I confirmed in databook
that these registers are being written to the wrong offset (per
my databook they should be written in bits 0:1 and 7 instead of
bits 4:5). The piece of code in
Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at
hashank Sharma (4):
> drm: add picture aspect ratio flags
> drm: Add aspect ratio parsing in DRM layer
> video: Add new aspect ratios for HDMI 2.0
> drm: Add and handle new aspect ratios in DRM layer
I am using these patches to run HDMI 2.0 compliance so:
Tested-by: Jose Abreu
Hi Shashank,
On 17-10-2016 12:32, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
> supported for HDMI 2.0 4k modes.
>
> Adding aspect ratio support in DRM
Hi Eugeniy,
On 30-03-2017 13:05, Eugeniy Paltsev wrote:
> Hi,
>
> I am trying to add support of new component framework API in ARC PGU driver.
> The point is that for now we have ARC PGU driver which works with adv7511
> encoder. Both of them don't support component framework API. I had to add
parsing
them (because in patch 07/11 you reject these properties)? Also,
you need to make sure that source and sink supports the color space.
Best regards,
Jose Miguel Abreu
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Daniel Vetter
> Signed-off-by: Shashank Sharma
> ---
>
this patch adds a function in DRM layer, to
> add the output colorspace information in the AVI infoframes.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 40
> include/drm/dr
Hi All,
Is there any callback available, at the crtc level, that can
validate the probed modes before making them available for
userspace? I mean: I know that there is connector->mode_valid(),
but I couldn't find any equivalent crtc->mode_valid(). I found
mode_fixup() but this is called after giv
++ Daniel
++ Dave
On 21-04-2017 13:59, Jose Abreu wrote:
> Hi All,
>
>
> Is there any callback available, at the crtc level, that can
> validate the probed modes before making them available for
> userspace? I mean: I know that there is connector->mode_valid(),
>
s needed in arcpgu, please refer here [1].
[1] https://patchwork.kernel.org/patch/9694177/
Jose Abreu (2):
drm: Introduce crtc->mode_valid() callback
drm: arcpgu: Use crtc->mode_valid() callback
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Air
gt;> with the DWC
>> MLP PHY. The HDMI 2.0 PHY will require a separate configuration
>> function.
>>
>> Signed-off-by: Kieran Bingham
>>
>> Signed-off-by: Laurent Pinchart
>>
>> Tested-by: Neil Armstrong
>> Reviewed-by: Jose Abreu
>>
If the crtc does not implement the callback then the behaviour will
remain the same. Also, for a given set of crtcs that can be bound to
the connector, if at least one can display the mode then the mode
will be probbed.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syr
this clock
does not support all the needed ranges.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm
Hi Andrzej,
Thanks for your answer!
On 27-04-2017 11:05, Andrzej Hajda wrote:
> Hi Jose,
>
> On 26.04.2017 12:48, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode_valid()) is introd
Hi Ville,
Thanks for the review! My comments inline.
On 28-04-2017 12:41, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode
If the crtc does not implement the callback then the behaviour will
remain the same. Also, for a given set of crtcs that can be bound to
the connector, if at least one can display the mode then the mode
will be probbed.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syr
this clock
does not support all the needed ranges.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
---
Changes v1->v2:
- Reduce code duplication by using helper function
- c
s needed in arcpgu, please refer here [1].
[1] https://patchwork.kernel.org/patch/9694177/
Jose Abreu (2):
drm: Introduce crtc->mode_valid() callback
drm: arcpgu: Use crtc->mode_valid() callback
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airli
Hi Daniel,
On 02-05-2017 09:48, Daniel Vetter wrote:
> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode_valid()) is introduced that
>> i
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340 MHz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scrambling
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> This patch implements a small function that finds if a
> given CEA db is hdmi-forum vendor specific data block
> or not.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Shashank Sh
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
> 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
Hi Jani,
On 07-02-2017 13:35, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>>> +{
>>> + u8 status;
>>> + int ret;
>>> +
>>> + ret = drm_scdc_r
Hi Shashank,
On 07-02-2017 16:19, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:44 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 06-02-2017 13:59, Shashank Sharma wrote:
>>> HDMI 2.0 spec mandates scrambli
Hi Shashank,
On 08-02-2017 12:59, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/8/2017 4:57 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 07-02-2017 16:09, Sharma, Shashank wrote:
>>> Thanks for the review Jose,
Hi Shashank,
On 07-02-2017 16:09, Sharma, Shashank wrote:
> Thanks for the review Jose, my comments inline.
>
>
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:24 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> Sorry for the late review.
>>
&
Hi Jani,
On 07-02-2017 15:09, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>> Hi Jani,
>>
>>
>> On 07-02-2017 13:35, Jani Nikula wrote:
>>> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>>>> +bool drm_scdc_check_scrambling_stat
Hi,
On 07-02-2017 16:36, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 2/7/2017 4:31 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>&g
Hi Nickey,
On 22-02-2017 07:45, Nickey Yang wrote:
> "I2C Master Interface Extended Read Mode" implements a segment
> pointer-based read operation using the Special Register configuration.
>
> This patch fix
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_709810
Hi Nickey,
On 22-02-2017 11:11, Nickey.Yang wrote:
> Read EDID func is drm_do_probe_ddc_edid(in
> drivers/gpu/drm/drm_edid.c Line:1215)
> when block = 3 means &msgs[3].addr = DDC_SEGMENT_ADDR(0x30)
> ,but in dw_hdmi_i2c_xfer
> line 299 msgs[i].addr != addr (0x50), it will printk
> "uns
Hi,
On 15-11-2016 10:52, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
>> On 11/15/2016 3:30 PM, Daniel Vetter wrote:
>>> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> On Mon, No
Hi Laurent,
On 28-11-2016 14:24, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 28 Nov 2016 12:09:59 Jose Abreu wrote:
>> On 28-11-2016 11:45, Laurent Pinchart wrote:
>>> On Monday 28 Nov 2016 19:34:59 Andy Yan wrote:
>>>> On 2016å¹´11æ26æ¥ 03:26, Lauren
Hi All,
On 28-11-2016 11:45, Laurent Pinchart wrote:
> Hi Andy,
>
> (CC'ing Kieran Bingham)
>
> On Monday 28 Nov 2016 19:34:59 Andy Yan wrote:
>> On 2016å¹´11æ26æ¥ 03:26, Laurent Pinchart wrote:
>>> On Friday 25 Nov 2016 17:08:13 Philipp Zabel wrote:
Am Freitag, den 25.11.2016, 17:45 +020
Hi Laurent,
On 28-11-2016 19:19, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 28 Nov 2016 15:25:18 Jose Abreu wrote:
>> On 28-11-2016 14:24, Laurent Pinchart wrote:
>>> On Monday 28 Nov 2016 12:09:59 Jose Abreu wrote:
>>>> On 28-11-2016 11:45, Laurent Pi
Hi Mark,
On 09-06-2017 12:04, Jose Abreu wrote:
> Currently HDMI 2.0 PHYs do not have a default configuration function.
>
> As these PHYs have the same register layout as the 3D PHYs we can
> safely use the default configuration function.
I may have been a little to fast arri
Hi Mark,
On 09-06-2017 05:03, Mark yao wrote:
> Ignore this patch, Jose has a better patch to solve rk3399 hdmi
> phy configure.
>
> Hi Jose
>
> Sorry for missing your patch about hdmi 2.0 vendor phy fixup:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9702229&
Hello,
On 09-06-2017 05:11, Archit Taneja wrote:
> Hi Philippe, Rob,
>
> On 06/08/2017 09:10 PM, Rob Herring wrote:
>> Seems strange there's not also a pixel or bit clock? Or this
>> gets driven
>> from the phy?
>
> Since you mention phy here, I wanted to share a concern with
> the bindings.
> Th
prefer the pdata provided configuration
function over the internal one.
This patch is based on today's drm-misc-next branch.
Signed-off-by: Jose Abreu
Cc: Kieran Bingham
Cc: Laurent Pinchart
Cc: Archit Taneja
Cc: Andrzej Hajda
Cc: Mark Yao
Cc: Carlos Palminha
---
drivers/gpu/drm/b
Hi Laurent,
Sorry for the late reply!
On 10-06-2017 09:50, Laurent Pinchart wrote:
> Hi Jose,
>
> On Friday 09 Jun 2017 13:53:12 Jose Abreu wrote:
>> On 09-06-2017 12:04, Jose Abreu wrote:
>>> Currently HDMI 2.0 PHYs do not have a default configuration function.
>&g
Hi Daniel, Alexey,
On 25-05-2017 15:19, Jose Abreu wrote:
> Now that we have a callback to check if crtc supports a given mode
> we can use it in arcpgu so that we restrict the number of probbed
> modes to the ones we can actually display.
>
> This is specially useful because
platforms.
This patch is based on today's drm-misc-next branch.
Signed-off-by: Jose Abreu
Tested-by: Mark Yao
Cc: Kieran Bingham
Cc: Laurent Pinchart
Cc: Archit Taneja
Cc: Andrzej Hajda
Cc: Mark Yao
Cc: Carlos Palminha
Cc: Heiko Stübner
Changes in v2:
- Rebased and refrased c
take that into an advantage and use it
to calculate how much deviation we can support.
This patch was based on today's drm-misc-next.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Daniel Vetter
Cc: Dave Airlie
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 7 ---
1
Hi Neil,
On 06-07-2017 11:33, Neil Armstrong wrote:
> From: Russell King
>
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
>
> Tested-by: Neil Armstrong
> Acked-by: Neil Armstrong
> Acked-by: Hans Verkuil
> Signed-off-by
Hi Archit,
On 23-06-2017 10:36, Jose Abreu wrote:
> Currently HDMI 2.0 PHYs do not have a default configuration function.
>
> As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D
> PHYs we can provide the same default configuration function for both
> and
Hi Laurent,
On 01-03-2017 11:09, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
>> On 05-01-2017 12:29, Laurent Pinchart wrote:
>>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
>>>> On 20-12-2016 11:45, Russell
oll loop
> to the power off function.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 65
> +++-
> 1 file changed, 37 insertions(+), 28 deletions(-)
&
n Bingham
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 --
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
> inc
Hi Laurent,
On 01-03-2017 22:39, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The DWC HDMI TX controller interfaces with a companion PHY. While
> Synopsys provides multiple standard PHYs, SoC vendors can also integrate
> a custom PHY.
>
> Modularize PHY configuration to support vendor PHYs
Hi Laurent,
On 01-03-2017 22:39, Laurent Pinchart wrote:
> The color space converter isn't part of the PHY, move its configuration
> out of PHY code.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/dr
Hi Laurent,
On 02-03-2017 13:41, Laurent Pinchart wrote:
>
>> Hmm, this is kind of confusing. Why do you need a phy_ops and
>> then a separate configure_phy function? Can't we just use phy_ops
>> always? If its external phy then it would need to implement all
>> phy_ops functions.
> The phy_ops a
Hi Laurent,
On 01-03-2017 22:39, Laurent Pinchart wrote:
> Most of the hdmi_phy_test_*() functions are unused. Remove them.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge
l delay. Retrying the read
> five times with a 1ms to 2ms delay between each attempt should thus be
> more than enough.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 52
>
be provided by the platform glue layer. The existing
> PHY handling code (limited to Synopsys PHY support) is refactored into a
> set of default PHY operations that are used automatically when the
> platform glue doesn't provide its own operations.
>
> Signed-off-by: Laurent Pi
Suggested-by: Jose Abreu
> Signed-off-by: Laurent Pinchart
Thanks a lot!
There are typo errors (which were there before, I just noticed
them now), please see bellow.
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/Kconfig
Hi Neil,
On 03-03-2017 16:42, Neil Armstrong wrote:
>
> Sure, I was meaning the *input* format the controller receives from the
> pixel encoder, I'm quite sure the format is strict.
>
Hmm, not quite following you here. As far as the controller goes
it supports the formats I mentioned:
-8
Hi Neil,
On 03-03-2017 11:31, Neil Armstrong wrote:
>
> Sure, but I was struggling about finding an equivalence.
>
> How should I replace these ?
>
> DW_HDMI_ENC_FMT_RGB
> DW_HDMI_ENC_FMT_YCBCR444
> DW_HDMI_ENC_FMT_YCBCR422_16BITS
> DW_HDMI_ENC_FMT_YCBCR422_8BITS
> DW_HDMI_ENC_FMT_XVYCC444
>
> I
1/40 ratios
> - Remove leftovers from old patchset
>
> Signed-off-by: Shashank Sharma
> Reviewed-by: Thierry Reding
Maybe drm_scdc_set_scrambling() and
drm_scdc_set_high_tmds_clock_ratio() should return int error code
instead of bool, but anyway:
Reviewed-by: Jose Abreu
Hi Laurent,
On 02-03-2017 15:38, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
>> On 02-03-2017 13:41, Laurent Pinchart wrote:
>>>> Hmm, this is kind of confusing. Why do you need a phy_ops and
>>>> then a separat
Hi Neil,
On 03-03-2017 09:07, Neil Armstrong wrote:
>
> The problem is that the HPD/RxSense is tied to this phy_mask and glued into
> the
> dw-hdmi driver.
>
> The *real* solution would be to completely separate the HPD/RxSense irq
> handling to
> a separate driver as a shared irq...
>
> If Jos
Hi Alexey,
On 03-03-2017 13:27, Alexey Brodkin wrote:
>
> So if I understood you correct here what I really need is just to get rid of
> existing check,
> right? I.e. the following is to be in v2 respin:
> --->8---
> diff --git a/drivers/gp
function drm_parse_hf_vsdb so that all
>of HF-VSDB parsing can be kept in same function, in incremental
>patches.
>
> V3: Rebase.
> V4: Rebase.
> V5: Rebase.
> V6: Rebase.
>
> Signed-off-by: Shashank Sharma
> Reviewed-by: Thierry Reding
Reviewed-by: Jose Abre
Hi Neil,
On 06-03-2017 10:41, Neil Armstrong wrote:
> On 03/03/2017 06:22 PM, Jose Abreu wrote:
>> Hi Neil,
>>
>>
>> On 03-03-2017 16:42, Neil Armstrong wrote:
>>> Sure, I was meaning the *input* format the controller receives from the
>>> pixel
Hi Alexey,
On 03-03-2017 19:24, Alexey Brodkin wrote:
>
> Correct. Otherwise we'll get some modes and devices that
> don't work.
>
> Remember our saga with 74.25 vs 74.40 MHz?
>
> With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock
> which satisfy some monitors especially those w
Hi Neil,
On 07-03-2017 16:42, Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if provided.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |
gned-off-by: Neil Armstrong
Looks nice!
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135
> ++
> include/drm/bridge/dw_hdmi.h | 5 ++
> 2 files changed, 86 insertions(+), 54 deleti
Hi Neil,
On 07-03-2017 16:42, Neil Armstrong wrote:
> From: Laurent Pinchart
>
> In preparation for adding PHY operations to handle RX SENSE and HPD,
> group all the PHY interrupt setup code in a single location and extract
> it to a separate function.
>
> Signed-off-by: Laurent Pinchart
> Sign
Hi Romain,
On 08-03-2017 08:15, Romain Perier wrote:
> Currently, the irq handler that monitores changes for HPD anx RX_SENSE
> relies on the status of the bridge for updating the status of the HPD.
> The update is done only when the bridge is enabled.
>
> However, on Rockchip platforms we have f
Hi Neil,
On 08-03-2017 12:12, Neil Armstrong wrote:
>
> Hi Jose,
>
> It seems here that we only have the RGB444<->YUV444 8bit tables, from the
> Amlogic
> source I have the following for 10bit, 12bit and 16bit for itu601 :
>
> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
> { 0x
Hi Neil,
On 09-03-2017 14:27, Jose Abreu wrote:
> Hi Neil,
>
>
> On 08-03-2017 12:12, Neil Armstrong wrote:
>> Hi Jose,
>>
>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the
>> Amlogic
>> source I have the following for
Hi,
On 13-03-2017 09:36, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
>> On 03/10/2017 10:35 AM, Romain Perier wrote:
>>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
>>> step E. and is kept enabled for later use. This
Hi Russell,
On 13-03-2017 13:10, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 12:55:58PM +0000, Jose Abreu wrote:
>> Hi,
>>
>>
>> On 13-03-2017 09:36, Russell King - ARM Linux wrote:
>>> On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstron
ort "I2C Master Interface
> Extended Read Mode" to read data addressed by non-zero segment
> pointer, this means that if EDID has more than 1 extension blocks"
>
> With this patch,dw-hdmi can read EDID data with 1/2/4 blocks.
>
> Signed-off-by: Nickey Yang
Hi Nickey,
On 20-03-2017 11:39, Nickey Yang wrote:
> Vendor specific infoframe is mandatory for 4K2K resolution.
> Without this, the HDMI protocol compliance fails.
>
> Signed-off-by: Nickey Yang
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers
Hi Nickey,
On 20-03-2017 06:10, Nickey Yang wrote:
> Vendor specific infoframe is mandatory for 4K2K resolution.
> Without this, the HDMI protocol compliance fails.
>
> Signed-off-by: Nickey Yang
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 50
>
> driver
Perform sanity checks so that HDMI 2.0+ modes are not exported to
drivers or userspace unless asked to.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c| 2 ++
drivers/gpu/drm/drm_probe_helper.c | 9 -
include
-by: Laurent Pinchart
> Signed-off-by: Neil Armstrong
Reviewed-by: Jose Abreu
Maybe if you submit a next version we could get rid of
"dw_hdmi_fb_registered" totally and move the remaining setup code
to a new "dw_hdmi_setup_i2c" function.
Best regards,
Jose Miguel Abreu
> -
This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 258
test this on your platform which has
non RGB in input and the CSC worked correctly, right?
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326
> +-
> include/drm/bridge/dw_hdmi.h |
Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
flag which will signal userspace that this is a HDMI 2.0+ mode. It
is expected that these new flags will not be exported to userspace
unless client asks to.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: dri-devel
We can't expect userspace to have full support for all HDMI 2.0+
features. Instead of expecting/waiting for userspace to support
the new features add a knob, much like the stereo knob, so that
DRM core will only expose the features when asked too.
Signed-off-by: Jose Abreu
Cc: Carlos Pal
++ Daniel
++ Ville
++ Shashank
On 22-03-2017 17:35, Jose Abreu wrote:
> Hi all,
>
> This is a RFC series that aims to collect comments regarding the handling
> of HDMI 2.0+ video modes and features in the DRM core.
>
> Some of the HDMI 2.0 features are already implement
1 - 100 of 315 matches
Mail list logo
