On 05/16/2014 10:21 AM, Nick Dyer wrote: > Stephen Warren wrote: >> On 05/08/2014 01:50 PM, Nick Dyer wrote: >>> The patches I posted at the end of March are the first 22 out of this tag: >>> >>> https://github.com/ndyer/linux/tree/for-next-20140316-v8 >> >> I took those 22 patches, applied them on top of next-20150507 (which is >> just what I happened to be developing on top of right now), and rebased >> my patches which add DT support. You can find the result here if you want: >> >> git://github.com/swarren/linux-tegra.git tegra_dev > > Thanks for this. Would you be happy for me to pick these changes up and > include them along with the other work I am sending to Dmitry? I am just > beginning to do various updates to the whole series, one of the things I > need to sort out is the device tree support. That would be fine. I assume you'd only take the 2 Atmel driver patches. I'll send the Tegra patches separately once the driver is merged. One thing I wasn't really sure about: With your latest patches, it seems like the bootloader address is auto-calculated from the application address. As such, do I still need separate struct i2c_device for the application and bootloader I2C addresses? If not, we should remove the atmel,mxt-tp-bootloader from those patches. If so, I need to add the second DT node back into the Tegra DT. Either way, it might be preferable if we only had 1 node in DT, and the driver automatically handled the two separate I2C addresses. > I will need to add device tree parameters for the touchscreen as well as > the touchpad, of course. > > By the way, the driver should work without any firmware file and just use > the firmware and configuration from NVRAM - request_firmware() returns a > failure and it continues through mxt_initialize(). Hmmm. I couldn't get that to work after applying the patches you posted. However, it did with what's already in linux-next plus the patches I sent. > In a later patch in my long series, I make the MXT_CFG_NAME configurable > from platform data (because you may have multiple devices needing different > configs), and leaving it null means the call to request_firmware() is skipped. It'd be preferable to automatically derive the firmware name from the device type (touchscreen/touchpad) or some other parameter that can be calculated at run-time, or queried from HW (e.g. version # from bootloader?). I'm not sure that putting firmware filenames in DT is a good idea, but perhaps that would work. Deriving firmware filename from the DT compatible value would work best. If different HW needs different firmware, it should probably have a different compatible value in DT. I don't want to build firmware filenames into the kernel at compile-time, since I want to be able to take a single kernel and run it on any ARM board, each of which might use different firmware, but all the same, use the same root filesystem (on an SD card) on all boards, without having to rename firmware. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
