- 22 Aug, 2009 19 commits
-
-
Marcel Holtmann authored
The Marvell driver has some weird quirks on how to construct proper SKBs with Bluetooth HCI commands. Fix it to use skb_put properly and also use hci_opcode_pack instead of self-crafted macro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
For some reason the btmrvl_device struct has a name field that the SDIO fills in, but then never ever uses again. That is totally pointless and so just remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
Make the module description entries for the core and also the Marvell SDIO driver match common practive inside the Bluetooth subsystem. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The Marvell Bluetooth SDIO driver has a really complicated concept on how firmware names are assigned to specific device ids. Fix that by doing a proper structure and assign it to the module device table. And while at it fix various coding style weirdness that is still present in this driver. Signed-off-by: Marcel Holtman <marcel@holtmann.org>
-
Marcel Holtmann authored
The Marvell core Bluetooth driver has various weird casting and unneeded braces in its code that makes it hard to read. Remove all of these to make the code a little bit simpler. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The Marvell Bluetooth driver has debugfs support and they are casting like there is no tomorrow. Remove all of them and magically the code becomes more readable. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
Both header files of the Marvell Bluetooth driver are private anyway and if the driver happens to include them twice or they create a circular dependency then the driver needs fixing. So just remove both pointless ifdefs. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The Makefile entry for the Marvell driver is broken when it comes to handling the optional DEBUG_FS correctly. That must have been the reason why they were using select in Kconfig in the first place. Fix this and make it really optional. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The Marvell driver selects DEBUG_FS and FW_LOADER for its core driver and that is pointless. Don't select DEBUG_FS since it is either enabled or not and it is not for the driver to enable it. Also FW_LOADER is only used within the SDIO driver and so just have that one select the FW_LOADER option. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
add btmrvl.txt to Documentation/ This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
/debug/btmrvl/config/ /debug/btmrvl/status/ See Documentation/btmrvl.txt for details. This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
This driver supports Marvell Bluetooth enabled devices with SDIO interface. Currently only SD8688 chip is supported. The helper/firmware images of SD8688 can be downloaded from this tree: git://git.infradead.org/users/dwmw2/linux-firmware.git This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
This driver provides basic definitions and library functions to support Marvell Bluetooth enabled devices, such as 88W8688 WLAN/BT combo chip. This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The core exports the hci_conn_hold_device() and hci_conn_put_device() functions for device reference of connections. Use this to ensure that the uevents from the parent are send after the child ones. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The device model itself has no real usable reference counting at the moment and this causes problems if parents are deleted before their children. The device model itself handles the memory details of this correctly, but the uevent order is not consistent. This causes various problems for systems like HAL or even X. So until device_put() does a proper cleanup, the device for Bluetooth connection will be protected with an extra reference counting to ensure the correct order of uevents when connections are terminated. This is not an automatic feature. Higher Bluetooth layers like HIDP or BNEP should grab this new reference to ensure that their uevents are send before the ones from the parent device. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
Currently the HID subsystem will create HIDRAW devices for the transport driver, but it will not disconnect them. Until the HID subsytem gets fixed, ensure that HIDRAW and HIDDEV devices are disconnected when the Bluetooth HID device gets removed. Based on a patch from Brian Rogers <brian@xyzw.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Vikram Kandukuri authored
This patch increases the receive buffer size to HCI_MAX_FRAME_SIZE which improves the RX throughput considerably. Tested against BRM/Atheros/CSR USB Dongles with PAN profile using iperf and chariot. This gave significant (around 40%) increase in performance (increased from 0.8 to 1.5 Mb/s in Sheld room) Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Vikram Kandukuri authored
There is a test case in PTS tool; PTS will send the VIRTUAL_CABLE_UNPLUG command to IUT. Then IUT should disconnect the channel and kill the HID session when it receives the command. The VIRTUAL_CABLE_UNPLUG command is parsed by HID transport, but it is not scheduled to do so. Add a call to hidp_schedule() to kill the session. Signed-off-by: Jothikumar Mothilal <jothikumar.mothilal@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The SCO sockets for Bluetooth audio setup and streaming are missing the shutdown implementation. This hasn't been a problem so far, but with a more deeper integration with PulseAudio it is important to shutdown SCO sockets properly. Also the Headset profile 1.2 has more detailed qualification tests that require that SCO and RFCOMM channels are terminated in the right order. A proper shutdown function is necessary for this. Based on a report by Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
-
- 21 Aug, 2009 1 commit
-
- 20 Aug, 2009 20 commits
-
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
The current mwl8k_priv->fw_lock spinlock doesn't actually protect against multiple commands being submitted at once, as it is not kept held over the entire firmware command submission. And since waiting for command completion sleeps, we can't use a spinlock anyway. To fix mwl8k firmware command serialisation properly, we have the following requirements: - Some commands require that the packet transmit path is idle when the command is issued. (For simplicity, we'll just quiesce the transmit path for every command.) - There are certain sequences of commands that need to be issued to the hardware sequentially, with no other intervening commands. This leads to an implementation of a "firmware lock" as a mutex that can be taken recursively, and which is taken by both the low-level command submission function (mwl8k_post_cmd) as well as any users of that function that require issuing of an atomic sequence of commands, and quiesces the transmit path whenever it's taken. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Delete most of the mwl8k_work_struct fields and options, since most of them are unused or never changed from their defaults: - We always use priv->config_wq, so delete the wqueue argument from mwl8k_queue_work(). - MWL8K_WQ_SPIN and MWL8K_WQ_POST_REQUEST are never used, as all callers sleep for request completion, so sleep unconditionally. - MWL8K_WQ_FREE_WORKSTRUCT is never used. - MWL8K_WQ_TX_WAIT_EMPTY is always set, so assume it unconditionally. - timeout_ms/txwait_attempts/tx_timeout_ms are never changed from their defaults, so just hardcode these in the workqueue worker. - step is never used. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Various mwl8k_txq_xmit changes: - Extract the QoS field before adding the DMA header. - Only write to tx->status once, and only after all the other descriptor fields have been set. - Do all tx state manipulation under the tx spinlock. - Remove the priv->inconfig check, as all transmit queues will be frozen during config cycles, so we won't ever be asked to transmit if a config cycle is running. - Remove some more dead code. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Use MWL8K_TX_QUEUES instead of a hardcoded "4" in a couple of places. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Since firmware load commands don't generate 'command done' interrupts like normal commands do, polling for command done interrupts just unnecessarily slows down the firmware load process. Removing this bit of code speeds up loading a typical firmware image from 840 msec to 180 msec. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
Adding and removing the DMA header that the mwl8k hardware requires on tx and provides on rx can never fail, since we are guaranteed to have enough headroom on the tx path to expand the packet, and we only ever shrink the packet on the rx path. (And on both paths we are guaranteed to be the only user of the skb we are handling.) This allows removing all of the skb clone handling in the tx and tx reclaim paths, and eliminates error checks in both the tx and rx paths, simplifying the code a bit more. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lennert Buytenhek authored
There is no need to check for NL80211_IFTYPE_MONITOR in ->add_interface(), as this function is never called for monitor interfaces. Also, there is no need to advertise this bit in our wiphy's ->interface_modes. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-