Hello, This might be slightly off-topic, but I do think it will be interesting to some people here, so please read on.
I recently acquired a tablet based on the Intel Atom Z3735G SoC (Baytrail microarchitecture). The tablet came with Windows 8.1 preinstalled, which isn't of much interest to me. Debian 8 runs quite well - except that half the hardware isn't working. Of particular interest is the touch screen: It's a Silead GSL1680, which hasn't been used in x86 hardware much, as far as I know. All of the drivers I could find for this controller seem to be custom-built for specific Android devices. I also found the userspace driver by Sergio Costas. It seems much more useful, but has a drawback: You need to manually figure out the exact hardware pin assignments and create a custom launcher script for every device model. And it doesn't seem like it's guaranteed to work. I haven't been successful so far. So, that got me thinking... Wouldn't it be better to have a kernel driver, optimally even in mainline Linux, that works everywhere? There are a few pros and cons to that approach. + Hardware configuration can be automatically extracted from the ACPI DSDT or the DeviceTree by the kernel + Much of the basic HID/I2C/Interrupt/GPIO functionality is built in and doesn't need to be reimplemented + The driver will load automatically when appropriate hardware is detected in a system + Better performance than in userspace - Loading device firmware/calibration/configuration data is more complicated - The configuration is still device specific and needs to be passed from userspace Since I have zero experience with writing Linux kernel drivers, this is a bit of a tour de force. However, I have looked at similar drivers (linux/drivers/input/touchscreen/*i2c* are of particular interest), and I think it should be doable, even for a novice. I have collected two important bits so far: - The corresponding DSDT entry from my tablet - A header file containing the configuration data that was shipped with the Windows driver I also found the data sheet for the GSL1680/3680. It's marked as "Release under NDA", so I'm not going to post it here. The filename is GSL1680.pdf, so you may easily find it yourself. The data sheet also mentions an application note and a configuration tool. Those would be interesting material, but I think the data sheet and existing driver code are sufficient write a new generic kernel driver. The things I want to figure out first, are: - Is there a vendor-supplied DeviceTree definition for a specific device, or does every manufacturer rely on hardcoded data in the driver? - What's the general structure of the "firmware"? Is it just a configuration file and calibration data, or does it contain actual program code? Can we split the two and use the code or part of the configuration for all GSLx680 devices? I wrote a driver skeleton that loads and matches successfully and gets the important data (I2C bus, device address and interrupt line number) from the DSDT passed by the kernel. I'm not doing anything with it yet, except logging. Interestingly, the IRQ number does not match what's written in the DSDT. There must be some kind of internal translation going on? See my fork of Joe Burmeister's sunxi-gslx680 project here: https://github.com/onitake/gslx680-acpi The DSDT and firmware header are in acpi/, the skeleton is in gslx680_ts_acpi.c. I also changed the Makefile to build for the local machine instead of cross compiling. Regards, Greg -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
