Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
On Thu, Jan 14, 2021 at 02:42:26PM +0100, Christophe Leroy wrote: > Le 14/01/2021 à 14:22, Mark Brown a écrit : > > For GPIO chipselects you should really fix the driver to just hand the > > GPIO off to the core rather than trying to implement this itself, that > > will avoid driver specific differences like this. > IIUC, it is not trivial as it requires implementing transfer_one() instead > of the existing transfer_one_message() in the driver. Am I right ? Yes, that's a good idea in general though. It should normally be pretty simple since the conversion is mostly just deleting code doing things which will be handled by the core. > What's the difference/benefit of transfer_one() compared to the existing > transfer_one_message() ? It factors out all the handling of chip selects, including per-transfer chip select inversion and so on, and also factors out all the handling of in-message delays. If nothing else it reduces the amount of duplicated code that might require maintainance can have issues with misaligned expectations from the core or client drivers. signature.asc Description: PGP signature
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
Le 14/01/2021 à 14:22, Mark Brown a écrit : For GPIO chipselects you should really fix the driver to just hand the GPIO off to the core rather than trying to implement this itself, that will avoid driver specific differences like this. IIUC, it is not trivial as it requires implementing transfer_one() instead of the existing transfer_one_message() in the driver. Am I right ? What's the difference/benefit of transfer_one() compared to the existing transfer_one_message() ?
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
On Thu, Jan 14, 2021 at 01:33:50PM +0100, Christophe Leroy wrote:
> Le 14/01/2021 à 12:59, Mark Brown a écrit :
> > On Thu, Jan 14, 2021 at 12:27:42PM +0100, Christophe Leroy wrote:
> > > Today I have in the DTS the CS GPIOs declared as ACTIVE_LOW.
> > > If I declare them as ACTIVE_HIGH instead, then I also have to set
> > > spi-cs-high property, otherwise of_gpio_flags_quirks() is not happy and
> > > forces the GPIO ACTIVE LOW.
> > > When I set spi-cs-high property, it sets the SPI_CS_HIGH bit in spi->mode.
> > OK, so it sounds like you want SPI_CS_HIGH and that is being set
> > correctly?
> > > In fsl_spi_chipselect(), we have
> > >
> > > bool pol = spi->mode & SPI_CS_HIGH
> > >
> > > Then
> > > pdata->cs_control(spi, pol);
> > > So changing the board config is compensated by the above, and at the end
> > > it still doesn't work.
> > This is a driver bug, the driver set_cs() operation should not be
> > modifying the value it is told to set.
> A driver bug ? Or maybe a change forgotten in commit 766c6b63aa04 ("spi:
> fix client driver breakages when using GPIO descriptors") ?
The expectation that the driver will be using the chip select exactly as
passed in and not attempting to implement SPI_CS_HIGH itself when it has
set_cs() has been there for a considerable time now, that's not new with
the cleanup. Drivers should only be paying attention to SPI_CS_HIGH in
cases where the hardware controls the chip select autonomously and so
set_cs() can't be provided.
> I'm almost sure it was not a bug, it is in line which what is said in
> the comment removed by the above mentionned commit.
Please take a look at the list archive discussions around this - there's
been a lot of confusion with GPIO descriptors in particular due to there
being multiple places where you can set the inversion. Note that the
situation you describe above is that you end up with all the various
places other than your driver agreeing that the chip select is active
high as it (AFAICT from what you're saying) actually is.
For GPIO chipselects you should really fix the driver to just hand the
GPIO off to the core rather than trying to implement this itself, that
will avoid driver specific differences like this.
signature.asc
Description: PGP signature
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
Le 14/01/2021 à 12:59, Mark Brown a écrit :
On Thu, Jan 14, 2021 at 12:27:42PM +0100, Christophe Leroy wrote:
Today I have in the DTS the CS GPIOs declared as ACTIVE_LOW.
If I declare them as ACTIVE_HIGH instead, then I also have to set
spi-cs-high property, otherwise of_gpio_flags_quirks() is not happy and
forces the GPIO ACTIVE LOW.
When I set spi-cs-high property, it sets the SPI_CS_HIGH bit in spi->mode.
OK, so it sounds like you want SPI_CS_HIGH and that is being set
correctly?
In fsl_spi_chipselect(), we have
bool pol = spi->mode & SPI_CS_HIGH
Then
pdata->cs_control(spi, pol);
So changing the board config is compensated by the above, and at the end it
still doesn't work.
This is a driver bug, the driver set_cs() operation should not be
modifying the value it is told to set.
A driver bug ? Or maybe a change forgotten in commit 766c6b63aa04 ("spi: fix client driver
breakages when using GPIO descriptors") ?
I'm almost sure it was not a bug, it is in line which what is said in the comment removed by the
above mentionned commit.
I'll send a fix.
Christophe
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
On Thu, Jan 14, 2021 at 12:27:42PM +0100, Christophe Leroy wrote: > Today I have in the DTS the CS GPIOs declared as ACTIVE_LOW. > If I declare them as ACTIVE_HIGH instead, then I also have to set > spi-cs-high property, otherwise of_gpio_flags_quirks() is not happy and > forces the GPIO ACTIVE LOW. > When I set spi-cs-high property, it sets the SPI_CS_HIGH bit in spi->mode. OK, so it sounds like you want SPI_CS_HIGH and that is being set correctly? > In fsl_spi_chipselect(), we have > > bool pol = spi->mode & SPI_CS_HIGH > > Then > pdata->cs_control(spi, pol); > So changing the board config is compensated by the above, and at the end it > still doesn't work. This is a driver bug, the driver set_cs() operation should not be modifying the value it is told to set. signature.asc Description: PGP signature
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
Le 13/01/2021 à 13:33, Mark Brown a écrit :
On Wed, Jan 13, 2021 at 09:49:12AM +0100, Christophe Leroy wrote:
With commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO
descriptors") reverted, it is back to work:
...
What shall I do ?
I would guess that there's an error with the chip select polarity
configuration on your system that just happened to work previously, I'd
suggest fixing this in the board configuration to bring it in line with
everything else.
Not that easy.
Today I have in the DTS the CS GPIOs declared as ACTIVE_LOW.
If I declare them as ACTIVE_HIGH instead, then I also have to set spi-cs-high property, otherwise
of_gpio_flags_quirks() is not happy and forces the GPIO ACTIVE LOW.
When I set spi-cs-high property, it sets the SPI_CS_HIGH bit in spi->mode.
In fsl_spi_chipselect(), we have
bool pol = spi->mode & SPI_CS_HIGH
Then
pdata->cs_control(spi, pol);
So changing the board config is compensated by the above, and at the end it
still doesn't work.
Whereas reverting the above mentionned commit sets back SPI_CS_HIGH into spi->mode without changing
the ACTIVE level of the GPIO, resulting in the correct polarity.
So, I'm a bit lost, where is the problem exactly ?
Thanks
Christophe
Re: SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
On Wed, Jan 13, 2021 at 09:49:12AM +0100, Christophe Leroy wrote:
> With commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO
> descriptors") reverted, it is back to work:
...
> What shall I do ?
I would guess that there's an error with the chip select polarity
configuration on your system that just happened to work previously, I'd
suggest fixing this in the board configuration to bring it in line with
everything else.
signature.asc
Description: PGP signature
SPI not working on 5.10 and 5.11, bisected to 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
Hello,
My board has powerpc 885 microcontroler. Temperature sensor is an LM74.
Kernel has CONFIG_SPI_FSL_SPI and CONFIG_SPI_FSL_CPM and CONFIG_SENSORS_LM70.
Since kernel 5.10, 'sensors' reports temperature 0°C on my board:
root@vgoip:~# sensors
lm74-spi-0-5
Adapter: SPI adapter
temp1: +0.0 C
lm74-spi-0-1
Adapter: SPI adapter
temp1: +0.0 C
With commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") reverted,
it is back to work:
root@vgoip:~# sensors
lm74-spi-0-5
Adapter: SPI adapter
temp1:+38.9 C
lm74-spi-0-1
Adapter: SPI adapter
temp1:+37.2 C
What shall I do ?
Thanks
Christophe
Re: Using gpio in MPC8309
On 2012-07-12 18:08, Gal Afel wrote: Hello, I just got a TWR-MPC8309 from Freescale running Embedded Linux OS. The kernel version is Linux 2.6.11+pq3 patches and the kernel preconfig file is linux_2.6.11_mpc8548_cds_def.config. That's a really OLD kernel, plus it doesn't seem to match your hardware. MPC8309 is a very different beast from the MPC8548. I'm new to processors running Linux and I'm having a hard time trying to understand how can I program the GPIO and use them. Is there a tutorial or any documentation you could provide me to get started on accessing the processor pins please? I'm using CodeWarrior Development Studio for Power Architecture version 10.0.2 and I haven't found a library that includes the functions to access the pins functionality. Is there any documentation you could suggest me to do that please? Try looking at the Linux kernel source file 'Documentation/gpio.txt' -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Using gpio in MPC8309
Hello, I just got a TWR-MPC8309 from Freescale running Embedded Linux OS. The kernel version is Linux 2.6.11+pq3 patches and the kernel preconfig file is linux_2.6.11_mpc8548_cds_def.config. I'm new to processors running Linux and I'm having a hard time trying to understand how can I program the GPIO and use them. Is there a tutorial or any documentation you could provide me to get started on accessing the processor pins please? I'm using CodeWarrior Development Studio for Power Architecture version 10.0.2 and I haven't found a library that includes the functions to access the pins functionality. Is there any documentation you could suggest me to do that please? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Using GPIO
Hi,
I am also trying to use Xilinx GPIO driver on my board but I encounter some
problems. I thought they will be resolved with this information but it
doesn't.
I use GPIO driver as built-in but during kernel boot but I don't see log
about it contrary to Xemac driver for instance. First I wanted to create my
gpio driver normally without using Xilinx one, with ioremap and writel/readl
but I didn't write anything in the register, I don't know why. Then I tried
to use Xilinx GPIO driver but I don't know why I don't hit xgpio_probe,
xgpio_init returns 0 so it's OK.
Do you have any idea ?
Thanks
Ludovic Desroches
arch/ppc/syslib/virtex_devices.c:
* // 0 is LEDS_4BIT, 1 is LEDS_POSITIONS, 2 is PUSH_BUTTONS_POSITION
** #define XPAR_GPIO(num) { \
**.name = xilinx_gpio, \
**.id = num, \
**.num_resources = 2, \
*That was a 2.
If anybody wants to make a patch out of those few lines of code, I couldn't
figure out how to do this with git... But I will use a more general GPIO
approach as soon as I can put my hands on our custom card.
*.resource = (struct resource[]) { \
**{ \
**.start = XPAR_GPIO_##num##_BASEADDR, \
**.end = XPAR_GPIO_##num##_HIGHADDR, \
**.flags = IORESOURCE_MEM, \
**}, \
**{ \
**.start = XPAR_INTC_0_GPIO_##num##_VEC_ID, \
**.flags = IORESOURCE_IRQ, \
**}, \
**}, \
** }
** [...]
** /* GPIO instances */
** #if defined(XPAR_GPIO_0_BASEADDR)
** XPAR_GPIO(0),
** #endif
** #if defined(XPAR_GPIO_1_BASEADDR)
** XPAR_GPIO(1),
** #endif
** #if defined(XPAR_GPIO_2_BASEADDR)
** XPAR_GPIO(2),
** #endif
*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using GPIO
I think there are some more details in my notes: https://lpsc-secure.in2p3.fr/trac/akido/wiki/CrossCompile#GettingGPIOtoworkinuserspace I am also trying to use Xilinx GPIO driver on my board but I encounter some problems. I thought they will be resolved with this information but it doesn't. -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using GPIO
Thanks for the answer,
Dts files are not used with arch/ppc.
My question was more general, since arch/ppc will soon (?) disapear...
In arch/ppc, the drivers that are in the system depend on the
arch/ppc/platforms/4xx/xparameters/xparameters_ml405.h to setup the
addresses of the devices and their configuration.
Yes, and I've taken care to define that.
I looked at the ML405 setup in the git tree and it appears that it would
need to be added to arch/ppc/syslib/virtex_devices.c. The platform data
in virtex_devices.c must include the GPIO for it to be probed correctly.
It should be easy for you to add the data to make it work.
Seems straightforward enough, but when I add the following:
// 0 is LEDS_4BIT, 1 is LEDS_POSITIONS, 2 is PUSH_BUTTONS_POSITION
#define XPAR_GPIO(num) { \
.name = xilinx_gpio, \
.id = num, \
.num_resources = 3, \
.resource = (struct resource[]) { \
{ \
.start = XPAR_GPIO_##num##_BASEADDR, \
.end = XPAR_GPIO_##num##_HIGHADDR, \
.flags = IORESOURCE_MEM, \
}, \
{ \
.start = XPAR_INTC_0_GPIO_##num##_VEC_ID, \
.flags = IORESOURCE_IRQ, \
}, \
}, \
}
[...]
/* GPIO instances */
#if defined(XPAR_GPIO_0_BASEADDR)
XPAR_GPIO(0),
#endif
#if defined(XPAR_GPIO_1_BASEADDR)
XPAR_GPIO(1),
#endif
#if defined(XPAR_GPIO_2_BASEADDR)
XPAR_GPIO(2),
#endif
Then the boot stops right after Uncompressing Linux...done.
Now booting the kernel
I've probably overlooked something obvious, but I'm pretty new in putting my
greasy fingers on delicate kernel internals...
In particular I don't know what is this .num_resources value.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using GPIO
On Mon, 19 May 2008 13:56:12 +0200 Guillaume Dargaud [EMAIL PROTECTED] wrote: Thanks for the answer, Dts files are not used with arch/ppc. My question was more general, since arch/ppc will soon (?) disapear... Device Tree Souce files. See lots of examples in arch/powerpc/boot/dts/. Those files are used to build the device tree binary blob for platforms that lack OpenFirmware. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using GPIO
If you're using arch/powerpc, my understanding is that CONFIG_XILINX_GPIO needs to be enabled as well as having the right info in the dts file. I'm using arch/ppc, so excuse my ignorance but what are dts files ? I see arch/powerpc/boot/dts/ml405.dts in the kernel tree which would need some changes, but it looks like a generated file. Generated by what ? If you're using arch/ppc, I believe you just need CONFIG_XILINX_GPIO enabled. When the system boots up, you see a message on the console when the GPIO driver initializes. That's what I'm trying to use, but there's no gpio info in the messages. Here's a copy: Linux version 2.6.25-rc9 ([EMAIL PROTECTED]) (gcc version 4.1.2) #27 Thu May 15 18:40:17 CEST 2008 Xilinx Generic PowerPC board support package (Xilinx ML405) (Virtex-4 FX) Entering add_active_range(0, 0, 32768) 0 entries of 256 used Zone PFN ranges: DMA 0 -32768 Normal 32768 -32768 Movable zone start PFN for each node active PFN ranges 0:0 -32768 On node 0 totalpages: 32768 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp Xilinx INTC #0 at 0x8180 mapped to 0xFDFFF000 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 127872k available (1516k kernel code, 460k data, 80k init, 0k highmem) Calibrating delay loop... 298.40 BogoMIPS (lpj=496640) Mount-cache hash table entries: 512 net_namespace: 152 bytes NET: Registered protocol family 16 Registering device uartlite:0 Registering device xsysace:0 Fixup MAC address for xilinx_lltemac:0 Registering device xilinx_lltemac:0 Registering device xilinx_iic:0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered io scheduler noop registered (default) uartlite.0: ttyUL0 at MMIO 0x8403 (irq = 8) is a uartlite enabled loop: module loaded xsysace xsa: Xilinx SystemACE revision 1.0.12 xsysace xsa: capacity: 1014048 sectors xsa: xsa1 xsa2 Xilinx SystemACE device driver, major=254 xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3 xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc9008100 XLlTemac: buffer descriptor size: 32768 (0x8000) XLlTemac: Allocating DMA descriptors with kmalloc6XLlTemac: (buffer_descriptor_init) phy: 0x7ca8000, virt: 0xc7ca8000, size: 0x8000 XTemac: PHY detected at address 7. eth0: Dropping NETIF_F_SG since no checksum feature. xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C0 mapped to 0xC9004000, irq=2 mice: PS/2 mouse device common for all mice xilinx_iic.0 #0 at 0x8160 mapped to 0xC902, irq=4 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: XLlTemac: Options: 0x3fa eth0: XLlTemac: allocating interrupt 0 for dma mode tx. eth0: XLlTemac: allocating interrupt 1 for dma mode rx. eth0: XLlTemac: speed set to 100Mb/s eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 192.168.1.185, my address is 192.168.1.200 IP-Config: Complete: device=eth0, addr=192.168.1.200, mask=255.255.255.0, gw=192.168.1.185, host=genepy, domain=, nis-domain=(none), bootserver=192.168.1.185, rootserver=192.168.1.185, rootpath=/media/rootfs Looking up port of RPC 13/2 on 192.168.1.185 Looking up port of RPC 15/1 on 192.168.1.185 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 80k init ...and the boot proceeds fine. And a cleaned-up .config: CONFIG_WORD_SIZE=32 CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOG_BUF_SHIFT=14 CONFIG_NAMESPACES=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y
RE: Using GPIO
Hi, Dts files are not used with arch/ppc. In arch/ppc, the drivers that are in the system depend on the arch/ppc/platforms/4xx/xparameters/xparameters_ml405.h to setup the addresses of the devices and their configuration. I looked at the ML405 setup in the git tree and it appears that it would need to be added to arch/ppc/syslib/virtex_devices.c. The platform data in virtex_devices.c must include the GPIO for it to be probed correctly. It should be easy for you to add the data to make it work. I see a GPIO in the xparameters*.h for the LEDs. Thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Dargaud Sent: Friday, May 16, 2008 2:16 AM To: linuxppc-dev@ozlabs.org Subject: Re: Using GPIO If you're using arch/powerpc, my understanding is that CONFIG_XILINX_GPIO needs to be enabled as well as having the right info in the dts file. I'm using arch/ppc, so excuse my ignorance but what are dts files ? I see arch/powerpc/boot/dts/ml405.dts in the kernel tree which would need some changes, but it looks like a generated file. Generated by what ? If you're using arch/ppc, I believe you just need CONFIG_XILINX_GPIO enabled. When the system boots up, you see a message on the console when the GPIO driver initializes. That's what I'm trying to use, but there's no gpio info in the messages. Here's a copy: Linux version 2.6.25-rc9 ([EMAIL PROTECTED]) (gcc version 4.1.2) #27 Thu May 15 18:40:17 CEST 2008 Xilinx Generic PowerPC board support package (Xilinx ML405) (Virtex-4 FX) Entering add_active_range(0, 0, 32768) 0 entries of 256 used Zone PFN ranges: DMA 0 -32768 Normal 32768 -32768 Movable zone start PFN for each node active PFN ranges 0:0 -32768 On node 0 totalpages: 32768 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp Xilinx INTC #0 at 0x8180 mapped to 0xFDFFF000 PID hash table entries: 512 (order: 9, 2048 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 127872k available (1516k kernel code, 460k data, 80k init, 0k highmem) Calibrating delay loop... 298.40 BogoMIPS (lpj=496640) Mount-cache hash table entries: 512 net_namespace: 152 bytes NET: Registered protocol family 16 Registering device uartlite:0 Registering device xsysace:0 Fixup MAC address for xilinx_lltemac:0 Registering device xilinx_lltemac:0 Registering device xilinx_iic:0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered io scheduler noop registered (default) uartlite.0: ttyUL0 at MMIO 0x8403 (irq = 8) is a uartlite enabled loop: module loaded xsysace xsa: Xilinx SystemACE revision 1.0.12 xsysace xsa: capacity: 1014048 sectors xsa: xsa1 xsa2 Xilinx SystemACE device driver, major=254 xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: a:35: 1: 2: 3 xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc9008100 XLlTemac: buffer descriptor size: 32768 (0x8000) XLlTemac: Allocating DMA descriptors with kmalloc6XLlTemac: (buffer_descriptor_init) phy: 0x7ca8000, virt: 0xc7ca8000, size: 0x8000 XTemac: PHY detected at address 7. eth0: Dropping NETIF_F_SG since no checksum feature. xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at 0x81C0 mapped to 0xC9004000, irq=2 mice: PS/2 mouse device common for all mice xilinx_iic.0 #0 at 0x8160 mapped to 0xC902, irq=4 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: XLlTemac: Options: 0x3fa eth0: XLlTemac: allocating interrupt 0 for dma mode tx. eth0: XLlTemac: allocating interrupt 1 for dma mode rx. eth0: XLlTemac: speed set to 100Mb/s eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 192.168.1.185, my address is 192.168.1.200 IP-Config: Complete: device=eth0, addr=192.168.1.200, mask=255.255.255.0, gw=192.168.1.185, host=genepy, domain=, nis-domain=(none), bootserver=192.168.1.185, rootserver=192.168.1.185, rootpath=/media/rootfs Looking up port of RPC 13/2 on 192.168.1.185 Looking up port of RPC 15/1 on 192.168.1.185 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 80k
Using GPIO
Hello all, I'm trying to use the Xilinx GPIO from a user program. Since I haven't managed to compile their example (simon.c is given without a makefile), I wanted to try using /dev/gpio... So I added /dev/gpio0 c 666 0 0 10 185 - - - to device_table.txt when I generated my root filesystem with buildroot, but apparently this leads nowhere as it's not visible in /proc/devices. Is there some example or tutorial on how to use CONFIG_XILINX_GPIO ? Either as a device or as API calls... -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
