GPIO on LX2160a ARDB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

GPIO on LX2160a ARDB

1,804 Views
phoffmann
Contributor II

I'm trying to test GPIO by connecting 2 pins via a jumper on GPIO 3. Pin 1 is configured as an output and pin 2 is configured as an input. I've updated the RCW to enable GPIO (set EVT20_PMUX = 1).

My question is how do I correctly configure the GPIBE? Is there something in the devicetree that needs to be set for this to be configured? Or do I have to update the GPIO controller (gpio-mpc8xxx.c) to set the GPIBE?

I have configured the kernel with CONFIG_GPIO_SYSFS. I can use sysfs to configure the GPIOs, but I must use devmem2 to enable the GPIO port's input via the GPIO Input Buffer Enable Register (GPIBE). Once I set GPIBE, I'm able to set the value of the output GPIO pin and read the correct value at the GPIO pin.

When I look at the GPIO controller code (gpio-mpc8xxx.c), I can't see how the GPIBE is configured. I would have thought the code to do this would already be in the controller, since it looks like QorIQ T4240 also has a GPIBE register.

Does the LX2160a ARDB currently support the GPIO pins? I am using the LSDK rev 19.03.

Tags (3)
0 Kudos
4 Replies

1,572 Views
phoffmann
Contributor II

I figured out the problem by looking at the patches at https://lore.kernel.org/patchwork/project/lkml. You need to do the following to get the interrupt handling to work:
1. Apply the "Fix GPIO work fail" patch (1-2-arm64-dts-ls1028a-Fix-GPIO-work-fail.patch  -- this is the patch mentioned by Pavel)
2. Apply the ""Enable port input and interrupt" patch (1-3-gpio-mpc8xxx-Enable-port-input-and-interrupt.patch)
a. Correct this patch (Li Yang caught this problem, but for some reason this fix was not added)
- gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR, 0xffffffff);
+ gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR, 0);
3. fix the device-tree and gpio-mpc8xxx.c so that the changes will be applied to LX2160A.

0 Kudos

1,572 Views
Pavel
NXP Employee
NXP Employee

The latest patch is: https://lore.kernel.org/patchwork/patch/1101924/

 

Have a great day,
Pavel Chubakov

0 Kudos

1,572 Views
phoffmann
Contributor II

Pavel,

Thanks for the patch. I applied the patch with minor modifications (the patch only applies the fix for the ls1028a).

With this patch, I was able to read the value from the GPIO input without needing any GPIBE register hacks.

I am still having issues with trying to request IRQs. With the driver I'm working on, I see an RCU stall when I call devm_request_irq(). I see the printk before devm_request_irq(), but not the prink immediately after (see OUTPUT1). I have been able to reproduce a similar behavior using only CONFIG_GPIO_SYSFS (see OUTPUT2). 

The stall that I'm seeing might be related to the issue seen at https://community.nxp.com/thread/511620. The LS2088 also has GPIOs with a GPIBE register. I've tried applying the patch at the end of this thread, but that doesn't fix the stall.

# OUTPUT1: Output from driver patterned after PPS driver. Shows both the linux IRQ number as well as the hwirq.

# PPS driver: drivers/pps/clients/pps-gpio.c.

insmod int_receiver.ko
[ 69.184855] int_receiver: loading out-of-tree module taints kernel.
[ 69.193206] INT_RECEIVER: Device probed
[ 69.210467] INT_RECEIVER: GPIO pin is 429.
[ 69.214998] INT_RECEIVER: IRQ is 384 (hwirq 13)
[ 69.219940] INT_RECEIVER: Do request_irq
[ 90.238679] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 90.244419] rcu: 0-....: (1 GPs behind) idle=f1e/1/0x4000000000000004 softirq=17964/17965 fqs=2512
[ 90.253536] rcu: (t=5250 jiffies g=6109 q=265)
[ 90.258143] Task dump for CPU 0:
[ 90.261359] insmod R running task 0 3751 3518 0x0000022a
[ 90.268397] Call trace:

