https://bugzilla.kernel.org/show_bug.cgi?id=52121
--- Comment #17 from Konrad Rzeszutek Wilk
2013-01-04 19:26:35 ---
(In reply to comment #16)
> I'm sorry Konrad, but I don't know exactly what you mean when you say "run on
> bare metal".
without Xen.
--
Configure bugmail: https://bugzill
https://bugzilla.kernel.org/show_bug.cgi?id=52121
--- Comment #18 from Fernando Chaves 2013-01-04
19:34:06 ---
Yes, everything works at 100% without Xen, both CLI and Xorg, even in CentOS.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving
On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
...
> I think we have now two ways to go forward with cons and pros:
> 1) Keep host1x and tegra-drm as separate driver
>+ Code almost done
>- we need dummy device and dummy driver
>- extra code and API when host1x creates dummy device and
On Fri, 4 Jan 2013, Dave Airlie wrote:
> Did you run these with pre-kms userspace etc to make sure it doesn't
> cause regressions there?
>
I did some tests with UMS and shuffled a number of cards. As I feared, I
ran into a number of unrelated problems, but in each case I have seen
identical be
On Fri, Jan 4, 2013 at 5:57 PM, Ilija Hadzic
wrote:
>
> On Fri, 4 Jan 2013, Dave Airlie wrote:
>
>> Did you run these with pre-kms userspace etc to make sure it doesn't
>> cause regressions there?
>>
>
> I did some tests with UMS and shuffled a number of cards. As I feared, I ran
> into a number o
(Please CC me on replies, I'm not subscribed.)
Since linux kernel version 3.7(.1), whenever I have already turned my
monitor off and the X server's dpms settings engages after the timeout,
I get the following:
[245917.595824] [ cut here ]
[245917.595837] WARNING: at driver
There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.
v4:
- removed error check for drm_mode_connector_update_edid_property
which is expected to fail for Virtu
This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports th
This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.
Both, mixer
This patch adds the implementation of check_mode callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.
Signed-off-by: Rahul Sharma
Signed-off
With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.
Signed-off-by: Rahul Sharma
Signed-off-by: Sean Paul
---
From: Sean Paul
This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.
Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.
Signed-off-by:
On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma
wrote:
> This patch adds the display mode check operation to exynos_mixer_ops
> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
> on the proposed display modes. These restriction needs to be considered
> during mode negotiatio
101 - 113 of 113 matches
Mail list logo
