omap DSS fails with tft410 driver panel?

omap DSS fails with tft410 driver panel?

[Enric Balletbo Serra]

Hi all,

I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
changes the panel driver used on some boards. I tested current
linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
following error (see http://pastebin.com/VjPGCQDt for full log) :

   [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
   [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
   [   21.236236] omapfb omapfb: setup_plane failed

Before checking what happens there is a known issue with this ?

Thanks in advance,
    Enric

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

On 2012-10-11 18:58, Enric Balletbo Serra wrote:
> Hi all,
> 
> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
> changes the panel driver used on some boards. I tested current
> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
> following error (see http://pastebin.com/VjPGCQDt for full log) :
> 
>    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>    [   21.236236] omapfb omapfb: setup_plane failed
> 
> Before checking what happens there is a known issue with this ?

Works fine for me, although only with a quite minimal test environment.

Looking at the log, it looks to me that your userspace is trying to
configure the overlays, and that somehow leads to the driver getting
zero as the fb address.

I'm guessing that some wrong value is passed when configuring, or
missing some step in configuring. However, It should be the omapfb that
rejects configuration that would lead to paddr == 0, not omapdss, so
there's definitely bug in the error handling of omapfb.

Can you tell me more what's going on there? I presume the error happens
when booting? What userspace component is using omapfb in your setup? X?

If you can, put some debug prints into omapfb-ioctl.c:omapfb_setup_plane
to see what code path it takes, and where it goes wrong.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Enric Balletbo Serra]

Hi Tomi,

Thanks for your answer.

2012/10/12 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> On 2012-10-11 18:58, Enric Balletbo Serra wrote:
>> Hi all,
>>
>> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
>> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
>> changes the panel driver used on some boards. I tested current
>> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
>> following error (see http://pastebin.com/VjPGCQDt for full log) :
>>
>>    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>    [   21.236236] omapfb omapfb: setup_plane failed
>>
>> Before checking what happens there is a known issue with this ?
>
> Works fine for me, although only with a quite minimal test environment.
>

I tried with a minimal environment (without X) and I don't see the
error, so looks you've reason and the problem is with my userspace
application (X). OTOH, I don't see the video output. I remember that
this worked before, but seems now is broken. I'll check mux and others
hints to try to solve the problem ..

> Looking at the log, it looks to me that your userspace is trying to
> configure the overlays, and that somehow leads to the driver getting
> zero as the fb address.
>
> I'm guessing that some wrong value is passed when configuring, or
> missing some step in configuring. However, It should be the omapfb that
> rejects configuration that would lead to paddr == 0, not omapdss, so
> there's definitely bug in the error handling of omapfb.
>
> Can you tell me more what's going on there? I presume the error happens
> when booting? What userspace component is using omapfb in your setup? X?

Yes, the error occurs while booting, and the rootfs tries to load X server.

>
> If you can, put some debug prints into omapfb-ioctl.c:omapfb_setup_plane
> to see what code path it takes, and where it goes wrong.
>

First I'll try to get video output without X, then, if you want I can
debug this problem if you think it's interesting.

Regards,
    Enric

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On 2012-10-15 19:08, Enric Balletbo Serra wrote:
> Hi Tomi,
> 
> Thanks for your answer.
> 
> 2012/10/12 Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> On 2012-10-11 18:58, Enric Balletbo Serra wrote:
>>> Hi all,
>>>
>>> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
>>> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
>>> changes the panel driver used on some boards. I tested current
>>> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
>>> following error (see http://pastebin.com/VjPGCQDt for full log) :
>>>
>>>    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>>    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>>    [   21.236236] omapfb omapfb: setup_plane failed
>>>
>>> Before checking what happens there is a known issue with this ?
>>
>> Works fine for me, although only with a quite minimal test environment.
>>
> 
> I tried with a minimal environment (without X) and I don't see the
> error, so looks you've reason and the problem is with my userspace
> application (X). OTOH, I don't see the video output. I remember that
> this worked before, but seems now is broken. I'll check mux and others
> hints to try to solve the problem ..

It's not about muxing, but something else. So an earlier kernel works
with the exact same userspace and kernel boot arguments? Then we
probably have a bug in the kernel driver. But I can't say much from the
debug prints, except that probably something goes wrong in the
SETUP_PLANE ioctl.

If you can, please add debug prints to omapfb-ioctl.c's
omapfb_setup_plane() and print out the data in the  omapfb_plane_info
parameter, and also prints to the error code paths in the function.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra
<eballetbo@gmail.com> wrote:

> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
> changes the panel driver used on some boards. I tested current
> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
> following error (see http://pastebin.com/VjPGCQDt for full log) :
>
>    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>    [   21.236236] omapfb omapfb: setup_plane failed

Was there ever any resolution to this issue?

I am seeing the same errors on Overo.  The video output actually
works, but it appears that this error causes X to close and then
restart repeatedly.

I'll add the printk's to omapfb_setup_plane() that were requested by
Tomi and report back.

Regards,

Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On 2012-11-22 02:08, Steve Sakoman wrote:
> On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra
> <eballetbo@gmail.com> wrote:
> 
>> I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
>> tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
>> changes the panel driver used on some boards. I tested current
>> linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
>> following error (see http://pastebin.com/VjPGCQDt for full log) :
>>
>>    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>>    [   21.236236] omapfb omapfb: setup_plane failed
> 
> Was there ever any resolution to this issue?

Not that I know.

> I am seeing the same errors on Overo.  The video output actually
> works, but it appears that this error causes X to close and then
> restart repeatedly.
> 
> I'll add the printk's to omapfb_setup_plane() that were requested by
> Tomi and report back.

How can I reproduce this? Is there a downloadable rootfs somewhere that
I could try?

Could you also copy full kernel boot log to pastebin or such?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

>> I'll add the printk's to omapfb_setup_plane() that were requested by
>> Tomi and report back.

Today was a holiday, so family obligations didn't allow much time to
look at this.

I did however do a quick build with some printk's in
omapfb_setup_plane() so I could narrow down where to start looking.

I discovered that the error (omapdss OVERLAY error: check_overlay:
paddr cannot be 0) is happening as a result of the
ovl->set_overlay_info() call in the else clause of the code below:

    if (pi->enabled) {
        r = omapfb_setup_overlay(fbi, ovl, pi->pos_x, pi->pos_y,
            pi->out_width, pi->out_height);
        if (r) {
            printk("omapfb_setup_plane: pi->enabled &
omapfb_setup_overlay()\n");
            goto undo;
        }
    } else {
        struct omap_overlay_info info;

        ovl->get_overlay_info(ovl, &info);

        info.pos_x = pi->pos_x;
        info.pos_y = pi->pos_y;
        info.out_width = pi->out_width;
        info.out_height = pi->out_height;

        r = ovl->set_overlay_info(ovl, &info);
        if (r) {
            printk("omapfb_setup_plane: !pi->enabled &
ovl->set_overlay_info failed\n");
            goto undo;
        }
    }

I'll look at this more over as I get time over the coming days.

> How can I reproduce this? Is there a downloadable rootfs somewhere that
> I could try?

The only downloadable rootfs I have is 3.5 based.  I'll try to get a
3.6 image posted in the next couple of days.

> Could you also copy full kernel boot log to pastebin or such?

OK, will do that with my next build.  I'll assume you want dss
debugging enabled for that.

Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

On 2012-11-23 08:14, Steve Sakoman wrote:
> On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 
>>> I'll add the printk's to omapfb_setup_plane() that were requested by
>>> Tomi and report back.
> 
> Today was a holiday, so family obligations didn't allow much time to
> look at this.
> 
> I did however do a quick build with some printk's in
> omapfb_setup_plane() so I could narrow down where to start looking.
> 
> I discovered that the error (omapdss OVERLAY error: check_overlay:
> paddr cannot be 0) is happening as a result of the
> ovl->set_overlay_info() call in the else clause of the code below:
> 
>     if (pi->enabled) {
>         r = omapfb_setup_overlay(fbi, ovl, pi->pos_x, pi->pos_y,
>             pi->out_width, pi->out_height);
>         if (r) {
>             printk("omapfb_setup_plane: pi->enabled &
> omapfb_setup_overlay()\n");
>             goto undo;
>         }
>     } else {
>         struct omap_overlay_info info;
> 
>         ovl->get_overlay_info(ovl, &info);
> 
>         info.pos_x = pi->pos_x;
>         info.pos_y = pi->pos_y;
>         info.out_width = pi->out_width;
>         info.out_height = pi->out_height;
> 
>         r = ovl->set_overlay_info(ovl, &info);
>         if (r) {
>             printk("omapfb_setup_plane: !pi->enabled &
> ovl->set_overlay_info failed\n");
>             goto undo;
>         }
>     }

Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and
info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
the point where it sets info.paddr, as I think that's the only place
where omapfb sets paddr.

I don't know what's going on there, why the paddr is suddenly zero.
Looking at the log from Enric, SETUP_PLANE works fine just fine, and
then, for no reason, next SETUP_PLANE fails, and the log doesn't show
anything much happening between.

However, I think omapdss may have been more permissive in the past,
allowing paddr 0 if the overlay is disabled. I could add that back, but
I'd rather first understand what's happening here.

> I'll look at this more over as I get time over the coming days.
> 
>> How can I reproduce this? Is there a downloadable rootfs somewhere that
>> I could try?
> 
> The only downloadable rootfs I have is 3.5 based.  I'll try to get a
> 3.6 image posted in the next couple of days.
> 
>> Could you also copy full kernel boot log to pastebin or such?
> 
> OK, will do that with my next build.  I'll assume you want dss
> debugging enabled for that.

That's probably not needed. I mostly wanted to know if there's some dss
error/warning seen on the boot. But probably not if the problem happens
in the code above.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:


> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and
> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
> the point where it sets info.paddr, as I think that's the only place
> where omapfb sets paddr.

OK, did that and here is what I get when starting up gdm, prior to
that all is normal

root@omap3-multi:~# systemctl start gdm.service
Starting Gnome Display Manager...
Started Gnome Display Manager                                          [  OK  ]
root@omap3-multi:~# [   83.475128] omapfb_setup_plane entry
[   83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[   83.485809] omapfb_setup_overlay: setting info.paddr = 9f400000
[   83.492431] dss_ovl_set_info entry
[   83.496307]     ovl->id = 0
[   83.499267]     info->paddr = 9f400000
[   83.503601] omapfb_setup_plane: return success
[   83.508697] omapfb_setup_plane entry
[   83.513153] dss_ovl_set_info entry
[   83.516723]     ovl->id = 2
[   83.520111]     info->paddr = 0
[   83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0
[   83.530426] omapfb_setup_plane: !pi->enabled & ovl->set_overlay_info
[   83.537414] dss_ovl_set_info entry
[   83.540985]     ovl->id = 2
[   83.544250]     info->paddr = 0
[   83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0

<repeats  as X dies and restarts>

> I don't know what's going on there, why the paddr is suddenly zero.
> Looking at the log from Enric, SETUP_PLANE works fine just fine, and
> then, for no reason, next SETUP_PLANE fails, and the log doesn't show
> anything much happening between.
>
> However, I think omapdss may have been more permissive in the past,
> allowing paddr 0 if the overlay is disabled. I could add that back, but
> I'd rather first understand what's happening here.

>From the above it seems that the first SETUP_PLANE is for ovl->id = 0
and then those that fail are for ovl->id =2.

No idea what is going on in user space, but maybe this will mean
something to you :-)

Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]

On 2012-11-23 17:20, Steve Sakoman wrote:
> On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 
> 
>> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
>> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and
>> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
>> the point where it sets info.paddr, as I think that's the only place
>> where omapfb sets paddr.
> 
> OK, did that and here is what I get when starting up gdm, prior to
> that all is normal
> 
> root@omap3-multi:~# systemctl start gdm.service
> Starting Gnome Display Manager...
> Started Gnome Display Manager                                          [  OK  ]
> root@omap3-multi:~# [   83.475128] omapfb_setup_plane entry
> [   83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [   83.485809] omapfb_setup_overlay: setting info.paddr = 9f400000
> [   83.492431] dss_ovl_set_info entry
> [   83.496307]     ovl->id = 0
> [   83.499267]     info->paddr = 9f400000
> [   83.503601] omapfb_setup_plane: return success
> [   83.508697] omapfb_setup_plane entry
> [   83.513153] dss_ovl_set_info entry
> [   83.516723]     ovl->id = 2
> [   83.520111]     info->paddr = 0
> [   83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> [   83.530426] omapfb_setup_plane: !pi->enabled & ovl->set_overlay_info
> [   83.537414] dss_ovl_set_info entry
> [   83.540985]     ovl->id = 2
> [   83.544250]     info->paddr = 0
> [   83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> 
> <repeats  as X dies and restarts>
> 
>> I don't know what's going on there, why the paddr is suddenly zero.
>> Looking at the log from Enric, SETUP_PLANE works fine just fine, and
>> then, for no reason, next SETUP_PLANE fails, and the log doesn't show
>> anything much happening between.
>>
>> However, I think omapdss may have been more permissive in the past,
>> allowing paddr 0 if the overlay is disabled. I could add that back, but
>> I'd rather first understand what's happening here.
> 
> From the above it seems that the first SETUP_PLANE is for ovl->id = 0
> and then those that fail are for ovl->id =2.
> 
> No idea what is going on in user space, but maybe this will mean
> something to you :-)

Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?

Anyway, I guess it's a valid thing to configure the overlay with
paddr == 0 when the overlay is disabled. In fact, paddr == 0 check 
is in any case quite limited, as if the board's physical memory
doesn't contain the given paddr, the DSS HW will fail just as it 
would for paddr 0. So the paddr == 0 check is more of a sanity check
than a comprehensive test.

Can you try the following patch:

diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index 45f4994..e271e28 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
 int dss_ovl_simple_check(struct omap_overlay *ovl,
 		const struct omap_overlay_info *info)
 {
-	if (info->paddr == 0) {
-		DSSERR("check_overlay: paddr cannot be 0\n");
-		return -EINVAL;
-	}
-
 	if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
 		if (info->out_width != 0 && info->width != info->out_width) {
 			DSSERR("check_overlay: overlay %d doesn't support "


 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?

That was my guess too, and after some digging I am fairly certain this
is the case.

> Anyway, I guess it's a valid thing to configure the overlay with
> paddr == 0 when the overlay is disabled. In fact, paddr == 0 check
> is in any case quite limited, as if the board's physical memory
> doesn't contain the given paddr, the DSS HW will fail just as it
> would for paddr 0. So the paddr == 0 check is more of a sanity check
> than a comprehensive test.
>
> Can you try the following patch:
>
> diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
> index 45f4994..e271e28 100644
> --- a/drivers/video/omap2/dss/overlay.c
> +++ b/drivers/video/omap2/dss/overlay.c
> @@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
>  int dss_ovl_simple_check(struct omap_overlay *ovl,
>                 const struct omap_overlay_info *info)
>  {
> -       if (info->paddr == 0) {
> -               DSSERR("check_overlay: paddr cannot be 0\n");
> -               return -EINVAL;
> -       }
> -
>         if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
>                 if (info->out_width != 0 && info->width != info->out_width) {
>                         DSSERR("check_overlay: overlay %d doesn't support "


I tried something similar over the weekend (just removed the return so
I still got the error printout) and found that the simple_check failed
in 2 more places.

Here is the patch I ended up with to get a successful simple_check:

--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -610,7 +610,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
 {
     if (info->paddr == 0) {
         DSSERR("check_overlay: paddr cannot be 0\n");
-        return -EINVAL;
+//        return -EINVAL;
     }

     if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
@@ -630,7 +630,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
     if ((ovl->supported_modes & info->color_mode) == 0) {
         DSSERR("check_overlay: overlay %d doesn't support mode %d\n",
                 ovl->id, info->color_mode);
-        return -EINVAL;
+//        return -EINVAL;
     }

     if (info->zorder >= omap_dss_get_num_overlays()) {
@@ -641,7 +641,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
     if (dss_feat_rotation_type_supported(info->rotation_type) == 0) {
         DSSERR("check_overlay: rotation type %d not supported\n",
                 info->rotation_type);
-        return -EINVAL;
+//        return -EINVAL;
     }

     return 0;

After digging a little more it turned out that the continual
restarting of X wasn't due to the above error, but to a build system
glitch.  So the above issue doesn't block a basic X session.

I checked XVideo both with and without the above patch and it is
broken in both cases.  I'm beginning to suspect that this might be a
user space bug and will do a little investigation.

Because of this I don't think any dss changes should be made at this point.

During my testing I think I uncovered another issue :-(

I set omapdss.def_disp=lcd43 on the kernel command line to see if the
behavior changed with the LCD as the default device.

What I encountered was a null pointer crash:

[    3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R
[    3.488250] Unable to handle kernel NULL pointer dereference at
virtual address 00000028
[    3.496765] pgd = c0004000
[    3.499603] [00000028] *pgd=00000000
[    3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM
[    3.508605] Modules linked in:
[    3.511810] CPU: 0    Not tainted  (3.6.0 #1)
[    3.516357] PC is at dss_mgr_check_timings+0x4/0x30
[    3.521484] LR is at dpi_check_timings+0x18/0xb8
[    3.526336] pc : [<c025df70>]    lr : [<c0260dc0>]    psr: 40000013
[    3.526336] sp : dec2bd88  ip : 22222222  fp : def7e180
[    3.538330] r10: def951c0  r9 : def61000  r8 : de41b858
[    3.543823] r7 : dec2bdfc  r6 : c06c0a50  r5 : dec2be00  r4 : deea1cd4
[    3.550659] r3 : dec1ba40  r2 : dec2bdc8  r1 : dec2be00  r0 : 00000000
[    3.557495] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[    3.565155] Control: 10c5387d  Table: 80004019  DAC: 00000015
[    3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0)
[    3.577270] Stack: (0xdec2bd88 to 0xdec2c000)
[    3.581848] bd80:                   dec1ba40 c0260dc0 ffffffff
deea1cd4 def7e180 c046a7d0
[    3.590423] bda0: 22222222 22222222 22222222 22222222 deea1cd4
c06c0a50 dec2be00 dec2bdfc
[    3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50
00000000 de41b800 c046749c
[    3.607513] bde0: 0000003d c0495788 00000018 00000000 00000010
def98640 dec00140 00000000
[    3.616088] be00: 03000400 0000dac0 00300020 00040050 0003000f
00000001 00000000 00000000
[    3.624664] be20: 00000001 00000000 00000000 c0459380 deea257c
c06c0d00 dec2be50 00000000
[    3.633209] be40: c025cc10 c029a98c 00000000 c029ae80 dec075d8
00000000 00000000 de41b800
[    3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 00000002
00000001 de41b800 c0689470
[    3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40
00000000 def99148 decdf208
[    3.658935] bea0: def95240 c0137e24 00000000 c0054e18 00000000
00000003 decdf208 00000000
[    3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728
0000009e 00000000 c068920c
[    3.676055] bee0: 00000000 c029d830 c029d81c c029c514 c06e25dc
c06c3098 c06c3098 c06c30cc
[    3.684631] bf00: c06e25dc c029c790 00000000 dec2bf18 c06e25dc
c029aa9c dec077d8 decd9670
[    3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 00000000
c029bb2c c05a9b18 c05a9b18
[    3.701751] bf40: c06e25dc 00000001 c06a0c9c c0710300 0000009e
c029ccb4 00000000 c06e25c8
[    3.710296] bf60: 00000001 c06a0c9c c0710300 0000009e c068920c
c029daa4 00000007 c06967d8
[    3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c
976c0d2e c06a0cc4 00000008
[    3.727447] bfa0: 00000007 c06967d8 c06a0c9c c0710300 0000009e
c0669160 c06967e0 c06698d8
[    3.735992] bfc0: 00000007 00000007 c0669160 00000013 00000000
00000000 00000000 c06697a0
[    3.744567] bfe0: c000eea8 00000013 00000000 00000000 00000000
c000eea8 fffffff7 dffefffe
[    3.753143] [<c025df70>] (dss_mgr_check_timings+0x4/0x30) from
[<c0260dc0>] (dpi_check_timings+0x18/0xb8)
[    3.763183] [<c0260dc0>] (dpi_check_timings+0x18/0xb8) from
[<c026e738>] (tfp410_check_timings+0x28/0x3c)
[    3.773223] [<c026e738>] (tfp410_check_timings+0x28/0x3c) from
[<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4)
[    3.783905] [<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4) from
[<c0689470>] (omapfb_probe+0x210/0x600)
[    3.794036] [<c0689470>] (omapfb_probe+0x210/0x600) from
[<c029d830>] (platform_drv_probe+0x14/0x18)
[    3.803619] [<c029d830>] (platform_drv_probe+0x14/0x18) from
[<c029c514>] (driver_probe_device+0x11c/0x330)
[    3.813812] [<c029c514>] (driver_probe_device+0x11c/0x330) from
[<c029c790>] (__driver_attach+0x68/0x8c)
[    3.823760] [<c029c790>] (__driver_attach+0x68/0x8c) from
[<c029aa9c>] (bus_for_each_dev+0x48/0x80)
[    3.833251] [<c029aa9c>] (bus_for_each_dev+0x48/0x80) from
[<c029bb2c>] (bus_add_driver+0xf0/0x248)
[    3.842742] [<c029bb2c>] (bus_add_driver+0xf0/0x248) from
[<c029ccb4>] (driver_register+0x9c/0x12c)
[    3.852203] [<c029ccb4>] (driver_register+0x9c/0x12c) from
[<c029daa4>] (platform_driver_probe+0x18/0x9c)
[    3.862243] [<c029daa4>] (platform_driver_probe+0x18/0x9c) from
[<c0689234>] (omapfb_init+0x28/0x54)
[    3.871826] [<c0689234>] (omapfb_init+0x28/0x54) from [<c0008654>]
(do_one_initcall+0x90/0x160)
[    3.880950] [<c0008654>] (do_one_initcall+0x90/0x160) from
[<c06698d8>] (kernel_init+0x138/0x1f8)
[    3.890228] [<c06698d8>] (kernel_init+0x138/0x1f8) from
[<c000eea8>] (kernel_thread_exit+0x0/0x8)
[    3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028)
[    3.906097] ---[ end trace 38f657b10d460537 ]---

It seems that dss_mgr_check_timings is being called with a null dssdev->manager.

Other than the fact that there should be a null pointer check in the
code, it seems that this is a regression since it used to be possible
to switch the default display in this fashion.  Is this no longer
allowed?

Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 5666 bytes --]

On 2012-11-27 21:15, Steve Sakoman wrote:

> During my testing I think I uncovered another issue :-(
> 
> I set omapdss.def_disp=lcd43 on the kernel command line to see if the
> behavior changed with the LCD as the default device.
> 
> What I encountered was a null pointer crash:
> 
> [    3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R
> [    3.488250] Unable to handle kernel NULL pointer dereference at
> virtual address 00000028
> [    3.496765] pgd = c0004000
> [    3.499603] [00000028] *pgd=00000000
> [    3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM
> [    3.508605] Modules linked in:
> [    3.511810] CPU: 0    Not tainted  (3.6.0 #1)
> [    3.516357] PC is at dss_mgr_check_timings+0x4/0x30
> [    3.521484] LR is at dpi_check_timings+0x18/0xb8
> [    3.526336] pc : [<c025df70>]    lr : [<c0260dc0>]    psr: 40000013
> [    3.526336] sp : dec2bd88  ip : 22222222  fp : def7e180
> [    3.538330] r10: def951c0  r9 : def61000  r8 : de41b858
> [    3.543823] r7 : dec2bdfc  r6 : c06c0a50  r5 : dec2be00  r4 : deea1cd4
> [    3.550659] r3 : dec1ba40  r2 : dec2bdc8  r1 : dec2be00  r0 : 00000000
> [    3.557495] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> [    3.565155] Control: 10c5387d  Table: 80004019  DAC: 00000015
> [    3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0)
> [    3.577270] Stack: (0xdec2bd88 to 0xdec2c000)
> [    3.581848] bd80:                   dec1ba40 c0260dc0 ffffffff
> deea1cd4 def7e180 c046a7d0
> [    3.590423] bda0: 22222222 22222222 22222222 22222222 deea1cd4
> c06c0a50 dec2be00 dec2bdfc
> [    3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50
> 00000000 de41b800 c046749c
> [    3.607513] bde0: 0000003d c0495788 00000018 00000000 00000010
> def98640 dec00140 00000000
> [    3.616088] be00: 03000400 0000dac0 00300020 00040050 0003000f
> 00000001 00000000 00000000
> [    3.624664] be20: 00000001 00000000 00000000 c0459380 deea257c
> c06c0d00 dec2be50 00000000
> [    3.633209] be40: c025cc10 c029a98c 00000000 c029ae80 dec075d8
> 00000000 00000000 de41b800
> [    3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 00000002
> 00000001 de41b800 c0689470
> [    3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40
> 00000000 def99148 decdf208
> [    3.658935] bea0: def95240 c0137e24 00000000 c0054e18 00000000
> 00000003 decdf208 00000000
> [    3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728
> 0000009e 00000000 c068920c
> [    3.676055] bee0: 00000000 c029d830 c029d81c c029c514 c06e25dc
> c06c3098 c06c3098 c06c30cc
> [    3.684631] bf00: c06e25dc c029c790 00000000 dec2bf18 c06e25dc
> c029aa9c dec077d8 decd9670
> [    3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 00000000
> c029bb2c c05a9b18 c05a9b18
> [    3.701751] bf40: c06e25dc 00000001 c06a0c9c c0710300 0000009e
> c029ccb4 00000000 c06e25c8
> [    3.710296] bf60: 00000001 c06a0c9c c0710300 0000009e c068920c
> c029daa4 00000007 c06967d8
> [    3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c
> 976c0d2e c06a0cc4 00000008
> [    3.727447] bfa0: 00000007 c06967d8 c06a0c9c c0710300 0000009e
> c0669160 c06967e0 c06698d8
> [    3.735992] bfc0: 00000007 00000007 c0669160 00000013 00000000
> 00000000 00000000 c06697a0
> [    3.744567] bfe0: c000eea8 00000013 00000000 00000000 00000000
> c000eea8 fffffff7 dffefffe
> [    3.753143] [<c025df70>] (dss_mgr_check_timings+0x4/0x30) from
> [<c0260dc0>] (dpi_check_timings+0x18/0xb8)
> [    3.763183] [<c0260dc0>] (dpi_check_timings+0x18/0xb8) from
> [<c026e738>] (tfp410_check_timings+0x28/0x3c)
> [    3.773223] [<c026e738>] (tfp410_check_timings+0x28/0x3c) from
> [<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4)
> [    3.783905] [<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4) from
> [<c0689470>] (omapfb_probe+0x210/0x600)
> [    3.794036] [<c0689470>] (omapfb_probe+0x210/0x600) from
> [<c029d830>] (platform_drv_probe+0x14/0x18)
> [    3.803619] [<c029d830>] (platform_drv_probe+0x14/0x18) from
> [<c029c514>] (driver_probe_device+0x11c/0x330)
> [    3.813812] [<c029c514>] (driver_probe_device+0x11c/0x330) from
> [<c029c790>] (__driver_attach+0x68/0x8c)
> [    3.823760] [<c029c790>] (__driver_attach+0x68/0x8c) from
> [<c029aa9c>] (bus_for_each_dev+0x48/0x80)
> [    3.833251] [<c029aa9c>] (bus_for_each_dev+0x48/0x80) from
> [<c029bb2c>] (bus_add_driver+0xf0/0x248)
> [    3.842742] [<c029bb2c>] (bus_add_driver+0xf0/0x248) from
> [<c029ccb4>] (driver_register+0x9c/0x12c)
> [    3.852203] [<c029ccb4>] (driver_register+0x9c/0x12c) from
> [<c029daa4>] (platform_driver_probe+0x18/0x9c)
> [    3.862243] [<c029daa4>] (platform_driver_probe+0x18/0x9c) from
> [<c0689234>] (omapfb_init+0x28/0x54)
> [    3.871826] [<c0689234>] (omapfb_init+0x28/0x54) from [<c0008654>]
> (do_one_initcall+0x90/0x160)
> [    3.880950] [<c0008654>] (do_one_initcall+0x90/0x160) from
> [<c06698d8>] (kernel_init+0x138/0x1f8)
> [    3.890228] [<c06698d8>] (kernel_init+0x138/0x1f8) from
> [<c000eea8>] (kernel_thread_exit+0x0/0x8)
> [    3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028)
> [    3.906097] ---[ end trace 38f657b10d460537 ]---
> 
> It seems that dss_mgr_check_timings is being called with a null dssdev->manager.
> 
> Other than the fact that there should be a null pointer check in the
> code, it seems that this is a regression since it used to be possible
> to switch the default display in this fashion.  Is this no longer
> allowed?

It is allowed. Which kernel is that? I tried v3.7-rc4 and the current
omapdss master, both work for me with overo + lcd43 add on.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Enric Balletbo Serra]

2012/11/29 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> On 2012-11-27 21:15, Steve Sakoman wrote:
>
>> During my testing I think I uncovered another issue :-(
>>
>> I set omapdss.def_disp=lcd43 on the kernel command line to see if the
>> behavior changed with the LCD as the default device.
>>
>> What I encountered was a null pointer crash:
>>
>> [    3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R
>> [    3.488250] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000028
>> [    3.496765] pgd = c0004000
>> [    3.499603] [00000028] *pgd=00000000
>> [    3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM
>> [    3.508605] Modules linked in:
>> [    3.511810] CPU: 0    Not tainted  (3.6.0 #1)
>> [    3.516357] PC is at dss_mgr_check_timings+0x4/0x30
>> [    3.521484] LR is at dpi_check_timings+0x18/0xb8
>> [    3.526336] pc : [<c025df70>]    lr : [<c0260dc0>]    psr: 40000013
>> [    3.526336] sp : dec2bd88  ip : 22222222  fp : def7e180
>> [    3.538330] r10: def951c0  r9 : def61000  r8 : de41b858
>> [    3.543823] r7 : dec2bdfc  r6 : c06c0a50  r5 : dec2be00  r4 : deea1cd4
>> [    3.550659] r3 : dec1ba40  r2 : dec2bdc8  r1 : dec2be00  r0 : 00000000
>> [    3.557495] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>> Segment kernel
>> [    3.565155] Control: 10c5387d  Table: 80004019  DAC: 00000015
>> [    3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0)
>> [    3.577270] Stack: (0xdec2bd88 to 0xdec2c000)
>> [    3.581848] bd80:                   dec1ba40 c0260dc0 ffffffff
>> deea1cd4 def7e180 c046a7d0
>> [    3.590423] bda0: 22222222 22222222 22222222 22222222 deea1cd4
>> c06c0a50 dec2be00 dec2bdfc
>> [    3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50
>> 00000000 de41b800 c046749c
>> [    3.607513] bde0: 0000003d c0495788 00000018 00000000 00000010
>> def98640 dec00140 00000000
>> [    3.616088] be00: 03000400 0000dac0 00300020 00040050 0003000f
>> 00000001 00000000 00000000
>> [    3.624664] be20: 00000001 00000000 00000000 c0459380 deea257c
>> c06c0d00 dec2be50 00000000
>> [    3.633209] be40: c025cc10 c029a98c 00000000 c029ae80 dec075d8
>> 00000000 00000000 de41b800
>> [    3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 00000002
>> 00000001 de41b800 c0689470
>> [    3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40
>> 00000000 def99148 decdf208
>> [    3.658935] bea0: def95240 c0137e24 00000000 c0054e18 00000000
>> 00000003 decdf208 00000000
>> [    3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728
>> 0000009e 00000000 c068920c
>> [    3.676055] bee0: 00000000 c029d830 c029d81c c029c514 c06e25dc
>> c06c3098 c06c3098 c06c30cc
>> [    3.684631] bf00: c06e25dc c029c790 00000000 dec2bf18 c06e25dc
>> c029aa9c dec077d8 decd9670
>> [    3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 00000000
>> c029bb2c c05a9b18 c05a9b18
>> [    3.701751] bf40: c06e25dc 00000001 c06a0c9c c0710300 0000009e
>> c029ccb4 00000000 c06e25c8
>> [    3.710296] bf60: 00000001 c06a0c9c c0710300 0000009e c068920c
>> c029daa4 00000007 c06967d8
>> [    3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c
>> 976c0d2e c06a0cc4 00000008
>> [    3.727447] bfa0: 00000007 c06967d8 c06a0c9c c0710300 0000009e
>> c0669160 c06967e0 c06698d8
>> [    3.735992] bfc0: 00000007 00000007 c0669160 00000013 00000000
>> 00000000 00000000 c06697a0
>> [    3.744567] bfe0: c000eea8 00000013 00000000 00000000 00000000
>> c000eea8 fffffff7 dffefffe
>> [    3.753143] [<c025df70>] (dss_mgr_check_timings+0x4/0x30) from
>> [<c0260dc0>] (dpi_check_timings+0x18/0xb8)
>> [    3.763183] [<c0260dc0>] (dpi_check_timings+0x18/0xb8) from
>> [<c026e738>] (tfp410_check_timings+0x28/0x3c)
>> [    3.773223] [<c026e738>] (tfp410_check_timings+0x28/0x3c) from
>> [<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4)
>> [    3.783905] [<c046749c>] (omapfb_parse_def_modes+0x338/0x3f4) from
>> [<c0689470>] (omapfb_probe+0x210/0x600)
>> [    3.794036] [<c0689470>] (omapfb_probe+0x210/0x600) from
>> [<c029d830>] (platform_drv_probe+0x14/0x18)
>> [    3.803619] [<c029d830>] (platform_drv_probe+0x14/0x18) from
>> [<c029c514>] (driver_probe_device+0x11c/0x330)
>> [    3.813812] [<c029c514>] (driver_probe_device+0x11c/0x330) from
>> [<c029c790>] (__driver_attach+0x68/0x8c)
>> [    3.823760] [<c029c790>] (__driver_attach+0x68/0x8c) from
>> [<c029aa9c>] (bus_for_each_dev+0x48/0x80)
>> [    3.833251] [<c029aa9c>] (bus_for_each_dev+0x48/0x80) from
>> [<c029bb2c>] (bus_add_driver+0xf0/0x248)
>> [    3.842742] [<c029bb2c>] (bus_add_driver+0xf0/0x248) from
>> [<c029ccb4>] (driver_register+0x9c/0x12c)
>> [    3.852203] [<c029ccb4>] (driver_register+0x9c/0x12c) from
>> [<c029daa4>] (platform_driver_probe+0x18/0x9c)
>> [    3.862243] [<c029daa4>] (platform_driver_probe+0x18/0x9c) from
>> [<c0689234>] (omapfb_init+0x28/0x54)
>> [    3.871826] [<c0689234>] (omapfb_init+0x28/0x54) from [<c0008654>]
>> (do_one_initcall+0x90/0x160)
>> [    3.880950] [<c0008654>] (do_one_initcall+0x90/0x160) from
>> [<c06698d8>] (kernel_init+0x138/0x1f8)
>> [    3.890228] [<c06698d8>] (kernel_init+0x138/0x1f8) from
>> [<c000eea8>] (kernel_thread_exit+0x0/0x8)
>> [    3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028)
>> [    3.906097] ---[ end trace 38f657b10d460537 ]---
>>
>> It seems that dss_mgr_check_timings is being called with a null dssdev->manager.
>>
>> Other than the fact that there should be a null pointer check in the
>> code, it seems that this is a regression since it used to be possible
>> to switch the default display in this fashion.  Is this no longer
>> allowed?
>
> It is allowed. Which kernel is that? I tried v3.7-rc4 and the current
> omapdss master, both work for me with overo + lcd43 add on.
>

Sorry for the delay, I also can't reproduce the issue, I think is
related due I upgrated the X server to a newer version. I would
recover my old rootfs to try to reproduce the issue...

>  Tomi
>
>

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Thu, Nov 29, 2012 at 3:22 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2012-11-27 21:15, Steve Sakoman wrote:
>> It seems that dss_mgr_check_timings is being called with a null dssdev->manager.
>>
>> Other than the fact that there should be a null pointer check in the
>> code, it seems that this is a regression since it used to be possible
>> to switch the default display in this fashion.  Is this no longer
>> allowed?
>
> It is allowed. Which kernel is that? I tried v3.7-rc4 and the current
> omapdss master, both work for me with overo + lcd43 add on.

It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)

Steve

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Thu, Nov 29, 2012 at 3:33 AM, Enric Balletbo Serra
<eballetbo@gmail.com> wrote:

> Sorry for the delay, I also can't reproduce the issue, I think is
> related due I upgrated the X server to a newer version. I would
> recover my old rootfs to try to reproduce the issue...

I am using xorg-server-1.11.2, which version have you switched to?

Steve

Re: omap DSS fails with tft410 driver panel?

[Enric Balletbo Serra]

2012/11/29 Steve Sakoman <sakoman@gmail.com>:
> On Thu, Nov 29, 2012 at 3:33 AM, Enric Balletbo Serra
> <eballetbo@gmail.com> wrote:
>
>> Sorry for the delay, I also can't reproduce the issue, I think is
>> related due I upgrated the X server to a newer version. I would
>> recover my old rootfs to try to reproduce the issue...
>
> I am using xorg-server-1.11.2, which version have you switched to?

I'm using version 1.13.0, but now I'm not sure if I have solved the
problem using this version or updating the kernel. I need to check.

>
> Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On 2012-11-29 16:18, Steve Sakoman wrote:
> On Thu, Nov 29, 2012 at 3:22 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2012-11-27 21:15, Steve Sakoman wrote:
>>> It seems that dss_mgr_check_timings is being called with a null dssdev->manager.
>>>
>>> Other than the fact that there should be a null pointer check in the
>>> code, it seems that this is a regression since it used to be possible
>>> to switch the default display in this fashion.  Is this no longer
>>> allowed?
>>
>> It is allowed. Which kernel is that? I tried v3.7-rc4 and the current
>> omapdss master, both work for me with overo + lcd43 add on.
> 
> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)

Still can't reproduce. So does the null pointer deref happen at boot
time? What display related kernel boot options do you have? This looks
funny, considering lcd43 is a bit smaller lcd:

[    3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>
> Still can't reproduce. So does the null pointer deref happen at boot
> time? What display related kernel boot options do you have? This looks
> funny, considering lcd43 is a bit smaller lcd:

Yes, it happens at boot time.

The boot options:

[    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=500
vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait

My DSS config options:

#
# Frame buffer hardware drivers
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
CONFIG_OMAP2_VRAM=y
CONFIG_OMAP2_VRFB=y
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=12
CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y
# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set
CONFIG_OMAP2_DSS_DPI=y
# CONFIG_OMAP2_DSS_RFBI is not set
CONFIG_OMAP2_DSS_VENC=y
# CONFIG_OMAP2_DSS_SDI is not set
CONFIG_OMAP2_DSS_DSI=y
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0
CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y
CONFIG_FB_OMAP2=y
CONFIG_FB_OMAP2_DEBUG_SUPPORT=y
CONFIG_FB_OMAP2_NUM_FBS=3

#
# OMAP2/3 Display Device Drivers
#
CONFIG_PANEL_GENERIC_DPI=y
CONFIG_PANEL_TFP410=y
CONFIG_PANEL_LGPHILIPS_LB035Q02=y
CONFIG_PANEL_SHARP_LS037V7DW01=y
# CONFIG_PANEL_NEC_NL8048HL11_01B is not set
# CONFIG_PANEL_PICODLP is not set
# CONFIG_PANEL_TAAL is not set
# CONFIG_PANEL_TPO_TD043MTEA1 is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_L4F00242T03 is not set
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
# CONFIG_LCD_PLATFORM is not set
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=m
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_PANDORA is not set


Steve

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On 2012-11-29 16:53, Steve Sakoman wrote:
> On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 
>>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>>
>> Still can't reproduce. So does the null pointer deref happen at boot
>> time? What display related kernel boot options do you have? This looks
>> funny, considering lcd43 is a bit smaller lcd:
> 
> Yes, it happens at boot time.
> 
> The boot options:
> 
> [    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=500
> vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43
> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait

Ok, now I see it. It happens because DVI is not configured to be used,
but you have DVI video mode specified in the command line.

I'll study this further and make a fix.

 Tomi




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Javier Martinez Canillas]

On Thu, Nov 29, 2012 at 3:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2012-11-29 16:53, Steve Sakoman wrote:
>> On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>>>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>>>
>>> Still can't reproduce. So does the null pointer deref happen at boot
>>> time? What display related kernel boot options do you have? This looks
>>> funny, considering lcd43 is a bit smaller lcd:
>>
>> Yes, it happens at boot time.
>>
>> The boot options:
>>
>> [    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=500
>> vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43
>> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
>
> Ok, now I see it. It happens because DVI is not configured to be used,
> but you have DVI video mode specified in the command line.
>
> I'll study this further and make a fix.
>
>  Tomi
>
>
>

Hello folks,

Did you find a solution for this?

I still have the issue, when trying to start X I got:

[   25.152160] OMAPFB: ioctl QUERY_PLANE
[   25.156066] OMAPFB: ioctl SETUP_PLANE
[   25.160095] OMAPFB: omapfb_setup_plane
[   25.164093] omapdss OVERLAY error: check_overlay: paddr cannot be 0
[   25.170684] omapdss OVERLAY error: check_overlay: paddr cannot be 0
[   25.177337] omapfb omapfb: setup_plane failed
[   25.181976] OMAPFB: ioctl failed: -22

I'm using the arm-soc.git tree with the latest fixes and cleanups for
v3.8 sent by Tony yesterday and Xorg 1.13.

The latest commit id is:

commit aad05c3602ba5c42ff8d0e572b2f614f25779ede
Merge: eccf4b3 f64d204
Author: Olof Johansson <olof@lixom.net>
Date:   Mon Dec 17 18:44:26 2012 -0800

    Merge branch 'late/omap-cleanup' into for-next

I've CONFIG_OMAP2_DSS, CONFIG_FB_OMAP2 and CONFIG_PANEL_TFP410
built-in and this is my kernel command line is:

console=ttyO2,115200n8 mpurate=auto vram=12M
omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait

Also I have this log about a locking dependency:

[   24.690795]
[   24.690826] ======================================================
[   24.690826] [ INFO: possible circular locking dependency detected ]
[   24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted
[   24.690826] -------------------------------------------------------
[   24.690826] Xorg/1259 is trying to acquire lock:
[   24.690887]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0068708>]
__blocking_notifier_call_chain+0x30/0x60
[   24.690887]
[   24.690887] but task is already holding lock:
[   24.690917]  (console_lock){+.+.+.}, at: [<c02cec98>] do_fb_ioctl+0x200/0x5d8
[   24.690917]
[   24.690917] which lock already depends on the new lock.
[   24.690917]
[   24.690917]
[   24.690917] the existing dependency chain (in reverse order) is:
[   24.690948]
[   24.690948] -> #1 (console_lock){+.+.+.}:
[   24.690979]        [<c00902a4>] lock_acquire+0x9c/0x124
[   24.690979]        [<c0042b0c>] console_lock+0x50/0x64
[   24.691009]        [<c0320bd0>] register_con_driver+0x38/0x134
[   24.691009]        [<c03221a0>] take_over_console+0x18/0x44
[   24.691040]        [<c02d7674>] fbcon_takeover+0x64/0xc8
[   24.691070]        [<c04f4dd4>] notifier_call_chain+0x44/0x84
[   24.691070]        [<c0068720>] __blocking_notifier_call_chain+0x48/0x60
[   24.691070]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
[   24.691101]        [<c02cf654>] register_framebuffer+0x16c/0x23c
[   24.691131]        [<c04ee990>] omapfb_create_framebuffers+0x520/0x700
[   24.691131]        [<c0723480>] omapfb_probe+0x4e4/0x768
[   24.691162]        [<c03399f8>] platform_drv_probe+0x18/0x1c
[   24.691162]        [<c03387b4>] driver_probe_device+0x78/0x210
[   24.691192]        [<c03389e0>] __driver_attach+0x94/0x98
[   24.691192]        [<c03370b4>] bus_for_each_dev+0x50/0x7c
[   24.691223]        [<c0337fe0>] bus_add_driver+0x178/0x240
[   24.691223]        [<c0338eb0>] driver_register+0x78/0x144
[   24.691253]        [<c0339be8>] platform_driver_probe+0x18/0x9c
[   24.691253]        [<c0722f70>] omapfb_init+0x28/0x54
[   24.691284]        [<c00086a4>] do_one_initcall+0x34/0x178
[   24.691284]        [<c04e47ac>] kernel_init+0x100/0x2b4
[   24.691314]        [<c0013170>] ret_from_fork+0x14/0x24
[   24.691314]
[   24.691314] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
[   24.691345]        [<c008f85c>] __lock_acquire+0x15e4/0x1b00
[   24.691345]        [<c00902a4>] lock_acquire+0x9c/0x124
[   24.691375]        [<c04f0eb8>] down_read+0x2c/0x3c
[   24.691375]        [<c0068708>] __blocking_notifier_call_chain+0x30/0x60
[   24.691406]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
[   24.691406]        [<c02ce1c0>] fb_blank+0x34/0x98
[   24.691436]        [<c02cecb0>] do_fb_ioctl+0x218/0x5d8
[   24.691436]        [<c0114924>] do_vfs_ioctl+0x80/0x5f0
[   24.691467]        [<c0114f04>] sys_ioctl+0x70/0x78
[   24.691467]        [<c00130c0>] ret_fast_syscall+0x0/0x3c
[   24.691467]
[   24.691467] other info that might help us debug this:
[   24.691467]
[   24.691497]  Possible unsafe locking scenario:
[   24.691497]
[   24.691497]        CPU0                    CPU1
[   24.691497]        ----                    ----
[   24.691497]   lock(console_lock);
[   24.691497]                                lock((fb_notifier_list).rwsem);
[   24.691528]                                lock(console_lock);
[   24.691528]   lock((fb_notifier_list).rwsem);
[   24.691528]
[   24.691528]  *** DEADLOCK ***
[   24.691528]
[   24.691528] 2 locks held by Xorg/1259:
[   24.691558]  #0:  (&fb_info->lock){+.+.+.}, at: [<c02cdf9c>]
lock_fb_info+0x18/0x3c
[   24.691589]  #1:  (console_lock){+.+.+.}, at: [<c02cec98>]
do_fb_ioctl+0x200/0x5d8
[   24.691589]
[   24.691589] stack backtrace:
[   24.691619] [<c001ac2c>] (unwind_backtrace+0x0/0xf0) from
[<c04eb508>] (print_circular_bug+0x278/0x2c4)
[   24.691650] [<c04eb508>] (print_circular_bug+0x278/0x2c4) from
[<c008f85c>] (__lock_acquire+0x15e4/0x1b00)
[   24.691650] [<c008f85c>] (__lock_acquire+0x15e4/0x1b00) from
[<c00902a4>] (lock_acquire+0x9c/0x124)
[   24.691680] [<c00902a4>] (lock_acquire+0x9c/0x124) from
[<c04f0eb8>] (down_read+0x2c/0x3c)
[   24.691711] [<c04f0eb8>] (down_read+0x2c/0x3c) from [<c0068708>]
(__blocking_notifier_call_chain+0x30/0x60)
[   24.691711] [<c0068708>] (__blocking_notifier_call_chain+0x30/0x60)
from [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
[   24.691741] [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
from [<c02ce1c0>] (fb_blank+0x34/0x98)
[   24.691741] [<c02ce1c0>] (fb_blank+0x34/0x98) from [<c02cecb0>]
(do_fb_ioctl+0x218/0x5d8)
[   24.691772] [<c02cecb0>] (do_fb_ioctl+0x218/0x5d8) from
[<c0114924>] (do_vfs_ioctl+0x80/0x5f0)
[   24.691772] [<c0114924>] (do_vfs_ioctl+0x80/0x5f0) from
[<c0114f04>] (sys_ioctl+0x70/0x78)
[   24.691802] [<c0114f04>] (sys_ioctl+0x70/0x78) from [<c00130c0>]
(ret_fast_syscall+0x0/0x3c)

I will look at this, but just wanted to ask first in case I missed
some patches that already fix this.

My complete .config [1], dmesg [2] and xorg.conf [3].

Thanks a lot and best regards,
Javier

[1]: http://fpaste.org/DJgw/
[2]: http://fpaste.org/XEs5/
[3]: http://fpaste.org/dhWd/

Re: omap DSS fails with tft410 driver panel?

[Javier Martinez Canillas]

On Tue, Dec 18, 2012 at 9:31 AM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Thu, Nov 29, 2012 at 3:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2012-11-29 16:53, Steve Sakoman wrote:
>>> On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>
>>>>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>>>>
>>>> Still can't reproduce. So does the null pointer deref happen at boot
>>>> time? What display related kernel boot options do you have? This looks
>>>> funny, considering lcd43 is a bit smaller lcd:
>>>
>>> Yes, it happens at boot time.
>>>
>>> The boot options:
>>>
>>> [    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=500
>>> vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43
>>> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
>>
>> Ok, now I see it. It happens because DVI is not configured to be used,
>> but you have DVI video mode specified in the command line.
>>
>> I'll study this further and make a fix.
>>
>>  Tomi
>>
>>
>>
>
> Hello folks,
>
> Did you find a solution for this?
>
> I still have the issue, when trying to start X I got:
>
> [   25.152160] OMAPFB: ioctl QUERY_PLANE
> [   25.156066] OMAPFB: ioctl SETUP_PLANE
> [   25.160095] OMAPFB: omapfb_setup_plane
> [   25.164093] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> [   25.170684] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> [   25.177337] omapfb omapfb: setup_plane failed
> [   25.181976] OMAPFB: ioctl failed: -22
>
> I'm using the arm-soc.git tree with the latest fixes and cleanups for
> v3.8 sent by Tony yesterday and Xorg 1.13.
>
> The latest commit id is:
>
> commit aad05c3602ba5c42ff8d0e572b2f614f25779ede
> Merge: eccf4b3 f64d204
> Author: Olof Johansson <olof@lixom.net>
> Date:   Mon Dec 17 18:44:26 2012 -0800
>
>     Merge branch 'late/omap-cleanup' into for-next
>
> I've CONFIG_OMAP2_DSS, CONFIG_FB_OMAP2 and CONFIG_PANEL_TFP410
> built-in and this is my kernel command line is:
>
> console=ttyO2,115200n8 mpurate=auto vram=12M
> omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
> root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>
> Also I have this log about a locking dependency:
>
> [   24.690795]
> [   24.690826] ======================================================
> [   24.690826] [ INFO: possible circular locking dependency detected ]
> [   24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted
> [   24.690826] -------------------------------------------------------
> [   24.690826] Xorg/1259 is trying to acquire lock:
> [   24.690887]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0068708>]
> __blocking_notifier_call_chain+0x30/0x60
> [   24.690887]
> [   24.690887] but task is already holding lock:
> [   24.690917]  (console_lock){+.+.+.}, at: [<c02cec98>] do_fb_ioctl+0x200/0x5d8
> [   24.690917]
> [   24.690917] which lock already depends on the new lock.
> [   24.690917]
> [   24.690917]
> [   24.690917] the existing dependency chain (in reverse order) is:
> [   24.690948]
> [   24.690948] -> #1 (console_lock){+.+.+.}:
> [   24.690979]        [<c00902a4>] lock_acquire+0x9c/0x124
> [   24.690979]        [<c0042b0c>] console_lock+0x50/0x64
> [   24.691009]        [<c0320bd0>] register_con_driver+0x38/0x134
> [   24.691009]        [<c03221a0>] take_over_console+0x18/0x44
> [   24.691040]        [<c02d7674>] fbcon_takeover+0x64/0xc8
> [   24.691070]        [<c04f4dd4>] notifier_call_chain+0x44/0x84
> [   24.691070]        [<c0068720>] __blocking_notifier_call_chain+0x48/0x60
> [   24.691070]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
> [   24.691101]        [<c02cf654>] register_framebuffer+0x16c/0x23c
> [   24.691131]        [<c04ee990>] omapfb_create_framebuffers+0x520/0x700
> [   24.691131]        [<c0723480>] omapfb_probe+0x4e4/0x768
> [   24.691162]        [<c03399f8>] platform_drv_probe+0x18/0x1c
> [   24.691162]        [<c03387b4>] driver_probe_device+0x78/0x210
> [   24.691192]        [<c03389e0>] __driver_attach+0x94/0x98
> [   24.691192]        [<c03370b4>] bus_for_each_dev+0x50/0x7c
> [   24.691223]        [<c0337fe0>] bus_add_driver+0x178/0x240
> [   24.691223]        [<c0338eb0>] driver_register+0x78/0x144
> [   24.691253]        [<c0339be8>] platform_driver_probe+0x18/0x9c
> [   24.691253]        [<c0722f70>] omapfb_init+0x28/0x54
> [   24.691284]        [<c00086a4>] do_one_initcall+0x34/0x178
> [   24.691284]        [<c04e47ac>] kernel_init+0x100/0x2b4
> [   24.691314]        [<c0013170>] ret_from_fork+0x14/0x24
> [   24.691314]
> [   24.691314] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
> [   24.691345]        [<c008f85c>] __lock_acquire+0x15e4/0x1b00
> [   24.691345]        [<c00902a4>] lock_acquire+0x9c/0x124
> [   24.691375]        [<c04f0eb8>] down_read+0x2c/0x3c
> [   24.691375]        [<c0068708>] __blocking_notifier_call_chain+0x30/0x60
> [   24.691406]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
> [   24.691406]        [<c02ce1c0>] fb_blank+0x34/0x98
> [   24.691436]        [<c02cecb0>] do_fb_ioctl+0x218/0x5d8
> [   24.691436]        [<c0114924>] do_vfs_ioctl+0x80/0x5f0
> [   24.691467]        [<c0114f04>] sys_ioctl+0x70/0x78
> [   24.691467]        [<c00130c0>] ret_fast_syscall+0x0/0x3c
> [   24.691467]
> [   24.691467] other info that might help us debug this:
> [   24.691467]
> [   24.691497]  Possible unsafe locking scenario:
> [   24.691497]
> [   24.691497]        CPU0                    CPU1
> [   24.691497]        ----                    ----
> [   24.691497]   lock(console_lock);
> [   24.691497]                                lock((fb_notifier_list).rwsem);
> [   24.691528]                                lock(console_lock);
> [   24.691528]   lock((fb_notifier_list).rwsem);
> [   24.691528]
> [   24.691528]  *** DEADLOCK ***
> [   24.691528]
> [   24.691528] 2 locks held by Xorg/1259:
> [   24.691558]  #0:  (&fb_info->lock){+.+.+.}, at: [<c02cdf9c>]
> lock_fb_info+0x18/0x3c
> [   24.691589]  #1:  (console_lock){+.+.+.}, at: [<c02cec98>]
> do_fb_ioctl+0x200/0x5d8
> [   24.691589]
> [   24.691589] stack backtrace:
> [   24.691619] [<c001ac2c>] (unwind_backtrace+0x0/0xf0) from
> [<c04eb508>] (print_circular_bug+0x278/0x2c4)
> [   24.691650] [<c04eb508>] (print_circular_bug+0x278/0x2c4) from
> [<c008f85c>] (__lock_acquire+0x15e4/0x1b00)
> [   24.691650] [<c008f85c>] (__lock_acquire+0x15e4/0x1b00) from
> [<c00902a4>] (lock_acquire+0x9c/0x124)
> [   24.691680] [<c00902a4>] (lock_acquire+0x9c/0x124) from
> [<c04f0eb8>] (down_read+0x2c/0x3c)
> [   24.691711] [<c04f0eb8>] (down_read+0x2c/0x3c) from [<c0068708>]
> (__blocking_notifier_call_chain+0x30/0x60)
> [   24.691711] [<c0068708>] (__blocking_notifier_call_chain+0x30/0x60)
> from [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
> [   24.691741] [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
> from [<c02ce1c0>] (fb_blank+0x34/0x98)
> [   24.691741] [<c02ce1c0>] (fb_blank+0x34/0x98) from [<c02cecb0>]
> (do_fb_ioctl+0x218/0x5d8)
> [   24.691772] [<c02cecb0>] (do_fb_ioctl+0x218/0x5d8) from
> [<c0114924>] (do_vfs_ioctl+0x80/0x5f0)
> [   24.691772] [<c0114924>] (do_vfs_ioctl+0x80/0x5f0) from
> [<c0114f04>] (sys_ioctl+0x70/0x78)
> [   24.691802] [<c0114f04>] (sys_ioctl+0x70/0x78) from [<c00130c0>]
> (ret_fast_syscall+0x0/0x3c)
>
> I will look at this, but just wanted to ask first in case I missed
> some patches that already fix this.
>
> My complete .config [1], dmesg [2] and xorg.conf [3].
>
> Thanks a lot and best regards,
> Javier
>
> [1]: http://fpaste.org/DJgw/
> [2]: http://fpaste.org/XEs5/
> [3]: http://fpaste.org/dhWd/

I've confirmed that this is the same issue that Steve had
(dss_ovl_simple_check() failing due info->paddr == 0), so I tried his
patch to force dss_ovl_simple_check() to always succeed. The second
SETUP_PLANE ioctl doesn't fail anymore and I can see Xorg server is
running.

But still I don't have any output on the screen. Any hints will be appreciated.

Here is my complete dmesg:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.7.0-00017-g6c2ecfb-dirty (javier@munra)
(gcc version 4.6.3 (crosstool-NG linaro-1.13.1+bzr2368 - Linaro GCC
2012.03) ) #155 SMP Tue Dec 18 12:14:19 CET 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine: IGEP v2 board
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 130816
[    0.000000] free_area_init_node: node 0, pgdat c07e09c0,
node_mem_map c0d40000
[    0.000000]   Normal zone: 1024 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 129792 pages, LIFO batch:31
[    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[    0.000000] PERCPU: Embedded 9 pages/cpu @c1148000 s12992 r8192 d15680 u36864
[    0.000000] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 129792
[    0.000000] Kernel command line: console=ttyO2,115200n8
mpurate=auto vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y
omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Memory: 511MB = 511MB total
[    0.000000] Memory: 505132k/505132k available, 19156k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc06fc424   (7122 kB)
[    0.000000]       .init : 0xc06fd000 - 0xc07512c0   ( 337 kB)
[    0.000000]       .data : 0xc0752000 - 0xc07e3388   ( 581 kB)
[    0.000000]        .bss : 0xc07e33ac - 0xc0d3fab0   (5490 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96
interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns,
wraps every 131071999ms
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.001007] Calibrating delay loop... 397.57 BogoMIPS (lpj=1554432)
[    0.109374] pid_max: default: 32768 minimum: 301
[    0.109954] Security Framework initialized
[    0.110107] Mount-cache hash table entries: 512
[    0.114685] CPU: Testing write buffer coherency: ok
[    0.115509] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.115570] Setting up static identity map for 0x804f8070 - 0x804f80e0
[    0.118194] Brought up 1 CPUs
[    0.118225] SMP: Total of 1 processors activated (397.57 BogoMIPS).
[    0.121429] devtmpfs: initialized
[    0.178405] pinctrl core: initialized pinctrl subsystem
[    0.185058] regulator-dummy: no parameters
[    0.187011] NET: Registered protocol family 16
[    0.187896] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.189819] omap-gpmc omap-gpmc: GPMC revision 5.0
[    0.200897] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.201385] OMAP GPIO hardware version 2.5
[    0.203857] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.206451] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.208709] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.211242] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[    0.213562] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[    0.220794] omap_mux_init: Add partition: #1: core, flags: 4
[    0.223358] IGEP2: Hardware Revision C (B-NON compatible)
[    0.230804] _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx
[    0.239440] Reprogramming SDRC clock to 400000000 Hz
[    0.240264] IGEP: initializing NAND memory device
[    0.252227] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.267913]  omap-mcbsp.2: alias fck already exists
[    0.268707]  omap-mcbsp.3: alias fck already exists
[    0.272338] OMAP DMA hardware revision 5.0
[    0.276702]  arm-pmu: alias fck already exists
[    0.342346] bio: create slab <bio-0> at 0
[    0.432434] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[    0.433410] fixed-dummy: no parameters
[    0.434448] vwlan: 3300 mV normal
[    0.441284] SCSI subsystem initialized
[    0.443695] usbcore: registered new interface driver usbfs
[    0.444213] usbcore: registered new interface driver hub
[    0.445007] usbcore: registered new device driver usb
[    0.450622] omap_i2c omap_i2c.3: bus 3 rev1.4.0 at 100 kHz
[    0.464324] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
[    0.464965] twl 1-0048: power (irq 343) chaining IRQs 346..353
[    0.467926] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
[    0.468353] gpiochip_find_base: found new base at 492
[    0.469909] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030
[    0.480804] VIO: 1800 mV normal standby
[    0.483184] vdd_mpu_iva: 600 <--> 1450 mV normal
[    0.485565] vdd_core: 600 <--> 1450 mV normal
[    0.487762] VMMC1: 1850 <--> 3150 mV at 3150 mV normal standby
[    0.490661] VDVI: 1800 mV normal standby
[    0.491485] omap_i2c omap_i2c.1: bus 1 rev1.4.0 at 2600 kHz
[    0.499176] Switching to clocksource 32k_counter
[    0.643341] NET: Registered protocol family 2
[    0.645416] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.645721] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
[    0.647979] TCP: Hash tables configured (established 4096 bind 4096)
[    0.648681] TCP: reno registered
[    0.648712] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.649047] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.650085] NET: Registered protocol family 1
[    0.651397] RPC: Registered named UNIX socket transport module.
[    0.651428] RPC: Registered udp transport module.
[    0.651458] RPC: Registered tcp transport module.
[    0.651458] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.652557] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.652893] CPU PMU: probing PMU on CPU 0
[    0.652923] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver,
5 counters available
[    0.842712] VFS: Disk quotas dquot_6.5.2
[    0.843048] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.846191] NFS: Registering the id_resolver key type
[    0.846679] Key type id_resolver registered
[    0.846710] Key type id_legacy registered
[    0.846862] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    0.847442] msgmni has been set to 986
[    0.851013] io scheduler noop registered
[    0.851043] io scheduler deadline registered
[    0.851135] io scheduler cfq registered (default)
[    0.855895] OMAP DSS rev 2.0
[    0.888336] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.896820] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0
[    0.899444] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1
[    0.901397] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2
[    1.611419] console [ttyO2] enabled
[    1.617340] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 96) is a OMAP UART3
[    1.662353] brd: module loaded
[    1.687408] loop: module loaded
[    1.698608] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.706298] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc
(Micron NAND 512MiB 1,8V 16-bit), page size: 2048, OOB size: 64
[    1.718414] Creating 5 MTD partitions on "omap2-nand.0":
[    1.724029] 0x000000000000-0x000000080000 : "X-Loader"
[    1.737426] 0x000000080000-0x000000200000 : "U-Boot"
[    1.748809] 0x000000200000-0x000000280000 : "Environment"
[    1.760040] 0x000000280000-0x000000580000 : "Kernel"
[    1.772552] 0x000000580000-0x000020000000 : "File System"
[    2.223999] OneNAND driver initializing
[    2.238800] smsc911x: Driver version 2008-10-21
[    2.251861] libphy: smsc911x-mdio: probed
[    2.256439] smsc911x smsc911x.0 eth0: attached PHY driver [SMSC
LAN8700] (mii_bus:phy_addr=smsc911x-0:01, irq=-1)
[    2.268829] smsc911x smsc911x.0 eth0: MAC Address: 4e:5f:57:5d:d2:c5
[    2.277496] usbcore: registered new interface driver asix
[    2.283813] usbcore: registered new interface driver cdc_ether
[    2.290618] usbcore: registered new interface driver smsc95xx
[    2.297241] usbcore: registered new interface driver net1080
[    2.303680] usbcore: registered new interface driver cdc_subset
[    2.310485] usbcore: registered new interface driver zaurus
[    2.316955] usbcore: registered new interface driver cdc_ncm
[    2.325286] usbcore: registered new interface driver cdc_wdm
[    2.331359] Initializing USB Mass Storage driver...
[    2.337097] usbcore: registered new interface driver usb-storage
[    2.343505] USB Mass Storage support registered.
[    2.348937] usbcore: registered new interface driver usbtest
[    2.357238] mousedev: PS/2 mouse device common for all mice
[    2.365661] input: TWL4030 Keypad as
/devices/platform/omap_i2c.1/i2c-1/1-004a/twl4030_keypad/input/input0
[    2.384185] input: twl4030_pwrbutton as
/devices/platform/omap_i2c.1/i2c-1/1-004b/twl4030_pwrbutton/input/input1
[    2.397186] twl_rtc twl_rtc: Power up reset detected.
[    2.404022] twl_rtc twl_rtc: Enabling TWL-RTC
[    2.413330] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    2.421386] i2c /dev entries driver
[    2.428680] Driver for 1-wire Dallas network protocol.
[    2.438079] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[    2.446624] twl4030_wdt twl4030_wdt: Failed to register misc device
[    2.453460] twl4030_wdt: probe of twl4030_wdt failed with error -16
[    2.463409] omap-dma-engine omap-dma-engine: allocating channel for 48
[    2.470550] omap-dma-engine omap-dma-engine: allocating channel for 47
[    2.525421] omap-dma-engine omap-dma-engine: allocating channel for 62
[    2.532470] omap-dma-engine omap-dma-engine: allocating channel for 61
[    2.569366] mmc0: new SDIO card at address 0001
[    2.920196] usbcore: registered new interface driver usbhid
[    2.926239] usbhid: USB HID core driver
[    2.932037] oprofile: using arm/armv7
[    2.936737] TCP: cubic registered
[    2.940338] Initializing XFRM netlink socket
[    2.945068] NET: Registered protocol family 17
[    2.949859] NET: Registered protocol family 15
[    2.955017] Key type dns_resolver registered
[    2.959655] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[    2.978881] ThumbEE CPU extension supported.
[    2.991058] OMAPFB: omapfb_init
[    2.991302] OMAPFB: omapfb_probe
[    2.994323] fbcvt: 1024x768@60: CVT Name - .786M3-R
[    2.999938] OMAPFB: create 3 framebuffers
[    2.999999] OMAPFB: fb_infos allocated
[    2.999999] OMAPFB: allocating 1572864 bytes for fb 0
[    3.002807] OMAPFB: allocated VRAM paddr 9f600000, vaddr e090c000
[    3.002838] OMAPFB: region0 phys 9f600000 virt e090c000 size=1572864
[    3.002868] OMAPFB: region1 phys 00000000 virt   (null) size=0
[    3.002868] OMAPFB: region2 phys 00000000 virt   (null) size=0
[    3.002868] OMAPFB: fbmems allocated
[    3.003082] OMAPFB: check_fb_var 0
[    3.003082] OMAPFB: max frame size 1572864, line size 2048
[    3.003112] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768
[    3.003143] OMAPFB: set_fb_fix
[    3.005126] OMAPFB: fb_infos initialized
[    3.010009] OMAPFB: set_par(0)
[    3.010070] OMAPFB: set_fb_fix
[    3.010070] OMAPFB: apply_changes, fb 0, ovl 0
[    3.010131] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[    3.010162] OMAPFB: paddr 9f600000
[    3.010314] OMAPFB: pan_display(0)
[    3.010314] OMAPFB: setcmap
[    3.010345] OMAPFB: setcmap
[    3.019195] Console: switching to colour frame buffer device 128x48
[    3.019195] OMAPFB: pan_display(0)
[    3.019195] OMAPFB: setcmap
[    3.027313] OMAPFB: setcmap
[    3.036560] OMAPFB: framebuffers registered
[    3.036590] OMAPFB: apply_changes, fb 0, ovl 0
[    3.036621] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[    3.036621] OMAPFB: paddr 9f600000
[    3.036682] OMAPFB: apply_changes, fb 1, ovl 1
[    3.036743] OMAPFB: apply_changes, fb 2, ovl 2
[    3.036834] OMAPFB: create_framebuffers done
[    3.036865] OMAPFB: mgr->apply'ed
[    3.039794] OMAPFB: create sysfs for fbs
[    3.039825] OMAPFB: create sysfs for fbs
[    3.041259] VDVI: incomplete constraints, leaving on
[    3.051971] twl_rtc twl_rtc: setting system clock to 2000-01-01
00:00:00 UTC (946684800)
[    3.065521] Waiting for root device /dev/mmcblk0p2...
[    3.222808] mmc1: host does not support reading read-only switch.
assuming write-enable.
[    3.231597] mmc1: new SDHC card at address e624
[    3.238830] mmcblk0: mmc1:e624 SU08G 7.40 GiB
[    3.255645]  mmcblk0: p1 p2
[    3.322967] EXT4-fs (mmcblk0p2): warning: maximal mount count
reached, running e2fsck is recommended
[    3.341094] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    3.349884] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    3.381835] devtmpfs: mounted
[    3.385833] Freeing init memory: 336K
[    4.150543] OMAPFB: pan_display(0)
[    4.150573] OMAPFB: setcmap
[    4.150573] OMAPFB: setcmap
[    4.161651] OMAPFB: user mmap region start 9f600000, len 1572864,
off 9f600000
>[    4.548126] udevd[780]: starting version 182
[    7.068847] omap-twl4030 omap-twl4030: ASoC: CPU DAI omap-mcbsp.2
not registered
[    7.076965] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
[    7.084411] platform omap-twl4030: Driver omap-twl4030 requests
probe deferral
[    7.171356] omap-twl4030 omap-twl4030: ASoC: CODEC twl4030-codec
not registered
[    7.179565] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
[    7.186950] platform omap-twl4030: Driver omap-twl4030 requests
probe deferral
[    7.387695] lib80211: common routines for IEEE802.11 drivers
[    7.394042] lib80211_crypt: registered algorithm 'NULL'
[    7.551940] omap-twl4030 omap-twl4030: ASoC: CODEC twl4030-codec
not registered
[    7.560028] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
[    7.567504] platform omap-twl4030: Driver omap-twl4030 requests
probe deferral
[    8.216064] cfg80211: Calling CRDA to update world regulatory domain
[    8.364746] omap-twl4030 omap-twl4030:  twl4030-hifi <->
omap-mcbsp.2 mapping ok
[    8.573333] libertas_sdio: Libertas SDIO driver
[    8.578369] libertas_sdio: Copyright Pierre Ossman
[   11.256774] libertas_sdio: failed to find firmware (-2)
[   12.367126] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
[   13.176910] smsc911x smsc911x.0 eth0: SMSC911x/921x identified at
0xe08c8000, IRQ: 290
[   24.423065] OMAPFB: check_var(0)
[   24.423156] OMAPFB: check_fb_var 0
[   24.423187] OMAPFB: max frame size 1572864, line size 2048
[   24.423187] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768
[   24.423278] OMAPFB: set_par(0)
[   24.423278] OMAPFB: set_fb_fix
[   24.423278] OMAPFB: apply_changes, fb 0, ovl 0
[   24.423339] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[   24.423339] OMAPFB: paddr 9f600000
[   24.423858] OMAPFB: pan_display(0)
[   24.423858] OMAPFB: setcmap
[   24.423950] OMAPFB: pan_display(0)
[   24.423950] OMAPFB: setcmap
[   24.423950] OMAPFB: setcmap
[   24.433532] OMAPFB: setcmap
[   24.436462] OMAPFB: ioctl GET_CAPS
[   24.436676] OMAPFB: ioctl QUERY_MEM
[   24.445281] OMAPFB: user mmap region start 9f600000, len 1572864,
off 9f600000
[   24.547180] OMAPFB: ioctl QUERY_PLANE
[   24.547302] OMAPFB: ioctl SETUP_PLANE
[   24.547302] OMAPFB: omapfb_setup_plane
[   24.547424] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[   24.547424] OMAPFB: paddr 9f600000
[   24.547790]
[   24.547790] ======================================================
[   24.547790] [ INFO: possible circular locking dependency detected ]
[   24.547821] 3.7.0-00017-g6c2ecfb-dirty #155 Not tainted
[   24.547821] -------------------------------------------------------
[   24.547821] Xorg/1277 is trying to acquire lock:
[   24.547882]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0068708>]
__blocking_notifier_call_chain+0x30/0x60
[   24.547882]
[   24.547882] but task is already holding lock:
[   24.547912]  (console_lock){+.+.+.}, at: [<c02cec98>] do_fb_ioctl+0x200/0x5d8
[   24.547912]
[   24.547912] which lock already depends on the new lock.
[   24.547912]
[   24.547912]
[   24.547912] the existing dependency chain (in reverse order) is:
[   24.547943]
[   24.547943] -> #1 (console_lock){+.+.+.}:
[   24.547943]        [<c00902a4>] lock_acquire+0x9c/0x124
[   24.547973]        [<c0042b0c>] console_lock+0x50/0x64
[   24.548004]        [<c0320bcc>] register_con_driver+0x38/0x134
[   24.548004]        [<c032219c>] take_over_console+0x18/0x44
[   24.548034]        [<c02d7674>] fbcon_takeover+0x64/0xc8
[   24.548034]        [<c04f4dd4>] notifier_call_chain+0x44/0x84
[   24.548065]        [<c0068720>] __blocking_notifier_call_chain+0x48/0x60
[   24.548065]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
[   24.548095]        [<c02cf654>] register_framebuffer+0x16c/0x23c
[   24.548095]        [<c04ee990>] omapfb_create_framebuffers+0x520/0x700
[   24.548126]        [<c0723480>] omapfb_probe+0x4e4/0x768
[   24.548126]        [<c03399f4>] platform_drv_probe+0x18/0x1c
[   24.548156]        [<c03387b0>] driver_probe_device+0x78/0x210
[   24.548187]        [<c03389dc>] __driver_attach+0x94/0x98
[   24.548187]        [<c03370b0>] bus_for_each_dev+0x50/0x7c
[   24.548187]        [<c0337fdc>] bus_add_driver+0x178/0x240
[   24.548217]        [<c0338eac>] driver_register+0x78/0x144
[   24.548217]        [<c0339be4>] platform_driver_probe+0x18/0x9c
[   24.548248]        [<c0722f70>] omapfb_init+0x28/0x54
[   24.548248]        [<c00086a4>] do_one_initcall+0x34/0x178
[   24.548278]        [<c04e47a8>] kernel_init+0x100/0x2b4
[   24.548309]        [<c0013170>] ret_from_fork+0x14/0x24
[   24.548309]
[   24.548309] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
[   24.548339]        [<c008f85c>] __lock_acquire+0x15e4/0x1b00
[   24.548339]        [<c00902a4>] lock_acquire+0x9c/0x124
[   24.548370]        [<c04f0eb8>] down_read+0x2c/0x3c
[   24.548370]        [<c0068708>] __blocking_notifier_call_chain+0x30/0x60
[   24.548370]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
[   24.548400]        [<c02ce1c0>] fb_blank+0x34/0x98
[   24.548400]        [<c02cecb0>] do_fb_ioctl+0x218/0x5d8
[   24.548431]        [<c0114924>] do_vfs_ioctl+0x80/0x5f0
[   24.548431]        [<c0114f04>] sys_ioctl+0x70/0x78
[   24.548461]        [<c00130c0>] ret_fast_syscall+0x0/0x3c
[   24.548461]
[   24.548461] other info that might help us debug this:
[   24.548461]
[   24.548461]  Possible unsafe locking scenario:
[   24.548461]
[   24.548461]        CPU0                    CPU1
[   24.548461]        ----                    ----
[   24.548492]   lock(console_lock);
[   24.548492]                                lock((fb_notifier_list).rwsem);
[   24.548492]                                lock(console_lock);
[   24.548522]   lock((fb_notifier_list).rwsem);
[   24.548522]
[   24.548522]  *** DEADLOCK ***
[   24.548522]
[   24.548522] 2 locks held by Xorg/1277:
[   24.548553]  #0:  (&fb_info->lock){+.+.+.}, at: [<c02cdf9c>]
lock_fb_info+0x18/0x3c
[   24.548583]  #1:  (console_lock){+.+.+.}, at: [<c02cec98>]
do_fb_ioctl+0x200/0x5d8
[   24.548583]
[   24.548583] stack backtrace:
[   24.548614] [<c001ac2c>] (unwind_backtrace+0x0/0xf0) from
[<c04eb508>] (print_circular_bug+0x278/0x2c4)
[   24.548614] [<c04eb508>] (print_circular_bug+0x278/0x2c4) from
[<c008f85c>] (__lock_acquire+0x15e4/0x1b00)
[   24.548645] [<c008f85c>] (__lock_acquire+0x15e4/0x1b00) from
[<c00902a4>] (lock_acquire+0x9c/0x124)
[   24.548675] [<c00902a4>] (lock_acquire+0x9c/0x124) from
[<c04f0eb8>] (down_read+0x2c/0x3c)
[   24.548675] [<c04f0eb8>] (down_read+0x2c/0x3c) from [<c0068708>]
(__blocking_notifier_call_chain+0x30/0x60)
[   24.548706] [<c0068708>] (__blocking_notifier_call_chain+0x30/0x60)
from [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
[   24.548706] [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
from [<c02ce1c0>] (fb_blank+0x34/0x98)
[   24.548736] [<c02ce1c0>] (fb_blank+0x34/0x98) from [<c02cecb0>]
(do_fb_ioctl+0x218/0x5d8)
[   24.548736] [<c02cecb0>] (do_fb_ioctl+0x218/0x5d8) from
[<c0114924>] (do_vfs_ioctl+0x80/0x5f0)
[   24.548767] [<c0114924>] (do_vfs_ioctl+0x80/0x5f0) from
[<c0114f04>] (sys_ioctl+0x70/0x78)
[   24.548797] [<c0114f04>] (sys_ioctl+0x70/0x78) from [<c00130c0>]
(ret_fast_syscall+0x0/0x3c)
[   25.008056] OMAPFB: ioctl QUERY_PLANE
[   25.011962] OMAPFB: ioctl SETUP_PLANE
[   25.015930] OMAPFB: omapfb_setup_plane
[   25.019897] omapdss OVERLAY error: check_overlay: paddr cannot be 0
[   25.026580] omapdss OVERLAY error: check_overlay: overlay 2 doesn't
support mode 0
[   25.034576] omapdss OVERLAY error: check_overlay: rotation type 0
not supported
[   25.044525] OMAPFB: ioctl QUERY_MEM
[   25.048339] OMAPFB: ioctl QUERY_PLANE
[   25.052215] OMAPFB: ioctl GET_CAPS
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap DSS fails with tft410 driver panel?

[Javier Martinez Canillas]

On Tue, Dec 18, 2012 at 12:23 PM, Javier Martinez Canillas
<martinez.javier@gmail.com> wrote:
> On Tue, Dec 18, 2012 at 9:31 AM, Javier Martinez Canillas
> <martinez.javier@gmail.com> wrote:
>> On Thu, Nov 29, 2012 at 3:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2012-11-29 16:53, Steve Sakoman wrote:
>>>> On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>
>>>>>> It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)
>>>>>
>>>>> Still can't reproduce. So does the null pointer deref happen at boot
>>>>> time? What display related kernel boot options do you have? This looks
>>>>> funny, considering lcd43 is a bit smaller lcd:
>>>>
>>>> Yes, it happens at boot time.
>>>>
>>>> The boot options:
>>>>
>>>> [    0.000000] Kernel command line: console=ttyO2,115200n8 mpurate=500
>>>> vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43
>>>> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
>>>
>>> Ok, now I see it. It happens because DVI is not configured to be used,
>>> but you have DVI video mode specified in the command line.
>>>
>>> I'll study this further and make a fix.
>>>
>>>  Tomi
>>>
>>>
>>>
>>
>> Hello folks,
>>
>> Did you find a solution for this?
>>
>> I still have the issue, when trying to start X I got:
>>
>> [   25.152160] OMAPFB: ioctl QUERY_PLANE
>> [   25.156066] OMAPFB: ioctl SETUP_PLANE
>> [   25.160095] OMAPFB: omapfb_setup_plane
>> [   25.164093] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>> [   25.170684] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>> [   25.177337] omapfb omapfb: setup_plane failed
>> [   25.181976] OMAPFB: ioctl failed: -22
>>
>> I'm using the arm-soc.git tree with the latest fixes and cleanups for
>> v3.8 sent by Tony yesterday and Xorg 1.13.
>>
>> The latest commit id is:
>>
>> commit aad05c3602ba5c42ff8d0e572b2f614f25779ede
>> Merge: eccf4b3 f64d204
>> Author: Olof Johansson <olof@lixom.net>
>> Date:   Mon Dec 17 18:44:26 2012 -0800
>>
>>     Merge branch 'late/omap-cleanup' into for-next
>>
>> I've CONFIG_OMAP2_DSS, CONFIG_FB_OMAP2 and CONFIG_PANEL_TFP410
>> built-in and this is my kernel command line is:
>>
>> console=ttyO2,115200n8 mpurate=auto vram=12M
>> omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi
>> root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>>
>> Also I have this log about a locking dependency:
>>
>> [   24.690795]
>> [   24.690826] ======================================================
>> [   24.690826] [ INFO: possible circular locking dependency detected ]
>> [   24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted
>> [   24.690826] -------------------------------------------------------
>> [   24.690826] Xorg/1259 is trying to acquire lock:
>> [   24.690887]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0068708>]
>> __blocking_notifier_call_chain+0x30/0x60
>> [   24.690887]
>> [   24.690887] but task is already holding lock:
>> [   24.690917]  (console_lock){+.+.+.}, at: [<c02cec98>] do_fb_ioctl+0x200/0x5d8
>> [   24.690917]
>> [   24.690917] which lock already depends on the new lock.
>> [   24.690917]
>> [   24.690917]
>> [   24.690917] the existing dependency chain (in reverse order) is:
>> [   24.690948]
>> [   24.690948] -> #1 (console_lock){+.+.+.}:
>> [   24.690979]        [<c00902a4>] lock_acquire+0x9c/0x124
>> [   24.690979]        [<c0042b0c>] console_lock+0x50/0x64
>> [   24.691009]        [<c0320bd0>] register_con_driver+0x38/0x134
>> [   24.691009]        [<c03221a0>] take_over_console+0x18/0x44
>> [   24.691040]        [<c02d7674>] fbcon_takeover+0x64/0xc8
>> [   24.691070]        [<c04f4dd4>] notifier_call_chain+0x44/0x84
>> [   24.691070]        [<c0068720>] __blocking_notifier_call_chain+0x48/0x60
>> [   24.691070]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
>> [   24.691101]        [<c02cf654>] register_framebuffer+0x16c/0x23c
>> [   24.691131]        [<c04ee990>] omapfb_create_framebuffers+0x520/0x700
>> [   24.691131]        [<c0723480>] omapfb_probe+0x4e4/0x768
>> [   24.691162]        [<c03399f8>] platform_drv_probe+0x18/0x1c
>> [   24.691162]        [<c03387b4>] driver_probe_device+0x78/0x210
>> [   24.691192]        [<c03389e0>] __driver_attach+0x94/0x98
>> [   24.691192]        [<c03370b4>] bus_for_each_dev+0x50/0x7c
>> [   24.691223]        [<c0337fe0>] bus_add_driver+0x178/0x240
>> [   24.691223]        [<c0338eb0>] driver_register+0x78/0x144
>> [   24.691253]        [<c0339be8>] platform_driver_probe+0x18/0x9c
>> [   24.691253]        [<c0722f70>] omapfb_init+0x28/0x54
>> [   24.691284]        [<c00086a4>] do_one_initcall+0x34/0x178
>> [   24.691284]        [<c04e47ac>] kernel_init+0x100/0x2b4
>> [   24.691314]        [<c0013170>] ret_from_fork+0x14/0x24
>> [   24.691314]
>> [   24.691314] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
>> [   24.691345]        [<c008f85c>] __lock_acquire+0x15e4/0x1b00
>> [   24.691345]        [<c00902a4>] lock_acquire+0x9c/0x124
>> [   24.691375]        [<c04f0eb8>] down_read+0x2c/0x3c
>> [   24.691375]        [<c0068708>] __blocking_notifier_call_chain+0x30/0x60
>> [   24.691406]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
>> [   24.691406]        [<c02ce1c0>] fb_blank+0x34/0x98
>> [   24.691436]        [<c02cecb0>] do_fb_ioctl+0x218/0x5d8
>> [   24.691436]        [<c0114924>] do_vfs_ioctl+0x80/0x5f0
>> [   24.691467]        [<c0114f04>] sys_ioctl+0x70/0x78
>> [   24.691467]        [<c00130c0>] ret_fast_syscall+0x0/0x3c
>> [   24.691467]
>> [   24.691467] other info that might help us debug this:
>> [   24.691467]
>> [   24.691497]  Possible unsafe locking scenario:
>> [   24.691497]
>> [   24.691497]        CPU0                    CPU1
>> [   24.691497]        ----                    ----
>> [   24.691497]   lock(console_lock);
>> [   24.691497]                                lock((fb_notifier_list).rwsem);
>> [   24.691528]                                lock(console_lock);
>> [   24.691528]   lock((fb_notifier_list).rwsem);
>> [   24.691528]
>> [   24.691528]  *** DEADLOCK ***
>> [   24.691528]
>> [   24.691528] 2 locks held by Xorg/1259:
>> [   24.691558]  #0:  (&fb_info->lock){+.+.+.}, at: [<c02cdf9c>]
>> lock_fb_info+0x18/0x3c
>> [   24.691589]  #1:  (console_lock){+.+.+.}, at: [<c02cec98>]
>> do_fb_ioctl+0x200/0x5d8
>> [   24.691589]
>> [   24.691589] stack backtrace:
>> [   24.691619] [<c001ac2c>] (unwind_backtrace+0x0/0xf0) from
>> [<c04eb508>] (print_circular_bug+0x278/0x2c4)
>> [   24.691650] [<c04eb508>] (print_circular_bug+0x278/0x2c4) from
>> [<c008f85c>] (__lock_acquire+0x15e4/0x1b00)
>> [   24.691650] [<c008f85c>] (__lock_acquire+0x15e4/0x1b00) from
>> [<c00902a4>] (lock_acquire+0x9c/0x124)
>> [   24.691680] [<c00902a4>] (lock_acquire+0x9c/0x124) from
>> [<c04f0eb8>] (down_read+0x2c/0x3c)
>> [   24.691711] [<c04f0eb8>] (down_read+0x2c/0x3c) from [<c0068708>]
>> (__blocking_notifier_call_chain+0x30/0x60)
>> [   24.691711] [<c0068708>] (__blocking_notifier_call_chain+0x30/0x60)
>> from [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
>> [   24.691741] [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
>> from [<c02ce1c0>] (fb_blank+0x34/0x98)
>> [   24.691741] [<c02ce1c0>] (fb_blank+0x34/0x98) from [<c02cecb0>]
>> (do_fb_ioctl+0x218/0x5d8)
>> [   24.691772] [<c02cecb0>] (do_fb_ioctl+0x218/0x5d8) from
>> [<c0114924>] (do_vfs_ioctl+0x80/0x5f0)
>> [   24.691772] [<c0114924>] (do_vfs_ioctl+0x80/0x5f0) from
>> [<c0114f04>] (sys_ioctl+0x70/0x78)
>> [   24.691802] [<c0114f04>] (sys_ioctl+0x70/0x78) from [<c00130c0>]
>> (ret_fast_syscall+0x0/0x3c)
>>
>> I will look at this, but just wanted to ask first in case I missed
>> some patches that already fix this.
>>
>> My complete .config [1], dmesg [2] and xorg.conf [3].
>>
>> Thanks a lot and best regards,
>> Javier
>>
>> [1]: http://fpaste.org/DJgw/
>> [2]: http://fpaste.org/XEs5/
>> [3]: http://fpaste.org/dhWd/
>
> I've confirmed that this is the same issue that Steve had
> (dss_ovl_simple_check() failing due info->paddr == 0), so I tried his
> patch to force dss_ovl_simple_check() to always succeed. The second
> SETUP_PLANE ioctl doesn't fail anymore and I can see Xorg server is
> running.
>
> But still I don't have any output on the screen. Any hints will be appreciated.
>
> Here is my complete dmesg:
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.7.0-00017-g6c2ecfb-dirty (javier@munra)
> (gcc version 4.6.3 (crosstool-NG linaro-1.13.1+bzr2368 - Linaro GCC
> 2012.03) ) #155 SMP Tue Dec 18 12:14:19 CET 2012
> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine: IGEP v2 board
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] On node 0 totalpages: 130816
> [    0.000000] free_area_init_node: node 0, pgdat c07e09c0,
> node_mem_map c0d40000
> [    0.000000]   Normal zone: 1024 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 129792 pages, LIFO batch:31
> [    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
> [    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
> [    0.000000] PERCPU: Embedded 9 pages/cpu @c1148000 s12992 r8192 d15680 u36864
> [    0.000000] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
> [    0.000000] pcpu-alloc: [0] 0
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 129792
> [    0.000000] Kernel command line: console=ttyO2,115200n8
> mpurate=auto vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y
> omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
> [    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] __ex_table already sorted, skipping sort
> [    0.000000] Memory: 511MB = 511MB total
> [    0.000000] Memory: 505132k/505132k available, 19156k reserved, 0K highmem
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc06fc424   (7122 kB)
> [    0.000000]       .init : 0xc06fd000 - 0xc07512c0   ( 337 kB)
> [    0.000000]       .data : 0xc0752000 - 0xc07e3388   ( 581 kB)
> [    0.000000]        .bss : 0xc07e33ac - 0xc0d3fab0   (5490 kB)
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96
> interrupts
> [    0.000000] Total of 96 interrupts on 1 active controller
> [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
> [    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns,
> wraps every 131071999ms
> [    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
> [    0.000000] Console: colour dummy device 80x30
> [    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat,
> Inc., Ingo Molnar
> [    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
> [    0.000000] ... MAX_LOCK_DEPTH:          48
> [    0.000000] ... MAX_LOCKDEP_KEYS:        8191
> [    0.000000] ... CLASSHASH_SIZE:          4096
> [    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
> [    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
> [    0.000000] ... CHAINHASH_SIZE:          16384
> [    0.000000]  memory used by lock dependency info: 3695 kB
> [    0.000000]  per task-struct memory footprint: 1152 bytes
> [    0.001007] Calibrating delay loop... 397.57 BogoMIPS (lpj=1554432)
> [    0.109374] pid_max: default: 32768 minimum: 301
> [    0.109954] Security Framework initialized
> [    0.110107] Mount-cache hash table entries: 512
> [    0.114685] CPU: Testing write buffer coherency: ok
> [    0.115509] CPU0: thread -1, cpu 0, socket -1, mpidr 0
> [    0.115570] Setting up static identity map for 0x804f8070 - 0x804f80e0
> [    0.118194] Brought up 1 CPUs
> [    0.118225] SMP: Total of 1 processors activated (397.57 BogoMIPS).
> [    0.121429] devtmpfs: initialized
> [    0.178405] pinctrl core: initialized pinctrl subsystem
> [    0.185058] regulator-dummy: no parameters
> [    0.187011] NET: Registered protocol family 16
> [    0.187896] DMA: preallocated 256 KiB pool for atomic coherent allocations
> [    0.189819] omap-gpmc omap-gpmc: GPMC revision 5.0
> [    0.200897] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
> [    0.201385] OMAP GPIO hardware version 2.5
> [    0.203857] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
> [    0.206451] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
> [    0.208709] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
> [    0.211242] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
> [    0.213562] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
> [    0.220794] omap_mux_init: Add partition: #1: core, flags: 4
> [    0.223358] IGEP2: Hardware Revision C (B-NON compatible)
> [    0.230804] _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx
> [    0.239440] Reprogramming SDRC clock to 400000000 Hz
> [    0.240264] IGEP: initializing NAND memory device
> [    0.252227] hw-breakpoint: debug architecture 0x4 unsupported.
> [    0.267913]  omap-mcbsp.2: alias fck already exists
> [    0.268707]  omap-mcbsp.3: alias fck already exists
> [    0.272338] OMAP DMA hardware revision 5.0
> [    0.276702]  arm-pmu: alias fck already exists
> [    0.342346] bio: create slab <bio-0> at 0
> [    0.432434] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
> [    0.433410] fixed-dummy: no parameters
> [    0.434448] vwlan: 3300 mV normal
> [    0.441284] SCSI subsystem initialized
> [    0.443695] usbcore: registered new interface driver usbfs
> [    0.444213] usbcore: registered new interface driver hub
> [    0.445007] usbcore: registered new device driver usb
> [    0.450622] omap_i2c omap_i2c.3: bus 3 rev1.4.0 at 100 kHz
> [    0.464324] twl 1-0048: PIH (irq 23) chaining IRQs 338..346
> [    0.464965] twl 1-0048: power (irq 343) chaining IRQs 346..353
> [    0.467926] twl4030_gpio twl4030_gpio: gpio (irq 338) chaining IRQs 354..371
> [    0.468353] gpiochip_find_base: found new base at 492
> [    0.469909] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030
> [    0.480804] VIO: 1800 mV normal standby
> [    0.483184] vdd_mpu_iva: 600 <--> 1450 mV normal
> [    0.485565] vdd_core: 600 <--> 1450 mV normal
> [    0.487762] VMMC1: 1850 <--> 3150 mV at 3150 mV normal standby
> [    0.490661] VDVI: 1800 mV normal standby
> [    0.491485] omap_i2c omap_i2c.1: bus 1 rev1.4.0 at 2600 kHz
> [    0.499176] Switching to clocksource 32k_counter
> [    0.643341] NET: Registered protocol family 2
> [    0.645416] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> [    0.645721] TCP bind hash table entries: 4096 (order: 5, 147456 bytes)
> [    0.647979] TCP: Hash tables configured (established 4096 bind 4096)
> [    0.648681] TCP: reno registered
> [    0.648712] UDP hash table entries: 256 (order: 2, 20480 bytes)
> [    0.649047] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
> [    0.650085] NET: Registered protocol family 1
> [    0.651397] RPC: Registered named UNIX socket transport module.
> [    0.651428] RPC: Registered udp transport module.
> [    0.651458] RPC: Registered tcp transport module.
> [    0.651458] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.652557] NetWinder Floating Point Emulator V0.97 (double precision)
> [    0.652893] CPU PMU: probing PMU on CPU 0
> [    0.652923] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver,
> 5 counters available
> [    0.842712] VFS: Disk quotas dquot_6.5.2
> [    0.843048] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [    0.846191] NFS: Registering the id_resolver key type
> [    0.846679] Key type id_resolver registered
> [    0.846710] Key type id_legacy registered
> [    0.846862] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
> [    0.847442] msgmni has been set to 986
> [    0.851013] io scheduler noop registered
> [    0.851043] io scheduler deadline registered
> [    0.851135] io scheduler cfq registered (default)
> [    0.855895] OMAP DSS rev 2.0
> [    0.888336] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.896820] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0
> [    0.899444] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1
> [    0.901397] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 90) is a OMAP UART2
> [    1.611419] console [ttyO2] enabled
> [    1.617340] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 96) is a OMAP UART3
> [    1.662353] brd: module loaded
> [    1.687408] loop: module loaded
> [    1.698608] mtdoops: mtd device (mtddev=name/number) must be supplied
> [    1.706298] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc
> (Micron NAND 512MiB 1,8V 16-bit), page size: 2048, OOB size: 64
> [    1.718414] Creating 5 MTD partitions on "omap2-nand.0":
> [    1.724029] 0x000000000000-0x000000080000 : "X-Loader"
> [    1.737426] 0x000000080000-0x000000200000 : "U-Boot"
> [    1.748809] 0x000000200000-0x000000280000 : "Environment"
> [    1.760040] 0x000000280000-0x000000580000 : "Kernel"
> [    1.772552] 0x000000580000-0x000020000000 : "File System"
> [    2.223999] OneNAND driver initializing
> [    2.238800] smsc911x: Driver version 2008-10-21
> [    2.251861] libphy: smsc911x-mdio: probed
> [    2.256439] smsc911x smsc911x.0 eth0: attached PHY driver [SMSC
> LAN8700] (mii_bus:phy_addr=smsc911x-0:01, irq=-1)
> [    2.268829] smsc911x smsc911x.0 eth0: MAC Address: 4e:5f:57:5d:d2:c5
> [    2.277496] usbcore: registered new interface driver asix
> [    2.283813] usbcore: registered new interface driver cdc_ether
> [    2.290618] usbcore: registered new interface driver smsc95xx
> [    2.297241] usbcore: registered new interface driver net1080
> [    2.303680] usbcore: registered new interface driver cdc_subset
> [    2.310485] usbcore: registered new interface driver zaurus
> [    2.316955] usbcore: registered new interface driver cdc_ncm
> [    2.325286] usbcore: registered new interface driver cdc_wdm
> [    2.331359] Initializing USB Mass Storage driver...
> [    2.337097] usbcore: registered new interface driver usb-storage
> [    2.343505] USB Mass Storage support registered.
> [    2.348937] usbcore: registered new interface driver usbtest
> [    2.357238] mousedev: PS/2 mouse device common for all mice
> [    2.365661] input: TWL4030 Keypad as
> /devices/platform/omap_i2c.1/i2c-1/1-004a/twl4030_keypad/input/input0
> [    2.384185] input: twl4030_pwrbutton as
> /devices/platform/omap_i2c.1/i2c-1/1-004b/twl4030_pwrbutton/input/input1
> [    2.397186] twl_rtc twl_rtc: Power up reset detected.
> [    2.404022] twl_rtc twl_rtc: Enabling TWL-RTC
> [    2.413330] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
> [    2.421386] i2c /dev entries driver
> [    2.428680] Driver for 1-wire Dallas network protocol.
> [    2.438079] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
> [    2.446624] twl4030_wdt twl4030_wdt: Failed to register misc device
> [    2.453460] twl4030_wdt: probe of twl4030_wdt failed with error -16
> [    2.463409] omap-dma-engine omap-dma-engine: allocating channel for 48
> [    2.470550] omap-dma-engine omap-dma-engine: allocating channel for 47
> [    2.525421] omap-dma-engine omap-dma-engine: allocating channel for 62
> [    2.532470] omap-dma-engine omap-dma-engine: allocating channel for 61
> [    2.569366] mmc0: new SDIO card at address 0001
> [    2.920196] usbcore: registered new interface driver usbhid
> [    2.926239] usbhid: USB HID core driver
> [    2.932037] oprofile: using arm/armv7
> [    2.936737] TCP: cubic registered
> [    2.940338] Initializing XFRM netlink socket
> [    2.945068] NET: Registered protocol family 17
> [    2.949859] NET: Registered protocol family 15
> [    2.955017] Key type dns_resolver registered
> [    2.959655] VFP support v0.3: implementor 41 architecture 3 part 30
> variant c rev 3
> [    2.978881] ThumbEE CPU extension supported.
> [    2.991058] OMAPFB: omapfb_init
> [    2.991302] OMAPFB: omapfb_probe
> [    2.994323] fbcvt: 1024x768@60: CVT Name - .786M3-R
> [    2.999938] OMAPFB: create 3 framebuffers
> [    2.999999] OMAPFB: fb_infos allocated
> [    2.999999] OMAPFB: allocating 1572864 bytes for fb 0
> [    3.002807] OMAPFB: allocated VRAM paddr 9f600000, vaddr e090c000
> [    3.002838] OMAPFB: region0 phys 9f600000 virt e090c000 size=1572864
> [    3.002868] OMAPFB: region1 phys 00000000 virt   (null) size=0
> [    3.002868] OMAPFB: region2 phys 00000000 virt   (null) size=0
> [    3.002868] OMAPFB: fbmems allocated
> [    3.003082] OMAPFB: check_fb_var 0
> [    3.003082] OMAPFB: max frame size 1572864, line size 2048
> [    3.003112] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768
> [    3.003143] OMAPFB: set_fb_fix
> [    3.005126] OMAPFB: fb_infos initialized
> [    3.010009] OMAPFB: set_par(0)
> [    3.010070] OMAPFB: set_fb_fix
> [    3.010070] OMAPFB: apply_changes, fb 0, ovl 0
> [    3.010131] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [    3.010162] OMAPFB: paddr 9f600000
> [    3.010314] OMAPFB: pan_display(0)
> [    3.010314] OMAPFB: setcmap
> [    3.010345] OMAPFB: setcmap
> [    3.019195] Console: switching to colour frame buffer device 128x48
> [    3.019195] OMAPFB: pan_display(0)
> [    3.019195] OMAPFB: setcmap
> [    3.027313] OMAPFB: setcmap
> [    3.036560] OMAPFB: framebuffers registered
> [    3.036590] OMAPFB: apply_changes, fb 0, ovl 0
> [    3.036621] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [    3.036621] OMAPFB: paddr 9f600000
> [    3.036682] OMAPFB: apply_changes, fb 1, ovl 1
> [    3.036743] OMAPFB: apply_changes, fb 2, ovl 2
> [    3.036834] OMAPFB: create_framebuffers done
> [    3.036865] OMAPFB: mgr->apply'ed
> [    3.039794] OMAPFB: create sysfs for fbs
> [    3.039825] OMAPFB: create sysfs for fbs
> [    3.041259] VDVI: incomplete constraints, leaving on
> [    3.051971] twl_rtc twl_rtc: setting system clock to 2000-01-01
> 00:00:00 UTC (946684800)
> [    3.065521] Waiting for root device /dev/mmcblk0p2...
> [    3.222808] mmc1: host does not support reading read-only switch.
> assuming write-enable.
> [    3.231597] mmc1: new SDHC card at address e624
> [    3.238830] mmcblk0: mmc1:e624 SU08G 7.40 GiB
> [    3.255645]  mmcblk0: p1 p2
> [    3.322967] EXT4-fs (mmcblk0p2): warning: maximal mount count
> reached, running e2fsck is recommended
> [    3.341094] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [    3.349884] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [    3.381835] devtmpfs: mounted
> [    3.385833] Freeing init memory: 336K
> [    4.150543] OMAPFB: pan_display(0)
> [    4.150573] OMAPFB: setcmap
> [    4.150573] OMAPFB: setcmap
> [    4.161651] OMAPFB: user mmap region start 9f600000, len 1572864,
> off 9f600000
>>[    4.548126] udevd[780]: starting version 182
> [    7.068847] omap-twl4030 omap-twl4030: ASoC: CPU DAI omap-mcbsp.2
> not registered
> [    7.076965] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
> [    7.084411] platform omap-twl4030: Driver omap-twl4030 requests
> probe deferral
> [    7.171356] omap-twl4030 omap-twl4030: ASoC: CODEC twl4030-codec
> not registered
> [    7.179565] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
> [    7.186950] platform omap-twl4030: Driver omap-twl4030 requests
> probe deferral
> [    7.387695] lib80211: common routines for IEEE802.11 drivers
> [    7.394042] lib80211_crypt: registered algorithm 'NULL'
> [    7.551940] omap-twl4030 omap-twl4030: ASoC: CODEC twl4030-codec
> not registered
> [    7.560028] omap-twl4030 omap-twl4030: snd_soc_register_card() failed: -517
> [    7.567504] platform omap-twl4030: Driver omap-twl4030 requests
> probe deferral
> [    8.216064] cfg80211: Calling CRDA to update world regulatory domain
> [    8.364746] omap-twl4030 omap-twl4030:  twl4030-hifi <->
> omap-mcbsp.2 mapping ok
> [    8.573333] libertas_sdio: Libertas SDIO driver
> [    8.578369] libertas_sdio: Copyright Pierre Ossman
> [   11.256774] libertas_sdio: failed to find firmware (-2)
> [   12.367126] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
> [   13.176910] smsc911x smsc911x.0 eth0: SMSC911x/921x identified at
> 0xe08c8000, IRQ: 290
> [   24.423065] OMAPFB: check_var(0)
> [   24.423156] OMAPFB: check_fb_var 0
> [   24.423187] OMAPFB: max frame size 1572864, line size 2048
> [   24.423187] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768
> [   24.423278] OMAPFB: set_par(0)
> [   24.423278] OMAPFB: set_fb_fix
> [   24.423278] OMAPFB: apply_changes, fb 0, ovl 0
> [   24.423339] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [   24.423339] OMAPFB: paddr 9f600000
> [   24.423858] OMAPFB: pan_display(0)
> [   24.423858] OMAPFB: setcmap
> [   24.423950] OMAPFB: pan_display(0)
> [   24.423950] OMAPFB: setcmap
> [   24.423950] OMAPFB: setcmap
> [   24.433532] OMAPFB: setcmap
> [   24.436462] OMAPFB: ioctl GET_CAPS
> [   24.436676] OMAPFB: ioctl QUERY_MEM
> [   24.445281] OMAPFB: user mmap region start 9f600000, len 1572864,
> off 9f600000
> [   24.547180] OMAPFB: ioctl QUERY_PLANE
> [   24.547302] OMAPFB: ioctl SETUP_PLANE
> [   24.547302] OMAPFB: omapfb_setup_plane
> [   24.547424] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [   24.547424] OMAPFB: paddr 9f600000
> [   24.547790]
> [   24.547790] ======================================================
> [   24.547790] [ INFO: possible circular locking dependency detected ]
> [   24.547821] 3.7.0-00017-g6c2ecfb-dirty #155 Not tainted
> [   24.547821] -------------------------------------------------------
> [   24.547821] Xorg/1277 is trying to acquire lock:
> [   24.547882]  ((fb_notifier_list).rwsem){.+.+.+}, at: [<c0068708>]
> __blocking_notifier_call_chain+0x30/0x60
> [   24.547882]
> [   24.547882] but task is already holding lock:
> [   24.547912]  (console_lock){+.+.+.}, at: [<c02cec98>] do_fb_ioctl+0x200/0x5d8
> [   24.547912]
> [   24.547912] which lock already depends on the new lock.
> [   24.547912]
> [   24.547912]
> [   24.547912] the existing dependency chain (in reverse order) is:
> [   24.547943]
> [   24.547943] -> #1 (console_lock){+.+.+.}:
> [   24.547943]        [<c00902a4>] lock_acquire+0x9c/0x124
> [   24.547973]        [<c0042b0c>] console_lock+0x50/0x64
> [   24.548004]        [<c0320bcc>] register_con_driver+0x38/0x134
> [   24.548004]        [<c032219c>] take_over_console+0x18/0x44
> [   24.548034]        [<c02d7674>] fbcon_takeover+0x64/0xc8
> [   24.548034]        [<c04f4dd4>] notifier_call_chain+0x44/0x84
> [   24.548065]        [<c0068720>] __blocking_notifier_call_chain+0x48/0x60
> [   24.548065]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
> [   24.548095]        [<c02cf654>] register_framebuffer+0x16c/0x23c
> [   24.548095]        [<c04ee990>] omapfb_create_framebuffers+0x520/0x700
> [   24.548126]        [<c0723480>] omapfb_probe+0x4e4/0x768
> [   24.548126]        [<c03399f4>] platform_drv_probe+0x18/0x1c
> [   24.548156]        [<c03387b0>] driver_probe_device+0x78/0x210
> [   24.548187]        [<c03389dc>] __driver_attach+0x94/0x98
> [   24.548187]        [<c03370b0>] bus_for_each_dev+0x50/0x7c
> [   24.548187]        [<c0337fdc>] bus_add_driver+0x178/0x240
> [   24.548217]        [<c0338eac>] driver_register+0x78/0x144
> [   24.548217]        [<c0339be4>] platform_driver_probe+0x18/0x9c
> [   24.548248]        [<c0722f70>] omapfb_init+0x28/0x54
> [   24.548248]        [<c00086a4>] do_one_initcall+0x34/0x178
> [   24.548278]        [<c04e47a8>] kernel_init+0x100/0x2b4
> [   24.548309]        [<c0013170>] ret_from_fork+0x14/0x24
> [   24.548309]
> [   24.548309] -> #0 ((fb_notifier_list).rwsem){.+.+.+}:
> [   24.548339]        [<c008f85c>] __lock_acquire+0x15e4/0x1b00
> [   24.548339]        [<c00902a4>] lock_acquire+0x9c/0x124
> [   24.548370]        [<c04f0eb8>] down_read+0x2c/0x3c
> [   24.548370]        [<c0068708>] __blocking_notifier_call_chain+0x30/0x60
> [   24.548370]        [<c0068750>] blocking_notifier_call_chain+0x18/0x20
> [   24.548400]        [<c02ce1c0>] fb_blank+0x34/0x98
> [   24.548400]        [<c02cecb0>] do_fb_ioctl+0x218/0x5d8
> [   24.548431]        [<c0114924>] do_vfs_ioctl+0x80/0x5f0
> [   24.548431]        [<c0114f04>] sys_ioctl+0x70/0x78
> [   24.548461]        [<c00130c0>] ret_fast_syscall+0x0/0x3c
> [   24.548461]
> [   24.548461] other info that might help us debug this:
> [   24.548461]
> [   24.548461]  Possible unsafe locking scenario:
> [   24.548461]
> [   24.548461]        CPU0                    CPU1
> [   24.548461]        ----                    ----
> [   24.548492]   lock(console_lock);
> [   24.548492]                                lock((fb_notifier_list).rwsem);
> [   24.548492]                                lock(console_lock);
> [   24.548522]   lock((fb_notifier_list).rwsem);
> [   24.548522]
> [   24.548522]  *** DEADLOCK ***
> [   24.548522]
> [   24.548522] 2 locks held by Xorg/1277:
> [   24.548553]  #0:  (&fb_info->lock){+.+.+.}, at: [<c02cdf9c>]
> lock_fb_info+0x18/0x3c
> [   24.548583]  #1:  (console_lock){+.+.+.}, at: [<c02cec98>]
> do_fb_ioctl+0x200/0x5d8
> [   24.548583]
> [   24.548583] stack backtrace:
> [   24.548614] [<c001ac2c>] (unwind_backtrace+0x0/0xf0) from
> [<c04eb508>] (print_circular_bug+0x278/0x2c4)
> [   24.548614] [<c04eb508>] (print_circular_bug+0x278/0x2c4) from
> [<c008f85c>] (__lock_acquire+0x15e4/0x1b00)
> [   24.548645] [<c008f85c>] (__lock_acquire+0x15e4/0x1b00) from
> [<c00902a4>] (lock_acquire+0x9c/0x124)
> [   24.548675] [<c00902a4>] (lock_acquire+0x9c/0x124) from
> [<c04f0eb8>] (down_read+0x2c/0x3c)
> [   24.548675] [<c04f0eb8>] (down_read+0x2c/0x3c) from [<c0068708>]
> (__blocking_notifier_call_chain+0x30/0x60)
> [   24.548706] [<c0068708>] (__blocking_notifier_call_chain+0x30/0x60)
> from [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
> [   24.548706] [<c0068750>] (blocking_notifier_call_chain+0x18/0x20)
> from [<c02ce1c0>] (fb_blank+0x34/0x98)
> [   24.548736] [<c02ce1c0>] (fb_blank+0x34/0x98) from [<c02cecb0>]
> (do_fb_ioctl+0x218/0x5d8)
> [   24.548736] [<c02cecb0>] (do_fb_ioctl+0x218/0x5d8) from
> [<c0114924>] (do_vfs_ioctl+0x80/0x5f0)
> [   24.548767] [<c0114924>] (do_vfs_ioctl+0x80/0x5f0) from
> [<c0114f04>] (sys_ioctl+0x70/0x78)
> [   24.548797] [<c0114f04>] (sys_ioctl+0x70/0x78) from [<c00130c0>]
> (ret_fast_syscall+0x0/0x3c)
> [   25.008056] OMAPFB: ioctl QUERY_PLANE
> [   25.011962] OMAPFB: ioctl SETUP_PLANE
> [   25.015930] OMAPFB: omapfb_setup_plane
> [   25.019897] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> [   25.026580] omapdss OVERLAY error: check_overlay: overlay 2 doesn't
> support mode 0
> [   25.034576] omapdss OVERLAY error: check_overlay: rotation type 0
> not supported
> [   25.044525] OMAPFB: ioctl QUERY_MEM
> [   25.048339] OMAPFB: ioctl QUERY_PLANE
> [   25.052215] OMAPFB: ioctl GET_CAPS

Hi,

I've tested with the latest stable kernel (Linux 3.7.1) and the video
output is working correctly with the same user-space components.
The complete dmesg is here: http://fpaste.org/1Kv4/

Looking at the logs for both kernels I realized that there are two
differences main between the working (3.7.1) and non-working
(mainline) kernel (besides the versions of course):

a) The number of framebuffers created (working 1, non working 3)
b) The omapfb now uses dma_alloc_attrs to allocate memory instead of
the now removed OMAP-specific omap_vram_alloc

For a) I built mainline with CONFIG_FB_OMAP2_NUM_FBS=1 and that made
the error about the overlay paddr being zero disappear (OVERLAY error:
check_overlay: paddr cannot be 0) but still no video on the screen.

Conversely I build 3.7.1 with CONFIG_FB_OMAP2_NUM_FBS=3 and even
though I had the paddr can't be zero error, video is working
correctly. So it seems that error shouldn't affect the video display.

For b) I tried to built mainline with CONFIG_CMA=y but it didn't work either.

Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On 2012-12-18 10:31, Javier Martinez Canillas wrote:

> Did you find a solution for this?

Not that I know.

> Also I have this log about a locking dependency:
> 
> [   24.690795]
> [   24.690826] ======================================================
> [   24.690826] [ INFO: possible circular locking dependency detected ]
> [   24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted
> [   24.690826] -------------------------------------------------------

I've also seen these. But they don't seem to happen with linux-next (or
Linus' current tree). I haven't been able to figure out the reason for
the warning, but as they seem to have disappeared, they may be related
to something else than omapfb/omapdss.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

On 2012-12-18 15:45, Javier Martinez Canillas wrote:
> Hi,
> 
> I've tested with the latest stable kernel (Linux 3.7.1) and the video
> output is working correctly with the same user-space components.
> The complete dmesg is here: http://fpaste.org/1Kv4/
> 
> Looking at the logs for both kernels I realized that there are two
> differences main between the working (3.7.1) and non-working
> (mainline) kernel (besides the versions of course):
> 
> a) The number of framebuffers created (working 1, non working 3)
> b) The omapfb now uses dma_alloc_attrs to allocate memory instead of
> the now removed OMAP-specific omap_vram_alloc
> 
> For a) I built mainline with CONFIG_FB_OMAP2_NUM_FBS=1 and that made
> the error about the overlay paddr being zero disappear (OVERLAY error:
> check_overlay: paddr cannot be 0) but still no video on the screen.

Ok. I think the reason for that is that the paddr errors come from X
trying to setup the video overlays with paddr 0. The video overlays are
by default on fb1 and fb2, so they are not present if you set the
NUM_FBS to 1.

> Conversely I build 3.7.1 with CONFIG_FB_OMAP2_NUM_FBS=3 and even
> though I had the paddr can't be zero error, video is working
> correctly. So it seems that error shouldn't affect the video display.

Hmm, so do you get any display with 3.8, before X is started, using
plain fb? For example, break the boot before X is started, and do

cat /dev/urandom > /dev/fb0

Do you have an userspace image I could download to reproduce this?

> For b) I tried to built mainline with CONFIG_CMA=y but it didn't work either.

I don't think the vram change affects this, except if you see errors
about mem alloc. But yes, I think you should enable CMA with 3.8,
although allocation may work fine for smaller displays even without CMA.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: omap DSS fails with tft410 driver panel?

[Javier Martinez Canillas]

On Wed, Dec 19, 2012 at 9:33 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2012-12-18 15:45, Javier Martinez Canillas wrote:
>> Hi,
>>
>> I've tested with the latest stable kernel (Linux 3.7.1) and the video
>> output is working correctly with the same user-space components.
>> The complete dmesg is here: http://fpaste.org/1Kv4/
>>
>> Looking at the logs for both kernels I realized that there are two
>> differences main between the working (3.7.1) and non-working
>> (mainline) kernel (besides the versions of course):
>>
>> a) The number of framebuffers created (working 1, non working 3)
>> b) The omapfb now uses dma_alloc_attrs to allocate memory instead of
>> the now removed OMAP-specific omap_vram_alloc
>>
>> For a) I built mainline with CONFIG_FB_OMAP2_NUM_FBS=1 and that made
>> the error about the overlay paddr being zero disappear (OVERLAY error:
>> check_overlay: paddr cannot be 0) but still no video on the screen.
>
> Ok. I think the reason for that is that the paddr errors come from X
> trying to setup the video overlays with paddr 0. The video overlays are
> by default on fb1 and fb2, so they are not present if you set the
> NUM_FBS to 1.
>

Yes, that's what I thought, I'll just use CONFIG_FB_OMAP2_NUM_FBS=1
then on my defconfig.

>> Conversely I build 3.7.1 with CONFIG_FB_OMAP2_NUM_FBS=3 and even
>> though I had the paddr can't be zero error, video is working
>> correctly. So it seems that error shouldn't affect the video display.
>
> Hmm, so do you get any display with 3.8, before X is started, using
> plain fb? For example, break the boot before X is started, and do
>
> cat /dev/urandom > /dev/fb0
>
> Do you have an userspace image I could download to reproduce this?
>
>> For b) I tried to built mainline with CONFIG_CMA=y but it didn't work either.
>
> I don't think the vram change affects this, except if you see errors
> about mem alloc. But yes, I think you should enable CMA with 3.8,
> although allocation may work fine for smaller displays even without CMA.
>
>  Tomi
>
>

Hi Tomi,

At the end it was a red herring.

The problem was not in the kernel but in U-Boot that now only sets the
OMAP mux pins of the peripherals that uses. So the DSS OMAP mux pins
and the OMAP GPIO line that is used to power up the TFP410 chip has to
now be set in the kernel.

We will send a patch for the igep0020 board file to fix the issue.

Thanks a lot for your help and sorry for the noise!

Best regards,
Javier

Re: omap DSS fails with tft410 driver panel?

[Laurent Pinchart]

Hi Steve,

On Wednesday 21 November 2012 16:08:06 Steve Sakoman wrote:
> On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra
> 
> <eballetbo@gmail.com> wrote:
> > I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
> > tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
> > changes the panel driver used on some boards. I tested current
> > linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
> > 
> > following error (see http://pastebin.com/VjPGCQDt for full log) :
> >    [   21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> >    [   21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> >    [   21.236236] omapfb omapfb: setup_plane failed
> 
> Was there ever any resolution to this issue?

Does mainline commit 950e2fb420d54bf0ee0de2fb0f146827a98330bf help ?

> I am seeing the same errors on Overo.  The video output actually
> works, but it appears that this error causes X to close and then
> restart repeatedly.
> 
> I'll add the printk's to omapfb_setup_plane() that were requested by
> Tomi and report back.

-- 
Regards,

Laurent Pinchart

Re: omap DSS fails with tft410 driver panel?

[Javier Martinez Canillas]

On Fri, Dec 21, 2012 at 9:30 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Steve,
>
> On Wednesday 21 November 2012 16:08:06 Steve Sakoman wrote:
>> On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra
>>
>> <eballetbo@gmail.com> wrote:
>> > I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to
>> > tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410)
>> > changes the panel driver used on some boards. I tested current
>> > linux-next-20101011 kernel with my IGEPv2 board and DSS fails with
>> >
>> > following error (see http://pastebin.com/VjPGCQDt for full log) :
>> >    [ 21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>> >    [ 21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0
>> >    [ 21.236236] omapfb omapfb: setup_plane failed
>>
>> Was there ever any resolution to this issue?
>
> Does mainline commit 950e2fb420d54bf0ee0de2fb0f146827a98330bf help ?
>

Hi Laurent,

I just tried today's mainline kernel which has:

950e2fb [media] omap_vout: use omapdss's version instead of cpu_is_*

but I still see the log message "omapdss OVERLAY error: check_overlay:
paddr cannot be 0" (full log: http://fpaste.org/jOBo/)

This doesn't affect the video display though since the framebuffer
video is working correctly.

Setting CONFIG_FB_OMAP2_NUM_FBS=1 in my .config makes the error
message disappear since the paddr is correctly
set for the first overlay:

[    3.175842] OMAPFB: allocated VRAM paddr 9e900000, vaddr de900000
[    3.182891] OMAPFB: paddr 9e900000

Best regards,
Javier

Re: omap DSS fails with tft410 driver panel?

[pawel cern]

Try adding kernel bootargs, lets say: vram=48M omapfb.vram=0:16M,1:16M,2:16M

And see what happens.