Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Arend, Tomasz,

On Mon, Jan 27, 2014 at 8:20 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote:
> Hi Chen-Yu, Arend,
>
>
> On 26.01.2014 22:39, Arend van Spriel wrote:
>>
>> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede@xxxxxxxxxx>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>>> Quick update, I've just tested:
>>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>>
>>>>>
>>>>>
>>>>> About this, I would like to move WiFi power control to a regulator,
>>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>>
>>>>
>>>>
>>>> Actually the sunxi-mci.c driver already has support for an optional
>>>> regulator called vmmc.
>>>>
>>>> I like this idea, I've done a version of the dt patch using a regulator
>>>> instead of rfkill here:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>>
>>>> This works as advertised and IMHO is the better solution.
>>>
>>>
>>> I have a version in another branch I haven't pushed. I had it using an
>>> always-on regulator. I can adjust it to use vmmc.
>>>
>>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>>> in mmc core.
>>> We should re-use code if possible, wouldn't you agree?
>>>
>>>>>> About the oob interrupt stuff not working, AFAIK you should set a
>>>>>> pinctrl
>>>>>> function (not input, but a function like mmc is a function) on the pin
>>>>>> in
>>>>>> question
>>>>>> for it to work as external interrupt, I believe you're not doing so in
>>>>>> your
>>>>>> dts.
>>>>>
>>>>>
>>>>>
>>>>> The pinctrl driver seems to set the function when the interrupt is
>>>>> enabled.
>>>>> Unfortunately we don't have any documentation/examples on how to use
>>>>> them.
>>>>> I will look into that later.
>>>>
>>>>
>>>>
>>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>>> gpio-input,
>>>> maybe that conflicts ?
>>>
>>>
>>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>>> but then the whole thing hung. Looks like pinctrl irqchip was not
>>> properly handling chained interrupts. I have done a simple fix, and I
>>> hope to test it tomorrow. Then I'll do some more testing with different
>>> configurations and hopefully write some documents.
>>
>>
>> Hi Chen-Yu,
>>
>> I had a look at github tree from Hans with your DT support patch for
>> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
>> the bindings are still experimental, but I would prefer you to use brcm
>> instead of broadcom in the 'compatible' entry as found in
>> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
>> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
>> but I guess that train has left and it is tricky to change it now.

I will fix this, though the only reason I did this is for the
OOB interrupts.

>> In the brcmfmac patch you also use multiple of_device ids. Could we make
>> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
>> or whatever...
>
>
> brcmfmac and wifi-fullmac strings sound to generic for me. What happens if
> an incompatible brcmfmac chip shows up? I'd rather use something like
> "bcm43xx" to cover existing chip family, if all the bcm43xx chips are
> compatible, or something more specific otherwise.
>
> By the way, you might find this thread interesting:
>
> http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783

Yeah I've been following this thread.

> In addition to the general idea of handling power control, I have also
> posted a link to my patch adding DT support to brcmfmac driver.

Actually since that thread started, I prefer handling the regulators and
possibly clocks in the mmc controller, as Olof posted. But that's just
my opinion.


Cheers,
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux