It will include 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 rese
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
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
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 7 +-
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
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/bridge/dw
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 (ret
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 if
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 "ops
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
>
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:
>>>&
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 wi
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 wi
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 HDMI
++ 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
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 a
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
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
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
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
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
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
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
>
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:
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.
>
> Sign
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
drivers/gpu/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
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 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 driver declares a dev_type to distinguish pl
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 Abreu
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:
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
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 va
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:
>> [...]
>>>> +/**
>>>&g
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
r macros 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
> ---
>
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
> interface for control. The correct way to identify AHB audio DMA support
> is through bit 1 in CONFIG3_ID.
>
> Signed-off-by: Laurent Pinchart
Reviewed
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.
correct 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
rsion easier.
>
> Among the supported platforms only i.MX6DL and i.MX6Q have been
> identified as needing the workaround. Disabling it on Rockchip RK3288
> (which integrates a v2.00a controller) didn't produce any error or
> artifact.
>
> Signed-off-by: Laurent Pinchart
Review
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
e instead of raw register values.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 25 +++--
> drivers/gpu/drm/bridge/dw-hdmi.h | 8
> 2 files changed, 27 insertions(+), 6 deletions(-)
>
>
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
name the bit accordingly.
>
> Signed-off-by: Laurent Pinchart
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(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm
t; - 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
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
> +
#x27;able.
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 V
to-date, 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/driv
y6TPsyCl9uN7Wsis-qhY&m=wGqvHYK00VvbUVGun4-ZhK6KZ4Ht_lHwPGfC6ajlzxE&s=7YpJD-fwUixHNz9SNn2B1ijuL5mEVeEUmolbf3NqWcs&e=
>
> (still under review) and sending as individual patch.
>
> Cc: Jose Abreu
> Cc: Daniel Vetter
>
> Suggested-by: Jose Abreu
> Signed-off-by: Shas
Hi Shashank,
On 29-12-2016 05:53, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 12/27/2016 3:07 PM, Daniel Vetter wrote:
>> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> On 21-12-201
Hi Shashank,
On 21-12-2016 03:49, Sharma, Shashank wrote:
> Thanks for the review Jose.
>
> My comments, inline.
>
> Regards
> Shashank
> On 12/20/2016 7:49 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 20-12-2016 13:47, Shashank Sharma
Hi all,
I am an employee at Synopsys and as part of our IP Prototyping Kits we are
adding audio support to the ADV7511 HDMI transmitter. Our work is based on the
Analog Devices kernel tree available at:
https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.
Hi Laurent,
Thanks for your reply. The video stream must be inited to the transmittion of
audio (the HDMI mode must be enabled) so it is not possible to transmit audio
over HDMI without a video stream.
I will keep audio and video in a single driver and add a Kconfig option to the
audio support
Hi Laurent,
On 01-04-2016 18:10, Laurent Pinchart wrote:
> Hi Jose,
>
> Thank you for the patch.
>
> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was por
ine
* Dropped IRQ handler for I2S
Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)
Jose Abreu (3):
drm/i2c/adv7511: Rename and move to separate folder
drm/i2c/adv7511: Add audio support
ASo
alogdevicesinc/linux/
The audio can be disabled using menu-config so it is possible
to use only video mode. The audio (when enabled) registers as
a codec into ALSA.
SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.
Signed-off-by: Jose Abreu
---
.../bindings/display/br
Hi Laurent,
On 04-04-2016 22:41, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
>> On 01-04-2016 18:10, Laurent Pinchart wrote:
>>> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>>>> This patch adds audio supp
adding of audio
support.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v3.
drivers/gpu/drm/i2c/Kconfig| 6 +---
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig| 6
drivers/gpu/drm/i2c
There is no need to unmask all interrupts at I2S start. This
can cause performance issues in slower platforms.
Unmask only the interrupts for the used channels.
Signed-off-by: Jose Abreu
---
Changes v2 -> v3:
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler
gested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)
NOTE:
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.
Jose
adding of audio
support.
Signed-off-by: Jose Abreu
---
No changes v3 -> v4.
This patch was only introduced in v3.
drivers/gpu/drm/i2c/Kconfig| 6 +---
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/adv7511/Kconfig|
necessary to add this custom platform driver so that
HDMI audio works in AXS boards.
The selection between the use of DMA engine or custom
PCM can be made using a device tree boolean parameter
which was introduced in this patch ('snps,use-dmaengine').
Signed-off-by: Jose Abreu
---
This patch updates documentation for the Designware I2S
driver.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v4.
Documentation/devicetree/bindings/sound/designware-i2s.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound
This patch makes Designware I2S driver use the fifo
depth value to program the fifo configuration register
instead of using hardcoded values.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v4.
sound/soc/dwc/designware_i2s.c | 9 +++--
1 file changed, 7 insertions(+), 2
alogdevicesinc/linux/
The audio can be disabled using menu-config and/or device tree
so it is possible to use only video mode. The audio
(when enabled) registers as a codec into ALSA.
SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.
Signed-off-by: Jose Abreu
---
Hi Mark,
On 07-04-2016 18:53, Mark Brown wrote:
> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>
>> + Optional properties:
>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
>> + it is required to use the properties 'dma
Hi Lars,
On 08-04-2016 16:46, Lars-Peter Clausen wrote:
> On 04/07/2016 06:53 PM, Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
>> commit 177
Hi Lars,
On 08-04-2016 16:52, Lars-Peter Clausen wrote:
> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>> Hi Mark,
>>
>>
>> On 07-04-2016 18:53, Mark Brown wrote:
>>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>>>
>>>> + Opt
Hi Lars,
On 09-04-2016 16:02, Lars-Peter Clausen wrote:
> On 04/08/2016 06:12 PM, Jose Abreu wrote:
> [...]
>>> [...]
>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec
>>>> interface
>>>> + into ALSA SoC.
>>>
Hi Lars,
On 09-04-2016 15:55, Lars-Peter Clausen wrote:
> On 04/08/2016 06:08 PM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 08-04-2016 16:52, Lars-Peter Clausen wrote:
>>> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>>>> Hi Mark,
>>>>
&
Hi Lars,
On 11-04-2016 10:33, Lars-Peter Clausen wrote:
> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 09-04-2016 16:02, Lars-Peter Clausen wrote:
>>> On 04/08/2016 06:12 PM, Jose Abreu wrote:
>>> [...]
>>>>> [...
Hi Lars,
On 11-04-2016 13:23, Lars-Peter Clausen wrote:
> On 04/11/2016 01:32 PM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 11-04-2016 10:33, Lars-Peter Clausen wrote:
>>> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>>>> Hi Lars,
>>>
Hi Alexey, Daniel,
On 05-04-2018 10:32, Daniel Vetter wrote:
> On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin
> wrote:
>> Hi Daniel,
>>
>> On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
>>> On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
>>> wrote:
Hello,
We're trying to
Hi Jernej,
On 20-09-2017 21:01, Jernej Skrabec wrote:
> [added media mailing list due to CEC question]
>
> This patch series adds a HDMI glue driver for Allwinner H3 SoC. For now, only
> video and CEC functionality is supported. Audio needs more tweaks.
>
> Series is based on the H3 DE2 patch seri
Now that ARC properly supports DMA mmapping we can use the
standard CMA helper to map dumb buffers. This makes ARC PGU
works with standard DRM consumer applications like, for
example, mpv via DRM.
This fixes the use of dumb buffers.
Signed-off-by: Jose Abreu
Fixes: 0c4250e7b15e ("drm
deviation. Lets take that into an advantage and use it to
calculate how much deviation we can support.
Signed-off-by: Jose Abreu
Acked-by: Alexey Brodkin
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Daniel Vetter
Cc: Dave Airlie
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 7 ---
1 file changed, 4
.
Signed-off-by: Jose Abreu
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Daniel Vetter
Cc: Dave Airlie
---
drivers/gpu/drm/arc/arcpgu_drv.c | 24 +---
1 file changed, 1 insertion(+), 23 deletion
Hi Daniel, all,
So, I was playing around with arcpgu and I found a bug at module
unloading. I corrected it and tested (using a 4.12 kernel) and I
got a nice WARNING from DRM core at unloading (instead of the old
NULL pointer I got :D). I debugged it and found out that an empty
modesetting (i.e. a
Hi all,
Two fixes and an improvement for arcpgu. I've sent this patches in separate
but I've now collected them all to ease the review.
Best regards,
Jose Miguel Abreu
Jose Abreu (3):
drm: arcpgu: Fix mmap() callback
drm: arcpgu: Fix module unload
drm: arcpgu: Allow some clock
At module unload we are expecting a struct drm_device but at
probing we are not setting it right. Fix this and correct the
arcpgu module unload.
Signed-off-by: Jose Abreu
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha
Cc: Alexey Brodkin
t;
> This patch uses the new mode_valid callback (many thanks to
> Jose Abreu for upstreaming it!) to ensure we don't select
> modes we cannot generate.
>
> NOTE: Stylistically I suspect there are better ways to do what
> I'm trying to do here. The encoder -> crtc bit is
On 18-07-2017 17:56, John Stultz wrote:
> On Tue, Jul 18, 2017 at 4:10 AM, Jose Abreu wrote:
>> Hi John,
>>
>>
>> On 18-07-2017 05:22, John Stultz wrote:
>>> Currently the hikey dsi logic cannot generate accurate byte
>>> clocks values for all pi
t;
> This patch uses the new mode_valid callback (many thanks to
> Jose Abreu for upstreaming it!) to ensure we don't select
> modes we cannot generate.
>
> Also, since the ade crtc code will adjust the mode in mode_set,
> this patch also adds a mode_fixup callback which we us
On 19-07-2017 20:21, John Stultz wrote:
> On Wed, Jul 19, 2017 at 3:16 AM, Jose Abreu wrote:
>> Hi John,
>>
>>
>> On 18-07-2017 18:59, John Stultz wrote:
>>> Currently the hikey dsi logic cannot generate accurate byte
>>> clocks values for all pi
Hi Ville,
On 13-11-2017 17:04, Ville Syrjala wrote:
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
>
Maybe "if (to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_RESE
On 13-11-2017 17:04, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the user mode would specify an aspect ratio other than 4:3 or 16:9
> we now silently ignore it. Maybe a better apporoach is to return an
> error? Let's try that.
>
> Also we must be careful that we don't try to send illegal p
harma
> Cc: Jim Bride
> Cc: Jose Abreu
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jose Abreu
Best Regards,
Jose Miguel Abreu
__
Hi Ville,
On 15-11-2017 15:49, Ville Syrjala wrote:
>
> +#define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> + DRM_MODE_FLAG_NHSYNC | \
> + DRM_MODE_FLAG_PVSYNC | \
> + DRM_MODE_FL
depend
> on these.
>
> v2: Recommend DRIVER instead of BUILTIN (ajax)
>
> Cc: Jose Abreu
> Cc: Adam Jackson
> Cc: Keith Packard
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Adam Jackson
> Reviewed-by: Alex Deucher
>
Reviewed-by: Jose Abreu
Best Regards,
Jose Miguel
;ramdac
> interface with some ancient S3 graphics adapters. Why someone though
> it would be a good idea to expose it directly to users I don't know.
> And later on it got copied into the randr protocol and kms uapi.
>
> Cc: Jose Abreu
> Cc: Adam Jackson
> Cc: Keith Packar
ev emulation never uses the corresponding fbdev flag
> there should be no sane way for this to come back into kms via
> userspace either.
>
> Cc: Jose Abreu
> Cc: Adam Jackson
> Cc: Keith Packard
> Signed-off-by: Ville Syrjälä
Hi Nick,
On 01-12-2017 00:11, Nick Bowler wrote:
> Hi,
>
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
>> A note about the test setup: I had to remove the test equipment so I
>> no longer have any information about the video mode from the sink side
>> (like in the photos). Thus, with the curren
On 03-12-2017 05:20, Nick Bowler wrote:
>
> Your patch changes things. With this applied on top of 4.15-rc1
> it is failing 100% of the time instead of only half of the time.
Ok, it was a long shot anyway.
>
> I brought the original test equipment back to the setup so I can
> see the video and p
Hi Alexey,
On 04-12-2017 11:32, Alexey Brodkin wrote:
> My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
> and it cannot use DRI video card natively. Is that correct?
>
>
Xserver can use DRI directly, you need to enable modesetting
driver in Xorg config or use the des
On 04-12-2017 13:16, Alexey Brodkin wrote:
> Option "kmsdev" "/dev/dri/card1"
Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
if you don't specify the busID it will fallback for the first
card that matches "armada-drm" or "imx-drm" or "udl".
> But if I swap "imx-
On 04-12-2017 14:53, Alexey Brodkin wrote:
> Full log you may find below.
Sorry but I meant /var/log/Xorg.0.log file.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 04-12-2017 16:00, Alexey Brodkin wrote:
> [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV
> target
>
I'm wondering if this means that target format for UDL is YUV ...
But anyway, I revisited your first email and noticed that you
said kmscube runs fine. Is this usi
Hi Alexey,
On 04-12-2017 17:29, Alexey Brodkin wrote:
>
> Indeed, in case of kmscube etnaviv is a renderer while UDL
> outputs the picture on the screen.
Thats nice :)
Ok, from your logs I was not able to see anything wrong. X server
does not error exit and Prime seems to be working in DRM ...
On 05-12-2017 11:53, Alexey Brodkin wrote:
>
> From my note above about udl_drm_gem_mmap() being only used in case of Xserver
> I barely may conclude anything. Given my lack of knowledge of DRM guts
> especially
> when it comes to complicated cases with DMA buffer exports/imports I cannot
> say
>
Hi Sean,
On 07-12-2017 00:00, Sean Paul wrote:
> Welcome to version 4 of the patchset. I think we're nearing the finish line
> (hopefully) now. This set addresses the review feedback from v3. I applied
> some
> R-b's from v3 review, and converted others to Cc since other changes were made
> to th
Hi,
On 13-12-2017 11:05, Hans Verkuil wrote:
> On 13/12/17 11:30, Maxime Ripard wrote:
>> Hi Hans,
>>
>> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
>>> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
>>> picture. Some
>>> digging found that there is no
know if this is specific to Synopsys Phy we only
set this if Phy type is DWC_HDMI.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: David Airlie
Cc: Russell King
Cc: Fabio Estevam
Cc: Daniel Vetter
Cc: Takashi Iwai
Cc: Vladimir Zapolskiy
Cc: Thierry Reding
Cc: dri-dev
201 - 300 of 315 matches
Mail list logo
