Re: [PATCH v2 1/6] drm: Add SCDC helpers

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. >> &

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

Hi Jani, On 07-02-2017 15:09, Jani Nikula wrote: > On Tue, 07 Feb 2017, Jose Abreu <jose.ab...@synopsys.com> wrote: >> Hi Jani, >> >> >> On 07-02-2017 13:35, Jani Nikula wrote: >>> On Tue, 07 Feb 2017, Jose Abreu <jose.ab...@synopsys.com> wro

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

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

Re: [PATCH v2 1/6] drm: Add SCDC helpers

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,

Re: [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

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

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

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

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

Hi Jani, On 07-02-2017 13:35, Jani Nikula wrote: > On Tue, 07 Feb 2017, Jose Abreu <jose.ab...@synopsys.com> wrote: >>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter) >>> +{ >>> + u8 status; >>> + int ret; >>> + >&

Re: [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

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

Re: [PATCH v2 2/6] drm/edid: check for HF-VSDB block

ed...@nvidia.com> > Signed-off-by: Shashank Sharma <shashank.sha...@intel.com> Reviewed-by: Jose Abreu <joab...@synopsys.com> Best regards, Jose Miguel Abreu > --- > drivers/gpu/drm/drm_edid.c | 15 +++ > include/linux/hdmi.h | 1 + > 2 file

Re: [PATCH v2 1/6] drm: Add SCDC helpers

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

Re: [PATCH] drm: bridge: dw-hdmi: support i2c extended read mode

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 [3].addr = DDC_SEGMENT_ADDR(0x30) > ,but in dw_hdmi_i2c_xfer > line 299 msgs[i].addr != addr (0x50), it will printk >

Re: [PATCH] drm: bridge: dw-hdmi: support i2c extended read mode

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 >

Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data

Hi Neil, On 17-01-2017 12:31, 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 > --- >

Re: [RFC/RFT PATCH 3/4] drm/bridge: dw-hdmi: Enable CSC even for DVI

.@baylibre.com> I was going to say that you should make sure the output colorspace is RGB or else DVI will fail to work, but I just noticed the output colorspace is fixed in the code to RGB. Though, that may change in the future. Reviewed-by: Jose Abreu <joab...@synopsys.com> Best

Re: [RFC/RFT PATCH 2/4] drm/bridge: dw-hdmi: Add support for custom PHY handling

Hi Neil, On 17-01-2017 12:31, Neil Armstrong wrote: > @@ -1434,9 +1434,18 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct > drm_display_mode *mode) > hdmi_av_composer(hdmi, mode); > > /* HDMI Initializateion Step B.2 */ > - ret = dw_hdmi_phy_init(hdmi); > - if

[PATCH] drm: Complete CEA modedb(VIC 1-107)

; +3840, 4016, 4104, 4400, 0, > +2160, 2168, 2178, 2250, 0, > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), > + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27}, 4016 should be instead 4896. 4104 should be instead 4984. 44

[PATCH v3 0/4]: Picture aspect ratio support in DRM layer

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

[RFC v2] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

. The reason this is still a RFC is because there is no reference in kernel for this new sampling mode (specially in AVI infoframe part), so, I was hoping to hear some feedback first. Tested in a HDMI 2.0 compliance scenario. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Daniel Vetter Cc: Jani

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Daniel, On 04-01-2017 08:34, Daniel Vetter wrote: > On Fri, Dec 30, 2016 at 04:53:16PM +0000, Jose Abreu wrote: >> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0. >> According to the spec the EDID may contain two blocks that >> signal this sampling mode:

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, On 04-01-2017 13:22, Ville Syrjälä wrote: > On Fri, Dec 30, 2016 at 04:53:16PM +0000, Jose Abreu wrote: >> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0. >> According to the spec the EDID may contain two blocks that >> signal this sampling mode:

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, On 04-01-2017 16:36, Ville Syrjälä wrote: > On Wed, Jan 04, 2017 at 04:15:01PM +0000, Jose Abreu wrote: >> [snip] >>> Why does userspace need to know this? My thinking has been that the >>> driver would do the right thing automagically. >>&g

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

Hi Laurent, On 05-01-2017 12:29, Laurent Pinchart wrote: > Hi Jose, > > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote: >> On 20-12-2016 11:45, Russell King - ARM Linux wrote: >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote: >>>> Instea

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

