Yeah, pin 5 should be 220 which matches what is in the wiki. Even without my module involved (fresh boot into a 3.17) I cannot seem to control GPIO 220. I confirmed I was able to manipulate one of the other GPIO pins on the low-speed-expansion header. I am using the latest (rev 76) fw.
So, with a clean boot (my module nowhere to be found) when I root@minnow-fe-37-9a:~# echo 220 > /sys/class/gpio/export I get: [ 608.068793] byt_gpio INT33FC:00: pin 66 cannot be used as GPIO. has anyone successfully used pin 5 as GPIO with rev 76 fw? On Thu, Jan 29, 2015 at 1:09 PM, John "Warthog9" Hawley <[email protected]> wrote: > On January 29, 2015 11:51:33 AM PST, Kevin Shelton <[email protected]> > wrote: >>Looks like my gpio number was wrong for my 3.17 system. I confirmed >>on the datasheet that SIO_SPI_CS# goes to GPIO_S0_SC[66], which should >>be the 67th GPIO in the block of 102 GPIOs beginning at 154 on my >>system (so that checks out to the 220 on the wiki). However, I run >>into: >> >>[ 143.049918] byt_gpio INT33FC:00: pin 66 cannot be used as GPIO. >>[ 143.056556] spi spi0.0: failed to request chip select GPIO220 >>[ 143.063007] pxa2xx-spi 80860F0E:00: can't setup spi0.0, status -22 >> >>On Thu, Jan 29, 2015 at 2:01 AM, Kevin Shelton <[email protected]> >>wrote: >>> pin 5 still idling high at 3.3V after the pxa2xx_spi_chip addition >>> >>> On Thu, Jan 29, 2015 at 1:06 AM, Kevin Shelton <[email protected]> >>wrote: >>>> added the following to my board file: >>>> >>>> #include <linux/spi/pxa2xx_spi.h> >>>> >>>> static struct pxa2xx_spi_chip mbm = { >>>> .gpio_cs = 476 >>>> }; >>>> >>>> as well as >>>> .controller_data = &mbm >>>> to the spi_board_info struct >>>> >>>> And now my module no longer returns from cs_setup before getting to >>>> the cs polarity logic (at least in ACPI mode, not yet tested in PCI >>>> mode). I've also yet to confirm that my SPI device is actually >>>> working, but I think this is on the right track. >>>> >>>> On Wed, Jan 28, 2015 at 11:31 PM, Kevin Shelton >><[email protected]> wrote: >>>>> My board file loads, but with a NULL chip_info when I'm in ACPI >>mode >>>>> for LPSS & SCC Devices Mode (so IIUC, the NULL chip_info prevents >>>>> spi-pxa2xx.c from flipping the polarity on the SS line). >>>>> >>>>> My module will explode when in PCI mode (tried in PCI mode because >>>>> spi-pxa2xx.c has a comment "Slave devices enumerated from ACPI >>>>> namespace don't usually have chip_info") with: >>>>> >>>>> [ 559.236046] divide error: 0000 [#1] PREEMPT SMP >>>>> [ 559.241217] Modules linked in: low_speed_spidev(O+) >>>>> [ 559.246686] CPU: 0 PID: 11980 Comm: insmod Tainted: G >>O >>>>> 3.17.0-rc4-yocto-standard+ #13 >>>>> [ 559.256712] Hardware name: Circuitco MinnowBoard MAX B3 >>>>> PLATFORM/MinnowBoard MAX, BIOS MNW2MAX1.X64.0076.R01.1412081258 >>>>> 12/08/2014 >>>>> [ 559.269850] task: ffff880073e5dfc0 ti: ffff880078f30000 task.ti: >>>>> ffff880078f30000 >>>>> [ 559.278222] RIP: 0010:[<ffffffff8148c57d>] [<ffffffff8148c57d>] >>>>> ssp_get_clk_div+0x3b/0x4a >>>>> [ 559.287481] RSP: 0018:ffff880078f33c80 EFLAGS: 00010246 >>>>> [ 559.293422] RAX: 0000000000000000 RBX: ffff880073f4b660 RCX: >>000000000000003f >>>>> [ 559.301405] RDX: 0000000000000000 RSI: 0000000000000000 RDI: >>ffff880073e54428 >>>>> [ 559.309388] RBP: ffff880078f33c80 R08: 00000000000000df R09: >>ffffffff82075580 >>>>> [ 559.317370] R10: 0000000000000000 R11: 0000000000000000 R12: >>ffff880078578400 >>>>> [ 559.325353] R13: 0000000000000000 R14: ffff880073e54428 R15: >>0000000000002710 >>>>> [ 559.333338] FS: 00007f8296dcd700(0000) >>GS:ffff880079200000(0000) >>>>> knlGS:0000000000000000 >>>>> [ 559.342392] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>>>> [ 559.348819] CR2: 00007f8296dc9000 CR3: 000000007418b000 CR4: >>00000000001007f0 >>>>> [ 559.356801] Stack: >>>>> [ 559.359046] ffff880078f33cc0 ffffffff8148caa8 000000e000000040 >>>>> ffff880078578400 >>>>> [ 559.367334] 0000000000000000 0000000000000000 ffff880073e54000 >>>>> 0000000000000000 >>>>> [ 559.375628] ffff880078f33d10 ffffffff814888e6 0000000000000000 >>>>> ffff880078f33d10 >>>>> [ 559.383923] Call Trace: >>>>> [ 559.386660] [<ffffffff8148caa8>] setup+0x1fb/0x4b8 >>>>> [ 559.392119] [<ffffffff814888e6>] spi_setup+0xfd/0x1ad >>>>> [ 559.397871] [<ffffffff8143b32f>] ? bus_for_each_dev+0x63/0x85 >>>>> [ 559.404399] [<ffffffff81488aa4>] spi_add_device+0x10e/0x1a6 >>>>> [ 559.410732] [<ffffffff81489062>] spi_new_device+0xb5/0xcb >>>>> [ 559.416874] [<ffffffffa00030bf>] >>>>> low_speed_spidev_module_init+0xbf/0x133 [low_speed_spidev] >>>>> [ 559.426318] [<ffffffffa0003000>] ? 0xffffffffa0003000 >>>>> [ 559.432070] [<ffffffff8100032d>] do_one_initcall+0xff/0x185 >>>>> [ 559.438404] [<ffffffff8110172a>] ? __vunmap+0xa9/0xaf >>>>> [ 559.444155] [<ffffffff8108e4fb>] load_module+0x1756/0x1ef0 >>>>> [ 559.450392] [<ffffffff8108bfd3>] ? >>free_modinfo_version+0x27/0x27 >>>>> [ 559.457311] [<ffffffff8108ed57>] SyS_init_module+0xc2/0xcf >>>>> [ 559.463550] [<ffffffff8175fed2>] system_call_fastpath+0x16/0x1b >>>>> >>>>> I notice the below that sounds a little curious when I'm in PCI >>mode >>>>> (these are present for other devices, but from looking at >>>>> /sys/class/spi_master it seems that pci0000:00/0000:00:1e.5 is the >>>>> pxa2xx). >>>>> >>>>> [ 1.282369] pci 0000:00:1e.5: BAR 0: reserving [mem >>>>> 0x9093c000-0x9093cfff flags 0x40200] (d=0, p=0) >>>>> [ 1.282377] pci 0000:00:1e.5: can't claim BAR 0 [mem >>>>> 0x9093c000-0x9093cfff]: no compatible bridge window >>>>> [ 1.292998] pci 0000:00:1e.5: BAR 1: reserving [mem >>>>> 0x9093d000-0x9093dfff flags 0x40200] (d=0, p=0) >>>>> [ 1.293007] pci 0000:00:1e.5: can't claim BAR 1 [mem >>>>> 0x9093d000-0x9093dfff]: no compatible bridge window >>>>> >>>>> >>>>> >>>>> On Wed, Jan 28, 2015 at 4:19 PM, Kevin Shelton >><[email protected]> wrote: >>>>>> through liberal sprinkling of printks I find that when >>spi_new_device >>>>>> gets called in my board file, eventually setup_cs gets called in >>>>>> drivers/spi/spi-pxa2xx.c, but setup_cs returns before it can set >>>>>> gpio_cs_inverted because chip_info is NULL >>>>>> >>>>>> Should board files define a pxa2xx_spi_chip struct (I see this >>done in >>>>>> arch/arm/mach-pxa/hx4700.c)? >>>>>> >>>>>> Am I correct in calling hx4700.c a board file? >>>>>> >>>>>> On Tue, Jan 27, 2015 at 9:21 PM, Darren Hart >><[email protected]> wrote: >>>>>>> This changes the mechanism used to enumerate the hardware device >>to the >>>>>>> OS. Recent Linux kernels 3.16+ support for ACPI and PCI >>enumeration. ACPI >>>>>>> is supported since 3.14. Either should work for a board-file. >>>>>>> >>>>>>> -- >>>>>>> Darren >>>>>>> >>>>>>> >>>>>>> On 1/27/15, 3:13 PM, "Kevin Shelton" <[email protected]> wrote: >>>>>>> >>>>>>>>sorry for the not clear writing: I meant to say ACPI mode for the >>>>>>>>"LPSS & SCC Devices Mode" setting >>>>>>>> >>>>>>>>On Tue, Jan 27, 2015 at 3:11 PM, Kevin Shelton >><[email protected]> >>>>>>>>wrote: >>>>>>>>> I realized that in my BIOS settings, I was in ACPI mode. Do I >>need to >>>>>>>>> be in PCI mode to use a board file? What does that ACPI-PCI >>switch in >>>>>>>>> the BIOS do? thanks for all the help >>>>>>>>> >>>>>>>>> On Mon, Jan 26, 2015 at 11:35 PM, Darren Hart >><[email protected]> >>>>>>>>>wrote: >>>>>>>>>> The SPI bus controlled by the pxa2xx driver is on the LPSS, >>which, yes, >>>>>>>>>> corresponds to the Low Power IO Controller in that block >>diagram. >>>>>>>>>> >>>>>>>>>> On 1/26/15, 10:38 PM, "Kevin Shelton" <[email protected]> >>wrote: >>>>>>>>>> >>>>>>>>>>>Thanks John and Darren. I will play with spid_devtest and >>have >>>>>>>>>>>reached out to [email protected]. >>>>>>>>>>> >>>>>>>>>>>A minnowmax-specific question: In the Baytrail block diagram >>at >>>>>>>>>>>http://media.bestofmicro.com/Y/3/400395/original/bay-trail-soc.jpg >>>>>>>>>>>does the Marvell pxa27x correspond to the "Low Power IO >>Controller"? >>>>>>>>>>> >>>>>>>>>>>On Mon, Jan 26, 2015 at 6:33 PM, Darren Hart >><[email protected]> >>>>>>>>>>>wrote: >>>>>>>>>>>> On 1/26/15, 5:52 PM, "John Hawley" <[email protected]> >>wrote: >>>>>>>>>>>> >>>>>>>>>>>>>On 01/26/2015 05:47 PM, Kevin Shelton wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Jan 23, 2015 at 2:41 PM, John Hawley >><[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I saw the thread 'Adding an SPI device to the >>Minnowboard' >>>>>>>>>>>>>>from >>>>>>>>>>>>>>late >>>>>>>>>>>>>> > 2013 and 'SPI support on minnowboard v1' from Aug >>2014. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Darren Hart notes: >>>>>>>>>>>>>> > Ultimately we want to do things like this without >>board >>>>>>>>>>>>>>files by >>>>>>>>>>>>>>using >>>>>>>>>>>>>> > the _DSD mechanisms introduced by the ACPI 5.1 >>specification >>>>>>>>>>>>>>last >>>>>>>>>>>>>>week >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I just wanted to confirm the ACPI mechanism is not >>the >>>>>>>>>>>>>>recommended way >>>>>>>>>>>>>> > yet, and that using low-speed-spidev.c as a template >>is still >>>>>>>>>>>>>>the >>>>>>>>>>>>>>way to go. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The answer to that will depend on what kernel you are >>>>>>>>>>>>>>intending to >>>>>>>>>>>>>> target. Kernel's with ACPI 5.1 _DSD support, I think >>you'd >>>>>>>>>>>>>>want >>>>>>>>>>>>>>to >>>>>>>>>>>>>>push >>>>>>>>>>>>>> on that. Older kernels without that, likely spidev or >>a more >>>>>>>>>>>>>>targeted >>>>>>>>>>>>>> driver. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently, I am targeting 3.17. 3.17 does not have ACPI >>5.1 _DSD >>>>>>>>>>>>>> support, correct? >>>>>>>>>>>>> >>>>>>>>>>>>>Off the top of my head that came in in 3.18, so yes that's >>correct. >>>>>>>>>>>> >>>>>>>>>>>> 3.19 iirc. >>>>>>>>>>>> >>>>>>>>>>>> Also, using _DSD required a firmware change, or at least a >>DSDT >>>>>>>>>>>>update. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> > Additional q: >>>>>>>>>>>>>> > How do you tell the SPI controller that you have an >>>>>>>>>>>>>>active-high >>>>>>>>>>>>>>instead >>>>>>>>>>>>>> > of the usual active-low device? Is it correct to do >>a >>>>>>>>>>>>>>bitwise >>>>>>>>>>>>>>or >>>>>>>>>>>>>>with >>>>>>>>>>>>>> > SPI_CS_HIGH (0x4) with your SPI_MODE in your >>spi_board_info >>>>>>>>>>>>>>struct, like: >>>>>>>>>>>>>> > .mode = SPI_MODE_0 | SPI_CS_HIGH >>>>>>>>>>>>>> >>>>>>>>>>>>>> That should work, but take my statement with a grain >>of salt >>>>>>>>>>>>>>as I >>>>>>>>>>>>>> haven't tried it with a device. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems to have no effect that I can discern. Pin 5 >>idles at 3.3V >>>>>>>>>>>>>> whether I have >>>>>>>>>>>>>> .mode = SPI_MODE_3 | SPI_CS_HIGH >>>>>>>>>>>>>> -or- >>>>>>>>>>>>>> .mode = SPI_MODE_3 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I threw in a >>>>>>>>>>>>>> pr_info("SPI mode=%i\n", cod_spi_board_info.mode); >>>>>>>>>>>>>> to sanity check that I am setting the mode to what I think >>I am (3 >>>>>>>>>>>>>>or >>>>>>>>>>>>>>7). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any debugging ideas? >>>>>>>>>>>>>> What is the best way to learn more about the SPI master? >>It's >>>>>>>>>>>>>>built >>>>>>>>>>>>>> into the CPU, correct? >>>>>>>>>>>>>> This smells in the ballpark of >>>>>>>>>>>>>> relatedness: >>>>>>>>>>>>>>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/2634 >>>>>>>>>>>>>>67. >>>>>>>>>>>>>>ht >>>>>>>>>>>>>>ml >>>>>>>>>>>>>> I don't grok that patch, but I confirmed my version of >>pxa2xx.c in >>>>>>>>>>>>>>my >>>>>>>>>>>>>> 3.17 tree appears to contain that change. >>>>>>>>>>>>> >>>>>>>>>>>>>The SPI interface is indeed built into the CPU. It's the >>pxa2xx >>>>>>>>>>>>>core, >>>>>>>>>>>>>which it looks like you've found. I'd have to punt to >>someone else, >>>>>>>>>>>>>as >>>>>>>>>>>>>I'll admit, I don't know the SPI code well enough to say >>what's going >>>>>>>>>>>>>on. I've CC'ed Darren Hart, he might know who to check with >>next. >>>>>>>>>>>> >>>>>>>>>>>> Those are some very specific SPI usage questions that I >>don't know >>>>>>>>>>>>the >>>>>>>>>>>> answer to off the top of my head. To find out, I would: >>>>>>>>>>>> >>>>>>>>>>>> 1) Search for other drivers in tree and externally that use >>>>>>>>>>>>active-high >>>>>>>>>>>> >>>>>>>>>>>> First hit looks interesting: >>>>>>>>>>>> https://www.kernel.org/doc/Documentation/spi/spidev_test.c >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) Lookup the right mailing lists for SPI Linux kernel >>development >>>>>>>>>>>>and >>>>>>>>>>>>ask >>>>>>>>>>>> the same question there >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Darren Hart >>>>>>>>>>>> Intel Open Source Technology Center >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> elinux-MinnowBoard mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Darren Hart >>>>>>>>>> Intel Open Source Technology Center >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Darren Hart >>>>>>> Intel Open Source Technology Center >>>>>>> >>>>>>> >>>>>>> >>_______________________________________________ >>elinux-MinnowBoard mailing list >>[email protected] >>http://lists.elinux.org/mailman/listinfo/elinux-minnowboard > > Check http://elinux.org/Minnowboard:MinnowMax#Low_Speed_Expansion_.28Top.29 > for the Linux GPIO numbers we are expecting. > > - John _______________________________________________ elinux-MinnowBoard mailing list [email protected] http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
