From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C9A547E for ; Fri, 7 Aug 2015 12:40:55 +0000 (UTC) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9FEBE143 for ; Fri, 7 Aug 2015 12:40:54 +0000 (UTC) Received: by oio137 with SMTP id 137so52233109oio.0 for ; Fri, 07 Aug 2015 05:40:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20150723105726.GC30929@amd> <20150723121441.GB29747@amd> <20150723084251.54da2be0@gandalf.local.home> <20150723154014.GD11162@sirena.org.uk> <55B7FD82.8010806@sonymobile.com> <20150728230743.GO4753@usrtlx11787.corpusers.net> <55C2337A.9010500@gmail.com> Date: Fri, 7 Aug 2015 14:40:53 +0200 Message-ID: From: Linus Walleij To: Marcel Holtmann , Ulf Hansson Content-Type: text/plain; charset=UTF-8 Cc: Bjorn Andersson , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH , "kyungmin.park@samsung.com" , John Stultz , Pavel Machek Subject: Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Aug 5, 2015 at 7:00 PM, Marcel Holtmann wrote: >>> Current Bluetooth/WiFi chips usually come in these flavors. WiFi on >>> PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on >>> SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a >>> mobile phone, you can choose the low power version you like. And this >>> often turns into SDIO for WiFi and UART for Bluetooth. >> >> SDIO is such a pain. The hosts and devices have so many quirks as there >> is no interoperability testing. > > What I have found is that the quirks are in the host controller for SDIO. > Once that is working, the drivers have less quirks to handle Yeah and SDIO is more common for WLAN than for BT indeed. What we've seen (paging Ulf Hannson) is that SDIO has had a number of quirks because of two things: - Devices that are not cards require a non-power of two byte transfer, and often hardware quirks to even write say 1, 2 or 3 bytes in the 32bit out FIFO registers. - Power sequencing WRT the device on the outer side, which has been addressed in drivers/mmc/core/pwrseq.c First is just basic driver features not uniformly implemented, the second I think is addressed now, just tricksy to use. Linus Walleij