Another problem.
After performing several modesets, the IPU seems to lock up and produce
no syncs or output data.
I've seen this many times over the last week while testing out various
aspects of imx-drm, and had put it down to problems with the clocking
arrangement getting its settings wrong.
On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
As for imx-drm, there was a warning which preceded that oops. Here's the
full log, below the - marker - this is from unbinding the imx-drm
module, and then trying to reboot.
imx-drm is really very broken in
On Sun, Oct 20, 2013 at 05:31:56PM +0100, Russell King - ARM Linux wrote:
On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
As for imx-drm, there was a warning which preceded that oops. Here's the
full log, below the - marker - this is from unbinding the
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
Sorry, but I don't think imx-drm is driving the hardware correctly, and
I know that Greg wants it moved out of drivers/staging, but frankly it
seems
Hi Russell,
Am Mittwoch, den 16.10.2013, 20:02 +0100 schrieb Russell King - ARM
Linux:
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
Sorry, but I don't think imx-drm is driving the hardware
Okay, next problem...
As I described via the Cubox-i community last night on google+...
I'm now at the point where certain resolutions and refreshes work fine
(eg, 720p @ 50 or 60Hz, 1366x768, 1024x768).
Others either don't display (1080p, 800x600, 848x480, 640x480), or have
speckles, a line of
On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Another point on patch 1. Sorry, I don't have patch 1 to reply to, it
seems it was deleted from linux-arm-kernel's moderation queue.
On Wed, Oct 16, 2013 at 12:37:42PM -0700, Troy Kisky wrote:
On 10/16/2013 10:03 AM, Russell King - ARM Linux wrote:
On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Another point on patch 1.
On 10/16/2013 1:27 PM, Russell King - ARM Linux wrote:
On Wed, Oct 16, 2013 at 12:37:42PM -0700, Troy Kisky wrote:
On 10/16/2013 10:03 AM, Russell King - ARM Linux wrote:
On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
On Wed, Oct 16, 2013 at 02:03:17PM -0700, Troy Kisky wrote:
Freescale's kernel(imx_3.0.35_4.1.0) has this code
video/mxc_hdmi.c-/* Workaround to clear the overflow condition */
video/mxc_hdmi.c-static void mxc_hdmi_clear_overflow(void)
video/mxc_hdmi.c-{
video/mxc_hdmi.c- int count;
Another point on patch 1. Sorry, I don't have patch 1 to reply to, it
seems it was deleted from linux-arm-kernel's moderation queue.
drm_mode_connector_attach_encoder() is called too early, before the
base.id field in the encoder has been initialised. This causes the
connectors encoder array to
On Thu, Oct 03, 2013 at 03:51:25PM -0300, Fabio Estevam wrote:
This is based on the initial work done by Sascha Hauer and Tony Prisk.
Tested on imx6q-wandboard and imx6q-sabresd boards.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Rebased against
12 matches
Mail list logo
