[plug] Kernel hacking advice needed

[Jeremy Kerr]

Hi Owain,

> Ok - I'm running 2.6 kernel and there is actually a module that
> someone has kindly written in linux/drivers/mcp23s08.c,

Looks good. Are you required to use a 2.6 kernel though? They're getting
pretty old now..

> so I followed
> another board definition (arch/arm/mach-at91/board-cdu.c) which had
> set up the driver and modified it to my own situation:
> 
> /*
> * SPI devices.
> */
> #define MCP23S08_GPIO_BASE 128
> 
> static const struct mcp23s08_platform_data mcp23s08_gpio_info = {
> .chip[0].is_present = true,
> .chip[0].pullups = 0,
> .base = MCP23S08_GPIO_BASE,
> };
> 
> and:
> 
> { /* GPIO expander MCP23S08 */
> .modalias = "mcp23s08",
> .chip_select = 1,
> .max_speed_hz = 1000000,
> .bus_num = 3,
> .platform_data = &mcp23s08_gpio_info,
> .mode = SPI_MODE_3,
> },
> 
> It looks like the kernel driver makes the device appear as a generic
> gpio. So I looked for a spi device to appear in my sysfs and there it
> was /sys/class/gpio/gpio128 and I can access what I think are the the
> individual gpio pins. The problem is that when I bias the pins the
> values don't change and when I put a my little logic analyser on the
> spi pins of the chip I  see spi traffic to other devices on the spi
> bus,

So it sounds like the SPI master is being initialised correctly then? Is
the mxp23s08 device (electrically) connected to the same master as your
other working SPI devices?

> but the chip select (which I can toggle using the sysfs gpio
> functions) from the arm processor is not being activated at all.

I'd check the following:

 * That your mcp23s08 device is being registered to the correct SPI
   master (spi_register_board_info will match the bus_num from your
   struct spi_board_info to a master with the same number). You can
   poke around your Linux device hierarchy in the /sys filesystem.

 * That the chip_select member of your struct spi_board_info is correct

(I don't have a 2.6 kernel handy, so this is based on 3.8; sorry if
things have changed since then!)
> 
> Now, I suppose I'm at a bit of a loss what to do, my experience in
> kernel hacking is limited (hence the looking for online resources to
> help :) ).
> 
> Firstly I'm in embedded land and don't really have the full set of
> tools that I'm used to. When I modprobe the module I don't get any
> errors on my serial console, but I don't have access to dmesg - so I'm
> not too sure where any kernel messages are being put - I know that
> printk messages are sent to the serial console I'm monitoring.

That should be sufficient then. Might be good to put 'debug' on the
kernel command line so that you get all levels of printk messages.

A couple of other tips:

 * if you '#define DEBUG' at the top of a kernel source file, the
   pr_debug() macros will be expanded to printk(KERN_DEBUG ...).
   You'll need to add this before all includes though.

 * if your serial console is bidirectional (and depending on the
   userspace you're using), you may be able to just start a shell
   on the serial device, which will give you dmesg output, and
   allow you to poke around in /sys

> And
> when I tried to compile a debug kernel and run it with gdb I ran out
> of memory!

Yeah, the debugging symbols are pretty huge. Debugging via printk is
often the easiest way of doing things.

Cheers,


Jeremy


> P.S. Apologies for not putting a [plug] in the first message

P.S. The list does that for you :)