Re: h5400_wifi - proposal for the driver

On Št, 2008-05-08 at 00:53 +0200, Michal Panczyk wrote:
> Hello (full working) list :)

  Hello:)

> I would like to propose the first step of getting a nice wifi driver
> for h5000 devices. I tried to get some help on that on kernel-discuss
> but due to current situation of the kernel development it failed.
>
> My work was mostly concentrated on h5400_wifi.c - mostly stripping the
> old version to the very necessary minimum. All the work was inspired
> by Milan Plizk - chats on irc, post at angstrom-devel and or bugzilla.
> In current form driver works. The procedure is simple (but needs to be
> simplified !). The driver sets two bits to enable the wifi device -
> for details see [1].
> To get the wifi working the ohci_hcd need to be loaded before the
> h5400_wifi. I think this is the first thing that needs to be changed -
> make the h5400_wifi depend on the ohci module.

  This sounds viable -- you could use request_module to do that, and
combined with proper Kconfig dependency on OHCI_HCD, it should work as
desired (if h5400_wifi is compiled and loaded, we are sure we also have
ohci_hcd in memory).

> The next thing the module does is activates the led. In current form
> it is the left red one blinking, showing that the module is loaded. It
> does not show "connected" state, or rx/tx activity (as in wince -
> AFAIR).

  LEDs should be fully controlled by at76_usb in ideal case (newer
at76_usb is even capable of triggering LEDs). There should be somewhere
also patched version of older at76_usb, which "blinks" (or at least some
patch) :)

> Another problem with the driver, or more precisely with the kernel is
> that the GPIOs are not reseted after reboot - once the module is
> loaded, bits are set, and the machine is reseted, the bits stay set
> on. This results in uncontrolled wifi activation after loading
> ohci_hcd module, with no h5400_wifi module.

  If you are speaking about "hardware reset", I think disabling wifi in
h5400.c would suffice. But this is more an ugly hack than good solution.
Maybe if would be worth the effort if h5400_wifi exported some sysfs
files, which could be used for manipulation with wifi state; maybe even
separate for radio and for wifi chip itself.

>
> The future of the driver is:
> -merging it to h5400.c

  Yes, this is neccessity.

> -figure out a nice way to control activation if the wifi device
> instead of loading/unloading module

  See two paragraphs above :)

> -making it powersave in sleepmode
> -more control of leds (rx, tx activity signaling)

  I think this should be handled by the at76_usb driver itself.

> -investigating the driver crashes

  ... and this as well, plus samcop's DMA and OHCI :)

>
> Please keep in mind that this is just a proposal - I worked on that
> and tested the driver in a bit older kernel version - one from
> angstrom-devel, where bt and bl were not yet merged in the h5400.c. I
> can supply a test image after some progress is made.
>
> I attach a patch against cvs.
>
> I would be more than happy to answer all questions concerning this
> proposal. I would really like to see it working with no "ugly hacks",
> so all the help is appreciated.

  The sysfs-way might be good enough for now. I also have the original
idea in my head, where wifi could be enabled using ifconfig wlan0 up,
but I'm not sure whether it can be hacked easily enough.

        Milan

>
> _______________________________________________
> H5400-port mailing list
> H5400-port_at_handhelds.org
> https://www.handhelds.org/mailman/listinfo/h5400-port
Received on Thu May 08 2008 - 04:13:35 EDT