Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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 to be far from ready for that. Certainly the HDMI parts seems to be especially problematical. I want it out of staging if it's working properly. Yours is the first report of it not working properly, and in fact, probably one of the first users of the driver, as I haven't gotten any reports of it working or not at all over the years. Next problem... unbinding, rebinding, and then unbinding the imx-drm device produces the nice oops below. I've not debugged this yet. Alignment trap: not handling instruction e1932f9f at [c00758ec] Unhandled fault: alignment exception (0x001) at 0x6e72666f Internal error: : 1 [#1] SMP ARM Modules linked in: fuse bnep rfcomm bluetooth CPU: 0 PID: 1125 Comm: bash Tainted: GW3.12.0-rc4+ #123 task: d0d6ec00 ti: d7ff2000 task.ti: d7ff2000 PC is at __lock_acquire+0x1a8/0x1e14 LR is at lock_acquire+0x68/0x7c pc : [c00758f0]lr : [c0077aa8]psr: 20070093 sp : d7ff3cc8 ip : fp : d7ff3d54 r10: db2a6334 r9 : r8 : 6e72656b r7 : c0846208 r6 : c08852cc r5 : d0d6ec00 r4 : 0002 r3 : 6e72666f r2 : db2a6334 r1 : 0001 r0 : d7ff2000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 20df804a DAC: 0015 Process bash (pid: 1125, stack limit = 0xd7ff2240) Stack: (0xd7ff3cc8 to 0xd7ff4000) 3cc0: 0006 0007 c0cd22f0 0006 d7ff3d1c d7ff3ce8 3ce0: c00782f8 c0075050 0001 db801f00 d7ff2000 c0078648 d7ff2000 3d00: 0001 d7ff3e08 d7ff3e60 d7ff3dd8 d7ff3d3c d7ff3d20 d7ff3e08 3d20: d7ff3d7c d7ff3d30 c0072a58 d7ff2000 60070013 d0d6ec00 d7ff2000 3d40: c06679c8 d0d6ec00 d7ff3d8c d7ff3d58 c0077aa8 c0075754 0002 3d60: c02ff27c 0002 db2a62fc c02ff27c c08852cc 3d80: d7ff3de4 d7ff3d90 c05f80c4 c0077a4c 0002 c02ff27c c0072a20 3da0: dad64000 d7ff3e24 d7ff3df8 d7ff3e04 d7ff3e5c d0d6f000 c013f1c8 db322880 3dc0: db2a6440 db2a6000 c0872568 0008 c06679c8 db286000 d7ff3e04 d7ff3de8 3de0: c02ff27c c05f8074 db280f00 db322880 db2a6000 db29b810 d7ff3e1c d7ff3e08 3e00: c02f13ac c02ff268 d0e55000 c087265c d7ff3e2c d7ff3e20 c0464d7c c02f1398 3e20: d7ff3e54 d7ff3e30 c02f506c c0464d68 d0e55000 c087265c db29b810 c0872568 3e40: 0008 db286000 d7ff3e74 d7ff3e58 c02fa284 c02f503c c087265c c087265c 3e60: db29b810 0008 d7ff3e8c d7ff3e78 c02fb900 c02fa258 db29b810 c0872678 3e80: d7ff3e9c d7ff3e90 c0464d54 c02fb8d4 d7ff3eac d7ff3ea0 c0312bfc c0464d44 3ea0: d7ff3ec4 d7ff3eb0 c03113b0 c0312be8 db29b844 db29b810 d7ff3edc d7ff3ec8 3ec0: c0311434 c0311344 c0872678 c085b588 d7ff3efc d7ff3ee0 c03103ac c0311418 3ee0: c941b300 c941b318 d7ff3f70 db28c280 d7ff3f0c d7ff3f00 c030f934 c0310338 3f00: d7ff3f3c d7ff3f10 c013d7d0 c030f918 d7ff3f70 dbb5e600 0008 003ba408 3f20: d7ff3f70 0008 d7ff3f6c d7ff3f40 c00db77c c013d6d4 3f40: 0001 c000eb44 dbb5e600 d7ff3f70 003ba408 0008 3f60: d7ff3fa4 d7ff3f70 c00dbb58 c00db6b8 d7ff3f94 b6f7fa78 3f80: 0008 003ba408 0004 c000eb44 d7ff2000 d7ff3fa8 3fa0: c000e980 c00dbb18 b6f7fa78 0008 0001 003ba408 0008 3fc0: b6f7fa78 0008 003ba408 0004 bee5c9ec 000a6094 003f7f08 3fe0: bee5c96c b6eee747 b6f2611c 40070010 0001 0138 0020 Backtrace: [c0075748] (__lock_acquire+0x0/0x1e14) from [c0077aa8] (lock_acquire+0x68/0x7c) [c0077a40] (lock_acquire+0x0/0x7c) from [c05f80c4] (mutex_lock_nested+0x5c/0x394) r7: r6:c08852cc r5:c02ff27c r4:db2a62fc [c05f8068] (mutex_lock_nested+0x0/0x394) from [c02ff27c] (drm_modeset_lock_all+0x20/0x58) [c02ff25c] (drm_modeset_lock_all+0x0/0x58) from [c02f13ac] (drm_fbdev_cma_restore_mode+0x20/0x34) r6:db29b810 r5:db2a6000 r4:db322880 r3:db280f00 [c02f138c] (drm_fbdev_cma_restore_mode+0x0/0x34) from [c0464d7c] (imx_drm_driver_lastclose+0x20/0x24) r5:c087265c r4:d0e55000 [c0464d5c] (imx_drm_driver_lastclose+0x0/0x24) from [c02f506c] (drm_lastclose+0x3c/0x174) [c02f5030] (drm_lastclose+0x0/0x174) from [c02fa284] (drm_put_dev+0x38/0x154) [c02fa24c] (drm_put_dev+0x0/0x154) from [c02fb900] (drm_platform_exit+0x38/0x5c) r7:0008 r6:db29b810 r5:c087265c r4:c087265c [c02fb8c8] (drm_platform_exit+0x0/0x5c) from [c0464d54] (imx_drm_platform_remove+0x1c/0x24) r5:c0872678 r4:db29b810 [c0464d38] (imx_drm_platform_remove+0x0/0x24) from [c0312bfc] (platform_drv_remove+0x20/0x24) [c0312bdc] (platform_drv_remove+0x0/0x24) from [c03113b0] (__device_release_driver+0x78/0xd4) [c0311338] (__device_release_driver+0x0/0xd4) from [c0311434] (device_release_driver+0x28/0x34) r5:db29b810 r4:db29b844 [c031140c
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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 corruption that flashes up, and blanks (576p @50 Hz, 480p @60Hz), possibly a result of loss of signal. I've been looking at the DMFC, suspecting a fifo problem, but that to me looks fine - we seem to always allocate 4 slots, with each slot having a bandwidth of 99Mpixels each. This in theory should give a maximum of 396Mpixels, which is more than plenty. The bandwidth calculation is probably wrong though - the peak bandwidth is actually the pixel clock since this is the rate at which pixels have to be supplied during a line, not the refresh * hdisplayed * vdisplayed - that's the average bandwidth over a full frame. However, if it was a DMFC problem, and as this only carries pixel data, I'd expect that not to cause loss of signal. I've checked the phy MPLL settings back to the manual for certain problem clock rates, and they also seem fine. I've polled the status register to see whether it's unstable, and it appears to remain locked. I think I should probe the HDMI signals, particularly the clock signal to see if that provides any useful clues. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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.
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 be empty, and userspace KMS to fail.
There's also bugs in the CSC setting too - it runs off the end of the
array and gcc warns about this. The code was clearly wrong.
You may wish to combine this patch with patch 1 to sort all that out.
For the patch below:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
Thanks, Russell.
Will submit v3 when I am back to the office.
Okay, I still have a problem with HDMI: I have a magenta vertical line
down the left hand side of the frame, the displayed frame is shifted
right by the width of that line and the right hand side is missing some
pixels.
First off, the hsync position programmed into the HDMI registers appears
to be wrong.
I'm at a loss why imx-hdmi is obfuscated with a conversion from a
drm_display_mode structure to a fb_videomode. This adds additional
confusion and additional opportunities for bugs; this is probably
exactly why the hsync position is wrong.
In CEA-861-B for 720p @60Hz:
DE: __^^^
HS: ___^^^___
^ ^ ^
| | 220 clocks
| 40 clocks
110 clocks
The IMX6 manual says HSYINCINDELAY0 is Hsync active edge delay. Integer
number of pixel clock cycles from de non-active edge. So, this should be
110. Yet it ends up being programmed as 220, leading to a magenta vertical
bar down the left hand side of the display.
Now, if you look at Documentation/fb/framebuffer.txt, in this case, the
right margin should be 110 clocks, hsync len should be 40 and the left
margin should be 220 clocks.
However, this is not what your conversion to a fb_videomode does. It
reverses the left and right margin. A similar confusion also exists
in the conversion of the upper/lower margins too.
The DRM model is this (for 720p @60Hz):
0 1280 1390 1430 1650
|===||---|--|
^ ^^ ^ ^
start hdisplay hsync_start hsync_end htotal
The fb model is the same as the above but rotated:
left margindisplayedright margin hsync_len
|--|===||---|
So, the left margin is the bit between hsync_end and htotal, and the
right margin is the bit between hdisplay and hsync_start. Exactly
the same analysis applies to the upper/lower margins.
What I suggest is that the use of fb_videomode is entirely killed off
in this driver to remove this layer of confusion and instead the DRM
model is stuck to within this DRM driver.
Now on to the next problem. HSYNC/VSYNC polarity.
So, this is the mode which is set:
1280x720 (0x41) 74.2MHz +HSync +VSync *current +preferred
h: width 1280 start 1390 end 1430 total 1650 skew0 clock 45.0KHz
v: height 720 start 725 end 730 total 750 clock 60.0Hz
Note the positive HSync and VSync polarity - this is correct, backed
up by CEA-861-B.
The IPU DI0 is configured thusly in its general control register:
0x264 = 0x26, which is what is set when the requested mode
has DRM_MODE_FLAG_PHSYNC and DRM_MODE_FLAG_PVSYNC flags set.
However, if we look at the HDMI config: 0x121000 = 0x18. Active low
hsync/vsync. This is quite obvious when you look at the code -
convert_to_video_timing() does *nothing* at all when converting the
sync polarities, which means hdmi_av_composer() doesn't program them
appropriately. And yes, poking 0x78 into this register finally fixes
the problem.
Yet another reason why this silly conversion from one structure form
to another is a Very Bad Idea. Until I found this, I was merely going
to send a patch to sort out convert_to_video_timing(), but quite frankly
I'm going to kill this thing off right now.
Another thing:
static int imx_hdmi_setup(struct imx_hdmi *hdmi, struct drm_display_mode *mode)
{
int ret;
convert_to_video_timing(hdmi-fb_mode, mode);
hdmi_disable_overflow_interrupts(hdmi);
hdmi-vic = 6;
It's quite wrong to force every video mode set to be CEA mode 6. IIRC,
There is a function in DRM which will tell you the CEA mode number.
Again, I'll fix this in my patch rewriting this bit of the driver to
be correct.
I'm also suspicious of the HDMI Initialization Step comments, because
they make no sense:
/* HDMI Initialization Step B.4 */
static void imx_hdmi_enable_video_path(struct imx_hdmi *hdmi)
{
yet
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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. 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 be empty, and userspace KMS to fail.
There's also bugs in the CSC setting too - it runs off the end of the
array and gcc warns about this. The code was clearly wrong.
You may wish to combine this patch with patch 1 to sort all that out.
For the patch below:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
Thanks, Russell.
Will submit v3 when I am back to the office.
Okay, I still have a problem with HDMI: I have a magenta vertical line
down the left hand side of the frame, the displayed frame is shifted
right by the width of that line and the right hand side is missing some
pixels.
First off, the hsync position programmed into the HDMI registers appears
to be wrong.
I'm at a loss why imx-hdmi is obfuscated with a conversion from a
drm_display_mode structure to a fb_videomode. This adds additional
confusion and additional opportunities for bugs; this is probably
exactly why the hsync position is wrong.
In CEA-861-B for 720p @60Hz:
DE: __^^^
HS: ___^^^___
^ ^ ^
| | 220 clocks
| 40 clocks
110 clocks
The IMX6 manual says HSYINCINDELAY0 is Hsync active edge delay. Integer
number of pixel clock cycles from de non-active edge. So, this should be
110. Yet it ends up being programmed as 220, leading to a magenta vertical
bar down the left hand side of the display.
Now, if you look at Documentation/fb/framebuffer.txt, in this case, the
right margin should be 110 clocks, hsync len should be 40 and the left
margin should be 220 clocks.
However, this is not what your conversion to a fb_videomode does. It
reverses the left and right margin. A similar confusion also exists
in the conversion of the upper/lower margins too.
The DRM model is this (for 720p @60Hz):
0 1280 1390 1430 1650
|===||---|--|
^ ^^ ^ ^
start hdisplay hsync_start hsync_end htotal
The fb model is the same as the above but rotated:
left margindisplayedright margin hsync_len
|--|===||---|
So, the left margin is the bit between hsync_end and htotal, and the
right margin is the bit between hdisplay and hsync_start. Exactly
the same analysis applies to the upper/lower margins.
What I suggest is that the use of fb_videomode is entirely killed off
in this driver to remove this layer of confusion and instead the DRM
model is stuck to within this DRM driver.
Now on to the next problem. HSYNC/VSYNC polarity.
So, this is the mode which is set:
1280x720 (0x41) 74.2MHz +HSync +VSync *current +preferred
h: width 1280 start 1390 end 1430 total 1650 skew0 clock
45.0KHz
v: height 720 start 725 end 730 total 750 clock
60.0Hz
Note the positive HSync and VSync polarity - this is correct, backed
up by CEA-861-B.
The IPU DI0 is configured thusly in its general control register:
0x264 = 0x26, which is what is set when the requested mode
has DRM_MODE_FLAG_PHSYNC and DRM_MODE_FLAG_PVSYNC flags set.
However, if we look at the HDMI config: 0x121000 = 0x18. Active low
hsync/vsync. This is quite obvious when you look at the code -
convert_to_video_timing() does *nothing* at all when converting the
sync polarities, which means hdmi_av_composer() doesn't program them
appropriately. And yes, poking 0x78 into this register finally fixes
the problem.
Yet another reason why this silly conversion from one structure form
to another is a Very Bad Idea. Until I found this, I was merely going
to send a patch to sort out convert_to_video_timing(), but quite frankly
I'm going to kill this thing off right now.
Another thing:
static int imx_hdmi_setup(struct imx_hdmi *hdmi, struct drm_display_mode
*mode)
{
int ret;
convert_to_video_timing(hdmi-fb_mode, mode);
hdmi_disable_overflow_interrupts(hdmi);
hdmi-vic = 6;
It's quite wrong to force every video mode set to be CEA mode 6. IIRC,
There is a function in DRM which will tell you the CEA mode number.
Again, I'll fix this in my patch rewriting this bit of the driver to
be correct.
I'm also
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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;
video/mxc_hdmi.c- u8 val;
video/mxc_hdmi.c-
video/mxc_hdmi.c- /* TMDS software reset */
video/mxc_hdmi.c: hdmi_writeb((u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
video/mxc_hdmi.c-
video/mxc_hdmi.c- val = hdmi_readb(HDMI_FC_INVIDCONF);
video/mxc_hdmi.c-
video/mxc_hdmi.c- if (cpu_is_mx6dl()) {
video/mxc_hdmi.c-hdmi_writeb(val, HDMI_FC_INVIDCONF);
video/mxc_hdmi.c-return;
video/mxc_hdmi.c- }
video/mxc_hdmi.c-
video/mxc_hdmi.c- for (count = 0 ; count 5 ; count++)
video/mxc_hdmi.c- hdmi_writeb(val, HDMI_FC_INVIDCONF);
video/mxc_hdmi.c-}
So, perhaps you need to move the software reset first.
Just tried that - and yes, it does work (I'm on i.MX 6Solo for which
cpu_is_mx6dl() would return true.) Well done!
Indeed yes, the workaround in the code Fabio has differs from the
procedure given in the errata.
Note that this gives a new problem: we shouldn't use cpu_is_mx6dl()
in drivers - differences like this should be specified via DT properties.
I think we need this to recognise both fsl,imx6q-hdmi and fsl,imx6dl-hdmi
so that this workaround can detect when its running on a Solo/DL SoC.
Well, I now have quite a pile of patches for the hdmi code. :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Mon, Oct 14, 2013 at 11:47:17PM -0300, Fabio Estevam wrote: On Mon, Oct 14, 2013 at 2:38 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2 advertises itself as adding support for the wandboard, but in actual fact it's adding the generic bits too. Thanks for your review. Will address your comments in v3. Philipp Zabel mentioned that he will move imx-drm out of staging, so will send v3 after Philipp's patch gets into linux-next. That's unfortunate, especially given the bug with the clock polarity (which, although I can tweak the register directly, it's not obvious that changing the clk_pol initialisation is the correct solution.) There's also another issue here: the lack of DRM prime support. As you have a separate GPU and separate VPU, you really need dmabuf support implemented so that you can hand your scanout buffers/overlays to other subsystems. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support
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 be empty, and userspace KMS to fail.
There's also bugs in the CSC setting too - it runs off the end of the
array and gcc warns about this. The code was clearly wrong.
You may wish to combine this patch with patch 1 to sort all that out.
For the patch below:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
diff --git a/drivers/staging/imx-drm/imx-hdmi.c
b/drivers/staging/imx-drm/imx-hdmi.c
index e227eb1..ca0450b 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -507,7 +507,7 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi
*hdmi)
hdmi_writeb(hdmi, ((*csc_coeff)[0][2] 0xff), HDMI_CSC_COEF_A3_LSB);
hdmi_writeb(hdmi, ((*csc_coeff)[0][2] 8), HDMI_CSC_COEF_A3_MSB);
hdmi_writeb(hdmi, ((*csc_coeff)[0][3] 0xff), HDMI_CSC_COEF_A4_LSB);
- hdmi_writeb(hdmi, ((*csc_coeff)[0][4] 8), HDMI_CSC_COEF_A4_MSB);
+ hdmi_writeb(hdmi, ((*csc_coeff)[0][3] 8), HDMI_CSC_COEF_A4_MSB);
hdmi_writeb(hdmi, ((*csc_coeff)[1][0] 0xff), HDMI_CSC_COEF_B1_LSB);
hdmi_writeb(hdmi, ((*csc_coeff)[1][0] 8), HDMI_CSC_COEF_B1_MSB);
@@ -516,7 +516,7 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi
*hdmi)
hdmi_writeb(hdmi, ((*csc_coeff)[1][2] 0xff), HDMI_CSC_COEF_B3_LSB);
hdmi_writeb(hdmi, ((*csc_coeff)[1][2] 8), HDMI_CSC_COEF_B3_MSB);
hdmi_writeb(hdmi, ((*csc_coeff)[1][3] 0xff), HDMI_CSC_COEF_B4_LSB);
- hdmi_writeb(hdmi, ((*csc_coeff)[1][4] 8), HDMI_CSC_COEF_B4_MSB);
+ hdmi_writeb(hdmi, ((*csc_coeff)[1][3] 8), HDMI_CSC_COEF_B4_MSB);
hdmi_writeb(hdmi, ((*csc_coeff)[2][0] 0xff), HDMI_CSC_COEF_C1_LSB);
hdmi_writeb(hdmi, ((*csc_coeff)[2][0] 8), HDMI_CSC_COEF_C1_MSB);
@@ -525,7 +525,7 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi
*hdmi)
hdmi_writeb(hdmi, ((*csc_coeff)[2][2] 0xff), HDMI_CSC_COEF_C3_LSB);
hdmi_writeb(hdmi, ((*csc_coeff)[2][2] 8), HDMI_CSC_COEF_C3_MSB);
hdmi_writeb(hdmi, ((*csc_coeff)[2][3] 0xff), HDMI_CSC_COEF_C4_LSB);
- hdmi_writeb(hdmi, ((*csc_coeff)[2][4] 8), HDMI_CSC_COEF_C4_MSB);
+ hdmi_writeb(hdmi, ((*csc_coeff)[2][3] 8), HDMI_CSC_COEF_C4_MSB);
val = hdmi_readb(hdmi, HDMI_CSC_SCALE);
val = ~HDMI_CSC_SCALE_CSCSCALE_MASK;
@@ -1774,8 +1774,6 @@ static int imx_hdmi_register(struct imx_hdmi *hdmi)
{
int ret;
- drm_mode_connector_attach_encoder(hdmi-connector, hdmi-encoder);
-
hdmi-connector.funcs = imx_hdmi_connector_funcs;
hdmi-encoder.funcs = imx_hdmi_encoder_funcs;
@@ -1803,6 +1801,8 @@ static int imx_hdmi_register(struct imx_hdmi *hdmi)
hdmi-connector.encoder = hdmi-encoder;
+ drm_mode_connector_attach_encoder(hdmi-connector, hdmi-encoder);
+
return 0;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..65e54b4 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -88,3 +88,7 @@
crtcs = ipu1 0, ipu1 1;
};
};
+
+hdmi {
+ crtcs = ipu1 0, ipu1 1;
+}
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..d2467f5 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -159,3 +159,7 @@
crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
};
};
+
+hdmi {
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ccd55c2..b148cb3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1301,6 +1301,16 @@
};
};
+ hdmi: hdmi@012 {
+ compatible = fsl,imx6q-hdmi;
+ reg = 0x0012 0x9000;
+ interrupts = 0 115 0x04;
+ gpr = gpr;
+ clocks = clks 123, clks 124;
+ clock-names = iahb, isfr;
+ status = disabled;
+ };
+
dcic1: dcic@020e4000 {
reg = 0x020e4000 0x4000;
interrupts = 0 124 0x04;
Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2
advertises itself as adding support for the wandboard, but in actual
fact it's adding the generic bits too.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
On Mon, Oct 14, 2013 at 06:40:30PM +0100, Russell King - ARM Linux wrote:
Another thing that my build testing (and use on cubox-i) picked up:
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..65e54b4 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -88,3 +88,7 @@
crtcs = ipu1 0, ipu1 1;
};
};
+
+hdmi {
+ crtcs = ipu1 0, ipu1 1;
+}
Missing semi-colon.
Okay, next question(s).
1. How well tested is any of this imx-drm stuff?
2. What sort of testing has it been subject to?
Answers to these two questions may help stop me wasting a lot of time
chasing what is a really weird bug.
So, I have X up and running on the Cubox-i carrier-1, using the imx-drm
stuff (I've slightly hacked my xf86-armada X driver to get this working.)
This works fine - it detects the connectors, selects an appropriate
video mode and produces a picture of the correct shape and size.
However... I see really weird effects colouring effects - almost like
water over the image. It's certain colour transitions in the image
which seem to trigger this. There are also certain pixels which
twinkle.
Text looks very strange too. Rather than the font being crisp and clear,
it looks like there's red and green shift to it - but its not that it's
all shifted in that way.
Now, if I use the modetest utility from libdrm-2.4.43 to display a SMPTE
test pattern, this again looks right, but there are several vertical
single pixel lines of noise. The most striking one is below the upper
red bar in the lower dark area. I have a single pixel noisy vertical
line.
I've tried the kernel which Rabeeh supplied, which is based on BSP 4.1.0,
and this works fine as far as I can tell with the same image (though,
it's a little difficult converting the XWD dump to something that can
be directly poked into /dev/fb0..., although this results in R/B swap.)
Any ideas where to start looking?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/51] DMA mask changes
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. If I did that, then the mailing lists would not get the first patch, because almost none of the lists would be referred to by patch 1. Moreover, people complain when they don't have access to the full patch series - they assume patches are missing for some reason, and they ask for the rest of the series. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/51] DMA mask changes
This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev-dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +-- Documentation/DMA-API.txt |8 +++ arch/arm/include/asm/dma-mapping.h|8 +++ arch/arm/mm/dma-mapping.c | 49 ++-- arch/arm/mm/init.c| 12 +++--- arch/arm/mm/mm.h |2 + arch/powerpc/kernel/vio.c |3 +- block/blk-settings.c |8 ++-- drivers/amba/bus.c|6 +-- drivers/ata/pata_ixp4xx_cf.c |5 ++- drivers/ata/pata_octeon_cf.c |5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c| 48 ++-- drivers/dma/amba-pl08x.c |5 ++ drivers/dma/dw/platform.c |8 +-- drivers/dma/edma.c|6 +-- drivers/dma/pl330.c |4 ++ drivers/firmware/dcdbas.c | 23 +- drivers/firmware/google/gsmi.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +- drivers/media/platform/omap3isp/isp.c |6 +- drivers/media/platform/omap3isp/isp.h |3 - drivers/mmc/card/queue.c |3 +- drivers/mmc/host/sdhci-acpi.c |5 +- drivers/net/ethernet/broadcom/b44.c |3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++ drivers/net/ethernet/emulex/benet/be_main.c | 12 + drivers/net/ethernet/intel/e1000/e1000_main.c |9 +--- drivers/net/ethernet/intel/e1000e/netdev.c| 18 +++- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
Re: [patch] iio: mxs-lradc: use helper functions to simplify the code
On Thu, Sep 05, 2013 at 05:15:02PM -0300, Fabio Estevam wrote:
Looks good, just one minor suggestion:
On Thu, Sep 5, 2013 at 3:16 PM, Dan Carpenter dan.carpen...@oracle.com
wrote:
+static void lradc_reg_set(struct mxs_lradc *lradc, u32 val, size_t chan)
+{
+ writel(val, lradc-base + chan + STMP_OFFSET_REG_SET);
+}
+
+static void lradc_reg_clear(struct mxs_lradc *lradc, u32 val, size_t chan)
+{
+ writel(val, lradc-base + chan + STMP_OFFSET_REG_CLR);
+}
Maybe 'static inline' ?
GCC will already inline these if it thinks they're appropriate for that
treatment.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
