Author Topic: Calling all Linux Kernel developers! (Read 399386 times)

tangrs · « **Reply #465 on:** December 03, 2012, 01:59:30 am »

Quote from: calc84maniac on December 03, 2012, 01:38:24 am

Pages have to be aligned to their size. What's with the random 0xfed7ee21 address?

For static memory mappings, you can choose where things are mapped to in virtual memory.

Edit: Fixed the nspireio issue. Latest commit should run on CXs fine.

willrandship · « **Reply #466 on:** December 03, 2012, 04:55:42 am »

I would point out that each of the series of rootfs files people post essentially counts as its own separate distro. It has about the same amount of difference at this level. So, keep that in mind before you go jumping for renaming the project.

Vogtinator · « **Reply #467 on:** December 03, 2012, 09:55:26 am »

I'm currently testing GPIOs with ndless. The binary (input) value of all ports toggles randomly between 0x59d00bf and 0x5bdoobf.
(Could also be periodically, sample rate is highest possible)
What is GPIO 21(0x020000)?
Also, the output value (0x80132d) doesn't vary at all. Isn't the touchpad connected to GPIOs 1 + 3?

Edit: Can I use GPIOs both as input and output? Example:
GPIO1 configured as output=HIGH, connected to ground through resistor.
Can I read input=LOW?

Edit2: With linux the gpio input still toggles randomly.
Should I implement an irq_chip for this? Directly setting, getting and changing direction are working. (At least the right values in the registers change)

Edit3: Could someone please test GPIOs? I don't know how.
http://dl.dropbox.com/u/105478372/zImagetest.tns
With useless i2c-gpio:
http://dl.dropbox.com/u/105478372/zImagetesti2c.tns

tangrs · « **Reply #468 on:** December 03, 2012, 08:17:50 pm »

Quote from: Vogtinator on December 03, 2012, 09:55:26 am

I'm currently testing GPIOs with ndless. The binary (input) value of all ports toggles randomly between 0x59d00bf and 0x5bdoobf.

That's probably to be expected. The pins are probably not connected to anything so it's floating.

Quote

(Could also be periodically, sample rate is highest possible)
What is GPIO 21(0x020000)?
Also, the output value (0x80132d) doesn't vary at all. Isn't the touchpad connected to GPIOs 1 + 3?

The output shouldn't vary at all unless you change it.

Quote

Edit: Can I use GPIOs both as input and output? Example:
GPIO1 configured as output=HIGH, connected to ground through resistor.
Can I read input=LOW?

I know you can do this with AVRs (people did this to make a cheap touch sensor - i.e. bring pin high and measure how long it actually takes to go high). Not sure with Nspires though.
[/quote]

Quote

Edit2: With linux the gpio input still toggles randomly.

Again, as expected from floating voltages.

Quote

Should I implement an irq_chip for this? Directly setting, getting and changing direction are working. (At least the right values in the registers change)

Why not?

Quote

Edit3: Could someone please test GPIOs? I don't know how.
http://dl.dropbox.com/u/105478372/zImagetest.tns
With useless i2c-gpio:
http://dl.dropbox.com/u/105478372/zImagetesti2c.tns

Best test for GPIO is the touchpad

Speaking of which, should the touchpad driver be a kernel driver or a userspace daemon (pulling strings with i2c and userspace uevents)?

Vsod99 · « **Reply #469 on:** December 03, 2012, 11:51:06 pm »

I'm trying to make sense of all this, is there a build released for touchpad models yet or not?

tangrs · « **Reply #470 on:** December 04, 2012, 12:55:57 am »

Quote from: Vsod99 on December 03, 2012, 11:51:06 pm

I'm trying to make sense of all this, is there a build released for touchpad models yet or not?

The source code has Touchpad support but no public build just yet. Lionel is helping to get nightly kernel builds up and running which will support all three models.

Of course, in the meanwhile, you can certainly build your own kernel by downloading the source off github or ask around if someone has a build.

