summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'firewire-updates' of ↵Linus Torvalds2012-03-2216-325/+478
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull IEEE 1394 (FireWire) subsystem updates post v3.3 from Stefan Richter: - Some SBP-2 initiator fixes, side product from ongoing work on a target. - Reintroduction of an isochronous I/O feature of the older ieee1394 driver stack (flush buffer completions); it was evidently rarely used but not actually unused. Matching libraw1394 code is already available. - Be sure to prefix all kernel log messages with device name or card name, and other logging related cleanups. - Misc other small cleanups, among them a small API change that affects sound/firewire/ too. Clemens Ladisch is aware of it. * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: (26 commits) firewire: allow explicit flushing of iso packet completions firewire: prevent dropping of completed iso packet header data firewire: ohci: factor out iso completion flushing code firewire: ohci: simplify iso header pointer arithmetic firewire: ohci: optimize control bit checks firewire: ohci: remove unused excess_bytes field firewire: ohci: copy_iso_headers(): make comment match the code firewire: cdev: fix IR multichannel event documentation firewire: ohci: fix too-early completion of IR multichannel buffers firewire: ohci: move runtime debug facility out of #ifdef firewire: tone down some diagnostic log messages firewire: sbp2: replace a GFP_ATOMIC allocation firewire: sbp2: Fix SCSI sense data mangling firewire: sbp2: Ignore SBP-2 targets on the local node firewire: sbp2: Take into account Unit_Unique_ID firewire: nosy: Use the macro DMA_BIT_MASK(). firewire: core: convert AR-req handler lock from _irqsave to _bh firewire: core: fix race at address_handler unregistration firewire: core: remove obsolete comment firewire: core: prefix log messages with card name ...
| * firewire: allow explicit flushing of iso packet completionsClemens Ladisch2012-03-187-13/+127
| | | | | | | | | | | | | | | | | | | | | | Extend the kernel and userspace APIs to allow reporting all currently completed isochronous packets, even if the next interrupt packet has not yet been reached. This is required to determine the status of the packets at the end of a paused or stopped stream, and useful for more precise synchronization of audio streams. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: prevent dropping of completed iso packet header dataClemens Ladisch2012-03-183-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The buffer for the header data of completed iso packets has a fixed size, so it is possible to configure a stream with a big interval between interrupt packets or with big headers so that this buffer would overflow. Previously, ohci.c would drop any data that would not fit, but this could make unsuspecting applications believe that fewer than the actual number of packets have completed. Instead of dropping data, add calls to flush_iso_completion() so that there are as many events as needed to report all of the data. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: factor out iso completion flushing codeClemens Ladisch2012-03-181-19/+18
| | | | | | | | | | | | | | | | | | | | | | In preparation for the following patches that add more flushing, move the code for flushing accumulated header data into a common function. The timestamp of the last completed packed is passed through the context structure instead of a function parameter to allow accessing this value later outside of the handle_i?_packet functions. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: simplify iso header pointer arithmeticClemens Ladisch2012-03-181-10/+12
| | | | | | | | | | | | | | | | | | | | When storing the header data of completed iso packets, we effectively treat the buffers as arrays of quadlets. Actually declaring the pointers as u32* avoids repetitive pointer arithmetic, removes the unhelpfully named "i" variables, and thus makes the code clearer. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: optimize control bit checksClemens Ladisch2012-03-181-3/+3
| | | | | | | | | | | | | | | | Doing the endian conversion on the constant instead of the memory field allows the compiler to do the conversion at compile time. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: remove unused excess_bytes fieldClemens Ladisch2012-03-181-1/+0
| | | | | | | | | | | | | | | | Commit 6498ba04aee6 (remove unused dualbuffer IR code) overlooked a field in struct iso_context. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: copy_iso_headers(): make comment match the codeClemens Ladisch2012-03-181-4/+3
| | | | | | | | | | | | | | | | | | The comment incorrectly talked about one little-endian quadlet, while there are actually two. Furthermore, the endianness of the remaining headers depends on whatever protocol is used, so don't mention them. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: cdev: fix IR multichannel event documentationClemens Ladisch2012-03-171-3/+2
| | | | | | | | | | | | | | | | | | | | State more precisely when fw_cdev_event_iso_interrupt_mc is sent. While the comment tried to reflect an amibuity in the OHCI specification, there is only one method that is useful in practice, and this also matches all the hardware implementations I've tested. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: fix too-early completion of IR multichannel buffersClemens Ladisch2012-03-171-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | handle_ir_buffer_fill() assumed that a completed descriptor would be indicated by a non-zero transfer_status (as in most other descriptors). However, this field is written by the controller as soon as (the end of) the first packet has been written into the buffer. As a consequence, if we happen to run into such a descriptor when the interrupt handler is executed after such a packet has completed, the descriptor would be taken out of the list of active descriptors as soon as the buffer had been partially filled, so the event for the buffer being completely filled would never be sent. To fix this, handle descriptors only when they have been completely filled, i.e., when res_count == 0. (This also matches the condition that is reported by the controller with an interrupt.) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: 2.6.36+ <stable@vger.kernel.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: move runtime debug facility out of #ifdefStefan Richter2012-03-102-24/+1
| | | | | | | | | | | | | | | | | | CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers if CONFIG_EXPERT was set. But in hindsight, this stuff is far too useful to omit it. So get rid of two #else branches that are only going to bitrot otherwise. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: tone down some diagnostic log messagesStefan Richter2012-03-102-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "skipped bus generations" message was added together with the respective fw_device retaining/ reviving code in order to see how it all works out. It did well, so don't spam the log anymore. The "register access failure" situation still needs an actual handler. But at this point it makes less sense to ask folks to send mails about it. We now have a pretty good picture of what controllers emit this and when: Texas Instruments PCIxx21 FireWire + CardBus + flash memory card controller: https://bugzilla.redhat.com/show_bug.cgi?id=608544 O2 Micro FireWire + flash memory card controller: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688 http://marc.info/?l=linux1394-devel&m=132309283531423 http://marc.info/?l=linux1394-devel&m=132368567907469 http://marc.info/?l=linux1394-devel&m=132516165727468 http://marc.info/?l=linux1394-devel&m=133006486927699 Pinnacle Movieboard: commit 7f7e37115a8b6724f26d0637a04e1d35e3c59717 http://marc.info/?l=linux1394-devel&m=130714243325962 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: sbp2: replace a GFP_ATOMIC allocationStefan Richter2012-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | sbp2_send_management_orb() is called by sbp2_login, sbp2_reconnect, and sbp2_remove, all which are able to sleep during memory allocations. Actually, sbp2_send_management_orb() itself is a sleeping function. Login and remove could allocate with GFP_KERNEL but reconnect needs GFP_NOIO to ensure progress in low memory situations. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: sbp2: Fix SCSI sense data manglingChris Boot2012-02-221-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCSI sense data in SBP-2/3 is carried in an unusual format that means we have to un-mangle it on our end before we pass it to the SCSI subsystem. Currently our un-mangling code doesn't quite follow the SBP-2 standard in that we always assume Current and never Deferred error types, we never set the VALID bit, and we mishandle the FILEMARK, EOM and ILI bits. This patch fixes the sense un-mangling to correctly handle those and follow the spec. Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: sbp2: Ignore SBP-2 targets on the local nodeChris Boot2012-02-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | The firewire-sbp2 module tries to login to an SBP-2/3 target even when it is running on the local node, which fails because of the inability to fetch data from DMA mapped regions using firewire transactions on the local node. It also doesn't make much sense to have the initiator and target on the same node, so this patch prevents this behaviour. Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changed the comment)
| * firewire: sbp2: Take into account Unit_Unique_IDChris Boot2012-02-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the target's unit directory contains a Unit_Unique_ID entry, we should use that as the target's GUID for identification purposes. The SBP-2 standards document says: "Although the node unique ID (EUI-64) present in the bus information block is sufficient to uniquely identify nodes attached to Serial Bus, it is insufficient to identify a target when a vendor implements a device with multiple Serial Bus node connections. In this case initiator software requires information by which a particular target may be uniquely identified, regardless of the Serial Bus access path used." [ IEEE T10 P1155D Revision 4, Section 7.6 (page 51) ] and [ IEEE T10 P1467D Revision 5, Section 7.9 (page 74) ] Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: nosy: Use the macro DMA_BIT_MASK().santosh nayak2012-02-221-2/+2
| | | | | | | | | | | | | | Use the macro DMA_BIT_MASK instead of the constant 0xffffffff Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: core: convert AR-req handler lock from _irqsave to _bhStefan Richter2012-02-221-13/+8
| | | | | | | | | | | | | | | | | | | | fw_core_handle_request() is called by the low-level driver in tasklet context or process context, and fw_core_add/remove_address_handler() is called by mid- or high-level code in process context. So convert address_handler_lock accesses from those which disable local IRQs to ones which just disable local softIRQs. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: core: fix race at address_handler unregistrationStefan Richter2012-02-221-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following unlikely but possible race: CPU 1 CPU 2 ------------------------------------------------------------------------ AR-request tasklet lookup handler unregister handler free handler->callback_data or handler call handler->callback The application which registered the handler has no way to stop nodes sending new requests to their address range, hence cannot prevent this race. Fix it simply by extending the address_handler_lock-protected region from only around the lookup to around both lookup and call. We only need to do so in the exclusive region handler; the FCP region handler already holds the lock around the handler->callback call. Alas this removes the current ability to execute the callback in parallel on different CPUs if it was called for different FireWire cards at the same time. (For a single card, the handler is already serialized.) If this loss of a rather obscure feature is not tolerable, a more complex fix would be required: Add a handler reference counter; wait in fw_core_remove_address_handler() for this conter to become zero. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: core: remove obsolete commentStefan Richter2012-02-221-8/+0
| | | | | | | | | | | | | | | | | | | | Target-like applications or peer-to-peer-like applications require the global address handler registration which we have right now, or a per- card registration. And node lookup, while it would be nice to have, would be impossible in the brief time between self-ID-complete event and completion of firewire-core's topology scanning. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: core: prefix log messages with card nameStefan Richter2012-02-227-57/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associate all log messages from firewire-core with the respective card because some people have more than one card. E.g. firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0 firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0 firewire_core: created device fw0: GUID 0814438400000389, S800 firewire_core: phy config: new root=ffc1, gap_count=5 firewire_core: created device fw1: GUID 0814438400000388, S800 firewire_core: created device fw2: GUID 0001d202e06800d1, S800 turns into firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0 firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0 firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800 firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5 firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800 firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800 This increases the module size slightly; to keep this in check, turn the former printk wrapper macros into functions. Their implementation is largely copied from driver core's dev_printk counterparts. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: net: use dev_printk APIStefan Richter2012-02-221-20/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the log line prefix from "firewire_net: " to "net firewire0: " etc. for the case that several RFC 2734 interfaces are being used in the same machine. Note, the netdev_printk API is not very useful to firewire-net. netdev_notice(net, "abc\n") would result in irritating messages like "firewire_ohci 0000:0a:00.0: firewire0: abc". Nor would a dev_printk on the fw_unit.device to which firewire-net is being bound be useful, because there are generally multiple ones of those per interface (from all RFC 2734 peers on the bus, the local node being only one of them). In the initialization message of each interface, log the PCI device name of the card which is parent of the netdevice instead of the GUID of the peer which was semi-randomly used to establish the netdevice. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: net: identify to driver core as "firewire_net", not "net"Stefan Richter2012-02-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On second thought, there is little reason to have driver name differ from module name. Therefore, change /sys/bus/firewire/drivers/net /sys/bus/firewire/devices/fw0.0/driver -> [...]/net /sys/module/firewire_net/drivers/firewire:net to /sys/bus/firewire/drivers/firewire_net /sys/bus/firewire/devices/fw0.0/driver -> [...]/firewire_net /sys/module/firewire_net/drivers/firewire:firewire_net It is redundant but consistent with firewire-sbp2's recently changed driver name. I don't see this anywhere used, so it should not matter either way. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: sbp2: identify to driver core as "firewire_sbp2", not "sbp2"Stefan Richter2012-02-221-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit eba9ebaaa26d "firewire: sbp2: use dev_printk API" changed messages from e.g. firewire_sbp2: fw3.0: logged in to LUN 0000 (0 retries) to sbp2 fw3.0: logged in to LUN 0000 (0 retries) because the driver calls itself as "sbp2" when registering with driver core and with SCSI core. This is of course confusing, so switch to the name "firewire_sbp2" for driver core in order to match what lsmod and /sys/module/ show. So we are back to firewire_sbp2 fw3.0: logged in to LUN 0000 (0 retries) in the kernel log. This also changes /sys/bus/firewire/drivers/sbp2 /sys/bus/firewire/devices/fw3.0/driver -> [...]/sbp2 /sys/module/firewire_sbp2/drivers/firewire:sbp2 to /sys/bus/firewire/drivers/firewire_sbp2 /sys/bus/firewire/devices/fw3.0/driver -> [...]/firewire_sbp2 /sys/module/firewire_sbp2/drivers/firewire:firewire_sbp2 but "cat /sys/class/scsi_host/host27/proc_name" stays "sbp2" just in case that proc_name is used by any userland. The transport detection in lsscsi is not affected. (Tested with lsscsi version 0.25.) Udev's /dev/disk/by-id and by-path symlinks are not affected either. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: sbp2: use dev_printk APIStefan Richter2012-01-151-42/+51
| | | | | | | | | | | | All messages are uniformly prefixed by driver name and device name now. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: ohci: use dev_printk APIStefan Richter2012-01-151-79/+106
| | | | | | | | | | | | All messages are uniformly prefixed by driver name and device name now. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: move fw_device reference counting from drivers to coreStefan Richter2012-01-155-19/+16
| | | | | | | | | | | | | | | | | | | | fw_unit device drivers invariably need to talk to the fw_unit's parent (an fw_device) and grandparent (an fw_card). firewire-core already maintains an fw_card reference for the entire lifetime of an fw_device. Likewise, let firewire-core maintain an fw_device reference for the entire lifetime of an fw_unit so that fw_unit drivers don't have to. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | Merge tag 'pinctrl-for-3.4' of ↵Linus Torvalds2012-03-2235-1447/+12805
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pinctrl updates for v3.4 from Linus Walleij (*): - Switches the PXA 168, 910 and MMP over to use pinctrl - Locking revamped - Massive refactorings... - Reform the driver API to use multiple states - Support pin config in the mapping tables - Pinctrl drivers for the nVidia Tegra series - Generic pin config support lib for simple pin controllers - Implement pin config for the U300 * tag 'pinctrl-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (48 commits) ARM: u300: configure some pins as an example pinctrl: support pinconfig on the U300 pinctrl/coh901: use generic pinconf enums and parameters pinctrl: introduce generic pin config pinctrl: fix error path in pinconf_map_to_setting() pinctrl: allow concurrent gpio and mux function ownership of pins pinctrl: forward-declare struct device pinctrl: split pincontrol states into its own header pinctrl: include machine header to core.h ARM: tegra: Select PINCTRL Kconfig variables pinctrl: add a driver for NVIDIA Tegra pinctrl: Show selected function and group in pinmux-pins debugfs pinctrl: enhance mapping table to support pin config operations pinctrl: API changes to support multiple states per device pinctrl: add usecount to pins for muxing pinctrl: refactor struct pinctrl handling in core.c vs pinmux.c pinctrl: fix and simplify locking pinctrl: fix the pin descriptor kerneldoc pinctrl: assume map table entries can't have a NULL name field pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state ... (*) What is it with all these Linuses these days? There's a Linus at google too. Some day I will get myself my own broadsword, and run around screaming "There can be only one". I used to be _special_ dammit. Snif.
| * | ARM: u300: configure some pins as an exampleLinus Walleij2012-03-121-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To show how the pin configuration is used on the U300, let's include some configs for two GPIO pins. ChangeLog v1->v2: - Provide a better example, set the clock return pin to pull-up and set the card detect pin to high impedance. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | pinctrl: support pinconfig on the U300Linus Walleij2012-03-124-8/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds pin configuration support for the U300 driver pair, we can now read out the biasing and drive mode in debugfs and configure it using the new configuration API. ChangeLog v1->v2: - Migrate to pin config and generic pin config changes. ChangeLog v2->v3: - Adjust to generic pin config changes in v7 patch set. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | pinctrl/coh901: use generic pinconf enums and parametersLinus Walleij2012-03-121-43/+13
| | | | | | | | | | | | | | | | | | | | | | | | Adjust the COH 901 driver to use the standard enums for biasing and driving pins, alter signature of config function to suit the framework. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | pinctrl: introduce generic pin configLinus Walleij2012-03-127-4/+289
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a split-off from the earlier patch set which adds generic pin configuration for the pin controllers that want it. Since we may have a system with mixed generic and custom pin controllers, we pass a boolean in the pin controller ops vtable to indicate if it is generic. ChangeLog v1->v5: - Follow parent patch versioning number system. - Document the semantic meaning of return values from pin config get functions, so we can iterate over pins and check their properties from debugfs as part of the generic config code. - Use proper cast functions in the generic debugfs pin config file. - Expand generic config to optionally cover groups too. ChangeLog v5->v6: - Update to match underlying changes. ChangeLog v6->v7: - Drop DRIVE_OFF parameter, use bias high impedance for this - Delete argument for drive modes push-pull, od and os. These are now just state transitions. - Delete slew rate rising/falling due to discussions on on proper semantics - Drop config wakeup, struct irq_chip does this for now, add back if need be. - Set PIN_CONFIG_END to 0x7fff making room for custom config parameters from 0x8000 and up. - Prefix accessor functions with pinconf_
| * | pinctrl: fix error path in pinconf_map_to_setting()Linus Walleij2012-03-121-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code was using the union member setting->data.configs.group_or_pin to store a potential error code, but since that member is unsigned the < 0 comparison was not true, letting errors pass through, ending up as mapped to pin "-22". Fix this up and print the error. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | pinctrl: allow concurrent gpio and mux function ownership of pinsStephen Warren2012-03-122-29/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per recent updates to Documentation/gpio.txt, gpiolib drivers should inform pinctrl when a GPIO is requested. pinctrl then marks that pin as in-use for that GPIO function. When an SoC muxes pins in a group, it's quite possible for the group to contain e.g. 6 pins, but only 4 of them actually be needed by the HW module that's mux'd to them. In this case, the other 2 pins could be used as GPIOs. However, pinctrl marks all the pins within the group as in-use by the selected mux function. To allow the expected gpiolib interaction, separate the concepts of pin ownership into two parts: One for the mux function and one for GPIO usage. Finally, allow those two ownerships to exist in parallel. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | Merge branch 'pinctrl-tegra-for-next-diet' into for-nextLinus Walleij2012-03-068-0/+7393
| |\ \
| | * | ARM: tegra: Select PINCTRL Kconfig variablesStephen Warren2012-03-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This causes the Tegra pinctrl driver to be built whenever core Tegra support is enabled. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| | * | pinctrl: add a driver for NVIDIA TegraStephen Warren2012-03-067-0/+7389
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a driver for the Tegra pinmux, and required parameterization data for Tegra20 and Tegra30. The driver is initially added with driver name and device tree compatible value that won't cause this driver to be used. A later change will switch the pinctrl driver to use the correct values, switch the old pinmux driver to be disabled, and update all code that uses the old pinmux APIs to use the new pinctrl APIs. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net> [squashed "fix case of Tegra30's foo_groups[] arrays"] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: forward-declare struct deviceStephen Warren2012-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a dummy declaration of struct device to avoid the following warning: In file included from include/linux/pinctrl/machine.h:15:0, from arch/arm/mach-tegra/board-pinmux.h:18, from arch/arm/mach-tegra/board-trimslice-pinmux.c:20: include/linux/pinctrl/pinctrl.h:115:12: warning: 'struct device' declared inside parameter list [enabled by default] include/linux/pinctrl/pinctrl.h:115:12: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: split pincontrol states into its own headerLinus Walleij2012-03-064-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the pin control state defines into its own header file, since it is used both by machine.h which is facing the platform and by consumer.h which is facing the drivers, and pinctrl.h which is pinctrl-driver internal, let's not have each and every .h file include all others, then isolation is moot. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: include machine header to core.hLinus Walleij2012-03-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct pinctrl_setting contains an enum pinctrl_map_type field, so we need to include machine.h. Also fix kerneldoc to indicate that the pinctrl_setting is about both muxing and other config. Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: Show selected function and group in pinmux-pins debugfsStephen Warren2012-03-052-1/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until recently, the pinctrl pinmux-pins debugfs file displayed the selected function for each owned pin. This feature was removed during restructing in support of recent API rework. This change restoreds this feature, and also displays the group that the function was selected on, in case a pin is a member of multiple groups. Based on work by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: enhance mapping table to support pin config operationsStephen Warren2012-03-059-108/+611
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pinctrl mapping table can now contain entries to: * Set the mux function of a pin group * Apply a set of pin config options to a pin or a group This allows pinctrl_select_state() to apply pin configs settings as well as mux settings. v3: Fix find_pinctrl() to iterate over the correct list. s/_MUX_CONFIGS_/_CONFIGS_/ in mapping table macros. Fix documentation to use correct mapping table macro. v2: Added numerous extra PIN_MAP_*() special-case macros. Fixed kerneldoc typo. Delete pinctrl_get_pin_id() and replace it with pin_get_from_name(). Various minor fixes. Updates due to rebase. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: API changes to support multiple states per deviceStephen Warren2012-03-057-225/+375
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The API model is changed from: p = pinctrl_get(dev, "state1"); pinctrl_enable(p); ... pinctrl_disable(p); pinctrl_put(p); p = pinctrl_get(dev, "state2"); pinctrl_enable(p); ... pinctrl_disable(p); pinctrl_put(p); to this: p = pinctrl_get(dev); s1 = pinctrl_lookup_state(p, "state1"); s2 = pinctrl_lookup_state(p, "state2"); pinctrl_select_state(p, s1); ... pinctrl_select_state(p, s2); ... pinctrl_put(p); This allows devices to directly transition between states without disabling the pin controller programming and put()/get()ing the configuration data each time. This model will also better suit pinconf programming, which doesn't have a concept of "disable". The special-case hogging feature of pin controllers is re-written to use the regular APIs instead of special-case code. Hence, the pinmux-hogs debugfs file is removed; see the top-level pinctrl-handles files for equivalent data. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: add usecount to pins for muxingStephen Warren2012-03-052-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multiple mapping table entries could reference the same pin, and hence "own" it. This would be unusual now that pinctrl_get() represents a single state for a client device, but in the future when it represents all known states for a device, this is quite likely. Implement reference counting for pin ownership to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: refactor struct pinctrl handling in core.c vs pinmux.cStephen Warren2012-03-054-376/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change separates two aspects of struct pinctrl: a) The data representation of the parsed mapping table, into: 1) The top-level struct pinctrl object, a single entity returned by pinctrl_get(). 2) The parsed version of each mapping table entry, struct pinctrl_setting, of which there is one per mapping table entry. b) The code that handles this; the code for (1) above is in core.c, and the code to parse/execute each entry in (2) above is in pinmux.c, while the iteration over multiple settings is lifted to core.c. This will allow the following future changes: 1) pinctrl_get() API rework, so that struct pinctrl represents all states for the device, and the device can select between them without calling put()/get() again. 2) To support that, a struct pinctrl_state object will be inserted into the data model between the struct pinctrl and struct pinctrl_setting. 3) The mapping table will be extended to allow specification of pin config settings too. To support this, struct pinctrl_setting will be enhanced to store either mux settings or config settings, and functions will be added to pinconf.c to parse/execute pin configuration settings. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: fix and simplify lockingStephen Warren2012-03-055-122/+215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: fix the pin descriptor kerneldocLinus Walleij2012-03-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The introduction of the owner field on the pin descriptor was not properly documented so fix this up. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: assume map table entries can't have a NULL name fieldStephen Warren2012-03-024-21/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pinctrl_register_mappings() already requires that every mapping table entry have a non-NULL name field. Logically, this makes sense too; drivers should always request a specific named state so they know what they're getting. Relying on getting the first mentioned state in the mapping table is error-prone, and a nasty special case to implement, given that a given the mapping table may define multiple states for a device. Remove a small part of the documentation that talked about optionally requesting a specific state; it's mandatory now. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that stateStephen Warren2012-03-026-152/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Dong Aisheng <dong.aisheng@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | | pinctrl: enhance pinctrl_get() to handle multiple functionsStephen Warren2012-03-023-27/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present, pinctrl_get() assumes that all matching mapping table entries have the same "function" value, albeit potentially applied to different pins/groups. This change removes this restriction; pinctrl_get() can now handle a set of mapping tables where different functions are applied to the various pins/groups. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-05 05:01:47 +0000