All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@epfl.ch>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Longchamp Valentin <valentin.longchamp@epfl.ch>,
	"linux-arm-kernel@lists.arm.linux.org.uk"
	<linux-arm-kernel@lists.arm.linux.org.uk>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Dan Williams <dan.j.williams@intel.com>,
	"linux-fbdev-devel@lists.sourceforge.net"
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH 2/4 v8] i.MX31: Image Processing Unit DMA and IRQ drivers
Date: Fri, 23 Jan 2009 14:01:53 +0100	[thread overview]
Message-ID: <4979BFC1.1070504@epfl.ch> (raw)
In-Reply-To: <Pine.LNX.4.64.0901231308040.4463@axis700.grange>

Guennadi Liakhovetski wrote:
> On Fri, 23 Jan 2009, Valentin Longchamp wrote:
>> I think something is working badly with the initcall (subsys). Has
>> someone already experienced something similar ?
> 
> Strange, try to look which initcalls are before and after ipu_init in your 
> kernel:
> 
> arm-linux-objdump -Dr vmlinux |grep __initcall_ |less
> 
> which on my kernel produces
> 
> ...
> c0019c6c <__initcall_input_init4>:
> c0019c70 <__initcall_ipu_init4>:
> c0019c74 <__initcall_proto_init4>:
> ...
> 
> and see whether those other two initcalls get called, if they do, then 
> either you're running a different kernel from the one you're looking at, 
> or it _does_ get called and you're debugging wrongly, or you have a very 
> selective memory corruption, or... a miracle is taking place.
> 

Well no miracle is taking place (And I have checked, the kernel I am
running is the correct one according to the build date tag with uname).
For me the initcalls are:

c0019390 <__initcall_misc_init4>:
c0019394 <__initcall_ipu_init4>:
c0019398 <__initcall_proto_init4>:

(Not exactly the same addresses as before because I add some pr_debug
calls for debug). But none of them are called. And all of them are
subsys_initcall. Do I have to enable something in my configuration so
that these initcall actually get called ?

However, they all have the same "look" so to say: no real ARM assembly
instruction but only addresses as Russel pointed it before:

> c0019390 <__initcall_misc_init4>:
> c0019390:       c001349c        .word   0xc001349c
> 
> c0019394 <__initcall_ipu_init4>:
> c0019394:       c0014258        .word   0xc0014258
> 
> c0019398 <__initcall_proto_init4>:
> c0019398:       c00143e4        .word   0xc00143e4

This may be the reason why these initcall are not actually called:
Guennadi's ones had a real ARM assembly instruction. To solve all my
problems I need to understand why my subsys_initcall do not get called.

Thank you all for your great help

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

  reply	other threads:[~2009-01-23 13:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 18:04 [PATCH 0/4 v8] i.MX31: dmaengine and framebuffer drivers Guennadi Liakhovetski
2009-01-08 18:04 ` Guennadi Liakhovetski
2009-01-08 18:04 ` [PATCH 1/4 v8] dmaengine: add async_tx_clear_ack() macro Guennadi Liakhovetski
2009-01-08 18:04 ` [PATCH 2/4 v8] i.MX31: Image Processing Unit DMA and IRQ drivers Guennadi Liakhovetski
2009-01-16  9:59   ` Sascha Hauer
2009-01-22 18:51   ` Valentin Longchamp
2009-01-22 19:04     ` Guennadi Liakhovetski
2009-01-22 19:48       ` Valentin Longchamp
2009-01-22 20:27         ` Guennadi Liakhovetski
2009-01-23  9:30           ` Valentin Longchamp
2009-01-23  9:46             ` Guennadi Liakhovetski
2009-01-23 11:22               ` Valentin Longchamp
2009-01-23 11:34                 ` Russell King - ARM Linux
2009-01-23 12:13                 ` Guennadi Liakhovetski
2009-01-23 13:01                   ` Valentin Longchamp [this message]
2009-01-23 13:08                     ` Russell King - ARM Linux
2009-01-23 13:12                     ` Guennadi Liakhovetski
2009-01-23 13:18                       ` Russell King - ARM Linux
2009-01-23 13:21                         ` Valentin Longchamp
2009-01-23 13:25                           ` Russell King - ARM Linux
2009-01-23 13:27                           ` Guennadi Liakhovetski
2009-01-23 13:54                           ` Holger Schurig
2009-01-23 20:55                           ` Robert Schwebel
2009-01-23 13:22                         ` Guennadi Liakhovetski
2009-01-23 13:26                           ` Russell King - ARM Linux
2009-01-23 14:51               ` Valentin Longchamp
2009-01-23 15:09                 ` Valentin Longchamp
2009-01-08 18:05 ` [PATCH 3/4 v8] i.MX31: framebuffer driver Guennadi Liakhovetski
2009-01-08 18:05   ` Guennadi Liakhovetski
2009-01-16 10:00   ` Sascha Hauer
2009-01-08 18:05 ` [PATCH 4/4 v8] i.MX31: platform bindings and initialisation for IPU and framebuffer drivers Guennadi Liakhovetski
2009-01-08 18:05   ` Guennadi Liakhovetski
2009-01-09  8:17 ` [PATCH 0/4 v8] i.MX31: dmaengine " Sascha Hauer
2009-01-09  8:27   ` Guennadi Liakhovetski
2009-01-09 10:09     ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4979BFC1.1070504@epfl.ch \
    --to=valentin.longchamp@epfl.ch \
    --cc=dan.j.williams@intel.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.