Vogtinator · « **Reply #471 on:** December 04, 2012, 04:51:30 am »

Quote

That's probably to be expected. The pins are probably not connected to anything so it's floating.

One floating pin? I'd expect more pins to float, although it's bad engineering.

Quote

The output shouldn't vary at all unless you change it.

It has to be changed by the touchpad I²C driver.
The input and direction pins should do something, too.

Quote

I know you can do this with AVRs (people did this to make a cheap touch sensor - i.e. bring pin high and measure how long it actually takes to go high). Not sure with Nspires though.

I tried it myself and it worked better than I expected.
For i2c-gpio there's an option "scl_is_output_only", so I need to know whether it works..

Quote

Again, as expected from floating voltages.

More important, that says GPIOs are working under linux

Quote

Best test for GPIO is the touchpad :-P

But the touchpad seems to be not connected to GPIOs at all.
Or it could be the OS is not doing any i²c in background and I have to poll the touchpad.
I can't use touchpad_scan(touchpad_report_t) as it's not running in background.. Has someone an idea?

Quote

Speaking of which, should the touchpad driver be a kernel driver or a userspace daemon (pulling strings with i2c and userspace uevents)?

I²C can't be use for anything else than the touchpad, so a userspace implementation would only be more confusing.

willrandship · « **Reply #472 on:** December 04, 2012, 12:12:25 pm »

Well, of course i2c isn't still running in the background OS: You completely replaced it. Nothing is running in the background except what Linux knows to do. Is there a driver for the i2c protocol implemented yet? AFAIK direct GPIO works great for an i2c connection. According to wikipedia, standard protocol uses two drivers: One for the i2c itself (assuming there is a dedicated i2c chip) and one for the device connected to it. (Here, the touchpad). I think it would be a good idea to stick to that, so that if anyone ever tries to use the i2c for something else, like in a h/w project, they already have the i2c bus to work with. Plus, that should give access to any i2c device drivers that are available.

I found this wiki that may help development

Maybe we'll get lucky and find out the touchpad itself is already supported, and just the adapter needed a driver.

Vogtinator · « **Reply #473 on:** December 04, 2012, 12:26:57 pm »

Quote

Well, of course i2c isn't still running in the background OS: You completely replaced it. Nothing is running in the background except what Linux knows to do

No, im reading the GPIO registers with a C program started with ndless.

Quote

Is there a driver for the i2c protocol implemented yet?

Yes, i2c-gpio.

Quote

Maybe we'll get lucky and find out the touchpad itself is already supported, and just the adapter needed a driver.

If not, I think the serial mouse driver in linux will be a good example and it will be easy to port it to i²c.
Could be a bit harder if it uses interrupts, tough.

tangrs · « **Reply #474 on:** December 04, 2012, 05:42:09 pm »

Quote from: Vogtinator on December 04, 2012, 12:26:57 pm

No, im reading the GPIO registers with a C program started with ndless.

Ndless programs are started with interrupts off so the OS won't be able to update it.

Vogtinator · « **Reply #475 on:** December 05, 2012, 12:57:10 am »

Then how can I see how the OS is changing the GPIOs? Only in nspire_emu, if I compile it with custom debugging?
Simply re-enable interrupts?

Edit: As GPIOs generate only one interrupt (7) I have to use an irq_domain. But there are only 32 irq's available on the device.
Are there some kind of virtual interrupts?

Edit2: With "IRQ chained handlers" I now get almost infinite amount of interrupts.. The GPIO irqs don't want to stop, even after I did

Code: [Select]

for (irq = 0; irq < controller->chip.ngpio; irq += 8) {
	/* Sticky interrupt status */
	writew(0xFF, NSPIRE_GPIO(irq, INT_STICKY));
	/* Reset interrupt status */
	writew(0xFF, NSPIRE_GPIO(irq, INT_STATUS));
	/* Disable interrupts */
	writew(0xFF, NSPIRE_GPIO(irq, INT_DISABLE));
}

