[MinnowBoard] SPI questions

Kevin Shelton kmshelton at gmail.com
Thu Jan 29 10:01:07 UTC 2015


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 <kmshelton at gmail.com> 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 <kmshelton at gmail.com> 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 <kmshelton at gmail.com> 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 <dvhart at linux.intel.com> 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" <kmshelton at gmail.com> 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 <kmshelton at gmail.com>
>>>>>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 <dvhart at linux.intel.com>
>>>>>>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" <kmshelton at gmail.com> wrote:
>>>>>>>
>>>>>>>>Thanks John and Darren.  I will play with spid_devtest and have
>>>>>>>>reached out to linux-spi at vger.kernel.org.
>>>>>>>>
>>>>>>>>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 <dvhart at linux.intel.com>
>>>>>>>>wrote:
>>>>>>>>> On 1/26/15, 5:52 PM, "John Hawley" <john.hawley at intel.com> wrote:
>>>>>>>>>
>>>>>>>>>>On 01/26/2015 05:47 PM, Kevin Shelton wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 23, 2015 at 2:41 PM, John Hawley <john.hawley at intel.com
>>>>>>>>>>> <mailto:john.hawley at intel.com>> 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
>>>>>>>>> elinux-MinnowBoard at lists.elinux.org
>>>>>>>>> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Darren Hart
>>>>>>> Intel Open Source Technology Center
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Darren Hart
>>>> Intel Open Source Technology Center
>>>>
>>>>
>>>>


More information about the elinux-MinnowBoard mailing list