Hi Laurent, On 05-01-2017 00:15, Laurent Pinchart wrote: > Hi Jose, > > On Tuesday 20 Dec 2016 15:01:52 Jose Abreu wrote: >> On 20-12-2016 13:11, Laurent Pinchart wrote: >>> On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote: >>>> On 20-12-2016 01:33, Laurent

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

Hi Laurent, On 05-01-2017 11:44, Laurent Pinchart wrote: [snip] >>> I've tried moving SVSRET right before the reset and everything still seems >>> to work fine, so I'll submit a patch. >>> >>> Is the rest of the sequence correct ? When should SVSRET be deasserted >>> (the driver currently

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, On 05-01-2017 11:46, Ville Syrjälä wrote: > On Thu, Jan 05, 2017 at 10:07:45AM +0000, Jose Abreu wrote: >> Hi Ville, >> >> >> On 04-01-2017 16:36, Ville Syrjälä wrote: >>> On Wed, Jan 04, 2017 at 04:15:01PM +, Jose Abreu wrote: >>

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

Hi Laurent, Sorry for the delayed answer but I am quite busy at the moment. On 06-01-2017 01:48, Laurent Pinchart wrote: [snip] The TX_READY signal is documented in the i.MX6 datasheet as being a PHY output signal, but there seems to be no HDMI TX register from which its state

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Shashank, Thanks for the review. On 09-01-2017 05:22, Sharma, Shashank wrote: > Regards > > Shashank > > > On 12/30/2016 10:23 PM, Jose Abreu wrote: >> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0. >> According to the spec the EDID may con

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Shashank, On 09-01-2017 12:45, Sharma, Shashank wrote: > Regards > > Shashank > > > On 1/9/2017 4:41 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> Thanks for the review. >> >> >> On 09-01-2017 05:22, Sharma, Shashank wrote: >

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, On 10-01-2017 11:16, Ville Syrjälä wrote: > On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote: >> [snip] >> The pixel clock rate is half of the TMDS character rate in 4:2:0 >> (in 24 bit), but for example in deep color 48 bit it will be the >&g

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, [snip] >> Are you going to update all the userspace clients? Exposing HDMI 2.0 >> modes only for your favorite client doesn't sound like a good plan to >> me. >> >> If we simply compute from a specific modeline whether it needs to be >> transmitted as 4:2:0, I suppose we could simply

Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

Hi Ville, Sorry for the late reply. On 11-01-2017 11:36, Ville Syrjälä wrote: > On Wed, Jan 11, 2017 at 10:27:03AM +0000, Jose Abreu wrote: >> Hi Ville, >> >> >> On 10-01-2017 17:21, Ville Syrjälä wrote: >> >> [snip] >> >>>> Bu

Re: [PATCH 0/3] dw-hdmi: miscellaneous cleanups and fixes

nclude these 3 patches if they can be acked soon enough. > > Laurent Pinchart (3): > drm: bridge: dw-hdmi: Define and use macros for PHY register addresses > drm: bridge: dw-hdmi: Fix the name of the PHY reset macros > drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY

Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data

Hi Laurent, On 18-01-2017 20:49, Laurent Pinchart wrote: > > Ideally the bridge mode set operation should be extended to take format and > colorspace information (or another bridge operation should be created for > that > purpose, I'm still undecided). As that's quite a big change, I'm fine

Re: [RFC/RFT PATCH 2/4] drm/bridge: dw-hdmi: Add support for custom PHY handling

Hi Neil, On 18-01-2017 11:20, Neil Armstrong wrote: > > It's the idea we discussed with Laurent. > Keeping the Synopsys PHY code inside the dw-hdmi driver would be simpler. > > But don't you think adding a proper "ops" structure apart from the plat_data > should be necessary ? > > Neil > An

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

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

[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

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

[PATCH 0/4]: Picture aspect ratio support in DRM layer

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

[PATCH 0/3 v3] drm: bridge/dw-hdmi: Fixes for dw-hdmi and DWC support

Cc: Thierry Reding Cc: dri-devel 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/d

[PATCH 1/3 v3] drm: bridge/dw-hdmi: Add support for DWC Phy

and validated. This is specific to Synopsys Phy. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Archit Taneja Cc: David Airlie Cc: Russell King <rmk+kernel at arm.linux.org.uk> Cc: Fabio Estevam Cc: Daniel Vetter Cc: Takashi Iwai Cc: Vladimir Zapolskiy Cc: Thierry Reding Cc: dri

[PATCH 2/3 v3] drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets

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

[PATCH 0/4]: Picture aspect ratio support in DRM layer

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 expected. Best regards, Jose Miguel

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

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

[PATCH 0/4]: Picture aspect ratio support in DRM layer

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 before and

[PATCH 2/3 v3] drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets

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

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

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

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

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 i

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

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

HDMI 2.0 Support

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

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

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

[Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

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

[PATCH] drm: edid: HDMI 2.0 HF-VSDB block parsing

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: Carlos Palminha Cc

[PATCH] drm: edid: HDMI 2.0 HF-VSDB block parsing

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 information about >&g

drm/bridge: dw_hdmi: Colorspace registers

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 corre

drm/bridge: dw_hdmi: Colorspace registers

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

[PATCH] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

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 <rmk+kernel at arm.linux.org.uk> Cc:

[PATCH v2 0/4] Picture aspect ratio support in DRM layer

arma (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 I als

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

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,

Question regarding clocks in the DW-HDMI DT bindings

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

Question regarding clocks in the DW-HDMI DT bindings

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

Question regarding clocks in the DW-HDMI DT bindings

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

[PATCH] drm: bridge/dw-hdmi: Add support for DWC Phy

This patch adds support for the Synopsys HDMI TX Phy in bridge dw-hdmi. The init flow is the same as the Rockchip Phy so we only need to add one define and one if statement. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel

DRM DMA Engine

Hi Daniel, On 30-05-2016 10:36, Daniel Vetter wrote: > On Mon, May 30, 2016 at 10:00:56AM +0100, Jose Abreu wrote: >> ++ Daniel >> >> >> On 30-05-2016 09:44, Jose Abreu wrote: >>> Hi Daniel, >>> >>> Thanks for your answer. >>> &g

DRM DMA Engine

Hi Daniel, On 15-06-2016 09:52, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu > wrote: >>> I assume that xilinx VDMA is the only way to feed pixel data into your >>> display pipeline. Under that assumption: >>> >>> drm_plane sh

DRM DMA Engine

Hi Daniel, Sorry to bother you again. I promise this is the last time :) On 15-06-2016 11:15, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu > wrote: >> On 15-06-2016 09:52, Daniel Vetter wrote: >>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu >

DRM DMA Engine

Hi Ilia, Thanks for your answer. On 16-06-2016 13:39, Ilia Mirkin wrote: > On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu > wrote: >> Hi Daniel, >> >> Sorry to bother you again. I promise this is the last time :) >> >> On 15-06-2016 11:15, Daniel Vetter wrote:

[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

Hi, On 24-06-2016 03:40, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Current dw-hdmi is supporting sound via AHB bus, but it has > I2S audio feature too. This patch adds I2S audio support to dw-hdmi. > This HDMI I2S is supported by using ALSA SoC common HDMI encoder > driver. > >

[PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

On 29-08-2016 10:21, Russell King - ARM Linux wrote: > On Mon, Aug 29, 2016 at 10:17:04AM +0100, Jose Abreu wrote: >> Colorspace and scan information values were being written in wrong >> offsets. This patch corrects this and writes the values at the >> offsets spec

[PATCH 00/22] R-Car Gen3 HDMI output support

pu/drm/rcar-du/rcar_du_regs.h | 23 ++ > drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 105 ++ > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 17 +- > include/drm/bridge/dw_hdmi.h | 35 +- > 21 files changed, 765 insertions(+), 295 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt > create mode 100644 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c > Patches 01 to 13 are: Reviewed-by: Jose Abreu I have one minor comment for patch 12. Best regards, Jose Miguel Abreu

[PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration

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

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Laurent, On 02-12-2016 15:43, Laurent Pinchart wrote: > 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

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Thierry, Do you think while you are at it you could implement a set_scrambling() callback? It should be pretty straight forward: you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it again. I think this is an important feature that we should have. Best regards, Jose Miguel

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Thierry, On 05-12-2016 11:14, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 11:06:15AM +0000, Jose Abreu wrote: >> Hi Thierry, >> >> >> Do you think while you are at it you could implement a >> set_scrambling() callback? It should be pretty straight forward:

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Laurent, On 05-12-2016 11:32, Laurent Pinchart wrote: > Hi Jose, > > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: >> On 02-12-2016 15:43, Laurent Pinchart wrote: >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: >>>> On Fri, Dec 0

[PATCH v2 1/3] drm: Add SCDC helpers

Hi Thierry, On 02-12-2016 19:24, Thierry Reding 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 the > symbolic names for the

[PATCH v2 1/3] drm: Add SCDC helpers

Hi, On 05-12-2016 13:31, Ville Syrjälä wrote: > On Mon, Dec 05, 2016 at 12:16:52PM +0100, Thierry Reding wrote: >> On Mon, Dec 05, 2016 at 10:12:39AM +0000, Jose Abreu wrote: >>> On 02-12-2016 19:24, Thierry Reding wrote: >> [...] >>>> +/** >>>

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Daniel, On 06-12-2016 08:23, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 05:37:22PM +0100, Thierry Reding wrote: >> On Mon, Dec 05, 2016 at 02:19:48PM +0000, Jose Abreu wrote: >>> Hi Thierry, >>> >>> >>> On 05-12-2016 11:14, Thierry Reding w

[PATCH 4/4 RESEND] ARC: axs10x: Update defconfigs so that I2S is enabled

The defconfigs for the AXS boards were updated to enable Designware I2S driver. Signed-off-by: Jose Abreu --- arch/arc/configs/axs101_defconfig | 1 + arch/arc/configs/axs103_defconfig | 1 + arch/arc/configs/axs103_smp_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git

[PATCH 0/4 RESEND] Add I2S/ADV7511 audio support for ARC AXS10x boards

ARC AXS10x platforms consist of a mainboard with several peripherals. One of those peripherals is an HDMI output port controlled by ADV7511 transmitter. This patch set adds audio for the ADV7511 transmitter and I2S audio for the AXS10x platform. Jose Abreu (4): [adv7511] Add audio support

[PATCH 2/4 RESEND] ARC: axs10x: Update defconfigs so that audio is enabled

The defconfigs for the AXS boards were updated so that ALSA SoC is enabled and also the audio for the ADV7511 HDMI transmitter. Signed-off-by: Jose Abreu --- arch/arc/configs/axs101_defconfig | 3 +++ arch/arc/configs/axs103_defconfig | 5 + arch/arc/configs/axs103_smp_defconfig | 5

[PATCH 3/4 RESEND] ASoC: dwc: Add I2S HDMI audio support using custom platform driver

HDMI audio support was added to the AXS board using an I2S cpu driver and a custom platform driver. The platform driver supports two channels @ 16 bits with rates 32k, 44.1k and 48k. ALSA Simple audio card is used to glue the cpu, platform and codec driver (adv7511). Signed-off-by: Jose Abreu

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

Hi Mark, On 29-03-2016 19:22, Mark Brown wrote: > On Tue, Mar 29, 2016 at 07:03:01PM +0100, Jose Abreu wrote: > >> The major part of this patch is the adding of an ALSA platform driver so that >> audio comes out of the box in AXS boards but we also added functionalities to

[PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

Hi Archit, On 29-03-2016 18:03, Archit Taneja wrote: > > > On 3/29/2016 4:22 PM, Jose Abreu wrote: >> Hi Archit, >> >> On 29-03-2016 09:05, Archit Taneja wrote: >>> Hi, >>> >>> On 03/28/2016 08:06 PM, Jose Abreu wrote: >>>&

DRM DMA Engine

Hi all, Currently I am trying to develop a DRM driver that will use Xilinx VDMA to transfer video data to a HDMI TX Phy and I am facing a difficulty regarding the understanding of the DRM DMA Engine. I looked at several sources and at the DRM core source but the flow of creating and interfacing

DRM DMA Engine

Hi all, Currently I am trying to develop a DRM driver that will use Xilinx VDMA to transfer video data to a HDMI TX Phy and I am facing a difficulty regarding the understanding of the DRM DMA Engine. I looked at several sources and at the DRM core source but the flow of creating and interfacing

DRM DMA Engine

Hi Daniel, Thanks for your answer. On 26-05-2016 09:06, Daniel Vetter wrote: > On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: >> Hi all, >> >> Currently I am trying to develop a DRM driver that will use >> Xilinx VDMA to transfer video data to a HDM

DRM DMA Engine

++ Daniel On 30-05-2016 09:44, Jose Abreu wrote: > Hi Daniel, > > Thanks for your answer. > > On 26-05-2016 09:06, Daniel Vetter wrote: >> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: >>> Hi all, >>> >>> Currently I am trying to de

[PATCH v2 2/2] drm: parse hf-vsdb

ros of 36 and 30-bit depths > - Added a sub-class for HDMI related information within drm_display_info > (Thierry, Daniel) and populated it with HF-VSDB specific info. > > Cc: Thierry Reding > Cc: Daniel Vetter > Cc: Jose Abreu > Signed-off-by: Shashank Sharma > --- > dri

[PATCH v2 14/29] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register

t.pinchart+renesas at ideasonboard.com> Reviewed-by: Jose Abreu Best regards, Jose Miguel Abreu > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++--- > drivers/gpu/drm/bridge/dw-hdmi.h | 4 > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/dr

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

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 >

[PATCH v2 1/2] drm: Create new structure for HDMI info

rrect values in this structure. > We are adding parsing of HF-VSDB In the next patch. > > Cc: Thierry Reding > Cc: Daniel Vetter > Cc: Jose Abreu > Suggested-by: Thierry Reding > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/drm_edid.c | 6 +

[PATCH v2 15/29] drm: bridge: dw-hdmi: Handle overflow workaround based on device version

pinchart+renesas at ideasonboard.com> Reviewed-by: Jose Abreu Best regards, Jose Miguel Abreu > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 46 > > 1 file changed, 33 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/bridg

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

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

[PATCH v2 13/29] drm: bridge: dw-hdmi: Reject invalid product IDs

w register values. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com> Reviewed-by: Jose Abreu > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 25 +++-- > drivers/gpu/drm/bridge/dw-hdmi.h | 8 > 2 files changed, 27 ins

[PATCH v2 16/29] drm: bridge: dw-hdmi: Detect PHY type at runtime

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. >&g

[PATCH v2 12/29] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET

name the bit accordingly. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com> Reviewed-by: Jose Abreu > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 8 > drivers/gpu/drm/bridge/dw-hdmi.h | 4 ++-- > 2 files changed, 6 insertions(+),

[PATCH v3 2/3] drm: parse hf-vsdb

- Fix the bit nos for YUV420 deep color macros > - write HDMI_IEEE_OUI_HFVSDB value in lower case > > Cc: Thierry Reding > Cc: Daniel Vetter > Cc: Jose Abreu > Signed-off-by: Shashank Sharma Looks good by me. I don't have the setup to test it right now,

[PATCH v3 1/3] drm: Create new structure for HDMI info

Hi Shashank, On 21-12-2016 15:29, Shashank Sharma wrote: [snip] > + > + /** > + * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding. > + * various sinks can support 10/12/16 bit per channel deep > + * color encoding. edid_yuv420_dc_modes = 0 means sink doesn't > +

[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

. The reason this is still a RFC is because there is no reference in kernel for this new sampling mode (specially in AVI infoframe part), so, I was hoping to hear some feedback first. Tested in a HDMI 2.0 compliance scenario. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Daniel Vetter Cc: Jani

[PATCH v3 3/3] drm: clean cached display info

te, avoiding any errors due to invalid cached data. > > Cc: Jose Abreu > > Suggested-by: Jose Abreu > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/drm_probe_helper.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/g

[PATCH] drm: clean cached display info

s-qhY=wGqvHYK00VvbUVGun4-ZhK6KZ4Ht_lHwPGfC6ajlzxE=7YpJD-fwUixHNz9SNn2B1ijuL5mEVeEUmolbf3NqWcs= > > (still under review) and sending as individual patch. > > Cc: Jose Abreu > Cc: Daniel Vetter > > Suggested-by: Jose Abreu > Signed-off-by: Shashank Sharma > --- Reviewed-by: Jose

  1   2   3   4   >