NSPIRE_GPIO returns the adress of the given register in the given GPIO section. (And works)
Edit3: Works now.. My error was elsewhere (as expected..).
But the touchpad doesn't, have to investigate that further, but it's hard without any hardware-debugging like scope..

Levak · « **Reply #476 on:** December 05, 2012, 05:49:05 pm »

Quote from: Vogtinator on December 05, 2012, 12:57:10 am

But the touchpad doesn't, have to investigate that further, but it's hard without any hardware-debugging like scope..

This ?
http://ndlessly.wordpress.com/2012/04/09/introducing-ocd-the-ti-nspire-on-calc-debugger/

tangrs · « **Reply #477 on:** December 05, 2012, 05:55:17 pm »

Quote from: Vogtinator on December 05, 2012, 12:57:10 am

Then how can I see how the OS is changing the GPIOs? Only in nspire_emu, if I compile it with custom debugging?
Simply re-enable interrupts?

Edit: As GPIOs generate only one interrupt (7) I have to use an irq_domain. But there are only 32 irq's available on the device.
Are there some kind of virtual interrupts?

IRQ domains are probably the way to go then. AFAIK, IRQ domains manage mappings over hardware to 'virtual' IRQs.

If you're referring the the NR_IRQS macro, I don't exactly know the correct value for the Nspire but 32 seems to work (lol). Feel free to fiddle around with it.

Vogtinator · « **Reply #478 on:** December 06, 2012, 01:28:27 am »

IRQ domain add legacy failed on boottime with a huge stack backtrace because of a warning on line 23, which gets shown if the irqs couldn't get reserved.
It still fails with nr_irqs 128..
But with irq_set_chained_handler it seems to work but still crashes if I enable interrupts on GPIO 21. I"ll try both, like mach-at91/gpio.c.
If I regiser the chained handler for the timer int, /proc/interrupts shows
18: GPIO timer
and the system is VERY slow (what makes sense, but it still works).

Levak: Sadly useless.. Does still run in foreground. If I poll the touchpad the function returns after it has the data..

Edit 2: If I enable int's for GPIO21 (the floating one), the kernel hangs. No soft-lockup, hard-lockup.
What could be the reasons? For the other GPIOs it works fine (they're not changing).

Code: [Select]

irq = request_irq(controller->irq, nspire_gpio_irq, 0, "gpio", controller);

static irqreturn_t nspire_gpio_irq(int irq, void *data)
{
    uint8_t pin, port;
    uint16_t status_val;
    uint16_t __iomem *status = NSPIRE_GPIO(0, INT_MASKED_STATUS);
    for (port = 0; port < controller->chip.ngpio; port += 8) {
        status_val = readw(status);
        /* Ack interrupt */
        writew(0xFF, status + (NSPIRE_GPIO_INT_STATUS_OFFSET
        - NSPIRE_GPIO_INT_MASKED_STATUS_OFFSET));
        status += NSPIRE_GPIO_SECTION_SIZE;
        //if(!status_val)
            continue;
        //Rest cut out
    }
    return IRQ_HANDLED;
}

Do I have to do some other calls for registering my IRQ? I think request_irq should do it.

Vogtinator · « **Reply #479 on:** December 07, 2012, 05:22:55 pm »

I just measured the outputs and inputs of some GPIOs connected to the pins on the bottom port, and it's correct.
They're even sensitive for fingertips..
The input of the pins 1 and 3 are always high, so there are indeed pullups.
But why does the touchpad not get detected? (At least not through i2cdetect)

Author Topic: Calling all Linux Kernel developers! (Read 399386 times)

tangrs

Re: Calling all Linux Kernel developers!

willrandship

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!

tangrs

Re: Calling all Linux Kernel developers!

Vsod99

Re: Calling all Linux Kernel developers!

tangrs

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!

willrandship

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!

tangrs

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!

Levak

Re: Calling all Linux Kernel developers!

tangrs

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!

Vogtinator

Re: Calling all Linux Kernel developers!