Hi George, On 01/10/2012 01:14 AM, George Kashperko wrote: > Hi, Hauke. > >> On 01/09/2012 08:14 PM, George Kashperko wrote: >>> Hello, Hauke! >>> >>> Spotted a typo in drivers/ust/host/ssb-hcd.c >>> #define SSB_OHCI_CORECTL_HOSTMODE (1 << 13) >>> >>> It should be 1 << 29 for SSB as SiliconBackplane control flags are at >> high >>> 16 bits of SSB_TMSHIGH >> >> In drivers/usb/host/ssb-hcd.c in OpenWrt brcm47xx it says: >> #define SSB_HCD_TMSLOW_HOSTMODE (1 << 29) >> >> When searching for SSB_OHCI_CORECTL_HOSTMODE I found your patch >> changing >> it to (1 << 13). Did you get a little confusion or am I wrong? ;-) > To keep things the same for both ssb and ssb/ai I've used control flags in > unsigned short, just 16bits. > Thus flags were 1:1 for axi; for ssb respective abstraction handlers' code > behind device_(enable|reset) did << 16 > So for mine ssb/ai patches 1 << 13 will be 1 << 13 + 16 > For pure ssb it should be 1 << 29 So the code, currently in OpenWrt trunk, is correct? > >> >>> Also, for bcma-based EHCI to work correctly it requires OHCI to be >> driven >>> as well >>> or USB1.1 devices won't work (researched and reported by Joel Crisp >>> <joel.a.crisp at googlemail.com>) so it seems reasonable to have >>> +kmod-usb-ohci in package/kernel/modules/usb.mk (might with >> +kmod-usb2 as >>> well). >> EHCI just supports USB 2.0, in general for USB 1.1 support an other >> interface like OHCI or UHCI is needed [0]. Yeah it would make sense to >> add a dependency to kmod-usb2 for the OHCI or UHCI driver depending on >> the platform, I will talk with the other developers about it as it does >> not affect brcm47xx only, but all USB 2.0 controllers. > Just looked through package/kernel/modules/usb.mk again. Think I'm wrong > here as you already have +TARGET_brcm47xx:kmod-usb-brcm47xx in DEPENDS for > both ohci and ehci. kmod-usb-brcm47xx just provides the common usb driver drivers/usb/host/bcma-hcd.ko and drivers/usb/host/ssb-hcd.ko, the problem when installing just kmod-usb2 and and using an usb 1.1 device still exists. Most users do not know that USB 2.0 just provides support for USB 2.0 devices and not for USB 1.1 devices. > Actually it even wiser to keep it in this way rather than back-reference > them from usb-brcm47xx as I thought initially. So please just forget it - > its really fine as it is now. Yes the references between the ochi and ehci driver before would probably make it impossible to integrate it into the mainline Linux kernel and it cause some confusions for the users. > Overall there could be done few cleanups for the (ssb|bcma)-hcd.c, If you > don't plan to do it yourself I could do a patch and send you for review in > few days as soon as get some spare time and finish testings on 47XX SoCs > I've got. I would appreciate a patch with some cleanups for (ssb|bcma)-hcd.c. My current plan is to send it for Linux mainline inclusion in the next weeks. Currently there is still a problem with the BCM5357 Tathagata is working on and I do not have a device which uses the usb controller on the ssb bus to the the ssb part. > >> While I am writing you, I would like to apply >> http://www.znau.edu.ua/temp/asus-rt-n16/2012-01-01T23-55/000-openwrt471 >> 6-TARGET_brcm4716-prereq.patch >> to OpenWrt trunk, are you fine with that? > Sure thing, I'm not a Broadcom guy and don't stamp PROPRIETARY UNPUBLISHED > here and there :P > Btw I see good room for broadcom-diag gpio code cleanup. We could could > modify half-assed generic gpio to be finally compliant with it completely > moving out that #ifdefs into chipcommon/extif code and rm -f src/gpio.h Yes that needs cleanup. src/gpio.h is just there to also support the old and removed Broadcom code using kernel 2.4 and should be removed. I am planing to convert the GPIO support to libgpio as there are 3 different gpio devices on the broadcom target (ssb extif, ssb chipcommon and bcma chipcommon). I am thinking about moving the device detection code from broadcom-diag to arch/mips/bcm47xx/ so all drivers are able to use it. The flash driver need some device detection to not overwrite some special partitions and there are also some workaround in b44 for some devices. > >> We also wrote a spec [1] of the gmac et driver, so someone (now Rafał) >> is able to implement a clean room developed driver for the gmac core. > Great ! Hopefully we will have fully functional GPL-compliant 4716 system > soon. >
Hauke _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
