-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/56909b99/attachment.html>
W dniu 08.08.2015 o 01:27, Thierry Reding pisze:
> From: Thierry Reding
>
> Use vendor prefixes for Kconfig symbols and filenames. This should make
> it easier to identify the various bridge drivers and to organize the
> directory.
>
> While at it, rename dw_hdmi.[ch] to dw-hdmi.[ch] for consist
W dniu 08.08.2015 o 01:27, Thierry Reding pisze:
> From: Thierry Reding
>
> The likelihood of getting a large number of panel drivers from different
> vendors is quite high. Add a prefix to the two existing Samsung panel
> drivers to set a guideline for future patch submissions. Using vendor
> pr
Hi Yakir,
I think this Rockchip portion is missing a devicetree binding.
You have the ability to power down the actual edp phy by using
grf_edp_iddq_en from GRF_SOC_CON12. This is similar to how the
rk3288 usb-phy gets put into a deeper state. So maybe you could
provide a phy driver (drivers/phy
Hi Hekio,
å¨ 2015/8/8 6:46, Heiko Stübner åé:
> Hi Yakir,
>
>
> I think this Rockchip portion is missing a devicetree binding.
Oh, thanks, I would complete it in next ;)
> You have the ability to power down the actual edp phy by using
> grf_edp_iddq_en from GRF_SOC_CON12. This is similar
On Fri, Aug 07, 2015 at 11:40:28PM +0100, Russell King - ARM Linux wrote:
> However, if we do this, then we might as well just modify
> dw_hdmi_connector_get_modes(), and arrange for a HPD de-assertion to
> NULL and free hdmi->edid so the next get_modes() call triggers a re-read.
Testing with the
On Sat, Aug 08, 2015 at 02:35:40PM +0100, Russell King - ARM Linux wrote:
> I have a whole bunch of further patches for dw-hdmi, so if you don't
> mind, I'll take your two, merge them on the front of my series, and
> re-post them. I think we're getting close to the time where we can
> see initial
On Sat, Jun 20, 2015 at 12:28:15AM +0800, Yakir Yang wrote:
> Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card
> driver could connect to this codec through the codec dai name
> "dw-hdmi-i2s-audio".
I'm applying this patch to my tree with some changes. I haven't seen
anyone ack it, nor
This sub-series is a mixture of development:
* Removing the incorrect pixel repetition configuration code
* Preventing pixel-doubled modes from being used
* Adding interlaced video support
* Implementing the sink_is_hdmi/sink_has_audio flags I suggested a few
months ago
* Only enabling audio sup
dw_hdmi sets a pixel repetition factor of 1 for VICs 10-15, 25-30 and
35-38. However, DRM uses their native resolutions in its timing
information. For example, VIC 14 can be 1440x480 with no repetition,
or 720x480 with one pixel repetition. As DRM uses 1440 pixels per line
for this video mode, w
As mentioned in the previous commit, the dw-hdmi driver does not support
pixel doubled modes at present; it does not configure the PLL correctly
for these modes. Therefore, filter out the double-clocked modes as we
presently are unable to support them.
Signed-off-by: Russell King
---
drivers/gp
Use a function to convert the sync pin to a bit mask for the DI_GENERAL
register, and move this out of the interlace/non-interlace path to the
common path.
Signed-off-by: Russell King
---
drivers/gpu/ipu-v3/ipu-di.c | 50 +
1 file changed, 28 insertion
The support for interlaced video modes seems to be broken; we don't use
anything other than the vtotal/htotal from the timing information to
define the various sync counters.
Freescale patches for interlaced video support contain an alternative
sync counter setup, which we include here. This setu
Add support for interlaced video modes to the dw_hdmi bridge. This
mainly involves halving the vertical parameters to be programmed into
the bridge registers, and setting the interlace_allowed connector flag.
This brings working 1080i support. However, 480i and 576i fail to
work due to the lack
The FSL kernel detects the HDMI vendor id, and uses this to set
hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately,
rather than detecting whether we are outputting a CEA mode. Update
the dw_hdmi code to use this logic, but lets eliminate the mdvi
variable, prefering the more ver
Only enable audio support if the sink supports audio in some form, as
defined via its EDID. We discover this capability using the generic
drm_detect_monitor_audio() function.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 12 +---
1 file changed, 9 insertions(+), 3 d
On a mode set, DRM makes the following sequence of calls:
* for_each_encoder
* bridge mode_fixup
* encoder mode_fixup
* crtc mode_fixup
* for_each_encoder
* bridge disable
* encoder prepare
* bridge post_disable
* disable unused encoders
* crtc pre
dw_hdmi_phy_enable_power() is not about enabling and disabling power.
It is about allowing or preventing power-down mode being entered - the
register is documented as "Power-down enable (active low 0b)."
This can be seen as the bit has no effect when the HDMI phy is
operational on iMX6 hardware.
When connected to HDMI sources, some DVI monitors de-assert their HPD
signal and TDMS loads for one seconds every four seconds when there is
no signal present on the connection.
Unfortunately, this behaviour is indistinguishable from a proper HDMI
setup with an AV receiver in the path to the displ
HDMI sinks are permitted to de-assert and re-assert the HPD signal to
indicate that their EDID has been updated, which may not involve a
change of video information.
An example of where such a situation can arise is when an AV receiver
is connected between the source and the display device. Event
Following on from the previous sub-series, this sub-series adds audio
support to dw-hdmi.
The two different variants are now in this patch: AHB audio support
found on iMX6 platforms, and I2S support found on Rockchip patches.
Thanks to Yakir Yang for contributing the I2S support.
I suspect that t
Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer
format supported by the hardware is its own special IEC958 based format,
which is not compatible with any ALSA format. To avoid doing too much
data manipulation within the driver, we support only ALSAs IEC958 LE and
24-bit PCM form
Parse the ELD (EDID like data) stored from the HDMI driver to restrict
the sample rates and channels which are available to ALSA. This causes
the ALSA device to reflect the capabilities of the overall audio path,
not just what is supported at the HDMI source interface level.
Signed-off-by: Russel
Add basic support for multi-channel PCM audio, with fixed speaker
mappings. This has been tested with an AV receiver, and appears to
work for low sample rates up to 8 channels.
It should be noted that multi-channel mode using the IEC958 alsa-lib
conversion plugin requires correct AES channel stat
With multichannel audio, we need to allow larger buffer sizes to avoid
XRUNs during playback. Push the buffer size up to 1024K, but as we
maintain two buffers, ensure that the vmalloc buffer does not exceed
the userspace buffer size.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdm
There's no need to be recursive when computing the N value for the ACR
packet - we can instead calculate the multiplier prior to our switch()
based lookup, and multiply the N value appropriately afterwards.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 25 +--
Adjust the pixel clock values in the N calculation to match the more
accurate clock values we're given by the DRM subsystem, which are the
kHz pixel rate, with any fractional kHz rounded down in the case of
the non-240, non-480 line modes, or rounded up for the others. So,
25.20 / 1.001
We never set the ratio for CTS/N calculation for the audio clock
regenerator (ACR) to anything but 100, so this adds pointless
complexity. Should we support pixel repetition, we should update the
CTS/N calculation code to use those parameters or the actual TMDS clock
rate instead of a ratio.
Sign
Given the TDMS clock, audio sample rate, and the N parameter, we can
calculate the CTS value for the audio clock regenerator (ACR) using the
following calculation given in the HDMI specification:
CTS = ftdms * N / (128 * fs)
The specification says that the CTS value is an average value, w
From: Yakir Yang
To: linux-rockchip at lists.infradead.org,alsa-devel at
alsa-project.org,dri-devel at lists.freedesktop.org,linux-kernel at
vger.kernel.org,linux-arm-kernel at lists.infradead.org
Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card
driver could connect to this codec th
The dw_hdmi enable/disable handling is particularly weak in several
regards:
* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
while DRM is setting a mode, which could race with a mode being set.
* Hotplug will always re-enable the phy whenever it detects an active
hotplug si
The Nvidia blob allows a pixel clock up to 225 MHz in version 346.59,
but only allowed 165MHz in version 295 for HDMI connections. This was
tested with a GF114 (Nvidia GTX 560 TI) and a HDMI monitor which used
225 MHz pixel clock and a signal link DVI monitor with a pixel clock of
less than 165 MHz
This allows to test whether a specific quirk
is (still) need on a particular hardware combination.
Adel Gadllah (1):
radeon: Add option to disable dpm quirks
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 4
drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
dri
Allow users to disable hardware specific dpm quirks
using a module parameter.
This patch leaves quirks enabled by default.
Signed-off-by: Adel Gadllah
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 4
drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
drivers
These patches are adding support for outputting 2560x1440 at 56 over HDMI.
This needs a pixel clock of 225 MHz which was not supported before.
This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and
one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running
with 192
Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actual possible.
Signed-off-by: Hauke Mehrtens
On 08.08.2015 17:09, Adel Gadllah wrote:
> Allow users to disable hardware specific dpm quirks
> using a module parameter.
>
> This patch leaves quirks enabled by default.
You should read the code a bit more carefully, you can already override
the kernel quirks by specifying radeon.dpm=1 on the k
akes 450 ms.
It seems to take 240 ms from loading the Radeon module to the message below.
[ 231.481] (II) [KMS] Kernel modesetting enabled.
Another 100 ms are used up, in the lines below.
[ 231.481] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[ 231.504] (II) RADEON(0): Output VGA-0 has no monitor section
[ 231.534] (II) RADEON(0): Output DVI-0 has no monitor section
[ 231.556] (II) RADEON(0): EDID for output VGA-0
[ 231.586] (II) RADEON(0): EDID for output DVI-0
[ 231.586] (II) RADEON(0): Manufacturer: SAM Model: 194 Serial#:
1112092985
Is it correct, that EDID is probed for both outputs? Is that necessary?
I assume during startup the Linux kernel for example already collected
this information and if no change of monitor/output is detected, the
EDID should be the same, right?
Is that already implement and I just need to apply the correct
configuration?
Any suggestions on how to decrease the startup time for the X server
are much appreciated.
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/e9c08481/attachment-0001.sig>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/1f5345ff/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150808/53f24870/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/7966d3da/attachment.html>
Am 08.08.2015 um 21:10 schrieb Christian König:
> On 08.08.2015 17:09, Adel Gadllah wrote:
>> Allow users to disable hardware specific dpm quirks
>> using a module parameter.
>>
>> This patch leaves quirks enabled by default.
>
> You should read the code a bit more carefully, you can already overr
42 matches
Mail list logo
