On Fri, Jul 06, 2007 at 01:20:04PM +0200, EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng) wrote:
> I have drivers for the following SH7720 onchip devices, but only for 2.4
> usb-host, which was based on the generic usb-ohci.c
> usb-gadget, is also listet on the usb-gadget site, but seems to be 2.4
> only
> LCD controller (found nowhere else)
>
> Does anybody know if there are recent versions of these drivers?
>
The USB drivers I don't know about, there's always been very little in
the way of feedback from people actually using these things on the older
parts. I've added Shimoda-san to the CC, perhaps he has some ideas about
USB support on SH7720.
As for the LCD controller, there are quite a few various implementations
floating around. You might look at something like hitfb to see if you're
able to adapt it for your needs. Porting a 2.4 framebuffer driver to 2.6
is not a lot of work, and those are fairly trivial to merge, the main
thing to remember is that a lot of parts have rather similar controllers,
albeit occasionally with a few differences that make code-sharing more
problematic.
> I also had the smsc9115 ethernet controller working in 2.4 with the sh3
> driver from the smsc homepage. There is a SMSC911X driver in 2.6, but it
> is only for Xscale (ARCH_PXA), has anybody already portet it on SH?
> STLinux has a 2.6 port of the driver from SMSC included in their kernel,
> but a driver, already in vanilla would be nice.
>
Use smc91x, it's in use by most of the solution engine boards, the
sh4-202 microdev, and numerous others.
On Fri, Jul 06, 2007 at 04:50:22PM +0200, Manuel Lauss wrote:
> Free drivers for recent Linux kernels are almost non-existant;
> fortunately the datasheets are quite good (compared to other embedded SoCs I'm
> working with..) and writing linux drivers isn't that hard ;-)
>
This largely goes back to the point that most vendors snapshot an ancient
kernel, focus their product development there, and then toss out a
tarball so they're compliant with the letter of the license.
Surprisingly, this doesn't actually help anyone, and so while we're
easily able to hunt down numerous antiquated drivers in various states of
disarray, it does require a bit of a push or at least rudimentary support
from the vendor in order to get this stuff merged.
We've too often had the situation where a vendor has submitted some
platform code and drivers, it's been merged, and then they're never heard
from again. This leads to a maintenance nightmare, and it's really just
not worth the trouble. This is getting better for some platforms and some
drivers, but it's still something that needs quite a bit of work.
It comes down to development methodology. So, if people want drivers for
their platforms integrated, do your development on a current kernel, work
with community developers rather than against them, and then pull those
back in to your snapshotted product tree rather than trying to push them
out after the fact. If folks can't do that, don't expect to see many
drivers in mainline.
|