# Note: cat /proc/interrupts before the driver was run shows the following:
CPU0 ... CPU15
13: 75 ... 0 GICv3 106 Level 2040000.i2c

# OUTPUT2: Output from CONFIG_GPIO_SYSFS:

# 428 and 429 are jumpered together.

echo 428 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio428/direction
echo 1 > /sys/class/gpio/gpio428/value

echo 429 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio429/direction
echo both > /sys/class/gpio/gpio429/edge

[ 1080.358463] rcu: INFO: rcu_preempt self-detected stall on CPU
[ 1080.364205] rcu: 0-....: (5264 ticks this GP) idle=7ca/1/0x4000000000000004 softirq=74533/74535 fqs=2558
[ 1080.373844] rcu: (t=5252 jiffies g=97433 q=306)
[ 1080.378537] Task dump for CPU 0:
[ 1080.381753] sh R running task 0 3518 1 0x00000202
[ 1080.388792] Call trace:
[ 1080.391235] dump_backtrace+0x0/0x180
[ 1080.394886] show_stack+0x14/0x20
[ 1080.398190] sched_show_task+0x134/0x170
[ 1080.402100] dump_cpu_task+0x40/0x50
[ 1080.405664] rcu_dump_cpu_stacks+0x94/0xd4
[ 1080.409747] rcu_check_callbacks+0x568/0x880
[ 1080.414006] update_process_times+0x2c/0x58
[ 1080.418177] tick_sched_handle.isra.5+0x30/0x50
[ 1080.422694] tick_sched_timer+0x48/0x98
[ 1080.426518] __hrtimer_run_queues+0x120/0x1b8
[ 1080.430862] hrtimer_interrupt+0xd4/0x250
[ 1080.434861] arch_timer_handler_phys+0x28/0x40
[ 1080.439293] handle_percpu_devid_irq+0x80/0x138
[ 1080.443811] generic_handle_irq+0x24/0x38
[ 1080.447808] __handle_domain_irq+0x5c/0xb0
[ 1080.451891] gic_handle_irq+0x7c/0x180
[ 1080.455628] el1_irq+0xb0/0x128
[ 1080.458756] __do_softirq+0x90/0x210
[ 1080.462320] irq_exit+0xd0/0xd8
[ 1080.465449] __handle_domain_irq+0x60/0xb0
[ 1080.469532] gic_handle_irq+0x7c/0x180
[ 1080.473268] el1_irq+0xb0/0x128
[ 1080.476399] _raw_spin_unlock_irqrestore+0x14/0x40
[ 1080.481177] __setup_irq+0x4ec/0x6d8
[ 1080.484740] request_threaded_irq+0xe4/0x198
[ 1080.488998] request_any_context_irq+0x60/0xb0
[ 1080.493431] gpio_sysfs_request_irq.isra.1+0xb0/0x140
[ 1080.498470] edge_store+0x10c/0x130
[ 1080.501948] dev_attr_store+0x18/0x28
[ 1080.505599] sysfs_kf_write+0x3c/0x50
[ 1080.509249] kernfs_fop_write+0x118/0x1e0
[ 1080.513247] __vfs_write+0x30/0x168
[ 1080.516723] vfs_write+0xa4/0x1a8
[ 1080.520025] ksys_write+0x60/0xd8
[ 1080.523328] __arm64_sys_write+0x18/0x20
[ 1080.527240] el0_svc_common+0x60/0x100
[ 1080.530977] el0_svc_handler+0x2c/0x80
[ 1080.534713] el0_svc+0x8/0xc

0 Kudos

1,572 Views
Pavel
NXP Employee
NXP Employee

There is the patch to fix it is here: http://patchwork.ozlabs.org/patch/1005806/
Please try to use this patch.

Have a great day,
Pavel Chubakov

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos